告别“编排剧场”，走向生产级数字劳动力基础设施

在过去两年中，多智能体系统（Multi-Agent Systems, MAS）经历了一场从概念狂欢到工程现实的深刻洗礼。社交媒体上曾充斥着各种让 Agent 自由对话、开会讨论的“自主蜂群”Demo，但在企业严肃生产环境中，这类设计迅速暴露出误差级联、协调税高昂、上下文爆炸与安全失控等严重工程瓶颈。

近期，工业界与学术界释放出高度一致的演进信号：一是 Anthropic 官方发布的 Claude Code Desktop 桌面多会话更新，展现了嵌套子会话、物理工作区隔离与人在回路的工程交互范式；二是 Meta FAIR 与哈佛大学研究者发表的前沿学术论文 《Scaling Multi-Agent Intelligence with Substrate-Centric Coordination》 (ScaleMAS)，用实验表明以底座为中心的协作扩展性更好。

本文将系统阐述 ReadyForAI 的多 Agent 架构哲学：为什么企业不需要纸上谈兵的“编排剧场”，而需要一套由坚固操作系统底座（NodalOS）与七大治理产品构成的“企业数字劳动力基础设施”。

---

一、 行业幻灭与工程觉醒：多 Agent 的四大“现实深坑”

在探索大语言模型（LLM）落地的初期，许多团队试图通过增加 Agent 数量来解决复杂问题，但在真实业务场景中往往很快撞上“工程之墙”。

一线工程团队总结出的四大核心痛点包括：

1. 误差级联效应（Cascading Failures）：大模型本质是概率模型。当系统允许 Agent 自由对话时，上游的一个轻微幻觉会被下游节点当成既成事实继续衍生，导致整个业务链条被错误信息渗透，整体错误率成倍放大。
2. 协调税（Coordination Tax）与成本隐患：Agent 之间互相寒暄、传参、无效反问与循环重试，导致 Token 消耗显著攀升。例如在一项原本仅需单步处理即可完成的业务中，若拆分为多个 Agent 互相交互，耗时可能增加数倍、Token 成本成倍攀升，不仅没有提升产出质量，反而推高了整体协同成本。
3. 上下文爆炸与注意力衰减：在长周期业务中，所有历史记录与中间状态堆积在一个 Context 窗口中，造成严重的“首尾遗忘”，Agent 极易偏离最初的企业规范与业务目标。
4. 缺乏确定性保障的提示词防线：试图单纯在 System Prompt 里写“你没有财务权限”、“严禁删除数据”，这种防线在提示词注入（Prompt Injection）和越权调用面前缺乏确定性保障（参见《生产环境不相信 Prompt：企业 Agent 的五层工程责任》）。

我们的工程判断非常明确：

凡是能用单个提示词配合确定性工程逻辑解决的问题，坚决不要盲目引入多 Agent。
一旦业务复杂度确实需要多角色协作，协作逻辑绝不能寄托于 Agent 之间的自由会话，而必须下沉到底座与外部控制面之中。

---

二、 行业风向标的技术印证

多 Agent 正在告别无序的“自由蜂群”，收敛于更严密的工程范式。近期工业界与学术界的突破性进展充分印证了这一趋势：

2.1 工业界实践：Claude Code Desktop 的多会话与隔离体系

在 Anthropic 官方发布的 Claude Code Desktop 桌面版技术更新 中，官方展现了面向生产级开发的多 Agent 交互与工程控制范式：

• 分层主从拓扑（Nested Sessions）：当需要并行执行任务时，主会话为每个任务启动一个独立的嵌套子会话；子会话完成后将结果汇报回主会话，从而保持主线程的清晰可读；
• 物理工作区与环境配置：支持将环境保存为多目录、SSH 主机或云端，并支持为每个目录单独开启 Git Worktree，有效减少多会话并发修改代码时的相互干扰；
• 非阻塞交互与主动派生：支持在主会话运行的同时通过 /btw 命令在独立标签页中提出旁支问题；同时，当 Claude 在执行过程中主动建议后续工作时，支持一键将其开辟为全新会话独立执行；
• 人在回路（HITL）侧栏控制面：侧边栏清晰指示哪些会话正在工作、哪些会话需要人类介入；会话内部提供实时跟进任务计划的待办清单（to-do list），在需要人类时通过回顾卡片（recap card）总结当前轮次，并在侧栏呈现运行位置、上下文与改动详情。

ClaudeDevs 在 X 上发布的 Claude Code Desktop 多会话更新（2026-10-15），查看原帖

