来自 ICML 的态势感知：关于 Code Agent

ICML上的Code Agent: 共识如此集中且确定

七月的首尔很热，空气里有潮湿的海风，也有会场空调和咖啡混在一起的味道。ICML 的大厅里，人群从 poster 区流到走廊，再从走廊流回一张张临时拼出来的小桌。有人抱着电脑讲 eval，有人在白板前画 RL pipeline，也有人只是站在扶梯口，把一个还没成形的想法讲给刚认识的人听。

在这种嘈杂里，一个信号反而变得很清楚：话题总会绕回 Code。 做开发者工具的人在谈 Code Agent，模型公司在谈 Code RL，聊模型能力、评测、infra、量化和金融场景、研究流程自动化的人，最后也很容易落到同一个问题：如果要训出一个真正能做事的专项 Agent，Code 是不是眼下最确定的入口？

这种确定性有点少见。过去两年，很多 Agent 叙事都很大：通用助理、全能员工、自动公司。但到了真实讨论里，大家其实更关心一个朴素的问题：它能不能先在一个任务域里稳定创造价值？ Code Agent 在这里显得扎实。软件工程本身就是高价值工作，量化、金融、企业 infra、内部工具链里也到处都是代码和胶水流程。一个面向专项任务的 Code Agent 只要能稳定工作，就会直接变成生产力。

我印象比较深的是和一个量化公司的人聊天。他说他们老板这次下场很直接：在当前阶段，投入多少钱、多久能覆盖成本、能不能迅速转成利润，这件事的确定性空前高。过去很多 Agent 故事还停在愿景里，但 Code 不一样，它直接贴着生产系统、研究流程和交易 infra。一旦能把一部分工程、研究、调试和维护链路稳定自动化，账是可以算出来的，所以资金和团队会更快入场。

所以这次在 ICML 上，我听到的是一种收束：很多原本分散的路线，开始承认 Code Agent 是一个足够清楚的任务模板。 它既有商业价值，也有训练价值；既能做真实事情，也能沉淀 trajectory；既能服务一个明确场景，又能逼出模型的长链路执行能力。

进一步看，很多新任务正在顺着 Code Agent 的能力长出来。Cyber 网络安全、EDA / 电路设计、Science / research task、生物制药、Auto Research，都在尝试把自己的任务整理成可执行、可验证、可复盘的形式。它们现在看起来像横向任务，但如果任务足够长程、反馈足够清楚，也可能慢慢长成新的纵向训练场。 Code 的热度真正重要的地方在于，它让大家第一次比较具体地看见：Agent 任务到底应该长什么样。

Agent 任务的纵横地图

我现在更愿意用“一条纵向、多条横向”来看 Agent 任务。纵向看的是模型智能上限：一个任务能不能持续训练模型的长链路执行、工具使用、状态追踪、错误恢复和验证意识。横向看的是经济价值和业务厚度：这个任务域有没有真实需求、真实预算、真实流程，能不能变成可持续的生产力。

Code 的特别之处，是它同时站住了纵向和横向。 横向上，软件工程、量化、金融、企业 infra 都有真实高价值任务；纵向上，Code 又是一个可验证、长程、反馈密集、能规模化构造任务的训练环境。应用价值和训练价值两边都很强。

Code 同时站在纵向和横向

所以 Code 这件事最有意思的地方，在于它同时站在两个位置上。纵向上，它是训练 Agent 能力的环境；横向上，它又是一个真实、昂贵、高频的生产任务域。这也是为什么大家会在 ICML 的不同讨论里反复绕回 Code：它能同时解释训练和商业。

先说纵向。一个好的训练场，至少要足够长程、足够好 verify。Code 两个条件都很强：真实任务需要读 repo、理解上下文、跨文件修改、运行测试、debug、回滚，再确认有没有破坏其他路径。这里面每一步都在考模型的规划、状态追踪、工具调用和错误恢复。模型只靠单轮聊天，很难稳定长出这些能力；但放进工程环境里，它必须一边做事，一边根据反馈修正自己。

这也是 Code 对训练有吸引力的原因。它给模型一个持续变化的工作现场。Agent 今天改了哪些文件，为什么这么改，测试为什么失败，下一步是补依赖、改逻辑还是回滚，这些都会变成 trajectory。对训练来说，这比一个最终分数更有价值，因为中间过程本身就能告诉你模型卡在哪里。

再说横向。Code 本身就是很厚的商业任务域。软件工程、量化、金融、企业 infra、数据平台、研究工具链，都有大量读代码、改代码、调系统、接工具、维护流程的工作。这些工作本来就在组织里发生，组织每天都要付钱解决。只要 Code Agent 能稳定吃掉其中一部分，价值就很直接。

