让 Agent 长跑，现在已经不难了。开个定时任务、扔一个目标进去，它就能自己找资料、写代码、改表格，甚至顺手把结果发出去。
真正难的是另一件事：你怎么知道它干完了，以及它是不是干了不该干的。
聊天窗口是很差的监工。你得守着，关掉客户端任务就断，第二天早上只剩一堆日志要翻。上周 AWS 开源了一个叫 Pizza Bot 的项目，专门解决这个问题——它不做 Agent 框架，它给 Agent 装了一个收件箱。
Pizza Bot 是什么：把 Agent 的活变成”邮件”
Pizza Bot 是一个自托管应用，把后台 Agent 的工作结果组织成邮件式的界面。它的收件箱分三个区：
- All：所有任务的完整历史，按主题串成一条条 thread；
- Unread：已经干完、等人过目的活；
- Action：被挂起、等你点头或者回答问题的活。
这个划分看着简单，但它对准了一个真实痛点。Agent 跑长任务的时候，输出的不是一条能读完的答案，而是几十步中间过程。你不需要看每一步，你只需要知道”哪几件已经完成”和”哪几件卡住了”。
更有意思的是它的设计前提。项目团队在发布说明里写得很直白：“这个界面假设你根本没在看。” 别的产品默认你盯着屏幕，它默认你已经睡了。这一个假设，决定了它能做三件别的东西做不了的事：审批暂停可以跨会话保留、通知值得看而不是噪音、定时任务产出的是可回溯的 thread 而不是一坨 log。
顺便说一句，这东西不是新概念白纸。它的前身是 AWS Startups 首席技术专家 Joseph Dolivo 2025 年 4 月的一个副业项目 JoeBot，用来做重复的 CRM 记录。内部版本在亚马逊内部跑过，用过的人超过 2000 个，场景包括会议准备、邮件起草、Slack 汇总、CRM 归档和调研。
技术底座：DeepAgents + LangGraph，状态落在 SQLite
拆开看，Pizza Bot 的结构比它的名字靠谱得多。
- 运行时：Agent 引擎用 LangChain 的 DeepAgents，跑在 LangGraph 上，走的是有状态执行那一套；
- 持久化：LangGraph 的 checkpoint 会把 Agent 状态存下来，所以一次运行可以停在审批点、可以扛住客户端断线，之后接着跑而不是从头再来；
- 存储：thread 和其他应用数据存在本地 SQLite 和普通文件里，数据目录默认在
~/.pizza-bot-oss； - 客户端：macOS、Windows、Linux 桌面端都有，另有浏览器和终端客户端，都通过 HTTP 和服务器推送事件跟后端通信；
- 模型：Amazon Bedrock、Anthropic、Google Gemini、OpenAI、OpenRouter 都能配，也能接本地 Ollama。
有一个细节值得单独拎出来：关掉客户端不会停任务，但退出桌面 App 会。 桌面端默认内嵌一个本地服务，App 一退，内嵌服务跟着停，正在进行的那一步有可能会丢（checkpoint 保住 thread，保不住飞行中的那一步）。想让活在你合上笔记本之后继续跑，就得把后端放到一台常开机或容器里。
还有个八卦可以当参考：AWS 自己是有 Agent SDK 的（Strands Agents），但团队最后选了 LangGraph。Dolivo 的解释是 LangGraph 的长期有状态工作流工具更成熟、生态更广、开发者更熟，而且既然要开源，就得先降低上手摩擦。
审批不是摆设：能改参数再放行
Pizza Bot 里我最喜欢的设计，是它对”危险动作”的处理方式。
它用 SKILL.md 定义每一个专职 worker，里面除了写指令，还能声明两样东西：tools 是这个 worker 允许调用的 MCP 工具清单，interruptOn 是逐工具的审批策略，allowedDecisions 决定你在收件箱里能看到哪几个按钮。
关键在于按钮里有一个 edit——你可以直接改 Agent 提出的参数再放行，而不是只能”拒绝，然后从头再来一遍”。这个差别在实际使用里非常大：Agent 写好了邮件、定好了会议时间，只差一个收件人写错了，你改一下就行，不用把整个任务推倒重跑。
另外两条安全设定也算克制：一个 skill 只有它声明的 MCP 服务器和工具真的可用时才能被调用，界面上会明确标出哪个 skill 目前跑不起来；安装 MCP 服务器或插件等于在你的权限下执行代码，所以安装是一个显式的决定，而不是顺手点一下的副作用。
四步上手
想试的话，路径不长：
- 装起来：从仓库拉桌面端安装包，或者直接跑独立后端。数据目录默认在
~/.pizza-bot-oss，一个 SQLite 数据目录只允许一个后端进程，别重复起。 - 配模型：进 Settings，在 Providers 里选 Bedrock、Anthropic、Gemini、OpenAI、OpenRouter 或 Ollama。有数据不能出机器的场景，直接选本地模型。
- 接工具：把 MCP 服务器配上。这里有个省事的地方——你已有的 Claude Code 兼容
.mcp.json可以直接放进去用。想让它自己上网页，它内置了一个基于 Playwright MCP 的浏览器自动化 skill。 - 写自己的 skill：普通 SKILL.md 加两个字段就行。把发布、付款、删除这类工具写进
interruptOn，让 Agent 到这一步必须等你。
任务是手动触发、cron 定时、webhook 三种都支持，调度由服务端负责。有个细节值得知道：服务端宕机重来之后，错过的 cron 时段只会补跑 1 次，而不是把错过的每一次都重放一遍——这个取舍是对的，否则恢复瞬间会被自己堆的任务淹掉。
三个真实场景
场景一：早起看结果，而不是半夜盯着。 把行业资讯汇总、竞品价格巡检、站点异常扫描这类活挂成 cron，晚上跑，早上你打开收件箱只看 Unread。这类定时汇总任务，本质上跟 AI Agent 任务队列怎么设计 里讲的思路是一个路子，只不过这次队列、状态和通知被打包成了一个现成的应用。
场景二：审批型流程。 起草客户回复、生成报价单、提交工单——Agent 把活干到 95%，最后一步挂进 Action 区等你。写得对不对、参数改不改，你在收件箱里一次处理完。
场景三：数据不出门。 接 Ollama 跑本地模型，公司内部资料整理、会议纪要归档这类活全部在机器上完成。这在你想用云 Agent 又不敢上传资料的时候，是一条现实的路。
如果你之前看过 我用邮箱远程调度 Codex 那篇，会发现这是同一个思路的工业化版本：那篇是自己拼一套邮箱工作流，Pizza Bot 是把这套东西做成了带状态、带审批、带 MCP 的自托管应用。
优缺点说实话
优点：
- 不绑云。Apache 2.0，代码在独立 GitHub 组织里，数据默认留在本机；
- 模型自由切换，本地模型也是第一等公民；
- 审批粒度细到单个工具，而且支持改参数放行；
- MCP 生态直接复用，Claude Code 的配置文件能拿来就用；
- 定时、webhook、常开后端三种部署形态都覆盖了。
缺点也很明显，先说清楚再上手：
- 它是社区项目，不是 AWS 服务。 官方明确说不提供 AWS 支持和 SLA，跑不跑得住、备不备份、升不升级，都是你自己的事。这点跟 Anthropic 把 Agent 配置变成仓库文件 那类”官方产品”完全是两种关系。
- 内部那批现成 skill 被摘掉了。 Pizza Bot 在亚马逊内部好用，很大程度靠的是内网现成的技能和 MCP 集市；公开版重建时这些被移除了，因为都是针对亚马逊自家系统做的。所以你得自己补 skill 和 MCP，作者也直说这块最需要社区帮忙。
- 桌面端退出即断。 想要真”无人值守”，必须上常开主机或容器，多一份运维成本。
- cron 错过只补跑 1 次。 可靠性设计上的取舍，密集调度场景要自己留意。
- 项目很年轻。 一天就攒不出生态，能好用到什么程度，得看你自己的工作流跟它的假设合不合。
适合谁，不适合谁
适合：手上有稳定的重复性 Agent 任务的开发者和小团队；在意数据不出内网的团队；已经在用 MCP 和 Claude Code 生态、想找个统一收件箱的人；愿意自己维护一台常开机器的技术型用户。
不适合：想要开箱即用 SaaS 的人；没有常开主机、也不打算配的人；指望有商业支持兜底的企业生产系统。
替代方案上，顺手的几个：要框架不要应用的，可以把 LangChain 的 Agent Inbox 思路 自己接起来；要更轻的编排，Dify 和 n8n 够用；目标只是让 Cursor 在云端跑长任务，Cursor Projects 更省事；想让办公软件自己干几小时，微软 Opal 是另一条线；自己拼邮箱管道，上面那篇老文 的脚本还能直接用。
更多的工具横向对比，可以翻 AI 工具评测专题。
老达点评
Pizza Bot 这个名字起得随意，但它戳中的位置很准。
过去一年 AI Agent 的关键词一直是”能跑多久、能干多复杂”，各种 持久模式 和长任务方案层出不穷。但真实使用里，卡住人的往往不是能力上限，而是交接成本：Agent 干完了，人得从头读一遍才知道发生了什么；Agent 要动手了，人得守在屏幕前点头。这两个成本不降下来，Agent 再强也只是个需要全程陪护的实习生。
Pizza Bot 的聪明之处在于它选了”邮件”这个比喻。邮件最擅长的事情不是传递信息，而是异步——发的人不用等，收的人不用守，状态天然可追溯。把它套在 Agent 上，收件箱就顺手变成了任务队列、审批台和审计日志的三合一。这个思路，跟 MCP 从有状态改到无状态、让 Agent 真正能上生产（去年那次协议大改）是同一层楼里的推演。
不过我得泼一点冷水。它是社区项目，不是产品。 亚马逊内部那 2000 人用着舒服，是因为背后有内网现成的技能集市和一整套基础设施；公开版把这些摘掉之后，你拿到的更像是”一套好的架构示范 + 一堆需要自己填的坑”。它真正适合的，是那些本来就在自己维护 Agent 工作流、愿意为自己写 skill 的人——对他们来说，它省掉的是搭状态机和审批界面的功夫，这部分工作其实不小。
如果你现在还没有稳定的后台 Agent 任务，建议先别急着部署。先问问自己：有没有哪件事是”每天/每周都要做、步骤固定、中途不需要我做决定”的？ 有，Pizza Bot 就是它的归宿；没有，那你缺的不是收件箱，是任务本身。
常见问题
Pizza Bot 是 AWS 官方产品吗？
不是。它是 AWS 员工发起并开源的社区项目，代码在独立的 GitHub 组织里，采用 Apache 2.0 协议，没有 AWS 官方支持，也没有 SLA 承诺，需要你自托管。
关掉笔记本，任务还能继续跑吗？
只有后端在常开主机或容器里运行时才可以。用桌面端默认的内嵌服务，退出应用会结束正在进行的运行；thread 会由 checkpoint 保留，但飞行中的那一步可能丢失。客户端断开连接则不影响服务端任务。
支持国内常用的模型吗？
通过 OpenRouter 可以接入大量第三方模型；需要完全本地化时，接 Ollama 跑本地权重即可，数据不必离开机器。
