15 小时删掉 37.5 万行代码，Coding Agent 开始自己带团队了

今天看到一件挺夸张的事。

Nous Research 联合创始人、Hermes Agent 创建者 Teknium，给 Hermes Agent 下了一个目标：大幅清理自己的代码仓库。

一个 /goal，一台桌面电脑，连续工作大约 15 个小时。按照 Teknium 的说法，Hermes 不断简化、合并、优化和删除代码，最后让整个仓库少了 37.5 万行。

第一眼看，这像是又一次“AI 干了个大活”的故事。

我看完原帖，脑子里冒出来的问题是：这么多 Subagent，到底是谁在管？

这 15 个小时里，主 Agent 组织着一批又一批 Subagent 检查、修改和汇总代码。与其说它在展示一个模型多会写代码，不如说它在试着运行一支软件团队。

先把几个夸张的数字说清楚

Teknium 的原帖里提到，整个过程出现了大约 120 个 Subagent 的波次，还有 3 组各 15 个 Subagent。这些 Subagent 又可以继续创建自己的 Subagent，也就是递归委派。

几分钟后，他又补了一句：当天这场会话里，一共有 1320 个 Subagent “诞生又消失”。

这不是 1320 个 Agent 同时运行，而是 15 个小时里累计启动过的 Subagent。至于峰值并发到底有多少，原帖说得并不清楚，没必要替它推算一个更吓人的数字。

37.5 万行也只是 Teknium 公布的结果。目前还没有完整的代码差异、删除内容、模型成本和最终测试报告公开出来。它可以算一次大规模实验，还不能直接叫作一次成功的自动重构。

变化出现在工作方式上：一个长时间目标交给主 Agent，它自己拆任务、分配工作、检查结果，再一轮轮推进。15 个小时里，Teknium 没有逐个打开上千个终端，也没有挨个告诉 Subagent 下一步做什么。

Goal Mode 不是新功能，组织方式才是看点

Coding Agent 帮人整理旧项目、删除重复逻辑，早就不是什么新能力。

Hermes 自己也有一个 simplify-code Skill，会让四个 Reviewer 分别从代码复用、质量、效率和抽象层次检查近期改动，再由主 Agent 汇总哪些修改值得执行。

它使用的 /goal 也不是 Hermes 首创。Hermes 官方文档写得很坦白：这套实现直接受 Codex CLI Goal Mode 启发。

这类机制会把目标和完成标准一起交给 Agent。只要目标还没有达到，它就继续下一轮，直到完成、暂停，或者需要人补充信息。

这次 Hermes 做的，是把长期目标、大规模代码清理和递归 Subagent 接在一起，连续跑了 15 个小时。原来由人负责的拆解、委派和追进度，开始被放进 Agent 系统内部。

未来可能只需要一个对话窗口

我一直觉得，Claude Code 和 Codex 不会是 Coding Agent 的最终形态。

它们已经很好用了。但大部分时候，人还是要坐在电脑前，告诉它下一步做什么；方向不对了纠正，测试失败了再让它继续修。

Agent 干了很多活，人依然承担着项目经理和调度员的角色。我们负责拆任务、选择模型、切换工具、决定什么时候再开一个 Agent，最后把不同 Agent 的结果拼起来。

这让我想起以前在诺基亚的时候，我参观过工厂。车间里面一个人都没有，全是高度自动化的生产设备，人在外面。

这种场景后来也出现在物流行业。京东官方介绍过全无人仓，旺季每天可以处理超过 130 万单；顺丰也曾在报告中写到，在一些物流场景里，包裹从卸车、供件、分拣到装车已经可以全流程无人化作业。

机器和系统照常运行，人不用再守在每一个操作位上。

未来的 AI 可能也会经历这个变化。电脑、IDE、代码仓库和各种 Agent 都会继续存在。变化的是，人不用再坐在电脑前，盯着它们一步步工作。

比如我说：“我们想给产品增加一个新的会员功能，你先研究用户需求，做一版方案。”

