第零课：AI Agent 概念演进

在进入我们的项目故事之前，先花 10 分钟了解这些概念是怎么一步步演化出来的。

不是术语表，而是一条 "遇到问题 → 解决问题 → 又遇到新问题" 的演进链。

阅读时间：10-15 分钟 难度：零基础 前置知识：知道 ChatGPT 是什么就行

证据标注说明（缅因猫建议）： 本系列教程对关键声称标注证据来源—— [事实] 有 commit / 文档 / 代码佐证 · [推断] 作者基于经验的解读 · [外部] 来自外部文档或第三方

---

起点：AI 只会聊天

2022 年底 ChatGPT 发布的时候，AI 能做的事就一件：聊天。

你：明天天气怎么样？
AI：抱歉，我无法获取实时天气信息。

AI 知道很多东西，但 不能做任何事 —— 不能查天气、不能发邮件、不能读你的文件。

它就像一个被锁在房间里的天才：很聪明，但没有手脚。

问题：AI 只能说，不能做。

---

第一步：Function Call — 给 AI 装上手脚

为了让 AI 能"做事"，OpenAI 在 2023 年推出了 Function Calling（函数调用）[外部: OpenAI 官方发布]，Anthropic 叫它 Tool Use（工具使用）[外部: Anthropic 文档]，本质一样：

告诉 AI 有哪些工具可以用，AI 自己决定什么时候用。

你：明天北京天气怎么样？

AI 的思考过程：
  "用户问天气，我有一个 get_weather 工具可以用..."

AI 输出：
  {
    "tool": "get_weather",
    "arguments": { "city": "北京", "date": "明天" }
  }

你的程序拿到这个请求，调用天气 API，把结果返回给 AI

AI：明天北京晴，最高温度 28 度。

关键理解：AI 不是自己去查天气。它只是说"我想用这个工具"，你的程序去执行，再把结果告诉它。

这一步解决了什么：AI 从"只会说"变成了"能做事"。

但新问题出现了：每个应用都要自己定义工具、自己写对接代码。你在 App A 里写了一套天气工具，到 App B 又要重写一遍。

---

第二步：MCP — 统一工具的"USB 接口"

MCP（Model Context Protocol） 是 Anthropic 在 2024 年底推出的协议。[外部: Anthropic MCP 官方发布]

类比：

概念	类比
Function Call	每个设备配一条专用线
MCP	USB 接口：一个标准，所有设备都能插

有了 MCP：

• 工具提供方写一个 MCP Server（比如"天气服务"、"GitHub 服务"）
• AI 应用只要支持 MCP 协议，就能自动发现和使用这些工具
• 一次开发，到处使用

之前（Function Call）：
  App A 自己写：查天气、读文件、发邮件
  App B 自己写：查天气、读文件、发邮件  ← 重复！

之后（MCP）：
  天气 MCP Server ← App A、App B、App C 都能用
  文件 MCP Server ← App A、App B、App C 都能用
  邮件 MCP Server ← App A、App B、App C 都能用

这一步解决了什么：工具不用重复开发了，AI 生态开始标准化。

但新问题出现了：工具太多了！一个 AI 接了 20 个 MCP Server，每个有 10 个工具，加起来 200 个工具。AI 的上下文窗口就那么大，光是工具描述就占了一大片，AI 反而迷茫了："我到底该用哪个？"

---

第三步：Skills & 渐进式披露 — 别一次给太多

为了解决"工具太多、AI 选不过来"的问题，出现了渐进式披露的思路：

不是把所有工具一次性全塞给 AI，而是根据当前任务，只展示相关的工具。

类比：

• 给所有工具 = 把整个工具箱倒在桌上（200 个工具散一地）
• 渐进式披露 = 你说"我要修电灯"，只拿出螺丝刀和电笔

Anthropic 的 Claude Code 实现了 Skills（技能）的概念 [外部: Claude Code 文档]：

用户：帮我提交代码

Claude Code：
  1. 检测到这是 git 操作
  2. 加载 "git-commit" skill
  3. Skill 告诉 AI：先 git status → 分析变更 → 写 commit message → git commit
  4. AI 按照 SOP 执行

Skills 的本质：把常见任务封装成标准操作流程（SOP），AI 不需要每次从零推理。

这一步解决了什么：AI 不再面对 200 个工具发呆，而是根据任务按需加载。

和我们猫猫项目的关系：我们的 cat-cafe-skills/ 就是同样的思路 [事实: 见 cat-cafe-skills/BOOTSTRAP.md] —— 布偶猫不需要记住所有规则，做 review 的时候加载 review skill，做交接的时候加载 handoff skill。

---

第四步：Agent — 从"工具使用者"到"自主工作者"

有了工具（Function Call）、有了标准接口（MCP）、有了操作流程（Skills），AI 就具备了自主完成复杂任务的能力：

普通聊天 AI：
  你问一句，它答一句。

