# Coding Agent 的独特性：为什么它难以复制

## 一个被轻视的悬念

回想一下时间线。ChatGPT 刚火起来的那段时间，Coding 场景的表现其实并不比其他场景更出色。它没有在一夜之间成为超人，也没有让程序员集体失业。很长一段时间里，人们拿 LLM 去写诗、聊天、问问题，就像对待一个聪明的陌生人。

但后来情况变了。Anthropic 在 Coding 上的持续押注，让这个场景逐渐成为 AI 创造真实价值的支柱之一。今天回头看，Coding Agent 的成熟度已经远超其他任何工作场景。这个结果需要认真消化——它未必撑住了"岌岌可危的 AI 泡沫"，但它确实是目前最能回应"AI 到底能干什么"这个问题的答案。

接下来的问题是：Coding 是一个开始，还是一个极其独特的特例？

如果它是一个开始，那么随着模型能力的继续提升，我们会看到越来越多的场景陆续跑通，更多 Agent 市场被打开，更大规模的 AI 投资也能够被持续消化。如果它是一个特例，那它的成功就来自一些其他领域难以照搬的条件——我们就需要重新审视"接下来会有更多场景爆发"这个预期。

我的判断倾向后者，但结论比"悲观的独特性"更复杂。

## Agent 落地的阻碍：如何表征世界

要理解 Coding 为什么成功，先要问 Agent 落地这件事，难点究竟在哪。

讨论 AI Agent 时，人们常关注模型能不能推理、能不能调用工具、上下文窗口够不够大。这些确实是能力问题。但从行为层面看，智能体落地最难的地方，其实是**如何表征它所在的世界**。

这个问题在认知科学和机器人学里有漫长讨论。Frame Problem 最早由哲学界提出，核心困难在于：一个智能体在感知和行动时，无法穷举"哪些信息与当前任务相关、哪些变化值得关注"。它知道世界在变化，但无法事先圈定变化的边界。到了部分可观测马尔可夫决策过程（POMDP），这一问题被形式化了：智能体只能通过不完整的观测来推断隐藏的世界状态，而观测噪声、状态不确定性和行动后果之间的耦合，让决策变得极度困难。

这就是为什么许多"通用 Agent"的尝试最终停留在演示层面。不是模型不够聪明，而是 Agent 面对的世界没有给它提供足够的结构来减少不确定性。它需要自己判断什么重要、什么不重要、哪些行动是对的、哪些代价可以接受——而现实并没有把这些答案写在表面。

代码世界恰好绕开了这一整类问题。

## 代码是"世界即其自身模型"的具象化

Rodney Brooks 有一句常被引用的话：**"the world is its own best model."** 与其为世界构建一个抽象表征，不如让智能体在世界中操作——世界本身就是它所需要知道的一切。

软件工程恰好是这句话的注脚。代码不是对世界的某种映射或近似，代码就是世界本身。当你修改一行代码，你不需要推断"这个世界里的某个隐藏变量发生了什么变化"，因为代码库的全部状态就在文件系统里，可以被读取、被编译、被运行、被比较。

更关键的是，软件工程在过去几十年里，已经为 Agent 建立了一整套完整的闭环系统。回看那条已经被反复验证的链路：

> Goal → Understand → Modify → Test → Deliver

每一个环节都有对应的验证和反馈机制：

**Test** 回答"我改后的代码能不能工作"。模型写错代码并不可怕，因为单元测试和集成测试会暴露大部分错误。**CI（持续集成）**自动运行这些测试，把反馈返回给 Agent，让它知道哪一步出了问题。**Diff** 让人和模型都能看到具体改了什么，改动是局部的还是全局的。**Review** 由人判断修改方向是否合理。**回滚**则是最后的安全网——即使出错上线，版本管理也能让你回到上一个稳定状态。

这套体系不是为 AI 设计的。它在 AI 出现之前已经存在了二三十年，是软件工程行业多年积累的产物。LLM 补上的，只是过去最难自动化的一段：理解自然语言需求、读懂大量已有代码、生成修改、根据反馈迭代。理解与判断的部分由模型补齐，验证与反馈的部分早就在轨道上等着。

