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 时代建构产品的核心素养。
这篇文章 Harness Engineering 是什么？AI 的下一 个战场不是模型，而是模型外面的那层架构 最早出現於 鏈新聞 ABMedia。
相关文章
