摘要

很多人理解 AI Agent，停留在“大模型负责思考，工具负责执行，知识库负责提供资料”这一层。

这个理解可以解释一个 Agent Demo 是如何搭建出来的，却解释不了一个 Agent 为什么会在真实业务中重复调用工具、丢失任务状态、引用错误资料，甚至在执行了一半之后彻底失控。

真正的 AI Agent，不是“大模型加几个工具”，而是一套围绕大模型构建的闭环执行系统。

在这套系统中：

• Token 决定上下文预算；

• Prompt 定义行为边界；

• RAG 提供事实证据；

• Tool 负责执行原子动作；

• Skill 定义专业工作方法；

• MCP 负责连接外部系统；

• SDD 明确开发规格；

• Harness 控制整个任务的运行过程。

本文将从工程视角拆解这些概念之间的关系，并通过一个企业级供应商风险分析案例，解释一个真正可以进入生产环境的 Agent 应该如何设计。

关键词： AI Agent、RAG、MCP、Skill、Harness、SDD、上下文工程、智能体架构

---

一、为什么“大模型加工具”不等于 AI Agent

很多人第一次接触 AI Agent，脑子里会形成一个非常直观的架构：

大模型负责思考，接几个工具负责干活，再连接一个知识库，这不就是 Agent 吗？

这个理解不能说错，但它只解释了一个 Agent Demo 是怎么搭出来的。

它无法解释下面这些问题：

• 为什么有些 Agent 演示时很惊艳，正式使用时却经常卡死？

• 为什么同一个任务，有时能完成，有时会重复调用工具？

• 为什么 Agent 接入了知识库，依然会一本正经地胡说八道？

• 为什么接入 MCP 后，模型仍然不会主动规划任务？

• 为什么给 Agent 几十个工具，它反而更容易选错？

• 为什么一个简单的“读取数据、生成报告、发送邮件”，进入生产环境后会变得异常复杂？

问题的根源在于：

模型会生成内容，不代表系统能够稳定完成任务。

普通大模型解决的是一个相对简单的问题：

用户问题
→ 模型生成
→ 返回答案

而 Agent 面对的通常不是一个问题，而是一个目标。

例如：

分析过去一年的销售数据，找出下降最严重的产品，生成一份管理层报告，并发送给负责人。

这个目标不可能通过一次文本生成完成。

Agent 至少需要经历：

接收目标
→ 分析任务
→ 拆分步骤
→ 查询数据
→ 检查数据
→ 计算指标
→ 生成报告
→ 验证报告
→ 请求审批
→ 发送邮件

而且，每执行完一步，Agent 都必须观察结果。

如果数据库查询失败，需要判断是重试、更换查询方式，还是停止任务。

如果数据字段缺失，需要停止分析，或者明确标记数据缺口。

如果报告中的数字与原始数据不一致，需要重新计算。

如果邮件涉及外部收件人，需要进入人工审批流程。

所以，真正的 Agent 不是一个单向生成系统，而是一个不断循环的执行系统：

目标
→ 决策
→ 行动
→ 观察
→ 验证
→ 修正
→ 再行动

这才是 Agent 与普通聊天机器人的本质区别。

---

二、先建立正确的 Agent 分层模型

Token、Prompt、Skill、RAG、MCP、SDD 和 Harness 经常被并列介绍。

这种方式便于记忆，但从工程角度看并不准确。

因为这些概念解决的根本不是同一种问题。

更合理的方式，是把 Agent 系统划分为四个层次。

1. 资源与上下文层

包括：

• Token

• Prompt

• RAG

• Memory

• Context Engineering

这一层决定模型能够看到什么信息，以及应该如何理解这些信息。

2. 能力与执行层

包括：

• Tool

• Skill

• Function Calling

• Workflow

这一层决定 Agent 能做什么，以及应该按照什么方法完成任务。

3. 连接与协议层

包括：

• MCP

• API

• Connector

• 数据库连接器

• 文件系统连接器

这一层负责把外部系统、数据和工具暴露给 Agent。

4. 开发与运行控制层

包括：

• SDD

• Harness

• Evaluation

• 权限管理

