比 Jev 更专业，TierSense 正式发布，约 30ms 为 Agent 做关键判断

来源：市场资讯

（来源：机器学习算法那些事）

任务该交给哪个模型？哪些历史可以压缩？什么时候需要找回早先的信息？

这些判断反复出现在 Agent 的运行过程中，也在消耗等待时间。

清枢团队正式发布 TierSense-1「枢衡」（https://tierflow.cn/tiersense）——面向 Agent 三类关键决策的专用模型。三项 API 的单次完整请求均约 30ms，直接返回评分、判断与置信度，供应用程序决定下一步。

TierSense-1.0「枢衡」｜面向 Agent 关键决策的模型

Jev：根据状态与类型化问题，直接返回程序可用的结构化判断。TierSense 采用独立技术路线，专门为 Agent 的模型调度与上下文管理提供快速判断。

随着 TierSense 的发布，我们同步公开了部分支撑 TierFlow 与 TierSense 的四篇研究论文。希望让开发者在体验产品的同时，也能进一步了解相关方

法、实验与技术依据。

从论文中的方法与实验，到实际工作流中的调用与验证，我们也欢迎研究者和开发者提出问题、交流结果。

四篇论文完整内容：访问 TierFlow 研究页面（https://tierflow.cn/research）

首发开放三项独立 API：难度感知、逐步压缩判断，以及压缩与召回判断。开发者可以按自己的工作流选择接入。

难度感知

用于模型选择

逐步压缩判断

用于历史取舍

压缩与召回判断

用于记忆系统

判断交给 TierSense，执行交给 LLM

01PART

让快速判断进入 Agent 的执行过程

Agent 开始执行前，要决定使用哪个模型；工具返回大量内容后，要判断哪些历史仍有价值；继续执行前，还可能需要找回先前的约束。

用 LLM 完成这些判断，需要额外的推理与生成时间。固定规则容易实现，却难以覆盖不断变化的任务状态。TierSense 为这些环节提供专门的评分与判断，让应用能根据当前任务调整策略。

功能示意｜TierSense 提供判断，应用代码组织执行

TierSense 接收当前任务或完整对话上下文，直接返回数值和判断，不生成完成任务所需的代码、摘要或执行内容。应用读取结果后，再组织 LLM 与工具执行。

开发者保留流程控制权：评分怎样映射到候选模型，什么置信度触发压缩或检索，判断不确定时如何处理，都由业务代码配置。

这让决策与执行可以分别优化：TierSense 提供快速的状态判断，应用结合模型能力、预算和任务要求采取行动。

02PART

任务难度：让模型选择有据可依

同样一句“帮我修复这个问题”，背后可能是局部修改，也可能是跨文件定位、多轮工具调用和复杂规划。如果所有任务都使用同一个模型，很难同时照顾响应速度、预算和完成质量。

难度感知 API 接收当前任务与必要上下文，从代码修复、工具调用、多跳推理、任务分解和规划五个维度评分，并根据这五项分数计算总体难度。接口只返回这六个数值，取值范围均为 0–10。

评分维度取值范围

代码修复

0–10

工具调用

0–10

多跳推理

0–10

任务分解

0–10

0–10

总体难度（由五项分数计算）

0–10

功能示意｜五项能力维度与总体难度均返回 0–10 分

总体难度接近的任务，能力要求也可能不同：一个更依赖代码理解，另一个更依赖工具与多步规划。五维评分可与候选模型的能力、预算和延迟要求结合，形成更具体的调度依据。

以代码修复为例，任务开始时可以先评估已知信息，再选择执行模型。若后续排查发现问题涉及更多模块，应用也可以提交更新后的任务与上下文，重新评估当前难度，决定是否调整模型或处理方式。

TierSense 提供评分依据，具体模型由应用选择。开发者可以从简单阈值开始，再用自己的任务数据调整路由策略。

03PART

逐步压缩判断：逐一评估历史步骤

Agent 运行得越久，历史里的内容就越复杂：已经完成的尝试、重复的日志、尚未解决的报错、用户明确提出的约束。它们都占用上下文，但对下一步的价值并不相同。

消息的新旧不能直接代表价值。早先的约束可能仍影响最终结果，刚产生的大段工具输出，也可能只需保留一个结论。判断需要落到具体步骤。

