Agent 的下一轮效率竞争，发生在每一步调用之前

来源：市场资讯

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

把合适的模型和必要的信息，放到真正需要它们的那一步。

一个代码 Agent 接到“修复并发下的重复订单”任务，接下来可能要读文件、找调用链、定位竞态、修改代码、执行测试。这里面，有些步骤只是整理信息，有些步骤却决定修复是否成立。如果整条链始终使用同一档模型、反复携带全部历史，预算就很难与每一步的实际需求精确匹配。

问题由此变得具体：什么时候值得调用更强的模型？什么时候可以收拢历史？什么时候又必须把旧证据找回来？这些看似细小的判断，持续影响着完整任务的成本与可靠性。

要回答这些问题，可以在每次调用前增加一层状态评估：先判断下一步需要什么能力，再决定携带哪些信息、是否恢复历史证据。模型选择、上下文压缩和记忆召回，也就成为相互关联的决策。优化的重点随之落到每一步如何分配资源上。

本文看点

01

控制层与接口契约

02

状态、证据与压缩策略

03

实验结果与完整成本

每一步的难度不同，算力也应该重新分配

任务开始时确定一个模型，只完成了第一次资源分配。随着工具返回新证据，下一步可能从简单检索变成复杂推理，也可能从困难排查变成机械确认。有效的调度需要在这些变化发生时，重新评估能力需求。

具体做一次选模，需要同时考虑当前任务、候选模型的能力，以及预期的消耗。上下文怎样组织，也会影响模型的选择。在 TierFlow（tierflow.cn） 公开的调度流程中，BrainNet-8B 参与任务感知，任务理解、上下文与记忆优化、模型能力映射和成本预测被纳入同一次步骤级决策。〔13〕

产品截图 A｜TierFlow 官网“产品原理”区域。页面中的模型名称、能力与时延描述来自官方披露；截图用于展示产品设计，不代表本文复测。2026 年 10 月 1 日截取。〔13〕

