agent-token-skill-rag-mcp-sdd-harness">Agent工程六层链路选型指南：Token、Skill、RAG、MCP、SDD与Harness

Agent工程的核心矛盾，往往不在于模型参数是否足够大，而在于模型之外那条支撑链路是否搭得稳。Token、Skill、RAG、MCP、SDD、Harness这六个词经常被并列提及，但它们并不是六个可以独立采购或独立优化的模块，而是同一个系统从“能回答”走向“能交付”的六层约束。本文要帮助读者完成的选型判断是：在自身业务背景、团队能力与安全约束下，如何为这六层分别选择合适的实现方式，并使它们形成可验证的闭环，而不是堆叠出一组互不衔接的能力。

选型通常发生在以下背景中：团队已经完成模型接入与基础对话验证，准备把Agent推向真实业务；或者现有Agent在演示阶段表现良好，但在长任务、多工具、重复流程中频繁失控；又或者架构评审需要回答“这套Agent方案能不能支撑未来一年的业务增长与合规要求”。这些场景下，选型不是比较“哪个组件更强”，而是判断“哪套组合更适合当前需求、团队能力、系统规模与长期规划”。

一、先理解六层约束的定位，再谈选型

在进入具体评估维度之前，需要先明确每一层解决的是什么问题，否则选型会退化为名词对照。

• Token层决定Agent当前能看见多少东西。它约束的是上下文窗口的分配策略：哪些信息进入上下文、以什么顺序进入、何时压缩或裁剪、长会话如何保持关键状态。Token层的选型实质是上下文管理策略的选型。
• Skill层决定Agent遇到重复任务时按什么规矩做。它约束的是任务执行的标准化程度：能力如何封装、调用边界如何定义、失败如何回退、多步骤流程如何编排。Skill层的选型实质是任务抽象与复用机制的选型。
• RAG层决定Agent缺知识时从哪里补证据。它约束的是知识供给的可信度：检索来源、切分粒度、召回策略、重排与引用溯源。RAG层的选型实质是证据链路的选型。
• MCP层决定Agent怎么安全、标准地接触外部系统。它约束的是工具与数据源的接入方式：协议是否统一、权限是否可控、调用是否可审计。MCP层的选型实质是外部系统集成规范与安全边界的选型。
• SDD层决定Agent写代码之前有没有明确规格。它约束的是从意图到实现的中间产物：需求是否被结构化为可核对的规格、验收标准是否前置、变更是否可追溯。SDD层的选型实质是规格驱动开发流程的选型。
• Harness层决定这些能力能不能稳定跑成一个闭环。它约束的是运行时治理：编排、重试、观测、评测、灰度与回滚。Harness层的选型实质是Agent运行时与质量保障体系的选型。

六层之间存在明显的依赖关系：Token层不稳，RAG塞再多证据也会被挤掉；Skill层不标准，MCP接入的工具越多越难治理；SDD缺失，Harness只能在错误的结果上做无意义的稳定性优化。因此选型必须按链路整体考虑，而不是逐项采购。

二、需求拆解：先回答五个问题

在评估任何一层的方案之前，建议先用五个问题把需求拆开，这些问题直接决定后续每一层的权重分配。

1. 业务目标是什么？ 是提升问答准确率、降低人工处理成本、支撑复杂多步任务，还是把开发流程本身自动化。目标不同，六层的优先级完全不同。以知识问答为主，RAG与Token层权重最高；以流程自动化为目标，Skill与Harness层权重最高；以研发提效为目标，SDD与MCP层不可回避。
2. 系统规模与增长预期如何？ 日调用量、并发会话数、知识库文档量、接入的外部系统数量、用户分布，都会影响架构选择。小规模阶段可以接受简单实现，但需要确认所选方案在数据量增长一个数量级后不会推倒重来。
3. 任务的可容忍错误率是多少？ 内部辅助工具可以容忍一定错误并依赖人工复核；面向客户或涉及资金、权限变更的场景，错误成本高，必须把可审计、可回滚、可拦截作为硬性要求，这会直接抬高MCP与Harness层的选型门槛。
4. 团队能力结构如何？ 团队是否具备检索系统调优经验、协议与网关开发能力、评测体系建设能力，决定了应该选择托管化程度更高的方案，还是自建可控性更强的方案。运维人力有限时，优先考虑运维负担低的实现。
5. 安全与合规边界在哪里？ 数据是否出域、工具调用是否需要审批、日志是否需要留存、权限是否要按最小原则隔离。这些约束往往不是选型后补充，而是选型前置条件。

