1. Refactoring Hermes with 1,393 agents
- 作者/来源: Teknium / Nous Research
- 发布日期: 2026-09-15
- 原文: https://nousresearch.com/refactoring-hermes-with-1393-agents
推荐理由: 这是近期少见的、把大规模 multi-agent coding 运行过程写得足够具体的真实工程复盘。Hermes 没有让 1,393 个 Agent 随机冲进同一个仓库,而是由 orchestrator 先测量代码库、切成互不重叠的工作组,再用 git worktree、冻结基线、接口对比和逐步提交控制并行修改。它展示的不是“Agent 数量越多越好”,而是 如何把一个原本不可并行的大型重构转化成可以被机器调度和验证的工作图。
核心要点:
- 主 Agent 做协调,不直接写代码。 Hermes 把代码库划分成 36 个不重叠区域,为 worker 生成明确任务说明;worker 在独立 git worktree 中修改,有些 worker 继续向下委派,任务树最多延伸三层。主 Agent 负责读报告、集成分支和跑检查,而不是和 worker 争抢同一份 working tree。
- 验证边界比并行规模更重要。 对外接口会与原版本做精确比较,例如 tool JSON schema 必须一致、CLI
--help输出可以逐字节比较;失败测试还会在冻结的原始 baseline 上重跑,以区分“本次改坏”还是“原本就坏”。即便如此,社区 review 仍发现了被误删的 public names 和约 65 处异常处理语义变化,说明现有测试没有覆盖所有兼容性约束。 - 结果显著,但需要正确理解。 非测试 Python 从 1,063,826 行降到 698,363 行(-34.4%),5,000 行以上文件从 37 个降到 6 个,300 行以上函数从 192 个降到 2 个;主 run 约 19 小时、最高 218 个 worker 同时运行,模型成本约 19,300 美元,含后续修复约 25,000 美元。作者同时明确指出,他们测到的是代码查找 token 降低,并没有证明重构后 Agent 完成工程任务一定更快。
核心启示:大规模 Agent 并行的核心不是“开更多 Agent”,而是先把工作变成
可切片任务 + 隔离工作区 + 明确接口 + 可执行验证 + 可恢复状态。真正可扩展的是 harness,而不是并发数字。
2. Context Is the New Codebase.
- 作者/来源: Justin Bartak / Orbyt Labs
- 发布日期: 2026-09-17
- 原文: https://www.orbytlabs.ai/blog/context-engineering
推荐理由: 这篇最有价值的地方不是再解释一遍“什么是 context engineering”,而是作者给出了一个月、35 个真实 Agent 工作 session 的读取数据,并据此重新定义优化目标:Agent 系统的大头不是输出 token,而是每一轮反复读取的 context。 这使 CLAUDE.md、constitution、spec、tool result 和历史轨迹从“辅助提示词”变成需要像源码一样治理的运行时资产。
核心要点:
- 35 个 session 中,context read 与 output 的比例达到 285:1。 作者记录了约 17.07B context-read tokens 与 59.9M output tokens,平均每个 turn 会重新读取约 504K tokens;三条超过 6,000 turns 的长 session 就占了当月约 60% 的总消耗。对于长时程 Agent,成本近似是
context size × turn count,而不是只看生成了多少 token。 - 重型 artifact 一旦进入主 loop,会被持续“复读”。 76 次图片读取产生约 9.4M tool-result tokens,占作者统计的 tool-result volume 的 47%,平均一次图片约 123K tokens,而且后续每个 turn 都会再次携带这些内容。作者的处理方式是把图片、巨型文件和探索式扫描隔离给 subagent,只把压缩后的结论返回主 Agent。
- Context 文件应具备代码级治理。 standing instructions 应压缩成会真正改变行为的规则;独立 tool calls 尽量 batch,减少重复读取完整上下文;constitution/spec 应进入版本控制、有 owner,并用检查机制发现失效规则或 drift。作者把 spec 视为 interface、tests 视为 executable requirements、stale/contradictory context 视为会影响所有 Agent 的 behavior bug。
核心启示:Context engineering 不只是 retrieval,而是一套 read-side systems engineering:
budget → isolate → batch → compress → version → test。当 Agent 反复读取同一环境时,一条多余规则或一个重型 artifact 都会被按 turn 数放大。