从 Jev 到 TierSense， Agent 的「判断层」正在被拆出来 | GAIR Paper 132

把难度评估、历史压缩和记忆召回的判断，交给一款专用模型。

编辑丨岑峰

Agent每向前走一步，都可能需要先做出几次判断。

举个例子，一个修复订单接口的编程Agent，在读完代码、查过日志之后，它要决定下一轮该调用哪个模型，哪些历史可以压缩，哪些旧信息需要找回，这些选择不直接产出代码，却影响着后续执行的时间、资源和证据。过去，这类判断通常被塞进大语言模型的提示词里；但现在，一种新的分工正在出现：把判断从生成中拆出来，交给专门的轻量模型。

9 月 15 日，TypeSafe 发布 Jev并提出 System One 模型这一产品路线，正是这一趋势的早期信号：读取输入状态，直接返回软件可以使用的结构化决策。它将快速判断放在了模型能力的中心。

这一思路已经进入具体项目。Browser Use 公开的 jev-ultrafast 让 Jev 选择浏览器操作和目标元素，只在需要输入文字时调用小型 LLM。判断与文本生成，开始在同一个 Agent 中各司其职。

TierFlow 团队联合人大高瓴马彦彪老师和清华大学韩军功教授团队推出的TierSense走的是同一条路，但切入点更为具体。根据官网介绍，TierSense-1「枢衡」提供难度感知、逐步压缩判断、压缩与召回判断三类能力，返回评分或结构化建议，供应用组织执行，单个 API 整次请求耗时约为 30ms。

图 1｜把难度评估、历史压缩和记忆召回的判断，交给一款专用模型TierSense， 约 30ms 响应单词API请求。

https://github.com/wangmingxuan666/Tiersense/

“判断交给 TierSense，执行交给 LLM”，概括了它强调的分工。可以通过API对TierSense进行访问，同时官网还放出了4篇研究论文，作为TierSense的技术支撑。

官网链接：https://tierflow.cn/tiersense

研究报告：https://tierflow.cn/research

从 Jev 的结构化决策，到 TierSense 聚焦的三类 Agent 判断，这类模型提出了一个值得检验的方向：让反复发生的选择交给专用模型，能否让整个工作流更高效？答案要从接口、研究和任务结果中寻找。

01

把三类判断放进 Agent 的执行循环

先看模型选择。TierSense 的难度感知接口从代码修复、工具调用、多跳推理、任务分解和规划五个维度输出分数，各维度为 0–2，同时返回 0–10 的综合难度。

官网文档特别说明，综合分经过内部加权与标定，既不是五项分数直接相加，也不是任务成功率。

分数的用途，要放到任务推进过程中看。同一个代码修复任务，最初可能只涉及一个函数；读到新代码、发现并发约束后，所需能力就可能变化。

应用可以再次评分，结合候选模型、预算和延迟要求，调整下一轮的模型选择。

图 2｜三类接口的返回结果与应用侧动作。分数、建议和置信度的含义不同，不能混读为任务成功率。根据官网接入文档整理。

执行几轮之后，另一类问题出现了：历史消息越来越长，哪些内容还值得继续携带？

TierSense 的逐步压缩接口对可见历史步骤给出建议、置信度和消息下标。开发者还可以配置检查间隔、连续步骤数、token 与置信度门槛，决定何时处理一批历史。摘要生成和消息替换由调用方完成。

02

压缩与召回可以同时发生

图 3｜三类接口各自输出判断，应用把判断转化为具体操作。根据官网及接入文档整理

第三项能力从当前对话整体出发，分别判断是否需要压缩、是否需要召回。这两个问题并不互斥：已完成的排查细节可以收起，早先保存的接口兼容约束又可能需要补回。

这个接口提供需求判断，历史记忆的保存和检索由应用完成。

图 4｜以代码修复为例，同一段历史的作用随执行阶段变化。图中为解释性场景，非产品实测；摘要、存储、检索由应用执行。

一个容易被忽略的细节是置信度。压缩与召回指南明确写明，它表示对最终判断的支持程度，并非经过校准的正确概率。

因此，0.8 不能直接读成“这次判断有 80% 的概率正确”。结构化结果方便程序使用，结果是否可靠仍要通过任务验证。

03

上下文如何取舍

四篇论文给出不同切口

