什麼是 Zero 的 A2A？
Zero A2A 是產品內部實用的智能體對智能體通訊方式。它允許一個智能體開啟多個獨立的聊天，讓協調者能將有限的工作委派給專家智能體，並讓你在聊天編輯器中輸入 @，將現有聊天帶入比較、交接或決策流程。
當一項工作過於廣泛、雜亂或風險過高，不適合用一場長對話時，這特別有用。你不必要求一個智能體在同一個上下文中處理所有測試、來源與決策，而是為每個工作分配明確的歸屬，只帶回重要的證據。
Zero 中 A2A 的三種運作方式
| 你想做什麼 | 使用這種設置 | 適合的第一個情境 |
|---|---|---|
| 用乾淨的上下文重複一種方法 | 一個智能體，多個聊天 | 分別測試註冊、帳單、權限與行動裝置 |
| 將工作分配給不同專家 | 一個協調者，多個專家智能體或子智能體 | 將發佈分拆為研究、瀏覽器 QA、撰寫與發佈 |
| 重用現有成果 | 在編輯器中@另一個聊天 | 比較兩份 QA 報告或將研究結果交給寫作任務 |
這些模式背後有三個產品物件：
- 智能體是可重複使用的工作者。它擁有指令、工作流程、連接器、權限、語氣、角色與模型選擇。
- 聊天是與一個智能體的獨立對話。它將測試、審查或生產任務保存在自己的上下文中。
- 執行是在聊天中的一次主動回應。執行負責實際工作，當工作區達到並行上限時可能會等待。
重點很簡單：新的子聊天不會繼承控制聊天的完整歷史。它的第一則訊息應包含完成任務所需的一切。
A2A、多聊天、子智能體、工作流程與自動化
這些術語解決不同問題。請用最小的設置來獲得你需要的界線。
| 產品模式 | 改變了什麼 | 最適用於 |
|---|---|---|
| Zero 的 A2A | 智能體與聊天如何協調工作 | 委派、比較、交接與最終整合 |
| 一個智能體下多個聊天 | 上下文，指令與權限不變 | 平行測試、本地化檢查、研究批次、模型評估 |
| 專家智能體或子智能體 | 角色、指令、模型、工具或權限 | 研究、QA、寫作、數據分析、受控發佈 |
| 工作流程 | 智能體可重複執行的儲存程序 | 穩定的檢查清單或多步驟方法 |
| 自動化 | 啟動智能體工作流程的觸發器 | 定期報告、事件驅動分流、重複檢查 |
實用原則：方法不變時分拆聊天，方法或存取權變動時分拆專家智能體，程序需重複時用工作流程。
1. 一個智能體開啟多個乾淨聊天
你即將發佈。註冊、帳單、權限與行動裝置都需要最終檢查。將所有檢查放在一場長聊天裡看似方便，但狀態可能從一個流程洩漏到下一個。例如帳單升級可能在權限測試開始前就改變了帳戶。
請改用每個流程一個聊天。
一份共用簡報，四個獨立檢查，最後彙整成一份報告。
我們於 2026 年 8 月 25 日在測試產品中重現了這個設置。同一個 Zero 智能體為新手引導、帳單、隊友權限與行動裝置加本地化測試開啟了四個真實聊天。
每個流程有自己的聊天，證據易於檢查。
試試這個提示：
將這次測試發佈分為四個獨立任務。分別開啟一個聊天處理註冊與新手引導、一個處理帳單升級、一個處理隊友邀請與權限拒絕、一個處理行動裝置加本地化檢查。每個聊天都用同一個 walkthrough 智能體。每位工作者需回報測試網址、帳戶角色、步驟編號、截圖、通過/失敗狀態與精確重現步驟。將結果帶回這裡並彙整重複阻礙。
這種模式也適用於：
- 每個瀏覽器或裝置尺寸一個聊天
- 每個語系或帳戶角色一個聊天
- 每個拉取請求或功能旗標一個聊天
- 每位審查者一個聊天，發現分開直到最後
- 每批客戶訪談或研究來源一個聊天
- 比較模型輸出時每個模型一個聊天
常見錯誤？簡報太短。「檢查帳單」讓工作者猜測帳戶、版本、預期結果與證據格式。當流程會改變共用資料時，請給每個聊天相同檢查清單與獨立測試帳戶。
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]。將草稿連結與未解決問題回報本聊天。
這裡的@聊天標籤很有用，能給下一位工作者精確來源。檔案量大時，也請傳遞產物連結。協調者只需狀態、決策與最終包，不需每份草稿都複製進自己的上下文。
Zero 中智能體如何共享上下文？
Zero 的智能體不需一場巨大的共用對話。上下文透過明確簡報、@聊天提及、產物連結與回傳摘要流動。每位工作者收到最小有用上下文，完成有限任務，並將證據或決策回傳協調者。
這種方式避免兩個常見多智能體問題：一是無關歷史不會擠滿工作者上下文，二是協調者能精確看到每個主張的來源或聊天。
請用這四種上下文共享模式：
- 自足簡報： 適合需全新開始的子聊天。
@聊天提及： 適合現有對話作為來源時。- 產物連結： 適合文件、截圖、數據集與程式碼變更。
- 結構化回傳： 適合多位工作者需用相同格式回報時。
不要假設子聊天已知控制聊天的決策。若術語、限制、帳戶、日期範圍或輸出格式重要，請寫在第一則訊息。
更多 A2A 與多智能體工作流程情境
| 情境 | 如何分拆 | 回傳內容 |
|---|---|---|
| 發佈 walkthrough | 同一智能體，每個用戶流程一個聊天 | 截圖、通過/失敗檢查、共通阻礙 |
| 本地化 QA | 同一智能體，每個語系一個聊天 | 破損字串、版面問題、語系專屬截圖 |
| 瀏覽器與裝置測試 | 同一智能體，每個瀏覽器或視窗一個聊天 | 可比較的相容性矩陣與證據 |
| 拉取請求審查 | 同一智能體，每個 PR 或審查角度一個聊天 | 錯誤、風險說明、逐行建議 |
| 客戶研究 | 同一智能體，每批訪談一個聊天 | 引言、模式、異議、來源連結 |
| 事件回應 | 協調者加 app、API、部署、客戶影響智能體 | 一份時間線，標明共識與衝突 |
| 內容產製 | 研究、寫作、設計、QA、發佈智能體 | 已審查草稿與受控發佈交接 |
| 客服分流 | 協調者加帳戶、產品、帳單、回覆智能體 | 根本原因、優先順序、負責人、回覆草稿 |
| 數據分析 QA | 分析智能體加獨立審查者 | 檢查過的 join、分母、時區、假設 |
| 模型比較 | 同一簡報下不同模型的乾淨聊天 | 準確率、成本、延遲、格式分數 |
正確分拆能創造有用界線。它可能隔離上下文、保護權限、維持審查獨立，或讓現成工作同時執行。
什麼時候該用一個聊天、多個聊天或多個智能體？
一個聊天適用於每個步驟都依賴前一步答案的情境，例如逐步除錯。
同一智能體下多個聊天適用於指令不變但需要乾淨上下文或獨立證據時。這通常是測試、研究批次與公平比較的最佳起點。
多個專家智能體適用於每部分需不同專業、連接器、權限或模型時。請給一位協調者負責最終決策。
工作流程適用於程序需重複執行時。只有當程序還需排程或事件觸發時才加上自動化。Zero 將這兩個基礎元件分開說明：工作流程定義方法，自動化決定何時執行。
A2A 的安全性與權限界線
多智能體工作更安全，若存取權隨任務分配。只給每位專家完成其部分所需的連接器與權限。研究智能體很少需要發佈權限，QA 智能體可能需要測試登入但不需生產帳單控制，發佈智能體可有草稿權限但仍需人工核准最終發佈。
將外部寫入權限集中於一位命名負責人。多個智能體可讀取資料庫、CRM 或 CMS，但應由一位智能體建立最終工單、更新紀錄、發送客戶回覆或發佈頁面。這可避免重複寫入，也讓稽核紀錄更清楚。
高風險工作請在簡報中加上停止條件：「僅草稿」、「勿發送」、「證據衝突時升級」、「更改生產前需核准」。A2A 讓委派更容易，但仍需明確責任歸屬。
四條讓 A2A 工作井然有序的原則
1. 讓每則首訊息自足
包含目標、來源資料、限制、輸出格式、目的地與停止條件。子聊天不應猜測控制聊天已知內容。
2. 給工作者相同回應格式
若四個 QA 聊天回傳四種格式，協調者只會忙著整理文字。請每位工作者回報相同欄位：環境、步驟、證據、狀態、下一步。
3. 共用寫入權限只給一位負責人
兩位正確的智能體也可能因重複寫入而造成混亂。請指明最終外部動作的負責智能體。
4. 只分拆有益於分拆的工作
創建八個聊天不代表八個執行會同時進行。工作區並行限制仍適用，依賴性工作應等待輸入。若每步都依賴前一步，請保留在同一聊天。
Zero A2A 與 Google 的 Agent2Agent 協定相同嗎？
本說明不主張協定等同。本文描述的是 Zero 內部智能體與聊天的產品級協調：如何分拆、參照、評審與透過介面交接工作。
Google 的 Agent2Agent 開放協定是遠端智能體系統間通訊的技術標準，包括能力發現、任務管理、訊息與產物。搜尋「A2A」多聚焦於該協定，因此區分很重要：Zero A2A 是本文涵蓋的實用產品工作流程。
常見問題
聊天和智能體是一樣的嗎？
不是。智能體是可重複使用的工作者設定。聊天是與該智能體的一次獨立對話。一個智能體可擁有多個聊天。
子聊天會共享控制聊天的上下文嗎？
不會。每個子聊天都需完整簡報。工作者可回傳結果或將有限產物傳給另一個聊天，但不應假設有共用歷史。
我 @ 聊天時會發生什麼？
Zero 會插入你選定聊天的結構化參照。該參照標識你指的對話，不會將完整對話貼入編輯器，因此請加上明確動作，如比較、審查、繼續或擷取。
Zero 中的子智能體是什麼？
子智能體是接受協調者有限任務的專家智能體。它可用不同指令、工具、權限或模型，然後將結果回傳控制聊天。
多個聊天可以平行執行嗎？
可以，當工作區有並行資源且任務彼此獨立時。達到上限時額外任務會排隊。有依賴性的工作應依序執行。
什麼時候該用不同智能體？
當工作需要不同指令、工作流程、模型、連接器或權限時請用不同智能體。僅需乾淨上下文時，請用同一智能體下多個聊天。
請先試試測試環境 walkthrough
在 Zero 開啟新聊天，將一次真實發佈檢查分拆為四個乾淨聊天。每個聊天都要求截圖與相同通過/失敗格式。完成後，可將其中一支換成專家智能體，或在評審提示中提及兩個已完成聊天。
更多靈感請參見20 智能體應用案例與精確提示、工具。
