Agent on KnightLi的博客

CLI-Anything：把軟體變成 Agent 可用的命令列

Mon, 25 May 2026 00:24:36 +0800

CLI-Anything 是 HKUDS 開源的 Agent 工具化專案，目標是把原本面向人類 GUI 操作的軟體，轉成 AI Agent 更容易呼叫的命令列介面。它不是重新實作一個簡化版軟體，而是圍繞既有程式碼庫和真實後端生成 CLI harness，讓 Agent 可以透過穩定命令、狀態會話和結構化輸出來完成任務。

這個方向解決的是 Agent 使用軟體時最常見的斷層：GUI 自動化依賴截圖、點擊和座標，容易受介面變化影響；單一 API 又經常覆蓋不完整，Agent 需要自己拼接大量上下文。CLI-Anything 選擇把軟體能力收斂成命令列，因為命令天然適合被模型讀取、組合、驗證，也便於接入腳本和自動化流程。

它怎麼工作

官方倉庫把 CLI-Anything 描述為一套自動生成 CLI 的流水線。給它一個本機軟體原始碼路徑或 GitHub 倉庫地址後，流程會分析程式碼結構、識別後端和資料模型，設計命令分組，再實作 CLI、測試和文件。

生成出來的 CLI 通常包含兩種使用方式：一種是面向連續工作的 REPL，會保留專案狀態；另一種是子命令模式，適合腳本和流水線。命令還會提供 JSON 輸出，方便 Agent 直接解析結果，同時保留人類可讀的格式用於除錯。

官方範例裡，Claude Code 外掛可以這樣使用：

1
2
3

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything <software-path-or-repo>

如果已經生成某個軟體的 harness，後續使用方式會更接近普通 Python CLI：

cd <software>/agent-harness
pip install -e .
cli-anything-<software> --help
cli-anything-<software>
cli-anything-<software> --json <command>

適合什麼場景

CLI-Anything 更適合那些「能力在真實軟體裡，但 Agent 不好穩定操作」的場景。例如影像、影片、音訊、辦公文件、3D 建模、資料分析或 AI/ML 工具鏈，只要專案有可分析的程式碼庫、可呼叫的後端或清晰的資料模型，就有機會被包裝成 Agent 可用的命令集。

它的價值不只是在命令列裡多一層封裝，而是把軟體的關鍵操作變成可發現、可組合、可測試的介面。Agent 可以先透過 --help 理解能力，再用 JSON 輸出接收結果，並把多個命令串成工作流。對於需要批次處理、自動驗證和持續迭代的任務，這比臨時讓 Agent 點擊介面更可控。

需要注意的邊界

CLI-Anything 並不等於任何軟體都能立刻無成本接入。它依賴目標軟體的原始碼、後端能力、檔案格式和可測試性；如果一個軟體高度封閉、關鍵邏輯只存在於 GUI 層，生成高品質 CLI 的難度會明顯上升。

官方方法論也強調真實後端和測試驗證，這意味著生成 harness 不是只寫幾個命令包裝腳本就結束。要讓它用於嚴肅工作，還需要確認命令覆蓋範圍、輸出格式、依賴安裝、真實軟體呼叫和端到端測試是否可靠。更現實的用法，是先為一個明確工作流生成 CLI，再透過 refine、test、validate 等命令逐步補齊能力。

小結

CLI-Anything 的思路很直接：不要讓 Agent 去適應脆弱的人類介面，而是為現有軟體補上一層穩定、結構化、可測試的命令列入口。它適合想把專業軟體納入 Agent 工作流的人，也適合研究「Agent 原生軟體」形態的開發者。真正落地時，重點不在於一句命令生成了多少程式碼，而在於生成的 CLI 是否能呼叫真實能力、保持狀態、輸出結構化結果，並經得起測試。

DeepSeek V4 Flash 做 Godot 遊戲 Demo：幾毛錢能跑通到什麼程度？

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash 用來開發 Godot 遊戲 Demo，到底能不能打？

重點很直接：它能不能做出一個可執行、可觀察、帶物理效果的 Godot 小 Demo。

結論先說：可以跑通，效果不算商業級，但已經足夠作為玩法原型和物理互動 Demo 使用。更重要的是，成本非常低，適合快速驗證想法。

