--- layout: default title: 一个 Agent 系统的核心组成 description: 从系统视角拆开 Agent 的关键模块 eyebrow: Agent Basic / 03 --- # 一个 Agent 系统的核心组成 很多 Agent 教程的问题在于，它们喜欢直接上框架代码，但不先把系统拆开。 结果就是你能跑出一个 Demo，却说不清楚： - 哪部分负责决策 - 哪部分负责保存状态 - 哪部分负责调用工具 - 哪部分负责限制系统乱跑 如果这些边界不清楚，后面系统一复杂，就很难维护。 ## 不要先从框架开始，要先从模块开始 一个最小但像样的 Agent 系统，通常可以拆成下面这些部分： 1. `Goal`：目标 2. `State`：状态 3. `Model`：模型 4. `Tools`：工具 5. `Memory`：记忆 6. `Planner / Policy`：决策逻辑 7. `Evaluator / Guardrails`：评估与约束 不是每个系统都必须把这些拆成独立模块，但你脑子里必须有这张图。 ## 1. Goal：系统到底在完成什么 目标定义的是： - 任务要解决什么问题 - 输出应该长什么样 - 任务什么时候算完成 如果目标本身不清晰，Agent 往往会表现成： - 做很多无关动作 - 无限探索 - 输出看起来努力，但没有完成任务 所以很多 Agent 问题，根本不是模型问题，而是目标定义问题。 ## 2. State：系统当前处于什么状态 `State` 是 Agent 系统最容易被忽略、但最关键的部分之一。 它可以包含： - 当前任务输入 - 已完成的步骤 - 已获取的信息 - 中间分析结果 - 下一步待办 - 是否满足结束条件 如果没有明确状态，系统每次执行都像重新开始。 这会直接导致： - 上下文混乱 - 重复调用工具 - 无法恢复执行 - 很难调试 所以很多现代 Agent 框架强调状态驱动，不是为了“高级”，而是为了可维护。 ## 3. Model：负责理解、推理和生成 模型本身通常负责下面几类工作： - 理解任务 - 解释上下文 - 决定下一步动作 - 生成结构化结果 - 生成最终输出 但要注意： > 模型不是整个 Agent，模型只是 Agent 中的一个核心组件。 如果把所有能力都堆给模型提示词，系统会变得很脆弱。 ### Context 是模型能力的天花板 模型每一步决策的质量，取决于它当时能看到什么。这个“能看到什么”就是 Context。 Context 通常包含：系统指令、工具定义、用户输入、历史轨迹、检索到的外部资料、结构化状态。 所以 Agent 的能力天花板往往不是模型参数量，而是 **Context 的组织质量**： - 关键约束是否在上下文中 - 历史信息是否被合理裁剪 - 检索结果是否相关 - 工具描述是否让模型能正确选择 这就是为什么 “Context Engineering”（上下文工程）被单独作为一个工程方向对待。它比 Prompt Engineering 范围更大——不只是写好提示词，而是设计整个信息供给策略。 ## 4. Tools：让 Agent 获得外部能力 没有工具的 Agent，能力边界通常非常窄。 工具可以包括： - 搜索 - 数据库查询 - API 请求 - 文件读写 - 代码执行 - 外部系统操作 工具解决的是“模型本身做不到”的事情。 例如模型不能直接知道今天实时市场价格，但它可以决定去调用价格查询工具。 ### 工具的三种类型 从功能角度，工具通常可以归为三类： | 类型 | 作用 | 举例 | | --- | --- | --- | | 感知类（Perception） | 获取信息 | 搜索、数据库查询、文件读取、API 拉取 | | 执行类（Execution） | 产生外部副作用 | 写入数据库、发送消息、创建资源、执行代码 | | 协作类（Collaboration） | 与其他 Agent 或人类交互 | 发送消息给另一个 Agent、请求人工审批 | 这个分类的实际价值在于：**不同类型的工具需要不同的安全策略**。 - 感知类工具通常可以放心重试，因为没有副作用 - 执行类工具需要幂等保护和审批机制，因为重复执行可能造成损害 - 协作类工具需要明确的通信协议和超时处理 在设计工具系统时，先把每个工具归类，再决定对应的权限、重试和审计策略，比一刀切地处理所有工具更稳。 ## 5. Memory：让系统不总是失忆 记忆至少可以分成两种： ### 会话内记忆 用于当前任务过程中的状态延续，例如： - 已经查过哪些数据 - 前面做过哪些判断 - 当前分析到了哪一步 ### 跨会话记忆 用于长期偏好、历史记录或用户画像，例如： - 用户关注哪些风险指标 - 过去的分析习惯 - 历史结论和反馈 不是每个场景都需要长期记忆，但大多数 Agent 至少需要会话内状态记忆。 ## 6. Planner / Policy：决定接下来做什么 这是 Agent 和普通 Workflow 差别最大的地方之一。 这里要解决的问题不是“模型会不会说”，而是： - 下一步是否需要工具 - 用哪个工具 - 是否需要继续收集信息 - 什么时候该停止 在简单系统里，这部分可能只是一个 Prompt。 在复杂系统里，它可能会变成一套显式的状态机、策略函数或图结构。 ## 7. Evaluator / Guardrails：防止系统看起来在工作，实际上在失控 这部分经常被 Demo 忽略，但真实系统离不开。 它们通常负责： - 检查输出格式是否正确 - 检查证据是否充足 - 检查结果是否越权 - 控制成本、延迟和工具调用次数 - 在必要时触发人工接管 如果没有这些约束，Agent 很容易出现两种常见问题： - 一本正经地产生错误结论 - 为了完成任务不断尝试，直到把成本和时间拉爆 ## 把这些模块串起来看 你可以把一个典型 Agent 系统理解成下面这个流程： ```text Goal -> State 初始化 -> Planner 判断下一步 -> Model 生成动作或参数 -> Tools 执行外部动作 -> State 更新 -> Evaluator / Guardrails 检查 -> 继续循环或结束 ``` 这个图本身不复杂，但它决定了你后面写出来的是“系统”，还是“很多 prompt 和 if-else 拼在一起的脚本”。 ## 一个务实建议 在你真正开始做 Agent 之前，先别急着选框架。 先拿一张纸把下面这些问题写清楚： 1. 目标是什么 2. 状态里放什么 3. 哪些能力必须通过工具获得 4. 哪些决策交给模型，哪些决策交给程序 5. 什么时候结束，什么时候失败，什么时候人工介入 如果这些问题答不清楚，再高级的框架也救不了设计问题。 ## 小结 Agent 不是一个“会自己动起来的模型”，而是一套模块协作的系统。 先把模块边界想清楚，后面不管你用 LangGraph、Agents SDK 还是自己写执行循环，都会稳很多。 下一篇建议接着看： - [为什么很多 Agent Demo 一落地就不稳定](../04-why-agent-demos-break/index.html)