对比其他场景，这个差异是结构性的。客服有工单和 Resolution 指标，但客户问题是否真正解决、情绪是否被安抚、是否会产生后续投诉，都是延迟且模糊的信号。法律工作有判例和条文，但一份法律意见书"好不好"没有自动测试能判断。咨询报告、战略分析，更是几乎不存在客观判据——它们要等市场和时间来给答案，而且给答案的滞后常常以月甚至年计。

所以，Coding 的成功并不能简单理解为"LLM 特别会写代码"。**更准确的说法是：先有了一条铺好的轨道，Agent 才得以在上面跑起来。** 代码世界是这个时代最接近于"世界即其自身模型"的人工环境，Agent 在这里不需要回答"如何表征世界"这个根本问题，因为它面对的就是一个已完全表征的世界。

## 分层看：Coding 的不可复制性

站在这个视角，可以把 Coding 的独有条件做一次分层，每一层都对应着代码世界在不同环节上独有的特性。

**第一层：表征层——世界本身可读。**

代码的全部状态以文本形式存在于文件系统中，Agent 可以完整读取输入。这并非所有数字化工作都能做到——客服场景中客户意图无法从字段里完全读出，安全运营中攻击者的真实意图隐藏在大量日志的噪声背后。代码世界没有这个问题：你要改什么，什么就是一组文件；你要理解什么，什么就在源码和依赖里。这一层几乎不花费额外成本，因为表征是代码的天然属性。

**第二层：验证层——结果可计算判定。**

任何一次修改是否成功，客观答案都存在。编译是否通过、测试是否绿、覆盖率是否达标、性能是否回退，这些都是可运行、可计算、无歧义的判据。验证可以在秒级到分钟级完成，成本极低。

**第三层：纠错层——错误可定位、可回退。**

Diff 告诉你改了什么，Review 判断方向，版本管理确保任何时候都能回到上一个状态。即使出问题，损害也已经限制在可控范围。这一层的成本也几乎为零——不是因为它容易建设，而是因为它已经建设完毕。

**第四层：经济层——边际验证成本趋近于零。**

前三层之所以可贵，在于它们的成本结构。测试和 CI 的边际成本是计算时间，几乎可忽略；回滚成本取决于版本管理的成熟度，同样极低。一个 Agent 每多迭代一轮，它获得的反馈质量乘以迭代次数，就是它学习的速度。Coding 的反馈不仅质量高，而且**密度高、延迟低、成本低**，这让高频自主迭代在经济上成为可能。

把四层放在一起，就能看到其他领域为何困难重重。在大多数真实工作场景里，结果正确与否的判断是**缺失的、延迟的、昂贵的或者模糊的**。一个客服交互是否成功，可能要等客户投诉或好评才能确认；一份法律意见是否严谨，要等诉讼结果——那可能是几个月之后的事；战略建议是否正确，可能永远没有确定答案。反馈信号缺失或滞后，意味着 Agent 无法在合理时间内自我纠错，无法形成"迭代—学习—改进"的自洽循环。没有闭环，就没有意义上完整的 Agent——只有一次性的人机对话。

## Service 和 Operations：差距在哪一层

既然 Coding 如此独特，那么 Service 和 Operations 这类场景呢？是不是就没有机会了？

我认为不完全如此。Build、Service、Operations 是三种反复出现的 Agent 工作模式，现在可以把它们放在上面的框架下来看。

Service（客服、IT 支持）和 Operations（安全运营、监控、运维）**并不完全具备**像 Coding 那样的完整闭环条件，但它们是目前所有非代码场景中目标最清晰、观测和反馈最适合的候选者。

它们与 Coding 的差距在于验证层的强度不同——客服有 Resolution 指标和 CSAT，但无法像编译测试那样给出无歧义的"对/错"；Operations 有明确的异常事件定义和恢复标准，这让它比 Service 更接近闭环，但仍需人在部分环节确认。另一方面，Service 天然缺少 Coding 那样的完整状态读取能力——客户的一句话说出口，背后隐藏的意图和真实需求并不会完全呈现在结构化数据里。

