别再把 AI Agent 理解成“大模型加工具”：一文讲透 Token、Skill、RAG、MCP、SDD 与 Harness

摘要很多人理解 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. 资源与上下文层包括TokenPromptRAGMemoryContext Engineering这一层决定模型能够看到什么信息以及应该如何理解这些信息。2. 能力与执行层包括ToolSkillFunction CallingWorkflow这一层决定 Agent 能做什么以及应该按照什么方法完成任务。3. 连接与协议层包括MCPAPIConnector数据库连接器文件系统连接器这一层负责把外部系统、数据和工具暴露给 Agent。4. 开发与运行控制层包括SDDHarnessEvaluation权限管理状态管理CheckpointHuman-in-the-loop这一层决定 Agent 如何被开发、约束、执行、恢复和验证。很多 Agent 项目失败并不是模型不够强而是一开始就把不同层级的问题混在了一起。例如用 Prompt 代替权限系统用 MCP 代替任务规划用向量数据库代替完整 RAG用聊天记录代替任务状态用模型自我判断代替独立评估。这些设计在 Demo 阶段可能可以运行但很难进入生产环境。三、Token不仅是计费单位更是 Agent 的上下文预算很多人对 Token 的理解停留在“调用模型需要按 Token 收费”。这当然没有错。但对于 Agent 来说Token 更重要的含义是Token 是 Agent 在当前推理过程中可以使用的上下文预算。模型在一次任务中看到的所有内容最终都会占用 Token。包括系统提示词用户任务历史对话RAG 检索结果工具定义工具调用参数工具返回结果当前任务状态模型生成内容。可以把上下文窗口想象成一张办公桌。办公桌越大确实可以放更多资料。但桌子大不代表工作效率一定高。如果桌面上堆满了无关文档、重复信息、过期对话、几百个工具说明和未经筛选的数据模型不仅不会变得更聪明反而更容易受到干扰。因此Agent 的 Token 优化不是简单地压缩文字而是解决四个问题什么信息应该进入当前上下文信息应该在什么时候进入信息应该以什么结构进入哪些历史内容可以丢弃或压缩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可能包含读取本月和上月销售数据检查数据完整性按区域、客户和产品进行拆分计算同比、环比和目标完成率识别异常增长与异常下降生成管理层摘要按照公司模板制作报告检查报告数字是否与原始数据一致交给负责人审批。这个过程中可能调用多个 Tool但整个业务流程才是一个 Skill。一个完整的 Skill 通常包含适用范围触发条件输入要求标准工作流程工具使用说明异常处理方式输出模板检查清单参考文档自动化脚本。可以用一句话理解Tool 是手里的工具Skill 是使用这些工具完成工作的专业方法。如果一个 Agent 拥有大量 Tool却没有高质量 Skill它就像一个安装了很多软件、但没有接受岗位培训的新人。它可能知道如何打开 Excel、查询数据库和发送邮件却不知道一份合格的经营分析报告应该包含什么。真正拉开 Agent 差距的往往不是工具数量而是 Skill 的质量。六、RAG真正解决的不是“模型不知道”而是“答案没有证据”RAG 经常被比喻成让大模型参加开卷考试。这个比喻很形象。大模型在预训练过程中学到的是通用知识但企业真正需要的通常是内部制度产品资料客户要求项目文档技术规范会议纪要历史案例实时业务数据。这些信息不适合全部写入 Prompt也不可能每次都重新训练模型。RAG 的基本流程是用户问题 → 检索外部资料 → 获取相关证据 → 将证据交给模型 → 基于证据生成答案但是很多团队接入一个向量数据库之后就认为 RAG 已经完成了。实际上向量检索只是 RAG 中间的一步。一个完整的企业 RAG 系统通常包括文档采集文件解析OCR 识别内容清洗重复数据处理文档分类元数据标注权限标注语义切片索引构建查询理解关键词检索向量检索混合召回结果重排序证据组合答案生成引用生成事实验证效果评测。任何一个环节出现问题最终答案都可能错误。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 自主规划能力。有了 MCPAgent 只是更容易连接外部系统。至于什么时候调用工具应该调用哪个工具调用失败怎么办是否需要重试返回结果是否可信任务是否已经完成是否需要人工审批这些都不是 MCP 负责的。更准确的关系是MCP 提供接口 Tool 提供动作 Skill 提供方法 模型负责判断 Harness 负责控制这也是为什么有些系统接入 MCP 后Agent 依然不稳定。连接能力只是 Agent 的基础设施不是 Agent 的完整运行逻辑。八、SDDAI 写代码越快规格越不能模糊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 TABLEDELETE修改生产数据执行未知脚本。同样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 定义行为规则系统告诉 Agent1. 分析交付、质量、合同和财务四个维度。 2. 所有结论必须有数据或文档依据。 3. 缺少数据时标记 Information Not Available。 4. 不得根据行业常识推测供应商财务状况。 5. 高风险结论必须交给采购负责人确认。第二步Harness 创建任务状态系统建立任务记录目标 生成 A 供应商年度风险报告 当前状态 执行中 已完成步骤 无 待执行步骤 1. 查询交付数据 2. 查询质量记录 3. 检索合同文档 4. 计算风险指标 5. 生成报告 6. 验证报告 7. 等待审批第三步通过 MCP 发现外部能力Agent 发现当前可以调用ERP 订单查询工具质量系统查询工具合同知识库供应商主数据系统报告生成工具。第四步加载供应商风险分析 SkillSkill 告诉 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 才不再只是一个会聊天的工具。它才开始成为一个能够持续交付结果的数字员工。