智能体团队快速入门

在项目中使用智能体团队的实战指南阅读时间：8-10 分钟 | 完整文档：「智能体团队」（30 分钟总览）

这是什么？

你知道智能体团队的存在，也读过了理论。但在你的项目中，什么时候才应该真正使用它们？

本指南为你提供：

✅ 5 分钟配置（环境准备 → 第一次测试）
✅ 4 个可复制使用的模式，适用于真实项目（指南 + RTK）
✅ 决策矩阵（何时用，何时不用）
✅ 指标，用于衡量 ROI
✅ 红色警报，避免浪费

跳过本页如果：你想了解理论 → 请阅读「智能体团队完整文档」。

1. 5 分钟配置

步骤 1：前置条件检查

Bash

# 检查 Claude Code 版本（需要 v2.1.32+）
claude --version

# 检查模型可用性
claude
> /model opus
# 应显示："Model changed to opus (claude-opus-4-6-20250624)"

最低要求：

Claude Code v2.1.32+
Opus 4.6 模型
Git 仓库（智能体团队使用 git 进行协调）

步骤 2：启用功能

Bash

# 设置环境变量（添加到 ~/.bashrc 或 ~/.zshrc 以持久化）
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

# 启动 Claude Code
claude

步骤 3：验证

Plain

> 智能体团队是否已启用？

预期响应：

Plain

是的，智能体团队在本次会话中已启用。我可以使用以下功能创建智能体团队，并行处理复杂任务：
- 多智能体协调
- 基于 Git 的任务认领
- 自主团队协调

若未启用：检查环境变量是否已设置（echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS）。

步骤 4：第一次测试（2 个智能体）

Plain

> 创建一个简单的测试团队来分析这份 README：
> - 智能体 1：检查结构（章节、目录、徽章）
> - 智能体 2：检查内容质量（清晰度、示例、完整性）

将会发生什么：

Claude 生成 2 个智能体（你会看到"正在创建团队…"的消息）
智能体并行工作（你可能看到"Idle"消息——这是正常现象）
Claude 呈现综合发现（汇聚点 + 各智能体独特见解）

导航：

Shift+Down：在团队成员输出间循环切换（进程内模式）
主视图：综合汇总

时长：简单的 2 智能体任务约 1-2 分钟。

2. 适合你项目的模式

2.1 Claude Code 指南 - 发布前审查

用途：版本发布前的系统性审计，捕获一致性问题（链接失效、计数不同步、版本号错误）

触发时机：每次执行 /release 命令前

时长：3-5 分钟

团队组成：

Plain

团队：pre-release-audit（3 个智能体）
├─ accuracy-auditor → 验证声明、统计数据、版本号、外部链接
├─ consistency-checker → 检查模板数量、评估数量、指南行数在各文件间是否一致
└─ breaking-checker → 识别与上一个发布版本相比的破坏性变更

可复制提示：

Plain

> 创建一个发布前审计团队：
> - 准确性：检查 CHANGELOG.md、README.md 和 guide/ultimate-guide.md 中的所有声明、统计数据、版本号、外部链接
> - 一致性：验证模板数量（统计 examples/ 文件）、评估数量（统计 docs/resource-evaluations/ 文件）、指南行数（wc -l guide/ultimate-guide.md）在 README.md、guide/cheatsheet.md、machine-readable/reference.yaml 中是否一致
> - 破坏性变更：通过分析 CHANGELOG.md 的 [Unreleased] 部分，识别与 v3.23.0 相比的破坏性变更

ROI：能捕获以下类型的 bug：

LinkedIn URL 损坏（今天的真实审计中已捕获）
指南/落地页之间的不同步（模板数量）
多个文件中的错误版本号
失效的外部链接

何时跳过：简单的错别字修复（无版本号/计数/链接变更）。

真实示例（2026-02-08 的测试）：

Plain

发现：
- 准确性：1 个关键（LinkedIn URL 格式错误），3 个警告（外部链接待验证）
- 一致性：2 个关键（README 与落地页模板数量不匹配，reference.yaml 中的行号过时）
- 破坏性变更：相比 v3.23.0 未检测到破坏性变更（干净发布）

汇聚点：2 个智能体标记了模板数量问题（高置信度）
时长：4 分 12 秒
结论：✅ 高价值，发现了 3 个本会发布出去的关键问题

