基于 Agent Teams 全栈实践个人网站开发【二】_Agent团队搭建篇文章目录基于 Agent Teams 全栈实践个人网站开发【二】_Agent团队搭建篇如何通过 Skills 构建 Agent Teams 的角色能力发装备的逻辑角色配置矩阵零基础构建完整 Agent 三条路径解析路径一推荐新手/create-subagent交互式引导路径二有想法未组织一句话启动 迭代补全路径三已有规划配置矩阵 批量生成对比汇总表/create-subagent交互式引导方式创建产品 Agent一、 Qoder通过/create-subagent命令创建产品 Agent二、product-manager.md结果三、添加技能、工作流通过角色配置矩阵批量创建 Agent以产品 Agent 为例说明创建一个agent需要注意的事项Qoder 主会话设计点1. 设计点・不包含什么 包含什么2.设计点・开放问题是强制决策3.设计点・Skills 配套逻辑注意事项装备配置的核心逻辑六个角色全部配装完毕数字人团队如何交流通信协议与任务调度机制_单兵对比提出问题三个待解决协作问题业界协议全景三层互补叠加第一层・MCP第二层・A2A第三层・编排总结我们的方案subagent-driven派发模板为什么必须结构化Anthropic 踩过的坑现象一跑偏年份现象二重复劳动现象三没有分工Anthropic 的教训原文业界六种编排模式全景我们怎么选主・辅・质检 三重套一、三层架构详情1. 主模式Orchestrator-Worker编排者 - 工人2. 辅模式Fan-out / Fan-in扇出 / 扇入3. 质检环节Reflection反思思想二、选型答疑为什么不用对话式和图式三、任务执行节奏划分串行节点必须排队执行并行节点可同时运行并行隔离git worktree 一工地三施工区三大并行开发痛点实操命令代码块using-git-worktrees Skill一个工地三个施工区质检二阶段评审 Maker‑Checker第一阶段Spec 合规评审spec‑reviewer 执行双向对账第二阶段代码质量评审测试 Agent 执行 Playwright 端到端 E2E 测试业界模式说明Maker‑Checker生产者‑校验者完整调度泳道图——CEO 三次决策清晰可见单兵 vs 团队决策清单一、维度对比表二、核心理念提炼三、四类适配场景选型指南场景 1时长2 分钟 → 优先单 Agent 单兵作战场景 2强依赖运行时输出 → 优先单 Agent场景 3全局重构类任务 → 不适合多 Agent场景 4Token 成本敏感业务 → 谨慎使用多 Agent如何通过 Skills 构建 Agent Teams 的角色能力发装备的逻辑角色配置矩阵核心原则按岗位职责匹配专属工具能力不配置通用全能工具每个 Agent 只装备适配自身业务的技能与约束规则从源头避免跨岗越权、职责混淆。角色Skills专属技能Rules约束规则岗位价值解读产品 Agent头脑风暴brainstorming、方案编写writing-plansspec-driven-workflow规约驱动工作流聚焦需求研讨、输出标准 Spec 文档是整条流水线的契约制定者交互 Agent方案编写writing-plans前端规范frontend-conventions、样式规范styling-conventions承接产品 Spec输出页面交互方案对齐前端视觉与交互标准前端 Agent测试驱动开发test-driven-development、执行落地executing-plans前端规范frontend-conventions、样式规范styling-conventions依照交互方案完成页面编码以 TDD 模式保障前端代码质量后端 Agent测试驱动开发test-driven-development、执行落地executing-plans后端 / 数据库 / API 规范backend·database·api-conventions负责接口、数据表、服务逻辑开发单独遵循后端专属技术规范测试 Agent测试驱动开发test-driven-development、完工校验verification-before-completionAPI 规范api-conventions接口层专项验收在项目交付前完成全量校验拦截缺陷体验 Agent完工校验verification-before-completion前端规范frontend-conventions、样式规范styling-conventions站在用户视角验收页面视觉、交互手感补全测试未覆盖的体验问题全员共享子 Agent 协作开发subagent-driven-development编码通用规范coding-conventions所有角色统一协作格式、统一编码底线原则最后一行是公共语言subagent-driven-development同一个交接单格式 coding-conventions同一套底线 YAGNI/DRY/TDD。零基础构建完整 Agent 三条路径解析路径一推荐新手/create-subagent交互式引导运行逻辑系统像面试官逐层提问用户仅需回答 5–6 句简短表述Qoder 自动整理输出规范完整的角色文件适配完全零基础人群。路径二有想法未组织一句话启动 迭代补全运行逻辑先用一句话描述需求再通过 3–4 轮对话逐步补充输出格式、角色权限、排除边界等约束条件迭代打磨让 Agent 质量趋近完善适合思路零散、不会结构化梳理需求的使用者。路径三已有规划配置矩阵 批量生成运行逻辑将前文的角色配置矩阵提交给 Qoder仅一条指令即可一次性生成六个角色的全部配套文件面向前期规划完备、追求批量高效落地的使用者。对比汇总表路径适配人群用户投入成本AI 交付成果/create-subagent交互式引导零基础回答 5–6 个短问题完整角色文件一句话 迭代补全有想法但不会结构化梳理3–4 轮对话打磨逐步迭代逼近高质量成品矩阵 批量生成已有完整规划思路输入一条指令一次性产出全部角色文件无需刻意学习撰写超长 Prompt核心能力是清晰描述你想要的 Agent 角色定位、岗位职责把 “讲清人物画像” 放在首位即可落地。/create-subagent交互式引导方式创建产品 Agent一、 Qoder通过/create-subagent命令创建产品 Agent二、product-manager.md结果三、添加技能、工作流通过角色配置矩阵批量创建 Agent以产品 Agent 为例说明创建一个agent需要注意的事项Qoder 主会话你: /create-subagent Qoder: 角色名称 你: product-manager Qoder: 角色职责 你接收一句话需求输出 PRD 与用户故事 Qoder: 输出格式 你功能概述 / 用户故事 / 边界清单 / 开放问题 Qoder: 加载哪些 Skills? 你: brainstorming, writing-plans Qoder: 加载哪些 Rules? 你: spec-driven-workflow Qoder: 工具授权 你只读 —ReadGrepGlob → 自动生成 product-manager.md设计点1. 设计点・不包含什么 包含什么“不做什么” 直接决定后续 Spec 边界。不写 Agent 自由发挥、悄悄加功能。2.设计点・开放问题是强制决策让 AI 把 “假设点” 显式列出强制你拍板而不是偶然发现他替你做了决定。3.设计点・Skills 配套逻辑brainstorming 把模糊需求逼出来writing-plans 把 design 拆成可执行 tasks。注意事项⚠️背景提醒 —— 你不需要背 Skill / Rule 名称ls .qoder/skills/看 8 件 superpowersls .qoder/rules/看 6 条公共约束直接问 Qoder: “项目里有哪些 Skill 可用”装备配置的核心逻辑装备类型配给谁解决什么问题Skill按角色选配让自主循环有方法论步骤Rule按角色选配部分全员共享让记忆带上不可逾越的红线tools按角色授权只读 vs 读写精确控制 “能用哪些工具”角色定岗位・Skill 定本事・Rule 定红线・tools 定权限 —— 四件套组装好一个数字成员就建好了。六个角色全部配装完毕产品 / 交互 只读・前端 / 后端 / 测试 读写・体验 只读 执行全员共享subagent-driven-development交接单格式 coding-conventions三条底线数字人团队如何交流通信协议与任务调度机制_单兵对比提出问题员工到齐了公司为什么还不能运转因为他们互相不认识不知道怎么说话。三个待解决协作问题产品 → 交互 怎么交 PRD前端 ∥ 后端 怎么并行跑不打架合并前质检 怎么保证不漏项AI 团队的沟通不靠开会 —— 靠交接单。业界协议全景三层互补叠加第一层・MCPAgent—外部工具Anthropic 2024 年底发布。Client-Server 模式解决 “怎么调数据库 / API / 浏览器”。已是 30 工具事实标准。第二层・A2AAgent—AgentGoogle 2025/04 发布。Agent Card 名片 结构化 Task 生命周期 Message/Part 分离。不靠聊靠工单。第三层・编排多个 Agent 顺序与传递对话式AutoGen、图式LangGraph、派发式Codex/Devin。我们选派发式。总结三层不是互斥是互补叠加MCP 解决 Agent 怎么跟工具说话・后面详讲A2A 解决 Agent 怎么派任务给别人编排层解决谁先谁后・一个完整多 Agent 系统三层都需要我们的方案subagent-driven派发模板你不需要手填这个模板/opsx:apply自动读取proposal.md/design.md/tasks.md拼装成每个 Agent 需要的任务描述。原理结构化输入输出契约谁负责・做什么・拿什么材料・交什么东西・遵守什么约束・怎么算完成六个维度一个不少。AI Agent 之间不靠口头交代靠结构化的输入输出契约。为什么必须结构化Anthropic 踩过的坑“你去调研半导体短缺”—— 一句话发给 lead agent发现三个糟糕事实现象一跑偏年份一个 subagent 跑去调研 2021 年的汽车芯片危机。现象二重复劳动另外两个 subagent 同时调研 2025 年供应链 —— 一样的活。现象三没有分工没有任何人去看 “现在与未来”、“下游应用”。Anthropic 的教训原文“每个 subagent 需要明确的目标、输出格式、工具与来源指导、清晰的任务边界。没有详细描述agent 会重复工作、遗漏空白、或找不到信息。”这就是为什么 opsx 要在 Spec 阶段就把需求结构化 ——proposal 定边界 /design 定细节 /tasks 定步骤。业界六种编排模式全景序号编排模式核心思路代表项目 / 优缺点1顺序流水线A→B→C 一条线走到底简单脚本一环卡住全停2编排者 - 工人大脑拆任务・多 Worker 执行・收集结果Codex / Devin灵活・编排者是单点3扇出 / 扇入多 Agent 同时独立任务・最后汇合并行数据管道快・并发冲突风险4对话式Agent 之间像人一样轮流发言AutoGen / ChatDev决策高・容易死循环5图式有向图・边传递状态・支持条件分支LangGraph / CrewAI表达强・配置复杂6反思式Agent 自审自己输出・发现问题修正Reflexion / LATS质量高・token 贵六种不互斥・真实系统往往是组合使用。选择原则简单场景用最简单的模式。我们怎么选主・辅・质检 三重套一、三层架构详情1. 主模式Orchestrator-Worker编排者 - 工人你是 CEOOrchestrator。相比 Beam AI 记录的「强模型编排 轻量模型执行」方案更进一步 ——人类负责人本身不消耗 token。2. 辅模式Fan-out / Fan-in扇出 / 扇入前端、后端并行开发属于扇出由 spec-reviewer 统一质检汇总属于扇入任务数量≥4 时最高可降低 75% 耗时、缩短 99% 等待时长。3. 质检环节Reflection反思思想依靠 spec-reviewer 双向对账 测试 Agent 执行 Spec 到端到端校验核心逻辑是让一个 Agent 审查另一个 Agent 的输出成果。二、选型答疑为什么不用对话式和图式对话式适配辩论协商类场景本方案前期就用 Spec 敲定共识无需多 Agent 辩论图式适配复杂分支流转场景本业务流水线以线性流程为主没必要搭建复杂图结构三、任务执行节奏划分串行节点必须排队执行链路产品→交互→前端后序环节必须依赖上游产出完成后才能启动并行节点可同时运行前端开发、后端开发互不依赖二者统一依照同一份 Spec 开展工作并行隔离git worktree 一工地三施工区MindStudio人一次只做一件事・AI 可以全速并行・但环境不隔离会重写三大并行开发痛点问题一互相覆盖Agent A 修改某文件时Agent B 同期也修改该文件造成代码互相覆盖冲突。问题二Context Rot上下文腐化加倍恶化多个 Agent 读取同一份上下文上下文混杂错乱的问题会被放大加剧。问题三假设被打破某个 Agent 改动数据库后其余 Agent 原本的测试前置假设失效测试结果失真。实操命令代码块using-git-worktrees Skill# 为个人中心创建独立 worktreegitworktreeadd../wanderchina-profile feature/user-profile# 为消息通知创建独立 worktreegitworktreeadd../wanderchina-notifications feature/user-notifications# 为站内私信创建独立 worktreegitworktreeadd../wanderchina-messages feature/user-messages一个工地三个施工区类比逻辑盖楼、装修、绿化分头施工全部完工后再统一合并技术效果三条流水线对应三个独立目录运行期间互不干扰开发结束再依次合并回main主分支。质检二阶段评审 Maker‑Checker主上下文不接收脏代码 —— 这是铁律不是建议第一阶段Spec 合规评审spec‑reviewer 执行双向对账对照规则将代码与 Spec 里的WHEN/THEN逐条映射核验结果输出表格形式标注✅通过、❌不通过、⚠️预警三类状态刚性约束只要出现❌不通过项直接退回重做第二阶段代码质量评审测试 Agent 执行 Playwright 端到端 E2E 测试准入门槛代码覆盖率达到 100%才允许启动 E2E 测试放行标准全部测试用例跑绿才算阶段通过拦截规则任意一项测试未达标禁止代码合并、禁止交接交付业界模式说明Maker‑Checker生产者‑校验者Beam AI 过往结论双大模型互审可提升产出质量但运行成本会上涨 40%–60%本方案优化点Checker 环节不依赖 LLM 主观判断改用结构化对账 自动化测试的组合方式质控更客观、可控。ps省去 5 分钟评审换来后续 10 倍修复成本不要省。完整调度泳道图——CEO 三次决策清晰可见单兵 vs 团队决策清单一、维度对比表维度单 Agent 单会话Agent Teams上下文崩溃风险高・4 小时后开始失忆低・每个小而精返工次数多・需求 / 实现 / 测试互打少・Spec 是合同你的介入次数多・每步盯着少 3 次签字・验收・合并并行能力无・前后端串行有・三子需求同时跑启动成本低・直接聊就行高・要建团队・写 Agent 文件二、核心理念提炼团队不是为了快是为了稳。快只是并行的副产品。多 Agent 团队架构的首要价值是降低出错概率、规范流程稳定性并行提速是配套收益而非设计初衷。三、四类适配场景选型指南场景 1时长2 分钟 → 优先单 Agent 单兵作战短平快的临时任务直接使用单个 Agent 即可拆分派发团队任务只会徒增流程开销。场景 2强依赖运行时输出 → 优先单 Agent任务必须等待上一步运行结果才能推进多 Agent 并行派发没有实际意义串行单兵执行更高效。场景 3全局重构类任务 → 不适合多 Agent全局重构需要连贯共享上下文认知不同 Agent 拆分后上下文割裂反而容易出现逻辑断层。场景 4Token 成本敏感业务 → 谨慎使用多 Agent多 Agent 对应多独立会话Token 消耗会成倍上涨预算有限场景优先控制 Agent 数量。