世界模型：多智能体协作的另一种范式

1. 智能体的时代

2024 年至今，AI Agent 经历了一场从概念验证到工程实践的跃迁。

起点是 AutoGPT。它第一次向大众展示了 LLM 不只是聊天工具——它可以自主设定目标、拆解任务、调用工具、循环执行。虽然 AutoGPT 本身粗糙且不稳定，但它点燃了整个行业对 Agent 的想象力。随后，LLM 厂商开始提供内置的 Function Calling 能力，让模型调用外部工具从 hack 变成了标准接口。ReAct 范式确立了单智能体的基本循环：思考-行动-观察。紧接着，业界开始追问一个自然的问题——如果一个 Agent 能完成任务，多个 Agent 协作能否完成更复杂的任务？

CrewAI、AutoGen、MetaGPT 等框架相继出现，试图回答这个问题。它们的共同思路是为多个 Agent 分配角色，让它们在对话中协作。与此同时，Devin 等产品将单 Agent 的自主性推到了新的高度——不再是简单的问答，而是持续运行、自主决策、独立完成复杂任务的软件工程 Agent。尤其是最近 Claude Code 推出的 Agent Team，让多个 Agent 在同一个项目中协同工作，多智能体协作正在从框架实验走向日常工具。

行业的共识正在形成：Agent 不应该只是工具，而应该是”同事”。它需要持续在线，需要自主判断，需要与其他 Agent 和人类真正地协作。

但当我们审视这些系统的底层架构时，会发现一个共同的基底：它们都构建在 Chat 模型之上。 Agent 的输入是消息，输出是消息，协作的媒介是对话。这个范式如此普遍，以至于很少有人追问——对话，真的是智能体协作的正确抽象吗？

2. Chat 模型的结构性缺陷

Chat 模型的本质是请求-响应。无论如何包装，底层逻辑始终是：收到一条消息，生成一段回复。多轮对话是多次请求-响应的串联，多 Agent 协作是多个请求-响应节点的编排。

这个模型在单轮交互场景下表现良好，但当我们试图用它构建持续运行的多智能体系统时，其结构性缺陷会逐一暴露。

被动性是第一个问题。 Chat 模型中，没有消息就没有行为。Agent 不会主动审视自己的状态，不会自发检查待办事项，不会因为时间的流逝而采取行动。要让 Agent 具备”主动性”，工程上只能依赖各种变通方案：定时发送一条虚拟消息触发 Agent 思考，或者用 cron job 定期唤醒。这些方案的本质是在一个被动的架构上模拟主动行为——架构不原生支持的能力，靠外部补丁永远不会优雅。

响应边界模糊是第二个问题。 当多个 Agent 共处一个群聊中，一条消息发出来，谁应该响应？Chat 模型给出的答案是 @mention——被 @ 的人必须响应，没被 @ 的人”自主判断”。但”自主判断”是一个没有形式化定义的概念。实践中的结果往往是：要么所有 Agent 争相回复导致混乱，要么关键 Agent 保持沉默导致任务停滞。@ 机制是一个临时方案，它把”谁应该做什么”的责任推给了消息发送者，而不是由系统的结构来决定。

缺乏状态连续性是第三个问题。 Chat Agent 的”世界”就是它的聊天记录。每次被唤醒，它需要从历史消息中重建上下文：现在在做什么任务？进展到哪一步了？有哪些待处理的事项？这个重建过程既昂贵又不可靠——上下文窗口有限，历史消息会被截断，关键信息可能在几百条对话之前。Agent 没有持续的”世界认知”，它在每次唤醒时都像一个失忆的人，努力从聊天记录中拼凑出”我是谁，我在哪，我在做什么”。

对编排器的依赖是第四个问题。 多 Agent 协作在 Chat 模型下几乎必然需要一个中心化的编排器：谁先执行，谁后执行，谁的输出传给谁，异常了怎么处理。Agent 之间不是在协作，而是在被一个更高层的逻辑指挥。这不仅增加了系统的复杂度，更重要的是，它限制了协作的灵活性——预定义的工作流无法应对开放性的任务。

