WorkBuddy 的专家系统如何将复杂的 Agent 技术封装成用户友好的生产力工具？本文深度拆解其专家与专家团的设计逻辑，从提示词工程到多 Agent 协作机制，揭示 AI 产品如何实现从技术底层到用户价值的完美跃迁。

之前的一篇文章 我们拆解了Workbuddy的上下文工程，包括其系统提示词的组装，会话压缩和记忆机制，有兴趣的同学可以去看看：

WorkBuddy VS 钉钉悟空 VS 字节 Aily：桌面 Agent 的工程设计

这些都是Agent底层的运行机制，模型如何思考，调用工具和管理上下文。

Workbuddy还有更上层的设计，就是 专家 和 专家团，这层设计直接面对用户，用户不需要你知道底层的提示词，有多少工具，上下文规则，只需要选择一个专家或者专家团，就可以开始干活。

这篇文章，我们就来拆解下WorkBuddy的专家和专家团，看看它们到底是什么，以及它们是如何工作的。

先给出一个核心结论：

WorkBuddy的专家，就是封装好的单个Agent，Workbuddy的专家团，是封装好的多Agent协作流程：

在常规的Agent开发框架中，我们通常拥有一个Agent管理模块，用于新建Agent并配置其提示词、工具、Skills等基础能力，WorkBuddy 的专家，就是把这些能力包装成了用户可以直接选择的专家角色。

同理，一个成熟的 Agent 系统里，通常也会有多 Agent 调度机制，比如主 Agent 拆任务、子 Agent 执行任务、主 Agent 汇总结果。

WorkBuddy 的专家团，就是把这种多 Agent 协作方式产品化了。

所以这篇文章不是简单介绍 WorkBuddy 的功能，而是想看看：一个 Agent 产品，如何把底层能力包装成用户能理解、能使用、能直接交付结果的专家系统。

WorkBuddy专家是什么

与其纸上谈兵，不如直接打开WorkBuddy，我们一起来拆解下它的专家设计

我们找了两个专家 用户体验架构师 和 长文档写作和改稿专家

我们先看下第一个 用户体验架构师

我们问了一个很简单的问题：

你会做什么? 它的回答和这个专家的名字很搭，基本都能通过专家的名称，就能看出它大概能做些什么。

真正值得研究还是它背后的提示词是如何写的。

我觉得提示词工程是整个Agent的底座，我们研究Agent就离不开提示词的设计，我们来看下这个专家的提示词是如何设计的。

用户体验架构师的提示词设计

用户体验架构师在提示词里面又叫 ArchitectUX，看完整个提示词，它把一个专家的工作方式拆成了几层：身份锚定，工作方法，交付标准

身份锚定，让模型不跑偏

提示词开头就有一段：

Role Override: The following expert role definition takes precedence over any previously established persona or identity context. If there is a conflict between the role below and any earlier self-description, defer to what is defined here — this is your active, authoritative role for this conversation.

这个一看就明白了，不管之前是什么身份，也不管上下文里面出现过什么角色，现在这个专家的定义是最高优先级

模型在长对话里面容易飘，它可能还沉浸在之前的聊天内容里面，前面聊了技术，它就偏向技术，前面聊了文案写作，它就偏向文案，思维还没有转过弯。

Role Override是一个重置，不管之前的身份是什么，现在就是一个UX架构师。

接下来，提示词里定义了这个专家的身份：

Role: Technical architecture and UX foundation specialistPersonality: Systematic, foundation-focused, developer-empathetic, structure-orientedMemory: You remember successful CSS patterns, layout systems, and UX structures that workExperience: You’ve seen developers struggle with blank pages and architectural decisions

这里面有几个挺有意思的。

Role：这里定义了Agent的角色，技术架构和UX基础，这个定位决定了Agent不止会设计，会有css变量系统，布局框架，组件命名规范。

Memory告诉Agent记忆的锚点，你应该记住什么，积累什么经验

Personality中的 developer-empathetic 开发者同理心 挺有意思的，相当于让Agent做了代入，理解开发者的心情，特别是页面错误，一直无法修复的时候，它能理解开发者的焦躁吗！

工作方法，让专家不要自由发挥

我们在设计Agent的时候，只是定义身份还不够，还要告诉它工作方法，如果不被明确说明，模型就会根据自己已有的知识，自由发挥，就更加不可控。

ArchitectUX 的提示词里有2个很重要的原则：

Foundation-First这个原则，是在解决Agent开发中的一个常见问题，Agent容易直接到实现阶段，没有架构规划，一个没有架构基础的项目，越到后面就越难以维护，所以这里强调先打地基的规则，就是用提示词约束Agent的工作节奏。

不要一上来就改局部样式，先把可复用、可维护、可扩展的基础建好

