上下文里放什么：摘要，还是权威状态

近期我拿着同一个问题去问了两个人。

metacodes 的 wayfind 刚在 #277 里承认了一件事：长任务跑到上千轮之后，目标本身会拖代码的后腿。他的解法是 TinyKG 上的任务 DAG，每轮注入“当前任务 + 根到当前节点的路径摘要”。我把问题又丢给 LoopX 作者：层级摘要逐层蒸馏，丢了约束、放松了验收，怎么发现？他回了五条机制，每条都挂着 pin 到具体 commit 的源码链接。

10 月 18 日，#277 关闭：goal 和 swarm 分别在 10 月 17 日随 AgentCore Revision 23（PR #286，SDK 0.10.0-dev）、Revision 24（PR #294，SDK 0.11.0-dev）落地；长程部分被明确拆成独立的设计与评估工作（“a separate design and evaluation effort”），DAG 还没有自己的 issue，更没有 PR。从公开承认到关闭只隔了一天。LoopX 的答案已经在 main 上跑着。

第二篇拆解的是问题本身，这篇比的是解法。两边源码我都读了，读完发现一件预告里没人提的事：两种解法的坑，是同一个。

一、先把问题说到机制层

Codex 的 goal 扩展源码（codex-rs/ext/goal，约三千行 Rust）是个清楚的标本。它的自动续跑，本质是每轮重注入一份 <objective> 包裹的目标全文（templates/goals/continuation.md），配一整套审计软约束：标 complete 前要逐条找证据，不许用更窄的方案替代目标。预算则是硬机制：目标存数据库、模型没有“停下”这个选项、token 记账排除缓存命中。

这套设计在百轮内好用，因为它的一切保证本来就以会话为界：目标是锚，会话是锚的绳长。同一个注入物拉到周尺度就出事——顶层目标全文逐轮压进上下文，工作早钻进某个子系统了。绳放尽了，锚不在船边，每一轮注入都在把船往回拽。

二、解法 A：改变注入物的结构

metacodes 的路线：既然全文注入会压顶，就改注入物的结构。TinyKG 把任务逐层分解成 DAG，每轮注入的从“顶层目标全文”换成“当前任务 + 根到当前节点的路径摘要”，模型只看路径上的相关切片。

这个方向不孤独。最接近的现成原型是 Mage（arXiv 2606.06090）：两层状态树，顶层在子目标与决策边界生成摘要——几乎就是“当前任务 + 路径摘要”，连摘要触发点都一样。

两个已知的开放问题，第二篇写过。

头一个是层级摘要的保真度没有评测方法。Mage、HORMA 这类层次摘要工作都假设摘要是好的，没有失真检测器。DAG 化等于把“每轮注入原文”换成“每轮注入蒸馏产物”，每层蒸馏丢了什么约束，目前没有任何检测手段。

第二个是 replan 语义。父目标变更后，已展开的子树如何失效、如何对账，论文和 Devin 都没有公开解法。

截至写稿，这个 DAG 方案的状态是：问题被承认，解决思路已经规划好，评估也承诺了，但还没开工。

三、解法 B：让摘要不当权威

LoopX 作者的回答，核心在一句话：“摘要承担阅读和理解的作用，权威状态由对应的写入与变更规则维护。”

这不是“把摘要做得更好”，是剥夺摘要的权威：目标、待办、归属、阻塞条件、证据全放在模型上下文之外，每轮注入的是状态内核的当轮读取，摘要只是辅助理解的读物。

我问了一句“每轮到底注入什么”，他指了两个入口，两个入口的答案都在代码里。

quota_planning_horizon_v0 就是 planning horizon（计划视界）：一个有界、只读的上下文，让 agent 在当前选中的 todo 之外，看到它所在的战略链——事实来源、策略决策、准入、验证。协议文档自己写了动机：“只显示那个门禁，会让模型去优化眼前这片叶子”；planning horizon 让这条有界的链可见，但“不悄悄替换掉选中的 todo”。

关键在默认值：把 goal 原文一并带进来的 planning_horizon_goal 选项默认关闭——LoopX 控制面自己的 planning horizon 默认连目标原文都不带，只给当前工作周围一圈有界视界。

另一个入口是 replan context。启用 evidence_conditioned_v1（同样默认关闭）后，若历史中存在已被接受、绑定证据的 vision 路线，replan 上下文会返回上次路线决定连同其后的进度证据，因果顺序取自追加位置而非时间戳，“又做一次复盘或只引用一次”不会消耗证据。

这跟 succession advisory 一脉相承：把“上次决定了什么、之后实际做了什么”重建成可读模型交回判断，而不是自动失效。文档把边界写得很清楚——“这些是记录中的观测，不等于执行或收益的证明”。

范围也得说清楚，不然容易夸大成“LoopX 不注入目标”：LoopX 的内层循环仍交给宿主自己的 /goal 跑，宿主那层的续跑提示词照旧注入目标全文，LoopX 不替代它、也关不掉它。准确说法是“控制面不加注，宿主层照旧”。

他给的五条机制，我逐条对着 commit 105c4bc15 核验过源码，五条都能在仓库里找到对应文件。但五条不是并列的——只有两条在本文的论证链上。

一条是状态的寿命要超过当前会话——Goal、待办、归属、阻塞条件、证据、后续入口全在上下文之外，模型每轮读到的是权威事实的当轮读取，写入与变更规则决定谁能改。interaction_contract.ts 把这条写得很直白：先读完整 Goal 意图与选中的 Todo 是前置义务，“A summary cannot replace this read”。

