企业官网建设流程全解析

认知具身智能体架构（Cognitive Embodied Agents Architecture，CEAA）并不是一个抽象的框架名词，而是一类专门面向交互式计算系统的设计思路。通俗地说，它希望解决一个长期存在的矛盾：大模型智能体在单轮问答里表现不错，但一旦进入需要连续感知环境、拆解任务、调用工具、根据反馈修正计划的交互式场景，就容易出现上下文混乱、工具调用失败后无法恢复、记忆丢失、决策链断裂等问题。CEAA 的价值在于把智能体拆成可观察、可管理、可测试的多个认知模块，让系统既能理解用户输入，也能在真实执行环境中“行动”并“反省”。

这篇文章不对具体论文做二次转述，而是从工程落地角度，用一套可运行的 Python 原型工程来还原 CEAA 的典型设计：感知层接收用户输入和工具返回结果，认知层完成目标拆解和计划生成，记忆层区分短期上下文与长期知识，行动层执行工具调用，反思层在关键节点评估当前结果是否需要修正。读完你可以掌握这类系统的基本模块划分、数据流走向、关键代码写法，以及上线前必须处理的参数调优、日志排查和稳定性问题。

1. 为什么交互式计算系统需要 CEAA 这类架构

1.1 一个智能体程序为什么会“看起来很笨”

很多团队的第一版 Agent 实现是这样的：用户发来一句话，程序把这句话拼进 Prompt，让大模型输出一段 JSON，JSON 里指定要调用的工具和参数，程序再执行工具，把结果追加进上下文，最后让大模型生成回答。

这个流程在单个工具、单个步骤、网络稳定、模型输出稳定的情况下能跑通。但进入真实交互式系统后，问题会逐个暴露。

第一个问题是上下文没有边界。每轮工具调用结果都往 Prompt 里塞，一旦超过模型上下文窗口，要么截断，要么报错。截断后，用户最初的目标可能已经丢失，智能体继续执行“当前步骤”，而不是“最初的用户目标”。

第二个问题是工具调用失败后没有恢复机制。天气接口超时、数据库查询返回空、参数拼写错误，这些情况在单轮流程中只能报错终止。但真正可用的交互系统应该在失败后重新评估：是换一个工具，还是重新拆解目标，还是直接向用户澄清。

第三个问题是记忆没有分层。短期对话信息、用户偏好、领域知识、历史执行记录混在一起，检索时无法区分优先级，最终导致系统在不同场景下表现不稳定。

CEAA 这类认知架构的核心贡献，就是不让智能体的决策逻辑散落在 Prompt 里，而是把它显式建模成模块：感知、认知、记忆、行动、反思。每个模块只负责一件事，模块之间通过结构化的消息传递数据。

1.2 CEAA 的“具身”到底指什么

“具身智能体”中的“具身”容易让人联想到机器人，但这里的“体”不一定是指物理躯体。在交互式计算系统里，具身可以理解为智能体拥有自己的“执行通道”，能够对运行环境产生影响。

例如：

• 一个智能客服系统，具身通道是查询订单接口、退款接口、知识库检索接口。
• 一个 IDE 编程助手，具身通道是读取文件、执行测试、搜索代码、修改代码的能力。
• 一个网页自动化系统，具身通道是页面点击、输入、滚动、截图的动作接口。
• 一个仿真环境里的决策体，具身通道是移动、转向、抓取等仿真动作。

“具身”意味着智能体不是一个只会生成文本的回答器，而是一个能获取环境反馈并基于反馈调整行动的闭环系统。这就是 CEAA 中 Embodied 的核心含义。

1.3 CEAA 与普通 Agent 框架的差异

普通 Agent 框架更强调“如何让模型调用工具”，CEAA 类架构更强调“如何让系统稳定完成交互任务”。它们的关注点有明显区别：

实际项目不会二选一。多数 CEAA 风格系统底层仍然会依赖函数调用或工具协议，只是上层增加了认知状态机，让整个流程更可控。

2. 核心模块与数据流设计

2.1 五个核心模块

CEAA 风格系统通常包含五个核心模块：

