研究对象界定与方法

在 2026 年的语境里，“Harness Engineering”大概率指的是围绕 AI Agent（尤其是编码/执行型 Agent）搭建一整套“驾驭系统（harness）”的工程实践：不是继续把力量押在“更强的模型”或“更巧的提示词”，而是把模型当作发动机，把工具、环境、约束、反馈回路、可观测性、验证与持续改进机制当作方向盘、刹车、仪表盘与赛道围栏，通过系统化投入把“参差不齐、偶尔闪光但不稳定的智能”变成可持续交付的生产力。这个定义在 2026 年初被 Mitchell Hashimoto（HashiCorp 联合创始人）用“我并不确定行业是否已有通用叫法，但我开始称之为 harness engineering”的方式明确提出，并给出核心描述：当代理犯错时，要在系统层面工程化解决方案，让它未来不再重复犯同类错误。

为了避免概念漂移，本报告采用业界在 2026 年上半年逐渐收敛的一条“硬边界”来界定范围：Agent = Model + Harness，其中 harness 是“除了模型权重以外的一切代码、配置与执行逻辑”。这也解释了为什么同一个模型在不同产品里表现可能天差地别：差异往往不在模型本身，而在 harness 的设计质量与迭代速度。

方法上，本报告使用“横纵分析法”：

纵向（Diachronic）：从“早期提示词与工具调用”一路追到“以 harness 为核心的组织与标准化”，重点讲清楚：为什么行业会从 Prompt Engineering / Context Engineering 走到 Harness Engineering，以及每个节点背后的约束与取舍。

横向（Synchronic）：以 2026 年 4 月为切面，判断竞品形态。由于 Harness Engineering 是工程范式/能力集合而不是单一产品，严格意义上它“没有直接竞品”（你很难说“某个产品”在和“软件工程”竞争）。但在实践层面，它体现为多条可选路径与工具栈之间的竞争：OpenAI/Codex、Anthropic/Claude Agent SDK + MCP、LangChain 深度代理栈、企业内部系统（如 Stripe Minions）、开源/社区编排（如 Ralph Loop）、以及以 Block goose 为代表的“本地优先 agent 框架”。它们在“把模型变成可干活的代理”这条赛道上竞争用户与生态位，因此横向部分按“竞品充分（场景 C）”来分析。

纵向分析：沿时间轴的演化叙事

如果把 2026 年的 Harness Engineering 看成一部电影，它的主线其实不是“模型越来越聪明”，而是一个更现实的工程命题：当模型开始能写很多代码、能调用很多工具以后，真正的瓶颈变成了可靠性与可控性——也就是“你如何让它持续、稳定、可审计地把事情做完”。

这条主线大致经历了五幕：从 Prompt 时代的“语言说服”，到工具时代的“让模型长手脚”，再到 Context 时代的“让模型吃到对的信息”，最后进入 Harness 时代的“把系统本身变成治理机器”，并在 2025–2026 年通过标准化组织把它固化为生态基础设施。

第一幕：Prompt 时代的天花板

早期大模型的主交互是“文本输入—文本输出”。工程师最先能调的旋钮也最简单：提示词。2023 年 OpenAI 在 API 层面推出 function calling，明确把“让模型输出结构化的函数调用参数”作为产品能力，这为后续 Agent 的工具化铺路：模型不再只写答案，而开始“建议调用某个工具并给出参数”。

但 Prompt 的局限很快变得明显：再漂亮的系统提示也只是“软约束”，没有强制力；更糟糕的是，模型的非确定性决定了它会在长任务里遗忘、偷懒、提前宣告完成，或者在不同轮次里自相矛盾——它像一个聪明但健忘、还很会自我辩护的实习生。

此时学术界与工程界出现了一个关键转折：把“推理（Reasoning）”与“行动（Acting）”交织起来，让模型在循环里通过外部环境反馈纠错。2022 年的 ReAct 论文把这种模式系统化：模型交替产生推理痕迹与动作，通过调用外部信息源/环境减少幻觉并改进轨迹。它在今天看起来像常识，但在当时，它把 Agent 的雏形钉在了地上：没有行动与反馈，长链条推理会错误传播；有行动与反馈，系统更可解释、更可校验。

