AI杂谈：当我们在谈论Harness时，我们在谈论什么？

一、默认不信任：从“相信它”到“约束它”

很多人在和 AI 互动时，都会不自觉地信它一点。你问一个问题，它给出一个很流畅、很自信的回答，你很容易就接受了。这个习惯可能和搜索引擎时代有关：你搜东西，它给链接，你默认那些链接大体上指向了正确的信息。后来 ChatGPT 不给链接了，直接把答案端到你面前，而且语气更稳、更像那么回事。人的大脑很容易被这种“自信”骗过去，把它误当成“可靠”。

但工程系统不能这么做。工程系统的出发点通常更悲观一点：零件会坏，输入会脏，网络会抖，最不该出错的地方迟早也会出错。桥梁设计时不能只考虑“天气好、车流正常、所有螺栓都没问题”的情况，还要追问：如果某个关键部件真的失效了，整座桥能不能别一下子塌掉。

把这个思路放到 AI 系统里，就是 Harness 的第一条原则：默认不信任模型。这里的“不信任”没有敌意，也不等于觉得模型没用；它只是把模型当成一个高性能但会出问题的部件来处理。既然它可能犯错，就要提前给它套上不会自动脱落的约束。

Claude Code 的设计就是一个很好的例子。它的出发点很清楚：模型在这里更接近一个必须在受控环境里运行的程序，不能被当成天然拥有权限的“用户”。它要运行代码，可以，但要放在沙箱里，跑完沙箱就销毁。它要调用工具，可以，但要先过权限检查，不能因为它说“我觉得应该这样”就直接执行。它要花钱，也可以，但每个任务都有预算上限，超过了就切断，不和模型商量。

这里有个细节我觉得很值得注意：权限判断不要只做成简单的“允许/拒绝”。人在做安全决策时，经常需要中间状态。有时候是“可以，但就这一次”；有时候是“等一下，我先看一眼”；有时候是“这个操作本身没问题，但现在这个上下文不对”。所以一个成熟的权限系统，最好明确留出第三种状态：询问。

这看起来像是一个 UI 或交互细节，但它背后其实是在重新定义 Agent 的位置。模型可以理解你的意图，可以提出下一步建议，也可以准备好操作方案。但最后到底要不要做，不能只由模型自己决定。运行时系统、规则和用户都应该参与这个判断。理解你的意图，不等于自动拥有你的授权，更不等于拥有持续授权。

这更像是给 Agent 上保险。你信任你的车，但你还是会系安全带。

二、用结构来维持秩序

我们有一个很自然的反应：AI 表现不好，就换一个更聪明的模型。这个想法没错，有时候也确实有效。但 Harness 提醒我们，还有另一条路：不换模型，先换系统。

这需要一点观念上的转弯。它意味着我们要承认，一个系统里即使有很聪明的部件，如果整体结构很乱，结果也可能很差；反过来，一个模型没那么完美，但外部结构设计得好，系统反而可以跑得更稳。

结构不像模型能力那么显眼。一个精心设计的错误恢复路径，大多数时候都是看不见的。它不会在发布会上被演示，也不会让人一眼觉得“哇，好智能”。它只是安静地待在那里，等那个一万次请求才会出现一次的极端情况。可如果它不在，那一次就可能把人半夜从床上拽起来。

Claude Code 的设计者在一篇文档里写过一句话，大意是：一个会道歉的系统，不一定成熟；一个知道什么时候不该开始、什么时候该重试、什么时候该中止、什么时候该准确汇报失败的系统，才更接近成熟。

我很喜欢这句话，因为它说出了 AI 助手从“聊天产品”走向“工程系统”时最关键的变化。早期 AI 助手常见的模式是：错了就道歉，然后马上给出另一个答案。这个答案可能还是错的，但它看起来很努力。它像一个过分热心的实习生，总想用更多输出弥补错误，结果有时反而把事情搞得更乱。

