第7章 实战：企业PRD需求多智能体评审系统

本章你将学到：

• 将Harness五步法从单智能体迁移到多智能体协作系统
• 设计多个Agent的角色职责边界，避免职责重叠和输出混乱
• 用Trae搭建多角色研讨流程，让Agent按顺序发言并生成评审报告
• 为复杂系统构建配套的评测智能体，实现全链路自动化评测
• 将完整项目包装为课程设计、科创竞赛或求职作品集

本章你将产出：一个包含4个评审角色Agent、1个汇总报告Agent、1个评测审计Agent的企业级多智能体系统，以及一份可直接用于求职的项目报告
全部章节：收录在专栏《AI应用工程化实战教程》

---

7.1 从单智能体到多智能体：一次能力的跃迁

前七章，我们围绕“评论甄别智能体”走完了完整的Harness五步法流程。你学会了用一套工程化方法，开发一个可评测、可迭代的AI系统。你用Claude Code和Trae分别实现了一遍，证明了范式不绑定工具。

但现在，让我们面对一个事实：真实企业场景中，几乎没有哪个有价值的系统是单个智能体能完成的。

一个产品需求文档（PRD）评审，需要产品经理关注用户价值，研发工程师评估技术可行性，测试工程师识别质量风险，运营人员考虑市场影响。你不可能把这四种视角全部塞进一个Prompt里，然后指望一个AI面面俱到——它会变成第1章那种“规则越加越多、最后不敢再改”的乱麻。

正确的做法是：让多个智能体各司其职，像一支真正的团队一样协作。 这就是多智能体系统的核心价值——不是“一个更聪明的AI”，而是“一群分工明确的AI”。

本章，你将搭建这样一支AI评审团队。

---

7.2 项目背景与需求定义

7.2.1 场景设定

某软件公司需要一套自动化系统，用来对新产品需求文档（PRD）进行多角色协同评审。传统做法是：产品经理写好PRD，群发邮件给研发、测试、运营，各自回复意见，然后开会讨论——流程冗长、标准不统一、评审质量高度依赖个人状态。

公司希望用多智能体系统来改进这个流程。系统接收一份PRD，自动触发四个角色Agent依次评审，最后汇总生成评审报告（包含通过/不通过决定、风险项清单、行动项建议）。

这仍然是一个“用AI评测AI”的Harness工程场景——评审系统本身是业务智能体群，我们还会为它开发一个专属的评测审计智能体，用来评估整套系统的评审质量。

7.2.2 系统架构设计

整个系统由以下角色组成：

评审角色（4个业务智能体）：

角色	职责	关注维度
产品经理Agent	评审PRD的用户价值和市场合理性	用户场景是否清晰、需求是否解决真实痛点、优先级依据是否充分
研发工程师Agent	评审技术可行性和实现复杂度	技术方案是否合理、依赖是否明确、是否有潜在实现风险
测试工程师Agent	评审可测试性和质量风险	验收标准是否可度量、边界情况是否覆盖、是否存在安全或性能隐患
运营经理Agent	评审市场影响和运营可落地性	上线后对用户的影响、运营推广的可执行性、数据监控指标是否明确

协作调度角色：

角色	职责
汇总报告Agent	收集四个评审角色的输出，按照统一结构生成最终评审报告（包含总体结论、各角色意见、风险项汇总、行动项清单）

质量保障角色：

角色	职责
评测审计Agent	对整套系统的评审输出进行质量评估——拿到一份PRD和对应的黄金评审报告，比对系统生成的评审报告是否覆盖了关键风险点、是否遗漏重要行动项

角色间的信息流转如下：

用户输入PRD
    │
    ▼
┌─────────────┐
│ 调度层(Harness) │
└──────┬──────┘
       │ 并行/串行调度
       ▼
┌──────┬──────┬──────┬──────┐
│ 产品 │ 研发 │ 测试 │ 运营 │  ← 四个评审Agent依次或并行发言
└──┬───┴──┬───┴──┬───┴──┬───┘
   │      │      │      │
   └──────┴──────┴──────┘
          │
          ▼
   ┌──────────┐
   │ 汇总报告Agent │
   └─────┬────┘
         │
         ▼
   最终评审报告

