6.6 智能体与世界模型

前五节讲的都是一次调用的模型：给输入，拿输出。但真实任务很少一次做完——查资料、写代码、跑测试、看报错、再改，这是一个持续多轮、与外部世界交互的过程。

本节处理两件事，它们常被混在一起谈但其实是不同层次的问题：

智能体（agent）：把「模型 + 工具 + 记忆 + 循环」组装成一个会持续行动的系统（6.6.1–6.6.6）。它的「世界」是外部环境，模型只能调用它。
世界模型（world model）：让模型在内部模拟环境的演化，从而可以在「想象」里规划（6.6.7–6.6.8）。它的「世界」是模型自己学出的动力学。

两者的连接点是同一个问题：当模型输出「看起来会规划」的文本时，它到底做了多少真实的搜索与验证？（6.6.9）

6.6.1 ReAct：推理—行动—观察的循环

定义 6.6.1 · ReAct 循环（reason + act）

在每个时间步 $t$ ，智能体维护一个轨迹前缀（历史），并交替生成两类内容：

$\underbrace{\text{Thought}}_t\ \to\ \underbrace{\text{Action}}_t\ \to\ \underbrace{\text{Observation}}_t\ \to\ \text{Thought}_{t+1}\ \to\ \cdots$

Thought（内部推理）：由模型自己生成的中间文字，不改变外部世界（「我需要先查一下这个函数的签名」）；
Action（行动）：以结构化格式发出的调用（搜索 / 计算 / 代码执行 / 读写文件 / 请求用户），格式由系统约定（6.6.2）；
Observation（观察）：外部系统返回的结果（可能成功、可能报错），被拼回上下文作为下一轮 Thought 的条件。

关键结构事实：Observation 不由模型生成。这使循环获得了一个模型无法伪造的信息通道——这也是 ReAct 与「让模型自己编一整套推理」的实质性差别。

为什么「与外部交互」比「想得更久」更有价值

回到 6.3.1 的结论：提示不能创造模型里没有的知识。当任务需要的信息不在模型里（今天的股价、你公司私有代码库、某个库的最新 API），任何长度的思考都无法补上——只能去查。

ReAct 的价值因此有三层：① 信息获取（把外部世界变成上下文）；② 错误外部化（能拿到真实报错，而不是猜自己错在哪）；③ 状态持久化（把中间结果写进环境——文件、变量、数据库——而不是全压在上下文里，这直接缓解 6.1.6 的上下文预算问题）。

代价同样直接：每轮都增加延迟与成本（多次模型调用 + 工具往返）；更麻烦的是循环不可控——模型可能反复调用同一个工具、陷入无效重试、或者在无进展时继续烧预算。因此实际的智能体系统必须有终止条件与预算上限，这不是可选项。

6.6.2 工具调用与 function calling

定义 6.6.2 · 工具调用（tool use / function calling）

把可用工具以结构化描述注入上下文（名称、说明、参数 schema），模型不再生成自然语言里的「我要查天气」，而是生成一段可解析的调用：

{"name": "get_weather", "arguments": {"city": "北京", "date": "2025-03-01"}}

宿主程序解析这段输出、执行真实函数、把返回值作为 Observation 拼回上下文。模型从不执行任何东西——它只生成文本，执行发生在宿主侧。

这一区分不是学术洁癖：它决定了权限边界在哪里。模型能做的上限，等于宿主授予的工具集合；一个只暴露「读」工具的智能体无法写文件，与模型的「意愿」无关。

function calling 真正的技术含量在 schema 设计

模型能不能用好一个工具，主要不取决于模型，而取决于工具描述写得好不好。这是「agent-experience」式的接口设计问题，四条经验：

参数要薄：一个工具做一件事。参数越少、越自解释，模型调用错误率越低。给一个「万能工具」带 12 个可选参数，模型几乎必然用错。
名字要动词化且具体：search_flights 优于 query。名字是模型最主要的语义线索。
错误要结构化返回：返回 {"error": "rate_limited", "retry_after": 5} 远好于抛一段栈。模型能据此改变策略；而一段非结构化报错常常引发无意义的重复调用。
幂等性要显式：写明哪些工具可以安全重试。智能体会重试——如果重试有副作用（下单、发邮件），这是事故源头。

例 6.6.1 · 给一个「订机票」助手设计工具集