2.2 Claude Code 指南 - 落地页同步

用途：验证指南/落地页同步（版本、计数、内容），无需手动运行脚本

触发时机：重大指南修改后（版本升级、模板添加、FAQ 变更）

时长：2-3 分钟

团队组成：

Plain

团队：landing-sync（2 个智能体）
├─ guide-scanner → 提取版本号、模板数量、评估数量、指南行数、FAQ 内容
└─ landing-scanner → 与 index.html、examples.html 对比，检查同步状态

可复制提示：

Plain

> 验证指南/落地页同步：
> - 指南扫描器：从 VERSION 文件提取版本号，模板数量（find examples/ -type f | wc -l），评估数量（find docs/resource-evaluations/ -name "*.md" | wc -l），指南行数（wc -l guide/ultimate-guide.md），README.md 中的 FAQ 条目
> - 落地页扫描器：检查 <local-path> 和 examples.html 中的版本（页脚+FAQ）、徽章中的模板数量、评估数量、指南行数近似值（~9800+）
>
> 报告：已同步 ✅ / 带行号的不匹配项

ROI：

零不同步内容发布到生产环境
避免手动执行 ./scripts/check-landing-sync.sh
比脚本更快（2 分钟 vs 运行脚本 + 修复的 5 分钟）

何时跳过：纯代码修改（不影响文档/计数）。

成功标准：

Plain

✅ 全部同步：版本号、模板数量、评估数量匹配
⚠️ 不匹配：index.html 中需要修复的具体行号

2.3 Claude Code 指南 - 多文件文档更新

用途：跨多个文件（ultimate-guide.md、reference.yaml、README.md）添加新功能文档，保持交叉引用一致性

触发时机：新功能章节（>50 行）、破坏性变更、架构更新

时长：5-8 分钟

团队组成：

Plain

团队：doc-update（3 个智能体）
├─ content-writer → 在 ultimate-guide.md 中撰写含示例的主要章节
├─ index-updater → 更新目录、reference.yaml 条目、README 导航
└─ consistency-checker → 验证交叉引用、行号、锚点可用性

可复制提示：

Plain

> 为新功能"[功能名称]"更新文档：
> - 内容范围：在 guide/ultimate-guide.md 的 [X.Y] 章节中写入：
>   - 概述（是什么/为什么/何时使用）
>   - 2-3 个具体示例
>   - 最佳实践 + 注意事项
>   - 相关章节的链接
>   上下文：仅限 guide/ultimate-guide.md 的 [X.Y] 章节
> - 索引范围：更新：
>   - guide/ultimate-guide.md 目录（添加 [X.Y] 章节）
>   - machine-readable/reference.yaml（添加含行号的条目）
>   - README.md 导航（如果是主要功能，添加链接）
>   上下文：仅限索引文件（目录、reference.yaml、README.md）
> - 一致性范围：验证：
>   - 所有交叉引用均可正确解析
>   - reference.yaml 中的行号与实际内容匹配
>   - README 中的锚点指向正确章节
>   - 无失效的内部链接
>   上下文：所有已修改文件的交叉引用验证

ROI：

零失效链接（consistency-checker 全部捕获）
比顺序执行快 60%（撰写 → 索引 → 验证）
并行工作减少等待时间

何时跳过：单文件编辑（<50 行）、无需交叉引用。

真实示例（添加智能体团队章节）：

Plain

任务：添加"智能体团队"为第 9.20 节（300 行）
涉及文件：3 个（ultimate-guide.md、reference.yaml、README.md）

顺序估算：12-15 分钟（撰写 → 索引 → 验证）
智能体团队：7 分 30 秒（3 个智能体并行）
节省：40% 时间 + 零手动交叉引用检查

2.4 RTK - 安全 PR 审查

用途：审查外部贡献者 PR 的安全问题（注入、令牌泄露）、Rust 惯用法和性能

触发时机：非核心贡献者提交 PR 时，PR 涉及敏感代码（认证、外部命令、正则表达式）

时长：5-8 分钟

团队组成：

Plain

团队：security-pr-review（3 个智能体）
├─ rust-expert → 检查所有权模式、错误处理（anyhow/thiserror）、惯用代码
├─ security-auditor → 扫描注入风险、令牌泄露、输入清洗
└─ perf-analyzer → 审查内存分配、异步模式、编译正则表达式

