0%

一、写在前面:为什么需要 Superpowers?

你有没有遇到过这样的场景:

  • 让 AI 帮你写代码,它一上来就开始”输出”,完全不考虑你的真实需求
  • AI 写的代码看似没问题,但测试一跑就崩,因为它根本没写测试
  • AI “自主工作”了半小时,结果偏离了原需求十万八千里
  • 多个功能并行开发,AI 把代码混在一起,最后连回滚都困难

Superpowers 就是解决这些问题的”流程管家”。它不是让 AI 更聪明,而是让 AI 更靠谱——先规划、再测试、再实现、再审查,像真正工程师一样工作。


二、Superpowers 是什么?

2.1 一句话定义

Superpowers 是由 Jesse Vincent(Perl 专家、Markdown 发明者之一)开发的软件开发工作流系统,通过一系列”技能(Skills)”让 AI 编码助手遵循严格的工程流程。

2.2 核心理念

打个比方:

没有 Superpowers 有 Superpowers
AI 像是个”热情但冲动的新手”——拿到任务就写代码,写完就交 AI 像是个”老练的资深工程师”——先问清楚需求,写测试,再实现,最后审查
容易偏离需求 强制按计划执行
测试是”事后补的” 测试是”先写的”(TDD)
一个分支干所有事 Git Worktree 隔离开发

2.3 支持的 AI 工具

工具 安装方式
Claude Code /plugin install superpowers@claude-plugins-official
Cursor /add-plugin superpowers
GitHub Copilot CLI copilot plugin install superpowers
Gemini CLI gemini extensions install
Codex CLI 手动配置(见后文)
OpenCode 手动配置

三、核心工作流程详解

3.1 七步流程

Superpowers 强制 AI 遵循以下流程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
┌──────────────────────────────────────────────────────────────────────┐
│ Superpowers 工作流程 │
├──────────────────────────────────────────────────────────────────────┤
│ │
│ 1. brainstorming (头脑风暴) │
│ └─► AI 不直接写代码,先问你"到底想做什么" │
│ └─► 通过苏格拉底式提问,提炼出清晰的设计文档 │
│ │
│ 2. using-git-worktrees (创建隔离工作空间) │
│ └─► 自动创建新分支 + Git Worktree │
│ └─► 确保开发环境干净、可回滚 │
│ │
│ 3. writing-plans (编写计划) │
│ └─► 将设计拆成 2-5 分钟的小任务 │
│ └─► 每个任务包含:文件路径、代码、验证步骤 │
│ │
│ 4. subagent-driven-development (子代理执行) │
│ └─► 每个任务派发一个新的子代理 │
│ └─► 主代理审查子代理的工作 │
│ └─► 可连续自主工作数小时 │
│ │
│ 5. test-driven-development (强制 TDD) │
│ └─► RED: 先写失败的测试 │
│ └─► GREEN: 写最少代码让测试通过 │
│ └─► REFACTOR: 优化代码 │
│ └─► 如果代码先于测试写了,会被删除! │
│ │
│ 6. requesting-code-review (代码审查) │
│ └─► 每个任务完成后自动审查 │
│ └─► 两阶段审查:规格合规 + 代码质量 │
│ └─► 关键问题会阻塞进度 │
│ │
│ 7. finishing-a-development-branch (完成分支) │
│ └─► 验证所有测试通过 │
│ └─► 提供:合并 / PR / 保留 / 丢弃选项 │
│ └─► 清理 Worktree │
│ │
└──────────────────────────────────────────────────────────────────────┘

3.2 为什么这套流程有效?

问题 1:AI 容易”跑偏”

传统 AI 编码:

1
2
3
4
5
用户:帮我加个登录功能
AI:好的,开始写代码...
(30分钟后)
AI:登录功能写好了,还顺便加了注册、找回密码、OAuth...
用户:??我只想要个简单的登录啊

有 Superpowers:

1
2
3
4
5
6
7
8
9
用户:帮我加个登录功能
AI (brainstorming):让我先理解一下:
- 登录方式是什么?账号密码?OAuth?
- 需要记住登录状态吗?多久?
- 安全要求是什么?
用户:账号密码登录,记住 7 天,简单安全就行
AI:好的,我来写设计文档,你确认后再动手
(用户确认后)
AI:现在开始实现,每个任务都会按计划执行

问题 2:AI 不写测试

传统 AI 编码:

1
2
3
4
AI:功能写完了!
用户:测试呢?
AI:呃...我补一下
(补的测试可能根本测不到关键逻辑)

有 Superpowers(强制 TDD):

1
2
3
4
5
AI:现在要实现登录验证
AI:先写测试(RED)→ 测试失败 ✓
AI:再写代码(GREEN)→ 测试通过 ✓
AI:重构优化(REFACTOR)→ 测试仍通过 ✓
AI:继续下一个任务

问题 3:多功能开发混乱

传统方式:

1
2
3
4
5
main 分支上同时开发 3 个功能
功能 A 改了文件 X
功能 B 也改了文件 X
功能 C 又改了文件 X
→ 冲突灾难

有 Superpowers(Git Worktree):

1
2
3
4
功能 A → worktree/feature-a/ (独立目录)
功能 B → worktree/feature-b/ (独立目录)
功能 C → worktree/feature-c/ (独立目录)
→ 完全隔离,互不影响


四、安装配置实战

4.1 Claude Code 安装(推荐)

方式一:官方插件市场(最简单)

1
2
# 在 Claude Code 中执行
/plugin install superpowers@claude-plugins-official

方式二:第三方市场

1
2
3
4
5
# 先注册市场
/plugin marketplace add obra/superpowers-marketplace

# 再安装插件
/plugin install superpowers@superpowers-marketplace

验证安装:

1
2
3
4
# 查看已安装插件
/plugin list

# 应该看到 superpowers

4.2 Cursor 安装

在 Cursor Agent 聊天中:

1
/add-plugin superpowers

或者在插件市场搜索 “superpowers”。

4.3 GitHub Copilot CLI 安装

1
2
3
4
5
# 注册市场
copilot plugin marketplace add obra/superpowers-marketplace

# 安装插件
copilot plugin install superpowers@superpowers-marketplace

4.4 Codex CLI 手动安装

Codex 目前没有插件市场,需要手动配置:

步骤 1:获取技能文件

1
2
3
4
5
6
# 克隆仓库
git clone https://github.com/obra/superpowers.git