• 状态管理

• Checkpoint

• Human-in-the-loop

这一层决定 Agent 如何被开发、约束、执行、恢复和验证。

很多 Agent 项目失败，并不是模型不够强，而是一开始就把不同层级的问题混在了一起。

例如：

• 用 Prompt 代替权限系统；

• 用 MCP 代替任务规划；

• 用向量数据库代替完整 RAG；

• 用聊天记录代替任务状态；

• 用模型自我判断代替独立评估。

这些设计在 Demo 阶段可能可以运行，但很难进入生产环境。

---

三、Token：不仅是计费单位，更是 Agent 的上下文预算

很多人对 Token 的理解，停留在“调用模型需要按 Token 收费”。

这当然没有错。

但对于 Agent 来说，Token 更重要的含义是：

Token 是 Agent 在当前推理过程中可以使用的上下文预算。

模型在一次任务中看到的所有内容，最终都会占用 Token。

包括：

• 系统提示词；

• 用户任务；

• 历史对话；

• RAG 检索结果；

• 工具定义；

• 工具调用参数；

• 工具返回结果；

• 当前任务状态；

• 模型生成内容。

可以把上下文窗口想象成一张办公桌。

办公桌越大，确实可以放更多资料。

但桌子大，不代表工作效率一定高。

如果桌面上堆满了无关文档、重复信息、过期对话、几百个工具说明和未经筛选的数据，模型不仅不会变得更聪明，反而更容易受到干扰。

因此，Agent 的 Token 优化，不是简单地压缩文字，而是解决四个问题：

1. 什么信息应该进入当前上下文？

2. 信息应该在什么时候进入？

3. 信息应该以什么结构进入？

4. 哪些历史内容可以丢弃或压缩？

1. 不要一次加载所有工具

假设一个企业 Agent 拥有 300 个工具。

如果每次执行任务，都把这 300 个工具的名称、参数和说明全部放入上下文，会产生两个问题。

第一，消耗大量 Token。

第二，增加模型选择错误工具的概率。

更合理的方式是先进行工具检索。

例如用户提出：

查询供应商交付情况，并生成风险报告。

系统只需要加载：

• 供应商查询工具；

• 订单查询工具；

• 交付率计算工具；

• 报告生成工具。

而不是把招聘、库存、财务、客户管理、邮件、审批等所有工具全部交给模型。

这可以称为：

Tool Retrieval，工具检索。

工具不是越多越好，而是当前任务中暴露给模型的工具越准确越好。

2. 不要把海量原始数据塞给模型

假设用户要求分析十万条订单。

错误做法是把十万条订单全部交给模型阅读。

正确做法是先通过数据库、SQL 或程序完成：

• 筛选；

• 聚合；

• 排序；

• 统计；

• 异常检测；

• 指标计算。

然后只把关键结果交给模型解释。

例如：

订单总量：103,258 条
延期订单：8,741 条
整体延期率：8.46%
延期最严重产品：产品 A
延期率最高区域：华南地区
连续三个月恶化供应商：7 家

模型适合进行判断、归纳、解释和表达。

数据库与程序更适合执行精确计算。

不要让大模型代替数据库，也不要让数据库代替大模型进行业务解释。

3. 长任务不能依赖完整聊天记录

任务执行时间越长，历史内容越多。

如果每一轮都携带完整对话，Token 会持续膨胀，关键任务信息也会被大量过程文本淹没。

成熟的 Agent 不会把全部历史对话当作状态。

它会把执行过程压缩成结构化数据，例如：

当前目标：生成供应商年度风险报告

已完成：
1. 订单数据查询
2. 交付指标计算
3. 质量记录查询

失败记录：
1. 合同系统第一次查询超时
2. 第二次查询成功

当前产物：
1. delivery_summary.json
2. quality_summary.json

下一步：
检索合同风险条款

这就是 Context Engineering，也就是上下文工程。

Prompt Engineering 关注的是：

一句话应该怎么写，模型才能回答得更好？

Context Engineering 关注的是：

在整个任务过程中，模型每一轮究竟应该看到什么？

对于生产级 Agent，后者往往比前者更加重要。

