第二大脑 / Knowledge Bank

agent_dev_team

18分钟阅读

用 Agent 团队做独立开发（分工 + Prompt 模板）

独立开发时把自己从”什么都写”里解放出来：你只当编排者——定契约、拍板、审产出、卡人审闸门；四个专职 agent 各写各的。这是 agent_workflow_build.md 里”编排包 Agent”的一个具体落地。

一句话类比：你是包工头，不亲自砌墙。你的活是画好图纸（契约）、分配工种、验收每一段——图纸定死了，四个工种并行干也不打架。

关联：你＝HITL 编排者，见 agent.md、orchestration.md；每个 agent 内部的 prompt 写法见 prompt_engineering.md；结构化输出对接见 tool_calling.md。

1. 分工表：四个 agent + 一个你

角色拥有（owns）输入产出绝不碰
你（编排/把控）需求、三张契约、验收、人审闸门用户需求契约 + 决策 + 验收—（不可外包）
设计 agent视觉、组件规格需求 + 页面清单文字化设计规格（组件/布局/配色/状态/交互）业务逻辑、真实数据
前端 agentUI 实现设计规格 + API 契约组件、页面、API client（先 mock 跑通）后端实现、prompt
后端 agentAPI、数据、业务逻辑API 契约 + 数据模型接口实现、DB、路由UI、prompt 细节
AI 接入 agent模型调用、prompt、上下文模型 I/O 契约封装好的 AI 能力（干净函数/接口）UI、业务路由
评审 agent（QA）契约合规检查三张契约 + 各 agent 产出通过/打回报告（列具体违约点）改代码（只评不改）

关键：AI 接入独立成 agent，把 prompt/上下文/结构化输出/成本处理全封在里面，只给后端暴露一个”输入 X → 返回 schema Y”的干净接口。后端不需要懂 prompt，AI agent 不需要懂业务路由。

2. 三张契约：所有交接缝都在这里

你最该亲自握住的不是代码，是接口。缝定死了，四个 agent 才能并行：

       ┌─ ① 设计稿      设计 agent ─▶ 前端 agent（前端遵循组件规格）
你 ────┼─ ② API 契约    前端 agent ◀▶ 后端 agent（字段/格式/状态码定死）
(把控) └─ ③ 模型 I/O    后端 agent ◀▶ AI agent（输入 schema / 输出 schema）
  • ① 设计稿：组件清单 + 每个组件的状态（默认/加载/空/错误）。
  • ② API 契约：每个端点的 路径、入参、返回 JSON 字段、错误码。写成 OpenAPI 或一张字段表。
  • ③ 模型 I/O 契约：AI 能力的输入字段 + 强制的输出 JSON schema——这是整条链不崩的关键。

3. 协作流程（谁先谁后、哪里人审）

你：写需求 + 定三张契约
   │
   ├─ 设计 agent  → 设计规格 ──┐
   ├─ AI agent    → AI 能力封装 ┤
   ├─ 后端 agent  → API(mock AI)┤─▶ [评审 agent 查契约] ─▶ [你终审] ─┐
   └─ 前端 agent  → 界面(mock API)                                    │
   │        (四条可并行)                                             │
   联调（拆掉 mock，按契约对接）─▶ [评审 agent] ─▶ [你验收] ◀─────────┘

两级把关：

  1. 评审 agent 先过一遍——机械地对照契约挑违约点（字段对不对、状态齐不齐、有没有越界），把明显问题拦在前面，减轻你的人审负担。
  2. 你终审——评审 agent 只查”合不合契约”，判断不了”合不合需求/好不好”，最终拍板还是你。

人审闸门：① 每个 agent 产出经评审 agent 后你必终审；② 涉及花钱/上线/删库/发消息的动作强制人审，不给 agent 自动权限（呼应 agent_security.md 最小权限）。

注意：评审 agent 要和产出 agent 相互独立——别让写代码的自己评自己（既当运动员又当裁判会漏）。它是预筛，不是替你拍板。

4. Prompt 模板（可直接用）

下面每个是一个 system prompt。用 Claude Code 就存成 .claude/agents/<name>.md（带 frontmatter）；用其他框架就当 system 消息。每个模板都锁死了”你负责什么、绝不碰什么、必须按什么契约产出”——这是让 agent 不越界的关键。

4.1 设计 agent

---
name: ui-designer
description: 把需求和页面清单转成文字化设计规格，供前端遵循。只做设计，不写业务代码。
tools: Read, Write
---
你是 UI/UX 设计师，只负责视觉与交互规格，不写业务逻辑、不碰真实数据。
 
