大家好，我是魯工。Agent Teams不算啥新功能了，我很早就在Claude Code裏面用上了。之前有Agent swarm、Agent group等叫法，但本質上都是並行驅動多個Agent來完成任務，其實就是開團。我上週末把Claude Code中有關Agent teams的文檔仔細研讀了下，發現這個東西能挖的東西挺多。這篇文章按官方文檔的邏輯順序串起來寫一下：先講清楚和subagents的區別、什麼場景該用、怎麼啓動、怎麼控制、怎麼算才算最佳實踐，再用三個我自己跑過的實測案例落到具體場景。看完這篇基本能從零上手。Agent Teams vs. SubagentsClaude Code裏做多任務並行，之前主要靠Subagents（子智能體）或者git worktrees。這塊我之前寫過一些文章，具體可參考：用Subagents打造Claude Code專業開發團隊Claude Code + Git Worktrees，並行開發最正確的打開方式Subagents能有獨立的context window、配專用的系統提示、選不同的工具和模型。但它有個天花板：只能向主代理彙報結果，彼此之間沒有直接對話的通道。Agent Teams把這個限制打掉了。三個維度看差別：維度SubagentsAgent Teams通信只向主代理彙報隊友之間直接收發消息協調主代理統一管理共享任務列表+自協調Context自己的窗口，結果回主會話自己的窗口，完全獨立Token成本較低（結果彙總）較高（每個隊友是獨立Claude實例）適用場景結果導向的專注任務需要討論和質疑的複雜工作總結下就是，Subagents是實習生各自給領導交作業，Agent Teams是小組同事坐一起能互相討論。Agent Teams什麼時候啓用不是所有任務都適合開團。因為開團的token成本是真的高，一個3人團隊的token消耗大概是單會話的3到4倍，盲目濫用會很疼。官方文檔列了幾個最強用例：研究和審查類任務。多個隊友可以同時調查問題的不同方面，然後互相分享和質疑彼此的發現。比如審一個PR，三個隊友分別負責安全、性能、測試覆蓋三個角度。新模塊或功能開發。每個隊友擁有一個獨立的部分，不會相互干擾。前提是任務可拆，文件不衝突。帶競爭假設的Bug調試。多個隊友各拿一個理論並行測試，能更快收斂到根因。這個對抗"找到一個看似合理的解釋就停下來"的錨定偏見特別有用。跨層協調。前端、後端、測試改動同時進行，每個隊友負責一個方面。反過來不適合的場景也很明確：順序依賴強的任務（B必須等A完成）、同一個文件多人編輯（容易覆蓋）、依賴關係特別多的工作。這幾種場景下要麼用單會話順序處理，要麼用subagents就行，強行開團反而是負擔。如何啓用Agent TeamsAgent Teams功能在Claude Code中並不是默認開啓的，開團有兩個前置條件。一是Claude Code v2.1.32以上（這個大家基本都滿足，Native安裝方法會自動更新Claude Code版本）。二是在 ~/.claude/settings.json 里加一個環境變量：{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }}啓動方式很簡單：直接用自然語言告訴Claude你想要什麼團隊、做什麼任務。Claude自己負責創建team lead、生成teammates、協調工作。官方文檔裏給的標準例子：I'm designing a CLI tool that helps developers track TODO comments across their codebase. Create an agent team to explore this from different angles: one teammate on UX, one on technical architecture, one playing devil's advocate.這條prompt官方原話是"This example works well"，三個角色獨立、不需要互相等待，開團效果最好。觸發關鍵詞很關鍵。prompt裏必須顯式出現agent team / teammate / team lead / shared task list這類詞，Claude才會走Agent Teams分支。中文口語裏說的"開兩個agent並行"、"派兩個子代理"這種寫法有概率會被識別成subagents，可能不會創建team。指定隊友數和模型。Claude會根據任務自己決定開幾個隊友，但你也可以直接指定：Create a team with 4 teammates to refactor these modules in parallel. Use Sonnet for each teammate.也可以讓不同隊友用不同模型，比如lead用 Opus、teammate用Sonnet控制成本。Claude主動提議團隊。如果你給的任務確實受益於並行，Claude會主動建議開團，但不會未經你同意就創建。最終決定權在你手裏。判斷team是否真的被創建有個硬標準：執行後看 ~/.claude/teams/ 目錄下有沒有新生成的team目錄（帶config.json）。有目錄才是真的開團了；沒有就是走的subagents。如何控制Teammates團隊跑起來之後，你不是隻能等結果，整個過程都可以介入。先看顯示模式，Agent Teams功能支持in-process和split panes兩種顯示模式：In-process：所有隊友都跑在主終端裏，用Shift+Down循環切換。任何終端都能用，不用額外裝東西。Split panes：每個隊友一個獨立窗格，輸出全程可見，點擊哪個窗格就直接進到對應隊友的會話。需要tmux或iTerm2支持。啓用方式三種，從大到小：全局config，在 ~/.claude.json 裏設：{ "teammateMode": "tmux"}單次啓動flag：claude --teammate-mode tmux默認auto模式：我們已經在tmux session裏打開Claude Code，Claude會自動切split panes，否則回到in-process。split panes的兩種入口：tmux（macOS下最穩定）；iTerm2，需要安裝it2 CLI，並在Settings → General → Magic開Enable Python API）。每個隊友都是完整獨立的Claude Code會話，可以直接給它們發消息：In-process模式：Shift+Down切到目標隊友，輸入消息直接發；Enter進入隊友會話查看詳情，Escape中斷當前輪次；Ctrl+T調出共享任務列表。Split-pane模式：直接點擊窗格就能進對應隊友的會話，每個隊友有完整終端視圖。共享任務列表協調整個團隊的工作。任務有三種狀態：pending、in progress、completed，還可以設置依賴關係（一個任務blocked by另一個時，依賴任務不解除就不能認領）。兩種分配方式：lead顯式指派（"把這個任務給researcher隊友"），或者隊友完成自己的任務後自動認領下一個未分配的。複雜或風險高的任務可以要求隊友先做planning，lead審過才動手：Spawn an architect teammate to add structured logging middleware. Require plan approval before any changes. Reject any plan that does not include rollback strategy and test coverage.關鍵：在prompt裏給lead寫清楚批准準則（"必須包含測試覆蓋"、"必須有回滾方案"），不然lead會按自己的判斷批。被拒絕的隊友會留在plan模式，按反饋修訂重新提交。關閉和清理方面，可以選擇關閉單個隊友以及任務完成後清理團隊。關閉單個隊友：Ask the researcher teammate to shut down隊友收到關閉請求可以批准或拒絕。整個團隊跑完，跟lead說一句：Clean up the team這會刪除共享團隊資源。如果還有隊友在跑，清理會失敗，先關閉它們再清。這一步必須由lead執行，隊友自己跑clean會出問題。另外還可以使用hooks強制質量門。Agent Teams配套了三個新的hook事件：TeammateIdle（隊友空閒時）、TaskCreated（任務創建時）、TaskCompleted（任務完成時）。在hook裏以exit 2退出可以阻斷對應行為，stderr內容會作為反饋傳給teammate。適合把團隊規範硬編碼進去，比如"任務標記完成前必須跑過測試"、"不允許創建修改數據庫schema的任務"。比prompt裏反覆叮囑可靠得多，prompt是軟約束模型可能忘，hook是硬約束直接攔住。兩個實測玩法下面給兩個Agent Teams的玩法，一個是常規啓用玩法，一個是tmux啓用玩法。案例一：一句話調研開團最常規的玩法，給一個調研任務+大致角色分工，剩下交給Claude。比如：啓用Agent Teams幫我調研Claude Code中MCP、Skills、Plugins、Hooks、Agent teams的核心區別與聯繫。跑下來Claude會自動創建team lead加5個teammates，各跑各的方向，最後lead綜合輸出。案例二：使用tmux體驗分窗並行我們可以把上述常規的Agent teams啓用方法在tmux下重試一遍，感受下tmux對多個teammates的自動分窗並行效果。並行工作的最佳實踐跑過幾個團隊之後總結的幾條經驗，結合官方建議。給隊友足夠的context。隊友自動加載項目級的CLAUDE.md、MCP servers和skills，但不會繼承lead的對話歷史。在生成prompt裏要把任務相關的關鍵信息寫清楚，特別是文件路徑、模塊約定、技術棧細節。團隊規模3到5個最合適。再多協調開銷和token成本就指數上升，3到5個隊友做5到6個任務每人是經過驗證的甜蜜點。如果有15個獨立小任務，3個隊友是一個好起點，讓隊友各自輪轉處理。teammates多了，即使是Max 20x訂閲，也很容易觸發五小時限額：任務粒度要恰到好處。太小協調開銷超過收益；太大隊友長時間不check浪費風險高。理想粒度是一個自包含的可交付單元（一個函數、一個測試文件、一份審查）。等隊友完成再繼續。lead有時會自己開始幹活而不是等隊友。如果發現這種情況，直接告訴它 "wait for your teammates to complete their tasks before proceeding"。從研究和審查類任務入手。新手第一次開團，建議從不需要寫代碼的任務開始（PR審查、庫調研、Bug調查），這種任務邊界清楚、不涉及並行實施的協調挑戰，能直觀感受到Agent Teams的價值。避免文件衝突。兩個隊友編輯同一個文件會互相覆蓋。任務拆分時保證每個隊友擁有獨立的文件集。主動監控和指導。讓團隊無人值守跑太久會浪費成本。中途用 Ctrl+T 看任務列表，發現方向跑偏直接Shift+Down過去重定向。最容易碰上的問題：team怎麼都開不起來。prompt跑下去仍然是Running N agents...這種subagents形態。那麼請按下列順序自查：prompt裏有沒有顯式用 agent team / teammate 關鍵詞（啓動章節強調過的）echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS確認下輸出是不是1改完settings.json有沒有完全退出Claude Code重啓跑完prompt後 ls ~/.claude/teams/ 看下目錄有沒有生成新team。有目錄才是真觸發了，這是判斷的最硬標準Agent Teams本質上是Claude Code工具層在多智能體協作上的一套工程化實現。3到5人的小團隊規模、開發者能看懂每一步的透明度、本地直接跑不依賴雲端，這些是它的核心定位。如果你的任務到了幾百個sub-agent併發那種量級（比如一次性生成30個落地頁、批量匹配100個崗位生成簡歷），可以去看看Kimi K2.6剛發的Agent Swarm，走的是另一條雲端大規模分解的路。兩者定位不重合，按場景選就是了。如果覺得有用，點個贊或者在看，也方便更多朋友看到。我是魯工，九年AI算法老兵，AI全棧開發者，深耕AI編程賽道。歡迎關注，感興趣的朋友也可以加我微信（louwill26_）交個朋友。>/ 作者：魯工