这些接口背后，是长程 Agent 的一个具体难题：同一段历史，在不同阶段的价值可能完全不同。官网列出的四篇论文，分别从压缩时机、证据保留、记忆需求和成组删除风险切入这个问题。

StateComp 研究“何时压缩”。一段错误日志在定位问题时可能不可替代，问题解决后却未必需要保留全部细节。论文据此训练状态相关的判断器，区分仍需保留完整内容的历史与已适合摘要化的历史，并将相邻候选步骤合并处理。

Stable Geometry 研究“保留什么”。论文指出，表示空间中的相似，不等于执行证据相同。计划修改一个文件、真正执行修改、随后读取结果，可能在语义上接近，却分别证明了不同的事情。它提出的 GEM 方法先保护任务与执行证据，再补充几何覆盖。

图 5｜四项研究分别关注时机、证据、记忆需求与成组删除风险。这是研究问题的梳理，不代表四种方法均已直接部署进 TierSe nse 。

Memory Control进一步考察，Agent 行动前的内部状态是否已经包含压缩与召回需求的信号，并提出将状态引导的压缩与外部证据检索结合的 PaMER 框架。

DRSR 则关注多个片段一起删除的风险：单独看都像冗余的信息，合在一起移除后，可能让剩余上下文失去关键依据。

把四项研究放在一起看，核心问题逐渐清晰：上下文管理需要跟随任务状态变化。

历史占了多少 token，描述的是体量；哪些内容还支撑着下一步行动，才决定它们能否被压缩。论文展示了不同的方法路径，对外 API 实际采用了哪些部分，则需与研究系统分别理解。

04

token 减半后 任务表现基本持平

StateComp 的实验提供了一组直观数据。在 WorkBuddyBench 的 260 项任务中，论文使用 DeepSeek-V4-Flash 作为执行模型，比较接入 StateComp 前后的任务表现与 token 消耗。统计包括主 Agent 和摘要调用的输入、输出 token。

图 6｜WorkBuddyBench 的 Full260 实验包含四类任务，各领域任务数不同。按 StateComp 第 5.1 节及附录表 A6 重绘。

图 7｜StateComp 论文第 5.1、5.3 节及表 2 的结果。token 为 260 项任务的合计；平均奖励采用原始尺度，不是任务成功率。本图为论文数据重绘，非 TierSense API 独立测评。

结果是，总 token 从 698.17M 降至 333.24M，减少 52.27%；平均任务奖励从 0.6987 变为 0.7026。

也就是说，在这组实验中，主 Agent 与摘要调用消耗的 token 降低了一半以上，平均任务表现仍然接近。

05

四类任务的收益并不完全相同

把总量拆到四类任务后，差异更清楚了。代码、办公、安全与网页任务的 token 降幅分别约为 38.89%、55.75%、55.42% 和 53.03%。

四个领域的 token 消耗都下降，但任务奖励并未同步上升。

图 8｜StateComp 附录表 A6、A7 的分领域结果。token 包括主 Agent 与摘要的输入、输出；奖励采用 0–1 原始尺度，图中保留四位小数。未展示统计显著性结论。

数据也保留了必要的细节。不同领域的收益并不完全一致，安全类任务的平均奖励略有下降；论文将本地表征提取开销另行报告。

因此，52.27% 对应特定统计口径下的 token 降幅，不能直接改写成 API 费用、总算力或用户总成本下降 52.27%。

其中，安全类任务的 token 总量由约 358.59M 降至 159.85M，平均奖励则从 0.4776 变为 0.4731。这个细节提醒读者：资源消耗下降与任务质量变化，需要放在同一张图里观察。

这组实验给出的启发相当具体：判断一段历史何时可以被压缩，有机会影响整个任务的资源消耗。接下来需要检验的，是这种收益能否在不同模型、任务与负载下重复出现。

06

约30ms的判断能节省多少时间

回到 TierSense 的产品层面，约 30ms 的意义是什么？官网将这一数字标注为团队提供的单个 API 整次请求约值，并用条件测算展示替换判断环节可能带来的变化。

如果原本一次判断需要 10 秒，替换为 30ms，单看这一环节约快 333 倍。

但假设后续执行仍需 20 秒，完整流程只是从 30 秒缩短至 20.03 秒，约快 1.50 倍。

这个条件示例说明，局部加速必须结合它在任务总耗时中的占比来理解。