1. 感知模块（Perception）：负责接收用户输入、系统事件、工具返回结果，统一转换成结构化感知信息。
2. 认知模块（Cognition）：负责目标理解、任务拆解、计划生成、步骤选择。它决定“接下来做什么”。
3. 记忆模块（Memory）：负责保存和检索信息，分为短期工作记忆和长期记忆。它决定“我有什么信息可用”。
4. 行动模块（Action）：负责执行具体工具调用、HTTP 请求、代码执行等操作。它决定“如何把决策变成行动”。
5. 反思模块（Reflection）：负责在关键节点评估当前执行结果是否满足目标，决定继续、调整还是终止。它决定“当前做得对不对”。

在实际系统中，认知模块和反思模块通常会多次调用大模型，而且调用逻辑不同。认知模块使用结构化的规划 Prompt，反思模块使用评估 Prompt。两者不能混用，否则反思会被规划逻辑带偏。

2.2 一次完整交互的数据流

一次完整交互可以拆成如下八个阶段：

1. 用户输入到达感知模块。
2. 感知模块对输入做归一化，生成 PerceptionEvent。
3. 记忆模块检索与当前输入相关的长期记忆。
4. 认知模块综合用户目标、短期上下文、长期记忆，输出计划或下一步动作。
5. 行动模块执行工具调用，得到 Observation。
6. 感知模块把 Observation 转成新感知事件。
7. 反思模块判断当前结果是否符合预期。
8. 符合预期则生成最终回复；不符合则回到第 4 步重新规划。

数据流中的关键点是“反馈闭环”。如果不经过第 7 步，系统就退化成普通的单轮工具调用。

2.3 关键状态与消息结构

为了让各模块解耦，消息结构必须稳定。这里给出一个最小 JSON 设计，示例工程会使用同样的结构：

{ "session_id": "sess_10001", "goal": "查询北京今天的天气，并给出穿衣建议", "plan": [ {"step": 1, "action": "weather_query", "params": {"city": "北京", "date": "today"}} ], "current_step": 1, "memory": { "short_term": [ {"role": "user", "content": "北京天气适合穿什么？"} ], "long_term_hits": [ {"content": "用户在北京工作，通勤距离约5公里"} ] }, "last_observation": { "action": "weather_query", "status": "success", "data": {"temperature": 28, "condition": "晴"} }, "reflection": { "need_replan": false, "reason": "天气数据已获取，可直接生成穿衣建议" } }

在这个结构里，goal 始终保留用户最初的目标，不被中间步骤覆盖。plan 是认知模块生成的执行计划，action 是当前正在执行的工具，observation 是工具返回结果，reflection 记录反思模块的判断。调试时只要把每一轮的这个 JSON 打印出来，就能知道系统在哪一步出了问题。

3. 准备原型工程环境

3.1 技术选型

下面这套原型工程使用 Python 3.10+ 实现，主要选型如下：

• FastAPI：提供 HTTP 接口，方便把智能体能力暴露成交互式计算服务。
• Pydantic：定义消息结构和配置模型。
• Chroma：作为长期记忆的向量存储，开发环境可以直接本地运行。
• Redis：保存短期记忆和会话状态，生产环境常用；没有 Redis 时也可以先使用内存版本。
• OpenAI 兼容接口：通过统一的 Chat Completions 接口调用大模型，便于替换不同模型服务。

选择 FastAPI 的原因是异步模型适合工具调用场景。工具调用经常有网络等待，同步阻塞会浪费连接资源。异步接口可以在等待工具返回时继续处理其他请求，提升吞吐量。

3.2 项目目录结构

推荐使用如下目录结构：

ceaa_demo/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI 入口 │ ├── config.py # 配置加载 │ ├── models.py # 消息结构定义 │ ├── memory.py # 记忆模块 │ ├── tools.py # 工具注册与执行 │ ├── agent.py # 认知循环主控制器 │ └── reflection.py # 反思模块 ├── config.yaml # 运行配置 ├── requirements.txt # 依赖列表 └── tests/ └── test_agent.py # 基础测试

这个结构不复杂，但每个模块边界清楚。实际项目可以在此基础上扩展：感知模块单独拆文件、工具按领域分目录、记忆库抽象成接口、日志模块独立接入。

3.3 依赖安装与虚拟环境

先创建虚拟环境并激活：

python3.10 -m venv .venv source .venv/bin/activate

在requirements.txt中写入依赖：

