agent-team

SKILL.md

智能体团队协作框架

任务目标

  • 本Skill用于:统一管理和灵活组合多个智能体角色,组建任务导向的智能体团队
  • 能力包含:智能体注册、动态组队、协作流程、角色扩展、共享记忆、实时沟通
  • 触发条件:当需要多个智能体协同完成任务时,或需要管理特定场景的智能体组合时

核心概念:忙碌的AI团队公司

智能体即角色

每个智能体是一个独立的角色,具备:

  • 角色定位:明确的职责和专业领域
  • 能力特征:专业知识和性格特点
  • 协作接口:与其他智能体协作的方式
  • 输出规范:标准化的输出格式

智能体团队:一个忙碌的一人AI团队公司

团队由多个智能体组成,就像一个真实的工作团队:

角色分工明确

干活的智能体(执行层):

  • 自动化工程智能体:实现技术方案、生成代码、部署系统
  • 前端/后端工程师:编写代码、实现功能
  • 数据分析师:处理数据、生成报告
  • 运营专家:执行运营策略、优化流程

指挥的智能体(管理层):

  • 主持人:引导讨论流程、控制节奏
  • 项目经理:制定计划、分配任务、跟踪进度
  • 战略分析智能体:制定战略、规划方向
  • 产品经理:定义产品、规划路线图

挑毛病的智能体(评审层):

  • 评审员:评估质量、发现问题、提供建议
  • 技术架构师:评审架构、指出风险
  • 市场分析师:评审方案、指出市场问题
  • 财务顾问:评审成本、指出财务风险

实时沟通可见

智能体之间的讨论过程完全可见:

  • ✅ 实时显示发言过程
  • ✅ 记录每个智能体的观点
  • ✅ 展示辩论和争论
  • ✅ 显示共识和分歧
  • ✅ 记录决策过程

就像在一个真实的会议室,你能看到每个人发言、讨论、辩论的全过程。

共享数据库记忆

所有智能体共享同一个数据库记忆:

  • ✅ 统一的上下文信息
  • ✅ 共享的项目状态
  • ✅ 一致的决策历史
  • ✅ 统一的知识库
  • ✅ 不会前言不搭后语

确保智能体之间的信息一致,避免上下文混乱。

团队特点

  • 动态组合:根据任务需求选择合适的智能体
  • 灵活协作:智能体之间可以相互调用和补充
  • 可扩展:随时添加新的智能体角色
  • 场景化:常见场景有预设团队配置
  • 实时沟通:完整展示智能体之间的讨论过程
  • 共享记忆:统一的数据库记忆,确保上下文一致

智能体分类

1. 会议决策类智能体

适用于需要多角度分析、辩论和决策的场景。

核心角色

  • 技术架构师:系统架构、技术选型
  • DevOps工程师:部署运维、稳定性
  • 前端/后端工程师:用户体验/业务逻辑
  • 产品经理:产品规划、用户需求
  • 市场分析师:市场调研、竞品分析
  • 财务顾问:成本控制、财务分析
  • 项目经理:进度管理、资源协调

详见:references/meeting-agents.md

2. OPC系统构建类智能体

适用于一人公司从"做事→做产品→做系统"的完整流程。

核心角色

  • 战略分析智能体:市场扫描、需求分析、机会识别
  • 产品架构智能体:产品设计、模块化封装、技术选型
  • 自动化工程智能体:流程设计、技术实现、系统集成

详见:references/opc-agents.md

3. 通用协作智能体

适用于跨场景的通用协作需求。

核心角色

  • 主持人:引导讨论流程、总结共识
  • 记录员:整理讨论内容、生成会议记录
  • 评审员:评估方案质量、提供改进建议
  • 协调员:解决冲突、促进协作

详见:references/general-agents.md

快速启动

方式一:使用预设团队配置

根据常见任务场景,选择合适的预设团队:

场景1:技术架构决策会议

推荐团队:
- 指挥的:主持人、项目经理
- 挑毛病的:技术架构师、DevOps工程师、评审员
- 干活的:前端工程师、后端工程师

调用方式:"请用技术决策团队评估[某技术方案]"
实时沟通:你会看到主持人引导讨论,各智能体发言、辩论、形成共识的全过程

场景2:OPC系统构建

推荐团队:
- 指挥的:战略分析智能体(战略)、产品架构智能体(设计)
- 干活的:自动化工程智能体(实现)
- 挑毛病的:评审员(评估)

调用方式:"请用OPC团队构建[某领域]的系统"
实时沟通:你会看到三步流程中的每个环节,各智能体的输出和反馈

场景3:产品定价策略会议

推荐团队:
- 指挥的:主持人、产品经理
- 挑毛病的:市场分析师、财务顾问、评审员
- 干活的:销售总监(市场执行)

调用方式:"请用产品团队制定[某产品]的定价策略"
实时沟通:你会看到市场分析、成本核算、定价讨论的全过程

场景4:完整项目执行

推荐团队:
- 指挥的:项目经理、战略分析智能体
- 挑毛病的:技术架构师、市场分析师、财务顾问、评审员
- 干活的:自动化工程智能体、前端工程师、后端工程师