关键设计原则：四个评审角色职责正交——产品关心“做不做”，研发关心“怎么做”，测试关心“怎么验”，运营关心“怎么推”。如果某个角色的输出里出现了另一个角色的核心判断（比如研发在评审“用户价值大不大”），就说明职责边界定义不清。

---

7.3 创建项目并设计规范文档

从本章开始，我们使用Trae作为主开发工具——多智能体项目涉及多个Prompt文件、多个脚本、复杂的依赖关系，可视化IDE能更好地管理这些复杂性。

7.3.1 创建新项目

打开Trae，选择“新建项目”，创建一个名为 prd-review-system 的新文件夹。

在Trae的AI对话面板中输入：

请为项目 prd-review-system 创建以下目录结构：
- specs/         存放规范文档
- prompts/       存放各角色的Prompt模板
- agents/        存放各角色的运行脚本
- data/          存放测试数据集
- tests/         存放评测脚本和报告
- README.md      项目说明文档

7.3.2 用AI生成系统规范文档

在对话面板中输入：

我正在开发一个“企业PRD需求多智能体评审系统”。请帮我生成一份系统设计规范文档，保存为 specs/system_design.md。

系统架构如下：
- 4个评审角色Agent：产品经理、研发工程师、测试工程师、运营经理
- 1个汇总报告Agent
- 1个评测审计Agent（用于评估评审质量）

请为每个角色定义：
1. 职责描述（一句话）
2. 输入内容（它收到什么信息）
3. 输出内容（它输出什么，格式是什么）
4. 评审关注的具体维度（3-4个）
5. 与其他角色的职责边界（明确指出“这不是你的职责范围”的事项，避免重叠）

另外：
- 定义汇总报告的格式：包含总体评审结论（通过/有条件通过/不通过）、各角色意见摘要、风险项列表（按严重程度排序）、行动项清单
- 定义评测审计Agent的评测标准：如何判断一次评审是否“正确”——关键风险是否被识别、是否有重要遗漏、行动项是否具体可执行
- 描述角色间的协作流程：是串行（一个接一个发言）还是并行（同时发言再汇总），以及调度层的职责

Trae会生成一份完整的系统设计规范。审查重点：

• 每个角色的职责边界是否清晰？有没有重叠？
• 有没有明确列出“这不是你的职责”——这是避免多Agent输出混乱的关键。
• 汇总报告的结构是否包含结论、风险、行动项？
• 评测审计的标准是否可操作（不是“评审质量好”，而是“风险覆盖率超过80%且无严重遗漏”）？

如果发现职责有重叠或模糊地带，在对话面板中要求Trae修正：

specs/system_design.md 中，产品经理Agent和运营经理Agent都在关注“用户影响”，职责有重叠。请明确划分：产品经理关注“用户价值和需求本身”，运营经理关注“上线后对现有用户行为的影响和推广策略”。

---

7.4 构建测试数据集与黄金标准

7.4.1 生成测试PRD

在对话面板中输入：

请根据 specs/system_design.md，生成10条测试用的产品需求（PRD），保存为 data/test_prds.json。

要求：
1. 每条PRD包含：
   - prd_id（PRD-001到PRD-010）
   - title（需求标题）
   - background（背景描述）
   - requirement（具体需求描述，100-200字）
   - acceptance_criteria（验收标准，至少2条）
   - priority（优先级：P0/P1/P2）

2. 覆盖以下类型：
   - 需求清晰、方案合理的优秀PRD（3条）
   - 技术方案有明显缺陷的PRD（2条）
   - 验收标准模糊、不可度量的PRD（2条）
   - 用户场景不清晰、价值不明的PRD（1条）
   - 缺少关键信息（如没有背景、没有验收标准）的不完整PRD（1条）
   - 包含潜在安全或合规风险的PRD（1条）

3. JSON数组格式，语言为中文。

7.4.2 构建黄金评审报告

这是本章最关键的步骤。对于每条测试PRD，我们需要一份“黄金评审报告”——由人工确认的、高质量的标准答案。这份黄金报告用来衡量评审系统的输出质量。

