Skills角色分配：让多个Skill像团队一样协作
想象你不是一个”全能选手”在工作，而是一个”团队”在工作：
- 有人负责接收问题
- 有人负责分析问题
- 有人负责执行任务
- 有人负责把结果返回给你
这就是”角色分配”要解决的问题：让多个Skill像一个团队一样分工合作。
0. 从一个问题开始
先来看一个常见的场景：
你写了一个”智能助手”S kill，它需要：
- 理解用户说的话
- 调用合适的工具
- 生成回复
如果你把这些都塞进一个Skill，会发生什么？
# 一个"全能"但混乱的Skill
instructions: |
你是一个智能助手，需要：
1. 理解用户意图
2. 调用天气API查天气
3. 调用日历API看日程
4. 调用邮件API发邮件
5. 生成自然语言回复
...这个Skill会变得：
- 太大太复杂
- 难以维护
- 难以测试
- 难以扩展
更好的做法：把这个”全能选手”拆成多个专业角色。
1. 角色系统的核心理念
1.1 什么是角色
角色（Role）定义了一个人在团队中的位置和职责。在Skills系统中，角色就是一组相关能力的封装。
类比一下现实世界：
| 现实团队 | Skills角色系统 |
|---|---|
| 团队成员 | Role/Agent |
| 岗位职责 | 职责边界（Scope） |
| 工作技能 | Skills |
| 协作方式 | 通信协议 |
| 汇报关系 | 依赖关系 |
1.2 为什么需要角色
| 没有角色 | 有角色 |
|---|---|
| 一个Skill做所有事 | 每个角色做一件事 |
| 代码臃肿难维护 | 职责清晰易维护 |
| 测试困难 | 独立测试容易 |
| 扩展困难 | 添加新角色简单 |
| 单点故障 | 角色可独立替换 |
1.3 角色 vs Skills vs Agents
这三个概念经常被混用，但它们有区别：
Agent = Role + Memory + Tools + Autonomy
Role = Persona + Skills + Context
Skill = Capability + Instructions
| 概念 | 说明 | 类比 |
|---|---|---|
| Agent | 完整的AI实体，有自主决策能力 | 一个完整的员工 |
| Role | Agent的职责定义，不包含执行能力 | 岗位描述 |
| Skill | 具体的能力单元 | 员工掌握的技能 |
实际理解：
- 你可以把Role理解为一个”岗位”
- Agent是有人来担任这个岗位
- Skills是这个人掌握的技能
2. 角色的构成要素
2.1 完整角色定义
一个完整的角色定义应该包含这些要素：
# SKILL.code-reviewer-role.md
---
name: code-reviewer
type: role
version: 1.0.0
---
# 代码审查员角色
## 身份标识
- **名称**：代码审查员
- **人设**：严谨、专业、注重细节
- **专长**：代码质量、安全审计、性能优化
## 职责边界
### 我负责的（in_scope）
1. 代码语法检查
2. 代码风格审查
3. 安全漏洞检测
4. 性能问题识别
### 我不负责的（out_of_scope）
1. 需求变更
2. 架构设计决策
3. 直接修改代码
## 工作方式
- **沟通风格**：直接、简洁、技术性强
- **决策方式**：证据驱动、数据支撑
- **协作模式**：请求-响应
## 生命周期
- **就绪**：等待任务
- **执行**：处理审查任务
- **等待**：等待用户反馈
- **终止**：完成任务2.2 职责边界的定义原则
单一职责原则（SRP）
每个角色应该只有一个核心职责：
# ✅ 好的职责定义
responsibilities:
in_scope:
- 代码审查 # 只负责审查
out_of_scope:
- 修改代码 # 不做修改
# ❌ 糟糕的职责定义
responsibilities:
in_scope:
- 代码审查
- 代码修改 # 职责混杂
- 架构设计 # 职责混杂最小权限原则
角色只应该拥有完成职责所必需的最小权限：
# ✅ 好的权限定义
permissions:
filesystem:
read: true # 需要读代码
write: false # 不需要写代码
network:
api_calls: false # 不需要调用外部API明确的输入输出
每个角色应该明确：
- 它接受什么输入
- 它产生什么输出
- 它与其他角色的接口
3. 角色的生命周期
3.1 生命周期阶段
┌─────────────────────────────────────────────────────────────┐
│ 角色生命周期 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────┐ │
│ │ 初始化 │ → 加载定义、初始化状态 │
│ └───────┘ │
│ ↓ │
│ ┌───────┐ │
│ │ 就绪 │ → 等待任务 │
│ └───────┘ │
│ ↓ │
│ ┌───────┐ │
│ │ 执行中 │ → 处理任务 │
│ └───────┘ │
│ ↓ │
│ ┌───────┐ │
│ │ 等待中 │ → 等待资源/响应 │
│ └───────┘ │
│ ↓ │
│ ┌───────┐ │
│ │ 终止 │ → 保存状态、清理资源 │
│ └───────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
3.2 生命周期配置
lifecycle:
# 初始化阶段
init:
- load_definitions # 加载角色定义
- initialize_memory # 初始化记忆
- establish_connections # 建立连接
# 就绪阶段
ready:
- wait_for_tasks # 等待任务
- monitor_dependencies # 监控依赖
# 执行阶段
executing:
- process_task # 处理任务
- call_tools # 调用工具
- communicate # 与其他角色通信
# 等待阶段
waiting:
- block_on_resource # 等待资源
- timeout_handling # 超时处理
# 终止阶段
terminate:
- save_state # 保存状态
- release_resources # 释放资源
- cleanup_connections # 清理连接4. 角色间的通信协议
4.1 为什么需要通信协议
多个角色要协作，就必须通信。如果每个角色用自己的方式说话，就会鸡同鸭讲。
没有协议：
角色A：发了条消息
角色B：收到，但看不懂
结果：协作失败
有协议：
角色A：按协议格式发送消息
角色B：按协议格式解析消息
结果：协作成功
4.2 消息格式定义
# 标准消息格式
message_format:
header: # 消息头
message_id: string # 唯一标识
timestamp: datetime # 发送时间
sender: role_id # 发送者
receiver: role_id # 接收者
message_type: enum # 消息类型
correlation_id: string # 关联ID（用于追踪）
body: # 消息体
intent: string # 意图
content: object # 内容
parameters: object # 参数
footer: # 消息尾
priority: enum # 优先级
ttl: integer # 生存时间
metadata: object # 元数据4.3 消息类型
| 消息类型 | 方向 | 说明 | 典型场景 |
|---|---|---|---|
| REQUEST | A→B | 请求执行任务 | 分配任务 |
| RESPONSE | B→A | 返回任务结果 | 完成任务 |
| NOTIFICATION | 任意 | 通知事件发生 | 状态变更 |
| QUERY | A→B | 查询信息 | 获取数据 |
| COMMAND | A→B | 发出命令 | 流程控制 |
| EVENT | 发布者→订阅者 | 发布事件 | 事件驱动 |
# 消息类型定义
message_types:
REQUEST:
fields: [task, parameters, deadline, priority]
expected_response: RESPONSE
timeout: 30000
RESPONSE:
fields: [status, result, error, metadata]
NOTIFICATION:
fields: [event_type, event_data, source]
delivery: at_most_once
EVENT:
fields: [event_name, payload, timestamp]
subscription: role_ids4.4 通信模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| 同步通信 | 发送方等待响应 | 需要即时结果 |
| 异步通信 | 发送方不等待 | 耗时任务 |
| 广播通信 | 一对多 | 状态变更通知 |
| 组播通信 | 一对组 | 多角色协作 |
# 通信模式配置
communication_modes:
synchronous:
pattern: request-response
timeout: 30000
retry_on_timeout: false
asynchronous:
pattern: fire-and-forget
queue: true
delivery_guarantee: at_least_once
broadcast:
pattern: publish-subscribe
subscribers: [role_1, role_2, role_3]
filter: event_type5. 能力矩阵：让任务找到合适的角色
5.1 什么是能力矩阵
能力矩阵是系统中所有角色能力的结构化表示，帮助系统了解每个角色能做什么，便于任务分配。
5.2 能力定义格式
# 代码审查员的能力矩阵
capability_matrix:
role: code-reviewer
capabilities:
- name: syntax_check
description: 代码语法检查
level: expert # novice/competent/proficient/expert
input_types: [source_code]
output_types: [issue_list]
performance:
avg_duration: 500 # 平均耗时（毫秒）
max_duration: 2000 # 最大耗时
- name: security_scan
description: 安全漏洞扫描
level: proficient
input_types: [source_code, dependencies]
output_types: [vulnerability_report]
tools: [security_scanner]
- name: performance_analysis
description: 性能分析
level: competent
input_types: [source_code, profiler_output]
output_types: [performance_report]
constraints:
max_concurrent_tasks: 3 # 最大并发任务数
supported_languages: [javascript, python, java, go]
max_file_size: 10485760 # 10MB5.3 任务分配策略
task_allocation:
algorithm: capability_matching
matching_criteria:
- capability_match_score # 能力匹配度
- current_workload # 当前工作负载
- historical_performance # 历史表现
- availability # 可用性
allocation_strategy:
best_match:
enabled: true
min_match_score: 0.8 # 最低匹配分数
load_balancing:
enabled: true
threshold: 0.7 # 负载超过70%时尝试分配其他角色
fallback:
enabled: true
on_no_match: escalate_to_human5.4 分配流程图
任务输入
↓
分析任务需求
↓
┌─────────────────────────────────┐
│ 能力匹配 │
│ ┌─────────┐ ┌─────────┐ │
│ │角色A │ │角色B │ │
│ │匹配度80% │ │匹配度95% │ │
│ │负载60% │ │负载30% │ │
│ └─────────┘ └─────────┘ │
│ ↓ │
│ 选择角色B（匹配度高+负载低） │
└─────────────────────────────────┘
↓
分配任务给角色B
↓
执行任务
↓
返回结果
6. 角色冲突解决
6.1 冲突的类型
在多角色系统中，冲突可能发生在多个层面：
| 冲突类型 | 说明 | 示例 |
|---|---|---|
| 资源冲突 | 竞争同一资源 | 多个角色争用同一数据库连接 |
| 输出冲突 | 对同一问题给出不同答案 | 两个角色对代码质量评分不一致 |
| 边界冲突 | 职责边界不清晰 | 某个任务不知道该谁来做 |
| 优先级冲突 | 对同一任务优先级判断不同 | 两个角色都认为自己应该先处理 |
6.2 优先级策略
最简单的冲突解决方式：谁优先级高听谁的。
conflict_resolution:
strategy: priority_based
priority_levels:
admin: 100 # 管理员
security_officer: 90 # 安全官
quality_assurance: 80 # 质量保障
regular_role: 50 # 普通角色
resolution_rules:
- higher_priority_wins # 优先级高的获胜
- tiebreaker: most_relevant_role # 平局时选最相关的6.3 仲裁机制
引入专门的”法官”角色来解决冲突：
conflict_resolution:
strategy: arbitration
arbitrator: SKILL.conflict-arbitrator
arbitration_process:
- collect_conflicting_positions # 收集各方立场
- analyze_conflict_type # 分析冲突类型
- apply_resolution_rules # 应用解决规则
- generate_resolution # 生成解决方案
- notify_all_parties # 通知各方6.4 协商机制
让冲突双方自己商量：
conflict_resolution:
strategy: negotiation
negotiation_steps:
- role_a_proposes # A提出方案
- role_b_responds # B回应
- compromise_generated # 生成折中方案
- check_acceptance # 检查是否接受
- iterate_or_finalize # 迭代或确定6.5 投票机制
多个角色投票决定：
conflict_resolution:
strategy: voting
voting_rules:
eligible_voters: [role_1, role_2, role_3, role_4]
quorum: 0.6 # 60%参与率
decision_threshold: 0.5 # 简单多数
weighted_votes: true # 加权投票6.6 冲突预防
比解决冲突更重要的是预防冲突：
conflict_prevention:
- clear_boundary_definitions # 清晰的边界定义
- explicit_ownership # 明确的所有权
- regular_boundary_review # 定期边界审查
- cross_role_training # 跨角色培训7. 角色进化机制
7.1 为什么要进化
AI系统的角色不是一成不变的。随着业务发展、用户反馈和性能数据的积累，角色需要不断进化。
7.2 进化的维度
| 进化类型 | 说明 | 例子 |
|---|---|---|
| 能力增强 | 学习新技能 | 新增Python代码审查能力 |
| 行为优化 | 改进工作方式 | 调整输出格式提高可读性 |
| 边界调整 | 调整职责范围 | 从”只审查”变成”审查+修复建议” |
7.3 能力增强
evolution:
type: capability_enhancement
sources:
- explicit_feedback # 显式反馈（用户评分）
- implicit_learning # 隐式学习（行为分析）
- knowledge_transfer # 知识转移（从其他角色学习）
mechanisms:
skill_acquisition:
trigger: repeated_failure_with_hint # 反复失败+有提示
process:
- identify_missing_capability # 识别缺失能力
- search_knowledge_base # 搜索知识库
- acquire_new_skill # 获取新技能
- validate_effectiveness # 验证效果7.4 行为优化
evolution:
type: behavior_optimization
optimization_targets:
- response_accuracy # 响应准确率
- processing_speed # 处理速度
- user_satisfaction # 用户满意度
methods:
- reinforcement_learning # 强化学习
- behavior_cloning # 行为克隆
- human_feedback_integration # 人类反馈整合7.5 进化管理
evolution_management:
# 进化频率控制
frequency:
min_interval: 7d # 至少7天
max_changes: 3 # 每次最多3个变更
# 变更验证
validation:
automated_tests: true
shadow_mode: true # 影子模式验证
rollout_percentage: 10 # 灰度发布10%
# 回滚机制
rollback:
enabled: true
trigger: performance_drop > 10%
automatic: false # 需要人工确认8. 实际案例：构建一个客服团队
8.1 团队结构
┌─────────────────────────────────────────────────────────────┐
│ 客服团队 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ 调度员 │ ← 接收用户问题，分发给专人处理 │
│ └──────┬──────┘ │
│ ↓ │
│ ┌──────┴──────┬────────────┐ │
│ ↓ ↓ ↓ │
│ ┌──────┐ ┌──────────┐ ┌──────┐ │
│ │ 技术 │ │ 业务 │ │ 投诉 │ │
│ │ 客服 │ │ 客服 │ │ 客服 │ │
│ └──────┘ └──────────┘ └──────┘ │
│ │
│ ┌─────────────┐ │
│ │ 质检员 │ ← 检查回复质量 │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
8.2 角色定义
调度员
# SKILL.dispatcher.md
---
name: dispatcher
description: 问题调度员
---
# 问题调度员
## 职责
接收用户问题，分析问题类型，分发给合适的客服。
## 能力
- 意图识别：判断问题属于技术/业务/投诉
- 紧急识别：判断是否紧急需要优先处理
- 路由分配：把问题分配给合适的客服
## 边界
- 我负责：分析、分发
- 我不负责：直接回答用户问题技术客服
# SKILL.tech-support.md
---
name: tech-support
description: 技术客服
---
# 技术客服
## 职责
处理技术相关问题，包括使用问题、Bug、功能咨询。
## 能力
- 技术问题诊断
- 使用指导
- Bug记录和反馈
## 边界
- 我负责：技术问题
- 我不负责：退款请求、业务咨询业务客服
# SKILL.business-support.md
---
name: business-support
description: 业务客服
---
# 业务客服
## 职责
处理业务相关问题，包括订单、付款、合同等。
## 能力
- 业务规则解答
- 订单处理
- 退款请求
## 边界
- 我负责：业务问题
- 我不负责：技术问题8.3 协作流程
用户：我的订单还没到
↓
┌─────────────┐
│ 调度员 │ → 判断为"业务问题"
└──────┬──────┘
↓
┌─────────────┐
│ 业务客服 │ → 查询订单状态
└──────┬──────┘
↓
┌─────────────┐
│ 质检员 │ → 检查回复质量
└──────┬──────┘
↓
用户：收到回复"您的订单正在配送中，预计明天送达"
8.4 冲突解决案例
场景：用户同时问了技术问题和业务问题。
冲突：技术客服和业务客服都觉得对方应该处理。
解决：
- 调度员识别出两个问题
- 技术问题分配给技术客服
- 业务问题分配给业务客服
- 两个客服分别处理各自的问题
- 质检员合并检查
9. 常见问题
Q1: 角色越多越好吗？
答：不是。角色太多会导致：
- 系统复杂度增加
- 协作开销增大
- 难以维护
建议：先从2-3个核心角色开始，根据需要逐步拆分。
Q2: 角色之间应该直接通信还是通过中介？
答：看场景：
- 直接通信：角色之间关系紧密，需要频繁交互
- 通过中介（消息队列）：角色之间解耦，不需要实时交互
Q3: 怎么避免角色之间的循环依赖？
答：
- 使用单向依赖原则
- 引入协调者角色
- 使用事件驱动而非直接调用
Q4: 角色能动态创建和销毁吗？
答：可以，但需要：
- 生命周期管理
- 状态迁移机制
- 资源清理
10. 总结
- 角色是职责的封装：每个角色负责一块职责
- 角色有生命周期：初始化→就绪→执行→等待→终止
- 角色靠协议通信：标准化的消息格式让协作成为可能
- 能力矩阵帮助分配：让合适的角色做合适的事
- 冲突需要解决：优先级、仲裁、协商、投票
- 角色可以进化：随着时间学习和改进
记住：角色系统的目标是让协作更顺畅，而不是增加复杂度。
下一步
- 想学更具体的组织方式 → Skills设计模式
- 想学如何测试角色协作 → Skills测试与优化
- 想学遇到问题怎么排查 → Skills调试实战
相关文档
- Skills基础理论 - Skills核心概念
- Skills设计模式 - 设计模式详解
- Skills编写规范 - 编码规范
- Tool集成指南 - 工具集成
- Skills测试与优化 - 测试与优化
本文档介绍了Skills系统中角色分配的设计理念、协议定义和实现机制。