所以 Code 的位置很特殊：它可以变成训练模型 Agent 能力的训练场，也可以横向覆盖真实生产工作流。很多方向只能回答其中一个问题：要么商业价值很清楚，但训练信号太弱；要么评测很清楚，但离真实生产太远。Code 现在难得的是，两边都能回答，所以它才会成为这一轮 Agent 讨论里最集中的共识。

新的横向任务从 Code 长出

横向的变化也很明显。很多任务开始学习 Code 的任务组织方式。它们把原本松散的业务流程，改写成更像工程任务的形态：有环境，有工具，有中间状态，有结果检查，也有失败后的修正路径。这个变化比“给行业套一个 chatbot”更重要。

我在现场更明显看到的是几类外溢。第一类是 Auto Research，大家在想怎么把研究过程拆成可执行、可追踪、可验证的 Agent 工作流；第二类是 Cyber，安全任务本来就有扫描、利用、修复、验证和复现，天然接近 Code Agent 的工作循环；第三类是 EDA / 电路设计，RTL、仿真、综合、约束、timing 和验证本来就是强工具链环境；第四类是 Bioscience，尤其是生物制药，它有实验、数据、脚本、指标和复现链路；第五类是更广义的 Science，很多科研流程也在被重新整理成可执行、可追踪的任务环境。

1. Auto Research这里看到的是把选题、检索、实验脚本、数据分析、图表、报告和复现串成工作流。它更接近“研究过程自动化”，单点问答只能覆盖很小一部分。
2. Cyber安全任务天然有工具链、沙箱、扫描、利用、修复和验证，链路长，反馈也更清楚，所以很容易被拿来对齐 Code Agent 的工作循环。
3. EDA / 电路设计电路设计有 RTL、netlist、仿真、综合、约束、timing closure 和 formal verification。Agent 如果能进入这套工具链，反馈会比很多开放任务硬得多。
4. Bioscience / 生物制药生物制药有实验设计、数据处理、脚本、指标、复现和合规约束。如果这些流程被整理成环境，就会很接近新的 Agent 任务场。
5. 其他 Science更广义的科学研究也在往这个方向靠：文献、数据、实验记录、模拟、分析脚本和报告，可以被串成更长的执行链路。

这些方向现在看起来是横向外溢：它们先接住真实业务需求，先解决具体场景里的效率问题。但它们真正值得看的地方，是有没有可能沉淀出稳定任务分布。如果一个领域里每天都有高价值任务发生，而且任务过程能被记录、验证和复盘，它就不会只是一个 demo 场景，而会开始靠近 Code 的位置。

所以“从 Code 长出”指的是新的任务域正在被 Code 的格式重新组织。所有事情不需要都变成写代码；关键是把自己的领域改造成 Agent 可以长期工作的环境。

态势感知（I）：更多 Task 接入 Code Agent 的横向系统

接下来几个月，横向会先变得更热。更多任务会接入 Code Agent 的横向系统：Auto Research、Cyber、EDA / 电路设计、数据分析、科研实验、生物制药、GUI / Browser。它们不一定一开始就是新的训练场，但会先学习 Code Agent 的任务组织方式：把任务拆成可执行步骤，把环境状态暴露出来，把反馈和验证接进工作流。

这里的“接入”要把真实工作流拆开，放进一个 Agent 能够持续工作的环境里。任务入口要清楚，工具调用要稳定，中间状态要能被看见，最后结果要能被检查。只有这样，Agent 才会从一次性回答变成在任务场里反复行动。

所以这条线看的是真实任务域能否被改造成 Code-like environment。比如 GUI 方向要解决的是状态表示和回放，Cyber 要解决的是安全边界和可复现环境，EDA 要解决的是工具链接入、仿真反馈、约束生成和 timing closure，Bio / Science 要解决的是实验流程和指标验证，数据分析要解决的是数据、脚本、图表和结论之间的闭环。这些问题看起来很工程，但正是横向任务能不能进入 Agent 体系的门槛。

横向任务越厚，越能提供真实需求、真实预算、真实流程，也越有机会反过来成为模型能力增长的燃料。短期看，它们会先以工具、MCP、workflow、harness 的形式接进来；长期看，其中少数任务如果积累出稳定环境和稳定反馈，就可能继续往纵向走。

这也是为什么 MCP / Tool Use 会变得重要。它们更像横向接入的基础设施：把外部系统包装成 typed tools，让非代码任务更容易进入 Code Agent 式循环。有价值的横向扩张，会让 Agent 在更多真实环境里做事，而不只是知道更多行业名词。

态势感知（II）：今天的横向任务可能成为明天的纵向任务