Demo 表現

這個 Demo 的重點是物理互動。

幾個比較直觀的效果包括：

繩子可以被切斷。
箱子會掉到地上。
調大質量後，箱子碰撞會更猛烈。
繩子表現出比較明顯的彈性。
調整摩擦力和彈性後，箱子會出現明顯的滑動和反彈。

從呈現效果看，它已經不是「只生成幾段 Godot 腳本」那麼簡單，而是一個能執行、能觀察物理表現的小型原型。

可用程度

這個 Demo 的價值在於「能跑、能看、能改」。它不是完整遊戲，也不是可以直接商業化的工程，但已經能說明幾個問題：

DeepSeek V4 Flash 能理解 Godot Demo 的基本目標。
AI Agent 可以把需求轉成可執行工程。
Godot 物理互動這種非網頁類任務，已經可以進入低成本原型階段。
對個人開發者來說，它能把「想法」快速變成「能看的東西」。

如果目標是做一個正式遊戲，它當然還不夠；但如果目標是驗證「這個玩法有沒有意思」「物理效果大概能不能做出來」，這個 Demo 已經可用。

成本意義

最值得關注的不是畫面有多精緻，而是成本。

如果一個 Godot 物理 Demo 只需要幾毛錢級別的模型成本，就能得到一個可執行版本，那麼它的意義就不是替代專業遊戲開發，而是大幅降低原型試錯成本。

以前想驗證一個小遊戲想法，至少需要自己熟悉 Godot、寫腳本、調場景、調物理參數。現在可以先讓 AI Agent 生成一個可執行版本，再由人判斷方向對不對。

對獨立開發者來說，這類低成本試錯很有用：

快速驗證玩法概念。
生成臨時 Demo 給別人看。
探索 Godot API 和物理系統。
把想法轉成能跑的初版工程。
在不確定方向前減少手寫程式碼成本。

DeepSeek V4 Flash 的表現

比較值得注意的是，使用的是 DeepSeek V4 Flash，而不是更貴、更重的旗艦模型。

它在「低成本原型」這個定位上表現不錯。它不是最強、最穩、最適合交付生產工程的模型，但在預算敏感、想快速試一下方向的場景裡，很有吸引力。

適合什麼場景

DeepSeek V4 Flash + Agent + Godot 更適合下面這些任務：

小型玩法原型。
物理效果 Demo。
UI 或互動概念驗證。
教學示例。
輔助理解 Godot 專案結構。
生成第一版可執行工程。

不太適合直接承擔這些任務：

大型遊戲架構。
複雜角色控制器。
網路同步。
商業專案核心程式碼。
高精度物理模擬。
不經過人工測試的自動提交。

換句話說，它適合做「第一稿」和「試驗場」，不適合當生產工程負責人。

這說明了什麼

這說明，AI 程式設計正在從網頁、腳本、後端介面，繼續向遊戲開發和互動原型擴展。

過去遊戲開發的門檻很高，尤其是引擎、腳本、資源管理和物理系統混在一起時，新手很容易卡住。現在模型加 Agent 工具，可以先把工程搭起來，讓開發者把注意力放在玩法判斷和效果調優上。

它帶來的變化可能有三點：

第一，遊戲原型會更便宜。很多想法不用等到完整開發階段才驗證，可以先得到可執行 Demo。

第二，獨立開發者會更敢嘗試。不會 Godot 的人，也可以借助 AI 先摸到專案結構和基本流程。

第三，模型穩定性會變得更重要。遊戲開發不是只要程式碼能跑，還要效果合理、手感正常、參數可控。未來誰能更好地結合實際畫面和執行狀態，誰就更適合做這類任務。

小結

DeepSeek V4 Flash 做 Godot Demo，可以概括成一句話：效果不完美，但足夠便宜、足夠快，也足夠適合做原型。

它離商業遊戲還很遠，但如果目標是用極低成本驗證一個小遊戲想法，它已經很有價值。

對個人開發者來說，最現實的用法不是把遊戲全交給 AI，而是讓 AI 先給出能跑的工程，再由人負責判斷、取捨和打磨。這樣用，DeepSeek V4 Flash 這類低成本模型反而會很香。

