★ FEATURED ARTICLE 1. 为什么要在协作平台里塞一个“写作助手”智能体1.1 团队写作的真实痛点先说个我自己观察到的现象。很多团队在协作软件里聊得热火朝天但一落到“写东西”这件事上就开始别扭周报要么拖到周日晚上才凑会议纪要靠人会后追着问“当时那条结论是什么来着”方案文档改了七八版互相都分不清哪份是最新的。我做过一阵子团队效率工具方面的落地跑下来发现真正耗时间的不是“写”这个动作而是“从零开始组织语言”。同样一份新产品发布文案每个人写出来的风格、结构、用词都不一样改来改去的沟通成本比写本身还高。这时候就很自然地想到如果能在大家每天都在用的协作平台里放一个随时能喊的写作助手让它按统一的风格把初稿给出来再由人来改效率能提升一大截。我用的方案是把一个叫 OpenClaw 的智能体运行时接到协作平台机器人上做一个写作助手。这篇文章就把整个配置过程拆开讲包括我踩过的坑和调参心得。1.2 智能体不是普通聊天机器人在动手之前得先把概念理清楚。普通的聊天机器人核心是“你问一句它答一句”回答质量完全靠单次 Prompt没有记忆、不会主动调用工具、也没办法感知上下文。而 OpenClaw 这类智能体运行时它的典型特征有三个有状态能记住这次会话里用户说过什么、自己写过什么甚至能跨会话保存用户偏好能调工具不只是输出文字还能调用文档读取、知识库检索、模板渲染这些外部能力能编排一个任务可以被拆成多步比如先检索资料、再列大纲、再逐段写最后按格式输出。写作助手这件事恰好适合用智能体来做。因为写作天然是“多步骤”的收集需求、明确场景、组织结构、逐段输出、按格式转换每一步都需要一定程度的判断。如果只用一个简单的“提示词机器人”效果通常会让你失望。比如让它“写一份周报”它会很泛地写一段“本周我完成了……”但不会去查你之前提交过的周报风格也不会主动拆出“本周重点、数据进展、风险与下步计划”这种结构。而 OpenClaw 可以通过技能Skill定义一套行为模板再配合知识库里的历史样例让生成结果贴着你团队的写法走。1.3 我们最终选择了怎样的架构先明确一个原则不要自己造一个聊天机器人平台。协作平台侧的机器人能力、事件订阅、消息下发都是现成的我们要做的只是把“协作平台的机器人”和“OpenClaw 智能体后端”粘起来。整体架构大致是这样用户在协作平台的会话里 机器人协作平台把这个消息事件通过后台推送到 OpenClaw 服务OpenClaw 解析指令前缀比如“#周报”、带上会话上下文、调用配置好的大模型、检索知识库、生成结果再通过协作平台的机器人接口把内容发回会话。这套架构里有三个关键点协作平台只负责消息收发真正干活的在 OpenClaw技能Skill决定智能体的行为边界而不是靠一个巨大的系统提示词硬撑知识库是团队风格的记忆体让模型“投喂”给你团队的写法而不是每次白手起家。在动手配置之前还有一件事要想清楚写作助手到底服务谁如果是给个人用配置可以很轻如果是给整个团队用就得在权限、指令设计、知识库内容上多花功夫。我下面讲的是以团队使用为目标的完整配置。2. 配置前的准备协作平台应用与 OpenClaw 基础环境2.1 协作平台侧的机器人应用我接下来用“协作平台”统一代指团队在用的办公协同软件如果你用的是飞书、钉钉、企微这类产品思路是一致的入口菜单位置可能稍有差异但核心概念都是一套机器人应用、凭证、事件订阅、权限范围。在协作平台开放后台新建一个“自建应用”拿到两个最重要的凭证App ID应用唯一标识App Secret调用接口时签名用的密钥务必保管好别提交到 Git。在应用里找到“机器人”能力开启它。开启后这个应用就具备了在群聊里收发消息的身份。然后要配置“事件订阅”。这一步是关键因为智能体能不能实时响应完全依赖协作平台能不能把消息事件及时推给你自己的服务。事件订阅里需要填一个回调地址指向你的 OpenClaw 服务对外暴露的 HTTP 端点同时选择一个加密策略通常是配置 Encrypt Key 和 Verification Token这两个值后面配置 OpenClaw 时要原样填进去。权限方面至少需要申请这几类读取消息内容让后端能看到用户发的是什么发送消息让智能体能回复到群里上传文件/图片如果要支持“把生成的文档发出来”这个能力需要这个权限读取文档如果需要智能体引用云文档里的模板需要配置对应的文档只读权限。注意协作平台后台的权限改完后通常要等几分钟生效。我有一回配置完立刻测试提示无权限折腾了半天发现是权限还没同步完。2.2 OpenClaw 运行环境与模型接入OpenClaw 是一个可自托管的智能体运行时简单理解它就是一个“大脑壳”负责接收事件、管理会话、调度模型和工具。运行时本身不产生内容内容由接入的大模型生成。部署时我建议直接用 Docker 方式跑省去本机 Python 环境的依赖问题。如果喜欢用源码跑至少保证 Python 3.11 以上并装好 requirements 里列出的依赖。模型接入这一步需要准备一个可用的模型 API。现在的通用大模型能力都很强写作场景建议选择上下文窗口大一点的版本至少 32K 以上因为写作任务经常需要来回修改上下文一长模型窗口小的话就很容易截断。在 OpenClaw 配置文件里核心是配置三样东西API Key模型服务的密钥Base URL模型服务的地址模型名你要调用的具体模型版本。我建议先不要用小众模型优先选通用能力强、指令跟随好的主流模型等整个链路跑通了再逐个模型对比写作质量。2.3 先把最简单的链路打通很多人一上来就配知识库、配技能结果复杂到根本分不清问题出在哪。我的习惯是先做一个“最小链路”。所谓最小链路就是只做三件事机器人收到消息 → OpenClaw 调用模型生成一句回复 → 机器人把回复发回群。测试方式很简单在协作平台里创建一个只有你和机器人的群发送“你好”看是否有自动回复。这一步如果通了后面的技能、知识库、模板都是在同一个链路上叠加能力这一步不通先别往下走否则排查问题时你会被“模型没返回”和“技能没触发”双重问题折磨。我第一次部署时就卡在这一步长达两个小时。后来发现是事件订阅回调地址填错了我用的是 HTTP但 OpenClaw 配置里要求的路径前缀没对导致协作平台验证回调一直失败。所以最小链路的价值就在于把变量控制到最少逐层排除。3. 核心配置实操从机器人到写作技能3.1 在协作平台侧把消息事件推给 OpenClaw现在进入正式配置环节。假设你已经完成了最小链路下面要做的是把“被动回复”变成“按指令执行”。协作平台的事件订阅配置里通常会让你选择“监听哪些事件”。我配置写作助手时选择的是消息事件大类里的“接收消息”子事件同时勾选了“接收消息中的 提及”选项。这样只有用户在群里 机器人事件才会触发避免机器人抓取所有群消息导致噪音和费用浪费。OpenClaw 侧要做的是配置好回调地址对应的路由。以我部署的服务为例OpenClaw 暴露的 HTTP 服务默认监听0.0.0.0:8000回调路径一般是/openclaw/webhook。这里的路径可以根据自己需要调整但必须和协作平台事件订阅里填写的地址完全一致。关于地址还有一个容易坑的点协作平台的服务器在发起回调验证时如果填的是http而你的服务做了 HTTPS 强制跳转验证会失败。所以要么保证服务本身开启 TLS要么在网关层把回调路径单独放开不做跳转。在回调验证阶段协作平台会发送一个带有加密参数的验证请求OpenClaw 会拿着你配置好的 Encrypt Key 和 Verification Token 去解。这一步能过说明协议层已经没问题了。3.2 定义写作助手的“人设”很多人不太重视系统提示词System Prompt觉得“反正模型能力强随便说说就行”。但实际上写作助手和通用聊天机器人最大的差别就在于“人设稳定”。我推荐的思路是这样的把“写作助手”的系统提示词拆成四个块——身份、职责、风格、约束。身份这块我写的是你是团队的写作助手名字叫“笔杆子”。你的职责是帮助团队成员完成日常写作任务包括周报、会议纪要、方案文档、公告通知、文案润色等。风格这块针对团队最常见的场景写清楚你输出的语言要简洁、准确、有逻辑。避免空话套话。使用中文简体。句子长度适中段落之间有清晰的逻辑递进。涉及数据和事实时必须基于上下文内容不要编造。约束这块非常重要当用户的要求不明确时先反问澄清不要直接生成。当用户要求超出写作范围如代码调试、复杂计算、闲聊时礼貌说明你只负责写作相关任务。人设定义好之后你会发现生成内容的质量稳定了一个档。因为模型在“身份明确、边界清晰”的提示下输出更收敛不像通用聊天那样一会儿正经一会儿口语化。3.3 技能设计一套指令前缀就是一个能力如果说人设决定了“你是什么样的人”技能决定了“你能干什么活”。OpenClaw 的技能机制可以理解为一套“指令前缀 处理流程”的映射。在设计写作助手的技能时我一开始犯过一个错误试图把十几个能力塞进一个巨大的指令描述里。结果就是模型经常搞混用户说“写周报”它却在输出会议纪要的开头。后来我改成“小技能、清晰前缀”的方式。每个能力独立配置一个技能每个技能绑定一个明确的指令前缀比如指令前缀技能名称能力说明#周报周报生成根据用户提供的本周工作要点生成结构化周报#纪要会议纪要根据对话记录或用户粘贴的要点整理为完整会议纪要#文案营销文案根据产品信息和目标人群输出多种风格的短文案#润色文本润色在保持原意的前提下优化语句流畅度和表达逻辑#公告通知公告生成正式、简洁的团队通知或公告技能内部需要定义一个“执行流程”。以“#周报”为例我会让 OpenClaw 执行四步确认用户提供的周报素材是否充分缺内容先追问从知识库中检索该用户历史周报的风格按“本周进展、数据亮点、风险与问题、下周计划”四段生成输出前自动检查是否包含空泛套话如有则替换。这里要注意技能里的每步不要写得过于死板。比如“从知识库检索历史周报”这一步如果知识库没有该用户的记录就应当降级为“按团队通用风格生成”而不是报错停止。我在实际配置里会给每个技能都写一个“兜底策略”。3.4 加入知识库让它更懂你的团队写作助手最大的价值不在于“会写”而在于“写得像你们团队写的”。所以知识库很关键。我是这样构建的在 OpenClaw 里挂一个名为“团队写作资产”的知识库数据来源包括三个部分。第一部分是团队的历史文档。把过去的周报、月报、会议纪要、对外方案脱敏后汇总起来。这些文档是模型学习团队表达风格的原始素材。第二部分是品牌与规范类材料。比如产品命名规范、术语表、宣传口径、禁用语清单。有了这些材料生成的对外文案才不会出现“口径不准”的问题。第三部分是模板库。比如周报模板、会议纪要模板、活动方案模板。这些模板经过人工整理结构清晰模型在生成时会优先参考模板结构。在配置知识库时有一个参数你一定会遇到那就是“检索条数 TopK”。它表示每次生成前从知识库里捞多少条相关片段喂给模型。我实测下来的建议是写作场景 TopK 设置在 3 到 5 之间不要贪多。因为写作任务的上下文本身有限检索出的片段太多反而会稀释模型的注意力让它一会儿学这个风格一会儿学那个风格。另外文档切块大小也不要忽视。如果一次切块太大比如 2000 字一块检索出来的片段可能包含太多无关信息如果切块太小比如 200 字一块上下文被割裂模型学不到完整结构。我实验下来500 到 800 字的切块对写作素材来说比较舒服。提示知识库里的历史文档一定要做脱敏。我见过有人直接把包含客户名字、报价信息的方案文档丢进知识库结果生成的对外文案里带着敏感数据这是很严重的失误。4. 关键参数调优与方法取舍4.1 模型选择与参数设置写作助手能不能写好模型选择占一半。我把主流模型在写作场景下都试了一遍跑完的感受是不要只看“综合榜单”上的分数要用你自己团队的文档去测试。我自己的测试方法是准备三份材料一份周报素材、一段客户现场沟通记录、一个产品卖点清单分别让不同模型生成然后对比“结构是否清晰、语言是否符合团队习惯、是否保留关键信息”。测试完通常会发现有些模型长文本能力很强但细节指令跟随弱有些模型小段输出很好但一写长方案就散。在 OpenClaw 里我尽量选择上下文长、指令跟随稳的那一类。参数设置上写作场景我建议这样起步参数建议区间场景说明temperature0.3 到 0.5事实类写作纪要、周报低一点更稳temperature0.7 到 0.9创意类写作文案、标题高一点有惊喜top_p0.8 到 0.9配合 temperature 使用降低采样偶然性max_tokens600 到 2000周报/纪要建议 1000 左右长方案再加大这里特别说说 temperature。很多人觉得“越高越有创意”其实对写作助手来说高 temperature 往往意味着“跑题”和“前后不一致”。周报这类事实型写作我常年设置在 0.4只有生成营销文案开头这种需要发散的任务才临时调高到 0.8。4.2 提示词模板的设计细节系统提示词是底的技能提示词是骨的而真正让模型输出“可用初稿”的是每个技能内部的提示词模板。以“#纪要”为例我的技能提示词长这样你正在把一段对话记录整理为会议纪要。对话记录已经提供。请按以下结构输出 一、会议主题 二、参会人根据上下文判断不确定则标注“待确认” 三、讨论要点按主题归类 四、结论与决定 五、待办事项必须包含负责人和截止时间如上下文未提及则标注“未明确” 六、风险与问题 要求只基于提供的对话记录整理不要补充任何记录中出现过的信息如有信息缺失直接标注“缺失”不要猜测。这个模板的要点是把希望模型遵守的结构一步一步列出来而不是笼统要求“整理成会议纪要”。模型对结构化指令的遵循度远高于模糊指令。同时要注意模板里的“不要补充……不要猜测”这些约束不是摆设。写作场景最大的风险就是模型“合理想象”把会议里根本没提过的内容补进纪要里。加一句“如上下文未提及则标注‘未明确’”看起来有点啰嗦但能省掉大量后期纠错时间。4.3 从 Prompt 到工具按需收敛能力在 OpenClaw 里很多写作场景其实用不到工具调用靠提示词就够。但有一种情况必须上工具当你需要“引用具体文档内容”时。比如用户说“根据《产品术语表》的规范写一份功能上新公告”这时模型如果没有工具去读取那份文档就只能凭训练记忆或知识库片段作答极容易出错。我的建议是在把知识库搭好之后不要一上来就让模型随意调用所有工具。而是先在技能里明确“什么情况下需要检索知识库”给模型一个触发条件。一个反例是这样的我在一个技能里同时开放了“知识库检索”和“文档读取”两个工具结果模型几乎每次都去检索即使任务很简单导致响应变慢、上下文被检索内容占满。后来我改成“只有用户明确提到参考某个文档时才触发文档读取只有技能模板里注明需要历史风格时才触发知识库检索”情况才明显改善。这里有个通用的取舍原则智能体不是越聪明越好而是越可控越好。写作助手尤其如此因为写作的评判标准不是“信息多”而是“符合需求”。5. 常见问题与排查实录5.1 事件回调验证失败这是配置环节最容易卡住的一步具体现象是协作平台后台提示“回调验证失败”。排查顺序我建议按这四点来确认回调地址从外网可访问。用本机 curl 测一下 URL 是否返回预期结构确认 Encrypt Key 和 Verification Token 一致。OpenClaw 配置里的值必须和协作平台后台完全一致多一个空格都不行确认回调地址不是 HTTP 强制跳转。有些对公网服务默认做了 HTTP 到 HTTPS 的重定向而协作平台回调验证时如果遇到 301/302会直接判定失败确认路径大小写完全一致。我见过把/OpenClaw/webhook和/openclaw/webhook搞混导致验证失败的。如果以上都检查过还不行看一眼 OpenClaw 的日志。回调验证失败时日志里通常会写明是“解密失败”还是“签名不匹配”这些信息能直接定位到问题。5.2 机器人收不到消息最小链路测试时发消息给机器人没有反应是一个高频问题。我第一个排查的是“事件订阅是否生效”。很多时候后台配置没保存、或者新事件类型没重新发布消息根本推不出来。第二个要查的是“是否只有 机器人才触发”。如果你配置的事件是“被 时触发”但测试时没 机器人那当然没反应。还有一种情况比较隐蔽机器人所在群是“新群”但是协作平台的事件订阅范围是按群类型走的。有些平台默认不推送“多人群”里的机器人消息而只推送单聊消息。这个我在文档里翻了好久才找到配置时注意看事件说明里的适用范围。最后一个可能是 OpenClaw 服务本身崩了。我建议第一步先看服务进程而不是去协作平台后台改配置。服务没起来后台怎么调都没用。5.3 生成的文本丢失格式/乱码写作助手输出的一大痛点就是格式。协作平台的消息发送接口通常支持富文本和 Markdown但不同平台的渲染规则不一样换行、列表、标题的语法兼容性有差异。我踩过的一个坑是OpenClaw 默认以 Markdown 格式输出发送到群里后列表符号混乱、加粗失效。后来我在技能输出环节加了一步“格式转换”把模型输出的纯 Markdown 转成协作平台消息接口认可的富文本结构。乱码问题则通常和字符编码有关。如果你的 OpenClaw 服务跑在容器里环境变量没设置 UTF-8中文就会出现乱码。排查方法很简单在日志里看看最终发送的消息体是不是正确的中文如果是那就是发送接口的问题如果日志里已经是乱码那就是容器编码问题在启动时加上语言环境变量即可。提示请在将机器人的输出发送到群之前增加一个“消息预览”。这个功能看起来不起眼但在团队正式使用前能帮你省掉非常多的“格式不对”投诉。5.4 知识库检索不准知识库建好之后你会发现“历史文档明明在那里但模型就是检索不到”。我分析下来原因无非几种一是切块策略不当。比如把整篇周报切成了一块检索“亮点表达”时匹配到的片段太杂模型找不到精确句子。二是检索条数太少或太多。TopK 设得太少相关文档没被捞出来设得太多无关内容会干扰输出。三是查询语句太口语化。比如用户说“帮我写个上个月的总结”知识库检索时用的是整句原文去匹配效果自然差。OpenClaw 支持重写检索查询可以先让模型把用户的话改写成适合检索的关键词组合再去知识库查。我用完之后检索命中率明显提高。四是向量化模型与文档语言不匹配。如果是中文文档嵌入模型必须对中文有较好的支持否则检索质量会非常差。建议在搭建知识库之前先用一组中文样例测试检索命中率。5.5 上下文太长导致超时智能体在写作场景下上下文很容易超长。用户粘贴一大段对话记录、技能触发了知识库检索、历史消息又参与拼装几轮下来传给模型的上下文可能超过模型窗口上限表现为请求失败或超时。OpenClaw 对这类问题有一些缓解手段但我更建议在技能层做控制而不是依赖后端硬截断。比如“#纪要”技能在用户粘贴对话记录后先做一步“压缩”把记录里的闲聊、无关内容过滤掉只保留带实质内容的语句再作为最终上下文提交给模型。这一步能极大降低超时概率也能提升纪要质量。另外要给每个技能设置明确的输入长度上限。超过上限时不是无奈地截断而是主动提示用户“记录过长请分段提供”这比静默丢数据要安全得多。6. 进阶玩法从“能写”到“好用”6.1 定时任务让周报主动来找人写作助手跑通之后我做的第一个进阶功能是“定时提醒写周报”。OpenClaw 支持定时任务配置。每周五下午五点机器人会自动在团队群发一条消息内容是各位周报时间到。回复“#周报”把本周完成事项发给我我会在五分钟内生成初稿。这个功能本身不复杂但它改变了使用习惯。以前是“我想起来才写”现在是“机器人提醒我写”。对于团队来说这种主动式交互比被动响应更容易形成使用粘性。定时任务里要处理好时区和节假日。我建议不要硬编码在技能里而是通过配置管理否则遇到节假日调休提醒就会变得不合时宜。6.2 与多维表格联动从生成到归档第二个有价值的玩法是让生成结果直接写入多维表格。比如“#周报”生成之后默认只是把文本发到群里但如果接入了多维表格就可以按“人、周次、进展、风险”几个字段自动写入一条记录。后续团队的周报汇总、向上汇报直接从表格拉数就行不需要再让人收集整理。这个联动在 OpenClaw 里是通过“数据表写入”工具实现的。配置过程也不复杂先在协作平台的多维表格里建好字段再在 OpenClaw 的工具配置里填上表格 ID 和 API Token然后技能生成内容时将结构化字段映射到表格列。做这一步有一个前提技能输出必须是结构化数据。如果模型生成的是大段文本写进表格后很难拆分。所以我在“#周报”技能里专门定义了一个 JSON 结构输出步骤生成后先把文本解析成字段再写入表格。6.3 多人协作权限与职责分离当写作助手不止一个人用时就要考虑权限问题了。我遇到过的情况是有人用机器人生成对外公告但公告内容还需要指定负责人审核后才能发出去。OpenClaw 的事件模型里可以识别消息发送者的身份。我基于这个能力做了两套策略普通成员只能触发“#周报”“#纪要”“#润色”这类个人写作技能团队管理员可以触发“#公告”这类对外输出技能。这种做法不是故意添麻烦而是为了避免“机器人生成了错误的对外文案还直接被发了出去”这种风险。写作助手服务于生产力但前提是它不能成为错误信息的放大器。6.4 人工审核给生成内容留一道闸最后说一个我强烈建议的功能人工审核。写作助手生成的初稿质量再怎么高也只能当“初稿”来用。所以在对外场景里我加了一条“生成后不直接发布”的规则机器人把初稿发给发起人并提示请确认以下内容是否需要修改。回复“确认”后我再发送到目标群回复修改意见我会按意见重新生成。这个设计的出发点很简单机器人的写作能力再强也不代表它能替团队承担表达责任。留一道人工闸让“AI 生成”变成“AI 辅助”既安全又实用。从实际使用效果看加了人工审核之后团队对机器人的信任度反而更高了。因为大家知道最终发出去的内容是经过人确认的不会出现“机器人说错话”的尴尬。最后再啰嗦几句我自己折腾这套写作助手下来的最大感受是配置本身不难难的是把“能力边界”定清楚。技术同学容易陷进“让机器人无所不能”的兴奋里但真正让团队愿意长期用的是一个“在有限场景下稳定输出”的助手。如果你准备自己动手配置我建议按这个顺序走先把最小链路跑通再定义人设再接技能知识库和定时任务放到后面。每一步都用真实场景的样例去验证别拿“你好”测试完就当完成。还有一个小技巧给每个技能准备一个“验收清单”。比如“#纪要”的验收标准可以是五要素齐全、无虚构内容、格式规范。每次调完参数用同一份测试材料跑三遍看输出是否稳定。写作助手这活儿稳定性比偶尔惊艳重要得多。后续如果你们团队也把写作助手接进了协作平台欢迎来交流你们在技能设计和知识库搭建上的思路。这块的坑很多但收益也确实很大。
阅读完成 · 觉得有帮助？