fastapi==0.110.0 uvicorn[standard]==0.29.0 pydantic==2.6.4 pydantic-settings==2.2.1 redis==5.0.3 chromadb==0.4.24 openai==1.30.1 pyyaml==6.0.1 httpx==0.27.0

安装命令：

pip install -r requirements.txt

这里没有把全部依赖锁到具体补丁版本，落地前要结合自己的 Python 版本和模型服务版本重新确认。如果使用新版本 Chroma，接口可能有调整；如果模型服务兼容 OpenAI SDK，openai 包版本也要匹配。

4. 实现一个 CEAA 风格的最小认知体

4.1 配置加载：config.yaml

核心配置放在config.yaml中，代码如下：

agent: name: ceaa-demo max_iterations: 5 reflection_interval: 3 short_term_ttl_seconds: 1800 memory: vector_store: "chroma" collection: "ceaa_memory" long_term_top_k: 3 llm: provider: "openai_compatible" base_url: "http://localhost:8000" # 示例地址，按自己的模型服务配置 api_key: "EMPTY" model: "qwen2.5-7b-instruct" # 示例模型名 temperature: 0.3 max_tokens: 1024 tools: timeout_seconds: 10 enabled_tools: - weather_query - calculator - knowledge_search

参数说明：

• max_iterations：认知循环最大轮数，防止工具反复失败造成死循环。
• reflection_interval：每隔多少轮执行一次反思判断，减少不必要的模型调用。
• short_term_ttl_seconds：短期记忆过期时间。
• long_term_top_k：长期记忆检索时返回的最大条数。
• temperature：生成计划时调低温度，让模型输出更稳定。
• timeout_seconds：工具调用超时时间。

这里强调一点：base_url和model只是一个示例。在真实项目中，必须按自己实际部署的模型服务地址和模型名填写，否则无法运行。

4.2 消息结构定义

在models.py中定义消息结构，使用 Pydantic 可以自动校验字段：

from typing import Any, Optional from pydantic import BaseModel, Field class PerceptionEvent(BaseModel): session_id: str user_input: str extra: dict[str, Any] = Field(default_factory=dict) class MemoryQueryResult(BaseModel): content: str score: float = 0.0 metadata: dict[str, Any] = Field(default_factory=dict) class ActionCall(BaseModel): name: str params: dict[str, Any] = Field(default_factory=dict) class Observation(BaseModel): action: str status: str # success / error data: Optional[Any] = None error: str = "" class ReflectionResult(BaseModel): need_replan: bool = False reason: str = "" should_stop: bool = False

把消息定义成独立数据类的好处是：每个模块只依赖接口，不依赖内部实现。比如反思模块只需要传入goal、plan、observation三个字段，不需要知道记忆模块到底存在 Redis 还是磁盘。

4.3 记忆层：统一接口

记忆模块是 CEAA 里最容易写坏的部分。这里给出一个接口抽象：

class BaseMemoryStore: def save_short_term(self, session_id: str, role: str, content: str) -> None: raise NotImplementedError def load_short_term(self, session_id: str, limit: int = 20) -> list[dict]: raise NotImplementedError def save_long_term(self, content: str, metadata: dict) -> None: raise NotImplementedError def search_long_term(self, query: str, top_k: int = 3) -> list[MemoryQueryResult]: raise NotImplementedError

内存实现：

class InMemoryMemoryStore(BaseMemoryStore): def __init__(self): self.short_term: dict[str, list[dict]] = {} self.long_term: list[dict] = [] def save_short_term(self, session_id: str, role: str, content: str) -> None: self.short_term.setdefault(session_id, []).append( {"role": role, "content": content} ) def load_short_term(self, session_id: str, limit: int = 20) -> list[dict]: return self.short_term.get(session_id, [])[-limit:] def save_long_term(self, content: str, metadata: dict) -> None: self.long_term.append({"content": content, "metadata": metadata}) def search_long_term(self, query: str, top_k: int = 3) -> list[MemoryQueryResult]: # 原型阶段不做向量检索，按顺序返回最近记录 results = [] for item in self.long_term[-top_k:]: results.append( MemoryQueryResult(content=item["content"], score=0.0, metadata=item["metadata"]) ) return results

这个内存实现主要用于跑通流程。实际项目里，save_long_term和search_long_term要替换为向量数据库实现。典型做法是：保存时对content做 embedding，存入向量库；检索时对query做 embedding，再执行相似度查询。

