agent-team-builder

Agent Team Builder

通过交互式需求梳理，为业务工作流设计并生成可用于生产环境的多 Agent 团队配置。此技能会生成配置文件，但不会执行或部署 Agent。

目录

• references/team-templates.md — 销售、支持、研究和内容团队的起点模板。
• references/config-schema.md — 完整的 team-config.yaml 架构及高级功能（A2A 消息传递、扩缩容、共享上下文）。
• references/output-files.md — 要生成的文件及最终回复格式。

工作流

始终先完成需求梳理，再进行设计。未了解业务流程前，绝不生成团队配置。

1. 进行需求梳理。 每次询问用户一个方面：

   • 流程名称（要自动化的内容）。
   • 当前状态（涉及哪些人员、交接点在哪里）。
   • 痛点（延迟、错误或瓶颈发生在哪里）。
   • 工作量（每天／每周／每月运行次数）。
   • 成功指标（耗时、错误率、满意度）。
   • 约束（合规要求、审批关卡、人机协同要求）。
   • 集成项（CRM、电子邮件、Slack、数据库、API）。

2. 设计团队架构。 确定所需的最少 Agent 数量（通常为 3-7 个）。按需选择角色类型：

   • Coordinator — 编排工作流、分配任务、处理异常。
   • Specialist — 在一个领域具备深入专业知识。
   • Validator — 负责质量保证、合规检查和输出审核。
   • Interface — 负责对外沟通。
   • Data — 负责检索、转换和存储数据。

   选择一种通信模式：中心辐射式（顺序执行）、流水线式（线性执行）、网状（协作式）或广播式（通知）。适用时，从 references/team-templates.md 中的模板开始。

3. 明确每个 Agent 的规范。 定义：Agent ID、角色标题、完整且可用于生产环境的系统提示词、工具访问权限（遵循最小权限原则）、输入架构、输出架构、交接规则、升级规则、成功标准和故障模式。

4. 生成配置文件。 按照 references/output-files.md 生成 team-config.yaml、每个 Agent 对应的 agents/{id}/prompt.md、workflow.md 和 test-scenarios.yaml，并遵循 references/config-schema.md。

5. 使用 references/output-files.md 中的回复格式呈现设计。

执行规则

1. 始终从需求梳理开始。
2. 遵循最小权限原则——仅向每个 Agent 授予其所需的工具和访问权限。
3. 针对故障进行设计——为每个 Agent 指定故障模式和恢复策略。
4. 保留人工参与环节——为高风险决策设置升级路径。
5. 定义可衡量的结果——为每个 Agent 设定可跟踪的成功标准。
6. 从小规模开始——建议采用 3-4 个 Agent，并根据性能数据扩展。
7. 记录所有内容——确保生成的配置具有自说明性且易于维护。
8. 生成测试场景，以便在部署前验证团队。
9. 建议在全面部署前进行试点。
10. 生成的配置中绝不包含 API 密钥、密码或机密信息；请使用环境变量引用。

生成的 team-config.yaml 旨在供 Agent 编排框架使用。请将所有生成的系统提示词视为起点，并根据实际运行表现进行优化。