简介：本文围绕智能体开发与落地过程中最常被提及的六类核心能力进行系统对比，包括上下文组织、技能封装、检索增强、上下文协议、规范驱动开发与运行治理框架。文章从架构定位、作用边界、接入成本、适用场景和组合关系等维度展开分析，帮助开发者在设计智能体应用时准确判断各项能力的真实价值与选择顺序，避免概念混用或过度设计。
在实际开发中，智能体应用经常面临一个看似简单却非常棘手的问题：代码库装不进上下文。
假设你让一个智能体修改订单模块。按照直觉，它的第一步应该是阅读相关文件。于是它可能尝试读取以下内容：
src/order/OrderService.javasrc/order/OrderController.javasrc/order/model/Order.javasrc/order/mapper/OrderMapper.xmlsrc/common/Result.javasrc/config/AppConfig.java...
但很快你会发现几个问题。第一，文件数量远远超过单次上下文窗口能够承载的上限。第二，即使强行塞入，模型对文件之间的调用关系、历史变更原因和业务约束仍然缺乏理解。第三，每次执行都重新读取全部文件，会造成大量重复的上下文消耗，响应速度和成本都不理想。
这个场景本质上揭示了一个关键事实：智能体的能力并不是由单一模型参数决定的，而是由围绕模型的一系列工程化能力共同决定的。这些能力包括怎么管理上下文、怎么复用已有操作、怎么从外部知识库补充信息、怎么与外部系统交互、怎么约束输出格式、怎么在复杂环境中稳定运行。
因此，理解这些能力之间的区别与联系，比单纯关注模型本身更贴近实际生产需求。本文将从这一角度出发，对六类关键概念进行拆解和对比。
为了避免概念混用，先对本文涉及的六个对象做统一说明。它们是智能体系统在不同层次上需要面对的六类问题所对应的解决方案。
Token：模型输入输出的最小计量单位，也是上下文窗口的物理边界。它既代表成本，也代表信息密度。智能体开发中几乎所有优化动作，最终都会反映在 Token 的使用效率上。
Skill：将一段可复用的操作封装为标准化能力单元。一个技能可能包含提示词模板、工具调用序列、输入输出约束和失败重试策略。技能的价值在于让智能体不必每次从零开始规划某一类任务。
RAG：检索增强生成。通过先检索外部知识片段，再将相关片段注入上下文，从而让模型在不需要完整理解全部语料的前提下回答领域问题。它解决的是“知识太多，无法全部装入上下文”的问题。
MCP：模型上下文协议。它定义智能体与外部工具、数据源和服务之间的一种标准化交互方式，目标是让模型能够以统一的方式发现、调用和管理外部能力，而不必为每个工具单独编写适配逻辑。
SDD：规范驱动开发。要求先在需求层面形成结构化、可验证的规范，再驱动后续设计、编码和验证流程。它解决的是智能体生成结果不可控、需求理解不稳定、产出偏离预期的问题。
Harness：运行治理框架，负责智能体应用在开发、测试、部署和运行阶段的生命周期管理。它通常包括任务调度、状态跟踪、回滚、监控、评估、权限控制和版本管理等功能。
需要强调的是，这六者并不处于同一层级，也不是互相替代的关系。它们分别回答了智能体工程化中不同维度的问题。
虽然定位不同，这六类能力在目标和逻辑上存在一些共同点。
第一，它们都服务于同一个核心目标：降低模型能力与真实任务完成之间的落差。模型本身具备理解和生成能力，但仅靠模型无法可靠完成复杂业务任务，必须依赖外部工程能力弥补上下文、知识、工具、规范和治理方面的不足。
第二，它们都在试图减少模型的不确定性。技能通过预封装减少规划偏差，RAG 通过检索约束减少知识幻觉，SDD 通过规范约束减少产出偏离，Harness 通过运行管控减少不可控行为，MCP 通过标准化协议减少工具调用不一致，Token 优化则通过控制输入质量间接影响输出稳定性。
第三，它们在架构上都需要与模型网关或智能体运行时协同工作，而不是独立生效。换句话说，这些能力通常不是单独采购或单独部署的组件，而是嵌入在智能体应用的整体架构中。
Token 是资源层概念，属于模型推理的基础计量单位。它直接受模型上下文窗口大小、计费方式和分词规则影响。开发者对 Token 的优化通常是间接的，例如通过裁剪输入、压缩提示词、选择更合适的模型或调整检索策略来实现。
Skill 是能力封装层。它位于模型与具体任务之间，将特定任务的执行经验固化下来。一个技能的粒度可以是单个工具调用，也可以是一组包含条件判断和循环逻辑的复杂流程。技能设计的好坏，直接影响智能体在相似任务上的执行效率与一致性。
RAG 是知识接入层。它负责在模型推理前从外部知识源获取相关信息。RAG 的核心不是“生成答案”，而是“为生成提供更准确的上下文”。因此它的主要工程难点集中在切片策略、检索质量、重排序和上下文融合上。
MCP 是交互协议层。它规范了智能体与外部系统之间的通信方式。可以将其理解为一种“工具调用的标准化接口”，降低模型对异构工具的学习成本，也降低工具提供方的接入成本。
SDD 是开发流程约束层。它不在运行时直接提升模型能力，而是在开发阶段通过规范文档、校验规则和生成约束来保证最终产出的质量。SDD 更适合用于生成代码、接口定义、配置文件等可验证的结构化产出场景。
Harness 是生命周期治理层。它覆盖从任务创建到结果交付的完整过程，负责调度、状态管理、评估、回滚、权限、审计和监控。Harness 通常不是单个工具，而是一个框架或平台能力集合。
从接入难度看，Token 优化几乎不需要额外系统建设，但需要深入理解模型输入输出行为。Skill 的接入成本取决于是否已有清晰的业务流程抽象，如果任务边界模糊，技能拆分反而会带来额外维护负担。RAG 的接入成本中等，但检索质量调优往往需要较长时间。MCP 的接入成本取决于工具侧的协议适配工作量和模型侧对协议的支持程度。SDD 的接入成本主要体现在规范编写和校验规则维护上，对团队工程习惯有较高要求。Harness 的接入通常涉及现有开发流程和运维体系的整合，改造成本最高。
Token 优化对性能的影响最直接，减少无效输入通常能带来更低的延迟和成本。RAG 会增加检索阶段的额外延迟，需要在召回质量和响应速度之间做取舍。Skill 可能引入额外的编排开销，但在熟练任务上可以显著减少模型反复试错的时间。MCP 可能增加网络往返和协议解析开销，但换来的是一致的安全控制和审计能力。SDD 主要影响开发阶段耗时，运行时性能影响较小。Harness 会引入治理成本，但对生产环境稳定性、权限控制和错误追踪能力提升明显。
在安全方面，Token 本身不涉及权限控制，但上下文中的敏感信息可能带来泄露风险。RAG 需要关注知识库的权限隔离和数据脱敏。MCP 需要重点管理工具授权、调用审计和越权防护。SDD 需要保证规范本身不被恶意注入指令。Harness 则承担整体运行时的身份认证、权限分发和日志审计职责。
| 维度 | Token | Skill | RAG | MCP | SDD | Harness |
|---|---|---|---|---|---|---|
| 核心定位 | 模型计量单位 | 能力封装单元 | 外部知识接入 | 工具交互协议 | 开发流程约束 | 运行治理框架 |
| 主要作用 | 控制上下文与成本 | 复用任务执行经验 | 补充领域知识 | 标准化工具调用 | 保证产出符合规范 | 管理智能体生命周期 |
| 作用阶段 | 推理阶段 | 执行阶段 | 推理前 | 推理中调用外部工具时 | 开发阶段 | 全生命周期 |
| 典型优化方向 | 输入裁剪、提示词压缩 | 技能拆分与复用 | 切片、检索、重排序 | 工具发现与授权 | 规范编写与校验 | 调度、监控、回滚 |
| 接入复杂度 | 低 | 中 | 中高 | 中 | 中高 | 高 |
| 主要风险 | 上下文超限 | 技能边界模糊 | 检索质量差 | 工具越权调用 | 规范不完整 | 治理过重拖慢迭代 |
在原型阶段，首要任务是验证智能体能否完成核心任务。此时建议优先控制 Token 消耗，通过精简输入减少成本和延迟。可以暂不引入复杂 Harness，但应将关键操作封装为基础技能，方便后续复用。如果任务依赖大量内部文档，可以先用轻量级 RAG 方案验证检索效果。
当智能体需要与订单、库存、用户等业务系统交互时，MCP 的价值会明显提升。通过统一协议管理工具调用，可以避免模型为每个业务接口编写不同的调用逻辑。同时需要配合 Harness 进行权限控制和调用审计，防止模型发起越权操作。
在代码生成、接口生成等结构化产出场景中，SDD 的约束价值更高。通过预先定义接口规范、字段约束和校验规则，可以显著减少生成结果的返工率。这类场景中，Token 优化不再是首要目标，产出准确性和可验证性更为关键。
当智能体需要回答大量基于内部知识库的问题时，RAG 是核心能力。此时应重点关注知识切片策略、检索准确率和上下文融合方式。Token 优化与 RAG 密切相关，因为检索结果的质量直接影响每次请求消耗的 Token 数量。
如果目标是构建长期运行的智能体平台，Harness 不可或缺。它负责统一管理技能、工具、知识库和规范的版本与发布流程，同时提供评估、监控和回滚能力。没有 Harness 的智能体应用往往在演示阶段表现良好，但进入生产后难以稳定运维。
在实际项目中，这六类能力通常不会单独使用。更常见的是根据任务特征进行组合。
任务标准化程度高的场景：优先建设 Skill 和 SDD，通过固化流程和约束产出来提升效率。
知识来源分散且更新频繁的场景：将 RAG 作为主要知识接入手段，同时通过 Token 优化控制上下文成本。
工具集成复杂、安全要求高的场景：引入 MCP 统一工具协议，并叠加 Harness 进行治理。
从原型走向生产的过程：逐步将 Harness 纳入体系，同时完善技能版本管理和规范校验机制。
需要特别注意的是，并非所有项目都需要完整引入全部六类能力。过早上线复杂治理框架可能拖慢迭代速度，而忽视运行治理又会让系统在生产环境频繁失控。合理的做法是根据当前阶段的主要矛盾，先解决最影响结果质量的那个问题，再逐步补齐其他能力。
如果团队已经在使用某一种或几种能力，要扩展到新的能力组合时，需要注意以下问题。
第一，技能与规范的迁移成本不低。已经固化的技能可能依赖特定提示词格式或工具返回结构，切换到新的 Harness 或 MCP 实现时，需要重新验证兼容性。
第二，RAG 知识库的迁移涉及数据格式、切片策略和索引方式。不同的检索实现可能对同一份知识源产生不同的召回结果，迁移后必须重新评估检索准确率。
第三，MCP 工具接入时要特别关注授权模型的变化。原来直接调用工具的方式改为协议化管理后，权限校验路径可能变长，需要确认超时、重试和降级策略仍然有效。
第四，SDD 规范的维护需要持续投入。规范过少会导致约束不足，规范过多则会限制模型发挥空间。建议从最小可验证规范开始，逐步细化。
第五，Harness 引入后，原有开发流程和持续集成体系需要适配。建议先以旁路方式接入监控和评估能力，再逐步纳入强制卡点。
Token、Skill、RAG、MCP、SDD 与 Harness 分别对应智能体工程化中的不同问题域。Token 管理的是资源边界，Skill 封装的是执行经验，RAG 连接的是外部知识，MCP 规范的是工具交互，SDD 约束的是开发产出，Harness 治理的是生命周期。它们之间不是替代关系，也不是简单的叠加关系，而是需要根据业务场景、团队能力和阶段目标进行组合与裁剪。
理解这些区别之后，再回到最初的问题——代码库装不进上下文。解决这个问题往往不是单纯扩大 Token 窗口，而是组合使用技能封装常见操作、通过检索只提取相关代码片段、用协议统一仓库访问方式，并在治理框架中固化这些策略。只有把每一层能力放在正确的位置上，智能体才能从“能对话”走向“能可靠完成任务”。