Knowledge Base

閱讀站

首頁而家只顯示最近 50 篇文章，避免文章量愈大愈拖慢首頁載入。

共 1227 篇文章

寫好一個 Skill 有多難？Anthropic 踩了幾百個坑之後的答案

寫好 Claude Code Skill 嘅核心：善用文件系統、Gotchas 同避免寫 Claude 已知嘅嘢

多 Agent 協調的五種模式：從最簡單的開始，按需演進

題記：本文編譯自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them[1]》，由 Cara Phillips 撰寫。用一個 Agent 搞不定複雜任務？上多 Agent 吧。這個判斷現在大家基本都認了。但上多 Agent 之後緊跟着一個更具體的問題：這些 Agent 之間怎麼配合？我之前寫過 Anthropic 的 Harness 設計和 Managed Agents 架構，都涉及到多 Agent 的分工協作。但那兩篇偏重怎麼搭基礎設施，沒有系統聊過協調模式本身該怎麼選。網上能找到的多 Agent 教程大多也停留在“拆任務 + 合結果”這個層面，對模式之間的取捨和演進路徑講得不多。Anthropic 剛發的這篇博客正好補了這個缺口，把多 Agent 協調歸納成五種模式，從最簡單到最複雜，還給出了什麼時候該從一種演進到另一種的判斷標準。讀完最大的感受是：大部分團隊的問題不是不知道多 Agent 的好處，而是上來就挑了一個聽起來最酷的模式，結果被協調開銷拖死了。Anthropic 的建議是，從最簡單的能跑通的模式開始，看它哪裏撐不住了，再往上演進。模式一：生成-驗證這是最簡單的多 Agent 模式，也是部署最廣的。Generator-Verifier 模式邏輯很簡單。一個 Agent 負責生成輸出，另一個負責評估。評估通過就結束，不通過就把反饋打回給生成方，重新來一輪。循環下去直到通過或者達到最大迭代次數。最典型的應用是代碼生成：一個 Agent 寫代碼，另一個寫測試、跑測試。客服場景也適用，生成方起草郵件回覆，驗證方檢查是否準確引用了產品文檔、是否回應了用戶提到的每個問題。這個模式看着簡單，但踩坑的地方也很集中。最常見的失敗是驗證標準太模糊。如果你只告訴驗證方檢查輸出是否足夠好，它大概率會糊弄人，放行所有東西。驗證方的價值完全取決於你能不能把“好”拆成具體的、可檢查的標準。這一點在我之前寫 Harness 設計那篇裏也提過。Anthropic 的工程師 Prithvi 花了很多精力調教 Evaluator，反覆看日誌、找判斷偏差、改 Prompt，來回迭代了好幾輪才讓它的評分標準達到合理水平。另一個問題是迭代循環可能卡死。生成方解決不了驗證方提的問題，兩邊來回震盪不收斂。所以必須設最大迭代次數，加一個兜底策略，比如升級給人處理，或者返回當前最好的版本並標註問題。模式二：編排-子Agent這是層級式的分工。一個 Agent 當 Team Lead，負責規劃任務、分配工作、彙總結果。子 Agent 接到具體任務後執行完就彙報。Orchestrator-Subagent 模式Claude Code 用的就是這個模式。主 Agent 自己寫代碼、編輯文件、跑命令，需要搜索大型代碼庫或者調查獨立問題時，就在後台派 subagent 去做，自己繼續手頭的活。每個 subagent 在自己的上下文窗口裏工作，完成後把精煉過的結果返回給主 Agent。這個模式適合任務拆分清晰、子任務之間依賴少的場景。比如自動化代碼審查：一個 PR 進來，需要查安全漏洞、檢查測試覆蓋率、評估代碼風格、驗證架構一致性。每個檢查維度獨立、上下文不同、輸出格式明確。編排 Agent 把每個檢查派給專門的子 Agent，收集結果後合成一份統一的 Review。問題出在信息瓶頸上。當子 Agent 發現了對其他子 Agent 有用的信息時，這條信息必須經過編排 Agent 中轉。安全子 Agent 發現了一個認證漏洞，這個發現影響架構子 Agent 的分析。編排 Agent 需要識別這種依賴關係並正確路由信息。經過幾輪中轉之後，關鍵細節經常被丟失或者在摘要中被省略掉。我在用 Claude Code 的 subagent 時也有類似體感。subagent 搜完代碼庫回來的結果有時候會把關鍵上下文壓縮掉，主 Agent 拿到的是一個乾淨但不夠完整的摘要。對於簡單查詢這不是問題，但對於需要子 Agent 之間共享發現的複雜任務，編排模式就開始吃力了。模式三：Agent 團隊編排模式裏的子 Agent 是用完即棄的。接到任務，幹完活，交結果，走人。但如果任務需要 worker 在多輪中積累經驗呢？Agent 團隊模式的區別就在這裏：worker 是持久的。Agent Teams 模式一個協調者啓動多個 worker Agent 作為獨立進程。領任務，幹活，交結果。不重置，不遺忘。每個 worker 在多輪迭代中積累對自己負責領域的熟悉度。最直觀的例子是大規模代碼遷移。每個 worker 分管一個服務，在反覆處理這個服務的依賴、測試、部署配置的過程中，逐漸摸清它的脾氣。一次性 subagent 每次接手都要重新理解服務的配置約定和依賴關係，持久 worker 第一次弄明白之後後續迭代直接複用，省掉重複的上下文加載。但獨立性是硬前提。團隊模式裏的 worker 沒有中間人幫忙傳話。一個 worker 的改動影響了另一個，誰都不知道，產出可能衝突。多個 worker 操作同一個代碼庫時尤其明顯，常見的應對方式是文件級別的分區或者合併前跑衝突檢測，但這增加了協調者的複雜度。完成時間的參差也是個問題，一個 worker 兩分鐘搞定，另一個要二十分鐘，協調者得有耐心等。模式四：消息總線前面三種模式都有明確的協調者在指揮交通。但如果 Agent 數量繼續增加、交互模式變得不可預測呢？Message Bus 模式消息總線引入了一個共享通信層。核心操作就兩個：發佈和訂閲。Agent 訂閲自己關心的 topic，路由器負責分發。新 Agent 上線不需要改已有的連接，訂閲相關 topic 就能開始接收工作。搞過微服務事件驅動架構的應該不陌生，本質上就是 Kafka 那套思路，只不過參與者從服務變成了 Agent。Anthropic 舉的例子是安全運維自動化。告警從多個來源進來，分診 Agent 分類後路由給對應的調查 Agent，調查結果再流向響應協調 Agent。事件一個階段接一個階段地流下去，新出了什麼威脅類型就加個新 Agent，各個 Agent 還能獨立開發部署。代價是可追溯性變差了。一個告警觸發五個 Agent 之間的事件級聯，要搞清楚到底發生了什麼，調試難度比編排模式那種順序決策鏈高了不少。路由器分錯類或者丟了事件更麻煩，系統會靜默失敗，什麼都不處理但也不崩潰。模式五：共享狀態前四種模式裏都有一箇中心角色在管理信息流。共享狀態模式把這個中間人去掉了。Shared State 模式沒有中央協調者。Agent 自主運行，讀寫一個共享的數據庫、文件系統或文檔。工作一般從往存儲裏丟一個問題或數據集開始。停下來的條件有幾種：時間到了、結果收斂了，或者有個專門的 Agent 判斷存儲裏的東西已經夠用了。研究綜合場景是這個模式的主場。多個 Agent 分頭調查一個複雜問題的不同方面，學術 Agent 發現了一個關鍵研究者，這條信息對行業 Agent 調查這個研究者的公司立刻就有用。不用等協調者來路由，發現直接寫進存儲，其他 Agent 馬上就能看到。附帶好處是沒有單點故障，任何一個 Agent 停了，其他 Agent 繼續讀寫。代價也很明顯。Agent 可能重複工作或者走互相矛盾的方向。更棘手的是反應式循環：Agent A 寫了一個發現，Agent B 讀到後寫了跟進，Agent A 看到跟進後又回應。系統持續燒 token 但不收斂。重複工作和併發寫入有成熟的工程方案，加鎖、版本控制、分區都行。但反應式循環是行為層面的問題，必須認真設計終止條件：時間預算、收斂閾值，或者專門的 Agent 來判斷何時該停。這個模式讓我想到分佈式系統裏的最終一致性。沒有強協調者的好處是吞吐量高、沒有瓶頸，但你需要在應用層面處理衝突和收斂問題。Agent 領域也是同樣的取捨。怎麼選，怎麼演進五種模式擺在面前，選哪個？Anthropic 給了幾組對比的決策邏輯，我覺得最實用的是前兩組。編排-子Agent vs Agent 團隊編排-子Agent vs Agent 團隊兩者都有協調者分派工作，區別在於 worker 需要維持上下文多久。子任務短小、輸出明確的，用編排模式。子任務需要多步驟持續工作、會從積累的上下文中受益的，用團隊模式。判斷標準是：當子 Agent 需要跨調用保留狀態時，團隊模式更合適。我自己的經驗也驗證了這一點。Claude Code 日常的代碼搜索、文件查閲用編排模式完全夠用，subagent 幹完就走。但之前寫複雜 feature 的時候，需要多個 Agent 持續處理不同模塊的開發和測試，編排模式的一次性 subagent 就不夠用了，每次都要重新理解模塊上下文。編排-子Agent vs 消息總線編排-子Agent vs 消息總線兩者都能處理多步驟工作流，區別在於工作流結構是否可預測。步驟順序事先已知的，用編排模式。工作流由事件驅動、可能隨發現變化的，用消息總線。有個經驗法則：當編排 Agent 裏的條件分支越來越多、需要處理越來越多的特殊情況時，就該考慮換消息總線了。Agent 團隊 vs 共享狀態Agent 團隊 vs 共享狀態各管各的互不交叉，用團隊模式。發現需要實時流通，用共享狀態。一旦 worker 之間需要互相溝通而不只是最後彙總結果，共享狀態更自然。消息總線 vs 共享狀態消息總線 vs 共享狀態事件從一個階段觸發到下一個階段然後完成的，用消息總線。Agent 在持續積累的知識基礎上反覆迭代的，用共享狀態。還有一個值得留意的信號：如果消息總線裏的 Agent 發佈事件是為了分享發現而不是觸發動作，那你可能需要的是共享狀態。寫在最後實際生產系統往往會混用多種模式。常見的組合是外層用編排-子Agent 管整體工作流，內層某個協作密集的子任務用共享狀態。或者外層用消息總線做事件路由，每種事件類型由一個 Agent 團隊來處理。這五種模式是積木，不是互斥的選項。Anthropic 的建議是從編排-子Agent 開始。它能覆蓋最廣的問題範圍，協調開銷也最低。等它在特定場景下撐不住了，再根據具體瓶頸演進到其他模式。Claude Code 就是編排-子Agent 模式的典型實現，對大多數日常任務來說完全夠用。只有當任務複雜到需要多個 Agent 持續協作、共享中間發現的時候，才值得引入更復雜的模式。有意思的是，不同框架對協調模式的抽象思路差異很大。Anthropic 這套分類偏描述性，告訴你有哪些模式、怎麼選。LangGraph 走的是 graph-based 的路子，用狀態圖來定義 Agent 之間的流轉邏輯，更偏編程範式。CrewAI 則是角色分工優先，先定義 Agent 的角色和目標，協調模式隱含在角色關係裏。三種抽象各有適用場景，但底層要解決的問題是一樣的：誰跟誰通信、信息怎麼流、什麼時候該停。相關資源：• 原文連結：https://claude.com/blog/multi-agent-coordination-patterns• 構建多 Agent 系統：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them• Harness 設計：https://www.anthropic.com/engineering/harness-design-long-running-apps• Managed Agents：https://www.anthropic.com/engineering/managed-agents• 構建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents好了，今天就聊到這兒。如果你也在探索多 Agent 架構和 AI 編程，歡迎關注 Feisky 公眾號，我會定期分享實踐中的發現和踩坑經驗。

