Agent on KnightLi的博客

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 會更適合。

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