Zero 中的 A2A 是什麼？
Zero A2A 是產品內部代理之間溝通的一種實用形式。它讓一個代理能開啟多個獨立對話、讓協調者將有範圍限制的工作委派給專業代理，也讓你在對話輸入框中輸入 @，將現有對話帶入比較、交接或決策流程。
當一項任務範圍太廣、雜訊太多或風險太高，不適合在一段漫長的對話中完成時，這個功能就非常有用。與其讓一個代理在同一個上下文中承擔所有測試、資料來源和決策，不如給每項工作一個明確的歸屬，只帶回真正重要的證據。
A2A 在 Zero 中的三種運作方式
| 你想做的事 | 使用此設定 | 適合的入門情境 |
|---|---|---|
| 以乾淨的上下文重複同一套方法 | 一個代理，多個對話 | 分別測試註冊、帳單、權限和行動裝置 |
| 將工作的各部分交給不同專家 | 一個協調者，多個專業代理或子代理 | 將產品上線拆分為研究、瀏覽器 QA、撰寫和發布 |
| 重複使用已有的成果 | 在輸入框中 @ 另一個對話 | 比較兩份 QA 報告，或將研究成果帶入撰寫任務 |
這些模式背後有三個產品物件：
- 代理是可重複使用的工作者。它擁有指令、工作流程、連接器、權限、語氣、角色和模型選擇。
- 對話是與代理進行的一次獨立交流。它讓測試、審查或正式任務保有各自的上下文。
- 執行是對話中一次進行中的回應。執行負責完成工作，當工作區達到並行上限時可能會等待。
有一個重要細節很簡單：新的子對話不會繼承控制對話的完整歷史記錄。它的第一則訊息應包含完成工作所需的一切資訊。
A2A、多個對話、子代理、工作流程與自動化
這些術語解決的是不同的問題。請使用能提供你所需邊界的最小設定。
| 產品模式 | 改變的內容 | 最適合用於 |
|---|---|---|
| Zero 中的 A2A | 代理與對話如何協調工作 | 委派、比較、交接和最終整合 |
| 同一代理下的多個對話 | 上下文，而指令和權限保持不變 | 平行測試、本地化檢查、研究批次和模型評估 |
| 專業代理或子代理 | 角色、指令、模型、工具或權限 | 研究、QA、撰寫、資料分析和受控發布 |
| 工作流程 | 代理可重複執行的已儲存程序 | 穩定的檢查清單或多步驟方法 |
| 自動化 | 觸發代理啟動工作流程的條件 | 排程報告、事件驅動的分類和定期檢查 |
一個實用的判斷原則：當方法不變時拆分為對話，當方法或存取權限改變時拆分為專業代理，當程序需要以相同方式重複執行時使用工作流程。
1. 一個代理開啟多個乾淨的對話
你即將發布產品。註冊、帳單、權限和行動裝置都需要最後一輪檢查。把所有檢查放進一段漫長的對話聽起來很方便，但狀態可能從一個流程洩漏到下一個。帳單升級可能在權限測試開始之前就改變了帳戶狀態。
改用每個流程一個對話的方式。
一份共用簡報，四個獨立檢查，最後一份總結報告。
我們於 2026 年 8 月 25 日在測試環境產品中重現了這個設定。同一個 Zero 代理為上線引導、帳單、團隊成員權限以及行動裝置加本地化測試各開啟了一個真實對話。
每個流程都有自己的對話，讓證據易於檢視。
試試這個提示：
將這次測試環境發布作為四項獨立工作來進行。開啟一個對話處理註冊和上線引導，一個處理帳單升級，一個處理團隊成員邀請和拒絕權限，一個處理行動裝置加本地化檢查。每個對話使用同一個流程代理。每位工作者必須回傳測試的 URL、帳戶角色、編號步驟、截圖、通過/失敗狀態，以及精確的重現步驟。將結果帶回這裡，並將重複的阻礙項目分組。
這個模式也適用於：
- 每個瀏覽器或裝置尺寸一個對話
- 每個語言環境或帳戶角色一個對話
- 每個 Pull Request 或功能旗標一個對話
- 每位審查者一個對話，在最後才匯整發現
- 每批客戶訪談或研究資料來源一個對話
- 每個模型一個對話，以便公平比較輸出結果
通常會出什麼問題？簡報太簡短。「檢查帳單」讓工作者對帳戶、版本、預期結果和證據格式一無所知。給每個對話相同的檢查清單，當流程會改變共用資料時，提供獨立的測試帳戶。
2. 使用 @ 將另一個對話帶入工作
有時候有用的成果已經存在。一個研究對話有客戶引言。一個 QA 對話有截圖。第二次審查得出了不同的結論。你不需要把所有內容複製貼上。
點擊輸入框並輸入 @。Zero 會開啟你現有對話的清單。
開始輸入標題以縮小清單範圍，然後選擇你需要的對話。
選取的對話會以可點擊的橘色標籤顯示。
標籤指向確切的上線引導對話。回答將寫在目前的對話中。
然後加上一個動詞。告訴 Zero 要對那個對話做什麼：
- 「將
@Onboarding QA與這份帳單審查進行比較。」 - 「從
@Customer research batch 2繼續，並在這裡撰寫建議。」 - 「挑戰
@Security review中風險最高的結論。」 - 「將
@Mobile walkthrough中的截圖整理成錯誤報告。」 - 「從
@Launch research中提取所有未解決的問題。」
輸入 @，選擇對話，然後說明你希望 Zero 對它做什麼。
提及是一個地址，而不是模糊的文字標籤。它讓 Zero 指向選取的對話，而不需要將完整對話貼入輸入框。這讓目前的訊息保持易讀，但你的指令仍需要明確的動作。「使用這個」太模糊。「比較失敗的步驟並排列共同阻礙項目的優先順序」才是清楚的。
3. 將不同部分交給專業代理或子代理
當你需要同一個工作者的乾淨副本時，使用多個對話。當工作需要不同的指令、工具、模型或權限邊界時，使用專業代理。為協調者執行有範圍限制任務的專業代理，通常稱為子代理。
產品上線是一個很好的例子。Research Scout 可以驗證證據。Browser QA 可以檢查已發布的產品。Launch Writer 可以起草頁面。Publishing Operator 可以在聲明通過審查後建立 CMS 草稿。
測試環境工作區有一個核心代理和四個具名專業代理，每個都準備好接受有範圍限制的任務。
協調者負責最終成果。專業代理回傳證據和產出物，然後由一位負責人撰寫最終結果。
以下是一個實用的上線簡報：
協調 Feature X 的上線套件。請 Research Scout 驗證客戶證據和競爭對手聲明。請 Browser QA 在測試環境中重現每項產品聲明並附上截圖。請 Launch Writer 在證據到位後才起草頁面。Publishing Operator 可以建立 CMS 草稿，但不得發布。在這個對話中回報缺少的證據和相互衝突的聲明。
價值來自真實的邊界。研究代理可以保持唯讀狀態。發布代理可以擁有草稿存取權限，但沒有發布權限。QA 代理每次都可以遵循固定的瀏覽器檢查清單。Zero 的權限控制有助於將這些邊界保持在最小範圍。
不要只是為了讓側邊欄看起來更忙碌而建立專業代理。只有當角色改變了工作的執行方式時，才建立一個。
4. 讓獨立審查者各自表述，再使用裁判
只有當第二位審查者不是在複製第一位的意見時，兩份審查才有價值。開啟乾淨的對話，給兩位審查者相同的證據，並讓他們的初始報告保持獨立。
然後開啟一個裁判對話，在一個提示中同時提及兩份報告。
一個提示可以參照兩個真實的 QA 對話，並請 Zero 找出共同的阻礙項目。
例如：
比較
@Onboarding QA與@Billing QA。列出兩個對話都發現的阻礙項目、只有一個對話發現的問題，以及仍然缺少的證據。然後決定是否應該發布這個版本。為每個阻礙項目引用支持它的截圖或步驟。
這個模式適用於設計審查、安全審查、供應商選擇、架構決策、合約審查和模型比較。在報告到來之前先定義裁判標準。否則裁判可能會獎勵最有自信的寫作，而不是最有力的證據。
5. 將工作從一個代理交接給下一個
有些工作不應該同時進行。研究必須在草稿之前完成。草稿必須在 QA 之前完成。QA 必須在發布之前完成。
將每次交接視為一份簡短的交接說明：
- 指名接收的代理或對話。
- 附上或參照產出物。
- 說明驗收標準。
- 說明接收者必須在哪裡回報。
「告訴撰寫者你發現了什麼」很難驗證。這樣更好：
將已核准的研究摘要傳送給 Launch Writer。草稿必須只使用已驗證的聲明，保留已核准的術語，並將任何缺少的證明標記為
[EVIDENCE NEEDED]。將草稿連結和未解決的問題回傳到這個對話。
@ 對話標籤在這裡很有用，因為它給下一位工作者一個精確的來源。對於檔案較多的工作，也要傳遞產出物連結。協調者需要的是狀態、決策和最終套件，而不是每一份草稿筆記都複製到自己的上下文中。
AI 代理如何在 Zero 中共享上下文？
Zero 中的代理不需要一個龐大的共用對話。上下文透過明確的簡報、@ 對話提及、產出物連結和回傳摘要來傳遞。每位工作者接收最少量的有用上下文，完成有範圍限制的任務，然後將證據或決策回傳給協調者。
這種方式避免了兩個常見的多代理問題。第一，不相關的歷史記錄不會佔用工作者的上下文。第二，協調者可以清楚看到哪個來源或對話支持某項聲明。
使用以下四種上下文共享模式：
- 自給自足的簡報： 最適合需要從頭開始的新子對話。
@對話提及： 最適合現有對話是來源的情況。- 產出物連結： 最適合文件、截圖、資料集和程式碼變更。
- 結構化回傳： 最適合多位工作者需要以相同格式回報的情況。
不要假設子對話已經知道控制對話的決策。如果某個術語、限制條件、帳戶、日期範圍或輸出格式很重要，請在第一則訊息中說明。
更多 A2A 和多代理工作流程情境
| 情境 | 如何拆分 | 回傳的內容 |
|---|---|---|
| 發布流程檢查 | 同一代理，每個使用者流程一個對話 | 截圖、通過/失敗檢查和共同阻礙項目 |
| 本地化 QA | 同一代理，每個語言環境一個對話 | 損壞的字串、版面問題和特定語言環境的截圖 |
| 瀏覽器和裝置測試 | 同一代理，每個瀏覽器或視窗大小一個對話 | 附有證據的可比較相容性矩陣 |
| Pull Request 審查 | 同一代理，每個 PR 或審查角度一個對話 | 錯誤、風險備註和行級建議 |
| 客戶研究 | 同一代理，每批訪談一個對話 | 引言、模式、反對意見和來源連結 |
| 事件應對 | 協調者加上應用程式、API、部署和客戶影響代理 | 一份標示出共識與衝突的時間軸 |
| 內容製作 | 研究、撰寫、設計、QA 和發布代理 | 已審查的草稿和受控的發布交接 |
| 客戶支援分類 | 協調者加上帳戶、產品、帳單和回覆代理 | 根本原因、優先順序、負責人和草稿回覆 |
| 資料分析 QA | 分析師代理加上獨立審查者 | 已檢查的關聯、分母、時區和假設 |
| 模型比較 | 使用相同簡報和不同模型的乾淨對話 | 準確度、成本、延遲和格式評分 |
正確的拆分能創造有用的邊界。它可以隔離上下文、保護權限、讓審查保持獨立，或讓準備好的工作同時進行。
什麼時候應該使用一個對話、多個對話或多個代理？
當每個下一步都立即依賴前一個答案時，使用一個對話。循序漸進的除錯過程就是一個好例子。
當指令保持不變，但你需要乾淨的上下文或獨立的證據時，使用同一代理下的多個對話。這通常是測試、研究批次和公平比較的最佳起點。
當每個部分需要不同的專業知識、連接器、權限或模型時，使用多個專業代理。讓一個協調者負責最終決策。
當程序應該可重複執行時，使用工作流程。只有當該程序還需要排程或事件觸發時，才加入自動化。Zero 將這兩個建構模組分開說明：工作流程定義方法，而自動化決定執行時機。
A2A 安全性與權限邊界
當存取權限與任務相符時，多代理工作會更安全。只給每個專業代理其工作所需的連接器和權限。研究代理很少需要發布存取權限。QA 代理可能需要測試環境登入，但不需要正式環境的帳單控制。發布代理可能需要草稿存取權限，但仍需要人工核准最終發布。
將外部寫入操作集中在一個具名負責人身上。多個代理可以讀取儲存庫、CRM 或 CMS，但應由一個代理建立最終工單、更新記錄、傳送客戶回覆或發布頁面。這可以防止重複寫入，並讓稽核軌跡更易於追蹤。
對於風險較高的工作，在簡報中加入停止條件：「僅限草稿」、「不要傳送」、「如果證據衝突則升級」或「在變更正式環境之前請求核准」。A2A 讓委派更容易，但不能取代明確的問責制。
讓 A2A 工作保持整潔的四條規則
1. 讓每則第一訊息自給自足
包含目標、來源材料、限制條件、輸出格式、目的地和停止條件。子對話不應該需要猜測控制對話已知的內容。
2. 給工作者相同的回應格式
如果四個 QA 對話回傳四種不同的格式，協調者就得花時間整理文字。要求每位工作者提供相同的欄位：環境、步驟、證據、狀態和下一步行動。
3. 將共用寫入操作交給一個負責人
兩個正確的代理仍然可能因為寫入兩次而造成混亂。指定擁有最終外部行動的代理。
4. 只拆分能從拆分中獲益的工作
建立八個對話並不意味著八個執行會同時進行。工作區並行限制仍然適用，有依賴關係的工作應等待其輸入。當每個下一步都依賴前一個答案時，將工作保留在一個對話中。
Zero A2A 與 Google 的 Agent2Agent 協議相同嗎？
這裡不聲稱任何協議等同性。本指南描述的是 Zero 內部跨代理和對話的產品層級協調：如何透過介面拆分、參照、裁判和交接工作。
Google 的 Agent2Agent 開放協議是遠端代理系統之間通訊的技術標準，包含能力探索、任務管理、訊息和產出物。「A2A」的搜尋結果通常聚焦於該協議，因此這個區別很重要：Zero A2A 是本文所涵蓋的實用產品工作流程。
常見問題
對話和代理是同一件事嗎？
不是。代理是可重複使用的工作者設定。對話是與該代理進行的一次獨立交流。一個代理可以擁有許多對話。
子對話會共享控制對話的上下文嗎？
不會。以完整的簡報開始每個子對話。工作者可以回傳結果或將有範圍限制的產出物傳遞給另一個對話，但不應假設有共用的歷史記錄。
當我 @ 一個對話時會發生什麼？
Zero 會插入一個指向你所選對話的結構化參照。該參照識別你所指的對話，不會將完整對話貼入輸入框，因此請加上明確的動作，例如比較、審查、繼續或提取。
Zero 中的子代理是什麼？
子代理是從協調者接受有範圍限制任務的專業代理。它可以使用不同的指令、工具、權限或不同的模型，然後將結果回傳給控制對話。
多個對話可以平行執行嗎？
可以，當工作區並行容量可用且任務相互獨立時。當達到上限時，額外的工作可能會排隊等待。有依賴關係的工作應循序執行。
什麼時候應該使用不同的代理？
當工作需要不同的指令、工作流程、模型、連接器或權限時，使用不同的代理。當你主要需要乾淨的上下文時，在同一個代理下使用多個對話。
先試試測試環境流程檢查
在 Zero 中開啟一個新對話，將一次真實的發布檢查拆分為四個乾淨的對話。在每個對話中要求截圖和相同的通過/失敗格式。一旦這個方式奏效，將其中一個分支替換為專業代理，或在裁判提示中提及兩個已完成的對話。
更多想法，請參閱20 個 AI 代理使用案例，附精確提示和工具。
