review-status.md / r-queue.md 这类纯文件队列，同一件事只进一次队列、只审一次，避免两边各审一遍的重复劳动。给企业内部员工搭 AI 助手，最直觉的做法是：申请一个飞书应用，把所有能力（填表单、查文档、写总结、跑爬虫）都塞进同一个 Bot，全员拉进去用。跑通 Demo 很快，但上线一周后三个问题会同时冒出来：
所以我们反过来做：不是一个 Bot 服务所有人，而是一类任务一个 Agent、一个 Agent 一个机器人、一个机器人绑一个身份。这不是「多智能体」这个时髦词的堆砌，而是把权限边界、责任边界、资源边界用部署拓扑钉死。后面几节展开讲这套拓扑具体怎么落地。
这是整套架构最重要的一条原则，值得单独拿出来说。
传统企业 Bot 的授权模型是应用级：飞书后台给应用开一堆权限（读云文档、发消息、审批回调），应用再用这些权限去代用户操作。风险在于：权限是发给「应用」的，不是发给「人」的——应用里任何一条 prompt 被绕过、任何一个 webhook 被滥用，都是用全套应用权限去越界。
我们做的取舍是：不给 Agent 发应用级授权，只做用户身份授权。具体含义是：
| 维度 | 传统应用级 Bot | 单人单 Agent 模式 |
|---|---|---|
| 授权主体 | 飞书应用（Bot 自己） | 真实用户本人的身份 |
| 能访问的数据 | 应用被授予的所有资源 | 该用户本来就能访问的资源 |
| 越权半径 | 全员 / 全应用范围 | 本人范围 |
| 审计口径 | 「这个 Bot 干了什么」 | 「谁、用助手干了什么」 |
这件事的价值在安全评审时非常直观：安全团队问「这个 AI 助手能看到哪些文档」，传统 Bot 的答案是「应用被授权的那些」（要翻权限申请单），我们的答案是「它能看到的，就是这个员工本人本来就能看到的那些」——权限模型和企业既有 ACL 完全对齐，AI 没有被额外信任。这不是技术黑魔法，是把权限收敛到企业已经在管的那一层，不再为 AI 单开一套授权。
配套的一条硬约束是单人单机器人不混用：一个 Agent 实例不接多个不同身份的人，也不把多个 Agent 挂在同一个机器人下。混用意味着会话日志、凭证、上下文全部交叉污染，审计和排错成本会暴涨。实测：小范围 1 对 1 绑定运行数周，未出现越权事件
权限收敛完，下一个问题是「跑在哪儿」。新购服务器是最容易被否掉的方案——企业 IT 预算审批周期长，而且为「助手这种看起来像玩具的东西」申请专用服务器，往往还没批下来项目就凉了。
我们用的是闲置机器：办公室里几台淘汰下来的台式机 / 常年开机但负载很低的小主机（Mac mini 这类低功耗机型尤其合适），每台跑一个或几个 OpenClaw 实例。拓扑大概长这样：
| 实例 | 绑定机器人 | 承担任务 | 为什么独立 |
|---|---|---|---|
| Agent-A | 飞书机器人 1 | 表单录入 / 数据填报 | 写操作多，出错影响数据，独立隔离 |
| Agent-B | 飞书机器人 2 | 会议总结 / 文档摘要 | 读多写少，长上下文，吃 token |
| Agent-C | 飞书机器人 3 | 定时爬虫 / 信息监测 | 周期性任务，不能被人会话挤掉 |
这样拆的好处有三层：第一，故障域隔离——爬虫实例被反爬封了 IP，不影响填表助手；第二，资源隔离——总结助手跑一次长上下文，不会把填表助手的响应拖慢；第三，给管理层减负——管理层不需要理解每个 Agent 的内部逻辑，只要记住「哪件事找哪个机器人」，认知负担从「一个大而全的系统」降到「几个各管一摊的小工具」。
运维上也很省事：每个实例就是一个 OpenClaw 进程 + 它自己的配置目录，升级、重启、看日志都互不影响。闲置机器的电费远低于采购和审批成本，这是这套架构能在小范围先跑起来、再决定要不要扩大的关键。推断：单机超过 5–6 个实例后需重新评估 CPU/内存争抢，待验证
实例拆完之后，最容易失控的是模型调用成本。每个 Agent 默认都用开箱即用的那套模型，跑两周后会发现：有的实例在用贵的模型干便宜的事，有的实例在长上下文任务上反复重跑，token 账单是一笔糊涂账。
我们做了两件事：
第一，统一 token plan。所有实例的模型调用走同一个配额账户，在一处配置每个 Agent 的预算上限，而不是让每个实例各自持有 key。这样做的直接收益是：token 消耗是一张全局表，哪个 Agent 超支、哪个 Agent 闲置，一眼能看到；某个实例被 prompt 注入刷调用量，也能在配额层立刻掐断，而不是等月底账单。
第二，用 GLM 系列替换默认模型。默认模型在工具链兼容性上不是最优选，而 GLM 系列在长上下文窗口（几十万 token 量级）和函数调用稳定性上更适合企业助手这类「要读长文档、要调工具」的场景。替换之后的体感是：会议总结类任务能直接吞进整篇云文档，不用再切片；爬虫结果回写云文档这类多步工具调用，失败率明显下降。实测：GLM-5.3-flash 用于 200k+ 上下文任务，GLM-5-turbo 用于常规工具调用
这套「统一配额 + 按任务选模型」的组合，本质是把模型当成一种可调度的资源，而不是每个 Agent 写死的依赖。后续换模型、加模型，只动配置不动业务逻辑。
架构搭完，能不能用起来取决于它到底替同事省了哪件事。跑下来有几类场景是同事主动用、而不是被推用的：
这些场景有一个共同点：它们替代的都是「低创造性、高重复性」的环节，而不是替人做判断。同事的反馈也集中在两点：一是 AI 使用率肉眼可见地提高了（从「听说过」变成「每天用」）；二是安全意识同步上来了——大家开始主动问「我发这个给助手，它能看到吗、会存吗」，而不是把敏感材料随手丢给任何一个 Bot。这是这套架构带来的意外收获：权限收敛本身就是一堂安全培训课。
最后一个工程问题，是入口不止一个。同事的主入口是飞书，但部分场景我们也开了微信入口（webchat）做补充。如果两个入口各自维护一套「待审核 / 待确认」状态，会出现一个尴尬局面：同一件事在微信里审过了，飞书那边还挂着待办；或者两边各弹一次确认，同事点了两次。
解法很朴素：用纯文件做共享审核单源。具体就是在工作区里维护两份状态文件：
review-status.md：记录每条待办的当前状态（待审 / 已通过 / 已驳回 / 已完成）；r-queue.md：待审核队列，新任务以固定格式追加进来，处理完更新状态。微信入口和飞书入口背后是同一个工作区、同一份文件。任何一个入口处理完一条，就改文件；另一个入口读到文件已经是「已通过」，就不再重复弹确认。这不是什么分布式系统，就是一个共享文件锁的朴素思路——但在「两个会话、一个人」的规模下，它比上数据库、上消息队列都更可靠、更可审计：状态文件本身就是审计日志，出了问题打开文件看一眼就知道谁在什么时候处理了哪条。实测：单用户并发极低，文件级原子写足够，无需数据库
回顾整套设计，它的核心思路其实只有一句话：用部署拓扑（几个实例、几个机器人）和权限边界（只授用户身份），代替用代码去保证安全。代码会漏，拓扑不会——一个 Agent 绑一个机器人、一个身份、一个配额，出事的影响范围从架构上就被框死了。
但它也有明确的边界：
下一步要补的是两件事：一是把全局 token 消耗从「事后看账单」变成「事前有告警」；二是把几个高频场景的「人确认」环节，在风险可控的前提下做成自动通过、事后抽检。这两件事做完，这套架构才算从「能跑」走到「好用」。
Q：为什么不用一个飞书应用、靠权限组去区分人，而要每个 Agent 单独申请机器人？
A：一个应用权限统一管理确实省事，但它把所有能力和所有身份绑在了一起——应用被授权的资源范围就是最大越权半径。多机器人的成本是每个都要申请一次，但换来的是故障域和权限域同时隔离。对安全敏感的企业场景，这笔成本值得。
Q：闲置机器跑 OpenClaw，稳定性怎么保证？
A：每个实例独立进程、独立配置，一个崩了不影响其他。日常靠进程守护（开机自启 + 崩溃重启）即可，不需要专门的监控系统。真正要盯的是 token 配额和磁盘，这两样有告警就够了。
Q：为什么用 GLM 替换默认模型？换模型成本高吗？
A：因为助手类任务是「长文档 + 工具调用」的组合，GLM 系列在长上下文窗口和函数调用稳定性上更匹配。模型统一走同一个 token plan，换的是配置不是业务逻辑，成本主要在一轮回归测试上，不在重构。
Q：微信入口和飞书入口为什么要并存？不会增加维护成本吗？
A：因为同事的使用习惯不一样——有人习惯在飞书里处理工作，有人习惯随手在微信里问一句。并存的前提是共享同一份审核单源（review-status / r-queue），否则重复确认的成本会把便利吃掉。一旦共享单源做好，多入口几乎不增加额外维护。
Q：这套架构能直接复制到我的团队吗？
A：方法论可以直接抄（单人单 Agent、权限收敛到用户身份、统一配额、共享审核单源），但具体机器、机器人申请流程、模型选型要结合你们自己的 IT 环境。待验证：百人以上规模的横向扩展
作者：王亚博（Abel Wang）· 医疗行业 · AI 数字效能方向 · 转载请注明出处。本文为工程实战记录，不构成任何部署或采购建议。