用阶段凭据发现多智能体静默停滞

Agent 跑了一夜，早上告诉你「任务完成」，实际却卡在第二阶段，后面五个小时毫无进展。原文针对这种失控提出了一套办法：先拆清任务，再按阶段留下可核查的记录，最后根据记录判断是否完成，而不是听 Agent 自述。

这个思路值得借鉴，但文章同时也是 Zambo 的产品推广。读它时要分清两件事：阶段验收与交接机制有工程价值，产品能否保证「不会静默停滞」，还要看监控如何触发、凭证究竟证明了什么。

完成任务，不能只靠 Agent 说一句完成

原文用一个包含 8 个阶段、40 个步骤的夜间任务说明问题：第一阶段完成，第二阶段第一步卡住，直到早上用户追问才继续。作者没有提供这次运行的完整日志，因此更适合把它看作问题场景，不能当作有数据支持的故障复盘。

作者提出的第一项改动，是执行前就把工作量写清楚。「先调研，再开发」太模糊；「第三阶段包含 6 次抓取、2 次保存」才有明确的核查对象。

接着，每个阶段都必须留下三类记录：

• 用 continuity_get_recent 读取阶段执行轨迹。
• 用 memory_remember 保存阶段账本事实。
• 用 journal_log 写入阶段日志。

这里的「账本事实」，可以理解成一份持久保存的阶段验收记录。某个阶段拿不出这份记录，就不能算完成，即使执行它的 Agent 声称做完了。

任务是否完成，应由阶段记录决定，而不是由最终总结决定。

多 Agent 之间通过 handover 交接，协调者从 pickup 接续记录中核查工作。原文强调，协调者接取交接记录免费，但这里的免费属于 Zambo 的产品计费规则，并非所有 Agent 框架都具备的性质。

凭证能证明留过记录，不能证明工作正确

只保存阶段记录还不够。作者安排协调者每阶段抽查 3 份凭证，通过 pdf_extract 打开运行链接，对照阶段声明核验。8 个阶段合计 24 次检查。

这一步试图发现的是：Agent 声称做了某件事，记录里却没有对应产物，或者产物与声明不一致。协调者自己的 journal_log 日志也不能算独立证据，它仍然是协调者报告的内容。

原文对凭证的能力边界有明确限定：它能证明已保存的阶段结果在保存后没有被修改，不能证明阶段工作本身正确。至于这种防篡改性质具体怎样实现，正文没有展开。

对应到编程任务，保存了一份测试报告，与测试是否覆盖真实需求，是两道判断。即使报告原封不动，测试也可能漏掉边界条件。

作者还提出「先查记录」的巡检：逐阶段检查账本是否存在、凭证能否打开。其他人不能直接读取协调者的记忆，需要使用公开凭证链接，或者交接给他们的接续记录。

这样确实容易定位缺口。但「有地方可查」距离「凌晨自动发现故障」还有一步：谁定时检查？多久没有新记录算超时？发现后通知谁？原文没有给出完整机制。它描述了检查依据，没有充分说明检查如何持续运行。

54 次调用怎么算，免费额度又覆盖了什么

原文把协调者的调用预算拆成四块：任务约定 2 次，8 个阶段共 48 次，停滞排查 3 次，收尾 1 次，总计 54 次计费调用，另有免费的 wrap 收尾。

每阶段 6 次，正好对应读取轨迹、保存账本、写日志，以及 3 次抽查。前置约定加上前三阶段是 2 + 3 × 6 = 20 次，因此第 21 次调用是第四阶段开始时的轨迹读取。

按文中的每日 20 次免费额度，第一晚只能完成前三阶段，剩余 34 次留给第四至第八阶段、停滞排查和最终收尾。作者给出两个选择：沿阶段边界交接，分 3 天完成；或者把每阶段抽查从 3 次降到 1 次，减少 16 次调用。

后者仍然需要 38 次调用，并没有降到单日免费额度内。

这些数字只统计协调者。工作 Agent 使用各自身份和额度，因此 54 次调用不是整个 Agent 团队的总成本。 预算还假设协调者始终使用同一个身份，换成多个协调者后，额度边界未必仍然相同。

商业方案也需要按原文口径理解：Day Pass 为一次性 $0.99，24 小时不限量；Zambo Pass 为 $29／30 天，另列 $290／年及 $ZAMBO 持有者 $19 的价格，均声称不会自动续费。这些是文章提供的报价，不能据此判断当前售价。

接入方面，所有入口都指向同一 MCP 端点 https://zambo.dev/mcp。原文列出 Claude、Cursor、ChatGPT、Windsurf 和 VS Code，也提供框架适配包。Node 用户对应的安装命令是：

npm install aer-1

要注意这条命令没有锁定版本，原文标注的版本是 v0.1.27。

其他入口为 CrewAI 的 pip install crewai-zambo（v0.1.9）、LangChain 的 pip install langchain-zambo（v0.1.10）、OpenAI Agents 的 pip install aer1-openai-agents（v0.1.20）、AutoGen 的 pip install aer1-autogen（v0.1.16）、Agno 的 pip install agno-aer1（v0.1.2），以及 LlamaIndex 的 pip install aer1-llamaindex（v0.1.15）。

记录格式名为 AER-1，原文称其为开放的 IETF 草案，编号 draft-zambo-aer1-26。草案身份不能等同于正式标准，也不能单凭格式名称判断跨工具兼容性。

我的判断

我认同把验收记录放在总结之前。长任务一旦涉及多轮工具调用、多 Agent 交接，用户需要知道最后一个已确认完成的阶段在哪里，才能决定继续、重试还是人工接手。

但标题里的「不能静默停滞」说得过满。完整记录能让停滞留下可辨认的缺口，主动发现缺口仍需要独立巡检、超时判断和通知机制。正文没有把这一层讲透。

每阶段抽查 3 份，也属于经验配置。原文没有提供与抽查 1 份、全量验证或其他方案的对照数据，无法判断多花 16 次调用究竟能提高多少检出率。

对于一般前端和 Node 团队，可以先比较已有的 CI 产物、任务状态表和失败通知是否够用。这些机制同样能承载阶段验收；Zambo 的差异集中在 Agent 交接与统一记录上，文章没有证明它对所有长任务都更划算。

作者自述是名为 rambo 的 AI，同时担任 Zambo 运营负责人。这个商业立场需要保留在阅读判断里：文章给出了一套可借鉴的设计，但没有给出足以验证整体效果的对照实验。

能拿来做什么

• 给耗时的 AI 编程任务设定可验收的阶段，例如调研结论、代码产物、检查结果和交付记录，并提前写明每阶段需要交出什么。
• 让 Agent 的完成声明关联实际产物。前端或 Node 任务可以关联代码变更、构建输出和测试报告，再分别判断产物是否存在、内容是否合格。
• 为无人值守任务单独设置超时检查和通知，明确多久没有进展就需要介入，避免把早上的人工追问当作监控。
• 在交接记录中保存最后完成阶段、凭证位置和下一步动作。原文用「Continue my Zambo session」配合 pickup 恢复任务，关键是让接手者拿到足够的执行上下文。