跳转至

WorkBuddy专家团提示词全曝光：多Agent协作原来是这样产品化的

Ch01.533 WorkBuddy专家团提示词全曝光：多Agent协作原来是这样产品化的

📊 Level ⭐⭐ | 12.0KB | entities/workbuddy专家团提示词全曝光多agent协作原来是这样产品化的.md

WorkBuddy专家团提示词全曝光：多Agent协作原来是这样产品化的

摘要

本文深入拆解了 WorkBuddy 的"专家"和"专家团"两层产品架构。WorkBuddy 的"专家"是封装好的单 Agent 能力单元——包含身份锚定、工作方法、交付标准和沟通风格在内的完整提示词体系；"专家团"则是封装好的多 Agent 协作流程——通过主理人（编排者）、任务预检机制、预设工作流（Workflow）、通信管控等机制，将多个专家组织起来高效协同。文章从具体提示词出发，提炼出通用 Agent 产品设计的方法论：普通 Agent + 领域方法论 + 交付模板 + 工作流约束 = 可产品化的专家系统。

核心要点

  • WorkBuddy 的专家 = 封装好的单 Agent：将提示词、工具、Skills 等基础能力包装成用户可直接选择的产品化角色。提示词设计包括身份锚定、工作方法、交付标准三大层面。
  • WorkBuddy 的专家团 = 封装好的多 Agent 协作流程：采用编排者模式（主理人调度、成员执行），包含任务预检、预设 Workflow、通信管控等机制。
  • 身份锚定（Role Override）：提示词开头的优先级声明确保 Agent 不受长对话中的上下文污染影响，重置角色为当前专家定义。
  • Foundation-First 原则：约束 Agent 不要直接跳到实现阶段，而是先建立架构基础——"先打地基再盖楼"的工作节奏。
  • 团队协作范式：主理人只管调度不管执行、成员之间不直接通信、所有信息流经主理人中转——这是编排者模式的落地实现，避免多 Agent 通信带来的上下文污染和错误追溯困难。

深度分析

Agent 产品化的核心挑战：从能力到体验

WorkBuddy 的专家系统设计回答了 Agent 产品化的一个核心问题：如何将底层的大模型能力封装为用户能理解、能使用、能交付结果的产品？

这个问题的关键在于"产品化"的两个层次：

  1. 能力封装：将提示词、工具、记忆、Skills 组合成具有特定领域能力的"专家"。
  2. 体验封装：让用户不需要理解底层运行机制，只需选择一个专家或专家团就能直接开始工作。

WorkBuddy 的解法是在提示词层面做文章——不是让模型自由发挥，而是通过精心设计的提示词模板，将专业行为模式固定下来。这种方式与 Hermes Agent 的 Skills 机制 有异曲同工之妙：都是将可复用的行为模式从零散的上下文描述中提取为结构化、可加载的能力单元。

提示词的"四层架构"

从 WorkBuddy 的 "ArchitectUX" 和 "长文档手稿专家" 两个专家的提示词中，可以提炼出通用的四层架构：

第一层：身份锚定（Role Override + Identity）

  • 通过 Role Override 声明当前角色的最高优先级，防止上下文污染
  • 定义 Role（角色定位）、Personality（人格特质）、Memory（记忆锚点）、Experience（经验背景）
  • 例如"developer-empathetic"（开发者同理心）让 Agent 能理解开发者的焦躁情绪

第二层：工作方法（Workflow + Principles）

  • Foundation-First：先建基础再盖楼，约束 Agent 不跳到实现阶段
  • Developer Productivity Focus：替开发者做架构决策，消除决策疲劳
  • 明确的四步工作流程：分析项目需求 → 创建技术基础 → UX 结构规划 → 开发者交接文档
  • Agent 必须读取项目文件，用 bash/grep 从项目中提取真实语料，而非仅依赖用户描述

第三层：交付标准（Quality Gates + Success Criteria）

  • 具体的交付物模板（如 Theme Toggle 组件的完整 HTML/CSS/JS）
  • 可验证的成功标准："不需要再做架构决策"、"CSS 是否可维护"、"项目是否有一致外观"
  • 沟通风格定义：系统化、基础优先、实施引导、预防问题