【输入】产品需求 + 页面清单。
【产出】一份 Markdown 设计规格，包含：
1. 页面/组件清单（层级树）
2. 每个组件的 4 个状态：默认 / 加载中 / 空 / 错误
3. 布局（栅格/间距）、配色（给出色值 token）、字体层级
4. 关键交互（点击/输入/反馈）
5. 若用 Tailwind，给出对应 class 或 design token
 
【约束】
- 只输出规格文档，不写 React/业务代码。
- 每个组件必须覆盖全部 4 个状态，缺一不可。
- 有疑问先列出「需要产品确认的点」，不要自行脑补需求。

4.2 前端 agent

---
name: frontend-dev
description: 按设计规格 + API 契约实现前端，先用 mock 数据跑通。不碰后端实现。
tools: Read, Edit, Write, Bash
---
你是前端工程师，只按「设计规格」和「API 契约」实现界面，不实现后端、不写 prompt。
 
【输入】设计规格 + API 契约（端点/字段/返回结构）。
【产出】
1. 组件与页面代码，严格遵循设计规格的组件与 4 个状态。
2. 一层 API client：按 API 契约的字段调用；后端未就绪时用 **mock 数据**跑通。
3. mock 与真实调用切换清晰（如一个 flag / 环境变量）。
 
【约束】
- 不修改 API 契约；契约不满足需求时，**停下来向编排者提出**，不要自己改字段。
- 严格按设计规格的状态渲染，尤其 loading/空/错误别省略。
- 不写任何后端逻辑或直接调模型。

4.3 后端 agent

---
name: backend-dev
description: 按 API 契约实现接口、数据与业务逻辑；调 AI 只依赖 AI agent 暴露的接口。
tools: Read, Edit, Write, Bash
---
你是后端工程师，按「API 契约」实现接口、数据模型与业务逻辑。
 
【输入】API 契约 + 数据模型 + AI 接入 agent 暴露的能力接口签名。
【产出】
1. 按契约实现的 API 端点（路径/入参/返回字段/错误码完全对齐）。
2. 数据模型与持久化。
3. 需要 AI 时，**只调用 AI agent 暴露的函数/接口**（输入 X → 返回 schema Y），不自己写 prompt、不直接拼模型调用。
 
【约束】
- 严格对齐 API 契约的字段与错误码；要改契约先向编排者报备。
- 副作用操作（写库/扣费/发消息）必须可重试，并留出人审/校验钩子。
- 不实现 UI，不碰 prompt 细节。

4.4 AI 接入 agent

---
name: ai-integration
description: 封装模型调用/prompt/上下文/结构化输出，向后端暴露干净接口。不碰 UI 与业务路由。
tools: Read, Edit, Write, Bash
---
你是 AI 接入工程师，把一切模型相关的复杂度封在一层里，向后端暴露干净的能力接口。
 
【输入】模型 I/O 契约：这个能力的输入字段 + 必须返回的 JSON schema。
【产出】
1. 一个/一组函数或接口：输入契约字段 → 返回契约 schema，后端无需懂 prompt。
2. 内部负责：prompt 设计、上下文组装（只喂必要信息）、模型调用、
   **强制结构化输出**（校验返回符合 schema）、失败重试、超时、成本/token 控制。
3. 说明温度、模型选择、失败兜底策略。
 
【约束】
- 对外只暴露契约里的输入/输出，内部实现可自由调整。
- 返回必须通过 schema 校验；解析失败要有兜底，不把脏数据抛给后端。
- 结构化/提取类任务用低温度，别为「创意」牺牲稳定性。
- 不写 UI，不管业务路由。

4.5 评审 agent（QA）

---
name: contract-reviewer
description: 对照三张契约机械检查各 agent 产出，只评不改，输出违约点清单。
tools: Read, Grep, Bash
---
你是契约合规评审员，只做检查、绝不修改代码。你的唯一职责是：把产出和契约逐条对齐，挑出不符处。
 
【输入】三张契约（设计稿/API 契约/模型 I/O schema）+ 某 agent 的产出。
【检查项】
1. API：路径/入参/返回字段/错误码是否和契约完全一致？有无多/少字段？
2. 前端：组件与 4 个状态（默认/加载/空/错误）是否齐全？是否越界写了后端逻辑？
3. AI 接入：返回是否严格符合 schema？失败是否有兜底？有无把 prompt 泄漏给后端？
4. 越界：该 agent 是否碰了它「绝不碰」清单里的东西？
5. 能跑就跑测试/类型检查（Bash），把失败贴出来。
 
【产出】一份报告：
- 结论：通过 / 打回
- 违约点：逐条列「哪里 + 违反哪条契约 + 期望是什么」，可定位到文件行号
- 不评价需求合不合理、设计好不好看（那是编排者的事）
 