记忆分层的核心原因有三点：

1. 短期记忆必须与长期记忆隔离，否则会话上下文会被历史知识污染。
2. 长期记忆检索必须限制top_k，否则 Prompt 会被无关信息塞满。
3. 短期记忆需要设置过期时间，避免会话状态无限增长。

4.4 工具注册与执行

工具模块的核心是“注册表模式”。每个工具是一个普通函数，通过装饰器注册到全局登记表，认知模块只需要按名称找到并调用：

import time from typing import Callable, Any TOOL_REGISTRY: dict[str, Callable] = {} def register_tool(name: str): def decorator(func: Callable): TOOL_REGISTRY[name] = func return func return decorator @register_tool("calculator") def calculator(expression: str) -> dict: # 注意：生产环境不要直接用 eval，这里仅用于原型演示 allowed_chars = set("0123456789+-*/(). ") if not set(expression).issubset(allowed_chars): return {"error": "仅支持简单数学表达式"} try: result = eval(expression) return {"result": result} except Exception as exc: return {"error": str(exc)} @register_tool("weather_query") def weather_query(city: str) -> dict: # 原型阶段返回模拟数据，生产环境替换为真实天气服务 time.sleep(0.5) return {"city": city, "temperature": 28, "condition": "晴"} async def run_tool(name: str, params: dict, timeout: int = 10) -> Observation: if name not in TOOL_REGISTRY: return Observation(action=name, status="error", error=f"unknown tool: {name}") func = TOOL_REGISTRY[name] try: data = await asyncio.wait_for( asyncio.to_thread(func, **params), timeout=timeout ) return Observation(action=name, status="success", data=data) except asyncio.TimeoutError: return Observation(action=name, status="error", error="tool timeout") except Exception as exc: return Observation(action=name, status="error", error=str(exc))

这里使用asyncio.wait_for是为了给外部工具设置超时。没有超时机制时，一个第三方接口卡住会拖垮整个智能体请求。

注意：Python 的eval不是安全函数。上面 calculator 只是为了演示工具注册机制，生产环境应改用ast.literal_eval或调用后端计算服务，避免任意代码执行风险。

4.5 认知循环主控制器

认知循环是 CEAA 核心中的核心。它负责把感知、记忆、规划、行动、反思串起来：

from typing import Any from .models import Observation, ReflectionResult from .memory import BaseMemoryStore from .tools import run_tool class CognitiveAgent: def __init__(self, memory: BaseMemoryStore, llm_client, config: dict): self.memory = memory self.llm_client = llm_client self.config = config async def run(self, session_id: str, user_input: str) -> dict: short_context = self.memory.load_short_term(session_id, limit=20) long_memories = self.memory.search_long_term( user_input, top_k=self.config.get("long_term_top_k", 3) ) goal = await self._plan(user_input, short_context, long_memories) self.memory.save_short_term(session_id, "user", user_input) for step in range(1, self.config.get("max_iterations", 5) + 1): action = await self._decide_next_action(goal, short_context, long_memories) if action is None: break observation = await run_tool( action.name, action.params, timeout=self.config.get("tools", {}).get("timeout_seconds", 10) ) self.memory.save_short_term(session_id, "tool", observation.model_dump_json()) if step % self.config.get("reflection_interval", 3) == 0: reflection = await self._reflect(goal, observation) if reflection.need_replan: goal = await self._replan(goal, reflection.reason) if observation.status == "error": continue if self._is_goal_finished(action, observation): break final_answer = await self._generate_answer( goal=goal, session_id=session_id, short_context=short_context ) self.memory.save_short_term(session_id, "assistant", final_answer) return {"session_id": session_id, "answer": final_answer}

_plan、_decide_next_action、_reflect都会调用大模型，但 Prompt 完全不同。这里的关键设计是：每一步的模型输出都要解析成结构化对象，解析失败时记录日志，并让系统进入重试或终止分支，而不是直接崩溃。

4.6 暴露 HTTP 交互接口

在main.py中把智能体包成一个 HTTP 服务：