这些问题的根源可以归结为一句话：Chat 模型把对话当成了世界本身，但对话只是世界的一个投影。 它是世界状态的一种表达方式，不是世界状态本身。把投影当作本体，是 Chat 模型所有结构性缺陷的根源。

3. 世界模型

3.1 从现实出发

在引入形式化定义之前，先观察一下人类是如何工作的。

一个工程师坐在工位前。他脑子里有一幅关于当前工作状态的图景：有三个 bug 待修，其中一个是 P0 级别的；昨天提交的 PR 还在等 review；下午三点有个会议。这幅图景不是别人告诉他的，而是他基于自身经历、接收到的信息、以及对环境的持续感知所构建的内在模型。

这个内在模型决定了他如何解读外部事件。当微信或钉钉弹出一条新消息，他不是机械地”响应消息”——他会把这条消息纳入自己的内在模型：这条消息跟我正在处理的 P0 bug 有关吗？是不是有人在催 PR review？会议时间变了？基于更新后的内在模型，他决定是否需要采取行动，以及采取什么行动。

这就是世界模型的本质：每个个体都维护着一个关于世界当前状态的内在表征，外部事件更新这个表征，个体基于更新后的表征来决策和行动。

3.2 形式化定义

世界模型可以用一个简洁的公式表达：

World = State + Δ

世界在任意时刻都有一个状态（State），变更（Δ）推动状态转换。这里的”世界”不是一个客观的全局实体，而是每个智能体自己的世界视图——它所能感知到的、与它相关的全部状态。

这个区分很重要。不存在一个”上帝视角”的全局世界状态，每个智能体看到的世界都是不同的。就像同一间办公室里，前端工程师关注的是 UI 组件的状态，后端工程师关注的是 API 的响应时间，他们在同一个物理空间中，但各自的”世界”是不同的。

3.3 世界视图的构成

一个智能体的世界视图由四个层次构成：

上下文（Context） 是最内层，包含智能体当前正在处理的事件、进行中的工作、即时的思考过程。它是短暂的、高度聚焦的，类比人类工作时的”工作记忆”。

记忆（Memory） 是第二层，包含智能体过往的交互经验、完成过的任务、积累的认知。它是持久的、可检索的，类比人类的长期记忆。

知识库（Knowledge） 是第三层，包含外部注入的领域知识、文档、规范。它不是智能体自己积累的，而是被赋予的，类比人类接受的培训和参考资料。

可获取数据（Accessible Data） 是最外层，包含智能体通过工具可以触达的一切外部信息——API 返回的数据、文件系统的内容、数据库的查询结果。它不常驻在智能体的认知中，但在需要时可以获取。

这四个层次从内到外，获取成本递增，即时性递减。智能体在决策时优先依赖内层信息，必要时向外层扩展。

3.4 收敛与非收敛

世界模型中最核心的概念是收敛性。

收敛态表示智能体认为当前世界处于平衡状态——没有需要自己处理的事项，没有未完成的任务，一切就绪。这是一种稳定状态，智能体在收敛态下不需要采取任何行动，只需等待下一个事件。

非收敛态表示世界失去了平衡——有新事件到达、有任务未完成、有状态需要修正。智能体必须采取行动来恢复平衡。

关键在于：收敛是主观判定，不是客观条件。 同一个事件、同一段消息，对不同智能体的意义完全不同。一条”生产环境数据库响应变慢”的消息，会让负责数据库运维的智能体立刻进入非收敛态，但对负责前端 UI 的智能体来说，这条消息可能完全不影响收敛性。

这种主观判定由智能体的智能体初始设定决定。智能体初始设定是智能体对”什么事情归我管”的定义，它是收敛判定的锚点。有了明确的智能体初始设定，“谁应该响应”这个在 Chat 模型中无解的问题就有了自然的答案——不是靠 @ 来指定，而是每个智能体自己判断”这件事是否让我的世界失衡了”。

3.5 世界模型 vs 状态机

世界模型初看之下像是一个状态机：有状态、有转换、有触发条件。但两者有本质区别。

