聊天窗这个界面，本身就是一个假设
过去两年，绝大多数人与智能体打交道的入口是一个对话框。输入一句话，等它回一段话，再输入下一句。这个界面之所以流行，是因为它足够通用：任何任务都能塞进去，任何模型都能接上来。
但对话框隐含了一个前提——两边都在场。人在屏幕前，任务在几十秒内给出结果。这个前提在演示场景下成立，在真实工作里经常不成立。一条研究任务可能要跑十几分钟，一个需要签核的动作可能卡在那里等人点头，一个定时监控可能在你睡觉的时候才触发。
AWS 在 9 月开源了 Pizza Bot，切入的正是这个错位。按官方说明，它是一个自托管应用，让智能体在后台干活，把已完成的任务与待决策的事项，摆进一个邮件式的收件箱。项目采用 Apache 2.0 许可，代码托管在 GitHub，桌面端覆盖 macOS、Windows 与 Linux，另有浏览器与终端客户端。需要先说清楚一点：这不是 AWS 官方支持的服务，用户需要自行承担运维责任。
这套东西不是凭空长出来的
理解它的分量，需要看它的来路。按公开说明，这套工具的早期版本先在亚马逊内部使用，服务对象超过 2000 名员工，处理的事情包括会议准备、邮件起草、Slack 线程摘要、客户关系管理系统录入以及调研任务。之后 AWS 把它重建成开源版本对外发布。
内部先跑再开源，这一点比桌面端数量更值得关注。它意味着这套界面不是为发布会设计的演示品，而是被真实工作流反复摩擦过的产物。会议准备需要访问日历、客户记录与文档；客户关系系统录入需要写入动作；Slack 摘要需要读聊天历史。这些任务的共同点是——都不适合在对话框里盯着看。
三个视图：把「待办」和「待批」分开
Pizza Bot 的界面把智能体的工作拆成三栏。全部视图保存线程历史，相当于一个归档；未读视图放已完成、等待查看的结果；动作视图放暂停下来、需要回答或批准的运行。旁边还有一个活动面板，展示主智能体派出去的子智能体，包括各自的记录与工具调用。
这个划分方式值得留意。多数产品的做法是把「结果」和「待办」混在一条时间线里，用户自己分辨哪些要处理。把「已完成」与「待审批」拆成两个独立队列，等于承认这是两类性质不同的信息：前者只需要阅读，后者需要决策，而决策往往更慢、更容易被遗忘。
任务可以由三种方式启动：手动触发、定时调度、以及通过 webhook 触发。调度归服务器所有，不是客户端。按官方说明，如果系统在停机期间错过了若干次定时，重启后只会补跑一次，而不是把每一次错过的间隔都重放一遍。触发记录会被持久化保存。
运行时：检查点撑着「关掉窗口也不停」
Pizza Bot 的持久执行基于 DeepAgents 与 LangGraph。一个 Hono 写的 API 服务器负责运行与存储；Electron 与浏览器客户端共用一套 React 界面，所有客户端通过 HTTP 与服务器推送事件通信。LangGraph 的检查点保留线程状态与审批暂停点，另有两个独立的 SQLite 存储分别放跨线程记忆与应用元数据。重新连上的客户端可以回放缓冲的事件。
这套架构带来一个明确的边界：关掉一个线程、断开一个客户端，都不会停掉服务器上正在跑的运行。但如果你退出的是桌面应用，它内嵌的那个服务器会一起停掉，进行中的运行随之结束。检查点能保住线程，正在执行的那一步却可能丢失。也就是说，要让任务在客户端退出后继续跑，需要一个常驻后端，而不是只装一个桌面客户端。
还有一条容易忽略的限制：按公开说明，每个 SQLite 数据目录只支持一个后端进程。
模型与工具：不绑定单一厂商
模型侧，Pizza Bot 支持 Amazon Bedrock、Anthropic、Google Gemini、OpenAI、OpenRouter，以及通过 Ollama 运行的本地模型。工具侧走 MCP，同时支持用 Markdown 写的 SKILL.md 文件来定义专门的子智能体，这与 Anthropic 推动的技能约定一致。
技能的设计里有一个务实的细节：每个技能可以拥有自己的指令与一组受限的 MCP 工具。官方举的例子是，一个会议准备技能可能拿到日历、客户记录与文档工具；而随项目附带的一个浏览器自动化技能，只被授予浏览器工具，访问不到其他 MCP 服务。这种「按技能收窄权限」的做法，目的是让智能体能干什么变得可读、可检查。
另外，项目兼容已有的 Claude Code 风格的 .mcp.json 配置，插件可以把技能与 MCP 服务器打包在一起。对已经在用 MCP 的团队来说，迁移成本因此降低。
审批策略：按工具逐个配，而不是全局开关
Pizza Bot 的审批不是一刀切，而是按工具配置。技能作者可以为某个具体工具设置拦截条件与允许的决策类型，用户可以批准、修改提议的参数，或者拒绝这个动作。
这个粒度选择是对的。全局审批会把所有动作都变成等待，让人很快厌倦并开始无脑放行；完全不审批则把风险交给运气。按工具逐个配置，等于让团队把注意力集中在真正不可逆的动作上——写生产数据、发外部消息、动钱。需要提醒的是，这些控制需要针对相关工具显式配置才会生效，默认状态并不会自动帮你把关。
中立思辨
需要辩证看待几件事。其一，这不是 AWS 官方支持的服务，用户要自己承担部署与运维。开源版本还移除了亚马逊内部专用的技能与 MCP 连接，项目能否好用，很大程度取决于社区能否补上这些集成。
其二，收件箱这个比喻解决了一部分问题，也转移了一部分问题。把结果堆进队列确实比盯着对话框舒服，但「看护」这件事并没有消失，只是从屏幕前挪到了一个列表里。真正的收益取决于动作视图里的待批事项是否足够少、足够清晰。如果每天积压几十条待批，收件箱很快会变成另一个被忽略的通知中心。
其三，桌面端与常驻后端的差别，决定了这套工具适合谁。个人用户在笔记本上跑个轻任务没问题；要跑跨小时的定时任务，就必须有一台常开的机器，运维成本随之上升。
其四，模型与工具的开放是优点，也意味着责任前移。数据会经过所配置的模型提供商与工具，自托管并不等于数据不出本机。团队需要按自己的合规要求逐项确认。
其五，社区集成的进度、各客户端的成熟度差异、以及后续版本的路线，公开材料未充分展开。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
给团队的四条做法
把思路拆出来，有四条不依赖该工具也能用。
先把任务按「能不能离开屏幕」分类。几十秒出结果、需要来回确认的，留在对话界面；跑十几分钟、等审批、按定时触发的，才值得搬进异步队列。分类错了，工具再好也白搭。
按工具定审批，而不是按智能体定。同一个智能体里，读操作与写操作的风险差得很远。把门槛设在动作上，比设在角色上更精确。
为「谁来兜底」提前设计。异步运行必然有卡住的时候。要明确谁能处理动作队列、超时之后怎么办、失败的任务是否重试。这些规则不定下来，队列会变成没人认领的积压。
把常驻后端当成一个产品决策。如果要跑定时任务与跨小时任务，就先规划一台常开的机器与它的备份、升级与监控，而不是等到桌面端意外退出、任务丢了一半才发现。