from fastapi import FastAPI from pydantic import BaseModel from .agent import CognitiveAgent from .memory import InMemoryMemoryStore app = FastAPI() memory = InMemoryMemoryStore() agent = CognitiveAgent(memory=memory, llm_client=None, config={}) class ChatRequest(BaseModel): session_id: str message: str @app.post("/chat") async def chat(req: ChatRequest): result = await agent.run(session_id=req.session_id, user_input=req.message) return result @app.get("/health") async def health(): return {"status": "ok"}

上面的agent.py中真正调用大模型时，需要传入llm_client。建议在启动前先用 mock 客户端测试完整流程，避免模型服务不稳定影响代码调试。

5. 参数说明与调优方向

5.1 核心参数速查表

认知型智能体的性能不只看模型质量，还看参数是否合理。下面这张表列出原型工程中最常见的调优参数。

5.2 如何判断参数是否合理

判断标准不是“参数看着合理”，而是看三个指标：

1. 任务完成率：复杂任务最终是否得到有效结果。
2. 平均轮数：一笔请求平均执行了多少轮工具调用。
3. 反思触发率：反思模块触发重新规划的比例。

如果平均轮数超过max_iterations的 80%，说明计划拆分可能过于细碎，或工具调用失败率过高。如果反思触发率低于 5%，可能说明反思 Prompt 太宽松，没有真正发现执行偏差。如果反思触发率高于 40%，则要考虑初始规划 Prompt 是否不够清晰，导致频繁返工。

调参时不要一次性改多个参数。每次只改一个，通过日志和测试集对比效果，才能定位影响来源。

5.3 学习环境与生产环境的参数差异

学习环境可以直接使用上面的默认值，重点是把链路跑通。生产环境需要额外考虑：

6. 运行与验证

6.1 启动服务

确认配置无误后，启动 FastAPI 服务：

uvicorn app.main:app --host 0.0.0.0 --port 8000

在启动阶段，先访问健康检查接口：

curl http://127.0.0.1:8000/health

预期返回：

{"status": "ok"}

此时只能确认进程活着，不能证明认知链路正常。

6.2 调用交互接口

发送一条测试请求：

curl -X POST http://127.0.0.1:8000/chat \ -H "Content-Type: application/json" \ -d '{"session_id": "sess_001", "message": "北京今天天气怎么样"}'

正常响应的结构类似：

{ "session_id": "sess_001", "answer": "北京今天晴，气温 28 度，建议穿短袖或薄衬衫。" }

如果接入的是 mock 大模型，则可能返回固定文本，这属于正常现象。关键是观察日志中是否输出了感知、规划、行动、反思的完整事件。

6.3 检查中间状态与日志

强烈建议在CognitiveAgent.run()中增加结构化日志输出，下面示例直接打印关键状态：

import json from .models import ActionCall, Observation def log_state(self, step: int, goal: str, action: ActionCall, observation: Observation): print(json.dumps({ "event": "agent_step", "step": step, "goal": goal, "action": action.name, "action_params": action.params, "observation_status": observation.status, "observation_data": observation.data, "observation_error": observation.error }, ensure_ascii=False))

验证时重点关注以下内容：

1. goal 是否一直保留原始用户目标。
2. plan 是否被正确拆成步骤。
3. action 名称是否在 TOOL_REGISTRY 中存在。
4. observation 是 success 还是 error。
5. reflection 是否触发了 replan。
6. 最后生成的 answer 是否引用了有效 observation 数据。

如果日志缺失其中任何一项，说明对应模块没有执行或没有输出，需要优先补齐。

7. 常见问题排查

7.1 问题现象与处理方案

下面这组问题是从实际开发中总结出来的高频问题。

7.2 一条从用户输入到输出的排查链路

遇到问题时，建议按下述顺序排查，而不是直接怀疑大模型：

1. 先看输入是否正确到达感知模块：session_id 是否一致，message 是否完整。
2. 看记忆模块是否返回了错误内容：短期上下文是否包含脏数据，长期记忆是否命中无关内容。
3. 看认知模块输出的计划是否合理：工具名是否正确，参数是否完整，步骤顺序是否符合逻辑。
4. 看行动模块执行结果：工具是否注册，是否超时，返回数据是否被正确封装成 Observation。
5. 看反思模块判断：是否因为一个合理结果触发了 replan，或因为错误结果错误地选择了继续。
6. 最后看答案生成模块：是否使用了 observation 中不存在的字段，是否忽略了检索到的记忆。