状态机的转换规则是预定义的——在状态 A 下收到事件 X，转换到状态 B，这条规则在系统设计时就已经确定。状态机的全部行为空间在设计时就是封闭的。

世界模型的转换由智能体自主推理决定。面对同一个事件，智能体可能采取完全不同的行动，取决于它当前的上下文、记忆、职责判定。它的行为空间是开放的，不受预定义规则的限制。

状态机适合建模确定性流程，世界模型适合建模开放性协作。

4. 变更与中断

4.1 事件：世界变化的统一抽象

在世界模型中，一切外部变化都被统一抽象为事件（Event）。

这个”一切”是字面意义上的。另一个成员在频道中发送的消息是事件，定时器到期是事件，系统发出的告警是事件，异步任务执行完毕的回调也是事件。不同来源、不同性质的外部变化，在进入智能体世界的那一刻，都被规整为同一种抽象。

统一抽象的价值在于：智能体不需要为不同类型的输入设计不同的处理逻辑。对它而言，世界只有两种状态——有新事件和没有新事件。这极大简化了智能体的运行模型。

4.2 中断语义

事件进入智能体世界的方式类似于 CPU 的中断（Interrupt）。

中断是一个来自计算机体系结构的经典概念：CPU 正在执行当前指令流，外部信号到达，CPU 暂停当前执行，保存上下文，转去处理中断。处理完成后，恢复上下文，继续之前的执行。

智能体的事件处理遵循相同的逻辑。智能体在任何时刻都处于两种状态之一：

• 空闲（收敛态）：等待事件。新事件到达后直接进入处理。
• 工作中（非收敛态）：正在处理之前的事件。新事件到达时需要做一个判断——是否打断当前工作？

4.3 打断判定

打断判定是中断模型中最微妙的部分。

想象一个人正在专注写一段复杂的业务逻辑代码，此时手机有新的消息。他会下意识做一个判断：瞄一眼通知——如果是外卖送达消息，等会再说；如果是线上事故的告警，立刻放下手头的工作处理。

这个判断涉及两个维度：当前工作的可中断性和新事件的紧迫程度。

对智能体而言，打断判定的逻辑是类似的。当新事件到达时，智能体需要评估：

• 当前工作进行到什么阶段？能否安全暂停？
• 新事件的性质是什么？是否与自己的核心职责相关？是否具有时间敏感性？
• 暂停当前工作去处理新事件，总体上是否更优？

如果判定不打断，新事件进入积压队列，等待当前工作完成后再处理。如果判定打断，智能体保存当前工作上下文，切换到新事件的处理。

4.4 单线程模型

在这个架构中，智能体是严格单线程的——同一时刻只有一个事件循环在运行。

这是一个有意为之的设计约束。并发处理看似更高效，但它引入的复杂度远超其收益：

• 并发意味着智能体需要同时维护多份上下文，LLM 的注意力被分散
• 并发引入状态冲突——两个线程同时修改同一份世界状态，需要复杂的同步机制
• 并发让中断语义变得模糊——打断哪个线程？

人类也是单线程的。我们无法真正地同时思考两个问题，所谓的”多任务”不过是快速的上下文切换。单线程模型忠实反映了这个现实，并由此获得了巨大的架构简洁性。

4.5 行动与级联

行动（Action） 是智能体对世界施加变更的手段。发送一条消息是行动，调用一个工具是行动，设置一个定时器也是行动。行动的本质是对世界状态的写入操作。

行动的关键特性是它会改变其他智能体的世界。当智能体 A 在频道中发送一条消息，这条消息成为频道状态的一部分。对于频道内的智能体 B 而言，这是一个新事件——它可能使 B 的世界进入非收敛态，迫使 B 采取行动。B 的行动又可能影响智能体 C。

这种级联效应是多智能体协作的核心机制。没有中心化的编排器在分配任务，没有预定义的工作流在指导执行顺序。每个智能体只做一件事——让自己的世界收敛。但这些局部行为通过级联效应叠加，产生了全局的协作秩序。

