先说个现象。很多人装完 WorkBuddy 之后的第一周，基本就是问它几个问题、让它帮忙写个周报，然后就没有然后了。不是它不行，是你根本还没把它"接"到你的工作里。我常打一个比方：刚装好的 WorkBuddy 就像一台没插网线、没装驱动的电脑，摆在桌上挺好看，但干不了活。真正让这类效率智能体从玩具变成工具的分界线，就是"连接"——连上模型、连上文件、连上你的历史记忆、连上钉钉、连上知识库、连上那些定时脚本。
这一篇是《WorkBuddy 实战蓝皮书》的第三篇，前两篇分别讲的是安装环境准备和基础上手操作，这篇专门处理"连接"。顺便回应两个网上经常看到的问题：一是 WorkBuddy 和 CodeBuddy 到底啥区别，二是有个热梗问"WorkBuddy 就是小龙虾吗"——那纯属圈子里开玩笑的称呼，不用太当真，真正值钱的是它背后那套连接架构。下面我把这几个月实际部署、排障、搭自动化流程的经验全部拆开讲。
1. "连接"到底连的是什么：拆开 WorkBuddy 的四种连接能力
1.1 为什么很多人用不起来：差的就是连接密度
我见过太多人把 WorkBuddy 当成一个"更聪明的聊天框"来用。问它"帮我写个会议纪要模板"，它写得确实不错，然后呢？没了。下周一开会你还是手动开录音、手动整理、手动发到群里。这就是典型的"能对话但没连接"。
WorkBuddy 的定位从来不是聊天机器人，而是一个工作台。工作台意味着它要跟你的真实工作环境发生交互：读你指定的文件夹、查你团队的知识库、调你多维表里的数据、到点给你推送消息。每接通一条线，它的实用价值就翻一倍。我把这种能力拆成四层，后面所有操作都是围绕这四层展开的。
1.2 第一层连接：模型通道
WorkBuddy 本身不生产智能，它需要背后接一个大模型的 API 或本地模型服务。这是最底层、也是最先要打通的一条连接。这条线断了，上面所有功能都是空中楼阁。很多网络连接失败、启动卡住的问题，根源都在这层。
1.3 第二层连接：上下文
所谓上下文连接，就是让 AI 在动手之前能拿到它需要的"背景资料"。包括历史对话记录、本地记忆、知识库文档、你授权的文件夹内容。没有这层连接，它只能靠模型自身的通用知识回答你，那跟你用网页版有什么区别？有了这层连接，它才知道你上周讨论到什么程度、你团队的项目代号是什么、你惯用的周报格式长什么样。
1.4 第三层连接：外部系统工具
这是"连接篇"里最重头的部分。包括钉钉多维表定期同步、定时发送微信消息、调用内部 wiki 接口、跑定时脚本、对接网页版的 Webhook 等等。这层连接解决的是"AI 说了话之后，谁来执行"的问题。我后面会专门讲这几个场景的落地配置。
1.5 第四层连接：开发者生态
WorkBuddy 有开发者平台，也提供网页版和本地版。这一层面向的是有开发能力的人：通过 API 把 WorkBuddy 嵌入你自己的系统，或者通过 Webhook 让别人调用你封装好的技能。到这一步，它就不再只是一个客户端工具，而是你自动化体系里的一个"大脑节点"。
1.6 顺带说清 WorkBuddy 和 CodeBuddy 的分工
这个问题在网上被反复问。从我实际使用的体感来说，CodeBuddy 主攻代码场景，更像一个坐在你旁边的结对编程助手，你给它看代码、让它补全、让它解释报错，它的主战场是 IDE 和代码仓库。WorkBuddy 主攻工作流场景，它关心的不是某一段代码，而是"这个任务由哪些步骤组成、每一步需要调什么资源、最后结果怎么推给你"。简单说，一个面向码代码的过程，一个面向跑通业务的过程。两者有重叠，但发力点不同。
2. 跑通环境连接：从本地部署到模型通道配置
2.1 网页版、Linux 版、本地部署怎么选
很多人的第一个问题是：我到底该用网页版，还是老老实实在自己机器上装一个？我的建议很直接：想拿它当玩具，用网页版；想拿它当生产力工具，必须本地部署。
网页版的优势是零门槛，浏览器打开就能用，官方帮你维护模型通道和存储，适合体验功能。但它的局限性也很明显：定时任务、文件夹访问这类"连接能力"会受到托管环境的限制，比如它没法直接读你公司内网的多维表，也没法在你没打开浏览器的时候帮你执行定时任务。
Linux 版和本地部署适合真正的重度用户。我自己就在 Ubuntu 服务器上部署了一套，用容器方式跑，好处有三个：第一，数据不出内网，公司敏感资料不会经过第三方托管链路；第二，可以直连内网里的各个系统，比如企业微信机器人、内部 wiki、数据库；第三，可以设置 crontab 级别的调度，真正做到"7×24 小时待命"。
注意，网上有人问"WorkBuddy 启动非常慢怎么办"，大部分情况是因为本地部署时首次启动要校验模型文件、初始化技能索引。如果你机器性能一般，第一次启动等三五分钟是正常的，第二次启动会快很多。
2.2 模型通道配置的实操细节
无论你选哪种部署方式，模型通道配置都是避不开的一步。我以本地部署为例，配置一般集中在config.toml或环境变量里。核心就三件事：模型服务地址、API Key、模型名称。
[model] provider = "openai-compatible" # 也可能填 vllm / ollama / 官方通道 base_url = "http://127.0.0.1:8000/v1" api_key = "sk-你的密钥" model_name = "qwen2.5-32b-instruct" temperature = 0.3这段配置里最容易出问题的三个点，我逐个说：
- base_url 填错。很多人会漏掉后面的
/v1后缀，导致握手失败。大多数兼容 OpenAI 协议的服务都要求 URL 最后带/v1。 - model_name 和实际服务不匹配。你本地部署的模型可能叫
qwen2.5-32b-instruct，但服务端注册名可能带了时间戳或版本号。先用curl http://127.0.0.1:8000/v1/models查一下真实返回的模型 ID，再填到配置里。 - api_key 权限不足。有些网关服务支持多 Key 多权限，如果你的 Key 只开了"只读"权限，模型调用会被拒。确保 Key 至少具备
model:invoke权限。
2.3 网络连接失败的完整排查链路：以 3002 错误为例
网上搜 WorkBuddy 时，"workbuddy 网络连接失败 3002"是高频词。我自己的服务器也出过这个错误码，这里把完整排查链路写出来，下次你遇到可以直接照做。
3002 这个错误码，按官方文档和我实际抓包的经验，属于网络通道建立失败，也就是客户端和服务端之间的 TCP/TLS 链路没有正常建立。常见原因按优先级排序如下：
- DNS 解析失败。别笑，这是最高频的。先执行
nslookup your.workbuddy.endpoint或dig看能不能解析出 IP。如果内网 DNS 没有放行这个域名，就会报 3002。 - 端口不通。默认 HTTPS 走 443，但如果你配了自建网关用了非标端口，要检查防火墙。用
telnet your-host 443或者nc -vz your-host 443验证。 - SSL/TLS 证书问题。自建服务经常用自签证书，WorkBuddy 客户端默认会校验证书链。如果是内网测试环境，可以在客户端配置里把
verify_ssl临时设为false先跑通，但生产环境不建议这么干。 - 超时设置太短。如果你的模型服务在远端，推理响应时间本身就长，客户端默认连接超时可能不够。把超时从默认 30 秒调到 120 秒再试。
我实际遇到 3002 那次，最后定位到是公司内网网关策略阻止了客户端访问外部的模型 API 地址。因为客户端配置里写了外网模型服务地址，而服务器所在网段只允许白名单域名出网。解决办法是把模型服务地址改成内网部署的模型网关。整个排查过程大约半小时，但如果没有这套链路，很容易在配置层面反复折腾。
提示：遇到网络类报错，先别急着改配置。按"域名解析 → 端口连通 → 证书校验 → 超时设置 → 访问策略"的顺序逐层排查，比瞎猜高效得多。
2.4 启动非常慢的两个真正原因
很多人启动 WorkBuddy 时卡在启动界面，然后就去网上搜"workbuddy 启动非常慢"。我拆过启动日志，慢通常出在两个环节：
第一是模型元数据加载。如果配置里连的是远端模型网关，启动时客户端会去拉取模型列表、校验模型可用性。如果网关响应慢或网络有延迟，启动就会卡。解决办法是在配置里手动指定model_name，跳过模型列表拉取。
第二是技能和插件初始化。WorkBuddy 启动时会扫描技能目录，为每个 Skill 建立索引。如果你塞了几十个第三方技能，每个技能都带描述文件和脚本，索引构建时间会显著拉长。优化方式是精简技能数量，把不常用的技能移到备份目录，启动时就不会被扫描。
3. 连接私有数据：记忆迁移、文件夹权限与知识库接入
3.1 历史对话记录和本地记忆迁移
用了一段时间之后，WorkBuddy 会积累一批很有价值的资产：历史对话记录和本地记忆。这些东西相当于 AI 的"工作经验"，换机器如果不迁移，你就等于把老员工开除了。
本地部署的话，对话记录一般以 SQLite 或 JSONL 的形式存在数据目录里。迁移三步走：
- 找到数据目录，整体打包备份。以我 Ubuntu 上的安装路径为例，一般在
~/.workbuddy/或你自定义的WORKBUDDY_DATA环境变量指向的目录。 - 在新机器上安装相同版本，先把数据目录解压过去，再启动服务。注意版本差异，尽量大版本一致，避免数据库结构不兼容。
- 启动后进入设置页，检查"记忆"和"历史会话"是否还在。如果发现技能引用失效，多半是因为记忆里记录了旧机器的绝对路径，需要重新授权。
有个细节：迁移后一定要重新检查文件夹授权范围。记忆里那些技能引用的路径在新机器上可能不存在，或者权限配置被重置了。我迁移过一次，workbuddy 能想起来我之前的对话，但每次执行读取文件夹操作都说"无权限"，排查了半天才发现是新机器的工作目录没加进授权列表。
3.2 访问文件夹范围设置：给 AI 划定物理边界
WorkBuddy 访问你本机文件不是无限制的，它需要你显式授权哪些目录可以被读取。这既是安全设计，也是效率设计。
设置路径通常是：设置 → 权限 → 文件夹访问范围 → 添加允许访问的目录。你要遵循的是最小权限原则：它干活需要读哪些目录，就给哪些目录。比如它要帮你整理周报，那就只授权~/Documents/reports和~/Projects/team-share，不要图省事直接把整个 home 目录授权了。
为什么这么强调？两个原因。一是安全，WorkBuddy 的技能可以调用脚本执行命令，如果一个第三方技能被诱导去读你的私钥目录，危害很大。二是效率，授权目录太广会导致技能搜索文件时被大量无关文件淹没，上下文里塞满垃圾，回答质量反而下降。
我在网上看到有人问"workbuddy 如何设置访问文件夹范围"，实际上官方文档里有明确说明，设置完会生成一个权限清单。我建议你定期检查这份清单，把不再需要的目录移除。
3.3 把 WeKnora 这类开源知识检索组件接进来
团队内部知识库的接入，是 WorkBuddy 从"个人助手"变成"团队助手"的关键一步。我在生产环境用的是开源知识库问答组件WeKnora来做多源知识检索，然后把它接进 WorkBuddy。
简单说，WeKnora 这类组件做的事情是：把你的 wiki 页面、内部网页、离线文档抓取下来，做切片和向量化，然后提供一个检索接口。WorkBuddy 本身不需要知道文档存在哪，它只需要在回答问题时先去 WeKnora 检索相关内容，把命中片段作为上下文，再组织答案。
接入思路不复杂，核心是把 WeKnora 封装成 WorkBuddy 可调用的一个工具。它的检索 API 一般是标准 HTTP 接口，示例请求如下：
curl -X POST "http://your-weknora-host/api/search" \ -H "Content-Type: application/json" \ -d '{ "query": "项目周报模板口径", "top_k": 5 }'返回结果通常是文档片段和相似度分数。你可以写一个几十行的 Python 脚本，把这个检索能力封装成 WorkBuddy 的 Skill（后面第五章会讲具体怎么封装），让模型在回答前先调一次检索，再基于检索结果组织答案。
这样做的好处是立竿见影的：原来你问它"我们团队的周报模板是什么"，它只能瞎编；现在它能从你们的 wiki 里把真实模板捞出来给你。生成式 AI 最怕一本正经地胡说八道，接上知识库检索就是最好的纠偏手段。
3.4 LLM wiki 的落地用法
"workbuddy llm wiki"也是热搜词之一。所谓 LLM wiki，我理解就是"给大模型看的知识库"，跟给人看的 wiki 不同，它的写作方式要更适合被检索和切片。
实践中我的建议是：把团队规范、操作手册、常用口径统一沉淀成 wiki 页面，每个页面标题要清晰，正文第一段就给出结论，然后才是细节。比如"周报模板.md"的开头直接写"标准周报包含：上周总结、本周计划、风险项三个板块"，而不是先铺垫一堆背景。
接入节奏分三步：
- 先把最高频的 20~30 个页面做结构化整理，覆盖常用模板、命令手册、业务流程。
- 让 WeKnora（或你选的检索组件）抓取并建索引。
- 在 WorkBuddy 里建一个"知识库检索 + 回答"的 Skill，测试检索命中率。
注意：知识库不是一次建完就完事的。我每两周会让爬虫重新抓一次 wiki，不然新更新内容永远检索不到。很多团队接入知识库后觉得"不好用"，八成是索引停在两周前。
4. 连接外部系统：钉钉多维表、定时微信消息与开发者 API
4.1 钉钉多维表的定期同步：用连接器替代手工搬运
我在团队里用得最频繁的连接场景，就是让 WorkBuddy 每天自动同步钉钉多维表里的项目数据。以前的做法是每天上班第一件事，打开多维表导出 Excel，再把关键数字粘到汇报文档里。现在这个动作完全交给了 WorkBuddy。
实现思路是：通过 WorkBuddy 的连接器配置钉钉多维表的访问凭证，然后用定时任务触发同步。
连接器配置核心参数包括：
app_key和app_secret（钉钉开放平台的凭证）base_id（多维表工作台 ID）table_id（具体数据表 ID）sync_mode（全量同步 or 增量同步）
定时同步的配置我用的是标准的 cron 表达式。比如每个工作日上午 9 点同步一次：
0 9 * * 1-5有一点必须强调：定时任务执行的前提是你的 WorkBuddy 服务端一直开着。很多人在网页版上配置了定时任务，然后关掉浏览器，以为任务会照常执行——不会的。所以生产环境的定时任务一定要挂在本地部署的服务上。
实测下来，增量同步比全量同步稳定得多。全量同步每次要拉整张表，数据量大时容易超时，而且会占用大量 token。增量同步依赖多维表的modified_at字段，只拉取最近变更的数据，既快又省。
4.2 定时发送微信消息的实现方式与注意点
"workbuddy 定时发送微信消息"这个需求非常普遍，但我必须先泼一盆冷水：不要直接做个人微信的自动定时发送。个人微信的自动化存在风控风险，轻则消息发不出去，重则账号被限制，把关键业务流程挂在个人微信自动化上极不明智。
正确姿势是走企业微信机器人 Webhook。在群里添加一个自定义机器人，拿到 Webhook 地址之后，任何程序都可以往这个地址 POST 一段 JSON，实现消息推送。示例脚本如下：
import requests import json webhook_url = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的机器人key" def push(title, content): data = { "msgtype": "markdown", "markdown": { "content": f"## {title}\n\n{content}" } } resp = requests.post(webhook_url, data=json.dumps(data), headers={"Content-Type": "application/json"}) return resp.json() if __name__ == "__main__": push("每日早报", "1. 本周项目A进度正常\n2. 项目B有风险")然后把这段脚本交给 WorkBuddy 的定时任务调度。每天上午 8 点 50 分，它会先去查多维表数据、去知识库检索口径，再把这几个数据源的内容拼成一条早报推送到群里。整个过程不需要任何人手动参与。
注意：企业微信机器人 Webhook 有频率限制，官方建议每 20 秒最多 20 条消息。正常办公场景根本用不满，但如果你的脚本在循环里疯狂推送，会被限流甚至封掉 Webhook。
4.3 开发者平台与网页版的 API 化：把 WorkBuddy 当服务用
WorkBuddy 除了交互界面，还提供了开发者平台。这意味着你可以在自己的代码里调用 WorkBuddy 的能力，而不只是打开界面跟它聊。这层连接适合有一定开发能力的用户，我列几个典型用法：
- 内部系统触发某个事件时，自动让 WorkBuddy 生成一份报告。
- 你的网页后端接入 WorkBuddy 的会话 API，把 AI 能力集成进自己的产品。
- 通过 Webhook 接收 WorkBuddy 技能执行完毕的回调，做后续联动。
最简单的 API 调用方式是先获取 access_token，然后用标准 HTTP 请求创建会话、发送消息。示例：
import requests token_url = "https://your-workbuddy-host/api/v1/auth/token" session_url = "https://your-workbuddy-host/api/v1/sessions" # 获取 token token_resp = requests.post(token_url, json={"api_key": "your-api-key"}) token = token_resp.json()["access_token"] # 创建会话并发送消息 headers = {"Authorization": f"Bearer {token}"} session_resp = requests.post(session_url, headers=headers, json={"name": "自动报告生成"}) session_id = session_resp.json()["id"] msg_resp = requests.post(f"{session_url}/{session_id}/messages", headers=headers, json={ "content": "请根据最近一周的多维表数据生成项目周报" }) print(msg_resp.json())有开发能力的读者应该已经感觉到了，这一步把 WorkBuddy 从一个"工具"变成了"平台能力"。我的实际感受是，当你能在自己的代码里调用它的时候，自动化方案的设计空间一下子大了很多。
4.4 一个综合工作流示例：从数据到消息的全链路
前面几节讲的都是单个连接，这一节我把它们串起来，看一个真实在跑的全链路工作流。场景：每天早上给团队推送一份"项目健康早报"。
整个流程分三步：
第一步，触发器。用 cron 在每天早上 08:50 触发daily_health_report技能。
第二步，处理逻辑。技能执行三件事：
- 调用钉钉多维表连接器，拉取最近一天更新的项目进度数据；
- 调用 WeKnora 知识库检索，获取团队定义的风险判定口径（比如"延期超过 3 天视为高风险"）；
- 把数据交给大模型，按口径生成结构化早报。
第三步，输出。调用企业微信机器人 Webhook 推送早报，同时写入一份 JSON 日志，方便以后追溯。
这个工作流的好处是：每一个环节单独拎出来都不难，但连起来之后就形成了自动化闭环。AI 的决策判断（什么是风险、怎么描述进度）、外部系统的数据（多维表）、知识库的口径判断（判定标准）、消息触达（企业微信）四条线通过 WorkBuddy 串在一起。这比我之前用的纯脚本方案灵活得多，因为业务口径变化时，我只需要改 wiki 里的口径文档，不需要改代码逻辑。
5. 把连接沉淀成 Skill：自定义指令推荐与封装思路
5.1 Skill 的本质：不是提示词，是可复用的小型自动化单元
很多人以为 WorkBuddy 的 Skill 就是一段精心设计的提示词，这是最大的误解。真正好用的 Skill 是"提示词 + 脚本 + 参数约定"的组合体，它把"让 AI 干活"这件事标准化成可复用的自动化单元。
一个标准 Skill 的目录结构大致是这样：
daily_report/ ├── SKILL.md ├── scripts/ │ ├── fetch_data.py │ └── push_msg.py └── assets/ └── template.mdSKILL.md：描述这个技能是做什么的、输入参数有哪些、执行流程是什么。scripts/：放实际的可执行脚本，比如拉数据的、推消息的。assets/：放模板和静态资源。
为什么推荐把脚本独立出来而不是塞在提示词里？因为脚本可以做校验、重试和幂等处理。比如拉取多维表数据时，网络抖动导致拉取失败，脚本里可以自动重试三次；推送消息之前，脚本可以先校验消息长度、检查必填字段。这些能力是纯提示词做不到的。
5.2 几个实测好用的 Skill 方向
我根据自己的使用场景，整理了下面这几个值得优先做的 Skill，供你参考：
| Skill 名称 | 输入 | 输出 | 关键参数 |
|---|---|---|---|
| 周报生成器 | 时间段、项目名 | 结构化周报文本 | 数据来源、模板路径 |
| 会议纪要整理 | 音频转写文本 | 决议 + 待办清单 | 输出模板、待办提取规则 |
| 多维表周汇总 | 表 ID、统计维度 | 汇总报告 | 维度字段、对比周期 |
| 知识库问答 | 用户问题 | 带引用的回答 | 检索组件地址、top_k |
以"会议纪要整理"为例，以前是开完会手动把录音丢给工具转文字，再手动总结，再手动提炼待办。做成 Skill 之后，只需把转写文本丢给它，输出就是格式统一的"会议决议 + 待办 + 负责人"。这不是能力上的飞跃，但节省的重复劳动非常可观。
5.3 手写一个 Skill 的完整示例
这里我演示如何把前面"钉钉多维表同步 + 企业微信推送"封装成一个 Skill。新建daily_report目录，先写 SKILL.md：
# Daily Report Skill ## 用途 每天定时生成项目进度早报，并推送到企业微信群。 ## 输入参数 - project_ids: 项目 ID 列表 - push_url: 企业微信机器人 Webhook 地址 ## 执行流程 1. 调用 scripts/fetch_data.py 拉取多维表数据 2. 调用 scripts/push_msg.py 把报告推送到企业微信再写scripts/push_msg.py，伪代码如下：
import sys import json import requests def build_markdown(data): lines = ["## 今日项目早报", ""] for project in data: lines.append(f"- **{project['name']}**: {project['status']}") return "\n".join(lines) def push(webhook, content): payload = {"msgtype": "markdown", "markdown": {"content": content}} resp = requests.post(webhook, json=payload, timeout=10) resp.raise_for_status() if __name__ == "__main__": input_data = json.loads(sys.stdin.read()) markdown = build_markdown(input_data["projects"]) push(input_data["push_url"], markdown)关键点是：Skill 的输入输出要尽量结构化。SKILL.md 里明确输入参数，脚本处理具体格式转换，这样同一个 Skill 可以复用到不同群、不同项目的场景。
5.4 编写自定义指令时最容易踩的三个坑
第一，指令太宽泛。如果你写的是"生成项目周报"五个字，AI 就不知道用哪个模板、参考哪些数据、推给谁。一定要把数据来源、模板路径、输出目的地写清楚。
第二，没给失败出口。Skill 执行过程中一定会遇到异常，比如多维表接口超时、webhook 被限流。好的 Skill 必须定义"失败时怎么办"，要么重试、要么降级为邮件通知、要么写到错误日志。没有失败处理的 Skill 在生产环境就是定时炸弹。
第三，忘了权限配置。前文反复强调过，Skill 能访问哪些目录、能执行哪些系统命令，都受权限配置约束。如果你写了一个 Skill，但它的脚本需要读取一个未授权目录，执行就会失败。所以在写好 Skill 后，第一件事就是确认它的目录访问范围。
6. 我实际踩过的连接坑：一份排障笔记
6.1 网络类问题的表现与处理
除了前文说的 3002 网络通道建立失败，还有几个高频错误：
- 401 Unauthorized：API Key 错误或已过期。先检查环境变量是否生效，再检查 Key 是否还有额度。
- 403 Forbidden：Key 有权限但操作被禁止，常见于调用了未授权的 API 接口。去开发者平台确认这个 Key 绑定的权限范围。
- 模型名不存在：服务端返回 404 或者模型列表里找不到你配置的名字。按我前面说的，先用 curl 拉一遍模型列表核对。
- 超时：模型推理时间超过客户端超时阈值。优先调大超时时间，同时检查模型服务本身负载是否过高。
6.2 文件夹授权过小导致的"技能失效"
有一次我配置了一个知识库同步 Skill，运行时报"找不到文件"。我看路径也没问题，权限清单里也加了目录。后来才发现，我授权的是~/wiki目录，但 Skill 的脚本以 systemd 服务身份运行时，HOME环境变量指向的是/root，导致脚本实际解析出的路径是/root/wiki，而不是我以为的/home/user/wiki。
这个坑非常隐蔽。解决办法有两个：一是全部使用绝对路径；二是在脚本里显式设置HOME环境变量，而不是依赖系统默认值。
6.3 钉钉多维表同步时的字段类型问题
钉钉多维表的字段类型改动会静默影响同步结果。比如某个字段原来存的是数字，后来有人把字段类型改成文本，同步脚本如果直接做数值计算就会报错，而且这个错误不是每次都出现，只在数据变更时触发。
我现在的做法是：在同步脚本里加一层字段类型校验，发现类型不匹配就先记录告警，而不是直接让任务失败。这样至少能保证群里准时收到消息，只是内容里会带上"数据源字段类型异常"的提示。
6.4 记忆迁移后的路径引用失效
前面提过记忆迁移。这里再补一个具体案例：迁移后，我的"周报生成器" Skill 一直报"没权限访问目录"。排查下来发现，记忆里记录的是旧机器上的路径/home/olduser/reports，新机器实际路径是/home/newuser/reports。WorkBuddy 的权限粒度是基于路径的，旧路径不在授权清单里，自然被拒绝。
在语言层面做一次批量替换：把记忆导出文件里的旧路径全局替换成新路径，或者干脆清掉与该 Skill 相关的旧记忆，让它重新学习一次。我更推荐后者，因为记忆里混杂了太多环境相关的内容，与其逐个修，不如让它重新积累。
6.5 给新手的"三天连接上车"清单
如果你也想把 WorkBuddy 从聊天框变成生产力工具，我建议按这个顺序动手：
- 第一天：先搞定模型通道配置，确保能正常对话；然后把常用的文档目录加进文件夹访问范围。
- 第二天：配置历史对话记录和记忆存储的位置；找一个内部 wiki 页面，接一个检索组件测试知识库问答。
- 第三天：配置第一个外部连接：企业微信 Webhook 推送；再做一个最简单的定时任务（比如每天早上推一条消息），验证全套链路。
按这个顺序走，三天后你就拥有一个能读本地文件、能查团队知识、能定时推送消息的工作台了。别一上来就追求复杂，连接这个东西，通了第一条，后面的路自然会越走越宽。我在真实环境里踩过的坑基本都写在上面了，希望你能绕开。
