多个 AI Agent 同时工作时，谁来接住它们的问题？Plannotator Inbox 实战
当 AI 编程 Agent 只运行几分钟时，把问题直接显示在终端里很自然。但现在的任务越来越长：一个 Agent 在跑测试，另一个在改前端，第三个还在等待你决定 API 方案。人不可能一直盯着三个终端窗口，Agent 的提问、阻塞和待审查变更也不应该埋在滚动日志里。
Plannotator Inbox 解决的是这个“异步交接”问题。它是 Plannotator 的本地 Inbox：Agent 在工作期间把问题、计划、原型和审查请求写进去，人稍后打开浏览器阅读并回答，答案再作为会话的下一步交给 Agent。它不是另一个聊天机器人，而是一个让长时间运行任务拥有收件箱的决策界面。
先安装，再启动本地 Inbox
官方页面给出的安装方式是下载脚本，然后启动 Inbox：
curl -fsSL https://plannotator.ai/install.sh | bash plannotator inbox
服务监听在本机 127.0.0.1，线程、回答和决策会保存到 ~/.plannotator 下的文件中。这个设计很适合开发机使用：问题不会先经过第三方 SaaS，Agent 也不需要把项目上下文上传到远端面板。
Inbox 页面会把尚未处理的项目集中起来。你可以先回答一个阻塞问题，再回头审查另一个 Agent 生成的 diff，而不是在多个终端之间寻找“它刚才到底问了什么”。
它和 Agent 自带终端有什么不同？
终端适合观察当前运行中的 Agent；Inbox 适合处理你没有实时观察的运行。一次完整的交接大致是：
- Agent 写入一个问题、计划、原型或审查请求，并附上相关上下文。
- 人在 Inbox 中选择选项、评论计划，或在原型和变更上添加批注。
- 点击发送后，回答成为该会话的下一轮输入，Agent 继续执行。
计划审查尤其适合放在这里。你可以在计划的具体行旁边评论，确认方案后再把决定发送出去。如果 Agent 在发送后修改了计划，Inbox 会提示版本变化，避免你审查的是已经过期的内容。
原型也不只是一个附件。页面支持在原型上固定评论，内容可以包含 Markdown、HTML、Mermaid 和 Graphviz。对于“这个流程图的第三步应该改成异步”这类反馈，直接标注位置比复制一大段文字更清楚。
如何连接不同的 Agent
Plannotator 页面列出了多种接入方式。Claude Code、Pi 和 OpenCode 可以通过相应的集成把内容写入 Inbox；其他 Agent 则可以把 Inbox 作为本地 MCP Server 使用。例如页面给出的 MCP 配置命令是：
codex mcp add plannotator-inbox -- plannotator inbox mcp
页面还提供了 Codex、Cursor、VS Code、Gemini CLI、Zed、Goose、Amp 和 Cline 等客户端的接入说明。这里要注意边界：Inbox 的核心是本地线程和 MCP 连接，不代表每个客户端都拥有完全相同的原生插件能力。接入前应按自己的 Agent 查看对应步骤。
一套更稳妥的团队流程
个人使用时，可以把 Inbox 当成“稍后处理”的队列：Agent 开始长任务后离开终端，等需要决策时再处理线程。团队使用时，建议把它和下面的规则配合起来：
- 先要求 Agent 提交计划，再允许修改关键目录。
- 涉及数据库、权限和部署的决定必须人工确认。
- 审查 diff 时要求 Agent 给出变更摘要，但以真实 diff 为准。
- 发送前检查线程中的上下文是否完整，避免只回答一个脱离背景的选项。
- 对重要决定开启项目级记录，让后续 Agent 能读到已经确认的约束。
Inbox 能减少上下文丢失，却不会替你判断答案是否正确。它也不是权限隔离、测试套件或代码审查器的替代品。对于高风险操作，仍应保留最小权限、自动化测试和可回滚变更。
总结
长时间运行的 Agent 最大的问题之一，不是它不会工作，而是它会在你不在场时提出问题。Plannotator Inbox 把这些问题从终端滚动信息变成可异步处理的线程，并把回答重新送回 Agent。它尤其适合多个 Agent 并行、远程开发和需要反复审查计划与原型的工作流。
如果你的痛点是“Agent 经常问我，但我总是在两天后才看到”，这种本地 Inbox 比再开一个聊天窗口更贴近问题本身：它保留会话上下文，也让人类决定真正成为执行流程的一部分。