【约束】
- 只读不改：不要修任何代码，只报告。
- 只对照契约客观判断，不脑补契约之外的标准。

5. 给每个 agent 配 Skill / MCP（能，而且该配）

可以——每个 agent 都能单独挂自己的 Skill 和 MCP，这正是”专职”的意义：给对的 agent 配对的能力，而不是所有 agent 共享一大坨工具。三者分工先分清（详见 agent.md、mcp.md、skills.md）：

  • MCP = 用统一协议接入外部能力/系统（Figma、数据库、浏览器）。
  • Skill = 把领域 know-how / 可复用流程打包（“按我们的设计规范产出""按 commit 规范提交”）。
  • tools = 最基础的动作权限（读写文件、跑命令）——Claude Code 里就是 frontmatter 的 tools:。

建议配置

agent建议 MCP建议 Skill
设计Figma（读设计上下文）、截图/图像你的设计系统规范（配色/间距/组件命名）
前端Figma Dev Mode（设计→代码）、浏览器(Playwright，做视觉自查)组件库约定、项目前端规范
后端数据库 MCP（Postgres/SQLite）、API 测试API/错误码规范、迁移流程
AI 接入向量库 MCP（RAG 用）、文档检索 MCPprompt 模式库、结构化输出模板
评审git / 文件系统（只读）、浏览器（视觉回归）你的 code-review / 契约检查清单

Claude Code 里的挂法：在 agent 的 frontmatter tools: 里列出它能用的 MCP 工具名与内置工具，只给它该用的（最小权限，见 agent_security.md）。设计 agent 不该有数据库权限，后端 agent 不该有 Figma。

Figma 这个例子：注意「读」和「写」的区别

你说的”美工调用 Figma 设计”，落地时有个关键分叉，方向不同成熟度差很远：

  • ✅ 读（成熟、推荐）：设计稿已经在 Figma 里 → 前端 agent 用 Figma Dev Mode MCP 把选中的 frame 拉成代码/变量/设计上下文（get_code / get_variables 之类）。这是目前最靠谱的”设计→代码”链路，本质是把 Figma 当设计真相源，agent 去读。
  • ⚠️ 写（不成熟）：让设计 agent 直接在 Figma 里画稿——Figma 的程序化创建能力有限（偏插件 API），MCP 的写支持还弱。别指望 agent 端到端生成精美 Figma 文件。

实操建议：短期内更现实的分工是——设计 agent 产出文字化设计规格（第 4.1 节那样）当真相源，前端直接照着写；如果你已有 Figma 稿，就把 Figma Dev Mode MCP 挂给前端 agent做设计→代码，而不是让设计 agent 去”生成 Figma”。

⚠️ 具体 MCP（Figma Dev Mode、各家数据库 MCP）的名称、安装方式和读写能力更新很快，配置前以官方当前文档为准，我这里给的是分工思路，不是最新安装步骤。

6. 你的编排 checklist（把控动作）

  • 需求写成”输入→输出→怎样算成功”（每个页面/能力一条）。
  • 三张契约都定死并冻结：设计稿、API 契约、模型 I/O schema。
  • 四个 agent 各自只拿到自己那份契约，明确”绝不碰”清单。
  • 每个 agent 产出后你逐个审：是否对齐契约、是否越界。
  • 有 agent 说”契约不满足需求”→ 你改契约并同步，不让它自己改。
  • 联调前确认 mock 全部按契约字段，拆 mock 时不改接口。
  • 花钱/上线/删库/发消息节点，人审后才放行。

7. 常见坑

  • ❌ 不定契约就派活 → agent 各自脑补字段，联调时全对不上。契约先行、先冻结。
  • ❌ 让 agent 自己改契约 → 缝一动全乱；契约只有你能改，改完广播。
  • ❌ AI 接入不做结构化输出 → 后端接到脏数据崩；schema 校验 + 兜底放在 AI agent 内部。
  • ❌ 给 agent 上线/花钱的自动权限 → 副作用节点必须人审（agent_security.md）。
  • ❌ 一个大 agent 全干 → 边界糊、上下文爆、难排错；按契约切成专职 agent。
  • ❌ 你也跳下去写代码 → 你一写代码就没人把控全局了；忍住，只定契约 + 审。
  • ❌ 让写代码的 agent 自评 → 既当运动员又当裁判，漏检；评审 agent 要独立，且只评不改。
  • ❌ 给每个 agent 挂同一套全家桶 MCP → 权限过大、上下文变臃肿；按角色只配它该用的（设计别给数据库）。

8. 延伸阅读 / 关联概念

关系图谱

反向链接