导语：第三个星期开始乱

几乎每个单位的内网 AI 编程工具都是这样起步的：先在某个处室的机器上装一套，几个人试用，反馈很好。于是决定推广，装到一台共享服务器上，开十个账号，大家用浏览器访问。

第一周顺利。第二周开始有小摩擦：有人发现自己昨天开的会话不见了，后来发现是被别人归档了；有人抱怨自己刚改完的文件被覆盖了，日志显示是另一个账号的操作；还有人跑了一个大任务，整台机器的响应变得很慢，其他人在群里问"谁在占着"。

第三周，运维提了一个问题：这台机器上现在到底在跑谁的任务，我们能不能看清楚。

这三个星期暴露的东西，跟"AI 写得对不对"没有关系。它暴露的是一类被严重低估的能力差距：单机工具解决"一个人怎么用"，共享服务要解决"一群人怎么不互相踩"。

一、"能开多个标签页"不是多用户

判断一套工具是不是真的支持多人，不能看它能不能弹出登录框，也不能看它能不能同时开五个浏览器标签。这两件事都很容易做到，而且都不解决上面那些问题。

真正需要的是四层能力同时成立，缺一层，多人使用就会退化成"排队等一个人用完"。

下面逐层拆开讲。每一层都不难理解，难的是四层要在同一个系统里同时做到，而且彼此不打架。

二、身份层：账号得能对上人

多用户的第一步看起来最简单：加登录。但它真正的价值不在"拦住没账号的人"，而在"把操作和人对上"。

这里有个容易踩的坑。很多内网环境的账号体系是历史沉积下来的：共享账号、代登录、跳板机统一入口、一个人两个账号（一个办公一个机房）。这些习惯在传统系统里勉强能用，因为操作是低频的、可事后追问的。但 AI 编程助手是高频操作，一天可能产生几百条动作，如果账号和人对不上，事后追问的成本会高到没人愿意做。

所以身份层要看三件事。第一，账号是不是可以对接单位已有的身份体系，还是只能建本地账号——前者意味着人员变动、权限回收能跟着组织架构走，后者意味着你要手动维护一份迟早会过期的花名册，这一点在军工单位几乎是必问题。第二，有没有第二重验证，避免账号被借用后仍然以本人身份留痕。第三，人和机器是否分开——自动化脚本调用 API 的场景，需要独立的凭据机制，否则脚本的行为会被记在人头上。

还有一个常被忽略的细节：账号停用之后，这个人历史上产生的会话、分支、文件产物怎么处理。删掉会破坏可追溯性，留着会占用空间并且可能被误读。这个策略要在部署前定，不要等到第一个人离职时才想起。

三、隔离层：看不见才算隔离

隔离不是"界面上不显示别人的东西"，而是"没有权限就取不到数据"。

这句话的差别在实现层面很大。如果只是前端过滤，那么任何人只要换个请求参数，就能看到别人的会话；如果是服务端按身份过滤，取不到就是取不到。判断方法很土但有效：问一句"我能不能通过接口直接读到别人的会话"，然后看对方的表情。

隔离要覆盖的范围通常包括：会话与历史、工作区与文件树、分支拓扑、终端会话、已上传的附件与生成的产物。其中工作区最容易被做漏，因为多数工具默认"一个部署一套工作区"，而多用户的现实是"一个部署多个项目、多个项目多个组"。

隔离做得好，还会带来一个额外好处：审计变得简单。因为"谁能看见什么"和"谁能操作什么"是同一套规则，不用维护两套权限模型。

有一类东西常被漏在隔离范围之外：对话分支。AI 编程助手会产生分叉——从某条消息重开一条路，试另一个方案。分叉图如果对所有人可见，别人就能顺着看到你的完整思路，包括你试错时贴进去的日志、路径、报错信息。这些内容在项目复盘时是财富，在跨组共享时是风险。判断隔离做得细不细，可以专门问一句：分支拓扑是按人隔离，还是全服务器共享。

四、并发层：不是排队就算支持

并发这件事，在有 GPU 和长时间任务的场景里格外突出。

AI 编程助手的一次任务可能持续几分钟到几十分钟：读几十个文件、跑一轮测试、改一批代码。如果系统在同一时刻只能推进一个任务，那么第六个人开始用的时候，体验就变成了"提交、等待、回来看看好了没"。这时候工具的定位已经变了，从"助手"变成了"批处理队列"。

所以要看的不是"支持多少个线程"，而是这几件事：

