四天前我把 Octop v1.0.2 装了一遍，写了一篇实测。当时在三处地方给了它差评：模型 key 明文存在 SQLite 里、权限只到角色模板这一层、没有云端协同。

10 月 25 日上午 11 点 36 分，v1.0.3b1 发出来了。这三处里有两处被直接补上，第三处是我自己写错了。

这不是「预判成功」的故事，反而是「我看得太浅」——它动手的速度比我下判断的速度快。所以这篇不重写原文，只讲增量：这四天它动了什么，哪几条旧判断要改，哪几条反而更结实了。

这四天，仓库变了多少

指标	10 月 22 日	10 月 26 日
最新版本	v1.0.2（10-18）	v1.0.3b1（10-25）
star	10,627	11,078
fork	1,346	1,422
未关闭 issue	865	789

star 涨 451，issue 少 76。一边有人涌进来，一边积压在消化——这两个方向同时发生，说明维护的人是跟得上的。

再看发版间隔。v1.0.2 是 10 月 18 日，v1.0.3b1 是 10 月 25 日，正好七天；而在这七天里，beta 之间的间隔是两天（b7→b8）、三天（b8→b9）。

稳定版按周出，beta 按两三天出。这不是「一个稳定项目偶尔打个补丁」的节奏，是「主干一直在动，定期切一个标记」的节奏。

这版改了四块

按 CHANGELOG 整理，不加工：

新增：建用户时可顺带生成一个默认专家；权限按页面 Tab 拆开，可按组折叠；用户组能限制技能包、知识库、连接器、模型、存储、专家这六类资源对谁可见；技能包支持共享，并能用文件树编辑；建专家、团队等资源时可选头像；表单和对话可让 AI 润色；搜索增加 DeepSeek 和元宝；模型层支持 OpenAI Responses API。

修复：云端协同共享后可直接对话；回复生成过程中刷新页面不会把内容冲掉，也不能趁机删掉这场会话；手机截图写进专家自己的工作区；只改定时任务文案时，间隔任务不再重新计时；浏览器工作台恢复中文输入；向导密码随数据目录迁移。

变更：云端协同默认把对端地址和账号打码；共享来的资源在头像上做标记；支持子路径部署；飞牛原生包标记 x86。

安全：密钥改为加密保存，旧明文仍能读出；插件上传和解压限制了体积。

三个扣分点，两个被补上，一个是我写错了

密钥加密：我查过库，那个「明文」是实锤

原文我写的是「凭证留在本地」这种轻描淡写。写这篇之前我回去翻了实测那台机器的库，~/.octop/octop.db：

select * from providers 一行下去，api_key 字段就是 sk- 开头的完整串，一个字符都没遮。也就是说，任何能读到这个文件的人（备份包、误传的目录、同机的其他账号）都能直接拿走你的模型额度。

新版改成了加密保存。但发布说明里那句「旧明文仍能读出」很关键——升级之后，库里存的那条老记录还是明文，只是新写入的会加密。所以升级完要做的第一件事是去后台把密钥重新填一遍，让它以密文重存，再删掉旧的。不做这一步，加密等于没上。

用户组权限：从「谁能登录」走到了「谁能看见」

原文我写「没有租户级配额治理，只有 admin / user / 自定义三种角色模板」。这句在 v1.0.2 是对的。

v1.0.3b1 补上了：用户组可以分别限制技能包、知识库、连接器、模型、存储、专家这六类资源对谁可见。这是一个实质性的进步——企业里最常见的诉求不是「这个人能不能进系统」，而是「销售部不该看见财务的知识库」，这条现在能配了。

但要说清它还没到什么程度：

它是「看得见」的治理，不是「用多少」的治理。没有 token 配额，没有部门月度上限，没有「超过预算自动停」。这三样才是把 AI 助手交给几十个人日常使用时的真正风险点。现在仍然得自己在网关层拦。

所以我的判断从「没有治理」修正为「治理做到可见性这一层，配额层仍然空白」。给企业做 PoC 够用，做部门级铺开要自己补。

实例协同：这一条我原文写错了

原文我说「没有云端协同」。严格讲，这句话不准确——v1.0.2 的 CHANGELOG 里就写着「两台 Octop 可以连起来用：通过云端协同使用对方的专家」，仓库里也有 docs/bridge.md。v1.0.3b1 只是让这个能力真正可用了（共享后可直接对话）。

但我也没完全说错。翻完那份文档，Bridge 的定位是Octop 与 Octop 之间的实例桥：用户级连接（地址 + 用户名 + 密码），在本机看到对端专家列表，按需拉对话记录，像选本地专家一样跟对端专家对话，而且对话只在专家所在的那台机器上执行，发起侧不落完整历史。

这解决的是「我在公司连家里那台」的问题，不是「我把报告发到云上给人看」的问题。文档自己也标着「实现中（Phase 0–3 骨架已落地）」。

