过去两年，Agent 产品密集发布，演示大多惊艳，但真正被规模化日常付费使用的场景，第一个是编码。从代码补全、技术问答到自主修改一个代码库，Coding Agent 已经进入多数工程师的工作流。一个方向率先跑通，通常不是运气，而是结构性原因。编码场景至少具备三个其他场景暂不完全具备的条件。
一、代码是天然可验证的执行环境
Agent 的核心难题，不是生成内容，而是判断自己做得对不对。在多数领域，这个判断要靠人：文案好不好、方案行不行，评审者见仁见智。编码不一样。代码写完，编译器立刻给出对错，测试套件立刻给出覆盖，运行结果立刻给出行为。反馈即时、客观、可自动化，不需要任何人到场。
这意味着 Agent 可以在一个闭环里自我校准：改一行，跑一次测试，看一次结果，再决定下一步。反馈闭环的密度，决定 Agent 进化的速度。编码把这个条件给到了极致。
Agent 的能力边界，不在于它会不会做，而在于它能不能知道自己做对了。
二、工程任务数字化程度高，语料充足
第二个条件是语料。开源社区三十年的协作，沉淀了海量「任务—修改—评审—结果」的完整记录：issue 描述了任务，diff 记录了解法，持续集成验证了结果。这些语料天然成对，自带对错标签。
同时，软件工程本身是数字化程度最高的工种之一：任务分配、代码托管、构建与测试全部在线。Agent 接入的不是一个需要新建的工作流，而是一个已经运行了几十年的在线工作流。
三、错误成本可控，可回滚
第三个条件是容错。写错代码当然有代价，但版本控制、分支保护、代码评审与测试环境，把代价压在了可控范围内：一次错误的修改可以被评审拦截，可以被一键回滚，可以关在测试环境里不出门。
Agent 敢放手做事的前提，是做错的成本可承受。编码场景用三十年工程实践建好了这层保险，Agent 只是住了进来。
四、从编码到更广的知识工作
这三个条件——可验证的反馈、充足的语料、可控的试错成本——并不专属于编码。它们描述的是一类工作：过程在线、结果可量化、反馈可自动获得的知识工作。沿着这个标准扫描各个行业，可以得到一份 Agent 落地的顺序表。
销售获客排在这份顺序表的前列。线索来自哪里、触达是否有效、跟进到哪一步、是否推进到会议与成交，每一步都留下数据，每一步都有结果反馈。它与编码共享同一个结构性条件，只是验证信号从「测试是否通过」换成了「客户是否回复」。我们将在下一篇文章中专门讨论这件事。
Coding Agent 的意义，不止于让工程师写得更快。它第一次证明：只要反馈闭环存在，Agent 就能对一类知识工作真正负责。这个结论，值得沿更多行业重新推导一遍。