主 Agent 可以让产品 Agent 整理需求，让研究 Agent 分析竞品，让设计 Agent 出交互；方案确定后，再交给 Coding Agent 开发、测试 Agent 检查、安全 Agent 审核。它平时自己推进，只在碰到产品选择、数据风险和生产发布时回来找我确认。

我不需要分别打开 ChatGPT、Figma、Claude Code、Codex 和一堆测试工具，可能只需要面对一个对话窗口。

表面上只有一个入口，背后仍是一套分工明确的 Agent 系统。开发环境、浏览器、设计工具、测试设备、云服务器和权限系统都不会少，它们只是从人的工作台，逐渐变成 Agent 调用的执行节点。

Coding Agent 的未来，可能更像一家软件公司

当任务开始连续运行十几个小时，甚至以天为单位运行，决定体验的就不只是模型写代码的能力了。

主 Agent 会不会规划，能不能把任务拆清楚，是否知道该把工作交给谁；不同 Agent 修改同一个项目时会不会冲突；出了问题能不能回滚；遇到高风险操作，会不会停下来找人确认——这些能力都会变得重要。

这时的 Coding Agent 更像一家小型软件公司。模型是工程师，Skill 是工作方法，工具和沙箱是办公环境，测试和评审负责质量，主 Agent 负责理解目标、分配工作和控制进度。

模型能力当然仍然重要，只是当后台同时跑着产品、设计、开发、测试和安全等角色时，系统怎么组织它们，会直接影响成本和结果。

Agent 越多，管理问题也越突出。更多 Subagent 可以提高扫描和执行速度，也可能让不同 Agent 做出局部正确、全局冲突的修改。递归委派缺少统一的目标、权限和验收标准，错误同样会被快速放大。

权限隔离、操作审计、成本控制、数据安全、结果验收和责任边界，一个都绕不过去。一个对话窗口可以把复杂度藏起来，复杂度并不会消失，只会转移到 Agent 系统内部。

AI 写代码太快，清理代码反而成了新工作

这次实验还有一个挺现实的提醒：代码写得越快，项目也越容易变胖。

发现一个问题，让 Agent 补个判断；需要兼容旧方案，再加一层封装；新方案已经上线，旧实现却还留在仓库里。同一种能力被实现好几遍，局部补丁不断叠加，测试、脚本、配置和文档也越积越多。

人写代码会产生技术债，AI 写代码同样会产生，而且可能积得更快。未来的主 Agent 要会安排其他 Agent 写代码，也要知道何时停下来整理，把已经没有价值的东西删掉。

代码清理还有一个直接的价值：省钱。

今年 5 月，两位研究者做了一组对照实验：让 Claude Code 在 6 组最小对照仓库上完成 33 个任务，一共跑了 660 次。代码是否整洁没有显著改变最终通过率，但明显改变了 Agent 的工作过程。

在更干净的代码仓库里，Agent 消耗的 Token 少了大约 7%—8%，文件重访减少了约 34%。

代码干不干净，未必决定 Agent 最后能不能把任务做完，却会决定它要绕多少路、读取多少上下文，以及最后花掉多少钱。

过去整理代码，主要是为了让下一个程序员看得轻松一点。以后整理代码，也是为了让下一个 Agent 少读一点、少猜一点、少烧一点 Token。

现在还只是一次实验

Hermes 这次清理还缺少完整 diff、成本和验收结果，代码行数本身也不是质量指标。原有功能是否保持、测试是否通过、性能有没有退化、依赖关系有没有变简单，这些问题比“删了多少行”重要得多。

先别急着把它当作大型软件项目已经可以无人接管的证明。把它放在今天看，它更像一场产品预演：人给出目标和边界，主 Agent 组织后面的模型、工具、机器和其他 Agent。

短期看，每个开发者可能都会有一个 Coding Agent。再往后，公司可能会有一个统一的 Agent 工作入口。员工告诉它想完成什么，系统自己决定应该让谁来做、在哪里做，以及什么时候回来找人；人只负责目标、边界和关键判断。

一个成熟的 Agent 系统，应该让你平时不用盯着；到了需要做决定的时候，它会回来。