上下文感知规划 Jaffe2718/s1cap

S1CAP

System-1 Context-Aware Planning

实现进展： 上下文投递现在只补回 DSH 模型可见面上真正缺失的内容，完全可见的历史会跳过召回打分。需求打分采用有界并发，并在窗口变化时复用已付费的配对。正确性修复、可复现的离线测量结果和已知限制见优化报告；下面较早的进度记录描述的是更早的实现。

S1CAP：用 System-1 模型做上下文感知规划，让 LLM 智能体更高效

作者： Yuanming Chen · LI Changzhe

进度： M0 已完成（包已就绪，Laya 运行时在本机验证通过，插件能在真实 DSH 配置档中激活）。M1 观察模式已上线，并在真实会话中验证通过：每次调用的流水线（SEGMENTER → RECALL → ASSEMBLER）会跑起来，提示词原样返回；系统提示词取自 harness 注册表，所以 pinned 块和缓存稳定的前缀都不为零（真实一轮中 blocks.pinned = 684）；关联图的维护由真实的 session/event 流量驱动；回放 harness 能逐字节复现控制面记录。接下来要做存放 Jev key 的设置面板。细节、证据和逐项验收测试见 docs/STATUS.md。

S1CAP 让一个廉价的 System-1 决策模型（Jev / Laya / Kev 这一类，说 /v1/systemone 协议）来掌管 LLM 智能体 harness 的上下文生命周期，而不是交给昂贵的 System-2 LLM。S1CAP 控制层只在两个点介入。这里先说明这两点共同的一条边界，因为它决定了下面每一项测量该怎么读：目前还没有任何单元格能交付组装好的布局——模型视图回写是 docs/ARCHITECTURE.md 里的一行 🔜（packages/proxy，尚未编写）——所以顺序只是被记录下来，今天真正到达模型的是召回选择加一个插入块：

1. 上下文感知 （每次 LLM 调用，模型看到什么）——每个会话片段（用户轮次、助手消息、推理轨迹、工具调用/结果）都是不断生长的关联图中的一个节点，节点之间的配对由 System-1 模型按需打分：某一步的召回只请求它这次游走需要的那些行（AssociationGraph.recallDemand，2026-10-05），所以游走永远到不了的分支永远不会被打分。每一轮，有界 BFS + 相关性阈值 + token 预算决定哪些片段能进来，并按 Trace-as-State 顺序组装：[pinned prefix | state proxy T | recent tail | recalled blocks | current input]。其中哪一半今天能到达模型，写在下面的评测设计里：选择能到，组装顺序还不能。
2. 计划排序（规划中上下文感知的那部分）——LLM 给出的候选计划直接送到第二个 System-1 后端，由它按选择题打分；PLAN GATE 把这些分数归一化，给计划排序并限制尝试次数，执行按这个顺序走，并受验证预言机约束，首次成功后丢弃未执行的备选方案。已设计并实现，但截至 2026-10-02 尚未接入任何消融单元： 轮次 20261002-2037 完全没有记录到 plan_gate 事件，因为模型没有写出编号计划，也没有发出 todo/write，所以这个开关从策略、预设和报告里移除了，而不是留着 on 却不起作用（packages/core/src/types.ts）。

一切都靠测量，不靠假设：解决率、按提示词缓存命中/未命中拆分的 token 成本（这是成本的主导杠杆——在 DeepSeek 上，缓存命中的 token 比未命中便宜约 50 倍），以及排除审批等待后的墙钟时间。定义见 docs/FORMULAS.md，scripts/cell-report.mjs 是它们唯一的实现。

为什么是现在（2026 年 9 月）

