上下文分诊 · Context Triage

Agentic Context Engineering (ACE)：让上下文自我进化

它改了什么。 今天大部分生产 agent 在上下文摄入的那一刻就给每段内容打优先级 — 一份文档是 P0、一行日志是 P2、一份过期的规范是 P3 — 然后整个会话都把这个标签当事实 用。前 30 轮这套做法跑得动；下 30 轮就开始崩，因为 agent 此时已经学到了东西：当初的 P0 把它带偏 了，当初的 P3 反而是关键。ACE 引入了一个独立、持续存在的对象 — 论文叫它“策略手册” (playbook) — agent 每一轮结束时根据刚刚发生的事重写这个手册，下一轮再把改过的手册作为上 下文的一部分摄入。这样一来，agent 对“什么重要”的判断不再被锁死在最初的摄入时刻。

为什么对分诊有意义。 这个领域一直在犯的根本错误，是把“摄入时打的优先 级”当成“整个会话都成立的优先级”。优先级其实是一个活的假设，会随着 agent 学到 更多而衰减。一个从不修订标签的分诊层，等于在让模型继续相信一个小时前的猜测 — 而那个猜测当 初根本无法预料到现在的输入。到第二小时，这就是 agent 开始对“显而易见的事实”产生幻 觉的最常见原因：相关上下文技术上还在窗口里，但优先级压得太低，模型已经不去注意它了。

你应该怎么做才不一样。 别再把优先级存在 hashmap 里。改用一个 append-only 的日志 ，键是 (token-id, 轮次, 修订证据)。每一次优先级变更都是一条新记录，附带“为什么改” — 是哪一次观察暴露了上一个标签是错的。每轮结束时的反思步骤就是写这个日志最自然的位置。 这样有两个好处：复盘时修订是可审计的，一次质量回退可以追到当时做出决策的那一轮；agent 自己也 可以回过头读自己的历史，问“我当时为什么把这个事实降级了？”。这是 agent 在会话内自我 改进的结构性前提 — 没有这一条，对话内 agent 学不到任何东西。

头条数据。 Agent benchmark 提升 10.6%，金融 benchmark 提升 8.6%。让认真考虑采购 的客户停下来看的那个结果在 AppWorld：跑 ACE 的开源 backbone agent 在整体得分上和顶级闭源生产 系统打平，在更难的评测分片上反超它们。机制不是更大的模型，不是更多 token，而是一个被允许 “改主意”的分诊层。

PAACE：计划感知的自动化 agent 上下文工程

它改了什么。 在 PAACE 之前，一段上下文拿到的优先级只取决于事实本身：“这是 个 Stripe 交易 ID，给它打分。”PAACE 加了第二个维度 — agent 当前的计划步。同一个 Stripe 交易 ID，如果 agent 下一步是“诊断这次具体的支付失败”，它会被打成 P0；如果下一步是 “总结上周基础设施延迟趋势”，它会被打成 P3。事实没变，变的是 agent 接下来要拿它做什么 。PAACE 把这种依赖显式表达出来 — 训练了一个小的蒸馏打分器，输入是 (事实, 当前计划步) 这个 元组，agent 的完整计划作为支撑上下文。

为什么对分诊有意义。 没有计划感知，每个分诊层都会退化到同一个防御性策略：把 “接下来 10 步任何一步都可能用到”的东西全留着。这就是悄无声息吃掉 token 预算的策略。 一个涉及 10 个子系统、50 步的计划，会在前 5 步内积累所有 10 个子系统的上下文，分诊层却没办法说 “我们现在已经稳定在子系统 A 了，子系统 B 到 J 可以降级了”。结果是 agent 把死重一直背 到会话结束。PAACE 是第一篇给分诊层提供这种“减重信号”的论文。

你应该怎么做才不一样。 训练（或蒸馏）一个小路由器，输入键是 (事实, 计划步)， 不是 (事实) 本身。PAACE-FT 是开源配方。把这个小路由器放在每一轮跑，而不是只在会话边界跑。 一个关键细节：路由器必须把 agent 的当前计划作为显式输入，而不是塞进 system prompt 里 的软提示 — 计划与优先级之间的依赖太强，不能交给 in-context learning 自己悟。