完成

我聽了三小時出海創業直播，把哥飛、彪哥、壹樹的話整理成這篇筆記

出海創業核心：先開槍再瞄準、創始人親力親為、朋友係戰略低成本、AI係基礎設施

完成

DeepSeek V4好用嗎？【秋芝的AI開箱】

DeepSeek V4 唔係炸裂之作，但百萬上下文變標配、Agent能力強，性價比高，絕對值得用

完成

開源我的 7 個寫作Skill 流程，4 個 Skill 方法論

01最近我用得最順手的 Skill，是寫作。傳統的寫作流程是：搜熱點、找選題、開始寫、寫完改、改完發。每一步都要自己動手，每一步都有卡點：選題難：刷了一小時，不知道寫什麼動筆難：有了選題，不知道怎麼開頭堅持難：寫了幾百字，沒靈感了，下次再說但自從用了 Skill 組合，全都變了。熱點採集，Skill 幫我從 5 個平台並行搜索，自動整理成列表。選題篩選， Skill 幫我打分排序，挑出最值得寫的 TOP10。內容創作， Skill 用問答方式把我腦子裏的想法挖出來，再組織成文章。文章審稿？ Skill 用編輯視角幫我找問題，給修改建議。我只需要在關鍵節點做決策，其他全是自動化完成。通過這一套寫作流程，我提煉出了一個 Skill 組合的通用方法。這個方法可以幫你：把複雜任務拆解成 SOP設計多個 Skill 的搭配組合複用到任何領域（不只是寫作）今天這篇文章，我會先展示完整的寫作 Skill 鏈路，再抽象出背後的方法論，最後用一個產品經理的工作流案例來驗證它。02 拆解：我用到的 7 個 Skill一開始我只是一個個的 Skill 分開用，後面發現各種各樣的玩法，開始把這些 Skill 組合再一起使用。所謂的組合也就是把上一個 Skill 的輸出內容給到下一個 Skill 來輸入。單個 Skill 的價值遠遠小於多個可組合 Skill 的價值。這要在你使用過程中才能體會到有多震撼。下面我來演示我這個穩定運行的寫作 Skill 流水線。Skill 1：topic-collector（熱點採集）觸發方式：說"開始今日選題"或"採集熱點"工作原理：這個 Skill 會並行搜索 5+ 數據源，把分散在各平台的信息聚合成結構化列表。數據源包括：Twitter/X：重點 AI 博主（@AnthropicAI、@kaborsk1、@levelsio 等）Product Hunt：當日 AI/開發工具上榜產品Reddit：r/ClaudeAI、r/ChatGPT、r/LocalLLaMAHacker News：Show HN 項目和熱門討論官方博客：Anthropic、OpenAI、Google DeepMind輸出格式：按來源分類，每條熱點附帶原文連結、熱度指標、一句話摘要。原理：用預設的搜索關鍵詞組合，調用 WebSearch，然後用模板格式化輸出。下載地址：https://github.com/zephyrwang6/myskill/tree/main/topic-collectorSkill 2：topic-generator（選題生成）觸發方式：說"生成選題"或"篩選熱點"工作原理：接收 topic-collector 的熱點列表，按選題價值打分篩選，輸出 TOP10。篩選標準：必須滿足：AI 相關、有用戶價值、國內用戶能理解加分項：熱度高、24h 內新鮮、有獨特角度、可操作輸出內容：每個選題包含：事件描述（一句話說清楚發生了什麼）核心角度（為什麼值得寫）推薦標題（3 個備選）預估熱度（1-5 星）原理：用評分矩陣對每條熱點多維度打分，按總分排序取前 10。下載地址：https://github.com/zephyrwang6/myskill/tree/main/topic-generatorSkill 3：topic-reviewer（選題審核）觸發方式：說"審核選題"或"這個選題行不行"工作原理：這是選題的守門員，決定一個選題是否值得投入時間寫。審核機制：一票否決項：熱度 <100、與 AI 無關、超過 72h 舊聞、無可操作內容評分制（滿分 100）：獨特角度 30%、用戶價值 25%、國內適配 20%、標題吸引力 15%、寫作難度 10%通過線：70 分以上才值得寫。輸出：通過/不通過 + 評分表 + 修改建議。原理：把"要不要寫"這個主觀判斷，變成可量化的評分體系。避免衝動寫作，也避免好選題被放棄。下載地址：https://github.com/zephyrwang6/myskill/tree/main/topic-reviewerSkill 4：doc-coauthoring（共同創作）觸發方式：說"幫我寫文章"或"我們一起寫"工作原理：這是最複雜的 Skill，包含三大階段、7-8 種創作方法：可以參考我這篇文章：6 個工作流寫出“人”的質感具體原理如下Stage 1：Context Gathering（上下文收集）AI 提問：這篇文章寫給誰？想達到什麼效果？用戶信息傾倒：把知道的背景、素材、想法全說出來AI 追問：針對模糊點繼續提問，直到理解充分Stage 2：Refinement & Structure（迭代優化）按章節逐個完成：Clarifying Questions：針對這一節問 5-10 個問題Brainstorming：生成 10-20 個可能的內容點Curation：用戶選擇保留/刪除/合併哪些Gap Check：檢查是否遺漏重要內容Drafting：AI 撰寫這一節初稿Iterative Refinement：用戶反饋 → AI 修改 → 循環Stage 3：Reader Testing（讀者測試）用"無上下文的新讀者"視角閲讀文章檢查：有沒有看不懂的地方？假設了讀者不知道的信息？發現盲點後返回 Stage 2 修改原理：把寫作從"一個人憋"變成"兩個人聊"。通過結構化的問答，把腦子裏的隱性知識挖出來，再由 AI 組織成文字。地址：https://github.com/zephyrwang6/myskill/tree/main/doc-coauthoringSkill 5：article-review（深度審稿）觸發方式：說"審稿"、"幫我評價這篇文章"或"文章評審"工作原理：這個 Skill 模擬一個 AI 時代的資深內容主編角色，從心法、戰略、技法、修煉四個維度對文章進行全方位深度評審，確保內容具備"活人感"、"真誠度"和"專業性"。審稿法：活人感：是否有個人真實經歷/情感波動？是否有"我以為/我覺得"的主觀視角？真誠度：是否有誇大其詞或隱瞞缺點？引用的數據/案例是否可靠？價值觀：是否為了流量違背自己的認知？老讀者看到會覺得你變了嗎？選題質量:評估專業領域 × 讀者普遍興趣 × 當下時間節點三者交集 = 好選題（決定80%的生死）結構是否清晰？重點是否加粗？一目十行能抓住核心嗎？輸出：修改建議清單 + 改寫示例。原理：用一套固定的審稿框架，每次審稿都覆蓋關鍵維度，不遺漏問題。下載：https://github.com/zephyrwang6/myskill/tree/main/article-reviewSkill 6-7：NotebookLM 配圖 + 發佈這兩步是手動操作：把終稿複製到 NotebookLM，用提示詞生成全文配圖上傳公眾號後台，排版發佈未來可能也會 Skill 化，但目前手動效率也夠用。不必追求完全的自動化，而是追求核心卡點。03 抽象：發現的通用模式用了一段時間後，我發現這些Skill 組合有規律可循。我總結了四個方法：方法1：任務分解每個複雜任務都能拆成三步：信息獲取 → 做決策 → 執行交付客觀信息交給 AI 決策，主觀信息交給人來決策。比如今日熱點信息是什麼，完全由 AI 處理就好了。但是涉及到選題是什麼，大綱怎麼寫都需要人來輸入信息給 AI 決策。寫作任務對應：採集熱點 → 選題審核 → 創作輸出。方法 2：Skill 流水線每個 Skill 是一個小員工：上一個 Skill 的輸出 = 下一個 Skill 的輸入比如上面提到的寫作 Skill：熱點列表 → 選題方案 → 文章初稿 → 審稿建議 → 終稿。方法 3：模塊化Skill 分三類，像樂高積木一樣組合：信息模塊：搜索、採集、閲讀思考模塊：分析、比較、決策產出模塊：寫作、格式化、發佈信息和產出需要調用工具，需要 MCP、API 的配置而思考決策需要足夠量的上下文。方法 4：循環反饋好的 Skill 組合自帶檢驗環節：Plan → Do → Check → Act寫完初稿（Do）→ 審稿打分（Check）→ 修改（Act）→ 再循環。通用組合公式：理解上面這四個方法，掌握這些公式，你可以設計任何領域的 Skill 組合。04 舉一反三：產品經理的 Skill 組合寫作只是一個場景。讓我用更復雜的案例來驗證這套方法論。我剛根據自己的工作設計了一套產品經理 Skill 組合。信息獲取：輸入需求信息（用戶描述、競品參考、業務背景）。決策優化：需求澄清和優化（AI 提問、補充細節、去除歧義）。產出執行：直接在原型代碼倉庫進行設計（生成可交互原型）。質量檢驗：設計後截圖 + 按模板輸出需求文檔同樣的公式：信息 → 決策 → 產出 → 檢驗。但這套 Skill 跑完，我意識到一個問題，假如以後用戶直接提出需求，運行一套全自動的 Skill，輸出原型和設計文檔給到開發，就不需要產品經理了。甚至更進一步，連開發都不需要了。用戶自己自定義 APP 的樣式，AI 直接生成可用的產品。那個時候，產品經理還會不會存在？如果存在，他們的職責和技能必定會發生巨大變化。從"需求文檔撰寫者"變成"Skill 組合設計者"？從"畫原型的人"變成"定義什麼是好產品的人"？AI 有了 Skill ，那人類的核心技能是什麼？這是 AI 時代每個職業人都該思考的問題。05 結語組合 Skill 的核心心法只有一句話：把複雜任務拆成流水線，每個環節交給專門的 Skill。你不需要一開始就設計完美的組合。先跑通一個最小流程，再逐步添加"決策"和"檢驗"環節。就像搭樂高，先有骨架，再豐富細節。希望這篇文章能幫你找到自己的 Skill 組合方式。我是空格，本文由我的寫作 Skill 和我共同完成，有什麼好的想法歡迎在評論區告訴我。有用的話，點贊轉發支持一下。

完成