这一设计直观体现了：优秀的 Agent 协同并不依赖黑盒的自由私聊，而是依赖清晰的拓扑分层、工作区物理隔离与可干预的人在回路界面。

2.2 学术界前沿：Meta FAIR 与哈佛 ScaleMAS 论文提出的“底座中心化”范式

Meta FAIR 与哈佛大学研究者联合发表的前沿学术论文 《Scaling Multi-Agent Intelligence with Substrate-Centric Coordination》 (ScaleMAS)，指出了传统多智能体设计的核心缺陷：把协作逻辑硬编码进 Agent 本身（Agent-Centric）。在 ScaleMAS 架构中，所有 Agent 采用同一套 harness 与统一 prompt，不预设角色分工，也不进行 Agent 间的直接私聊或任务分派。

论文借鉴了万维网（Web）的设计哲学，提出 以底座为中心（Substrate-Centric） 的全新架构：

• 不可变追加消息库（Append-Only Datastore）：所有知识与结论统一发布（publish）至只追加、不修改、不删除的消息库中，任何 Agent 均可按地址精准追溯出处（visit）；
• 有界阅读（Bounded Reads）：每个 Agent 每次检索严格限制返回至多 k 条记录。无论外部群体扩充到多大规模，单个 Agent 的读取量不随群体规模增长；
• 同行引用计权（Citation Weight）：无需中心裁判，借鉴 Web 的 PageRank 思路，当推论被后续 Agent 引用时动态提权。在 BrowseComp-Plus 基准测试的所有运行中，被引排名前 20% 的记录中有 85% 落在正确答案的证据链上，而被引排名后 20% 的记录仅占 29%（论文指出该指标同时反映连通性与相关性）；
• 实验验证的高容错与横向扩展：系统成功扩展至 128 个 Agent。在 FATE-M 基准测试中，即使设定 p=0.8 的极高丢步率（平均每 5 步缺席 4 步），8 个 Agent 的 ScaleMAS 仍能解出 22.0% 的任务，而依赖中心协调者的 AOrchestra 在 p=0.2 时得分即下降过半；在 Contradiction Audit 测试中加入 1 个每步都报错的故障节点时，ScaleMAS 依然保持与纯健康节点相当的表现（7 个健康节点时均为 19.4%），而对照方案 DeLM（黑板式共享上下文）则跌落至 1% 以下。

---

三、 ReadyForAI 的设计哲学：打造“数字劳动力基础设施”

结合前沿工程实践与学术洞见，ReadyForAI 在构建企业级数字劳动力体系时，确立了四项基础设计原则：

1. 底座中心化（Substrate-Centric over Swarms）
   Worker 之间严禁点对点直接通信，NodalOS 在消息总线（Fabric）上执行硬性拒绝，禁止 Worker 之间的消息互发与频道广播；所有任务协作必须经由 Coordinator 编排与 PathPilot 流水线调度完成。将通信与协调下沉到底座，确保拓扑清晰可控。
2. 隔离优先，显式共享（Isolation First, Explicit Sharing）
   摒弃隐式共享记忆。每个 Agent 拥有独立的运行时、工作区与记忆空间；在 Linux 上默认对 agentd 拉起的 Agent 子进程施加 Landlock 文件系统边界，限制仅可写入当前工作区、shared/ 目录、私有临时目录与各 CLI 的状态目录（进程内运行的 Basic / Native / Coordinator 不受影响，macOS 目前不施加）；重型数据与文件流转必须经由工件服务（ArtifactService）显式授权（Grant），杜绝隐式上下文污染。
3. 确定性工程兜底概率性智能（Deterministic Guardrails over System Prompts）
   绝不把企业安全寄托在提示词防线上。底层运行总线内置路径防逃逸、单任务 Token 消耗硬上限与禁止 Agent Tool 嵌套调用等硬约束；Policy Hook Bus 在关键拦截点上对工具调用、模型调用与派单执行基于 CEL 表达式的策略求值，可同步放行、拒绝或转交（defer）由 Coordinator / 外部求值器裁决。
4. 长周期执行与状态持久化（Durable Execution & Atomic State Machine）
   真实业务任务往往持续数小时乃至数天。单机进程允许崩溃重启，业务状态、派单记录与待办定时器由内嵌 SQLite 数据库事务持久化，确保系统在任意时刻均可断点恢复。