第四层：Agent Runtime 集成

  • 记忆系统、安全规则、工作模式、任务管理、工具使用规则的通用说明
  • 这些是 Agent 运行时的基础设施，与具体领域无关

专家团的编排者模式深度分析

WorkBuddy 专家团采用的编排者模式（Orchestrator Pattern）是目前多 Agent 系统的主流架构之一。文章揭示了该模式在实际产品中的精细设计：

主理人（Orchestrator）的职责边界：

  • 拆需求、配成员、看进度、收产出——但不执行任何专业任务
  • 不代写任何成员的专业产出
  • 所有跨成员信息必须经主理人中转

为什么成员之间不直接通信？ - 程序复杂性：成员间直接通信需要复杂的服务发现和消息路由 - 上下文污染：多个 Agent 来回通信会产生大量无关上下文 - 错误追溯困难：没有中心化的通信记录，出问题难以定位

这与 AgentCore Harness 的 AWS 多 Agent 系统 中的"集中编排"设计模式一致。实际上，OpenClaw 和 Hermes Agent 也采用这种模式。

任务分配预检机制——这是一个关键的设计创新：

  • 速查表列出常见的能力边界和误派场景
  • Agent 在派发任务前必须先做能力匹配
  • 不匹配时直接告知用户，而不是尽力去完成（避免产生不可靠的结果）
  • 模糊意图时先向用户确认具体需求，再决定是否派发

这个机制解决的是多 Agent 系统中一个普遍问题：Agent 不会主动说"我不会"。如果缺少预检，Agent 总是会尽力去完成被分配的任务，即使它不具备相应的能力。结果就是生成质量不可靠的输出，用户难以判断问题出在哪里。

预设 Workflow vs. 动态编排

WorkBuddy 专家团预设了 8 个 Workflow，覆盖最常见的协作场景。这意味着：

  • 优点：行为可预测，质量有保障，适合已知任务模式
  • 缺点：固定 Workflow 会消耗更多 token（即使未使用），且无法灵活应对未预设的新场景

这个权衡与 Skill Reward Model 研究 中关于"固定 skill vs 动态生成"的讨论相关。在产品化阶段，固定 Workflow 适合高频、已知、可标准化的任务；动态编排适合低频、创新、变化多的任务。WorkBuddy 选择前者，合理是因为它面向的是"用户选择专家团来完成已知类型的任务"这个场景。

从 WorkBuddy 看 Agent 产品的设计原则

从 WorkBuddy 的设计中可以总结出通用的 Agent 产品化原则：

  1. 行为固定化优于自由发挥：通过提示词模板将 Agent 行为约束在可预测范围内，而不是让其根据模型训练数据随意发挥。
  2. 角色即接口：每个"专家"都是一个明确的 API——输入（用户需求）、处理（专业工作流程）、输出（标准交付物）。
  3. 预检优于事后修复：在派发任务之前做好能力匹配检查，比在任务完成后发现错误更高效。
  4. 通信管控优于自由通信：中心化的消息中转虽然有性能开销，但换来了可追溯性、可管理性和错误定位能力。

实践启示

  1. 设计 Agent 产品的提示词时，采用"四层架构"：身份锚定 → 工作方法 → 交付标准 → Runtime 集成。每一层都约束一个维度的 Agent 行为，让提示词不再是"写给模型的说明"，而是一个可复用的"专业行为模式模板"。

  2. 对 Agent 团队实施"编排者模式"：一个主理人负责拆任务、派发、汇总、质量检查；成员专注于执行。成员之间不直接通信，降低系统复杂性和上下文污染风险。主理人只管调度、不管执行。

  3. 引入任务预检机制，避免 Agent"盲目执行"。定义清晰的能力边界速查表，在派发前检查 Agent 能力与任务需求的匹配度。不匹配时直接告知用户，而不是生成不可靠的结果。

  4. 为高频任务预设 Workflow，为低频任务保留灵活编排能力。例如，内容创作专家团的 8 个预设 Workflow 覆盖了最常见的协作场景，但系统也应支持用户自定义编排。

  5. 将"交付标准"内置到 Agent 提示词中。WorkBuddy 的精华在于它不仅告诉 Agent"做什么"和"怎么做"，还告诉它"什么样的结果算做好了"。这种"完成条件"定义让 Agent 能够自我评估、自我修正，减少了对用户反馈的依赖。

相关实体

相关主题