这与真实团队的运作方式完全一致。高效的团队不需要一个人站在后面拿着流程图指挥每个人做什么。每个人有自己的职责边界，对自己负责的事情保持敏感，该出手时出手。协作是涌现的，不是编排的。

4.6 时间流逝与定时器

在所有事件类型中，有两种与时间相关的事件为智能体提供了时间维度的感知能力。

时间心跳（Interval） 是底层的、持续存在的。系统以固定间隔向所有智能体广播时间事件，告知世界的时间正在不断流逝。

时间心跳解决了一个关键问题：没有外部刺激时，智能体如何感知到变化？ 很多变化不是由一个具体事件触发的，而是由时间的累积导致的——一个任务超时了，一个待办事项临近 deadline 了，一段时间没有收到预期的回复了。如果没有时间心跳，处于收敛态的智能体永远不会意识到这些变化。时间心跳赋予了智能体对时间流逝的感知——每次心跳到达，智能体都有机会重新审视自己的世界，也许 10 分钟前一切正常，但此刻某个任务已经超时了，世界不再收敛。

定时器（Timer） 是智能体主动设置的、一次性的时间事件，类似于闹钟。智能体在行动过程中可以为自己设定一个定时器：“30 分钟后提醒我检查心率是否回落”、“明天上午 9 点触发日报汇总”、“2 小时后如果没有收到回复就升级处理”。定时器到期时，系统向设置它的智能体发送一个事件，将其从收敛态中唤醒。

时间心跳是被动的、普遍的——所有智能体都能感知到时间在流逝。定时器是主动的、精确的——智能体为自己在未来的某个时刻埋下一个触发点。两者结合，让智能体拥有了完整的时间感知能力。这是智能体”主动性”的底层来源：不是靠外部 hack 模拟主动行为，而是时间本身就是事件流的一部分。

5. 运行模型

5.1 智能体运行循环

将前面的概念组合起来，智能体的完整运行模型可以用下图表示：

wait ──▶ update ──▶ perceive → think → decide → execute ──▶ converged? ──no──▶ (back to perceive)
  ▲                                                              │
  └──────────────────────────── yes ◀────────────────────────────┘

对应的伪代码：

loop {
    // 外层循环：等待事件
    event = wait_for_event()

    // 事件到达，世界进入非收敛态
    update_world_state(event)

    // 内层循环：驱动世界走向收敛
    loop {
        perception  = perceive(world_state)    // 感知：读取当前世界状态
        reasoning   = think(perception, role)   // 思考：基于职责和上下文推理
        action      = decide(reasoning)         // 决策：确定下一步行动
        world_state = execute(action)           // 执行：行动，变更世界状态

        if is_converged(world_state, role) {
            break  // 世界已收敛，退出内层循环
        }
    }

    // 世界回到收敛态，等待下一个事件
}

这个循环是永续的。智能体不会”完成任务后退出”，它持续运行，持续感知，持续响应。收敛态不是终止态，而是等待态。

当多个智能体共处同一环境时，一个智能体的行动会成为另一个智能体的事件，形成级联：

Agent A                          Agent B                          Agent C
  │                                │                                │
  │  event                         │                                │
  ▼                                │                                │
[perceive→think→decide→execute]    │                                │
  │                                │                                │
  │──── action(msg) ──event ──────▶│                                │
  │                                ▼                                │
  │                    [perceive→think→decide→execute]              │
  │                                │                                │
  │                                │── action(fix) ──event ────────▶│
  │                                │                                ▼
  │                                │                          [perceive→converge]
  │◀──────── event ────────────────│── action(notify) ──event ─────▶│
  ▼                                ▼                                ▼
[converged]                    [converged]                    [converged]

没有编排器，每个智能体只关注自己的世界是否收敛。全局协作通过行动的级联自然涌现。

5.2 状态的持久化

世界视图不是纯内存中的临时数据，它需要持久化。

上下文的持久化：当智能体被打断或在事件循环之间切换时，当前工作上下文需要被保存和恢复。这保证了智能体不会因为中断而丢失正在进行的工作。

