企业官网建设流程全解析

基于 Agent Teams 全栈实践个人网站开发【二】_Agent团队搭建篇

如何通过 Skills 构建 Agent Teams 的角色能力

发装备的逻辑：角色配置矩阵

核心原则：按岗位职责匹配专属工具能力，不配置通用全能工具，每个 Agent 只装备适配自身业务的技能与约束规则，从源头避免跨岗越权、职责混淆。

最后一行是公共语言：subagent-driven-development（同一个交接单格式） + coding-conventions（同一套底线 YAGNI/DRY/TDD）。

零基础构建完整 Agent 三条路径解析

路径一：推荐新手｜/create-subagent交互式引导

运行逻辑：系统像面试官逐层提问，用户仅需回答 5–6 句简短表述，Qoder 自动整理输出规范完整的角色文件，适配完全零基础人群。

路径二：有想法未组织｜一句话启动 + 迭代补全

运行逻辑：先用一句话描述需求，再通过 3–4 轮对话逐步补充输出格式、角色权限、排除边界等约束条件，迭代打磨，让 Agent 质量趋近完善，适合思路零散、不会结构化梳理需求的使用者。

路径三：已有规划｜配置矩阵 + 批量生成

运行逻辑：将前文的角色配置矩阵提交给 Qoder，仅一条指令即可一次性生成六个角色的全部配套文件，面向前期规划完备、追求批量高效落地的使用者。

对比汇总表

无需刻意学习撰写超长 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: 工具授权？ 你：只读 —Read，Grep，Glob → 自动生成 `product-manager.md`

设计点

1. 设计点・不包含什么 > 包含什么

“不做什么” 直接决定后续 Spec 边界。不写 = Agent 自由发挥、悄悄加功能。

2.设计点・开放问题是强制决策

让 AI 把 “假设点” 显式列出，强制你拍板，而不是偶然发现他替你做了决定。

3.设计点・Skills 配套逻辑

brainstorming 把模糊需求逼出来；writing-plans 把 design 拆成可执行 tasks。

注意事项

⚠️背景提醒 —— 你不需要背 Skill / Rule 名称

• ls .qoder/skills/看 8 件 superpowers
• ls .qoder/rules/看 6 条公共约束
• 直接问 Qoder: “项目里有哪些 Skill 可用？”

装备配置的核心逻辑

角色定岗位・Skill 定本事・Rule 定红线・tools 定权限 —— 四件套组装好，一个数字成员就建好了。

六个角色全部配装完毕

产品 / 交互 只读・前端 / 后端 / 测试 读写・体验 只读 + 执行

全员共享：subagent-driven-development（交接单格式）+ coding-conventions（三条底线）

数字人团队如何交流：通信协议与任务调度机制_单兵对比

提出问题

员工到齐了，公司为什么还不能运转？

因为他们互相不认识，不知道怎么说话。

三个待解决协作问题

1. 产品 → 交互 怎么交 PRD？
2. 前端 ∥ 后端 怎么并行跑不打架？
3. 合并前质检 怎么保证不漏项？

AI 团队的沟通不靠开会 —— 靠交接单。

业界协议全景：三层互补叠加

第一层・MCP

Agent<—>外部工具

Anthropic 2024 年底发布。Client-Server 模式，解决 “怎么调数据库 / API / 浏览器”。已是 30 + 工具事实标准。

第二层・A2A

Agent<—>Agent

Google 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. 主模式：Orchestrator-Worker（编排者 - 工人）

你是 CEO=Orchestrator。相比 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 可以全速并行・但环境不隔离会重写

三大并行开发痛点

1. 问题一：互相覆盖

   Agent A 修改某文件时，Agent B 同期也修改该文件，造成代码互相覆盖冲突。

2. 问题二：Context Rot（上下文腐化）加倍恶化

   多个 Agent 读取同一份上下文，上下文混杂错乱的问题会被放大加剧。

3. 问题三：假设被打破

   某个 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 执行双向对账）

1. 对照规则：将代码与 Spec 里的WHEN/THEN逐条映射核验
2. 结果输出：表格形式标注✅通过、❌不通过、⚠️预警三类状态
3. 刚性约束：只要出现❌不通过项，直接退回重做

第二阶段：代码质量评审（测试 Agent 执行 Playwright 端到端 E2E 测试）

1. 准入门槛：代码覆盖率达到 100%，才允许启动 E2E 测试
2. 放行标准：全部测试用例跑绿才算阶段通过
3. 拦截规则：任意一项测试未达标，禁止代码合并、禁止交接交付

业界模式说明：Maker‑Checker（生产者‑校验者）

• Beam AI 过往结论：双大模型互审可提升产出质量，但运行成本会上涨 40%–60%；
• 本方案优化点：Checker 环节不依赖 LLM 主观判断，改用结构化对账 + 自动化测试的组合方式，质控更客观、可控。

ps：省去 5 分钟评审，换来后续 10 倍修复成本，不要省。

完整调度泳道图——CEO 三次决策清晰可见

单兵 vs 团队：决策清单

一、维度对比表

二、核心理念提炼

团队不是为了快，是为了稳。快，只是并行的副产品。

多 Agent 团队架构的首要价值是降低出错概率、规范流程稳定性，并行提速是配套收益，而非设计初衷。

三、四类适配场景（选型指南）

场景 1：时长＜2 分钟 → 优先单 Agent 单兵作战

短平快的临时任务，直接使用单个 Agent 即可，拆分派发团队任务只会徒增流程开销。

场景 2：强依赖运行时输出 → 优先单 Agent

任务必须等待上一步运行结果才能推进，多 Agent 并行派发没有实际意义，串行单兵执行更高效。

场景 3：全局重构类任务 → 不适合多 Agent

全局重构需要连贯共享上下文认知，不同 Agent 拆分后上下文割裂，反而容易出现逻辑断层。

场景 4：Token 成本敏感业务 → 谨慎使用多 Agent

多 Agent 对应多独立会话，Token 消耗会成倍上涨，预算有限场景优先控制 Agent 数量。