# Coding Agent 是个例外，还是一个开始？

Claude 在 Coding 上的表现，某种程度上支撑住了岌岌可危的 AI 叙事，这个有点意外的结果在过去一段时间让我们更加坚定（或重燃）对 AI 的信心。我们很难在两三年前想到，Coding 为什么成了 AI 最有价值的产出场景。无论如何，我们开始假装自己早就看懂了这个方向，只是现在又有了新的拷问：如果 Coding 是可复制的，那么更多应用场景的爆发就有理有据；如果 Coding 有着其他领域极难复制的特殊条件，那我们今天对 AI 投资规模的很多预期，恐怕都要重新算账。

**经过一段时间的研究，我认为 Coding 的成功极难迁移。AI 落地可以探索的路径，跟我们在 demo 里看到的完全不一样。**

**Agent 落地的障碍，在于对世界的表征**

AI 领域有一个经典思想难题，叫 Frame Problem。人类智能体能在一个世界里行动，但它无法穷举所有信息里哪些与当前决策相关：煮鸡蛋需要知道水会沸腾，不需要知道窗外云在移动。可它怎么知道哪些信息与任务有关，哪些可以忽略？作出这种区分，本身就很困难。

换成更技术化的语言，现实世界中的大多数任务都能建模成部分可观测的马尔可夫决策过程（POMDP）：智能体在任何一个时刻只能看到状态的一部分，必须在信息不完备的情况下做决策，然后依靠结果反馈来修正。这对 Agent 是个结构性挑战：它必须维护一个足够好的“世界模型”，把外部世界压缩成可处理的心理表征，再以表征去做推断。一旦这个表征不准确，Agent 就会沿着错误方向越走越远，而它所服务的大多数真实场景，恰恰是表征最难的：客服背后是巨大且动态更新的业务规则，运维背后是复杂又不断演化的系统拓扑，这些地方几乎无法被压缩进一个鲁棒的模型。

从 Frame Problem 到 POMDP，这些讨论都指向了 Agent 落地时的困难：如何表征它所在的世界。

## 代码领域恰好绕开了这个问题