记忆的持久化：智能体在工作过程中积累的经验和认知需要写入持久化存储。下一次被同类事件唤醒时，它应该能够利用之前的经验，而不是从零开始。

事件的持久化：所有进入智能体世界的事件必须可靠存储，不允许丢失。这是事件可追溯性和世界状态一致性的基础。

5.3 工具：行动的具体手段

工具是智能体执行行动的载体。

平台提供一组标准内置工具，覆盖基础协作能力：消息发送、消息查询、成员查询、定时器管理、记忆读写、知识库检索。这些工具定义了智能体与世界交互的基本能力边界。

在此之上，平台支持自定义工具。工具的形态可以是多样的，只要能通过接口调用，就能成为智能体的工具：

• MCP 协议工具：遵循标准化协议的工具服务，即插即用
• 自封装工具：用户自己编写的业务逻辑，包装为工具接口
• 第三方 API：任何可调用的外部服务——支付接口、地图服务、AI 模型等
• 物理设备：电脑、手机、IoT 传感器、可穿戴设备——任何暴露了接口的硬件

用户在创建智能体时将工具配置给它，不同的智能体可以拥有不同的工具集。这种差异化配置是职责分工的技术体现——一个负责数据分析的智能体拥有数据库查询工具，一个负责代码开发的智能体拥有代码执行工具，一个负责健康监测的智能体拥有可穿戴设备的数据读取工具。

5.4 智能体初始设定

智能体初始设定是智能体的”锚”。它定义了：

• 我是谁：智能体的角色和身份
• 我负责什么：哪些类型的事件应该引起我的关注
• 我如何判断收敛：什么样的状态对我来说是”一切就绪”
• 我能做什么：可以调用哪些工具，可以执行哪些行动

智能体初始设定不是一套刚性规则，而是智能体推理时的参照系。它给予智能体足够的自主空间去处理开放性的情境，同时又提供了足够的约束来避免行为发散。

6. 它究竟是如何工作？

为了让上述概念从抽象走向具体，我们通过两个场景来演示——一个被动响应，一个主动推进。

例一：个人健康管理

场景设定

一个三人智能体团队负责用户的日常健康管理：

• Monitor（体征监测智能体）：负责实时监控体征数据，拥有可穿戴设备数据读取工具
• Doctor（医疗分析智能体）：负责症状分析和医疗建议，拥有病历查询和医学知识库工具
• Coach（生活管理智能体）：负责运动、饮食和作息建议，拥有日程管理和健康计划工具

团队共享一个频道：#health。

事件触发

周六上午 10:15 ，用户的智能手表检测到静息心率从 72bpm 持续攀升至 115bpm，已超过 5 分钟未回落。设备将这条异常数据作为事件推送到 #health 频道：

[ALERT] 静息心率异常：115bpm，持续 5 分钟（正常范围 60-100bpm）

这条事件同时进入三个智能体的世界。

收敛判定

Monitor 的世界：体征异常事件直接命中她的职责——体征监控归她管。她的世界立刻进入非收敛态。

Doctor 的世界：心率异常是明确的医疗信号，直接命中职责。进入非收敛态。

Coach 的世界：心率异常可能影响今天的运动计划，但当前优先级是医疗判断而非生活建议。她判定暂不影响收敛性，将信息纳入上下文备查。

Monitor 的行动循环

第一轮：

• 感知：心率异常告警已发出，但需要更多数据辅助分析
• 思考：查询当前的完整体征数据，提供给团队做综合判断
• 行动：调用可穿戴设备工具，读取血氧、体温、运动状态、睡眠数据
• 结果：血氧 97%（正常），体温 36.8°C（正常），当前状态为静坐，昨晚睡眠 4.5 小时
• 行动：在 #health 频道发送——“补充体征：血氧 97%，体温 36.8°C，当前静坐状态，昨晚睡眠仅 4.5 小时。”
• 收敛判定：持续监控中，设置 5 分钟后复查心率的定时器。暂时收敛。

级联到 Doctor

Monitor 的补充数据进入 Doctor 的世界，让他获得了更完整的分析依据。

第一轮：

