agent-orchestration-advisor

目的

指导产品经理设计多 Agent 工作流：将复杂、重复的 PM 任务拆分为并行运行、各有所长的 AI Agent，而不是采用线性、顺序式流程或手动执行。借助这种方式，从“文档繁重的管理员”转变为“系统级协调者”，统筹由 AI Agent、人类团队和市场数据构成、持续交互的“动态系统”。

关键转变： 从线性项目管理（一次处理一个任务）转向编排（多个 Agent 同时工作，各自拥有明确的职责边界和交接流程）。

这并非要教你编写提示词，而是要设计工作流，让 AI Agent 负责重复性的研究、综合和验证工作，而 PM 专注于战略和决策。

输入

最适合提供： 你想要编排的工作流或重复性任务，用一两句话描述即可，无论目前执行方式有多手动或混乱。 也有帮助： 当前流程的痛点（太慢、顺序环节太多、太依赖你）、团队已在使用的工具，以及你是否已先完成 context-engineering-advisor（这是必备的前置步骤）。

在调用时提供的任何内容——技能名称后面的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已经回答的问题。请使用这些信息，并跳过其中已经涵盖的问题；不要重复询问。

什么都没准备好？也没关系。 顾问会先询问你每周最耗时的 PM 工作流是什么，然后围绕它逐一梳理四个编排维度。

调用示例： 为我们的每周竞争情报工作设计一套编排方案：目前一位 PM 需要花 6 小时依次完成资料抓取、摘要整理和简报撰写。

核心概念

编排与项目管理

维度	项目管理	编排
方法	线性监督进度安排和人工任务	管理由 AI Agent、人类和数据持续交互构成的“动态系统”
任务流	顺序执行（完成 A，再做 B，然后做 C）	并行执行（A、B、C 同时运行）
PM 的角色	文档繁重的管理员	系统级领导者，协调自动化系统和人类判断
关注点	产出（交付的功能）	成效（业务成果、学习速度）
风险管理	手动跟踪和缓解	实时监控，由 Agent 系统标记缺漏

关键洞见： 编排并非要取代人类，而是通过自动化重复、耗时的任务，大幅提升人类判断的效力。

---

编排的四个维度

1. 多 Agent 工作流的协调

将复杂任务拆分为各有所长、并行运行的 Agent。

示例：

• 手动方式（旧）： PM 花 8 小时汇总竞争情报，再花 4 小时综合客户反馈，然后花 3 小时找出路线图缺口，总计顺序执行 15 小时
• 编排方式（新）： 三个 Agent 同时运行：
  • Agent A：竞争情报（研究 Agent）
  • Agent B：客户反馈综合（综合 Agent）
  • Agent C：路线图缺口分析（分析 Agent）
  • 总耗时：8 小时（受运行最慢的 Agent 限制）；PM 花 2 小时审核输出，总计 10 小时，节省 5 小时

核心原则： 从手动筛选转向假设编排——由 Agent 提出假设，PM 负责验证和决策。

2. 跨职能 AI 团队的领导

管理多元化团队（数据科学家、ML 工程师、合规人员、伦理学家），确保解决方案可扩展、合乎伦理并保持一致。

包括以下内容：

• 将多样性意识融入工作流
• 风险管理（不能事后才考虑）
• 伦理编排（确保 AI 不会“失控”）
• 跨职能协同（工程、合规、设计）

PM 的角色： 治理守护者——确保 AI 系统体现公司的价值观。

3. 启动控制塔功能

利用 Agentic 系统实时监控各职能部门的组织准备情况，并在关键故障发生前标记差距。

监控内容：

• 支持准备情况（文档、培训、升级路径）
• 营销准备情况（消息、素材、GTM 计划）
• 运营准备情况（基础设施、扩展能力、监控）

核心原则： Agentic 系统充当预警系统，在差距演变为阻碍之前及时标记。

4. 战略意图对齐（应用上下文工程）

为 AI Agent 提供正确组合的使命、约束和优先事项，确保自动化决策体现公司价值观。

关联： 这是编排层的上下文工程。基础内容请参阅 context-engineering-advisor。

Agent 需要：

• 产品约束（我们会／不会构建什么）
• 战略优先事项（当前最重要的是什么）
• 运营定义（共享术语表）
• 证据标准（什么才算验证）

---

四种 AI 管理工作流（Productside 蓝图）