需求：用户说「帮我订下周三去上海的机票，尽量上午到」。设计工具集，并说明每个设计决策对应的失败模式。

解

坏设计（常见初稿）：

book_trip(details: string)   # 一个工具，字符串参数

失败模式：模型把所有信息塞进一个自由文本字段，宿主无法可靠解析；订错日期 / 舱位 / 乘机人；出错后模型无法知道哪一步错了；且不可重试（一次调用可能已下单）。

好设计（拆成可检查的步骤）：

工具	参数	类型	幂等	对应设计意图
`search_flights`	`origin, destination, date, earliest_departure?, latest_arrival?`	只读	✅ 可重试	查询与下单分离——先看选项再决定
`get_flight_detail`	`flight_id`	只读	✅	把「选哪个」所需的信息（经停、行李额）拿到手
`hold_seat`	`flight_id, passenger, ttl_minutes`	预留	⚠️ 有限重试	加一个可撤销的中间态：把不可逆操作推到最后一刻
`confirm_booking`	`hold_id, payment_method`	有副作用	❌ 绝不重试	唯一真正扣款的动作，需要显式确认
`ask_user`	`question, options?`	交互	✅	给模型一条「信息不足时问人」的退路（6.7.4 的弃答思想）

关键设计原则（三条，可迁移到任何智能体）：

把不可逆操作单独隔离，并且必须由用户或策略显式确认。这等价于给智能体加了一个「提交」闸门。
每一步都给出可检查的中间产物（flight_id、hold_id），这样出错时能定位到具体一步，而不是「订错了」。
提供 ask_user。一个没有提问能力的智能体，在信息不足时的唯一选择是猜——而猜在订票这种任务上代价很高。

验证方式：给 20 条对抗性指令（日期歧义、「下周三」跨月、「尽量上午到」不可满足、同一乘客重复下单）测调用轨迹，检查是否出现「未经确认的 confirm_booking」。这条检查比总体成功率重要得多。 $\blacksquare$

∎

6.6.3 工具协议：MCP 一类标准化接口

当工具数量增长，「每个应用自己定义一套调用格式」就变成了重复劳动：同一个「读数据库」能力要在 N 个框架里各写一遍。工具协议要解决的就是这个 × 个应用的重复问题。

定义 6.6.3 · 模型上下文协议（Model Context Protocol, MCP）

MCP 是一套客户端—服务器式的开放协议（Anthropic 于 2024 年提出并公开规范，无 arXiv 编号，引用请指向官方规范页面），用 JSON-RPC 消息在两端之间传递信息。典型角色划分：

角色	职责	例子
MCP 主机（host）	运行模型的宿主应用，管理会话与权限	一个 IDE、一个聊天客户端
MCP 客户端（client）	协议实现方，与服务器建立连接	宿主内部的连接管理器
MCP 服务器（server）	暴露具体能力：`tools`（可调用动作）、`resources`（可读数据）、`prompts`（预置模板）	一个「文件系统」服务器、一个「数据库」服务器

解耦的价值：一个能力（例如「查询公司知识库」）只要实现一次，就能被任何支持该协议的宿主使用；宿主更换模型、更换框架，能力的复用不受影响。这与「一次编写、多处调用」的插件生态逻辑一致。

协议化之后，真正的难题变了

标准化解决了「重复实现」，但把问题上移了一层。剩下的三件事一个也没被协议解决：

权限与授权。协议规定「怎么调用」，不规定「谁可以调用什么」。当一台服务器能读写你的文件系统时，授权模型（谁能连、能连哪些、是否需要逐次确认）成为主要风险面。
信任边界。工具返回的内容是外部数据，可能是不可信的（一个网页服务器返回的内容里可能含有针对模型的指令）。工具输出应当被当作数据而不是指令——这是提示注入的入口，属于第 7 讲的范围。
工具发现与选择。当可用工具从 5 个变成 500 个，「选对工具」本身变成一个检索问题；把全部工具描述塞进上下文会挤爆窗口。这直接引出按任务动态加载工具子集的设计。

一句话：协议降低的是集成成本，不降低安全成本。看到「标准化工具生态」这类说法时，要分清它解决了哪一层。

6.6.4 记忆、规划与反思

智能体的三件套：记忆 / 规划 / 反思