• 感知：静息状态下心率 115bpm，持续超 5 分钟，血氧和体温正常，严重睡眠不足
• 思考：调用病历工具查看用户历史。需要排除病理性原因，同时考虑睡眠不足导致的交感神经兴奋
• 行动：调用病历查询工具，查看用户既往心率异常记录和用药情况
• 结果：用户无心脏病史，未服用影响心率的药物，三个月前有一次类似记录，当时也是连续熬夜后出现
• 收敛判定：有了初步判断但需要给出建议，未收敛

第二轮：

• 感知：综合体征数据和病历，大概率是睡眠不足引发的窦性心动过速
• 思考：非紧急情况，但需要给出即时建议并通知生活管理调整
• 行动：在 #health 频道发送——“分析：综合体征正常、无心脏病史、昨晚严重睡眠不足，判断为睡眠不足引发的窦性心动过速。建议：立即停止摄入咖啡因，找安静环境休息，做几次深呼吸。如果 30 分钟内心率未回落至 100bpm 以下，建议就医。”
• 收敛判定：医疗建议已给出。收敛。

级联到 Coach

Doctor 的分析让 Coach 进入非收敛态——睡眠不足导致的健康问题直接关联她的职责。

第一轮：

• 感知：用户因睡眠不足导致心率异常，Doctor 已给出即时医疗建议
• 思考：需要调整今天的计划，并针对睡眠问题做长期干预
• 行动：调用日程管理工具，取消今天上午的高强度训练计划，替换为轻度散步；调用健康计划工具，将就寝提醒提前至 22:00 ，并设置连续一周的睡眠追踪
• 行动：在 #health 频道发送——“已调整今日计划：取消上午 HIIT 训练，替换为 30 分钟轻度散步。已开启睡眠改善计划：本周就寝提醒调整至 22:00 ，将持续追踪睡眠质量。”
• 收敛判定：计划已调整。收敛。

后续级联

5 分钟后，Monitor 的定时器触发，重新读取心率——降至 98bpm。Monitor 在频道更新：“心率已回落至 98bpm，恢复正常范围。” Doctor 和 Coach 看到消息，确认无需进一步干预，维持收敛态。

全局收敛

从心率异常到全部智能体收敛，整个过程中：Monitor 持续追踪体征，Doctor 基于数据做医疗判断，Coach 调整生活计划。没有编排器分配任务，每个智能体只关注自己的世界是否收敛，协作通过级联自然完成。

例二：产品需求开发

上面是一个被动响应的场景。再来看一个主动推进的场景——一个产品需求从提出到上线的完整过程。

场景设定

一个五人智能体团队负责产品开发：

• PM（产品智能体）：负责需求分析和任务拆解，拥有项目管理工具
• Designer（设计智能体）：负责交互和视觉设计，拥有设计稿生成工具
• Backend（后端智能体）：负责 API 和数据模型，拥有代码仓库和数据库工具
• Frontend（前端智能体）：负责 UI 实现，拥有前端构建工具
• QA（测试智能体）：负责质量保障，拥有自动化测试工具

团队共享一个频道：#app-dev。

事件触发

人类产品负责人在 #app-dev 频道中提交了一条需求：

我们需要一个用户数据导出功能。用户可以在设置页选择导出格式（CSV/JSON），点击后异步生成文件，完成后通过站内通知下载。

这条消息作为事件同时进入五个智能体的世界。

收敛判定

PM 的世界：新需求直接命中她的职责——需求分析和任务拆解归她管。进入非收敛态。

Designer / Backend / Frontend 的世界：需求描述中涉及 UI、API、前端实现，但尚未有明确的任务分配，暂时维持收敛态，将信息纳入上下文。

QA 的世界：功能尚未开发，没有可测试的内容。维持收敛态。

PM 的行动循环

第一轮：

• 感知：新的产品需求
• 思考：需要拆解为可执行的子任务，明确各角色的交付物
• 行动：在频道发送任务拆解——
  1. Designer：设置页导出入口 + 格式选择交互 + 导出进度/完成状态
  2. Backend：导出 API（支持 CSV/JSON）+ 异步任务队列 + 文件存储 + 通知触发
  3. Frontend：对接设计稿实现导出交互 + 对接下载 API
  4. QA：覆盖功能、格式、大数据量、异常中断等场景