另一条是顶层目标和当前工作的节奏不能一样。Goal 保存长期方向，Vision 保存当前路线，Todo/frontier 表达眼下可推进的工作；进入子系统后，局部工作可以围绕局部问题持续展开。交付连续性就是这条原则落到代码里的样子：同一任务已有实质进展（previous_delivery_outcome）、仍可执行（actionable + capability_ready）、归属有效（没有被别的 agent 认领）时，后续心跳直接继续它，不必每轮拽回去重过顶层判断。delivery_continuity.ts 有 394 行，heartbeat_receipt 就在 preemption 列表里。顶层干预本来就不该每轮发生——压顶问题在这一层是被设计排除的，不是被缓解的。

这条正好对上第三个因素——目标无法跟随演进：把它留在顶层，别每轮把人拽回去。但它也是这份解法自带的代价——让局部不被拽回，等于允许方向慢慢偏。

其余三条是把同一套纪律铺到结算、重规划和交接上：模型说“完成了”不算数，要经过验证和结算才能成为后续工作的依据；replan 必须说清哪些保留、哪些改变、哪些停止，1511 行的契约里写着“没有有效变化依据的复盘不能自动解除义务”；跨轮跨层的交接按 Effect stride / Delivery stride / Authority stride 三级切分，“一次 scheduler tick 本身不能制造任何一种语义迁移”。

他最后一段回答值得整句引：“状态格式正确、传递成功，不代表语义一定完整……任意自然语言约束在超长运行中始终不丢失，仍是需要持续验证的目标。”

四、分野的精确定义

两种解法摆在一起，最容易说错的一句话是“一个外置状态一个不外置”——不对，TinyKG 图数据库本身就是外置状态，两家的状态都在模型之外。

真正的分野更窄：每轮注入上下文的，是派生物还是权威本身。

左边依赖蒸馏保真，右边依赖摘要无权威；两家的失效模式是同一个开放问题的两种形态。

metacodes 注入的是派生物——DAG 路径摘要是对图状态的蒸馏计算，模型拿到的行动依据是二手的，成败取决于蒸馏是否保真。LoopX 注入的是权威状态的当轮读取，不过蒸馏层。这一点在 planning horizon 上最清楚：两家都在解决“让当前工作看到自己在路径上的位置”，metacodes 给蒸馏出来的路径摘要，LoopX 给一份权威行的有界只读投影，默认连目标原文都不带。

两家的失效模式也就分开了：metacodes 的坑是蒸馏丢了约束而没有检测器；LoopX 的坑是状态 schema 表达不了的约束无处安放——能被外置状态看守的，只有能被结构化的那部分约束。作者承认的那句“任意自然语言约束不丢失仍未验证”，承认的就是这半边。

两个坑其实是同一个问题——没法被结构化的自然语言约束，怎么证明它还在——只是落在两个格子里，解决办法也不同，别指望一个指标通吃。

metacodes 这格是丢失检测。约束本来在图里、可结构化，蒸馏通道把它丢了。变异探针、约束注入在原理上直接可测：注入一条已知必须存活的约束，路径摘要后检查它还在不在。

LoopX 这格是无法表达。约束从一开始就进不了 schema，通道再无损也没用。先要解决自然语言约束的发现与归类，检测手段在它之后才有地方挂。

也别把分野读成对立。两条路线不互斥：DAG 节点完全可以持有权威、摘要只做视图，那是兼有两家之长的形态。现在下胜负结论太早——一边还没开工，另一边的验收文化不允许它提前宣布胜利。

五、一枚硬币的两面

“允许方向慢慢偏”不是修辞：连续性保护会放大渐进型漂移。

交付连续性让局部工作不被顶层目标拽回——这一层，问题解决了一半。硬币的另一面：局部一直“对”，方向慢慢偏，不触发任何单点告警。保护局部连续性的机制越强，渐进漂移的通道越宽。

LoopX 的作者很显然非常清楚这件事。仓库里躺着一份 goal-direction-baseline RFC（目标方向基线），状态“已接受、Partial”，M1 候选明确写着“不代表通用运行时启用”。机制已落地，纠偏还是候选。这个时差不是疏漏。长程系统现在就卡在这里：“敢深入”做出来了，“不跑偏”还在图纸上。

这也正是我在第一篇给 LoopX 提的第二条建议（replan 产出目标 diff、方向性变更挂 operator gate）。

跑稳、跑好之外，还有第三件事——记得为什么跑。

他最近发了《通用长程是 RSI 的先决条件》，主张递归自我改进的瓶颈不在“AI 能不能改自己的代码”，在改进能否累积——目标延续、反馈累积、改进接续。

顺带更新负面清单两格。replan 对账这一格，LoopX 的答案是两件套：successor 链接 lineage_only，检测到接续问题强制 authoring_decision_required——不自动失效、不自动转移，决策显式摆回人面前。新增的一格是不可结构化约束的存续：蒸馏保真检测（metacodes 的坑）与 schema 外约束看护（LoopX 的坑）是同一个问题下的两个格子，谁先填上，取决于各自承诺的那个评估。

两种解法的承诺都能被检验。剩下的，等评估。

相关阅读

• LoopX 作者的 RSI 文：《通用长程是 RSI 的先决条件》–https://loopx-project.github.io/loopx/blog/zh/long-horizon-rsi/