每位 PM 都必须掌握这些工作流，才能在快速推进的同时保持扎实：

1. 上下文工程 ✅（基础）

   • 创建能记住产品领域、研究、JTBD、角色和约束的 AI 工作区
   • 技能： context-engineering-advisor

2. 合成评估 📋（质量保证）

   • 针对 AI 推理的自动化验证测试
   • 生成合成数据，根据跟踪记录运行工作流
   • 消除 80% 的幻觉风险

3. Agentic 工作流 ← 我们就在这里

   • Agent 处理重复性任务（竞争情报、客户综合分析、路线图缺口）
   • PM 专注于战略

4. 氛围编程 📋（快速原型开发）

   • 根据上下文工作区生成可点击的原型
   • 将反馈周期从数周缩短至数小时
   • 关联： pol-probe-advisor（通过氛围编程创建的 PoL 探测）

---

AI 适配型问题（Teresa Torres）

什么样的问题属于“AI 适配型”？

• 过去因涉及人工参与而难以扩展（例如，综合分析 50 次用户访谈）
• 现有非 AI 解决方案难以胜任（例如，手动跟踪竞争动态）
• 需要大规模保持一致性（例如，分析 100 项功能的风险）

核心观点：“AI 让构建变得更容易，但选择构建什么仍是首要挑战。”编排可以帮助解决“构建”部分，让 PM 专注于“选择”。

---

四大风险（Marty Cagan，AI 时代）

编排器负责管理整个组织面临的这些风险：

风险	标准定义	AI 时代层面	编排器的职责
价值风险	客户愿意付费吗？	与成本相比，AI 是否带来了足够的增量收益？	在进行编排前，通过 PoL 探测验证价值
可用性风险	用户能弄明白怎么用吗？	UX 合适吗？（聊天界面往往并不合适！）	与真实用户一起测试工作流
可行性风险	我们能构建它吗？	我们理解“AI 的物理规律”吗？令牌预算够吗？	在技术约束范围内设计
可持续性风险	我们能销售／支持它吗？	是否有法律限制？数据隐私风险？运营支出（OpEx）是否可持续？	监控成本、合规性和可扩展性

---

反模式（这不是什么）

• 不是为了取代 PM： 编排可以增强判断力，而非消除判断力
• 不是为了自动化一切： 有些任务需要人类的共情能力和上下文
• 不是为了复杂而复杂： 只有在能显著节省时间或提高质量时才进行编排
• 不是“设置好就不管”： 编排后的工作流需要监控和维护

---

何时使用此技能

✅ 适用于以下情况：

• 每周有耗时 5 小时以上的重复性 PM 任务（竞争分析、客户信息汇总、路线图维护）
• 需要按顺序完成的工作可以并行处理（研究，然后汇总，再分析）
• 需要大规模保持一致性（分析 50 项功能的风险、汇总 100 次客户访谈）
• 你把时间花在执行上，而不是战略上

❌ 以下情况不适用：

• 任务是一次性的或很少发生（不值得承担编排开销）
• 每个步骤都需要关键的人类判断（需要共情的工作）
• 任务本身已经足够快（不要过度设计）
• 你还没有先打好上下文工程基础（参见 context-engineering-advisor）

---

应用

此交互式技能会通过自适应提问，逐步设计多 Agent 工作流。

---

步骤 0：收集上下文

Agent 提问：

在设计编排工作流之前，我们先收集一些背景信息：

当前的 PM 工作：

• 每周哪些重复性任务最耗时？（竞争分析、客户信息汇总、路线图更新等）
• 你在这些任务上花多少时间？（每周小时数）
• 这些任务是否需要按顺序完成，还是可以并行处理？

预期结果：

• 对你来说，“足够好”的自动化是什么样的？（减少 80% 的人工工作？提高一致性？）
• 哪些部分需要人类判断？（最终决策、共情、伦理考量）

技术背景：

• 你是否具备上下文工程基础？（约束注册表、业务术语表——参见 context-engineering-advisor）
• 你目前使用哪些 AI 工具？（Claude Projects、ChatGPT、自定义 Agent）

你可以简要描述，也可以粘贴示例。

---

步骤 1：评估任务是否适合 AI

Agent 提问：

我们来判断你的任务是否适合编排。以下哪项最能描述你的情况？

选择一项：

1. “我每周花 10 小时以上处理重复性的研究／汇总任务”

   • 示例：汇总竞争情报、汇总客户反馈、跟踪功能请求
   • 评估：非常适合编排

