mirror of
https://github.com/automazeio/ccpm.git
synced 2025-10-09 13:41:06 +03:00
50f3ec8644
- Add Chinese documentation links in README.md, COMMANDS.md, and AGENTS.md - Fix typo: 'mutiple' -> 'multiple' in README.md - Include new Chinese documentation files in doc/ directory 🤖 Generated with [Claude Code](https://claude.ai/code) Co-authored-by: Claude <noreply@anthropic.com>
3.7 KiB
3.7 KiB
代理
专门处理繁重工作的代理，返回简洁摘要以保留上下文。
核心理念
"不要将子代理拟人化。使用它们来组织你的提示并省略上下文。当子代理能够完成大量工作但只向主线程提供少量信息时效果最佳。"
– Adam Wolff, Anthropic
可用代理
🔍 code-analyzer
- 目的: 跨多个文件查找错误而不污染主线程上下文
- 模式: 搜索多个文件 → 分析代码 → 返回错误报告
- 用法: 当你需要追踪逻辑流、查找错误或验证更改时
- 返回: 仅包含关键发现的简洁错误报告
📄 file-analyzer
- 目的: 读取和总结详细文件(日志、输出、配置)
- 模式: 读取文件 → 提取见解 → 返回摘要
- 用法: 当你需要理解日志文件或分析详细输出时
- 返回: 关键发现和可操作的见解(减少80-90%的大小)
🧪 test-runner
- 目的: 执行测试而不将输出转储到主线程
- 模式: 运行测试 → 捕获到日志 → 分析结果 → 返回摘要
- 用法: 当你需要运行测试并理解失败原因时
- 返回: 包含失败分析的测试结果摘要
🔀 parallel-worker
- 目的: 协调处理问题的多个并行工作流
- 模式: 读取分析 → 生成子代理 → 整合结果 → 返回摘要
- 用法: 当在工作树中执行并行工作流时
- 返回: 所有并行工作的整合状态
为什么使用代理?
代理是保护主线程免受信息过载的上下文防火墙:
不使用代理:
主线程读取10个文件 → 上下文爆炸 → 失去连贯性
使用代理:
代理读取10个文件 → 主线程获得1个摘要 → 上下文得以保留
代理如何保留上下文
- 繁重工作 - 代理完成繁琐的工作(读取文件、运行测试、实现功能)
- 上下文隔离 - 实现细节保留在代理中，不在主线程
- 简洁返回 - 只有必要信息返回到主线程对话
- 并行执行 - 多个代理可以同时工作而不会产生上下文冲突
使用示例
# 分析代码查找错误
任务: "在代码库中搜索内存泄漏"
代理: code-analyzer
返回: "发现3个潜在泄漏: [简洁列表]"
主线程不会看到: 检查的数百个文件
# 运行测试
任务: "运行身份验证测试"
代理: test-runner
返回: "10个测试中有2个失败: [失败摘要]"
主线程不会看到: 详细的测试输出和日志
# 并行实现
任务: "使用并行流实现问题#1234"
代理: parallel-worker
返回: "完成4/4个流，修改了15个文件"
主线程不会看到: 单个实现细节
创建新代理
新代理应遵循以下原则:
- 单一目的 - 每个代理都有一个明确的工作
- 上下文缩减 - 返回处理内容的10-20%
- 不角色扮演 - 代理不是"专家"，而是任务执行器
- 清晰模式 - 定义输入 → 处理 → 输出模式
- 错误处理 - 优雅地处理失败并清晰报告
需避免的反模式
❌ 创建"专家"代理 (数据库专家、API专家) 代理没有不同的知识 - 它们都是相同的模型
❌ 返回详细输出 违背了上下文保留的目的
❌ 让代理相互沟通 应该使用协调代理(如parallel-worker)
❌ 为简单任务使用代理 只有当上下文缩减有价值时才使用代理
与PM系统的集成
代理与PM命令系统无缝集成:
/pm:issue-analyze→ 识别工作流/pm:issue-start→ 生成parallel-worker代理- parallel-worker → 生成多个子代理
- 子代理 → 在工作树中并行工作
- 结果 → 整合回主线程
这创建了一个层次结构，在每个级别都最大化并行性同时保留上下文。