在对话面板中输入：

现在我需要为每条测试PRD构建黄金评审报告。请读取 data/test_prds.json，逐条分析，为每条PRD生成一份黄金评审报告，保存为 data/golden_reviews.json。

每条黄金报告包含：
- prd_id：对应的PRD编号
- overall_conclusion："通过"/"有条件通过"/"不通过"
- product_opinion：产品视角的关键判断（2-3句话）
- dev_opinion：研发视角的关键判断（2-3句话）
- test_opinion：测试视角的关键判断（2-3句话）
- ops_opinion：运营视角的关键判断（2-3句话）
- risk_items：应该被识别出的风险项列表（每条包含 risk_description 和 severity）
- action_items：应该被提出的行动项列表（每条包含 action_description 和 owner角色）
- key_review_points：评审中必须覆盖的关键检查点（3-5个），用于后续评测审计

注意：
- 这是“标准答案”，必须经过认真推敲。请基于系统设计规范中每个角色的关注维度，给出专业、准确的评审意见。
- 对于明显有缺陷的PRD，要明确指出缺陷所在。
- 对于不完整的PRD，要指出缺失了哪些关键信息。

审查黄金报告：打开 data/golden_reviews.json，逐条检查。黄金报告的质量直接决定了评测体系的可信度。如果某条黄金报告明显不合理（比如对有严重安全风险的PRD给出了“通过”），你需要手动修正。

实际上，建议的做法是：AI生成黄金报告后，你至少手动校准3条（包括1条“通过”、1条“不通过”、1条“边界情况”），其余7条可以在AI生成的基础上微调。这样既保证了GT的权威性，又提高了效率。

---

7.5 分步实现评审系统

7.5.1 生成四个评审角色的Prompt

在对话面板中输入：

请根据 specs/system_design.md 中的角色定义，为四个评审角色分别生成系统提示词。

要求：
1. 每个角色一个文件，保存在 prompts/ 目录下：
   - prompts/product_owner.txt（产品经理）
   - prompts/developer.txt（研发工程师）
   - prompts/tester.txt（测试工程师）
   - prompts/operations.txt（运营经理）

2. 每个Prompt包含：
   - 角色设定：你是谁，你的专业背景
   - 职责范围：你负责评审什么
   - 职责边界：明确写出“你不负责”的事项
   - 评审框架：按哪些维度进行评审（具体到子问题）
   - 输出格式：严格JSON，结构如下：
     {
       "role": "角色名称",
       "prd_id": "PRD编号",
       "conclusion": "通过"/"有条件通过"/"不通过",
       "strengths": ["优点1", "优点2"],
       "concerns": ["关注点1", "关注点2"],
       "risk_items": [{"description": "...", "severity": "高/中/低"}],
       "suggestions": ["建议1", "建议2"],
       "requires_clarification": ["需要澄清的问题1"]
     }
   - 约束：不输出JSON以外的任何内容，不越权评审其他角色的核心职责

3. 请先读取 specs/system_design.md 理解各角色定义，再生成Prompt。

7.5.2 生成汇总报告Agent

在对话面板中输入：

请为汇总报告Agent生成系统提示词，保存为 prompts/summarizer.txt。

要求：
- 角色：PRD评审汇总分析师
- 输入：一份PRD + 四个角色的评审输出（JSON格式）
- 任务：
  1. 综合四个角色的意见，形成总体结论（"通过"/"有条件通过"/"不通过"）
  2. 汇总各角色意见摘要
  3. 合并所有风险项，按严重程度排序（高→中→低），去重
  4. 汇总所有行动项，按负责角色分组
  5. 标注角色之间有分歧的问题点（如果存在）
- 输出格式：严格JSON
  {
    "prd_id": "...",
    "overall_conclusion": "通过/有条件通过/不通过",
    "conclusion_reason": "总体结论依据",
    "role_summaries": {
      "product_owner": "摘要",
      "developer": "摘要",
      "tester": "摘要",
      "operations": "摘要"
    },
    "risk_items": [{"description": "...", "severity": "高/中/低", "raised_by": "角色"}],
    "action_items": [{"description": "...", "owner": "角色", "deadline_suggestion": "..."}],
    "divergence_points": ["分歧点描述"]
  }
