智慧代理團隊需要對話之外的證據

Anthropic於2026年11月6日公布Project EVE研究，實驗進行於4至7月。協作代理很少識別出被明確要求破壞任務的同伴。這檢驗的是人為設定的對抗行為，並非自發惡意。原始報告

這項區別不是附帶說明，而是理解結果的起點。完成協作任務與建立可信組織，是兩件不同的事。前者要求各方貢獻能夠銜接，後者還要回答：某項貢獻錯誤、不完整或有意誤導時，系統會怎樣。Open Market Notes的判斷是，企業採購應分別評估這兩種能力，不能把流暢的團隊對話直接當作額外的安全保障。

第二個意見，未必來自第二次觀察

設想一個用來說明問題的採購流程：一個代理查詢供應商庫存，一個準備訂單，另一個複核建議。如果複核者只能看到第一個代理的摘要，三個參與者仍可能依賴同一次未經核實的觀察。討論增加後，解釋可以更清楚，庫存卻不會因此更真實。

這種風險不需要惡意才能發生。過期回覆、單位錯誤或遺漏的條件，都能沿相同路徑傳播。因此，設計重點不該只是要求同伴保持懷疑，而是讓重要判斷對應到提出者無法悄悄替換的證據。能夠直接讀取帶時間標記的供應商回覆，與只能要求同伴再保證一次，是兩種不同的複核。

這也改變了備援的意義。同一種解釋複製三次，不等於三次獨立檢查。Anthropic在8月13日的多代理研究中討論了相似代理產生相關錯誤的問題。此前研究 據此，我們認為，審核是否獨立，應看資訊來源和存取路徑，而不只是代理數量或角色名稱是否不同。

分配工作，不等於交出整個決定

既有安全原則提供了一個參考。NIST於2020年8月發布的零信任架構，不認可僅憑位置或所有權就自動賦予信任。NIST文件 將這項原則用於代理團隊，是本文的設計建議，不表示NIST認證了這些系統：同屬一個工作流程，不應自動獲得執行敏感操作的權限。

以上述採購流程為例，代理可以調查供應商，但不一定能修改核准供應商名冊；可以準備訂單，但不一定能放行付款。這些邊界有助於限制錯誤影響，卻並非沒有成本。增加審批會產生等待，收緊存取可能阻礙合理的故障復原，共同負責也可能變成無人負責。因此，清晰的邊界必須同時配有明確的升級處理責任人。

外部紀錄也不是保存下來就有用。如果日誌記錄每一句話，卻無法把建議對應到最後的執行，企業得到的可能是大量文件，而非可追究的責任。真正有用的鏈條應具體呈現：哪次觀察支持哪項決定，什麼權限允許執行，實際狀態又改變了什麼。這是本文提出的設計標準，不是遊戲實驗已經測出的效果。

應當計算的是有根據的信任成本

多代理的商業價值通常先以處理量來說明。採購方還需要知道，確認已完成工作值得接受，要花多少成本。假設兩個系統完成同一組訂單，一個經常需要人工重建過程，另一個能為異常提供可核驗依據，僅比較完成數量會掩蓋不同的營運負擔。

試點因此不應只使用乾淨輸入，也可在授權測試環境中加入錯誤資訊、過期紀錄和無法使用的服務。除最終答案是否正確外，還應記錄：有害操作是否被阻止、多少正常操作被誤擋、復原用了多久。這些是建議的評估面向，不是Project EVE公布的統計數字。它們能區分只會完成簡單案例的團隊，與能夠把失敗限制在可接受範圍的系統。

這裡存在真實取捨。對每個低影響陳述都做獨立檢查，可能比任務本身節省的時間還多。更值得優先核驗的，是難以撤回的決定，或一旦出錯就會影響許多後續判斷的依賴項。對常規結果抽樣，對關鍵依賴要求更強證據，才能讓審核強度與風險匹配。界線應按實際工作流程劃定，最終仍是管理責任。

遊戲是測試環境，不是上線證明

EVE AI Lab也確認合作，並區分歷史市場實驗與共享世界中的團隊活動。合作方說明 這能佐證實驗場景，不能證明結論可直接遷移。遊戲沒有完整複製企業合約、客戶責任、權限系統和事故處理機制。報告不足以確定普遍適用的企業失敗率，本文也不作這種推斷。

結果同樣不意味每項任務都需要更大的監督模型。有時缺少的只是一個更簡單的獨立紀錄、一項更窄的權限，或一個可以撤回的操作。只有能取得足以糾正最初說法的證據，增加推理才有意義。

因此，採購問題需要比「代理能否合作」更具體：當整個團隊達成一致時，有什麼獨立依據，使企業可以放心採取行動？更可靠的實現，應以可觀察的控制和復原表現回答，而不只是提供一段有說服力的對話。