Pizza Bot：给后台 AI Agent 一个可自托管的任务收件箱

预计阅读时间：9 分钟

大多数 AI 助手都围绕即时对话设计：用户提出问题，模型立即返回答案。但代码审查、报表生成、数据核对和运维诊断往往需要运行数分钟甚至更久，中途还可能等待人工批准。由一支在 AWS 工作的开发者团队开源的 Pizza Bot，试图用“收件箱”而不是聊天窗口来承载这类后台任务。

Pizza Bot 是一个可自托管应用。Agent 可以按计划运行，也可以由 Webhook 触发；主 Agent 能把工作委派给专门的 Worker，并在执行敏感操作前暂停，等待人工确认。它更接近 AI 任务控制台，而不只是又一个聊天机器人界面。

为什么收件箱适合后台 Agent

同步聊天隐含了一个前提：请求和响应发生在同一次短连接中。后台 Agent 则有不同的生命周期：

用户、定时器或外部系统创建任务。
Agent 在后台读取上下文并执行工具调用。
任务可能被拆分给多个专业 Worker。
高风险步骤进入等待状态，由人批准或拒绝。
最终结果回到收件箱，供用户稍后查看。

这种模型把“提交工作”和“消费结果”解耦。用户不必保持浏览器页面打开，调用方也不需要让 HTTP 请求等待十几分钟。对团队而言，收件箱还能自然表达几种重要状态：待处理、运行中、等待审批、成功和失败。

需要注意的是，收件箱只是交互层，不会自动解决后台执行的全部难题。生产部署仍然需要考虑任务持久化、重复投递、超时、重试、权限隔离和审计日志。

调度、Webhook 与 Worker 分工

Pizza Bot 支持计划任务和 Webhook 触发，这覆盖了两类常见场景。

计划任务适合周期性工作，例如：

每天汇总错误日志并生成简报；
每周检查长期未更新的工单；
定期扫描依赖更新并给出升级建议；
在工作日早晨整理待审批事项。

Webhook 更适合事件驱动流程。例如，代码仓库收到 Pull Request 后创建审查任务，监控系统发出告警后触发诊断，或者客服系统收到高优先级工单后要求 Agent 整理上下文。

任务委派则能避免一个“全能 Agent”持有所有工具和权限。可以将 Worker 按职责划分：

log-analyst 只读取日志和指标；
code-reviewer 只读取仓库并生成审查意见；
report-writer 负责整理结果，不接触生产环境；
deployment-worker 可以执行发布，但必须经过人工批准。

这种拆分不仅是提示词工程，也是一种权限边界。每个 Worker 应只拿到完成任务所需的最小凭据。

可以这样接入 Webhook

下面是一个可直接改造的事件发送脚本。由于来源摘要没有给出 Pizza Bot 的具体 API 路径和字段，示例采用通用 Webhook 契约；运行前需要把 URL、令牌以及 JSON 字段映射为实际部署所要求的格式。

#!/usr/bin/env bash
set -euo pipefail

# 修改为 Pizza Bot 部署提供的 Webhook 地址和密钥。
export PIZZA_BOT_WEBHOOK_URL="https://pizza-bot.example.com/webhooks/tasks"
export PIZZA_BOT_TOKEN="replace-with-a-secret"

curl --fail-with-body \
  --request POST \
  --url "$PIZZA_BOT_WEBHOOK_URL" \
  --header "Authorization: Bearer $PIZZA_BOT_TOKEN" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "event_id": "pr-482-opened",
  "task": "Review pull request 482 and summarize correctness, security, and test risks.",
  "worker": "code-reviewer",
  "context": {
    "repository": "acme/payments-api",
    "pull_request": 482
  },
  "approval_required_for": [
    "post_comment",
    "merge_pull_request"
  ]
}
JSON

这里有三个值得保留的设计，即使实际字段名称不同：

event_id 用作幂等键，避免 Webhook 重试时创建重复任务；
worker 明确任务应交给哪个专业 Agent；
approval_required_for 把读取与写入操作分开，防止 Agent 未经确认就评论或合并代码。

如果触发方支持签名，生产环境应优先使用 HMAC 签名验证，而不是只依赖静态 Bearer Token。还应限制请求体大小、设置时间戳容差，并记录事件 ID，防止重放攻击。

人工审批不是弹窗，而是状态机

“执行前询问用户”听起来简单，落到后台系统中却应该被建模为持久状态。一个任务可以采用如下状态转换：

queued -> running -> waiting_for_approval -> running -> completed
                    |                         |
                    +-> rejected              +-> failed

当 Agent 请求审批时，系统至少应保存：拟执行的动作、目标资源、参数摘要、风险说明、申请者、审批者和过期时间。批准之后也不应盲目复用旧计划；如果目标资源在等待期间发生变化，Worker 应重新校验前置条件。

例如，“发布新版本”不能只显示一个确认按钮。审批卡片最好明确列出环境、版本、变更集和回滚方式。对于删除数据、修改权限或向外部系统发送消息等不可逆操作，可以要求双人审批或短时有效的凭据。

落地前的检查清单

Pizza Bot 展示了一种值得关注的 Agent 产品形态：任务异步运行，结果进入收件箱，专业 Worker 分工执行，关键节点由人接管。它尤其适合耗时较长、结果可以稍后消费，并且需要审计或审批的工作。

在团队中试用时，可以从低风险、只读任务开始，并检查以下事项：

是否能持久化任务状态，服务重启后能否继续处理；
Webhook 是否具备鉴权、签名校验、幂等和重放防护；
每个 Worker 是否使用独立、最小权限的凭据；
超时、重试和部分失败是否有明确策略；
审批请求是否展示了足够具体的操作内容；
Prompt、工具调用、审批和最终结果是否可审计；
敏感数据是否会进入模型上下文或长期日志；
是否设置并发、令牌消耗和外部 API 成本上限。

不要一开始就让 Agent 自动修改生产系统。先让它生成报告，再允许它起草操作，最后才逐步开放经过审批的写入能力。收件箱解决了人与后台 Agent 如何协作的问题，而真正决定系统能否上线的，仍然是权限、状态和失败处理是否足够扎实。