从插件到办公助手:WorkBuddy 的四年演化路

你手机或电脑上刚装上 WorkBuddy，打开一看，5.6 版本，界面挺新，功能挺全。很多人会下意识觉得：这是个新出的 AI 办公软件吧。

它确实是个新壳，2026 年 5 月才露面，还不到一岁。但壳里头那颗 Agent 内核，从 2022 年的补全插件算起，已经悄悄积累了四年。这篇就讲讲，这颗内核是怎么一步步长出来的，也就是从插件到今天这个办公助手，这四年到底经历了什么。

先说一个诚实的前提。WorkBuddy 是闭源软件，没有公开的 git 仓库，你没法像看开源项目那样翻它的提交历史。它官方唯一公开的时间线，是一份 Changelog 文档，最早的版本记录停在 4.24.0，时间大概在 2026 年 5 月下旬。

那怎么还原它的来龙去脉？我有三件一手证据，它们彼此印证，像化石一样把演化路径留了下来。

第一件，三套独立的版本计数器。同一家公司的三个产品，版本号各走各的：CodeBuddy IDE 走 4.x，命令行版走 2.x，WorkBuddy 走 5.x。版本号不统一，通常意味着它们是三个独立的发布体，各有各的节奏。

第二件，一个共同的内部代号 genie。这个代号同时在三处出现：CodeBuddy IDE 里那个 genie 内核扩展、WorkBuddy 安装包的包名、还有 CodeBuddy 的扩展目录。同一个代号出现在三个壳里，背后是同一个平台团队。

第三件，数据目录的同构，外加一个断链的符号链接彩蛋。三个产品在本机的存储目录骨架几乎一样，WorkBuddy 是超集。更直白的痕迹是，~/.codebuddy/bin/ 底下有个叫 workbuddy 的符号链接，指向一个根本不存在的 VS Code 式路径，链接早就断了。这种装过又没装干净的残留，是安装器同源的铁证。

把这三件证据拼起来，一条演化主线就清楚了。

时间回到 2022 年，AI 云爆发。腾讯的第一步，选了最省力的形态：插件。做代码补全，不碰本地执行，架构就是「编辑器插件、API 网关、模型」三层。

2023 年，腾讯云 AI 代码助手上线，进 VS Code 和 JetBrains 的插件市场。到 2024 年 1 月，插件做到 1.6.0，已经能对话、能用 @workspace 拉起 Agent、支持国际化、支持 iOA 登录和私有化部署。这里埋下了一颗种子：腾讯云登录和 iOA 登录双轨并存，后来长成了 WorkBuddy 的五轨发布体系。

插件这条路，很快就撞上三堵墙。补全是红海，竞争激烈；插件寄人篱下，改不了宿主的骨架，想让 AI 自己执行命令，插件形态也撑不住；更要命的是 Agent 浪潮起来了，Cursor 起势，Claude Code 问世，光补全已经不够看。

腾讯的应对是两步。第一步，在插件里做 Craft 开发智能体，让它能懂工程、能生成多文件项目，这是 Agent 内核的雏形。第二步，也是最关键的一步，立项把 Agent 能力从界面里抽出来，做成一套独立的平台层，内部代号就是前面说的 genie。2025 年 2 月，英文品牌 CodeBuddy 发布，内核已经能脱离界面独立服务多个前端。

这个「内核和界面分离」的决策，是整个演化史的拱心石。后面所有故事，都建立在这块基石上。

到了 2025 年，CodeBuddy IDE 发布，7 月 22 日内测全网宣传。为什么要去 fork 一个 VS Code，而不是继续做插件？腾讯云的人说得很直白：插件没法提供一站式用户体验。当目标升级成产设研一体化工作台，要深度改编辑器骨架，插件形态就不够用了。fork 还有一个现实好处，LSP、调试器、一百多个内置扩展、open-vsx 市场，全都能直接拿来用。

我本机装着的 CodeBuddy 4.12.1，就是 VS Code 基线 1.106.1 加上 genie 内核作为内置扩展。也正是在这一幕，国内版和国际版的双变体定型：国际版接 Claude、GPT、Gemini，国内版接混元和 DeepSeek。

2025 年底到 2026 年初，腾讯做了另一件事：把那个 Agent 内核抽成没有界面的命令行版，也就是 codebuddy-code，版本走 2.x。官方说法是，命令行版已经在腾讯内部吃过狗粮，适合塞进研发流水线，批量生成代码、跨项目重构。

命令行版没有界面包袱，迭代最快，成了内核新能力的首发渠道。一个规律从此刻进发布流程：命令行版先行，各个壳再跟上。比如同一时期，命令行版已经 2.158，而 WorkBuddy 内置的还停在 2.147，差了大约三周。

2026 年 5 月下旬，WorkBuddy 的 Changelog 从 4.24.0 开始。有意思的是，它一上来就有沙箱、MCP、专家体系、本地数据库，完全没有从零搭建的痕迹。因为它本来就不是新项目，而是一个新壳加上成熟内核。

