读这篇像读一份老练CTO的施工图：八个域的风险差十倍，最常见的死法是把它们塞进同一只「Swarm」。作者的拆法是控制面与执行面分离，四种执行模式按成本分级，上一级失败两次才许升级——因为多智能体的典型失败从来不是不够聪明，是三个Agent互相确认同一个错误。四个定生死的设计里，三身份分离（Agent、发起人、触发器每次调用都同时携带）和网关单入口（默认拒绝、deny先于allow、策略走code review）是治理的骨头，任务板唯一事实源与结构化信封交接是协作的骨头。
底座选型这条最有意思：三个候选里只有CopilotKit的OpenBot把「治理的六成难点」做成了代码，nightly-labs反而栽在PolyForm非商业许可上——能力再好，许可证过不了法务就是零。这份候选对比与此前的OpenBot架构调研（s89a3）互为印证：那篇核出网关先写审计后放行、策略双向故障闭合、egress默认拒绝清单比帖子还多两条，治理确实是这家底座最实的部分。
骨架之外补两块血肉。其一，预算与租约是真钱问题：每任务硬预算超了直接停（不是告警），一个仓库分支同时只许一个Agent写，这条照抄nightly的「车位」设计即可。其二，评测是上线门禁不是装饰：Golden Set要覆盖正常、边界、拒绝、注入、越权五类，写操作先跑影子模式，人工采纳率稳了再开自动。至于翻车高发区，作者给了四条铁律——不许裸写SQL连生产库、每个数字必须带血缘、驾驶舱只解释不生成、口径变更要版本化。多少企业Agent项目死在这一步，不是模型不行，是语义层缺位。
三身份分离值得单独展开，因为它回答的是审计唯一真正关心的问题：我不在的时候，谁用我的名义动了东西。Agent身份管授权范围与配额，发起人身份管数据可见性与行级权限，触发器身份管这次调用是定时任务还是另一个人——三者混用一次，事后追溯就断一次。把initiator_kind扩一维照搬进自己的网关，比事后补审计便宜得多。
时间线的算术也对：0阶段2到4周打底座，覆盖八域要8到12人干6到9个月，fork CopilotKit硬化到内部可用约3个月。这个成本结构说明一件事——Agent平台的大头从来不在模型调用，在权限、审计、审批这些「无聊」的工程上。谁先把治理做成代码，谁先拿到入场券。
钉子：五阶段路线图里「每个阶段必须能一键关掉」这条军规，在生产事故复盘里能救命；以及组织树继承策略在跨部门审批里的实际收敛速度。还有一个悬念值得押注：CopilotKit把会话记忆抽成ThreadStore接口之后，敏感域自建存储与托管Intelligence的双轨能跑多久——第一天抽接口是架构判断，第二天开始就是组织判断了。