需要指出的是，我们在架构取舍上并未全盘照搬 ScaleMAS。我们采纳的是其“通信与协调收归底座”这一半工程原则，即严禁 Worker 之间直接点对点通信，一切信息交互必须下沉至底座；但我们没有采纳其“完全去中心化、不做任务分派”的设计。企业级业务必须明确知晓谁来派单、谁对最终交付结果负责、算力与资金预算记在哪个业务单元名下，因此系统依然保留了中心化的 Coordinator 编排角色。保留 Coordinator 的代价，是让其成为了协作链路中的关键节点。为了缩短该节点出现故障后的恢复时间，NodalOS 引入了状态与派单记录事务性写入 SQLite、持久化定时器重启后自动补发、派单意图预写对账（Dispatch WAL）以及看门狗超时监控等机制，使 Coordinator 在崩溃重启后能够恢复状态、接续执行。

---

四、 分层架构实现：NodalOS 操作系统底座与治理套件闭环

ReadyForAI 将整个数字劳动力体系划分为两大部分：底层的单机 Agent 操作系统（NodalOS） 与 上层的全生命周期企业治理套件。

4.1 操作系统底座：NodalOS（坚固、自洽、轻量运行）

NodalOS 是面向私有化环境的异构 Agent 运行与管理底座。它由单一守护进程 agentd 和管理 CLI nodalctl 组成，纯 Go 实现、无 CGO 依赖，内嵌 SQLite，无需额外安装外部数据库或消息队列：

• 纳管 5 类已交付 RuntimeClass：
  1. Vendor：直接纳管 Claude Code、Codex、Grok、OpenCode 与通用命令行（generic），亦可托管基于 OpenAI Agents SDK / Claude Agent SDK 编写的应用程序；
  2. Sidecar：通过 HTTP（A2A profile，可托管 Google ADK 等应用）、stdio（自定义 JSONL）或 ACP（Agent Client Protocol）协议承接不同生态的 Agent；
  3. Coordinator：由模型驱动的常驻编排 Runtime，负责向 Worker 派单；
  4. Native：基于 NodalOS Go SDK 编写的原生 Agent；
  5. Basic：轻量线性循环 Agent，内部遵循行数软护栏以保持极简。
• Coordinator 长周期运行原语： 内置权威工作集（Working Set）常驻上下文注入、写入 SQLite 并在重启后自动补发的持久化定时器（Durable Timer）、派单意图预写对账（Dispatch WAL）、重复失败指纹拦截（防死循环调用）、看门狗超时监控（Watchdog）、Steer 固定合流窗口（防高频并发汇报风暴），以及会话中断接续机制；
• 策略拦截总线（Policy Hook Bus）：
  • 总线内置硬约束：底层内置路径防逃逸检查、单任务 Token 消耗硬顶，以及禁止 Agent Tool 嵌套调用；
  • CEL 动态求值：在 before_tool_invoke、before_coordinator_dispatch、before_model_invoke 等 Hook 拦截点上，执行基于 Google CEL 表达式的规则校验，支持同步放行、拒绝或转交（defer_to_coordinator / defer_to_external）；
• SQLite 三库与事件流架构：
  • nodalos.db：低频元数据与系统配置历史；
  • sessions.db：中频会话状态、分层运行时记忆（working/short_term/long_term）与定时器；
  • leases.db：高频租约与瞬态配额计数；
  • event-log/YYYY-MM-DD.log：独立的按日切分不可变追加事件流；
  • Fabric 消息总线闭集定义 5 类消息类型（REQUEST / REPLY / EVENT / STREAM / CONTROL），严格管控进程间通信流向。

4.2 极度克制的系统边界（明确不做清单）

NodalOS 的对外规范中严格界定了其系统边界，不做多余的事，让底座保持纯粹：

• ❌ 不内置上层业务人机交互界面：人机协同、待办流、审批卡片与全局控制台完全交由 AULO 承载；
• ❌ 不持有上层合规工单与审计账本：高阶人审工单、审计链与合规报告完全交由 OwlAudit 负责；
• ❌ 不参与上层业务绩效统计与展示：业务绩效指标归集与多角色治理分析完全由 AULO 聚合呈现；
• ❌ 不提供任务拓扑服务与预算子系统：任务拓扑归 AULO，多阶段任务与层级预算管理归 PathPilot（NodalOS 仅依据配置派单并计量调用消耗）。

4.3 商业治理闭环：七大企业级数字员工管理产品

在坚固的 NodalOS 之上，ReadyForAI 构建了完整的企业治理产品矩阵：