可复制提示：

Plain

> 对 PR #[编号] 进行范围聚焦分析：
> - Rust 范围：检查：
>   - 所有权模式（优先使用 &str 而非 String，减少克隆）
>   - 错误处理（带 .context() 的 anyhow::Result，测试外不用 unwrap）
>   - 惯用代码（impl 跟在类型后，#[cfg(test)] mod tests）
>   - Clippy 合规性（零警告）
>   上下文：所有已修改的 .rs 文件
> - 安全范围：扫描：
>   - 命令注入（Shell 转义、参数清洗）
>   - 令牌/凭据泄露（硬编码密钥、日志、错误消息）
>   - 输入清洗（路径遍历、正则 DoS）
>   - 文件操作（路径验证、权限）
>   上下文：输入处理、认证、文件 I/O 代码
> - 性能范围：审查：
>   - 不必要的内存分配（String::from vs &str）
>   - 异步模式（CPU 密集型工作用 spawn_blocking）
>   - 编译正则表达式（热路径用 lazy_static!）
>   - 算法复杂度（O(n) vs O(n²)）
>   上下文：热路径、循环、异步函数

ROI：

盲点检测：安全 + Rust + 性能 = 单独审查者会遗漏的区域
一致的审查质量（不依赖审查者的状态/专注度）
比顺序审查更快（3 个智能体并行 vs 3 轮审查）

何时跳过：受信任贡献者的内部 PR、微小变更（仅文档、注释、测试）。

成功标准：

Plain

✅ 汇聚点：2+ 个智能体标记同一关键问题（高置信度）
✅ 独特见解：每个智能体发现领域特定问题（Rust/安全/性能）
❌ 误报率：<20% 的发现是无效的

真实示例（假设的外部 PR）：

Plain

PR：添加新的 git 过滤命令
智能体发现：
- Rust：3 个问题（生产代码中有 unwrap、缺少 .context()、非惯用错误处理）
- 安全：2 个关键（通过用户输入的 Shell 注入、错误消息中的令牌泄露）
- 性能：1 个问题（每次调用时编译正则，而非 lazy_static）

汇聚点：安全 + Rust 都标记了缺少输入清洗（高置信度）
时长：6 分 40 秒
结论：✅ 关键安全问题已捕获，PR 需要修改

3. 决策矩阵：何时使用

情况	智能体团队？	原因
发布前审查（指南）	✅ 是	多层审计（准确性 + 一致性 + 破坏性变更）需要并行视角
简单错别字修复	❌ 否	杀鸡用牛刀，1 个智能体 10 秒，3 个智能体 = 成本浪费
外部 PR（RTK）	✅ 是	安全 + Rust + 性能 = 盲点检测，高风险审查
多文件文档更新（指南）	✅ 是	内容 + 索引 + 一致性 = 零失效链接，并行工作
落地页同步检查	⚠️ 可能	若怀疑不同步用智能体团队，否则 `./scripts/check-landing-sync.sh` 更快
CHANGELOG 更新	❌ 否	顺序任务（线性写作），无并行化收益
单文件编辑（RTK）	❌ 否	无需协调，顺序处理即可
小型 README 调整（<50 行）	❌ 否	无交叉引用，无复杂性，单智能体更快
架构设计	✅ 是	多视角（前端、后端、基础设施、安全）揭示盲点
Bug 调查	⚠️ 可能	简单 bug → 否，复杂多组件故障 → 是

经验法则

使用智能体团队的情况：

✅ 你自然会想到"我应该同时检查 X、Y 和 Z"
✅ 高风险（生产发布、外部贡献者、安全敏感）
✅ 需要多范围分析（Rust 范围 + 安全范围 + 性能范围）
✅ 跨文件一致性很重要（链接、计数、版本同步）
✅ 可以并行工作（独立任务，无顺序依赖）

不使用智能体团队的情况：

❌ 简单任务（<5 个文件，<100 行，1 个领域）
❌ 顺序工作流（步骤 B 依赖步骤 A 的结果）
❌ 预算紧张（3 倍 Token 消耗，留给高价值任务）
❌ 写入密集型（对同一文件大量编辑 = 合并冲突）

4. 最简工作流模板