完成

閱讀站

寫好一個 Skill 有多難？Anthropic 踩了幾百個坑之後的答案

多 Agent 協調的五種模式：從最簡單的開始，按需演進

用 Claude Code 處理視頻太麻煩,我順手寫了個 Skill

Harness 不只是腳手架：從 Claude Code、Hermes 和 OpenClaw 看 Agent 架構的三條路

MCP 不只是開發工具：生產級 Agent 集成的三條路

OpenClaw 的正確打開方式：從也就那樣到離不開

# Codex CLI 也能用 Skills 了：把 Claude Code 的“技能包”遷了過來

GPT Image 2 的騷玩法簡直層出不窮

今天，給這個image2提示詞大佬出篇個人專輯

我決定免費分享：如何讓 Gemini 像素級復刻任意寫作風格！

服了，真是什麼都能 Skill

分享幾個我在用的 AI Skill

Claude悄悄更新了Skills生成器，這絕對是一次史詩級升級。

02 如何判斷一個創業 idea 值不值得做——YC合夥人揭秘：那些價值百億美元的創業點子是怎麼來的

55,000 個開源 Skill 的分發困局：Skill 商業化三角少了一條邊

每週 5 小時到每天 10 分鐘：我用 CREAO Agent 把競品情報做成自動化流水線