第二条线更关键：今天的横向任务会不会长成新的纵向任务。Code Agent 已经演示过一次：一个高价值应用任务，也可以变成训练模型 Agent 能力的主战场。下一次交叉点，可能来自 Auto Research，也可能来自 Cyber、EDA / 电路设计、生物制药、科学研究或别的任务域。

关键在于哪个方向能从应用变成训练环境。横向先解决商业问题，纵向则要反过来抬高模型能力上限。一个任务域要完成这次升级，必须能不断产生高质量 trajectory，能给出自动反馈，能反复训练，并且能随着数据和环境扩展持续 scale。

筛选标准很硬：任务必须好验证，链路必须够长，失败必须能归因。好验证意味着结果可以通过测试、回放、指标、规则或外部环境状态判断；链路够长意味着任务要跨多个步骤暴露规划和错误恢复；失败能归因，才有可能把一次失败变成下一轮训练材料。

这个升级通常不会一步到位。一个横向任务会先以产品或工具形态出现，解决一个具体场景里的效率问题；然后慢慢长出 harness、任务生成、环境回放、verifier 和数据记录；最后才可能变成训练场。真正的分水岭，是它能不能从“帮人做一次事”，变成“持续产生可训练的任务分布”。

这几类和前面的横向观察是同一组，但这里换成就绪度视角：谁更接近成为纵向训练场，还卡在哪个瓶颈上？Cyber 和 EDA 更靠前，因为它们的反馈更硬；Auto Research 链路长，但任务定义还偏软；Bioscience / 生物制药价值厚，但反馈慢且噪声大；更广义的 Science 还不均匀，需要先把任务定义和 verifier 做硬。

所以我不会只看某个方向有没有大模型 demo，而会看它有没有开始形成“环境工程”。有没有标准化的任务入口，能不能稳定复现同一个场景，失败之后能不能知道错在计划、工具、数据还是验证，轨迹能不能被留下来继续训练。没有这些东西，横向再热也只是应用层；有了这些东西，它才有机会变成纵向训练的燃料。

所以未来几个月我会更关注这类信号：某个横向任务是否开始出现稳定环境、稳定 verifier、稳定 trajectory。只要这三件事同时出现，它就可能从应用层机会继续长成新的纵向训练场。

竞争策略：和“共识错开15 度夹角”

这个判断最后会落到一个很实际的问题：如果 Code Agent 已经成为共识，新的位置在哪里？我觉得可以和共识错开 15 度：离 Code 足够近，能继承它的任务模板、工具链和训练信号；同时避开最拥挤的中心，在新的任务域里形成差异化。

Code Agent 证明了一个真实任务域可以同时具备商业价值和训练价值。软件工程是第一个成熟例子，因为它有真实预算、强工具链、硬反馈、可验证结果，也能留下长链路 trajectory。这个模式一旦成立，竞争策略就分成两条：一条找下一个能抬高模型能力上限的纵向训练场；一条把更多真实任务横向接入 Code 这个通用 Agent / 环境模板。

纵向策略，是压住下一个能够 scale up Agent 智能上限的训练任务。这个任务必须足够长程，能暴露规划、工具调用、状态追踪和错误恢复；也必须有稳定环境、硬 verifier 和可复盘轨迹，否则就很难成为训练场。SWE 是当前最清楚的样板，后面可能轮到 Cyber、EDA / 电路设计、Auto Research 或其他科学任务。

能持续生产高质量训练信号的方向更值得压注。Cyber 如果能解决合规和复现，就有沙箱、扫描、利用、修复、验证这条长链路；EDA 如果能接入工具链，就有 RTL、仿真、综合、约束和 timing closure 的硬反馈；Auto Research 如果能把研究过程标准化，就可能把检索、实验、数据、图表和报告变成可复盘轨迹。这些方向真正值钱的是环境、任务和 verifier。

横向策略，是把更多真实任务接入 Code 这个通用 Agent / 环境模板。每个行业都需要把任务改造成可执行、有状态、有工具、有反馈、有验证的工作循环；先套一个 chatbot，只能解决很表层的问题。MCP、GUI、数据分析、科研流程、企业系统和生物制药，真正的机会都在这里。

横向里最重要的是任务厚度。有没有真实用户每天在做这件事？有没有预算？有没有现成的数字环境和工具接口？有没有办法把结果验证出来？行业知识问答很容易停在演示层；行业流程变成 Code-like task，Agent 才有机会真正进入生产。

所以对个人或团队来说，不一定要站在共识正中心。更有价值的问题是：我掌握的任务域有没有独特数据、工具链、客户流程或 verifier？它能不能离 Code 主干足够近，被整理成可执行、可观察、可验证、可复盘的环境？如果答案是肯定的，这个 15 度夹角就比正中心更值得下注。