待验证｜Nous称1393个Agent重构Hermes

Nous Research在9月15日发布《Refactoring Hermes with 1,393 agents》，把Hermes Agent重构自身代码库的经历写成公开复盘。本期新闻钩子应落在9月15日的新增披露：运行规模、成本、代码变化和失败教训同时被写入可引用文章；9月4日的PR合并只是背景节点。

可以确认的部分包括：博客页面标注发布时间为2026-09-15T15:00:00Z；GitHub PR #102117公开可见且状态为Merged；Nous称主运行派发了1,393个subagents，峰值达到218个同时运行，主运行持续约十九个active hours，PR在September 4合并，非测试Python源码减少34.4%。

需要降级的部分同样关键。上述运行规模、模型成本、人工替代成本和“零行为变化”主要来自Nous或PR标题自述；GitHub页面能证明PR存在、合并和部分描述可见，却不能单独证明没有行为回归。Nous博客自己也写到，社区审查发现了被移除的公开名称，以及约65处suppress()重写带来的异常处理变化。

对开发者有价值的是方法边界，通用生产力倍率仍缺证据。这个案例说明多Agent可以把大型代码卫生任务拆成可并行审查的批次；它也提醒团队，生成diff只是开始，接口兼容、中断恢复、行为验证和失败经验回灌会决定工程账是否成立。

这次新增了什么

Nous的文章标题是“Refactoring Hermes with 1,393 agents”，副标题口径更激进：用约$19K token成本获得$1.8M价值。早报采用更窄的表述：这是Nous对一次Hermes自我重构的复盘，值得看，因为它把多Agent工程任务第一次写得足够具体，可以被外部读者逐项拆开。

根据博客叙述，Hermes仓库到9月已有超过百万行非测试Python源码，gateway/run.py单文件达到34,847行。9月2日，Teknium向自己日常使用的Hermes Agent下达目标：大幅简化代码、减少行数、拆开大文件、合并重复helper、提升可读性，并要求最终提交PR或一组PR。

运行方式并非一个Agent连续改代码。Nous称主Agent扮演协调者：先测量代码库，将任务拆成36个不重叠组，再为worker写任务说明。worker在独立git worktree里修改，避免彼此覆盖文件；一部分worker又继续委派子任务，最终形成三层以下的任务树。主Agent负责读报告、整合分支、跑检查，源码编辑主要分散给worker完成。

这个设计对Hermes本身有特殊加成。Hermes功能概览文档列出工具系统、skills、持久记忆、项目上下文、子Agent委派、代码执行和批处理等能力。Skills文档进一步说明，skills是按需加载的知识文档，可记录程序性经验和项目内规则。换句话说，Nous讲述的核心是一个长期使用的Agent把过去代码审查、失败复现和PR流程沉淀为可复用指令，再把这些指令下发到大规模重构中。

数字该怎样读

下面这组数字很醒目，但它们仍不构成独立benchmark。PR可见性给了外部核查入口；效率和成本仍主要是Nous自己的口径。

指标	Nous披露或PR可见口径	早报读法
子Agent数量	1,393个	主运行派发规模，未见完整任务树公开
同时运行峰值	218个	说明调度压力很高，不等于每个worker都产出有效修改
主运行时长	约19个active hours	运行时钟口径，不含全部人工审查和后续修复
PR合并时间	September 4	PR已合并；本期新增是9月15日复盘
非测试Python源码	1,063,826行到698,363行	对应34.4%减少，仍需结合diff语义看行为影响
大文件数量	37个到6个	文件拆分可改善可读性，也可能增加跨文件跳转
`gateway/run.py`	34,847行到5,512行	最大文件被拆解，是结构变化的可见证据
主运行模型成本	约$19,300	Nous自报estimated model cost，非公开账单审计
含跟进成本	约$25k	Nous称包含follow-up sessions，不含人类review时间
手工估算	$150k-$1.8M	范围很宽，对应两个月到两年小团队工作量

PR页面的Open Graph描述也显示了“1,063,826 -> 698,363 source LOC”“-34.4%”“37 -> 6”和gateway/run.py 34,847 -> 5,512等口径。这比纯营销推文更强，因为至少可以追到公开PR和diff入口。但“zero behavior change”仍是维护者主张，不能自动视为外部事实。

Nous还给出一组面向Agent可读性的测试：在前后两个版本中模拟查找同一批4,000个symbols，每次先搜索定义、读取60行窗口，必要时再以2,000行窗口继续读取。博客称平均每次lookup返回token从2,218降到993，需要第二次读取窗口的lookup从628降到184。这个数字可以说明大函数收缩降低了某类检索成本，但不能证明“Agent完成工程任务更快”；Nous原文也写明，他们没有测量agents completing engineering tasks。

过程里的风险比成果更有参考价值

这篇复盘最值得保留的部分，是Nous没有把失败完全抹掉。运行约50分钟时，供应商认证token过期，相关失败杀死了主运行；worker提交和brief保留下来，随后通过另一个Hermes会话诊断并准备handoff，再让恢复后的会话回去检查已保存改动、修补未完成提取并继续。

