碳基智2026年05月13日预计 5 分钟最近因为工作关系，我花了不少时间研究 AI 编程产品的架构设计，尤其是 Claude Code、Cursor、CodeBuddy 这类产品背后的 Harness Engineering。

        在看了大量技术博客、社区讨论、还有 Anthropic 团队在各种场合的分享之后，我发现一个问题：很多人对 Harness 最流行的那套理解，很可能是错的。

        1  在很多人的理解里，Harness 就是一个补丁，因为模型现在还不够好，所以需要在外面包一层东西来补它的缺陷。

        等模型足够强了，这层东西就会消失，大家又可以回到「直接把任务丢给模型」的简单世界。

        按这个逻辑，Harness 就是一种临时性的补丁，是从 AI 辅助写代码到 AI 独立工作这条路上的过渡态。

        这个理解非常符合大家对技术进步的直觉判断，缺陷被能力抹平，工具被智能取代，好像……没毛病？

        但它解释不了一个很具体的事实，而事实是证伪最好的依据。

        Claude 最新的模型比一年多前的 Sonnet 3.5 强了不止一个量级，无论是代码能力、推理深度还是指令跟随，都能给到一个夯。

        可你去看 Claude Code 这一年多的演进，你会发现：query loop 变复杂了，权限策略变细了，compact 机制从简单截断变成了带摘要的上下文换页，hook 系统从无到有，sub-agent 并行架构从单线程变成了多 worker 协作。

        不对啊，这不都是 Harness 的东西吗，它甚至在每一个维度上都变厚了。

        如果 Harness 只是能力补丁，模型变强应该让补丁变少才对。

        实际情况正好相反。2  Harness 到底在做什么？

        我举个更好理解的例子：想想你们公司管理新来实习生和管理一个总监的区别。

        实习生你基本不怎么管，给他派个活儿，他做完拿给你看就行了。

        为什么不管？因为他能干的事本来就少，权限有限，出不了大乱子。

        但一个总监呢？OKR 对齐、跨部门协调、定期汇报、预算审批、权限分级、下属管理……

        围绕他建立的管理机制比实习生复杂十倍。这是因为总监能力不行吗？

        恰恰相反，是因为他能调动的资源太多了、做的决策影响太大了、涉及的协作面太广了，所以需要更精密的协调和管控机制来确保他的能力被正确释放。

        Harness 和模型的关系，跟管理体系和员工的关系是同构的。

        模型越强，它能做的事越多、单次操作的影响越大、需要协调的上下文越复杂，围绕它建立的运行时机制就必须越精密。

        换个更底层的类比：CPU 和操作系统。Intel 8086 时代的 DOS 几乎没有进程管理、没有内存保护、没有权限隔离。

        现在 M4 Ultra 上跑的 macOS 有虚拟内存、有沙箱、有进程调度器、有精细到每个文件的权限系统。

        CPU 从 8086 进化到 M4 Ultra，操作系统从来没有因此变薄过。

        因为操作系统解决的问题是：一个强大但无状态、无边界的计算引擎，如何安全、可控地嵌入到一个有状态、有后果的真实世界中。

        Harness 就跟个操作系统一样。3  具体拆解下来，Harness 有四个职能，每一个都跟模型能力正相关而非负相关：上下文管理。

         模型有 context window 的物理限制，但更关键的是，即使窗口无限大，注意力也有信噪比。

        塞进去的信息越多，每一条信息被有效利用的概率越低。

        Claude Code 的 compact 机制就是在做虚拟内存——

        把当前不用的东西换出去、需要的时候换回来、中间做摘要保持连续性。

        模型越强、单次会话做的事越多，这套机制的压力就越大。

        权限边界。 一年前的模型大多数时候不敢也不会执行高危操作。

        现在的模型不但敢，而且真的能正确判断"该删的时候删"。

        恰恰因为它"能"了，围栏就得更精细。一个笨小孩拿剪刀你不太操心，一个身手灵活的成年人拿刀你得更关心他往哪挥。

        任务编排。 模型弱的时候，你给它的活是"改这个函数"。

        模型强了之后，你可以说"重构整个认证系统"。后者需要拆解成子任务、决定执行顺序、并行处理独立部分、在子任务间传递上下文、出了问题能回溯。

        这套调度逻辑只会随着任务规模的膨胀而变复杂。人机协议。

         模型越自主，人的焦虑越大——它在做什么？走偏了怎么办？

        怎么纠正方向？Task list、plan mode、审批机制、进度可视化，这些不是"模型不行才需要的辅助轮"，是信任基础设施。

        你把一个天才员工放到高度自主的岗位上，反而需要更清晰的汇报制度和决策边界，不是更少。

        四个职能里没有任何一个会因为模型变强而趋向消失，它们全部是正相关！

        模型能力越强，对这四层基础设施的需求越大。现在你告诉我，Harness 怎么可能随着模型能力的增长被填平？

        Tell me！4  写到这里，可能有人要搬出 Claude Code 的创造者 Boris 在红杉 AI 大会上的发言来杠我了。

        他说：随着模型能力增强，产品层的重要性会下降，很多原来由产品层做的事模型会自己完成。

        他还具体点了名，比如防 prompt 注入、命令静态校验、权限模式、人工审批，这些都是模型能力不足时的补丁，模型够强就会退出。

        理解起来，好像确实是在说 Harness 会消失啊？

        但你再看下他后面提到的 Claude Code 正在推进的工作呢？

        让 loop 成为一等功能、大规模并行 Agent 管理、Claude Design、computer use 持续进化……

        这些东西，不还是 Harness 的范畴吗？防 prompt 注入、静态校验、人工审批，这些东西存在的原因是「我不信任模型的判断，所以在外面加一道校验」。

        这是防御性 Harness，它确实是补丁，模型判断力够了，它确实可以跪安。

        但 loop 一等化、并行 agent 编排、computer use，这些东西存在的原因是「模型已经够强了，我需要更复杂的运行时来释放它的能力」。

        这是使能性 Harness（原谅我实在不想用赋能这个词），它是基础设施，只会随着模型能力的增长而增长。

        5  所以，我觉得，更合理的理解是，Harness 压根就不是补丁，它也不可能随着模型能力的增强被填平，反而会成为模型之外一个十分重要的，像操作系统一样的东西。

        我个人判断，Harness Engineering 会成为一个独立的、越来越重要的工程学科。

        操作系统工程从来不会因为 CPU 变强而消失，反而随着硬件能力解锁而变得更复杂、更精妙。

        这也是为什么 Anthropic 花巨大精力做 Claude Code 的 harness，而不是只堆模型参数。