Agent工程六层链路拆解：Token、Skill、RAG、MCP、SDD与Harness的协同差异与选型指南

一、对比背景：为什么Demo聪明，落地却变蠢？

许多开发者在实验环境中构建Agent时，往往能获得令人惊艳的效果——它能读懂需求、调用接口、生成代码，甚至完善测试用例。然而，一旦接入真实仓库、面对海量文件与复杂依赖，Agent的行为就会迅速劣化：它开始遗忘早期读取的内容，忽略接口文档中的关键约束，在工具调用报错后继续基于错误上下文生成结果，甚至自行脑补业务逻辑。这些问题并非模型能力不足，而是Agent工程化链路存在系统性缺陷。

本文对比的六个对象——Token、Skill、RAG、MCP、SDD、Harness——并非六个并列的工具或组件，而是描述同一个系统从“能回答”迈向“能交付”过程中必须依次建立的六层约束。理解它们各自的边界与相互作用，是构建稳定、可信、可维护的Agent系统的前提。

二、对象定义：六层约束分别解决什么问题

要素	核心定位	解决的核心问题
Token	Agent的工作台容量	单次推理能同时参考多少信息
Skill	重复任务的执行规范	面对同类任务时按什么既定流程操作
RAG	外部知识的获取通道	缺乏内部知识时从哪里检索可靠证据
MCP	外部系统的标准接口	如何安全、规范地操作外部工具与数据源
SDD	编码前的规格约束	动手写代码前是否已有明确、可验证的设计规格
Harness	全链路的运行闭环	上述能力能否在稳定、可观测的环境中协同执行

这六个要素之间存在严格的顺序依赖：Token决定信息容量，Skill决定行为范式，RAG决定知识来源，MCP决定交互边界，SDD决定输出质量，Harness决定整体稳定性。任何一个环节薄弱，都会导致整个交付链路失效。

三、相同点分析：它们共同服务于什么目标

尽管这六个要素在功能上差异显著，但它们具备三个深层共同点：

1. 目标一致性：所有要素最终都服务于同一个核心目标——让Agent从“概率性生成内容”转变为“确定性完成任务”。无论是扩大Token窗口、沉淀Skill规则，还是通过SDD约束设计，本质上都是在压缩模型的自由发挥空间，提升输出的可预测性。

2. 上下文敏感性：每个要素都高度依赖当前任务的上下文。Token窗口决定可携带多少上下文；RAG决定如何补充缺失的上下文；Skill决定在特定上下文中应该遵循何种既有模式。六者共同构成了一套上下文管理机制。

3. 工程化属性：这六个要素都不是模型自带的天然能力，而是需要在系统层面进行设计与配置的工程组件。它们考验的是开发者对任务流程的理解、对信息流的规划以及对异常场景的预判，而非单纯的模型选择。

四、核心差异分析：六个维度的深度对比

1. Token：工作台容量，而非存储仓库

Token很容易被简单理解为计费单位，但在Agent工程中，它的实际角色是“工作台”——模型在单次推理时能够同时摆放在桌面上处理的所有材料的总和，包括系统指令、历史对话、工具返回值、代码片段、错误日志和检索结果。

核心差异：Token窗口是有限且昂贵的。它决定了Agent在单步操作中能“看到”多大的信息量，但并非越大越好。窗口扩大并不会自动提升Agent的推理质量，反而可能引入更多噪声。在实践中，关键差异在于Token的分配策略——是平均分配给所有文件，还是优先保障核心规格文档、接口契约和近期关键对话。

关键认知：Token是六要素中的基础约束。当Token容量不足时，其他所有环节的效果都会被抑制。例如，即使RAG检索到了正确的文档片段，如果Token窗口已经塞满无关代码，这些关键信息也无法进入当前推理。因此，Token管理的本质是信息筛选与优先级排序，而非单纯扩容。

2. Skill：重复任务的标准化操作手册

Skill解决的是“当Agent反复遇到同一类任务时，如何保证每次的处理方式一致且符合预期”。它约定了任务拆解步骤、工具选择偏好、代码风格要求、异常处理流程等。

核心差异：Skill与RAG虽然都起到“补充信息”的作用，但两者的本质不同——RAG回答的是“知识是什么”，Skill回答的是“事情怎么做”。一个负责提供事实依据，一个负责提供操作范式。例如，处理“优惠券核销”这个任务时，RAG负责提供核销接口的字段定义，Skill则负责规定“必须先检查幂等键再调用核销接口”这个操作顺序。

关键认知：Skill的价值在于将成功经验固化下来，避免Agent每次面对同类任务都从头探索。但Skill的编写本身就是一项工程：规则太宽泛则失去约束力，太具体则无法应对变化。同时，Skill的选择通常依赖任务分类的准确性，如果分类环节出错，错误Skill的指导比没有Skill更加危险。