它的做法是：命令行版作为常驻子进程，配上一个自研的 Electron 办公壳，中间用 ACP 协议连接。于是它用四个月发了三十多个版本，走完了别家通常要两年的路。6 月 3 日上了 5.0 的团队协作，6 月 13 日加了微信支付和安全中心，7 到 8 月加深了企微助理和腾讯文档集成，9 月做到 5.6 的应用管理和平台化。

为什么要自研壳，而不是继续 fork VS Code？因为目标用户从开发者变成了所有人，办公场景早已跳出了编辑器的框架，VS Code 那一套生态资产在办公壳里全成了用不上的包袱。但 Agent 内核经过 ACP 原样复用。一句话区别：IDE 壳把内核当扩展嵌进去，WorkBuddy 把内核当子进程拉起来。

故事到 2026 年 9 月进入收口期。9 月 20 日和 21 日，CodeBuddy 和 WorkBuddy 同周发版。CodeBuddy 4.12.1 明确写了项目记忆的存储位置和格式，与命令行版保持一致，说明三个壳的数据格式正在合并。WorkBuddy 的发布轨道也从最早的两轨，长成了 SaaS、cloudhosted、selfhosted、internal、ioa 五轨。这五条不是随便分的，每一条对应一类分发对象。

SaaS 是默认轨，给公网所有普通用户，全量遥测加积分计费。cloudhosted 是腾讯云托管轨，给云上租户。selfhosted 是私有化部署轨，给企业把数据留在自己机房，模型都换成自家的。internal 是腾讯内部员工轨，内测功能从这里先放。ioa 是零信任企业环境轨，前面单独讲过，带防泄密管控。

为什么是这五条而不是三条四条？因为它要同时伺候五种完全不同的人：最广的公网用户、云租户、怕数据出机房的大企业、腾讯自己人、走零信任体系的客户。需求各不相同，只能一个环境一套配置。

这五轨是怎么发出来的？关键在前面那篇讲过的那句话：一次构建，两次配置。考古实测发现，五份配置文件是补丁叠加的关系，只有一份基础配置是全量的，另外四份只覆盖少数字段，运行时再合并。换成大白话，底层是同一套代码，按部署环境裁剪遥测、计费、模型和功能开关。这也是为什么插件时代埋下的腾讯云登录和 iOA 登录双轨，最终长成了今天这张五轨分发矩阵。

这五轨里，ioa 最特殊，值得多说两句，因为它正是序章那颗种子长成的结果。

iOA 是腾讯自研的零信任办公安全平台。它的核心理念是别再假设内网里的人就安全，改成每次访问都验证身份和设备是否合规，让应用对外隐身、权限只给最小范围，用来替代传统 VPN。iOA 登录，指的是用户拿企业的 iOA 身份来登录 AI 助手，和腾讯云登录是平行的另一套身份通道。

为什么插件时代的第一版（1.6.0）就要支持 iOA 登录和私有化部署？因为腾讯自己的员工就走 iOA 身份，企业客户又要求走零信任内网，AI 助手进不了传统内网就进不了大公司。也就是说，iOA 登录不是后来补的功能，是 B 端基因里自带的入场券。它的重要性在于，这是 Agent 客户端打入大企业的安全准入前提。只有被零信任体系接纳，企业才敢让一个能读文件、跑命令的 Agent 碰自己的敏感数据。所以 iOA 轨道会单独做合规管控，比如日志上传只在 iOA 环境开启，图片处理技能在 iOA 环境禁用，都是防泄密用的。当年那颗种子，如今长成了完整的企业分发体系。

讲到这里，得补一笔代价。WorkBuddy 选了本地优先：会话元数据先存在你电脑本地的库里，再向云端推增量。这个选法很稳，隐私和离线都占优，但带来一个必然后果，就是跨设备同步。你在一台电脑开的会话，换台设备要能接着聊，就得有人把本地会话和云端会话一一对上号。干这件事的，就是 edge-sync 这套跨设备映射库，它本质是一张桥。

这张桥把本地会话编号对上云端会话频道，把本地图片编号对上腾讯云上的文件地址。实测发现，映射库在四个月里滚动轮换了四代：v1 活到 8 月 12 日，v2 到 8 月 31 日，v3 到 9 月 16 日，v4 从 8 月 31 日用到现在，库里还躺着 487 条映射。每次轮换不是重写协议，而是同一套映射表按周期翻篇，目的是压住日志体积、定期重置同步代际。代价明摆着：Changelog 里跨设备同步这个毛病反复修，根子就在这张桥的维护上。这也就是本地优先架构交的那笔税。

回扣一下上一篇。上一篇讲 WorkBuddy 国内版和国际版是「一次构建，两次配置」，几乎是一个文件。那正是这套四年演化走到今天的最终形态：内核早就成熟，分版本只剩配置层面的事。

交流群

和我们一起探索

扫码加入