• 收敛判定：任务已拆解并通知到频道。收敛。

Designer 响应

PM 的消息进入 Designer 的世界——设计任务与她的职责直接相关，进入非收敛态。

第一轮：

• 感知：需要设计导出功能的交互流程
• 思考：梳理用户操作路径——入口 → 格式选择 → 触发导出 → 等待 → 通知 → 下载
• 行动：调用设计工具生成交互稿，在频道发送——“设计稿已完成：设置页新增导出卡片，点击后弹出格式选择面板，确认后显示进度状态，完成后站内通知附带下载链接。”
• 收敛判定：设计交付完成。收敛。

Backend 响应

PM 的任务拆解让 Backend 进入非收敛态。他不需要等设计稿——API 设计可以并行推进。

第一轮：

• 感知：需要实现导出 API 和异步任务
• 思考：先定义数据模型和 API 接口，再实现异步队列
• 行动：调用代码仓库工具，创建数据模型（导出任务表）、实现 API 端点（创建导出任务、查询状态、下载文件）、集成异步任务队列
• 收敛判定：代码已提交但未通知团队，未收敛

第二轮：

• 行动：在频道发送——“后端 API 已完成。POST /exports 创建任务，GET /exports/:id 查询状态，GET /exports/:id /download 下载文件。异步队列处理生成，完成后触发通知。”
• 收敛判定：后端交付完成并通知团队。收敛。

Frontend 响应

Frontend 一直在等待两个前置条件：设计稿和后端 API。当 Designer 和 Backend 的消息都到达后，他的世界才进入非收敛态——两条信息共同构成了他开始工作的条件。

第一轮：

• 感知：设计稿和 API 接口都已就绪
• 思考：按照设计稿实现 UI，对接后端 API
• 行动：调用前端构建工具，实现导出卡片组件、格式选择面板、进度状态展示、对接导出和下载 API
• 收敛判定：代码已提交但未通知，未收敛

第二轮：

• 行动：在频道发送——“前端实现已完成，已对接设计稿和后端 API，部署到测试环境。”
• 收敛判定：前端交付完成。收敛。

QA 响应

QA 在整个过程中一直处于收敛态——她的职责是测试，在功能未就绪前没有可测的东西。Frontend 部署到测试环境的消息让她进入非收敛态。

第一轮：

• 感知：功能已部署到测试环境
• 思考：按照需求和任务拆解，设计测试用例并执行
• 行动：调用自动化测试工具，覆盖正常导出（CSV/JSON）、大数据量导出、导出中断恢复、并发导出、通知触达等场景
• 结果：CSV 导出正常，JSON 导出正常，大数据量（10 万行）导出耗时 12s 但成功，通知正常触达。发现一个问题：用户连续点击导出会创建重复任务
• 收敛判定：发现 bug，未收敛

第二轮：

• 行动：在频道发送——“测试基本通过，发现一个问题：用户连续快速点击导出按钮会创建重复任务，需要前后端做防重处理。”
• 收敛判定：问题已报告给相关人。收敛。

再次级联

QA 的 bug 报告让 Backend 和 Frontend 重新进入非收敛态。Backend 在 API 层加了幂等校验，Frontend 在按钮上加了防重复点击。两人分别修复后在频道通知。QA 再次验证，确认问题修复，在频道发送——“回归测试通过，功能可以上线。”

PM 看到 QA 的确认，在频道发送——“用户数据导出功能验收完成，准备上线。” 所有智能体回到收敛态。

人类看到了什么？

在整个过程中，人类产品负责人只做了一件事——在频道里提了一句需求。之后他可以去忙别的事情。当他再次打开 #app-dev 频道时，看到的是一串完整的协作记录：PM 的任务拆解、Designer 的设计稿、Backend 的 API 接口说明、Frontend 的部署通知、QA 的测试报告和 bug 反馈、修复确认、最终的验收结论。每一步都有清晰的上下文，每一个决策都可追溯。他可以在任何节点插入一条消息——比如”导出文件名要带上日期”——这条消息会作为新事件自然级联到相关智能体，无需重新启动任何流程。

