Agent六层链路对比：Token到Harness如何选

一、对比背景：为什么要把六个词放在一起比

Agent工程中最常见的误区，是把效果不好直接归结为“模型不够大、不够新”，于是不断更换模型。但在真实生产环境中，决定一个Agent能否稳定交付的，往往不是模型本身，而是围绕模型搭起来的一条工程链路。这条链路上有六个关键约束层：Token、Skill、RAG、MCP、SDD、Harness。

这六个词经常被并列讨论，甚至被混为一谈——比如把RAG当成Agent的全部、把Skill当成工具接入的一种、把Harness等同于某个具体框架。这种混淆会直接导致建设顺序错误与重复投入：该补Token预算管理的时候去更换检索引擎，该固化Skill的时候去拼命扩上下文窗口。

因此，本文对比的不是六个互斥的“方案A与方案B”，而是同一系统里六个不同位置、不同职责的层。搞清楚它们的边界与分工，比在某一层内部反复内卷更重要。

二、对象定义：六层各自解决什么问题

agent-">1. Token：感知边界——Agent当前能看见多少

Token是模型读写信息的基本单位，上下文窗口决定了Agent单轮可感知的信息总量。工程上它绝不是“选个大窗口”就万事大吉：系统提示、对话历史、检索到的证据、工具返回值、中间推理步骤，都要竞争同一份预算。Token层的核心动作包括预算分配、截断与压缩策略、长程记忆外置、单轮成本核算。典型失效信号：答非所问、丢失早前约束、“证据明明在工具返回值里，但模型没看见”。

2. Skill：行为规约——重复任务按什么规矩做

Skill是封装好的可复用任务流程，通常由提示模板、执行步骤、工具调用顺序与结果校验规则组合而成。它解决的问题是：同一类任务做过一次之后，第二次、第两百次是否还能保持同样的质量。Skill层把“每次靠模型临场发挥”变成“按既定规程执行”。典型失效信号：同类任务质量方差大、无法批量复制、换一个会话就各干各的。

rag-">3. RAG：知识补给——缺知识时从哪里补证据

RAG（检索增强生成）解决模型参数化知识不足、过时或私有缺失的问题：先从外部知识库检索证据，再基于证据生成答案。工程重心在切片策略、向量化、召回与重排、引用溯源。典型失效信号：幻觉、编造出处、用旧版本知识回答新问题。需要注意，RAG解决的是“知道什么”，并不解决“会做什么”。

4. MCP：能力接入——外部工具怎么标准化接进来

MCP（模型上下文协议）代表一类标准化的模型—工具接入协议，作用类似模型与外部系统之间的“通用插座”：统一工具的发现、描述、调用与返回契约。它解决的问题是，N个Agent运行框架对接M个外部系统时，不必写N×M份胶水代码。工程重心在工具描述质量（模型能否“看懂”工具怎么用）、鉴权与调用安全。典型失效信号：模型不会用工具、误用参数、一个接口描述变更导致全部Agent行为异常。

5. SDD：任务规约——先定义“做什么”再执行

SDD（规格驱动开发）把模糊需求先固化为结构化规格——目标、边界、验收标准——再让Agent按规格分解任务、执行并对照规格自检。它解决的是需求理解偏差与验收无据可依的问题。典型失效信号：交付物与预期不符、反复返工、任务范围不断蔓延。

6. Harness：执行骨架——整个循环怎么可靠跑起来

Harness指包裹模型的执行框架与运行时：感知—规划—行动—观察的循环调度、重试与超时控制、沙箱执行、状态持久化与可观测性。它解决长任务可靠性与可复现性问题。典型失效信号：任务跑一半中断且无法续跑、同样的输入两次结果完全不同、出了问题无从排障。

六层在主循环中的位置（示意伪代码）

while not task_complete:
    # SDD层：对照任务规格，明确本轮目标与验收标准
    goal, acceptance = spec.resolve(task)
    # Token层：为本轮分配上下文预算（系统提示/历史/证据/工具返回）
    context = token_budget.allocate(system, memory, evidence, tool_results)
    # RAG层：知识不足时检索外部证据
    if knowledge_needed(goal):
        evidence = retrieve(index, goal, top_k)
    # Skill层：命中已知技能则按模板执行，否则由模型自行规划
    if skill_registry.match(goal):
        steps = skill.load(goal).steps
    else:
        steps = model.plan(context, goal)
    # MCP层：按标准协议发现并描述可调用工具
    tools = protocol.discover_and_describe(scope)
    # Harness层：统一调度执行，带沙箱、重试、超时与状态持久化
    result = harness.run(steps, tools,
                         sandbox=True, retry=2, timeout=30,
                         checkpoint=state_store)
    # 观察：结果写回历史，进入下一轮
    history.append(result)