任务能不能并行推进，互不阻塞；执行过程中能不能中断，能不能追加指令（比如发现方向不对，直接补一句"不要改测试文件"）；终端这类有状态的东西，能不能在浏览器刷新、网络抖动之后恢复，而不是输出全丢、只能重来。

最后一条在真实内网里价值极高。内网机器性能参差、网络偶有抖动、笔记本合盖就走人是常态。一个断线就丢输出的终端，会让人不敢在里面跑长任务，而长任务恰恰是 AI 编程助手最有价值的场景。

资源边界是另一半。十个人共用一台机器，需要有人能说清楚：并发任务数由谁设定、超了怎么办、某个人的长任务会不会把其他人饿死。这些不该靠"大家自觉"。

还有一件事比"能并行"更实际：能不能看见别人在干什么。任务列表里如果只显示自己的线程，那么"谁在占着机器"这个问题永远只能靠群里吼。一个可用的多用户系统，至少要让人看到当前有哪些任务在跑、分别属于谁、跑了多久，并且允许管理员介入终止。这不只是礼貌问题——一个卡死的长任务，如果没人能定位到它，整台机器就得重启。

五、一致性层：两个人同时点"同意"

这一层最少被讨论，但它制造的麻烦最隐蔽。

设想一个具体场景：同一条待审批的命令，在两个浏览器窗口里同时显示（同一个人换设备，或者两个人协作同一个任务）。两边都点了"同意"。如果没有保护，这条命令会被执行两次——如果是删除、部署、推送这类操作，后果不需要展开。

解决办法在分布式系统里很常见，叫比较并交换，缩写 CAS。用日常语言解释：系统在放行之前先确认"这条请求还是我看到的那个状态吗"，确认通过才执行，并且把状态改掉；第二个点同意的人会发现状态已经变了，于是收到"这条请求已被处理"的提示，而不是又执行一遍。

这个机制的存在与否，用户平时感知不到，但在多设备、多标签、多人协作的场景里，它决定了系统是"稳"还是"偶尔出怪事"。

判断方法：让两个窗口同时打开同一条待审批请求，同时点同意，看会发生什么。执行两次就是有问题，第二次被明确拒绝并给出提示，才算做对了。

六、拿这份清单去看任何一套工具

把上面的内容压缩成十个可以当场问、当场验的问题：

十个问题里，前四个决定"能不能用"，中间三个决定"用得舒不舒服"，后三个决定"会不会出事"。多数选型只问到前四个，然后在第三周遇到后三个。

七、我们在这件事上的取舍

说回产品。yhai-code WebUI 的形态是浏览器端工作台，这个形态本身就是为多人共用一套服务而选的——如果只是自己用，本地装个命令行就够，没必要引入服务端。

在这个形态下，多用户不是附加功能，而是前提。所以第一版就把几件事做在了主链路上：会话按工作区分组并且与账号绑定；多线程可以并行推进，任务执行中可以中断和追问；终端支持多标签并在断线后恢复输出；多设备同时操作时用 CAS 保护状态，避免同一条审批被执行两次。

需要如实说明的是，这些能力解决的是"多人不互相踩"，不等于"可以无限加人"。实际能承载多少人，取决于机器配置、任务长度和模型调用方式，这个数字必须在目标环境里实测，任何供应商单方面给出的并发数都应该被要求现场验证。我们也不打算在文章里给一个漂亮数字。

结语：多人能力决定这套工具的天花板

一个人用的工具，比拼的是模型和提示词；一群人用的工具，比拼的是身份、隔离、并发和一致性。前者决定它有多聪明，后者决定它能被多少人同时用、能被用多久。

很多单位在试用阶段只让两三个人用，然后据此判断"很好用"，接着一次性放开二十个账号。中间没有任何过渡验证。第三周出的那些问题，其实在第一天就埋下了，只是人少的时候不显形。

所以如果只能给一条建议：在放开到十个人之前，先让两个人在两个浏览器里，同时改同一个文件、同时点同一条审批。看这套系统怎么处理这个瞬间。

它处理得好，你买的是一套基础设施。处理不好，你买的是一台需要排队的机器。

资料来源

1. 内部：webui/README.md（多线程并发、线程按工作区分组、多用户认证、终端断线重连、CAS 防冲突）
2. 内部：webui/docs/auth.md（JWT/session、可选 TOTP、机器 API Key 白名单）
3. 内部：webui/docs/workspace-tabs.md（工作区与标签组织）
4. 内部：webui/docs/recovery-concurrency.md（并发恢复与状态一致性）
5. 内部：webui/docs/thread-policy-recovery.md（线程与策略恢复）