调用方式:"请执行[某项目]的完整流程"
实时沟通:你会看到从需求分析到技术实现的全过程,所有智能体的沟通和协作

详见:references/collaboration-templates.md

方式二:自定义团队组合

根据具体任务,手动选择需要的智能体,就像组建一个真实的项目团队:

  1. 查看可用智能体:使用 references/agent-registry.md 浏览所有智能体
  2. 选择智能体:根据任务需求选择智能体
    • 指挥的:选择1-2个管理型智能体
    • 挑毛病的:选择1-3个评审型智能体
    • 干活的:选择1-3个执行型智能体
  3. 定义协作流程:明确智能体之间的协作顺序和方式
  4. 执行任务:智能体按协作流程协同完成任务
  5. 实时观察:查看智能体之间的实时沟通过程

方式三:实时沟通模式

启用实时沟通模式,完整展示智能体之间的讨论过程:

【实时沟通模式】

> 主持人:各位,我们今天讨论的主题是"评估微服务架构的可行性"。请技术架构师先从技术角度发表观点。

> 技术架构师:从架构角度看,微服务架构可以提升系统的可扩展性和可维护性。但是也存在一些问题,比如分布式事务处理、服务间通信复杂度增加。我的建议是先评估业务是否真的需要这种架构。

> DevOps工程师:从运维角度,我担心的是部署复杂度和运维成本。每个服务都需要独立部署和监控,管理成本会显著增加。建议采用容器化部署来降低复杂度。

> 前端工程师:从用户体验角度,微服务架构对前端影响不大。但是要注意API的接口一致性,避免不同服务返回格式不统一的问题。

> 主持人:技术架构师提到了"先评估业务需求",能否具体说明评估标准?

> 技术架构师:评估标准包括:1)业务规模是否需要横向扩展;2)团队规模是否能支撑多个服务的开发;3)是否有足够的运维能力。

> 评审员:基于以上讨论,我评估这个方案的可行性。技术上可行,但运维成本较高。建议先在小范围试点,验证可行性后再推广。

> 主持人:经过讨论,我们达成了以下共识:1)采用微服务架构;2)先试点核心服务;3)使用容器化部署;4)小范围验证后再推广。

> 记录员:我已记录下完整的讨论过程和决策内容。

开启实时沟通模式,你会看到完整的讨论过程,就像在真实的会议室!

智能体协作流程

标准协作模式

串行协作:智能体按顺序依次处理

智能体A → 输出 → 智能体B → 输出 → 智能体C → 最终结果

适用于:OPC系统构建、分阶段决策

并行协作:多个智能体同时处理,然后汇总

智能体A ──┐
           ├→ 汇总整合 → 最终结果
智能体B ──┘

适用于:多角度分析、竞品对比

循环协作:智能体之间反复讨论和迭代

智能体A ⟷ 智能体B ⟷ 智能体C
   收敛到共识

适用于:会议决策、方案优化

混合协作:结合上述多种模式

[智能体A、B并行] → 汇总 → 智能C → 智体D循环讨论 → 最终结果

适用于:复杂任务、多阶段流程

协作原则

  1. 清晰的角色边界:每个智能体明确自己的职责范围
  2. 标准化的输出格式:智能体之间使用统一的数据格式
  3. 明确的协作协议:定义智能体如何调用和响应
  4. 反馈循环机制:支持智能体之间相互反馈和迭代
  5. 降级处理方案:当某个智能体失败时,有备用方案
  6. 共享数据库记忆:所有智能体共享同一个数据库,确保上下文一致

共享数据库记忆

记忆机制

所有智能体共享同一个数据库记忆,就像一个真实团队的共享知识库:

统一上下文信息

{
  "project_context": {
    "project_name": "AI脚本生成器",
    "current_stage": "技术架构设计",
    "participants": ["技术架构师", "DevOps工程师", "前端工程师"],
    "decisions_made": [
      "采用微服务架构",
      "使用Vue 3 + FastAPI技术栈"
    ]
  }
}

共享知识库

{
  "knowledge_base": {
    "technical_standards": {
      "api_format": "RESTful",
      "database": "PostgreSQL",
      "deployment": "Docker"
    },
    "business_goals": {
      "primary_goal": "1分钟生成3个脚本",
      "secondary_goals": ["支持多平台", "降低成本"]
    }
  }
}

决策历史

{
  "decision_history": [
    {
      "timestamp": "2024-01-01T10:00:00Z",
      "decision": "采用微服务架构",
      "reason": "提升可扩展性",
      "participants": ["技术架构师", "DevOps工程师"],
      "voting": {"support": 3, "oppose": 1, "abstain": 0}
    }
  ]
}

记忆的优势

  1. 上下文一致:所有智能体看到相同的信息,不会前言不搭后语
  2. 避免重复:已讨论过的内容不需要重复讨论
  3. 便于追踪:可以查看决策历史和讨论过程
  4. 支持回溯:可以随时查看之前的知识和决策
  5. 团队协同:所有智能体像在同一个办公室工作

记忆访问示例