DeepSeek-V4 Preview 發布：1M 上下文、雙模型與 API 切換提醒

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek 在 2026-04-24 發布了 DeepSeek V4 Preview Release。從官方新聞頁來看，這次更新的重點非常集中：1M context、V4-Pro 與 V4-Flash 雙模型、針對 Agent 場景的專門優化，以及 API 側的模型切換。

如果只看一句話，這次發布的核心訊號是：DeepSeek 不只是繼續做更強的模型，而是在把超長上下文和 Agent 能力一起往「可以直接上線使用」的方向推進。

1. 這次一共發布了什麼

官方頁面裡，DeepSeek-V4 Preview 主要包含兩條產品線：

DeepSeek-V4-Pro
DeepSeek-V4-Flash

對應的官方描述也很直接：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

從命名就能看出來，這次不是單模型升級，而是把高性能版本和更高性價比版本同時推出。

其中 V4-Pro 更強調上限，官方表示它的表現已經可以和全球頂級閉源模型競爭；V4-Flash 則更強調速度、效率和成本，更適合對回應速度和 API 成本更敏感的場景。

2. `1M context` 是這次最突出的賣點

官方頁面最醒目的表述之一，就是：「Welcome to the era of cost-effective 1M context length.」

DeepSeek 這次不只是說「支援長上下文」，而是明確把 1M context 當成這代模型的預設能力來講。頁面裡也寫得很清楚：

1M context 已經成為官方 DeepSeek 服務的預設標準
V4-Pro 和 V4-Flash 都支援 1M context

這件事的意義不只是「能塞更多 token」。它更直接影響下面這些任務：

長程式碼倉庫理解
長文件問答與資料整理
多輪 Agent 工作流
橫跨多檔案、多工具、多階段的複雜任務

如果上下文窗口夠大，模型就比較不容易因為中途丟失上下文而反覆回讀材料，這對 Agent 編碼和複雜知識工作會特別重要。

3. `V4-Pro` 主要在強調什麼

從官方頁的措辭來看，DeepSeek-V4-Pro 重點強調三件事：

Agentic Coding 能力
世界知識
推理能力

頁面提到，V4-Pro 在 Agentic Coding benchmark 上達到開源 SOTA；在世界知識方面領先目前的開源模型，只落後於 Gemini-3.1-Pro；在數學、STEM 和編碼能力上超過目前的開源模型，並且可以和頂級閉源模型競爭。

換句話說，V4-Pro 的定位並不是單純回答問題，而是更偏向高難度推理、複雜編碼和長任務執行。

4. `V4-Flash` 並不是簡單的縮水版

另一個值得注意的點是，官方沒有把 V4-Flash 包裝成「低配模型」，而是強調它在很多實際任務裡已經足夠強。

按照新聞頁給出的說法，V4-Flash：

推理能力已經很接近 V4-Pro
在簡單 Agent 任務上與 V4-Pro 表現相當
參數規模更小、回應更快、API 定價更便宜

這意味著 DeepSeek 這次給出的並不是「一個旗艦、一個入門」這種非常割裂的組合，而更像是：

V4-Pro：追求更高性能和更強上限
V4-Flash：追求更低延遲和更好的成本效率

對開發者來說，這樣的組合會更實用，因為很多線上任務真正需要的不是「理論最強」，而是「夠強、夠快、夠省」。

5. 官方特別強調了 Agent 優化

這次發布頁裡還有一個很明確的方向：DeepSeek 在主動把 V4 往 Agent 場景上推。

官方頁面提到，DeepSeek-V4 已經和一些主流 AI Agent 深度整合，包括：

Claude Code
OpenClaw
OpenCode

同時 DeepSeek 也提到，V4 已經在內部 agentic coding 場景中使用。

這說明它想覆蓋的，不再只是聊天或普通補全，而是更長鏈路的工作方式：讀程式碼、理解結構、調用工具、生成結果，再把整條流程串起來。

如果你最近剛好在關注 coding agent，這個訊號值得留意。因為它意味著模型廠商已經不再只拼 benchmark，而是在拼「能不能真正接進工作流」。