---

四、Prompt：不是一句提问，而是 Agent 的行为协议

在普通聊天场景中，Prompt 可能只是：

帮我写一封邮件。

但在 Agent 场景中，Prompt 不再只是任务描述，而更像一份行为协议。

一个完整的 Agent Prompt 至少需要说明：

• Agent 是谁；

• Agent 负责什么；

• 当前目标是什么；

• 什么条件算任务完成；

• 可以使用哪些信息；

• 可以调用哪些工具；

• 工具应该如何调用；

• 遇到异常应该怎么办；

• 什么情况下必须停止；

• 什么情况下需要人工审批。

例如，一个企业知识库 Agent，如果 Prompt 只写：

你是一个企业知识助手，请准确回答用户问题。

这样的提示词几乎没有真正的约束能力。

更完整的规则应该是：

1. 只允许基于检索到的企业资料回答。
2. 资料不足时输出“Information Not Available”。
3. 不得根据常识补充企业内部信息。
4. 每个关键结论必须附带来源。
5. 多个文档版本冲突时，优先使用仍然生效的正式版本。
6. 涉及薪酬、客户、合同和个人信息时，必须检查用户权限。
7. 连续检索两次仍无有效资料时，停止生成答案。

这时，Prompt 已经不是“提问技巧”，而是在定义 Agent 的决策边界。

但是必须注意：

Prompt 只能承担软约束，不能代替真正的权限控制。

例如：

不得删除生产数据。

这句话不能只写在 Prompt 中。

因为模型可能理解错误，也可能在复杂任务中忽略规则。

正确的做法应该是三层防护：

第一层：Prompt 引导

告诉模型不得执行删除操作。

第二层：工具限制

不向模型暴露生产环境的删除工具。

第三层：权限控制

即使模型生成了删除请求，服务端也会进行身份、角色和操作权限校验。

因此，生产级 Agent 应该遵循：

Prompt 负责引导，代码负责限制，权限系统负责兜底。

---

五、Tool 与 Skill：工具解决动作，Skill 解决工作方法

Skill 是目前最容易被误解的 Agent 概念之一。

很多人会说：

• 查询天气是一个 Skill；

• 发送邮件是一个 Skill；

• 查询数据库是一个 Skill。

严格来说，这些能力更接近 Tool，也就是工具。

1. Tool 是原子动作

Tool 负责完成一个边界明确的操作，例如：

• 查询订单；

• 读取文件；

• 执行 SQL；

• 发送邮件；

• 创建工单；

• 生成 PDF；

• 调用搜索接口。

一个 Tool 通常具有明确的输入和输出。

例如：

输入：
supplier_id
start_date
end_date

输出：
订单列表

Tool 只负责“做一个动作”，并不负责决定完整工作应该如何开展。

2. Skill 是完成工作的专业方法

Skill 解决的是：

如何组合多个动作，按照正确流程完成一类工作。

例如，“生成月度销售复盘报告”这个 Skill，可能包含：

1. 读取本月和上月销售数据；

2. 检查数据完整性；

3. 按区域、客户和产品进行拆分；

4. 计算同比、环比和目标完成率；

5. 识别异常增长与异常下降；

6. 生成管理层摘要；

7. 按照公司模板制作报告；

8. 检查报告数字是否与原始数据一致；

9. 交给负责人审批。

这个过程中可能调用多个 Tool，但整个业务流程才是一个 Skill。

一个完整的 Skill 通常包含：

• 适用范围；

• 触发条件；

• 输入要求；

• 标准工作流程；

• 工具使用说明；

• 异常处理方式；

• 输出模板；

• 检查清单；

• 参考文档；

• 自动化脚本。

可以用一句话理解：

Tool 是手里的工具，Skill 是使用这些工具完成工作的专业方法。

如果一个 Agent 拥有大量 Tool，却没有高质量 Skill，它就像一个安装了很多软件、但没有接受岗位培训的新人。

它可能知道如何打开 Excel、查询数据库和发送邮件，却不知道一份合格的经营分析报告应该包含什么。

真正拉开 Agent 差距的，往往不是工具数量，而是 Skill 的质量。

