用途
Analyse Team Session 用于分析一份 agent 团队会话导出，对照官方 Claude Code agent 团队最佳实践进行评估，产出一份结构化报告，包含适配性结论、评分卡、可执行建议以及改进后的提示词重写。
其核心原则为：每条建议都必须引用官方文档中的一项具体最佳实践，并引用会话中的具体证据，不做模糊评估。
适用场景
- 用户提供了团队会话导出并希望获得反馈
- 用户询问如何改进其 agent 团队的使用方式
- 用户想知道某项任务是否适合使用 agent 团队
- 在运行 agent 团队之后，用于识别下次应做哪些不同调整
不适用场景：
- 分析单独（非团队）的 Claude Code 会话
- 与 agent 团队无关的一般性 Claude Code 使用建议
使用方式
步骤 1：读取会话导出
读取完整的 markdown 会话导出文件。如果文件过大，则分块读取。
提取以下要素：
- 团队名称与会话 ID
- 时长与 agent 列表
- 原始用户提示词——启动团队的首次用户消息
- 团队结构——lead 与 teammates、其角色、所用模型
- 任务列表——创建、分配、完成的任务（查找 TaskCreate/TaskUpdate 调用）
- 沟通流向——teammates 之间的私信（SendMessage 调用）、广播
- 工具调用——每个 agent 做了什么（读取、编辑、网络抓取等）
- 最终输出——lead 最终产出的结果
步骤 2：获取官方文档
使用 WebFetch 获取最新的 agent 团队最佳实践：
- https://code.claude.com/docs/en/agent-teams —— 最佳实践、何时使用、架构、限制
- https://code.claude.com/docs/en/costs —— “Agent team token costs”与“Manage agent team costs”章节
这些是所有评分标准的权威来源。如果 WebFetch 失败，告知用户缺少官方文档则无法继续分析。
步骤 3：对照评分标准进行评估
应用以下 8 个类别。对每一类：
- 评级：Gap（未遵循）、Partial（有尝试但不完整）或 Strong（执行良好）
- 引用证据：引用会话导出中的具体段落
- 说明：引用官方文档中的具体最佳实践
- 适配性
该任务是否适合 agent 团队？对照官方“何时使用 agent 团队”的标准：
- 是否涉及能带来真实价值的并行探索？
- agent 之间是否需要互相沟通，而不只是向 lead 汇报？
- 是否符合强用例（研究/评审、新模块、竞争性假设、跨层协调）？
- 或是否符合反模式（顺序任务、同一文件编辑、重度依赖）？
如果该任务使用 subagents 或单会话会更好，请直接说明并解释原因。
- 上下文共享
Teammates 在其 spawn 提示词中是否获得足够的上下文？文档要求“在 spawn 提示词中包含任务特定细节”，因为 teammates 不会继承 lead 的对话历史。
Spawn 提示词是否明确说明要做什么、去哪里看、以何格式汇报？
还是过于含糊，迫使 teammates 花费轮次自行摸索？
- 任务规模
任务范围是否恰当？文档定义了三个桶：
- 太小：协调开销超过收益
- 太大：teammates 长时间工作而缺乏检查点，增加浪费精力的风险
- 恰到好处：自包含单元，产出清晰交付物
文档建议每名 teammate 5-6 个任务，以保持生产力，并让 lead 在某位队友卡住时可重新分配工作。
- 沟通质量
Teammates 的沟通方式是否带来价值？这是与 subagents 的核心区别。
- teammates 是否彼此分享了发现？
- 是否有 teammate 质疑或建立在另一方发现之上？
- 是否存在真正的交叉传播，还是各自孤立工作？
如果 teammates 从未互相发消息，该任务本可以使用 subagents——需标记此点。
- 文件冲突规避
任务结构是否避免多名 teammates 编辑同一文件？文档警告两名 teammates 编辑同一文件会导致覆盖。
如果这是无文件编辑的评审/研究任务，标记为 N/A 并说明原因。
- Lead 编排
Lead 是否有效委派？文档警告 lead 有时会自行开始实现任务，而不是等待 teammates。
- Lead 是否创建任务、分配任务并等待结果？
- 还是自己开始干活？
- 是否将全部 teammates 的发现综合为连贯输出？
- 成本效率
成本是否得到恰当管理？文档建议：
- Teammates 使用 Sonnet（兼顾能力与成本）
- 保持团队规模小（token 使用量大致与团队规模成正比）
- 保持 spawn 提示词聚焦（提示词中的一切从一开始就计入上下文）
- 工作完成后清理团队（空闲 teammates 会持续消耗 token）
- 清理
团队是否正确关闭与清理？文档要求始终使用 lead 进行清理，并先通过 shutdown 请求关闭 teammates。
- teammates 是否被优雅关闭？
- lead 是否运行了团队清理？
- 还是会话结束时未做清理？
步骤 4：撰写分析报告
将报告保存至 .claude/output/<team-name>-analysis.md。可执行内容在前，详细证据在后。
使用以下结构：
# Agent Team Session Analysis: <team-name>
**Session:** <session-id> | **Team:** <team-name>
**Duration:** <duration> | **Agents:** <comma-separated list>
**Analysis date:** <today's date>
---
## Suitability Verdict
[1-2 段，评估该任务是否适合 agent 团队。
如果不适合，说明更合适的方法及原因。直接陈述。]
**Verdict:** Good fit / Marginal fit / Poor fit
---
## Summary
| Category | Rating |
|----------|--------|
| Suitability | [Strong/Partial/Gap] |
| Context Sharing | [Strong/Partial/Gap] |
| Task Sizing | [Strong/Partial/Gap] |
| Communication Quality | [Strong/Partial/Gap] |
| File Conflict Avoidance | [Strong/Partial/Gap/N/A] |
| Lead Orchestration | [Strong/Partial/Gap] |
| Cost Efficiency | [Strong/Partial/Gap] |
| Cleanup | [Strong/Partial/Gap] |
---
## Top Recommendations
[3-5 条按影响力排序的建议。每条必须具体、可执行，
并引用会话中发生的情况。]
1. **[Category]** - [建议，附具体修改示例]
2. ...
---
## Improved Prompt
如果原始提示词可按照所有最佳实践重写，
其大致样貌如下：
[重写用户原始提示词，纳入所有建议。
可直接复制粘贴用于下次运行。]
---
## Detailed Rubric Scorecard
### 1. Suitability - [Rating]
**Evidence:**
> [引用会话导出中的段落]
**Assessment:** [说明，引用文档中的具体最佳实践]
### 2. Context Sharing - [Rating]
**Evidence:**
> [引用段落]
**Assessment:** [说明]
[...继续全部 8 个类别...]
撰写报告后，告知用户报告保存位置，并用 2-3 句话总结关键发现。
质量检查清单
- 全部 8 个评分类别均附证据与文档引用
- 适配性结论直接且诚实（不含糊）
- 建议具体且可执行（而非“改善沟通”）
- 改进提示词是完整、可直接使用的重写版本
- 每项评级都引用会话导出中的具体段落
- 每项评估都引用官方文档中的具体最佳实践
- 报告保存至
.claude/output/<team-name>-analysis.md
常见陷阱
- 模糊评级：只说“Communication was Partial”而不引用实际消息（或缺失情况）。务必引用证据。
- 含糊结论：如果确实不适合 agent 团队，就直接说明。分析的意义在于诚实反馈，而非外交辞令。
- 泛泛建议：“改善任务规模”没有用处。“将单个评审任务拆分为 3 个聚焦子任务（语气、互动度、准确性），每个带 2-3 个检查点”才是可执行的。