周四下午，一家健身房的系统后台静悄悄地运行着。没人发号施令，没人在控制台前盯着，9个软件代理各司其职。它们共同维持着从会员签到、运动记录到支付结算的全部流程。奇特之处在于：这套系统没有中央协调器。运行34天，一切正常。

大多数多代理系统依赖一个中央协调器——一个负责决定哪个代理在何时、使用何种资源去执行什么任务的总控。这个设计思路很自然：总得有人当裁判。但该健身房背后的技术团队看到了另一面：每一个协调器都是单点故障源。协调器宕机，所有代理原地等待；协调器变慢，所有代理排起长队；协调器做出错误决策，每个代理都照单全收。行业的应对方案是让协调器更大、更快、做冗余备份——意味着更多服务器、更高成本、更复杂的架构。他们的方案简单得多：不要指挥官。

去掉中央控制后，用什么来维系秩序？答案是成文的“章程”。每个代理在一个书面规则集内运作，这组规则定义了四个维度的边界。第一是“领域”：这个代理负责什么，以及被严格禁止做什么。第二是“触发条件”：哪些事件或状态会唤醒这个代理。第三是“升级路径”：何时必须将任务移交给另一个代理或人类。第四是“审计”：独立审计代理Stella如何核查该代理的输出。没有代理能凌驾于章程之上。指挥官Shuyu无权推翻Stella的审计结论。资本代理Zeus不能插手门店运营。门店大脑Momo没有权限修改资本叙事。值得留意的是，这些约束不是靠代码强制执行的，而是靠治理机制——就像现实世界中的宪法运作方式，所有违规行为都会被记录，且对Stella完全可见。

系统分三层运行，每层的时间逻辑截然不同。Momo层始终在线，负责面部签到、训练记录、课程排期和支付处理，旗下有两个产品：面向B2B门店操作系统的Saros，以及面向消费者的代谢教练Melody。如果网络断掉，Momo继续离线运转，签到数据缓存在边缘端。KinTwin层采用边缘触发模式，当行为记录需要核验时才被激活。它在低功耗硬件上运行计算机视觉推理，完全不需要GPU。验证通过的记录会签名存证到用户的去中心化身份标识里。如果光线太差或摄像头被遮挡导致KinTwin无法完成校验，记录会被标记为待定，而不是被悄悄丢弃或者强行通过。全球运营层则是事件驱动型：Zeus协议在有已验证行为记录进入变现流水线时触发，Stella按固定审计周期自动启动——它从不休眠，持续扫描每个代理的输出窗口。

仅用2个CPU核心就能跑这套系统，设计上的自我设限是关键。第一个约束是时间复用：同一时刻只有2到3个代理处于活跃状态，其余全部休眠等待触发条件。这不是什么精巧的优化技巧，而是和实体健身房相同的调度逻辑——同一时段不可能所有人都挤在深蹲架前。第二个约束是边缘优先处理：计算机视觉推理在现场完成，不上云；云端虚拟机只负责协调、治理和变现这些轻量级负载。第三个约束是章程路由：触发事件到来时，由章程决定哪个代理上手处理，不需要路由层，不需要消息队列，不需要负载均衡器。事件精准抵达它该去的位置。

没了协调器，代理如何避免混乱？这是反对声音最集中的方向。传统架构的信奉者会指出，去中心化治理听起来美好，但在没有代码强制约束的情况下，章程的效力取决于代理是否遵守——这更像社会契约而非技术保障。一旦某个代理被恶意篡改或出现未预见的边界条件，缺乏中央仲裁者可能导致连锁失效。另一派则从工程经济学角度反驳：在特定场景下，中央协调器本身就是过度设计。健身房的业务流具有天然的时间稀疏性和空间分布特征——签到、训练记录、支付这些操作不会同时涌入，代理可以在各自的时间窗口内从容处理。这种情况下，协调器引入的不是秩序，而是不必要的串行瓶颈和费用黑洞。两组观点的分歧本质上不在技术路线，而在场景判断：系统需要治理的是高频耦合的复杂依赖，还是可以解耦为独立时间片的松散协作？

这个案例给出的答案是后者。章程将职责边界写死，代理之间通过显式的升级路径而非点对点协商来交互，审计代理提供事后的、系统级的合规检查。在34天的运行周期里，没有协调器介入，没有全局状态同步，没有优先级队列。并不是说这种模式可以推广到所有多代理系统，但在门店运营这类资源受限、任务可切分、实时性要求不极端的场景中，去掉指挥官不是冒险，是回归问题本质。