---

六、RAG：真正解决的不是“模型不知道”，而是“答案没有证据”

RAG 经常被比喻成让大模型参加开卷考试。

这个比喻很形象。

大模型在预训练过程中学到的是通用知识，但企业真正需要的通常是：

• 内部制度；

• 产品资料；

• 客户要求；

• 项目文档；

• 技术规范；

• 会议纪要；

• 历史案例；

• 实时业务数据。

这些信息不适合全部写入 Prompt，也不可能每次都重新训练模型。

RAG 的基本流程是：

用户问题
→ 检索外部资料
→ 获取相关证据
→ 将证据交给模型
→ 基于证据生成答案

但是，很多团队接入一个向量数据库之后，就认为 RAG 已经完成了。

实际上，向量检索只是 RAG 中间的一步。

一个完整的企业 RAG 系统通常包括：

1. 文档采集；

2. 文件解析；

3. OCR 识别；

4. 内容清洗；

5. 重复数据处理；

6. 文档分类；

7. 元数据标注；

8. 权限标注；

9. 语义切片；

10. 索引构建；

11. 查询理解；

12. 关键词检索；

13. 向量检索；

14. 混合召回；

15. 结果重排序；

16. 证据组合；

17. 答案生成；

18. 引用生成；

19. 事实验证；

20. 效果评测。

任何一个环节出现问题，最终答案都可能错误。

1. 文档解析错误

PDF 中的表格没有正确解析，模型看到的内容本身就是错误的。

2. 切片错误

一条完整制度被拆成多个不相关片段，适用条件与最终结论被分开。

3. 检索错误

用户问的是“差旅住宿上限”，系统召回的却是“差旅报销流程”。

两者语义相关，但不是同一个问题。

4. 版本错误

系统检索到了相关制度，但该制度已经废止。

5. 权限错误

用户没有权限查看的文件，因为向量相似度较高而被召回。

6. 生成错误

检索内容是正确的，但模型总结时加入了资料中不存在的判断。

因此，RAG 的真正价值不是简单地给模型增加知识。

而是：

为模型生成的关键结论建立一条可以追溯的证据链。

一个成熟的企业 RAG，不应该只回答：

公司的住宿报销标准是每天 500 元。

而应该回答：

根据《差旅管理制度 V3.2》第 4.1 节，某级别员工的住宿标准为每天 500 元。该制度于某年某月某日正式生效。

如果资料没有明确说明，就应该输出：

Information Not Available

而不是根据行业经验自行补全。

这才是企业级 RAG 与普通问答机器人的区别。

---

七、MCP：统一连接外部能力，但不负责思考

MCP 经常被称为“AI 世界的 USB-C”。

这个比喻比较准确。

在没有统一协议时，一个 Agent 要连接不同系统，通常需要分别开发：

• 数据库连接器；

• 文件系统连接器；

• 邮件连接器；

• CRM 连接器；

• ERP 连接器；

• 浏览器连接器；

• 搜索连接器。

每个系统的参数格式、权限方式和调用逻辑都不相同。

MCP 的价值，是把这些外部能力以统一方式暴露给 AI 应用。

Agent 可以通过 MCP 发现：

• 有哪些资源可以读取；

• 有哪些工具可以调用；

• 每个工具需要什么参数；

• 工具会返回什么结果；

• 有哪些 Prompt 模板可以使用。

但是必须明确：

MCP 解决的是连接问题，不是决策问题。

它不会自动赋予 Agent 自主规划能力。

有了 MCP，Agent 只是更容易连接外部系统。

至于：

• 什么时候调用工具；

• 应该调用哪个工具；

• 调用失败怎么办；

• 是否需要重试；

• 返回结果是否可信；

• 任务是否已经完成；

• 是否需要人工审批；

这些都不是 MCP 负责的。

更准确的关系是：

MCP 提供接口
Tool 提供动作
Skill 提供方法
模型负责判断
Harness 负责控制

这也是为什么有些系统接入 MCP 后，Agent 依然不稳定。

连接能力只是 Agent 的基础设施，不是 Agent 的完整运行逻辑。

---

