这几个月，AI编程工具的热闹程度有点夸张。新模型一波接一波：GPT、Claude、Gemini、Grok都在刷存在感。

大家最容易盯着一个问题：到底哪个模型写代码更强？

这个问题当然重要，但最近有个公开案例很有意思。同样是写代码的任务，换了个工具格式，成功率从6.7%涨到68.3%，差了十倍。单纯等下一轮模型升级，很难指望一个环节自己涨出这种幅度。

也就是说，问题不一定出在脑子上面，也可能出在脑子里面的工具、流程和反馈系统上。

这篇想讲的就是这个判断：AI编程Agent真正拉开差距的地方，不只在模型，还在Harness。

一、先把Harness放到一个简单公式里

现在很多人会用一个公式理解Agent：

Agent = Model + Harness

Model是大模型本身，负责理解、推理、生成方案。Harness是模型外面的那套装备，比如系统提示词、工具定义、编辑格式、上下文管理、错误处理、重试逻辑、安全边界和反馈机制。

如果打个比方，模型像发动机，Harness像方向盘、刹车、仪表盘和安全带。发动机再强，如果车身控制系统很差，最后也跑不稳。

Martin Fowler最近也专门写过Harness Engineering。他把Harness拆成两类：Guides和Sensors。

Guides是前馈控制。它在Agent动手之前告诉它怎么做，比如代码规范、任务边界、工具说明、目录规则。

Sensors是反馈控制。它在Agent做完之后告诉它哪里不对，比如测试失败、lint报错、截图异常、运行日志、人工反馈。

只有Guides，没有Sensors，规则不知道有没有生效。只有Sensors，没有Guides，Agent会一遍遍撞墙再改。

二、为什么一个编辑格式能让成功率翻十倍

Can Bölük是游戏安全出身的开发者，他做的实验最能说明Harness的价值。他做的一个终端编程Agent实验，重点不是再造一个模型，而是把Agent的工作环境打磨到足够稳。

AI写代码时，有一个环节特别容易出错：读文件、理解问题、生成修改，最后把修改写回文件。

很多时候，模型已经知道怎么改，真正卡住的是改动落盘这一步。文件在读取之后变了、上下文里少了几行、缩进没复现好、替换片段不唯一，都可能让一次看似正确的修改失败。

写回文件看起来简单，其实很难。不同工具的方案差别很大。

Codex的apply_patch是一种自定义diff格式，适合Codex自己，但其他模型未必理解。Claude Code的str_replace要求模型复现要替换的文本。空格、缩进、换行只要对不上，就可能失败。Cursor的方案是用神经网络合并，短文件可以直接重写，长文件则需要更复杂的合并能力。

Can的解法叫hashline。它给每一行代码加一个很短的内容哈希。模型要改哪一行，不用完整复述那一行，只要引用对应标签。如果文件已经被别人改过，哈希对不上，这次编辑就会被拒绝。

关键变化就是这一步：把编辑工具的格式从str_replace换成hashline，模型没换，Grok Code Fast 1的成功率却从6.7%提到了68.3%。

这个设计很朴素，但效果很猛。16个模型、3种编辑格式、每种540个任务里，hashline基本都能追平或超过str_replace。弱模型提升最大，Grok 4 Fast的输出token还下降了61%。

这就是Harness的意义。它的作用不是提高模型智商，而是把任务改造成更适合模型完成的形态。

这也解释了为什么单纯比较模型榜单会漏掉很多东西。同一个模型，放在不同编辑工具、不同上下文压缩方式、不同失败恢复机制里，表现可能完全不一样。

三、这东西对日常使用到底有什么用

把Harness说得太工程化，容易让人觉得离自己很远。其实换个说法，它就是给AI准备一个更好用的工作台。

很多人用AI时，习惯每次重新开聊：把需求说一遍，把背景说一遍，发现答偏了再补一句，格式不对再补一句。这样当然能用，但很累，也很不稳定。

Harness的思路是：别把所有压力都放在一句prompt上，而是把常用的背景、规则、工具、检查步骤提前摆好。

Guides像说明书。比如你希望它按什么语气写、参考哪些材料、不要碰哪些边界、输出什么格式，这些都属于Guides。

