关于 Harness、SDD、Context Engineering 本质是什么

Harness、SDD、上下文工程的概念和背景

2026 年开年，AI Agent 工程领域最热的三个词，分别是 Context Engineering、SDD（Spec-Driven Development）和 Harness Engineering。它们几乎同时出现在一线工程团队的讨论中，但彼此之间的关系并不总是清晰。

先理清各自的位置。

Context Engineering（上下文工程）。 这个词在 2025 年中由 Andrej Karpathy 和 Shopify CEO Tobi Lutke 的推文带入主流视野。它关注的核心问题是：模型在执行任务时，“看到"了什么信息？相比 Prompt Engineering 的"怎么把任务表达对”，Context Engineering 把焦点从单次输入-输出对，扩展到了动态管理上下文窗口——RAG 检索、工具输出、对话历史、系统指令的编排——让模型在正确的时刻获得正确的信息。Anthropic 给出的定义很直接：当 Agent 朝向更长时间跨度和多轮推理演进时，核心挑战变成了"管理整个上下文状态：系统指令、工具、MCP 服务器、外部数据、消息历史"。

SDD（Spec-Driven Development，规范驱动开发）。 这是 AI 原生开发中正在快速成型的一种方法论。它的核心理念是"规范为先"：在编写任何实际代码之前，先编写一份详尽、精确、可执行的规范文档，将其作为项目的"单一真相源"。SDD 的工作流通常包括四个阶段：意图定义（澄清需求）、技术规划（设计技术方案）、任务分解（拆解为可执行单元）和自动化实现（由 AI Agent 按规范生成代码）。规范的精确度直接决定生成代码的质量——这已经不同于传统的"需求文档 + 手写代码"模式，规范不再是建议性的参考，而是驱动执行的契约。

Harness Engineering（驾驭工程）。 这个术语由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月的博文中正式命名，后经 OpenAI 的实验报告和 Thoughtworks 工程师 Birgitta Böckeler 的分析框架迅速传播。它的关注范围比前两者更宽：Harness Engineering 是对系统的设计与实现，约束 Agent 能做什么，告知它应该做什么，验证它是否正确完成，并在出错时纠正它。模型是马，Harness 是缰绳、马鞍、马蹄，甚至是路。没有 Harness 的系统跑得快，但没有可靠的方向。

三者不是替代关系，而是层级关系：Context Engineering 关注模型"看到什么"，SDD 关注"以什么规范驱动执行"，Harness Engineering 关注"模型运行在什么系统里"。 Context Engineering 和 SDD 是 Harness Engineering 的两个核心组成部分——前者解决信息供给，后者解决执行契约，而 Harness 负责将这一切整合为一个可运行、可约束、可验证的系统。

在 LLM 应用的发展过程中产生这些概念的原因

这些概念的集中涌现不是巧合。它们共同指向一个根本性问题：当 LLM 的通用能力已经足够强时，瓶颈从模型本身转移到了模型工作的环境。 具体来说，驱动因素有两个层面。

私网知识 —— 但这不是最重要的原因

大模型通过海量公开数据训练获得了广泛的世界知识，但企业的核心资产——私有的业务数据、领域术语、内部规范、历史决策记录——永远不在训练语料中。这确实是 RAG、知识库等技术需求的市场驱动力，但坦白说，这不是催生上述概念的最关键原因。RAG 解决的是"不知道"的问题，而当前一线团队面临的主要矛盾，早已不是模型"知识不够"，而是模型"知道得太多却做不对"。

让 LLM 足够聚焦

真正的核心原因，是如何让一个通用模型在特定场景下保持专注。

LLM 的智能广度是其核心优势，但也是其核心难题。一个能写诗、能编程、能分析财报的模型，在面对"请为这个 Python 函数编写单元测试"时，它的注意力同样会扩散到不相关的知识空间。MoE（混合专家）架构本质上试图解决这个问题——通过路由机制将输入分配到最相关的专家子网络——但在当前的技术水平下，MoE 的"智能聚焦"能力还远远不够。模型依然会在长上下文中漂移，在复杂任务中遗忘早期指令，在缺乏反馈时陷入循环。

