world_model创建流程

AGIAgent 中 world_model 创建流程

这份文档说明：world_model 是怎么在 Agent 运行过程中一步一步生成出来的。

可以把它理解成一个“边玩游戏、边记世界规律”的后台系统。

它不是一开始就把整个世界模型写好，而是：

1. Agent 正常跑任务
2. 某一轮发现了值得记录的新东西
3. Agent 自己输出 FLAG_CURIOSITY: yes
4. 系统把这一小段经历抓出来
5. 交给 world_model 的 LLM 去提炼
6. 提炼成图里的点、线、规则
7. 再把这些内容写入 world graph 文件

1. 快速了解

world_model 的生成流程可以概括成一句话：

Agent 在运行时一旦说“这一轮有新发现”，系统就把这一轮附近的信息打成一个小包，交给另一个 LLM 提炼成图增量，再把图增量合并进 world graph。

2. 整个流程的入口

world_model 不会自己主动更新。

它的唯一开关是（后续会优化为多参数加权触发）：

FLAG_CURIOSITY: yes
CURIOSITY_REASON: ...

也就是说：

• 没有 FLAG_CURIOSITY
  不更新 world_model
• 有 FLAG_CURIOSITY
  才会触发一次后台 world_model 更新

所以现在的 world_model 不依赖 curiosity 分数，不依赖 chunk 统计，也不是每轮都更新。

3. 第一步：Agent 先正常运行

在 world_model 介入之前，Agent 先正常做自己的事情，比如：

• 读取当前场景
• 调用动作工具
• 得到 observation
• 得到 feedback
• 查看 admissible commands
• 再决定下一轮要做什么

这个阶段 world_model 不参与决策，它只是挂在后面的一个知识系统。

可以理解成：

前台是 Agent 在玩游戏，后台是一个准备记笔记的系统。

4. 第二步：Agent 在某一轮说“这轮值得记”

如果 Agent 在这一轮的输出末尾写了：

FLAG_CURIOSITY: yes
CURIOSITY_REASON: 首次进入客厅，发现前门打开后仍然不能直接离开

那么系统就会认为：

这一轮包含了新的实体、状态、转移关系、失败经验、恢复经验或规则线索，值得写入 world_model。

然后后台 world_model 更新流程开始。

5. 第三步：系统先打一个 scene/discovery packet

这一阶段系统不会直接拿整份日志去让 LLM 乱总结。

它会先把这次触发更新的关键上下文打包成一个小结构，叫做：

• scene packet
• 或 discovery packet

这个 packet 主要记录：

• 当前环境名 env_name
• 当前轮次 current_round
• 触发原因 trigger_reason
• 当前动作 action
• 动作前看到什么 before_observation
• 动作后看到什么 after_observation
• 系统反馈 feedback
• 当前可执行命令 admissible_commands
• 本轮模型输出摘要 latest_response
• 最近几轮历史摘要 recent_history_excerpt

可以把它想成：

这次更新 world_model 用的“证据包”。

这个 packet 会被写进：

• scenes.jsonl

所以 scenes.jsonl 的作用就是：

记录每次图更新，到底是基于哪次发现发生的。

6. 第四步：系统先看一眼当前已经有的图

在正式生成图增量之前，系统会先读取当前这个环境已经积累好的 world graph。

例如某个环境目录下会有：

• nodes.jsonl
• edges.jsonl
• rules.jsonl
• scenes.jsonl
• meta.json

系统不会把整个图原封不动塞给 LLM，而是先做一个简化摘要，大概告诉 LLM：

• 当前这个环境已经有多少节点
• 有多少边
• 有多少规则
• 目前大概记住了哪些状态和实体

这一步的目的是：

让 LLM 在生成新知识时知道“旧图里已经有什么”，避免重复乱写。

7. 第五步：把 scene packet + 当前图摘要 发给 world_model 专用 LLM

到了这一步，系统会调用 world_model 的专用 prompt。

