Agent Basic / 03
一个 Agent 系统的核心组成
很多 Agent 教程的问题在于，它们喜欢直接上框架代码，但不先把系统拆开。
结果就是你能跑出一个 Demo，却说不清楚：
- 哪部分负责决策
- 哪部分负责保存状态
- 哪部分负责调用工具
- 哪部分负责限制系统乱跑
如果这些边界不清楚，后面系统一复杂，就很难维护。
不要先从框架开始，要先从模块开始
一个最小但像样的 Agent 系统，通常可以拆成下面这些部分：
Goal：目标State：状态Model：模型Tools：工具Memory：记忆Planner / Policy：决策逻辑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 系统理解成下面这个流程：
Goal
-> State 初始化
-> Planner 判断下一步
-> Model 生成动作或参数
-> Tools 执行外部动作
-> State 更新
-> Evaluator / Guardrails 检查
-> 继续循环或结束
这个图本身不复杂，但它决定了你后面写出来的是“系统”，还是“很多 prompt 和 if-else 拼在一起的脚本”。
一个务实建议
在你真正开始做 Agent 之前，先别急着选框架。
先拿一张纸把下面这些问题写清楚：
- 目标是什么
- 状态里放什么
- 哪些能力必须通过工具获得
- 哪些决策交给模型，哪些决策交给程序
- 什么时候结束，什么时候失败，什么时候人工介入
如果这些问题答不清楚，再高级的框架也救不了设计问题。
小结
Agent 不是一个“会自己动起来的模型”，而是一套模块协作的系统。
先把模块边界想清楚，后面不管你用 LangGraph、Agents SDK 还是自己写执行循环，都会稳很多。
下一篇建议接着看：