# 复制技能到 Codex 目录
mkdir -p ~/.codex/skills
cp -r superpowers/skills/* ~/.codex/skills/

步骤 2:配置 Codex

创建或编辑 ~/.codex/config.json

1
2
3
{
"skillsDirectory": "~/.codex/skills"
}

步骤 3:验证

启动 Codex 后,技能会自动加载。

4.5 Gemini CLI 安装

1
2
3
4
5
# 安装扩展
gemini extensions install https://github.com/obra/superpowers

# 更新
gemini extensions update superpowers

4.6 更新插件

1
2
3
4
5
6
7
8
# Claude Code
/plugin update superpowers

# Copilot CLI
copilot plugin update superpowers

# Gemini CLI
gemini extensions update superpowers

五、使用实战:从零开始

5.1 触发技能

Superpowers 的技能会自动触发。你不需要特殊命令,只需要用自然语言描述需求。

示例:启动一个新功能

1
我想给博客系统加一个评论功能,支持用户登录后评论

AI 会自动调用 brainstorming 技能:

1
2
3
4
5
6
7
8
AI:让我先理解你的需求...

问题 1:评论需要审核吗?还是直接发布?
问题 2:评论可以回复吗?支持嵌套?
问题 3:评论内容有什么限制?字数、格式?
问题 4:需要通知博主吗?邮件?站内?

请逐一回答,我会根据你的回答设计功能。

5.2 头脑风暴阶段

你的回答:

1
2
3
4
评论不需要审核,直接发布
支持回复,但不嵌套(最多一层)
评论最多 500 字,不能发链接
不需要通知

AI 会生成设计文档:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
## 评论功能设计文档

### 核心需求
- 用户登录后可评论
- 评论直接发布,无需审核
- 支持回复评论(一层)

### 技术方案
- 数据表:comments (id, user_id, post_id, content, parent_id, created_at)
- API:POST /comments, GET /comments/:post_id
- 前端:评论框 + 评论列表 + 回复按钮

### 验收标准
- 登录用户可发表评论
- 可回复他人评论
- 评论字数限制 500 字
- 不允许发送链接

你确认后,AI 进入下一阶段。

5.3 Git Worktree 阶段

AI 会自动:

1
2
3
4
5
6
7
8
9
10
11
12
# 创建新分支
git checkout -b feature/comments

# 创建 Worktree(独立工作目录)
git worktree add .claude/worktrees/feature-comments feature/comments

# 在 Worktree 中初始化环境
cd .claude/worktrees/feature-comments
npm install # 或其他项目初始化命令

# 验证测试基线
npm test # 确保当前测试都通过

Worktree 的好处:

1
2
3
4
5
6
你的主项目目录:     /projects/my-blog/
评论功能 Worktree: /projects/my-blog/.claude/worktrees/feature-comments/

两个目录完全独立!
你可以在主目录继续其他工作
AI 在 Worktree 专心开发评论功能

5.4 编写计划阶段

AI 会把设计拆成小任务:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
## 实现计划

### 任务 1:创建评论数据模型 (预计 3 分钟)
- 文件:`src/models/comment.js`
- 代码:定义 Comment schema
- 验证:模型可正确创建实例

### 任务 2:添加评论 API (预计 5 分钟)
- 文件:`src/routes/comments.js`
- 代码:POST /comments, GET /comments/:post_id
- 验证:API 测试通过

### 任务 3:评论前端组件 (预计 10 分钟)
- 文件:`src/components/CommentBox.jsx`, `src/components/CommentList.jsx`
- 代码:评论输入框、评论列表、回复按钮
- 验证:组件渲染正确,可交互

### 任务 4:字数限制和链接过滤 (预计 3 分钟)
- 文件:`src/utils/commentValidator.js`
- 代码:验证函数
- 验证:超过 500 字拒绝,包含链接拒绝

### 任务 5:集成测试 (预计 5 分钟)
- 文件:`tests/comment.test.js`
- 代码:完整流程测试
- 验证:测试通过

任务粒度原则:

  • 每个任务 2-5 分钟
  • 明确的文件路径
  • 验证步骤

5.5 子代理执行阶段

这是 Superpowers 的核心亮点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
┌─────────────────────────────────────────────────────────────┐
│ 子代理驱动开发 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 主代理 (你对话的 AI) │
│ │ │
│ ├──► 派发子代理 1 → 执行任务 1 (创建模型) │
│ │ │ │
│ │ └──► 完成后返回结果 │
│ │ │
│ ├──► 主代理审查:符合设计?代码质量? │
│ │ │
│ ├──► 派发子代理 2 → 执行任务 2 (添加 API) │
│ │ │ │
│ │ └──► 完成后返回结果 │
│ │ │
│ ├──► 主代理审查... │
│ │ │
│ └──► 继续执行... │
│ │
│ 优势: │
│ - 每个任务用"新鲜"的子代理,无上下文污染 │
│ - 主代理审查,确保质量 │
│ - 可连续自主工作数小时 │
│ │
└─────────────────────────────────────────────────────────────┘

你的体验:

1
2
3
4
5
6
7
8
AI:开始执行任务 1...
AI:任务 1 完成,审查中...
AI:审查通过 ✓,继续任务 2...
AI:任务 2 完成,审查中...
AI:发现一个小问题,已修复 ✓
AI:继续任务 3...
(你可以去喝咖啡了)
AI:所有任务完成!

5.6 TDD 阶段(强制)

Superpowers 的 TDD 是真正的 RED-GREEN-REFACTOR:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 步骤 1:RED - 先写失败的测试
describe('CommentValidator', () => {
it('should reject comment longer than 500 chars', () => {
const longComment = 'a'.repeat(501);
expect(validateComment(longComment)).toBe(false);
});
});

// 运行测试 → 失败 ✓ (因为 validateComment 还不存在)

// 步骤 2:GREEN - 写最少代码让测试通过
function validateComment(content) {
if (content.length > 500) return false;
return true;
}

// 运行测试 → 通过 ✓

// 步骤 3:REFACTOR - 优化代码
function validateComment(content) {
const MAX_LENGTH = 500;
const LINK_PATTERN = /https?:\/\/\S+/;

if (content.length > MAX_LENGTH) return false;
if (LINK_PATTERN.test(content)) return false;
return true;
}

// 运行测试 → 仍通过 ✓

如果 AI 先写了代码再写测试?

1
2
AI 会删除代码,重新从测试开始写!
这是强制的,不是建议。

5.7 代码审查阶段

每个任务完成后,主代理会审查:

审查维度:

维度 检查内容
规格合规 是否符合设计文档?
代码质量 可读性、命名、结构
测试覆盖 测试是否充分?
安全性 有无安全漏洞?

审查结果:

1
2
3
4
5
6
7
8
审查报告:

✓ 规格合规:符合设计文档
⚠ 代码质量:变量命名可优化(comment → userComment)
✓ 测试覆盖:覆盖了主要场景
✓ 安全性:无明显问题

建议:优化变量命名后继续

关键问题会阻塞进度:

1
2
❌ 发现关键问题:API 缺少权限验证
→ 必须修复后才能继续

5.8 完成分支阶段

所有任务完成后:

1
2
3
4
5
6
7
8
9
10
AI:所有任务完成!验证测试...
AI:所有测试通过 ✓

请选择下一步:
[1] 合并到主分支
[2] 创建 Pull Request
[3] 保留分支(暂不合并)
[4] 丢弃所有更改

你的选择?

选择后,AI 会:

1
2
3
4
5
6
7
# 如果选择合并
git checkout main
git merge feature/comments
git worktree remove .claude/worktrees/feature-comments

# 如果选择创建 PR
gh pr create --title "Add comment feature" --body "..."

六、与 GitHub SpecKit 的对比

6.1 两者是什么关系?

SuperpowersGitHub SpecKit 都是”规范驱动开发”的工具,但理念和实现方式不同。

特性 Superpowers GitHub SpecKit
开发者 Jesse Vincent(独立开发者) GitHub 官方
形态 Skills 插件系统 CLI + Skills + Extensions 生态
核心理念 流程至上 - 强制 TDD、强制审查 规范至上 - spec 成为可执行文档
安装方式 /plugin install uv tool install specify-cli
项目宪法 /speckit.constitution 创建
产出文件 动态生成 固定:spec.md, plan.md, tasks.md
TDD 强制 RED-GREEN-REFACTOR 推荐但不强制
Git Worktree 自动创建 无内置
子代理执行 内置 subagent-driven 通过扩展实现
可视化 UI VS Code 扩展支持
外部集成 有限 Jira、Azure DevOps、Linear 等 40+ 扩展

6.2 核心哲学差异

Superpowers:流程至上

1
2
3
4
5
6
7
8
核心理念:"让 AI 不犯错误"

方式:强制工程流程
- 不写测试就不能写代码
- 不审查就不能继续
- 不隔离就不能开发

适合:个人开发者、追求代码质量

SpecKit:规范至上

1
2
3
4
5
6
7
8
核心理念:"让规范成为第一性原理"

方式:规范可执行
- spec.md 直接生成代码
- 规范是"活的",不是文档
- 专注于"做什么",而非"怎么做"

适合:团队协作、需要外部集成

6.3 工作流对比

Superpowers 流程:

1
2
3
需求 → 头脑风暴 → Worktree → 计划 → 子代理执行 → TDD → 审查 → 完成分支
↑ ↑ ↑ ↑ ↑ ↑
问清楚 隔离环境 拆任务 自动执行 强制 质量保证

SpecKit 流程:

1
2
3
宪法 → Specify → Plan → Tasks → Implement
↑ ↑ ↑ ↑ ↑
原则 需求 技术 任务 执行

6.4 SpecKit 的独特优势

1. 项目宪法

1
2
3
4
5
# 定义项目原则
/speckit.constitution Create principles focused on:
- Code quality: clean code, no duplication
- Testing: unit tests required for all logic
- Performance: response time < 200ms

这会生成一个”宪法文件”,指导所有后续开发。

2. 丰富的扩展生态

扩展 功能
spec-kit-jira 同步到 Jira
spec-kit-review 代码审查
spec-kit-qa QA 测试
spec-kit-ship 自动发布
superpowers-bridge 将 Superpowers 集成到 SpecKit!

3. 预设系统

可以自定义术语和模板:

1
2
3
4
5
6
7
8
{
"name": "pirate-speak",
"templates": {
"spec.md": "Voyage Manifest",
"plan.md": "Battle Plan",
"tasks.md": "Crew Assignments"
}
}

6.5 Superpowers 的独特优势

1. 强制 TDD

1
2
3
这是最大的区别。
SpecKit 推荐 TDD,但 Superpowers 强制 TDD。
如果你先写代码再写测试,代码会被删除。

2. Git Worktree 隔离

1
2
3
4
每个功能在独立目录开发:
- 不影响主项目
- 可以并行开发多个功能
- 回滚简单(删除 worktree 即可)

3. 子代理驱动

1
2
3
4
每个任务派发新的子代理:
- 无上下文污染
- 主代理审查质量
- 可连续自主工作数小时

6.6 可以一起用吗?

可以! 社区已经创建了 superpowers-bridge 扩展:

1
2
3
4
5
# 在 SpecKit 项目中安装
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 安装 superpowers-bridge 扩展
# (详见扩展文档)

这样你可以:

  • 用 SpecKit 管理规范和外部集成
  • 用 Superpowers 的 TDD、Worktree、子代理执行

七、最佳实践与适用场景

7.1 适用场景建议

场景 推荐
个人开发者,追求代码质量 Superpowers
企业团队,需要外部集成 SpecKit
已有完善规范流程 SpecKit(可定制扩展)
需要长时间自主运行 Superpowers(子代理可工作数小时)
多功能并行开发 Superpowers(Git Worktree)
两者都需要 SpecKit + superpowers-bridge

7.2 使用 Superpowers 的建议

建议 1:让 AI 问清楚再开始

1
2
3
4
不要急着说"开始写代码"
等 AI 完成头脑风暴
仔细阅读设计文档
确认后再说"开始实现"

建议 2:任务粒度要小

1
2
3
4
5
6
7
好的任务:2-5 分钟,一个文件
不好的任务:"实现整个评论功能"

小任务的好处:
- 更容易审查
- 更容易回滚
- 更容易并行

建议 3:关注审查报告

1
2
3
不要忽略审查报告中的警告
即使是"建议优化"
让 AI 修复后再继续

建议 4:并行开发时用 Worktree

1
2
3
4
5
6
如果你要同时开发 3 个功能:
功能 A → 让 AI 创建 worktree/feature-a
功能 B → 让 AI 创建 worktree/feature-b
功能 C → 让 AI 创建 worktree/feature-c

完全隔离,不会冲突

7.3 使用 SpecKit 的建议

建议 1:先写宪法

1
/speckit.constitution Define project principles first

宪法会指导所有后续开发,相当于”项目宪法”。

建议 2:选择合适的扩展

1
2
3
需要 Jira 集成?→ spec-kit-jira
需要代码审查?→ spec-kit-review
需要自动发布?→ spec-kit-ship

建议 3:利用社区预设

1
2
3
4
不想自己配置?
用社区预设:
- Agent Teams Lite(多代理)
- Pirate Speak(有趣模板)

八、常见问题

Q1: Superpowers 和 SpecKit 可以同时用吗?

可以。 安装 superpowers-bridge 扩展即可。

Q2: Superpowers 会让我写代码变慢吗?

短期内可能变慢(因为要先规划、先写测试),但长期会更快(因为减少返工)。

Q3: 子代理执行安全吗?

安全。 子代理在隔离环境中执行,主代理审查结果。

Q4: Git Worktree 会占用很多磁盘空间吗?

会占用一些,但完成后会自动清理。 你也可以手动清理:

1
2
git worktree list
git worktree remove <path>

Q5: SpecKit 的扩展稳定吗?

社区扩展由独立开发者维护,GitHub 官方不审核。 使用前建议查看源代码。


九、总结

核心要点

  1. Superpowers 是流程管家:让 AI 遵循严格的工程流程
  2. 核心流程:头脑风暴 → Worktree → 计划 → 子代理 → TDD → 审查 → 完成
  3. 强制 TDD:不写测试就不能写代码
  4. Git Worktree:每个功能在独立目录开发
  5. 子代理执行:每个任务派发新的子代理,主代理审查

与 SpecKit 的核心区别

方面 Superpowers SpecKit
理念 流程至上 规范至上
TDD 强制 推荐
Worktree 自动 无内置
子代理 内置 通过扩展
生态 单一技能库 40+ 扩展

选择建议

1
2
3
追求代码质量、个人开发 → Superpowers
团队协作、外部集成 → SpecKit
两者都需要 → SpecKit + superpowers-bridge

学习路径

1
2
3
4
5
第 1 天:安装 Superpowers,体验头脑风暴
第 2 天:完整走一遍流程,感受 TDD
第 3 天:尝试并行开发(Worktree)
第 4 天:对比 SpecKit,选择适合你的
第 5 天:深入使用,定制你的工作流

参考资料



一、CrewAI 是什么?

官方定义

CrewAI 是一个精简、快速的 Python 框架,用于编排自主 AI 代理(Agent)。它让多个 AI Agent 可以协同工作,像一个团队一样完成复杂任务。

核心特点

特点 说明
独立框架 不依赖 LangChain 或其他框架,从零构建
高性能 比 LangGraph 快 5 倍以上
灵活定制 从高层工作流到底层提示词都可定制
两种模式 Crews(自主协作)+ Flows(精确控制)

与其他框架对比

框架 优点 缺点
CrewAI 简洁、快速、独立 社区相对较新
LangGraph 功能强大 样板代码多、与 LangChain 强耦合
Autogen 对话代理能力强 缺乏流程概念
ChatDev 有流程概念 定制能力有限

适用场景

  • 自动化工作流(报告生成、数据分析)
  • 多角色协作系统(一人公司、虚拟团队)
  • 复杂任务分解与执行
  • AI 驱动的应用开发

二、核心概念

2.1 Agent(代理)

Agent 是 CrewAI 的核心单元,代表一个”角色”。

1
2
3
4
5
6
7
8
9
10
11
from crewai import Agent

agent = Agent(
role="高级数据分析师", # 角色
goal="分析数据并提供洞察", # 目标
backstory="你是一位资深分析师...", # 背景故事
verbose=True, # 详细输出
allow_delegation=True, # 是否可以委派任务
tools=[], # 可用工具
llm=..., # 使用的大模型
)

关键参数

  • role:角色名称,定义 Agent 的身份
  • goal:目标,定义 Agent 想要达成什么
  • backstory:背景故事,决定 Agent 的性格和行为方式
  • tools:Agent 可以使用的工具列表
  • llm:Agent 使用的大模型

2.2 Task(任务)

Task 定义 Agent 需要完成的具体工作。

1
2
3
4
5
6
7
8
from crewai import Task

task = Task(
description="分析销售数据,找出增长趋势",
expected_output="包含 5 个关键发现的报告",
agent=agent, # 执行任务的 Agent
output_file="report.md", # 输出文件
)

2.3 Crew(团队)

Crew 是 Agent 的集合,定义它们如何协作。

1
2
3
4
5
6
7
8
from crewai import Crew, Process

crew = Crew(
agents=[agent1, agent2, agent3],
tasks=[task1, task2, task3],
process=Process.sequential, # 或 Process.hierarchical
verbose=True,
)

协作模式

模式 说明 适用场景
Process.sequential 顺序执行,一个任务完成后执行下一个 流程明确的任务
Process.hierarchical 层级模式,自动分配 Manager Agent 协调 需要动态决策的任务

2.4 Tools(工具)

Tools 扩展 Agent 的能力,让它可以搜索、读写文件、调用 API 等。

1
2
3
4
5
6
7
8
9
10
from crewai_tools import SerperDevTool, FileReadTool

search_tool = SerperDevTool() # 搜索工具
file_tool = FileReadTool() # 文件读取工具

agent = Agent(
role="研究员",
tools=[search_tool, file_tool],
...
)

2.5 整体工作流程

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────────┐
│ Crew │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Agent 1 │ │ Agent 2 │ │ Agent 3 │ │
│ │ (分析师) │ │ (研究员) │ │ (撰稿人) │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Task 1 │ │ Task 2 │ │ Task 3 │ │
│ │ 分析数据 │→│ 研究背景 │→│ 撰写报告 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────────┘

三、安装与环境配置

3.1 环境要求

  • Python 3.10 - 3.13
  • 推荐使用 uv 作为包管理器

3.2 安装 CrewAI

方式一:使用 pip

1
2
3
4
5
# 基础安装
pip install crewai

# 安装额外工具
pip install 'crewai[tools]'

方式二:使用 uv(推荐)

1
2
3
4
5
6
# 安装 uv
pip install uv

# 安装 CrewAI
uv pip install crewai
uv pip install 'crewai[tools]'

3.3 创建项目

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建新项目
crewai create crew my_project

# 项目结构
my_project/
├── .env # 环境变量
├── pyproject.toml # 项目配置
└── src/my_project/
├── main.py # 入口文件
├── crew.py # Crew 定义
├── tools/ # 自定义工具
└── config/
├── agents.yaml # Agent 配置
└── tasks.yaml # Task 配置

3.4 常见安装问题

问题 1:ModuleNotFoundError: tiktoken

1
uv pip install 'crewai[embeddings]'

问题 2:Windows 上 Rust 编译错误

1
2
3
# 安装 Visual C++ Build Tools
# 或使用预编译包
uv pip install tiktoken --prefer-binary

四、大模型服务接入(重点)

这是大多数新手卡住的地方。CrewAI 默认使用 OpenAI,但你必须配置正确的 base_url 才能连接到你的大模型服务。

4.1 核心概念

为什么需要 base_url?

1
2
3
4
┌─────────────┐         ┌─────────────────────┐
│ CrewAI │ ────→ │ LLM 服务端点 │
│ (你的代码) │ HTTP │ (base_url) │
└─────────────┘ └─────────────────────┘
  • 默认情况下,CrewAI 会连接 https://api.openai.com/v1
  • 如果你用的是其他服务(阿里百炼、DeepSeek 等),必须指定 base_url
  • 否则会报错:Connection refusedInvalid API key

4.2 OpenAI 官方

1
2
3
4
5
6
7
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
model="gpt-4o",
api_key="sk-xxxxx",
# base_url 默认是 https://api.openai.com/v1,可以不填
)

环境变量方式

1
OPENAI_API_KEY=sk-xxxxx

4.3 Anthropic Claude

1
2
3
4
5
6
from langchain_anthropic import ChatAnthropic

llm = ChatAnthropic(
model="claude-sonnet-4-6",
api_key="sk-ant-xxxxx",
)

环境变量方式

1
ANTHROPIC_API_KEY=sk-ant-xxxxx

4.4 阿里百炼 Coding Plan(推荐)

阿里百炼 Coding Plan 提供两种兼容协议:

协议 Base URL 说明
OpenAI 兼容 https://coding.dashscope.aliyuncs.com/v1 使用 langchain-openai
Anthropic 兼容 https://coding.dashscope.aliyuncs.com/apps/anthropic 使用 langchain-anthropic

使用 OpenAI 兼容协议

1
2
3
4
5
6
7
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
model="qwen-max", # 通义千问模型
api_key="your_dashscope_key",
base_url="https://coding.dashscope.aliyuncs.com/v1", # 关键!
)

使用 Anthropic 兼容协议

1
2
3
4
5
6
7
from langchain_anthropic import ChatAnthropic

llm = ChatAnthropic(
model="qwen-max",
api_key="your_dashscope_key",
base_url="https://coding.dashscope.aliyuncs.com/apps/anthropic", # 关键!
)

环境变量方式

1
2
DASHSCOPE_API_KEY=your_dashscope_key
DASHSCOPE_BASE_URL=https://coding.dashscope.aliyuncs.com/v1

4.5 DeepSeek

1
2
3
4
5
6
7
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
model="deepseek-chat",
api_key="your_deepseek_key",
base_url="https://api.deepseek.com/v1", # 关键!
)

4.6 智谱 AI (GLM)

1
2
3
4
5
6
7
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
model="glm-4",
api_key="your_zhipu_key",
base_url="https://open.bigmodel.cn/api/paas/v4/", # 关键!
)

4.7 本地模型 (Ollama)

1
2
3
4
5
6
7
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
model="llama3",
api_key="ollama", # 任意值
base_url="http://localhost:11434/v1", # Ollama 默认端口
)

4.8 统一配置方案

在实际项目中,推荐使用配置文件统一管理:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# config/llm_config.py

import os
from langchain_openai import ChatOpenAI

def get_llm(provider: str = "dashscope"):
"""统一获取 LLM"""

configs = {
"openai": {
"model": "gpt-4o",
"api_key": os.getenv("OPENAI_API_KEY"),
"base_url": None,
},
"dashscope": {
"model": "qwen-max",
"api_key": os.getenv("DASHSCOPE_API_KEY"),
"base_url": "https://coding.dashscope.aliyuncs.com/v1",
},
"deepseek": {
"model": "deepseek-chat",
"api_key": os.getenv("DEEPSEEK_API_KEY"),
"base_url": "https://api.deepseek.com/v1",
},
}

config = configs.get(provider)
if not config or not config["api_key"]:
raise ValueError(f"请配置 {provider} 的 API Key")

return ChatOpenAI(
model=config["model"],
api_key=config["api_key"],
base_url=config["base_url"],
)

使用

1
2
3
4
5
# 默认使用阿里百炼
llm = get_llm()

# 切换到 OpenAI
llm = get_llm("openai")

4.9 Agent 中使用 LLM

1
2
3
4
5
6
7
8
9
from crewai import Agent
from config.llm_config import get_llm

agent = Agent(
role="分析师",
goal="分析数据",
backstory="你是一位资深分析师",
llm=get_llm("dashscope"), # 指定 LLM
)

五、项目结构详解

5.1 使用 CLI 创建项目

1
2
crewai create crew my_crew
cd my_crew

5.2 目录结构说明

1
2
3
4
5
6
7
8
9
10
11
12
13
14
my_crew/
├── .env # 环境变量(API Key 等)
├── pyproject.toml # Python 项目配置
├── README.md
└── src/my_crew/
├── __init__.py
├── main.py # 入口文件,运行 crew
├── crew.py # 定义 Crew、Agent、Task
├── tools/ # 自定义工具
│ ├── __init__.py
│ └── custom_tool.py
└── config/
├── agents.yaml # Agent 配置(角色、目标、背景)
└── tasks.yaml # Task 配置(描述、预期输出)

5.3 agents.yaml 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# config/agents.yaml

researcher:
role: >
{topic} 高级研究员
goal: >
深入研究 {topic} 领域的最新发展
backstory: >
你是一位经验丰富的研究员,擅长发现最前沿的技术趋势。
你以能够找到最相关信息并以清晰简洁的方式呈现而闻名。

analyst:
role: >
{topic} 数据分析师
goal: >
分析研究数据并生成洞察报告
backstory: >
你是一位严谨的分析师,擅长将复杂数据转化为可执行的洞察。

占位符说明

  • {topic} 会在运行时被替换为实际值

5.4 tasks.yaml 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# config/tasks.yaml

research_task:
description: >
{topic} 进行全面研究,找出最新、最相关的信息。
expected_output: >
包含 10 个关键发现的要点列表
agent: researcher # 执行此任务的 Agent

analysis_task:
description: >
分析研究结果,生成详细的分析报告。
expected_output: >
一份完整的 Markdown 格式报告
agent: analyst
output_file: report.md # 输出文件

5.5 crew.py 定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# crew.py

from crewai import Agent, Crew, Process, Task
from crewai.project import CrewBase, agent, crew, task

@CrewBase
class MyCrew():
"""我的 Crew"""

@agent
def researcher(self) -> Agent:
return Agent(
config=self.agents_config['researcher'],
verbose=True,
)

@agent
def analyst(self) -> Agent:
return Agent(
config=self.agents_config['analyst'],
verbose=True,
)

@task
def research_task(self) -> Task:
return Task(
config=self.tasks_config['research_task'],
)

@task
def analysis_task(self) -> Task:
return Task(
config=self.tasks_config['analysis_task'],
output_file='report.md',
)

@crew
def crew(self) -> Crew:
return Crew(
agents=self.agents,
tasks=self.tasks,
process=Process.sequential,
verbose=True,
)

5.6 main.py 入口

1
2
3
4
5
6
7
8
9
10
11
12
13
# main.py

from my_crew.crew import MyCrew

def run():
"""运行 Crew"""
inputs = {
'topic': 'AI Agents'
}
MyCrew().crew().kickoff(inputs=inputs)

if __name__ == "__main__":
run()

5.7 运行项目

1
2
3
4
5
# 方式一:使用 CLI
crewai run

# 方式二:直接运行 Python
python src/my_crew/main.py

六、实战:构建一人公司 Agent 团队

6.1 场景描述

假设你要开发一个「人生规划器」App,但你只有一个人。你可以创建一个 Agent 团队来帮你:

  • CEO Agent:负责决策和协调
  • CTO Agent:负责技术架构
  • 产品经理 Agent:负责需求分析
  • 工程师 Agent:负责代码实现
  • 测试 Agent:负责质量保证

6.2 项目结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
life-planner-crew/
├── .env
├── requirements.txt
├── main.py
├── agents/
│ ├── ceo_agent.py
│ ├── cto_agent.py
│ ├── product_manager.py
│ ├── backend_engineer.py
│ ├── frontend_engineer.py
│ └── qa_agent.py
├── tasks/
│ ├── requirement_tasks.py
│ ├── development_tasks.py
│ └── test_tasks.py
├── crews/
│ └── development_crew.py
├── tools/
│ └── file_tools.py
└── config/
├── project_config.py
└── llm_config.py

6.3 LLM 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# config/llm_config.py

import os
from langchain_openai import ChatOpenAI

DASHSCOPE_API_KEY = os.getenv("DASHSCOPE_API_KEY")
DASHSCOPE_BASE_URL = "https://coding.dashscope.aliyuncs.com/v1"

def get_default_llm():
"""默认模型(用于决策类 Agent)"""
return ChatOpenAI(
model="qwen-max",
api_key=DASHSCOPE_API_KEY,
base_url=DASHSCOPE_BASE_URL,
)

def get_efficient_llm():
"""高效模型(用于执行类 Agent)"""
return ChatOpenAI(
model="qwen-turbo",
api_key=DASHSCOPE_API_KEY,
base_url=DASHSCOPE_BASE_URL,
)

6.4 Agent 定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# agents/ceo_agent.py

from crewai import Agent
from config.llm_config import get_default_llm

def create_ceo_agent():
return Agent(
role="CEO - 公司首席执行官",
goal="""
负责:
1. 战略决策和目标设定
2. 团队协调和资源分配
3. 处理 Agent 团队分歧
4. 确保项目按时保质完成
""",
backstory="""
你是一位经验丰富的技术创业者。
决策果断但善于倾听,关注商业价值。
""",
verbose=True,
allow_delegation=True, # 可以委派任务
llm=get_default_llm(),
)

# agents/backend_engineer.py

def create_backend_engineer_agent():
return Agent(
role="后端工程师",
goal="实现 API 和数据库逻辑",
backstory="你专注于 Node.js 后端开发",
verbose=True,
allow_delegation=False,
llm=get_efficient_llm(), # 使用高效模型
)

6.5 Crew 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# crews/development_crew.py

from crewai import Crew, Process
from agents import (
create_ceo_agent,
create_cto_agent,
create_product_manager,
create_backend_engineer,
)

def create_development_crew():
# 创建 Agent
ceo = create_ceo_agent()
cto = create_cto_agent()
pm = create_product_manager()
backend = create_backend_engineer()

return Crew(
agents=[ceo, cto, pm, backend],
tasks=[], # 动态添加
process=Process.hierarchical, # 层级模式
manager_llm="qwen-max",
manager_agent=ceo, # CEO 作为管理者
verbose=True,
)

6.6 运行效果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
python main.py

# 输出
╔═══════════════════════════════════════════════════════════════╗
║ 🎭 Life Planner Crew - 一人公司 Agent 团队 🎭 ║
╚═══════════════════════════════════════════════════════════════╝

📋 检查环境配置...
✓ DASHSCOPE_API_KEY 已配置
✓ 项目目录存在

🎯 请选择操作模式:
[1] 初始化项目
[2] 功能开发模式
[3] 决策讨论模式

七、常见问题与解决方案

Q1: 连接大模型失败

错误信息

1
ConnectionError: Failed to connect to api.openai.com

原因:没有配置正确的 base_url

解决

1
2
3
4
5
6
7
8
9
# 错误 ❌
llm = ChatOpenAI(model="qwen-max", api_key="xxx")

# 正确 ✅
llm = ChatOpenAI(
model="qwen-max",
api_key="xxx",
base_url="https://coding.dashscope.aliyuncs.com/v1",
)

Q2: API Key 格式错误

错误信息

1
AuthenticationError: Invalid API key

检查项

  1. API Key 是否正确复制(没有多余空格)
  2. 是否填对了环境变量名
  3. .env 文件是否被正确加载

解决

1
2
3
4
5
6
7
# 确保加载 .env
from dotenv import load_dotenv
load_dotenv()

# 验证 API Key
import os
print(os.getenv("DASHSCOPE_API_KEY"))

Q3: Agent 输出不符合预期

原因:角色定义不够清晰

解决:优化 backstory

1
2
3
4
5
6
7
8
9
10
11
# 不好 ❌
backstory="你是一个程序员"

# 更好 ✅
backstory="""
你是一位专注 Node.js 后端开发的工程师。
- 擅长 RESTful API 设计
- 遵循 Clean Code 原则
- 注重代码可维护性
- 使用 TypeScript 和 NestJS
"""

Q4: 依赖安装失败

Windows 上常见问题

1
2
3
4
# 安装 Visual C++ Build Tools
# 或使用预编译包
pip install tiktoken --prefer-binary
pip install 'crewai[embeddings]'

Q5: 如何调试 Agent

开启 verbose 模式

1
2
3
4
5
6
7
8
9
agent = Agent(
role="分析师",
verbose=True, # 输出详细过程
)

crew = Crew(
agents=[agent],
verbose=True, # 输出团队协作过程
)

八、总结

核心要点

  1. CrewAI 是什么:多 Agent 协作框架,让多个 AI 角色协同完成任务
  2. 核心概念:Agent(角色)、Task(任务)、Crew(团队)、Tools(工具)
  3. 关键配置:LLM 接入必须配置 base_url,这是大多数人踩坑的地方

大模型接入速查表

服务商 base_url 备注
OpenAI 默认 无需配置
阿里百炼 Coding Plan https://coding.dashscope.aliyuncs.com/v1 OpenAI 兼容
DeepSeek https://api.deepseek.com/v1 OpenAI 兼容
智谱 AI https://open.bigmodel.cn/api/paas/v4/ OpenAI 兼容
Ollama http://localhost:11434/v1 本地模型

学习资源

下一步

  1. 尝试创建你的第一个 Crew
  2. 接入你喜欢的大模型服务
  3. 设计适合你场景的 Agent 角色
  4. 组合 Crews 和 Flows 构建复杂工作流

作者:AI 技术探索者
日期:2026-03-31

本文基于 CrewAI v1.12+ 和阿里百炼 Coding Plan 服务编写

背景

2023 年 ChatGPT 火了,2024 年 Agent 热了,2025 年 AI 应用全面开花。Java 开发者的 AI 工具箱已经非常成熟——Spring AI 1.0 GA 在 2025 年 5 月正式发布,经过近一年的迭代,已经成为企业级 Java AI 应用的事实标准。

这篇文章站在当下时间点,从产生背景架构演进,从与 LangChain4J 的深度对比实战代码,让你看完就能上手做 AI 应用。不讲虚的,全是干货。


一、Spring AI 是什么,为什么需要它

1. Java 开发者的 AI 困境(2023-2024)

AI 大模型爆发初期,Java 开发者面临两难选择:

方案 问题
直接调用 API 每个服务商 API 不同,切换成本高;缺乏高级抽象(RAG、对话记忆、Agent 等)
用 Python 框架 LangChain、LlamaIndex 都是 Python 原生,Java 项目得跨语言集成,架构不统一

更关键的是:企业级 Java 应用 80% 以上跑在 Spring 上,需要一个原生融入 Spring 生态的 AI 框架。

2. Spring AI 的诞生与演进

Spring AI 的版本演进时间线:

时间节点 版本 里程碑意义
2023 年 11 月 0.8.0 项目启动,首个 Milestone
2024 年全年 0.8.x - 0.9.x 快速迭代,积累社区反馈
2025 年 5 月 1.0.0 GA Spring I/O 2025 正式发布,生产就绪
2025 年下半年 1.0.x - 1.1.x 稳定迭代,修复问题,增加 MCP 支持
2026 年初 1.1.x / 1.2 Agent 能力增强,国产模型支持完善

1.0 GA 版本的核心里程碑

  • API 稳定:ChatClient、Advisor、VectorStore 等核心接口不再变化
  • 生产就绪:Observability、错误处理、配置管理达到企业级标准
  • 生态完善:官方支持 20+ 模型服务商,10+ 向量数据库
  • 文档成熟:官方文档完善,示例丰富,社区活跃

3. 当前定位

站在今天,Spring AI 已经是:

Java 企业级 AI 应用的标准框架,Spring 生态的 AI 基础设施。

一句话概括:Spring AI 是 Java 界的 LangChain,但它比 LangChain 更懂企业级应用。

4. 核心价值矩阵

价值点 说明 企业收益
统一 API 抽象 OpenAI、Azure、Anthropic、Ollama、国产模型……一个接口搞定 模型切换零代码改动,供应商议价能力提升
Spring 原生集成 自动配置、依赖注入、Observability、配置中心 Spring 开发者零学习成本,复用现有基础设施
企业级特性 Token 消耗监控、调用链追踪、熔断降级、安全审计 生产环境直接部署,运维体系一体化
高级 AI 抽象 RAG、Agent、MCP、Function Calling、对话记忆 不用自己造轮子,专注业务逻辑
国产模型支持 阿里通义、百度文心、讯飞星火、腾讯混元 数据合规、成本可控、中文效果优化

二、架构设计:三层抽象 + MCP 协议层

Spring AI 1.0 的架构已经稳定,可以概括为四层:

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────────────┐
│ 应用层 (Application) │
│ ChatClient / PromptTemplate / Advisor / Agent │
├─────────────────────────────────────────────────────────────┤
│ MCP 协议层 (Protocol) │
│ MCP Client / MCP Server / Tool Registry │
├─────────────────────────────────────────────────────────────┤
│ 核心抽象层 (Core Abstractions) │
│ ChatModel / EmbeddingModel / ImageModel / AudioModel │
├─────────────────────────────────────────────────────────────┤
│ 集成层 (Integrations) │
│ OpenAI / Azure / Anthropic / Ollama / Alibaba / VectorDB │
└─────────────────────────────────────────────────────────────┘

1. 核心抽象层:统一接口设计

Spring AI 定义了一套稳定的模型接口,不管底层用哪个服务商,API 都一样。

ChatModel——对话模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 核心接口定义(1.0 GA 后已稳定)
public interface ChatModel extends Model<Prompt, ChatResponse> {
ChatResponse call(Prompt prompt);
}

// 使用示例:服务商切换只需改配置,代码不动
@Autowired
private ChatModel chatModel; // 配置决定具体实现(OpenAI、Azure、Ollama...)

public String chat(String userMessage) {
Prompt prompt = new Prompt(userMessage);
ChatResponse response = chatModel.call(prompt);
return response.getResult().getOutput().getContent();
}

EmbeddingModel——向量嵌入模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public interface EmbeddingModel extends Model<EmbeddingRequest, EmbeddingResponse> {
EmbeddingResponse embed(EmbeddingRequest request);

// 1.0 新增:批量嵌入
List<float[]> embed(List<String> texts);
}

// 使用示例
@Autowired
private EmbeddingModel embeddingModel;

public float[] embed(String text) {
return embeddingModel.embed(text);
}

ImageModel——图像生成模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public interface ImageModel extends Model<ImagePrompt, ImageResponse> {
ImageResponse call(ImagePrompt prompt);
}

// 支持 DALL-E 3、Stability AI、Midjourney API
@Autowired
private ImageModel imageModel;

public String generateImage(String promptText) {
ImagePrompt prompt = new ImagePrompt(promptText,
ImageOptions.builder()
.width(1024)
.height(1024)
.style("vivid")
.build());
return imageModel.call(prompt).getResult().getOutput().getUrl();
}

2. 应用层:高级功能封装

ChatClient——对话客户端(1.0 推荐使用)

ChatClient 是 Spring AI 1.0 推荐的高级 API,采用流式 Builder 模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@Autowired
private ChatClient.Builder chatClientBuilder;

// 构建带默认配置的 ChatClient
ChatClient chatClient = chatClientBuilder
.defaultSystem("你是一个专业的 Java 开发顾问")
.defaultOptions(ChatOptions.builder()
.model("gpt-4o")
.temperature(0.7)
.build())
.build();

// 简单调用
String response = chatClient.prompt()
.user("解释一下 Spring 的依赖注入")
.call()
.content();

// 流式响应(SSE 或 WebSocket)
chatClient.prompt()
.user("写一个 Spring Boot 启动流程分析")
.stream()
.content()
.subscribe(chunk -> System.out.print(chunk));

// 结构化输出(1.0 新增)
Person person = chatClient.prompt()
.user("从文本中提取人物信息:张三,35岁,北京人")
.call()
.entity(Person.class); // 自动转换为 POJO

PromptTemplate——提示词模板

支持 Mustache 语法,动态生成提示词:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
PromptTemplate template = new PromptTemplate("""
请根据以下信息回答问题:

用户姓名:{{name}}
用户角色:{{role}}
问题:{{question}}

请以{{style}}的风格回答。
""");

Map<String, Object> params = Map.of(
"name", "张三",
"role", "架构师",
"question", "如何设计微服务架构",
"style", "专业简洁"
);

Prompt prompt = template.create(params);

Advisor——拦截器模式(1.0 正式 API)

Advisor 是 Spring AI 1.0 的核心拦截器机制,有两种类型:

  • CallAroundAdvisor:同步调用拦截
  • StreamAroundAdvisor:流式调用拦截
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// 自定义 Advisor(1.0 正式 API)
public class LoggingAdvisor implements CallAroundAdvisor {

@Override
public String getName() {
return "LoggingAdvisor";
}

@Override
public int getOrder() {
return 0; // 执行顺序
}

@Override
public AdvisedResponse aroundCall(AdvisedRequest request, CallAroundAdvisorChain chain) {
// 前置处理:记录请求
log.info("AI Request: {}", request.userText());

// 执行调用
AdvisedResponse response = chain.nextAroundCall(request);

// 后置处理:记录响应
log.info("AI Response: {}", response.response().getResult().getOutput().getContent());

return response;
}
}

// 内置 Advisor:QuestionAnswerAdvisor(RAG 自动检索)
QuestionAnswerAdvisor qaAdvisor = new QuestionAnswerAdvisor(
vectorStore,
SearchRequest.defaults()
);

// 内置 Advisor:对话记忆
PromptChatMemoryAdvisor memoryAdvisor = new PromptChatMemoryAdvisor(
chatMemory,
"conversation-123"
);

// 使用多个 Advisor(链式执行)
String response = chatClient.prompt()
.user("什么是 Spring AI?")
.advisors(memoryAdvisor, qaAdvisor, loggingAdvisor)
.call()
.content();

Agent——自主任务执行(1.1+ 新增)

Spring AI 1.1 开始引入 Agent 抽象,支持自主任务分解和执行:

1
2
3
4
5
6
7
8
9
10
// Agent 基础示例
@Autowired
private Agent agent;

public String executeTask(String task) {
return agent.execute(task)
.plan() // 自主规划
.execute() // 执行步骤
.result(); // 返回结果
}

3. MCP 协议层:AI 的 USB-C 接口

MCP(Model Context Protocol) 是 Anthropic 在 2024 年推出的开放协议,2025 年成为 AI 工具连接的事实标准。Spring AI 1.0 正式支持 MCP。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
MCP 架构:
┌─────────────────────────────────────────────────────────────┐
│ Spring AI MCP Layer │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌──────────────┐ │
│ │ MCP Client │──────► MCP Servers │ │
│ │ (Spring AI) │ │ (Tool/DB/API)│ │
│ └─────────────┘ └──────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────┐ ┌──────────────┐ │
│ │ ChatClient │ │ GitHub MCP │ │
│ │ Agent │ │ File MCP │ │
│ │ │ │ Postgres MCP │ │
│ └─────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘

使用 MCP Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 配置 MCP Server
spring.ai.mcp.servers.github.type=stdio
spring.ai.mcp.servers.github.command=/usr/local/bin/github-mcp-server

// 使用 MCP 工具
ChatClient client = ChatClient.builder(chatModel)
.defaultMcpServers("github", "filesystem", "postgres")
.build();

String response = client.prompt()
.user("查看我最近的 GitHub PR,并总结变更内容")
.call()
.content();
// Agent 会自动调用 GitHub MCP Server 获取 PR 数据

4. 集成层:服务商适配现状(2026)

类型 支持的服务商 状态
对话模型 OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini、Amazon Bedrock、阿里通义、百度文心、讯飞星火、腾讯混元、Ollama ✅ 生产就绪
Embedding OpenAI、Azure、阿里通义、本地模型 ✅ 生产就绪
图像生成 OpenAI DALL-E 3、Stability AI、Azure ✅ 生产就绪
向量数据库 Pinecone、Chroma、Weaviate、Milvus、Redis、PostgreSQL/pgvector、MongoDB、Elasticsearch ✅ 生产就绪
MCP Server GitHub、Filesystem、PostgreSQL、Slack、Google Drive(官方),第三方生态丰富 ✅ 1.0+ 支持

三、Spring 生态兼容方案

Spring AI 最大的优势是原生融入 Spring 生态,这是 LangChain4J 无法比拟的。

1. 自动配置(Spring Boot Starter)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<!-- OpenAI -->
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-openai-spring-boot-starter</artifactId>
<version>1.1.0</version>
</dependency>

<!-- 阿里云通义千问 -->
<dependency>
<groupId>com.alibaba.cloud.ai</groupId>
<artifactId>spring-ai-alibaba-starter</artifactId>
<version>1.0.0</version>
</dependency>

<!-- 向量数据库 -->
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-milvus-store-spring-boot-starter</artifactId>
</dependency>

2. Observability(可观测性)

Spring AI 自动集成 Spring Boot Actuator,AI 调用的可观测性零配置开启

1
2
3
4
5
6
7
8
9
10
management:
endpoints:
web:
exposure:
include: health,metrics,prometheus
tracing:
enabled: true
observations:
ai:
enabled: true # AI 调用自动追踪

自动上报的指标

指标 说明
ai.chat.tokens.used Token 消耗量(Prompt + Completion)
ai.chat.latency 调用耗时(P50、P95、P99)
ai.chat.success.rate 成功率
ai.embedding.latency Embedding 耗时
ai.vectorstore.search.latency 向量检索耗时

自动追踪的 Span

1
2
3
4
5
6
AI Chat Call
├── ai-chat-request (Prompt 构建)
├── ai-chat-model-call (LLM 调用)
│ ├── token-count (Token 计算)
│ └── response-parse (响应解析)
└── ai-chat-response (结果处理)

3. Spring Cloud 集成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// 配置中心:模型参数动态刷新
@RefreshScope
@Service
public class AiService {

@Value("${spring.ai.openai.chat.options.model}")
private String model;

@Value("${spring.ai.openai.chat.options.temperature}")
private Double temperature;
}

// 熔断降级:AI 调用失败保护
@Service
public class ResilientAiService {

@Autowired
private ChatClient chatClient;

@CircuitBreaker(name = "aiService", fallbackMethod = "fallback")
@Retry(name = "aiService")
@RateLimiter(name = "aiService")
public String chat(String message) {
return chatClient.prompt()
.user(message)
.call()
.content();
}

public String fallback(String message, Exception e) {
return "AI 服务暂时不可用,请稍后重试";
}
}

4. Spring Security 集成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// AI API Key 安全管理
@Configuration
public class AiSecurityConfig {

@Bean
public ChatModel chatModel(KeyProvider keyProvider) {
// Key 从 Vault 或密钥管理服务获取
String apiKey = keyProvider.getApiKey("openai");

return OpenAiChatModel.builder()
.apiKey(apiKey)
.build();
}
}

// 用户级 AI 权限控制
@Service
public class SecuredAiService {

@PreAuthorize("hasRole('AI_USER')")
public String chat(String message) {
// 只有 AI_USER 角色才能调用
return chatClient.prompt().user(message).call().content();
}
}

四、Spring AI vs LangChain4J:2026 年深度对比

LangChain4J 是另一个流行的 Java AI 框架,两者经常被拿来对比。站在 2026 年的视角,对比结果已经清晰。

1. 版本成熟度对比

框架 最新版本 发布时间 成熟度
Spring AI 1.1.x / 1.2 2025.05 GA 生产就绪,API 稳定
LangChain4J 1.0.x 2025.06 GA 生产就绪,社区活跃

两者都在 2025 年上半年发布了 1.0 GA 版本,生产就绪度相当。

2. 设计哲学对比

维度 Spring AI LangChain4J
设计哲学 Spring 原生,企业级优先 轻量独立,框架中立
依赖要求 必须有 Spring Boot 3.x 无强制依赖,支持 Quarkus/Micronaut/Spring
API 风格 Builder 模式 + Advisor 链 流式 API + AI Services 注解
配置方式 YAML 自动配置 + Actuator 代码 Builder 配置
生态集成 Spring 全生态无缝集成 需手动集成各框架

3. 核心能力对比

能力 Spring AI LangChain4J 说明
Chat ✅ ChatClient ✅ ChatLanguageModel 都成熟
Embedding ✅ EmbeddingModel ✅ EmbeddingModel 都成熟
RAG ✅ QuestionAnswerAdvisor ✅ ContentRetriever + Augmentor Spring AI 更简洁
Function Calling ✅ @Bean + @Description ✅ @Tool 注解 LangChain4J 更直观
对话记忆 ✅ PromptChatMemoryAdvisor ✅ ChatMemoryProvider 都成熟
结构化输出 ✅ .entity(Class) ✅ 返回 POJO 都成熟
MCP 协议 ✅ 1.0+ 原生支持 ✅ 1.0+ 支持 Spring AI 集成更深
Agent ⚠️ 1.1+ 基础支持 ✅ 成熟的 Agent 框架 LangChain4J 更成熟
Observability ✅ Actuator 自动集成 ⚠️ 需手动配置 Spring AI 完胜
国产模型 ✅ 官方支持阿里/百度/讯飞 ⚠️ 需自行适配 Spring AI 优势

4. 代码风格对比

对话模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Spring AI:流式 Builder
@Autowired
private ChatClient chatClient;

String response = chatClient.prompt()
.system("你是一个专业的顾问")
.user("你好")
.advisors(memoryAdvisor)
.call()
.content();

// LangChain4J:直接调用
ChatLanguageModel model = OpenAiChatModel.builder()
.apiKey("key")
.modelName("gpt-4o")
.build();

String response = model.generate("你好");

AI Services 注解(LangChain4J 特色)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// LangChain4J 的声明式 AI Services
interface Assistant {
@SystemMessage("你是一个专业的 Java 顾问,回答要简洁")
String chat(@UserMessage String question);

@UserMessage("讲一个关于 {{topic}} 的笑话")
String tellJoke(@V("topic") String topic);
}

// 一行代码构建
Assistant assistant = AiServices.builder(Assistant.class)
.chatLanguageModel(model)
.chatMemoryProvider(id -> MessageWindowChatMemory.withMaxMessages(10))
.tools(new MyTools())
.build();

// Spring AI 需要用 ChatClient + PromptTemplate 实现
// 目前没有直接的 AI Services 对应

RAG 实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Spring AI:Advisor 自动处理
@Autowired
private VectorStore vectorStore;

QuestionAnswerAdvisor qaAdvisor = new QuestionAnswerAdvisor(
vectorStore,
SearchRequest.defaults().withTopK(5)
);

String response = chatClient.prompt()
.user("什么是 Spring AI?")
.advisors(qaAdvisor)
.call()
.content();

// LangChain4J:ContentRetriever + Augmentor
ContentRetriever retriever = EmbeddingStoreContentRetriever.builder()
.embeddingStore(embeddingStore)
.embeddingModel(embeddingModel)
.maxResults(5)
.build();

Augmentor augmentor = DefaultAugmentor.builder()
.contentRetriever(retriever)
.build();

Assistant assistant = AiServices.builder(Assistant.class)
.chatLanguageModel(model)
.augmentor(augmentor)
.build();

5. Agent 能力对比(关键差异)

LangChain4J 的 Agent 更成熟

1
2
3
4
5
6
7
8
9
10
// LangChain4J:完整的 Agent 框架
Agent agent = Agent.builder()
.chatLanguageModel(model)
.tools(new FileTools(), new WebSearchTools(), new DatabaseTools())
.chatMemoryProvider(id -> MessageWindowChatMemory.withMaxMessages(20))
.systemMessage("你是一个自主解决问题的助手...")
.build();

// Agent 自主执行复杂任务
String result = agent.run("分析这份文档,找出关键问题,并生成改进建议");

Spring AI 的 Agent(1.1+)还在发展

1
2
3
4
5
6
7
// Spring AI:基础 Agent 能力
AgentExecutor executor = AgentExecutor.builder()
.chatModel(chatModel)
.tools(toolRegistry)
.build();

AgentResult result = executor.execute("任务描述");

结论:复杂 Agent 应用,LangChain4J 目前更成熟;企业级可观测 Agent,Spring AI 更适合。

6. 选型决策矩阵

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
选型决策树:

├─ 项目技术栈?
│ ├─ Spring Boot → Spring AI(生态融合度最高,必选)
│ ├─ Quarkus → LangChain4J(官方支持更好)
│ ├─ Micronaut → LangChain4J
│ └─ 纯 Java → LangChain4J(轻量)

├─ 是否需要企业级特性?
│ ├─ Observability 重要 → Spring AI(零配置集成)
│ ├─ Spring Cloud 配置中心 → Spring AI
│ ├─ Spring Security 权限 → Spring AI
│ └─ 不需要 → LangChain4J 或 Spring AI 都行

├─ Agent 复杂度?
│ ├─ 复杂自主 Agent → LangChain4J(Agent 框架更成熟)
│ ├─ 简单对话 + RAG → Spring AI(QuestionAnswerAdvisor 更简洁)
│ └─ 可观测 Agent → Spring AI

├─ 国产模型需求?
│ ├─ 阿里通义/百度文心 → Spring AI(官方支持)
│ └─ 国际模型为主 → 两者都支持

├─ 团队熟悉度?
│ ├─ Spring 开发者 → Spring AI(零学习成本)
│ ├─ 非 Spring 开发者 → LangChain4J

└─ 快速原型?
├─ 声明式接口 → LangChain4J AI Services(接口定义即实现)
└─ Spring 体系 → Spring AI ChatClient

一句话总结

场景 推荐
Spring Boot 企业项目 Spring AI(必选)
Quarkus/Micronaut 项目 LangChain4J
复杂自主 Agent LangChain4J(Agent 更成熟)
RAG + 可观测性 Spring AI(Advisor + Actuator)
国产模型合规 Spring AI(官方支持)
快速原型 LangChain4J AI Services

五、实战:Spring AI 经典实践

1. 基础对话应用

Maven 依赖(Spring Boot 3.x)

1
2
3
4
5
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-openai-spring-boot-starter</artifactId>
<version>1.1.0</version>
</dependency>

配置

1
2
3
4
5
6
7
8
9
spring:
ai:
openai:
api-key: ${OPENAI_API_KEY}
base-url: https://api.openai.com # 可切换代理地址
chat:
options:
model: gpt-4o-mini
temperature: 0.7

Controller(推荐写法)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
@RestController
@RequestMapping("/api/chat")
public class ChatController {

private final ChatClient chatClient;

// 推荐:构造时注入,一次性构建
public ChatController(ChatClient.Builder builder) {
this.chatClient = builder
.defaultSystem("你是一个友好的助手,用简洁的语言回答")
.defaultOptions(ChatOptions.builder()
.temperature(0.7)
.build())
.build();
}

@PostMapping
public String chat(@RequestBody String message) {
return chatClient.prompt()
.user(message)
.call()
.content();
}

@GetMapping("/stream")
public Flux<String> streamChat(@RequestParam String message) {
return chatClient.prompt()
.user(message)
.stream()
.content();
}

// 结构化输出
@PostMapping("/extract")
public Summary extract(@RequestBody String text) {
return chatClient.prompt()
.user("总结以下文本:\n" + text)
.call()
.entity(Summary.class);
}
}

public record Summary(String title, List<String> keyPoints, String conclusion) {}

2. Function Calling(工具调用)

Spring AI 1.0 的 Function Calling 已经非常成熟:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
@Configuration
public class AiFunctions {

// 方式一:Spring Bean 函数
@Bean
@Description("查询指定城市的实时天气信息")
public Function<WeatherRequest, WeatherResponse> weatherFunction(WeatherService weatherService) {
return request -> weatherService.getCurrentWeather(request.city());
}

// 方式二:复杂函数
@Bean
@Description("在数据库中搜索相关文档")
public Function<SearchRequest, List<Document>> searchDocuments(DocumentRepository repo) {
return request -> repo.searchByKeyword(request.keyword(), request.limit());
}
}

public record WeatherRequest(String city) {}
public record WeatherResponse(String city, double temperature, String condition, int humidity) {}
public record SearchRequest(String keyword, int limit) {}

// Controller 使用
@RestController
public class WeatherController {

private final ChatClient chatClient;

public WeatherController(ChatClient.Builder builder) {
this.chatClient = builder
.defaultFunctions("weatherFunction", "searchDocuments")
.build();
}

@GetMapping("/weather")
public String askWeather(@RequestParam String question) {
// LLM 自动识别需要调用 weatherFunction
// 如 "北京今天天气怎么样?适合户外运动吗?"
return chatClient.prompt()
.user(question)
.call()
.content();
}
}

3. RAG 应用实战(QuestionAnswerAdvisor)

Spring AI 1.0 的 RAG 实现已经非常简洁:

1
2
3
4
5
6
7
8
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-pdf-document-reader</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-milvus-store-spring-boot-starter</artifactId>
</dependency>

文档导入服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
@Service
public class DocumentService {

private final EmbeddingModel embeddingModel;
private final VectorStore vectorStore;

public DocumentService(EmbeddingModel embeddingModel, VectorStore vectorStore) {
this.embeddingModel = embeddingModel;
this.vectorStore = vectorStore;
}

public void importPdf(String filePath) {
// 1. 读取 PDF
Resource resource = new FileSystemResource(filePath);
TikaDocumentReader reader = new TikaDocumentReader(resource);
List<Document> documents = reader.get();

// 2. 分块
TokenTextSplitter splitter = new TokenTextSplitter(
500, // 默认块大小
100, // 重叠大小
5, // 最小块大小
10000, // 最大块大小
true // 保持段落完整
);
List<Document> chunks = splitter.split(documents);

// 3. 向量化并存入 VectorStore(自动 Embedding)
vectorStore.add(chunks);
}
}

RAG 查询服务(使用 QuestionAnswerAdvisor)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@Service
public class RagService {

private final ChatClient chatClient;
private final VectorStore vectorStore;

public RagService(ChatClient.Builder builder, VectorStore vectorStore) {
this.vectorStore = vectorStore;

// 核心:QuestionAnswerAdvisor 自动处理检索和上下文注入
QuestionAnswerAdvisor qaAdvisor = new QuestionAnswerAdvisor(
vectorStore,
SearchRequest.defaults()
.withTopK(5)
.withSimilarityThreshold(0.7)
);

this.chatClient = builder
.defaultSystem("""
你是一个专业的问答助手。
请严格基于提供的文档内容回答问题。
如果文档中没有相关信息,请明确告知"文档中未找到相关内容"。
回答时请标注信息来源。
""")
.defaultAdvisors(qaAdvisor)
.build();
}

public String query(String question) {
// Advisor 自动检索相关文档并注入上下文
return chatClient.prompt()
.user(question)
.call()
.content();
}
}

对比:Spring AI 的 RAG 只需要 3 行核心代码,LangChain4J 需要更多配置。

4. 使用阿里云通义千问(国产模型)

国内项目首选阿里云,性价比高,中文效果好:

1
2
3
4
5
<dependency>
<groupId>com.alibaba.cloud.ai</groupId>
<artifactId>spring-ai-alibaba-starter</artifactId>
<version>1.0.0</version>
</dependency>
1
2
3
4
5
6
7
spring:
ai:
alibaba:
api-key: ${DASHSCOPE_API_KEY}
chat:
options:
model: qwen-plus # qwen-turbo / qwen-plus / qwen-max
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Service
public class AlibabaAiService {

private final ChatClient chatClient;

public AlibabaAiService(ChatClient.Builder builder) {
this.chatClient = builder
.defaultSystem("你是一个专业的中文顾问")
.build();
}

public String chat(String message) {
return chatClient.prompt()
.user(message)
.call()
.content();
}
}

支持的通义模型:

  • qwen-turbo:速度快,成本低,适合简单对话
  • qwen-plus:能力均衡,推荐日常使用
  • qwen-max:最强推理,适合复杂任务
  • qwen-vl:多模态,支持图像理解

5. MCP 工具集成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 配置 MCP Server
spring:
ai:
mcp:
servers:
github:
type: stdio
command: /usr/local/bin/github-mcp-server
args:
- --token=${GITHUB_TOKEN}
filesystem:
type: stdio
command: /usr/local/bin/fs-mcp-server
args:
- --root=/data/documents
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Service
public class McpAiService {

private final ChatClient chatClient;

public McpAiService(ChatClient.Builder builder) {
this.chatClient = builder
.defaultMcpServers("github", "filesystem")
.build();
}

public String analyzeGithubPr(String repo, int prNumber) {
return chatClient.prompt()
.user("分析 " + repo + " 的 PR #" + prNumber + " 的变更内容")
.call()
.content();
// 自动调用 GitHub MCP Server 获取 PR 数据
}
}

六、Spring AI 在 AI 潮流中的作用与影响

1. 降低 Java 企业接入 AI 的门槛

经过近一年的生产验证,Spring AI 已经证明了自己的价值:

2024 年痛点 2026 年现状
Java 开发者被迫学 Python Spring 开发者零学习成本接入 AI
跨语言架构复杂 单一技术栈,架构统一
缺乏企业级特性 Observability、安全、配置管理一体化

数据佐证:Spring AI GitHub Stars 从 2024 年的几千增长到 2026 年的数万,企业采用率快速增长。

2. 推动 AI 应用标准化

Spring AI 带来的标准化价值:

标准化 影响
API 统一 模型切换零成本,供应商议价能力提升
Prompt 模板化 版本管理、复用、测试规范化
RAG 模式 QuestionAnswerAdvisor 成为参考模式
Observability AI 调用监控追踪有 Spring 标准
MCP 协议 工具连接有开放标准,生态繁荣

3. 企业级 AI 应用的基础设施

Spring AI 不是玩具框架,是生产级基础设施:

能力 Spring AI 实现
可观测性 Actuator 自动集成,Token 消耗、耗时、成功率自动上报
可配置 YAML 配置 + 配置中心动态刷新
可扩展 新服务商扩展简单,遵循 Spring 模式
可集成 Spring Cloud、Security、Data 一体化
可运维 熔断、限流、重试、降级开箱即用

4. 与 LangChain 生态的分工协作

生态 定位 2026 状态
LangChain(Python) AI 创新的前沿试验场 继续引领新模式
LangChain4J Java 轻量级选择,Agent 优先 Agent 能力领先
Spring AI Java 企业级标准,可观测优先 企业采用率领先

三者不是竞争,是分工协作:LangChain 探路 → LangChain4J 快速跟进 → Spring AI 企业级封装。


七、避坑指南(2026 版)

1. 常见问题

问题 解决方案
API Key 管理混乱 用 Spring Cloud Vault 或配置中心,禁止硬编码
Token 消耗失控 启用 Actuator,配置预算告警,用 maxTokens 限制
RAG 效果不好 调整 Top-K、相似度阈值、分块策略,换 Embedding 模型
响应慢 流式响应,用小模型处理简单请求,预热连接
幻觉问题 RAG + 严格系统提示,设置”无法回答”的 fallback
国产模型不稳定 多模型备份,配置 fallback chain

2. 最佳实践

  1. 用 ChatClient,别直接用 ChatModel:ChatClient 封装更好,Advisor 链式处理
  2. RAG 用 QuestionAnswerAdvisor:3 行代码搞定,别手动拼接上下文
  3. Function 定义清晰@Description 写清楚用途和参数,帮助 LLM 正确调用
  4. VectorStore 选型:原型 Chroma,生产 Milvus/Qdrant,小数据 Redis/pgvector
  5. Observability 必开:上线前先配好,AI 调用必须有追踪
  6. 国产模型合规:数据不出境,用阿里/百度/讯飞,成本可控

3. 生产部署 Checklist

  • [ ] API Key 从配置中心/Vault 获取
  • [ ] Observability 开启,Token 消耗监控
  • [ ] 熔断降级配置(AI 调用失败 fallback)
  • [ ] 流式响应(降低首字延迟)
  • [ ] 日志脱敏(Prompt 可能含敏感信息)
  • [ ] VectorStore 持久化配置
  • [ ] 多模型备份(OpenAI 备通义,反之亦然)

总结

Spring AI 已经是 Java 企业级 AI 应用的事实标准:

维度 Spring AI 优势
成熟度 1.0 GA 近一年,API 稳定,生产验证
生态融合 Spring Boot/Cloud/Security/Actuator 一体化
企业级特性 Observability、配置管理、安全审计开箱即用
国产支持 阿里/百度/讯飞官方支持,合规可控
RAG 简洁 QuestionAnswerAdvisor 3 行代码搞定
MCP 支持 1.0+ 原生支持,工具生态繁荣

一句话:Spring 项目做 AI 应用,Spring AI 是唯一合理的选择。LangChain4J 在 Agent 方面领先,但企业级可观测性,Spring AI 完胜。

如果你是 Spring 开发者,想做 AI 应用,现在就是最好的时机——Spring AI 已经成熟,文档完善,社区活跃,生产就绪。


参考资料

一、为什么 SDD 突然火了?

2025 年下半年,GitHub 上突然冒出两个”爆款”项目:

项目 Stars 出品方 创建时间
spec-kit 87,549 GitHub 官方 2025-08
OpenSpec 39,543 Fission AI 2025-08

两个项目都主打同一个概念——SDD(Specification-Driven Development,规格驱动开发)

有意思的是,SDD 这个概念早在 2010 年左右就有人提过,但一直不温不火。为什么到了 2025 年突然”爆了”?

答案很简单:AI 编码助手成熟了

以前写规格是为了”人理解需求”,现在写规格是为了”AI 理解需求并生成代码”。这个转变,让 SDD 从”锦上添花”变成了”必备技能”。


二、SDD 的起源与发展

2.1 方法论的演进脉络

软件开发方法论一直在”左移”——把质量保障的关口往前推:

1
2
3
4
5
6
7
8
9
10
11
传统开发:需求 → 编码 → 测试 → 部署
↑______________| 问题发现太晚

TDD(2003):测试 → 编码 → 重构
↑_____| 先写测试,确保可测试

BDD(2006):行为描述 → 测试 → 编码
↑__________| 用自然语言描述行为

SDD(2025):规格 → AI生成代码 → 审查验证
↑______________| 先写清楚"要什么",AI 再生成"怎么做"

用一个生活类比:

方法论 类比
传统开发 厨师边做菜边尝,最后才发现盐放多了
TDD 先准备好品尝标准,做菜过程中不断对照
BDD 先写好”菜谱描述”(这道菜应该有什么味道),再让厨师做
SDD 先写好”完整菜单规格”(食材、步骤、口味),让 AI 厨师按规格来做

2.2 为什么以前 SDD 不火?

SDD 的核心思想是”先写规格再写代码”,听起来很合理。但以前有三大障碍:

  1. 人写代码比写规格快:资深程序员脑子里有模板,写代码比写文档快多了
  2. 规格容易过时:代码改了,规格忘了同步,最后变成”摆设”
  3. 没有工具支撑:规格只是 Markdown 文档,没法”执行”,也没法验证代码是否符合规格

2.3 为什么现在突然火了?

2024-2025 年,三个关键条件同时成熟:

条件 变化
AI 编码工具成熟 Claude Code、Cursor、Copilot 能真正写出可用代码
开发者角色转变 从”代码编写者”变成”规格设计者 + 代码审查者”
工具链完善 spec-kit、OpenSpec 提供了规格的”执行框架”

一个数据:预计到 2026 年,80% 的开发者将常态化使用 AI 编码工具。开发者花在规格设计和架构上的时间将超过写代码的时间。


三、SDD 的核心能力

3.1 一句话定义

SDD = 先用结构化规格精确描述”要做什么”,再让 AI 照着规格生成代码,最后验证代码是否符合规格。

3.2 核心能力拆解

能力 说明
协作澄清 开发者可能不清楚怎么做,AI 协助完成问题定义和方案探索——这是 SDD 最被低估的能力
规格即契约 规格不是”参考文档”,而是人机之间的”契约”——AI 必须按规格实现
迭代友好 规格可以随时更新,AI 会同步更新代码(不是”写完就扔”)
验证闭环 有工具验证代码是否符合规格,偏离时自动提醒
追溯性强 每一行代码都能追溯到对应的规格条款

3.3 协作澄清:SDD 最被低估的能力

很多人以为 SDD 是”开发者先写清楚规格,再让 AI 照着做”。但现实是:开发者往往也不清楚自己要什么

这时候,SDD 的”澄清模式”就派上用场了:

1
2
传统模式:开发者想清楚 → 写规格 → AI 实现
澄清模式:开发者有个模糊想法 → AI 协助澄清 → 共同定义问题 → 探索方案 → 写规格 → AI 实现

用一个类比:

场景 类比
传统 SDD 你拿着完整菜单去餐厅,厨师照着做
澄清模式 你说”我想吃点清淡的”,厨师和你讨论:是汤?是蒸菜?有什么忌口?最后一起定菜单

这就是 /speckit.clarify/opsx:explore 模式的价值——AI 不是被动执行者,而是主动的”需求澄清伙伴”

3.4 规格包含什么?

一个完整的 SDD 规格通常包含四个部分:

1
2
3
4
5
6
7
openspec/changes/add-dark-mode/
├── proposal.md # 为什么做这个改动?影响范围?
├── specs/ # 详细需求规格
│ ├── requirements.md # 功能需求
│ └── scenarios.md # 使用场景
├── design.md # 技术方案:怎么实现?
└── tasks.md # 任务清单:分几步完成?

3.5 与 TDD/BDD 的关系

SDD 不是替代 TDD/BDD,而是它们的”前置层”:

1
2
3
4
5
6
7
8
9
10
11
12
13
┌─────────────────────────────────────────────────────┐
│ SDD │
│ 规格 → 定义"要做什么" │
├─────────────────────────────────────────────────────┤
│ BDD │
│ 行为描述 → 定义"应该有什么行为" │
├─────────────────────────────────────────────────────┤
│ TDD │
│ 测试 → 定义"怎么验证正确性" │
├─────────────────────────────────────────────────────┤
│ 实现 │
│ 代码 → AI 按上述三层约束生成 │
└─────────────────────────────────────────────────────┘

四、如何与 Code Agent 配合使用

4.1 工作流程对比

没有 SDD 时的工作流

1
2
3
4
5
6
7
8
9
10
你:帮我加个深色模式
AI:(直接开始写代码)好的,我创建 ThemeContext...
你:等等,我想要的是 localStorage 持久化
AI:那我改一下...
你:还要支持系统主题自动切换
AI:再改一下...
你:切换按钮放在导航栏右侧
AI:...

问题:需求在"聊天中不断补充",AI 来回改,效率低

有 SDD 时的工作流

1
2
3
4
5
6
7
8
你:/opsx:propose "添加深色模式"
AI:生成完整规格 → proposal + specs + design + tasks
你:(审查规格)嗯,规格里漏了 localStorage 持久化,补一下
AI:(更新规格)
你:(确认无误)/opsx:apply
AI:按规格一次性实现,不用来回改

优势:先对齐"要做什么",再一次性实现

4.2 支持的 Code Agent

Code Agent spec-kit 支持 OpenSpec 支持
Claude Code --ai claude /opsx:* 命令
Cursor ✅ slash commands ✅ slash commands
GitHub Copilot CLI ✅ 原生支持 ✅ skills 模式
Codex CLI ✅ skills 模式 ✅ skills 模式
Windsurf

五、问题澄清模式:当你不知道怎么做时

前面讲的流程都有一个前提:开发者知道”要做什么”。但现实往往是:

“我想给博客加个评论功能,但不知道怎么设计…”
“用户反馈搜索太慢,但我不清楚具体慢在哪里…”
“产品说要提升用户体验,但这个需求太模糊了…”

这时候,澄清模式(Clarify/Explore) 就派上用场了。

5.1 澄清模式的价值

澄清前 澄清后
“我想加评论功能”(模糊) “评论功能需要:登录才能评论、支持楼中楼、可编辑删除、有审核机制”(清晰)
“搜索太慢”(笼统) “问题定位:首页搜索接口响应 3s+,原因是全文检索没走索引,需要优化 SQL 并加缓存”(具体)
“提升用户体验”(抽象) “具体方案:页面加载加骨架屏、关键操作加确认弹窗、表单加实时校验提示”(可落地)

澄清过程本身就是在”定义问题”——很多 Bug 的根因不是代码写错了,而是需求本身就没想清楚。

5.2 spec-kit 的澄清流程

使用 /speckit.clarify 命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
你:/speckit.clarify "我想给博客加个评论功能"

AI:让我帮你澄清一下这个需求...
Q1: 评论需要登录才能发吗?
你:是的,必须登录

Q2: 评论支持回复别人的评论吗?(楼中楼)
你:支持,最多嵌套 3 层

Q3: 评论发出去能编辑或删除吗?
你:发出去 5 分钟内可以编辑,用户自己发的可以删除

Q4: 评论需要审核吗?还是直接显示?
你:需要审核,管理员后台审核后才显示

AI:好的,我来整理一下澄清后的需求...

[生成 clarification.md]
✓ 问题边界已明确
✓ 关键决策已记录
✓ 可以进入规格编写阶段

你:/speckit.spec blog-comment-system

5.3 OpenSpec 的探索流程

使用 /opsx:explore 命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
你:/opsx:explore "用户反馈搜索太慢,想优化一下"

AI:让我先帮你分析问题...

1. 定位问题范围:
- 是首页搜索慢?还是后台管理搜索?
- 是所有搜索都慢?还是特定关键词?
- "慢"的标准是什么?2s?5s?

你:首页的全站搜索,大概 3-4 秒才出结果,用户说体验很差

2. 排查可能原因:
- 检查当前实现:全文检索 LIKE '%keyword%'
- 数据量:posts 表 10万+,没走索引
- 缓存策略:无缓存,每次查库

3. 方案探索:
方案A:加全文索引(MySQL FULLTEXT)
方案B:引入 Elasticsearch
方案C:加 Redis 缓存热点关键词

各方案对比:
| 方案 | 成本 | 效果 | 维护难度 |
|------|------|------|----------|
| A | 低 | 中(大数据量仍慢) | 低 |
| B | 高 | 高 | 高(新增组件) |
| C | 低 | 中(命中率依赖) | 低 |

建议组合方案:A + C,先加索引打底,再加缓存加速热点

你:就用 A + C 组合方案

AI:好的,我来生成探索记录...

[生成 openspec/explorations/search-optimization/]
✓ exploration.md — 问题分析 + 方案对比
✓ decision.md — 最终选择的方案 + 原因
✓ 可以进入 /opsx:propose 阶段

5.4 澄清模式的核心价值

用一个公式总结:

1
需求质量 = 澄清深度 × 规格精度 × 验证闭环

澄清是起点。如果一开始需求就模糊,后面写再详细的规格、做再严格的验证,都是”在错误的方向上努力”。

很多项目的返工、延期,根因都在这里:

返工原因 根因
“这不是我想要的” 澄清不够,理解偏差
“需求又变了” 边界没定清楚,后面不断加范围
“实现方案不对” 没探索充分,选错了技术路线

SDD 的澄清模式,就是帮你把这些问题”前置解决”——在写代码之前,先把问题聊清楚。


六、与 Claude Code 配合的安装步骤

6.1 spec-kit 安装

1
2
3
4
5
6
7
8
# 方式一:推荐安装稳定版本(v0.6.1)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.6.1

# 方式二:安装最新版本
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 验证安装
specify check

初始化项目:

1
2
3
4
5
# 创建新项目
specify init my-project --ai claude

# 或在现有项目中初始化
specify init . --ai claude

6.2 OpenSpec 安装

1
2
3
4
5
6
7
8
9
# 需要 Node.js 20.19.0+
npm install -g @fission-ai/openspec@latest

# 验证安装
openspec --version

# 初始化项目
cd your-project
openspec init

七、实战示例:同一个需求,两种工具

需求:为博客网站添加深色模式

7.1 spec-kit 使用流程

步骤 1:定义项目原则

1
2
cd my-project
claude

在 Claude Code 中执行:

1
2
3
4
> /speckit.constitution 创建项目核心原则:
- 代码风格遵循 ESLint 规范
- 所有 UI 组件需要单元测试
- 新功能需要配套文档

AI 会生成 .speckit/constitution.md 文件。

步骤 2:创建功能规格

1
2
3
4
5
6
7
> /speckit.spec add-dark-mode 创建深色模式功能规格

需求要点:
- 支持亮色/深色/跟随系统三种模式
- 用户偏好存储在 localStorage
- 导航栏右侧放置切换按钮
- 切换时平滑过渡动画

AI 会生成 .speckit/features/add-dark-mode/spec.md

步骤 3:生成实施计划

1
> /speckit.plan add-dark-mode

AI 生成 .speckit/features/add-dark-mode/plan.md,包含:

  • 技术方案(用 React Context 还是 CSS 变量?)
  • 文件改动清单
  • 实施步骤

步骤 4:分解任务

1
> /speckit.tasks add-dark-mode

生成 .speckit/features/add-dark-mode/tasks.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
## Tasks

### 1. 基础设施
- [ ] 1.1 创建 ThemeContext
- [ ] 1.2 定义 CSS 变量体系
- [ ] 1.3 创建 useTheme hook

### 2. UI 组件
- [ ] 2.1 创建 ThemeToggle 组件
- [ ] 2.2 添加过渡动画样式
- [ ] 2.3 集成到导航栏

### 3. 持久化
- [ ] 3.1 localStorage 存取逻辑
- [ ] 3.2 系统主题监听

### 4. 测试
- [ ] 4.1 ThemeContext 单元测试
- [ ] 4.2 ThemeToggle 组件测试

步骤 5:执行实施

1
> /speckit.implement add-dark-mode

AI 按任务清单逐项实现代码。

步骤 6:验证审查

1
> /speckit.verify add-dark-mode

AI 检查:

  • 每个任务是否完成
  • 代码是否符合规格
  • 测试是否通过

7.2 OpenSpec 使用流程

步骤 1:一键生成完整规格

1
2
cd my-project
claude

在 Claude Code 中执行:

1
2
> /opsx:propose "添加深色模式,支持亮色/深色/跟随系统三种模式,
用户偏好存储在 localStorage,导航栏右侧放置切换按钮"

AI 一次性生成完整规格目录:

1
2
3
4
5
6
7
openspec/changes/add-dark-mode/
├── proposal.md # ✅ 为什么做?影响哪些页面?
├── specs/
│ ├── requirements.md # ✅ 功能需求详情
│ └── scenarios.md # ✅ 用户使用场景
├── design.md # ✅ 技术方案:React Context + CSS 变量
└── tasks.md # ✅ 实施任务清单

步骤 2:审查并调整规格

1
2
> 打开 specs/requirements.md,补充一个需求:
切换按钮需要显示当前模式图标(太阳/月亮/电脑)

AI 更新规格文件。

步骤 3:执行实施

1
> /opsx:apply

输出:

1
2
3
4
5
6
7
8
9
10
11
12
AI: Implementing tasks...
✓ 1.1 Create ThemeContext provider
✓ 1.2 Define CSS variable system
✓ 1.3 Create useTheme hook
✓ 2.1 Create ThemeToggle component
✓ 2.2 Add transition animation
✓ 2.3 Integrate to navbar
✓ 3.1 localStorage logic
✓ 3.2 System theme listener
✓ 4.1 Unit tests
✓ 4.2 Component tests
All tasks complete!

步骤 4:归档

1
> /opsx:archive

AI 将完成的变更归档:

1
2
Archived to openspec/changes/archive/2026-04-13-add-dark-mode/
Specs updated. Ready for the next feature.

八、spec-kit vs OpenSpec:如何选择?

维度 spec-kit OpenSpec
出品方 GitHub 官方 Fission AI(创业公司)
风格 工程化、严谨 灵活、快速
安装 Python + uv Node.js + npm
流程 分步执行(6 个命令) 一键生成 + 一键应用
扩展性 40+ 官方扩展 配置化定制
适合场景 大型项目、团队协作 个人项目、快速迭代
学习曲线 较陡(概念多) 较平(上手快)

选择建议

1
2
3
4
5
6
如果你是...
├─ 大型团队,需要严格控制 → 选 spec-kit
├─ 个人开发者,追求效率 → 选 OpenSpec
├─ Python 项目 → spec-kit(工具链一致)
├─ TypeScript/JS 项目 → OpenSpec(工具链一致)
└─ 想快速体验 SDD → 先试 OpenSpec,再学 spec-kit

九、总结:SDD 是 AI 编码时代的”必修课”

回顾一下:

  1. SDD 不是新概念,但 AI 编码工具让它变得至关重要
  2. 核心能力:协作澄清、规格即契约、迭代友好、验证闭环、追溯性强
  3. 澄清模式:当你不知道怎么做时,AI 协助你把需求聊清楚——这是最被低估的能力
  4. 与 Code Agent 配合:先对齐”要做什么”,再让 AI 一次性实现
  5. 两个主流工具:spec-kit(GitHub 官方)、OpenSpec(灵活高效)

一句话总结:

以前写代码靠”手艺”,现在写代码靠”规格”。写得越清楚,AI 生成得越精准。

如果你自己都不清楚要什么,先用澄清模式把需求聊明白——这才是 SDD 的起点。


参考资料

如果你是一个人做项目,你不需要成为产品经理、架构师、营销专家——只需要知道何时调用哪个「虚拟专家」。Agency-Agents 这个开源项目,就是把 200 多个专业角色打包成了可以直接导入 Claude Code 的 Agent 文件。本文会介绍这个工具是什么、怎么用,以及如何用它协作开发一个完整项目。

阅读全文 »

用 Claude Code 写代码的时候,你有没有过这种焦虑:不知道当前用的什么模型、context 还剩多少、这一轮对话花了多少钱?这三个指标直接影响代码质量和你的钱包,但 Claude Code 默认不显示。好在有个 statusLine 功能,可以自定义一个「仪表盘」实时监控这些数据。

阅读全文 »

画架构图、流程图、时序图,传统方式是打开 draw.io 手动拖拽。Next AI Draw.io 提供了另一种方式:你用自然语言描述,AI 帮你画。更棒的是,它支持 MCP 协议,可以在 Claude Code 中直接调用——写代码时让 AI 顺手把图也画了。

阅读全文 »

写在前面

如果你刚读完《AI 概念指南》,对 LLM、Agent 这些基础概念有了初步了解,但在实际使用 AI 时,可能又遇到了新的困惑:

  • “Claude Code 和 Claude 是什么关系?用 Claude Code 必须用 Claude 吗?”
  • “Claude Code 里可以切换模型,那它和 Kimi、GLM 是什么关系?”
  • “我想用国产模型,该选工具还是选模型?”

这些问题非常普遍。AI 领域有两层东西叠在一起:一层是”大脑”(模型),一层是”应用”(工具)。很多小白搞混,就是因为分不清哪层是哪层。

这篇文章的目标:让你彻底搞清楚模型和工具的关系,看完之后不再迷糊


一、核心概念:两层架构

把 AI 世界想象成一个餐厅:

1
2
3
4
5
6
7
8
9
10
11
┌─────────────────────────────────────────────────────────┐
│ 餐厅(AI 生态) │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 厨师(模型) │◄──────│ 服务员(工具) │ │
│ │ │ │ │ │
│ │ 负责做菜 │ │ 负责端菜、接待 │ │
│ │ 提供"智能能力" │ │ 提供"交互界面" │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘

第一层:AI 模型(厨师)—— 提供”智能”

模型是 AI 的核心,负责思考、理解、生成内容。它就像餐厅里的厨师,决定菜品的”味道”(智能水平)。

模型的核心特点:

  • 不直接面向用户,而是通过 API 被”工具”调用
  • 是智能的”发动机”,所有的推理、理解、生成都在这里完成
  • 一次训练成本极高(数亿到数十亿美元),但边际使用成本低

第二层:AI 工具(服务员)—— 提供”交互”

工具是用户实际接触的产品,负责界面交互、功能整合。它就像餐厅里的服务员,把厨师做的菜端到顾客面前。

工具的核心特点:

  • 直接面向用户,提供聊天界面、编程环境、文档处理等功能
  • 调用一个或多个模型的 API,把模型能力”包装”成用户友好的产品
  • 本身不产生智能,只是”智能的搬运工”

二、主流模型一览(第一层)

先认识一下市面上的”厨师们”:

国内模型

模型 出品公司 特点 适用场景
Kimi 月之暗面 超长上下文(200万字),中文优化 长文档阅读、论文分析
GLM 智谱AI 开源+闭源双轨,学术背景强 技术研究、企业部署
Qwen(通义千问) 阿里巴巴 中文能力强,开源生态好 中文场景、企业应用
DeepSeek 深度求索 开源、性价比极高、数学推理强 代码、数学、技术研究
Doubao(豆包) 字节跳动 中文理解好,性价比高,多场景适配 日常对话、办公助手
MiniMax MiniMax 多模态、语音交互强 语音场景、多模态应用

国外模型

模型 出品公司 特点 适用场景
Claude Anthropic 推理严谨、代码能力强、上下文长 编程、长文档分析、安全场景
GPT(ChatGPT 底层) OpenAI 生态最完善、插件最多 通用场景、创意写作
Gemini Google 多模态原生、谷歌生态集成 多媒体处理、谷歌用户
Llama Meta 完全开源、可本地部署 私有部署、技术研究

一个关键认知

模型本身不是产品。你无法”直接使用”模型,必须通过某个工具(如 ChatGPT、Claude 网页版、API 接口等)来访问模型的能力。

1
2
3
4
5
6
7
8
┌─────────────────────────────────────────────────────────┐
│ 模型不能直接访问 │
│ │
│ ❌ "我要用 GPT-4" —— 这是无法直接做到的 │
│ ✅ "我要用 ChatGPT" —— 这才是正确说法 │
│ │
│ 因为 ChatGPT 是工具,GPT-4 是它背后的模型 │
└─────────────────────────────────────────────────────────┘

三、主流工具一览(第二层)

再认识一下”服务员们”:

AI 对话工具(网页版/APP)

这些工具提供对话界面,让你能和模型”聊天”:

工具 主要模型 是否支持切换模型
ChatGPT GPT 系列 ❌ 仅 OpenAI 模型
Claude 网页版 Claude 系列 ❌ 仅 Anthropic 模型
Kimi 网页版/APP Kimi ❌ 仅月之暗面模型
豆包 Doubao ❌ 仅字节跳动模型
Poe 多模型 ✅ 支持 Claude、GPT、Llama 等
Cherry Studio 多模型 ✅ 支持配置多种模型 API
Chatbox 多模型 ✅ 支持配置多种模型 API

AI 编程工具(IDE/编辑器插件)

这些工具专注于编程场景,能读写代码、理解项目:

工具 类型 支持的模型 特点
Claude Code CLI/IDE插件 Claude、Kimi、GLM、MiniMax、Doubao 等多模型 官方出品,代码理解最强,支持多模型切换
Cursor AI IDE Claude、GPT、DeepSeek、Gemini 等 可切换模型,IDE 集成体验好
GitHub Copilot IDE 插件 GPT 系列 微软出品,与 GitHub 深度集成
Trae AI IDE Kimi、GLM、Doubao 等(国内模型为主) 字节出品,中文优化
Qoder AI 编程工具 多模型 支持多种国产模型
OpenCode 开源 AI 编程工具 多模型 开源免费,可自定义配置

重要说明:Claude Code 是 Anthropic 官方出品的编程工具,但它支持多种模型,包括国内的 Kimi、GLM、MiniMax、Doubao 等。对于没有海外信用卡的中国用户,可以配置国产模型 API 来使用 Claude Code。

工具的本质

工具做的事情就是把你的输入(问题、代码、文档)发送给模型,然后把模型的回答展示给你:

1
2
3
4
5
6
7
8
9
┌─────────────────────────────────────────────────────────────────┐
│ 工具的工作流程 │
│ │
│ 用户输入 ──► 工具处理 ──► 调用模型 API ──► 获取模型回答 ──► 展示给用户
│ │ │ │
│ "帮我写个函数" 发送请求 返回代码
│ 到模型服务器 给用户
│ │
└─────────────────────────────────────────────────────────────────┘

四、模型与工具的关系图

关系示意图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
                              工具层(用户直接接触)
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Claude Code │ │ Cursor │ │ Trae │ │
│ │ (多模型) │ │ (多模型) │ │ (国内模型) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 多模型 API │ │ 多模型 API │ │ Kimi/GLM API │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────┬───────────────────────────────┘


模型层(智能来源)
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Claude │ │ GPT │ │ Gemini │ │ Kimi │ │ DeepSeek│ │
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ GLM │ │ Doubao │ │MiniMax │ │ Qwen │ │ ... │ │
│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘

两种关系模式

模式一:官方绑定型

1
2
3
4
5
6
7
8
9
10
11
┌─────────────┐           ┌─────────────┐
│ ChatGPT │ ────────► │ GPT │
│ (工具) │ 官方绑定 │ (模型) │
└─────────────┘ └─────────────┘

┌─────────────┐ ┌─────────────┐
│ Claude 网页版│ ────────► │ Claude │
│ (工具) │ 官方绑定 │ (模型) │
└─────────────┘ └─────────────┘

特点:一个工具只能用自家模型的 API,不能切换其他模型

模式二:多模型支持型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────┐           ┌─────────────┐
│ Claude Code │ ────────► │ Claude │
│ (工具) │ │ (模型) │
│ │ ────────► ├─────────────┤
│ │ │ Kimi │
│ │ ────────► ├─────────────┤
│ │ │ GLM │
│ │ ────────► ├─────────────┤
│ │ │ MiniMax │
│ │ ────────► ├─────────────┤
│ │ │ Doubao │
└─────────────┘ └─────────────┘

特点:一个工具可以切换多个模型,用户自己选择

注意:Claude Code 虽然是 Anthropic 官方出品,但它支持配置多种模型的 API。对于中国用户来说,这意味着你可以用 Kimi、GLM、MiniMax、Doubao 等国产模型来驱动 Claude Code,而不必依赖海外支付渠道。


五、常见困惑解答

Q1:Claude Code 就是 Claude 吗?

不是。

  • Claude 是模型,是 Anthropic 开发的 AI “大脑”
  • Claude Code 是工具,是 Anthropic 官方出品的编程助手

Claude Code 调用模型来帮你写代码,但它不只是调用 Claude,还支持 Kimi、GLM、MiniMax、Doubao 等多种模型。你可以理解为:

1
Claude Code = 编程专用界面 + 代码操作能力 + 多模型 API 支持

Q2:为什么 Claude Code 可以选择 Claude、Kimi、GLM、MiniMax?

因为 Claude Code 是”多模型工具”,它支持配置多个模型厂商的 API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────────────────────────────────────────────────┐
│ Claude Code 架构 │
│ │
│ 用户界面 ◄──► Claude Code 核心 ◄──► 模型配置 │
│ │ │
│ ┌──────────────────┼────────────┐ │
│ ▼ ▼ ▼ │
│ Claude API Kimi API GLM API │
│ (Anthropic) (月之暗面) (智谱AI) │
│ │
│ ▼ ▼ ▼ │
│ MiniMax API Doubao API 其他 API │
│ (MiniMax) (字节跳动) (可扩展) │
└─────────────────────────────────────────────────────────┘

Claude Code 做的是”整合商”的工作,让你在一个工具里能用多个模型。

对于中国用户特别友好:如果你没有海外信用卡,无法购买 Claude API,完全可以配置国产模型(如 Kimi、GLM、MiniMax、Doubao)的 API 来使用 Claude Code。这些国产模型通常支持国内支付方式,获取 API 更方便。

Q3:我想用国产模型,该怎么选?

方案一:直接用模型官方工具

  • Kimi → Kimi 网页版/APP
  • GLM → 智谱清言
  • Doubao → 豆包 APP
  • Qwen → 通义千问
  • DeepSeek → DeepSeek 网页版

方案二:用支持国产模型的编程工具

这是很多程序员的选择,既能用国产模型,又能享受专业编程工具的体验:

  • Claude Code(推荐)—— 支持 Kimi、GLM、MiniMax、Doubao 等多种国产模型,代码能力最强
  • Trae(字节出品)—— 默认 Kimi/GLM/Doubao,中文优化
  • Qoder —— 支持多种国产模型
  • Cursor —— 支持 DeepSeek

Q4:模型和工具哪个更重要?

都重要,但影响点不同:

维度 模型决定 工具决定
智能水平 ✓ 回答质量、推理能力
使用体验 ✓ 界面设计、操作流畅度
功能丰富度 ✓ 代码高亮、文件管理、历史记录
模型选择 ✓ 是否支持切换模型
价格 ✓ API 调用成本 ✓ 订阅费用
隐私合规 ✓ 数据处理方式 ✓ 本地存储、日志记录

一句话总结:模型决定”上限”,工具决定”体验”。


六、选型指南

按需求选

你的需求 推荐模型 推荐工具
日常聊天问答 GPT-4o、Claude、Doubao ChatGPT、Claude 网页版、豆包
读长文档/论文 Kimi、Claude Kimi 网页版、Claude
写代码/重构 Claude、DeepSeek、GLM Claude Code、Cursor
数学/逻辑推理 DeepSeek-R1、Claude DeepSeek 网页版、Claude Code
国产模型+编程 Kimi、GLM、Doubao、MiniMax Claude Code(配置国产模型 API)
企业私有部署 GLM、Qwen、DeepSeek OpenCode、自建平台

按用户类型选

用户类型 推荐组合 理由
完全小白 ChatGPT 或 Kimi/豆包 网页版 开箱即用,无需配置
办公族 Kimi/豆包 + Claude 网页版 长文档 + 通用问答
程序员(有海外支付) Claude Code + Claude API 官方模型,体验最佳
程序员(国内用户) Claude Code + Kimi/GLM/Doubao API 国产模型,支付方便
技术极客 Cherry Studio + 多模型 API 灵活配置,自由切换
企业用户 私有部署 + 定制工具 数据安全,合规可控

七、避坑指南

常见误区

误区 正确理解
“我买了 Cursor,是不是就能用 Claude?” Cursor 是工具,Claude API 需要单独付费或配置
“Claude Code 只能用 Claude 吗?” 错误! Claude Code 支持多种模型,包括 Kimi、GLM、MiniMax、Doubao 等
“Kimi 和 DeepSeek 哪个好?” 没有绝对好坏,看场景:Kimi 长文档强,DeepSeek 代码数学强
“Claude Code 是官方出品,肯定只支持自家模型” 官方出品不代表只支持自家模型,Claude Code 是开放的多模型工具
“国产模型不如国外模型” 各有优势,国产模型中文理解更好,国外模型生态更完善

省钱技巧

  1. 简单任务用小模型:日常对话用更便宜的模型(如 GPT-4o-mini、Claude Haiku)
  2. 复杂任务用大模型:代码、推理用更强的模型(如 Claude Sonnet、DeepSeek-V3)
  3. 对比后再订阅:先用免费额度测试,再决定是否付费
  4. 注意 API 调用成本:工具可能免费,但模型 API 调用要收费
  5. 国产模型性价比高:Kimi、GLM、Doubao 等国产模型通常价格更友好,支付更方便

八、总结

用一个比喻来总结模型和工具的关系:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 模型 = 发动机(提供动力) │
│ 工具 = 汽车(提供驾驶体验) │
│ │
│ Claude Code = 一辆可以换不同发动机的改装车 │
│ 可以装 Claude、Kimi、GLM、MiniMax、Doubao 等 │
│ │
│ ChatGPT = 装了 GPT 发动机的官方轿车(不能换发动机) │
│ Claude 网页版 = 装了 Claude 发动机的官方轿车(不能换发动机) │
│ │
│ 你可以: │
│ - 买不能换发动机的官方车(ChatGPT、Claude 网页版) │
│ - 买可换发动机的车(Claude Code、Cursor、Poe) │
│ - 自己组装(Cherry Studio + API) │
│ │
│ 核心原则:先想好你要什么体验,再选车和发动机 │
│ │
└─────────────────────────────────────────────────────────────────┘

记住三个要点

  1. 模型是智能来源,工具是交互入口 —— 搞清楚你在用哪层
  2. 一个工具可能支持多个模型,一个模型可以被多个工具调用 —— 它们是多对多的关系
  3. Claude Code 支持多模型 —— 对于中国用户,可以配置国产模型 API 来使用

附录:术语对照表

模型术语 所属公司 常见混淆
Claude Anthropic Claude Code 是工具,Claude 是模型;但 Claude Code 支持多模型
GPT-4、GPT-4o OpenAI ChatGPT 是工具,GPT 是模型
Kimi 月之暗面 同名,但要注意区分工具和模型
DeepSeek 深度求索 同名,网页版是工具,API 是模型
GLM 智谱AI 智谱清言是工具,GLM 是模型
Doubao(豆包) 字节跳动 豆包 APP 是工具,Doubao 是模型
Qwen 阿里巴巴 通义千问是工具,Qwen 是模型
Gemini Google Gemini 网页版是工具,Gemini 是模型

参考资料

背景

很多刚开始接触大模型的朋友,经常会看到”消耗了 XXX tokens”、”超出 token 限制”这样的提示。但到底什么是 Token?为什么大模型要用 Token 而不是直接理解整段话?本文将深入浅出地解答这些问题。


一、Token 是什么?

Token 是大模型处理文本的最小单位。可以把它理解为文本世界的”乐高积木块”——模型不是逐字逐句读取,而是先把文本拆成一块块 Token,再逐块处理。

1.1 通俗理解

想象你在读一本书:

阅读方式 特点
字符级别 一个字母一个字母读 → 太慢,无法理解语义
单词级别 一个单词一个单词读 → 更合理,但词汇量太大
Token 级别 介于两者之间,灵活切分 → 效率与能力的平衡点

1.2 具体例子

英文句子 I love artificial intelligence

1
2
3
按字符:20 个字符(含空格)
按单词:4 个单词
按 Token:约 5-6 个 Token(取决于分词器)

中文句子 我爱人工智能

1
2
按字符:6 个汉字
按 Token:约 6-10 个 Token(每个汉字可能单独成 Token)

二、为什么使用 Token 而不是”理解整段话”?

这个问题触及了大模型的核心原理。答案很简单:计算机只能处理数字,不能直接理解文字

2.1 大模型的工作流程

1
文字 → Token → 数字(向量)→ 计算 → 预测 → Token → 文字

每一步都必须是有限、可枚举的。

2.2 如果是”整段话处理”

假设模型要直接处理”整段话”,会遇到以下问题:

问题 说明
无限组合 一段话可能有任意长度、任意组合,无法穷举
无法对齐 “我爱AI”和”我 爱 AI”算同一段话吗?
无法计算 神经网络本质是矩阵乘法,需要固定维度的输入
存储爆炸 要存储所有可能的句子组合,内存直接撑爆

2.3 Token 方案的优势

优势 说明
有限词汇表 常用 Token 约 5-10 万个,可以穷举并编号
可数学化 每个 Token 对应一个向量(如 4096 维),可以计算
灵活组合 像乐高一样,有限积木块能拼出无限造型
长短皆可 Token 序列可以处理任意长度的文本

2.4 语言的组合性原理

语言有一个核心特点:有限符号,无限组合

1
2
3
英语:26 个字母 → 无数句子
中文:几千常用字 → 无数句子
Token:几万个 Token → 无数句子

大模型的设计正是利用了这个特性:

如果 Token 只有 5 万个,但能组合出无限句子,那么模型只需要学会这 5 万个 Token 的”表示”和”关系”,就能理解所有可能的句子。

这比试图记忆所有可能的句子要高效得多。


三、Token 的产生背景与历史

3.1 为什么不按”单词”处理?

早期自然语言处理确实尝试过按单词处理,但遇到两个问题:

问题一:词汇量爆炸

英语有超过 100 万个单词,而且每天都在增加新词。要让模型记住所有单词,词汇表会无限膨胀。

问题二:罕见词无法处理

遇到没见过的单词(如 unprecedented),模型直接”不认识”。

3.2 子词分词的诞生

研究者提出子词分词的概念:

1
2
常见词 → 整体作为一个 Token
罕见词 → 拆成多个子词 Token

例如:

单词类型 处理方式 例子
常见词 整体作为一个 Token the, is, hello, love
罕见词 拆成多个 Token unprecedentedun + pre + ced + ented
新词 用已知 Token 组合表示 chatgptchat + g + pt

3.3 主流分词算法

目前主流的分词算法有三类:

算法 全称 特点 代表模型
BPE Byte Pair Encoding 合并频率最高的相邻符号 GPT 系列
WordPiece WordPiece 基于概率的分词,用 ## 标记子词 BERT 系列
Unigram Unigram Language Model 基于统计概率,选择最优分词 T5、XLNet

3.4 BPE 分词示例

BPE 的核心思路是迭代合并

1
2
3
4
5
6
7
8
9
10
11
初始状态:每个字符都是一个 Token
["u", "n", "p", "r", "e", "c", "e", "d", "e", "n", "t", "e", "d"]

迭代 1:合并频率最高的字符组合 "e" + "d" → "ed"
["u", "n", "p", "r", "e", "c", "ed", "e", "n", "t", "ed"]

迭代 2:合并 "un"
["un", "p", "r", "e", "c", "ed", "e", "n", "t", "ed"]

迭代 N:最终得到
["un", "pre", "ced", "ented"]

通过这种方式,模型既能高效处理常见词,又能”认识”从未见过的罕见词。


四、Token 计量规则

4.1 不同语言的 Token 效率

这是很多中文用户最容易困惑的地方:

语言 Token 效率 估算公式
英文 1 Token ≈ 0.75 个单词 ≈ 4 个字符 Token 数 ≈ 单词数 × 1.3
中文 1 Token ≈ 0.6-0.8 个汉字 Token 数 ≈ 字数 × 1.5-2
代码 1 Token ≈ 4 个字符 Token 数 ≈ 字符数 ÷ 4

4.2 为什么中文 Token 数更多?

原因在于分词器的训练数据。主流分词器(如 GPT 系列)主要基于英文语料训练:

  • 英文artificial 可能是 1 个 Token(常见词)
  • 中文:每个汉字 可能各自成为 1 个 Token

这导致同样内容,中文 Token 数通常是英文的 1.5-2 倍

4.3 实例对比

同样的内容用不同语言表达:

内容 语言 Token 数估算
The future of artificial intelligence is bright 英文 约 7-8 个
人工智能的未来很光明 中文 约 10-12 个

这就是为什么用中文对话可能更快消耗 Token 配额。

4.4 不同模型的 Token 效率对比

模型系列 中文 Token 效率 特点
GPT-4 较低(约 2 字/Token) 英文优化,中文拆字多
Claude 中等(约 1.5 字/Token) 多语言平衡
DeepSeek 较高(约 1 字/Token) 中文专项优化
Qwen 较高(约 1 字/Token) 中文原生模型

五、Token 在大模型中的作用方式

5.1 完整处理流程

以句子 "人工智能很强大" 为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
步骤 1: 分词
"人工智能很强大" → ["人工", "智能", "很", "强大"]

步骤 2: 编号(在词汇表中查找)
["人工", "智能", "很", "强大"] → [3821, 567, 89, 4521]

步骤 3: 向量化(每个编号对应一个向量)
3821 → [0.12, -0.34, 0.56, 0.78, ...](4096 维向量)
567 → [0.23, 0.45, -0.11, 0.89, ...]
89 → [0.67, -0.23, 0.34, 0.12, ...]
4521 → [0.45, 0.67, 0.23, -0.45, ...]

步骤 4: 神经网络计算
向量输入 Transformer 模型,计算"下一个 Token 是什么"
- 注意力机制:计算 Token 之间的关联关系
- 前馈网络:提取和变换语义信息

步骤 5: 预测输出
模型输出概率分布 → "的"(概率最高)

步骤 6: Token 转文字
["的"] → "的"

完整输出:"人工智能很强大" + "的" → "人工智能很强大的..."

5.2 向量化是什么?

每个 Token 都有一个向量表示——可以理解为这个 Token 的”数学身份证”。

1
2
3
4
5
Token "人工智能" 的向量(简化示例):
[0.12, -0.34, 0.56, 0.78, 0.23, 0.45, -0.11, 0.89, ...]

这个向量有 4096 个数值(或更多)
每个数值代表这个 Token 在某个语义维度上的"坐标"

向量的神奇之处:语义相似的 Token,向量也相似。

1
2
3
4
5
6
7
Token "狗" 的向量:[0.8, 0.2, 0.1, ...]
Token "猫" 的向量:[0.7, 0.3, 0.2, ...]
Token "汽车" 的向量:[0.1, 0.9, 0.5, ...]

计算相似度:
"狗" vs "猫" → 高相似度(都是动物)
"狗" vs "汽车" → 低相似度(语义差异大)

5.3 为什么是 5 万个 Token 而不是 5 万个单词?

关键区别在于覆盖能力

1
2
3
4
5
6
7
8
单词方案:
- 词汇表:5 万个单词
- 遇到新词:直接"不认识"

Token 方案:
- 词汇表:5 万个 Token(子词)
- 遇到新词:用已知 Token 组合表示
- 例:新词 "deepseek" → ["deep", "seek"](都是已知 Token)

这就是 Token 方案的核心优势:有限词汇表 + 无限组合能力


六、Token 量化方法

6.1 方法一:在线可视化工具

最直观的方式是使用官方提供的 Tokenizer 工具:

工具 链接 特点
OpenAI Tokenizer https://platform.openai.com/tokenizer GPT 模型分词可视化
Anthropic Console https://console.anthropic.com Claude 模型分词查看

这些工具可以让你直观看到文本是怎么被拆成 Token 的。

6.2 方法二:代码计算

使用 Python 进行精确计算:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 方案 1:使用 tiktoken(OpenAI 官方库)
import tiktoken

enc = tiktoken.encoding_for_model("gpt-4")
text = "我爱人工智能"
tokens = enc.encode(text)
print(f"Token 数量: {len(tokens)}")
print(f"Token 列表: {tokens}")
print(f"Token 文本: {[enc.decode([t]) for t in tokens]}")

# 方案 2:使用 transformers(通用方案)
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("gpt2")
text = "我爱人工智能"
tokens = tokenizer.encode(text)
print(f"Token 数量: {len(tokens)}")

6.3 方法三:API 返回值

调用大模型 API 时,返回结果通常包含 Token 使用量:

1
2
3
4
5
6
7
8
9
10
11
12
13
from openai import OpenAI

client = OpenAI(api_key="your-key")

response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "介绍一下人工智能"}]
)

# Token 使用量
print(f"输入 Token: {response.usage.prompt_tokens}")
print(f"输出 Token: {response.usage.completion_tokens}")
print(f"总 Token: {response.usage.total_tokens}")

6.4 方法四:经验估算(快速估算)

当你没有工具时,可以用经验公式:

语言 估算公式 示例
英文 Token ≈ 单词数 × 1.3 100 单词 ≈ 130 Token
中文 Token ≈ 字数 × 1.5-2 100 字 ≈ 150-200 Token
代码 Token ≈ 字符数 ÷ 4 400 字符 ≈ 100 Token
混合 各部分分别估算再相加 英文 + 中文 + 代码

七、Token 限制与成本

7.1 各模型的 Token 限制

模型 上下文窗口 最大输出
GPT-4o 128K Token 16K Token
GPT-4 Turbo 128K Token 4K Token
Claude 3.5 Sonnet 200K Token 8K Token
Claude Opus 4.6 200K Token 32K Token
DeepSeek V3 200K Token 8K Token

7.2 Token 与 API 成本

API 费用通常按 Token 计算:

1
2
3
4
5
6
7
8
成本 = 输入 Token × 输入单价 + 输出 Token × 输出单价

例:GPT-4o
- 输入:$2.5 / 1M Token
- 输出:$10 / 1M Token

对话消耗 1000 输入 Token + 500 输出 Token
成本 = 1000 × $2.5/1M + 500 × $10/1M = $0.0075

7.3 超出 Token 限制会怎样?

1
2
3
4
5
6
7
情况 1:输入超出上下文窗口
→ API 报错:context_length_exceeded
→ 解决:截断历史消息或分段处理

情况 2:输出超出最大输出限制
→ 输出被截断,不完整
→ 解决:设置合理的 max_tokens 或分段生成

八、实用技巧:如何节省 Token

8.1 语言选择

同样的内容,用英文表达 Token 数更少:

内容 中文 Token 英文 Token
请帮我写一篇关于人工智能的文章 约 15-20 约 8-10

技巧:如果不需要输出中文,可以用英文提问和回答。

8.2 Prompt 精简

1
2
3
4
5
❌ 冗长版本(约 50 Token):
"请帮我写一篇非常详细的、包含多个方面的、内容丰富的关于人工智能发展历史的文章,要涵盖从早期研究到现在的发展历程"

✅ 精简版本(约 15 Token):
"写一篇 AI 发展史,涵盖早期到现在的关键节点"

8.3 避免重复上下文

每次对话都会带上历史消息,Token 消耗会累积:

1
2
3
4
第 1 轮:100 Token 输入
第 2 轮:100 + 50(历史)= 150 Token 输入
第 3 轮:100 + 50 + 50 = 200 Token 输入
第 N 轮:线性增长...

技巧

  • 定期开启新对话,清除历史
  • 只保留必要的历史消息
  • 使用 System Prompt 存储固定指令

8.4 System Prompt 的妙用

System Prompt 只计算一次,不会重复:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 每条消息都重复指令(浪费 Token)
messages = [
{"role": "user", "content": "请用简洁的语言回答:什么是 AI?"},
{"role": "assistant", "content": "AI 是..."},
{"role": "user", "content": "请用简洁的语言回答:什么是机器学习?"}, # 重复了指令
]

# 使用 System Prompt(高效)
messages = [
{"role": "system", "content": "请用简洁的语言回答所有问题"}, # 只算一次
{"role": "user", "content": "什么是 AI?"},
{"role": "assistant", "content": "AI 是..."},
{"role": "user", "content": "什么是机器学习?"},
]

8.5 图片的 Token 消耗

图片也会消耗 Token,计算方式较复杂:

1
2
3
4
图片 Token ≈ (图片宽度 ÷ 512) × (图片高度 ÷ 512) × 基础 Token 数

例:1024×1024 图片
Token ≈ 2 × 2 × 85 = 340 Token(大致估算)

技巧

  • 压缩图片尺寸
  • 只传必要的图片
  • 使用低分辨率版本

九、Token 与上下文窗口的关系

9.1 上下文窗口是什么?

上下文窗口是模型能”记住”的最大 Token 数:

1
2
3
4
5
模型上下文窗口 = 128K Token

意味着:
- 输入 + 历史对话 + 输出 的总 Token 数不能超过 128K
- 超过部分会被截断或报错

9.2 为什么需要长上下文?

场景 Token 需求
简单问答 100-500 Token
代码分析 5K-20K Token
长文档总结 50K-100K Token
复杂 Agent 任务 100K-1M Token

9.3 长上下文的代价

1
2
3
4
上下文越长:
- 计算成本越高(Transformer 是 O(n²) 复杂度)
- 响应速度越慢
- API 费用越高

十、总结

10.1 Token 的核心概念

概念 说明
Token 大模型处理文本的最小单位,类似”积木块”
分词器 把文本拆成 Token 的工具,不同模型分词方式不同
词汇表 所有已知 Token 的集合,通常 5-10 万个
向量 每个 Token 的”数学身份证”,用于计算

10.2 为什么选择 Token

原因 说明
计算机只认识数字 文字必须转换成数字才能计算
有限词汇表 5 万个 Token 可以穷举和编号
无限组合能力 有限积木块拼出无限造型
处理新词 用已知 Token 组合表示未见过的词

10.3 Token 计量要点

语言 估算公式
英文 Token ≈ 单词数 × 1.3
中文 Token ≈ 字数 × 1.5-2
代码 Token ≈ 字符数 ÷ 4

10.4 实用建议

  • 用英文对话可以节省 Token
  • 精简 Prompt,避免冗长描述
  • 使用 System Prompt 存储固定指令
  • 定期清理历史对话,避免累积
  • 压缩图片尺寸减少 Token 消耗

附录:Token 可视化体验

想直观感受 Token 是怎么”切”文本的?试试这些工具:

  1. OpenAI Tokenizerhttps://platform.openai.com/tokenizer

    • 输入中英文混排的内容
    • 看看模型是怎么”切”的
    • 每个 Token 用不同颜色高亮显示
  2. Anthropic Consolehttps://console.anthropic.com

    • Claude 模型的 Token 计数
    • 支持实时估算
  3. 本地体验

    1
    2
    3
    4
    5
    import tiktoken
    enc = tiktoken.encoding_for_model("gpt-4")
    text = "你的测试文本"
    print(enc.encode(text))
    print([enc.decode([t]) for t in enc.encode(text)])

参考资源

CloudCLI UI(又名 Claude Code UI)是一款基于 Node.js + React 的 Web 应用,为 Claude Code、Cursor CLI、Codex 和 Gemini CLI 提供统一的图形化界面。与桌面应用不同,它可以通过浏览器访问,支持移动端使用,并提供云端托管选项。本文将详细介绍其功能特性、安装配置和使用方法。

阅读全文 »