但这是**可追赶的工程差距**，还是**结构性差异**？我的判断是：工程差距与结构差距之间的边界并没有那么硬。安防是一个好的例子。一个园区有几百路摄像头，过去需要保安长时间盯着屏幕，一个人根本不适合持续观察几百路视频。这个场景的输入（视频流）和输出（需要关注的事件）都比较清楚，事件自动触发、人可确认告警是否有意义、确认结果可成为系统反馈。它没有 Coding 那样的自动验证，但它的观测和反馈条件远好于大多数白领工作。

这类场景最大的不同是，验证回路的一部分只能由人来完成——最后一个"对不对"的判断，往往需要人点头。这提高了成本，降低了迭代密度，但并没有把路径堵死。

## 以反馈方式构建，而非以规划方式构建

如果承认 Coding 的可迁移性是弱的，那么接下来的建设策略就应该接受这个约束。

我倾向于一个观点：**以反馈的方式构建 Agent，而不是以规划的方式。** 这里的反馈指客观、可计算的指标闭环——测试通过、Resolution 达成、事件恢复、判断被人工确认——而不是依赖人类主观判断的迭代。

这个逻辑很简单。以规划方式构建，意味着先定义"Agent 应该做什么"，再期望它在执行中自行修正。这在大部分场景里会失败，因为缺少修正所需的信号。以反馈方式构建，意味着先问"这项工作结束后，有没有一种客观方式判断做得好不好"，如果答不出来，就不该把它列为第一批要建 Agent 的场景。

我当然知道这个策略会排除大量有价值的场景——法律研究、策略分析、咨询建议，这些工作的价值很高，但都缺少客观判据。但这可以是一个合理的初始策略：在更有确定性的领域先做出成果，再逐步向外扩展。

确定性带来迭代，迭代带来信任，信任才有可能让 Agent 进入那些反馈模糊的场景——哪怕到那时，它也需要人机协作的新形式来弥补判据的缺失。

## 不被"产出物幻觉"拖垮

最后说一个在当下尤其重要的风险。

Coding Agent 的成熟，加上 Service 和 Operations 的初步落地，正在强化一种叙事：AI 会很快进入更多复杂工作场景，接下来会有应用爆发，支撑规模更大的投资。

我对"更多场景马上爆发"持保留态度。Coding 的独特之处不在于模型能力，而在于代码世界本身的自建模性、全量可读性和验证成本结构。这些条件在其他领域要么不存在，要么需要长期的工程化投入才能部分逼近。把一个领域做成 Agent 化闭环，和把一个 Agent 塞进一个没有闭环的领域，是两件难度完全不同的事。

另一个风险是"产出物幻觉"——被 Agent 生成的内容本身迷惑，误以为产出物可用就等于工作闭环成立。一份看起来完整的报告、一段写得流畅的代码，都不等于验证通过。Coding 之所以安全，正因为每一个产出物后面都跟着测试、CI、Review 和回滚。当我们在其他领域部署 Agent，却没有同等严格的验证机制时，产出物的"表面完成"恰恰是最危险的信号。

有价值的探索，应当建立在两种东西上：一是对场景条件的思辨——这个工作有没有闭环可关、有多少验证需要人做、反馈成本是多少；二是客观评测——不要被演示和产出物的外观说服，而是要看它在真实工作中的迭代成功率。

代码的独特性依然很强，它对我们复制应用场景不利。但这不意味着 Coding 之后的道路只能等待某个奇迹般的新领域出现。Service 和 Operations 已经展示了第二种可能：如果我们愿意接受"验证闭环可以部分由人承担"这个条件，那么工程化条件的边界会比最初想象得更宽。

关键不在于找到一个与代码世界等价的世界——那样的世界几乎不存在。而在于承认差距的层次和代价，然后回答：哪些差距值得用工程去弥合，哪些场景更适合用长期的人机协作去慢慢建设。在确定性更高之处先积累能力，不被泡沫叙事和产出物幻觉裹挟，这条路虽然慢，但比浮在表面的繁荣走得远得多。