图 9｜条件测算，非实测。假设后续执行固定为 20 秒，且不计新增压缩、检索等处理。30ms 取自官网团队提供的约值。

较短的响应时间，让“每一步都检查一下”成为更值得尝试的设计。任务难度变了，可以重新评分；工具返回了大段内容，可以再判断是否适合压缩。

最终收益取决于这些检查能否改善后续执行，也取决于输入长度、网络、并发和额外处理开销。

官网目前已经提供三项 API 的接入指南，产品页的交互示例仍明确标注为演示数据、未连接模型。难度指南也公开了团队的历史运行记录，同时说明这些记录展示的是任务识别与逐步评分效果，不构成难度准确率或选模收益的证明。

因此，评价 TierSense 更有意义的问题，是接入后同一组任务能否以更少的时间和资源完成，关键约束是否保留下来，以及判断不确定时系统能否继续稳妥执行。

一次接口响应的速度，只是这份答案的一部分。

07

专用判断模型的机会在哪里

从接口设计看，TierSense 选择了一组高频、输出范围相对明确的问题，再让应用代码把答案接入已有流程。开发者可以先记录评分和建议，观察它们与任务表现之间的关系，再逐步用于选模或历史处理。

这样一来，产品的验证也可以落到具体环节： 依据难度分数切换模型后，任务质量如何变化？ 按照建议生成摘要后，后续步骤是否仍能找到关键证据？ 召回操作带回的信息，是否帮助任务继续推进？

这些结果会决定一次判断的实际价值。

TierSense 值得关注的地方，是把模型能力放到了 Agent 运行过程中反复发生的选择上。随着任务拉长，执行模型需要持续处理新的观察、旧的证据与变化中的约束，为这些信息分配计算资源，也就成为一个可以单独优化的问题。

如果专用判断模型能在更多真实工作流中稳定节省资源，它就有机会成为 Agent 的常用组件。TierSense 正在尝试验证的，正是这份更细的分工：让每一次模型调用之前的选择，也获得模型能力的支持。

资料核对截至 2026 年 9 月 23 日。文中产品能力与性能口径来自官网及公开接入文档，研究结果来自官网论文；本文未进行独立 API 性能复测。

资料来源

1. TierSense 产品介绍：https://tierflow.cn/tiersense

2. 难度感知 API 使用指南：https://tierflow.cn/tiersense/docs/difficulty

3. 逐步压缩判断 API 使用指南：https://tierflow.cn/tiersense/docs/compression

4. 压缩与召回 API 使用指南：https://tierflow.cn/tiersense/docs/context

5. 清枢智汇研究成果页：https://tierflow.cn/research

6. StateComp 论文：https://arxiv.org/pdf/2609.27298

7. TypeSafe Jev 发布介绍：https://typesafe.ai/blog/introducing-system-one-models-and-jev

8. Stable Geometry 论文：https://arxiv.org/pdf/2609.27332

9. Memory Control 论文：https://arxiv.org/pdf/2609.27286

10. DRSR 论文：https://arxiv.org/pdf/2609.27276

11. Browser Use jev-ultrafast 项目： https://github.com/browser-use/jev-ultrafast

为了方便大家抱团交流、互通会议消息，我们专门建了IROS2026参会交流群！进群你会解锁这些「福利」

• 会议情报站：投稿 DDL、格式规范、评审进度……关键节点第一时间送达，再也不怕错过 deadline，投稿准备稳稳的。

• 同行茶话会：天南海北的同行都在群里，聊心得、碰思路、攒人脉，科研路上我们同行。

• 前沿补给站：最新研究成果、热点方向实时同步，结合会议主题帮你捋清投稿脉络，给论文灵感加满油。

• 现场后援团：（会议期间专属开启）：到了会场也不用慌——

  路线导航：场馆分布、报告厅怎么走，群里随时问；

  议题共读：热门 session、Keynote 探讨，错过也能追；

  Poster 汇编：现场海报精华整理，一键收藏不遗漏；

  约局广场：约饭局、采访局、交流局……想唠嗑、想合作、想面基，群里发起就成。

进群传送门：扫码进群或添加微信Luyoyo_2026，备注：ECCV + 单位/学校+姓名+方向。

搞科研/搞技术，信息差很重要。

来，一起快人一步！

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！

公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。