6. 底層結構創新是在為長上下文服務

在技術描述上，官方頁把這次的結構創新總結為：

token-wise compression
DSA (DeepSeek Sparse Attention)

頁面給出的方向非常明確：目標是把長上下文做得更便宜、更高效，盡量降低計算和顯存成本。

雖然新聞頁沒有展開完整技術細節，但這至少說明 DeepSeek 這次不是單純靠「更大算力硬堆更長窗口」，而是在結構層面針對長上下文效率做了專門優化。

對實際使用者來說，這通常比單純「窗口數字變大」更重要，因為真正決定可用性的，不只是能不能開到 1M，還包括：

速度是否還能接受
成本是否還能接受
長上下文任務是否真的穩定

7. API 已經可用，但要注意模型切換

官方頁面明確寫到，這次 API 當天就已經可用。

接入方式也比較簡單：

base_url 保持不變
把模型名切換為 deepseek-v4-pro 或 deepseek-v4-flash

同時頁面說明，這兩個模型都支援：

1M context
Thinking / Non-Thinking 雙模式
OpenAI ChatCompletions
Anthropic APIs

這意味著如果你原本已經接了 DeepSeek API，升級門檻並不高，主要是模型名切換和能力驗證。

8. 舊模型的退役時間也寫得很明確

對開發者來說，這次新聞頁裡最不能忽略的資訊之一，其實是舊模型退役提醒。

官方寫明：

deepseek-chat
deepseek-reasoner

會在 2026 年 7 月 24 日 15:59（UTC） 後完全退役並不可訪問。

頁面還說明，當前這兩個模型實際上已經路由到 deepseek-v4-flash 的非思考 / 思考模式。

這意味著如果你的專案裡還直接寫著 deepseek-chat 或 deepseek-reasoner，現在就應該開始安排遷移，而不要拖到正式下線前再處理。

9. 這次發布值得怎麼理解

如果把這次更新濃縮成幾個重點，大概可以這樣看：

DeepSeek 開始把 1M context 從「高配能力」變成預設標準
雙模型路線更清晰：一個衝性能上限，一個衝速度和性價比
Agent 能力已經被放到很核心的位置
API 升級路徑相對直接，但舊模型退役時間需要盡快關注

對一般使用者來說，最直觀的變化可能是：長文件、長程式碼、長流程任務會更容易放進一次上下文裡。
對開發者來說，更重要的是：如果你已經在做 Agent、程式碼助手、資料整理、複雜工作流，這一代模型顯然就是朝這些場景設計的。

DeepSeek 這次發布，不只是一次常規模型更新，更像是在明確它下一階段的產品方向：超長上下文 + Agent 優化 + 更實際的 API 可用性。

AI 名詞解釋：用白話講清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

剛開始接觸 AI，最容易讓人卻步的通常不是模型本身，而是討論裡那些一串一串的名詞。Agent、MCP、RAG、AIGC、Token 看起來都很常見，但如果沒有人先用白話講一遍，很多人其實只是「看過」，不是真的懂。

這篇就順著一組常見入門解釋的思路，把 10 個高頻 AI 名詞壓縮成一套更容易記住的意思。目標不是講得多學術，而是先幫你建立一個能跟上日常 AI 討論的基本框架。

10 個常見 AI 名詞，分別是什麼意思

1. Agent：不只會聊天的執行型 AI

Agent 可以先理解成「會做事的 AI 助手」。

一般聊天機器人比較像是你問一句、它答一句；Agent 則更進一步，它會把任務拆開、安排步驟、調用工具，最後把結果交回來。比如你叫它整理資料、查資訊、生成文件，它不只是給建議，而是可能直接把這些動作串起來完成。

所以 Agent 的重點，不在「會不會說」，而在「能不能做」。

2. OpenClaw：駐留在電腦裡的 AI 助手

這裡的 OpenClaw 被形容成一種住在你電腦裡的 AI 助手。

你可以把這類工具理解成更貼近桌面操作的 AI 幫手。它不只是接收文字，也可能直接觀察介面、調用本地工具、按流程執行任務。和一般網頁聊天相比，這類工具更強調實際操作能力。