成熟的 Harness 关心的重点，会从“怎样显得更努力”转向“怎样让系统更安全”。有时候，最好的动作就是什么都不做。有时候，正确的做法是直接承认失败，把失败状态清楚地交给人，不要编一个看起来完整、其实没验证过的结果糊过去。

这种克制不太讨喜，但很重要。我们总是容易奖励“更多”：更多功能，更多自动化，更多自主性。但 Harness 的方向经常是反过来的：更少的工具，更严格的约束，更明确的边界。这更像是从“能演示”走向“能长期运行”。

三、错误是主路径

传统软件开发里有个很常见的习惯：先把正常路径写通，错误处理以后再补。很多项目一开始都是这么起来的，先有 happy path，再慢慢补边角料。在普通软件里，这么做已经会留下不少坑；到了 AI Agent 系统里，这个习惯的代价会更高。

一个会自主执行代码的 Agent，和普通按钮后面的函数不一样。它的“正常路径”随时可能拐进异常路径。模型输出可能太长，API 可能抖一下，工具可能返回奇怪结果，上下文窗口可能在你最需要它的时候满掉。如果设计时把这些情况都当成很少发生的边缘问题，系统就像一座只计算了晴天承重的桥。

所以 Harness 设计里一个很明显的特征，就是把错误处理放到和业务逻辑同等重要的位置。错误已经是系统日常的一部分，不能再只按意外处理。这听起来有点悲观，但做过真实用户系统的人都知道：只要某个错误有可能发生，它迟早会发生，而且往往发生在你最不希望它发生的时候。

Claude Code 对 “prompt too long” 的处理就很典型。对长会话 Agent 来说，提示词过长并不罕见，更像是季节性天气。你知道它一定会来，所以不能等它来了再手忙脚乱。系统会先尝试最轻的清理方式，如果不够，再尝试更重的压缩；还不行，就触发熔断保护。它甚至还要考虑一种更烦人的情况：如果负责压缩的工具自己也失败了，系统该怎么办。

这里有个细节特别现实。模型输出因为达到最大 token 限制被截断时，很多系统会让模型先补一句很客气的话：“抱歉，我刚才被截断了，让我总结一下……”听起来很礼貌，但对任务推进没什么帮助，还会继续浪费本来就紧张的上下文和 token。

Harness 的做法更直接：给模型追加一条指令，让它不要道歉、不要回顾，直接接着干。如果被截断的是半个词，就从半个词继续写；如果任务太大，就拆小一点继续做。

这听起来有点粗暴，其实更尊重用户时间。工程系统真正的礼貌，是尽快把用户从失败状态里带出来。漂亮的抱歉，排在很后面。

四、精心控制上下文

AI Agent 最常见的失败模式之一，是长任务做到一半突然变得像喝醉了一样。它开始忘记前面做过什么，做出互相矛盾的决定，或者在最关键的一步突然换策略。有时候它还会出现一种很奇怪的“上下文焦虑”：感觉窗口快满了，就开始草草收尾，跳过本来应该做的验证。

我们很容易以为，上下文窗口越大越好。既然模型能读很多东西，那就把所有相关信息都塞进去，让它自己判断哪些重要。这个想法听起来省事，但其实很危险。这就像说：我有一个图书馆，所以我不用整理桌面了，所有书都堆在桌上就行。

上下文窗口更接近一张很贵、而且会被慢慢污染的工作台，不像无限容量的图书馆。你堆的东西越多，模型越难找到真正关键的信息。更麻烦的是，早期留下来的错误判断如果一直待在上下文里，后面就可能被模型反复当成依据。它像一个坏掉的指南针，不一定每一步都带偏你，但迟早会把方向弄歪。

Harness 对这个问题的态度很明确：上下文是一笔需要认真管理的预算。它要分层、分类、设上限，还要定期清理。