| 使能因素 | 事实 |
| Trace as State（arXiv:2609.02702） | 把推理轨迹状态代理放在长上下文之前，在 26/27 个模型×任务×指标组合中胜过轨迹追加——无需训练，只在推理时生效 |
| 决策模型登场 | Jev（TypeSafe AI）：输入 $0.042/M，输出免费，并行问题批次比串行便宜 12 倍 · 开源 Laya（Apache-2.0） · EdgeJev 本地运行时：322M INT8，324 MB，4 vCPU 上每次决策 15.6 ms |
| 缓存经济学 | DeepSeek deepseek-flash：缓存命中 $0.006/M，缓存未命中 $0.30/M——上下文组装是成本决策，不只是质量决策 |

架构

S1CAP 方法总览：按时间顺序的会话日志，经语义关联图上的任务条件化上下文组装；System-2 生成候选计划，System-1 重新排序，停止决策由模型自己掌握。

精确控制流和异步边界见详细技术路线（深色版本）。

面向用户的记录保持严格按时间顺序；只有模型视图被重新组装——而这次写回是 docs/ARCHITECTURE.md 里的一行 🔜（packages/proxy，尚未编写），所以排序那一半记录的内容，还不是模型读到的内容。唯一活跃的投递通道只插入 recalled 轮次，别的什么都不插，这就是为什么注册的对照测的是召回通道而不是 TAS（docs/CELLS-RUN.md）。

评估设计（三个单元）

运行三个单元：两个对照，一个受测臂（2×2 交叉的第四种组合——有治理但无排序 —— 按步测量比基线更差，已弃用；bench/README.md 记录了各项数值）。
某个实验臂带哪些开关，由预设和策略决定，不由本页决定： 实验臂定义见 bench/cells/C0.json–C2.json 以及 cellPolicy() （packages/core/src/types.ts），若与本页有出入，以那些文件为准。三个实验臂的含义是本页坚持的规则：

- C0 是基线，C2 是完整配置；C1 是第二个对照臂 —— 投递只有一个通道，且它的 tier1: off 让该通道按构造为空，因此它模型可见的输入与 C0 相同。
- 布局变量只有 tracePlacement —— 记录的顺序对应论文两个实验臂中的哪一个：TAS，即 trace 在长上下文之前，对照它的 Trace Append 控制组。它在每个实验臂里都被记录，而组装出的顺序在任何实验臂里都到不了模型：投递只追加 trace T 和召回的轮次，从不追加布局，所以只有靠模型视图回写，排序才可测量，而模型视图回写并不存在（docs/ARCHITECTURE.md §5；packages/proxy 尚未编写）。这不是第二个轴，也不是某个设置：论文在每个条件下都把 q 放在最后，所以按构造它就是每种布局的最后一个块。取值与默认值由代码决定：bench/cells/.json + cellPolicy() （packages/core/src/types.ts）。
- 因此注册的对比是 C0 vs C2，它今天测量的是召回选择及其插入 —— 召回通道，而不是 TAS。
- 因子 B 只是召回选择：计划门已设计并有单元测试，但没有接入任何 cell，所以它不属于这里的任何因子。

基准测试（全部自动评分，无 GUI，无 LLM 评委）：SWE-bench Verified · Terminal-Bench 4.0 · τ²-bench。测试池及其规模见 docs/AGENT_BRIEF.md §「Experiment design (three arms: two controls, one arm under test)」，每轮运行集见 docs/CELLS-RUN.md。模型：deepseek-flash （DeepSeek-V4.1-Flash），reasoningEffort 固定；不声明任何采样参数 —— 既不是 temperature 也不是 seed —— 因为 DSH 不暴露这些。

成功规则： 求解率相对 C0 非劣（配对 McNemar，单侧 α=0.05，边界 −2 pp）且 成本/任务或时间/任务改善 ≥10%（配对 bootstrap 95% CI 不含 0，Holm 校正）。成本赢了但求解率损失超过 2 pp 不算赢。冻结的规则见 docs/AGENT_BRIEF.md §「Metrics, hypotheses, success rule」；其测试池、网格与预算见 docs/AGENT_BRIEF.md §「Experiment design (three arms: two controls, one arm under test)」。

状态与路线图

