Coding Agents 2.0：接口、推理与核实

该模型已经能够编写法典了。接下来的竞争焦点在于如何并行运行这些智能体、以较低成本为它们提供服务，同时还要对其生成的代码质量保持信任。

在当前，编程无疑是 AI 智能体的核心应用，其重要性远远超过其他任何领域。根据 OpenRouter 发布的《2025 年 AI 行业现状》报告，编程在所有 LLM 生成的文本量中所占的比例从 2025 年初的约 11%上升到了同年后的 50%以上。

在不到一年的时间里，利用大型语言模型编写软件便成了人们最常做的事情。相关业务收入也与输入的文本量直接挂钩：Cursor 在四年多时间内就实现了约 40 亿美元的年化营收，最近还接受了 SpaceX 提出的 600 亿美元全股票收购方案；而 Claude Code 在推出后仅六个月，其每日营收就已突破 10 亿美元。我们采访过的每一位开发者都有过“那个演示让我大为震撼”的经历。

我们认为第一波发展已经基本完成——模型已经能够编写法典了。未来几年值得关注的问题并非这些智能体能否生成法典，而是围绕模型展开的各类问题：如何大规模运行这些智能体、在算力不足时如何为它们提供服务，以及如何确保它们输出的代码是正确的。这正是 Gradient 目前投入精力研究的领域，我们也认为未来的那些具有开创性意义的公司将会诞生于此。

随着法典应用的日益普及，瓶颈已不再是模型性能，而是变得极为稀缺的两种资源：人类的注意力与计算能力。在代码生成代理完成工作所需的几分钟时间里，程序员的注意力就会分散，而也无人能够逐一评价大量代理所产生的代码质量。计算能力则是另一道障碍，由于编码工作是网络中最耗费算力的任务，它最先面临这一挑战。

因此，第二阶段将从三个方面展开：重新设计的编程界面、专为提升编程效率而打造的推理架构，以及全新的核实层。

接口设计：我们将以集群形式运行编码智能体，而非逐一运行。

“一名开发者对应一个代码智能体”的工作模式已经难以为继。如今，单个智能体完成一项任务需要数分钟到数小时，等它处理完毕时，开发者早已开始处理其他任务。更合理的做法是创建多个智能体来处理不同的任务，仅将人类的注意力集中在最优质的成果上，这就好比管理者管理团队而非亲自包办所有工作。

但所谓的“代码生成舰队”并非仅仅指 10 个终端窗口而已。在 tmux 中同时运行 10 个并行版的 Claude Code 会生成 10 个相互独立的拉取请求，而这些请求仍都需要人工逐一进行评价，这根本无法解决现有的瓶颈问题。真正的舰队管理应当将软件发布的各个阶段——规划、编码、评价以及合并——分开处理，并对整个流程中的各类智能体进行协调，而不仅仅局限于代码生成这一环节。否则，这样的“舰队”只会产出大量质量一般的代码，这些代码会一直滞留在拉取请求队列中，永远无法真正被发布出来。

下一代接口应当以并行处理为核心，让每个编码智能体在独立的沙箱环境中运行。规划文档将成为整个智能体集群共同使用的共享资料。评价与合并流程不再成为人工操作的瓶颈：智能体评审器会自行执行验证流程，任何更改都会自动触发持续集成测试。已有部分团队开始着手开发相关技术。Emdash 能够在从开发服务器、云虚拟机到 GPU 计算设备等各类机器上运行编码智能体集群。Superset 具备高度的脚本化能力，提供了图形界面、命令行界面、MCP 服务器以及 TypeScript SDK，可用于对智能体集群进行管理。Conductor 则为“一键式工作流到 PR”的流程增加了评价环节。其他大型企业也在加入这一领域：Cognition 最近推出了 Devin Desktop，旨在通过单一界面即可管理智能体集群。

一旦接口按照集群语义来设计，人类的注意力便从无法预料的等待转变为对整个流程的协调管理，工作重点也会随之上升至更高层面：重新设计微服务、优化成本以及选择更优质的供应商。这样的工作越来越不像编程，而更像是管理一个工程团队。

基础设施：编程需要专属的推理框架

更多的并行代码生成代理能够产出更多的法典，由于编码工作对计算资源的需求极为庞大，这类代理所带来的需求增长速度远远快于供应能力的提升速度。即便像 Sonnet 5 这样的专有模型降低了成本，那些最复杂的编码任务依然会让封闭式 API 的运营模式难以维持。每个系统提示词都需要包含完整的代码库和工具定义，其输入的标记量是普通非编码任务的数倍。这种压力已经显现出来：Anthropic 为 Claude Code 设置了每周使用限额，因为那些选择每月 200 美元套餐的高频用户，其标记消耗成本往往早已超出这个限制；Microsoft 则正在取消其“经验值”与“设备”业务部门内部的 Claude Code 许可证，转而引导工程师使用 GitHub Copilot；Uber 在四个月内就耗尽了 2026 年的全部 AI 预算，对于高频用户而言，每位工程师每月的花费高达 500 美元至 2000 美元不等。编码需求的增长速度与软件发展相当，但计算资源的增长速度却取决于芯片和数据中心的建设进度，正是这种差距创造了机遇。

