来源：市场资讯
（来源：机器学习算法那些事）
任务该交给哪个模型？哪些历史可以压缩？什么时候需要找回早先的信息？
这些判断反复出现在 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 单次完整请求耗时约值。文中配图为功能与流程示意，速度比为条件换算。
热门跟贴