£148 搞定英國公司年審，淘寶報 ¥2000 還不含税款

38k 星，Matt Pocock 把工程師級 Skill 全開源了，專治 Claude Code "vibe coding"

一個自媒體博主做了17個開源Skills拿到9000 Star，他總結的四條設計哲學

版本管理名字瞎寫：三個 refine, 和一堆 .DS_Store

Vibe Coding數據分析時代，不要再用Excel做數據中轉了

Vibe Coding多個對話框如何承接的小技巧，以及其它

Week #6｜我花1小時寫了一個YouTube轉PDF逐字稿的Skill

2026 年，最需要掌握的一個AI使用習慣

1000一年的輸入法，用上之後真的再也不想打字了

YouTube 視頻也能存進 Obsidian？這個插件我低估它太久了

全網都在抄 Karpathy 的知識庫，但大多數人只學到了皮毛

NotebookLM × Gemini 徹底打通，我找到了 AI 時代知識庫的最優解

卸掉一堆 App 之後，我的 Mac 真正離不開的就這 6 個

GPT-5.5 發佈，讓我重新認識了 Codex

用了兩個月，我從 N 個 Obsidian Skills 裏篩出了這 7 個

拒絕算法投餵，我用 Openclaw+Notion 搭了一套 YouTube自動化信息流

