用途
该技能用于多智能体系统的设计，处理需要监督者模式、群体架构或智能体协调策略的场景。它的核心洞察是：子智能体存在的主要目的是隔离上下文，而不是拟人化地进行角色划分。
快速开始流程
- 识别需求：为什么要使用多个智能体？原因可能包括上下文限制、并行性、专业化。
- 选择模式：监督者、点对点或分层。
- 设计通信：消息传递、交接、状态共享。
- 实施防护措施：验证、超时、冲突解决。
- 监控：令牌使用、瓶颈、失败。
适用时机
- 上下文窗口限制使单智能体方案不可行。
- 任务可从并行执行中获益。
- 不同领域需要专门知识。
- 复杂工作流需要协调。
- 需要通过冗余获得韧性。
三种主要模式
1. 监督者/编排者
结构：由中心协调者向专家智能体分派任务并综合结果。
最佳适用：任务可清晰分解、需要人工监督、存在顺序依赖、有质量控制要求。
关键考量：当监督者错误地转述子智能体的响应时，会出现"传话游戏问题"。解决方案是实现 forward_message 工具，让子智能体可直接与用户通信：
def forward_message(agent_id: str, message: str, to: str = "user"): """Forward agent message directly without supervisor interpretation.""" return {"from": agent_id, "message": message, "forwarded": True}
2. 点对点/群体
结构：没有中心控制，智能体通过协议直接通信。
最佳适用：灵活探索、涌现式问题解决、并行处理、韧性架构。
关键要求：预定义通信协议、显式交接机制、共享状态管理、冲突解决规则。
3. 分层
结构：由策略层、规划层和执行层组成的多层智能体。
最佳适用：复杂组织工作流、多级抽象、清晰的关注点分离、企业级系统。
各层职责：策略层负责目标、优先级、资源分配；规划层负责任务分解、调度、协调；执行层负责实际工作、汇报、反馈。
令牌经济学
现实情况：与单智能体方案相比，多智能体系统约消耗 15 倍基线令牌。
| 方案 | 令牌倍数 | 用例 |
|---|---|---|
| 单智能体 | 1x | 简单、聚焦的任务 |
| 2-3 个智能体 | 3-5x | 中等复杂度 |
| 完整群体 | 10-20x | 复杂、并行工作 |
优化策略：模型选择带来的收益通常大于增加智能体数量；常规任务使用较小模型；将大模型保留用于综合与决策；实施激进的上下文压缩。
通信模式
消息传递：
class AgentMessage: sender: str recipient: str content: str message_type: Literal["request", "response", "broadcast"] requires_ack: bool = False
交接协议：
class Handoff: from_agent: str to_agent: str context: dict # Compressed relevant state task: str expected_output: str timeout_seconds: int = 300
状态共享：
class SharedState: version: int last_updated: datetime data: dict lock_holder: Optional[str] = None
def acquire_lock(self, agent_id: str) -> bool: ...
def release_lock(self, agent_id: str) -> bool: ...
def update(self, agent_id: str, changes: dict) -> bool: ...
实施指南
验证要求：在智能体之间传递前验证输出；检查消息格式与完整性；分派前核实智能体能力；状态更新后验证一致性。
共识机制：
| 机制 | 描述 | 最佳适用 |
|---|---|---|
| 简单多数 | 超过 50% 同意 | 快速决策 |
| 加权投票 | 按置信度加权计票 | 质量敏感场景 |
| 法定人数 | 要求最低响应数 | 容错 |
| 领导者选举 | 指定决策者 | 速度 |
建议实现加权投票而非简单多数：
def weighted_consensus(votes: List[Vote]) -> Decision: weighted_sum = sum(v.confidence * v.value for v in votes) total_weight = sum(v.confidence for v in votes) return Decision(value=weighted_sum / total_weight)
防护措施：
执行 TTL，用于防止无限循环：
max_execution_time = 300 # seconds max_iterations = 100
检查点监控，用于检测监督者瓶颈：
checkpoint_interval = 30 # seconds alert_threshold = 3 # missed checkpoints
熔断器，用于处理级联失败：
failure_threshold = 3 recovery_timeout = 60 # seconds
最佳实践
应当做到：从可用的最简单模式开始；定义显式交接协议；从一开始就纳入状态管理；监控每个智能体的令牌使用；实施优雅降级；记录所有智能体间通信。
不应做：对单智能体问题使用多智能体；假设智能体会隐式协调；在设计时忽略令牌成本；跳过智能体之间的验证；创建深度嵌套的层级；忘记超时处理。
错误处理
| 错误 | 原因 | 解决方案 |
|---|---|---|
| 智能体超时 | 任务过于复杂 | 拆分为子任务，延长时间 |
| 输出冲突 | 任务含糊 | 明确需求，增加验证 |
| 消息丢失 | 网络/状态问题 | 实施确认、重试 |
| 无限循环 | 缺少终止条件 | 添加 TTL、迭代限制 |
| 监督者瓶颈 | 汇报太多 | 增加中间聚合器 |
指标
| 指标 | 目标 | 描述 |
|---|---|---|
| 任务完成率 | >95% | 成功完成的任务 |
| 令牌效率 | >0.5 | 输出价值 / 使用的令牌 |
| 协调开销 | <30% | 协调与工作所用令牌之比 |
| 智能体利用率 | >70% | 活跃时间与等待时间之比 |
| 错误率 | <5% | 失败的智能体间操作 |
模式选择指南
上下文窗口是否足够？是则使用单智能体；否则判断任务是否可并行。可并行时，若智能体可独立工作则使用点对点，否则使用带并行工作者的监督者。不可并行时，若存在清晰层级则使用分层，否则使用监督者/编排者。
相关技能
- memory-systems：跨会话持久化
- parallel-dispatch：并发智能体执行
- subagent-driven：任务执行模式
版本历史
1.0.0（2026-01-19）：初始版本，改编自 Agent-Skills-for-Context-Engineering。