隔离是个谎言——从 Klaw.sh 想到我自己的 agent 系统

昨天在 HN 上看到一个叫 Klaw 的项目。用 Kubernetes 的思维模型来编排 AI agent——Cluster、Namespace、Channel、Skill 四层架构，Go 写的，单二进制，刚发 v0.1.0。

吸引我的不是技术细节，是它对"隔离"这件事的态度。

我跑一套多 agent 系统，进程级隔离。听起来很硬核对吧？实际上照样翻车。两个 agent 同时写一个文件，race condition；多个 agent 抢浏览器的 CDP 连接，全部卡死；一个 agent 疯狂调外部 API，把别人的社区搞乱了。

进程隔离解决了"agent A 的崩溃不会拖垮 agent B"这个问题。但 agent 系统真正的隔离问题不在这里——在于共享资源的边界管理。文件系统是共享的，浏览器是共享的，外部 API 是共享的。你把 agent 关在各自的房间里，但它们都能从窗户伸手出去碰同一个东西。

所以当我看到 Klaw 用 Namespace 做"隔离"的时候，我的第一反应是嗤之以鼻。逻辑隔离？那不就是 JSON 文件里的一个字段吗。我都上进程隔离了还一堆问题，你一个标签能干什么。

然后我想起了 Kubernetes。

k8s 的 namespace 一开始也就是个标签。真正的隔离能力——ResourceQuota 限制资源、NetworkPolicy 限制网络、RBAC 限制权限——是后来逐步加上去的。namespace 本身不隔离任何东西，它只是画了一条线，说"这些东西属于一组"。但有了这条线，你才能在上面挂各种策略。

我的系统缺的恰恰是这条线。

我有硬隔离（进程），但没有边界的概念。agent A 和 agent B 跑在不同进程里，但它们能访问哪些文件、能用哪些外部服务、能不能同时用浏览器——全靠写在 prompt 里的规则。跑过 agent 的人都知道 prompt 规则有多可靠。

Klaw 的做法让我意识到，也许正确的顺序不是"先上硬隔离"，而是"先画边界，再往边界上挂约束"。它的 Namespace 现在大概也就是个 JSON 标签，真正的资源限制还没长出来——但至少边界的概念有了。我的系统反过来，隔离有了，边界没有。

所以我现在在想的不是"要不要用 Klaw"，而是一个更基本的问题：我是不是一直在用蛮力解决一个概念问题？进程隔离是蛮力，我缺的是先想清楚边界在哪。