AWS认为，随着AI智能体从单纯回答提问转向在后台自主完成工作，它们需要一种不同的交互界面。
该公司开源了一款名为Pizza Bot的自托管应用，为用户提供了一个用于管理委托给AI智能体工作的收件箱，其中包含正在进行任务的独立线程，以及已完成或需要人工介入工作的队列，而不再将智能体的管理局限于传统的聊天窗口内。
AWS表示，这一设计理念的出发点在于，后台运行的智能体在工作过程中并不总是需要用户持续关注，采用收件箱模式可以让用户将耗时较长的任务交给智能体处理，之后再回头查看，从而清楚了解哪些任务已完成、哪些还需要人工干预。
底层架构
这种理念也体现在收件箱的任务组织方式上：“All”标签页记录每项任务或对话的完整历史，包括智能体的消息和已执行的工作；“Unread”标签页标记出用户尚未查看的已完成工作；“Action”标签页则展示因等待用户输入或批准而暂停的任务。
AWS在介绍Pizza Bot的博客文章中写道，该收件箱界面还包含一个名为Activity的面板，向用户展示智能体处理某项具体任务的方式，并附带对话记录。
AWS以收件箱为核心的设计思路同样体现在Pizza Bot的架构中。
该应用采用LangChain的Deep Agents作为执行框架，并以LangGraph作为有状态运行环境，两者结合使智能体能够在工作过程中对进度进行检查点保存，保留其消息记录、工具使用情况和当前状态，从而使任务可以被暂停和恢复，而不是必须依附于一个实时聊天会话，这家云计算巨头写道。
Pizza Bot的服务器位于该技术栈之上，负责连接智能体运行环境与用户界面、技能模块、MCP服务器以及模型提供方，开发者可以选择Anthropic、OpenAI、谷歌Gemini和Amazon Bedrock，也可以通过Ollama使用本地模型，该公司补充道。
在开箱即用能力方面，该应用内置了处理文件、浏览网页以及将任务委派给专业智能体的技能。开发者还可以添加现有的智能体技能和MCP服务器，让智能体接入其他工具和服务，该公司写道。
企业集成或仍是障碍
不过，分析师们对Pizza Bot的开箱即用技能和对现有工具的支持能否真正降低企业实施难度并不十分认可。
IT咨询公司Kanerika的首席营收官Bhupendra Chopra指出，尽管开箱即用能力以及对现有技能的支持能为企业团队节省构建应用的时间，但这并未解决使其真正运转起来所需的集成工作。
“在企业级智能体部署中，集成环节往往是资金投入最多的部分。销售或财务团队要从智能体中获得价值，前提是它能够读取并更新CRM、邮件系统和ERP系统，而这些系统中的每一个都需要有人专门构建、保障安全并持续维护相应的连接器，”Chopra指出。
Nord-IQ Research首席分析师Manoj Chandra Jha表示，由于该应用缺乏官方支持或任何服务级别协议（SLA），Pizza Bot的集成工作可能会更加复杂。这意味着集成和运维负担最终会落到企业自身，企业需要自行负责运行、保障安全并维护这套开源软件，Jha说。
企业生产力有望提升
但对于愿意承担这部分集成工作的企业而言，这种以收件箱为核心的方式有望提升生产力。
“这是一次具有实质意义的转变，因为它改变了将工作委托给智能体的经济性。聊天界面要求人在整个任务过程中持续投入注意力，而收件箱模式只在需要人做判断的时候才让人介入，这与高管将工作委派给团队的方式颇为类似，”Chopra说。
“编程类智能体已经证明了这种模式的可行性，工程师分配一个任务，然后审查最终生成的代码提交。Pizza Bot将这种方式扩展到了会议准备和后续跟进等任务上，”Chopra补充道。
此外，该分析师指出，这种以收件箱为核心的方式还能让企业团队更清晰地掌握定期执行任务的表现情况。
“对于定期执行的任务，以线程形式呈现结果能让用户追踪后台发生的情况，并发现那些原本可能被忽略的失败案例，”Chopra说。
眼不见心不烦
然而，这种方式也存在风险：“收件箱模式可能会让糟糕的工作变得不那么容易被发现。当有人在聊天窗口中盯着智能体工作时，他们能看到智能体是否在偏离方向，”HFS Research首席执行官Phil Fersht说。
相比之下，当数百项任务在后台悄然运行时，用户可能直到任务完成或出现需要处理的异常情况时，才会发现智能体犯下的错误，这可能使问题更难被及早发现，Fersht说。
Chopra表示，这种可见性的降低还可能引发审批疲劳。
“智能体发回数十个带有多项审批请求的线程，可能会让用户习惯性地不仔细阅读就直接批准，”Chopra说。
智能体准备执行操作与用户批准操作之间的延迟也存在风险：“智能体暂停时还有效的信息，几个小时后可能已经失效，这可能导致CRM更新过时，或者发出的会议邀请对应的时间段已不再可用，”他说。“在实时聊天中可能会被及时发现并质疑的错误假设，在智能体持续基于该假设推进工作、消耗模型资源的过程中，却可能无人察觉。定期执行的任务也可能在无人实时监控的情况下不断产生额外成本。”
他表示，可以通过设计更少但时机把握更精准的审批节点，并在允许执行操作前核实底层数据是否依然有效，来应对这些弊端。
采用可能从技术团队开始
这类权衡将在很大程度上决定Pizza Bot的实际应用场景。
“采用过程很可能是自下而上的，个别技术人员和小型平台团队会被Pizza Bot的可控性和基于标准的设计所吸引，”Jha说。“不过，风险规避倾向较强的行业，尤其是受监管行业，以及技术能力有限的业务用户，可能会对该应用采取更为谨慎的态度，”他补充道。
这可能使Pizza Bot在企业中扮演一个更为聚焦的角色，成为技术团队试验异步智能体和新型工作委派方式的工具，而不会立即取代企业在业务关键流程中通常使用的受管控界面和托管服务，他说。
本文最初发表于InfoWorld。
Q&A
Q1：Pizza Bot是什么？
A：Pizza Bot是AWS开源的一款自托管应用，为用户提供收件箱式界面来管理委托给AI智能体的工作，包含进行中任务的线程和已完成或需要人工介入的任务队列，而不再局限于传统聊天窗口。
Q2：Pizza Bot的技术架构是怎样的？
A：Pizza Bot采用LangChain的Deep Agents作为执行框架，LangGraph作为有状态运行环境，支持智能体在工作中检查点保存进度，可对接Anthropic、OpenAI、谷歌Gemini、Amazon Bedrock及本地Ollama模型。
Q3：企业使用Pizza Bot会遇到哪些挑战？
A：分析师指出，Pizza Bot缺乏官方支持和服务级别协议，集成CRM、邮件、ERP等系统的工作需企业自行承担，同时收件箱模式可能降低任务可见性，增加审批疲劳和数据过时风险。
