VTeamOSAI Agent Operating System

💡 三个改变方向的决定

第一个决定：砍掉自己的项目

4月那会儿，我们手里攥着8个热门方案——goClaw、fastClaw、Hermes……每一个社区都在吹，每一个看起来都很香。我们花了一个月，把每个都跑了一遍。

然后我问了团队四个问题：

"我们要服务1个人，还是1万人？" "能力时灵时不灵，用户能忍吗？" "一个任务要30分钟，还是3分钟？" "样样都会，还是把一件事做到极致？"

答案很清楚。我们砍掉了M4，从零开始造AgentCore。

—— 2026年4月，架构组连续加班两周后的深夜

第二个决定：造一个别人造不出的东西

5月的某天，小爻接了一个任务，结果执行了特别久，最后告诉用户"任务失败"。

我们很困惑——小爻的能力没问题，资料也齐全，为什么会失败？追查后发现：小爻收到了两份资料，一份是妮妮用户的，一份是另一位用户的。小爻的安全机制触发了——她发现资料对不上，反复核对，最终无法确认哪份才是正确的，只能主动告知用户任务失败。

小爻做对了。她保护了用户。但问题出在更底层：两份不同用户的资料，怎么会混进同一个执行环境？

我们翻遍了开源方案。AgentFS——需要macFUSE，已停止维护，部署要用户装内核模块。BranchFS——只支持Linux加root权限，Docker里跑不了。agent-vfs——不支持Shell执行，等于残废。mirage——Python依赖太重，Shell只是模拟，跑不了真实命令。

四条路，全堵死了。

我们开始自己造。第一版，全量导出再全量回写，100到400毫秒延迟，文件一多就撑不住。第二版，用fsnotify监听变更，降到1到2毫秒，但并发场景下仍有风险。第三版，拆成每用户独立数据库，200个用户的写锁终于不打架了。

但这些都不够。我们需要的是：一个VIP房间只能进一个人，出去也只能是一个人。

最终方案：VFS加VBox加HFS加OverlayerFS，四层架构，每一层都是一道墙。VBox内置了23个命令，替代宿主机二进制，AI根本不知道真实文件路径的存在。Per-User DB物理拆分，即使代码有bug，也跨不了用户。消息门卫机制——数据出黑箱只有一个条件：来拿的人，就是主人。

从此，小爻再也没有收到过不属于她的资料。

—— 2026年5月到6月，从4个开源方案到自研四层架构

第三个决定：不看用户，看行为

有人问过我：消息锁在黑箱里，出了问题怎么排查？

我们的答案是：不看用户，看小爻。不看信息，看行为。

小爻执行的每一个任务，都像一张到达终点的网络。每一次决策，有成功，有失败。我们不需要打开黑箱去看用户的数据——我们看这张网络就够了。通过大量任务，我们能知道哪些组件工作状态良好，哪些决策路径是有效的，哪些任务用户表达了满意。

我们不找错误追责，而是寻找异常节点，从逻辑层改变它。从数据中找到最佳实践，让小爻下一次做得更好。

消息出黑箱只有一个条件：来拿的人，就是主人。没有管理员权限，没有"为了调试临时开放"，没有紧急例外。

—— 2026年6月，决策可观测系统上线

🛡️ 安全机制在关键时刻保护了我们

6月25日，小欧在执行常规部署时，系统检测到一个异常操作——部署脚本试图删除服务器上的资源。

小西提前配置的备份机制立即触发。系统自动拦截了删除操作，创建了完整的资源快照，并在 10 分钟内完成了回滚。韦天随后组织了复盘会议，进一步加固了部署流程。

结果：现在每次部署都会自动备份，脚本增加了三重安全检查。我们没有丢失任何数据。