我用 Claude Code + Obsidian + NotebookLM 搭了一套會自我進化的AI研究系統

每日一 Skills 推薦｜baoyu-skills：13000 Star 的內容創作全家桶，從選題到發一條龍

會用AI的人，已經不需要學編程了—Vibe Coding實踐

AI時代，做一個會玩的人——把工作交給Skill

一覽7 個視頻合成Skills

自己做了一個 YouTube 視頻摘要 Skill

長視頻沒耐心看？快使用這個Agent Skill！！

絕了！這個視頻生成 Skill封神了

清華開源王炸！一鍵生成沉浸式 AI 互動課堂，多智能體陪你學到底

用大廠PUA話術逼AI寫代碼？這個開源項目，治好了AI編碼助手的擺爛病

解決了我最大的焦慮：開源 AI 筆記，數據 100% 自己掌控

同事.skill 火了之後，有人把前任也做成了 AI，結果有點失控！

同事離職後，我讓他繼續給我幹活！這個 Skill 讓他 "賽博永生"

一行命令搭建 AI 朝廷！這個開源項目讓你當皇帝，指揮 18 個 AI 大臣幹活

開源 TTS 天花板被捅破！VoxCPM2：20 億參數，30 種語言，48kHz，全功能免費商用

一條命令克隆任何網站！這個開源神器讓網站重構效率直接拉滿

告別信息差！這個 AI 代理技能，幫你抓住別人看不到的 30 天熱點

ljg-skills技能使用手冊