在Agent工程实践中，许多团队容易陷入一种误区：认为只要将底层模型替换为参数规模更大的版本，智能体能力就会自然跃升。然而，真实世界的交付瓶颈往往不在模型本身，而在于围绕模型构建的工程链路是否稳固。Token、Skill、RAG、MCP、SDD与Harness这六个术语频繁出现在技术讨论中，但它们并非六个相互独立的技术栈并列关系，而是描述同一个系统从“能回答”走向“能交付”的六层约束。本文以对比视角，深度拆解这六个要素的核心定位、技术差异、适用场景与选型逻辑，帮助读者建立一张清晰的Agent工程全景图。
一、对比背景：从“模型能力焦虑”转向“工程约束意识”
当前Agent开发中的普遍痛点在于：模型在演示环境表现惊艳，进入生产环境后却频繁出现答非所问、流程中断、权限失控、代码不可维护等问题。根本原因在于，团队过度关注单点模型指标，而忽略了围绕任务闭环的工程化约束。Token、Skill、RAG、MCP、SDD、Harness正是解决上述问题的六类约束手段。它们分别从感知范围、行为规范、知识补给、外部连接、开发规格、运行编排六个维度，定义了Agent在真实业务中的行为边界。理解它们的差异，是进行合理技术选型与架构设计的前提。
二、对象定义：六层约束分别解决什么问题
为了清晰对比，我们先为每个概念给出明确的功能边界定义：
- Token（上下文窗口管理）：决定Agent在执行任务时“当前能看见多少信息”。它包含输入上下文长度限制、关键信息截断策略、注意力分配权重等。Token管理解决的是模型工作记忆的有限性问题。
- Skill（技能与流程编排）：定义Agent遇到重复性或标准化任务时“按什么规矩做事”。Skill将确定性流程（如工单分类、数据清洗规则）固化为可调用的子程序，减少模型自由发挥带来的不确定性。
- RAG（检索增强生成）：决定Agent“缺乏知识时从哪里获取证据”。RAG通过外部向量数据库或知识库检索，为模型生成过程提供可追溯的上下文证据，缓解事实幻觉。
- MCP（模型上下文协议）：定义Agent“如何安全、标准化地接触外部系统”。MCP规定了模型调用工具、API、数据库时的认证方式、参数约束与流量控制，防止模型越权操作。
- SDD（规格驱动开发）：决定Agent在编写代码或生成配置文件之前“是否有明确的技术规格”。SDD强调先 definir 接口契约、数据结构、验收条件，再让模型实施生成，避免发散式编码。
- Harness（运行框架与治理）：作为上述五者的承载与调度环境，负责生命周期管理、日志追踪、失败重试、版本回滚、灰度发布以及安全审计。Harness决定了Agent系统的可运维性与稳定性。
三、相同点分析：六者的底层共同逻辑
尽管分工不同，这六层约束在设计哲学上存在三个显著共同点：
- 目标一致：都是为了降低Agent在真实业务中的不确定性，提升从输入到交付的成功率。
- 可组合性：它们不是互斥选型，而是需要按业务场景进行叠加组合。例如，一个客服Agent可能同时需要RAG补充产品知识、Skill执行业务流程、MCP调用订单系统。
- 依赖感知：六者均依赖底层模型的基础能力，但都试图将“模型原生的开放生成”收敛为“受控的、可预期的工程行为”。它们共同构成一层位于模型之上的“理性约束层”。
四、核心差异分析（对比维度展开）
1. 技术架构与系统边界
- Token层：紧贴模型运行时，属于模型推理管线的内部策略，通常通过提示词截断、摘要压缩或上下文压缩算法实现，与业务系统无直接耦合。
- Skill层：位于模型与业务逻辑之间，以代码函数或工作流定义存在，需要引入流程引擎或函数注册中心。
- RAG层：独立于模型之外的存储与检索系统，依赖向量化管道、索引服务与相似度计算服务，架构上属于外围知识供给模块。
- MCP层：属于通信协议层，需要定义统一的工具调用接口规范，包含请求格式、鉴权头、错误码与速率限制，类似于一套“Agent世界的API网关”。
- SDD层：属于开发流程层，通常以模板、schema文件或DSL（领域特定语言）形式存在，在模型编码前提供约束。
- Harness层：属于运行底座，包含容器化部署、可观测性探针、任务队列、状态存储与人工审核接口。
2. 功能能力与解决问题侧重点
| 对比维度 |
Token管理 |
Skill编排 |
RAG检索 |
MCP协议 |
SDD规范 |
Harness框架 |
| 核心问题 |
上下文溢出、信息丢失 |
流程不可控、重复劳动 |
知识不足、生成幻觉 |
工具调用混乱、权限失控 |
代码不符合预期、返工 |
运行不稳定、故障难排查 |
| 功能覆盖 |
截断策略、关键信息压缩 |
流程模板、条件分支 |
向量化、重排序、引用溯源 |
统一鉴权、参数白名单 |
接口定义、契约测试 |
日志追踪、限流熔断、审计 |
| 典型输出 |
精简后的有效上下文 |
标准化服务函数 |
带引用的知识片段 |
受控的API调用记录 |
符合规范的设计文档 |
可观测的运行状态视图 |
3. 接入方式与开发改造量
- Token层：接入成本最低，通常通过修改系统提示词或调用模型API的上下文截断参数完成，但调优难度在于如何平衡信息丢失与回答质量。
- Skill层：需要开发人员将既有业务逻辑封装为无状态函数，并编写触发条件，改造量中等。
- RAG层：需要构建离线数据管道、设计分块策略、配置向量索引，并持续维护知识库版本，初始工作量大，但一旦建立，维护成本集中于文档更新。
- MCP层：需要为每个外部系统编写符合协议的工具适配器。如果外部系统接口陈旧或文档不全，适配成本较高，但能获得统一的安全管控。
- SDD层：需要团队具备较强的架构设计能力，强制要求“先设计后编码”，初期拖慢节奏，但显著减少后期返工。
- Harness层：需要选择或自研运行底座，涉及与CI/CD、监控体系、日志平台的集成，初期搭建成本最高，但长期收益最明显。
4. 性能表现与稳定性侧重
- Token层：直接影响响应延迟与成本。上下文过长会增大计算开销，因此高效压缩能显著提升吞吐。
- Skill层：性能取决于流程引擎的调度效率，通过预编译或缓存可减少模型顺序推理次数。
- RAG层：性能瓶颈在检索延迟与召回质量。需要关注向量索引的构建速度与高并发下的查询QPS。
- MCP层：性能损耗集中在协议解析与安全校验，不当设计可能成为瓶颈，需注意连接池与异步化处理。
- SDD层：在运行期无直接性能损耗，但在编译期或校验期会产生额外开销，可通过增量校验优化。
- Harness层：框架本身的稳定性直接决定了Agent的整体可用性，需重点设计故障隔离与优雅降级机制。
5. 安全与合规约束
- Token层：需防止用户提示词注入导致上下文污染，需设置敏感信息过滤。
- Skill层：需控制技能调用权限，防止未授权技能被触发。
- RAG层：需确保知识库内容的权限隔离，防止低权限用户通过检索获取敏感文档。
- MCP层：是安全防护的核心阵地，必须提供OAuth、API Key、IP白名单等多重鉴权机制，且对所有调用进行全量审计。
- SDD层：通过强制数据schema校验，从源头避免不合规的数据结构进入下游。
- Harness层：提供统一的密钥管理、细粒度RBAC（基于角色的访问控制）以及操作日志的不可篡改存储。
6. 运维成本与长期维护
- Token管理：需要持续监测上下文长度分布，不断调整压缩阈值。
- Skill编排：技能列表会随业务增长膨胀，需建立技能版本管理与退役机制。
- RAG系统：是运维重灾区，需要定期更新索引、清理过期文档、监控检索质量漂移。索引重建耗时需规划窗口。
- MCP适配器：外部系统接口升级时需同步更新适配器，版本兼容性管理复杂。
- SDD规范：需维护schema仓库，并培训团队成员遵守规范，文化阻力可能较大。
- Harness框架：需要专职平台团队维护，涉及版本升级、插件兼容、容量规划等，运维成本最高。
五、结构化对比总结表
| 维度 |
Token管理 |
Skill编排 |
RAG检索 |
MCP协议 |
SDD规范 |
Harness框架 |
| 核心比喻 |
眼睛（看多远） |
肌肉记忆（熟练工） |
藏书阁（查资料） |
交通规则（过马路） |
图纸（盖楼前画图） |
工地监理（全程监管） |
| 主要解决 |
短期记忆有限 |
重复动作标准化 |
事实性知识缺失 |
外部系统安全接入 |
输出质量偏离 |
全局稳定性与可观测性 |
| 参与角色 |
算法工程师 |
业务开发/运维开发 |
数据工程师/算法 |
后端/平台开发 |
架构师/技术负责人 |
SRE（站点可靠性工程师）/平台组 |
| 故障模式 |
关键信息被截断 |
流程僵硬无法应对异常 |
检索到无关内容 |
鉴权失败或超时 |
规格陈旧导致生成内容过时 |
任务卡死、雪崩效应 |
| 典型治理手段 |
摘要压缩、滑动窗口 |
工作流引擎、状态机 |
混合检索、rerank重排序 |
熔断限流、请求签名 |
契约测试、linter静态检查 |
全链路追踪、混沌工程 |
六、典型场景与选型建议（条件化分析）
根据不同的业务场景，各层级的优先级与组合策略存在显著差异。以下提供几种典型画像供参考，并非绝对推荐。
场景A：轻量级客服问答机器人（面向内部知识库）
- 核心诉求：快速响应、事实准确、无需复杂业务流程。
- 优先级建议：Token管理 > RAG > Harness基础版。
- 理由：该场景以单轮或多轮问答为主，用Token管理确保上下文不超限，用RAG保证答案有据可依，Harness只需提供基础日志与限流即可。Skill与MCP在此场景非必需，SDD暂可忽略。
场景B：企业级自动化流程Agent（需要操作内部ERP/CRM系统）
- 核心诉求：权限严格、交付稳定、可审计。
- 优先级建议：MCP > Skill > Harness > SDD。
- 理由：操作外部系统必须先通过MCP定义安全边界；高频操作通过Skill封装为标准动作；Harness负责记录所有操作轨迹；SDD则用于约束生成的数据变更脚本，防止非法SQL操作。
场景C：研发辅助Agent（自动生成代码与接口）
- 核心诉求：减少人工review成本、保持代码风格统一、契约清晰。
- 优先级建议：SDD > Harness > Token管理 > Skill。
- 理由：代码生成的当前最大痛点是“跑不通”和“不符合规范”，SDD通过严格的输入输出schema强制约束生成格式；Harness负责自动执行单测与静态扫描；Token管理处理大文件拆分；Skill固化常用代码模板。
场景D：面向海量文档的复杂推理Agent（如金融研报分析）
- 核心诉求：深度上下文理解、多跳推理、长文档长时任务。
- 优先级建议：Token管理 > RAG > Harness > Skill。
- 理由：长文档阅读必须精细控制Token分配；RAG负责跨文档关联；Harness处理长时间任务的异步化与断点续跑；该场景应尽量避免使用MCP直连数据库，减少外部依赖带来的不确定性。
选型核心思路：如果团队刚起步，建议优先搭建Token管理 + 基础Harness，确保Agent“跑得动、可追踪”；随后根据出现的具体问题迭代添加其他层：
- 出现“流程返工”则引入Skill；
- 出现“知识幻觉”则引入RAG；
- 出现“工具调用失控”则引入MCP；
- 出现“生成物质量无法验收”则引入SDD。
七、迁移与使用注意事项
当团队计划将已有Agent系统从“裸模型提示词工程”升级为“六层完整架构”时，需注意以下风险点：
- 数据迁移风险：引入RAG时，原有非结构化知识文档需完成清洗、分块、向量化，历史版本文档需做好归档，避免脏数据污染索引。
- 接口兼容性风险：MCP适配器的引入可能让原本“直接HTTP调用”的业务系统产生鉴权阻断，需预留接口切换的灰度周期。建议在预发环境完整回归外部系统调用链。
- 规范引入的团队阻力：SDD要求开发流程前置设计阶段，可能被视为“增加额外工作量”。建议从一个小型非关键模块试点，用数据证明其降低的返工率。
- Harness的过度设计风险：对于日均调用量极低的小型应用，引入完整Harness（包括多环境、灰度、熔断）会造成运维负载过重。此时可选用轻量级日志存储与简单告警，逐步演进。
- Token管理的副作用：过于激进的上下文压缩可能导致模型丢失隐含的指令信息。需建立“关键指令关键词保护列表”，强制保留部分原文字符。
八、总结
Token、Skill、RAG、MCP、SDD与Harness并非一场技术军备竞赛，而是Agent工程化成长的六个必经阶段。它们从不同维度限制模型的“自由发挥”，将其束缚在业务可接受的边界内。核心区别清晰可见：Token管视力，Skill管习惯，RAG管证据，MCP管通道，SDD管质量，Harness管全局。真正的架构优化，不在于盲目堆砌全部组件，而在于精准识别当前业务交付链路上最薄弱的约束环节，并针对性地强化对应层级。理性的决策路径是：先建立基础运行框架，再根据故障驱动引入更细粒度的约束，最终形成一个稳固、可信、可演进的Agent交付系统。