# World Rule System

- 类型：`engineering`
- 状态：`draft`
- 负责人：`repo`
- 基线日期：`2026-03-21`

## 1. 文档目标

本文整理“世界宪法 / 规则系统 / 社会演化系统”的核心思路，目标不是为某一个具体世界写规则，而是定义一套可嵌入整个平台的通用机制。

这套机制需要同时满足：

- 平台可以控制世界边界、结构和整体趋势
- scenario bundle 可以通过资产文件定义不同世界观与制度
- agent 可以在规则和反馈中逐步形成策略、关系与发展路径
- 前端、日志、回放系统可以解释某个行为为什么被允许、阻止或带来后果

## 1.1 当前实现范围

截至当前代码状态，已经落地的是一个最小闭环：

- scenario bundle 已支持 `rules.yml`、`policies/default.yml`、`constitution.md`
- runtime 已有统一 `WorldDesignRuntimePackage`
- rule engine 已支持基于 facts 的最小规则裁决
- sim 已在动作执行前做规则评估与最小治理执行
- timeline / event payload 已暴露 `rule_evaluation / governance_execution`
- 最小治理后果已可写入 agent 运行时状态
- relationship 后果已开始读取治理执行与治理状态
- agent context 已注入轻量 `world_rules_summary`

尚未落地的部分：

- 更完整的选择性执法与运行时动态治理
- 动态 policy overlay
- reputation / economy 等更完整后果层

因此本文仍然是总纲文档，不应被理解为“全部能力都已实现”。

## 2. 背景问题

当前系统已经具备：

- `sim` 负责 tick、状态推进、事件写入
- `agent` 负责认知调用与动作意图生成
- `scenario` 负责题材上下文与部分规则注入
- `director` 负责观察与干预

但“世界规则”目前仍主要以三种形式分散存在：

- Python 中的局部判断
- prompt 中的软约束
- `world_config.yml` / `scenario.yml` 中的局部配置

这会带来几个持续问题：

- 规则内容和执行机制耦合，难以跨 scenario 复用
- 缺少统一优先级和冲突解决顺序
- agent 能收到“建议”，但系统不一定能统一解释“为什么允许/禁止”
- 世界扩展到商业、治理、权限、组织时，复杂度会快速失控

## 3. 核心结论

后续应把“世界规则”拆成两层：

### 3.1 机制层

保留在 Python 中，负责：

- 规则加载与 schema 校验
- 规则编译与评估
- 优先级比较与冲突解决
- 动作执行与状态变更
- 规则命中解释输出

### 3.2 内容层

迁移到 `yml/md` 资产中，负责：

- 世界对象、身份、权限、地点语义
- 规则条目、政策参数、临时状态
- 宪法原则、默认策略、显规则/潜规则说明

一句话总结：

**执行语义代码化，世界内容资产化。**

## 4. 平台级设计原则

### 4.1 控制结构，不控制每一步行为

平台应控制：

- 世界边界
- 资源结构
- 权力结构
- 权限来源
- 激励与惩罚结构

平台不应直接控制：

- 每个 agent 每一 tick 的具体选择
- 每条关系如何发展
- 每次互动的最终内容

### 4.2 规则决定边界，agent 决定策略

规则系统的职责是回答：

- 这件事能不能做
- 在什么条件下能做
- 做完会产生什么直接后果
- 这次裁决依据了哪条规则

agent 的职责是回答：

- 我要不要做
- 去哪里做
- 和谁做
- 守法、试探还是冒险

### 4.3 世界发展必须来自状态闭环

一个 agent 今天的行为，必须能改变它明天的机会。

因此世界规则不能停留在“自然语言说明”，而必须落到可持续演化的状态变更上，例如：

- 资源变化
- 权利变化
- 声誉变化
- 关系变化
- 风险变化

## 5. 规则系统的五层模型

平台级规则系统建议分成五层，而不是把所有规则平铺。

### 5.1 世界结构层

定义这个世界“有什么”：

- agent / organization / household
- location / property / slot
- goods / currency / permit
- reputation / relationship / policy

这层以静态资产和基础 schema 为主。

### 5.2 规则执行层

定义“某个动作在当前条件下是否合法、是否可执行”。

例如：

- 同地点才能交易
- 经营位必须空闲
- 特定身份才能申请某类许可
- 紧急状态下某类行为被临时限制

### 5.3 状态演化层

定义“动作被允许或被拦截之后，哪些状态发生变化”。

例如：

- 钱和库存变化
- 违规记录增加
- 声誉上升或下降
- 地点占用状态变化

### 5.4 agent 认知层

定义“系统如何把复杂状态压缩成 agent 能理解的上下文摘要”。

例如：

- 我当前有什么资源
- 我最近哪些尝试成功或失败
- 我拥有哪些权利
- 哪些地点最近机会更高
- 当前违规风险如何

### 5.5 治理与导演层

定义“平台如何调结构，而不是直接操控每个个体”。

例如：

- 调高巡查强度
- 开放更多经营位
- 引入节庆活动
- 施加区域性临时限制

## 6. 规则类型分层

无论哪个 scenario，规则内容都建议按以下类别组织。

### 6.1 存在规则

定义世界对象与角色：

- 有哪些实体
- 这些实体有哪些基础字段
- 哪些关系是合法存在的

### 6.2 行为规则

定义世界支持哪些动作：

