weixin_29053383说实话，我第一次在项目里正儿八经用上 Claude Code 的 Agent Team 模式，不是看了什么文档顿悟的，而是被一个需求逼的：三天内要交付一个带后台管理、文件上传、权限控制的小型全栈系统，功能不难，但杂，从数据库设计到前端页面，一个人写容易漏，两三个人又没得配。那天晚上我坐在电脑前突发奇想——既然 Claude Code 能自己写代码，能不能让多个 Claude 各管一段，像一个小团队一样分工干活？
试了一个晚上之后，我想把整套流程完整写下来：从安装配置到多 Agent 协作的项目结构设计，再到实际跑一个项目的完整流程、常见报错怎么处理，以及怎么控制 token 成本。这篇指南我会尽量写清楚，适合两类人看：一类是刚开始接触 Claude Code，想搞清楚它能干什么；另一类是已经在用，但总感觉"一个人跟 AI 结对编程"效率天花板明显、想试试让一群 AI Agent 协作开发的。
1. 为什么"一个人带一支 Agent 团队"能提升交付质量
先说结论：Claude Code 的 Agent Team 模式，本质上是把"一个对话窗口里让 AI 改代码"升级成"多个有明确分工、可以互相传递任务的 AI 角色并行协作"。它解决的痛点非常真实，你用普通对话写代码时一定遇到过。
1.1 单 Agent 写项目时的三个真实痛点
第一个痛点是上下文窗口被撑爆。你让同一个 AI 从数据库设计一路干到前端样式，它会把你聊过的每一轮对话都记在上下文里。写到第几十个文件的时候，它可能已经忘了项目最初定的技术栈，甚至会把接口名写错。我见过最离谱的一次，它在中途突然把一个已经删掉的旧字段又加回来了，就是因为上下文里残留的信息太多。
第二个痛点是角色冲突。写代码这件事，规划和执行是两种思维模式。规划的时候需要全局视角，想清楚模块怎么拆分、接口怎么定义；执行的时候需要聚焦，把一个个函数写扎实。让同一个 AI 在同一段对话里反复切换这两种模式，它往往会顾此失彼：规划的时候想得太细浪费时间，写代码的时候又忍不住改方案。
第三个痛点是缺少质量把关。你自己写完代码还得 review，AI 写完代码没人 review，很多低级错误就直接混进去了。这些错误回头又变成你调试的时间成本，等于你把 AI 写的代码又人工测了一遍。
1.2 Agent Team 的协作方式与优势
Agent Team 的思路是：你不是让一个超级 AI 干所有事，而是像带团队一样，拆成多个角色，每个角色干自己擅长的事。Claude Code 里有主代理（Main Agent）和子代理（Subagent）的区分——主代理负责理解你的总体意图、调度任务，子代理按照你定义的指令专注完成特定范围的活儿。
听起来抽象，我打个比方：你是一个项目经理，普通模式是你自己埋头把需求文档、方案、代码、测试全干了；Agent Team 模式是底下有架构师、前端、后端、测试各司其职，你只需要把需求拆分清楚，然后逐个派活、收活、验收。每个 Agent 只在自己的小上下文里工作，效率高、不容易串味，还能并行推进。
1.3 看完这篇文章你能学会什么
这篇指南会带你把 Agent Team 完整跑通一遍。我会从零开始讲安装和登录，重点讲最容易踩坑的环节，然后展开讲怎么设计你的 Agent 团队角色，再拿一个真实的小项目（带数据库的 Web 应用）完整演示一遍从需求到交付的流程。中间会把我在实际使用中遇到的报错、乱码、上下文丢失、token 超标等一系列问题都摊开讲，最后分享一套我自己整理的低成本用法。不想通篇看完的朋友，直接跳到你需要的章节就行。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备：安装、登录与三种常见报错的根因处理
这一节是纯粹的经验活。安装本身不复杂，但网上的教程往往漏了几个关键细节，导致很多人卡在第一步。我按自己实际操作过的路径重新捋一遍。
2.1 安装：npm 一条命令与 Node 版本检查
Claude Code 官方推荐通过 npm 全局安装，命令只有一条：
bash复制npm install -g @anthropic-ai/claude-code
安装完检查版本：
bash复制claude --version
能输出版本号，说明装好了。这里有个很多人忽略的前提：你的 Node.js 版本不能太老，建议 Node 18 或更高。如果 npm install 时报了一堆权限错误（常见于 macOS/Linux 下全局安装），多半是权限问题，加 sudo 可以解决，但更推荐用 nvm 管理 Node 之后再全局装，省心很多。
macOS 上我就是用 nvm 装的 Node，然后一条 npm 命令直接完成；Windows 上同样适用 npm 命令，不过 PowerShell 里如果遇到"无法加载 claude，因为在此系统上禁止运行脚本"这类提示，问题不在 Claude Code，而在 PowerShell 的执行策略，后面细说。
2.2 登录鉴权：Pro 订阅与 API Key 两种模式的取舍
装好之后，在终端敲 claude 进入交互界面，第一次会让你登录。登录方式有两种：一种是直接用 Claude 账号（Pro/Max 订阅）授权，一种是用 Anthropic API Key。
我的建议很明确：如果你只是自己日常写代码、做小项目，用订阅账号登录最省事，反正在你已经订阅的额度内使用，不需要额外为 token 付钱。但要注意，有些团队或公司环境会管控订阅登录，你可能会看到这条报错：your organization has disabled claude subscription access for claude code。这说明当前网络/组织环境不让你用订阅登录，解决办法就是改用 API Key 方式。
API Key 登录的核心就是配置环境变量：
bash复制export ANTHROPIC_API_KEY=sk-ant-xxxx
然后重新运行 claude，就没有登录框了。Windows PowerShell 下用 $env:ANTHROPIC_API_KEY="sk-ant-xxxx" 设置当前会话即可。我建议把 Key 写进系统环境变量或项目的 .env 文件，别频繁手动 export，容易遗漏导致莫名其妙的鉴权失败。
2.3 PowerShell 执行策略报错与 PATH 问题的排查
在 Windows 上跑 Claude Code 遇到的报错，很多跟 Claude 本身一点关系都没有。最常见的是安装时提示"禁止运行脚本"，或运行时提示 claude: command not found。
先说执行策略的问题。PowerShell 默认的脚本执行策略可能是 Restricted，导致 npm 生成的 .cmd 或 .ps1 命令无法执行。解决办法是给当前用户开放 RemoteSigned：
powershell复制Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
执行完重新开一个终端再试 claude。
再说 PATH 问题。npm 全局包的安装路径通常在一个 node 目录下，比如 Windows 的 %APPDATA%\npm，macOS/Linux 的 /usr/local/bin 或 nvm 的 bin 目录。如果你 npm install 显示成功，但终端找不到 claude，就是 PATH 没包含这个目录。用 npm prefix -g 看一下全局目录，把它加进 PATH 再重启终端即可。
2.4 VS Code 扩展提示 could not locate the claude cli on path 的处理
很多朋友喜欢在 VS Code 里用 Claude Code——这个后面会专门讲集成方式。这里先解决一个出现频率极高的报错：在 VS Code 扩展里启动 Claude Code 面板，提示 failed to run claude code: error: could not locate the claude cli on path。
这个报错的原因很直白：VS Code 扩展找不到 claude 命令。VS Code 启动时的环境变量和你终端里的未必完全一致，尤其是你通过 nvm、Volta 这类工具安装 Node 时，终端里能找到 claude，但 VS Code 的进程里 PATH 不完整。
处理办法按顺序试：
- 完全退出 VS Code，再从终端敲
code命令启动，这样 VS Code 会继承终端的 PATH。 - 确认
claude的绝对路径，比如which claude或者npm prefix -g，然后把目录加进系统 PATH。 - 实在不行，在 VS Code 设置里搜
claude-code.path或者直接在扩展设置中手动指定claude可执行文件的完整路径。
这问题我折腾过不止一次，最后是改回从终端启动 VS Code 一劳永逸解决的。
到这里环境基本就绪了。接下来进入正题：怎么设计并驱动一支 Agent 团队。
3. Agent Team 的核心机制：主代理、子代理与团队工作流
装好 Claude Code 只是拿到了入口，真正让它变成"团队协作工具"的，是理解它的一套代理运行机制。很多人不知道 Claude Code 可以定义多个专用代理，这也是这篇指南想重点讲清楚的部分。
3.1 主代理与子代理的分工逻辑
在 Claude Code 里，你日常对话的这个实例是主代理（Main Agent），它有最高的权限，能访问整个项目、执行命令、读写文件，也能调用其他工具。子代理（Subagent / Task Agent）是你用任务文件或命令定义出来的角色，每个子代理有自己独立的系统提示、工具集，甚至是可选的模型配置。
团队协作的核心逻辑是：主代理接收你的指令，拆任务，把任务派给合适的子代理，子代理完成后把结果交回主代理，由主代理汇总给你。放在实际项目里，就是你把"给我做一个博客系统"这句话丢给主代理，主代理内部可能先让规划子代理输出需求文档，再让后端子代理写接口，前端子代理写页面，测试子代理跑检查。
子代理之间如果没有特别设置，彼此不直接通信，所有信息都通过主代理中转。这个设计有利有弊：好处是信息流可控，主代理能过滤和整理；坏处是如果任务设计得不好，主代理可能变成瓶颈。所以，团队协作方案的设计重点，在于怎么让主代理高效地调度。
3.2 用 agents 目录定义团队成员角色
Claude Code 支持在项目里放一个 .claude/agents/ 目录，每个 Markdown 文件就代表一个 Agent 角色。这个机制非常像平时我们写在团队文档里的岗位说明书，只不过系统会直接把这个文件里的内容当成角色的系统提示词。
我拿自己的项目举例，这是我的一个 .claude/agents/planner.md 文件：
markdown复制---
name: planner
description: 负责需求拆解、架构设计和技术方案制定。当需要规划项目结构、拆分任务、定义接口时使用。
tools: Read, Grep, Glob, Task
model: claude-sonnet-4-5
---
你是一个资深软件架构师。你的职责是：
1. 阅读项目文档和代码，理解现状
2. 将需求拆解为可执行的任务清单
3. 给出模块划分、接口定义和数据模型设计
4. 输出清晰的任务描述，供其他 Agent 执行
注意：你不负责写业务代码，你的产出是文档和计划。
这里每个字段都有讲究。name 是 Agent 的标识；description 是主代理判断"什么任务该交给哪个 Agent"的依据，一定要写清楚这个 Agent 擅长干什么；tools 控制它能用的工具，比如我故意不给 planner 编辑文件的工具，防止它越权改代码；model 可以单独指定模型，这个在控制成本时特别有用。
同理，我还会定义 coder.md、reviewer.md、tester.md 等。把这些文件放在项目里，团队成员就只有这个项目有，不会污染其他项目，非常干净。
3.3 run_agent 与 Task 两种驱动方式
定义好角色之后，有两种方式让 Agent 跑起来。
一种是在对话里让主代理用 Task 工具派活。你可以直接说"让 planner 分析一下当前项目结构，输出开发计划"，主代理会自己创建对应的子代理去执行。这种方式适合日常交互，你不需要记任何命令。
另一种是直接用命令行驱动某个 Agent：
bash复制claude run_agent --agent planner "阅读项目 README 和现有代码，输出接下来三个迭代的开发计划"
这个命令会绕过主代理，直接让 planner 干活。适合在脚本、CI 流程里用，也适合你明确知道这一步该谁干的情况。两种方式没有绝对优劣，我更常用的是第一种，让主代理自己判断怎么调度，符合"团队协作"的感觉；只有在需要精确控制某一步时，才用 run_agent。
3.4 团队上下文的传递：CLAUDE.md 与 AGENTS.md
多 Agent 协作容易翻车的点，是"每个 Agent 只能看到部分上下文"。子代理不会自动知道你项目的技术栈、目录结构、命名规范，除非你把全局信息放到一个它们都能读到的地方。
Claude Code 约定的项目记忆机制有两个层级：项目根目录的 CLAUDE.md 是全项目共享的说明文件，任何 Agent 启动时都会读；AGENTS.md 是专门写给 Agent 看的指导文件，可以放在项目根目录，也可以放在子目录，让进入该目录工作的 Agent 自动加载。
我的做法是：CLAUDE.md 里写项目概览、技术栈、常用命令、目录结构说明，比如：
markdown复制# 项目概览
这是一个待办事项 Web 应用，用户可注册登录并管理自己的待办任务。
# 技术栈
- 后端：Node.js + Express
- 数据库：SQLite（通过 better-sqlite3）
- 前端：Vue 3 + Vite
# 常用命令
- 启动后端：npm run server
- 启动前端：npm run dev
- 运行测试：npm test
# 目录说明
- /server 后端代码
- /src 前端代码
- /db 数据库迁移脚本
AGENTS.md 里写协作规范，比如"所有 API 返回格式统一为 { code, data, message }""新增数据表必须写迁移脚本"之类的约定。这样即使任务换了一个新的 Agent 来执行，它也能快速了解项目，而不是靠猜。
这两个文件写得好不好，直接决定了你的 Agent 团队干活靠不靠谱。我见过很多项目没写 CLAUDE.md，结果 Agent 写出来的代码风格五花八门、目录乱堆。花二十分钟把这两个文件写好，后面省下的时间是按小时算的。
4. 端到端实战：用四角色协作完成一个带数据库的 Web 项目
理论讲了这么多，下面我带大家完整走一遍实战。这个项目我选的是"图书管理后台"，包含用户登录、图书增删改查和上传封面。不算复杂，但足够覆盖数据库、接口、页面、联调四个环节，适合演示多 Agent 协作。
4.1 需求拆解：把项目说明书转化为任务清单
一切协作从拆任务开始。我先在项目根目录建好了 CLAUDE.md，写明技术栈（Node.js + Express + SQLite，前端用 Vue 3），然后开始第一轮对话。
我在主代理里输入：
code复制请让 planner 分析这个需求：做一个图书管理后台。用户可以登录，登录后能看到图书列表，支持新增、编辑、删除图书，每本书包含书名、作者、ISBN、价格、封面图片。请输出完整的数据库设计、接口设计、页面划分和实施顺序。
主代理会调用 planner 子代理，产出一份任务规划。实际跑下来，planner 的输出通常包含：
- 数据模型设计：users 表、books 表，以及 cover 图片的存储方案（我这里是本地 uploads 目录）
- 接口清单：登录接口、获取图书列表接口、新增/编辑/删除接口、文件上传接口
- 页面划分：登录页、图书列表页、图书编辑弹窗
- 实施顺序：先搭后端骨架，再写数据库层，再写接口，再写前端页面，最后联调
这里的技巧是：给 planner 的输入信息越具体，它的输出就越可用。不要只说"做一个图书管理后台"，而是把你已知的技术栈、约束条件、甚至你偏好的一次性写清楚。
4.2 规划 Agent 产出架构方案的价值
你可能会觉得，让 AI 先写一份规划文档是浪费时间，直接写代码不香吗？我一开始也这么想，后来发现完全不是这么回事。
我的做法是：让主代理在收到 planner 的任务规划后，把这份规划放进项目根目录 docs/plan.md，然后后续所有 Agent 执行任务时都要求先读这个文件。这样做带来的最大好处是：所有子代理执行时对"要做什么、按什么顺序做"有统一认知，不会出现后端接口命名和前端页面各写各的、联调时对不上号的情况。
另外一个意外收获是：plan.md 变成了项目的活文档。中途我改变主意，想给图书加一个"出版年份"字段，直接改 plan.md，然后让主代理重新派活，整个项目都会一致更新，不会出现这个接口有年份、那个页面没年份的尴尬。
4.3 编码 Agent 分模块实现
规划出来后，我开始让编码 Agent 干活。我给 coder 定义的职责很纯粹：按 planner 的规划写代码，不擅自改设计。
我的调度方式是分阶段派活。第一阶段：
code复制请让 coder 按照 docs/plan.md 中的数据库设计和接口设计，完成后端部分的实现。完成后运行 npm test，确保接口测试通过。
coder Agent 会自动进入后端目录，按规划建表、写路由、写业务逻辑。这个阶段它主要跟文件系统打交道，不需要关心前端怎么渲染。第二阶段再派前端任务：
code复制请让 coder 按照 docs/plan.md 中的页面划分和接口定义，实现前端页面。接口地址以 /api 开头，联调时注意跨域配置。
前后端分开派活的好处是：每个 Agent 的上下文里只需要装下自己那部分信息，不会因为同时处理前后端而出现上下文爆炸。实际跑下来，coder 完成一个模块代码大约需要 3-8 轮对话，中间偶尔会自己发现问题并修复，整体还是很省心的。
4.4 审查 Agent 质量把关：堵住 AI 写代码的常见漏洞
这是我最喜欢的一个环节。AI 写代码很快，但也会写出一些"看起来没问题、实际埋雷"的代码。我让 reviewer 承担代码审查的角色，专门盯着几个高频问题：安全性（SQL 注入、越权访问）、健壮性（参数没校验、错误没捕获）、一致性（命名风格、字段名）。
我的指令是这样的：
code复制请让 reviewer 审查 /server 目录的代码。重点检查：
1. 登录接口是否校验了密码
2. 图书增删改接口是否有越权风险
3. 文件上传是否做了类型限制
4. 是否有明显的逻辑错误
输出审查报告，标注问题等级（严重/一般/建议）和修改建议。
reviewer 跑出来的报告往往能抓到几个真实问题。有一次它发现文件上传接口没限制文件类型，用户理论上可以上传任意文件，这属于严重漏洞。让它直接改掉之后再跑一轮测试，比我自己一行行 review 高效得多。
这里要说明一点：reviewer 能帮你堵住大部分常见问题，但它不是万能的。它不会真的去测复杂业务逻辑，也不会发现"需求本来就不合理"这种问题。所以最后我自己还是会过一遍关键代码，但整体 review 时间大大缩短了。
4.5 我踩过的协作坑：上下文隔离与文件冲突
多 Agent 协作不是银弹，我自己踩过两个很深的坑，写出来希望大家避开。
第一个坑是子代理拿到不完整上下文就乱干活。有一次我直接把一个 bug 的描述丢给 coder 去修，结果它压根没看项目里已有的代码，自己新写了一个模块，造成重复实现。从那以后，我给所有 Agent 下的任务指令里都加了硬性要求："动手前先读 CLAUDE.md 和 docs/plan.md，了解上下文"。这个要求写在 agents 目录角色的描述里更保险。
第二个坑是并行任务的文件冲突。Claude Code 支持并行执行多个 Task，我有一回让两个 Agent 同时改不同模块，结果它们同时改了共用的工具函数文件，后写的人把先写的人的部分逻辑覆盖了。现在我的原则是：共用的底层文件，串行改；彼此独立的模块，才并行。尤其是 schema、工具函数、公共组件这类改动，能串行就别并行，省得回头花更多时间解决冲突。
5. 集成与扩展：让 Agent 团队会用你的代码库
Agent 团队跑通之后，你会发现它的能力上限取决于"它能接触到哪些工具和上下文"。这一节讲怎么给团队加装备：Skills 技能库、MCP 外部数据连接，以及和本地模型、IDE 的集成。
5.1 Skills：给 Agent 添加可复用的团队技能
Skills 可以理解成给 Agent 准备的"操作手册"。和 agents 目录定义角色不同，skills 定义的是"怎么做某件事"的流程。用大白话说，agents 决定谁干活，skills 决定怎么把活干好。
一个 Skill 放在 .claude/skills/<技能名>/SKILL.md 里，结构是：
markdown复制---
name: frontend-component
description: 创建符合项目规范的 Vue 组件
---
1. 组件使用 `<script setup>` 语法
2. 样式使用 scoped
3. 组件 props 需要校验类型
4. 文件放在 /src/components 目录下
当编码 Agent 需要新建一个组件时，主代理会搜索匹配的 skill，读里面的操作流程来约束行为。这相当于把你的编码规范、最佳实践沉淀成了 AI 能读的文档。
官方有很多第三方 skill 可以下载，比如生成 PPT、做数据库迁移、写 Git commit message 等等。有意思的是，我见过有人专门做了个 GitHub 仓库收集各种 Claude Code skills，里面有个生成 PPT 大纲的 skill，效果挺惊艳。你自己也可以把自己平时做某类任务的固定流程写成 skill，一劳永逸。
5.2 MCP：让 Agent 直接读数据库
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 推出的开放标准，简单理解就是给 AI 接外部数据源的"USB 接口"。装一个 MCP 服务器，Agent 就能直接查数据库、调外部 API、操作浏览器，而不只是读文件、执行命令。
我最常用的场景是让 Agent 直接连数据库查数据。配置一个 SQLite MCP 服务：
bash复制claude mcp add mydb -- npx -y @modelcontextprotocol/server-sqlite --db-path ./data.db
配置之后，Agent 就能通过 MCP 工具直接执行 SQL 查询。比如我让它排查"为什么某个接口返回的数据不对"，它可以自己去数据库里查记录，而不是先让我导出数据、再把数据贴到对话里。排查效率提升非常明显。
不过需要提醒一句：给 Agent 数据库读权限很香，但也要设好边界。尤其是生产数据库，尽量只提供只读账号，防止 Agent 执行意外的写操作。我在本地开发环境随便用，接生产环境一定只读。
5.3 接入 DeepSeek / Ollama 本地模型：cc switch 的玩法
有人问过我不买 Claude 订阅，能不能用 Claude Code 接其他模型。答案是能，但要看具体模型。社区里大家都用 CC Switch 这个工具来管理和切换。
它本质上是个图形化的配置管理器，方便你在多套 Anthropic 兼容 API 配置之间切换。比如我经常在三个配置之间切换：
- Anthropic 官方 API（主力，质量最高）
- DeepSeek（省钱，处理简单任务）
- 本地 Ollama（完全离线，但能力弱，只用来跑小脚本）
DeepSeek 提供了 Anthropic 兼容的接口，接入方式直接设置环境变量：
bash复制export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=sk-你的key
export ANTHROPIC_MODEL=deepseek-chat
设置完运行 claude，它会向 DeepSeek 发请求。这个方案的优势是成本极低，适合大批量的简单任务。
Ollama 本地模型稍微麻烦一些，因为 Ollama 默认接口不是 Anthropic 格式，一般需要一个转换层，再配置到 CC Switch 里。我自己在 MacBook Air 上跑过 7B 量级的模型，写点简单脚本、帮忙看看报错还行；让它完整实现一个功能模块，质量和速度都不太够。所以我的定位是：本地模型当"备胎"，适合没网或隐私要求高的场景，主力还是云端模型。
5.4 终端里的团队工作流与 VS Code 的顺滑配合
虽然 Claude Code 本质是终端工具，但配合 VS Code 使用体验会舒服很多。官方提供了 "Claude Code for VS Code" 扩展，装好后在左侧边栏能看到聊天面板，选中的代码可以直接扔给 AI，AI 的修改也能直接在编辑器里对比。
我在实际使用中最常用的组合拳是：
- 在 VS Code 里选中一个函数或文件
- 通过面板让 coder Agent 写实现或修 bug
- 完成后用 Diff 视图逐行检查改动
不过要回归一下：某个 Editor 里直接看 AI 改动，总忍不住挑剔它，容易陷入"自己动手改更快"的陷阱。我的建议是，对不重要的代码尽量信任 Agent，把精力留给架构层面；对关键的登录鉴权、支付之类的代码，再自己 review 一遍。
如果你用的是 IDEA，目前官方的集成重心在 VS Code 生态，IDEA 上没有同等的官方插件。但 IDEA 内置终端完全支持 Claude Code，无非是没有侧边栏图形界面。我的习惯是 IDEA 里开一个终端 Tab 跑 Claude Code，遇到要改代码再让 AI 自己改文件，不冲突。
5.5 Windows 下的乱码问题与修复
用 Windows 跑 Claude Code 的朋友，大概率遇到过输出中文乱码。这个问题的根源是 Windows 终端默认编码经常是 GBK，而 Claude Code 的输出是 UTF-8。
解决方法很简单：在终端里先执行 chcp 65001，把代码页切到 UTF-8，再运行 claude。另外强烈建议用 Windows Terminal 而不是老的 conhost，前者对 UTF-8 的支持好得多，乱码概率大幅降低。如果还有问题，检查一下终端的字体设置，尽量用中文字体。
6. token 成本控制：多 Agent 协作的省钱打法
Agent Team 模式确实好用，但如果不懂控制成本，账单也会让你肉疼。这一节聊聊我自己的省钱策略，按"最省钱但最麻烦"到"花钱买效率"的顺序说。
6.1 按角色分配模型，拒绝所有任务都用最强模型
这是性价比最高的一招。Claude Code 的 agents 目录里有个 model 字段，可以让不同角色用不同模型。比如我的团队配置：
| 角色 | 模型 | 理由 |
|---|---|---|
| planner | claude-sonnet-4-5 | 规划需要较强推理能力，但不要求最强 |
| coder | claude-sonnet-4-5 | 编码主力，平衡质量与成本 |
| reviewer | claude-opus-sonnet（按需） | 审查关键代码时用最强模型，平时可降级 |
| 简单脚本处理 | claude-haiku 类小模型 | 跑个正则、格式化代码，完全够用 |
这样分配的思路是：高价值任务用好模型，重复机械任务用便宜模型。尤其注意，不要一股脑把"让 AI 读几十个文件再总结"这类任务丢给最强模型，它强在推理，不在读文件。
6.2 会话管理与上下文压缩：别让成本翻倍
token 消耗的大头往往不是输入指令，而是累积的上下文。Claude Code 会把你和 AI 的对话都算进 token 预算，对话越长，每发一条新消息要背负的上下文 token 就越多。很多人感觉"越聊越贵"，就是这个原因。
几个实用操作：
- 任务切换时用
/clear开启新会话，什么任务就让它专注什么，别一个会话干到底。 - 对话变得臃肿时用
/compact压缩历史，让 AI 精简重述关键信息。 - 用
claude --resume恢复旧会话时，挑真正需要的会话，不要每次为了一个窄问题把很长的工作记录全搭进去。 - 多 Agent 协作时，子代理完成的阶段性结果建议让主代理总结成摘要再提交，而不是整个完整输出都保留在对话里。
6.3 活用缓存机制与增量操作
Claude 的 API 有一个缓存机制，重复向模型发送相同的前缀内容时，缓存命中的部分价格会便宜很多。这意味着：你在会话中反复让 AI 阅读同一份 plan.md、CLAUDE.md，系统可能会对相同前缀启用缓存，这部分 token 的成本会降低。
基于这个机制，我的经验是：尽量保持项目上下文稳定。比如让所有子代理都先去读同一个 CLAUDE.md 再干活，比每个 Agent 各写各的上下文要省钱得多。同理，一个会话里连续完成同一模块的多个小任务，比频繁开新会话、重新发一遍项目背景更省钱——因为前期的项目上下文可以被缓存复用。
另外，能用 claude -p "..." 单次非交互模式跑完的简单任务，就不要开交互模式反复拉扯。比如"帮我把这个 JSON 转成 CSV"，一条命令结束，零历史负担。
6.4 实测统计：一个 Demo 项目的 token 消耗参考
最后给一个我自己跑"图书管理后台"项目的实测数据，给大家一个量级参考。这个项目最终产出了：2 张数据表、6 个后端接口、3 个前端页面、1 个文件上传功能。完整流程走完，Agent 团队的实际 token 消耗大致如下：
| 阶段 | 输入 token | 输出 token | 说明 |
|---|---|---|---|
| 规划阶段 | 约 1.5 万 | 约 0.4 万 | planner 读项目上下文+产出计划 |
| 后端实现 | 约 8 万 | 约 2.5 万 | 多次读写文件、跑测试 |
| 前端实现 | 约 6 万 | 约 2 万 | 写组件、调样式 |
| 审查修复 | 约 3 万 | 约 0.8 万 | reviewer 读代码+修改 |
| 合计 | 约 18.5 万 | 约 5.7 万 | 总约 24 万 token |
如果全部用默认配置的强模型，大概要花几美元；如果一部分用便宜模型，能压到一美元上下。对比人工开发一个类似项目的时间成本，这个成本完全能接受。当然，如果项目规模大几十倍，token 消耗也会线性增长，控制成本的核心还是靠任务拆分和模型分层。
几点个人体会
从第一次尝试 Agent Team 到现在，我把这个模式用在了不少项目里，逐渐形成了一套自己的判断标准：什么项目适合让 Agent 团队来干，什么项目还是自己写更快。我的经验是：需求相对明确、技术栈常见、模块边界清晰的项目，非常适合 Agent Team；而还在探索期、需求含糊、架构频繁变动的项目，让 AI 团队上场往往会返工，因为大部分 token 都花在了"推翻重来"上。
我最近用下来最顺手的场景是：把 Agent 团队当"高配实习生"用。planner 是那个帮你想方案、列清单的人，coder 是那个照着清单写代码、偶尔犯点小错但效率极高的人，reviewer 是那个帮你查漏补缺、挑毛病的人。你依然是项目的负责人，负责定方向、做决策、管结果，只是不再需要一个人把所有代码敲完。调整好心态、管理好上下文，这套用法能帮你省下大量时间。