2026 年，AI 产业出现一个新共识：决定AI 产品好坏的，不再是模型本身，而是模型外面那层叫做「harness」的东西。当Claude Code、Cursor、OpenClaw 使用的底层模型越来越接近时，真正拉开产品差距的，是harness 的设计。 Martin Fowler 的技术部落格、Anthropic 产品负责人trq212、以及Andrej Karpathy 的近期发言，都指向同一个方向：AI 的下一个战场是Harness Engineering。
什么是Agent Harness
一个AI agent 可以拆成两部分：模型（Model）和Harness。模型是大脑，负责理解语言和推理。 Harness 是模型以外的一切— 工具呼叫、记忆管理、上下文组装、状态持久化、错误处理、安全护栏、任务排程、生命周期管理。
用一个直观的比喻：LLM 是一匹马，harness 是马具— 缰绳、马鞍、与马车的连接结构。没有马具，马再强壮也拉不动车。 AI agent 也一样，模型再聪明，没有好的harness 就无法可靠地完成实际任务。
Akshay Pachaar 在一则广为流传的推文中提出了另一个比喻：「裸LLM 就像没有作业系统的CPU — 它能计算，但靠自己做不了任何有用的事。」Harness 就是那个作业系统。
为什么2026 年Harness Engineering 突然变重要
原因有三：
第一，模型能力趋于同质化。 GPT-5.4、Claude Opus 4.6、Gemini 3.1 Pro 在多数基准测试上的差距已经缩小到个位数百分点。当模型不再是瓶颈，产品差异化自然转移到harness 层。
第二，agent 从实验进入生产。 2025 年的agent 大多是demo，2026 年的agent 要跑在企业环境里— 需要处理中断恢复、长时间运行、多步骤任务、权限控制。这些全是harness 的工作。
第三，LLM 天生无状态。每次新的session 都从零开始，模型不记得上一次对话。 Harness 负责把记忆、上下文、工作进度持久化，让agent 能像一个真正的「同事」一样持续工作。
Harness 的核心组件
一个完整的agent harness 通常包含以下几层：
| 组件 | 功能 | 类比 |
|---|---|---|
| Orchestration Loop | 控制agent 的「思考→ 行动→ 观察」循环 | 作业系统的主循环 |
| Tool Management | 管理agent 可以使用的工具（档案读写、API 呼叫、浏览器操作等） | 驱动程式 |
| Context Engineering | 决定每次呼叫模型时送入哪些资讯、裁切哪些资讯 | 记忆体管理 |
| State Persistence | 保存工作进度、对话历史、中间结果 | 硬盘 |
| Error Recovery | 侦测失败并自动重试或回退 | 例外处理 |
| Safety Guardrails | 限制agent 的行为范围，防止危险操作 | 防火墙 |
| Verification Loops | 让agent 自我检查输出品质 | 单元测试 |
三层工程学：Prompt、Context、Harness
围绕LLM 的工程实践可以分为三个同心圆层次：
最内层是Prompt Engineering — 设计送给模型的指令，决定模型「怎么想」。这是2023 年的主流技能。
中间层是Context Engineering — 管理模型「看到什么」。决定哪些资讯在什么时机送入context window，哪些该裁切。随着context window 扩大到百万token，这层的重要性在2025 年开始浮现。
最外层是Harness Engineering — 涵盖前两者，再加上整个应用基础设施：工具编排、状态持久化、错误恢复、验证循环、安全机制、生命周期管理。这是2026 年的核心战场。
实例：为什么同一个模型在不同产品里表现天差地远
Claude Opus 4.6 在Claude Code里可以花一小时重构整个程式码库。但把同一个模型透过API 接上一个简陋的harness，它可能连跨档案的bug 修复都做不好。差别不在模型，在harness。
Claude Code 的harness 做了什么？
- 自动搜寻整个程式码库找到相关档案，而非要求用户一一指定
- 在修改前先读取档案内容，修改后执行测试验证
- 遇到测试失败会自动分析错误并重试
- 透过MCP连接外部工具（GitHub、资料库等）
- 记忆系统跨session 保存使用者偏好与专案脉络
- Advisor 策略让不同能力的模型分工合作
这些全是harness 的功劳。
Feedforward 与Feedback：Harness 的两大控制模式
根据Martin Fowler 技术部落格的分析，harness 的控制机制分为两类：
Feedforward（前馈控制）— 在agent 行动前就设好规则，预防不想要的输出。例如：system prompt 中的行为准则、工具白名单、档案存取权限。
Feedback（回馈控制）— 在agent 行动后检查结果，允许自我修正。例如：执行测试确认程式码正确、比对输出与预期格式、侦测幻觉并重新生成。
好的harness 同时使用两种控制，既限制行为范围又保留灵活性。
Harness Engineering 的产品化：Anthropic 怎么做
Anthropic 在2026 年4 月密集推出的产品更新，几乎都是harness engineering 的产品化：
- Managed Agents — 把harness 的基础设施（沙箱、排程、状态管理）做成托管服务，开发者只需定义agent 行为
- Advisor 策略— harness 层级的模型混用架构，自动判断何时该咨询更强的模型
- Cowork 企业版— 为非技术用户提供完整的harness（权限控制、支出管理、使用分析），让他们不需要理解底层技术
Anthropic 产品负责人trq212 的表述最为精准：「Prompting 是跟agent 对话的技能，但它是被harness 所中介的。我的核心目标是增大人类与agent 之间的频宽。」
对开发者的意义：新职业与新技能
Harness Engineering 正在成为一个独立的工程领域。它需要的技能组合跟传统后端工程或ML 工程都不同：
- 理解LLM 的能力边界与失败模式
- 设计可靠的工具呼叫与错误处理流程
- 管理context window — 什么时候塞入什么资讯
- 建构可观测性— 追踪agent 的决策路径与工具使用
- 安全设计— 限制agent 的行为范围而不扼杀其能力
对于正在学习Vibe Coding或使用AI 工具开发的人来说，理解harness 的概念将帮助你更有效地与AI agent 协作— 因为你会知道问题出在模型还是harness，以及如何透过调整harness 设定（而非反复改prompt）来改善结果。
结语：下一个十年的基础设施之争
AI 模型的竞争不会停止，但边际收益正在递减。 Harness 层的竞争才刚开始— 谁能建构最可靠、最灵活、最安全的harness，谁就能把同样的模型能力转化为更好的产品体验。
这也解释了为什么Anthropic、OpenAI、Google 都在从「模型公司」转型为「平台公司」— 他们卖的不再只是模型API，而是完整的harness 基础设施。对开发者而言，理解harness engineering 不是可选项，而是在AI 时代建构产品的核心素养。
本文链接地址：https://www.wwsww.cn/rgzn/38156.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