准确的表述应该是：它有了「机器与机器」的协同，仍然没有「成果上云给人看」的通道。没有在线资料库，没有分享链接，没有发布成网页。这一条对照 WorkBuddy 的差距依然成立。

有一条被挤在后面，但企业里更常用

四块里最不起眼的一条，是「技能包可以共享，并用文件树编辑」。

它解决的其实是能力分发。以前的做法是：每个人自己装一遍技能包，或者导出一个 ZIP 发过去再导入。现在可以共享——一个人写好的能力包，直接分给一组人。配合上面那条用户组可见性，你手上就有了两个旋钮：谁看得见（用户组）× 怎么发出去（共享）。

对做企业智能体的人来说，这两个旋钮合起来才叫「能力治理」——先决定有哪些能力，再决定谁能拿到。v1.0.2 之前这两个都缺。

需要说明的是：发布说明只说了「共享」和「文件树编辑」，没提版本号和回滚。所以这里我只能讲到共享这一层，共享出去的包改坏了怎么退回去，得自己去看。文件树能直接编辑，也意味着有人能悄悄改掉正在被别人用的包。

没变的部分，才是选型的关键

新版补了四处，但骨架一动没动。这四条在四天里没有任何变化，它们才是决定「能不能当底座」的东西：

还是单进程。没有水平扩展路径，并发上限就是那个进程的上限。这次只在部署方式上加了子路径支持——那条改动对反向代理后的企业内网很实用，但它改的是入口，不是并发。

内核还是在另外四个包里。octop-harness、octop-gateway、octop-memory、octop-browser，agent 循环最终调用 LangChain 的 deepagents。改界面容易，改心要跨仓库。

还是没有配额治理。上面说过了。

内置办公技能的授权边界还在。docx / pptx / xlsx 三套技能的 LICENSE.txt 写着 © Anthropic, PBC，是专有授权，和 Octop 自己的 MIT 不是一回事。企业采购要单独确认。

这次的迭代节奏，本身就是个信号

从 v1.0.0（9 月 14 日）到 v1.0.3b1（10 月 25 日），四十一天，十三个发布——平均三天一个。

这个节奏有两面：

好的一面是响应快。我上一篇点出的问题，四天里补了两处。虽然不是我影响的结果（我这个体量的反馈进不了它的排期），但至少说明社区声音它听得见。

不好的一面是接口不稳。beta 之间改字段、改路径、改配置结构都是常态。你要拿它做底座，第一件事不是选功能，是定死版本号，并且准备好「升级一次就要回归一轮」的成本。

想升的话，按这个顺序

如果你已经在用 v1.0.2，我建议这么升：

1. 先备份。octop backup 是独立命令，~/.octop/ 整个目录也拷一份，尤其是 octop.db 和 agents/。
2. 再升级，锁死版本号，别用 latest。
3. 升级后立刻轮换密钥。重新填一遍 provider 的 api-key，让密文覆盖旧的明文记录，旧的删掉。
4. 回归三件事：登录、专家列表、发一条消息能不能收到回复。这三个通了，基本就没问题。

我没在你的机器上做升级演练，上面这套是按 CHANGELOG 和代码结构推的，不是实测。真要上生产，先在一台测试机上走一遍。

结论：判断框架没变，扣分项减一

上一篇的三个结论，两个仍然成立，一个要修：

「内部 POC 可以，一周能上线」——成立，而且更容易了。用户组权限补齐后，部门之间能隔开；技能包共享后，能力分发也有路径了。

「对外交付的产品不建议拿它当底座」——仍然成立。原因不是功能缺，是所有权结构：心在别人的包里，升级节奏在别人手里，beta 之间会破坏兼容。这次补四处、七天一个版本，恰好把这条坐实了——它变得越快，你跟着它的成本越高。

「它每天在长，不是一个已经稳定的项目」——这条要改。不是改成「它稳定了」，而是改成：它长得比大多数人预期的快。这一点对选型有实际影响——「等它成熟」的时间成本，可能比想象中低；反过来说，「先自己造一套」的必要性，也比想象中低。

四天一个 beta，一周补两处硬伤。这种速度的项目，值得每两周回来看一眼。

参考资料

• Octop CHANGELOG（v1.0.3b1，2026-10-25；v1.0.0–v1.0.2）
• TencentCloud/Octop 仓库 docs/bridge.md、SECURITY.md
• GitHub API 统计数据（2026-10-22 / 2026-10-26 两次抓取）
• GitHub Releases API 发布时间（v1.0.3b1 published 2026-10-25T03:36:56Z）
• 凭证存储形态为本地实测（~/.octop/octop.db，v1.0.2）
• 升级步骤为按 CHANGELOG 与代码结构推导，未做升级演练

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。