如果說 Agent 是抽象層面的執行型 AI，那這種桌面型助手就是它在個人電腦上的一種具體落地形式。

3. Skills：替 Agent 裝上的能力包

Skills 可以理解成 Agent 的功能模組或操作說明。

同一個 Agent，裝上不同的 Skills，就會展現出不同的專長。有些偏文案，有些偏資料整理，有些偏程式處理。它們有點像手機裡的 App，也有點像一套套可重複利用的工作流程。

所以很多時候，不是模型突然變聰明了，而是它背後多了一組更明確的規則、工具和步驟。

4. MCP：AI 連接外部工具的統一方式

MCP 全稱是 Model Context Protocol。

如果用生活化的比喻，它有點像 AI 世界裡的 Type-C 介面。以前模型要接不同工具，往往得一套一套分開整合；有了統一協議之後，接入方式就會更標準，也更容易重複使用。

對大多數使用者來說，最值得記住的一點是：MCP 解決的不是模型會不會回答，而是模型怎麼安全、穩定地接上外部工具和資源。

5. 抽卡：AI 生成結果本來就有隨機性

「抽卡」這個說法常見於 AI 繪圖、影片生成和內容創作場景。

意思很簡單。就算是同樣的提示詞、同樣的大方向，每次生成出來的結果也可能不同。有時候效果很好，有時候明顯翻車，所以很多人會把反覆生成這件事形容成像遊戲裡抽卡。

它真正提醒我們的是：AI 生成不是固定公式，而是一個帶有機率波動的過程。

6. API：應用和模型之間的連接方式

API 全稱是 Application Programming Interface，也就是應用程式介面。

你可以把它理解成程式之間溝通的標準入口。當你在自己的應用、腳本或編輯器裡呼叫模型服務時，本質上就是透過 API 發送請求，再拿回結果。

如果把模型服務比作一家餐廳，那麼：

菜單像 API 文件
點餐像發起 API 請求
廚房出餐像模型回傳結果

所以很多工具表面看起來不一樣，但底層其實都在呼叫某種 API。

7. 多模態：AI 不只會處理文字

「多模態」說的是 AI 不再只會讀寫文字，而是可以同時處理多種形式的資訊。

例如它可以看圖、聽語音、理解影片、生成圖片，甚至支援即時語音和視訊互動。和早期只能處理文字的模型相比，多模態模型更接近同時具備「看、聽、說、寫」的能力。

這也是為什麼現在很多 AI 產品，已經不再只圍繞一個文字輸入框來設計。

8. RAG：先找資料，再組織答案

RAG 是 Retrieval-Augmented Generation，通常譯作檢索增強生成。

它適合用來解決一個很實際的問題：模型的訓練資料有時間邊界，也不會自動知道你公司最新的文件、客服紀錄或業務規則。RAG 的做法是先從指定資料裡找出相關內容，再根據這些內容生成回答。

它的價值通常體現在三點：

答案更容易貼近真實資料
可以追溯答案依據來自哪裡
新文件加入後，知識也能快速更新

所以很多企業知識庫、AI 客服和內部問答系統，底層都會用到 RAG。

9. AIGC：AI 生成內容的總稱

AIGC 是 AI Generated Content 的縮寫。

它不是某一個單獨工具，而是一個總稱，泛指 AI 生成出來的內容，包括文字、圖片、音訊、影片等各種形式。你看到的 AI 寫稿、AI 製圖、AI 做短影片、AI 配音，都可以放進 AIGC 這個大框架裡理解。

這個詞真正重要的地方在於，它描述的是一種內容生產方式，而不是某一個具體模型。

10. Token：模型處理內容時的計量單位

Token 可以理解成模型處理文字時使用的基本計量單位。

它不完全等於「一個字」或「一個單詞」，但在實際使用時，你可以先把它當成模型計算和計費的通用單位。你的輸入會消耗 Token，模型輸出的內容會消耗 Token，上下文裡保留的歷史內容同樣也會占用 Token。

所以為什麼很多模型服務一直強調上下文長度、成本控制和提示詞壓縮，本質上都和 Token 有關。

Claude Code 多 Agent 協作：Subagents 和 Agent Teams 怎麼選

