编者按｜FinOS
企业 AI 落地翻车，很少是因为「模型不够聪明」，而是因为没有共享的操作系统：谁能代表哪个租户行动、代码在什么边界里跑、对存量系统的写操作谁说了算、员工用的入口是不是企业自己的。本系列讲清这些层，并用可核对的工程事实说话——企业 AI 操作系统。
先说结论
常驻运行时回答「进程怎么活着」；多租户隔离回答「谁代表哪个租户，文件落到哪」。 两件事被当成一件事，Demo 就会被误认成上线标准。
个人 CLI 解决的是「我这台机器上，这一次会话能不能跑完」。企业运行时要回答的是「谁代表哪个租户，在什么生命周期里，把文件落到哪」。上篇把连接面从聊天窗里拆出来；进门之后，执行器要回答进程以什么形态跑、文件按什么身份落盘。沙箱原语和写接口治理是后面的层，常驻运行时替不了它们。
下面从一次典型的「笔记本 Demo、部门共用失控」现场说起，把执行器这一层讲清楚。
一、复盘会上两句话，各自只对了一半
财务同学笔记本上跑了一下午 CLI：问数、改表、出纪要，自己的目录干干净净。周一部分共用，客服、运营、财务打进同一套后台进程。有人把输出写进默认工作区，有人沿用同一份会话文件。下午审计对不上人——三条请求落在同一棵目录里，租户字段是空的。
复盘时两句话同时出现。「我们已经常驻了，又不是开一次关一次。」「目录已经按团队分开了，还要什么隔离？」两句各自对了一半。进程活着，不等于租户切开了；目录切开了，不等于爆炸半径被管住了。
五层里，执行器最容易被个人工具的成功经验带偏。笔记本 CLI 越顺手，越像「已经有运行时了」。平台评审如果只看会不会聊，就会漏掉两根轴：进程怎么活着，租户怎么切开。多买几个本地 Agent，只是把个人工作区复制了几遍。
二、一次性进程，和常驻运行时不是同一物种
个人 Agent 的默认形态很短：敲一条命令，拉起一个进程，会话结束进程退出。工作区在开发者家里，身份就是「坐在这台键盘前面的人」。Demo 成立，因为并发是一个人，审计对象是自己。
这条路径一进部门共用就裂开。终端关掉，推理循环也没了；定时任务没有宿主；第二个用户覆盖第一个用户的文件；节点重启后，谁也说不清上次跑到哪。不是模型变笨，是生命周期还停在「一次命令一次进程」。
常驻运行时是操作系统里的老问题，不是大模型发明的。服务要在用户退出终端后还活着，崩溃后要有人拉起，状态要落在进程之外。Linux 上通常交给 systemd 一类的服务单元；macOS 上是 launchd。Agent 执行器要进生产，先要过这一关：有没有一个可托管的 daemon，而不是靠谁的笔记本终端撑着。
常驻只解决「还在跑」。它不自动回答「这是谁的工作区」「审计记到谁头上」「两个租户是否共享同一块内存」。把 daemon 当成多租户，是把生命周期轴上的答案，抄到隔离轴上。定时智能体把这件事暴露得更清楚：没有常驻宿主，调度只能寄存在某个人的终端会话里；有了常驻宿主，仍要问这次调度代表哪个租户。生命周期和隔离会同时出场，但仍然不是同一笔账。
平台里还有一种更隐蔽的错觉：以为「后台常驻」等于「已经被平台接管」。进程在，只说明有人没关窗口，或者写了一行 nohup。可托管的意思是：有单元文件、有重启策略、有人能回答崩溃后谁拉起。少了这三项，常驻仍是个人习惯，不是运行时。
进程活着，只证明执行器有宿主。租户有没有切开，要另算一笔账。
三、逻辑租户和物理隔离，也是两笔账
平台工程里，多租户从来不是「隔离 / 不隔离」的开关。Kubernetes 官方文档把这件事写成光谱：软多租户共享控制面和节点，靠命名空间、配额、网络策略做逻辑切开；硬多租户才把控制面或数据面继续往外拆。文档也提醒：硬和软没有适用于所有人的定义，硬度是一层层叠上去的。
2021 年多租户工作组把常见形态收成三种模型——命名空间即服务、集群即服务、控制面即服务。共享得越多，密度越高，爆炸半径也越大；拆得越开，隔离越硬，运维账也越厚。Agent 运行时可以收成同一句话。多租户有两根正交的轴：
| 轴 | 它回答 | 常见错觉 | |----|--------|----------| | 逻辑租户 | 请求代表哪个组织、哪个用户、哪次会话；文件和审计键写到哪 | 目录前缀一加，隔离就完成了 | | 物理隔离 | 租户之间隔着进程、容器，还是可选的客户机内核 | 常驻进程本身就是物理边界 |
逻辑租户必须先成立
身份元组——至少包括租户、用户、会话——要在接口、存储键和审计里强制，哪怕全公司暂时共用一个运行时进程。工作区、会话、记忆都要带上租户标识，写成稳定的路径前缀或存储键。请求带着租户标识，才有资格往下写；租户字段为空，就不该落到一张「大家共用」的默认桌面上。
连接面校验过身份，并不等于执行器会按这个身份落盘。网关里的租户字段如果只用来做路由，运行时仍按调用方指定的目录写文件，逻辑切开会在最后一跳被拆掉。身份要被强制进路径和审计键，而不是停在请求头上供人查看。
逻辑切开失败，现场长一个样：工作区互相覆盖，审计对不上人，会话和记忆在租户之间渗。这些事故不需要内核逃逸，只需要两条请求写进同一条路径。
物理隔离是另一笔账
共享进程、多进程、容器、可选 MicroVM，切开的边界不一样，仍共享的东西也不一样。共享进程里，路径和键可以逻辑分离，内存和内核仍是一份；容器加上了 cgroup 和命名空间，宿主机内核往往还在；客户机内核级边界更贵，也不是每个内部团队的默认选项。
| 物理形态 | 切开的是什么 | 仍可能共享什么 | |----------|--------------|----------------| | 共享进程 | 路径、键、审计字段 | 进程、内存、内核 | | 多进程 / 容器 | 进程或容器边界 | 宿主机内核 | | 可选 MicroVM | 客户机内核 | 宿主机与虚拟化层 |
默认可共享运行时、用身份元组做逻辑分离；物理形态按威胁模型往上加。把「每客户一台 MicroVM」说成唯一生产形态，是把光谱上最贵的一档，当成了入场券。同组织多部门共用，和对外互不信任的公有租户，不是同一档威胁模型。
逻辑租户回答「这是谁的」。物理隔离回答「炸开时伤到谁」。两句都要答，不能用一句代替另一句。
四、生产里最常见的五种「焊死」
现场反复出现的，不是「模型不够聪明」，而是把生命周期和隔离焊成一件事。
1. 把个人 CLI 当成部门运行时。 笔记本上能 Demo，密钥、工作区、进程都在一个人的家里目录。一进共享，覆盖和断档同时发生。
2. 拉起一个后台进程，就宣布多租户完成。 daemon 只保证终端关掉后还在。租户字段、路径派生、审计对账，一项都没自动出现。
3. 所有人写同一棵扁平工作区。 没有租户段，记忆和会话靠文件名碰运气。逻辑租户在落盘这一层就已经不存在。
4. 把目录前缀当成内核隔离。 租户 A 和租户 B 的文件夹是逻辑切开。共享进程里，一次路径拼接错误就能跨过去。需要更大爆炸半径控制时，再选多进程、容器或更强的宿主边界——那是部署决策，不是改个文件夹名字。
5. 内部团队也按互不信任的公有租户来配物理隔离。 成本会把平台压垮，逻辑切开反而没人做完。威胁模型先写清楚，再决定要不要把进程拆开。
更好的做法很短。先定生命周期：个人试验可以一次性进程，共享入口必须常驻、可托管、崩溃可拉起。再定逻辑租户：没有身份元组，不写工作区。最后按威胁模型选物理形态，默认可共享运行时。执行器管「跑起来、按租户落盘」；代码在哪类主机原语里跑，是沙箱层；对存量系统的写操作谁批准，是行动治理层。三层不要焊进同一个二进制叙事。
两根轴焊死之后，评审会问错问题。会上只争论「要不要再买一个更聪明的本地 Agent」，却不问进程挂了谁拉起、文件写到哪棵树上、两个部门共用时爆炸半径停在哪。把轴分开，这三个问题才有地方挂。
常驻运行时和多租户隔离被当成一件事，Demo 就会被误认成上线标准。两根轴分开画，评审才问得动。
五、一条可核对的执行器形态（存在性证明）
分层讲到这里，已经不依赖任何一家供应商。需要的是存在性证明：常驻和租户路径能不能被写成可核对的命令与目录，而不是口口相传的架构图。
凡泰的 FinClaw 按公开文档定位为多用户 Claw，也就是智能体运行时——不是沙箱，也不是行动治理网关。CLI 提供 finclaw serve：长驻 daemon（Claw 加上 host-spi 适配）。需要交给操作系统托管时，可用 finclaw service 生成 systemd 或 launchd 单元。这只证明执行器有常驻形态，不证明租户已经被切开。
租户切开落在工作区路径上。工作区文件根下按租户划分：data/tenants//workspaces/...。多租户文档把逻辑租户和物理隔离分成两层：逻辑租户由身份元组强制；物理隔离是共享进程、多进程、容器等可选项。默认可共享 claw，先做逻辑分离。
常驻命令回答生命周期。租户目录回答逻辑切开。物理隔离仍是选项，不是默认口号。
这只是执行器层的存在性证明，不是「起一个 serve 等于有了操作系统」。操作系统还要有连接面、主机沙箱、行动面治理、企业自己的入口。没有常驻执行器和租户路径，后面的层没有稳定的跑法和落盘点；只有这一层，生产写操作照样会从旁路溜走，代码也会在没有主机边界的地方跑。
公开文档能核对的是 serve、租户路径、以及逻辑与物理两层拆法，不是吞吐量、客户名单，也不是「默认每客户一台 MicroVM」。把执行器说成操作系统全家桶，和把个人 CLI 说成生产运行时，是同一种层错位。读者带走的应是可复述的两根轴：先问进程怎么活着，再问租户怎么切开；切开时先强制逻辑身份，再按威胁模型加物理边界。
你们线上那套「已经能跑」的 Agent，进程活着的方式和租户切开的方式，分别写在哪一层？还是被当成同一件事？欢迎评论区对照自己的架构图聊聊。