三、相同点：六层的共性

• 都是对概率性输出的工程约束：模型本质是概率系统，六层都在不同位置加“护栏”，把不可控变为部分可控。
• 都不依赖更换模型：模型不变，仅靠六层建设即可显著提升交付率；反之只换模型不建链路，上限很快被锁死。
• 本质都是“契约”：Token预算、Skill模板、RAG引用、MCP工具描述、SDD规格、Harness流程，本质上都是事先约定的结构化契约。
• 都可独立建设、分层演进：每一层都可以单独度量、单独优化，也都应拥有自己的最小评测集。
• 都呈现“上限看模型、下限看工程”：六层做得好决定系统的下限，模型能力决定天花板，两者不可互相替代。

四、核心差异：六个维度逐一拆开

维度1：位置与职责方向

按数据流向可排成一条链：SDD定义任务（该做什么）→ Token决定感知（能看见什么）→ RAG补充知识（依据是什么）→ Skill约束行为（按什么规矩做）→ MCP接入能力（能调用什么）→ Harness管理执行（怎么可靠跑完）。SDD偏需求侧，Token与RAG偏感知侧，Skill与MCP偏行动侧，Harness偏运行侧。职责不同决定了它们不可互相替代：RAG做得再好也不能让Agent会调接口，MCP接得再多也不能保证知识正确。

维度2：确定性梯度

六层的“可确定性验证”程度不同：Token的截断策略与Harness的流程控制接近传统软件工程，可直接用单元测试验证；Skill模板与SDD规格是半结构化的，需通过评测集做统计性验证；RAG召回质量与模型输出是概率性的，只能靠指标持续监控。确定性越高的层，越应优先用传统工程手段加固。

维度3：失效模式与排障入口

同样一句“Agent答错了”，可能源自六层中任何一层的失效：Token没装下证据、RAG没召回证据、Skill缺少对应模板、MCP工具描述导致误用、SDD规格本身写错、Harness重试逻辑放大了错误。不区分层级混在一起排查，是Agent工程最常见的低效来源。

维度4：成本结构

• Token：随调用量线性增长的用量成本，以及预算管理的心智成本；
• Skill与SDD：前期人力沉淀成本高，后期边际成本低（写一次，复用百次）；
• RAG：知识库建设与持续维护成本（切片、更新、评测）；
• MCP：一次性接入适配成本，随接入系统数量增加逐步摊薄；
• Harness：持续性运维成本（监控、告警、故障恢复、版本升级）。

维度5：演进与替换成本

Token策略调整成本最低（改预算分配逻辑即可）；Skill模板迭代成本中等；RAG更换检索方案较贵（需重建索引并做回归评测）；MCP类协议本身为解耦而设计，替换成本中等；Harness更换框架成本最高——状态持久化格式、重试语义、可观测性口径全部重做，牵一发动全身。因此Harness的初始技术选型要最为谨慎。

维度6：层间协作关系（谁消费谁的产出）

Skill消费RAG的检索结果与MCP的工具描述；SDD的规格是Skill编排的输入；Token预算决定了RAG证据与MCP返回值最终能进入多少上下文；Harness调度以上所有层并为它们的失败兜底。理解这种消费关系，才能解释某些“优化传导不下去”的现象——常见案例是RAG召回质量很好，但Token预算不足，证据在压缩阶段被丢弃。

五、对比总表

层	解决的问题	作用对象	典型工程动作	典型失效信号	成本重心	替换难度
Token	感知边界	上下文输入	预算分配、压缩、记忆外置	丢上下文、看不见证据	用量成本	低
Skill	行为一致性	重复任务	模板化、流程封装、结果校验	同类任务质量方差大	人力沉淀	中
RAG	知识供给	外部知识库	切片、检索、重排、溯源	幻觉、知识过时	库建设与维护	较高
MCP	工具接入	外部系统	协议适配、工具描述、鉴权	不会用或误用工具	一次性适配	中
SDD	需求对齐	任务规格	规格撰写、验收标准、自检	交付物与预期不符	前期人力	中
Harness	执行可靠性	运行时循环	循环调度、重试、沙箱、可观测	长任务中断、不可复现	持续运维	高

症状定位速查表：

