状态包与证据

State Packets and Evidence

State Engineering · 状态工程

原版式注：双栏页，阅读顺序为左栏 → 右栏；章节字母按栏编号，本页出现两个 C 节，保留原编号。

A.状态工程State Engineering

Jev 只能判断它收到的状态。把一份巨大的对话转录丢过去，等于强迫模型从混杂的指令、陈旧的尝试、既有结论和无关历史中重建工作流。输出可能仍然满足声明的类型，但底层判断建立在过期或误导性的上下文之上。

状态包（state packet）应当紧凑、新鲜、基于证据。把目标、事实、产物、证据、约束、选项与状态版本分开。每个字段功能各异；这种分离让遗漏变得可见，也防止上一个智能体的解读变成不容置疑的事实。

表 Ⅳ　功能化的状态字段可减少证据与解读之间的意外耦合。
Table IV. Functional state fields reduce accidental coupling between evidence and interpretation.

状态里应当是可观测的证据，而不是结论。「研究大概足够了」是在要求 Jev 信任一个早先的判断；「已收集 7 个来源，其中 3 个官方来源，定价已核实，安全声明未解决」给模型的才是可判断的材料。

代码 5-1 · 继承信心 vs 呈现证据（原文保留英文）

BAD:     "research is probably enough"
BETTER:  "7 sources, 3 official, pricing verified,
          security claim unresolved"

BAD 要求 Jev 信任别人的结论；BETTER 给出可被判断的原始证据。

紧凑的状态包还应执行最小权限。决策模型只接收契约所需的字段。机密、个人信息、专有代码与无关的账户数据，不应仅仅因为它们存在于父智能体上下文中就被塞进来。

字段级访问规则让这个边界可评审，也让同一份底层运行状态可以分别为路由、检索、校验与审批契约产生不同的投影（projection）。

代码 5-2 · 状态包的功能字段（原文保留英文）

state = {
  goal, facts, artifacts,
  evidence, constraints,
  options, version
}

目标、事实、产物、证据、约束、选项、版本——七个功能字段构成最小状态包。

状态包不需要包含运行中的每一个事件，它只需要包含声明问题所需的证据。不同的决策族可以接收同一份底层状态的不同投影。

每个选项集都有失效条件：工作器变得不可用、按钮消失、预算变化、文件移动、权限被收回、来源被更新。基于过期状态的决策不只是弱推断，而是在一张无效图上的推断。

给可能过期的证据附上时间戳或版本号；评估前重建实时选项；当一致性重要时，阻止快照创建与决策评估之间的写入。如果系统要重试，就要求新证据或修改过的契约——对着同一份状态重复同一个不确定的问题，不是学习。

最小化不是激进删除，而是一份相关性声明。代码可以预先过滤精确不匹配项、检索可能的证据、构造一个小包；Jev 再解决剩余的语义模糊。这种分工防止模型去「重新发现」程序已经精确知道的事实。

状态包应当是人类可检查的。如果开发者说不清某个字段为什么在里面，这个状态多半吸收了转录历史，而不是决策证据。

状态测试应当对单个字段做移除、损坏与置旧，度量哪些证据真正驱动了分支。如果无关历史改变了答案，说明包的隔离不够；如果移除一个「理应必需」的字段毫无影响，要么该字段多余，要么契约没有可靠地使用它。

为常见状态版本与边界情况维护 fixture。fixture 应包含期望路由和一段简短的人类理由，而不是思维链轨迹。目标是验证决策边界与证据充分性。