这说明大规模Agent执行的难点远超“让模型会写代码”。系统要能处理凭证过期、子任务失联、上下文恢复、分支整合和审查闭环。Hermes案例比常见的“AI写了多少代码”更有信息量，因为它暴露了调度系统本身承压时会产生什么工程问题。

代码质量风险也没有消失。Nous写到，reviewers发现worker删除了一些仓库内没有调用方、但外部插件可能import的公开名称。这是典型的大规模清理风险：静态引用图看起来安全，公共API边界却在仓库之外。另一个例子是自动改写Suppress()或suppress()一类异常处理时，约65处改变了异常语义。这些问题在合并前经过社区审查和修复，但它们反过来说明测试覆盖并不足以单独约束这类重构。

后续的GitHub issue #103563还把这次运行拆成一次“forensic post-mortem”线索：它提到同一次运行产生93,284 calls和$19,302.59估算成本，并把缓存、认证、失败可见性、目标循环和工具摩擦等问题拆成多项修复。不过这个issue本身也是项目内部追踪材料，不是第三方审计。早报把它视为“Nous在继续复盘调度系统”的补充证据，而不是独立验证。

为什么这仍然值得报道

低置信不等于没价值。Hermes这次重构案例的价值在于，它把Agent工程从“模型能力展示”推进到“组织过程样本”：一个长期运行的工具记录用户偏好和项目规则，将任务拆给隔离worker，跨worktree并行执行，再把审查结果和失败经验回灌到下一次运行。

这与普通代码助手不同。普通助手的边界通常是单次上下文、单个IDE会话或一次PR建议；Hermes叙述的边界是跨会话记忆、skills沉淀、子Agent调度和项目级工作流。若这种模式成立，AI工程工具的竞争点会从“谁能写出某段函数”转向“谁能维持可审查的长周期工程状态”。

但外推必须谨慎。Hermes重构Hermes是强自指场景：维护者非常熟悉项目，skills来自日常开发，目标是代码卫生而非新功能，且项目愿意承受大规模重构带来的review成本。换成企业遗留系统、弱测试仓库、合规受限代码库或多团队共享API，风险结构会明显不同。

从组织经济账看，约$19,300主运行成本与约$25k含跟进成本听起来低于人工估算，但人工估算跨度从$150k到$1.8M，对应两个月到两年。这么宽的区间本身就说明它更像管理层粗估，而非严格成本模型。更完整的账应至少包含任务定义、人类review、回归测试、后续bug修复、知识迁移和维护者信任成本。

早报观点

早报判断是，Hermes案例的中心信息在工程约束：任务必须可拆，接口必须可比对，worker必须隔离，恢复必须可追踪，审查发现必须能进入下一轮规则。1,393个Agent和成本估算提供了叙事张力，但真正能被其他团队吸收的是这套控制面。

本文保持低置信，是因为Nous给出的数字足够具体，PR也公开可见，但效率倍率和“零行为变化”仍缺少独立审计。对其他团队来说，可复用的经验在于把大规模Agent任务当成分布式软件工程来管理，不能停留在$19K换$1.8M这个口号。

如果未来Agent coding真的进入团队生产系统，决定成败的不会是单个模型能否写出局部patch，而是组织能否为它提供稳定的基线、边界清楚的公共API清单、自动化兼容性检查和足够严格的人工审查入口。Hermes这次复盘提供了一个方向，也同时暴露了这条路的成本。

信源审计

这条新闻的信源层级需要明确分开。Nous博客是一手来源，负责发布时间、运行规模、成本估算、过程叙述和局限。GitHub PR #102117是主证据之一，负责确认有公开PR、状态已合并、标题与摘要中含34.4%源码减少等口径。Hermes功能概览和skills文档只提供产品背景：它支持持久记忆、skills、隔离subagents和相关协作机制。Nous X只证明9月15日社区传播和官方转述，不提供独立验证。

这意味着本文不会把“节省近200万美元工程时间”写成既成事实。更保守的说法是：Nous自估人工成本为$150k-$1.8M，时间为两个月到两年；实际模型成本约$19,300，含跟进约$25k；这些估算排除了人类审查时间，并且没有给出外部团队可直接套用的任务复杂度基线。

成本审计还缺什么

PR合并后的缺陷轨迹，是判断这次重构净收益的第一类证据。如果 #102117 后续持续出现兼容性、导入路径或异常处理修复，那么这次重构的净收益需要重新计算。反过来，如果后续维护者能证明大文件拆分显著降低新功能开发和bug修复时间，它才更接近一个正向工程样本。

Hermes自身的产品变化，是第二类证据。认证过期、子Agent失联、公共名称删除、异常处理语义变化和worker资源争用，都属于长跑Agent会反复遇到的问题。它们若变成默认检查、任务模板和调度保护，才说明这次自我重构转化成了系统能力。

外部复现决定这是不是可迁移方法。最有说服力的证据来自不同团队在不同仓库、不同测试覆盖和不同公共API边界下，用可公开审查的流程完成类似规模的代码卫生任务，并给出完整成本、审查和回归数据。

成本口径也需要补齐。模型账单只是Agent工程账的一部分。长周期任务还要算人类定义目标、处理失败、审查大diff、维护迁移文档、安抚插件作者和修复尾部回归的时间。只有这些成本都进入表格，多Agent重构才可能成为预算决策，而不是一次成功故事。