Pre-alpha —— M0 脚手架已落地：monorepo、@s1cap/core（分段器 · 关联图 · 组装器 · 计划门 · 遥测 v1）、@s1cap/s1-client、@s1cap/laya-runtime（Python 环境发现 + laya-serve 启动器）、dsh-s1cap 骨架、三格预设（C0–C2）；离线测试套件全绿（node --test，见下文），真实的 laya-serve 往返也已验证（/health 就绪 + 通过 /v1/systemone 做出的 noul 决策）。M0 剩余工作：针对 Jev 的实时后端冒烟测试。完整规格：docs/AGENT_BRIEF.md。

| M | 范围 |
| M0 | monorepo 脚手架、core + s1-client、遥测 v1、DSH 插件骨架 —— 脚手架已完成，实时后端冒烟测试待做 |
| M1 | 组装器/召回重放正确性测试、代理 MVP、DSH 钩子接线（agent/pre-step、surface 操作） |
| M2 | 计划门接线（只有当模型写出的计划能被门读到，格子才能触发门 —— 目前没有模型能做到）、降级路径、设置 UI、Terminal-Bench 10 任务成本试点 |
| M3 | 在 SWE-bench Verified + τ²-bench（+ TB）上做三格消融，可选 Laya 微调 |
| M4 | Terminal-Bench 格子、opencode 迁移检查、GLM 模型替换检查 |
| M5 | 论文：Pareto + 缓存瀑布图、案例研究、LaTeX 草稿 |

开发

node --test --experimental-strip-types "packages//test/.test.ts" # zero dependencies, offline
node scripts/check-diagram.mjs # every node box inside its lane band, no overlapping nodes
node scripts/check-doc-pointers.mjs # dead file/section pointers and stale value claims

第二条命令守护手绘的路线图：图是手画的，所以只有这项检查能拦住节点漂出所在泳道。

本地 Laya 后端：@s1cap/laya-runtime 会找出能 import laya 的 Python 环境（conda 环境通过 conda env list --json 解析，绝不靠猜路径），启动 laya-serve 并对 /v1/models 做健康检查。每个环境装一次 serving extra：<python> -m pip install "laya[serve]"；配置键和 DSH 配置档补丁见 docs/LAYA_RUNTIME.md。

工作区把 TypeScript 和 Node 类型固定为开发依赖。执行 pnpm install --frozen-lockfile 后，运行 pnpm typecheck、pnpm build、pnpm test；node scripts/check-lib-fresh.mjs 校验发布的 JavaScript 与源码一致。
pnpm 是预期的 workspace 管理器；在 Windows PowerShell 上请调用 pnpm.cmd（.ps1 shim 被默认执行策略拦截）。

仓库结构

s1cap/
packages/core # segmenter, association graph, assembler, plan gate, telemetry v1
packages/s1-client # /v1/systemone client + provider matrix
packages/proxy # OpenAI-compatible middleware (M1)
packages/dsh-plugin # dsh-s1cap: first-class DeepSeek Harness plugin (skeleton)
bench/ # cells/ presets; runners + stats land with M2
docs/ # 提案、实现简报、相关工作档案、公式 paper/ # LaTeX（M5）

文档

| 文档 | 读者 |
| docs/STATUS.md | 从这里开始 —— 已完成/待办清单，每个未完成项都附有智能体可直接上手的细节 |
| docs/PROPOSAL.md | 研究提案 —— 导师 / 合作者 |
| docs/ARCHITECTURE.md | 模块参考：路线 SVG + 连接语义、参数、实现状态 |
| docs/LAYA_RUNTIME.md | 本地 Laya 后端：Python 环境探测、启动器、配置键 |
| docs/CONTROL_PLANE_LOGGING.md | 控制面隔离：双日志设计，以及防止 System-1 给自己的输出打分的各项不变量 |
| docs/AGENT_BRIEF.md | 面向编码智能体的实现简报 —— 已验证事实基础、接口、算法、里程碑 |
| docs/FORMULAS.md | 形式化定义与公式手册（Markdown + LaTeX） |
| docs/RELATED_WORK.md | 已验证的相关工作档案 + 新颖性审查 |
| docs/REPO_METADATA.md | 仓库的标准描述、topics、关键词 |