为什么这件事在经济上重要。 “每轮重新分诊”以前贵到做不到 — 每轮 要调一次前沿模型，成本反而把正事挤掉了。PAACE-FT 把这个成本压到差不多一次 embedding 查询的量级。 这是“每轮重新分诊”从奢望变成默认架构选项的分水岭。对长跑的 agent 来说，正是这个成本 临界点的跨过，让计划感知的分诊第一次在经济上撑得住。

头条数据。 蒸馏出来的压缩器在 1/10 推理成本下保留教师模型 97% 的准确率。在 AppWorld、OfficeBench 和 8 目标多跳 QA 基准上测试，准确率和 F1 都比对比里的每一个 baseline 高， 同时用的 agent 步数更少、峰值 token 更低。

SWE-Pruner：编码 agent 的自适应上下文剪枝

它改了什么。 SWE-Pruner 给编码 agent 专门引入了一个分诊层 — 一个 0.6B 参数 的神经模型（论文叫它“速读器”skimmer），坐在前沿模型前面，逐行读源代码，决定哪些行能 真正进入前沿模型的视野。速读器小到可以每轮都跑，延迟成本几乎不可见。关键一点：速读器把 agent 当前的目标作为显式输入 — 比如“找出这个空指针错误的原因” — 用这个目标给每 一行打分。跟目标没有合理关联的行，在前沿模型把它们加载进上下文之前就被丢掉了。

为什么对分诊有意义。 这篇论文把大部分团队隐约感觉到但没量化的经济事实摆出来了： 前沿编码模型大头的 token 预算花在“读”上 — 看那些它最终并不会改动的代码。如果读 主导账单，那么放在模型前面的分诊层就不是边际优化，而是整个系统里最大的成本控制杠杆。大部分团队 在这一块投入不足，是因为他们假设模型在拿那些上下文“做有用的事”。数据告诉你它通常没在 做有用的事。模型是在防御性地读 — 因为它别无选择，每一次读都是“万一这个有用”。 一个建得好的分诊层，恰恰就是给模型一个理由“不必再防御性地读”。

你应该怎么做才不一样。 别再把分诊当成一次性的重预处理。把它做得像 tokenization 一样便宜，每轮都跑 — 每当 agent 的目标收窄一次，分诊层就应该重新打一次分。0.6B 速读器就是 参考设计：小到可以为你的领域微调，小到可以在 CPU 上跑，结构上又简单到任务定义一变你就能换掉。 目标提示要当作一等输入显式传给速读器 — 不要把它埋在 agent 的 system prompt 里让速读器自己 去挖。

头条数据。 在 SWE-Bench Verified（编码 agent 的标准基准）上，SWE-Pruner 把 token 用量削减 23–54%，同时保持或提升成功率。在 LongCodeQA 上达到 14.84× 压缩。能改变 你产品路线图的那个数字：一个少读 14.84 倍代码的编码 agent 表现并不变差 — 在生产规模上，这个 比例往往就是“每个客户都亏”和“开始盈利”之间的距离。

SideQuest：长程 agent 推理的模型驱动 KV 缓存管理

它改了什么。 在 2026 年之前，几乎所有分诊决策都发生在 prompt 组装时 — 在 模型开始推理之前。SideQuest 把这个决策搬进推理本身。第二条线程 — 论文叫它“副线 程”side thread — 跟主推理循环并行跑，持续给 KV 缓存里的 token 打效用分，等 agent 看到推理怎么展开之后，再把低效用的 token 驱逐掉。主推理线程永远不被副线程阻塞 — 驱逐 在后台发生，压缩后的缓存再回灌到推理的下一步。

为什么对分诊有意义。 Prompt 时刻的分诊有一个结构性的盲区：在你组装 prompt 的那 一刻，你根本不知道哪段上下文最后会承重、哪段只是装饰。那个信息只存在于推理过程中段。 “第 7 步那个观察其实关键”最早只能在第 8 步知道 — 而到了第 8 步，一次性摄入过滤 器早就锁死了它的选择，没办法修订。SideQuest 的洞察是：长程 agent 里分诊正确的位置，和 CPU 分支 预测器待的位置是一样的 — 在推理路径里，盯着正在发生的事，有权在推理进行过程中修订缓存。