这个 LLM 的任务不是写文章，不是写 markdown 报告，而是只做一件事：

把这次发现，翻译成一个 JSON 图增量。

它输出的内容大致是：

{
  "entities": [...],
  "states": [...],
  "edges": [...],
  "rules": [...]
}

这四类东西分别表示：

• entities
  世界里有哪些关键对象
• states
  世界处于什么状态
• edges
  状态与状态、状态与实体之间怎么连接
• rules
  世界中有哪些“如果……就会……”的规律

这一步你可以理解成：

把一次具体经历，翻译成“图数据库补丁”。

8. 第六步：系统先检查这个 JSON 合不合法

LLM 输出回来后，系统不会直接相信。

它会先检查：

• 这是不是一个 JSON 对象
• 里面有没有 entities / states / edges / rules
• 这些字段是不是数组
• 每一项是不是字典

如果格式不对：

• 这次 world_model 更新就会失败
• 不会把脏数据写进图里

所以这一层相当于：

先过格式关，再过知识关。

9. 第七步：把增量 merge 到 world graph

这一步是整个 world_model 创建流程的核心。

系统会把 LLM 给出的图增量，合并进当前已有的图里。

9.1 合并节点

如果输出了新的：

• entity
• state

系统会看旧图里有没有同类同名节点。

如果没有：

• 新建节点，写入 nodes.jsonl

如果有：

• 合并属性
• 合并 evidence
• 合并来源 scene
• 更新 confidence

所以：

world_model 不是每次重建整张图，而是一直在长大。

9.2 合并边

如果输出了 edge，系统会检查：

• relation 合不合法
  只能是：
  • transition
  • containment
  • episodic
• src_ref 能不能解析到已有节点
• dst_ref 能不能解析到已有节点

如果都对：

• 写进 edges.jsonl

如果有一个不对：

• 这条边就会被丢掉

所以“为什么没边”通常发生在这里。

9.3 合并规则

如果输出了 rule：

• 系统会看旧图里有没有类似规则
• 没有就新建
• 有就合并 evidence、linked nodes、confidence

最后写进：

• rules.jsonl

9.4 更新 scene 记录

刚才打好的 scene packet 会留在：

• scenes.jsonl

这让你以后能追溯：

这条知识到底是从哪次发现里长出来的。

9.5 更新 meta

最后系统更新：

• meta.json

这里面会记录：

• 环境名
• app 名
• 图版本号
• 更新时间
• 最后一次触发原因
• 当前图里一共有多少：
  • nodes
  • edges
  • rules
  • scenes

所以 meta.json 相当于：

world_model 当前长成什么样的统计面板。

10. 最后真正会生成哪些文件

以某个环境为例，例如：

• JerichoEnv905

最终会落在这个目录下：

• data/default/general/world_model_graph/JerichoEnv905/

这里通常会有：

nodes.jsonl

存图里的点：

• 实体
• 状态

edges.jsonl

存图里的线：

• 状态转移
• 包含关系
• 与 scene 的关联关系

rules.jsonl

存环境规律：

• 条件 -> 结果

scenes.jsonl

存本次更新的来源 packet：

• 这次为什么触发
• 当时看到了什么
• 做了什么动作

meta.json

存整体统计信息：

• 图版本
• 更新时间
• 当前节点/边/规则数量

11. 哪些东西不会单独落文件

有一些只是中间变量，只在内存里存在，不会单独存成文件：

• 当前图摘要
• LLM 原始回复文本
• 临时 JSON delta 对象
• merge 时生成的索引结构

真正长期存下来的，主要就是前面说的 5 类文件。

12. 总结

整个 world_model 创建过程：

1. Agent 在玩游戏
2. 某一轮它说“这轮有新发现，值得记”
3. 系统把这一轮附近的关键信息打成一个小证据包
4. 再让 world_model 的 LLM 把这个证据包翻译成：
   • 新节点
   • 新边
   • 新规则
5. 然后把这些内容补到已有的世界知识图里