名称: 代理专业化 描述: 遵循一个代理、一个提示、一个目的原则，指导创建专注的单用途代理。适用于设计新代理、重构全能代理为专业代理、优化代理上下文以适应单个任务时。 允许工具: 读取、Grep、Glob
代理专业化技能
创建专注、单用途代理以最大化效果的指南。
使用场景
- 为工作流程设计新代理
- 将全能代理重构为专业代理
- 优化代理上下文使用
- 创建易于评估的代理架构
核心原则
“一个代理、一个提示、一个目的”
每个代理应：
- 有且仅有一个目的
- 运行一个提示
- 为该目的使用完整上下文窗口
- 可复制和可改进
设计工作流程
步骤 1: 确定单一目的
问：“这个代理回答的 ONE 问题是什么？”
| 好的目的 | 坏的目的 |
|---|---|
| “分类此问题” | “分类、计划和实施” |
| “生成补丁计划” | “修复所有错误” |
| “对照规范审查” | “审查、测试和文档化” |
步骤 2: 确定所需最小上下文
应用最小上下文原则：
## 所需上下文
- [需要的具体文件或部分]
- [需要的模式或示例]
## 不需要
- [不相关的文档]
- [不会触及的代码]
步骤 3: 选择合适工具
仅包含代理实际使用的工具：
| 目的 | 工具 |
|---|---|
| 分类 | 读取 |
| 规划 | 读取、写入、Glob |
| 实施 | 读取、写入、编辑、Bash |
| 审查 | 读取、Bash、Glob |
| 文档化 | 读取、写入 |
步骤 4: 选择模型
根据任务复杂性匹配模型：
| 模型 | 最适合 |
|---|---|
| haiku | 分类、简单提取 |
| sonnet | 规划、中等推理 |
| opus | 复杂实施、关键决策 |
步骤 5: 设计专注的输出格式
输出应为：
- 结构化（如适用JSON）
- 最小化（仅下游需要的内容）
- 可解析（用于自动化）
代理模板
---
描述: [描述 ONE 目的的单个句子]
工具: [仅实际需要的工具]
模型: [基于复杂性的 haiku/sonnet/opus]
---
# [代理名称]
您是一个[角色]代理。您的 ONE 目的是[具体任务]。
## 您的功能
- **[工具]**: [如何支持目的]
## 流程
[单一目的的专注步骤]
## 输出格式
[结构化输出格式]
## 规则
1. [保持专注的约束]
2. [另一个约束]
要避免的反模式
全能代理
# 错误：做所有事情
您是一个全能的助手。计划功能、
实施代码、编写测试、审查更改和
创建文档。处理任何请求。
不专注的输出
# 错误：返回所有内容
返回详细分析，包括历史、
上下文、替代方案、影响和
对所有利益相关者的建议。
工具堆砌
# 错误：启用所有工具
工具: [读取、写入、编辑、Bash、Glob、Grep、WebFetch、Task、...]
专业化的好处
- 完整上下文窗口: 100% 用于任务
- 无上下文混淆: 单一目标
- 可复制: 相同提示，相同行为
- 可改进: 可独立优化
- 易于评估: 可 A/B 测试模型
- 易于调试: 清晰的职责范围
示例: 专业化 vs 全能模式
全能模式（坏）
处理 GitHub 问题：
1. 分类它
2. 创建分支
3. 规划实施
4. 实施功能
5. 编写测试
6. 运行测试
7. 审查实施
8. 修复任何问题
9. 创建文档
10. 创建 PR
专业化（好）
/classify-issue → 问题分类代理
/generate-branch-name → 分支命名代理
/feature → 规划生成代理
/implement → 计划实施代理
/test → 测试运行代理
/review → 规范审查代理
/patch → 补丁规划代理
/document → 文档生成代理
/pull-request → PR 创建代理
每个代理做好一件事。
记忆参考
- @one-agent-one-purpose.md - 完整原则文档
- @minimum-context-principle.md - 上下文工程指南
- @review-vs-test.md - 不同目的的示例
版本历史
- v1.0.0 (2025-12-26): 初始发布
最后更新
日期: 2025-12-26 模型: claude-opus-4-5-20251101