把长期规则和临时对话混在一起，是一个很常见的错误。Claude Code 用多层记忆来处理这件事。CLAUDE.md 更像“宪法”和“地方法规”，记录项目里的基本约束；MEMORY.md 是索引，本身要短，指向更详细的知识条目；当前会话则有自己的会话记忆模板，像工程笔记一样记录任务目标、当前进度、踩过的坑和下一步计划，不会把整段聊天原封不动塞进去。

当任务真的很长，上下文窗口不可避免要满时，Harness 会启动压缩。但好的压缩不能只是让模型随便写一段“前情提要”。它要分清哪些东西是后续工作必须保留的：当前计划是什么，改过哪些文件，哪些方法已经试过但失败了，失败原因是什么。这些信息要留下来，成为继续工作的语义底座。那些只是过程性的寒暄、重复解释、无关分支，就应该清掉。

压缩的目标不该写成回忆录；它要重建一个能继续工作的现场。

这其实是一种新的资源管理。过去我们管理 CPU、内存、磁盘、网络，现在还要管理模型的注意力。Harness 要做的，就是当好注意力的守门人：在关键时刻，让模型看到它真正需要看的东西，别让一堆旧信息拖着它走。

五、给不确定性分区

还有一个很容易让人动心的想法：如果一个 Agent 不够靠谱，那多加几个 Agent 会不会更好？一个人容易犯错，一群人互相讨论、互相检查，会不会就更稳？

这个想法很有诱惑力。所以很多系统会设计复杂的多 Agent 编排：研究 Agent、实现 Agent、审查 Agent、规划 Agent，各有角色和工具，看起来像一支小型硅谷创业团队。

但问题是，如果没有边界，多 Agent 只是把混乱平行化了。十个不太靠谱的实习生关在一个房间里，不会自动变成一个靠谱团队。很多时候，他们只是互相制造噪音。

真正好的多 Agent 设计，核心是把不同类型的不确定性分开，“人多力量大”反而退到次要位置。研究 Agent 可以在自己的小环境里探索，它可能误判，也可能漏线索，但它的混乱被限制在“研究”阶段。实现 Agent 专注修改代码，它可能写错，但错误被限制在“实现”阶段。然后再让一个独立的质量保证 Agent 进来。它不负责想新点子，也不继续加功能；它专门挑刺，去挑战前面那些看起来已经成立的结论。

这里最重要的一点是：验证必须和实现拆开。

让实现者自己评判自己的工作，本来就很难。人会下意识维护自己的方案，模型也一样，而且有时候更会。它会写出看起来很正确的测试来验证自己刚生成的代码，会把“我写完了”当成“我做对了”，也会为了让结果看起来完整，轻轻带过那些没有真正验证通过的地方。

所以 Harness 会把验证明确切成一个独立阶段，最好由独立角色来做。这表面上会慢一点，但它是质量的最后防线。多 Agent 的真正价值，除了并行速度，更在于职责边界带来的可追责性。出了问题，你能看清是哪一段链路出了问题，不用面对一锅所有 Agent 一起熬出来的浑汤。

六、你的团队，也是一个Harness

更有意思的是，Harness 这个想法并不只停留在代码里。它也会慢慢改变团队的组织方式。

我看到一个叫 CREAO 的 AI 创业公司 CTO 写过一篇文章。他们团队只有25个人，其中10个工程师。三个月里，他们把传统软件工程流程几乎拆了一遍，围绕 AI 重新组织工作方式。结果很夸张：两周内部署的生产更新，比过去整个季度还多；一个想法从提出到线上 A/B 测试，最快可以在同一天完成；效果不好的功能，当天就能撤掉。

单纯“让大家都用上 Cursor”，做不到这一点。真正的变化在工作流里。他们从“工程师写代码”，切换到更像“架构师定义规范，AI 负责实施，运维人员审批”的模式。AI 不只写代码，还参与代码审查、安全扫描、错误分析和自动修复。每天早上，AI 会先跑健康检查，分析生产错误，把问题聚类，生成工单，甚至在修复部署后自动验证并关闭工单。

