Agent on KnightLi的博客

AI 名词解释：用大白话讲清楚 Agent、MCP、RAG 和 Token

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

刚开始接触 AI，最容易劝退人的通常不是模型本身，而是讨论里那些一串串名词。Agent、MCP、RAG、AIGC、Token 看起来都很常见，但如果没人先用人话讲一遍，很多人其实只是在“眼熟”，并没有真正听懂。

这篇就顺着一组常见入门解释的思路，把 10 个高频 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 的思路就是，先从指定资料里把相关内容找出来，再结合这些资料生成回答。

它的价值通常体现在三点：

答案更容易贴近真实资料
可以追溯回答依据来自哪里
新文档加入后，知识可随时更新

所以很多企业知识库、智能客服和内部问答系统，底层都会用到 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 会更合适。

原文给了几个很典型的场景：

多人并行审查同一个 PR，但每个人关注不同维度
围绕同一个 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。

先用一个真实场景试一次，通常很快就能体会到差别：一个强调上下文隔离和结果回收，另一个强调多视角协同和持续互动。