专家系统怎样把那复杂的Agent技术给封装成是用户友好型的生产力工具呢? 本文深入地去拆解它那专家跟专家团的设计的逻辑, 从提示词工程开始, 再到多Agent协作机制这段的内容, 用以揭示AI产品到底如何达成从技术底层一直到用户价值的那种完美的跃迁。过往的当中的一篇文章, 我们针对其进行了拆解的上下文工程, 涵盖了系统提示词的组装, 会话上的压缩以及运用了某种记忆机制, 有兴趣的同学能够去瞧一瞧:VS, 钉钉悟空, VS, 字节Aily, 桌面, Agent, 的, 工程, 设计。这些均是, Agent底层的, 运行机制, 针对于模型怎样去思考, 以及。调用工具, 还有管理上下文。并且存在着更往上一级的设计, 那便是专家以及专家团 , 这般一层的设计是径直与用户相对接触的 , 用户并不需要你去晓得底层的提示词 , 有多少工具 , 上下文规则 , 仅仅只需挑选一位专家或者一个专家团 , 便能够开启干活的进程。我们就针对这篇文章, 来拆解一下其中提到的专家, 再拆解一下其中提到的专家团, 先看看它们实际究竟是什么, 然后再看看它们到底是怎样开展工作的。先给出一个核心结论具有专业知识的人士, 那便是经过封装处理的单个智能体, 而由众多具有专业知识人士所构成的团体, 乃是经过封装处理的多个智能体协同合作的流程:在常规开发框架里, 框架是关于Agent的, 我们一般会有一个模块去管理Agent, 这个模块用来创建Agent, 还用来设定其提示词、工具等基础方面的能力, 有这样一类专家, 他们把这些能力弄成了用户能够直接去选择的专家角色。同样的道理, 在一个已然成熟的 Agent 系统之中, 往往也会存在着多 Agent 调度的机制, 举例来说这样表现, 主 Agent 去拆分任务, 子 Agent 进而执行任务, 之后主 Agent 再去汇总结果。的专家团就是把这种多 Agent 协作方式产品化了。所以, 这篇文章并非单纯对功能予以介绍, 而是旨在探究, 一个 Agent 产品, 究竟怎样将底层能力包装成为专家系统, 此专家系统要能让用户理解, 要能方便用户使用, 还要能直接交付结果。专家是什么与其纸上谈兵不如直接打开我们一起来拆解下它的专家设计我们找了两个专家 用户体验架构师 和 长文档写作和改稿专家我们先看下第一个 用户体验架构师我们问了一个很简单的问题你能够做些什么呢, 它所给出的回应, 跟这位专家的姓名十分契合, 基本上借助专家的名号, 便能够瞧出它大概是能够做些什么的。真正值得研究还是它背后的提示词是如何写的。我感觉提示词工程而言乃是整个Agent所需的底座, 我们若要对Agent展开研究, 那便脱离不开提示词的设计。我们现在来瞧一瞧, 专家所设计的提示词究竟是怎样的。用户体验架构师的提示词设计被称作用户体验架构师的, 在提示词这里又名为, 在看完整个提示词后, 它将一位专家的工作方式划分成了几层, 分别是身份锚定, 工作方法, 交付标准。身份锚定让模型不跑偏提示词开头就有一段这个, 仅看这么一眼就已然是清晰明了的了, 无论在此之前究竟是何种身份, 也无论于上下文当中究竟曾呈现过哪些角色, 然而当下, 这个专家的定义可是处于最高优先级的模型于长对话当中极易飘动, 它或许仍旧沉浸于先前的聊天内容之内, 前面谈及了技术, 它便倾向于技术, 前面聊的是文案写作, 它就青睐文案, 思维尚未转变过来。Role, 它属于一种重置, 无论先前的身份究竟是怎样的, 而当下呢现在已然呈现为一名UX架构师了。接下来提示词里定义了这个专家的身份职能: 以及用户体验, y: , - , - , -: 你, 层叠样式表, 以及用户体验指出: 你已经看到有空白页面的情况并且。这里面有几个挺有意思的。范畴规定了智能自主程序的职责类别, 技术构建体系与用户体验根基, 这般的界定使得智能自主程序不但能够施展布局操控, 还会涵盖层叠样式表变量机制, 页面布局架构, 组件取名依据准则。告诉Agent记忆的锚点你应该记住什么积累什么经验其中的, 开发者同理心, 是挺有意思的一个情况, 它等同于让Agent进行了代入, 进而去理解开发者彼时的心情, 专门是针对页面出现错误的情况而言, 但一直存在那样的状况, 且始终无法予以修复的时候呢。它能够对开发者心底的焦躁情绪做到理解吗工作方法让专家不要自由发挥在设计Agent之际, 仅仅定义身份是不足够的, 还得告知其工作方式, 倘若不被清晰阐明, 模型便会依据自身已有的知识进行自由发挥, 进而越发难以把控。的提示词里有2个很重要的原则首先这个原则, 是用于解决Agent开发里的一个常见问题, Agent常常容易直接进入实现阶段, 却没有架构层面的规划, 一个缺乏架构基础的项目, 越往后就越发难以进行维护, 所以在此强调先打好地基的规则, 也就是运用提示词去约束Agent的工作节奏。不要一开始就去改动局部那种样式, 要先把具备可复用特点、有着可维护特性、存有可扩展属性的基础建设好。集中注意力于开发者架构决策时所产生的那种疲劳, 要是我们进行前端开发, 那必然都会历经挑选框架, 对css样式加以维护, 遵循命名的规范, 在开发之前, 这些我们都得事先确定好, 被设计成替开发者去做这些决策, 从而使得开发者拿到手后就能够即刻去编写业务代码。提示词将工作流程划分成四步了, 先是对项目需求予以分析, 接着去创建技术基础, 然后进行UX结构的规划, 最后就有开发者交接文档。此之中存在一项关键说明, 即需Agent去读取项目文件, 不可仅依用户所言, 要运用bash命令去读取项目配置, 凭借grep程序搜索关键词, 于项目里提取真实语料。的工作方式可以概括成一句话先理解项目现场再建立设计基础最后交付可执行的实现方案。交付标准让专家知道什么叫做好了除了身份和流程 提示词里还有大量关于交付物的定义。提示词之中, 还涵盖着完整的Theme组件, 其中有HTML模板, 有CSS样式, 还有类。直接把专业交付物模板写进了专家提示词。就是说, 它并非是让模型在现场进行随机发挥, 而是预先, 把专家所需要去完成交付的具体内容, 和交付所应当达到的精确程度, 以及以何种特定格式去交付这般的情况, 全部确切地写明白了。还定义成功标准放在这儿的标准, 是皆可去验证的, 当用户把交到手中的产物拿到手后, 能够依照着进行对照检查。不需要在做架构决策css是不是可维护项目是不是有了一致的外观技术基础是不是支持未来的扩展提示词里定义了的沟通风格给出了四个示例表述这个简单来说就是定义它的专业行为模式。它发出要求, 在进行沟通这个行为的时候, 要维持四个原创, 分别是系统化, 还有基础优先, 以及实施引导, 此外还有预防问题。如果我们去掉这层约束Agent 可能只会说我帮你的首页加了一些样式。但有了这层沟通风格之后它可能会更像架构师颜色变量的整个体系, 是我先去建立而成的。形成体系之后, 我又将其应用到按钮组件之上。如此这般, 要是随后需要加以调整主题色, 仅仅只需要对变量进行修改就行, 并不需要对每个组件逐一进行修改。Agent提示词之后, 存在着一大部分内容, 那是Agent的通用能力说明, 它涵盖了记忆系统, 还有安全规则, 以及工作模式, 另外包括任务管理, 也涉及工具使用规则等方面, 这些内容我们在此之前已经介绍过了, 所以在这里就不再进行繁琐的赘述了。长文档手稿专家: 另一种专家形态。我们再次去查看查看另外一位专家给出的提示词, 它并非进行技术交付, 而是从事内容创作, 我经过研究, 发现它跟上面所提到的提示词, 在结构方面高度一致。先看下身份定义由你担任长文档手稿专家一职, 针对提纲、访谈资料, 还有旧稿、研究材料以及零散的笔记, 进行系统的整合, 最终形成能够实现连绵不断推进态势的长文档手稿。其目的并非仅仅给予灵感, 而是要将用户所提供的材料, 使之变革成为具备切实可行性质的章节架构雏形打造出能够实现交付目标的正文样稿范例, 构建起可以重复运用的修改方案体系, 以及构想出持续不断去牵引推动的下一个步骤发展方向。接下来, 还有关于核心能力的内容, 还有关于高绩效工作假设的内容, 还有关于场景模板匹配等的内容, 这些内容, 都是与专家领域内的知识有相关性的, 我就不将它们一一列举出来了。关键在于, 我经由这两位专家以及那些提示词, 获取到了一套具备通用性的专家提示词撰写方式, 我认为这才是值得我们去学习的。另外 提示词里面还有一大推emoji图标这个专家的提示词 是不是也被AI润色了。专家的通用结构从两位专家给出的提示词当中, 我们能够提炼出一种通用结构, 它涵盖多个维度, 并非每个Agent注定都要将所有纬度假以填充, 反正至少在设计Agent提示词之际, 我们能够参照这些维度。这个跟我们平常的Agent提示词存在较大差异, 它的核心在于, 它对一个专家的工作模式进行了总结, 而后将其引入到提示词里, 尤其是工作流程、执行步骤, 还有明确的交付物, 从而让专家的Agent有了更优的行为依据。的专家本质上上是一套固定化下来的专业行为模式这种模式有点像普通的Agent, 加上领域方法论, 加上交付的模版, 加上工作流的约束, 也能够被理解成就是, 普通的Agent加上领域知识。对于我们这些普通的用户来讲, 这个由专家所设计的是挺好的, 我们在熟悉的领域之中知识是有限的, 当我们有需要去完成自身并不熟悉的领域相关任务之际, 运用这种已经封装好的专家Agent, 那可就相当省事了。专家团专家所处理的是单个领域之内的问题, 然而我们的任务常常并非如此简单, 经常需要跨越不同领域进行协作才能够完成, 专家团所从事的正是这样的工作, 将多个专家组织起来并协调他们一同开展工作, 这也就是我们所说的多Agent协作。我们来看一个具体的例子中有一个专家团内容创作专家团同样我们看下提示词是如何设计的主理人设计这是由专家团主理人给出的提示词, 它不亲自动手去操作执行, 仅仅负责进行调度安排, 包括拆解需求, 配置成员, 查看进度以及收取产出。而专家团所从事的工作任务就在于将多个专家召集组织起来, 从而实现协同工作。你身为 AI 内容创作专家团里的创意制片人司远Soren承担着协调团队去开展 AI 驱动的多模态内容生产任务的职责, 你具备把用户的创作需求拆解成为具体的技术执行方案的能力, 并且能成功调度适宜恰当的团队成员高效地完成交付。团队工作区专家团于工作之际, 得在相应目录之下构建一个团队的工作区, 系统会提供创建工具, 此为创建工具由主理人来创建, 如此这般整个团队便拥有了名称以及工作目录, 进而所有产出物得以统一管理。专家团再完成任务后会删除这个工作区。原始提示词如下:团队架构 提示词里面定义团队成员和职责对每一个成员而言, 均有着清晰明白的Agent ID, 系统借助该Agent ID予以调度, 并非凭借中文名字。且中文名字乃是供用户去看的, Agent ID则是供系统来使用的。任务分配预检整个系统存在关键设计之一, 那就是专家团具备任务分配预检的机制, 主理人在进行派发任务这个行为之前, 一定要先去做能力匹配哦。提示词当中, 存在着一个清晰的速查表, 它把常见的误排场景, 罗列出来给 Agent。存在一种预检机制, 它能够起到防止某些看似能够完成的误派情况发生的作用, 在多Agent系统里, Agent不会主动表明自己不会做, 它并非自己所能做的范畴, 它们总会竭尽全力去完成任务然而结果却无法予以保证了。预检的流程是1. 要解析用户意图, 那用户究竟是想要什么? 是生成, 还是编辑, 又或者是分析, 亦或是转录, 甚至是翻译?2. 对照速查表该意图是否在团队能力范围内3. 能力若匹配, 便正常进行派发能力若不匹配, 那就直接向用户告知当下的限制以及替代的建议, 对此禁止进行派发。4. 模糊意图就先向用户确认具体需求再决定是否派发预设预设的这个专家团有8个, 覆盖那种最常见的协作场景, 每个都对触发条件、执行阶段、关键决策点、产物交付规范作出了定义。关于详细的提示词, 我们就不去讲了, 它们全都是内容创作当中常见的一些流程编排, 在这里, 这也和skill有着同样精妙趣味相同的意味。团队协作这里明确规定了团队协作的范式1. 开端之际, 主理人要亲自去着手创建团队, 清晰地界定出协作的边界, 以及整理好相关的上下文, 且团队创建这项事宜, 必须是主理人来执行, 只能由主理人来执行没有旁人可以替代。2. 将调度成员, 按照SOP阶段, 把每一位成员拉进协作里, 再下发独立的任务。成员作为独立的协作方, 依据任务说明, 输出专业的产出。3. 信息传递环节: 成员所产出的内容要传回去给主理人, 被主理人进行汇总, 而后转交到下一阶段的成员手上。全部跨越成员之间的信息流动都得经由主理人来进行中转。4. 以成员结论作为标准: 任何专业方面的产出, 都必须是由相应的成员进行输出之后, 才能够予以采信, 而主理人仅仅是从事编排以及汇编的工作。这四条规条的关键所在是, 主理者仅仅负责进行调度, 并不负责去执行, 主理者不会代劳撰写任何一位成员的专业性产出, 成员相互之间不会直接进行通信, 所有的信息流动都要经由主理者来进行中转。这里为何要这般设计呢, 这里实际上是一种在常见多 Agent 里的编排者模式, 并且 Agent 也都运用的是此类模式。关键之处在于, 如果 Agent 成员们彼此能够实现互相调用以及通信, 不只是程序会变得复杂许多, 多个 Agent 反复进行通信, 会引发大量上下文污染, 并且一旦出现错误就很难去追溯。消息借助主理人编排者实现中转, 主理人具备全局视角, 由主理人对任务予以统一管理并进行工作派发, 出现问题时, 主理人能够知晓应当让谁加以解决, 所有通信均存有记录, 所有决策均有责任担当者。异常处理和交付检查清单专家团还设计了完善的异常处理机制要是有任何一位成员在达到哪怕一分钟多九分钟之长的这个时间段后, 依旧没有回传成果, 那么那主理人应当基于主动态度前往向用户通报等待的状况情况, 如果是同一个任务总计总计失败的次数超过了两次这一数目时, 就要终止掉该任务线并且朝着用户讲清楚其中的缘由原因。还有一个强制性的交付检查清单– 是否已调用交付工具– 所有图片文件是否已包含在交付中– 是否有产出物散落在不同目录未被收集从专家团里能学到什么我们所提及的专家团便是为一种多Agent协作的情况, 我们来瞧一瞧较为常见的多Agent协作究竟有着哪一些范式, 之前曾经存在过专门对多Agent予以介绍的文章, 大家能够返回去予以查看。就像上面所呈现的图示那样, 综合归纳起来总共也就是这几种情形, 而这里面所运用的恰恰便是那种调度 - 执行模式。具有调度与执行情形这般模样的, 正是最为基础的多 Agent 结构。而其中的所谓以处理用户目的以及全局判断权力为职责的, 乃是主 Agent。但子 Agent 则明显相异, 却仅仅处理被分配的局部任务而已。主 Agent 分析用户请求判断任务是否需要拆分。有一个主 Agent, 它会为每一个子任务, 去生成清晰明确的目标, 再生成相应的上下文, 最后还会生成输出要求。子 Agent 在独立上下文中执行任务。主要的 Agent 去搜集子 Agent 所产生的结果, 进而开展冲突处理相关动作, 再进行信息合并方面的操作, 最终给出回复。有所不同的是, 它事先预制了工作流进去, 它并未让模型依据自身的知识, 自行随意发挥, 而是在提示词之中规定了几种常见的执行中的工作流, 这等同于将其内置到提示词里了, 并非是按需加载的那种情况了, 如此一来, 实际上会造成一些token的浪费。然而在这个特定场景下, 用户原本就是选择专家团来达成任务, 似乎也并无不妥之处。最后能够被称作专家的, 其实就是那种被自定义出来的Agent, 它会把角色定义、工作流程、交付模板、能力支撑、降级方案以及持续牵引这些方面, 全部封装在一块儿。而所谓的专家团呢, 则变成了多Agent协作的形式, 借助调度层、任务预检、预设、精确层与生成层相互分离、通信管控这些机制, 从而将多个Agent组织起来, 达成一种高效协同的状态。
WorkBuddy专家团提示词全曝光：多Agent协作原来是这样产品化的
专家系统怎样把那复杂的Agent技术给封装成是用户友好型的生产力工具呢? 本文深入地去拆解它那专家跟专家团的设计的逻辑, 从提示词工程开始, 再到多Agent协作机制这段的内容, 用以揭示AI产品到底如何达成从技术底层一直到用户价值的那种完美的跃迁。过往的当中的一篇文章, 我们针对其进行了拆解的上下文工程, 涵盖了系统提示词的组装, 会话上的压缩以及运用了某种记忆机制, 有兴趣的同学能够去瞧一瞧:VS, 钉钉悟空, VS, 字节Aily, 桌面, Agent, 的, 工程, 设计。这些均是, Agent底层的, 运行机制, 针对于模型怎样去思考, 以及。调用工具, 还有管理上下文。并且存在着更往上一级的设计, 那便是专家以及专家团 , 这般一层的设计是径直与用户相对接触的 , 用户并不需要你去晓得底层的提示词 , 有多少工具 , 上下文规则 , 仅仅只需挑选一位专家或者一个专家团 , 便能够开启干活的进程。我们就针对这篇文章, 来拆解一下其中提到的专家, 再拆解一下其中提到的专家团, 先看看它们实际究竟是什么, 然后再看看它们到底是怎样开展工作的。先给出一个核心结论具有专业知识的人士, 那便是经过封装处理的单个智能体, 而由众多具有专业知识人士所构成的团体, 乃是经过封装处理的多个智能体协同合作的流程:在常规开发框架里, 框架是关于Agent的, 我们一般会有一个模块去管理Agent, 这个模块用来创建Agent, 还用来设定其提示词、工具等基础方面的能力, 有这样一类专家, 他们把这些能力弄成了用户能够直接去选择的专家角色。同样的道理, 在一个已然成熟的 Agent 系统之中, 往往也会存在着多 Agent 调度的机制, 举例来说这样表现, 主 Agent 去拆分任务, 子 Agent 进而执行任务, 之后主 Agent 再去汇总结果。的专家团就是把这种多 Agent 协作方式产品化了。所以, 这篇文章并非单纯对功能予以介绍, 而是旨在探究, 一个 Agent 产品, 究竟怎样将底层能力包装成为专家系统, 此专家系统要能让用户理解, 要能方便用户使用, 还要能直接交付结果。专家是什么与其纸上谈兵不如直接打开我们一起来拆解下它的专家设计我们找了两个专家 用户体验架构师 和 长文档写作和改稿专家我们先看下第一个 用户体验架构师我们问了一个很简单的问题你能够做些什么呢, 它所给出的回应, 跟这位专家的姓名十分契合, 基本上借助专家的名号, 便能够瞧出它大概是能够做些什么的。真正值得研究还是它背后的提示词是如何写的。我感觉提示词工程而言乃是整个Agent所需的底座, 我们若要对Agent展开研究, 那便脱离不开提示词的设计。我们现在来瞧一瞧, 专家所设计的提示词究竟是怎样的。用户体验架构师的提示词设计被称作用户体验架构师的, 在提示词这里又名为, 在看完整个提示词后, 它将一位专家的工作方式划分成了几层, 分别是身份锚定, 工作方法, 交付标准。身份锚定让模型不跑偏提示词开头就有一段这个, 仅看这么一眼就已然是清晰明了的了, 无论在此之前究竟是何种身份, 也无论于上下文当中究竟曾呈现过哪些角色, 然而当下, 这个专家的定义可是处于最高优先级的模型于长对话当中极易飘动, 它或许仍旧沉浸于先前的聊天内容之内, 前面谈及了技术, 它便倾向于技术, 前面聊的是文案写作, 它就青睐文案, 思维尚未转变过来。Role, 它属于一种重置, 无论先前的身份究竟是怎样的, 而当下呢现在已然呈现为一名UX架构师了。接下来提示词里定义了这个专家的身份职能: 以及用户体验, y: , - , - , -: 你, 层叠样式表, 以及用户体验指出: 你已经看到有空白页面的情况并且。这里面有几个挺有意思的。范畴规定了智能自主程序的职责类别, 技术构建体系与用户体验根基, 这般的界定使得智能自主程序不但能够施展布局操控, 还会涵盖层叠样式表变量机制, 页面布局架构, 组件取名依据准则。告诉Agent记忆的锚点你应该记住什么积累什么经验其中的, 开发者同理心, 是挺有意思的一个情况, 它等同于让Agent进行了代入, 进而去理解开发者彼时的心情, 专门是针对页面出现错误的情况而言, 但一直存在那样的状况, 且始终无法予以修复的时候呢。它能够对开发者心底的焦躁情绪做到理解吗工作方法让专家不要自由发挥在设计Agent之际, 仅仅定义身份是不足够的, 还得告知其工作方式, 倘若不被清晰阐明, 模型便会依据自身已有的知识进行自由发挥, 进而越发难以把控。的提示词里有2个很重要的原则首先这个原则, 是用于解决Agent开发里的一个常见问题, Agent常常容易直接进入实现阶段, 却没有架构层面的规划, 一个缺乏架构基础的项目, 越往后就越发难以进行维护, 所以在此强调先打好地基的规则, 也就是运用提示词去约束Agent的工作节奏。不要一开始就去改动局部那种样式, 要先把具备可复用特点、有着可维护特性、存有可扩展属性的基础建设好。集中注意力于开发者架构决策时所产生的那种疲劳, 要是我们进行前端开发, 那必然都会历经挑选框架, 对css样式加以维护, 遵循命名的规范, 在开发之前, 这些我们都得事先确定好, 被设计成替开发者去做这些决策, 从而使得开发者拿到手后就能够即刻去编写业务代码。提示词将工作流程划分成四步了, 先是对项目需求予以分析, 接着去创建技术基础, 然后进行UX结构的规划, 最后就有开发者交接文档。此之中存在一项关键说明, 即需Agent去读取项目文件, 不可仅依用户所言, 要运用bash命令去读取项目配置, 凭借grep程序搜索关键词, 于项目里提取真实语料。的工作方式可以概括成一句话先理解项目现场再建立设计基础最后交付可执行的实现方案。交付标准让专家知道什么叫做好了除了身份和流程 提示词里还有大量关于交付物的定义。提示词之中, 还涵盖着完整的Theme组件, 其中有HTML模板, 有CSS样式, 还有类。直接把专业交付物模板写进了专家提示词。就是说, 它并非是让模型在现场进行随机发挥, 而是预先, 把专家所需要去完成交付的具体内容, 和交付所应当达到的精确程度, 以及以何种特定格式去交付这般的情况, 全部确切地写明白了。还定义成功标准放在这儿的标准, 是皆可去验证的, 当用户把交到手中的产物拿到手后, 能够依照着进行对照检查。不需要在做架构决策css是不是可维护项目是不是有了一致的外观技术基础是不是支持未来的扩展提示词里定义了的沟通风格给出了四个示例表述这个简单来说就是定义它的专业行为模式。它发出要求, 在进行沟通这个行为的时候, 要维持四个原创, 分别是系统化, 还有基础优先, 以及实施引导, 此外还有预防问题。如果我们去掉这层约束Agent 可能只会说我帮你的首页加了一些样式。但有了这层沟通风格之后它可能会更像架构师颜色变量的整个体系, 是我先去建立而成的。形成体系之后, 我又将其应用到按钮组件之上。如此这般, 要是随后需要加以调整主题色, 仅仅只需要对变量进行修改就行, 并不需要对每个组件逐一进行修改。Agent提示词之后, 存在着一大部分内容, 那是Agent的通用能力说明, 它涵盖了记忆系统, 还有安全规则, 以及工作模式, 另外包括任务管理, 也涉及工具使用规则等方面, 这些内容我们在此之前已经介绍过了, 所以在这里就不再进行繁琐的赘述了。长文档手稿专家: 另一种专家形态。我们再次去查看查看另外一位专家给出的提示词, 它并非进行技术交付, 而是从事内容创作, 我经过研究, 发现它跟上面所提到的提示词, 在结构方面高度一致。先看下身份定义由你担任长文档手稿专家一职, 针对提纲、访谈资料, 还有旧稿、研究材料以及零散的笔记, 进行系统的整合, 最终形成能够实现连绵不断推进态势的长文档手稿。其目的并非仅仅给予灵感, 而是要将用户所提供的材料, 使之变革成为具备切实可行性质的章节架构雏形打造出能够实现交付目标的正文样稿范例, 构建起可以重复运用的修改方案体系, 以及构想出持续不断去牵引推动的下一个步骤发展方向。接下来, 还有关于核心能力的内容, 还有关于高绩效工作假设的内容, 还有关于场景模板匹配等的内容, 这些内容, 都是与专家领域内的知识有相关性的, 我就不将它们一一列举出来了。关键在于, 我经由这两位专家以及那些提示词, 获取到了一套具备通用性的专家提示词撰写方式, 我认为这才是值得我们去学习的。另外 提示词里面还有一大推emoji图标这个专家的提示词 是不是也被AI润色了。专家的通用结构从两位专家给出的提示词当中, 我们能够提炼出一种通用结构, 它涵盖多个维度, 并非每个Agent注定都要将所有纬度假以填充, 反正至少在设计Agent提示词之际, 我们能够参照这些维度。这个跟我们平常的Agent提示词存在较大差异, 它的核心在于, 它对一个专家的工作模式进行了总结, 而后将其引入到提示词里, 尤其是工作流程、执行步骤, 还有明确的交付物, 从而让专家的Agent有了更优的行为依据。的专家本质上上是一套固定化下来的专业行为模式这种模式有点像普通的Agent, 加上领域方法论, 加上交付的模版, 加上工作流的约束, 也能够被理解成就是, 普通的Agent加上领域知识。对于我们这些普通的用户来讲, 这个由专家所设计的是挺好的, 我们在熟悉的领域之中知识是有限的, 当我们有需要去完成自身并不熟悉的领域相关任务之际, 运用这种已经封装好的专家Agent, 那可就相当省事了。专家团专家所处理的是单个领域之内的问题, 然而我们的任务常常并非如此简单, 经常需要跨越不同领域进行协作才能够完成, 专家团所从事的正是这样的工作, 将多个专家组织起来并协调他们一同开展工作, 这也就是我们所说的多Agent协作。我们来看一个具体的例子中有一个专家团内容创作专家团同样我们看下提示词是如何设计的主理人设计这是由专家团主理人给出的提示词, 它不亲自动手去操作执行, 仅仅负责进行调度安排, 包括拆解需求, 配置成员, 查看进度以及收取产出。而专家团所从事的工作任务就在于将多个专家召集组织起来, 从而实现协同工作。你身为 AI 内容创作专家团里的创意制片人司远Soren承担着协调团队去开展 AI 驱动的多模态内容生产任务的职责, 你具备把用户的创作需求拆解成为具体的技术执行方案的能力, 并且能成功调度适宜恰当的团队成员高效地完成交付。团队工作区专家团于工作之际, 得在相应目录之下构建一个团队的工作区, 系统会提供创建工具, 此为创建工具由主理人来创建, 如此这般整个团队便拥有了名称以及工作目录, 进而所有产出物得以统一管理。专家团再完成任务后会删除这个工作区。原始提示词如下:团队架构 提示词里面定义团队成员和职责对每一个成员而言, 均有着清晰明白的Agent ID, 系统借助该Agent ID予以调度, 并非凭借中文名字。且中文名字乃是供用户去看的, Agent ID则是供系统来使用的。任务分配预检整个系统存在关键设计之一, 那就是专家团具备任务分配预检的机制, 主理人在进行派发任务这个行为之前, 一定要先去做能力匹配哦。提示词当中, 存在着一个清晰的速查表, 它把常见的误排场景, 罗列出来给 Agent。存在一种预检机制, 它能够起到防止某些看似能够完成的误派情况发生的作用, 在多Agent系统里, Agent不会主动表明自己不会做, 它并非自己所能做的范畴, 它们总会竭尽全力去完成任务然而结果却无法予以保证了。预检的流程是1. 要解析用户意图, 那用户究竟是想要什么? 是生成, 还是编辑, 又或者是分析, 亦或是转录, 甚至是翻译?2. 对照速查表该意图是否在团队能力范围内3. 能力若匹配, 便正常进行派发能力若不匹配, 那就直接向用户告知当下的限制以及替代的建议, 对此禁止进行派发。4. 模糊意图就先向用户确认具体需求再决定是否派发预设预设的这个专家团有8个, 覆盖那种最常见的协作场景, 每个都对触发条件、执行阶段、关键决策点、产物交付规范作出了定义。关于详细的提示词, 我们就不去讲了, 它们全都是内容创作当中常见的一些流程编排, 在这里, 这也和skill有着同样精妙趣味相同的意味。团队协作这里明确规定了团队协作的范式1. 开端之际, 主理人要亲自去着手创建团队, 清晰地界定出协作的边界, 以及整理好相关的上下文, 且团队创建这项事宜, 必须是主理人来执行, 只能由主理人来执行没有旁人可以替代。2. 将调度成员, 按照SOP阶段, 把每一位成员拉进协作里, 再下发独立的任务。成员作为独立的协作方, 依据任务说明, 输出专业的产出。3. 信息传递环节: 成员所产出的内容要传回去给主理人, 被主理人进行汇总, 而后转交到下一阶段的成员手上。全部跨越成员之间的信息流动都得经由主理人来进行中转。4. 以成员结论作为标准: 任何专业方面的产出, 都必须是由相应的成员进行输出之后, 才能够予以采信, 而主理人仅仅是从事编排以及汇编的工作。这四条规条的关键所在是, 主理者仅仅负责进行调度, 并不负责去执行, 主理者不会代劳撰写任何一位成员的专业性产出, 成员相互之间不会直接进行通信, 所有的信息流动都要经由主理者来进行中转。这里为何要这般设计呢, 这里实际上是一种在常见多 Agent 里的编排者模式, 并且 Agent 也都运用的是此类模式。关键之处在于, 如果 Agent 成员们彼此能够实现互相调用以及通信, 不只是程序会变得复杂许多, 多个 Agent 反复进行通信, 会引发大量上下文污染, 并且一旦出现错误就很难去追溯。消息借助主理人编排者实现中转, 主理人具备全局视角, 由主理人对任务予以统一管理并进行工作派发, 出现问题时, 主理人能够知晓应当让谁加以解决, 所有通信均存有记录, 所有决策均有责任担当者。异常处理和交付检查清单专家团还设计了完善的异常处理机制要是有任何一位成员在达到哪怕一分钟多九分钟之长的这个时间段后, 依旧没有回传成果, 那么那主理人应当基于主动态度前往向用户通报等待的状况情况, 如果是同一个任务总计总计失败的次数超过了两次这一数目时, 就要终止掉该任务线并且朝着用户讲清楚其中的缘由原因。还有一个强制性的交付检查清单– 是否已调用交付工具– 所有图片文件是否已包含在交付中– 是否有产出物散落在不同目录未被收集从专家团里能学到什么我们所提及的专家团便是为一种多Agent协作的情况, 我们来瞧一瞧较为常见的多Agent协作究竟有着哪一些范式, 之前曾经存在过专门对多Agent予以介绍的文章, 大家能够返回去予以查看。就像上面所呈现的图示那样, 综合归纳起来总共也就是这几种情形, 而这里面所运用的恰恰便是那种调度 - 执行模式。具有调度与执行情形这般模样的, 正是最为基础的多 Agent 结构。而其中的所谓以处理用户目的以及全局判断权力为职责的, 乃是主 Agent。但子 Agent 则明显相异, 却仅仅处理被分配的局部任务而已。主 Agent 分析用户请求判断任务是否需要拆分。有一个主 Agent, 它会为每一个子任务, 去生成清晰明确的目标, 再生成相应的上下文, 最后还会生成输出要求。子 Agent 在独立上下文中执行任务。主要的 Agent 去搜集子 Agent 所产生的结果, 进而开展冲突处理相关动作, 再进行信息合并方面的操作, 最终给出回复。有所不同的是, 它事先预制了工作流进去, 它并未让模型依据自身的知识, 自行随意发挥, 而是在提示词之中规定了几种常见的执行中的工作流, 这等同于将其内置到提示词里了, 并非是按需加载的那种情况了, 如此一来, 实际上会造成一些token的浪费。然而在这个特定场景下, 用户原本就是选择专家团来达成任务, 似乎也并无不妥之处。最后能够被称作专家的, 其实就是那种被自定义出来的Agent, 它会把角色定义、工作流程、交付模板、能力支撑、降级方案以及持续牵引这些方面, 全部封装在一块儿。而所谓的专家团呢, 则变成了多Agent协作的形式, 借助调度层、任务预检、预设、精确层与生成层相互分离、通信管控这些机制, 从而将多个Agent组织起来, 达成一种高效协同的状态。