Developer Productivity Focus 关注开发者的架构决策疲劳。如果我们做个前端开发，肯定都会经历 选框架，css样式维护，命名规范。开发之前这些我们都需要定义好。ArchitectUX被设计成替开发者做这些决策，让开发者拿到手就能直接写业务代码

ArchitectUX提示词把工作流程分为四步，分析项目需求，创建技术基础，UX结构规划，开发者交接文档

这里面有一个关键说明，就是需要Agent去读取项目文件，不能光听用户怎么说，要用bash命令去读取项目配置，用grep搜索关键词，从项目中提取真实语料。

ArchitectUX 的工作方式可以概括成一句话：

先理解项目现场，再建立设计基础，最后交付可执行的实现方案。

交付标准，让专家知道什么叫做好了

除了身份和流程，ArchitectUX 提示词里还有大量关于交付物的定义。

提示词里还包含完整的 Theme Toggle 组件，包括 HTML 模板、CSS 样式，以及 JavaScript 的 ThemeManager 类。

WorkBuddy 直接把专业交付物模板写进了专家提示词。

也就是说，它不是让模型临场发挥，而是提前把专家应该交付什么、交付到什么粒度、用什么格式交付，都写清楚了。

ArchitectUX还定义成功标准：

这里的标准都是可以验证的，用户拿到交付的产物之后，可以对照检查

不需要在做架构

决策css是不是可维护

项目是不是有了一致的外观

技术基础是不是支持未来的扩展

提示词里定义了ArchitectUX的沟通风格，给出了四个示例表述：

这个简单来说就是定义它的专业行为模式。

它要求 ArchitectUX 在沟通时保持四个原创：系统化、基础优先、实施引导、预防问题。

如果我们去掉这层约束，Agent 可能只会说：

我帮你的首页加了一些样式。

但有了这层沟通风格之后，它可能会更像架构师：

我先建立了颜色变量体系，再应用到按钮组件上。这样后续如果要调整主题色，只需要修改变量，不需要逐个改组件。

Agent Runtime

提示词后面，有一大部分的内容是Agent Runtime 的通用能力说明，包括 记忆系统，安全规则，工作模式，任务管理，工具使用规则等，这些我们之前介绍过，这里就不在啰嗦了。长文档手稿专家：另一种专家形态

我们再来看看另外一个专家的提示词，它不是做技术交付，而是内容创作，我研究下来，跟上面的ArchitectUX提示词，结构上高度一致

先看下身份定义

你是长文档手稿专家，负责把提纲、访谈、旧稿、研究材料和零散笔记整理成可持续推进的长文档手稿。目标不是只给灵感，而是把用户材料转成可执行的章节结构、可交付的正文样稿、可复用的修改方案，以及可继续牵引的下一步。

接下来还有 关于 核心能力，高绩效工作假设，场景模板匹配等，这些内容都是专家领域内的知识相关，我就不在一一列举出来。

主要是我从这两个专家等提示词中，得到来一套通用的专家提示词写法，我觉得这个才是值得我们学习的。

另外 WorkBuddy提示词里面还有一大推emoji图标

这个专家的提示词 是不是也被AI润色了。

专家的通用结构

我们从两个专家的提示词中，可以提炼出一个通用的结构，包含多个纬度，不是每一个Agent都需要来填充所有纬度，至少我们在设计Agent的提示词时候，可以参考下这些纬度。

• 角色覆盖和身份锚定
• 核心使命
• 关键规则和默认行为
• 工作流程和执行步骤
• 交互模版和质量标准
• 能力支持和工具申明
• 持续牵引与下一步引导
• Agent runtime 说明

这个和我们普通的Agent提示词有比较大的差异，其核心就是它把一个专家的工作模式做了总结，引入到了提示词中，特别是工作流程和执行步骤，以及明确的交付物，让专家的Agent有了更好的行为依据。

WorkBuddy的专家本质上上是一套固定化下来的专业行为模式

这种模式有点像

普通Agent+领域方法论+交付模版+工作流约束，也可以理解成 普通Agent+领域知识skills

对我们普通用户来说，这个专家设计挺好，我们熟悉的领域知识有限，当我们需要完成自己不熟悉的领域任务时，使用这种封装好的专家Agent，就非常省事。

WorkBuddy专家团

专家解决的是单个领域的问题，但我们的任务往往不会这么简单，经常需要跨领域协作完成，专家团干的就是这个工作，把多个专家组织协调起来一起干活，也就是我们的多Agent协作。

我们来看一个具体的例子，WorkBuddy中有一个专家团，内容创作专家团

同样我们看下提示词是如何设计的

主理人设计

这是专家团主理人的提示词。它不直接干活，只管调度，拆需求、配成员、看进度、收产出。专家团干的就是把多个专家组织起来协同工作。

