用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/anbeime/skill --skill agent-team命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | agent-team |
| description | 产品经理与项目管理专家在应对复杂项目时，使用此技能可动态组建包含“执行、指挥、评审”的专属AI团队。实时查看多智能体辩论与决策全过程，共享统一上下文记忆，一键完成从会议决策到系统构建的全流程高效协同！ |
每个智能体是一个独立的角色，具备：
团队由多个智能体组成，就像一个真实的工作团队：
干活的智能体（执行层）：
指挥的智能体（管理层）：
挑毛病的智能体（评审层）：
智能体之间的讨论过程完全可见：
就像在一个真实的会议室，你能看到每个人发言、讨论、辩论的全过程。
所有智能体共享同一个数据库记忆：
确保智能体之间的信息一致，避免上下文混乱。
适用于需要多角度分析、辩论和决策的场景。
核心角色：
详见：references/meeting-agents.md
适用于一人公司从"做事→做产品→做系统"的完整流程。
核心角色：
适用于跨场景的通用协作需求。
核心角色：
详见：references/general-agents.md
根据常见任务场景，选择合适的预设团队：
场景1：技术架构决策会议
推荐团队：
- 指挥的：主持人、项目经理
- 挑毛病的：技术架构师、DevOps工程师、评审员
- 干活的：前端工程师、后端工程师
调用方式："请用技术决策团队评估[某技术方案]"
实时沟通：你会看到主持人引导讨论，各智能体发言、辩论、形成共识的全过程
场景2：OPC系统构建
推荐团队：
- 指挥的：战略分析智能体（战略）、产品架构智能体（设计）
- 干活的：自动化工程智能体（实现）
- 挑毛病的：评审员（评估）
调用方式："请用OPC团队构建[某领域]的系统"
实时沟通：你会看到三步流程中的每个环节，各智能体的输出和反馈
场景3：产品定价策略会议
推荐团队：
- 指挥的：主持人、产品经理
- 挑毛病的：市场分析师、财务顾问、评审员
- 干活的：销售总监（市场执行）
调用方式："请用产品团队制定[某产品]的定价策略"
实时沟通：你会看到市场分析、成本核算、定价讨论的全过程
场景4：完整项目执行
推荐团队：
- 指挥的：项目经理、战略分析智能体
- 挑毛病的：技术架构师、市场分析师、财务顾问、评审员
- 干活的：自动化工程智能体、前端工程师、后端工程师
调用方式："请执行[某项目]的完整流程"
实时沟通：你会看到从需求分析到技术实现的全过程，所有智能体的沟通和协作
详见：references/collaboration-templates.md
根据具体任务，手动选择需要的智能体，就像组建一个真实的项目团队：
启用实时沟通模式，完整展示智能体之间的讨论过程：
【实时沟通模式】
> 主持人：各位，我们今天讨论的主题是"评估微服务架构的可行性"。请技术架构师先从技术角度发表观点。
> 技术架构师：从架构角度看，微服务架构可以提升系统的可扩展性和可维护性。但是也存在一些问题，比如分布式事务处理、服务间通信复杂度增加。我的建议是先评估业务是否真的需要这种架构。
> DevOps工程师：从运维角度，我担心的是部署复杂度和运维成本。每个服务都需要独立部署和监控，管理成本会显著增加。建议采用容器化部署来降低复杂度。
> 前端工程师：从用户体验角度，微服务架构对前端影响不大。但是要注意API的接口一致性，避免不同服务返回格式不统一的问题。
> 主持人：技术架构师提到了"先评估业务需求"，能否具体说明评估标准？
> 技术架构师：评估标准包括：1）业务规模是否需要横向扩展；2）团队规模是否能支撑多个服务的开发；3）是否有足够的运维能力。
> 评审员：基于以上讨论，我评估这个方案的可行性。技术上可行，但运维成本较高。建议先在小范围试点，验证可行性后再推广。
> 主持人：经过讨论，我们达成了以下共识：1）采用微服务架构；2）先试点核心服务；3）使用容器化部署；4）小范围验证后再推广。
> 记录员：我已记录下完整的讨论过程和决策内容。
开启实时沟通模式，你会看到完整的讨论过程，就像在真实的会议室！
串行协作：智能体按顺序依次处理
智能体A → 输出 → 智能体B → 输出 → 智能体C → 最终结果
适用于：OPC系统构建、分阶段决策
并行协作：多个智能体同时处理，然后汇总
智能体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。那我来设计前端组件结构。
> 评审员：查看决策历史（访问共享记忆），之前的技术选型是否还有优化空间？
> 主持人：基于当前的项目状态（访问共享记忆），我们正在进行技术架构设计阶段，接下来进入产品架构设计阶段。
详见：assets/agent-templates/new-agent-template.md
任务分析
团队组建
协作设计
任务执行
结果输出
任务："我想在AI短视频领域构建一个OPC系统"
团队配置：战略分析智能体 + 产品架构智能体 + 自动化工程智能体
协作流程：
1. 战略分析智能体
- 分析AI短视频领域
- 输出：TOP3产品化机会
2. 产品架构智能体（基于战略分析的输出）
- 针对优先级最高的机会设计产品架构
- 输出：模块化产品蓝图
3. 自动化工程智能体（基于产品架构的输出）
- 实现核心模块
- 输出：可运行代码和部署指南
最终交付：完整的技术方案和MVP代码
任务："评估是否采用微服务架构"
团队配置：技术架构师 + DevOps工程师 + 前端工程师 + 后端工程师 + CTO
协作流程：
1. 开场发言：各智能体从各自专业角度陈述观点
2. 自由讨论：智能体相互质疑、补充、辩论
3. 深入辩论：针对争议焦点展开针对性讨论
4. 共识收敛：总结各方观点，探索折中方案
5. 决策生成：综合各方意见形成决策结论
最终交付：包含技术论辩、成本分析、风险评估的完整会议记录
任务："评估AI短视频脚本生成系统的可行性"
团队配置：战略分析智能体 + 技术架构师 + 产品经理 + 市场分析师
协作流程：
1. 并行分析（战略分析智能体 + 市场分析师）
- 战略分析：识别市场机会
- 市场分析：竞品和用户需求
2. 汇总输入（产品经理）
- 整合市场分析结果
- 定义产品需求
3. 技术评估（技术架构师）
- 评估技术可行性
- 输出技术方案
4. 循环讨论（所有智能体）
- 技术架构师质疑市场需求的合理性
- 产品经理补充产品细节
- 市场分析师反馈用户预期
- 收敛到共识
最终交付：包含市场分析、产品设计、技术方案的完整可行性报告
最适合：
不太适合：