2. “我有一项需要多个连续步骤的任务，而且每个步骤都很耗时”

   • 示例：研究竞争对手 → 汇总发现 → 找出差距 → 更新路线图（总计 15 小时，按顺序完成）
   • 评估：适合并行处理

3. “我需要大规模保持一致性——分析许多类似事项”

   • 示例：分析 50 项功能的风险、汇总 100 次用户访谈、跟踪 20 个竞争对手
   • 评估：非常适合编排（Agent 可确保一致性）

4. “我的任务主要依赖人类判断和共情”

   • 示例：与利益相关者协商、团队辅导、权衡伦理问题
   • 评估：不适合编排（应由人主导）

用户回答：[选择]

Agent 分析：

根据你的选择：

• **选项 1–3：**继续设计工作流
• **选项 4：**建议继续由人主导任务；提供替代方案（例如，使用 AI 进行研究，但由人做决策）

---

第 2 步：将任务拆解为 Agent 专属子任务

Agent 提问：

我们来把任务拆解成独立的子任务，分别交由专门的 Agent 处理。

你选择的任务包含哪些不同步骤？

拆解示例（竞争情报）：

手动流程（旧）：

1. 调研 10 个竞争对手的产品页面（3 小时）
2. 跟踪近期推出的功能（2 小时）
3. 分析定价变动（2 小时）
4. 整理并撰写竞争格局文档（3 小时）
5. 找出战略差距（2 小时） **总计：**12 小时，按顺序完成

编排流程（新）：

• **Agent A（调研）：**抓取竞争对手的产品页面，提取功能
• **Agent B（发布跟踪）：**监控竞争对手的版本说明、博客文章和社交媒体
• **Agent C（定价分析）：**跟踪定价页面，找出变动
• **Agent D（综合分析）：**将 A、B、C 的发现汇总为结构化报告
• **Agent E（差距分析）：**比较我们的路线图与竞争对手的功能，标出差距 **总计：**Agent A-C 并行运行（3 小时），然后 D 和 E 依次运行（2 小时）= 5 小时 + 1 小时的项目管理审查 = 总计 6 小时（节省 50% 时间）

Agent 提供：

我会帮你拆解任务。请逐步描述你当前的工作流程，我会找出：

• 哪些步骤可以由 Agent 处理
• 哪些步骤可以并行运行
• 哪些步骤需要人工判断

用户回复：[描述流程]

**Agent 提供：**拆解后的工作流程及 Agent 分工。

---

第 3 步：设计并行与顺序流程

Agent 提问：

现在来设计工作流拓扑——哪些 Agent 并行运行，哪些依次运行。

三种流程模式：

模式 1：完全并行（最快）

[Agent A] ─┐
[Agent B] ─┼─→ [PM Review] → [Decision]
[Agent C] ─┘

• 所有 Agent 同时运行
• 项目经理一起审查所有输出
• **适用情况：**Agent 彼此独立（互不依赖）

模式 2：流水线（按顺序交接）

[Agent A] → [Agent B] → [Agent C] → [PM Review] → [Decision]

• 每个 Agent 都依赖前一个 Agent 的输出
• **适用情况：**后续 Agent 需要前序 Agent 的结果

模式 3：混合模式（并行 + 顺序）

[Agent A] ─┐
[Agent B] ─┼─→ [Agent D] → [Agent E] → [PM Review] → [Decision]
[Agent C] ─┘

• 部分 Agent 并行运行，再将结果传递给按顺序运行的 Agent
• **适用情况：**前期步骤相互独立，后续步骤进行综合分析

你的任务最适合哪种模式？

选项：

1. 完全并行 — 所有 Agent 彼此独立
2. 流水线 — 每个 Agent 都需要前一个 Agent 的输出
3. 混合模式 — 并行与顺序相结合
4. 不确定 — [Agent 分析你的拆解结果并给出建议]

用户回复：[选择]

**Agent 提供：**展示 Agent 依赖关系的可视化工作流图。

---

步骤 4：定义 Agent 边界和交接

Agent 询问：

现在，让我们定义每个 Agent 了解什么（上下文边界），以及Agent 之间如何交接。

为每个 Agent 定义：

1. Agent 名称和用途（它的任务是什么？）
2. 所需上下文（它需要哪些信息？）
   • 始终可用（来自上下文工程）
   • 按需检索（针对本次运行的特定信息）