- 约束：不输出JSON以外的任何内容

7.5.3 生成调度运行脚本

四个评审角色和一个汇总角色都有了，现在需要一个调度脚本串联整个流程。在对话面板中输入：

请根据以上设计，生成一个调度运行脚本 agents/run_review.py。

要求：
1. 读取 data/test_prds.json 中的某条PRD（通过命令行参数指定prd_id，如果不指定则默认评测第一条）。
2. 调度流程：
   a. 将PRD内容分发给四个评审Agent（串行或并行均可，但建议串行以便观察流程）
   b. 每个评审Agent调用Claude API，传入对应的系统提示词（从 prompts/ 目录读取），获得评审输出
   c. 将PRD和四个评审输出一起提交给汇总报告Agent
   d. 获得最终评审报告
3. 运行脚本时：
   - 在终端显示进度：正在调用产品经理Agent... → 完成 → 正在调用研发工程师Agent... → ...
   - 将最终评审报告保存为 data/review_result_{prd_id}.json
   - 同时将报告打印到终端
4. 使用 anthropic 和 python-dotenv 库，从 .env 文件读取API密钥。
5. 代码清晰，关键步骤有注释。

审查要点：

• 确认调度逻辑按照设计执行（四个评审角色→汇总报告）。
• 确认每个Agent调用时加载了正确的Prompt文件。
• 确认输出保存路径正确。

7.5.4 首次运行并测试

在Trae终端中执行：

cd agents
python run_review.py PRD-001

观察终端中依次刷过的进度提示。运行完成后，打开 data/review_result_PRD-001.json，检查评审报告的结构和质量：

• 四个角色都给出了合理的判断吗？
• 汇总报告的结论是否综合考虑了各方意见？
• 风险项是否按严重程度排序？
• 有没有某个角色“越权”评审了不属于它职责范围的内容？

如果发现明显问题，先记录下来，不要立刻修改Prompt。 等到8.6节跑完完整评测，有了数据支撑再迭代。

---

7.6 开发评测审计智能体

评审系统本身是可运行的，但我们怎么知道它评审得好不好？这就需要评测审计Agent。

7.6.1 生成评测审计Prompt

在对话面板中输入：

请为评测审计Agent生成系统提示词，保存为 prompts/auditor.txt。

这个Agent的任务是：比对评审系统生成的评审报告与黄金评审报告，评估评审系统的质量。

要求：
- 角色：AI系统质量审计员
- 输入：PRD原文、评审系统生成的报告、黄金评审报告
- 评测维度：
  1. 结论一致性（30%）：系统总体结论与黄金结论是否一致？
  2. 风险覆盖率（40%）：黄金报告中的关键风险项，系统覆盖了多少？
  3. 遗漏检测（20%）：黄金报告中的关键检查点，系统是否都有回应？
  4. 行动项有效性（10%）：系统提出的行动项是否具体、可执行？
- 输出格式：严格JSON
  {
    "overall_score": 0-100,
    "conclusion_match": true/false,
    "risk_coverage_rate": 0.0-1.0,
    "missed_risks": ["遗漏的风险项"],
    "missed_checkpoints": ["遗漏的检查点"],
    "action_item_quality": "高/中/低",
    "analysis": "综合评价，不超过150字"
  }
- 约束：不输出JSON以外的任何内容

7.6.2 生成批量评测脚本

在对话面板中输入：

请生成一个批量评测脚本 tests/run_audit.py。

要求：
1. 读取 data/golden_reviews.json 中的所有黄金报告。
2. 对每条黄金报告对应的PRD：
   a. 如果对应的评审报告 data/review_result_{prd_id}.json 不存在，则调用 agents/run_review.py 生成评审报告
   b. 调用评测审计Agent，比对评审报告和黄金报告
   c. 收集所有评测结果
3. 计算汇总指标：
   - 平均总分
   - 结论一致率
   - 平均风险覆盖率
   - 行动项质量分布