rag-">3. RAG：知识短板的外部补充通道

RAG解决的是“Agent内部参数中没有存储的知识，如何从外部可信源获取”。它将检索与生成结合，从文档库、接口文档、历史工单等外部知识源中找出与当前问题最相关的证据，作为生成内容的依据。

核心差异：RAG与其他要素的区别在于，它负责的是事实性信息的获取，而非流程性信息的确认。当Agent需要了解“某个接口是否要求幂等键”时，RAG的目标是检索到对应的接口文档片段。但这里有一个关键技术差异——检索到不等于理解到。Agent可能正确检索出文档内容，却未在后续代码生成中遵循其中的约束条款。因此，RAG需要与SDD配合使用：RAG负责把规格说明书呈现出来，SDD负责确保这些规格被转化为可验证的设计约束。

关键认知：RAG的检索质量受限于索引覆盖度、分块策略和相关性排序算法。在工程实践中，RAG的失败模式不仅仅是“检索不到”，更常见的是“检索到多个冲突信息时无法裁决”。为了缓解这一点，RAG通常需要配合置信度阈值和人工审核机制，而非完全依赖模型自动判断。

4. MCP：外部系统接入的安全边界

MCP解决的是“Agent如何以标准化、可控的方式调用外部工具、访问外部数据源或触发外部服务”。它提供了统一的协议层，将Agent与外部系统解耦，使得工具接入、权限校验、请求限流、错误处理等操作具备统一规范。

核心差异：MCP与RAG的区别在于，RAG只是“读”，MCP强调“读+写+执行”。当Agent需要下单、退款、修改配置或触发构建时，它必须在MCP框架下进行操作。核心差异还体现在安全边界上——MCP协议允许开发者精确指定Agent可以调用哪些工具、以什么身份调用、是否允许携带敏感参数。这些约束在RAG体系中是不存在的。

关键认知：MCP是Agent从“建议者”变为“执行者”的关键桥梁。但引入MCP也带来了故障放大效应：如果Agent在工具调用失败后未能正确中止任务，反而继续基于错误输出生成后续内容，那么错误会被逐级放大。因此，MCP的设计必须与Harness配合，制定明确的“失败即停止”策略，防止错误上下文污染后续推理。

5. SDD：编码前不可省略的规格确认

SDD解决的是“在Agent生成代码之前，是否已经明确知道要构建什么、验收标准是什么”。它的核心思想是：规格先行，编码在后。

核心差异：SDD与Skill的关键差异在于——Skill关注的是过程的规范性，SDD关注的是结果的确定性。Skill回答“按什么步骤做”，SDD回答“做到什么程度才算完成”。例如，对于“核销接口”这个任务，SDD需要产出明确的功能规格：支持幂等键去重、失败返回明确错误码、不包含任何退款逻辑等。只有将这些约束写入规格并确认无歧义后，Agent生成的代码才有明确的验证标尺。

关键认知：SDD是六要素中“逆向思维”最强的一个环节——它不是教Agent“怎么做”，而是通过定义清晰的验收条件，让Agent在生成过程中不断自我校验。缺乏SDD时，Agent容易在需求模糊地带自行发挥，例如在产品只说“优惠券核销”时自动脑补退款逻辑。SDD的价值就是将这些歧义显式化，并通过讨论或模板将其转变为不可忽略的约束。

6. Harness：全链路的运行闭环与容错机制

Harness解决的是“上述五个要素如何在稳定、可观测、可恢复的软件环境中协同运行”。它是Agent系统的“总控台”，负责编排任务队列、管理状态快照、处理中断恢复、记录完整日志以及触发告警。

核心差异：Harness与其他要素的本质区别在于，它不直接作用于模型推理，而是作用于系统的运行环境。Token管理、Skill调度、RAG检索、MCP调用、SDD校验，所有这些动作都在Harness的框架内发生。没有Harness，即使其他五项配置完美，Agent也只是一个无舵之船——任务中断后无法恢复，错误无法追根溯源，升级无法平稳发布。

关键认知：Harness的核心设计原则是“一切可追溯、一切可重放”。它要求记录Agent在每一步的输入与输出，包括Token窗口的快照、RAG检索的排序结果、MCP调用的请求与响应、SDD校验的通过与否。这些日志不仅是排查问题的依据，更是后续调整Skill、优化RAG索引和细化SDD规格的数据基础。

五、对比表格：六要素的关键维度差异

对比维度	Token	Skill	RAG	MCP	SDD	Harness
信息流向	输入侧	过程侧	知识侧	交互侧	输出侧	控制侧
主要问题	能看多少	怎么做	依据什么	如何接入	做到怎样	如何稳跑
失败模式	关键信息被截断	规则与任务不适配	检索结果冲突	权限错误未中止	规格含糊导致脑补	状态丢失无法恢复
依赖关系	是所有环节的基础	依赖Token容量执行	依赖Token窗口装载结果	依赖Skill中的调用规划	依赖RAG提供的规格素材	依赖全部环节的可观测性
优化方向	信息优先级排序	规则抽象与分类	索引质量与裁决机制	权限边界与失败策略	验收标准的明确化	状态管理与审计追踪