环境

已在开发机验证（2026-09-28）：Node v22.23.1 · npm 12.0.2 · git 2.45.2 · Python 3.13.13（miniforge）· i7-12700H（AVX2 —— 兼容 EdgeJev）· DSH 运行时自带 Node 24.18.1。

要求：Node ≥ 22.19（DSH 插件 engines 约定）· monorepo 需要 pnpm（在 Windows PowerShell 里请调用 pnpm.cmd，或放宽执行策略）· 本地 S1 运行时需要 Python ≥ 3.10（pip install "laya[serve]"、pip install edgejev）· System-1 后端：云端 Jev key，或面向弱 CPU 的本地 EdgeJev/Laya（324 MB，可离线）。

名称

S1CAP = System-1 Context-Aware Planning —— S1 指 System-1 决策模型，C-A-P 指它为 LLM 智能体所做的上下文感知规划。控制层在两个点介入：① 上下文感知（模型看到哪些片段）和 ② 规划排序（它自己的规划按什么顺序执行）。

致谢

TypeSafe AI（Jev）· Convai Innovations（Laya）· yzfly（EdgeJev）· jaredpalmer（Kev）· Benchmark Heaven（JevBench）· Xu Zou & Jie Tang（Trace as State，arXiv:2609.02702）· snailium（DSH 插件工程模板）· DeepSeek Harness

引用