组件	解决的问题	常见做法	主要失效模式
记忆	上下文有限（6.1.6），长任务的历史放不下	分层：工作记忆（当前上下文）+ 情景记忆（历史交互摘要/检索）+ 语义记忆（外部知识库）；用检索按需取回	检索召回不准导致「记错」；摘要丢关键细节；记忆污染（错误结论被写回长期记忆）
规划	长任务需要顺序决策，直接做会跑偏	先产出计划（任务分解），再逐步执行；或隐式规划（ReAct 式边走边想）	计划过期（环境变化后不重规划）；计划粒度失衡（太粗无法执行 / 太细浪费预算）
反思	重复犯错，不利用失败经验	对失败轨迹做自评、写成经验条目、下次注入上下文	自我评价不可靠（模型「觉得自己做对了」）；把偶然成功归因成规律（过度泛化）

关键提醒：这三件套都不是「让模型更聪明」的技巧，而是上下文工程——它们的共同目标是把「有用的信息」在正确时刻放进窗口，把「没用的信息」移出窗口。因此它们的效果高度依赖检索质量与注入位置（6.1.6 的位置偏差）。

为什么「反思」最容易变成自我欺骗

反思的机制是「让模型评价自己刚才的表现并总结经验」。问题在于：评价者与被评价者是同一个模型、同一份知识。如果它在某题上产生了错误认知，它很可能同样认为那个错误结论是对的——于是反思的输出不是修正，而是给错误结论加盖了一个「已验证」的章。

这与 6.3.4 里「PRM 会被钻空子」和 6.3.6 的奖励过优化是同一结构：用同一个不可靠的判断源做闭环，会放大而不是纠正偏差。

可操作的修正是引入外部信号：单元测试是否通过、编译是否成功、检索到的事实是否支持结论、人类是否确认。只有当反思的依据来自模型之外时，反思才真正有修正力——这也解释了为什么在代码智能体上「跑测试」比「让模型自我检查」有效得多。

6.6.5 编排框架的取舍

从手写循环到框架（选型依据）

层次	形态	什么时候够用	什么时候不够
手写循环	一个 `while` 循环 + 工具字典 + 终止条件	工具 ≤ 5 个、流程线性、任务是原型验证	需要并发、需要人工介入、需要状态持久化
工作流编排	把流程写成显式图（节点 = 步骤，边 = 条件）	流程已知、需要可审计、需要重试与回滚	任务太开放，无法预先画图
自主智能体	让模型自行决定下一步做什么	任务开放、无法预先枚举步骤	需要确定性与可审计性的场景（合规、金融、医疗）

判据（三条，按优先级）：

可审计性要求高 → 用显式工作流。 如果出事之后必须能回答「系统当时为什么做了这个决定」，一个自由循环是做不到的。
流程已知 → 不要用智能体。 用确定性代码解决确定性问题，成本低几个数量级，还没有随机性。
只在「决策空间无法预先枚举」时才上自主智能体，并且限制其权限范围（6.6.2 的工具集合就是权限边界）。

框架选择里最容易被忽略的一件事

大部分「智能体框架」解决的是管道问题（调用模型、解析工具、维护状态、重试），不解决能力问题。换成另一个框架，模型能做的任务不会变多；能变的只是工程可靠性（重试、超时、并发、可观测性）。

因此选型问题应被重新表述为：「我缺的是能力还是管道？」 如果任务失败是因为模型搞不清那个领域的问题，换框架不会有任何帮助——该做的是加检索、加工具、加更好的示例，或者换模型。先诊断瓶颈，再选框架，与 6.2.5 的「先诊断数据再改架构」是同一条纪律。

6.6.6 智能体评测：SWE-bench、GAIA、WebArena、OSWorld

四个代表性评测的定位（各自测什么）

评测	任务形态	判定方式	测什么能力	主要局限
SWE-bench（2023, arXiv:2310.06770）	真实 GitHub issue → 提交补丁	仓库的隐藏测试是否通过（需真实执行）	长程代码定位、修改、回归验证	任务来自公开仓库（污染风险）；测试覆盖不足时可通过「绕过问题」拿分
WebArena（2023, arXiv:2307.13854）	自建的真实网站环境（电商、论坛、GitLab 式）中的多步操作	环境状态是否达成目标	网页导航、表单填写、多步状态管理	环境是复刻而非真实站点；可自动化程度受环境设计限制
OSWorld（2024, arXiv:2404.07972）	真实操作系统里的桌面任务（跨应用操作）	系统状态 / 文件产物是否达标	桌面 GUI 操作、跨应用工作流	环境配置敏感、可复现性挑战大
GAIA（2023, arXiv:2311.12983）	需要检索 + 推理 + 工具使用的现实问题	与标准答案比对（多数有确定答案）	「使用工具解决现实问题」的综合能力	单答案判定偏严；题目数量有限、易被针对性优化