与此同时，2023 年 Toolformer 等研究进一步把“模型学习何时调用工具、如何用工具”的能力推向训练层；它提示行业：工具不是外挂，而可能成为模型能力的一部分。

第二幕：工具时代的爆炸与“连接器地狱”

当 function calling 与各类 agent 框架出现后，“让模型做事”开始变得可行，但很快撞上第二堵墙：连接成本。

每接一个数据源/系统（GitHub、Slack、Drive、数据库、内部工单……），都要写一套定制集成；而每换一个模型/平台，又要重写一遍。这就是典型的 N×M 集成困境。Anthropic 在 2024 年 11 月开源 Model Context Protocol（MCP）时，把它明确为要解决的核心痛点：模型再强也被“数据孤岛与遗留系统”困住；如果每个数据源都要单独实现连接，互联就无法规模化。

MCP 的关键意义不在于某个具体功能点，而在于它把“连接”抽象成一个开放协议：开发者可以实现 MCP server 暴露资源/工具，也可以实现 MCP client 让 AI 应用去连接这些 server，从而用单一协议替代碎片化集成。Anthropic 在发布时同时给出规范与 SDK、Claude 桌面端对本地 MCP server 的支持、以及一批开源 server 示例，并点名 Block、Replit、Sourcegraph 等早期采用者。

这一步在时间线上非常关键：它把“工具调用”从单点能力，推进成生态接口。后来的 Harness Engineering 之所以能“工程化”，很大一部分原因就是：工具与数据接入开始有了可复用的标准底座，而不是每家公司都在重复造轮子。

第三幕：Context 时代的兴起与“长上下文幻觉”的破灭

工具接上了，新的问题冒出来：模型到底看到了什么？

在 Agent 场景里，“看不到”往往等价于“不存在”。OpenAI 后来在 Codex 的 harness 叙事里，把这一点说得非常直白：对 agent 来说，任何不在其可访问上下文里的信息都等同于不存在——放在 Google Docs、Slack 讨论或人的脑子里的知识，对 agent 是不可见的。

于是 Context Engineering 兴起：RAG、记忆文件、项目规则文件、把组织知识写进 repo，让 agent 能检索、能定位、能逐步深入。

但 Context 时代很快遭遇第三堵墙：长上下文并不天然可靠。2025 年 Chroma 的 Context Rot 报告用系统实验指出：即便在刻意控制的简单任务里，模型表现也会随输入长度增加而下降，而且下降方式“非均匀、令人意外”；仅靠 Needle-in-a-Haystack 这类检索基准很容易产生“长上下文已解决”的错觉。它强调一个对 harness 极其重要的结论：不仅要关心信息是否在上下文里，更要关心信息以何种方式呈现；这等于把“上下文管理”从技巧升级为可靠性工程。

Anthropic 在面向 agent 的 context 工程实践中同样强调：模型会在一定程度上“失焦/混乱”，因此需要记忆文件、子代理、上下文重置等结构；其例子指出，代理可以通过写 NOTES.md / to-do list 等持久化笔记跨重置保持长期策略。

到这里，行业逐渐意识到：上下文不是越多越好。你需要结构、索引、渐进式披露（progressive disclosure），需要让 agent 按地图走，而不是把整本手册塞进它脑袋里。

第四幕：长时程代理的“交接班问题”与 Harness 雏形成型

一旦任务超过单个上下文窗，代理就像进入“轮班制”：每次新会话都像换了一个没有记忆的新员工。Anthropic 在 2025 年 11 月的《Effective harnesses for long-running agents》把这个问题讲得很具象：想象一个软件项目由轮班工程师持续推进，但每个新来的人都不记得上一班做了什么——这就是长时程 agent 的核心挑战。

他们给出的两段式方案很像“工程管理 + 交接制度”：

一个 initializer agent 负责首轮搭环境/拆任务；一个 coding agent 每次会话都要做增量进展，并留下清晰的 artifacts 给下一次会话续航。这里的关键不是“多智能体很酷”，而是把“可持续推进”拆成可工程化的角色与产物。

