Agent 跑几天，卡住的地方通常不是模型
Google Cloud 的 Agent 102 workshop 被整理成 6 层架构。Shoopy 的图工程长文讲了另一件事：单 agent 循环什么时候该拆，拆完以后人的注意力又成了新瓶颈。
一个 agent 跑三分钟和跑三天的区别，不在模型参数。跑三分钟，请求结束，进程结束，什么都没留下。跑三天，它要在周二下午等你批预算，在周三凌晨服务器重启后从同一个节点继续，在周四下单前再查一次座位，还不能因为重试多扣一次钱。
Shoopy 把 Google Cloud Agent 102 workshop 的内容整理成 9 页总结，拆成 6 层。他在回复里说明，这不是 Google 官方 PDF，原始 session 在 Annie Wang 的 YouTube 频道。
6 层分别是 Trigger、Runner、State、Resumable Workflow、Human Gate、Guards。
第一层 Trigger。模型不能自己设闹钟。调度器打一个 /wake 端点，agent 才会再跑。这句话听起来像废话，但很多 agent demo 默认模型会记得回来，其实不会。
第二层 Runner。adk web 是开发工具，不是生产环境。你的服务器要自己持有 runner、sessions 和 storage。
第三层 State。session 放真实数据库，用户偏好放在 user: 下，事实放 memory。重启不能丢东西。
第四层 Resumable Workflow。把服务器在队列中间杀掉，它从同一个节点恢复。已经完成的步骤不重跑。这一层是长期运行 agent 和聊天机器人的分水岭。
第五层 Human Gate。agent 申请预算，然后停下来等一个 yes。这个暂停也要跨重启。有网友追问 pending approval 是否持久化，Shoopy 回复说，它作为 event 存在 session 里，配合持久 session 和 resumability，重启后答案会回到同一个节点。
第六层 Guards。买之前重新检查座位，每个订单一个 idempotency key。重试不会重复扣款。有网友说，任何花钱的 agent 都不能重试成双扣，Shoopy 同意，retry-safe or don't ship it。
这 6 层里，最容易被跳过的是第 5 层和第 6 层。它们不产生演示效果，只防止你在凌晨三点被账单叫醒。
Shoopy 还写过一篇更长的文章，叫 Graph Engineering。核心判断是：一个 agent 在循环里可以计划、写代码、测试、review，但任务一复杂，上下文窗口会满，推理会退化，人又回到椅子上读每一个 diff。
他的解法是把工作拆给专家节点。一个节点分类，一个节点修，一个节点 review，一个节点重试。然后用边把工作路由起来，用状态把信息传下去。节点做事情，边决定下一步，状态是沿边流动的共享数据。循环是最小图，图工程不替代循环，它在循环上面。
但不是所有任务都值得画图。Shoopy 给了四个问题：失败会重复吗，不同失败类型需要不同处理吗，写 fix 的 agent 是否不该批准 fix，单 agent 循环是否已经是瓶颈。任何一个答案是否，就继续用循环。
真正落地时，有几个细节比架构图更重要。一个节点一个动词，分类的节点不修，修的节点不 review 自己。工具范围要收窄，reviewer 不能写文件，fixer 不能合并 PR。硬约束不要放 prompt 里。prompt 是建议，边是代码。路由规则要写在边逻辑里，因为 prompt 可能在长会话的第 47 轮被忽略。
状态也不要广播。每个节点只拿自己需要的那一片。分类器拿原始日志，fixer 拿分类结果、失败测试名和最近的 diff。如果每个节点都读全量状态，你得到的不是图，是一个更臃肿的上下文窗口。
门是另一个被低估的部分。硬门是测试、类型检查、lint、构建，过了就是过了。软门是第二个模型 review，比没有门强，但比测试弱。人门是 merge 或 deploy 前的最后一步。Karpathy 的规则在这里很直接：任务可验证，就可优化。Cherny 给过一个数据点，给 Claude 有效的验证方法，通常能把最终输出质量提升 2 到 3 倍。Anthropic 的多 agent 研究也提到，把 agent 拆成隔离上下文的专家，在内部研究基准上比单 agent 基线提升 90.2%。
图工程最后讲了两笔债。理解债务会随着图替你写代码而增长，安静运行的系统看起来像进步，但仓库里存在的东西和你真正理解的东西之间的差距在收利息。认知投降更隐蔽，图自己跑的时候，人很容易停止形成判断。缓解办法不技术：读每一个 diff，抽查门，把图限制在小的、机器可验证的任务上，找个人一起设计图。
到这里，问题从模型转到了人。
Volodymyr Gutorov 在回复里说，从一个循环走到专家图提升了吞吐，但也增加了停下来等人的节点。盯 4 到 5 个 Claude Code 会话本身就是一份工作。他做了一个桌面 OLED 设备，叫 Claude Mate，用来标记哪个会话 done、waiting 或 errored。
设备有两个版本。Arduino Nano 版走 USB，128×32 单色 OLED，三个按键。ESP32-S3 版无线，172×320 彩色屏，14500 电池，四个按键，还能在设备上看某个会话终端的实时镜像。两个版本说同一套协议。屏幕只显示一个会话，底下一条字母带显示整个队列的状态：E 错误，B 等待，W 工作，D 完成，I 空闲。LED 用不同节奏提示最严重的未确认告警，按键 GO 会把对应终端窗口提到前面。
它解决的不是 agent 能不能跑，而是多 agent 并行以后，人的注意力往哪放。有网友说，图给了你宽度，成本落在人身上，planner、coder、reviewer 并行以后，工作变成判断哪个分支卡住了。Claude Mate 把这件事压成一个小屏幕和一个按钮。
项目在 GitHub 上，非商业许可。没有硬件也能试，终端里跑 claude-mate 就是同一套界面。
大多数团队现在还用不上图。先把一个循环跑通，把状态落库，把重试做成幂等，把该停的地方停下来等人。如果循环已经是瓶颈，再按节点、边、状态、门去拆。长期运行 agent 的默认配置不复杂：等待交给调度器，状态交给数据库，恢复交给工作流，钱交给人工门和幂等键。剩下的，是读 diff。
参考链接：
发布时间: 2026-10-27 22:48