八、SDD：AI 写代码越快，规格越不能模糊

SDD 通常指 Spec-Driven Development，也就是规格驱动开发。

它的基本流程是：

定义规格
→ 制定方案
→ 拆分任务
→ 编码实现
→ 验证结果

传统开发中，经验丰富的工程师面对一句模糊需求，通常会主动询问细节。

但是 AI 编程 Agent 往往不会停下来等待。

当你告诉它：

帮我开发一个企业知识库。

它可能立刻生成：

• 文件上传页面；

• 向量数据库；

• 聊天窗口；

• 检索接口；

• 简单的后台管理功能。

看起来功能完整，但大量关键问题根本没有被定义：

• 支持哪些文件格式？

• 扫描 PDF 如何处理？

• 文档版本如何管理？

• 删除原文件后，向量数据是否同步删除？

• 不同部门是否可以查看彼此的资料？

• 回答是否必须附带引用？

• 错误引用如何检测？

• 检索质量如何评测？

• 知识库更新失败怎么办？

• 系统需要支持多少并发？

• 哪些操作必须经过审批？

如果这些问题没有写入规格，AI 就会根据自己的理解自动补全。

最终得到的通常不是一个真正可以上线的系统，而是一个能够运行的 Demo。

SDD 的价值，是把人脑中的隐含要求转化为：

• 明确的功能范围；

• 明确的输入输出；

• 明确的边界条件；

• 明确的异常处理；

• 明确的验收标准。

例如，不要只写：

系统应该准确回答问题。

而应该写：

1. 在包含 200 个问题的测试集中，Top-5 检索命中率不得低于目标阈值。
2. 每个关键答案必须包含有效引用。
3. 资料不足时必须拒绝回答。
4. 无权限文档不得被检索或返回。
5. 文档删除后，对应切片和向量数据必须同步删除。

前一句是愿望。

后面几句才是工程规格。

AI 越强，SDD 越重要。

因为模型生成代码的速度越快，错误方向被放大的速度也越快。

---

九、Harness：真正决定 Agent 能不能进入生产环境

如果只能从 Agent 工程中选择一个最值得深入学习的概念，我会选择 Harness。

因为 Prompt、RAG、Skill、Tool 和 MCP 解决的是：

Agent 具备什么能力？

而 Harness 解决的是：

这些能力如何被稳定、安全、持续地运行？

可以把 Harness 理解成 Agent 的运行时控制系统。

一个成熟的 Harness，至少需要负责以下内容。

1. 任务状态管理

系统必须知道：

• 当前目标是什么；

• 已经完成了哪些步骤；

• 下一步应该做什么；

• 哪些步骤执行失败；

• 哪些结果已经确认；

• 哪些任务正在等待审批。

如果 Agent 只依赖聊天记录保存状态，一旦上下文被压缩、服务重启或任务中断，整个流程就可能丢失。

任务状态应该存储在独立的持久化系统中，而不是只存在于模型上下文里。

2. Checkpoint 检查点

复杂任务每完成一个关键阶段，都应该保存检查点。

例如：

数据获取完成
→ 数据清洗完成
→ 分析完成
→ 报告生成完成
→ 审批完成
→ 邮件发送完成

如果报告生成阶段失败，系统应该从“分析完成”继续执行，而不是重新查询全部数据。

Checkpoint 的价值不只是节省资源，更重要的是让 Agent 具备可恢复能力。

3. 工具调度

Harness 需要控制：

• 工具调用顺序；

• 调用频率；

• 超时时间；

• 最大重试次数；

• 并发数量；

• 工具之间的依赖关系。

例如：

查询订单
→ 计算交付率
→ 生成趋势分析
→ 制作风险报告

模型不能跳过数据查询，直接编造分析结果。

4. 幂等控制

假设 Agent 调用“创建付款申请”接口时发生超时。

模型无法确定请求究竟有没有成功。

如果直接再次调用，就可能产生两条付款申请。

因此，生产系统必须为关键操作设置幂等标识。

例如：

idempotency_key = 供应商ID + 付款周期 + 业务类型

同一个业务动作无论重试多少次，都只能产生一次有效结果。

