2026 年一季度过后，一个几乎所有 AI 编程工具厂商都在默默加码的词是 Harness（字面意思「马具、挽具」）。它不是某个开源项目的名字，也不是一种新模型。它指的是一件更朴素、却更难做好的事情：把语言模型接进真实工程环境时，中间那一层胶水与安全护栏。
Anthropic 工程博客在 3 月发表的《Scaling Managed Agents》里说得很直接：「Agent Harness 就是模型与真实世界之间的一切。模型负责生成文本，Harness 负责决定这段文本能碰到什么。」这一年，让 Claude Code、Cursor、Cline、Aider 拉开差距的不是底层模型——他们共用同一批 Claude 4.6 / GPT 级别的模型权重——而是 Harness 的设计哲学。本文试图把「Harness 到底是什么、为什么重要、不同代表作品如何做选择」讲清楚。
一、什么是 Agent Harness
先把概念放回工程语境。一个能做事的 AI 代理，通常由三样东西构成：
- Session：一份只追加（append-only）的日志，记录从用户提问到每一次工具调用的完整历史。它既是模型下一次推理的上下文，也是事后审计的依据。
- Harness：一个循环——
call model → parse tool calls → route to tools → feed results back。Harness 决定模型「说」的话里，哪些是要真正执行的副作用，哪些只是对用户的解释。 - Sandbox：一个受控的执行环境。模型请求「运行
rm -rf node_modules」时，这句话先落进沙箱，再决定是否落到真实磁盘。
过去大家关注的是第一项和第三项——上下文工程和沙箱安全。2026 年的共识是，第二项才是差异化的真正战场。Harness 决定了三件事：
- 自主性的边界：哪些操作可以直接执行、哪些必须让用户点「同意」。
- 反馈回路的形状：每一次失败、每一次 lint 报错、每一次测试通过，如何被采集并喂回模型。
- 错误恢复的策略：模型选错方向时，是回滚、是反思、还是继续往前跑。
这三件事，没有任何一项是「更强的模型」能自动解决的。
二、三种代表性 Harness：执行层、编辑器层、审批层
Claude Code：执行层的极致自主
Claude Code 的哲学可以用一句话概括：把 AI 当成一个你真的可以转身走开的执行者。2026 年 3 月引入的 Auto Mode 把这个方向推到了新高度——一个跑在 Sonnet 4.6 上的后台分类器会实时评估每一次工具调用，判断是否可以跳过人类审批。
值得玩味的是架构上的一个细节：分类器看不到模型写给用户的那段解释文本。它只看得到用户的原始请求和模型即将调用的工具参数。这是一个有意识的设计选择——防止模型通过「甜言蜜语」把审批闸门绕过去。用 Anthropic 工程师的话说，这避免了「模型对 Harness 做 prompt injection」。
Claude Code 还是一个把「Session 作为一等公民」的典型。你可以暂停、恢复、fork、compact 一个会话，也可以通过 --resume 让另一台机器接着跑。Session 可序列化，意味着 Harness 具备一个常被忽视的能力：把一个跑了 40 分钟、包含 200 次工具调用的上下文，无损带到另一台机器上继续。这是把 AI 从「聊天助手」变成「远程工程师」的前提。
Cursor：编辑器层的速度感
Cursor 选择的是另一条路。它把 Harness 绑在编辑器里——你始终在文件上看到 diff、能一键撤销、能在 AI 还没写完时就打断它。Cursor 的 Cloud Agents 2026 架构文档里有一个反直觉的说法：「Harness Is the Product」（Harness 本身才是产品）——但它指的 Harness 是为了保留人类在闭环中的低摩擦感而设计的，而不是为了让 AI 独立跑完一个任务。
对比一下就很清楚：Claude Code 是「你出门买咖啡回来再看结果」，Cursor 是「你坐在键盘前，AI 帮你打字，但光标权永远在你手里」。同一批模型，两种完全不同的 Harness，产出两种完全不同的工作流。
Cline：逐步审批的极端保守
第三种代表是 Cline——一个 VS Code 插件形态的开源项目。它把 Harness 的旋钮拧到了最保守的一端：每一次文件改动都必须得到用户显式同意。这看起来效率低下，但 Cline 拥有一批死忠用户，他们普遍在两类场景里：
- 接触生产数据库、Kubernetes 集群等操作代价极高的环境；
- 处于和 AI 建立信任的早期阶段，希望通过「逐步看它犯错」来校准提示词。
Cline 的存在告诉我们一件事：Harness 的自主性不是越高越好，而是一个和具体任务、具体用户信任度耦合的参数。
三、Harness 工程师：一个正在成型的新岗位
「Harness Engineering」在 2026 年初开始被当成一个独立职位挂出来招聘。它和传统的 ML Engineer、Platform Engineer 都不完全重合。一个典型的 Harness 工程师，日常关心的问题大概是这些：
- 如何设计工具的
description字段，让模型更可能在正确的时机调用它？ - 当模型一次请求了 10 个工具调用，应该串行执行、并行执行，还是按依赖图排序？
- 工具的输出应该原样喂回模型，还是先做一层摘要（compacting）？摘要本身是不是会丢失关键信号？
- 一次失败的
npm run test是应该立刻终止任务，还是作为一个「信号」让模型自己决定下一步？ - 用户同一句「继续」在两种不同的 Harness 里，可能导致完全不同的语义——这是 bug 还是 feature？
这些问题没有一条能靠「换个更大的模型」解决。它们介于认知科学、人机交互、分布式系统三者之间——也因此，Harness 工程师正在成为 AI 产品团队里议价能力最高的角色之一。
四、给开发者的三条实用建议
如果你正在自己的项目里集成 AI 代理，不管是用 Claude Agent SDK、LangGraph 还是裸 API，下面这三条观察都值得放在心上：
1. 先定义「人类决策点」，再定义「工具列表」。 很多团队一上来就列出「我要给 AI 哪些工具」，但更关键的问题是「哪些动作必须停下来问人」。这是 Harness 的骨架。把骨架立错了，之后加再多工具都是补丁。
2. 反馈比自主性更重要。 一个「什么都能做」但收不到失败信号的 Agent，远比一个「什么都要问」但能精确看到测试结果、lint 报错、git diff 的 Agent 糟糕。Harness 的核心价值是让模型的每一步都能闭环地看到后果。
3. Session 序列化是 Harness 的分水岭。 能否把一个跑到一半的会话无损搬走，决定了你构建的是「玩具」还是「生产工具」。这一条最容易被低估，但也最能区分业余和专业的 Harness 实现。
总结
2026 年的 AI 编程代理赛道告诉我们一件事：同一台引擎可以装进跑车、也可以装进卡车，决定体验的是底盘和变速箱，不是引擎本身。Agent Harness 正是 AI 代理的底盘与变速箱——一层薄薄的胶水代码，却决定了你能不能真的把一台 LLM 变成一个可以转身托付的工程师。
下一次你对比两个 AI 编程工具、发现它们「明明用的是同一个模型」却体验差别巨大时，答案几乎总是藏在 Harness 这一层里。
评论