这正是 Context Engineering 和 SDD 的用武之地。Context Engineering 通过主动管理模型看到的信息来引导聚焦——不是靠模型自己的注意力机制被动选择，而是由工程系统决定"在什么时刻，模型应该看到什么"。SDD 则更进一步：它用结构化的规范文档作为执行蓝图，让模型不是"自由发挥"，而是"按图施工"。两者本质上都是在外部（而非模型内部）建立聚焦机制，弥补模型自身注意力机制的不足。

LangChain 的编码 Agent 在 Terminal Bench 2.0 上的表现直接证明了这一点：没有更换底层模型，只优化了 Harness（包括上下文加载策略、验证回路和反馈机制），得分就从 52.8% 提升至 66.5%，排名从前 30 跃升至前 5。同一个模型，不同的环境，结果天差地别。

关于怎么做的讨论，本质上就是在现阶段找到解决上述问题的方案

理解了"为什么要聚焦"，也就理解了"怎么做"的方向。当前围绕 Harness Engineering、SDD、Context Engineering 的所有实践讨论，本质上都是在回答同一个问题：在没有完美模型注意力机制的前提下，如何通过工程手段让 LLM 在具体任务上保持可靠？

这需要非常清晰的靶子。在实践中，我们看到一些工程团队"依葫芦画瓢"——引入几个 Skill、写一份 AGENTS.md、象征性地搭建工作流，招式看起来很酷炫，但由于没有真正理解要解决的问题，实际产出价值很小。炫技不是工程。

要真正解决"聚焦"问题，不能简单地套用几个 Skill 扔给 LLM 就完事。在软件工程领域，LLM 当前遇到的问题，本质上与软件工程几十年来一直在解决的问题是一致的：如何将项目的范围说清楚，让整个团队（现在包括 AI Agent）始终聚焦在一个局部，而整体范围的演进遵循产品发展的规律。

具体来说，这依然需要掌握方法和工具，渐进明晰地确定以下四个维度：

1. 需求范围：用户真正需要什么？在当前迭代中，什么必须做、什么可以不做？
2. 技术范围：为实现需求，涉及哪些系统模块、接口、数据流？边界在哪里？
3. 数据范围：需要哪些数据？数据结构、来源、质量要求是什么？
4. 项目约束：在成本、进度、人力资源及其他条件下，什么方案是可行的？

这四个维度的范围定义，在传统软件工程中由 BA（业务分析师）、SA（系统架构师）、PM（项目经理）等角色协作完成。在 AI Agent 时代，这些角色并没有消失——它们的工作成果被结构化为 Context 和 Spec，成为 Harness 的组成部分。

关于 Agent MCP Warehouse 在此方面的实践，以及得到的收获

Agent MCP Warehouse（mcp.smartmoves.com.cn）正是在这个方向上的实践探索。它的出发点很明确：将领域专家知识封装为标准化、可复用的 Skill 资产，让 AI Agent 在具体场景下按标准"工艺"执行，从而压缩软件研发中的"工艺方差"。

平台的核心逻辑可以概括为一句话：把 Skillsets 装进容器，将"技能的构建"和"技能的执行"拆开。

• 构建——由懂业务、懂技术的团队负责，把组织的领域经验结构化地写入 Skill 定义文件（SKILL.md）。每个 Skill 精确描述了触发条件、执行流程、输入/输出契约和质量标准。
• 执行——由 AI Agent 承担，按照 Skill 定义的标准"工艺"去干活。Agent 不需要重新理解领域方法论，只需要遵循 Skill 定义的步骤。
• 治理——中间有 Housekeeper 角色，负责技能资产的版本管理、质量审计、调度和持续迭代。

平台的第一个实践场景选择了软件工程领域，构建了 BA Master Agent（业务分析师）、SA Master Agent（系统架构师）和 PM Master Agent（项目经理）三类示例。

