作者运营一个名为 r2 的 Agentic Harness（智能体运维框架）三个月后，总结出四点经验。

第一，收件箱胜过任务列表。作者将工作队列从 Asana 迁移到 Gmail，让 agent 按邮件顺序处理。agent 处理时邮件归档到 processing 标签，完成后或需要人工介入时返回收件箱。agent 从不永久归档邮件，只有作者本人可以。收件箱变成了“等待你”的表面。之前有 24 个线程 无声沉寂在错误标签下，现在它们会带着一行原因浮出水面。

第二，路由是必需的基础设施。一个模型作为路由器，区分三种层级：本地快速模型、本地推理模型、云端回退层。本地任务平均耗时 4-6 分钟，云端任务约 39 秒。本地成本低，云端可靠。路由器需要知道某个任务能承受哪种模式，并记录真实的上云原因——而不是假装本地失败来作为升级理由。

第三，自我修复有效但脆弱，且会先暴露更多错误，再减少错误。之前六周内 agent 的错误率为零，之后先升到 15%，再升到 34%。这不是系统变差，而是系统不再隐藏失败。修复前，21 个线程 被困在错误状态，最老的已经 18 天，用手工 SQL 恢复了 112 次。修复后，失败立即暴露，经过四次带抖动的回退重试后进入死信队列。目前 0 个线程 处于错误状态。但暴露错误不等于修复。系统已自动回滚了 65 次 不良部署，其中 42 次 因单元测试失败。自七月底起，系统在部署前就能捕获坏代码，坏的主分支从未上线。但认证失败仍需人工刷新令牌，内存限制需要人工处理，模型“只叙述却不动手”也需要人工察觉。

第四，即使在免聚商进攻中也需要四分卫。工作不再是单一的大段提示词，而变成了一个由节点组成的图模型产出狭窄的 JSON 意图（动作、领域、理由、置信度），确定性代码执行写入操作，独立节点再读一遍来确认。制造者和验证者是不同节点永远不让 agent 给自己的作业打分。这种分离让剧本可以无需聚集就能跑。但不能取消四分卫。仍需要有人来决定哪些任务该上云、哪些失败需要人工介入、哪些部署需要回滚。三个月后，那个四分卫还是作者自己，他坐在一层代码之上而那层代码过去是整个团队。