2026 年 9 月 · 5 分钟阅读

关键定义
后台 agent(background agent) 不等待用户输入、在后台持续或定时运行的 agent——夜间对账、定时研究、批量文档处理。它与交互式 chat agent 的关键区别:用户不在场,产出物需要事后查看与决策。
Inbox 模式(收件箱模式) 把 agent 产出物按「已完工(Unread)/待你决定(Action)」分开排队、人回来处理而不是在场观看的监督界面。AWS 2026-09-10 开源 Pizza Bot 将其做成可自托管的参考实现。
给 agent 一个真正值得委派的任务,你会发现自己变成了 babysitter——盯聊天窗口滚动,等它停在一步需要你批准的地方。AWS 本周开源了 Pizza Bot(2026-09-10,Apache 2.0),把「后台 agent 的产出」变成收件箱:完工进 Unread,等批准的进 Action。这看起来是个小工具,实际是一个被大厂内部验证过的监督模式:异步 agent 需要异步监督界面,监督是排队决策,不是盯日志。
AWS 官方博客的表述值得原文引用:「你不发一封邮件然后坐着盯发件箱等回信。」Pizza Bot 的界面形状和邮件客户端一样的原因就在这:thread 是一个你回来处理的工作单元,不是一个你必须出席的会话。它起源于亚马逊内部,早期版本有 2000+ 人用于会议准备、邮件起草、Slack 摘要、CRM 记录、每日优先级与网络研究,然后从零重写为开源项目(AWS 官方博客,来源见文末)。
架构上它坚持「运行在你能拥有的地方」:自托管、无遥测;服务器拥有 agent 状态、通过 HTTP 响应,桌面端、浏览器与终端都可以当客户端;运行有 checkpoint,中途退出只丢正在飞的那一步,不丢整个 thread。模型供应商自由选(Anthropic、Bedrock、Gemini、OpenAI、OpenRouter,甚至本地 Ollama);工具走 MCP;技能用 SKILL.md 的 Markdown 约定。
最有工程价值的是两个机制:interruptOn 是 per-tool 的批准策略——哪些工具调用必须停下来等人,allowedDecisions 决定你看到的按钮;edit 允许你直接修改 agent 的提案,而不是拒绝后从头重跑。安装 MCP server 或插件是显式决策——运行代码之前先让你确认权限。
Chat 界面假设双方在场:快速问答成立,几分钟以上的任务就崩。后台与长时 agent 的监督表面必须是「你回来处理的东西」,而不是「你在场观看的过程」。三个设计要点值得任何团队抄走:第一,产出与待决分离——把「agent 做完的」(Unread)和「agent 要你决定的」(Action)分开排队,人一回来就能按优先级处理,不用从日志里翻;第二,可编辑的批准——纠正 agent 的提案比重跑便宜,也更接近真实协作;第三,监督数据不外包——自托管、无遥测、自带模型,agent 的产出与批准记录留在你拥有的地方。
这个判断在我们的日常运营里有实证。OOMeta 的每日 cron 管道就是同一模式的实例:agent 在夜间把信号整理成摘要队列,人工评审后决定行动;没有变化的批次输出 [SILENT],不刷屏。Unread/Action 分离与我们的信号纪律是同一个原则——把需要人决定的事,从噪声里分出来排队。后台 agent 规模越大,这个原则越贵:每多一个无人监督的异步 agent,就多一条没人看的日志。
① 重新设计产出物:每个后台 agent 的输出是一封信,不是一段日志
信的结构固定:做了什么、证据在哪、需要谁决定什么。写不出「需要谁决定什么」的产出物,说明任务还没拆到可监督的粒度。
② 定义批准点:哪些工具调用要 interruptOn
默认低风险动作直接做,高风险动作停下来等人。逐工具列批准策略,而不是给 agent 一把全权限钥匙。
③ 让纠正成为一等操作:拒绝之外要有 edit
监督的价值在于把人纠正 agent 的成本降到最低。只能 reject-and-rerun 的监督界面,会让监督者倾向于「算了就这样吧」。
④ 划数据边界:需要时才让数据出环境
自托管加本地模型(Ollama)是敏感数据工作流的默认选项;数据可以出环境时再上托管模型。
挑一个每周重复的工作流(夜间对账、定时研究简报、批量文档整理),用 Pizza Bot 或同款 inbox 模式跑两周,记录三个数:需要人工介入的次数、每次介入的决策时长、agent 产出物被直接采纳的比例。第一个数告诉你自动化到什么程度才安全;第二个数告诉你监督本身贵不贵;第三个数告诉你 agent 质量有没有过线。
留给买家的决策问题:你的后台 agent 现在是在「发信」,还是在「滚动日志」?如果答案是后者,问题不在 agent,在监督界面。
OOMeta AI
OOMeta 的每日运营就是 inbox 模式的实证:夜间 cron 把 agent 产出整理成摘要队列,人工评审后决定行动;无变化的批次输出 [SILENT],不刷屏。把需要人决定的事从噪声里分出来排队,是我们信号纪律的核心,也是我们为客户设计后台 agent 工作流时的默认原则。
预约诊断会参考来源:AWS Open Source Blog《Introducing Pizza Bot, an open source inbox for AI agents that work in the background》(2026-09-10)https://aws.amazon.com/blogs/opensource/introducing-pizza-bot-an-open-source-inbox-for-ai-agents-that-work-in-the-background/ · Pizza Bot GitHub 仓库 https://github.com/pizza-bot-app/pizza-bot
AWS 于 2026-09-10 开源的 Apache 2.0 应用:给后台运行的 agent 一个邮件式收件箱,完工进 Unread、待批准进 Action。它起源于亚马逊内部(早期版本 2000+ 人使用),用 DeepAgents/LangGraph 做有状态运行时,MCP 接工具(AWS 官方博客)。
Unread 是 agent 已完成、你还没看的产出;Action 是停在半路、等你批准或回答的工作。这个分离把「agent 做完的」和「agent 要你决定的」分开排队——监督从盯日志变成排决策。
interruptOn 是 per-tool 的批准策略:配置哪些工具调用必须停下等人;allowedDecisions 决定你看到的按钮。edit 允许你直接修改 agent 的提案而不是拒绝重跑——纠正比重启便宜,也更接近真实协作。
默认不会。Pizza Bot 自托管、无遥测,默认只监听本机,状态存在你自己的文件夹;模型供应商由你选,甚至可以用 Ollama 跑本地模型。安装 MCP server 或插件是显式决策,不是副作用。
OOMeta 的每日运营就是同一模式的实证:夜间 cron 把 agent 产出整理成摘要队列,人工评审后决定行动;无变化的批次输出 [SILENT] 不刷屏。Unread/Action 分离与我们的信号纪律是同一个原则——把需要人决定的事从噪声里分出来排队。
公共榜单测不出私有代码:Real-SWE 揭示编码 agent 的真实水位
首个用私有生产代码评测编码 agent 的基准(2026-09):最强组合 Fable 5.1 解决率仅 38.8%,短任务失败率 71.4%≈长任务 73.4%,99% 企业 token 对模型不可见。我们的判断:公共榜单是选型幻觉,私有域 eval 才是唯一可信信号。
FDE 战争东移:商品化的是部署,不是证明
09-10 一天三件事:Moonshot 组五家中国 SI 联合 FDE 团队、Palantir 把 Fujitsu 变成 Global FDE Partner、Sakana×SCSK×住友借约 10 万客户铺渠道。FDE 从自建军团变成可租通道——但装完后 agent 动作由谁独立核验,三个市场空白一致。
Docusign 把合同层开放给所有 Agent:9 月 30 日起 MCP 客户端可直接调用
9月4日 Docusign 宣布其 MCP Server 将于 9 月 30 日向所有 AI Agent 开放:Claude、ChatGPT、Gemini、Copilot、Slack 等任何 MCP 客户端都能原生调用合同分析、发送与签署,由 AI 引擎 Iris 注入历史谈判与政策上下文。签署动作需要企业级治理。
Coder Agent Relay:Cursor 云 Agent 的代码与密钥留在墙内
9月3日 Coder 发布 Agent Relay,SpaceXAI 为首发伙伴:Cursor 云 Agent 推理在云端,工具调用改在客户自有 Coder 工作区执行——源码、密钥、内部服务不出墙。受监管行业首次能用上前沿编码 Agent。Gartner:2027 年 80% 软件工程师需为生成式 AI 升级技能。