共同的评测方法论特征：前三者都在真实执行里判定（跑测试、查环境状态），因此造假成本高、难以靠记忆刷分——这是它们相对静态问答基准的核心优势（对照 6.7.2 的污染机制）。

为什么「执行式判定」是智能体评测的关键进步

静态问答基准的漏洞是：答案可以被记住。执行式判定的漏洞要小得多——你没法「记住」一个补丁能否让某个测试通过，因为那取决于真实的代码库状态。

但它带来新的三类问题：

环境依赖性。同一个智能体在不同操作系统、不同依赖版本下的分数可能差别很大；评测的可复现性成本远高于静态基准。
测试本身的漏洞。如果隐藏测试只覆盖了 bug 的一部分表现，智能体可以写出「让测试通过但不修根因」的补丁——这正是 6.3.5 里规格博弈的实例。
成本与速度。真实执行意味着每个任务都要起环境、跑测试，评测开销比一次问答高几个数量级，这也限制了评测集规模与迭代频率。

结论：执行式判定把「刷榜」的门槛抬高了，但没有消除它。判据应该转向「任务是否真的完成」而不是「测试是否通过」——这是 6.7 整节要展开的主题。

6.6.7 世界模型：在潜空间里想象

换一个方向：不借助外部环境的多轮交互，而是让模型自己在内部预测未来。

定义 6.6.4 · 世界模型（world model）

世界模型是学习环境演化的模型，典型形式是学习状态转移

$p(s_{t+1}\mid s_t,a_t)\qquad\text{或}\qquad p(z_{t+1}\mid z_t,a_t)\ \text{（在潜空间中的表示预测）},$

通常还配一个观测解码器 $p(o_t\mid z_t)$ 与一个奖励预测头 $r(z_t,a_t)$ 。拥有它之后，智能体可以不真动手，而在内部「想象」若干步、用模型做规划（planning）再选动作——这正是第 5 讲里 model-based RL 的核心：先用模型想象、再决策，以提高样本效率。

Dreamer 路线的关键设计：不直接预测像素，而是先学一个紧凑的潜状态（由循环状态空间模型 + 观测编码器得到 $z_t$ ），在潜空间里做前向展开（latent imagination）与价值估计。这让「想象」不必支付渲染像素的代价。

「在潜空间想象」为什么是必要的

在像素空间做 rollout 有两个致命问题：① 太贵——每一步都要生成一整帧图像，展开 50 步就是生成 50 帧；② 太噪——像素级预测里大量细节（纹理、背景）与决策无关，但对损失贡献很大，模型会把容量花在「画得像」而不是「动力学对」上。

潜空间方案把两者一起解决：状态被压成低维表示，动力学预测在这个低维空间进行，成本低、噪声少、且只保留与任务相关的结构。（这也是为什么它和第 4 讲的 VAE 有亲缘关系——都是「用一个紧凑表示承载信息」。）

代价：潜空间是学出来的，它的误差会与动力学误差叠加。更微妙的问题是表示漂移——如果动力学模型的 rollout 走到了编码器没见过的潜区域（out-of-distribution），解码出来的东西可能完全不合理，而模型内部并不知道自己走偏了。

例 6.6.2 · 复合误差：rollout 长度与想象可信度的定量关系

设单步预测的相对误差为 $\epsilon=0.02$ （2%），并假设误差在 rollout 中近似独立累积（这是一个简化假设，实际常常更差——误差会相互放大）。

(a) 预测 $H$ 步后，状态的相对误差大致如何增长？ (b) 若要求「想象状态与真实状态的相对误差不超过 10%」，在 $\epsilon=0.02$ 下最大可用 rollout 长度是多少？ (c) 若把单步误差改善到 $\epsilon=0.005$ ，最大长度变成多少？说明这个改善的价值。

解

(a) 误差按平方根累积（随机游走）或线性累积（系统性偏差），取决于误差性质：

独立随机误差： $e_H\approx\epsilon\sqrt{H}$ ；
系统性偏差（每个模型都会有）： $e_H\approx\epsilon H$ 。