同一时期，社区里也在野蛮生长另一种“极简 harness”——Ralph Wiggum Loop。Geoffrey Huntley 在 2025 年 7 月把 Ralph 描述为一种技术：本质上就是 bash 无限循环反复喂同一份 PROMPT.md，让 agent 在一次次干净上下文里继续干，直到做完。它粗糙、甚至“确定性地糟糕”，但恰恰因为简单，成为大量工程师验证“循环 + 外部反馈能逼出成果”的民间范式。

这一幕的决策逻辑很一致：当你发现模型在长对话里变笨、在长任务里偷懒，你有两条路——

要么寄希望于模型记得所有细节；要么承认它会衰退，然后把“衰退”当作系统缺陷，用重置、分段、artifact、循环、验证门来对抗。Anthropic 在后续的 harness 设计文章里甚至把 Sonnet 4.5 的“context anxiety（上下文焦虑）”当作要被 harness 结构性解决的问题：需要通过 context resets 与跨会话交接机制让模型保持在轨。

第五幕：术语诞生与 2026 年的“工程范式成年礼”

终于，到了 2026 年 2 月，Mitchell Hashimoto 在《My AI Adoption Journey》里把他一路从“别用聊天框写代码”走到“工程化驾驭系统”的经验写成 6 个阶段，并在 Step 5 明确提出：“我不知道行业是否已经有广泛接受的术语，但我开始称之为 harness engineering。”他把它定义为：当你发现 agent 犯错时，你要花时间工程化一个解决方案，让它以后不再犯同类错误。并且他非常具体地区分了两类改进：轻量的 implicit prompting（例如更新 AGENTS.md），以及更硬的 programmed tools（脚本、验证工具等）。

这个定义的爆炸性在于：它把 AI 代理的“可用性”从一次性调参，变成了持续工程活动——像修 CI、加 lint、补测试那样，每一次故障都沉淀为制度与工具。

仅仅六天后，OpenAI 在 2026 年 2 月 11 日发布《Harness engineering: leveraging Codex in an agent-first world》，几乎像在给这个术语写“企业级白皮书”：他们用 Codex 做了一个极端实验——构建并交付一个有内部日活用户与外部 alpha 测试者的软件产品，并刻意设定“0 行人工手写代码”的约束；他们估计以约十分之一的时间完成了约百万行规模的代码库。

更重要的是，OpenAI 把工程师角色的变化说得非常直接：当团队的主要工作不再是写代码，而是设计环境、表达意图、构建反馈回路以让 agent 可靠工作时，真正困难的问题变成了“环境、反馈回路与控制系统”。这句话几乎宣告：Harness Engineering 不只是个人技巧，而是组织工程学的新中心。

紧随其后，Thoughtworks 的 Birgitta Böckeler 在 2026 年 4 月 2 日发布《Harness engineering for coding agent users》，尝试把“harness”在“使用编码代理”这个边界内进一步结构化成可操作的心智模型：用 feedforward（指南）与 feedback（传感器）形成 steering loop（转向循环），再区分 computational（确定性、快）与 inferential（推断性、慢且不确定）两类控制，并提出 maintainability / architecture fitness / behaviour 三种“治理维度”。这一套话语把 Harness Engineering 从“术语”推向“工程理论”：它开始像测试体系、架构治理一样可以被讨论、被模板化、被组织化。

LangChain 则在 2026 年 2 月 17 日用更“工程结果导向”的方式证明 harness 的威力：他们的 coding agent 在 Terminal Bench 2.0 上从 Top 30 提升到 Top 5，模型不变，只改 harness，并把方法论沉淀为“trace 分析 → 归因失败模式 → 改系统提示、工具、中间件”的闭环。同年 3 月 10 日，LangChain 又发布《The Anatomy of an Agent Harness》，试图给 harness 下定义并拆出典型组件：系统提示、工具/技能/MCP、文件系统/沙箱/浏览器等基础设施、编排逻辑、以及用于压缩、延续、lint 等确定性 hooks。

到这里，Harness Engineering 的“成年礼”基本完成：它有了提出者（Hashimoto）、有了旗帜型案例（OpenAI Codex 实验）、有了理论化框架（Thoughtworks）、有了可量化的工程实证（LangChain），并开始出现生态标准化的组织承载（AAIF）。

待续。