智能体可以随时访问共享记忆,确保沟通连贯:

> 技术架构师:基于之前的讨论(访问共享记忆),我们已经决定采用微服务架构。现在我来详细设计服务拆分方案。

> 前端工程师:我记得之前的决策(访问共享记忆)是要使用Vue 3。那我来设计前端组件结构。

> 评审员:查看决策历史(访问共享记忆),之前的技术选型是否还有优化空间?

> 主持人:基于当前的项目状态(访问共享记忆),我们正在进行技术架构设计阶段,接下来进入产品架构设计阶段。

扩展新智能体

添加新角色的步骤

  1. 定义角色:明确智能体的定位、职责和能力
  2. 编写模板:使用 assets/agent-templates/ 中的模板
  3. 注册智能体:在 references/agent-registry.md 中添加
  4. 设计协作接口:定义与其他智能体的协作方式
  5. 测试验证:验证智能体能否正常协作

详见:assets/agent-templates/new-agent-template.md

资源索引

智能体注册表

  • references/agent-registry.md
    • 所有可用智能体的完整列表
    • 智能体的分类、定位和能力描述
    • 何时读取:需要选择智能体组建团队时

智能体详细定义

协作模板

智能体模板

操作步骤

标准流程

  1. 任务分析

    • 明确任务目标和约束条件
    • 识别任务所需的专业领域和视角
    • 评估任务的复杂度和阶段划分
  2. 团队组建

  3. 协作设计

    • 定义智能体之间的协作模式(串行/并行/循环/混合)
    • 设计协作流程和输出格式
    • 确定共识收敛方式
  4. 任务执行

    • 智能体按协作流程协同完成任务
    • 记录中间输出和讨论过程
    • 支持迭代和调整
  5. 结果输出

    • 汇总各智能体的输出
    • 生成统一的任务结果
    • 记录协作过程和关键决策

可选分支

  • 当任务简单:直接使用单个智能体完成任务
  • 当时间紧急:使用预设团队配置,快速启动
  • 当需要深入讨论:采用循环协作模式,多轮迭代
  • 当智能体失效:使用降级方案,或替换为备用智能体

使用示例

示例1:完整OPC系统构建

任务:"我想在AI短视频领域构建一个OPC系统"

团队配置:战略分析智能体 + 产品架构智能体 + 自动化工程智能体

协作流程

1. 战略分析智能体
   - 分析AI短视频领域
   - 输出:TOP3产品化机会

2. 产品架构智能体(基于战略分析的输出)
   - 针对优先级最高的机会设计产品架构
   - 输出:模块化产品蓝图

3. 自动化工程智能体(基于产品架构的输出)
   - 实现核心模块
   - 输出:可运行代码和部署指南

最终交付:完整的技术方案和MVP代码

示例2:技术架构决策会议

任务:"评估是否采用微服务架构"

团队配置:技术架构师 + DevOps工程师 + 前端工程师 + 后端工程师 + CTO

协作流程

1. 开场发言:各智能体从各自专业角度陈述观点
2. 自由讨论:智能体相互质疑、补充、辩论
3. 深入辩论:针对争议焦点展开针对性讨论
4. 共识收敛:总结各方观点,探索折中方案
5. 决策生成:综合各方意见形成决策结论

最终交付:包含技术论辩、成本分析、风险评估的完整会议记录

示例3:混合协作场景

任务:"评估AI短视频脚本生成系统的可行性"

团队配置:战略分析智能体 + 技术架构师 + 产品经理 + 市场分析师

协作流程

1. 并行分析(战略分析智能体 + 市场分析师)
   - 战略分析:识别市场机会
   - 市场分析:竞品和用户需求

2. 汇总输入(产品经理)
   - 整合市场分析结果
   - 定义产品需求

3. 技术评估(技术架构师)
   - 评估技术可行性
   - 输出技术方案

4. 循环讨论(所有智能体)
   - 技术架构师质疑市场需求的合理性
   - 产品经理补充产品细节
   - 市场分析师反馈用户预期
   - 收敛到共识

最终交付:包含市场分析、产品设计、技术方案的完整可行性报告

注意事项

  • 智能体数量适中:3-6个智能体为宜,过多会导致协作复杂
  • 角色边界清晰:每个智能体明确自己的职责,避免职责重叠
  • 输出格式统一:智能体之间使用统一的数据格式,便于信息传递
  • 支持降级处理:当某个智能体失效时,有备用方案保证任务继续
  • 迭代优化:根据协作效果,不断优化智能体定义和协作流程
  • 充分利用智能体能力:智能体具备分析、创作、推理能力,无需为简单任务编写脚本

适用场景

最适合

  • 需要多专业领域协作的复杂任务
  • 需要多角度分析和决策的场景
  • 需要系统化构建OPC场景
  • 需要灵活组建团队应对不同任务

不太适合

  • 简单单一智能体可完成的任务
  • 需要实时互动和即时响应的场景
  • 完全依赖人工判断的非结构化任务
Weekly Installs
1
First Seen
2 days ago
Installed on
amp1
cline1
openclaw1
opencode1
cursor1
kimi-cli1