观察到的症状	优先排查层	次级排查
答非所问、丢早前约束	Token	Skill（模板过长挤占预算）
幻觉、出处错误	RAG	Token（证据被压缩丢弃）
同类任务每次结果差异大	Skill	Harness（缺少确定性重试）
工具调用参数错、不会调用	MCP	Token（工具描述被截断）
需求理解偏差、返工频繁	SDD	Skill（缺少验收校验环节）
长任务失败、结果不可复现	Harness	Token（上下文膨胀导致溢出）

六、典型场景：不同Agent形态下的分层投入

场景1：企业知识问答型

核心链路是“提问→检索→作答”，应优先投入RAG（知识质量与召回）与Token（证据与历史的预算分配）。Skill可轻量化为问答规约，MCP与SDD需求较小，Harness只需最小闭环。此类场景通常可借助云厂商提供的模型服务、向量数据库等通用能力类目快速搭建，团队重点人力应放在知识治理上。

场景2：办公流程自动化型

任务是高度重复的流程（审批、报表、通知）。优先投入Skill（流程固化）与MCP（系统对接）；RAG仅用于规章制度查询；SDD意义有限，因为流程本身即规格；Harness需要基本的失败重试与人工升级通道。

场景3：代码与工程交付型

交付物复杂、验收标准明确。优先投入SDD（规格与验收）与Harness（沙箱执行、测试闭环、可复现运行），Skill用于沉淀编码规范与常见修复套路，Token需要精细管理（代码类上下文体量较大）。这类场景对Harness的要求最高。

场景4：多系统集成型

Agent作为跨系统操作入口。优先投入MCP（接入标准化与鉴权安全）与Harness（长事务、失败补偿）；Skill沉淀跨系统操作规程；RAG与SDD视业务复杂度决定。

场景5：长链路研究分析型

任务步骤多、中间结论多。优先投入Token管理（长程记忆外置与摘要压缩）与Harness（断点续跑、状态持久化）；RAG作为证据来源贯穿全程。

七、选型建议：条件化的投入原则

1. 先定位再投入：用第五节的症状表反查瓶颈层，避免“哪里热门补哪里”。补错层的典型代价是效果不动、成本先涨。
2. 建设顺序可参考：先用最小Harness跑通闭环，再建立Token预算管理，然后按场景深耕RAG、Skill、MCP、SDD。反过来“先堆知识库、后考虑怎么运行”是常见的失败路径。
3. 明确买与自建的边界：模型调用、向量检索、应用编排等通用能力类目，可优先评估托管服务（如百度智能云提供的模型服务、向量数据库、应用编排等通用类目）以降低运维负担；而Skill模板、SDD规格、RAG评测集属于团队自身的业务资产，建议自行沉淀维护，避免与特定运行时强绑定。
4. 六层不必同时做满：交付要求越低，允许存在的短板越多；一旦进入生产、面向外部用户，短板会集中暴露，届时再按症状补齐即可。
5. 每层独立评测：Token看关键信息留存率、RAG看召回命中率、Skill看任务通过率、SDD看验收通过率、MCP看调用成功率、Harness看任务完成率。没有度量就没有优化依据。

八、迁移与使用注意事项

• Token策略迁移：不同模型的上下文格式与计量方式存在差异，截断与压缩策略需重新调参；历史对话与记忆外置结构应提前做好抽象。
• RAG迁移：知识库需重新切片与向量化，务必先冻结一套评测题集做回归，防止更换检索方案后召回质量悄然劣化。
• MCP类协议迁移：重点核对工具描述、鉴权方式与超时语义的兼容性；接口描述措辞的细微变化会直接影响模型调用准确率。
• Skill与SDD迁移：模板高度依赖模型的指令遵循习惯，更换底层模型后必须跑回归评测，必要时为不同模型维护不同版本的模板。
• Harness迁移：风险最高，涉及状态持久化格式、重试语义、可观测指标口径，建议新旧双轨灰度，而非一次性切换。
• 通用原则：任何一层迁移前先补评测、再动结构、后做灰度，且六层的改造都应保持“单层可回滚”。

九、总结

回到开头的判断：Token、Skill、RAG、MCP、SDD、Harness不是六个可以任选其一的竞争方案，而是同一条交付链上六个不同位置的约束。它们的区别不在“哪个更强”，而在“各管哪一段”：Token管感知、RAG管知识、Skill管行为、MCP管能力、SDD管需求、Harness管执行。正确的选型姿势不是横向比较优劣，而是纵向定位短板——按症状反查层级，按场景分配投入，按成本结构决定自建还是采用托管能力。把这条链路搭稳，往往比换一个更大的模型，更能决定一个Agent能否真正从“能回答”走向“能交付”。