name: 代理专家创建 description: 使用Act-Learn-Reuse模式创建具有预加载领域知识的专业代理专家。当构建通过专业知识文件和自改进提示来维护心理模型的领域特定代理时使用。 allowed-tools: 读取, 搜索, 全局查找, 写入
代理专家创建技能
创建通过Act-Learn-Reuse模式学习和维护领域知识的专业代理专家。
核心解决的问题
“代理的巨大问题是这个：你的代理会忘记。这意味着你的代理不会学习。”
通用代理执行后就忘记。代理专家执行并学习，通过维护与代码库同步的专业知识文件（心理模型）。
何时使用
- 领域中重复的复杂任务（数据库、计费、WebSocket）
- 高风险系统，错误会级联（安全、支付）
- 需要跟踪心理模型的快速演进代码
- 跨会话需要一致的领域专业知识
- 构建计划-构建-改进自动化循环
Act-Learn-Reuse模式
┌─────────────────────────────────────────────────────────────┐
│ ACT-LEARN-REUSE 循环 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ACT ──────────► LEARN ──────────► REUSE │
│ │ │ │ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 采取有用行动 通过自改进提示更新专业知识文件 下次执行时首先读取专业知识文件 │
│ （构建、修复） │
│ │
└─────────────────────────────────────────────────────────────┘
| 步骤 | 动作 | 目的 |
|---|---|---|
| ACT | 采取有用行动 | 生成学习数据（构建、修复、回答） |
| LEARN | 在专业知识文件中存储新信息 | 通过自改进提示自动构建心理模型 |
| REUSE | 下次执行时首先读取专业知识 | 从心理模型中更快、更自信地执行 |
专业知识文件（心理模型）
“专业知识文件是你的代理专家问题空间的心理模型…这不是事实来源。这是一个工作记忆文件，一个心理模型。”
关键区别
| 概念 | 是 | 不是 |
|---|---|---|
| 专业知识文件 | 心理模型 | 事实来源 |
| 专业知识文件 | 工作记忆 | 文档 |
| 事实来源 | 实际代码库 | 专业知识文件 |
专业知识文件结构（YAML）
概述:
描述: "高层次系统描述"
技术栈: "关键技术"
模式: "架构模式"
核心实现:
模块名:
文件: "路径/到/文件.py"
行数: 400
用途: "此模块的作用"
架构结构: # 用于数据库专家
表:
表名:
用途: "此表存储的内容"
关键列: ["id", "created_at"]
关键操作:
操作类别:
操作名:
函数: "函数名()"
逻辑: "如何工作"
最佳实践:
- "实践 1"
- "实践 2"
已知问题:
- "问题 1 及解决方法"
行数限制（关键）
| 规模 | 行数 | 使用场景 |
|---|---|---|
| 小 | ~300-500 | 简单领域，聚焦范围 |
| 中 | ~600-800 | 复杂领域，中等范围 |
| 最大 | ~1000 | 非常复杂的领域（强制执行限制） |
为什么限制重要： 保护上下文窗口。专业知识文件必须保持可扫描性。
专家创建过程
步骤 1：定义领域
基于风险和复杂性识别专业知识领域：
| 风险级别 | 领域示例 | 为什么需要专家？ |
|---|---|---|
| 关键 | 计费、安全 | 影响收入/安全 |
| 高 | 数据库、认证 | 一切的基础 |
| 中高 | WebSocket、API | 复杂事件流 |
| 中 | DevOps、CI/CD | 基础设施依赖 |
步骤 2：设计专家目录结构
.claude/commands/experts/{领域}/
expertise.yaml # 心理模型（约600-1000行最大）
question.md # REUSE：不编码查询专业知识
self-improve.md # LEARN：与代码库同步心理模型
plan.md # REUSE：使用专业知识创建计划
plan-build-improve.md # 完整的ACT→LEARN→REUSE工作流
步骤 3：创建自改进提示
“不要直接更新此专业知识文件。教会你的代理如何直接更新它，以便它们能维护它。”
自改进提示教导代理如何学习：
# {领域} 专家 - 自改进
通过比较实际代码库实现来维护专业知识准确性。
## 工作流
1. **检查Git Diff**（如果 $1 为真）
- 运行 `git diff HEAD~1` 查看最近更改
- 如果没有与{领域}相关的更改，跳过
2. **读取当前专业知识**
- 加载 expertise.yaml 心理模型
3. **验证代码库**
- 逐行验证源文件
- 检查文件路径、行数、函数名
4. **识别差异**
- 列出更改内容与专业知识所述内容的差异
- 优先处理显著更改
5. **更新专业知识文件**
- 同步心理模型与实际代码
- 添加发现的新模式
- 移除过时信息
6. **强制执行行数限制（MAX_LINES: 1000）**
- 如果超出限制，压缩内容
- 优先处理关键信息
7. **验证检查**
- 确保YAML语法有效
- 验证所有文件引用存在
步骤 4：创建专家命令
计划-构建-改进三件套：
| 命令 | 目的 | 模型 | 令牌（子代理） |
|---|---|---|---|
| {领域}/plan | 调查和创建规范 | opus | ~80K（受保护） |
| {领域}/build | 从规范执行 | sonnet | 可变 |
| {领域}/self-improve | 更新心理模型 | opus | 仅传递git diff |
专家定义模板
子代理专家
---
name: {领域}-专家
description: 针对{目的}的{领域}专家
tools: [聚焦工具列表]
model: sonnet
color: blue
---
# {领域} 专家
你是{领域}专家，专门于{特定领域}。
## 专业知识
- {领域概念}的深入知识
- {常见模式}的经验
- {最佳实践}的理解
## 工作流
1. 分析请求
2. 应用领域专业知识
3. 提供结构化输出
## 输出格式
{此专家输出的结构化格式}
计划命令
---
description: 计划{领域}实施，提供详细规范
argument-hint: <{领域}-请求>
model: opus
allowed-tools: 读取, 全局查找, 搜索, WebFetch
---
# {领域} 专家 - 计划
你是{领域}专家，专门计划{领域}实施。
## 专业知识
[预加载领域知识]
## 工作流
1. **建立专业知识**
- 读取相关文档
- 审查现有实现
2. **分析请求**
- 理解需求
- 识别约束
3. **设计解决方案**
- 架构决策
- 实施方法
- 边缘案例
4. **创建规范**
- 保存到 `specs/experts/{领域}/{名称}-spec.md`
构建命令
---
description: 从规范构建{领域}实施
argument-hint: <规范文件路径>
model: sonnet
allowed-tools: 读取, 写入, 编辑, Bash
---
# {领域} 专家 - 构建
你是{领域}专家，专门实施{领域}解决方案。
## 工作流
1. 完全读取规范
2. 根据规范实施
3. 验证符合需求
4. 报告所做的更改
改进命令
---
description: 基于完成的工作改进{领域}专家知识
argument-hint: <工作摘要>
model: sonnet
allowed-tools: 读取, 写入, 编辑
---
# {领域} 专家 - 改进
基于完成的工作更新专家知识。
## 工作流
1. 分析完成的工作
2. 识别学到的新模式
3. 更新专家文档
4. 捕获经验教训
示例：钩子专家
子代理：hook-expert
---
name: hook-专家
description: Claude Code钩子自动化专家
tools: [读取, 写入, 编辑, Bash]
model: sonnet
color: cyan
---
# Claude Code 钩子专家
你是Claude Code钩子的专家。
## 专业知识
- 钩子事件类型（PreToolUse、PostToolUse、UserPromptSubmit等）
- settings.json中的钩子配置
- Python钩子实现模式
- UV脚本元数据头部
- 钩子输入/输出合同
命令
/hook_expert_plan- 计划钩子实施/hook_expert_build- 从规范构建/hook_expert_improve- 更新钩子专业知识
专家文件结构
.claude/
commands/
experts/
{领域}/
expertise.yaml # 心理模型（600-1000行）
question.md # 查询专业知识（$1 = 问题）
self-improve.md # 同步心理模型（$1 = check_git_diff）
plan.md # 创建计划（$1 = 任务）
plan-build-improve.md # 完整工作流（$1 = 任务）
agents/
{领域}-专家.md # 子代理定义
specs/
experts/
{领域}/
{特性名称}-spec.md # 生成的规范
引导策略
如何引导专家
-
从空白开始 - 让代理发现结构
# expertise.yaml（初始） 概述: 描述: "待填充" -
运行自改进 - 代理构建初始专业知识
/experts/{领域}/self-improve true -
迭代 - 运行自改进直到代理停止发现更改
-
验证 - 确保与代码库准确一致
何时不构建专家
| 反模式 | 问题 |
|---|---|
| 稳定、不变的代码 | 浪费精力 - 无需学习 |
| 简单/琐碎系统 | 开销超过收益 |
| 你不理解的领域 | 垃圾进，垃圾出 |
| 一次性完成所有 | 从最高风险领域开始 |
反模式
| 反模式 | 问题 | 解决方案 |
|---|---|---|
| 将专业知识视为事实来源 | 创建重复、冲突 | 心理模型验证代码库 |
| 手动更新专业知识文件 | 浪费工程师时间 | 让自改进提示维护 |
| 无限专业知识增长 | 上下文窗口膨胀 | 强制执行行数限制（约1000最大） |
| 无引导策略 | 起始点不明确 | 从简单开始，让代理定义结构 |
| 为稳定代码构建专家 | 浪费精力 | 仅用于演进、复杂系统 |
| 不理解就构建专家 | 垃圾进，垃圾出 | 你必须先理解领域 |
专家模式
模式：只读专家
用于分析而不修改：
工具: 读取, 全局查找, 搜索
目的: 审计、审查、分析
输出: 报告和建议
模式：构建专家
用于实施工作：
工具: 读取, 写入, 编辑, Bash
目的: 创建、修改、实施
输出: 代码更改和工件
模式：研究专家
用于信息收集：
工具: WebFetch, 读取, 写入
目的: 获取、处理、组织
输出: 文档和摘要
输出格式
创建专家时生成：
{
"专家名称": "{领域}-专家",
"目的": "{专业知识描述}",
"组件": {
"子代理": "{领域}-专家.md",
"计划命令": "{领域}_专家_plan.md",
"构建命令": "{领域}_专家_build.md",
"改进命令": "{领域}_专家_improve.md"
},
"所需目录": [
".claude/commands/experts/{领域}_专家/",
"specs/experts/{领域}/",
"ai_docs/{领域}/"
],
"分配工具": ["列表", "的", "工具"],
"模型分配": {
"计划": "opus",
"构建": "sonnet",
"改进": "sonnet"
}
}
关键引用
“通用代理与代理专家的区别很简单：一个执行并忘记，另一个执行并学习。”
“真正的专家总是在学习。他们正在更新他们的心理模型。”
“构建构建系统的系统。不要工作在应用层。”
交叉参考
这些是TAC课程材料和模式的概念参考：
- 一个代理，一个目的 - 专业化原则（TAC Lesson 6）
- R&D框架 - 减少与委派策略（TAC Lesson 8）
- 上下文准备模式 - 加载领域上下文（TAC Lesson 9）
- 12个杠杆点 - 杠杆点 #3：系统提示（TAC Lesson 3）
- TAC Lesson 13：代理专家 - Act-Learn-Reuse模式来源
最后更新: 2025-12-15
版本历史
- v1.0.0 (2025-12-26): 初始发布