这类问题在发送邮件、创建订单、发起审批和写入财务记录时尤其重要。

5. 权限与沙箱

Agent 可以生成 SQL，不代表它应该执行所有 SQL。

可以允许：

• SELECT；

• 数据统计；

• 查询语句生成；

• 只读分析。

但应该限制：

• DROP TABLE；

• DELETE；

• 修改生产数据；

• 执行未知脚本。

同样，Agent 可以生成邮件草稿，但真正发送给客户之前，可能必须经过人工审批。

6. 超时、重试与降级

工具失败之后不能无限重试。

Harness 应该根据错误类型决定：

• 立即重试；

• 延迟重试；

• 更换工具；

• 缩小任务范围；

• 使用降级方案；

• 停止执行；

• 请求人工介入。

网络超时和权限拒绝，不能使用同一种处理方式。

例如：

网络超时：
允许指数退避重试 3 次

权限拒绝：
立即停止，不进行重复调用

数据不存在：
标记 Information Not Available

服务不可用：
尝试备用数据源

7. 上下文压缩

长任务不能不断携带完整历史。

Harness 需要定期将执行过程压缩为结构化状态，只保留：

• 当前目标；

• 已完成步骤；

• 关键结论；

• 异常记录；

• 已生成产物；

• 下一步动作。

8. 独立评估器

Agent 不能自己说“任务完成了”，系统就直接认为完成。

必须建立独立验证机制。

例如：

• 代码是否通过自动化测试？

• 报告数据是否与数据库一致？

• 引用是否真的支持结论？

• 生成文件是否可以正常打开？

• 用户最初目标是否已经满足？

• 是否存在未处理异常？

生成者负责产出。

评估器负责检查。

这两个角色最好分离。

否则，Agent 很容易既当运动员，又当裁判。

9. Human-in-the-loop

涉及高风险操作时，Agent 必须暂停，等待人类确认。

例如：

• 删除数据；

• 发送外部邮件；

• 修改财务记录；

• 发布生产系统；

• 签署合同；

• 作出人事决定；

• 向客户发送正式文件。

Agent 的价值不是完全取消人，而是让人只处理真正需要判断、审批和承担责任的环节。

10. 可观测性

一个生产级 Agent 至少应该记录：

• 每轮模型输入；

• 每轮模型输出；

• 工具调用参数；

• 工具返回结果；

• 任务执行耗时；

• Token 消耗；

• 异常原因；

• 重试次数；

• 审批记录；

• 最终产物。

如果没有这些日志，Agent 一旦出错，开发团队甚至无法回答：

它为什么会这样做？

没有可观测性，就没有真正意义上的 Agent 工程。

---

十、用一个企业案例串起完整 Agent 架构

假设企业需要开发一个“供应商风险分析 Agent”。

用户提出任务：

分析 A 供应商过去一年的交付、质量和合同风险，生成一份风险报告。

这个任务会如何运行？

第一步：Prompt 定义行为规则

系统告诉 Agent：

1. 分析交付、质量、合同和财务四个维度。
2. 所有结论必须有数据或文档依据。
3. 缺少数据时标记 Information Not Available。
4. 不得根据行业常识推测供应商财务状况。
5. 高风险结论必须交给采购负责人确认。

第二步：Harness 创建任务状态

系统建立任务记录：

目标：
生成 A 供应商年度风险报告

当前状态：
执行中

已完成步骤：
无

待执行步骤：
1. 查询交付数据
2. 查询质量记录
3. 检索合同文档
4. 计算风险指标
5. 生成报告
6. 验证报告
7. 等待审批

第三步：通过 MCP 发现外部能力

Agent 发现当前可以调用：

• ERP 订单查询工具；

• 质量系统查询工具；

• 合同知识库；

• 供应商主数据系统；

• 报告生成工具。

第四步：加载供应商风险分析 Skill

Skill 告诉 Agent：

• 交付风险应该计算哪些指标；

• 质量风险如何分级；

• 合同中需要检查哪些条款；

• 缺失数据应该如何处理；

• 报告应该采用什么结构；

• 交付之前需要完成哪些检查。

第五步：调用 Tool 执行具体动作

