关于「智能体能不能干重活」，争论了几个月，大部分论据还停留在演示视频。Nous Research 这次给了一个可以算账的样本：让自家的 Hermes Agent 重构自己家的代码库——大约一百万行 Python，连续跑了十九个小时，动用了 1393 个子智能体，最后代码库体积缩减了 34.4%。
先把账摆出来。模型侧的花费约 1.93 万美元；按公司估算，同样的活交给人类工程师要做将近 200 万美元工时的量。十九小时对几个月，两个万美元对两百万美元，这组对比足够有冲击力。但做工程的人都清楚，这类账本有个经典的盲区：验证成本没有入账。重构一百万行代码，真正的风险不在「改」而在「改完之后对不对」——回归测试怎么设计的、谁审的合并请求、出问题怎么回滚，这些细节官方披露有限，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
抛开数字，这个案例的样本价值在另一个地方：Nous 选的是「重构」而不是「写新功能」。重构是最适合多智能体的场景——目标明确（行为不变、体积变小）、可机械化验证（测试套件）、可以切分成大量独立小任务。1393 个子智能体的并行分工，本质上把代码库切成了上千个互不干扰的作业面。反过来，如果让智能体直接给产品写新功能，需求理解和方案取舍就没法这么干净地切分，效果会大打折扣。
所以这篇案例的正确读法不是「工程师要失业了」，而是「多智能体适合什么活，边界比想象中清楚」。高重复、强验证、可并行的任务先被吃掉；需要品味、需要跨域权衡的任务还早。对工程管理者来说，更有用的动作是盘一盘自己代码库里有多少「重构型债务」——这部分恰恰是现有智能体最擅长啃的。
成本曲线也值得记一笔。1.93 万美元的模型花费，放在两年前是个不可想象的数字——不是太贵，而是太便宜：同等规模的模型调用当时根本买不到这种执行长度和稳定性。多智能体工程的真实门槛已经从「跑不起」转移到了「验证不起」，算力在贬值，而信任与评审的人力在升值。这个此消彼长，会重塑未来几年工程团队的编制逻辑。
还有一个细节值得琢磨：Nous 让智能体重构的是自己的代码库。这算是一种极端形式的吃自己的狗粮——Hermes 本身就是产品卖点，用它管理自身代码，等于每天都在生产环境里做压力测试。这种「自举式验证」比任何 benchmark 都诚实，也解释了为什么这一轮智能体落地案例里，开发者工具公司总是跑在前面：他们手里有最顺手的验证工具链。
想跟进复刻的团队，可以先把手头的任务做个筛选：代码库有没有像样的测试覆盖率、模块边界清不清楚、改动能不能按目录或服务切出互不干扰的作业面——这三条决定了多智能体重构是省钱还是添乱。中小型项目里，人机协作的节奏可能更划算：智能体出方案和初稿，工程师做关键决策与合并把关，把十九小时的全自主留给那些边界干净、验证充分的场景。工具在进化，但怎么用工具的分寸感，短期内还是人的活。