Bash 模板（可复用）

Bash

# 1. 配置（每次会话一次）
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

# 2. 启动 Claude
claude

# 3. 创建团队（提示模板）
> 创建一个团队来完成 [任务]：
> - 智能体 1（[范围/上下文]）：[具体任务]
> - 智能体 2（[范围/上下文]）：[具体任务]
> - 智能体 3（[范围/上下文]）：[具体任务]
>
> [要分析的文件/目录]

# 4. 观察（可选）
# Shift+Down 在团队成员输出间切换（进程内模式）

# 5. 综合汇总
# Claude 自动呈现综合发现

# 6. 行动
# 修复关键发现，跳过次要发现

示例提示（可直接复制）

发布前指南审计

Plain

> 创建一个发布前审计团队：
> - 准确性：检查 CHANGELOG.md、README.md 和 guide/ultimate-guide.md 中的所有声明、统计数据、版本号、外部链接
> - 一致性：验证模板数量（统计 examples/ 文件）、评估数量（统计 docs/resource-evaluations/ 文件）、指南行数（wc -l guide/ultimate-guide.md）在 README.md、guide/cheatsheet.md、machine-readable/reference.yaml 中是否一致
> - 破坏性变更：通过分析 CHANGELOG.md 的 [Unreleased] 部分，识别与 v3.23.0 相比的破坏性变更

安全 PR 审查（RTK）

Plain

> 对 PR #42 进行范围聚焦分析：
> - Rust 范围：检查所有权模式、错误处理（anyhow/thiserror）、已修改文件中的惯用代码（上下文：src/**/*.rs）
> - 安全范围：扫描注入风险、令牌泄露、输入清洗（上下文：认证、输入处理代码）
> - 性能范围：审查内存分配、异步模式、编译正则表达式（上下文：热路径、循环）

多文件文档更新

Plain

> 为新功能"智能体团队快速入门"更新文档：
> - 内容范围：撰写 guide/workflows/agent-teams-quick-start.md，包含概述、4 个模式、决策矩阵、指标
> - 索引范围：更新 guide/ultimate-guide.md（添加 9.20 节参考）、machine-readable/reference.yaml（添加条目）、CHANGELOG.md（添加"Added"条目）
> - 一致性范围：验证所有交叉引用可用、行号匹配、无失效链接（上下文：所有已修改文件）

落地页同步验证

Plain

> 验证指南/落地页同步：
> - 指南扫描器：从 VERSION 文件提取版本号，模板数量（find examples/ -type f | wc -l），评估数量（find docs/resource-evaluations/ -name "*.md" | wc -l），指南行数（wc -l guide/ultimate-guide.md）
> - 落地页扫描器：检查 <local-path> 和 examples.html 中的版本、计数、指南行数近似值

5. 成功指标

如何衡量智能体团队的 ROI

指标	目标	如何衡量
汇聚率	>50%	统计被 2+ 个智能体标记的发现 / 总发现数。高汇聚率 = 高置信度。
独特见解	每个智能体 ≥1 个	每个智能体必须在其领域内找到至少 1 个独特问题。若智能体发现 0 个独特问题 = Token 浪费。
误报率	<20%	统计无效发现 / 总发现数。误报过多 = 提示词质量差。
时间节省	60-70%	对比智能体团队耗时 vs 顺序执行耗时（估算 3 个任务 × 单智能体时间）。
Bug 捕获率	>80%	统计智能体发现的关键 bug / 发布后发现的总 bug 数。高比率 = 有效预防。

真实示例：发布前审查测试（2026-02-08）

Plain

任务：v3.23.1 发布前审计
智能体：3 个（accuracy-auditor、consistency-checker、breaking-checker）
时长：4 分 12 秒

原始发现：共 45 条
├─ 准确性：12 条（1 个关键：LinkedIn URL 格式错误，11 个警告）
├─ 一致性：18 条（2 个关键：模板数量不同步，行号过时）
└─ 破坏性变更：15 条（0 个破坏性变更，15 条信息说明）

去重后发现：约 30 个独特问题