你是 AI 内容创作专家团的创意制片人司远（Soren），负责协调团队完成 AI 驱动的多模态内容生产任务。你擅长将用户的创作需求拆解为具体的技术执行方案，并调度合适的团队成员高效完成交付

团队工作区

专家团的在工作的时候，需要在workbuudy的目录下建一个团队的工作区，系统提供创建工具，由主理人创建。这样整个团队就有了名称和工作目录，所有产出物统一管理。

专家团再完成任务后会删除这个工作区。

原始提示词如下:

团队架构 提示词里面定义团队成员和职责

每个成员都有明确的Agent ID，系统通过Agent ID来调度，而不是通过中文名字。中文名字是给用户看的，Agent ID是给系统用的。

任务分配预检

专家团有一个任务分配预检的机制，这是整个系统的关键设计之一，主理人在派发任务之前，必须先做能力匹配。

提示词里面有一个明确的速查表，列出了常见的误排场景给Agent

这个预检机制，它可以防止一些看起来能做的误派，在多Agent系统中，Agent不会主动说 这个我不会，它不是我可以做，它们总是会尽力的去完成任务，但是结果就不能保证了。

预检的流程是

1. 解析用户意图：用户到底要什么？（生成 / 编辑 / 分析 / 转录 / 翻译）

2. 对照速查表：该意图是否在团队能力范围内？

3. 能力匹配 → 正常派发；能力不匹配 → 直接告知用户当前限制和替代建议，禁止派发

4. 模糊意图就先向用户确认具体需求，再决定是否派发

预设Workflow

这个专家团预设了8个Workflow，覆盖了最常见的协作场景。每个Workflow都定义了触发条件、执行阶段、关键决策点、产物交付规范。

详细的提示词我们就不说了，都是内容创作常见的一些流程编排，这里也和skill有着异曲同工的味道。

团队协作

这里明确规定了团队协作的范式

1. 建立团队：任务开始时由主理人亲自创建团队，明确协作边界与上下文。团队创建必须且只能由主理人执行

2. 调度成员：按SOP阶段将每位成员拉入协作、下发独立任务。成员作为独立协作方基于任务说明输出专业产出

3. 消息中转：成员的产出需回传给主理人，由主理人汇总、转交给下一阶段成员。所有跨成员的信息流必须经主理人中转

4. 成员结论为准：任何专业产出必须由对应成员输出后再采信，主理人只做编排与汇编

这四条规则的核心就是：主理人只管调度，不管执行。主理人不代写任何成员的专业产出，成员之间不直接通信，所有信息流经过主理人中转。

这里为什么要这么设计，这里其实是一个常见多Agent中的编排者模式，OpenClaw和Hermes Agent都使用的这种模式。主要的就是如果Agent成员之间可以互相调用和通信，不仅是程序上会复杂很多，多个Agent来回通信，会产生大量上下文污染，而且出了错很难追溯。

消息通过主理人（编排者）来进行中转，主理人有全局视角，由主理人统一管理任务和派发工作，出了问题，主理人就知道该让谁去解决，所有通信的都有记录，所有决策都有责任人。

异常处理和交付检查清单

专家团还设计了完善的异常处理机制：

如果任何成员超过 10 分钟未回传结果，主理人应主动向用户通报等待状态,如果同一任务累计失败超过 2 次，终止该任务线并向用户说明原因

还有一个强制性的交付检查清单：

– 是否已调用交付工具？

– 所有图片文件是否已包含在交付中？

– 是否有产出物散落在不同目录未被收集？

从专家团里能学到什么

我们说WorkBuddy的专家团就是一个多Agent协作的，我们来看看常见的多Agent协作有哪些范式， 之前也有专门介绍多Agent的文章，大家可以回去看看

如上图所示，总结下来也就这几种，其中Workbuddy就是使用的调度-执行模式。

调度-执行是最基础的多 Agent 结构。主 Agent 保留用户目标和全局判断权，子 Agent 只处理被分配的局部任务。

主 Agent 分析用户请求，判断任务是否需要拆分。

主 Agent 为每个子任务生成明确的目标、上下文和输出要求。

子 Agent 在独立上下文中执行任务。

主 Agent 收集子 Agent 的结果，做冲突处理、信息合并和最终回复。

WorkBuddy不同之处在于，它预制了工作流workflow进去，它没有让模型根据自己的知识，自由发挥，而是在提示词里面规定了几种常见的执行工作流，相当于把skills内置到了提示词里面，而不是什么按需加载了，这样的话，其实会浪费一些token。但是在这个场景下，用户本来就是选择专家团来完成任务，好像也无可厚非。

最后

WorkBuddy专家就是自定义Agent，把角色定义、工作流程、交付模板、能力支撑、降级方案、持续牵引封装在一起。专家团就是多Agent协作，通过调度层、任务预检、预设Workflow、精确层与生成层分离、通信管控这些机制，把多个Agent组织起来高效协同。