必须区分这两者：前者温和，后者致命。实践中常见的是「早期像随机、后期像系统」——因为错误一旦让轨迹偏离真实分布，动力学模型就进入了它训练时没见过的状态区。

(b) 先按线性（系统性）这一保守假设：

$e_H=\epsilon H\le0.10\ \Longrightarrow\ H\le\frac{0.10}{0.02}=5\ \text{步}.$

按平方根这一乐观假设： $\epsilon\sqrt{H}\le0.10\Rightarrow\sqrt{H}\le5\Rightarrow H\le25$ 步。

两者相差 5 倍——这就是为什么「最大可信 rollout 长度」这个数字必须连同误差模型一起报告，单说一个「可以规划 25 步」是没有信息量的。

(c) 代入 $\epsilon=0.005$ ：

线性假设： $H\le0.10/0.005=20$ 步（从 5 步提升到 20 步，4 倍）；
平方根假设： $H\le(0.10/0.005)^2=400$ 步（从 25 步提升到 400 步，16 倍）。

结论：单步误差降低 4 倍，可规划步数提升 4–16 倍（取决于误差性质）。这解释了为什么世界模型研究把大量精力放在单步预测精度上——它在 rollout 里被指数式（平方根情形下是平方关系）放大。也说明了为什么实践里普遍采用「短 rollout + 频繁重规划 + 用模型做先验而非唯一依据」的组合：不是不知道怎么长规划，而是长规划的误差预算不够。 $\blacksquare$

∎

6.6.8 可交互环境生成与「世界模拟器」之争

两条路线的代表工作

方向	代表	核心做法	产出
潜空间 imagine	Dreamer 系列（2019 起，arXiv:1912.01603；DreamerV3 见 arXiv:2301.04104）	学潜动力学 + 在潜空间做 rollout 训练策略	一个可以「在脑子里练」的策略
从视频学可控环境	Genie（2024，arXiv:2402.15391）	从无标注视频里学「潜在动作」与可交互的环境模型，生成可被动作控制的画面	一个可玩的生成式环境（后续工作见官方页面，无 arXiv 编号，引用时指向官方博客）

「视频生成模型是世界模拟器吗」——两方证据并列

支持方的论证：

要把视频预测得足够好，模型必须隐式学到时间上的因果与一致性（物体不会凭空消失、遮挡关系随运动变化、影子与光源一致）。有研究报告视频模型在规模化后出现了对三维一致性与部分物理直觉的掌握——这是「有世界表征」的行为证据。
生成模型确实可以被「行动条件化」：给定一段输入动作或轨迹，它能生成相应的后续画面，这在形式上就构成了一个 $p(o_{t+1}\mid o_{\le t},a_t)$ 的近似。
作为训练环境或数据放大器的用途不需要它「理解物理」——只要生成的数据足够有用即可，这是一个更弱但更可检验的要求。

反对方的论证：

目的是「像」而不是「对」。 视频模型的训练目标是像素似然（或扩散目标），它优化的是「看起来合理的下一帧」。真实的物理一致性只是压低该目标的副产品，而不是被直接优化的对象（这与 6.1.1 里「优化似然而非事实」是同一个结构性问题，也与 6.4.6 的多模态幻觉同源）。
缺少动作接口与反事实能力。 一个真正的模拟器必须能回答「如果我这样做会怎样」。纯观测预测模型没有动作输入通道，也无法做反事实查询——它只能续写自己见过的统计模式。
复合误差与「看似合理的不一致」（例 6.6.2）：生成模型在长程上会逐渐漂移，而生成的内容仍然看起来很流畅——这种失败比「画面崩坏」更危险，因为它不会被视觉检查发现。
术语的膨胀风险：把强视频生成称为「世界模拟器」，会让下游使用者高估它在规划与控制中的可用性——这是术语造成的工程风险，与模型能力无关。

本教程的表述纪律：不裁定它「是不是」世界模型，而要求任何相关主张附带可检验的口径——在什么任务上、用什么指标、与什么基线比、误差如何随时间增长。没有这四项，主张不成立。（这也是本讲对第 7 讲的「风险分析」方法论的提前演练。）

6.6.9 智能体与世界模型的共同红线

关于智能体与世界模型的五条常见误解