汇聚分析：
├─ 高置信度（2-3 个智能体）：4 个问题
│   ├─ 模板数量不匹配（一致性 + 准确性）
│   ├─ 行号过时（一致性 + 准确性）
│   ├─ 外部链接需验证（准确性 + 破坏性变更）
│   └─ 文件间版本同步（3 个智能体全部标记）
└─ 独特见解：
    ├─ 准确性：LinkedIn URL 损坏（仅此智能体发现）
    ├─ 一致性：目录结构偏差（仅此智能体发现）
    └─ 破坏性变更：Changelog 格式改进建议（仅此智能体发现）

指标：
├─ 汇聚率：4/30 = 13%（低于目标，但关键发现均被多个智能体标记 = 置信度高）
├─ 独特见解：3/3 个智能体 = 100%（每个智能体在其领域内发现独特问题）
├─ 误报率：2/30 = 6.6%（低于 20% 目标 ✅）
├─ 时间节省：4 分钟 vs 顺序估算 12 分钟 = 节省 66% ✅
├─ Bug 捕获率：3 个关键 bug 在发布前被捕获 = 避免了生产问题 ✅

结论：✅ 对发布前审计高价值

如何追踪你的指标

每次智能体团队任务后：

统计发现：记录每个智能体的原始发现，然后去重
标记汇聚点：哪些问题被 2+ 个智能体标记了？
检查独特见解：每个智能体是否至少找到 1 个领域特定问题？
核实误报：有多少发现是无效/噪音？
时间对比：智能体团队耗时 vs 顺序估算耗时
发布后验证：智能体团队是否捕获了本会发布的 bug？

保留日志（项目文档中的 Markdown 表格）：

Markdown

| 日期 | 任务 | 智能体数 | 时长 | 发现数 | 汇聚率 | 独特见解 | 误报率 | 节省时间 | 捕获 Bug |
|------|------|--------|----------|----------|-------------|--------|--------|------------|-------------|
| 2026-02-08 | 发布前 v3.23.1 | 3 | 4m12s | 30 | 13%（4 个关键） | 3/3 | 6.6% | 66% | 3 |

指标不达标时调整提示：

低汇聚率（<30%）→ 范围过窄，扩大上下文边界重叠
无独特见解 → 范围过于相似，多样化分析角度
误报率高（>20%）→ 提示词过于模糊，添加具体标准

6. 局限与红色警报

智能体团队不会做的事情

局限	含义	缓解措施
3 倍 Token	每个智能体 = 独立模型调用 = 3 倍成本	留给高价值任务（发布前、安全 PR，而非错别字修复）
Idle 消息刷屏	智能体在协调期间显示"Idle"消息	正常行为，不是 bug，忽略这些消息
实验性	研究预览 = 稳定性无保证	预期会有 bug，不要依赖智能体团队处理生产关键工作流
协调开销	最多 3-5 个智能体，不是 10 个（协调复杂性增加）	坚持 2-4 个智能体，避免"10 人团队"提示
上下文隔离	智能体之间看不到彼此的发现（独立工作）	Claude 汇总发现，但智能体无法在任务中途基于对方的工作继续

红色警报：何时不要使用

❌ 简单任务（<5 个文件，<100 行，1 个领域）

示例：修复 README.md 中的错别字
为何避免：10 秒的任务消耗 3 倍 Token = 浪费

❌ 顺序工作流（步骤 B 依赖步骤 A 的结果）

示例：实现功能 → 编写测试 → 部署
为何避免：智能体并行工作，无法处理依赖关系

❌ 预算紧张（3 倍 Token，需要优化成本）

示例：有限 API 额度的个人项目
为何避免：智能体团队是高价值任务的奢侈选项，不是日常工作流

❌ 写入密集型（对同一文件大量编辑）

示例：重构整个代码库结构
为何避免：合并冲突、协调开销、智能体互相干扰

❌ 低风险审查（内部 PR、受信任贡献者、简单变更）

示例：团队成员修复小 bug
为何避免：杀鸡用牛刀，单智能体审查更快且更便宜

何时应该使用（即使有成本）

✅ 高风险（生产发布、安全敏感、外部贡献者）✅ 多领域（Rust + 安全 + 性能 = 盲点检测）✅ 并行友好（独立任务，无顺序依赖）✅ 一致性关键（跨文件同步、计数、版本）✅ 学习机会（理解盲点，改进提示）

总结：快速参考

配置（一次性 5 分钟）

Bash

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude
> 智能体团队是否已启用？  # 验证