3. 输出格式（它会生成什么？）
4. 交接给下一个 Agent（会传递什么？会过滤什么？）

示例（竞争情报编排）：

Agent A：竞争对手研究 Agent

• **用途：**抓取 10 个竞争对手的产品页面，提取功能
• 所需上下文：
  • 始终可用：竞争对手列表（来自约束注册表）
  • 检索获取：竞争对手 URL（来自数据库）
• **输出格式：**结构化 JSON：{competitor, features[], last_updated}
• **交接：**将 JSON 传递给 Agent D（综合 Agent）

Agent D：综合 Agent

• **用途：**汇总 Agent A、B、C 的发现，生成结构化报告
• 所需上下文：
  • 始终可用：报告模板、写作语气（来自上下文工作区）
  • 检索获取：Agent A、B、C 的输出
• **输出格式：**包含以下章节的 Markdown 文档：概述、主要功能、定价、发布活动
• **交接：**将报告传递给 Agent E（差距分析 Agent）

Agent 提供：

我会帮助你为每个 Agent 定义边界。针对你的工作流，让我们定义：

• 每个 Agent 需要什么上下文（始终可用还是按需检索）
• 每个 Agent 会生成什么格式（JSON、Markdown、结构化数据）
• Agent 如何交接（传递什么，过滤什么）

用户回复：[描述 Agent 需求]

**Agent 提供：**完整的 Agent 边界定义和交接规范。

---

步骤 5：实现战略意图对齐

Agent 询问：

为避免 Agent “擅自行动”，我们需要为它们提供正确组合的使命、约束和优先级。

战略意图检查清单（每个 Agent）：

1. **使命：**该 Agent 的首要目标是什么？

   • 示例：“识别可能影响 Q2 路线图的竞争威胁”

2. **约束：**该 Agent 不能做什么？

   • 示例：“不要推荐战略重点领域之外的功能”
   • 示例：“不要抓取禁止此类行为的网站数据（检查 robots.txt）”

3. **优先级：**如果 Agent 必须做出选择，什么最重要？

   • 示例：“优先考虑过去 30 天内发布的功能，而非较早发布的功能”

4. **证据标准：**什么信息才算有效？

   • 示例：“仅引用来自官方产品页面、发行说明或经过验证的博客文章的信息”

关联：这是应用于编排的上下文工程。如需更深入的指导，请参阅 context-engineering-advisor。

Agent 提供：

针对工作流中的每个 Agent，让我们定义：

• 使命（目标是什么？）
• 约束（哪些事项不在范围内？）
• 优先级（什么最重要？）
• 证据标准（什么才算有效？）

用户回复：[为每个 Agent 定义战略意图]

**Agent 提供：**每个 Agent 的战略意图文档。

---

步骤 6：设置 Launch Control Tower 监控

Agent 询问：

Launch Control Tower 提供实时监控，以便在问题演变成严重故障前发现缺口。

监控内容（三个维度）：

1. Agent 性能：

• Agent 是否按时完成任务？
• 输出是否达到质量标准？
• Agent 是否将令牌用量和成本控制在预算内？

2. 组织准备情况（如要推出某项功能）：

• 支持准备情况：文档是否已更新？培训是否已完成？升级处理路径是否已明确？
• 营销准备情况：宣传信息是否已定稿？素材是否已制作？GTM 计划是否已敲定？
• 运营准备情况：基础设施是否已扩容？是否已部署监控？回滚计划是否已就绪？

3. 风险标记：

• Agent 是否生成了意外输出？（可能存在幻觉）
• Agent 是否违反了约束？（伦理／合规问题）
• 交接是否失败？（Agent B 未能正确接收 Agent A 的输出）

监控方式：

选项 1：手动仪表板

• 每周由 PM 审查 Agent 输出
• 抽查质量，并与黄金数据集进行比较
• 手动识别风险标记

选项 2：自动监控

• Agent 将输出记录到中央仪表板
• 对每项输出运行自动化评测（见步骤 7）
• 质量低于阈值时触发警报

选项 3：混合方式

• 自动化评测 + 每周 PM 审查
• 关键问题触发警报，PM 抽查其他输出

哪种监控方式适合你们团队的成熟度？

选项：

1. 手动仪表板（成熟度较低、规模较小）
2. 自动监控（成熟度较高、规模较大）
3. 混合方式（推荐大多数团队采用）