你应该怎么做才不一样。 架构分成两种清晰的情况。如果你控制推理栈 — 也就是 说你跑的是 vLLM、SGLang、TensorRT-LLM 或类似的可改造服务框架 — SideQuest 的“飞行中 驱逐”现在做得到，对任何超过 50 步的 agent 来说，这大概率就是该选的架构。如果你不控制推理 （大多数直接用 Anthropic 或 OpenAI API 的团队），教训不一样但同样重要：把硬约束逼回 prompt 窗口，在你能做分诊的地方做分诊。不要因为 API 不暴露 KV 缓存就假装它是无界的。

更深一层。 分诊不再是“模型跑之前做的事”，而是“模型跑的过程中 持续做的事”。这是一个要求更高的架构，对短程 agent 不划算。但对今天定义前沿的长程 agent — 跨小时的编码会话、跨天的研究 agent、跨周的合规审查 — 这是唯一能在深度上撑得住的 架构。

头条数据。 SideQuest 在长程 agent 任务上把峰值 token 用量削减 65%，准确率几乎 不掉。能让你的路线图委员会停一下的那个数字：整个系统只用了 215 个训练样本。任何有适度微调预算 的团队都够得着。

Triage：基于代码质量信号把 SE 任务路由到成本合适的 LLM 分层

它改了什么。 2026 年 4 月这篇直接以“Triage”命名的论文把模式向一个 重要方向推广了。在它之前，“上下文分诊”的意思是决定哪些 token 进入一个给定的模型。这 篇论文问的是更前一个问题：哪个模型来处理这个任务？ 用一个对到来任务做的廉价信号 — 论文里用代码健康度指标，但框架可以推广到任何廉价代理 — 把每个任务路由到三个模型层之一： 轻量（Haiku 形态）、标准（Sonnet 形态）、重型（Opus 形态）。每一层的输出都过同一道验证 门。验证门是安全机制：正因为有它，“省钱但安全”的路由才成为可能 — 错误的路由会 在验证时被抓住，而不是落到客户面前才暴露。

为什么对分诊有意义。 每一个跑认真 agent 的团队最后都会发现同一个月度账单模式： 80% 的成本来自 20% 的调用 — 具体说，是那些重型模型调用。系统里每一块省钱空间都在“把 那 20% 的某一部分往下推一档”。难题一直是“怎么把一次调用往下推，又不会悄悄降质？” 诱惑是事前 gate — 预测任务难度，按预测路由。问题是预测不完美，而一个被路低了的难任务不会 显眼地出错；它会变得微妙地出错，回退一直藏到落到客户面前才暴露。Triage 这篇论文的贡献 是这套纪律：事后验证，不是事前 gate。让便宜的那一层先试，验证步骤抓住“ 便宜那层不够用”的情况。

你应该怎么做才不一样。 把 agent 建成两层同心圆的分诊。外层：基于廉价信号做模型 分层路由（本文）。内层：在选中的那一层里做上下文分诊（前四篇）。两层分别上报指标，让你能各自 独立调试 — 否则一次路由回退和一次上下文剪枝回退从外面看长得一样。汇报给领导的时候 — 你一定要汇报，因为省下来的钱不小 — PPT 上要放论文里的两个可证伪条件：轻层通过率必须大于 层间成本比（意思是便宜那层对的次数足够多，路由在经济上才划得来），代码健康度的效应大小至少 p̂ ≥ 0.56（意思是这个信号真的能区分容易任务和困难任务）。这是 CFO 能签字 的两个条件。

更深一步。 分诊不再是上下文过滤器，而是异构模型之间的预算分配器。一旦 你看到这一步，同样的模式就可以套到 embedding 模型、检索索引、图像生成器 — 任何有多档成本/ 质量分层的系统。模式迁移过来了，介质没变。

头条数据。 在 SWE-bench Lite（300 任务）上评测。三种路由策略正面对比：启发式 阈值、训练 ML 分类器、完美 hindsight oracle。Oracle gap 是这篇论文能发出来的原因 — 它告诉 你一个真实路由器建好之后，桌上还剩多少省钱空间，给你一个明确的目标数字，随着路由变好而逐步逼近。