Context 组装应成为独立执行引擎
ContextPipe 将上下文组装从调用前的拼接逻辑提升为可规划、优化、执行与反馈的运行时子系统。
原文：ContextPipe: A Context-Engineering Runtime for Long-Horizon Agents（2026-09-01）。
一、Context 问题已经从“装多少”转向“如何执行”
长任务 Agent 的上下文同时包含系统指令、工具定义、历史消息、记忆、检索结果、制品摘要和本轮临时状态。传统写法把它们在调用前依次追加：
const messages = [systemPrompt];
messages.push(...history);
messages.push(...retrievedMemory);
messages.push({ role: "user", content: input });
if (estimateTokens(messages) > limit) {
messages.splice(1, Math.floor(messages.length / 2));
}
return model.generate({ messages, tools });这段逻辑把来源发现、I/O、预算分配、裁剪、排序、缓存和模型调用混在一起。其结果是：无法解释某段信息为何进入上下文，无法安全并行检索，无法稳定复现裁剪决策，也无法知道模型实际消耗与计划偏差来自哪里。
二、五阶段管线重新划分了责任边界
| 阶段 | 允许做什么 | 禁止混入什么 |
|---|---|---|
| Plan | 选择来源、估算预算、生成依赖图 | 网络或存储 I/O |
| Bind | 读取历史、记忆、检索与制品 | 随返回顺序临时改策略 |
| Optimize | 确定性裁剪、压缩、排序和降级 | 隐式 Provider 调用 |
| Execute | 提交最终请求并接收响应 | 再次拼接不可追踪内容 |
| Feedback | 记录实际使用量、缓存与截断 | 仅记录最终答案而忽略执行事实 |
Plan 保持纯函数尤其关键：同样的目录、任务状态和预算应生成同样的计划，使单元测试、离线回放和 shadow diff 成为可能。Bind 成为唯一 I/O 阶段后，互不依赖的检索可以安全并行。
三、Context Source Catalog 是运行时的“系统表”
ContextPipe 为每个来源登记元数据，包括生命周期层级、内容类型、作用域、优先级、估算 Token、绑定延迟、可恢复性、可标记性和依赖关系。这相当于数据库优化器依赖的 catalog：
interface ContextSource<T> {
id: string;
tier: "system" | "session" | "turn" | "emergent";
kind: "instruction" | "history" | "memory" | "artifact" | "tool";
scope: "global" | "session" | "none";
priority: number;
estimatedTokens: (state: RunState) => number;
bindLatencyMs: number;
recoverable: boolean;
markerable: boolean;
dependencies: string[];
bind: (state: RunState, signal: AbortSignal) => Promise<T>;
}
const plan = contextPlanner.plan({
catalog,
runState,
modelWindow: 128_000,
responseReserve: 8_000,
thinkingReserve: 12_000,
schemaReserve: toolRegistry.estimatedTokens,
});
const bound = await contextBinder.bindConcurrently(plan);
const optimized = contextOptimizer.optimize(bound, plan.pressureTier);
const result = await executor.run(optimized.request);
feedbackStore.record(plan, optimized.trace, result.usage);这不是要求所有来源共享同一种数据格式，而是要求它们共享一组可用于决策和解释的元数据。只有被目录化，Context 才能参与预算、依赖和生命周期管理。
四、预算应包含即将发生的消耗
只用当前 Prompt Token 判断压力会低估响应、推理和工具 schema 的占用。论文区分原始压力与预测压力：
Praw=TL Ppred=T+RLT 是当前上下文估算，L 是模型窗口，R 是响应、思考与 schema 预留。论文给出的压力档位为：
| 预测压力 | 策略 | 含义 |
|---|---|---|
| [0, 0.60) | Normal | 保留正常上下文 |
| [0.60, 0.75) | TrimSchemas | 先压缩工具 schema |
| [0.75, 0.90) | CompactHistory | 压缩历史并保留关键锚点 |
| [0.90, 1] | AggressivePrune | 激进裁剪低优先级来源 |
预测只能把策略升级，恢复阶段还可继续升级；系统消息不得被删除。工程上应吸收“单调升级、保护不变量”的思想，但这些阈值来自特定实现，不是跨模型、跨业务的通用常数。生产系统应以实际截断率、质量损失、缓存价格和尾延迟校准。
五、缓存优化不是简单追求更高命中率
ContextPipe 把稳定、低波动内容放在前面，把频繁变化的内容放在后面，以形成可复用前缀。但实验出现了一个反直觉结果：结构化方案减少总 Prompt Token，却让 fresh token 增加、缓存命中率下降。因此成本必须同时考虑 fresh 与 cached token：
E(r)=fresh+r·cached论文据此得到盈亏平衡点 r*=0.145。当缓存 Token 单价低于 fresh Token 的约 14.5% 时，扁平基线可能更便宜；高于该比例时，结构化方案更可能节省成本。结论不是“压缩越多越省”，而是 Context 成本是 Token 数、缓存结构、价格、时延与质量的联合优化。
六、必须明确记录论文的数字不一致
摘要声称总 Token 减少 31%、LLM 调用减少 23%、响应时间减少 9%。但论文表 4 的均值为：
| 指标 | Flat | Structured | 按表格计算 |
|---|---|---|---|
| 总 Prompt Token | 1,045,222 | 730,978 | 减少 30.1% |
| Fresh Token | 46,581 | 99,967 | 增加 114.6% |
| Cache hit | 95.3% | 86.2% | 下降 9.1 个百分点 |
| Duration | 204 | 188 | 减少 7.8% |
| LLM calls | 30.2 | 25.0 | 减少 17.2% |
正文附近又写成调用减少 23.1%、时延减少 8.7%，与表格不一致。稳妥做法是把表 4 的原始数值作为可复算证据，并将摘要百分比标记为作者报告而非无条件采用。
七、EXPLAIN ANALYZE 比某个裁剪算法更值得产品化
ContextPipe 最具长期价值的产品思想，是为每次模型调用输出可解释执行轨迹：
{
"planId": "ctx-1842",
"pressure": { "raw": 0.68, "predicted": 0.82, "tier": "CompactHistory" },
"sources": [
{ "id": "system", "decision": "keep", "estimated": 2140, "actual": 2098 },
{ "id": "tool.schemas", "decision": "trim", "before": 18400, "after": 6200 },
{ "id": "history", "decision": "compact", "before": 51000, "after": 17300 },
{ "id": "artifact.summary", "decision": "keep", "bindMs": 42 }
],
"provider": { "promptTokens": 29211, "cachedTokens": 9600, "truncated": false },
"predictionError": { "tokens": -527, "ratio": -0.018 }
}这让开发者能回答：哪条规则删除了信息、哪种来源拖慢了请求、预算估计为何失准、缓存结构为何变化。新优化器可以先在 shadow 模式下生成计划，与旧请求做 diff，而不直接改变用户结果。
八、还不能由这篇论文推出什么
端到端实验只覆盖 Qutebrowser 子集中的 3 个任务，每个重复 3 次。机制级消融 A1–A4 仍未完成，端到端 solve rate 消融也被列为未来工作。因此论文足以支持“Context 应成为独立、可观测的运行时子系统”，不足以证明这套固定阶段、阈值或策略已在广泛任务上优于其他实现。
对 Agent 工程的合理迁移顺序是：先建 Catalog 与 EXPLAIN Trace，再引入预测预算和确定性策略，随后 shadow 对比，最后才让优化器影响生产请求。先获得可观测性，再追求自动优化。
结语
ContextPipe 的价值不在“节省 31% Token”这一句摘要，而在它改变了 Context 的系统身份：Context 不再是模型调用前的一段拼接代码，而是一个拥有目录、计划、执行、反馈与解释能力的执行引擎。这个方向值得进入 Agent Runtime；论文中的固定阈值和性能数字，则应继续接受更大规模、可复现的验证。