背景
隨著 AI 代理人被派去執行的工作越來越複雜，一個實際的互動問題逐漸浮現：傳統的聊天式介面預設使用者會坐在螢幕前等待回應，但許多真正有價值的任務，例如定期巡檢多個資料來源、等待外部事件觸發後才動作的流程，往往需要數十分鐘甚至更久才能產出結果，強迫使用者盯著對話視窗並不合理。根據 InfoQ 於 2026 年 10 月 4 日的報導，一個在 AWS 任職的開發者團隊近期將名為 Pizza Bot 的工具開源，正是為了解決這個問題。它是一個可自行架設的應用程式，讓 AI 代理人在背景執行任務，並透過類似電子郵件收件匣的介面回報結果。該工具採用 Apache 2.0 授權，意味著任何人都可以自由使用、修改與散布，同時保持資料與代理人狀態留在使用者自己的機器上。
核心內容與運作方式
Pizza Bot 的核心設計理念直接借用了電子郵件的使用模式。AWS 首席技術專家 Joseph Dolivo 與解決方案架構師 Igor Fil 用一個直覺的比喻說明：使用者寄出電子郵件後，不會一直盯著寄件匣等待回信，收件匣本身就是「之後再回來處理的工作單位」。套用同樣的邏輯，Pizza Bot 把每一條執行緒（thread）視為一件可以稍後回來檢視的工作，而不是一段必須全程參與的對話。在此架構下，代理人可以依照排程自動啟動，也可以透過 webhook 觸發；webhook 是一種讓外部系統在事件發生時主動通知程式的機制，例如當表單送出或檔案更新時自動喚醒代理人。代理人執行過程中還能把子任務分派給專門的工作代理人，並在需要採取有實質後果的動作之前暫停下來，等待人工核准。
這套設計建立在四個明確的需求之上：代理人必須能檢視多個資料來源、能在背景持續工作、能在執行重要動作前請求核准，以及能在任務完成時通知使用者。介面上，收件匣把工作整理為 All（全部）、Unread（未讀）與 Action（需要動作）三種佇列，另設有 Activity 面板，顯示已委派給各專門代理人的任務及其進度。這種編排方式讓使用者可以快速判斷哪些結果已經就緒、哪些需要自己的批准才能繼續，而不是在一堆執行日誌中翻找。
技術脈絡與資料控制
在技術層面，Pizza Bot 採用客戶端與伺服器分離的架構，支援多種模型供應商、MCP 伺服器與 Agent Skills。MCP 全名為 Model Context Protocol，是一套讓 AI 模型以標準化方式連接外部工具與資料來源的協定，解決了過去每個工具都要各自撰寫整合程式的問題；Agent Skills 則是把特定任務的知識與操作流程封裝成可重複使用的能力模組。值得注意的是其本地優先的設計：代理人的狀態、執行緒、檢查點、附件與日誌全部保存在使用者控制的資料夾中，憑證存放於作業系統的密鑰儲存區。作者明確指出，使用者可以控制哪些資料離開機器，系統只會把提示詞與附件送到使用者選定的模型供應商，並只向明確啟用的 MCP 伺服器發出工具呼叫。不過他們也提醒，這些 MCP 伺服器可以代表使用者執行動作，安裝任何一個伺服器之前都應該理解它擁有什麼權限，這點在評估第三方整合時尤其重要。
起源、迴響與限制
專案名稱直接致敬 Amazon 知名的 two-pizza team 文化，也就是團隊規模應小到兩個披薩就能餵飽的組織慣例。Dolivo 在 LinkedIn 上記錄了專案的演變：2025 年 4 月，他以一個名為 JoeBot 的業餘專案起步，目標是自動化繁瑣重複的 CRM 資料登錄工作。這個工具對技術使用者效果很好，但當非技術背景的同事得知後也想使用，促使它逐步演變成今天這個通用介面。兩位作者在 Hacker News 上表示，專案靈感來自 LangChain 一篇關於 ambient agents 的文章；ambient agents 指的是不等待使用者逐條下達指令、而能在背景持續觀察與運作的代理人，這正是目前 AI 代理人領域備受關注的方向之一。
早期社群迴響以正面為主，焦點集中在非同步收件匣模式與本地優先架構，認為這比對話式介面更符合長時間任務的實際工作方式。不過也有評論者提出質疑：市面上已存在多個目標相似的工具，Pizza Bot 是否能累積足夠的差異化價值仍待觀察；另一個疑問是，開源版本能否重建內部版本賴以成功的技能與整合生態系，畢竟一個工具框架本身不等於圍繞它形成的整合資產。此外必須注意的是，Pizza Bot 是社群專案而非 AWS 官方服務，因此沒有 AWS 技術支援，也不附帶服務等級協定。採用者需要自行負責維持服務運作、定期備份與版本更新。對於願意自行維運、重視資料控制權、且需要讓代理人在背景長時間工作的團隊而言，它提供了一個值得評估的開源選項，但其成熟度與生態系發展仍需時間驗證。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。