简介：本文系统对比Agent工程中Token、Skill、RAG、MCP、SDD、Harness六层约束的定位与差异，剖析demo聪明却交付变蠢的根因，给出各层适用场景、选型依据与落地注意事项，帮助技术负责人搭建从“能回答”到“能交付”的稳定链路。
很多团队在做 Agent 时都会遇到同一个反差：demo 阶段模型看起来很聪明，能读代码、能改文件、能跑测试，甚至能自动生成 PR；一旦接入真实仓库、真实接口和真实协作流程，输出就开始“变蠢”——忘记前面读过的内容、漏掉文档里的关键约束、工具报错后继续用错误上下文往下写、需求没说完就自行脑补业务逻辑。最后产物能跑，但不能合。
问题往往不在模型大小，而在支撑 Agent 运转的那条工程链路没有被拆清楚。本文围绕六个常被并列提及、实则分层约束的概念展开对比：Token、Skill、RAG、MCP、SDD、Harness。它们不是六个可以互相替换的选项，而是同一个系统从“能回答”走向“能交付”的六层约束。理解它们的相同点、差异点与使用边界，比单纯比较“哪个更重要”更有意义。
这六个词经常同时出现在 Agent 相关的讨论中，导致一种错觉：它们像是六种平行的能力，选几个装上就行。实际上它们解决的是完全不同层面的问题。
一个典型失败案例可以说明问题。某团队做一个代码变更助手，用户输入“给订单模块加一个优惠券核销能力”，Agent 自动读代码、查接口文档、改代码、跑测试、生成 PR。前三轮演示很顺：能找到订单服务类，能补数据传输对象，还能顺手生成单元测试。但接入真实仓库后问题集中爆发：
这些现象分别指向不同的约束层：遗忘指向 Token 窗口管理，漏约束指向知识检索与规格明确性，工具错误处理指向外部系统接入与运行闭环，脑补业务指向规格驱动。把它们混为一谈，就无法定位到底该补哪一层。
Token：Agent 的工作台。 模型单次推理能参考的指令、历史对话、工具结果、代码片段、错误日志、检索材料，都要摆在这张工作台上。工作台越大，能同时处理的材料越多，但它不是无限仓库。Token 层要解决的是“当前这一轮，Agent 能看见什么、该看见什么”。
Skill：重复任务的规矩。 当 Agent 反复遇到同类任务时，按什么步骤做、遵循什么规范、产出什么形态，需要被固化下来。Skill 层解决的是“遇到重复任务时按什么规矩做”，把一次性提示词沉淀为可复用的执行规范。
RAG：缺知识时补证据的通道。 模型自身不掌握仓库内的接口约定、内部文档和历史决策，需要通过检索把外部证据补进上下文。RAG 层解决的是“缺知识时从哪里补证据”，强调的是证据来源与召回质量。
MCP：接触外部系统的标准接口。 Agent 要读文件、调接口、查数据库、触发流水线，需要一种安全、标准的方式接触外部系统。MCP 层解决的是“怎么安全、标准地接触外部系统”，关注的是接入协议、权限边界与调用规范。
SDD：写代码之前的规格。 规格驱动开发强调在动手实现前先把需求、边界、验收条件明确下来。SDD 层解决的是“写代码之前有没有明确规格”，避免 Agent 用脑补代替需求。
Harness：把能力稳定跑成闭环。 有了上下文、规范、证据、接口和规格，还需要一套运行框架把它们串起来：任务分解、状态管理、错误处理、重试与终止条件。Harness 层解决的是“这些能力能不能稳定跑成一个闭环”。
尽管定位不同，这六层约束在几个方面高度一致。
目标一致：都是为降低不确定性。 大模型输出本身带有随机性，六层约束的共同作用是把开放性任务收敛为可验证的交付物。Token 收敛可见信息，Skill 收敛执行步骤，RAG 收敛事实依据，MCP 收敛系统交互，SDD 收敛需求解释，Harness 收敛运行流程。
逻辑一致：都遵循“约束换稳定”的思路。 每一层都在用某种形式的约束换取可预测性：窗口管理牺牲部分信息量换取聚焦，规格文档牺牲前期速度换取返工减少，标准接口牺牲灵活性换取安全与可维护性。
依赖一致：层与层之间存在耦合。 没有可靠的 RAG，Token 层会被无效材料挤占；没有明确的 SDD，Skill 会执行得越快偏差越大；没有 Harness 的错误处理，MCP 的调用失败会污染后续上下文。任何一层缺失，都会以其他层的表现异常暴露出来。
演进一致：都随任务复杂度提升而变得必要。 简单问答场景下六层几乎都不需要显式设计；任务一旦涉及多文件、多系统、多轮次，每一层都会从“可选”变成“必需”。
Token 约束的是信息容量与信息选择，属于上下文层面的问题；Skill 约束的是行为模式，属于执行规范层面；RAG 约束的是知识来源，属于证据层面；MCP 约束的是外部交互方式，属于集成层面；SDD 约束的是需求解释，属于定义层面；Harness 约束的是整体运行流程，属于编排层面。约束对象不同，意味着它们的失效表现也不同：Token 失效表现为遗忘和注意力涣散，Skill 失效表现为同类任务产出不一致，RAG 失效表现为引用错误或漏掉关键约束，MCP 失效表现为权限错误和调用越界，SDD 失效表现为需求脑补，Harness 失效表现为流程卡死或错误累积。
Token 层的实现主要围绕上下文窗口管理，包括摘要压缩、分段加载、优先级排序、按需检索等策略。业界常见做法是把长对话压缩为摘要以避免超过窗口上限，这类机制在 Agent 中不是锦上添花，而是基础设施。
Skill 层通常以规范文档、模板、可复用执行脚本或流程定义的形式存在，本质是把隐性经验显性化。
RAG 层涉及文档切分、向量化、索引构建、召回与重排等环节，架构上是一个独立的检索服务或检索模块。
MCP 层是协议与适配层，定义工具如何被描述、如何被调用、权限如何声明，架构上介于 Agent 运行时与外部系统之间。
SDD 层是流程与文档层，产出物是规格说明、验收标准和边界定义，通常与需求管理流程结合。
Harness 层是运行时框架，负责任务分解、状态持久化、工具调度、错误捕获、重试策略和终止判断，架构上最接近“Agent 操作系统”的角色。
从接入成本看，Token 层改造通常最先启动、成本相对可控，主要是上下文组织策略的调整；Skill 层的成本在于经验梳理和规范沉淀，前期人力投入明显；RAG 层需要额外的检索基础设施和数据治理，接入周期较长；MCP 层需要对外部系统做适配封装，涉及权限体系对接；SDD 层挑战最大，因为它改变的是团队的需求沟通习惯，属于流程改造而非纯技术改造；Harness 层则需要较强的工程能力，涉及状态管理、可观测性和容错设计。
Token 层不是越大越好。窗口扩大并不等于注意力均匀，无关材料越多，关键信息越容易被稀释。Token 管理的边界在于：必须区分“可加载”与“应加载”。
Skill 层的风险在于过度固化。任务形态一旦变化，旧规范可能成为负担，需要保留版本管理和失效机制。
RAG 层的边界在于证据质量。检索到错误或过期的文档，比没有检索更危险，因此需要来源可信度标注和冲突处理策略。
MCP 层的风险集中在权限与副作用。写操作类工具必须有明确的确认与回滚机制，否则一次误调用就可能造成实际影响。
SDD 层的边界在于成本收益。并非所有任务都值得写完整规格，小改动强行套规格会拖慢节奏，关键是区分任务等级。
Harness 层的风险在于复杂度失控。编排逻辑越复杂，调试难度越高，需要配套的可观测性，否则故障定位会非常困难。
Token 层关注上下文占用率、压缩触发频率、关键信息命中情况；Skill 层关注执行一致性和规范覆盖率；RAG 层关注召回率、引用准确率和证据时效；MCP 层关注调用成功率、权限拒绝率和副作用审计；SDD 层关注规格完备度和需求变更频率；Harness 层关注任务成功率、平均轮次、错误恢复率和终止原因分布。观测指标不同，说明它们无法用同一套度量体系评估。
| 维度 | Token | Skill | RAG | MCP | SDD | Harness |
|---|---|---|---|---|---|---|
| 约束对象 | 上下文信息 | 执行行为 | 知识证据 | 外部交互 | 需求定义 | 运行流程 |
| 解决的核心问题 | 当前能看见什么 | 重复任务怎么做 | 缺知识从哪补 | 怎么安全接外部系统 | 写码前有无规格 | 能否稳定闭环 |
| 典型失效表现 | 遗忘、注意力涣散 | 产出不一致 | 漏约束、引用错误 | 权限错误、越界调用 | 需求脑补 | 流程卡死、错误累积 |
| 主要实现形态 | 压缩、分段、优先级 | 规范、模板、流程定义 | 切分、索引、召回重排 | 协议适配、权限声明 | 规格文档、验收标准 | 任务编排、状态管理 |
| 接入成本 | 较低 | 中等 | 中等偏高 | 中等偏高 | 偏高（流程改造） | 高（工程能力） |
| 主要风险 | 信息稀释 | 规范过时 | 证据失真 | 副作用失控 | 过度规格化 | 编排复杂难调试 |
| 观测重点 | 占用率、命中率 | 一致性 | 召回率、准确率 | 成功率、审计 | 完备度 | 成功率、恢复率 |
单轮问答或简单信息查询。 六层中主要需要关注 Token 与 RAG：控制上下文长度，保证检索证据可靠即可，其余层投入产出比不高。
多文件代码修改类任务。 Token 管理与 SDD 最关键。前者决定 Agent 能否在多轮读取中保持聚焦，后者决定它是否会自行补出未要求的业务逻辑。Skill 用于固化常见的改造模式，Harness 负责在测试失败时正确终止或重试。
跨系统操作类任务。 MCP 与 Harness 是重点。外部系统调用必须有标准接口和权限边界，同时运行框架要能处理调用失败、超时和部分成功等状态。
高频重复型任务。 Skill 的价值最突出，把稳定流程沉淀下来可以显著降低输出波动；同时需要 Harness 保证每次执行都走同一条闭环。
需求模糊的探索型任务。 SDD 与 RAG 应优先补强：先用规格澄清边界，再用检索补充事实依据，避免 Agent 在模糊需求上高速跑偏。
面对这六层，选型的基本思路不是“哪个先进上哪个”，而是先定位当前系统的短板在哪一层。
如果失败表现为遗忘和上下文污染，优先做 Token 管理，包括摘要压缩、分段加载和材料优先级排序。如果失败表现为同类任务每次产出差异大，优先沉淀 Skill。如果失败表现为引用错误或漏掉文档约束，优先治理 RAG 的证据质量与召回策略。如果失败表现为工具调用越界或权限问题，优先建设 MCP 层的协议与权限规范。如果失败表现为需求脑补，优先引入 SDD，把验收条件前置。如果失败表现为流程中途卡死、错误后继续乱跑，优先补 Harness 的错误处理与终止条件。
需要强调的是，层与层之间存在先后依赖但不存在绝对顺序。上下文管理通常是起点，因为它直接影响其他层的材料能否被有效利用；运行闭环往往是最后一层，因为它的设计依赖前面几层的接口形态。团队规模有限时，可以按“先止血、再固化、后标准化”的节奏推进，而不必一次铺开六层。
如果团队已经在使用某种 Agent 实现，准备补齐这些约束层，需要注意几点。
接口兼容性。 引入 MCP 类标准接口时，要评估现有工具封装方式的改造成本，避免一次性重写全部工具。可以采用新老并存、逐步迁移的方式。
数据与权限。 RAG 接入内部文档时，必须同步梳理文档的访问权限，避免检索层绕过原有权限体系。MCP 的工具权限应遵循最小可用原则，写操作类工具建议增加人工确认环节。
流程冲击。 SDD 的引入会改变需求沟通节奏，需要给团队适应期，并从少量高价值任务开始试点，而不是全面强制。
稳定性风险。 Harness 的编排逻辑上线前应有充分的故障注入测试，重点验证工具失败、超时、部分成功等边界情况下的行为是否符合预期。
成本结构。 Token 压缩和 RAG 检索都会带来额外调用与计算开销，需要评估长期运行成本；Skill 与 SDD 主要是人力成本前置；MCP 与 Harness 的维护成本会随接入系统数量增长。
使用边界。 不要为了“体系完整”而给简单任务套上全部六层。约束层数应与任务复杂度匹配，过度工程化本身也会降低交付效率。
Token、Skill、RAG、MCP、SDD、Harness 不是六个并列的能力选项，而是同一套 Agent 工程体系中的六层约束：Token 决定 Agent 当前能看见多少东西，Skill 决定它遇到重复任务时按什么规矩做，RAG 决定它缺知识时从哪里补证据，MCP 决定它怎么安全、标准地接触外部系统，SDD 决定它写代码之前有没有明确规格，Harness 决定这些能力能不能稳定跑成一个闭环。
回到最初的问题：为什么很多 Agent demo 很聪明，一到工程交付就变蠢？答案不在模型本身，而在这条链路是否有短板。demo 阶段任务短、上下文少、容错高，六层的缺失不易暴露；真实交付场景把每一层的缺口都放大成了可见故障。对比这六层的意义，不在于评判谁更重要，而在于建立一种定位能力：当 Agent 表现异常时，能判断问题出在上下文、行为规范、证据来源、系统接入、需求定义还是运行闭环，从而把有限的工程投入用在真正的短板处。