何时使用（决策规则）

用：

高风险 + 多领域 + 并行友好

不用：

简单任务 + 顺序工作流 + 预算紧张

模式（4 个可直接使用的）

发布前审查（指南）→ 准确性 + 一致性 + 破坏性变更
落地页同步（指南）→ 指南扫描器 + 落地页扫描器
多文件文档更新（指南）→ 内容 + 索引 + 一致性
安全 PR 审查（RTK）→ Rust + 安全 + 性能

指标（追踪 ROI）

汇聚率：>50%（被 2+ 个智能体标记的发现）
独特见解：每个智能体 ≥1 个
误报率：<20%
时间节省：60-70%
Bug 捕获率：>80%

红色警报（避免浪费）

❌ 简单任务（<5 个文件）
❌ 顺序工作流
❌ 预算紧张
❌ 写入密集型（合并冲突）

下一步

尝试第一次测试（5 分钟配置 + 简单 2 智能体任务）
选择 1 个模式，适用于你的项目（指南或 RTK）
衡量指标（汇聚率、独特见解、节省时间）
根据结果调整提示
阅读完整文档了解高级模式：「智能体团队」

有问题？ 查阅「完整文档」了解：

架构深入解析（git 协调的工作原理）
高级用例（15+ 个生产场景）
故障排查（常见问题 + 解决方案）
最佳实践（团队规模、提示设计、冲突解决）

来源：飞书 · AI Spark 知识库｜原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/AiEYwefmBiwQeskGBBfcRt2hneg ｜归档：2026-06-04

自媒体人 AI 入门路径：从选题到复盘的完整工作流

Claude Code 深度全解

底层原理精讲

可视化图解

零到精通：七步上手路径

企业级安全与治理

生态与工具链全景

实战工作流手册

智能体团队快速入门 ​

这是什么？ ​

目录 ​

1. 5 分钟配置 ​

步骤 1：前置条件检查 ​

步骤 2：启用功能 ​

步骤 3：验证 ​

步骤 4：第一次测试（2 个智能体） ​

2. 适合你项目的模式 ​

2.1 Claude Code 指南 - 发布前审查 ​

2.2 Claude Code 指南 - 落地页同步 ​

2.3 Claude Code 指南 - 多文件文档更新 ​

2.4 RTK - 安全 PR 审查 ​

3. 决策矩阵：何时使用 ​

经验法则 ​

4. 最简工作流模板 ​

Bash 模板（可复用） ​

示例提示（可直接复制） ​

发布前指南审计 ​

安全 PR 审查（RTK） ​

多文件文档更新 ​

落地页同步验证 ​

5. 成功指标 ​

如何衡量智能体团队的 ROI ​

真实示例：发布前审查测试（2026-02-08） ​

如何追踪你的指标 ​

6. 局限与红色警报 ​

智能体团队不会做的事情 ​

红色警报：何时不要使用 ​

何时应该使用（即使有成本） ​

总结：快速参考 ​

配置（一次性 5 分钟） ​

何时使用（决策规则） ​

模式（4 个可直接使用的） ​

指标（追踪 ROI） ​

红色警报（避免浪费） ​

下一步 ​

智能体团队快速入门

这是什么？

目录

1. 5 分钟配置

步骤 1：前置条件检查

步骤 2：启用功能

步骤 3：验证

步骤 4：第一次测试（2 个智能体）

2. 适合你项目的模式

2.1 Claude Code 指南 - 发布前审查

2.2 Claude Code 指南 - 落地页同步

2.3 Claude Code 指南 - 多文件文档更新

2.4 RTK - 安全 PR 审查

3. 决策矩阵：何时使用

经验法则

4. 最简工作流模板

Bash 模板（可复用）

示例提示（可直接复制）

发布前指南审计

安全 PR 审查（RTK）

多文件文档更新

落地页同步验证

5. 成功指标

如何衡量智能体团队的 ROI

真实示例：发布前审查测试（2026-02-08）

如何追踪你的指标

6. 局限与红色警报

智能体团队不会做的事情

红色警报：何时不要使用

何时应该使用（即使有成本）

总结：快速参考

配置（一次性 5 分钟）

何时使用（决策规则）

模式（4 个可直接使用的）

指标（追踪 ROI）

红色警报（避免浪费）

下一步