多Agent平台工程：自适应推理深度节省thinking token

没人谈论的问题

在生产级 AI 系统中，有一个反复出现的问题：你的模型应该在回答之前先思考吗？

不是哲学意义上的，而是机制层面的。当用户问"我的账户余额是多少？"时，启用一个带有 16000 个思考 token 的链式思维推理引擎，就像雇一位 PhD 数学家来数零钱。你在燃烧算力，你在增加延迟，而答案并不会因此变得更好。但当有人问"比较三种部署架构在峰值负载下的 ROI，要考虑到故障模式和各区域延迟差异"时，零推理的直接调用会产生垃圾。

大多数平台选择一种方法并处处应用。贵的那些在简单查询上过度推理，在毫无用处的思考 token 上烧钱。便宜的那些在困难问题上推理不足，产生听起来自信但完全没切中要害的回答。

试想一个平台，其中数十个自主 Agent 为跨不同行业的数千个租户服务。调度 Agent 处理"把我的下午 3 点改到周四"，而分析 Agent 却在苦战"为什么 Q3 企业客户的流失率飙升"。这些请求打到同一个基础设施，但它们需要截然不同的认知投入。

我们正在构建的系统不选择单一深度。它对每个请求打分，并将其路由到相应的推理层。然后，正如我们将在第 2 和第 3 部分看到的，它从结果和人类反馈中学习，随着时间推移优化这个评分。

三个思维层级

把推理深度想象成一个有三个实用区间的光谱。

Tier 1: 无中间推理（NONE）

模型接收提示并直接生成响应。没有思考 token，没有结构化的中间步骤。输入进去，输出出来。这是你处理事实查询、简单状态检查、问候语和 FAQ 类问题的主力。延迟大约 200ms，成本极低。

这种情况什么时候会失败？当问题要求模型同时在工作记忆中保持多个约束条件时，或者当答案取决于将几个选项相互比较时。模型会产生听起来合理的内容，但实际上它并没有真正通过权衡来推理。

Tier 2: 轻量级结构化推理（DRAFT）

在这里，系统向提示中注入一条结构化指令："在回答之前，将你的推理写在 <draft> 标签内，限制在 512 个 token 以内。然后将你的最终答案写在 <answer> 标签内。"

模型获得了一个小型草稿本。它可以组织思路、检查一些约束条件、可能梳理出一个比较框架。但预算很紧张。512 个 token 的推理空间足够将一个中等复杂的问题分解为子部分并逐一处理，但不足以探索兔子洞或考虑五种替代框架。

系统解析响应，提取 <answer> 标签之间的内容，丢弃草稿。用户永远不会看到中间推理，除非运营商想用它来调试。

Tier 3: 完整链式思维（FULL_COT）

这一层将问题交给具有原生思考 token 支持的模型。像 o3 或 DeepSeek-R1 这样的模型有一个单独的"思考"通道，它们可以在产生可见响应之前长时间推理。系统设置一个 reasoning_effort 参数并分配一个思考预算（预算相关的内容稍后详述）。

模型现在可以花费数千个 token 来处理一个问题。它可以考虑替代方案、在走进死胡同时回溯、验证自己的逻辑。对于真正困难的分析问题，这能产生与其他两层质量上不同的答案。

权衡是显而易见的：延迟攀升到 2-5 秒，token 成本翻倍。你不会想让这东西跑在"你们几点关门？"上。

系统如何决定使用哪一层？

它将传入的请求通过一个多信号分类器运行，产生一个 0 到 1 之间的单一分数。

五个信号输入这个分数：

任务类型（权重：0.30）。这是事实查询？比较？分析？调试请求？创造性任务？分类器维护一个任务类型分类法及其相关难度先验。状态检查得分低。多标准比较得分高。

歧义性（权重：0.20）。这个请求可以被解释为多少种方式？"告诉我性能表现"是歧义的（什么性能？系统？团队？某个特定指标？）"上周二 /checkout 端点的 p95 延迟是多少"则没有歧义。歧义标记包括模糊的代词、缺失的上下文和未指定的作用域。

领域词汇密度（权重：0.20）。充满专业术语的请求表明答案需要领域专业知识和仔细推理。一条充满金融建模术语或医学术语的消息可能比随意问候需要更深入的思考。

词汇复杂度（权重：0.15）。句子长度、从句深度、词汇 sophistication。这是请求本身承载的认知负荷的代理指标。不是一个完美的信号（一个简短的请求可能需要复杂的推理），但与其他信号结合使用时很有用。

上下文依赖性（权重：0.15）。正确答案在多大程度上依赖于先前的对话历史、租户特定数据或交叉引用多个信息源？独立问题得分较低，而需要综合三条先前消息和两份文档的问题得分较高。

C(x) = 0.30 · S_task(x) + 0.20 · S_amb(x) + 0.20 · S_dom(x) + 0.15 · S_lex(x) + 0.15 · S_ctx(x)

每个信号函数 S(x) 输出 [0, 1] 范围内的值。加权和产生最终复杂度分数 C(x)，也在 [0, 1] 范围内。

路由阈值：

• C(x) < 0.30 → NONE（直接调用，无推理）
• 0.30 ≤ C(x) < 0.65 → DRAFT（轻量级草稿，512-token 上限）
• C(x) ≥ 0.65 → FULL_COT（原生思考 token，含预算）