用户回复：[选择]

**Agent 提供：**包含具体指标和警报阈值的监控计划。

---

步骤 7：制定评测计划

Agent 询问：

为了确保编排后的工作流能够产出高质量结果，我们需要一套评测框架。

四种评测类型（基于研究）：

评测类型	方法	使用时机
黄金数据集	20–100 个真实输入与预期输出示例	衡量基准质量
代码断言	输出必须遵循的规则（例如，必须包含有效的 JSON）	结构验证
LLM-as-Judge	由强大的模型（GPT-4o）为 Agent 输出评分	快速自动反馈
人工评测	PM 手动审查追踪记录	最终检查“品味”和“产品判断力”

评测流程：

1. **收集追踪记录：**记录每次 Agent 运行的输入和输出
2. **每周审查：**为追踪记录添加注释，对失败模式进行分类
3. **建立失败模式分类体系：**常见错误（幻觉、违反约束、质量低下）
4. **创建自动化评测：**使用黄金数据集或代码断言，针对常见失败模式进行评测
5. **迭代：**根据评测结果优化 Agent 提示词／上下文

对于你们的工作流，哪些评测方式合适？

选项：

1. 从黄金数据集开始——为每个 Agent 创建 20 个高质量输出示例
2. 从代码断言开始——定义结构规则（例如，输出必须是包含必需字段的有效 JSON）
3. 从人工评测开始——前 2 周由 PM 审查每项输出，并识别规律
4. 三种方式全部采用——全面的评测策略（推荐用于关键工作流）

用户回复：[选择]

**Agent 提供：**包含具体评测类型、频率和成功标准的评测计划。

---

第 8 步：实施计划与后续步骤

Agent 综合整理：

以下是完整的编排工作流计划：

┌─────────────────────────────────────────────────────────────┐
│ ORCHESTRATED WORKFLOW: [Your Task Name]                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│ TOPOLOGY: [Full Parallel / Pipeline / Hybrid]              │
│                                                             │
│ AGENTS:                                                     │
│ • Agent A: [Name] - [Purpose]                              │
│ • Agent B: [Name] - [Purpose]                              │
│ • Agent C: [Name] - [Purpose]                              │
│                                                             │
│ FLOW:                                                       │
│ [Agent A] ─┐                                                │
│ [Agent B] ─┼─→ [Agent D] → [PM Review] → [Decision]        │
│ [Agent C] ─┘                                                │
│                                                             │
│ CONTEXT BOUNDARIES:                                         │
│ • Always-available: [List]                                  │
│ • Retrieved on-demand: [List]                               │
│                                                             │
│ STRATEGIC INTENT:                                           │
│ • Mission: [Per agent]                                      │
│ • Constraints: [Per agent]                                  │
│ • Priorities: [Per agent]                                   │
│                                                             │
│ MONITORING:                                                 │
│ • Approach: [Manual / Automated / Hybrid]                   │
│ • Metrics: [List]                                           │
│ • Alert thresholds: [List]                                  │
│                                                             │
│ EVALUATION:                                                 │
│ • Golden Datasets: [Y/N]                                    │
│ • Code Assertions: [Y/N]                                    │
│ • Human Evals: [Frequency]                                  │
│                                                             │
│ TIME SAVINGS:                                               │
│ • Manual (old): [X hours]                                   │
│ • Orchestrated (new): [Y hours]                             │
│ • Savings: [X-Y hours per week]                             │
└─────────────────────────────────────────────────────────────┘

实施路线图：

第 1 周：构建上下文基础

• 如果尚未完成，请完成 context-engineering-advisor
• 创建约束注册表和操作术语表
• 记录每个 Agent 的战略意图

第 2 周：实施第一个 Agent

• 从最简单的 Agent 开始（通常是研究或数据收集）
• 使用 5 个真实示例进行测试
• 验证输出质量

第 3 周：添加其余 Agent

• 实施 Agent 2–5（视你的工作流而定）
• 测试 Agent 之间的交接
• 验证完整工作流的端到端运行情况

第 4 周：设置监控与评估

• 实施选定的监控方案
• 创建黄金数据集（如果已选择）
• 开展第一周的人工评估，识别失败模式

第 5 周及以后：迭代与扩展

• 根据评估结果完善 Agent 提示词
• 添加针对常见故障的自动化评估
• 扩展至更多使用场景

成功标准：

