在6.24日，Anthropic 官方部落格再發新文章 Building effective human-agent teams，作者 Kristen Swanson。
文章的核心點在於討論AI 團隊級協作的範式，正在發生轉移，從「一個人對一個聊天框（哪怕是背後站在很多agent）」，轉向「一群人和一群 agent 共享同一個工作空間」。
筆者此篇會在轉述原文核心觀點的基礎上，結合AI agent 落地經驗給出脈絡梳理與綜合性思考。
過去，使用 AI 一直是一種「單機（single-player）」體驗——一個人和 agent 協作，完成個人任務。
而現在新的模式是，人類和 agent 可以在同一個工作空間裡協作，服務於一個團隊共享的目標。
工作開始更像一場「多人連線遊戲（multiplayer game）」：由人類團隊制定策略，由 Claude 來執行。
總之，就是共享目標、共享上下文、尤其是共享工作空間。
如下圖，向右側的複雜工作模式的轉換正在發生：
而實現這一轉變的是 Anthropic 新產品 Claude Tag，一種讓 Claude 進駐 Slack 等團隊協作工具、像團隊成員一樣被 @ 和被指派的型態。
所以，這篇文章不是純理論，而是 Anthropic「本身產品在推動的方向」
原文給「multiplayer agents」下的定義是：同時與許多不同的人類協作的 AI 模型。
它和我們熟悉的普通 agent 有相同之處，也有關鍵區別：
相同：它有自己的記憶和技能（skills）。
不同：它有自己的憑證（credentials），
並且「living where work happens」——活在工作真正發生的地方。
在 Anthropic，那個地方就是 Slack 這樣的團隊協作工具。
這個「有自己的憑證、活在團隊頻道裡」的設定非常重要。
它意味著 agent 不再是借用某個人的帳號、在某個人的私有會話裡幹活，而是一個具備獨立身分的團隊實體：它能被全團隊看到、它的產出對所有人可見、它讀取的上下文是團隊級別的而非個人級別的。如下圖，變成你辦公軟體中的一員。
那要讓 agent 能在團隊頻道裡「高效參與」，需要一組特定的底層能力（比如Claude Tag 這樣的產品型態）+專門設計的持久記憶，身分獨享，資訊來源等機制。
除此之外，光有技術能力還不夠，要讓人工智慧團隊「成功」得靠的是一套工作方式和共享規範。
所以文章的後面四條經驗，講的全部是設計AI 團隊的 「規範」的經驗
Anthropic 認為不要逐個文件、逐個頻道地決定哪些資訊對 agent 可見，而是用清晰定義的安全邊界（security boundaries），一刀切地作用於整個 Slack 工作空間、會議轉錄、文檔庫。
原文專門點名了那種日常折磨：「這個頻道該設公開還是私有？這份文件能不能分享給那個人？這個 agent 能不能看那條訊息？」
應該在在邊界之內，上下文對每一個團隊成員——無論是人還是 AI對是可見的，甚至AI可以去仿照人一樣，申請文件的權限。
這一招的精妙在於它同時解決了兩個問題：
1.擴大了 agent 和人能拿到的上下文；
2.消除了「逐項分享」帶來的決策疲勞。
權限開放回報是實打實的，不再有資訊透傳的損失，而且因為 agent 讀文字的速度遠超人類，它們能「routinely surface relevant work that humans would otherwise have missed」（常常翻出人類本會錯過的相關工作）。
在筆者看來**，**這本質是組織文化與權限機制的轉移。
「預設內部公開」對很多公司來說是要動筋骨的文化變革。
因為Anthropic 一開始就是一家高度信任、資訊扁平的公司，所以他並不能理解那種大公司病，尤其是傳統行業中，跨級別的資訊差，形成的資源差。
而且對於很多強合規、強資訊隔離（金融、醫療、跨法域）的組織，「工作空間級一刀切」未必可行。
所以真正可應用的是它背後的精簡審批機制，比如只要agent 在某個群，就天然可讀該群有權限的文件，即使有權限管控，也可以天然的批量管理，而非先給文件，再安排品質。
原文的畫面感很強：人機團隊共享一份花名冊、一套產物、一個工作空間。
在這之上，agent 各有分工：
一個 agent 擁有某項項目的數據分析；
另一個持有並執行設計規範；
第三個負責研究綜合（research synthesis）。
項目啟動時，人類先和 agent 聊一聊，決定怎麼分配角色、人和 agent 如何協作。
然後產出下圖這樣的角色與規則+介入時機的組合。
角色明確之後，一個 agent 甚至可以「spin up」（拉起）其他 agent，確保每個具體任務都交給那個擁有正確記憶、正確存取權限的 agent 去做。
關鍵是工具配齊：做數據分析的 agent 可能需要 BigQuery 存取權，做 QA 的 agent 可能需要 Playwright MCP。
人類持有只有人類能持有的角色，確保讓人類判斷被用在最重要的決策上。
筆者認為：這也是 Anthropic 既往研究機制工作流程的架構。
用一個 lead agent 協調全局，把任務委派給並行運行的專門化 subagent。這類機制確實很實用，品質指標是幾乎翻倍的（高出 90.2%），雖然成本增長15倍的Token。不過，「多 agent 更強」不是普適結論，而是「在某類任務上、以可觀的算力代價換來的提升」。
尤其是廣度優先、可並行的工作中，並且由於更強的交叉驗證機制，所以資訊準確度更好。
並且還要精細設計，做好任務分解與角色隔離，而不是簡單地「多堆幾個 agent」。
否則就又是新一代畝產1萬八千斤的誤解了。
這很多觀點也在上篇文章裡如何用 Claude 的 Dynamic Workflows 做深度研究
原文區分了兩類 agent：一類只是「完成被指派的任務」，而最重要的那類會主動提出新項目和新工作流。
後者通常出現在一個已經具備豐富上下文、清晰角色的團隊，再加上一條額外的指引——北極星（north star）。
北極星負責幫團隊判斷「哪些任務和工作流才是對的」。
原文強調了幾條紀律：
•北極星永遠由人類設定，並紮根於公司的使命與業務目標；
•北極星一旦被清晰地寫下來，人類把它分享給團隊裡的 agent；
•然後——這一步很關鍵——人類挑選哪些 agent 應當主動提議新工作流。
假定一個營運驅動的產品和公司，那就應該讓營運角色來成為主導agent，而非是產品驅動，或者技術驅動，財務驅動。
就像如何用 Claude 的 Dynamic Workflows 做深度研究中的 路由模式（Classify-And-Act），先由一個 agent 分辨任務類型，再把任務分發給最適合的專門 agent 去做。
**筆者認為，**之前看 Anthropic 有不少文章，都有提現出在他們眼中什麼是 agent ，什麼是 workflow？
前者則「動態主導自己的流程和工具使用，掌控如何完成任務」。
而後者 是「透過預定義程式碼路徑編排」的確定性系統；
所以要做ai團隊，是應該給 agent 一條北極星而非一張任務清單，正是在有意識地把系統從 workflow 推向 agent。
一個有目標的Team會帶來一些創造力，而不是在有限的範疇內沒事找事。
當然，我們現在做的很多ai team，其實是程式化或者ai化workflow，這已經能解決很多問題了，如果我們後續需要的是創意性，自驅的，有主動解決問題能力的，則必須要設計這樣agent式的team。
這裡官方的數據非常讓我驚訝，他說：Anthropic 的工程師已經能讓團隊裡的 agent 獨立處理 500 個 bug 修復——但緊接著強調：「things certainly didn't start off that way（一開始絕不是這樣）。」
它把 agent 類比成新入職的人類同事：需要多輪反饋才能把「任務到底怎麼做最好」這種隱性知識外顯出來。
用戶必須反覆用各種任務去試探 agent，才能摸清它的能力邊界、如何清晰描述目標、它需要哪些 skill 文件、什麼 prompt 最能引出期望行為。
原文還特別提醒一個容易被忽視的點：模型會升級，任務要重測——prompt 可能要重寫，過去有用的護欄（Harness）可能反而會束縛一個更聰明的模型去尋找更有創造力的解法。
這條經驗裡含金量最高的，是關於**驗證（verification）**的論述：
我們發現，最好的長週期 agent，在交給人類看之前，有許多種方式來驗證自己的工作。
程式碼有測試，這是當然的；
但大多數其他工作同樣可以被驗證：技術文檔可以套用評分量規（rubric）和風格指南（style guide）；
當人類設定好標準、並確保交給 agent 的所有工作都可被審查時，品質就能保持、不偏離初衷；
此外，可以讓一個 agent 幹活、另一個 agent 檢查——這就是常說的 「Doer-Verifier」（執行者—驗證者）agent harness。
原文有個完整案例：某位工程負責人接手一個積壓（backlog）很重的新團隊，他叫上幾個人 + 幾個 agent 一起梳理優先級。
一組 agent 通讀所有積壓項、判斷是否有人在做、給無主項打複雜度分；
另一組從清單裡篩出中低複雜度項、直接產出程式碼改動。
起初，人類審查 agent 的每一個決策，並標出需要人介入的那些；然後，人類「教會」agent 把這類決策直接拋給人類，確保有艱難權衡的決定永遠有「human in the loop」。
並且每週，團隊還讓 agent 編一份包含「經驗與失誤（lessons & missteps）」的週報，讓 agent 記住錯誤、避免重犯。隨著時間推移，負責人能交給 agent 越來越複雜的改動，自己花在日常指導上的時間越來越少，如下圖：
像極了養聰明龍蝦的過程。
最後一段是全文我最欣賞的一處洞察——當 agent 變得更獨立之後，負責人開始教 agent 把「人類注意力」當作稀缺資源來對待：
比如把問題批次化，讓人一次性回答，重複關鍵上下文，讓人快速進入狀態，限制一次性丟給人的事項數量。
有些人甚至專門設一個 agent，唯一職責就是決定如何批次處理、並只把最重要的溝通上升給人類。
另一些人則給 agent 設「每天最多做多少工作」的護欄——這樣人類才來得及有意義地參與，並且保住對自己重要的技能不被荒廢。
筆者認為，這些經驗是整篇文章在「人機關係」上最深刻的地方。
第一，Anthropic的思想裡認為：有效的監督不是審批每一個動作，而是「處在能在關鍵時刻介入的位置」（being in a position to intervene when it matters）。
第二，把「人類注意力」顯式當作稀缺資源去優化，是一個被嚴重低估的設計原則。大多數關於 agent 的討論都在優化「agent 的能力」，而效率實際的瓶頸已經是「人的認知帶寬」了。
第三，Harness駕馭工程是在人機團隊裡，應該完全模擬高效團隊的方式，畢竟有些好馬，確實不需要韁繩，只需要目標。
這篇文章最誠實、也最容易被忽略的一句話出現在結尾：
他說，上面這4條經驗其實並不新穎，早在AI出現之前就存在了，好的團隊要有強有力的北極星、清晰的角色、紮實的文件、共享的品質標準、從錯誤中學習的空間，都是我們幾十年來就熟知的健康團隊習慣。
而AI agent team 只是讓這些基本功變得更加重要。
如果沒有合理的機制建設，AI 不會自動讓團隊變強，甚至會造成擠壓，最終帶來混亂，比如：
上下文渙散的團隊（如靠資訊差來管理），接入 agent 後只會更渙散（資訊隔絕越大，產出越偏離）；
角色定位混亂的團隊，agent 只會複製混亂，互相工作職責紊亂，決策者判斷源失真。
沒有驗證文化的團隊，agent 的錯誤會以更快的速度規模化，AI程式碼的速度已經遠超過人的CR速度。
因此，筆者認為，「從這波 agent 紅利裡拿到最多的團隊，也是那些最有意識地去踐行這些基本功的團隊。」
對正在押注 AI agent 的組織來說，這篇文章給出的真正功課，或許不在「怎麼用 Claude」，而在回頭把自己團隊的上下文、角色、目標與品質標準這四件舊事，認認真真地重做一遍。
165.89萬 熱度
35.61萬 熱度
12.94萬 熱度
60.43萬 熱度
100.66萬 熱度
解讀Anthropic新作：如何構建高效 AI 人機協作團隊
在6.24日，Anthropic 官方部落格再發新文章 Building effective human-agent teams，作者 Kristen Swanson。
文章的核心點在於討論AI 團隊級協作的範式，正在發生轉移，從「一個人對一個聊天框（哪怕是背後站在很多agent）」，轉向「一群人和一群 agent 共享同一個工作空間」。
筆者此篇會在轉述原文核心觀點的基礎上，結合AI agent 落地經驗給出脈絡梳理與綜合性思考。
一、主旨：AI協作團隊正在變成「連線模式」
過去，使用 AI 一直是一種「單機（single-player）」體驗——一個人和 agent 協作，完成個人任務。
而現在新的模式是，人類和 agent 可以在同一個工作空間裡協作，服務於一個團隊共享的目標。
工作開始更像一場「多人連線遊戲（multiplayer game）」：由人類團隊制定策略，由 Claude 來執行。
總之，就是共享目標、共享上下文、尤其是共享工作空間。
如下圖，向右側的複雜工作模式的轉換正在發生：
而實現這一轉變的是 Anthropic 新產品 Claude Tag，一種讓 Claude 進駐 Slack 等團隊協作工具、像團隊成員一樣被 @ 和被指派的型態。
所以，這篇文章不是純理論，而是 Anthropic「本身產品在推動的方向」
二、什麼是「多人 agent」 協作問題？
原文給「multiplayer agents」下的定義是：同時與許多不同的人類協作的 AI 模型。
它和我們熟悉的普通 agent 有相同之處，也有關鍵區別：
相同：它有自己的記憶和技能（skills）。
不同：它有自己的憑證（credentials），
並且「living where work happens」——活在工作真正發生的地方。
在 Anthropic，那個地方就是 Slack 這樣的團隊協作工具。
這個「有自己的憑證、活在團隊頻道裡」的設定非常重要。
它意味著 agent 不再是借用某個人的帳號、在某個人的私有會話裡幹活，而是一個具備獨立身分的團隊實體：它能被全團隊看到、它的產出對所有人可見、它讀取的上下文是團隊級別的而非個人級別的。如下圖，變成你辦公軟體中的一員。
那要讓 agent 能在團隊頻道裡「高效參與」，需要一組特定的底層能力（比如Claude Tag 這樣的產品型態）+專門設計的持久記憶，身分獨享，資訊來源等機制。
除此之外，光有技術能力還不夠，要讓人工智慧團隊「成功」得靠的是一套工作方式和共享規範。
所以文章的後面四條經驗，講的全部是設計AI 團隊的 「規範」的經驗
**三、**AI agent team 的四條經驗
經驗一：改革資訊管理，給 agent 盡可能廣的上下文
Anthropic 認為不要逐個文件、逐個頻道地決定哪些資訊對 agent 可見，而是用清晰定義的安全邊界（security boundaries），一刀切地作用於整個 Slack 工作空間、會議轉錄、文檔庫。
原文專門點名了那種日常折磨：「這個頻道該設公開還是私有？這份文件能不能分享給那個人？這個 agent 能不能看那條訊息？」
應該在在邊界之內，上下文對每一個團隊成員——無論是人還是 AI對是可見的，甚至AI可以去仿照人一樣，申請文件的權限。
這一招的精妙在於它同時解決了兩個問題：
1.擴大了 agent 和人能拿到的上下文；
2.消除了「逐項分享」帶來的決策疲勞。
權限開放回報是實打實的，不再有資訊透傳的損失，而且因為 agent 讀文字的速度遠超人類，它們能「routinely surface relevant work that humans would otherwise have missed」（常常翻出人類本會錯過的相關工作）。
在筆者看來**，**這本質是組織文化與權限機制的轉移。
「預設內部公開」對很多公司來說是要動筋骨的文化變革。
因為Anthropic 一開始就是一家高度信任、資訊扁平的公司，所以他並不能理解那種大公司病，尤其是傳統行業中，跨級別的資訊差，形成的資源差。
而且對於很多強合規、強資訊隔離（金融、醫療、跨法域）的組織，「工作空間級一刀切」未必可行。
所以真正可應用的是它背後的精簡審批機制，比如只要agent 在某個群，就天然可讀該群有權限的文件，即使有權限管控，也可以天然的批量管理，而非先給文件，再安排品質。
經驗二：每個人/agent 有明確角色與工具
原文的畫面感很強：人機團隊共享一份花名冊、一套產物、一個工作空間。
在這之上，agent 各有分工：
一個 agent 擁有某項項目的數據分析；
另一個持有並執行設計規範；
第三個負責研究綜合（research synthesis）。
項目啟動時，人類先和 agent 聊一聊，決定怎麼分配角色、人和 agent 如何協作。
然後產出下圖這樣的角色與規則+介入時機的組合。
角色明確之後，一個 agent 甚至可以「spin up」（拉起）其他 agent，確保每個具體任務都交給那個擁有正確記憶、正確存取權限的 agent 去做。
關鍵是工具配齊：做數據分析的 agent 可能需要 BigQuery 存取權，做 QA 的 agent 可能需要 Playwright MCP。
人類持有只有人類能持有的角色，確保讓人類判斷被用在最重要的決策上。
筆者認為：這也是 Anthropic 既往研究機制工作流程的架構。
用一個 lead agent 協調全局，把任務委派給並行運行的專門化 subagent。這類機制確實很實用，品質指標是幾乎翻倍的（高出 90.2%），雖然成本增長15倍的Token。不過，「多 agent 更強」不是普適結論，而是「在某類任務上、以可觀的算力代價換來的提升」。
尤其是廣度優先、可並行的工作中，並且由於更強的交叉驗證機制，所以資訊準確度更好。
並且還要精細設計，做好任務分解與角色隔離，而不是簡單地「多堆幾個 agent」。
否則就又是新一代畝產1萬八千斤的誤解了。
這很多觀點也在上篇文章裡如何用 Claude 的 Dynamic Workflows 做深度研究
經驗三：設定北極星角色，讓 agent 主動解決問題
原文區分了兩類 agent：一類只是「完成被指派的任務」，而最重要的那類會主動提出新項目和新工作流。
後者通常出現在一個已經具備豐富上下文、清晰角色的團隊，再加上一條額外的指引——北極星（north star）。
北極星負責幫團隊判斷「哪些任務和工作流才是對的」。
原文強調了幾條紀律：
•北極星永遠由人類設定，並紮根於公司的使命與業務目標；
•北極星一旦被清晰地寫下來，人類把它分享給團隊裡的 agent；
•然後——這一步很關鍵——人類挑選哪些 agent 應當主動提議新工作流。
假定一個營運驅動的產品和公司，那就應該讓營運角色來成為主導agent，而非是產品驅動，或者技術驅動，財務驅動。
就像如何用 Claude 的 Dynamic Workflows 做深度研究中的 路由模式（Classify-And-Act），先由一個 agent 分辨任務類型，再把任務分發給最適合的專門 agent 去做。
**筆者認為，**之前看 Anthropic 有不少文章，都有提現出在他們眼中什麼是 agent ，什麼是 workflow？
前者則「動態主導自己的流程和工具使用，掌控如何完成任務」。
而後者 是「透過預定義程式碼路徑編排」的確定性系統；
所以要做ai團隊，是應該給 agent 一條北極星而非一張任務清單，正是在有意識地把系統從 workflow 推向 agent。
一個有目標的Team會帶來一些創造力，而不是在有限的範疇內沒事找事。
當然，我們現在做的很多ai team，其實是程式化或者ai化workflow，這已經能解決很多問題了，如果我們後續需要的是創意性，自驅的，有主動解決問題能力的，則必須要設計這樣agent式的team。
經驗四：讓agent隨時間成長
這裡官方的數據非常讓我驚訝，他說：Anthropic 的工程師已經能讓團隊裡的 agent 獨立處理 500 個 bug 修復——但緊接著強調：「things certainly didn't start off that way（一開始絕不是這樣）。」
它把 agent 類比成新入職的人類同事：需要多輪反饋才能把「任務到底怎麼做最好」這種隱性知識外顯出來。
用戶必須反覆用各種任務去試探 agent，才能摸清它的能力邊界、如何清晰描述目標、它需要哪些 skill 文件、什麼 prompt 最能引出期望行為。
原文還特別提醒一個容易被忽視的點：模型會升級，任務要重測——prompt 可能要重寫，過去有用的護欄（Harness）可能反而會束縛一個更聰明的模型去尋找更有創造力的解法。
這條經驗裡含金量最高的，是關於**驗證（verification）**的論述：
程式碼有測試，這是當然的；
但大多數其他工作同樣可以被驗證：技術文檔可以套用評分量規（rubric）和風格指南（style guide）；
當人類設定好標準、並確保交給 agent 的所有工作都可被審查時，品質就能保持、不偏離初衷；
此外，可以讓一個 agent 幹活、另一個 agent 檢查——這就是常說的 「Doer-Verifier」（執行者—驗證者）agent harness。
原文有個完整案例：某位工程負責人接手一個積壓（backlog）很重的新團隊，他叫上幾個人 + 幾個 agent 一起梳理優先級。
一組 agent 通讀所有積壓項、判斷是否有人在做、給無主項打複雜度分；
另一組從清單裡篩出中低複雜度項、直接產出程式碼改動。
起初，人類審查 agent 的每一個決策，並標出需要人介入的那些；然後，人類「教會」agent 把這類決策直接拋給人類，確保有艱難權衡的決定永遠有「human in the loop」。
並且每週，團隊還讓 agent 編一份包含「經驗與失誤（lessons & missteps）」的週報，讓 agent 記住錯誤、避免重犯。隨著時間推移，負責人能交給 agent 越來越複雜的改動，自己花在日常指導上的時間越來越少，如下圖：
像極了養聰明龍蝦的過程。
最後一段是全文我最欣賞的一處洞察——當 agent 變得更獨立之後，負責人開始教 agent 把「人類注意力」當作稀缺資源來對待：
比如把問題批次化，讓人一次性回答，重複關鍵上下文，讓人快速進入狀態，限制一次性丟給人的事項數量。
有些人甚至專門設一個 agent，唯一職責就是決定如何批次處理、並只把最重要的溝通上升給人類。
另一些人則給 agent 設「每天最多做多少工作」的護欄——這樣人類才來得及有意義地參與，並且保住對自己重要的技能不被荒廢。
筆者認為，這些經驗是整篇文章在「人機關係」上最深刻的地方。
第一，Anthropic的思想裡認為：有效的監督不是審批每一個動作，而是「處在能在關鍵時刻介入的位置」（being in a position to intervene when it matters）。
第二，把「人類注意力」顯式當作稀缺資源去優化，是一個被嚴重低估的設計原則。大多數關於 agent 的討論都在優化「agent 的能力」，而效率實際的瓶頸已經是「人的認知帶寬」了。
第三，Harness駕馭工程是在人機團隊裡，應該完全模擬高效團隊的方式，畢竟有些好馬，確實不需要韁繩，只需要目標。
四、人機協作時代，會無情地放大原團隊的組織品質
這篇文章最誠實、也最容易被忽略的一句話出現在結尾：
他說，上面這4條經驗其實並不新穎，早在AI出現之前就存在了，好的團隊要有強有力的北極星、清晰的角色、紮實的文件、共享的品質標準、從錯誤中學習的空間，都是我們幾十年來就熟知的健康團隊習慣。
而AI agent team 只是讓這些基本功變得更加重要。
如果沒有合理的機制建設，AI 不會自動讓團隊變強，甚至會造成擠壓，最終帶來混亂，比如：
上下文渙散的團隊（如靠資訊差來管理），接入 agent 後只會更渙散（資訊隔絕越大，產出越偏離）；
角色定位混亂的團隊，agent 只會複製混亂，互相工作職責紊亂，決策者判斷源失真。
沒有驗證文化的團隊，agent 的錯誤會以更快的速度規模化，AI程式碼的速度已經遠超過人的CR速度。
因此，筆者認為，「從這波 agent 紅利裡拿到最多的團隊，也是那些最有意識地去踐行這些基本功的團隊。」
對正在押注 AI agent 的組織來說，這篇文章給出的真正功課，或許不在「怎麼用 Claude」，而在回頭把自己團隊的上下文、角色、目標與品質標準這四件舊事，認認真真地重做一遍。