由于闭源产品的价格居高不下且需求持续增长，市场亟需另一条发展路径，而开源正是这样的选择。在 SWE-bench 测试中，MiniMax M2.5 的性能仅略逊于 Claude 4.5 Opus，但其成本却低 10 倍；GLM、Kimi 和 DeepSeek 也紧随其后。与此同时，AiderCline 和 Opencode 等开源工具早已被应用于实际的工程开发流程中。如今，人们完全可以构建一个完全开源的编码环境，无需依赖任何专有技术——自行托管模型，再在其上运行相关工具，从而彻底摆脱订阅费用的压力。

但仅仅在通用的推理服务上添加编码功能并不足以解决问题。编码工作具有那些通用服务提供商并未优化的特性：长度较长且重复出现的系统提示语，以及极高的准确度要求。其中最明显的两个缺陷在于前缀缓存与量化处理。在每次编码会话中，系统提示语的大部分内容都是相同的，但通用引擎会将每个请求视为无状态请求，从而从头开始重新计算相关内容，这会导致其使用的计算资源成本是具备编码认知功能的引擎的 10 倍之多。量化问题更是雪上加霜：为了保障每条消息的处理成本，这些服务提供商会使用 FP4 或 INT4 格式，虽然这对普通聊天功能来说尚可接受，但在需要精确输出的结果——如函数调用和代码差异对比——的编码任务中，则存在很大风险。

要填补这些缺陷，就需要一套共同设计的软件栈，让框架、推理引擎与模型层之间能够相互协同。如果设计得当，这种专为编程场景打造的开放型软件栈不仅能解决缓存与精度问题，还能根据需求进行路由处理，针对不同语言或任务热插拔 LoRA 适配器，而无需为所有任务都运行一个庞大且成本高昂的模型。Synthetic 和 Crush/Hyper 等初创公司正是基于这一思路，将开源编码代理与专用推理架构相结合。企业出于自身考虑也已开始采用此类方案：摩根大通由于隐私法规的要求，再加上闭源模型的定价在如此大规模的应用中变得不可承受，因此选择在内部使用开源编码代理。无论谁能够构建出开放且经过充分优化的编码服务层，都能够在不牺牲性能的前提下弥补供需之间的差距。

核实：代码量增加 10 倍，对准确性的要求也就随之提升 10 倍。

更低的推理成本与并行处理机制使得编码代理能够生成比以往更多的法典，因此瓶颈又发生了变化，从代码的生成转向了对代码可靠性的保障。人们自然而然地会采取更多测试和审查的措施，而且目前已经存在一些专为人工智能设计的工具：CodeRabbit、Graphite、Greptile 和 Qodo 等，它们可以用来审查代码提交并自动生成测试用例。不过这些工具仅能优化工作流程，无法确保代码的正确性，而且一个代理去审查另一个代理生成的代码时，其结果具有不确定性，还容易出现共同的缺陷。对于常规任务而言，跳过正式的正确性验证或许还能接受，但对于关键系统来说则极其危险。曾经有编码代理误删了某公司的生产数据库，而一项针对 30 多万个由人工智能生成的代码提交的最新研究显示，其中超过 15%的提交存在至少一处问题，更有 24.2%的问题在经过审查后依然存在于代码库的最新版本中。即便代码看起来“没有问题”，实际上也可能存在隐患，而人工智能审查系统根本无法分辨这种差异。

目前有两种新兴方法。以 Harmonic、Logical Intelligence、Theorem.dev、Aretta 和 Galilei AI 为代表的形式化验证技术，通过数学方式而非测试来证明代码符合规范。这类技术基于 Lean 4 之类的定理证明工具以及 SMT 求解器，能够将代码转化为可被机器检查的规范，并在新的代码被加入后生成相应的证明。该技术原本应用于航空航天和芯片设计等物理领域，如今也被用于数据库、IAM 及云基础设施等软件领域——在这些系统中，单个代理程序引入的错误就可能导致价值数百万美元的损失。另一种方法是轨迹验证：开源项目 Maida 会对比代理程序的执行轨迹与基准值，从而识别出那些只有在程序运行出现异常时才会显现的行为退化问题，比如意外的工具调用或新出现的循环结构。

这一领域尚处于早期阶段。形式化方法会带来较高的计算成本，因为每个函数都需要相应的规范与证明。跟踪验证只能检测异常，无法确保代码的正确性，因此重构与回归测试的结果可能看起来并无差异。不过发展方向十分明确：谁能让验证过程更加廉价且具备足够的适应性，从而使编码智能体在保持正确性的同时实现自主运行，谁就能在最前沿引领编码智能体 2.0 时代的到来。

我们在 Gradient 所支持的项目

第一波编码智能体解决了一个问题：模型能否编写代码？答案是肯定的。而第二波则着眼于与之相关的一切：并行运行多个智能体、以更低的成本为其提供服务，以及确保其生成的代码质量。这些都是不同的企业建设难题，我们认为在这些问题上取得成功的公司，其重要性不亚于那些专注于模型研发的机构。

该模型已经能够编写代码。而那些能够决定我们是否可以在大规模应用且控制成本的前提下信任它的公司，目前还处于建设阶段。这正是我们正在支持的技术层面。