AI Agent架构实战：三个月总结四条教训

我的 agent 错误率从零飙升到百分之三十四。就在那一刻，在 Agentic Harness 中运行三个月所得出的四条经验教训终于浮出水面。

第一，收件箱优于任务清单

清单优于信息流，原因只有一个：你能一目了然。所以我把工作队列从 Asana 迁移到 Gmail，并构建了一个 agent 来处理它。agent 工作时，邮件线程归档在处理标签下。当它完成或需要我介入时，线程会重新回到收件箱。Agent 永远不会永久归档邮件——只有我会。收件箱成了"等待你处理"的界面。过去有二十四个线程静默地堆积在错误标签下，现在它们带着一行说明重新浮现。

第二，路由至关重要

一个模型演变成了路由器：快速的本地 worker、本地推理器、云端 fallback 分层。本地运行每个任务需要四到六分钟，云端运行约三十九秒。本地成本低廉，云端则稳定可靠。路由器的职责是判断任务应该选择哪种路径，并记录任务实际切换到云端的真正原因——而不是虚报一个本地失败来解释升级的理由。

第三，自我修复有效，但很脆弱

自我修复有效，但很脆弱，而且它暴露的错误比修复的错误更多。六周时间里我的 agent 错误率一直是零。然后它升到了百分之十五，又升到了百分之三十四。错误率上升不是因为系统变差了，而是因为系统不再隐藏失败。修复前，二十一个线程困在错误状态中，最久的已停滞十八天，一百一十二次恢复都是通过手写 SQL 完成的。修复后，失败立即浮现，以抖动退避重试四次，然后进入死信队列。如今零个线程停留在错误状态。但暴露错误不等于修复错误。系统现在会回滚自己的不良部署，迄今六十五次，其中四十二次是因为单元测试失败。自七月底以来，它在部署前而非部署后捕获损坏代码。损坏的 main 分支永远不会发布。不过，认证失败仍需要人工刷新 token。内存限制仍需要人工介入。一个只会叙述而不干活的模型，需要人工才能注意到。

第四，即使在无喊话进攻中，你仍然需要一个四分卫

工作不再是一个庞大的 prompt，而是一张由契约节点组成的图：模型产生一个狭窄的 JSON intent、一个 action、一个 domain、一个 reason、一个 confidence score。确定性代码执行写入操作。独立的节点重新读取以确认。Maker 和 verifier 是不同的节点——永远不要让 agent 评估自己的作业。这种分离让战术无需喊话就能执行。但它并不能移除四分卫。仍然需要有人来指挥那些重要的战术：哪个任务去云端，哪个失败需要人工介入，哪个部署需要回滚。三个月过去，那个四分卫仍然是我，坐在曾经是整个团队的代码之上的那一层。