这个顺序按输入、状态、决策、执行、反馈、输出排列。大部分问题发生在第 2 步和第 4 步，而不是模型推理本身。

7.3 三个最容易踩的坑

第一个坑：把短期记忆无限塞进 Prompt。有些实现每轮都把全部对话历史传给模型，结果上下文越来越长、费用越来越高、回答越来越不稳定。推荐做法是按 token 预算做截断或摘要，只保留最近几轮和关键目标信息。

第二个坑：工具返回结果不做结构校验。外部接口可能返回异常类型，比如None、空字符串、嵌套多层 JSON。如果直接把原始结果拼进 Prompt，模型可能会编造不存在的数据。推荐把工具结果统一转换成Observation，并对必填字段做校验。

第三个坑：没有结束条件。如果max_iterations设置过大，而反思模块又判断“继续执行”，复杂任务可能运行几十分钟还停不下来。推荐给每个 session 增加总耗时上限，并允许用户在接口层主动取消任务。

8. 从学习原型到生产环境的扩展

8.1 生产化之前必须先补齐的能力

学习阶段的重点是跑通链路，生产环境还需要补齐以下能力：

8.2 生产化上线前检查清单

下面这个清单可以在发布前逐项确认：

• [ ] 所有工具是否都有超时和异常处理。
• [ ] 是否移除eval、动态命令执行等高危操作。
• [ ] 大模型接口的api_key是否从环境变量或密钥服务读取。
• [ ] 短期记忆是否有过期策略和容量上限。
• [ ] 长期记忆是否有写入审核和敏感信息过滤。
• [ ] 用户输入是否经过长度限制和内容安全校验。
• [ ] 工具调用参数是否经过 schema 校验。
• [ ] 每个 session 是否有最大执行轮数和总耗时上限。
• [ ] 是否记录了完整的 trace 日志，能还原每轮决策。
• [ ] 是否具备一键终止某个 session 执行的能力。
• [ ] 是否配置了模型调用失败后的重试和降级策略。
• [ ] 是否在测试集上跑过至少 20 条典型任务，统计完成率和平均轮数。

这个清单不是一次性工作，而是每次改动核心 Prompt 或工具注册后都要跑一遍的回归检查。

8.3 扩展方向

CEAA 风格架构的扩展可以从下面几个方向入手。

第一，增加环境感知能力。不只是接收用户文本，还可以接入网页截图、系统日志、音频输入、模拟器状态，让感知模块处理多模态输入。

第二，增强决策规划。从单步决策升级为支持树搜索或蒙特卡洛搜索，在复杂任务中评估多条路径后再选择执行，适合任务状态空间较大的场景。

第三，完善记忆体系。可以加入“情景记忆”和“语义记忆”的区分，情景记忆保存具体事件的执行过程，语义记忆保存从事件中抽象出来的规则，检索时结合时间权重和相关性权重。

第四，引入人类反馈。反思模块不只依赖模型自评，还可以在关键节点向用户确认“我理解的目标是 X，是否继续”，减少因目标理解错误导致的大规模返工。

第五，把认知循环抽象成领域语言。例如在智能运维领域定义“告警感知、故障定位、预案选择、执行变更、验证恢复、复盘反思”六段状态机，每个领域都可以在 CEAA 基础上定制自己的认知流。

8.4 给新手的练习建议

如果刚接触这类架构，不要直接追求复杂功能。先用本项目的原型跑通一条最简单的工具调用链，比如“用户提问 -> 查天气 -> 返回建议”。然后逐步加入记忆、反思、失败恢复，每加一个模块都要观察日志的变化。

第二个练习是故意制造失败。把天气工具改成一个必然超时的假接口，观察认知循环如何进入错误分支，反思模块是否触发 replan。失败场景比成功场景更能暴露架构问题。

第三个练习是替换记忆后端。把InMemoryMemoryStore换成 Chroma 实现，用一批历史记录做检索测试，对比检索结果的相关性。记忆检索质量会直接影响认知模块的决策质量。

等这三个练习做完，再决定是否引入更复杂的消息队列、任务调度和多智能体协作。CEAA 这类架构的核心不是“模块越多越高级”，而是“每份状态都有明确归属，每次决策都有反馈闭环”。能把闭环做扎实，系统才真正具备在交互式计算环境中稳定工作的基础。