在第 t 轮调用前，应用已有原始任务、当前消息历史和工具结果。TierSense (https://tierflow.cn/tiersense) 对这些可见输入给出判断，应用再组织上下文、选择模型，进入下一轮执行。官方给出的组合方案包含这一顺序，但三类接口可独立启用，不需要每轮全部调用。〔2〕

图 1｜基于官方集成指南绘制的可选控制流程。虚线框内为 TierSense 判断；摘要、检索与选模动作由应用执行。〔2〕

可以用一个受约束的优化问题理解这层控制。设当前状态为 sₜ，应用需要选择模型 mₜ、保留的信息 Hₜ，以及记忆操作 aₜ。目标是在满足质量与时延要求的条件下，降低完整任务的期望成本。

ANALYTICAL MODEL

min E[C_task]

subject to Q_task ≥ Q_min

L_task ≤ L_max

本文用于解释设计目标的抽象式；不是 TierSense 对外公开的训练目标，也不是质量保证。

模型决定一次调用能做到什么，调度层负责让不同步骤获得合适的能力与输入。推理加速、上下文压缩和动态选模能够叠加，最终要看整条任务链是否因此更划算。

把“凭经验判断”，变成可以接入的信号

自己搭建 Agent 时，判断逻辑经常散落在提示词、长度阈值和路由规则里。TierSense 提供了一种更清晰的组织方式：把三类常用判断封装成接口，让业务系统能够分别使用、记录和校准。〔1〕

表 1｜三类接口的职责边界。接口名为简写，完整路径见官方文档。〔3〕〔4〕〔5〕

接口

返回的核心信号

应用侧动作

Score

五维特征分、综合难度

校准阈值并选择候选模型

Compress

逐步建议、消息位置；可选执行策略结果

按选定片段生成摘要并替换历史

Memory-Decide

压缩与召回两项判断、各自置信度

检查前提后，启动压缩或历史检索

Score 覆盖代码修复、工具调用、多跳推理、任务分解与规划五个维度，各项为 0–2，综合难度为 0–10。综合分不是直接求和，也不是任务成功概率。选模时应在自己的候选模型集合上，建立分数区间与任务表现之间的经验关系。〔3〕

产品截图 B｜TierSense 官网难度感知演示，展示任务输入、综合分与五维评分。页面明确标注“预设案例 · 演示数据，未连接模型”，图中 6.8 分不是本文的 API 实测。2026 年 10 月 1 日截取。〔10〕

例如，可以先观察哪些步骤在较小模型上已经稳定达标，再让评分参与路由。对无法稳定区分的任务保持更保守的配置。这样，难度评分提供状态特征，最终路由政策仍由业务约束决定；不能直接假定某个分数就对应某个模型。

Memory-Decide 的两项判断可以同时为真。它表达当前是否需要某种记忆操作，不返回摘要或已检索的内容。文档明确，其 confidence 是对最终判断的支持程度，不是经校准的正确概率。〔5〕

判断信号独立出来，开发者就能把业务目标写进执行策略：质量底线、候选模型、预算与回退条件，都有了明确的接入位置。

这也解释了两种产品形态的配合关系：已有自建执行系统的团队，可以用 TierSense 补充可独立接入的判断能力；希望通过统一入口使用自动调度的团队，则可以从 TierFlow 的大模型 API 开始。它们的接口职责需要分别理解。〔1〕〔13〕

前沿性，藏在“按状态管理信息”这件事里

状态相关的决策，是这条路线最值得深入的部分。TierFlow 公开的研究论文把问题推进到四个层面：何时压缩、何时召回、保留哪些证据、哪些片段可以一起删除。它们为理解产品的技术方向提供了依据，具体线上实现以接口文档和厂商披露为准。

TierFlow 官网的研究成果界面（https://tierflow.cn/research）公开了多项研究成果

表 2｜四项研究与控制问题的对应关系。表中是研究方法概括，不是线上系统组件清单。〔6〕〔7〕〔8〕〔9〕

研究

核心问题

技术切入点

StateComp

历史何时适合摘要化

状态相关的 KEEP／READY 判断

Memory Control／PaMER

当前是否需要记忆操作

行动前隐藏状态与历史证据检索

Stable Geometry／GEM

压缩时保留什么

优先保护任务和执行证据

DRSR

哪些历史能一起删除

学习候选删除集合的风险

StateComp 将历史交互与当前状态共同用于判断，在冻结语言模型表征上训练路由器，再把相邻候选交给摘要模块。其技术要点是可压缩性随执行状态变化，不只由信息年龄决定。〔6〕

Memory Control 则考察能否从行动前的隐藏状态预测压缩与召回需求。论文比较显示，隐藏状态的线性探针在两项任务上的 AUROC 高于长度／轮数及元数据基线；这说明状态表征包含额外的预测信息。〔7〕

表 3｜Memory Control 论文表 1 的平均 AUROC，越高表示区分能力越好；它不是 API 准确率。〔7〕

信号来源

压缩 AUROC

召回 AUROC

长度／轮数

元数据

隐藏状态＋线性探针

隐藏状态＋MLP

这类探针结果具有预测意义，不能单独证明模型内部存在可因果解释的记忆控制机制，也不意味着接口可以直接读取任意第三方模型的隐藏状态。PaMER 在研究系统中结合状态引导的压缩与外部证据恢复，强调近期状态与远期证据的互补。〔7〕

GEM 关注一个常见误判：语义或几何上接近，不代表执行证据相同。“准备修复”“已经修改”“验证通过”可能谈论同一目标，却分别表示计划、动作和结果。保留历史时需要关注信息在证据链中的角色。〔8〕

DRSR 把删除集合本身作为风险判断对象，并通过离线反事实删除构造监督。这个思路解决的是组合效应：两个片段分别可删，并不保证同时删除仍然安全。部署时，它在约束下选择候选，必要时不删。〔9〕

这几项研究让 TierFlow 的上下文与记忆优化有了更值得讨论的技术背景：压缩率之外，系统还要考虑后续行动需要怎样的证据。对于跨很多轮才能完成的 Agent，这比单看窗口容量更接近真实的工程问题。

该忘的收拢，该留的证据不能断

以下用一个代码排查场景演示。任务初期，原始错误日志仍是定位问题的依据；根因确认后，一部分搜索过程和中间解释可以被收拢，但接口约束、未解决问题与验证结果需要继续可用。图中的状态变化是解释性示例，不是对真实请求的预测记录。

图 2｜任务推进会改变历史的保留需求；是否执行摘要，还必须经过连续片段和执行门槛。示意图，非实测轨迹。

Compress 的执行策略按检查间隔、置信度、连续片段与片段门槛依次处理。以 span＝3、min_tokens＝2000 为例，需要同一片段至少 4 步且超过 2000 Token；中间出现保留步骤时，应分成不同片段，不能跨段累加。〔4〕

表 4｜门槛示例。假设检查已到期，且这些步骤均建议压缩并通过置信度筛选。〔4〕

连续步骤

同段 Token

执行摘要

4 步

1200

否：Token 不足

3 步

2600

否：步数未超过 3

4 步

2600

是：两项同时满足

把建议落成执行，还需要事务式更新思路：对历史建立快照，按快照中的消息位置取原文，完成摘要后再提交替换。否则，新消息到达或多个片段索引移动，都可能让正确建议作用在错误位置。官方指南也要求维护消息对应关系，并在失败时保留原上下文。〔2〕〔4〕

INTEGRATION PSEUDOCODE

snapshot, version = history.snapshot()

decision = tiersense.compress(snapshot)

pending = []

for span in decision.executable_spans:

summary = summarize(span.source)

validate(summary, required_evidence)

pending.append((span, summary))

history.commit_if_unchanged(version, pending)

# On failure: preserve history; log and retry safely

工程示意伪代码，不是可直接运行的 SDK。字段名称经过简化；摘要校验与版本控制由应用实现。

落地时，摘要至少要守住任务约束、证据位置、已确认结论、失败原因与未完成事项。重要约束还可以放进独立保护区。这些工程工作说明，让压缩长期可靠地运行需要判断、执行和回退共同配合；也是评估一套调度服务时值得深入的地方。

节省的价值，要和任务表现放在一起看

StateComp 在 WorkBuddyBench 的 260 项任务上，以 DeepSeek-V4-Flash 为执行模型进行比较。总 Token 统计包含主 Agent 与摘要调用的输入、输出，本地表征计算另计。图 3 展示消耗与质量两个维度。〔6〕

图 3｜StateComp 论文表 2 数据重绘。Token 单位为百万；奖励使用原始尺度。研究结果不等于 TierSense 商业 API 的独立实测。〔6〕

表 5｜分领域平均奖励，原论文表中数值为奖励乘以 100，此处恢复为原始尺度。〔6〕

任务领域

基线

StateComp

代码

办公

安全

网页

总体

总 Token 从 698.17M 降到 333.24M，降幅约 52.27%；总体奖励接近，但安全类略降。因此，证据更适合支持特定实验中的效率收益，不能扩展为所有领域质量都会提高，也不能将平均奖励当成成功率。〔6〕

这组结果展示了一种值得继续验证的可能性：通过更合理地组织历史，Agent 可以减少大量重复输入，同时保留接近的总体任务表现。对于 TierFlow 所关注的长链路场景，把预算从冗余输入转向关键步骤，正是一个有实际意义的优化方向。生产评估仍需补充任务分布、重复运行方差与失败样本。

为什么能省钱：减少错配，也减少重复支付

把前面的技术连起来，收益路径就清楚了：简单步骤使用合适的模型，历史收拢后减少重复输入，必要时再恢复证据。TierFlow 将这些环节放进统一调度入口，TierSense 则让开发者能按需接入判断信号。经济性取决于节省能否覆盖新增开销，下面用完整任务口径拆开计算。

ANALYTICAL MODEL

C_total = C_main + C_decision

+ C_summary + C_memory + C_tools

C_qualified = C_total / N_qualified

总额按完整评估批次统计，失败调用与重试已包含在各项成本中，避免重复计费；N_qualified 为达标完成任务数。

历史压缩尤其适合从未来多轮的重复输入中获益。假设一段历史被减少 ΔT 个 Token，后面还会被带入 R 轮，未缓存输入单价为 p，那么可减少的输入费用可近似为ΔT×R×p。缓存比例、摘要开销、路由变化和重试都会改变真实结果。

ANALYTICAL MODEL

Approx. net saving = ΔT × R × p − C_added

仅用于说明盈亏平衡；R、缓存价格及新增开销必须按真实工作流测量。

时间收益同样受原有判断占比限制。官网给出的约 30ms，是团队提供的单个 API 整次请求约值，不是全部网络、输入长度和并发条件下的时延保证。〔10〕

图 4｜条件测算，非产品实测。费用示例为 100→65＋8＝73；耗时示例为 40×1s＋160s→40×0.03s＋160s。

示例中，判断环节从 40 秒降为 1.2 秒，整个任务从 200 秒降为 161.2 秒，缩短 19.4%。局部加速约 33 倍，整体只加速约 1.24 倍，原因是主要执行耗时仍然存在。若原来用的是极快的本地规则，增加远程判断还可能变慢。

技术优化的验收对象应是“合格任务的单位成本与完成时间”。Token、模型价格和接口延迟，都只是组成项。

还有一项不在 Token 账单里的成本：团队维护模型适配、切换与重试逻辑所花的时间。TierFlow 通过兼容现有调用方式来降低接入工作量，这使团队可以更早把精力放到自己的任务集与验收标准上。具体能减少多少维护工作，取决于现有系统的复杂度。〔13〕

把调度能力接进现有 Agent，才是产品落点

对于希望先验证整体收益的团队，TierFlow 给出的入口比较直接：保留现有 OpenAI SDK 调用方式，将服务地址指向 TierFlow，并使用其支持的模型标识。任务分析、模型匹配、重试与成本控制由平台在内部处理。研究与工程能力的产品价值，就体现在开发者可以实际接入的服务边界上。〔13〕

产品截图 C｜TierFlow 官网开发者接入区域。当前页面示例使用 https://tierflow.cn/v1 与 tierflow 模型标识，也列出 tierflow_pro。2026 年 10 月 1 日截取；接入时以官方最新文档为准。〔13〕

TIERFLOW / JAVASCRIPT

import OpenAI from 'openai';

const client = new OpenAI({

baseURL: 'https://tierflow.cn/v1',

apiKey: process.env.TIERFLOW_API_KEY,

const result = await client.chat.completions.create({

model: 'tierflow',

messages: [{ role: 'user', content: '分析并修复重复订单问题' }],

按官网接入方式整理的最小请求示例，尚未执行。完整 Agent 仍需自己的工具执行循环；接入时核对当前支持的参数与能力。〔13〕

已经建立专有模型路由、摘要与检索流程的团队，则可以从 TierSense 的单个接口开始，保留自己的执行策略。这样的选择空间很实用：团队既能直接验证统一调度的任务收益，也能从一个明确的瓶颈切入，逐步改造。〔2〕〔13〕

表 6｜建议的分阶段评估方案。保持任务集、验收规则与预算口径一致；这是本文的工程建议。

实验组

启用内容

主要观察

A｜原始基线

现有 Agent

建立质量、费用和时延分布

B｜旁路记录

只记录评分与建议

观察信号与实际难度的关系

C｜单模块

分别启用压缩、召回或路由

识别每项模块的净贡献

D｜组合流程

启用验证有效的组合

检查相互影响、失败回退与尾部延迟

试验时同时记录质量、账单和完成时间，并把判断错误与接口故障分开观察。超时不是“无需压缩”，召回建议也不意味着记忆库里一定有答案。收益能被拆解，团队才更容易判断下一步应该优化哪里。〔5〕

如果要用技术语言解释“高端”，它应体现为多种能力的配合：任务理解决定什么时候投入算力，证据管理决定哪些信息必须保留，接口与执行策略让优化进入真实工作流。TierFlow 值得关注的，是把这些问题放进了同一个产品方向。公开资料尚不足以审计全部线上实现，但已经给出了清晰的研究线索和可验证的接入入口。

对于历史较长、工具反馈较多、步骤难度变化明显的 Agent，可以挑一组有代表性的任务，接入 TierFlow 跑一次对照；如果只想优化某个判断环节，就从 TierSense 对应接口开始。让真实工作流回答一个问题：同样的预算，能否稳定完成更多合格任务。

当 Agent 开始持续替人完成工作，效率就取决于每一步是否值得、每一段信息是否必要，以及每一次调用是否用对了能力。

TierFlow 试图把这些选择做进日常调用里。对开发者而言，这也是它最值得试验的地方：让 Agent 继续专注任务，让模型、上下文与预算之间的配合成为可以持续优化的系统能力。〔13〕

资料核对与截图截至 2026 年 10 月 1 日。本文为公开资料技术解读，未独立调用 TierSense 或 TierFlow API 复测。论文为研究预印本，研究系统结果不直接等同于商业服务表现。四张技术图的口径分别为文档机制整理、解释性示意、论文数据重绘与条件测算；三张产品截图均来自官网实际页面，TierSense 页面为预设演示。

参考资料

〔1〕TierSense 官方仓库

〔2〕官方 Agent 集成指南

〔3〕Score 使用指南

〔4〕Compress 使用指南

〔5〕Memory-Decide 使用指南

〔6〕StateComp：方法、实验设置与表 2

〔7〕Memory Control：表 1 与 PaMER

〔8〕Stable Geometry／GEM

〔9〕DRSR

〔10〕TierSense 官方产品页

〔11〕AI 科技评论相关报道，供背景阅读

〔12〕TypeSafe：Introducing System One Models & Jev

〔13〕TierFlow 官方产品页：调度原理与开发者接入