一个可用 Agent 的 8 个核心模块

如果只从模型能力理解 Agent，很容易把系统设计做薄。

我更愿意把 Agent 拆成八个模块：Instruction、Context、Planning、Tool Use、Execution、Verification、Memory、Permission。

Instruction
Context
Planning
Tool Use
Execution
Verification
Memory
Permission

这八层不是框架概念，而是我判断一个 Agent 能不能进入真实项目的检查清单。

1. Instruction：指令层

指令层回答的问题是：这个 Agent 是谁，应该遵守什么规则，什么事情不能做。

它不应该只有一句角色提示词。真实项目里的指令层应该包含：

• 产品目标
• 工作边界
• 输出规范
• 风险约束
• 团队约定
• 优先级规则

对开发类 Agent 来说，AGENTS.md、项目 README、代码风格、测试要求，都属于指令层的一部分。

2. Context：上下文层

上下文层决定 Agent 能不能理解现场。

上下文不是越多越好，而是要分层：

• 全局上下文：项目定位、技术栈、长期规则
• 任务上下文：本次需求、验收标准、限制条件
• 环境上下文：文件结构、运行结果、错误日志
• 历史上下文：之前的决策、失败尝试、用户偏好

好的上下文设计不是堆 token，而是让 Agent 在正确时间看到正确信息。

3. Planning：规划层

规划层负责把目标拆成可执行步骤。

但规划不是越详细越好。简单任务不需要复杂计划，复杂任务才需要显式拆解。过度规划会浪费上下文，也会让 Agent 变慢。

我更倾向于让规划层输出三类信息：

• 当前目标
• 关键步骤
• 验证方式

只要这三件事清楚，Agent 就不容易跑偏。

4. Tool Use：工具层

工具层决定 Agent 能改变什么。

工具不是越多越好。每接入一个工具，都要同时设计：

• 输入参数
• 返回结构
• 权限范围
• 失败处理
• 审计日志
• 是否允许写操作

工具层的质量，直接决定 Agent 是稳定执行系统，还是随机自动化脚本。

5. Execution：执行层

执行层负责把计划变成动作。

这里最重要的是节奏控制。Agent 不能一次性做太多不可逆动作。更稳的方式是小步执行、持续观察、及时修正。

在代码场景里，这意味着：先读文件，再改小块，再跑检查，再继续。不要一上来全局重构。

6. Verification：验证层

没有验证的 Agent 不值得信任。

验证可以有很多形式：

• 运行测试
• 读取命令输出
• 对比文件 diff
• 检查页面截图
• 校验结构化数据
• 让用户确认高风险决策

Agent 的汇报里应该明确说出验证了什么，而不是只说“完成了”。

7. Memory：沉淀层

Memory 不等于把所有对话都存起来。

真正有价值的记忆是可复用决策：

• 用户偏好
• 项目约定
• 常用流程
• 已知坑点
• 重要架构选择

Memory 应该少而准，并且允许修正。错误记忆比没有记忆更危险。

8. Permission：权限层

权限层是 Agent 进入生产环境的门槛。

我会把权限拆成几个级别：

• 只读：只能搜索、读取、分析
• 建议：能生成方案，但不能执行
• 沙箱写入：能改测试环境或临时文件
• 受控写入：能改真实资源，但需要确认
• 自动执行：只给低风险、可回滚任务

这套设计比简单的“允许 / 拒绝”更适合长期使用。

总结

一个可用 Agent 不是一个模型加几个工具。

它应该是一套执行系统：有指令、有上下文、有计划、有工具、有执行、有验证、有沉淀，也有权限边界。

当你开始按这八层设计 Agent，很多问题会变清楚：该给它什么信息，该让它调用什么工具，该在哪里停下来，该如何证明它真的完成了任务。