Wed, 22 Apr 2026 21:35:52 +0800

在 Claude Code 裡，和多 Agent 協作最容易混淆的兩個概念，就是 Subagents 和 Agent Teams。它們看起來都像是「開幾個 Agent 一起做事」，但定位其實不一樣。簡單說，前者更適合把獨立任務分出去做，後者更適合讓多個 Agent 圍繞同一件事持續協作、彼此驗證。

如果你之前用過 Skill，也可以先這樣理解：

Skill 負責定義流程和規則
Subagent 或 Agent teammate 負責實際執行任務

所以真正的問題不是哪個「更高級」，而是你要處理的是哪一類協作問題。

Subagents：把支線任務分出去

Subagents 更像是在目前會話裡臨時派出去的分身。每個分身都有自己的上下文視窗，做完之後只把結果摘要帶回來，主對話不會被大量中間輸出塞滿。

這類能力有幾個很直接的優點：

主線對話更乾淨，不容易被測試日誌、搜尋結果或長輸出污染
可以把彼此獨立的研究或執行任務並行化
很適合「把結果帶回來就好」的任務

原文提到，Claude Code 內建了三類 Subagent：

Explore：唯讀，適合快速搜尋程式碼庫
Plan：唯讀，適合在 plan mode 裡於背景收集資訊
General-purpose：可讀可寫，適合同時探索與修改的任務

自訂 Subagent

如果內建能力不夠，可以自己定義一個 Subagent。做法不複雜，本質上就是寫一個 Markdown 檔案：

.claude/agents/：只在目前專案生效
~/.claude/agents/：對所有專案生效

檔案格式類似這樣：

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

這裡最關鍵的是 description。Claude 會根據這段描述判斷什麼時候該呼叫這個 Subagent，所以寫得越精準，觸發通常越準。

另外幾個常見設定欄位也很實用：

tools：限制它可以使用哪些工具
model：決定使用 sonnet、opus、haiku 或 inherit
permissionMode：控制編輯權限與權限提示行為
memory：給 Subagent 一個跨對話記憶目錄

如果只是暫時要用一次，也可以直接透過 CLI 注入：

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents 適合什麼場景

Subagents 最適合的，通常是這幾類任務：

跑測試並只回傳失敗摘要，而不是把幾千行日誌全塞回主會話
並行調查幾個互不依賴的模組
把「找問題」和「修問題」拆成簡單的流水線

例如：

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

但如果任務需要頻繁來回調整、不同階段共享大量上下文，或者改動高度集中在一兩個檔案裡，那麼直接在主對話中處理，往往比另外派一個 Subagent 更省事。

Agent Teams：多個獨立會話一起協作

Agent Teams 是另一個層級的能力。它不是在同一個會話裡派出分身，而是啟動多個彼此獨立的 Claude Code 實例，讓它們圍繞共享任務清單協作，還可以彼此直接傳訊。

這也讓它更像是一個真正的小團隊，而不只是「把支線任務分出去」。

原文提到，這項功能目前仍然是實驗功能，需要先開啟：

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

把它加到 settings.json 後，就可以讓 Claude 依照你的需求組成一個 team。比如：

1
2
3

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.

Agent Teams 的組成

一個 Agent Team 主要由三部分組成：

Team lead：你目前使用的主會話，負責組隊、分派與彙總
Teammates：多個彼此獨立的 Claude Code 實例
Task list 和 Mailbox：共享任務清單與訊息通道

和 Subagents 最大的差別在於，teammates 之間可以直接溝通，不需要每次都透過 lead 中轉。任務狀態通常會在 pending、in progress、completed 之間流轉，而成員完成一項任務後，也可以繼續認領下一項。

Agent Teams 適合什麼場景

當任務需要多角度討論、互相挑戰結論，或者拆成多個模組並行推進時，Agent Teams 會更合適。

原文舉了幾個很典型的場景：

多位 reviewer 並行審查同一個 PR，但各自關注不同面向
多個 Agent 針對同一個 bug 提出不同假設，並互相反駁
前端、後端、測試分別推進不同模組

例如並行程式碼審查：

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

再比如辯論式偵錯：

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