三、核心评估维度与各层选型要点

3.1 Token层：评估上下文管理的可控性

Token层的选型不应只看“窗口多大”，而要看管理策略是否可控。评估维度包括：上下文组装是否支持分层（系统约束、任务规格、检索证据、历史对话分区管理）；压缩策略是否可配置且不丢失关键约束；长会话是否支持摘要与状态外置；超限时是否有确定性的降级行为而非静默截断。

适配判断：会话短、任务单一的场景，简单的窗口分配即可满足；长任务、多轮工具调用场景，应优先选择支持状态外置与结构化上下文管理的方案，并重点验证压缩后关键约束是否仍然生效。验证方法是构造超长会话与关键约束注入的测试用例，观察约束在压缩后是否被保留。

3.2 Skill层：评估任务抽象的标准化程度

评估维度包括：能力封装的粒度是否合理（过粗难以复用，过细编排成本高）；调用契约是否明确（输入输出结构、失败语义、超时行为）；是否支持组合编排与条件分支；重复任务是否有统一模板；能力版本变更是否可管理。

适配判断：重复任务少、以开放问答为主的场景，不必过早建设复杂Skill体系；存在大量固定流程（如工单处理、报表生成、代码审查步骤）的场景，应优先选择契约清晰、可版本化的Skill封装方式，否则工具越多，行为越不可预测。验证方法是选取一条真实高频流程，用Skill方式封装并与自由编排方式对比成功率与人工干预率。

3.3 RAG层：评估证据链路的可信度

评估维度包括：数据源接入的广度与更新机制；切分与索引策略是否适配文档结构；召回是否支持多路融合与重排；是否提供引用溯源；权限是否随检索生效（不同用户检索到不同范围）；评测集是否可维护。

适配判断：知识更新频繁、答案需要可追溯的场景，应把引用溯源与更新时效作为硬性指标；涉密或多租户场景，必须验证检索层的权限过滤是否在召回阶段生效而非事后裁剪。验证方法是构建包含边界问题与权限差异的评测集，分别测量召回率、引用正确率与越权检索率。

3.4 MCP层：评估集成规范与安全边界

评估维度包括：协议统一性（是否采用标准化的工具与数据源接入方式，降低逐个定制成本）；权限模型（调用身份、最小权限、敏感操作审批）；可审计性（调用日志、参数留存、异常告警）；隔离能力（不同工具、不同租户之间的边界）；扩展性（新增外部系统时的接入成本）。

适配判断：只接入一两个内部系统时，定制集成可以接受；当外部系统数量增长、或涉及敏感数据与写操作时，应优先选择标准化接入协议配合统一网关的方案，把权限与审计收敛到一层管理。需要谨慎的情况是：工具能力强大但权限粒度过粗，此时应补充审批与白名单机制，而非直接放开。

3.5 SDD层：评估规格驱动的可追溯性

评估维度包括：意图是否被结构化为可核对的规格（输入、输出、边界条件、验收标准）；规格与实现之间是否可追溯；变更是否走规格更新流程；规格是否可被自动校验或转化为测试用例。

适配判断：Agent仅做问答或轻量工具调用时，SDD并非必需；一旦Agent需要生成代码、修改配置或执行有副作用的操作，缺少明确规格会让Harness层无法判断“做对了没有”。此类场景应优先选择支持规格前置、验收标准可执行的流程，并验证规格变更后测试用例是否同步更新。

3.6 Harness层：评估运行时闭环能力

评估维度包括：编排能力（多步骤、条件分支、并行与超时控制）；可观测性（链路追踪、Token消耗、工具调用成功率、失败归因）；评测体系（离线评测集、线上采样、回归对比）；发布治理（灰度、回滚、限流）；成本可视（按任务维度的资源消耗）。

适配判断：验证阶段可以用轻量脚本串联；进入生产后，若缺少可观测与评测，任何一层的能力退化都无法被及时发现。团队运维资源有限时，可优先考虑托管化程度更高、内置监控告警与评测能力的运行时方案；对稳定性和数据主权要求高的场景，则需评估自建运行时的运维投入是否可长期承担。