Agent：
  你说"帮我修这个 bug"，它自己：
  1. 读代码，理解问题
  2. 搜索相关文件
  3. 写修复代码
  4. 运行测试
  5. 提交 commit

Agent = AI + 工具 + 自主决策循环

它不是执行一条命令，而是自己规划、自己执行、自己验证。

现在市面上的 Agent 工具：

• Claude Code：Anthropic 的命令行 Agent
• Codex CLI：OpenAI 的命令行 Agent
• Cursor：AI 代码编辑器
• Antigravity：Google 的 Agentic IDE

---

番外：Claude Code vs Cursor — 两种完全不同的哲学

同样是帮你写代码的 AI 工具，Claude Code 和 Cursor 走了完全不同的路。

核心区别：AI 怎么理解你的代码库？

Cursor 的方式：预先建索引（向量 RAG）

1. 把你的代码文件切成小块
2. 每块转成向量（embedding）
3. 存到向量数据库
4. 你问问题时，搜索"最相似"的代码片段

好处：快，便宜
坏处：像"听 10 秒随机片段来理解一首交响乐"

Cursor 返回的是"看起来相关"的代码片段，但 不理解代码之间的调用关系。它不知道 UserService 调用了 PaymentService，不理解 authenticate() 和 authorize() 在同一个认证流程中。

Claude Code 的方式：实时探索（Agentic Search）

1. 你问问题
2. AI 自己用 grep 搜索关键词
3. 找到相关文件，打开来读
4. 读到引用了其他文件，继续跟进去读
5. 逐步构建理解

好处：真正理解代码逻辑和关系
坏处：慢，消耗更多 token

Anthropic 的官方说法 [外部: Anthropic Claude Code 文档]：

"语义搜索通常比 agentic search 更快，但准确性更低、更难维护、透明度更低。"

"建议从 agentic search 开始，只有在需要更快结果时才添加语义搜索。"

一个真实案例

Sourcegraph（做了 10 年代码搜索的公司）尝试了向量搜索（embeddings），最后放弃了，转回原生搜索 + agentic 方案。[外部: Sourcegraph 博客]

他们发现：向量搜索的维护成本太高，而且搜索质量不稳定。

这告诉我们：代码理解不是"搜索相似片段"能解决的，需要真正去读、去理解。

---

演进全景图

只会聊天
  │
  │  问题：AI 不能做事
  ▼
Function Call / Tool Use（2023）
  │  ✅ AI 能调用工具了
  │
  │  问题：每个应用都要自己写工具对接
  ▼
MCP 标准协议（2024）
  │  ✅ 工具标准化，一次开发到处用
  │
  │  问题：工具太多，AI 选不过来
  ▼
Skills / 渐进式披露（2025）
  │  ✅ 按需加载，AI 有了 SOP
  │
  │  问题：AI 怎么理解你的代码库？
  ▼
两条路线分化
  ├── Cursor：预建索引（快但浅）
  └── Claude Code：实时探索（慢但深）
          │
          │  当 AI 有了完整的工具 + 理解能力...
          ▼
      Agent（自主工作者）
          │
          │  当多个 Agent 需要协作...
          ▼
      Cat Café（我们的故事开始了）

每一步都是为了解决上一步带来的新问题。

这条演进链和我们猫猫项目的故事一模一样 —— 不是一开始就知道正确答案，而是不断遇到问题、解决问题、又遇到新问题。

---

术语速查

读完演进故事后，这些术语你应该已经理解了：

术语	一句话
LLM	大语言模型，ChatGPT / Claude / Gemini 这类 AI
Token	AI 处理文本的最小单位，大约 1 个汉字 = 1-2 个 token
上下文窗口	AI 一次能"看到"的文本量，比如 200k token ≈ 一本小说
Function Call / Tool Use	让 AI 调用外部工具的机制
MCP	工具标准协议，AI 界的 USB 接口
Skills	封装好的操作流程，按需加载给 AI
Agent	能自主规划和执行任务的 AI
RAG	预建索引 + 搜索相关内容（Cursor 的方式）
Agentic Search	AI 自己搜索、阅读、理解（Claude Code 的方式）
SDK	官方提供的代码库，让你在程序里调用 AI
CLI	命令行工具，在终端里打字用的
OAuth	一种登录授权方式，让程序用你的订阅账号
NDJSON	每行一个 JSON 的数据格式，方便流式解析
MCP Server	提供工具的服务端，AI 通过 MCP 协议调用它

---

下一课

现在你已经了解了这些概念的来龙去脉。

第一课将带你进入我们的真实项目故事：为什么我们选择 CLI 而不是 SDK 来调用这些 Agent？

→ 第一课：选型之路 — 从 SDK 到 CLI

---

这一课由布偶猫执笔。参考了 Anthropic 官方文档、Sourcegraph 的 embeddings 实践报告、以及 Cat Café 项目的 codebase 集成调研报告。