如果你最近密集地使用过 Claude Code、Codex 或者任何一个主流 coding agent，大概率会有一种强烈的感受：这东西是真的能干活。它自己读代码、自己找 bug、自己跑测试、自己修复、自己总结，整个过程连贯到让你产生一种直觉——这不是自动化，这是“它真的在工作”。
这种感受是真实的。但我越来越觉得，大家从这种感受里得出的结论，可能有一个关键的偏差。
多数人的归因是：模型越来越像人了，越来越自主了，所以它能接管越来越复杂的工作。这个叙事非常顺滑，也非常符合直觉。但如果你仔细拆解那些成功案例的结构，会发现真正起作用的往往是另一套东西——任务被提前裁剪过、工作环境足够干净、skill 里注入了大量领域先验、人类做了充分的前置约束。
我不觉得这是一个纯粹的学术讨论。如果我们能从 coding agent 的成功里把真正起作用的因素拆出来，这些东西应该是可以迁移的——迁移到你手上任何一个想用 agent 解决的场景里。
两股力，一个交汇区
先从一个更大的图景说起。
Agent 能稳定工作的空间，其实是被两股力从两个方向同时挤出来的。
一股力是自上而下的：人把混沌的业务重写成结构化协议——定义 SOP、设计 skill、治理工具接口、建反馈闭环。方向是把世界变得对机器可读。
另一股力是自下而上的：模型通过训练和能力提升，吸收那些原本无法被规范化的部分——模糊的用户意图、不标准的输入格式、文档里的隐性知识、异常场景里需要语义判断的灰色地带。以前这些地方是秩序工程的死角，必须靠人兜底或者直接放弃。现在模型能在这些缝隙里提供“够用的判断”，等于从另一个方向在收窄混沌。
两股力的交汇区，就是 agent 可以稳定执行的空间。这个空间确实在快速扩大，大家都看到了。但功劳几乎被单方面归给了模型那一侧——因为模型的进步可见、可 benchmark、可开发布会，而秩序工程的进步是安静的，分散在每个 skill 文件和每条工具接口规范里，没有人会为它写一篇发布博客。
于是就产生了一个很普遍的直觉：模型变强了，工程约束就可以松一点，skill 可以糙一点，环境可以脏一点，反正模型能兜住。
这个直觉完全是反的。
乘法，不是替代
模型能力和 harness 质量之间是乘法关系。模型能力是乘数，harness 质量是被乘数。乘数越大，被乘数的差异就越醒目。
同样的模型，一个写得精确的 skill 可能让系统从“经常能用”变成“几乎总是对的”，一个写得糙的 skill 只是从“偶尔能用”变成“经常能用”。差距不是缩小了，是被放大了。
HAL benchmark 有一组很直观的数据：同一个 Claude Opus 4.5，从通用 scaffold 换到 Claude Code 的 harness，准确率从 42% 到 78%。模型一行权重没动，分数翻倍。Vercel 的故事更极端——给 agent 堆了 16 个专用工具，后来删掉 80% 只留 bash，成功率反而从 80% 升到 100%，速度快了三倍半。
这个乘法关系不只是理论洞察，它直接告诉你一件事：当你的 agent 效果不好时，先别急着换模型——先看看被乘数是不是瓶颈。很多时候升级模型带来的改善远不如把 skill 写好、把工具接口理清、把异常路径覆盖住。
为什么偏偏是 Coding Agent
接下来一个自然的问题：如果 harness 质量这么关键，为什么 coding agent 看起来用很轻的 harness 就跑得很好？
答案不是“模型特别擅长写代码”。答案在于代码世界自带一种极其罕见的东西，我把它叫做内生秩序密度。
秩序有两层来源。第一层是领域本身自带的内生秩序：文件系统是树状的，函数签名是显式的，类型系统提供静态约束，diff 可计算，测试可自动执行，版本控制提供完整的状态回溯。这不是谁设计出来的 harness，这是代码作为一种工作介质自身就携带的结构。模型在这个环境里工作，相当于走进了一个规则清晰、反馈即时、状态可观测的房间——它犯了错，房间本身会告诉它错在哪里。
第二层是工程师主动注入的外加秩序：skill、prompt 约束、工具接口规范、异常回退协议。作用是在内生秩序不够的地方补上缺口。
Coding agent 有效，是因为代码领域的内生秩序密度极高，第二层需要补的东西相对少。模型几乎是走进了一个已经整理好的房间，只需要少量额外规则就能稳定干活。
反过来看就更清楚
为什么 research agent、PM agent、security agent 到今天都没达到 coding agent 的可靠性？不是模型在那些领域“不够聪明”——是同一个模型。差异在于工作台的内生秩序密度完全不同。
研究工作的输入是非结构化文献、模糊的研究问题、没有明确终止条件的开放探索。安全运维的输入是脏日志、不完整的告警链、需要跨系统关联的上下文。PM 工作的输入是含糊的需求、多方利益博弈、没有形式化验收标准的交付物。
如果你想在这些领域达到 coding agent 的可靠性，外加秩序层必须极其厚重。你不只是在给模型加约束——你是在把一个对机器不可读的工作领域，翻译成一套可描述、可调用、可验证的协议系统。
“内生秩序密度”这个概念不只是解释了 coding agent 为什么强。它给了你一个面对任何新场景时的第一个判断入口：这个领域自带多少结构？反馈闭环是否存在？状态是否可观测？答案直接决定了你的 harness 要做多厚——以及你该不该现在就进场。
这也恰好解释了一个有趣的现象：Noam Brown 说的“scaffold 会被下一代模型冲掉”，在 coding 领域确实很有说服力——因为代码的内生秩序太强了，模型变强就能直接接管更多。但把这个结论外推到内生秩序稀薄的领域，就会严重高估模型独自能做到的事情。在那些领域，秩序不会从天上掉下来。
RL 会吃掉 Harness 吗
这是整个话题里最尖锐的一个问题。随着 RL 把越来越多真实世界的任务执行模式烧进模型权重，harness 工程是不是终究会变得不重要？
要回答这个，需要把“约束”拆细一点。
最内圈是通用执行范式——“遇到错误先读报错”、“改代码前先看上下文”、“长任务要分步验证”。这些跨领域通用，训练数据里大量出现，可以设计通用奖励信号。RL 对这一层的吞噬能力极强。Claude Code 用极轻的 harness 就能跑得好，很大程度上就是因为这一层约束已经被训练内化了。Noam Brown 说的“scaffold 被冲掉”，指的主要就是这个圈层，他说得对。
中间圈是领域级秩序——“金融变更必须双人审批”、“医疗建议必须引用循证来源”、“安全事件按 P0-P4 分级”。现实世界的领域秩序高度碎片化，每个组织的 SOP 不同，变化频繁。RL 能学会“一般的安全事件响应流程”，但学不会“你们公司凌晨三点 P0 该先打给谁、哪些服务可以降级、哪些绝对不能动”。
最外圈是实例级上下文——“这个 PR 改的是支付核心链路”、“系统正在数据库迁移”、“这个客户上周刚投诉过”。完全动态，运行时才产生，训练时根本不存在。RL 对这一层的吞噬能力接近于零。
不只是知识问题
外面两圈还有一个更深层的特点：它们本质上不是知识问题，而是权限和责任问题。
“这个操作需要审批”不是因为模型不知道怎么做，而是组织不允许它自主做。“这条回复必须符合合规要求”不是因为模型不会写别的，而是这个上下文里只有一种写法是合法的。即使模型能力完美，人类也不会取消这些约束——因为它们保护的是问责链、合规性和组织信任。
所以真正发生的事情不是“harness 变得不重要”，而是 harness 的工作重心在向外迁移。两年前你要教模型“先看再改”，现在 RL 替你做了。但“该不该做”、“在这个上下文里能不能做”、“做错了谁兜底”——这些永远是 harness 的地盘。
这三个圈层不只是一个理论分类。当你要决定一个约束到底该写进 skill 还是可以等模型自己学会，看它落在哪个圈就行——内圈的可以大胆放手，中间圈的要看你的场景多特殊，外圈的别犹豫，必须工程兜底。
所以拿到一个新场景，该怎么想
回到最初的问题。从 coding agent 的成功里到底能拆出什么？
我觉得不是一个“谁会赢”的竞争预测，而是一组你拿到新场景时可以立刻用的思考方式。
面对一个新场景，第一个问题是这个领域的内生秩序密度有多高。它有没有自带的结构化条件？输入输出是否可形式化？有没有天然的反馈闭环——也就是说，agent 做错了，环境本身能不能告诉它？如果这些条件好，你可能不需要太重的 harness，轻量约束就够模型发挥。如果这些条件差，你要投入的第一件事不是调 prompt，而是先把领域秩序建起来——定义清楚任务边界、输入格式、验收标准、异常回退路径。不做这一步，再强的模型也只是在混沌里做布朗运动。
第二个问题是你打算建的约束落在哪个圈层。如果是通用执行范式——“先看上下文再动手”、“出错了先读报错信息”——大概率模型已经会了，或者下一代模型会冲掉，不值得你花精力写进 skill。如果是领域级秩序——你们行业或者团队特有的 SOP 和规范——这是 harness 的核心价值区，值得投入。如果是实例级上下文——每次运行时才产生的动态信息——这不是 skill 能解决的，你需要的是运行时的上下文注入机制。
第三个问题是此刻在这个场景里，往哪一层再投入一块钱，获得的边际改善更大。如果你的 skill 写得粗糙、工具接口不清晰、异常路径没覆盖，那花钱升级模型几乎没用——被乘数太小，乘数再大也撑不起来。但如果你的秩序工程已经很扎实，继续精雕细琢的回报会递减，反而是模型能力的提升能带来更显著的改善。这不是一个静态的“秩序工程 vs 模型能力”之争，而是一个随场景成熟度变化的投资判断。
最后一个问题，也是最容易被忽略的：这个约束是因为模型能力不够才需要，还是即使模型完美也不能取消？ 前者是临时脚手架，模型变强就该拆掉。后者是永久性的治理结构——问责链、审批流程、合规边界——它们存在的理由不是智能不足，而是信任机制。分清这两种约束，你才不会在该放手的地方过度约束，也不会在该兜底的地方盲目信任模型。
尾声
Coding agent 的成功不是一个奇迹，也不只是模型能力的胜利。它是一个特定条件下两股力恰好高效配合的产物——代码世界自带了极高的内生秩序，模型在这个已经整理好的房间里充分发挥了弹性。
真正值得带走的不是“agent 真厉害”这个感叹，而是一个更冷静的问题：你手上的场景，离那个“已经整理好的房间”还有多远？差距在哪里？该由谁来补？是内生秩序本就不够，需要你先做一轮领域翻译？还是秩序其实已经有了，只是没被喂给模型？
想清楚这些，比换一个更强的模型有用得多。