• AULO（统一人机协作工作台）：把待办、审批、控制台、对话与绩效展示收进统一入口，支持按项目与 Coordinator 对话并在多 Agent 讨论中沉淀关键决策；
• PathPilot（任务执行控制面）：管理多阶段任务流水线（Pipeline）、里程碑推算、层级预算与跨任务资源锁，赋予复杂业务协同确定性；
• OwlAudit（合规审计与门禁）：挂接 NodalOS 外部治理 Hook，维护可验证、可检测断链的 Hash Chain 审计账本，提供 HITL / HOTL / HOOL 三档人工介入（HITL 实施审批门禁拦截）；
• LarkScout（知识编译加工平台）：将企业多源文档解析并提炼为带出处定位的原子事实单元（Claim），编译为主题知识视图，定时扫描知识矛盾并标记供人工复核；
• HarnessServer（上下文与能力装配引擎）：按角色将 Skill、SOP 注入 Agent 工作区，并在部署前通过 SkillScan 实施静态安全扫描（新装默认开启、可关闭）；
• HeronSentry（端到端运行观测面）：基于标准 OpenTelemetry (OTLP) 接收数据，还原端到端分布式调用拓扑，提供细化至输入、缓存命中与输出的 Token 成本核算与告警；
• PrismCouncil（战略决策推演沙盘）：8 大专业观点顾问多视角推演，由议事官调度团体或单体议事，收敛生成标准化 Decision Package，始终坚持人类终裁原则。

至此，回顾第一节提出的多 Agent 四大工程陷阱，分层架构体系给出了明确的应对路径：

1. 误差级联：由 Fabric 严禁 Worker 间点对点私聊与频道广播，结合 PathPilot 多阶段任务流水线与重复失败指纹拦截机制共同收敛，抑制局部偏差沿网状链路层层放大。
2. 协调税：由底座统揽拓扑调度、Steer 固定合流窗口平抑高频汇报风暴，叠加 PathPilot 层级预算与 HeronSentry 细粒度成本监控共同应对，控制通信与算力开销。
3. 上下文爆炸：由独立工作区与 Landlock 边界隔离、ArtifactService 显式授权传递重型工件，配合 LarkScout 原子 Claim 编译与 HarnessServer 按角色收敛上下文予以缓解。
4. 提示词防线缺乏确定性保障：由底层路径防逃逸与禁止工具嵌套等硬约束、Policy Hook Bus 的 CEL 策略求值，以及 OwlAudit 的 HITL 审批门禁兜底应对，守住系统物理底线。

---

五、 企业数字劳动力落地路线图

引入数字劳动力不需要一次性采购一整套庞大系统。ReadyForAI 倡导“小步快跑、阶段见效”的四步采纳路径：

阶段	启用产品	阶段核心目标与交付物
阶段 01：创建与纳管	NodalOS, PathPilot, AULO	将存量 Agent 团队安全运行起来，定义好可干预的任务流水线，人类通过统一操作台直观管理。
阶段 02：增强与进化	LarkScout, HarnessServer	沉淀企业私有知识，按角色下发 SOP，部署前静态扫描 Skill 安全风险，启动“经验回流飞轮”。
阶段 03：监督与决策	HeronSentry, OwlAudit, PrismCouncil	接入标准 OTLP 全链路可观测，建立可验证审计存证链，重大业务决策引入多视角对抗推演。
阶段 04：复制与推广	全部 8 款产品协同闭环	7 款治理产品与 NodalOS 底座协同闭环，横向复制到研发、测试、合规、财务、营销等多个部门，实现边际上线成本递减。

---

六、 结语：把确定性留在底座与控制面

在生成式 AI 狂飙猛进的时代，底层大语言模型正以几个月为周期推陈出新，今天看似领先的模型，明天就可能变为平价的标准耗材。

如果一家企业将协同逻辑深度绑定在特定大模型的黑盒对话框或自由蜂群中，不仅时刻面临被供应商锁定的风险，更无法将数字劳动力沉淀为自身的长期资产。

我们在《控制面必须自己养：模型半年一死，企业到底该买什么？》中深入剖析过这一逻辑：大模型是不断折旧的概率性算力，而企业内部沉淀的业务规范、权限边界、审计证据链以及基于底座与控制面的确定性治理能力，才是永续增值的核心资产。

多 Agent 系统的下半场，竞争的核心已经不再是“谁的提示词写得巧”，而是“谁的底座更稳固、谁的控制面更确定、谁的合规证据链更完整”。告别不可控的“编排剧场”，走向底座与控制面，正是企业构建生产级数字劳动力的坚实起点。

---

下一步：了解异构 Agent 如何在确定性底座上实现低税协同，可以看多 Agent 协作，或预约演示。延伸阅读：《控制面必须自己养：模型半年一死，企业到底该买什么？》、《生产环境不相信 Prompt：企业 Agent 的五层工程责任》。