在这个过程中，人的角色也变了。那位 CTO 观察到两种角色变得越来越重要：架构师和运维人员。

架构师是少数人。他们的价值已经慢慢从敲代码的速度，转到判断力上。他们定义什么叫“好”，审查 AI 给出的方案，找出那些不容易被模型意识到的问题：微妙的业务逻辑漏洞、被忽略的安全边界、正在悄悄积累的技术债。AI 很擅长给出一个看起来完整的方案，架构师要做的是在它最自信的时候问一句：等等，这里会不会有问题？

这种能力正在变得比单纯输出代码更重要，也更稀缺。

而更多工程师的工作，则慢慢转向运维人员式的角色。AI 先诊断问题，准备修复方案，生成拉取请求，再交给人来验证、审查和批准。人未必还站在代码第一生产者的位置上，更像质量守门人。很有意思的是，这位 CTO 发现，初级工程师反而适应得最快，因为他们没有那么多旧习惯需要放下。

他把这个过程叫作：把个人技巧变成团队制度。

这句话很准确。过去，一个团队能走多远，很大程度上依赖那几个高手脑子里的隐性知识：他们临场怎么判断，怎么发现风险，什么时候该停，什么时候该重构。现在，这些原本靠个人经验维持的东西，被写出来、流程化、制度化，变成整个团队都能复用的 Harness。

从这个角度看，Harness 已经超出软件架构，带有一种组织哲学的味道。它不太相信英雄主义，更相信系统。它不把希望押在某个天才随时在线、永远清醒；它相信好的流程可以持续、稳定、可预期地产出不错的结果。一个组织真正变成熟，可能就是从“不再只能靠几个超级个体撑着”开始的。

七、Harness的冷酷与温情

Harness 有个很有意思的反差。它的设计起点经常是“不信任”和“悲观主义”，但最后带来的结果，反而有一种很实际的温情。

它替用户守住预算，不让你睡一觉起来收到几千美元的 API 账单。它守住流程，不让一个实习生在深夜被叫起来处理本来可以被系统拦住的事故。它把人从那种“必须一直盯着屏幕、随时准备救火”的工作里稍微解放出来。

它用一堆看起来很冷的东西——沙箱、预算、熔断、权限、校验——搭出一个相对安全的外壳。正因为这些规则够冷，人才可以更放心地把任务交出去。

它承认人会犯错，模型也会犯错，然后把“防止错误扩大”的责任，从每个人必须时刻紧绷这件事上，转移到系统本身。一个好的 Harness，会让你工作时稍微放松一点。你知道，就算你或者你的 Agent 某一步搞砸了，系统也不至于让第一张多米诺骨牌一路倒到底。

尾声：为那匹野马，造一辆好车

最后还是回到那个很朴素的比喻。模型是马，是引擎，是那个潜力很大、但也并不稳定的核心部件。Harness 是缰绳，是方向盘，也是整辆车的底盘。

当我们谈论 Harness 时，重点不在某一个工具，也不在某个新名词本身。真正值得谈的，是一整套制度化的约束系统：它把一个不稳定的概率机器，慢慢驯化成一个可管理、可预测、可以托付任务的工程系统。

它的原则其实都不神秘：默认不信任任何部件；用结构代替临场聪明来维持秩序；把错误当作常态，提前准备好处理方式；认真管理上下文这笔昂贵的注意力预算；给不同的不确定性划出边界；最后，把个人英雄主义沉淀成团队可复用的制度。

这些原则没有哪个特别新。它们更像软件工程几十年来反复验证过的老经验。只不过过去两年，我们太容易被那些聪明、流畅、能说会道的模型吸引，反而把这些老东西暂时放到了一边。

Harness Engineering 的兴起，可能标志着一个转向：我们正在从“模型中心观”走向“系统中心观”。问题也从“怎样让模型更聪明”，扩展到另一个更难、也更值得花时间的问题：

“在模型并不总是可靠的前提下，我们怎样设计出可靠的系统？”