1. 为什么需要从零搭建一个WorkBuddy专家很多人第一次接触WorkBuddy的时候都会有一个误解以为它就是一个更聪明的聊天窗口你问它答仅此而已。但真正用起来之后你会发现WorkBuddy的核心价值根本不在于对话而在于它可以被配置成一个有角色、有技能、有权限边界、有记忆的专家实体。这四个维度缺一个它都只是个玩具四个都配齐了它才是一个能真正替你干活的数字同事。我自己最开始也是把它当普通助手用问什么答什么用了一段时间觉得也就那样。直到有一次我需要它持续跟进一个跨越多天的任务结果每次新开对话它都像失忆一样之前交代的背景、偏好、约束条件全部归零我才意识到问题的根源我从来没有认真配置过它的角色、Skill、权限和记忆。这四个东西不是可选项而是让WorkBuddy从通用问答机变成专属专家的必经之路。这篇文章要解决的问题很具体如何从零开始把一个空白的WorkBuddy配置成一个真正能用的专家。我会把角色定义、Skill挂载、权限设置、记忆体系这四块拆开讲透每一块都会说清楚为什么这么配配的时候容易踩什么坑配完之后怎么验证。适合两类人看一类是刚上手WorkBuddy、还没搞明白这些配置项到底干嘛的新手另一类是已经用过一段时间、但总觉得它不够懂我的老用户。需要先说明一点WorkBuddy这类工具的配置逻辑本质上和搭一个Agent系统是相通的——角色是System Prompt层的设定Skill是能力扩展层权限是安全边界层记忆是上下文持久化层。理解了这四层的分工你配置任何类似的Agent工具都会举一反三。下面我按先想清楚再动手的顺序一层一层往下拆。2. 角色定义把万能助手收敛成领域专家2.1 角色不是写一句人设就完事大部分人配置角色的时候习惯写一句你是一个专业的XX助手然后就结束了。这种配置几乎等于没配。因为专业这个词对模型来说没有任何约束力它不知道该专业到什么程度、该用什么口吻、遇到不确定的问题该怎么处理。一个真正有效的角色定义至少要覆盖四个维度身份定位、能力边界、行为风格、输出规范。身份定位回答你是谁能力边界回答你擅长什么、不擅长什么行为风格回答你怎么说话输出规范回答你交付的东西长什么样。这四个维度写清楚了模型的行为才会稳定。举个具体的例子。假设你要做一个代码审查专家不要写你是一个代码审查专家而要写成类似这样的结构身份你是一名有十年经验的资深后端工程师专精Java和Go的服务端代码审查能力边界你擅长发现并发安全、资源泄漏、边界条件、异常处理类问题对于前端样式和UI交互问题你只做提示不做深入分析行为风格直接指出问题不绕弯子每个问题必须给出具体的代码行和修改建议输出规范按严重程度分级输出每条包含问题描述、风险说明、修改示例三段这样写出来的角色模型在执行时才有明确的轨道可循。2.2 角色收敛带来的实际收益我做过一个对比测试。同一个代码审查任务用你是一个代码审查专家和用上面那种四维角色定义输出的质量差距非常明显。前者给出的意见泛泛而谈经常说建议优化异常处理这种正确的废话后者能精确到第47行的catch块吞掉了InterruptedException应该恢复中断状态或向上抛出。原因其实不复杂角色定义越具体模型在生成时的概率分布就越收窄它不会浪费算力去考虑那些你不关心的方向。这就像你找同事帮忙你说帮我看看代码他可能随便扫两眼你说帮我重点看并发和资源管理这块其他不用管他就会聚焦。提示角色定义里不擅长什么这一条经常被忽略但它其实很重要。明确告诉模型哪些事不归它管能有效减少它在无关方向上的过度发挥。2.3 角色定义里最容易踩的三个坑第一个坑是角色和Skill职责重叠。有些人在角色里写你要会调用XX工具完成YY任务但这件事其实应该交给Skill去做。角色管的是你是谁、你怎么想Skill管的是你能做什么动作两者混在一起会让配置变得难以维护。第二个坑是角色定义过长导致核心指令被稀释。我见过有人把角色写成两千字的小作文结果模型执行时反而抓不住重点。角色定义控制在300到600字比较合适把最关键的约束放在前面。第三个坑是没有给角色设定不确定时的行为。专家不是全知的遇到超出能力范围的问题应该明确说这个我不确定或者这超出我的专长范围而不是硬编一个答案。在角色定义里加一句遇到不确定的信息明确标注不确定不要编造能显著降低幻觉率。3. Skill配置让专家真正会干活的关键3.1 Skill到底是什么和角色有什么区别如果说角色定义的是这个专家是谁那Skill定义的就是这个专家会哪些具体动作。角色是静态的人设Skill是动态的能力。一个配置好的WorkBuddy专家应该是角色若干Skill的组合体。打个比方角色像是招聘时写的岗位JDSkill像是这个岗位需要的具体技能证书。你招一个数据分析师角色他还得会SQL、会做可视化、会写分析报告Skill这些技能不是与生俱来的是要一个个挂上去的。WorkBuddy的Skill机制本质上是把一些可复用的能力封装成模块需要的时候挂载到专家身上。这样做的好处是同一个Skill可以被多个专家复用你不用每次都重新写一遍。比如一个文件读写Skill代码审查专家要用文档整理专家也要用写一次就够了。3.2 从零创建一个Skill的完整思路创建Skill的时候我建议按这个顺序思考这个Skill解决什么具体问题不要做万能工具式的Skill一个Skill只干一件事。比如读取指定路径的文本文件并返回内容就是一个合格的Skill处理各种文件就是不合格的。输入是什么、输出是什么把输入参数和输出格式定义清楚。输入是文件路径还是文件内容输出是纯文本还是结构化数据边界条件怎么处理文件不存在怎么办内容超长怎么办编码不对怎么办这些都要在Skill里定义好。失败时怎么反馈Skill执行失败时要返回明确的错误信息而不是静默失败。我见过太多人创建Skill时只想着正常流程结果一遇到异常情况就抓瞎。一个Skill的健壮性恰恰体现在它对异常的处理上。3.3 Skill组合的实战案例假设你要做一个周报生成专家它需要这几个Skill配合Skill名称职责输入输出日志读取读取本周工作日志文件文件路径结构化日志条目内容归类把日志按项目分类日志条目列表分类后的内容摘要生成为每类内容生成摘要分类内容摘要文本格式化输出按模板排版摘要文本最终周报这四个Skill串起来就形成了一个完整的工作流。注意每个Skill都只做一件事组合起来才完成整个任务。这种设计的好处是任何一个环节出问题你都能快速定位是哪个Skill的锅而不是面对一个黑盒干瞪眼。注意Skill之间传递数据时格式一定要统一。我踩过的坑是前一个Skill输出的是JSON后一个Skill期望的是纯文本结果整个链路跑不通。建议在创建Skill时就约定好数据格式最好统一用结构化格式传递。3.4 Skill调试的实用技巧Skill写完不是就完事了一定要单独测试。我的做法是每个Skill都准备一组测试用例包括正常输入、边界输入、异常输入三类。正常输入验证功能对不对边界输入验证鲁棒性异常输入验证错误处理。调试Skill时最有用的一招是打印中间结果。很多Skill链路跑不通不是逻辑错了而是中间某一步的数据格式和你以为的不一样。把每一步的输入输出都打出来看一眼问题往往一目了然。另外Skill的命名要见名知意。别用skill1skill2这种名字用read_weekly_logclassify_by_project这种一看就懂的名字。等你Skill多了之后好名字能省下大量回忆时间。4. 权限设置给专家划清能碰和不能碰的边界4.1 为什么权限配置不能省很多人配置WorkBuddy时权限这一块直接跳过觉得反正是我自己用给全部权限就行了。这个想法在简单场景下没问题但只要涉及文件操作、外部调用、敏感数据全权限就是灾难的开始。权限的本质是最小必要原则一个专家只应该拥有完成它职责所必需的最小权限集合。周报生成专家只需要读日志文件的权限不需要写系统文件的权限代码审查专家只需要读代码的权限不需要执行代码的权限。多给的每一个权限都是一个潜在的风险点。我自己的教训是早期给一个文件整理专家开了全盘读写权限结果它有一次理解错了指令把一批不该动的文件给重命名了。虽然最后恢复了但那次之后我就彻底改了权限配置策略——能只读就不给写能给单目录就不给全盘。4.2 权限的常见类型和配置思路WorkBuddy这类工具的权限通常可以分成几类文件系统权限读、写、删除、执行以及作用范围单文件、单目录、全盘网络访问权限能否发起外部请求能访问哪些域名工具调用权限能调用哪些Skill能调用哪些外部工具数据访问权限能访问哪些数据源能读哪些字段配置时的思路是先默认全关再按需逐个打开。不要反过来先全开再关掉不需要的因为后者很容易漏掉。每打开一个权限都问自己一句这个权限是完成当前任务必须的吗答不上来就别开。4.3 权限配置的验证方法权限配完之后一定要验证。验证分两步正向验证和反向验证。正向验证是确认该能做的能做给专家一个需要用到授权权限的任务看它能不能正常完成。反向验证是确认不该能做的做不了故意让它尝试一个超出权限的操作看它是不是被正确拦截了。反向验证经常被忽略但它其实更重要。因为正向验证失败你会立刻发现反向验证失败你可能很久都察觉不到直到出事。我现在的习惯是每配置一个新专家都跑一遍反向测试确认权限边界是真实生效的。4.4 权限和角色的配合权限配置要和角色定义配合起来看。角色里说你只负责代码审查不修改代码那权限上就不该给写权限。如果角色说不修改代码但权限给了写权限就存在模型可能越界的风险。角色是应该做什么的软约束权限是能做什么的硬约束。软约束靠模型自觉硬约束靠系统强制。两者一致的时候最安全两者冲突的时候以硬约束为准但也要回头检查角色定义是不是写得不清楚。5. 记忆体系让专家不再每次都是第一次见你5.1 记忆为什么是专家配置的分水岭前面说的角色、Skill、权限配好之后专家已经能干活了。但你会发现一个致命问题它不记得你。每次新对话它都像第一次见你一样你之前交代的偏好、背景、约束全部归零。这就是记忆要解决的问题。记忆体系是区分能用和好用的分水岭。一个没有记忆的专家你每次都得重新交代一遍背景一个有记忆的专家用久了会越来越懂你你甚至不用说完它就知道你要什么。从技术角度看Agent的记忆通常分三层短期记忆、长期记忆、永久记忆。短期记忆是当前对话的上下文长期记忆是跨对话保留的信息永久记忆是那些几乎不会变的核心设定。三层记忆的读写策略不一样配置方式也不一样。5.2 短期记忆当前对话的上下文管理短期记忆就是当前这次对话里模型能看到的所有内容。它的核心问题是上下文窗口有限。对话一长早期内容就会被挤出去导致模型忘了前面说过什么。管理短期记忆的关键是信息压缩。不要把每一句闲聊都塞进上下文而是定期把重要信息提炼成摘要。比如对话进行了20轮你可以让专家把前20轮的关键结论总结成一段话后续对话基于这段摘要继续而不是带着全部原始对话。我自己的做法是在角色定义里加一条每完成一个阶段性任务主动总结当前进展和待办事项。这样即使上下文被截断重要的进展信息也已经以摘要形式保留下来了。5.3 长期记忆跨对话的信息持久化长期记忆解决的是下次对话还能记得的问题。它的实现方式通常是把关键信息存到外部存储下次对话时按需读取。长期记忆配置的核心是决定记什么和怎么取。记什么不是所有信息都值得记要记那些跨对话仍然有效的信息比如用户偏好、项目背景、常用配置。怎么取不是每次都把所有记忆全读进来而是根据当前对话主题检索相关的记忆片段。这里有个容易踩的坑记忆存太多反而会干扰。如果长期记忆里塞了几百条信息每次对话都全量加载不仅浪费上下文还会让模型抓不住重点。正确的做法是给记忆打标签按需检索。5.4 永久记忆那些不该变的核心设定永久记忆是三层里最稳定的一层通常就是那些设定好就不该变的内容比如专家的核心角色、基本行为准则、安全红线。这部分内容一般直接写在角色定义里不参与动态读写。永久记忆和长期记忆的区别在于永久记忆是宪法长期记忆是法律短期记忆是日常决定。宪法不轻易改法律可以修订日常决定随时变。配置的时候要分清哪些信息属于哪一层别把该进永久记忆的东西放到长期记忆里反复读写。5.5 记忆配置的验证和调优记忆配好之后验证方法是开一个新对话看专家能不能正确调用之前的记忆。如果它记得你之前说过的偏好说明长期记忆生效了如果它每次都要你重新交代说明记忆没配上或者检索没生效。调优的方向有两个提高召回准确率和降低噪声。召回准确率是指该记起来的时候能记起来噪声是指不该记起来的时候别乱记。这两个方向经常是矛盾的需要根据实际使用情况平衡。我的经验是宁可少记一点也不要记一堆没用的因为噪声对体验的伤害比偶尔忘事更大。6. 四层配置的联动与整体验证6.1 四层不是独立的是互相咬合的角色、Skill、权限、记忆这四层单独看每一层都不难难的是让它们协同工作。举几个联动的例子角色说你是代码审查专家Skill里就得有读取代码文件的能力权限里就得有读代码目录的授权记忆里就得记住用户常用的代码规范。角色说你不修改代码权限里就不该有写权限Skill里就不该有写文件的动作记忆里也不该记录用户让我改代码这类信息。Skill执行需要的数据可能来自记忆记忆里存的信息可能来自Skill的执行结果。两者是双向的。配置的时候建议先定角色再配Skill然后设权限最后接记忆。这个顺序是因为后一层依赖前一层不知道角色就不知道要什么Skill不知道Skill就不知道要什么权限不知道要处理什么信息就不知道记忆该记什么。6.2 整体验证的检查清单四层都配完之后跑一遍完整的验证。我通常用这个清单检查项验证方法通过标准角色一致性问它你是谁、擅长什么回答与角色定义一致Skill可用性给一个需要Skill的任务能正确调用并完成权限边界尝试越权操作被正确拦截短期记忆多轮对话后问前面内容能正确回忆长期记忆新开对话问之前信息能正确调用四层联动给一个综合任务全流程顺畅这个清单跑一遍基本能覆盖大部分配置问题。6.3 配置迭代没有一次配好的专家最后要说的是专家配置不是一次性的工作而是持续迭代的过程。你第一次配出来的专家大概率不会完美。用一段时间之后你会发现某些地方需要调整角色定义要补充、Skill要优化、权限要收紧、记忆策略要改。我的习惯是建一个配置日志每次调整都记一笔改了什么、为什么改、改完效果如何。这样积累下来你对什么样的配置对应什么样的行为会越来越有感觉下次配新专家的时候就能少走很多弯路。配置WorkBuddy专家这件事说到底是一个把模糊需求翻译成精确配置的过程。你对自己想要什么越清楚配置出来的专家就越好用。反过来配置的过程也会逼着你把需求想清楚——这可能是配置专家之外另一个意想不到的收获。