agent-team skill | PlugMCP
Skip to content Install The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add anbeime/skill --skill agent-team -a cursor -y Copy Download skill skills/agent-team/agent-team/SKILL.md on GitHub SKILL.md About FAQ
产品经理与项目管理专家在应对复杂项目时，使用此技能可动态组建包含“执行、指挥、评审”的专属AI团队。实时查看多智能体辩论与决策全过程，共享统一上下文记忆，一键完成从会议决策到系统构建的全流程高效协同！
name: agent-team
description: 产品经理与项目管理专家在应对复杂项目时，使用此技能可动态组建包含“执行、指挥、评审”的专属AI团队。实时查看多智能体辩论与决策全过程，共享统一上下文记忆，一键完成从会议决策到系统构建的全流程高效协同！
智能体团队协作框架
任务目标
本Skill用于：统一管理和灵活组合多个智能体角色，组建任务导向的智能体团队
能力包含：智能体注册、动态组队、协作流程、角色扩展、共享记忆、实时沟通
触发条件：当需要多个智能体协同完成任务时，或需要管理特定场景的智能体组合时
核心概念：忙碌的AI团队公司
智能体即角色
每个智能体是一个独立的角色，具备：
角色定位 ：明确的职责和专业领域能力特征 ：专业知识和性格特点协作接口 ：与其他智能体协作的方式输出规范 ：标准化的输出格式
智能体团队：一个忙碌的一人AI团队公司
团队由多个智能体组成，就像一个真实的工作团队：
角色分工明确
干活的智能体 （执行层）：
自动化工程智能体：实现技术方案、生成代码、部署系统
前端/后端工程师：编写代码、实现功能
数据分析师：处理数据、生成报告
运营专家：执行运营策略、优化流程
指挥的智能体 （管理层）：
主持人：引导讨论流程、控制节奏
项目经理：制定计划、分配任务、跟踪进度
战略分析智能体：制定战略、规划方向
产品经理：定义产品、规划路线图
挑毛病的智能体 （评审层）：
评审员：评估质量、发现问题、提供建议
技术架构师：评审架构、指出风险
市场分析师：评审方案、指出市场问题
财务顾问：评审成本、指出财务风险
实时沟通可见
智能体之间的讨论过程完全可见：
plugmcp Plug any tool into any agent. MCP servers for people who do not write servers. Gateway for volume, n8n for apps.
PlugMCP, 2026
✅ 实时显示发言过程
✅ 记录每个智能体的观点
✅ 展示辩论和争论
✅ 显示共识和分歧
✅ 记录决策过程 就像在一个真实的会议室，你能看到每个人发言、讨论、辩论的全过程。
共享数据库记忆
✅ 统一的上下文信息
✅ 共享的项目状态
✅ 一致的决策历史
✅ 统一的知识库
✅ 不会前言不搭后语
团队特点
动态组合 ：根据任务需求选择合适的智能体灵活协作 ：智能体之间可以相互调用和补充可扩展 ：随时添加新的智能体角色场景化 ：常见场景有预设团队配置实时沟通 ：完整展示智能体之间的讨论过程共享记忆 ：统一的数据库记忆，确保上下文一致
智能体分类
1. 会议决策类智能体
技术架构师：系统架构、技术选型
DevOps工程师：部署运维、稳定性
前端/后端工程师：用户体验/业务逻辑
产品经理：产品规划、用户需求
市场分析师：市场调研、竞品分析
财务顾问：成本控制、财务分析
项目经理：进度管理、资源协调
2. OPC系统构建类智能体 适用于一人公司从"做事→做产品→做系统"的完整流程。
战略分析智能体：市场扫描、需求分析、机会识别
产品架构智能体：产品设计、模块化封装、技术选型
自动化工程智能体：流程设计、技术实现、系统集成
3. 通用协作智能体
主持人：引导讨论流程、总结共识
记录员：整理讨论内容、生成会议记录
评审员：评估方案质量、提供改进建议
协调员：解决冲突、促进协作
快速启动
方式一：使用预设团队配置 推荐团队：
- 指挥的：主持人、项目经理
- 挑毛病的：技术架构师、DevOps工程师、评审员
- 干活的：前端工程师、后端工程师
调用方式："请用技术决策团队评估[某技术方案]"
实时沟通：你会看到主持人引导讨论，各智能体发言、辩论、形成共识的全过程
推荐团队：
- 指挥的：战略分析智能体（战略）、产品架构智能体（设计）
- 干活的：自动化工程智能体（实现）
- 挑毛病的：评审员（评估）
调用方式："请用OPC团队构建[某领域]的系统"
实时沟通：你会看到三步流程中的每个环节，各智能体的输出和反馈
推荐团队：
- 指挥的：主持人、产品经理
- 挑毛病的：市场分析师、财务顾问、评审员
- 干活的：销售总监（市场执行）
调用方式："请用产品团队制定[某产品]的定价策略"
实时沟通：你会看到市场分析、成本核算、定价讨论的全过程
推荐团队：
- 指挥的：项目经理、战略分析智能体
- 挑毛病的：技术架构师、市场分析师、财务顾问、评审员
- 干活的：自动化工程智能体、前端工程师、后端工程师
调用方式："请执行[某项目]的完整流程"
实时沟通：你会看到从需求分析到技术实现的全过程，所有智能体的沟通和协作
方式二：自定义团队组合 根据具体任务，手动选择需要的智能体，就像组建一个真实的项目团队：
查看可用智能体 ：使用 references/agent-registry.md 浏览所有智能体选择智能体 ：根据任务需求选择智能体
指挥的：选择1-2个管理型智能体
挑毛病的：选择1-3个评审型智能体
干活的：选择1-3个执行型智能体
定义协作流程 ：明确智能体之间的协作顺序和方式执行任务 ：智能体按协作流程协同完成任务实时观察 ：查看智能体之间的实时沟通过程
方式三：实时沟通模式 【实时沟通模式】
> 主持人：各位，我们今天讨论的主题是"评估微服务架构的可行性"。请技术架构师先从技术角度发表观点。
> 技术架构师：从架构角度看，微服务架构可以提升系统的可扩展性和可维护性。但是也存在一些问题，比如分布式事务处理、服务间通信复杂度增加。我的建议是先评估业务是否真的需要这种架构。
> DevOps工程师：从运维角度，我担心的是部署复杂度和运维成本。每个服务都需要独立部署和监控，管理成本会显著增加。建议采用容器化部署来降低复杂度。
> 前端工程师：从用户体验角度，微服务架构对前端影响不大。但是要注意API的接口一致性，避免不同服务返回格式不统一的问题。
> 主持人：技术架构师提到了"先评估业务需求"，能否具体说明评估标准？
> 技术架构师：评估标准包括：1）业务规模是否需要横向扩展；2）团队规模是否能支撑多个服务的开发；3）是否有足够的运维能力。
> 评审员：基于以上讨论，我评估这个方案的可行性。技术上可行，但运维成本较高。建议先在小范围试点，验证可行性后再推广。
> 主持人：经过讨论，我们达成了以下共识：1）采用微服务架构；2）先试点核心服务；3）使用容器化部署；4）小范围验证后再推广。
> 记录员：我已记录下完整的讨论过程和决策内容。
开启实时沟通模式，你会看到完整的讨论过程，就像在真实的会议室！
智能体协作流程
标准协作模式 智能体A → 输出 → 智能体B → 输出 → 智能体C → 最终结果
智能体A ──┐
├→ 汇总整合 → 最终结果
智能体B ──┘
智能体A ⟷ 智能体B ⟷ 智能体C
↓
收敛到共识
[智能体A、B并行] → 汇总 → 智能C → 智体D循环讨论 → 最终结果
协作原则
清晰的角色边界 ：每个智能体明确自己的职责范围标准化的输出格式 ：智能体之间使用统一的数据格式明确的协作协议 ：定义智能体如何调用和响应反馈循环机制 ：支持智能体之间相互反馈和迭代降级处理方案 ：当某个智能体失败时，有备用方案共享数据库记忆 ：所有智能体共享同一个数据库，确保上下文一致
共享数据库记忆
记忆机制 所有智能体共享同一个数据库记忆，就像一个真实团队的共享知识库：
{
"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}
}
]
}
记忆的优势
上下文一致 ：所有智能体看到相同的信息，不会前言不搭后语避免重复 ：已讨论过的内容不需要重复讨论便于追踪 ：可以查看决策历史和讨论过程支持回溯 ：可以随时查看之前的知识和决策团队协同 ：所有智能体像在同一个办公室工作
记忆访问示例 > 技术架构师：基于之前的讨论（访问共享记忆），我们已经决定采用微服务架构。现在我来详细设计服务拆分方案。
> 前端工程师：我记得之前的决策（访问共享记忆）是要使用Vue 3。那我来设计前端组件结构。
> 评审员：查看决策历史（访问共享记忆），之前的技术选型是否还有优化空间？
> 主持人：基于当前的项目状态（访问共享记忆），我们正在进行技术架构设计阶段，接下来进入产品架构设计阶段。
扩展新智能体
添加新角色的步骤
资源索引
智能体注册表
智能体详细定义
协作模板
智能体模板
操作步骤
标准流程
任务分析
明确任务目标和约束条件
识别任务所需的专业领域和视角
评估任务的复杂度和阶段划分
团队组建
协作设计
定义智能体之间的协作模式（串行/并行/循环/混合）
设计协作流程和输出格式
确定共识收敛方式
任务执行
智能体按协作流程协同完成任务
记录中间输出和讨论过程
支持迭代和调整
结果输出
汇总各智能体的输出
生成统一的任务结果
记录协作过程和关键决策
可选分支
当任务简单 ：直接使用单个智能体完成任务当时间紧急 ：使用预设团队配置，快速启动当需要深入讨论 ：采用循环协作模式，多轮迭代当智能体失效 ：使用降级方案，或替换为备用智能体
使用示例
示例1：完整OPC系统构建 团队配置 ：战略分析智能体 + 产品架构智能体 + 自动化工程智能体
1. 战略分析智能体
- 分析AI短视频领域
- 输出：TOP3产品化机会
2. 产品架构智能体（基于战略分析的输出）
- 针对优先级最高的机会设计产品架构
- 输出：模块化产品蓝图
3. 自动化工程智能体（基于产品架构的输出）
- 实现核心模块
- 输出：可运行代码和部署指南
示例2：技术架构决策会议 团队配置 ：技术架构师 + DevOps工程师 + 前端工程师 + 后端工程师 + CTO
1. 开场发言：各智能体从各自专业角度陈述观点
2. 自由讨论：智能体相互质疑、补充、辩论
3. 深入辩论：针对争议焦点展开针对性讨论
4. 共识收敛：总结各方观点，探索折中方案
5. 决策生成：综合各方意见形成决策结论
最终交付 ：包含技术论辩、成本分析、风险评估的完整会议记录
示例3：混合协作场景 团队配置 ：战略分析智能体 + 技术架构师 + 产品经理 + 市场分析师
1. 并行分析（战略分析智能体 + 市场分析师）
- 战略分析：识别市场机会
- 市场分析：竞品和用户需求
2. 汇总输入（产品经理）
- 整合市场分析结果
- 定义产品需求
3. 技术评估（技术架构师）
- 评估技术可行性
- 输出技术方案
4. 循环讨论（所有智能体）
- 技术架构师质疑市场需求的合理性
- 产品经理补充产品细节
- 市场分析师反馈用户预期
- 收敛到共识
最终交付 ：包含市场分析、产品设计、技术方案的完整可行性报告
注意事项
智能体数量适中 ：3-6个智能体为宜，过多会导致协作复杂角色边界清晰 ：每个智能体明确自己的职责，避免职责重叠输出格式统一 ：智能体之间使用统一的数据格式，便于信息传递支持降级处理 ：当某个智能体失效时，有备用方案保证任务继续迭代优化 ：根据协作效果，不断优化智能体定义和协作流程充分利用智能体能力 ：智能体具备分析、创作、推理能力，无需为简单任务编写脚本
适用场景
需要多专业领域协作的复杂任务
需要多角度分析和决策的场景
需要系统化构建OPC场景
需要灵活组建团队应对不同任务
简单单一智能体可完成的任务
需要实时互动和即时响应的场景
完全依赖人工判断的非结构化任务
How do I install agent-team? Download skills/agent-team/agent-team/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does agent-team live? The publisher keeps it at https://github.com/anbeime/skill.
Which agents can use agent-team? Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.