功能示意｜按步骤返回建议，再由调用方执行摘要或压缩

在第 k 步调用主模型前，API 接收完整消息上下文，自动识别前 k−1 步，逐一返回压缩建议、置信度和对应消息下标。

应用根据消息下标定位原始记录，再把选中的步骤交给摘要或压缩流程。

API 本身不生成摘要、不删除消息；建议保留或置信度不足的步骤，可以继续保留原文。

例如，在持续排查问题时，已经完成的定位过程与仍在使用的错误证据，需要不同的处理。逐步建议帮助应用做出取舍，具体压缩方式仍由已有策略控制。

每个建议都能对应到历史消息，便于开发者回查、调试，并结合任务结果调整策略。

04PART

压缩与召回判断：分别识别两种需要

上下文很长，仍可能缺少关键信息。例如，已完成阶段的日志还占着输入空间，而早先的接口约束已经移入外部记忆，后续修改又需要用到它。

因此，是否需要压缩与是否需要召回，应当分别判断。上下文长度只是其中一个信号。

逻辑示意｜压缩和召回分别判断，两种需要可以同时出现

压缩与召回判断 API 接收完整对话，包括用户问题、助手回复、工具调用及结果，分别返回：

• 是否需要压缩，以及该判断的置信度
• 是否需要召回，以及该判断的置信度

两个判断可以同时为真。

一次任务可能既需要收起已完成阶段的细节，又需要找回更早的约束。应用可以先完成相应处理，再把整理后的上下文交给执行模型。

只需要召回时，应用补入检索结果；只需要压缩时，进入已有压缩流程；两者都不需要时，继续执行。触发阈值与处理顺序由调用方配置。

API 只判断当前是否需要处理，不读取外部记忆，也不执行存储与检索。召回哪些内容、怎样补入上下文，由应用完成。

05PART

把三项能力放进一次代码修复任务

以“修复重复订单问题，同时保持现有接口兼容”为例，三项能力可以在不同环节参与判断。

接入流程示意｜按任务需要调用，各项能力可独立使用

提交任务与必要上下文，由难度感知 API 返回评分；应用结合可用模型和预算选择执行模型，再由 LLM 与工具读取代码、定位问题。

多轮排查产生了代码片段、工具输出和尝试记录。应用调用逐步压缩判断 API，按建议选择历史步骤，再交给摘要或压缩流程处理。

调用压缩与召回判断 API。如果需要召回，应用检索外部记忆，补入相关信息，例如早先约定的接口兼容性要求。

STEP 04

整理与交付

整理后的上下文交回执行模型，Agent 继续修改、测试并交付结果。

TierSense 参与判断，实际操作仍由应用组织。

这是一种接入示例，并非固定流水线。三项 API 可以独立使用，不要求每轮都全部调用；效果需要结合实际任务检验。

06PART

约 30ms 返回一次关键判断

三项 API 的单次完整请求均约 30ms。这让开发者可以在模型调用或上下文处理前加入快速判断，减少单纯为了做决策而等待 LLM 的时间。

耗时口径示意｜约 30ms 对应单个 API 的单次请求

如果一次长上下文的 LLM 判断耗时为 10 秒，以约 30ms 计算，同一判断环节的速度比约为 333 倍。

这是给定时间条件下的换算，并非同条件实测，也不代表完整 Agent 任务加速 333 倍。

完整任务仍包含 LLM 生成、工具调用、压缩与检索。实际收益需要同时观察总耗时、成本和任务完成质量；约 30ms 的表现也会随输入与部署环境变化。

///LAST

写在最后：怎么使用 TierSense

GETTING STARTED

可以先从一个最需要优化的环节开始：

• 模型选择

  ，接入难度感知。

• 历史取舍

  ，接入逐步压缩判断。

• 已有记忆系统

  ，接入压缩与召回判断。

从一次真实任务开始：选一组熟悉的任务，记录判断结果、后续处理和任务表现，再逐步调整路由与上下文策略。欢迎带着你的代码任务、长程工作流和上下文管理问题，来体验 TierSense。

官网提供了详细的用户使用指南，可登陆官网查看。

说明：约 30ms 为团队提供的单个 API 单次完整请求耗时约值。文中配图为功能与流程示意，速度比为条件换算。