「智能体会思考，因为它的日志里有 Thought」：Thought 是生成的文本，与 6.3.2 的 CoT 是同一个东西——提高表现，但不保证忠实。判断它是否真在推理的证据在外部：工具调用是否有效、结论是否被验证。
「框架让智能体更强」：框架解决管道可靠性（重试、超时、并发、可观测性），不解决能力问题（6.6.5）。换框架不会让模型多会一件事。
「反思能自我纠错」：同源自评会放大而非纠正偏差（6.6.4）。真正有修正力的反思必须有外部信号（测试、检索、人工确认）。
「世界模型的想象可以用来看未来」：内部 rollout 有复合误差，且误差随步数超线性累积（例 6.6.2）。想象是决策的辅助先验，不是仿真器。把「看起来会规划」当成「真的会规划」，是把第 4 讲式的「流畅生成」误当成了「可靠推理」。
「执行式评测（如 SWE-bench）不会被刷分」：它把门槛抬高了，但没有消除（6.6.6）。测试覆盖不足时「绕过问题」同样能拿分——判据要落到任务是否真的完成。

即时自测 · 6.6

Q1 ReAct 循环的三个环节里，哪一个不由模型生成？为什么这一点是它有效性的关键？

Q2 一个 agent 有 500 个可用工具。直接把它们全部放进系统提示会遇到什么问题？有哪些解法？

Q3 为什么「让模型自己反思刚才的错误」往往收效有限？给出一个能真正提高修正率的改法。

Q4 SWE-bench 用隐藏测试判定，为什么这比静态问答更难刷分？它仍有什么漏洞？

Q5 世界模型单步预测误差 $0.01$ ，若错误是系统性的，10 步 rollout 后的相对误差是多少？若改成 $0.002$ ，同样的 10 步误差变为多少？从中说明「单步精度」为什么是世界模型研究的第一优先级。

参考要点

Q1 Observation 不由模型生成，它来自外部系统（工具返回值、报错、文件内容）。这正是 ReAct 的价值：它提供了一个模型无法伪造的信息通道，使得「获取新信息」「拿到真实错误」成为可能——而不是在模型内部猜。结构上它等价于第 5 讲的「智能体—环境」交互循环。

Q2 问题：① 提示长度爆炸，工具描述可能占用上万 token，挤占任务本身的空间（6.1.6）；② 选择困难——500 个相似描述会让模型选错，且错误率随候选数上升；③ 成本上升（每次调用都为全部描述付费）。解法：① 按任务动态加载工具子集（先做技能/域分类，再注入相关工具，本质是一个检索问题）；② 分层工具（先选类别再选具体工具）；③ 精简描述（6.6.2 的「参数要薄、名字要具体」）；④ 对不常用但必要的工具用「发现接口」（先列出能力清单，再按需拉取详细 schema）。

Q3 因为评价者与被评价者是同一个模型、同一份知识：它若在某个结论上已有错误认知，反思很可能会为该错误背书（把它标成「已确认」），于是偏差被固化而不是被纠正。这与 PRM 被钻空子、奖励过优化是同一结构（用不可靠判断源做闭环）。改法：引入外部信号——对代码任务跑单元测试/编译；对事实任务做检索核对；对不可逆操作要求人工确认。只有依据来自模型之外，反思才有修正力。

Q4 更难刷分的原因：判定依赖真实执行（补丁必须让仓库的隐藏测试通过），无法靠记忆答案通过——状态空间太大且取决于真实代码库状态（对照静态问答基准的「答案可被记住」，见 6.7.2）。仍存的漏洞：① 测试覆盖不足——可以写出「让测试通过但不修根因」的补丁（规格博弈，6.3.5）；② 任务来自公开仓库，存在污染风险（题目与其修复在训练数据里可能出现过）；③ 环境依赖导致分数不稳（依赖版本、平台）。

Q5 系统性误差按线性累积： $0.01\times10=0.10$ （10%）。改成 $0.002$ 后： $0.002\times10=0.02$ （2%），改善 5 倍。若误差是独立随机的，则为 $\epsilon\sqrt{H}$ ： $0.01\times\sqrt{10}\approx0.032$ 与 $0.002\times\sqrt{10}\approx0.0063$ 。无论按哪种模型，单步精度都被 rollout 长度放大——这就是为什么世界模型研究把第一优先级给了单步动力学精度，而不是规划算法的花哨程度。

Keyboard shortcuts

深度学习导论 · 定制教程