这些技能的核心设计思想，正是回应上文所述的本质问题——“让 LLM 足够聚焦”。 它们不替代人做决策，而是通过与真实的 BA、SA、PM 进行问答式交互，逐步引导项目范围聚焦：BA Agent 通过与业务分析师的多轮对话，逐场景深挖需求细节，将模糊的业务诉求收敛为清晰的场景定义和数据边界；SA Agent 通过与系统架构师的交互，将零散的技术想法收敛为有约束的架构方案和接口规范；PM Agent 则通过与项目经理的协作，将宽泛的目标收敛为可执行的迭代计划和工作量评估。每一步交互都在"收缩范围"——不是 Agent 自己拍脑袋，而是引导人把脑子里隐式的经验显式化、结构化。

以 BA Master Agent 为例，它严格遵循门禁规则，按"根目的发现 → 领域知识加载 → 三维度需求澄清 → 结构化输出"四阶段渐进式推进。在每个阶段，Agent 向 BA 提出针对性问题——“这个场景的核心价值是什么？”“异常流程怎么处理？”“和哪些外部系统有交互？”——引导 BA 一步步填充信息空白。最终产出的是包含场景分析、流程描述、数据实体和系统边界的完整需求规格说明书。

这些具体 Agent 只是范式在软件工程领域的具象化验证。切换金融、医疗、制造等其他领域，只需替换为对应的领域 Skill 包，底层范式完全一致。

更重要的是，这些产出的目标不只是文档。 它们被设计为可供 LLM 直接消费的、结构化、可执行的输入——需求规格说明书定义了"做什么"，架构方案定义了"怎么做"，迭代计划定义了"以什么节奏做"。当这三个维度的输入清晰而聚焦时，LLM 从"理解需求"到"生成可交付代码"的信息损耗被大幅压缩，代码生成的精准度和可用性获得数量级提升。这正是 Harness Engineering 与 SDD 理念在实践中的交汇点：规范先行，范围聚焦，人机协作——让模型不是"自由发挥"，而是在清晰的边界内"精准施工"。

实践中的收获

第一，Context 和 Spec 是 Harness 的"材料"，不是全部。 在初期实践中，团队容易把所有精力放在写 AGENTS.md 和 Skill 定义上，而忽略了验证和反馈回路。OpenAI 报告中的经验同样适用：AGENTS.md 应该是一份不超过 100 行的精简目录，而非塞满所有信息的"百科全书"。苏黎世联邦理工学院的研究也证实，LLM 生成的大而全的指令文件反而会损害性能。

第二，"范围界定"是 Harness 的起点。 每次让 Agent 执行任务之前，必须先在需求、技术、数据和约束四个维度上界定清楚范围。这听起来像软件工程的老调重弹，但当执行者是 AI Agent 时，范围模糊的代价比人类团队更大——模型不会主动提问"你确定要这么做吗？"，它只会忠实地执行模糊的指令，然后在错误的方向上走很远。

第三，渐进式披露比一次性注入更有效。 Context 不是越多越好。Agent 不需要在一开始知道所有事情，它需要在正确的时机获得正确粒度的信息。这与人类工程师入职的逻辑一样——没有人第一天就读完公司所有文档。OpenAI 团队的实践也验证了这一点：从全局配置到项目根目录再到子目录，逐级就近优先。

第四，"验证即反馈"的闭环不可缺失。 Context 告诉 Agent"知道什么"，Harness 中的验证机制确保 Agent"做对了再继续"。在这个问题上，当前行业的差距很明显：LangChain 的调查显示，89% 的团队已为 Agent 实施可观测性（能"看见"Agent 做了什么），但仅有 52% 实施了评估（能判断"做得对不对"）。"看见"和"判断对错"之间，正是 Harness 要填补的缺口。

结语

Harness Engineering、SDD、Context Engineering 这些概念的集中涌现，并非术语的轮换炒作。它们标志着 AI Agent 工程从"模型竞赛"进入"环境竞赛"的范式转移。当底层模型的能力趋于同质化，真正拉开差距的，是谁能为 Agent 设计出更好的运行环境——让它在正确的时刻看到正确的信息，按明确的规范执行，在边界内行事，并在出错时被及时纠正。

这些概念的本质是相通的：通过各种工程手段，让 LLM 在某个具体的场景下足够聚焦，从而在 Token 效率、智力水平发挥程度、产出速率和质量上产生积极效果。

---

原型站点（含 help-doc）：https://mcp.smartmoves.com.cn