技能介绍

解决什么问题

设计多智能体系统时，最容易出问题的往往不是单个 agent 的 prompt，而是架构层：多个 agent 该串行、并行还是分层？消息如何传递？工具 schema 谁来校验？上线后又该从哪份日志计算成功率、延迟、成本与瓶颈？凭感觉拍板的后果很常见——层级过多让通信开销吃掉收益，或者 fan-out 之后无人做共识裁决，出错时根本查不动。

工作方式

这个技能把流程拆成三个确定性工具，上一步的 JSON 输出就是下一步的设计输入：

设计架构：先写一份 requirements JSON（goal、tasks[]、constraints{max_response_time, budget_per_task, concurrent_tasks}、team_size），脚本输出 arch.json，包含 pattern、agents、通信链路、mermaid 图与实现路线图。pattern 由决策表确定：单一有界任务适合 Single agent；并行同侪、以容错优先于可预测性时适合 Swarm，但要为调试和共识规则留预算。
生成工具 schema：用自然语言描述每个 agent 的工具，产出 tools.json 以及 Anthropic / OpenAI 两种 provider 格式。此步有硬门槛——每个工具必须打印 ✓ Valid；校验不通过就修，绝不把未验证的 schema 交给 agent。
评估执行日志：系统上线后（或先用 sample_execution_logs.json 空跑）输出 eval.json，覆盖 summary、agentmetrics、bottleneckanalysis、erroranalysis、costbreakdown、slacompliance 与 optimizationrecommendations，并拆分出错误与建议文件。

设计完成前还要通过验证闭环：schema 校验 0 invalid；pilot 评估打印 CRITICAL: 0（大于 0 就取 eval_recommendations.json 的首项修复后重跑）；最后对照 expected_outputs/ 确认 schema 形态没有漂移。三份 references/ 文档分别说明 pattern 取舍、schema / 幂等 / 错误处理规则，以及评估器实现的指标定义。

适用边界

需要设计新架构、从工具描述生成 provider 就绪的 schema，或评估执行日志时可以使用。Claude Code 的 workflow 自动化请用 workflow-builder，单 agent 脚手架请用 agent-workflow-designer，运行时多 agent fan-out 请用 agenthub。它也不会自动安装依赖、修改系统权限、创建持久任务或执行下载内容；涉及发送、发布、删除、付款、部署等外部写入时，会先展示目标与影响并等待确认。