4. 将逐条评测结果和汇总指标保存为 tests/audit_report.json。
5. 终端输出汇总指标概览。

7.6.3 运行评测

在Trae终端中执行：

cd tests
python run_audit.py

首次评测分数可能不高——这是正常的。评审系统涉及多个角色协作，初版通常存在协调问题。评测报告会告诉你：哪个角色经常漏掉关键风险？汇总报告是否正确传递了各角色的判断？行动项是否过于空泛？

这个评测审计Agent本身也是一份工程资产——它证明了你有能力对复杂AI系统进行全链路质量审计。

---

7.7 迭代优化一轮

基于 tests/audit_report.json 的分析，找出最影响系统质量的问题（通常是“风险覆盖率低”或某个特定角色表现不佳），针对性修改对应角色的Prompt。

例如，如果测试工程师经常漏掉安全风险：

请修改 prompts/tester.txt，在评审框架中增加一个专门的安全检查子维度：
- 安全性检查：PRD是否涉及用户数据收集？如果有，是否有明确的数据安全措施描述？是否存在潜在的安全漏洞（如输入未校验、权限未控制）？

修改后重新运行评测：

python run_audit.py

对比两次 audit_report.json 的指标变化，确认迭代有效。然后用Git提交：

git add -A
git commit -m "v1.1: 强化测试Agent安全评审维度，风险覆盖率从XX%提升至XX%"

---

7.8 作品集包装指南

你刚刚完成了一个企业级多智能体系统——这绝不是普通的课堂作业能比的。以下是包装建议：

1. 项目命名（用于简历和GitHub）

“基于多Agent协作的PRD智能评审系统——含自动化质量审计闭环”

2. 一句话介绍

模拟产品、研发、测试、运营四角色协同评审产品需求文档，内含5个专用Agent和1个评测审计Agent，实现从评审到质量评估的完整闭环。

3. 项目亮点（简历中的bullet points）

• 设计了4个正交职责的评审Agent（产品/研发/测试/运营），避免角色重叠和输出混乱
• 采用Harness工程化方法，规范驱动开发，所有Agent输出严格结构化
• 构建了10条PRD黄金评审报告数据集，用于自动化质量评测
• 配套开发了评测审计Agent，实现风险覆盖率、结论一致率等多维度自动评估
• 完整走通“规范定义→数据构建→Agent开发→评测迭代”的工程闭环

4. 可用于：

• 软件工程/人工智能课程设计

采用主流多智能体框架进一步完善后（见后续专栏） 可用于：

• 互联网+/挑战杯/大创等科创竞赛
• 校招AI应用岗/产品岗求职作品集
• GitHub开源项目（附带完整文档）

---

7.9 本章小结

• 多智能体系统的核心是职责正交。每个Agent只做自己最擅长的事，不越权、不重叠。设计阶段花在“定义职责边界”上的每一分钟，都会在开发阶段获得十倍的回报。
• 五步法在复杂系统中依然有效：规范定义→数据构建→Agent开发→评测迭代→优化闭环。规模变大了，方法不变。
• 评测审计Agent是系统的“质检员”。它让多智能体系统的质量不再是拍脑袋说“看起来还行”，而是可量化、可追溯的。
• 这个项目是你求职作品集的核心资产。它展示了工程化思维、多智能体架构设计能力、以及对AI系统质量的认真态度——这些恰好是企业最看重而普通毕业生最缺乏的。

---

课后练习

1. 运行评审系统，观察四个角色的输出。有没有某个角色出现了“越权评审”的情况？如果有，修改它的Prompt明确边界。
2. 从 data/test_prds.json 中选择一条你感兴趣的PRD，手动写一份你认为正确的评审报告，然后与系统生成的评审报告对比。你发现了哪些系统没有覆盖到的点？
3. （进阶）尝试修改调度脚本 agents/run_review.py，让四个评审Agent并行调用而不是串行调用（提示：使用 concurrent.futures 或 asyncio）。对比并行和串行的运行时间。
4. （进阶）为评测审计Agent增加一个评测维度：“角色覆盖完整性”——检查评审报告是否缺失了某个角色的意见。修改 prompts/auditor.txt 并重新评测。

---