這類任務的共同點是：你不是只要一個答案，而是需要多個 Agent 彼此交換判斷、質疑假設，最後收斂出更可靠的結論。

兩者怎麼選

如果想快速區分，可以直接記這條：

做完把結果帶回來，用 Subagents
需要討論與交叉驗證，用 Agent Teams

再展開一點，主要差異可以從這幾個面向來看：

通訊方式：Subagents 主要把結果回報給主會話；Agent Teams 的成員之間可以直接互相溝通
協調模式：Subagents 更依賴主對話統一調度；Agent Teams 有共享任務清單，成員可以自行認領
Token 成本：Subagents 較省；Agent Teams 較高，因為每個 teammate 都是獨立實例
適用任務：Subagents 更適合獨立、結果導向的工作；Agent Teams 更適合需要討論與交叉驗證的工作

使用時要注意什麼

Agent Teams 雖然更強，但不代表每個任務都值得直接開 team。原文特別提醒了幾個實際問題：

token 消耗明顯更高
若多個 teammate 同時編輯同一個檔案，很容易互相覆蓋
teammate 太多會增加協調成本，不一定帶來更好效果

因此，通常比較穩妥的做法是：

先從 3 到 5 個 teammate 開始
依模組或檔案拆任務，避免寫入衝突
如果 lead 太早接手了 teammate 的工作，要明確要求它先等隊友完成

另外，目前的實驗功能也還有一些限制，例如：

不支援 /resume 和 /rewind 恢復 in-process teammates
任務狀態有時會延遲，需要手動提醒更新
一個 lead 一次只能管理一個 team
teammate 不能再派出子 team

簡單結論

這兩種能力並不是互相替代，而是分別解決不同的協作問題。

如果你的需求是「把支線任務並行做掉，保持主上下文乾淨」，那就先用 Subagents。如果你的需求是「讓幾個 Agent 像小團隊一樣協作、討論、交叉驗證」，那麼 Agent Teams 會更適合。

實際拿一個任務試一次，通常很快就能感受到差別：一個強調上下文隔離與結果回收，另一個強調多視角協作與持續互動。

Agent on KnightLi的博客

CLI-Anything：把軟體變成 Agent 可用的命令列

它怎麼工作

適合什麼場景

需要注意的邊界

小結

DeepSeek V4 Flash 做 Godot 遊戲 Demo：幾毛錢能跑通到什麼程度？

Demo 表現

可用程度

成本意義

DeepSeek V4 Flash 的表現

適合什麼場景

這說明了什麼

小結

DeepSeek-V4 Preview 發布：1M 上下文、雙模型與 API 切換提醒

1. 這次一共發布了什麼

2. 1M context 是這次最突出的賣點

3. V4-Pro 主要在強調什麼

4. V4-Flash 並不是簡單的縮水版

5. 官方特別強調了 Agent 優化

6. 底層結構創新是在為長上下文服務

7. API 已經可用，但要注意模型切換

8. 舊模型的退役時間也寫得很明確

9. 這次發布值得怎麼理解

相關連結

AI 名詞解釋：用白話講清楚 Agent、MCP、RAG 和 Token

10 個常見 AI 名詞，分別是什麼意思

1. Agent：不只會聊天的執行型 AI

2. OpenClaw：駐留在電腦裡的 AI 助手

3. Skills：替 Agent 裝上的能力包

4. MCP：AI 連接外部工具的統一方式

5. 抽卡：AI 生成結果本來就有隨機性

6. API：應用和模型之間的連接方式

7. 多模態：AI 不只會處理文字

8. RAG：先找資料，再組織答案

9. AIGC：AI 生成內容的總稱

10. Token：模型處理內容時的計量單位

Claude Code 多 Agent 協作：Subagents 和 Agent Teams 怎麼選

Subagents：把支線任務分出去

自訂 Subagent

Subagents 適合什麼場景

Agent Teams：多個獨立會話一起協作

Agent Teams 的組成

Agent Teams 適合什麼場景

兩者怎麼選

使用時要注意什麼

簡單結論

相關連結

2. `1M context` 是這次最突出的賣點

3. `V4-Pro` 主要在強調什麼

4. `V4-Flash` 並不是簡單的縮水版