WorkBuddy 开放平台上线之后我身边不少朋友第一反应都是“这跟 CodeBuddy 有什么区别”。用过一段时间之后我的判断是CodeBuddy 是围着代码转的编程助手而 WorkBuddy 是围着“业务流程”转的效率智能体它的开放平台把 Agent、技能、连接器、知识库、工作流这一整套东西打包开放出来个人开发者可以把它当成一个低代码的 Agent 应用工厂。这篇文章我就完整记录一下个人开发者从注册、创建应用、配置技能、编排工作流到发布一个真正能跑的 Agent 应用的全过程包括我在实际接入中踩过的坑和排查思路适合想用 Agent 做办公自动化、个人效率工具又不想从零搓模型的服务端同学参考。1. 先搞清楚 WorkBuddy 开放平台到底“开放”了什么1.1 WorkBuddy 不是 CodeBuddy别拿编程助手的思路套很多新手上来就把 WorkBuddy 当成 CodeBuddy 的另一个版本这是个很容易犯的误解。CodeBuddy 的核心资产是“帮你写代码的能力”它把补全、解释、重构、Agent 化编程融合在 IDE 生态里解决的是开发效率问题。WorkBuddy 不一样它是腾讯的效率智能体重心在“替你去协调任务、操作工具、驱动流程”上典型的场景是整理多维表、定时推送、汇总信息、对接各种办公系统。从我自己的体验来看两者在使用方式上也有明显差异。用 CodeBuddy 时你是在“与一个懂编程的人结对编程”而用 WorkBuddy 时你更像是“给一个虚拟员工派活”你需要告诉它任务目标、可用工具、处理流程边界。这个思维转换很重要如果一直用编程助手的思路去用 WorkBuddy会发现很多能力发挥不出来。另外要注意的是CodeBuddy 的定位偏专业开发者而 WorkBuddy 的开放平台把大量能力模块化、可视化个人开发者不需要懂模型微调也能拼出一个可用的 Agent 应用。对非程序员来说这是个很友好的入口对程序员来说我们多了一层用 API 和工具去扩展的机会。1.2 开放平台的核心能力拆解我在接入时把 WorkBuddy 开放平台的能力归纳成五层这五层基本决定了你能写出什么复杂度的 Agent 应用层级核心作用个人开发者重点关注Agent 应用最终交付物面向用户/API 调用创建一个应用并对外开放Skill技能定义 Agent 能做什么专业动作复用平台技能或自定义Connector连接器打通第三方系统与内部工具钉钉多维表、飞书、企业微信、Obsidian知识库给 Agent 提供业务资料和上下文上传文档、绑定笔记、检索资料Workflow工作流将上述能力编排成有逻辑的流程定时触发、条件分支、循环处理这五个层级是逐层组合的关系。最基础的做法是只配指令把 Agent 当成一个问答机器人稍微复杂一点就挂上连接器和知识库再往上就可以用工作流把“合线任务”拆成有先后顺序的步骤。对比一下市面上类似平台比如扣子、DeepSeek 开放平台也在做类似的分层设计但 WorkBuddy 的差异点在于它对办公场景的连接器生态更偏“桌面工作台”本地客户端可以操作本机文件、执行命令甚至做 UI 自动化这是它比较难得的地方。1.3 个人开发者为什么值得现在接入我的判断是现在接入 WorkBuddy 开放平台有三层收益。第一层是解决自己的重复劳动。我最早做的一个应用就是定时把本地 CSV 数据同步到钉钉多维表以前下班前手动整理要花十几分钟现在定时任务到点自动跑。第二层是沉淀技能资产。你在平台上写好的指令、开发好的 Skill、编排好的工作流都可以存下来重复使用也可以共享给团队。对个人来说这些配置本身就是越来越值钱的数字资产。第三层是打通从“工具”到“服务”的路径。接入开放平台后应用可以发布成 API 或消息服务别人也能通过开放的接口调用你的 Agent。腾讯自己也推出了相关的从业者认证这说明生态正在往“个人开发者提供智能体服务”的方向走现在入场可以占到时间窗口。2. 从零开始账号、工具链和第一个应用2.1 网页版还是本地客户端先选入口再选方案WorkBuddy 有网页版、桌面客户端和 Linux 版本很多新手会纠结到底用哪个。我的建议是先想清楚你的 Agent 要操作什么。如果你的应用只涉及云端服务和办公软件比如读取钉钉多维表、调用知识库、定时发消息直接用网页版和开放平台后台就够了不用装客户端。如果你的应用需要操作本地文件、读写本地数据库、控制桌面软件、做 UI 自动化那就得装桌面客户端而且要注意 Windows 和 Linux 版本的差异。我自己在 Ubuntu 上部署过一次。Linux 版本的好处是可以把 WorkBuddy 的本地能力跑在服务器上配合 cron 或者平台定时触发做后台任务坏处是图形环境依赖比较多如果服务器没有桌面环境部分 UI 自动化功能会受限。更稳妥的做法是服务器上跑逻辑编排和 API 接入本地机器跑需要图形界面的交互任务两边通过工作流连接器协同。2.2 注册、认证与创建个人工作空间接入开放平台的第一步是注册账号这一步没什么难度用常规的注册方式就能完成。完成注册之后我建议先别急着创建应用去找到开发者认证入口完成个人开发者认证。个人开发者认证通常需要提供真实身份信息审核周期不长但如果不认证很多 API 权限和发布功能是打不开的。认证通过后平台会让你创建团队或工作空间。个人开发者就建一个“个人空间”事实上个人空间已经足够测试和运行大部分应用。不过要注意团队空间和个人空间的权限模型相差挺多团队空间里可以设置成员角色、资源分组、更细粒度的权限控制如果后续要把应用共享给同事使用建议从一开始就用团队空间省得后面迁移。创建完空间后最好花五分钟把“应用”和“技能”的目录结构搞清楚。应用是交付物技能是能力单元一个应用可以挂多个技能和连接器。这个理解越早建立后面编排工作流时就越不容易乱。2.3 创建应用、获取密钥理解鉴权与权限登录开放平台后台进入“应用管理”创建一个新应用。创建时会让你选择应用类型比如“个人应用”或“团队应用”个人项目选前者就行。创建成功后系统会生成一组密钥信息包括App ID应用的唯一标识Client Secret调用 API 时用于签名的密钥工作空间 ID资源隔离的标识这组信息一定要妥善保存尤其是 Client Secret它等同于你应用的“密码”。我见过不少开发者把密钥直接写在代码里提交到仓库这种操作非常危险一旦泄露别人就能以你应用的身份调用 API、读取知识库、触发工作流。正确的做法是把密钥放在环境变量或密钥管理服务里比如export WORKBUDDY_APP_IDyour_app_id export WORKBUDDY_CLIENT_SECRETyour_secret然后在代码中通过环境变量读取。另外开放平台的 API 通常采用 Token 机制调用前需要用 App ID 和 Secret 换取访问令牌令牌有过期时间频繁使用时要做缓存刷新别每次调用都去换一次 Token。2.4 第一个接口调用验证链路是否打通配置好密钥之后我习惯先跑一个最小的接口调用把整个链路验证通。以调用一个最简 Agent 对话接口为例伪代码大致是import requests def get_token(): # 用 app_id 和 client_secret 换取 token resp requests.post(https://api.open.workbuddy.example/v1/auth/token, json{ app_id: os.environ[WORKBUDDY_APP_ID], client_secret: os.environ[WORKBUDDY_CLIENT_SECRET] }) resp.raise_for_status() return resp.json()[access_token] def run_agent(text): token get_token() resp requests.post( https://api.open.workbuddy.example/v1/agent/run, headers{Authorization: fBearer {token}}, json{agent_id: your_agent_id, input: text} ) return resp.json() print(run_agent(你好请介绍一下你自己))注意上面的域名和路径是示例写法真实要以官方开放平台文档为准但调用流程的逻辑是一致的先换 Token再带 Token 调业务接口。如果这一步能正常返回结果说明账号、密钥、应用三者已经打通后面就可以放心做配置和编排了。如果在这一步就报错大多数是密钥填错、Token 过期、或者 IP 白名单没配好先去检查这三项。3. 设计一个真正能落地的 Agent指令、技能与工作流3.1 先写需求文档再写 Agent很多人在平台上建完应用立刻就开始写指令、配连接器结果做到一半发现需求没有想清楚来回返工。我现在的习惯是先在本地把“人话需求”写下来不碰任何配置。写需求文档时我会固定回答四个问题这个 Agent 的输入是什么用户的一句话、一条定时消息、一个 Webhook 请求输出是什么一段总结、一条推送、一次数据写入它需要借助哪些外部工具读取哪个表格、调用哪个接口、访问哪些资料边界在哪里不处理什么、权限到哪一层、数据量上限拿一个典型的场景举例——“定时同步钉钉多维表变更并推送提醒”输入是定时信号输出是微信消息工具是钉钉多维表连接器和消息推送连接器边界是只同步指定的视图、不写回数据、失败时只告警不重试。把这个写清楚之后后面每一步配置都会很快。3.2 自定义指令Agent 的“人设”与操作手册WorkBuddy 里的自定义指令是决定 Agent 行为风格的关键。它不是随便写几句话让模型“扮演”某个角色而是要给 Agent 一个稳定、可执行、边界清晰的操作手册。一个好的自定义指令模板我建议至少包含角色定义你是谁有什么能力任务目标你主要负责哪类事情执行步骤接到任务后先做什么、再做什么约束条件哪些事不能做哪些信息不能臆造输出格式固定结构方便下游处理举个例子如果你要让 Agent 做“周报信息收集助手”指令可以写成你是周报信息收集助手。每周五下午会收到团队成员的周报内容。 你的任务是从周报中提取本周完成事项、下周计划和风险问题三类信息。 提取时严格遵循原文不要补充原文没有的内容。 输出格式为 本周完成…… 下周计划…… 风险问题……这种指令比“帮我分析周报”有效得多因为模型对任务的预期被完全锁死了。我实测下来指令里的“约束条件”和“输出格式”这两段价值最大前者能显著减少幻觉输出后者能让下游工作流稳定解析。3.3 Skill 和连接器一个输出能力一个连接世界Skill 和连接器是最容易混淆的两个概念。我的理解是Skill 是 Agent 本身具备的专业能力比如“PDF 解析”“表格对比”“文本分类”连接器是 Agent 与外部世界打交道的“适配器”比如“钉钉导入”“飞书发送”“企业微信会话”。换句话说Skill 解决的是“会什么”连接器解决的是“能碰到什么”。一个 Agent 可以没有连接器只靠 Skill 做离线处理也可以只有连接器做纯数据搬运但要想处理真实业务两者通常要配合。在 WorkBuddy 开放平台上平台内置了一批官方 Skill 和连接器个人开发者可以先从复用的角度开始用现成的能力验证流程。如果平台满足不了需求再考虑自定义 Skill。自定义 Skill 一般有两种方式一是给 Agent 编写更详细的能力描述和示例让它具备某种新的处理能力二是通过 API 注册一个外部函数让 Agent 可以动态调用你自己的服务。从我自己的经验看第一次做应用时不要贪多先挂一个连接器、一个 Skill跑通后再加复杂度。接太多资源会让调试时无法定位到底是哪一环出的问题。3.4 知识库接入给 Agent 喂“内部资料”Agent 的默认知识来自基础模型它大概率不知道你团队的内部规范和业务数据。想让 Agent 回答你自己文档里的内容就要接入知识库。接入流程不复杂在开放平台创建知识库上传文档平台会自动完成分块和向量化。需要理解的概念是系统不会把整篇文档原样塞给模型而是把文档切成小块再通过向量检索找出与问题最相关的若干片段拼接进提示词。所以知识库的设计有两个关键点一是文档分块不要太碎也不要太大太碎了检索时缺少上下文太大了有效信息会被稀释二是检索数量要合理个人场景默认返回 3 到 5 个片段就够返回太多会把不相关的内容带进来反而干扰模型回答。我在配置知识库时踩过一个坑直接把 Obsidian 里的笔记全量上传结果因为笔记之间的交叉引用多检索出来的片段经常是断章取义。后来我是按“主题维度”把笔记拆成多个知识库并在 Agent 指令里明确告诉它“先判断问题属于哪个主题再去对应知识库检索”效果好了非常多。3.5 工作流编排把智能放进流程里只配指令和工具Agent 的行为仍然有较大的不确定性。如果希望这个应用在“固定时间、做固定动作、按固定规则判断”就需要工作流。WorkBuddy 的工作流和常见的自动化平台类似核心节点包括触发节点、代码节点、条件判断、循环处理、消息通知。它最大的价值是把原来靠模型即兴发挥的部分变成确定性的流程逻辑只有在必须“理解语义”的环节才调用大模型能力。举一个最简单的流程设计定时触发 - 调连接器读取钉钉多维表 - 用文本处理节点清洗数据 - 条件判断是否有新增记录 - 有则推送消息无则结束。在这个流程里真正用到模型智能的地方很少大部分是确定性的规则判断这样的应用运行起来稳定、可控、可排查。我建议的工作流设计原则是能用规则解决的不用模型能用模型解决的不用人流程节点尽量单一职责。这样出现问题时只看日志就能定位到具体节点。4. 完整实战钉钉多维表数据同步 定时微信提醒4.1 场景拆解触发、动作、输出现在用一个完整案例把上面的思路串起来。场景来自真实需求每天早上 9 点检查钉钉多维表中某个视图里“状态为待处理”的记录如果有新的未处理记录就把它们汇总后推送到微信群里并顺便发一条通知给负责人。拆解下来是这个结构触发方式定时触发每天 09:00动作一读取钉钉多维表指定视图的全部记录动作二筛选状态为“待处理”的记录动作三与上一次同步结果做对比找出新增项动作四将新增项格式化为文本输出通过消息推送连接器发到微信群这个流程没有特别复杂的逻辑分支但对稳定性的要求比较高因为它是每天自动跑的不允许出错了还有个人在边上盯着修。4.2 配置钉钉多维表连接器在开放平台后台找到钉钉连接器点击授权。这一步要注意授权时会让你勾选权限点我建议遵循最小权限原则只勾选“读取多维表记录”和“获取多维表信息”不要顺手把所有权限都勾上。权限越多未来泄露或被滥用的面就越大。授权完成后需要配置数据源。多维表的一个关键参数是“表格 UID”和“视图 ID”。新手容易在这里卡住在钉钉后台打开多维表时URL 里通常可以看到表格标识视图 ID 则在多维表界面的 URL 参数中具体位置以 WorkBuddy 官方文档的说明为准。配置好连接器后先不要直接接工作流先在连接器配置页做一次“测试连接”确认能正确读到表里的数据。这一步能省掉后面大量排查时间因为很多后续问题其实都源于最初就连不通。4.3 编排“读取 - 对比 - 判断 - 推送”工作流打开工作流编辑器创建一个新的工作流。节点按以下顺序排定时触发节点配置 cron 表达式为0 9 * * *时区选 Asia/Shanghai。读取多维表节点选择钉钉连接器填写表格 UID 和视图 ID输出完整记录集。数据过滤节点筛选条件是“状态等于待处理”。这一步用平台内置的过滤节点就能做不需要写代码。对比节点把本次筛选结果和上一次执行的缓存结果做差异对比输出新增项列表。平台如果提供“存储上一次结果”的能力就直接用没有的话可以自己维护一个状态表通过连接器写入。格式化节点把新增项逐条拼成可读文本格式大概是“新增待处理任务XXX负责人XXX”。推送消息节点选择微信通知通道把文本发到指定群。工作流设计完成后先把“定时触发”临时改成“手动触发”点击运行观察每个节点的输入输出。这里特别提醒第一次跑的时候对比节点很可能出错因为第一次执行根本没有“上一次结果”作为基准。我的处理方式是第一次运行只采集数据写入缓存不推送消息从第二次开始才触发推送逻辑。4.4 调试技巧分段验证、关键节点打印工作流跑不通的时候新手最容易犯的错误是盯着最终结果猜问题看到没推送消息就怀疑推送节点实际上是读取多维表那一步就已经失败了。我的调试方法是分段验证。先把流程从前往后拆成三段接入段定时到读取、处理段过滤、对比、格式化、输出段推送。每一段都单独运行一次确认通过再组合。在 WorkBuddy 工作流里每个节点的输入输出参数都可以打印出来。我会特别关注三类信息读取节点返回的字段名是否与预期一致比如状态字段的真实值可能是数字编码而不是中文过滤节点执行后记录数是否合理如果过滤后是 0检查筛选条件是否写反推送节点的消息内容里有没有出现空值和乱码如果某个节点支持“调试视图”直接在调试视图里查看数据样本比看运行日志直观得多。调试通过后再把定时触发打开观察连续两天的表现确认对比逻辑在真实日切场景下没有问题。4.5 发布上线与权限控制工作流调试通过后回到应用管理把工作流挂载到应用上并做一次发布。发布的目的是让应用从“草稿状态”变成“可用状态”并且生成对外可调用的接口或触发入口。发布时有一个很重要的配置项是权限范围。你可以选择仅自己可见适合还没有完全验证的应用空间内可见适合团队内部使用公开到平台适合想分享给外部用户我的建议是个人项目先选“仅自己可见”或“空间内可见”运行一两周确认稳定后再扩大范围。因为一次不成熟的发布如果触发了高频定时任务可能会产生意外的 API 调用量或数据写操作到时候排查起来很被动。发布后还要记得把密钥信息从这个项目的运维流程里彻底隔离。我说一个实际教训有一次我把 App ID 和 Secret 写在了一个自动化脚本的环境变量里后来这个脚本要给别人用环境变量差点被带出去。现在我的统一做法是凡是涉及密钥的配置一律只放在本地环境变量或所部署服务器的环境变量里不进入任何代码仓库和分享文件。5. 运行期常见故障与排查实录5.1 错误码 3002网络连接失败的排查路径用 WorkBuddy 一段时间后我遇到比较多的问题就是错误码 3002 网络连接失败。第一次遇到时我开始以为是开放平台服务不稳定后来才发现大部分情况下问题出在本地网络环境。排查时我会按这个顺序走检查本机网络是否正常能否正常打开网页、能否访问其他云端 API。检查系统防火墙是否拦截了 WorkBuddy 进程的网络请求尤其在企业内网环境需要确认目标域名是否加入了访问白名单。检查客户端或系统代理设置。如果客户端支持配置代理看看是不是填了一个已经失效的代理地址系统层面也要确认没有残留的代理设置指向不可用的服务。查看本地日志确认具体是在“认证”“连接服务器”还是“请求超时”环节失败。日志给出的阶段信息能直接缩小排查范围。如果上面都没问题再考虑是不是服务端临时故障可以去开放平台的状态页或开发者社区确认。这个错误码在 Linux/Ubuntu 环境下更常见因为服务器环境的网络限制往往比个人电脑多尤其是公司内网服务器。如果部署在云主机上还要检查安全组和出网规则。5.2 客户端启动慢从插件到索引逐个排查有段时间我的 WorkBuddy 客户端启动特别慢甚至要等好几分钟才能进入工作台。我一开始以为是机器配置不够后来排查下来是多方面原因叠加。第一个原因是插件过多。WorkBuddy 支持挂载各类插件和 Skill每次启动都会加载这些能力模块插件装多了启动时间自然变长。我的处理办法是把不常用的插件禁用掉只保留日常需要的几个。第二个原因是本地索引。如果客户端配置了本机文件索引或知识库同步启动时它可能会去扫描大量文件。我配置了 Obsidian 库同步之后启动时间明显变长。后来我把同步策略改成了手动触发只在需要时更新索引启动就快了很多。第三个原因容易被忽略缓存文件损坏。如果某次异常退出导致缓存损坏启动阶段会在定位缓存时反复重试。遇到这种情况最简单的方法是退出客户端后清理缓存目录再重新启动但要先确认清理缓存不会影响你的本地配置。5.3 连接器授权失效与 Skill 加载异常连接器用一段时间后突然报“授权失效”这是很常见的问题。原因是第三方平台的 Token 一般有时效到期后连接器就变成不可用状态。解决办法并不复杂回到连接器管理页面重新授权即可。但要注意如果你的连接器被多个应用或工作流引用重新授权后要重新做一次连通性测试确认所有引用它的工作流都能正常访问。Skill 加载异常则通常有两个原因。一是 Skill 依赖的底层能力被更新或下线导致调用时找不到对应接口二是自定义 Skill 的描述和示例格式不规范解析时出错。排查思路是先看控制台日志里加载 Skill 的报错信息如果是接口变更去官方文档确认新的调用方式如果是格式问题按文档重新调整 Skill 配置。5.4 Agent 输出不符合预期的调优思路如果你的 Agent 经常输出“看起来合理但其实不对”的内容不要急着反复改指令先定位是哪一层出了问题。我习惯按三个层次去排查。第一层是输入层Agent 收到的上下文数据是否准确完整比如读取多维表时是否少传了某个字段。第二层是指令层指令里对“正确输出”的定义是否足够具体比如“总结今天的待办”和“按负责人分组列出今天的待办并标注截止时间过期或未过期的都要标注清楚”后者的效果会稳定很多。第三层是工具层在调用 Skill 或连接器时传入的参数是否经过了正确的格式化模型有时会输出错误参数格式这需要工作流里加一个“参数清洗节点”来兜底。还有一个容易被忽略的技巧给 Agent 指定“不确定时怎么办”。比如在指令中明确写“如果检索不到相关信息直接回答未找到不要猜测”。这一句话能减少大量看起来一本正经的胡说八道。6. 从个人项目到开放生态还能往哪些方向延伸6.1 UI 自动化让 Agent 操作真实界面WorkBuddy 相比很多纯云端的 Agent 平台一个很实用的差异化能力是 UI 自动化。通过本地客户端Agent 可以操作真实桌面软件比如自动填写表单、点击按钮、抓取界面数据。我测试过一个场景让 Agent 打开某个内部系统页面按条件筛选列表导出数据到本地。这个流程如果用 RPA 工具来做要单独学一套工具链用 WorkBuddy 的话把“打开网页、点击筛选、导出”这些操作描述清楚配合本地客户端的能力就可以跑起来。不过要提醒一句UI 自动化对页面元素的定位稳定性要求比较高。页面改版、元素 id 变化、弹窗遮挡都会导致流程中断。所以它更适合“短期重复操作”或“页面相对稳定的内部系统”不适合作为长期无人值守的关键流程。真要做长期任务优先考虑 API 对接和连接器方案UI 自动化作为兜底补充。6.2 个人知识库助手接入 Obsidian 和 Wiki把 WorkBuddy 和 Obsidian、Wiki 结合起来可以做一个很实用的个人知识助手。思路是把 Obsidian 笔记库作为知识库来源让 Agent 在回答问题时优先检索自己的笔记再把 Wiki 站点作为连接器让 Agent 能拉取团队资料。这个场景的关键在于知识库的组织方式。我在前文提过全量上传笔记会出现检索片段破碎的问题我的解决方案是按照主题建多个知识库并在指令里给 Agent 一个“路由判断”先判断问题属于哪个主题再去对应知识库检索。这样回答的质量会有明显提升。另外可以考虑给这个知识助手加一个“回答格式模板”比如要求它回答时先给结论再给引用来源。这样当你需要回头验证 Agent 给的信息是否是笔记里的原意时可以直接对照来源而不是凭印象判断。6.3 参加 OPC 认证把工具变成可交付的服务腾讯围绕 WorkBuddy 效率智能体推出了 OPC 从业者认证这件事对个人开发者的意义我觉得不只是一个证书而是给“个人开发的智能体应用”提供了一个服务化的通道。通过认证和平台规则个人开发者可以把打磨好的 Agent 应用以更正式的方式提供给团队或外部用户使用。这意味着你的能力边界可以从“自己写给自己用”延伸到“开发一个服务给别人用”对应的是一整套新的交付标准应用稳定性、权限边界、异常处理、文档说明都要跟上。如果往这个方向走我有几点建议从一开始就按“可交付”的标准做应用工作流里补全异常分支、失败重试、日志记录。严格遵守平台的权限和合规要求个人应用不要过度收集用户数据。内容发布前做好敏感信息过滤应用涉及的指令、示例、知识库内容都要符合公序良俗和平台规范。我在实际使用中的体会是Agent 应用的开发跟传统软件开发有一个很不一样的地方它不需要你一开始就把所有边界都定义完美而是可以先做一个最小闭环让它跑起来再通过日志和真实反馈一点点调优。不要怕第一版“笨”怕的是第一版跑不起来、跑起来了你又不知道它为什么这么干。最后再分享一个我每次都会用的小技巧任何 Agent 应用上线前把它的运行日志打开到详细级别连续观察三天。第一天的日志会让你发现“它做了什么你以为没做的事”第二天的日志会让你发现“同样的任务它两次的处理方式竟然不一样”第三天的日志就能让你找到稳定复现的那个问题了。把这个问题修掉你的 Agent 应用才算真正可以从“玩具”变成“工具”。 WorkBuddy开放平台实战：从零构建个人Agent应用与工作流编排
WorkBuddy 开放平台上线之后我身边不少朋友第一反应都是“这跟 CodeBuddy 有什么区别”。用过一段时间之后我的判断是CodeBuddy 是围着代码转的编程助手而 WorkBuddy 是围着“业务流程”转的效率智能体它的开放平台把 Agent、技能、连接器、知识库、工作流这一整套东西打包开放出来个人开发者可以把它当成一个低代码的 Agent 应用工厂。这篇文章我就完整记录一下个人开发者从注册、创建应用、配置技能、编排工作流到发布一个真正能跑的 Agent 应用的全过程包括我在实际接入中踩过的坑和排查思路适合想用 Agent 做办公自动化、个人效率工具又不想从零搓模型的服务端同学参考。1. 先搞清楚 WorkBuddy 开放平台到底“开放”了什么1.1 WorkBuddy 不是 CodeBuddy别拿编程助手的思路套很多新手上来就把 WorkBuddy 当成 CodeBuddy 的另一个版本这是个很容易犯的误解。CodeBuddy 的核心资产是“帮你写代码的能力”它把补全、解释、重构、Agent 化编程融合在 IDE 生态里解决的是开发效率问题。WorkBuddy 不一样它是腾讯的效率智能体重心在“替你去协调任务、操作工具、驱动流程”上典型的场景是整理多维表、定时推送、汇总信息、对接各种办公系统。从我自己的体验来看两者在使用方式上也有明显差异。用 CodeBuddy 时你是在“与一个懂编程的人结对编程”而用 WorkBuddy 时你更像是“给一个虚拟员工派活”你需要告诉它任务目标、可用工具、处理流程边界。这个思维转换很重要如果一直用编程助手的思路去用 WorkBuddy会发现很多能力发挥不出来。另外要注意的是CodeBuddy 的定位偏专业开发者而 WorkBuddy 的开放平台把大量能力模块化、可视化个人开发者不需要懂模型微调也能拼出一个可用的 Agent 应用。对非程序员来说这是个很友好的入口对程序员来说我们多了一层用 API 和工具去扩展的机会。1.2 开放平台的核心能力拆解我在接入时把 WorkBuddy 开放平台的能力归纳成五层这五层基本决定了你能写出什么复杂度的 Agent 应用层级核心作用个人开发者重点关注Agent 应用最终交付物面向用户/API 调用创建一个应用并对外开放Skill技能定义 Agent 能做什么专业动作复用平台技能或自定义Connector连接器打通第三方系统与内部工具钉钉多维表、飞书、企业微信、Obsidian知识库给 Agent 提供业务资料和上下文上传文档、绑定笔记、检索资料Workflow工作流将上述能力编排成有逻辑的流程定时触发、条件分支、循环处理这五个层级是逐层组合的关系。最基础的做法是只配指令把 Agent 当成一个问答机器人稍微复杂一点就挂上连接器和知识库再往上就可以用工作流把“合线任务”拆成有先后顺序的步骤。对比一下市面上类似平台比如扣子、DeepSeek 开放平台也在做类似的分层设计但 WorkBuddy 的差异点在于它对办公场景的连接器生态更偏“桌面工作台”本地客户端可以操作本机文件、执行命令甚至做 UI 自动化这是它比较难得的地方。1.3 个人开发者为什么值得现在接入我的判断是现在接入 WorkBuddy 开放平台有三层收益。第一层是解决自己的重复劳动。我最早做的一个应用就是定时把本地 CSV 数据同步到钉钉多维表以前下班前手动整理要花十几分钟现在定时任务到点自动跑。第二层是沉淀技能资产。你在平台上写好的指令、开发好的 Skill、编排好的工作流都可以存下来重复使用也可以共享给团队。对个人来说这些配置本身就是越来越值钱的数字资产。第三层是打通从“工具”到“服务”的路径。接入开放平台后应用可以发布成 API 或消息服务别人也能通过开放的接口调用你的 Agent。腾讯自己也推出了相关的从业者认证这说明生态正在往“个人开发者提供智能体服务”的方向走现在入场可以占到时间窗口。2. 从零开始账号、工具链和第一个应用2.1 网页版还是本地客户端先选入口再选方案WorkBuddy 有网页版、桌面客户端和 Linux 版本很多新手会纠结到底用哪个。我的建议是先想清楚你的 Agent 要操作什么。如果你的应用只涉及云端服务和办公软件比如读取钉钉多维表、调用知识库、定时发消息直接用网页版和开放平台后台就够了不用装客户端。如果你的应用需要操作本地文件、读写本地数据库、控制桌面软件、做 UI 自动化那就得装桌面客户端而且要注意 Windows 和 Linux 版本的差异。我自己在 Ubuntu 上部署过一次。Linux 版本的好处是可以把 WorkBuddy 的本地能力跑在服务器上配合 cron 或者平台定时触发做后台任务坏处是图形环境依赖比较多如果服务器没有桌面环境部分 UI 自动化功能会受限。更稳妥的做法是服务器上跑逻辑编排和 API 接入本地机器跑需要图形界面的交互任务两边通过工作流连接器协同。2.2 注册、认证与创建个人工作空间接入开放平台的第一步是注册账号这一步没什么难度用常规的注册方式就能完成。完成注册之后我建议先别急着创建应用去找到开发者认证入口完成个人开发者认证。个人开发者认证通常需要提供真实身份信息审核周期不长但如果不认证很多 API 权限和发布功能是打不开的。认证通过后平台会让你创建团队或工作空间。个人开发者就建一个“个人空间”事实上个人空间已经足够测试和运行大部分应用。不过要注意团队空间和个人空间的权限模型相差挺多团队空间里可以设置成员角色、资源分组、更细粒度的权限控制如果后续要把应用共享给同事使用建议从一开始就用团队空间省得后面迁移。创建完空间后最好花五分钟把“应用”和“技能”的目录结构搞清楚。应用是交付物技能是能力单元一个应用可以挂多个技能和连接器。这个理解越早建立后面编排工作流时就越不容易乱。2.3 创建应用、获取密钥理解鉴权与权限登录开放平台后台进入“应用管理”创建一个新应用。创建时会让你选择应用类型比如“个人应用”或“团队应用”个人项目选前者就行。创建成功后系统会生成一组密钥信息包括App ID应用的唯一标识Client Secret调用 API 时用于签名的密钥工作空间 ID资源隔离的标识这组信息一定要妥善保存尤其是 Client Secret它等同于你应用的“密码”。我见过不少开发者把密钥直接写在代码里提交到仓库这种操作非常危险一旦泄露别人就能以你应用的身份调用 API、读取知识库、触发工作流。正确的做法是把密钥放在环境变量或密钥管理服务里比如export WORKBUDDY_APP_IDyour_app_id export WORKBUDDY_CLIENT_SECRETyour_secret然后在代码中通过环境变量读取。另外开放平台的 API 通常采用 Token 机制调用前需要用 App ID 和 Secret 换取访问令牌令牌有过期时间频繁使用时要做缓存刷新别每次调用都去换一次 Token。2.4 第一个接口调用验证链路是否打通配置好密钥之后我习惯先跑一个最小的接口调用把整个链路验证通。以调用一个最简 Agent 对话接口为例伪代码大致是import requests def get_token(): # 用 app_id 和 client_secret 换取 token resp requests.post(https://api.open.workbuddy.example/v1/auth/token, json{ app_id: os.environ[WORKBUDDY_APP_ID], client_secret: os.environ[WORKBUDDY_CLIENT_SECRET] }) resp.raise_for_status() return resp.json()[access_token] def run_agent(text): token get_token() resp requests.post( https://api.open.workbuddy.example/v1/agent/run, headers{Authorization: fBearer {token}}, json{agent_id: your_agent_id, input: text} ) return resp.json() print(run_agent(你好请介绍一下你自己))注意上面的域名和路径是示例写法真实要以官方开放平台文档为准但调用流程的逻辑是一致的先换 Token再带 Token 调业务接口。如果这一步能正常返回结果说明账号、密钥、应用三者已经打通后面就可以放心做配置和编排了。如果在这一步就报错大多数是密钥填错、Token 过期、或者 IP 白名单没配好先去检查这三项。3. 设计一个真正能落地的 Agent指令、技能与工作流3.1 先写需求文档再写 Agent很多人在平台上建完应用立刻就开始写指令、配连接器结果做到一半发现需求没有想清楚来回返工。我现在的习惯是先在本地把“人话需求”写下来不碰任何配置。写需求文档时我会固定回答四个问题这个 Agent 的输入是什么用户的一句话、一条定时消息、一个 Webhook 请求输出是什么一段总结、一条推送、一次数据写入它需要借助哪些外部工具读取哪个表格、调用哪个接口、访问哪些资料边界在哪里不处理什么、权限到哪一层、数据量上限拿一个典型的场景举例——“定时同步钉钉多维表变更并推送提醒”输入是定时信号输出是微信消息工具是钉钉多维表连接器和消息推送连接器边界是只同步指定的视图、不写回数据、失败时只告警不重试。把这个写清楚之后后面每一步配置都会很快。3.2 自定义指令Agent 的“人设”与操作手册WorkBuddy 里的自定义指令是决定 Agent 行为风格的关键。它不是随便写几句话让模型“扮演”某个角色而是要给 Agent 一个稳定、可执行、边界清晰的操作手册。一个好的自定义指令模板我建议至少包含角色定义你是谁有什么能力任务目标你主要负责哪类事情执行步骤接到任务后先做什么、再做什么约束条件哪些事不能做哪些信息不能臆造输出格式固定结构方便下游处理举个例子如果你要让 Agent 做“周报信息收集助手”指令可以写成你是周报信息收集助手。每周五下午会收到团队成员的周报内容。 你的任务是从周报中提取本周完成事项、下周计划和风险问题三类信息。 提取时严格遵循原文不要补充原文没有的内容。 输出格式为 本周完成…… 下周计划…… 风险问题……这种指令比“帮我分析周报”有效得多因为模型对任务的预期被完全锁死了。我实测下来指令里的“约束条件”和“输出格式”这两段价值最大前者能显著减少幻觉输出后者能让下游工作流稳定解析。3.3 Skill 和连接器一个输出能力一个连接世界Skill 和连接器是最容易混淆的两个概念。我的理解是Skill 是 Agent 本身具备的专业能力比如“PDF 解析”“表格对比”“文本分类”连接器是 Agent 与外部世界打交道的“适配器”比如“钉钉导入”“飞书发送”“企业微信会话”。换句话说Skill 解决的是“会什么”连接器解决的是“能碰到什么”。一个 Agent 可以没有连接器只靠 Skill 做离线处理也可以只有连接器做纯数据搬运但要想处理真实业务两者通常要配合。在 WorkBuddy 开放平台上平台内置了一批官方 Skill 和连接器个人开发者可以先从复用的角度开始用现成的能力验证流程。如果平台满足不了需求再考虑自定义 Skill。自定义 Skill 一般有两种方式一是给 Agent 编写更详细的能力描述和示例让它具备某种新的处理能力二是通过 API 注册一个外部函数让 Agent 可以动态调用你自己的服务。从我自己的经验看第一次做应用时不要贪多先挂一个连接器、一个 Skill跑通后再加复杂度。接太多资源会让调试时无法定位到底是哪一环出的问题。3.4 知识库接入给 Agent 喂“内部资料”Agent 的默认知识来自基础模型它大概率不知道你团队的内部规范和业务数据。想让 Agent 回答你自己文档里的内容就要接入知识库。接入流程不复杂在开放平台创建知识库上传文档平台会自动完成分块和向量化。需要理解的概念是系统不会把整篇文档原样塞给模型而是把文档切成小块再通过向量检索找出与问题最相关的若干片段拼接进提示词。所以知识库的设计有两个关键点一是文档分块不要太碎也不要太大太碎了检索时缺少上下文太大了有效信息会被稀释二是检索数量要合理个人场景默认返回 3 到 5 个片段就够返回太多会把不相关的内容带进来反而干扰模型回答。我在配置知识库时踩过一个坑直接把 Obsidian 里的笔记全量上传结果因为笔记之间的交叉引用多检索出来的片段经常是断章取义。后来我是按“主题维度”把笔记拆成多个知识库并在 Agent 指令里明确告诉它“先判断问题属于哪个主题再去对应知识库检索”效果好了非常多。3.5 工作流编排把智能放进流程里只配指令和工具Agent 的行为仍然有较大的不确定性。如果希望这个应用在“固定时间、做固定动作、按固定规则判断”就需要工作流。WorkBuddy 的工作流和常见的自动化平台类似核心节点包括触发节点、代码节点、条件判断、循环处理、消息通知。它最大的价值是把原来靠模型即兴发挥的部分变成确定性的流程逻辑只有在必须“理解语义”的环节才调用大模型能力。举一个最简单的流程设计定时触发 - 调连接器读取钉钉多维表 - 用文本处理节点清洗数据 - 条件判断是否有新增记录 - 有则推送消息无则结束。在这个流程里真正用到模型智能的地方很少大部分是确定性的规则判断这样的应用运行起来稳定、可控、可排查。我建议的工作流设计原则是能用规则解决的不用模型能用模型解决的不用人流程节点尽量单一职责。这样出现问题时只看日志就能定位到具体节点。4. 完整实战钉钉多维表数据同步 定时微信提醒4.1 场景拆解触发、动作、输出现在用一个完整案例把上面的思路串起来。场景来自真实需求每天早上 9 点检查钉钉多维表中某个视图里“状态为待处理”的记录如果有新的未处理记录就把它们汇总后推送到微信群里并顺便发一条通知给负责人。拆解下来是这个结构触发方式定时触发每天 09:00动作一读取钉钉多维表指定视图的全部记录动作二筛选状态为“待处理”的记录动作三与上一次同步结果做对比找出新增项动作四将新增项格式化为文本输出通过消息推送连接器发到微信群这个流程没有特别复杂的逻辑分支但对稳定性的要求比较高因为它是每天自动跑的不允许出错了还有个人在边上盯着修。4.2 配置钉钉多维表连接器在开放平台后台找到钉钉连接器点击授权。这一步要注意授权时会让你勾选权限点我建议遵循最小权限原则只勾选“读取多维表记录”和“获取多维表信息”不要顺手把所有权限都勾上。权限越多未来泄露或被滥用的面就越大。授权完成后需要配置数据源。多维表的一个关键参数是“表格 UID”和“视图 ID”。新手容易在这里卡住在钉钉后台打开多维表时URL 里通常可以看到表格标识视图 ID 则在多维表界面的 URL 参数中具体位置以 WorkBuddy 官方文档的说明为准。配置好连接器后先不要直接接工作流先在连接器配置页做一次“测试连接”确认能正确读到表里的数据。这一步能省掉后面大量排查时间因为很多后续问题其实都源于最初就连不通。4.3 编排“读取 - 对比 - 判断 - 推送”工作流打开工作流编辑器创建一个新的工作流。节点按以下顺序排定时触发节点配置 cron 表达式为0 9 * * *时区选 Asia/Shanghai。读取多维表节点选择钉钉连接器填写表格 UID 和视图 ID输出完整记录集。数据过滤节点筛选条件是“状态等于待处理”。这一步用平台内置的过滤节点就能做不需要写代码。对比节点把本次筛选结果和上一次执行的缓存结果做差异对比输出新增项列表。平台如果提供“存储上一次结果”的能力就直接用没有的话可以自己维护一个状态表通过连接器写入。格式化节点把新增项逐条拼成可读文本格式大概是“新增待处理任务XXX负责人XXX”。推送消息节点选择微信通知通道把文本发到指定群。工作流设计完成后先把“定时触发”临时改成“手动触发”点击运行观察每个节点的输入输出。这里特别提醒第一次跑的时候对比节点很可能出错因为第一次执行根本没有“上一次结果”作为基准。我的处理方式是第一次运行只采集数据写入缓存不推送消息从第二次开始才触发推送逻辑。4.4 调试技巧分段验证、关键节点打印工作流跑不通的时候新手最容易犯的错误是盯着最终结果猜问题看到没推送消息就怀疑推送节点实际上是读取多维表那一步就已经失败了。我的调试方法是分段验证。先把流程从前往后拆成三段接入段定时到读取、处理段过滤、对比、格式化、输出段推送。每一段都单独运行一次确认通过再组合。在 WorkBuddy 工作流里每个节点的输入输出参数都可以打印出来。我会特别关注三类信息读取节点返回的字段名是否与预期一致比如状态字段的真实值可能是数字编码而不是中文过滤节点执行后记录数是否合理如果过滤后是 0检查筛选条件是否写反推送节点的消息内容里有没有出现空值和乱码如果某个节点支持“调试视图”直接在调试视图里查看数据样本比看运行日志直观得多。调试通过后再把定时触发打开观察连续两天的表现确认对比逻辑在真实日切场景下没有问题。4.5 发布上线与权限控制工作流调试通过后回到应用管理把工作流挂载到应用上并做一次发布。发布的目的是让应用从“草稿状态”变成“可用状态”并且生成对外可调用的接口或触发入口。发布时有一个很重要的配置项是权限范围。你可以选择仅自己可见适合还没有完全验证的应用空间内可见适合团队内部使用公开到平台适合想分享给外部用户我的建议是个人项目先选“仅自己可见”或“空间内可见”运行一两周确认稳定后再扩大范围。因为一次不成熟的发布如果触发了高频定时任务可能会产生意外的 API 调用量或数据写操作到时候排查起来很被动。发布后还要记得把密钥信息从这个项目的运维流程里彻底隔离。我说一个实际教训有一次我把 App ID 和 Secret 写在了一个自动化脚本的环境变量里后来这个脚本要给别人用环境变量差点被带出去。现在我的统一做法是凡是涉及密钥的配置一律只放在本地环境变量或所部署服务器的环境变量里不进入任何代码仓库和分享文件。5. 运行期常见故障与排查实录5.1 错误码 3002网络连接失败的排查路径用 WorkBuddy 一段时间后我遇到比较多的问题就是错误码 3002 网络连接失败。第一次遇到时我开始以为是开放平台服务不稳定后来才发现大部分情况下问题出在本地网络环境。排查时我会按这个顺序走检查本机网络是否正常能否正常打开网页、能否访问其他云端 API。检查系统防火墙是否拦截了 WorkBuddy 进程的网络请求尤其在企业内网环境需要确认目标域名是否加入了访问白名单。检查客户端或系统代理设置。如果客户端支持配置代理看看是不是填了一个已经失效的代理地址系统层面也要确认没有残留的代理设置指向不可用的服务。查看本地日志确认具体是在“认证”“连接服务器”还是“请求超时”环节失败。日志给出的阶段信息能直接缩小排查范围。如果上面都没问题再考虑是不是服务端临时故障可以去开放平台的状态页或开发者社区确认。这个错误码在 Linux/Ubuntu 环境下更常见因为服务器环境的网络限制往往比个人电脑多尤其是公司内网服务器。如果部署在云主机上还要检查安全组和出网规则。5.2 客户端启动慢从插件到索引逐个排查有段时间我的 WorkBuddy 客户端启动特别慢甚至要等好几分钟才能进入工作台。我一开始以为是机器配置不够后来排查下来是多方面原因叠加。第一个原因是插件过多。WorkBuddy 支持挂载各类插件和 Skill每次启动都会加载这些能力模块插件装多了启动时间自然变长。我的处理办法是把不常用的插件禁用掉只保留日常需要的几个。第二个原因是本地索引。如果客户端配置了本机文件索引或知识库同步启动时它可能会去扫描大量文件。我配置了 Obsidian 库同步之后启动时间明显变长。后来我把同步策略改成了手动触发只在需要时更新索引启动就快了很多。第三个原因容易被忽略缓存文件损坏。如果某次异常退出导致缓存损坏启动阶段会在定位缓存时反复重试。遇到这种情况最简单的方法是退出客户端后清理缓存目录再重新启动但要先确认清理缓存不会影响你的本地配置。5.3 连接器授权失效与 Skill 加载异常连接器用一段时间后突然报“授权失效”这是很常见的问题。原因是第三方平台的 Token 一般有时效到期后连接器就变成不可用状态。解决办法并不复杂回到连接器管理页面重新授权即可。但要注意如果你的连接器被多个应用或工作流引用重新授权后要重新做一次连通性测试确认所有引用它的工作流都能正常访问。Skill 加载异常则通常有两个原因。一是 Skill 依赖的底层能力被更新或下线导致调用时找不到对应接口二是自定义 Skill 的描述和示例格式不规范解析时出错。排查思路是先看控制台日志里加载 Skill 的报错信息如果是接口变更去官方文档确认新的调用方式如果是格式问题按文档重新调整 Skill 配置。5.4 Agent 输出不符合预期的调优思路如果你的 Agent 经常输出“看起来合理但其实不对”的内容不要急着反复改指令先定位是哪一层出了问题。我习惯按三个层次去排查。第一层是输入层Agent 收到的上下文数据是否准确完整比如读取多维表时是否少传了某个字段。第二层是指令层指令里对“正确输出”的定义是否足够具体比如“总结今天的待办”和“按负责人分组列出今天的待办并标注截止时间过期或未过期的都要标注清楚”后者的效果会稳定很多。第三层是工具层在调用 Skill 或连接器时传入的参数是否经过了正确的格式化模型有时会输出错误参数格式这需要工作流里加一个“参数清洗节点”来兜底。还有一个容易被忽略的技巧给 Agent 指定“不确定时怎么办”。比如在指令中明确写“如果检索不到相关信息直接回答未找到不要猜测”。这一句话能减少大量看起来一本正经的胡说八道。6. 从个人项目到开放生态还能往哪些方向延伸6.1 UI 自动化让 Agent 操作真实界面WorkBuddy 相比很多纯云端的 Agent 平台一个很实用的差异化能力是 UI 自动化。通过本地客户端Agent 可以操作真实桌面软件比如自动填写表单、点击按钮、抓取界面数据。我测试过一个场景让 Agent 打开某个内部系统页面按条件筛选列表导出数据到本地。这个流程如果用 RPA 工具来做要单独学一套工具链用 WorkBuddy 的话把“打开网页、点击筛选、导出”这些操作描述清楚配合本地客户端的能力就可以跑起来。不过要提醒一句UI 自动化对页面元素的定位稳定性要求比较高。页面改版、元素 id 变化、弹窗遮挡都会导致流程中断。所以它更适合“短期重复操作”或“页面相对稳定的内部系统”不适合作为长期无人值守的关键流程。真要做长期任务优先考虑 API 对接和连接器方案UI 自动化作为兜底补充。6.2 个人知识库助手接入 Obsidian 和 Wiki把 WorkBuddy 和 Obsidian、Wiki 结合起来可以做一个很实用的个人知识助手。思路是把 Obsidian 笔记库作为知识库来源让 Agent 在回答问题时优先检索自己的笔记再把 Wiki 站点作为连接器让 Agent 能拉取团队资料。这个场景的关键在于知识库的组织方式。我在前文提过全量上传笔记会出现检索片段破碎的问题我的解决方案是按照主题建多个知识库并在指令里给 Agent 一个“路由判断”先判断问题属于哪个主题再去对应知识库检索。这样回答的质量会有明显提升。另外可以考虑给这个知识助手加一个“回答格式模板”比如要求它回答时先给结论再给引用来源。这样当你需要回头验证 Agent 给的信息是否是笔记里的原意时可以直接对照来源而不是凭印象判断。6.3 参加 OPC 认证把工具变成可交付的服务腾讯围绕 WorkBuddy 效率智能体推出了 OPC 从业者认证这件事对个人开发者的意义我觉得不只是一个证书而是给“个人开发的智能体应用”提供了一个服务化的通道。通过认证和平台规则个人开发者可以把打磨好的 Agent 应用以更正式的方式提供给团队或外部用户使用。这意味着你的能力边界可以从“自己写给自己用”延伸到“开发一个服务给别人用”对应的是一整套新的交付标准应用稳定性、权限边界、异常处理、文档说明都要跟上。如果往这个方向走我有几点建议从一开始就按“可交付”的标准做应用工作流里补全异常分支、失败重试、日志记录。严格遵守平台的权限和合规要求个人应用不要过度收集用户数据。内容发布前做好敏感信息过滤应用涉及的指令、示例、知识库内容都要符合公序良俗和平台规范。我在实际使用中的体会是Agent 应用的开发跟传统软件开发有一个很不一样的地方它不需要你一开始就把所有边界都定义完美而是可以先做一个最小闭环让它跑起来再通过日志和真实反馈一点点调优。不要怕第一版“笨”怕的是第一版跑不起来、跑起来了你又不知道它为什么这么干。最后再分享一个我每次都会用的小技巧任何 Agent 应用上线前把它的运行日志打开到详细级别连续观察三天。第一天的日志会让你发现“它做了什么你以为没做的事”第二天的日志会让你发现“同样的任务它两次的处理方式竟然不一样”第三天的日志就能让你找到稳定复现的那个问题了。把这个问题修掉你的 Agent 应用才算真正可以从“玩具”变成“工具”。