四、选型对比表

评估维度	Token层	Skill层	RAG层	MCP层	SDD层	Harness层
核心判断问题	上下文是否可控可降级	任务是否标准化可复用	证据是否可信可溯源	集成是否规范可审计	规格是否前置可追溯	运行是否可观测可回滚
主要风险	关键约束被压缩丢失	工具越多行为越不可预测	召回失真或越权检索	权限过粗、调用不可审计	无验收标准导致无法判定对错	故障无法定位、退化无法发现
优先加强条件	长会话、多轮工具调用	高频固定流程	知识密集、需引用	外部系统多、涉敏感操作	生成代码或有副作用操作	进入生产、多团队共用
可暂缓条件	短会话、单轮任务	开放问答为主	静态小知识库	仅单一内部系统	纯问答无副作用	验证期小流量
典型验证方式	超长会话约束保留测试	真实流程封装对比	评测集召回与越权测试	权限矩阵与审计抽查	规格变更与用例同步检查	灰度发布与回归对比

五、决策路径：从需求到方案

建议按以下顺序推进判断，避免在单层上过度投入而链路失衡。

1. 确认错误成本与合规边界：先划定不可妥协项（数据出域、审批、审计、回滚），这些条件会直接排除部分方案类型。
2. 确认业务目标的主路径：明确Agent主要承担问答、流程执行还是研发辅助，据此确定六层中哪两层是当前瓶颈。
3. 评估团队能力与运维预算：运维人力有限时，优先选择托管化程度高、内置观测与评测能力的方案；具备平台能力时，可选择可控性更强但需自建治理的实现。
4. 按依赖顺序补齐链路：先保证Token与Harness的底线能力（上下文可控、运行可观测），再扩展Skill与RAG，最后扩大MCP接入范围；SDD在涉及代码生成或写操作前必须就位。
5. 设定验证门槛再上线：为每一层定义可量化的通过标准，未达标不进入下一阶段。

六、验证方法：用小范围试运行降低选型风险

选型结论必须经过验证，而不是停留在架构图上。建议采用以下方法：

• 构建分层评测集：分别覆盖上下文压缩后的约束保持、Skill流程成功率、RAG召回与引用正确率、MCP越权拦截率、规格与用例一致性、Harness故障注入下的恢复能力。
• 灰度与对照运行：新旧方案并行处理同一批任务，对比成功率、人工干预率与单任务资源消耗，避免只看平均值而忽略长尾失败。
• 故障注入：主动模拟工具超时、检索为空、上下文超限、下游系统不可用，观察各层降级行为是否符合预期。
• 成本与延迟采样：按任务维度记录Token消耗、工具调用次数与端到端延迟，确认增长趋势在可接受范围内。
• 审计抽查：对MCP层调用日志做抽样复核，确认权限与参数留存满足合规要求。

七、落地注意事项

接入层面，六层的能力应通过统一配置与契约管理，避免每层各自为政导致行为不可复现。迁移层面，RAG与Skill的存量资产需要版本化，切换方案时保留回滚路径。权限层面，MCP层的权限模型应与既有身份体系打通，敏感操作默认走审批而非默认放开。数据层面，上下文与检索日志的留存策略需提前明确，兼顾审计需求与存储成本。稳定性层面，Harness层的限流、重试与熔断策略要按下游系统能力设定，避免重试风暴。成本层面，Token消耗与工具调用是主要变动成本，应建立按任务维度的可视与预算告警。运维层面，评测集需要随业务演进持续维护，否则回归对比会失去参考价值。

八、总结

Agent工程的选型，本质是六层约束的组合选型，而不是单点能力的比较。核心判断原则可以归纳为三条：第一，先定不可妥协的安全与合规边界，再谈能力扩展；第二，按依赖顺序补齐链路，Token与Harness是底线，Skill与RAG是效率杠杆，MCP是集成规范，SDD是有副作用操作前的必要前置；第三，每一层都要有可量化的验证门槛与回滚路径。适用边界同样清晰：短会话、单轮问答的小规模场景无需完整六层；而一旦Agent承担长任务、多工具调用或写操作，任何一层的缺失都会在Harness层以“无法定位的失败”形式暴露出来。选型的终点不是找到最强的组件，而是找到一组在当前团队能力与业务规模下能够稳定闭环、并可随规模平滑演进的分层实现。