六、典型场景方案选择建议

agent">场景一：简单问答型Agent

此时核心需求是知识获取与准确回答。Token与RAG是重心，需要合理分配Token窗口以便容纳检索内容，同时优化RAG检索准确率。Skill、MCP、SDD、Harness可以保持轻量甚至缺省。

场景二：代码生成与修改型Agent

这类场景必须同时依赖Token、MCP与SDD。Token决定能读取多少仓库文件，MCP决定如何操作代码仓库与测试环境，SDD则确保生成的代码符合规格，不擅自扩展业务逻辑。Skill用于固化常见代码修改模式。Harness用于记录变更历史，便于回滚。

场景三：高频重复操作型Agent

例如批量处理工单、自动生成报告。此时Skill与Harness是核心。Skill保证每次操作遵循同一种已验证的流程，Harness负责批量执行时的异常中断恢复与进度追踪。RAG与SDD的权重可以降低，只需在任务起点设定明确的输入输出模板。

场景四：高风险外部操作型Agent

涉及资金转账、权限配置等场景。此时MCP与SDD是绝对重心——MCP必须细化到操作级别的最小权限控制，SDD必须具有强约束的验收清单。Token与RAG的配置目标应该是“确保Agent完整理解操作约束”，而非追求信息广度。

七、选型与配置建议

1. 从Harness开始：无论什么场景，先搭建可观测、可回放的基础运行框架。没有Harness的Agent系统无法诊断问题，也就无法迭代优化其他要素。
2. Token分配优先于扩容：在增大Token窗口之前，先检查当前窗口中的信息是否都有必要。建立“优先级标记”机制，优先保留规格文档、核心接口契约与最近一次错误日志。
3. Skill需要持续沉淀：每解决一个新的问题类型，都应该分析是否能将解决路径转化为新的Skill。但Skill的纳入需要经过验证，不能只凭一次性成功就固化。
4. RAG的裁决机制比检索精度更重要：应当设计当多个检索结果产生冲突时的处理策略，例如根据文档异同版本、置信度评分或明确规则判断优先级。
5. MCP须遵循“最小调用”原则：只开放当前任务必需的工具与权限，并在每个调用前设置超时与失败中止策略。不要让Agent拥有“继续尝试”的自由裁量权。
6. SDD模板化：为常见任务类型（如接口开发、数据处理、缺陷修复）建立标准化规格模板，将模糊的业务需求强制转换为可勾选的功能清单。

八、迁移与使用注意事项

当Agent系统从演示环境迁移到生产环境时，需要特别关注以下五个风险点：

1. 数据规模的跳跃：演示环境中Token窗口可能刚好容纳全部文件，但真实仓库中文件数量会指数级增长。迁移前必须预先设计分块读取、摘要压缩与按需加载策略，而非盲目依赖更大的Token窗口。
2. 权限体系的变化：演示环境中通常使用同一套管理员权限，生产环境中则需按照岗位职责分别配置不同权限。MCP的权限映射需要逐项审查，防止Agent具备超出任务范围的系统访问能力。
3. 异常恢复流程：生产环境的Agent任务往往是长时运行任务，可能持续数分钟甚至数小时。Harness必须支持任务checkpoint与恢复，否则一旦网络抖动或服务重启，任务将从头执行并产生重复副作用。
4. SDD的审核成本：生产环境中的SDD确认不能只依赖模型自我评估，必须引入人工审核环节或基于规则的自动化校验工具。规格确认环节的投入，直接决定了交付物的可接受程度。
5. RAG知识源的真实一致性：生产环境的知识库是动态更新的，RAG检索到旧版本文档的概率显著提升。需要为RAG设计版本过滤机制，确保检索结果与当前系统版本保持一致。

九、总结

Token、Skill、RAG、MCP、SDD、Harness这六个要素，共同构成了Agent系统从“能回答问题”走向“能独立交付任务”的完整约束链路。它们之间的差异并非简单的好坏之分，而是在不同任务阶段、不同风险级别、不同运行环境中的功能分工。一个稳定的Agent系统，不会试图让模型变得更聪明，而是通过这六层约束，让模型的每一次推理都在既定的信息边界、操作规范、知识依据、权限范围、验收标准和运行保障之内进行。开发者需要理解每个要素的独特职责，同时明确它们之间的依赖关系——Token是基础工作台，Skill是过程蓝图，RAG是知识补给线，MCP是行动边界，SDD是质量红线，Harness是整个系统的骨架。只有这六者协同配合，Agent才能真正从聪明的演示者，转变为可靠的工作者。