Agent 依次调用：

订单查询工具
→ 质量记录工具
→ 合同检索工具
→ 指标计算工具

每个 Tool 只负责一个边界明确的动作。

第六步：RAG 提供合同证据

系统从合同和会议纪要中找到：

• 交付周期条款；

• 质量责任条款；

• 违约责任；

• 付款条件；

• 历史整改要求。

这些资料成为风险报告中的事实依据。

第七步：进行 Token 与 Context 管理

系统不会把所有原始订单和完整合同直接交给模型。

订单数据先由程序完成统计。

合同先筛选与当前风险维度有关的条款。

模型只接收当前步骤真正需要的信息。

第八步：评估器验证报告

系统检查：

• 报告中的交付率是否与数据库一致；

• 高风险结论是否存在对应证据；

• 合同引用是否准确；

• 是否存在数据缺失但未标记；

• 报告文件是否可以正常打开。

第九步：人工审批

采购负责人确认报告之后，系统才允许正式发送。

这才是一个完整的企业 Agent。

真正完成任务的，从来不是某一个单独模块。

而是所有模块形成的闭环。

---

十一、判断一个 Agent 是否成熟，只需要问五个问题

以后再看到一个 Agent 产品，不要只看它能不能聊天，也不要只看它连接了多少工具。

直接问下面五个问题。

1. 它如何保存任务状态？

任务中断之后，能不能继续执行？

如果只能重新开始，说明它缺乏可靠的状态管理和 Checkpoint。

2. 它如何验证执行结果？

是谁判断任务已经完成？

如果只是模型自己说“已经完成”，说明系统缺乏独立评估机制。

3. 它如何处理工具失败？

有没有超时、重试、降级和人工介入机制？

如果失败后只会重新调用，说明系统还不具备生产级错误处理能力。

4. 它如何控制权限？

模型能不能直接执行删除数据、发送外部邮件和修改生产系统等危险操作？

如果所有能力都直接暴露给模型，系统风险会非常高。

5. 它如何证明答案正确？

有没有数据依据、文档引用、版本信息和自动化评测？

如果答案无法追溯来源，它本质上仍然只是一个文本生成器。

如果这五个问题没有明确答案，那么这个 Agent 大概率仍然只是一个高级 Demo。

---

十二、真正需要记住的，不是几个名词，而是它们之间的关系

最后，用几句话重新理解整套 Agent 体系。

Token 是预算

决定模型当前能够承载多少有效信息。

Prompt 是规则

决定模型应该如何理解目标、约束和行为边界。

RAG 是证据

决定模型基于什么事实生成答案。

Tool 是动作

决定 Agent 能对外部世界执行什么操作。

Skill 是方法

决定 Agent 应该按照什么专业流程完成工作。

MCP 是接口

决定外部工具和资源如何被统一连接。

SDD 是开发规程

决定系统在开发前是否拥有明确目标、边界和验收标准。

Harness 是控制中枢

决定整个系统能否持续、稳定、安全地运行。

如果一定要为 Agent 写一个能力公式，可以是：

Agent 实际能力
=
模型能力
× 上下文质量
× 知识准确性
× 工具可靠性
× 任务规划能力
× 结果验证能力
× 工程控制能力

这里使用乘法，是因为任何一项接近零，整个 Agent 的实际价值都会迅速下降。

模型很强，但知识检索错误，答案仍然不可信。

工具很多，但没有权限控制，系统不敢上线。

Prompt 很完整，但没有任务状态，长任务依然会丢失步骤。

报告生成得很漂亮，但没有验证机制，就无法证明数字正确。

这就是 Agent 工程最重要的一次认知升级：

模型决定了 Agent 的能力上限，而数据、Skill、Tool、评测和 Harness，决定了系统能否稳定接近这个上限。

未来真正有竞争力的 Agent，不一定是接入了最强模型的系统。

而是能够把一个具有不确定性的大模型，放入一套可观察、可验证、可恢复、可审计、可控制的工程体系中。

当这套体系真正建立起来之后，AI 才不再只是一个会聊天的工具。

它才开始成为一个能够持续交付结果的数字员工。