• ✅ 时间节省：人工工作量减少 30% 以上
• ✅ 质量：Agent 输出在 80% 以上的情况下达到质量标准
• ✅ 一致性：输出在 95% 以上的情况下符合模板／格式要求
• ✅ 监控：在 PM 发现问题之前发出警报
• ✅ 评估：记录失败模式分类，并落实自动化评估

Agent 提供以下选项：

你希望我：

1. 导出此工作流计划为 Markdown 文档？
2. 提供实施模板（Agent 提示词模板、监控仪表板、评估清单）？
3. 推荐工具来构建此编排方案（Claude Projects、自定义 API、编排平台）？

---

示例

示例 1：竞争情报编排

背景：

• B2B SaaS 公司的 PM
• 跟踪 10 家竞争对手
• 人工流程：每周 12 小时（研究、综合整理、差距分析）

目标： 通过编排工作流将耗时缩短至 6 小时

工作流设计：

Agent：

• Agent A（研究）： 抓取竞争对手的产品页面，提取功能
• Agent B（发布跟踪）： 监控发行说明、博客和社交媒体，跟踪新产品发布
• Agent C（定价分析）： 跟踪定价页面，识别变更
• Agent D（综合整理）： 将 A、B、C 的发现汇总为结构化报告
• Agent E（差距分析）： 比较我们的路线图与竞争对手，标记战略差距

拓扑结构： 混合式（A、B、C 并行运行 → D → E → PM 审核）

战略意图：

• 使命（Agent E）：“识别可能影响 Q2 路线图的竞争威胁”
• 约束（Agent E）：“不要推荐超出我们战略重点领域（企业安全、AI 驱动的分析）的功能”
• 优先级（Agent B）：“优先关注过去 30 天内发布的功能”

监控：

• 混合方案：自动化评估 + 每周 PM 审核
• 指标：Agent 完成时间、输出质量评分（大模型评审）
• 警报：如果 Agent E 标记出超过 5 个严重差距（潜在战略威胁）

评估：

• 黄金数据集：20 个综合整理良好的竞争分析报告示例
• 代码断言：输出必须是包含必需字段（competitor、features[]、pricing[]、launch_date）的有效 JSON
• 人工评估：PM 每周审核一次完整的工作流运行结果

结果：

• 时间：12 小时 → 6 小时（节省 50%）
• 质量：格式一致，未遗漏竞争对手
• 战略价值：差距分析比人工流程提前 2 周标记出威胁

---

示例 2：客户反馈综合分析

背景：

• 消费类应用的 PM
• 每周收到 200 多条反馈（应用商店评价、支持工单、NPS 评论）
• 手动处理：每周 8 小时（阅读、标记、归纳主题）

**目标：**通过编排工作流，将耗时缩短至 2 小时

工作流设计：

Agent：

• **Agent A（数据采集）：**从 App Store、Google Play、Zendesk、NPS 调查中收集反馈
• **Agent B（标记）：**按类别标记反馈（缺陷、功能请求、易用性、性能）
• **Agent C（情感分析）：**对情感进行分类（正面、中性、负面、严重）
• **Agent D（主题提取）：**识别反馈中反复出现的主题
• **Agent E（优先级排序）：**根据出现频率 + 情感强度为主题评分
• **Agent F（综合分析）：**生成每周综合报告，列出排名前 5 的主题及示例引言

**拓扑：**流水线（A → B → C → D → E → F → PM 审核）

战略意图：

• 使命（Agent D）：“识别尚未满足的客户需求，这些需求有可能转化为路线图机会”
• 约束（Agent E）：“即使严重缺陷出现频率不高，也不得降低其优先级”
• 优先级（Agent F）：“聚焦过去 7 天内影响 10 名以上用户的主题”

监控：

• 自动化：仪表板显示 Agent 完成状态和错误率
• 警报：如果 Agent C 标记出超过 10 条“严重”情感项目（立即上报给 PM）

评估：

• 黄金数据集：50 个标记准确、综合分析完善的反馈示例
• LLM-as-Judge：每周评估 Agent D 的主题提取质量
• 人工评估：PM 抽查 10% 的已标记反馈

结果：

• 耗时：8 小时 → 2 小时（节省 75%）
• 质量：现在的主题有量化数据（出现频率、情感）作为依据
• 战略价值：识别出 3 个高影响力主题，并将其转化为 Q2 路线图功能

---

示例 3：大规模风险分析

背景：