一个具体例子让这变得具体。"我的账户余额是多少？"得分大约是：task_type = 0.1（事实查询），ambiguity = 0.1（意图清晰），domain = 0.05（无专业词汇），lexical = 0.1（简短、简单），context = 0.2（需要账户数据但很简单）。综合：0.30(0.1) + 0.20(0.1) + 0.20(0.05) + 0.15(0.1) + 0.15(0.2) = 0.03 + 0.02 + 0.01 + 0.015 + 0.03 = 0.105。NONE 层。直接回答。

现在试试"比较三种部署架构在峰值负载下考虑延迟、成本和故障模式的 ROI。"task_type = 0.9（多标准分析），ambiguity = 0.4（什么算作"ROI"需要解释），domain = 0.8（基础设施术语），lexical = 0.7（复杂句子，多个约束），context = 0.6（需要先前上下文中的架构细节）。综合：0.30(0.9) + 0.20(0.4) + 0.20(0.8) + 0.15(0.7) + 0.15(0.6) = 0.27 + 0.08 + 0.16 + 0.105 + 0.09 = 0.705。FULL_COT。这个需要思考。

为什么这在多 Agent 系统中很重要

单一 Agent 聊天机器人可以用固定推理深度凑合。但多 Agent 平台有一种拓扑结构，使静态方法失效。

想象一个接收每条入站消息的 supervisor Agent。它对意图进行分类并路由到专业 Agent：调度 Agent、账单 Agent、技术支持 Agent、分析 Agent。每个专业 Agent 处理问题空间的不同切片。

有趣的是：同一个专业 Agent 可能根据具体请求需要不同的推理深度。账单 Agent 处理"我的下次付款日是什么时候？"（NONE）的同时，也处理"解释为什么我这个月的发票增加了 40%，考虑到三个定价层级、周期中计划变更和按比例调整"（FULL_COT）。

推理策略是按请求选择的，不是按 Agent 固定的。账单 Agent 没有固定的推理深度。它在每次交互中根据用户实际询问的内容重新进行分类。

当你有 Agent 团队时，事情会变得更加分层。一个 lead Agent 可能会将一个复杂请求分解为子任务，将每个子任务委托给不同的专业 Agent。一个子任务可能是简单的数据检索（NONE），另一个可能需要交叉引用多个来源（DRAFT），第三个可能涉及真正的分析推理（FULL_COT）。系统对每个子任务独立评分。

这种按请求粒度是使整个系统在经济上可控的关键。如果你因为部分任务困难就把每个 Agent 设置为 FULL_COT，你为简单任务付出的代价是十倍。如果你因为大多数任务简单就把它们都设置为 NONE，困难的任务会产生糟糕的答案，你会失去用户信任。在请求层面评分意味着你只在推理创造价值的地方付推理的钱。

即使在 FULL_COT 内部，也不是每个困难问题都值得最大思考配额。一个中等复杂的问题可能需要 4096 个思考 token 来处理。一个真正困难的分析任务可能需要 16384 个。为一个只需要 4000 个 token 的问题分配 32000 个思考 token 就是浪费算力，有时还会降低质量（模型可能过度思考，在正确的中间步骤上兜圈子或自我怀疑）。

系统将复杂度子范围映射到预算层级：

• 简单（低于阈值）：0 token（NONE/DRAFT 处理）
• 中等（0.65-0.80）：4096 token
• 复杂（0.80-1.0）：16384 token

预算 enforcement 作为一个状态机工作。当模型开始思考时，状态是 ACTIVE。如果模型达到预算限制，状态转换到 EXHAUSTED，系统向模型发出信号以结束其推理。一个 512 token 的宽限窗口允许模型到达一个自然的停止点，而不是在思考中途被切断。宽限窗口之后，状态转换到 TERMINATED，模型必须从其完成的任何推理中产生最终答案。

这防止了推理失控。如果没有预算 enforcement，一个被给予原生思考 token 的模型有时会在一个并不受益于它的问题上花费 20000+ 个 token 进行绕圈子的推理。预算创建了一个上限，同时不妨碍在真正需要时进行深度推理。

策略选择的完整请求生命周期

请求进入复杂度分类器，分类器评估五个信号维度并产生一个加权分数。分数穿过两个阈值之一（0.30 和 0.65），将请求路由到三个策略通道之一。每个通道使用不同的机械方法来产生最终响应：简单的直传调用、带标签解析的结构化草稿信封、或带有预算 enforcement 的完整思考 token API。三者都收敛于交付给用户的响应。

分类器是有效的。它将大多数请求路由到合理的层。但它是一个启发式方法，而启发式方法不会学习。

如果系统在一个特定 Agent 的特定类型请求上持续推理不足，分类器会不断犯同样的错误。如果租户模式发生变化（可能一家企业改变了行业，其支持查询变得更加技术化），静态权重不会适应。

我们真正想要的是一个观察结果的系统。DRAFT 策略在这个上下文下产生了好的结果，还是力不从心？FULL_COT 响应值得额外的延迟和成本吗，或者 DRAFT 同样就好了？

这就是强化学习路由器，也就是第 2 部分的主题。核心思想：维护一个关于每个（模型，策略）组合在每个上下文中的表现好坏的概率信念，从该信念中抽样选择行动，观察结果，更新信念。一个学习地形上下文的上下文赌博机。

分类器给我们一个合理的起点。赌博机学会做得更好。

本系列下一期：第 2 部分探讨 Thompson Sampling 如何从生产结果中学习最优模型+策略路由。

你可以在 LinkedIn 和 Twitter 上关注我以获取更多更新。