Sensors像检查表。比如写完之后检查事实有没有漏、表格字段齐不齐、代码能不能跑、结论和材料是否对应，这些都属于Sensors。

这样做的好处很直接：第一次不用把话说得像法律合同，第二次不用从零开始解释，第三次出了错也更容易知道错在哪里。

也就是说，Harness不是只给大公司做Agent用的。只要你希望AI稳定帮你完成一类事情，而不是每次碰运气，它就有用。

四、几个最容易用上的场景

第一个场景是写作和整理材料。

不要只说帮我写一篇文章，而是给它三样东西：要写给谁看、手里有哪些材料、最后要检查什么。比如标题不能太硬、案例不能丢、结尾要落到一个判断，这些都可以变成固定规则。

第二个场景是读报告、读文档、读网页。

可以先让AI按固定表格提取信息：核心观点、关键数据、适用条件、可能争议、能不能直接采用。它读完之后，再让它反查一遍有没有把不确定的话说成确定。

第三个场景是做表格和数据分析。

很多时候模型会算，问题出在字段理解错了、口径混了、单位没对齐。Harness可以把字段解释、计算口径、异常值检查提前写清楚。

第四个场景是写代码或做自动化。

可以要求AI先说明会改哪些文件再动手，改完之后跑测试或给出自查清单，涉及删除、发消息、改配置这类动作时先停下来确认。

第五个场景是做一个反复使用的小助手。

比如每周整理会议纪要、把客户反馈归类、把产品需求改成任务清单。真正省时间的地方，是让它每次都按同一套流程交付，而不是偶尔答得漂亮。

这些场景背后其实是同一件事：把任务拆成输入材料、处理规则、可用工具、输出格式、检查方式。这五块越清楚，AI越不容易跑偏。

所以，与其一上来就追问哪个模型最强，不如先问一个更实际的问题：我能不能把这件事变成一套可复用流程？

五、官方也在把Harness做成基础设施

开源社区在做Harness，Anthropic也在做。他们最近推出的Claude Managed Agents，说到底就是托管式Harness。

它把一个Agent拆成几个概念：Agent、Environment、Session、Events。

Agent是模型加系统提示、工具、MCP和Skills。Environment是预配置云容器。Session是正在运行的任务实例。Events是应用和Agent之间的消息流。

这个抽象很重要。以前我们常把Agent看成是一个模型加一堆工具。但真要跑起来，还需要容器、网络权限、事件流、恢复机制、凭证隔离和审计记录。Managed Agents想做的，就是把这些脏活累活变成基础设施。

Anthropic工程团队还提到一个现实问题：Harness里写下的很多假设，会随着模型升级而过时。某个模型在上下文接近上限时会急着收工，于是你给它加重置机制。下一个模型不这样了，这个机制反而可能碍事。

这里最关键的设计，是把Brain、Hands、Session拆开。

Brain是Claude和Harness循环，负责思考和调度。Hands是沙箱容器和工具执行，负责真正动手。Session是事件日志和记忆，负责恢复上下文。

拆开之后，每一层都可以单独失败、单独恢复。容器挂了，Harness可以把它看成一次工具失败，让模型决定是否重试。Harness挂了，新Harness可以读Session事件，从上一次状态继续。

这还带来性能收益。因为不必每次都等容器重新启动，首token延迟可以明显下降。安全边界也更干净：代码在沙箱里跑，凭证不直接进入沙箱，OAuth token通过独立代理处理。

从这个角度看，Managed Agents不是简单替你调用Claude。它更像一个meta-harness：底层负责运行环境、会话和安全，上层可以承载不同的具体Harness。Claude Code可以是一种，某个垂直任务Agent也可以是一种。

这个方向和开源项目并不冲突。开源项目更灵活，可以疯狂试工具、试编辑格式、试多模型协作。托管方案更稳定，适合团队快速起步、少操心基础设施。两边的目标其实一样：让Agent更稳定地完成真实任务。

六、最后

模型决定Agent能不能做，Harness决定Agent能不能稳定做完。

这也是2026年AI编程Agent最值得看的地方。模型还会继续变强，但真正能把Agent放进日常开发流程里的，往往是那些看起来不那么性感的东西：工具协议、编辑格式、状态管理、反馈回路、安全隔离和恢复机制。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13689