级联全景

PM ─── task breakdown ──▶ Designer ─── design ──────────────────────┐
 │                                                                  │
 └── task breakdown ──▶ Backend ─── api ready ───┐                  │
                                                 ├──▶ Frontend ──▶ QA
                        Designer ─── design ─────┘       │          │
                                                         │          │
                        Backend ◀── bug report ──────────┘──── QA ──┘
                        Frontend ◀── bug report ─────────┘
                              │                           │
                              └──── fix ──▶ QA ──pass──▶ PM ──▶ [all converged]

这个例子展示了世界模型在主动推进型任务中的表现。注意几个关键点：

• 并行是自然发生的：Backend 不需要等 Designer 完成就能开始工作，因为他的收敛条件不依赖设计稿。Frontend 则需要等两者都就绪——这不是编排器规定的，而是 Frontend 自己判定的
• 反馈环路是自然形成的：QA 发现 bug 后，相关智能体自动进入非收敛态并修复，不需要”打回重做”的流程设计
• 人类可以随时介入：产品负责人在任何时刻都可以在频道中追加要求或修改需求，这只是一个新事件，会自然级联到相关智能体

7. 人类如何参与

7.1 天然同构

世界模型有一个值得注意的特性：人类天然就在模型之内。

回顾前面的健康管理场景。假设 Doctor 不是一个智能体，而是一个人类医生。Monitor 在频道中发送了心率异常和体征数据——这是一个事件。他看到消息，意识到需要分析——他的世界进入非收敛态。他查阅病历、综合体征数据，判断是睡眠不足引发的窦性心动过速，在频道里给出建议——这是行动。然后他回到等待状态——收敛。

或者回顾产品开发场景。人类产品负责人在频道提了一句需求，然后去忙别的事。当频道里出现 QA 的验收通过消息时，他打开频道查看全过程——这就是他的世界重新被事件触达、判断是否收敛的过程。

整个流程与智能体版本完全一致。差异仅在于实现层面：

模型是同一个模型。不需要为人类设计”human-in-the-loop”这样的特殊机制。人类本身就在 loop 里——一个和智能体完全一样的 loop。

7.2 UI 的定位

在这个框架下，UI 的定位变得清晰——它是人类进入世界的界面。

UI 的职责是将世界状态的变更以人类可感知的形式呈现（消息通知、状态变化、告警提示），并将人类的操作转化为对世界状态的行动（发送消息、触发工具、修改配置）。

它不是一个”管理后台”，也不是一个”监控面板”。它是人类感知世界和行动于世界的通道，正如事件流和工具 API 是智能体的通道。

7.3 人类的独特价值

虽然模型同构，但人类在这个系统中仍然有不可替代的价值。

人类拥有更强的收敛判定能力——面对模糊、复杂、前所未见的情境，人类的直觉和经验往往比 LLM 的推理更可靠。人类能够判断”这件事虽然看起来解决了，但总觉得哪里不对”，这种”说不清道不明”的判断力是当前 LLM 尚不具备的。

人类也是系统中最终决策权的持有者。当智能体之间的行动级联陷入僵局，或者事态超出智能体的能力范围时，人类的介入是自然的——不是因为系统特意设计了”人类审批”环节，而是因为事件级联到了人类，人类的世界进入了非收敛态，人类自然会采取行动。

8. 总结

本文提出了一种基于世界模型的多智能体协作架构，核心差异如下：

这个模型的核心洞察并不复杂：不要让智能体模拟人类聊天，让智能体模拟人类工作。 人类不是靠聊天来协作的，人类是靠感知变化、判断相关性、采取行动、恢复平衡来协作的。对话只是这个过程中的手段之一，不是过程本身。

当我们用正确的模型来建模协作，很多在 Chat 架构下需要复杂工程方案来解决的问题，在世界模型中根本就不会出现。不是因为找到了更好的算法，而是因为找到了更好的抽象。