论文撰写中。作者：Yuanming Chen、LI Changzhe。标题：S1CAP: Context-Aware Planning via System-1 Models for Efficient LLM Agents（2026-09-28 修订，此前修正了命名错误：该缩写展开为 System-1 Context-Aware Planning）。
bibtex
@misc{s1cap2026,
title = {S1CAP: Context-Aware Planning via System-1 Models for Efficient LLM Agents},
author = {Chen, Yuanming and LI, Changzhe},
year = {2026},
url = {https://github.com/Jaffe2718/s1cap},
note = {Paper in preparation}
}

许可证

待定（拟用 MIT）。

更正 2026-10-05 —— 布局轴已删除，下面的更正就是它替换掉的内容

追加在 docs/DOC-CONTRACT.md §4 下，紧挨着它下面的那条更正。上面 Evaluation design 里的那条要点，是对当前事实的实时陈述，所以就地更正了；被取代的措辞原样保留在这里。

改动了什么。 AssemblyPolicy.questionPlacement: 'first' | 'last' 已删除 —— 不是改名。再没有任何字段决定问题的位置。AssemblyPolicy.tracePlacement: 'trace-as-state' | 'trace-append' 是唯一的布局轴，而 q 按构造就是每种布局的最后一块。旧配置档的拼法怎么读、警告什么、拒绝什么，由 packages/core/src/config.ts 里的 LEGACY_LAYOUT_KEYS 负责，这里不再重复。

为什么删掉这条轴，而不是给它起个更好的名字。 下面的更正把 xFirst 改名为 questionPlacement，让「问题的位置是个变量」仍然可表达。论文（arXiv:2609.02702，§4.1）把问题放在每种条件下的最后 —— 「We therefore separate the question from the long context and place it at the end of every input」—— 它的两个分支是 [T, x, q]（Trace as State）和 [x, T, q]（Trace Append），「order as the only difference」。questionPlacement: 'first' 产生的是 [T, q, x]，两者都不是。一个字段，它的另一个取值排出的条件论文里根本没有，那它就不是变量，所以这条轴没了；配置档里还这么拼的，只读取并报告，不运行（两种拼法和它们的两种结果都在上面的代码里）。

为什么下面的更正还不够。 xFirst 和 questionPlacement 是同一条被删除的轴的两种拼法，不是两次改名：第一条更正把第二种拼法说成当前字段，而这里任何仍把它当成设置的句子，对当前构建的描述都是错的。trace 轴承载的东西没变，上面已经说了；问题轴承载的东西，现在是一个固定位置。

证据，来自轮次 20261004-0233 自己的 layoutOrder 记录。 两个 TAS 单元（C1、C2）记录的是 pinned, stateProxy, anchor, recalled, tail —— 问题在第二位，两个论文分支都不是 —— 而 C0 记录的是 pinned, recalled, tail, anchor，即论文的基线 M([x, q])。第一种顺序已经无法由任何设置产生，而当前构建确实产生的两种顺序，就是 packages/core/src/assembler.ts 头部那张表。

被取代的措辞，原样保留。 下面的更正声称问题有一个位置字段；这条笔记删掉的就是这个说法。
改动了什么。 AssemblyPolicy.xFirst: boolean 现在是 questionPlacement: 'first' | 'last'，而 AssemblyPolicy.stateProxyPosition: 'before-context' | 'after-context' 现在是 tracePlacement: 'trace-as-state' | 'trace-append'。映射关系一一对应 —— true → 'first'，false → 'last'； 'before-context' → 'trace-as-state'，'after-context' → 'trace-append' —— 配置档如果还写着旧写法，会被翻译过来，而不是按默认值运行（LEGACY_LAYOUT_KEYS，packages/core/src/config.ts，它会把这个替换作为警告报出来）。

它同时取代的 Evaluation design 那条要点，原文照录 —— "The two layout fields — tracePlacement … and
questionPlacement (where the question sits) — are recorded in every arm … The question's position is not the
paper's variable — the paper holds the question last in every condition, so no arm is defined by it."* —— 这是一条仍然有效的陈述，所以就地改正，而不是当作历史保留。

下面这条更正仍然承载的内容，以及这里没有更正的部分。 它的 Why 段落、它实测的证据，以及它对 Evaluation design 下各条要点的说明，都不受影响：要点登记是另一处更正（见下面这条更正末尾的说明）。

Correction 2026-10-05 — one layout field was renamed; the second was deleted (see the correction above)

追加在 docs/DOC-CONTRACT.md §4 之下。上面 Evaluation design 里那条要点是对当前事实的有效陈述，所以就地改正；被取代的措辞照录在这里。下面「What moved」里的字段映射已被上面的更正取代 —— questionPlacement 从未变成这段描述的字段：它同一天就被删掉了，被取代的措辞收在上面的更正里。这段仍然承载的，是这次改名为什么发生，以及代价是什么。

改动了什么。 AssemblyPolicy.xFirst: boolean 现在是 questionPlacement: 'first' | 'last'，而 AssemblyPolicy.stateProxyPosition: 'before-context' | 'after-context' 现在是 tracePlacement: 'trace-as-state' | 'trace-append'。映射关系一一对应 —— true → 'first'，false → 'last'； 'before-context' → 'trace-as-state'，'after-context' → 'trace-append' —— 配置档如果还写着旧写法，会被翻译过来，而不是按默认值运行（LEGACY_LAYOUT_KEYS，packages/core/src/config.ts，它会把这个替换作为警告报出来）。名称、取值和默认值归 packages/core/src/types.ts 和 packages/core/src/config.ts 所有；这里不再复述。

Why。 论文（arXiv:2609.02702，§4.1）把问题放在每个条件的最后 —— "the question appears at the end of the prompt … place it at the end of every input" —— 它的两个分支是 [T, x, q]（Trace as State）和 [x, T, q]（Trace Append），唯一的差别是顺序。xFirst 挪动了问题，也就是论文固定的那个元素，而它的名字把这件事说成论文的变量；stateProxyPosition 本来就是论文的轴，所以沿用了论文的命名。

代价，实测。 轮次 20261004-0233 自己的 layoutOrder 记录：两个 TAS 单元（C1、C2）记录为 pinned, stateProxy, anchor, recalled, tail —— 问题排在第二，这既不属于论文的任何一组，因为两者都设了 xFirst: true；C0（xFirst: false，TAS 关闭）记录为 pinned, recalled, tail, anchor，即论文的基线 M([x, q])。问题回到论文所放的位置后，这些布局不再可能产生，单靠 tracePlacement 就能在论文的两组之间做选择。

被取代的措辞，原文照录：

tas.on/xFirst 在每一组里都被记录，却一组都没送到模型：投递只插入一个 recalled 块，从不插入组装后的顺序，所以顺序只有在模型视图写回之后才可测量，而模型视图写回并不存在（docs/ARCHITECTURE.md §5；packages/proxy 尚未编写）。

尚未处理，且不属于本次更正。 Evaluation design 下面的分组条目 —— 「two controls and one arm under test」，以及「C1 is a second control arm … so its model-visible input is C0's」—— 仍然陈述着 docs/STATUS.md §10 的附录和 cellPolicy() 上方注释在 2026-10-04 取代掉的那套登记（C1 投递 trace，是论文的那一组）。那是另一处更正，留给它自己那一轮。

更正 2026-10-05（第三次）—— recalled 块移到 tail 之后：一次在 x 内部的缓存修复，论文的分组不变

附在 docs/DOC-CONTRACT.md §4 之下，位于上面两处更正的末尾，且不取代其中任何一处。What this is 里有一句现行文字在字面量中带着旧顺序，所以就地更正，原样措辞照录于下。上面第二处更正的 Why. 段落正是报告点出的那句：它陈述论文的变量及其两组，写的是对的，而这条说明就是读者现在需要放在它旁边的东西。

移动了什么。 recalled 块现在紧挨最后一个块之前，位于 tail 之后 —— 它原本是五个中的第三个，后面跟着 recent tail 和当前输入。每个 tracePlacement 值产生的块顺序，就是 packages/core/src/assembler.ts 头部的那张表，而 AssemblyLayout.order（packages/core/src/types.ts）是记录在案的陈述；这里不再把两者重述为规则。

为什么分组没有跟着移动。 论文的变量是 trace T 相对于长上下文 x 的位置 —— 两组是 [T, x, q]（Trace as State）和 [x, T, q]（Trace Append），唯一的差别是顺序 —— 而被召回的块是那段长上下文的一部分（AssemblyLayout.order：当前输入是 q，钉住的前缀和它之间的那些块，就是 trace 被放置其周围的长上下文；packages/dsh-plugin/src/context-delivery.ts：「这里的长上下文就是 recalled 块」）。块移到 x 内部后，T 在它那一侧的位置不变：在 'trace-as-state' 下 T 仍然排在 x 的每个块之前，在 'trace-append' 下则排在它们之后。

块为什么移动。 提示词缓存是前缀缓存：任何一个 token 发生变化，都会从该 token 起一直到提示词末尾匹配失败，所以放在「每步都变的块」后面的内容，都会跟着一起失效。被召回的块正是重新选择时会移动的那个块；把它放在 x 的末尾，意味着重新选择只让问题本身付出代价，别的都不受影响。在轮次 20261004-1458 C2 上实测：这一移动让每对交付内容的整段提示词失效跨度从 2,539 降到 2,111 token，而此前那次排序调整已经把该跨度从 6,179 降到 2,539。

被取代的原文，逐字照录。 What this is 条目里的顺序——「按 Trace-as-State 顺序组装：[pinned prefix | state proxy T | recalled blocks | recent tail | current input]」。现在写作 [pinned prefix | state proxy T | recent tail | recalled blocks | current input]。

保持原样的部分。 上面更正里带日期的证据——轮次 20261004-0233 自己的 layoutOrder 记录，以及记录中提到的那些顺序——属于那一轮的数据，保持可读，不作编辑；它记录的顺序已经无法由任何设置产生，汇编器头部表格对此已有说明。Evaluation design 中关于交付的句子不受影响：交付的文本来自插入通道，没有随这次移动而改变。