• 企业平台的 PM
• 需要对 50 项功能进行风险分析（安全、合规、性能、易用性）
• 手动处理：15 小时（每项功能 30 分钟）

**目标：**通过编排工作流，将耗时缩短至 5 小时

工作流设计：

Agent：

• **Agent A（安全风险）：**分析功能的安全漏洞（数据暴露、身份验证问题）
• **Agent B（合规风险）：**检查功能是否符合监管要求（GDPR、HIPAA、SOC2）
• **Agent C（性能风险）：**估算负载影响，识别扩展性问题
• **Agent D（易用性风险）：**标记复杂工作流和无障碍访问问题
• **Agent E（综合分析）：**汇总风险评分并生成风险矩阵

**拓扑：**完全并行（A、B、C、D 同时运行 → E → PM 审核）

战略意图：

• 使命（所有 Agent）：“标记可能延迟发布或损害客户的风险”
• 约束（Agent B）：“必须引用具体的监管要求（不得给出含糊的警告）”
• 优先级（Agent E）：“按影响程度 × 发生可能性对风险排序（标准风险矩阵）”

监控：

• 自动化：仪表板显示风险分布（低/中/高/严重）
• 警报：如果任何功能的风险评分为“严重”（上报给 PM 和领导层）

评估：

• 黄金数据集：30 个分析完善且已知风险的功能示例
• 代码断言：风险评分必须为 {low, medium, high, critical}，不得使用其他值
• 人工评估：安全团队每月审核 Agent A 的输出

结果：

• 耗时：15 小时 → 5 小时（节省 67%）
• 质量：所有 50 项功能的风险评分保持一致
• 战略价值：识别出 3 个在人工审核中可能被遗漏的严重风险

---

常见陷阱

1. 先编排，后构建上下文

**失败模式：**在没有上下文基础（约束、术语表、证据标准）的情况下构建 Agent 工作流。

**后果：**Agent 输出不一致、违反约束、产生幻觉。

**修复方法：**先完成 context-engineering-advisor。构建约束注册表、运营术语表和战略意图文档。

---

2. 过度编排简单任务

失败模式： 为每周耗时不足 2 小时的任务创建复杂的多 Agent 工作流。

后果： 编排开销（设置、监控、维护）超过节省的时间。

解决方法： 只对每周耗时 5 小时以上，或需要大规模保持一致性的任务进行编排。

---

3. 没有评估计划

失败模式： “设置好就不管了”——Agent 在没有质量检查的情况下运行。

后果： 质量随时间下降、幻觉未被察觉、违反约束。

解决方法： 至少实施黄金数据集 + 每周人工评估。建立失败模式分类体系，并创建自动化评估。

---

4. 忽视交接失败

失败模式： 未经测试便假定 Agent 能正确地相互传递数据。

后果： Agent B 收到来自 Agent A 的格式错误数据，输出垃圾内容。

解决方法： 明确测试交接。验证每次交接时的数据格式。使用代码断言强制检查结构。

---

5. 忘记“PM 审核”步骤

失败模式： 将编排后的工作流视为完全自主运行，不进行人工监督。

后果： Agent 作出的决策缺乏背景、同理心或战略一致性。

解决方法： 始终加入 PM 审核步骤。Agent 生成假设或建议；PM 进行验证并作出决策。

---

参考资料

相关技能

• context-engineering-advisor（交互式）— 前置条件： 在编排之前构建上下文基础
• ai-shaped-readiness-advisor（交互式）— 评估 Agent 编排成熟度（能力 #2）
• pol-probe-advisor（交互式）— Vibe Coding 关联（快速原型开发）
• discovery-process（工作流）— 在探索阶段使用编排后的 Agent

外部框架

• Dean Peters — The Product Manager as an Orchestrator（Productside 研究）
• Dean Peters — Productside Blueprint（四种 AI 管理工作流：上下文工程、合成评估、Agent 工作流、Vibe Coding）
• Teresa Torres — Continuous Discovery Habits（AI PM 的五项准则：上下文工程、编排、可观测性、评估、维护）
• Marty Cagan — Empowered（四大风险：价值、易用性、可行性、可持续性）

工具与平台

• Claude Projects — 在一个项目中使用多个 Agent 进行简单编排
• LangChain — 用于构建 Agent 链的框架
• LangGraph — 用于复杂工作流的状态机编排
• n8n / Zapier — 无代码工作流自动化（更简单的编排）