Brooks 所说的“The world is its own model”，强调通过感知和行动持续接触环境，减少对完整内部表征的依赖。[Brooks 原论文](https://people.csail.mit.edu/brooks/papers/representation.pdf) 软件开发提供了一个可以借鉴这一思路的环境：Agent 能读取仓库中的文件，运行程序，再根据结果检查自己对代码的理解。部分推断可以交给执行环境完成，模型因而不必在行动前掌握全部细节。

软件工程在长期发展中，也已经为 Agent 准备了完整的机制：

- 编译和运行检验代码能否执行；
    
- 测试自动发现大量逻辑错误；
    
- Diff 清楚展示改了什么；
    
- Code Review 判断改动是否合适；
    
- 版本管理让每一步都可能回滚。
    

Agent 可以在一个能够运行、测试和回滚的狭窄闭环里工作，不必先完美理解这个世界。它对世界的误解，会被测试和运行在很短时间内暴露，然后它据此调整。这个持续修正的循环，让已经暴露的错误成为下一轮修改的依据。工作过程可以表示为：Goal → Understand → Modify → Test → Deliver。

代码 Agent 可以借助这些工程条件，绕开一部分表征上的困难。工程环境提供了它能够反复核对的工作对象，让它通过操作和反馈修正理解。

## 独特性来自难以复制的条件

那么，其他领域能复制这个环境吗？我认为极难。

**输出能不能被客观检验？** Coding 的输出是一段能运行的修改，可以通过断言来验证。而绝大多数工作的“正确性”充满争议。报告的口径对不对、策略的方向对不对、法律方案妥不妥，这些问题的评判标准通常不是技术性的，而是价值判断。产出含糊，反馈的信号就含糊。

**反馈是否及时、无歧义？** 代码的反馈是测试，失败的测试能提供定位错误的线索。而大多数工作的反馈来自“三个月后决策的结果够不够好”“客户有没有回头复购”。这些反馈延迟、间接，还混入大量无关变量，Agent 从中学不到可靠的因果关系。

**有没有可逆的安全网？** 代码可以回滚，业务可以回滚吗？服务执行错误不可撤销，运维误操作可能导致不可逆的损失，客服对愤怒客户的错误回答无法倒退成“没说过”。没有低成本的纠错机制，Agent 的探索就没有安全的边界。

**这些条件能否后天搭建？** 代码领域的工作环境，是工程师在几十年间一点点建设起来的，调试器、CI、容器、监控和发布系统都来自这份积累。要其他领域复制，意味着要把该领域的工程体系本身建设到类似的完整度。这需要长期投入，持续改造该领域的工程体系。

我并不认为 Coding 的成功完全不可复制，但前提是让一个领域拥有能运行、能测试、能回滚的工程基础设施。在多数场景里，这个前提都还不存在，短期即使是有无限的热情和资本投入也很难补上来。

**这也是我推崇从 workflow 入手的原因。** 在非 Coding 场景中，业务信息和验证条件尚不充分时，可以先把已知规则写进流程，让 AI 在更小、受约束的局部环境中发挥作用。例如，一项服务可以由程序规定必须查询哪些数据、满足什么条件才能执行操作，AI 负责理解请求并处理其中允许变化的部分，超出范围时交给人确认。这样，流程先提供了一部分确定性，模型需要自行判断的信息和行动就少了。

如果一开始就要求 Agent 自主处理整个业务，它还需要辨认哪些信息相关，以及哪些变化会影响当前任务。这触及了 Frame Problem 在广义讨论中的相关性难题，也增加了整理业务表征和验证其可靠性的投入。**Workflow 让团队有机会先建设一个可用的局部环境，在实际工作中补足信息，再根据反馈扩大 AI 的自主范围。**

## 构建反馈，而不是规划世界

面对 AI 的规划困境，我倾向于从反馈系统入手，让 Agent 在行动中获得修正的依据。

规划的路线，是让 Agent 构建更完整的世界表征，把业务规则、因果和不确定性都装进模型里，让它想清楚之后再行动。这条路正面撞上了 Frame Problem，进展会很慢，失败率很高。

反馈的路线，是让 Agent 在一个边界清晰、输入输出可检验的循环里行动，使错误及时暴露，让团队能够根据人工确认的结果修改规则和实现。

Brooks 的 **subsumption architecture（包容式架构）** 提供了一个已经在机器人上实践过的思路。他把控制系统按行为能力分层，先实现避障，再增加游走和探索。每层都与感知和行动相连，较高层通过抑制或替换部分信号协调已有行为，底层能力可以独立工作。新能力是在环境中逐步调试、组合起来的。[Brooks 对架构与机器人实验的说明，第 6 节](https://people.csail.mit.edu/brooks/papers/representation.pdf)

把这种方法借用到 Agent，我更看重它的建设顺序：先让一段有限的工作能够完成，并获得结果反馈，再增加它能处理的情形。已有 workflow 可以承载经过验证的操作，Agent 根据当前状态安排局部行动，团队则通过失败记录改进系统。这里的反馈既帮助 Agent 完成当前任务，也帮助团队判断下一步该建设什么，减少提前规划整个业务世界所需的投入。

我目前看到三种已经沿这一方向发展的模式：

**Build** 围绕可验证的数字产物工作。Coding 是代表，但凡是产出能在交付时被客观检验的工作，机制都接近。

**Service** 针对具体请求提供服务，有明确的开始和结束。客服、IT 服务都是如此。这些类型的输入输出可以定义，其障碍在于很多企业的知识库和业务规则尚未工程化。

**Operations** 由持续发生的事件触发。运维、安全监控、摄像头异常识别都属于这类。它们的输入是持续到来的信号流，输出是需要关注的事件，最终判断由人确认。这个人工确认本身就是反馈。

这三类工作都有办法被检验、被修正。这未必需要 Agent 理解世界的一切，只需要在有限范围内建立闭环。

## demo 的兴奋，与商业闭环的距离

用反馈和验证来衡量，今天的 AI 叙事中存在大量的“产物幻觉”。

我写过一篇《AI 让我们变强，还是只是让我们产出更多？》。那篇文章里，我把 AI 提效分成三层：**产物增强**，过去做不出来的东西能生成了；**任务增强**，这个产物经过验证，解决了具体问题；**人的能力增长**，使用者因此形成了新方法、新判断。按这个标准，市场上绝大多数宣传只达到第一层：做出了一个漂亮的网站、一份报告或一个精美的 PPT，便宣称自己是“超级个体”。

这些产物确实令人兴奋，它们能否产生业务价值，要看使用以后发生了什么。对使用方而言，一份 PPT 如果推动了决策，一段代码如果通过测试并进入了生产，它们就有真实价值；如果产物只停留在生成的那一刻，没有改变任何实际决策，也没有验证任何判断，那只是数字产品的繁荣。随着 AI 降低生成成本，这种繁荣还会继续膨胀。

这恰恰是 Coding Agent 与很多 demo 叙事的区别：代码产物经过运行、测试和 Review 的严格检验；而大量其他 demo 的产物长期无需被检验，因为它没进入一条可评价的工作链。这些 demo 看着有价值，但接入业务环境以后，输入可能不清晰，输出也缺少验证。Agent 无法从反馈中修正错误，又回到了如何表征世界的问题。

## 从具备反馈条件的工作开始

回到最初的问题：Coding 之后，下一个成熟的 Agent 市场在哪里？

我不打算再找“下一个 Coding”了，而会去看哪些工作已经具备工程闭环的前提，再研究怎样建设其中的反馈系统。在一个明确的输入输出区间里，把检验、纠错、回滚的机制建起来，让 Agent 逐步承担它有能力完成的工作。

Build、Service、Operations 三类工作，是我能看到建立反馈闭环的起点。虽然它们的工程化程度参差不齐，但它们拥有最稀缺的要素：可界定的边界、可持续的评价、可发现并可修正的错误。

Coding 的成功能否复制到其他领域，仍然可以继续讨论。我倾向于认为，这个过程会很慢，也很困难，进展取决于我们愿意在反馈系统的建设上投入多少。而今天多数人的资金和注意力，仍然事实上花费在好看的 demo 上了。