前两天，一位 Linkly AI 用户给我们分享了一个挺有意思的玩法。
他用 WorkBuddy 接上 Linkly AI，不到半小时，就在企业微信群里搭出了一个“企微同事”。
这个企微同事做的事情很具体：有人问产品问题，它会根据资料给出答案。
传播稿写完了，也可以先让它检查里面的产品描述。
事情不大，但过程极度丝滑。这位用户第一次具体感受到：团队 Agent 共用一套上下文，会带来什么变化。
下面，我们把他的搭建过程和真实使用体验分享给大家。
Part 1：Agent 时代，为什么我们还在当“人肉 API”？
我们的团队群里经常反复出现这些问题：
- “这个功能现在支持了吗？”
- “这篇稿子里的产品描述能帮忙看看吗？”
其实，很多答案都已经写在官网文档或团队知识库里。但遇到问题，大家还是会选择 @ 一下产品同学。
久而久之，产品同学就有点像公司里的人肉 API。资料明明早已数字化，真正被调用的知识接口却还是人。
Part 2：不重搭知识库，也能拥有知识库 Bot？
所以最近我一直在想：既然答案本来就在资料里，为什么不能直接问知识库 Bot？
这件事听起来并不新鲜。给 Bot 喂几份产品资料，再告诉它“你是公司的产品助手，请基于产品资料回答问题”，不就完成了吗？
但真准备做的时候，我才发现不太对。
一个产品经理之所以能回答这些问题，并不是因为他背过一份 FAQ，而是因为他拥有背后的整套工作上下文。
在实际工作中，上下文并不只在企业知识库里。产品文档、更新日志、会议记录，甚至研发过程中的技术文档、Agent 生成的分析结果，都可能成为回答问题时需要参考的信息。
这些资料往往还没来得及沉淀成正式知识库，却已经会影响当下的判断。
就在这个时候，我们看到 WorkBuddy 的 CLI 接通了。我突然想到：如果产品已经有自己的上下文，能不能让 Agent 直接读取这些资料，把它们作为 Bot 回答问题时的上下文？
于是我跑了一遍：Linkly AI + WorkBuddy + 企业微信。
结果不到半小时，就搭出了一个“企微同事”。
在这个场景里，Linkly AI 负责连接产品同学电脑里分散的资料，作为 WorkBuddy 的上下文层；WorkBuddy 则负责运行 Bot。
这样既不用把资料再复制进一个新的 Bot，也不会把知识库和某个特定 Agent 绑死。换模型、换工作台，资料仍然可以继续使用。
Part 3：半小时，用 Linkly AI + WorkBuddy 搭个企微同事
具体怎么接？一共三步。
第一步：在 Linkly AI 里接入本地文档
新建一个可共享的知识库，把需要的本地产品资料直接接进去，例如产品帮助文档、产品更新日志和产品博客；再一键推送到云端，供其他 Agent 一起使用。
第二步：把 Linkly AI 接入 WorkBuddy
直接把下面这句话交给 WorkBuddy：
请阅读
https://linkly.ai/docs/zh/agent-setup.md，引导我完成 Linkly AI 的安装与集成，并测试 WorkBuddy 是否可以读取指定的云端知识库。
第三步：把 WorkBuddy 接进企业微信
实际路径也很简单：打开 WorkBuddy → 助理模式 → 助理设置 → 集成企业微信 → 扫码登录 → 完成配置。
配置好 Bot 后，把它拉进群。前前后后不到半小时，群里就多了一个“产品同事”。
Part 4：为什么是 Linkly AI？
知识库 Bot 去年就已经多到看不过来了。
如果最后只是“问一句产品问题，它答一句”，我不会觉得这东西真正改变了什么。真正让我觉得它好用的，是传播稿审核。
当时有一篇准备发布的稿子，需要产品同学确认其中涉及功能的描述有没有问题。
正常流程应该是：品宣同学写完 → @ 产品 → 产品逐条检查 → 提出修改意见。
这一次，品宣同学没有先找产品，而是直接把整篇稿子交给了 Bot。Bot 对涉及产品的内容进行了逐条核对。后来产品同事又检查了一遍 Bot 的审核结果，没有发现问题。
就是这个瞬间，我们发现：当知识库真正进入工作流，它会非常好用。
很多人看到这里可能会问：企业微信本来就能接各种知识库，为什么还要再加一层 Linkly AI？
如果一个团队的资料本来就完整地存放在企微文档和微盘里，而且只准备在企微里使用一两个机器人，那么直接使用企微知识集，很可能已经足够了。确实没有必要为了使用 Linkly AI 再增加一层系统。
但我们遇到的情况不是这样。
产品团队的资料一部分在 GitHub 和本地项目目录里，一部分是 PDF、PPT、会议录音和历史版本；传播团队有自己的选题、文章、用户反馈和素材库。真正参与工作的文件，远比已经被整理进企微知识库的内容多。
这时，问题就变成了：为了让企微机器人知道这些内容，要不要把真实工作中的资料再搬一遍？
Linkly AI 在这个工作流中，主要解决了两个问题。
1. 不再为了接入 Agent，维护第二份资料
企微知识集很适合使用已经沉淀在企微文档里的内容。资料更新后，知识集也可以自动同步。
但如果团队的原始资料位于本地文件夹、GitHub 仓库、Obsidian、PDF、图片或音视频中，通常仍然需要上传、迁移或重新整理。于是团队会同时拥有两份资料：
- 一份是真正参与工作的源文件；
- 一份是为了让机器人读取而建立的知识库副本。
Agent 的参与原本是为了解决问题，却又额外增加了维护成本。
Linkly AI 恰好可以减少这部分工作。它会为本地文件夹建立 Agent 能读懂的索引地图。文件仍然保存在原来的位置；当文件发生变化，Linkly AI 会持续更新索引。Agent 在需要时，可以通过这份索引地图找到最新内容。
哪些文件可以接入，仍然需要人来判断；但 Linkly AI 可以减少重复上传、迁移和同步的工作。
2. 不只给企微机器人加知识库，而是让所有 Agent 共用一层上下文
企微知识集可以为企微里的 Bot 提供上下文。但今天，一个团队通常不会只使用一个 Agent：开发人员在用 Codex 或 Claude Code，市场人员可能在用 WorkBuddy。
每个人都在给自己的 Agent 上传文件、介绍背景。换一个新的 Agent，这些动作又要重来一遍。
如果团队上下文没有及时同步给 Agent，就很容易出现“每个人的 Agent 都在自说自话”的情况：开发 Agent 已经读到了新版本，市场 Agent 却还在根据旧资料写文案。最后，所有人还是回到群里，反复询问那个最了解产品的人。
接入 Linkly AI 后，团队里的每个 Agent 都可以调用同一个持续更新的云端知识库。
它带来两个直接好处：
- 减少重复喂上下文的成本；
- 减少信息不同步导致的 Agent 错误判断。
Part 5：下一次，先问 Bot
这次尝试最直接的改观是：
- 对传播同学来说，写完内容后可以先完成一轮自查，不必一直等待回复；
- 对产品同学来说，可以把时间留给真正需要判断的部分，不用反复解释同一件事。
下一次再遇到类似的问题，我们会先问 Bot。它找不到答案，再去找人。
AI Native 团队不一定一上来就是几十个 Agent 自己开会、自己决策。
它可能只是从一件很小的事情开始：以前必须 @ 一个人的地方，现在第一次可以不用 @ 他了。