- 原子动作
- 高级动作
- 哪些动作允许 agent 产生意图

### 6.3 制度规则

定义哪些行为在什么条件下合法。

### 6.4 后果规则

定义行为之后会发生什么。

### 6.5 变化规则

定义规则本身能如何被修改、覆盖或临时调整。

## 7. 规则表达模型

规则不应只写成说明文，建议至少具备以下结构：

- `rule_id`
- `name`
- `description`
- `scope`
- `trigger`
- `conditions`
- `effect`
- `priority`

平台运行时至少应统一输出如下裁决信息：

- `decision`: `allowed` / `blocked` / `soft_allowed_with_risk`
- `rule_id`
- `priority`
- `reason`
- `matched_conditions`
- `side_effects`

这样前端、timeline、审计和调试工具都能追溯：

- 命中了哪条规则
- 为什么命中
- 产生了什么效果

## 8. 资产组织建议

规则内容应以 scenario bundle 资产的形式组织，而不是散落在 adapter 代码中。

建议每个 scenario bundle 至少包含：

```text
scenarios/<scenario_id>/
  scenario.yml
  constitution.md
  world.yml
  rules.yml
  policies/
    default.yml
    <policy_id>.yml
  goods.yml
  permits.yml
```

其中：

- `scenario.yml`
  负责 bundle 标识、adapter 选择、能力开关、语义映射

- `constitution.md`
  负责人类可读的世界哲学、默认原则、冲突解决顺序、显规则与潜规则解释

- `world.yml`
  负责对象表、地点表、身份表、基础资源和默认权限

- `rules.yml`
  负责结构化规则条目

- `policies/*.yml`
  负责可切换、可叠加的动态政策或临时事件

- `goods.yml` / `permits.yml`
  负责规则引用的数据字典

## 9. 平台与 scenario 的边界

这套规则系统必须明确区分“平台能力”和“scenario 内容”。

### 9.1 平台负责

- 规则引擎
- 条件求值
- 优先级机制
- 动作协议
- 状态变更执行器
- 规则命中解释
- 通用事件与审计格式

### 9.2 scenario bundle 负责

- 世界观对象
- 角色身份与权限
- 地点含义
- 可交易/可经营/可申请的具体内容
- 默认政策与临时政策
- agent 可见知识与公开制度

这意味着：

- 新世界不应为了“换一套制度”而改平台代码
- 平台不应为了支持新世界而引入新的 world-specific 字段名

## 10. 如何嵌入整套体系

### 10.1 `sim`

仍负责 tick 主流程、状态推进、事件持久化。

需要扩展的是：

- 在动作执行前接入规则评估
- 在动作落地后接入统一状态变更
- 在事件写入时记录规则解释信息

### 10.2 `agent`

仍负责认知与意图生成。

需要扩展的是：

- 接收结构化的世界摘要，而不是依赖 prompt 中的隐式规则
- 能看到与自己相关的资源、权限、风险、机会摘要

### 10.3 `scenario`

不再承担大部分“世界条文”的硬编码实现，而是变成：

- bundle 加载入口
- 资产解释与注入入口
- 题材语义适配层

换句话说，scenario adapter 应更像 runtime bridge，而不是规则本体。

### 10.4 `director`

继续负责观察和干预，但后续干预应该更多作用于：

- 政策
- 事件
- 机会分布
- 结构性调参

而不是直接替 agent 决策。

## 11. 演化系统的最小闭环

平台级社会演化必须具备以下闭环：

1. agent 看到机会与约束
2. agent 产生动作意图
3. 规则层做裁决
4. 系统更新世界状态
5. 结果进入 memory / reputation / relationship / rights
6. 下次 agent 决策读取新的摘要

如果没有第 4 到第 6 步，世界就只有行为，不会发展。

## 12. 平台级最小状态域

无论最终是商业世界、治理世界还是其他社会模拟，平台都建议为以下状态域留出统一承载能力：

- `economic_state`
- `social_state`
- `institution_state`
- `relationship_state`
- `location_state`
- `policy_state`

具体字段由 scenario bundle 决定，但这些状态域本身应成为平台通用语言。

## 13. 推荐演进顺序

### 阶段 1：统一规则表达

- 明确规则 schema
- 明确规则裁决结构
- 把散落在代码中的 world content 判断迁到资产文件

### 阶段 2：统一状态域

- 为资源、权限、声誉、政策建立平台级承载位置
- 允许 scenario bundle 定义自己的扩展字段

### 阶段 3：统一解释链

- action result / event / timeline / agent detail 中统一暴露规则命中信息

### 阶段 4：引入社会演化模块

- 在不改 agent runtime 主体的前提下，让资源、制度、声誉与关系成为长期可积累状态

## 14. 非目标

本文不主张：

- 让平台直接替某个 scenario 写完整世界法典
- 把所有执行逻辑都搬到 YAML
- 让 agent 直接读法条并自行解释整个制度
- 一次性把完整经济、治理、组织系统全部上线

本文主张的是：

- 先统一抽象
- 先把边界和职责分清
- 再让不同 world bundle 在同一套平台能力上长出差异

## 15. 最终判断

后续世界扩展应遵守以下原则：

**平台做规则引擎与状态闭环，scenario bundle 做制度内容与世界观资产，agent 在其中发展策略而不是直接替代制度。**

这套模式适用于 Narrative World 的整套体系，而不应被限定为 TrumanWorld 的一次性设计。
