企业系统是否需要学习世界模型？上下文对推断动力学的重要性 Do Enterprise Systems Need Learned World Models? The Importance of Context to Infer Dynamics
可读规则下运行时发现优于离线世界模型
前置知识
世界模型（World Model）
世界模型是智能体用以预测环境状态转移 $s_{t+1} \sim P(s_{t+1}|s_t, a_t)$ 的内部表示，常见做法是通过离线轨迹数据拟合潜变量动力学（如 Dreamer、I-JEPA）。它把'环境如何响应动作'压缩进模型参数，使智能体在不执行真实动作的情况下做规划。
本文质疑的是这条路线在企业场景下的有效性——企业系统里规则是显式可读的，把规则'内化'进权重是否必要、是否划算，是全文论证的起点。
业务规则与级联（Cascade）
业务规则（Business Rule, BR）是企业平台（如 ServiceNow）里依附于数据表的服务器端脚本，在记录被插入/更新/删除时按优先级触发。一个动作可能引发多条规则连锁执行，横跨多张表并启动 SLA 计时器，这就是'级联'。级联深度和分支完全由实例配置 $c$ 决定。
级联是企业动态性的核心载体，也是离线世界模型在分布漂移下崩溃的根本原因；理解级联是看懂 CascadeBench 设计的前提。
多租户与部署漂移（Deployment Shift）
企业平台通常服务多个客户（租户），每个租户拥有独立部署实例和独立业务规则集 $c$。同一动作 $a_t$ 在不同租户可能产生完全不同的 $s_{t+1}$。在租户 A 上训练的世界模型到租户 B 上评估时，性能会因 $c$ 改变而下降，这就是部署漂移。
本文论证'学习的世界模型跨租户会脆裂'的实证依据就来自这种漂移设置，CascadeBench 也按行业-规模组合做了未见过的租户留出。
ReAct 与检索增强推理
ReAct（Yao et al., 2022）是一种让 LLM 在'思考-动作-观察'循环里调用工具的方法，每一步 LLM 决定调用哪个工具、传什么参数，得到结果后再决定下一步。本文 Discovery Agent 就是把单一工具 `snow_query` 暴露给模型，让它自主查询业务规则、当前记录和 SLA 定义。
Discovery Agent 的整个工作机制就是 ReAct；理解它对看懂图 4 的多步滚动预测和附录 G 的算法伪代码至关重要。
LoRA 微调
Low-Rank Adaptation 是一种参数高效微调方法，在冻结原有权重的基础上，向注意力层注入低秩矩阵 $B A$（其中秩 $r$ 远小于隐藏维度）。本文用 LoRA（$r=16$, $\alpha=32$）在 27-31B 参数的开放模型上微调，训练 2 个 epoch、AdamW、cosine 学习率。
论文 Rung 2 的核心对比就是 LoRA 微调版 vs 基座版，结论是同分布测试 91.6 vs 40-41 IoU 的崩塌来自过拟合到训练租户的规则集。
研究动机
现有 LLM Agent 在企业系统里的部署越来越普遍，但它们如何理解环境动力学仍是开放问题。传统思路是学习一个世界模型把企业动态内化进参数，类比 Dreamer 在 Atari、I-JEPA 在视频上的做法。但企业系统有一个根本不同点：业务规则（BR）随租户和部署实例变化，并随时间演化（管理员会持续修改规则）。这意味着在租户 A 上用 $(s_t, a_t, s_{t+1})$ 三元组训练的世界模型，到了租户 B 上会因为 BR 配置不同而失效。论文用 CascadeBench 上的数据给出了实证：当把 BR 从提示中拿掉，所有模型（Sonnet 4.6、Opus 4.6、GPT-5、Gemini 3 Pro）在 9-16 IoU(T+F) 的低位徘徊；而同样模型加上 BR 后跃升到 38-51 IoU(T+F)——几乎所有判别力都依赖 BR 提供，而非模型权重。
本文的目标是论文要回答的核心问题是：当企业系统的转移规则在推理时可被读取时，Agent 是否还需要学习它们？具体目标有三：(1) 形式化企业动态为配置相关的转移函数 $s_{t+1} \sim P(s_{t+1}|s_t, a_t, c)$，其中 $c$ 是实例配置；(2) 提出 CascadeBench，一个用合成 schema 隔离记忆/检索干扰、专注于级联预测推理能力的基准；(3) 提出 Enterprise Discovery Agent（DA），通过运行时检索 $\tilde{c} \subseteq c$ 来恢复转移逻辑，而非依赖内化参数。
与已有工作不同的是，现有企业 Agent 基准（WorkArena、CRMArena、EnterpriseOps-Gym、World of Workflows 等）主要评估任务执行，WoW 虽然评估转移预测但只评估零样本、固定配置，没考虑租户切换时的漂移。另一条技术线（WebDreamer、Code World Models、GTM）继续沿'学习近似器模拟环境响应'的路走，没人质疑'规则可读时是否有必要走这条路'。本文独特定位在'可读 vs 不可读'的边界——把 BR 配置当作可查询对象而非预训练对象，论证发现策略比内化策略在跨租户场景下更稳健。这是一条与 WoW 互补但视角相反的路线：WoW 测'模型在零样本下能预测多少'，CascadeBench 测'给定规则模型能推理多少'，中间的差就是发现策略能补的洞。
核心方法
方法思路沿一条'假设-形式化-基准-对比'的链条推进。先把企业动态定义为 $P(s_{t+1}|s_t, a_t, c)$，把租户配置 $c$ 从隐变量变成可查询的显式对象；再构造一个叫 Enterprise Gym 的合成企业世界生成器（覆盖 6 个行业、11 个领域、64 个世界、27,243 条转移样本），并在此基础上构建 CascadeBench；最后在同一基准上比较三条路线——冻结模型的提示基线、用 LoRA 在转移数据上微调的学习世界模型、以及通过检索恢复规则的发现 Agent。直觉上，论文想验证'把规则内化进权重 vs 在推理时去读规则，哪种迁移性更强'。
核心创新是和世界模型范式的对立：当转移规则在推理时可被读取（业务规则、配置表），Agent 不应只依赖从历史转移数据中内化出的动力学，而应在每一步决策前去查询实例配置 $\tilde{c}$ 来重建当前转移函数。这和已有方法（WebDreamer、GTM、I-JEPA 全部内化）形成结构性差异。Discovery Agent 不用微调参数，而是用 retrieve-then-reason 策略 $\hat{s}_{t+1} = f_{\text{LLM}}(s_t, a_t, \tilde{c}, \hat{s}_{1:t})$，让同一冻结 LLM 通过工具调用跨租户迁移。另一个隐性创新是 CascadeBench 的设计：用合成 u_ 前缀 schema 排除真实平台表的记忆效应，按 Tier 1/2/3 三档难度分层，把 IoU(T+F) 与严格 IoU 分离，前者衡量定位级联足迹的能力，后者衡量预测具体值的精度。
方法步骤详情
方法分四步实施。第一步是 Enterprise Gym 世界构造，按 7 阶段依赖顺序流水线生成（组织结构 → 配置数据库拓扑 → 流程设计 → BR → 访问策略 → SLA → 字段约束），从约 27,000 个 LLM 生成的基场景经过程序化增强扩展到约 802,000 个有效初始状态，并通过 7 项质量护栏保证一致性。第二步是 CascadeBench 构造：先由 LLM 生成 u_ 前缀的合成 schema（避开 itam/cmdb/itsm/hr 等真实平台前缀），再用 14 项确定性校验生成 3-7 条规则的级联（拓扑含 flat/linear/complete graph），最后在真实 ServiceNow 实例上执行触发动作，用 sys_audit 抓取字段级变化作为 ground truth，并过滤掉系统元数据字段。第三步是三类方法实现：(a) 提示基线用冻结 LLM 接收 $(s_t, a_t)$ 及可选上下文，输出字段级 diff；(b) 学习世界模型用 LoRA（rank 16, α=32, 2 epoch, AdamW + cosine）在 $(s_t, a_t, s_{t+1})$ 三元组上微调 Qwen-3.5/3.6-27B 和 Gemma-4-31B；(c) Discovery Agent 用 ReAct 框架 + 单一 `snow_query` 工具（最多 15 次递归调用），系统提示把模型定位为 ITSM 领域专家，按 '推理 → 查询 sys_script/sys_choice/contract_sla/目标表 → 更新上下文' 循环输出 JSON 格式预测，再经 DiscoveryPostProcessor 抽取（先 fenced code block，再贪婪正则）。第四步是评估设置：CascadeBench 分 w/BR（oracle 上限）和 w/oBR（提示基线下限）两种上下文，并跑 Tier 1/2/3 分层；WoW 上做多步滚动预测 $k=1..5$ 以衡量级联预测中的误差累积。
技术新颖性
技术新颖性体现在三个层面。理论上把企业动态正式拆为 $P(s_{t+1}|s_t, a_t, c)$，强调 $c$ 是显式可读且随租户变化，这与经典世界模型把 $c$ 当隐变量学习的假设根本对立。基准上 CascadeBench 通过合成 schema + 上下文控制 + 内容字段过滤三重机制把'记忆'、'检索'、'推理'三个信号解耦，比 WoW 多了对'跨租户漂移'的显式建模——后者只评估固定配置的零样本。方法上 Discovery Agent 的 retrieve-then-reason 公式 $\hat{s}_{t+1} = f_{\text{LLM}}(s_t, a_t, \tilde{c}, \hat{s}_{1:t})$ 第一次把'何时/查询什么/怎么组合'作为运行时决策而非训练时的归纳偏置，并通过 Tier 3 结果揭示了'配置可读但执行顺序不可读'的边界。
实验结果
实验结果沿三条'rung'展开，每条都对应一个具体主张。Rung 1（提示 vs 微调在 w/oBR 上的差异）：在 CascadeBench w/oBR 条件下，前沿模型和基座开放模型的 IoU(T+F) 都在 9-16 区间（其中 Sonnet 4.6 10.53、Opus 4.6 16.15、Gemini 3 Pro 13.92），微调后基座提升约 2-3 IoU 点（Qwen-3.6-27B-LoRA 从 13.15 到 13.40），而 WoW 上微调提升更大（约 10 点）。但在 w/BR 条件下，SFT 不是统一受益：Qwen-3.5-27B-LoRA 反而达到 50.90 IoU，超过所有提示基线的 38-42 区间，说明 BR 上下文比内化更关键。Rung 2（分布内 vs 分布外）：图 3 显示 Gemma-4-31B-LoRA 在分布内测试集冲到 91.6 IoU、Qwen-3.6-27B-LoRA 冲到 82.0 IoU，远超基座的 30-40 区间；然而在 CascadeBench（合成 schema、规则未见过）上两者都掉到 40-41 IoU，几乎丧失分布内优势——这是过拟合到训练租户规则集的强证据。Rung 3（运行时发现 vs 静态提示）：表 2 比较 Oracle（有规则上下文上限）、Discovery Agent（运行时检索）、Prompted（无规则下限）：前沿模型 GPT-5/Opus 4.6/Sonnet 4.6/Gemini 3 Pro 在 Prompted 列只有 9.82/10.91/10.30/10.38，但 Discovery Agent 跃升至 32.1/32.0/29.7/31.2，恢复到 Oracle 列 41.78/40.46/38.15/41.36 的 70-80%。LoRA 模型上检索 vs 内化结果更微妙：Qwen-3.6-27B-LoRA 检索得 28.8，超过其 Oracle 的 40.47 之外的纯内化水平。WoW 多步滚动（图 4）显示 Discovery Agent 在 $k=1..5$ 全部超过匹配提示基线，最大提升约 0.10 IoU（Opus 4.6 在 k=1 从 0.395 到 0.448，Sonnet 4.6 从 0.323 到 0.438），且优势在更长 horizon 仍可见，说明运行时刷新能抵消部分误差累积。Tier 分层（图 5，表 4）给出更精细的诊断：Tier 1（schema 决定）在 Direct 提示下就能到 0.56-0.60 IoU，但 Tier 2（规则级联）和 Tier 3（执行推断）在 Direct 提示下全军覆没到 0.00；Discovery Agent 把 Tier 1/2 拉到 Oracle 持平（DA − Oracle 在 T1 是 +0.014、T2 是 +0.001），而 Tier 3 DA 比 Oracle 低 0.046——这是'配置可读但执行顺序不可读'的硬边界。失败模式分析（附录 H）进一步把 oracle 自身的 38-50% 上限定性化：AP Invoice 级联里 6 条规则仅前 2 条被准确预测（深度 1-2 召回 75-85%，深度 ≥3 召回仅 11%），根因分三类 P1（insert 漏掉，占 24-27% 召回）、P2（深度 ≥3 的级联淡出）、P3（单记录假设，把 `while (gr.next())` 循环当成单条）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| CascadeBench w/BR（Oracle 条件，给定 BR 上下文） | IoU(T+F) | GPT-5 61.50、Opus 4.6 59.69、Sonnet 4.6 57.67、Qwen-3.5-27B-LoRA 61.47 | 基座模型：Qwen-3.5-27B 60.86、Qwen-3.6-27B 60.06、Gemma-4-31B 60.32 | 前沿模型在 w/BR 上比 w/oBR 提升约 47-50 个 IoU 点（从 10 区间跃升到 60 区间），证明 BR 上下文是企业转移预测的决定性信号 |
| CascadeBench w/oBR（Discovery Agent 运行时检索） | IoU(T+F) | GPT-5 32.1、Opus 4.6 32.0、Qwen-3.6-27B-LoRA 28.8、Qwen-3.5-27B-LoRA 21.5、Gemma-4-31B-LoRA 12.5 | 同模型 Prompted：GPT-5 9.82、Opus 4.6 10.91、Sonnet 4.6 10.30、Gemini 3 Pro 10.38 | Discovery Agent 恢复约 20-22 个 IoU 点（从 10 区间到 28-32 区间），达到 Oracle 列 70-80% 的水平；其中 GPT-5 恢复幅度最大（+22.3 点） |
| WoW 多步滚动预测 | IoU（k=1..5） | Opus 4.6 DA: k=1 0.448, k=2 0.352, k=3 0.335, k=4 0.301, k=5 0.199；Sonnet 4.6 DA: k=1 0.438, k=2 0.314, k=3 0.296, k=4 0.275, k=5 0.189 | Opus 4.6 Prompted: k=1 0.395, k=2 0.253, k=3 0.228, k=4 0.197, k=5 0.105；Sonnet 4.6 Prompted: k=1 0.323, k=2 0.195, k=3 0.190, k=4 0.193, k=5 0.122 | Discovery Agent 在所有 horizon 上稳定超越 Prompted 基线；最大提升 0.10 IoU（k=1 阶段），优势在 k=5（长程）仍保持 ~0.09 IoU，验证运行时刷新抵消级联误差累积的假设 |
| 分布内测试 vs CascadeBench（OOD 漂移评估） | IoU | Gemma-4-31B-LoRA 分布内 91.6、CascadeBench 上 41.33；Qwen-3.6-27B-LoRA 分布内 82.0、CascadeBench 上 40.47 | Gemma-4-31B 基座分布内 ~30、CascadeBench 60.32；Qwen-3.6-27B 基座分布内 ~30、CascadeBench 60.06 | 微调在分布内带来 50+ IoU 的暴涨，但在 CascadeBench（合成 schema、规则未见过）上几乎崩溃到 40-41——这是关键的'内化收益不可迁移'证据，揭示 SFT 绑死在训练租户规则集 |
| CascadeBench Tier 分层（前沿模型） | IoU（T1/T2/T3） | GPT-5 Discovery Agent: T1 0.642, T2 0.639, T3 0.551；Opus 4.6 DA: T1 0.633, T2 0.633, T3 0.545 | GPT-5 Direct 提示: T1 0.580, T2 0.000, T3 0.000；Opus 4.6 Direct 提示: T1 0.562, T2 0.043, T3 0.000 | Discovery Agent 在 T2（规则级联）上从 0.000 跃升到 0.62+，几乎追平 Oracle（T1/T2 DA-Oracle 差距 ≤0.014），但 T3 仍有 0.046 的硬缺口，体现执行推断的边界 |
局限与改进
作者明确承认四点局限：(1) 可读性假设——Discovery Agent 假设 BR 在实时实例上可读，生产环境的访问控制一旦收紧就会退化为 Prompted 基线；(2) 工具能力瓶颈——在 27-31B 参数的开放模型上 ReAct 检索循环不可靠，Gemma-4-31B-LoRA 在 DA 列反而只有 12.5 IoU，低于其 LoRA 内化的 41.33，说明'训练 vs 发现'的选择是部署依赖的；(3) 单平台评估——实验仅在 ServiceNow 上做，其他企业平台的规则形式和级联语义未验证；(4) Tier 3 操作化受限——多规则冲突靠 sys_audit 区分，但异步/同步交错、并行规则竞态等更深层执行语义没单独分层，因为审计日志无法解析执行顺序。我自己观察到的额外限制包括：评测只覆盖 k≤5 的滚动，真实企业的级联深度可达数十层，长程稳定性未充分检验；CascadeBench 用合成 u_ 前缀表排除了记忆但也意味着实际企业部署很少有如此干净的隔离；Failcase 分析（附录 H）显示即便 Oracle 也有 30-40% 召回缺口，问题在 LLM 推理而非检索，但论文没有给出对应的训练缓解方案。
独立分析的弱点
独立审视论文，有几个具体弱点值得指出。第一，Discovery Agent 与提示基线的对比在公平性上存疑——DA 使用了静态上下文 + 运行时检索 $\tilde{c}$，而 Prompted 用了匹配的静态上下文却没有检索，这意味着 DA 多花的推理预算（最多 15 次 snow_query 调用）在某些情况下可能直接堆给提示也能拿到（论文未做控制变量）。第二，CascadeBench 的 Tier 3 操作化只覆盖'两条规则写同字段值不同'这种审计可检测的冲突，附录 H 里的真实级联复杂度（while 循环、嵌套插入、并行规则）超出了 Tier 3 定义边界，但论文在 Tier 分层表里只报 T3=0.00 显得过于干净。第三，WoW 的 DA-vs-Prompted 提升虽然稳定但绝对值小（k=5 上仅 +0.05 到 +0.09 IoU），对'发现优于内化'的强主张缺乏对应的统计显著性检验。第四，'同模型比较'只覆盖 Qwen-3.5/3.6-27B 和 Gemma-4-31B 三个开放权重（LoRA 可行）模型，没有跨更大的模型规模验证，使得'检索优于内化'的结论推广性受限。改进方向：在 DA vs Prompted 之间加入'无检索但有多轮自我反思'的对照组、给 IoU 加 bootstrap 置信区间、扩展到 GPT-OSS 或更大开放模型做规模扫描。
未来方向
作者在第 8 节明确指出下一步是'训练会主动检索的 Agent'——把'何时查、查什么、怎么组合规则'从硬编码的 ReAct 循环变成可学习的策略，可以借用 RL 或 process reward 来训练 discovery 的效用。论文 9 节还提到要把 Tier 3 扩展到异步/同步交错与执行顺序分析，需要解析 sys_audit 之外的引擎日志。基于现有成果可延伸的方向：(1) 把 CascadeBench 推广到非 ServiceNow 平台（Salesforce、SAP、Workday），验证'可读规则+发现'范式是否跨企业平台通用；(2) 把 Discovery Agent 与 World Model 结合——用世界模型做 Tier 1 的快速近似，把检索预算留给 Tier 2/3 的关键规则，形成混合推理；(3) 把附录 H 揭示的 P1（插入漏掉）/P2（深度级联淡出）/P3（单记录假设）三类失败模式作为训练信号，专门微调'级联组合推理能力'；(4) 研究 BR 的访问控制如何在不暴露完整规则的前提下仍支持 discovery，例如对规则条件做差分隐私化或对 agent 的查询做信息瓶颈约束。
复现评估
复现难度中等偏上。优点是：(1) CascadeBench 的构造流水线描述详细（附录 D），从 schema 生成、级联拓扑（flat/linear/complete graph）、14 项确定性校验到 sys_audit 抓取，全程可重现；(2) Enterprise Gym 的 27,243 条转移样本可由附录 E 的 7 阶段流水线加 7 项质量护栏重建；(3) 三类方法（提示、LoRA 微调、ReAct DA）的实现细节齐全——超参表（LoRA rank 16/α 32、AdamW β1=0.9 β2=0.95、2 epoch、Qwen 学习率 1e-4、Gemma 学习率 2e-4、Qwen 32k 上下文、Gemma 12k 上下文）都给在附录 I；(4) Discovery Agent 用 SyGra（Pradhan et al., 2025）开源框架编排，单一 snow_query 工具，附录 G 还给了完整伪代码（算法 1 的外层自回归 + 内层 ReAct + 后处理三步）。缺点是：(1) 数据生成和评估都需要真实 ServiceNow 实例，公开复现门槛高——没有租户账号的话，Enterprise Gym 的'在沙箱里执行真实动作'这一步无法绕过；(2) 部分对比模型（Sonnet 4.6、Opus 4.6、GPT-5、Gemini 3 Pro）依赖商业 API 且时间锁定；(3) LoRA 权重和 Enterprise Gym 数据集未声明开源情况；(4) Discovery Agent 的 15 次递归调用上限是经验值，未做消融。
论文图表
左半部分展示 CascadeBench 在多租户企业环境与不同配置复杂度层级上评估 Agent，给定当前状态 $s_t$ 与动作 $a_t$ 预测下一状态 $s_{t+1}$；右半部分对比学习世界模型（内化动力学，分布内好但漂移下退化）与 Discovery Agent（运行时查询实例配置，在漂移下更稳健）
这是论文的总览图，一图讲清'为什么需要 CascadeBench'和'为什么需要 Discovery Agent'两条主线，是引言部分最核心的视觉化