企业官网建设流程全解析

1. 先看懂这件事：为什么"生成"拖慢了 Small Agent

1.1 Agent 的真实瓶颈：每一步推理都在烧 token

先说一个很多人容易忽略的事实：一个几 B 参数的小型 Agent，真正拖慢它的往往不是模型推理速度本身，而是它在一次任务里到底"说了多少话"。

我最早做 Agent 优化时碰到过一个典型场景：用户问一句"帮我查一下最近三天服务器的错误日志"，Agent 要先在内部生成一段思考过程，接着判断该调用哪个工具，然后生成参数，最后还得生成一段总结。这一步下来，输入输出加起来常常要消耗几千个 token。小模型生成速度本来就只有大模型的几分之一，token 一多，整个请求的端到端延迟就完全失控了。更麻烦的是，这种延迟不是单次请求的问题，当你有几十路并发请求打过来时，小模型被长文本生成占满了算力，吞吐量也跟着崩。

我当时的优化思路和大多数人一样：换更大的模型、上量化、做 KV Cache 优化。但折腾一圈后发现，效果有限。真正让我打开局面的，是一个看起来"反直觉"的改动——把 Agent 的推理方式从"自由生成"改成"限定选择"。就用这个思路，我把一个 7B 规模 Agent 的单次任务延迟从平均 3.8 秒压到了 350 毫秒左右，关键是首 token 延迟下降了不止一个量级。

这篇内容我就把整个改造过程拆开来讲，适合正在做小型 Agent 落地、被延迟和成本卡住的朋友参考。先给结论：Agent 里大部分"思考"根本不需要生成，它们本质上是分类问题，用选择题的方式回答，又快又稳。

1.2 "做选择题"的本质：把开放式生成压缩成判别式决策

要理解这个提速思路，先要区分两种完全不同的推理方式。

常规的 Agent 推理就是让 LLM 自己组织语言，从"我看到了什么问题"推导到"我应该怎么做"。这个过程是自回归生成：模型每生成一个 token，就要把前面所有 token 再重新"过一遍脑子"（实际上是在已有的 KV Cache 上继续计算）。你让它写 200 个 token 的思考链，它就得做 200 次解码。就算模型一次前向只要几十毫秒，乘上 200 次也是好几秒。

而"做选择题"是判别式决策：你把所有可能的结果枚举出来，让模型在候选集里选一个。它不需要"构思"完整的回答，只需要计算每个选项的得分或者直接输出一个选项标记。这个解码过程往往只需要生成一个 token、做一次或两次前向，时间开销从"几秒"降到"几十毫秒"。

你可以这么理解：生成模式是让一个人现场写一篇小作文来回答你"你中午想吃什么"，而选择题模式是递给他一张菜单让他直接勾。后者当然快得多。但对小型 Agent 来说，最大的收益不是快，而是稳定——生成式推理可能跑偏，选择题只要候选集设计得好，基本不会跑出边界。

这里的关键问题是：Agent 的哪些环节可以设计成选择题？哪些必须保留生成？下面直接讲我改造时的分类方法。

2. 哪些推理环节可以被"选择题化"：改造前先分清四类决策

2.1 意图识别：最适合选择题化的第一站

几乎所有 Agent 的第一步都是理解用户意图，然后路由到对应流程。传统做法是让 LLM 输出一句意图描述，比如："用户想查询订单状态"。这句话其实完全没有必要"生成"出来——你根本不需要它组织的语言，你只需要它从你预设的意图列表里选中"查询订单状态"这一项。

我在改造中做的第一件事，就是把 Agent 的意图识别层从"开放生成"替换成"封闭分类"。做法是维护一张意图清单，比如常见的二十几个意图：查余额、查订单、申请退款、改地址、投诉、转人工、闲聊……然后让模型直接输出意图 ID 而不是意图描述文本。

这一步改造收益最大，因为 Agent 每次任务都会走到这一步，且确定性的解析过程后续所有分支都依赖它。用选择题方式做意图识别后，这一步的耗时稳定在几十毫秒以内，基本相当于一次快速前向。

提示：意图清单要设定"兜底"选项，比如"unknown"或者"需要澄清"，否则模型遇到清单外的意图时会被迫硬选一个，导致后续流程错乱。

2.2 工具选择与路由：候选集天然存在

Agent 的第二个高频推理动作是从工具列表里选出要调用的工具。这个场景简直是"选择题"的标准考场——你的候选集就是工具清单，是枚举出来的、数量有限的。

我见过很多 Agent 在这个环节犯一个"低级错误"：让 LLM 用自然语言写出"应该调用 get_order_status 工具"。这句话里有大量冗余 token："应该调用"四个字、工具名本身、引号、回车等。这些 token 都是纯粹的开销。正确的做法是：

1. 把所有工具名列表拼进 prompt；
2. 让模型输出工具名对应的序号或者直接输出工具名（通过约束解码只允许输出候选集内的词）；
3. 解析这个"选择结果"后直接进入工具调用分支。

这里我用到一个很关键的技巧：尽量让模型输出工具 ID 而不是工具描述。有些 Agent 为了可读性会让模型输出工具名，比如"get_order_status"，但工具名可能很长；而输出"T002"这样的短 ID 只需要很少的 token，配合约束解码甚至只需要一个 token 就能完成。我在一个内部项目里实测过，工具选择环节的平均解码长度从 8-10 个 token 降到了 1 个 token。

2.3 中间判断与断言：把长思考压缩成判断题

很多 Agent 在处理复杂任务时，需要在中间环节做临时判断。比如：用户提供的信息是否足够执行任务？这一步的结果是否需要继续追问？当前数据是否异常？这些判断如果用"生成一段推理"来回答，代价极高，而且生成的内容里一半是无关紧要的过渡句。

改造方式是：把这些中间判断全部变成判断题或二分类/多分类问题。比如"用户信息是否完整"，候选答案是"完整 / 不完整 / 不确定"；"数据是否异常"，候选答案是"正常 / 异常 / 需人工复核"。模型只需要输出一个词。

有人会担心：这样会不会丢失推理能力？实际上不会。推理能力并没有消失，是转移到了选项设计和下游分支逻辑里。你让模型去"解释为什么数据异常"它未必解释得清楚，但你让它判断"数据是否异常"再配合规则引擎去定位具体问题，往往更可靠。这也是我对"Agent 需要大模型思考"这个观念的重塑：小模型不擅长长链条开放式推演，但非常擅长做判别和选择。

2.4 参数抽取与槽位填充：用结构化填空替代自由文本

最后一个高频环节是参数抽取。比如用户说"帮我查 2024 年 3 月的销售额"，Agent 需要抽出时间范围"2024-03"。传统做法是让模型生成一段 JSON，里面包含 start_date、end_date 等字段。模型要"凭空生成"整个 JSON 结构，很容易出现格式错误、字段名写错、多余引号等问题。

改造思路是：把参数抽取变成槽位填充。你预先定义好 JSON 结构，模型只需要在指定槽位里填入内容。这是"生成"和"选择"的混合体：JSON 结构和字段名是固定的（不生成），具体参数值在某些场景下需要生成（比如日期、金额），而参数值也可以变成选项（比如城市列表、状态列表、产品线列表）。

我在实际改造中发现一个规律：结构化输出+候选枚举越彻底，延迟越低、稳定性越高。另外建议使用带约束解码能力的推理框架，它能直接指定输出格式，比如"这里必须输出一个整数""这里必须从给定列表中选择"，这样模型即使在生成参数值时也不会跑偏。

2.5 小结：一张表看懂改造前后的决策方式对比

3. 实操实录：一个 Small Agent 的 10 倍提速改造

3.1 改造前的样子：延迟数据先量清楚

我把一个内部客服场景的小型 Agent 拿出来做实验。这个 Agent 基于一个 7B 开源模型，任务流程大概是：用户提问 -> 识别意图 -> 判断是否需要追问 -> 选择工具 -> 抽取参数 -> 调用工具 -> 生成回复。

改造前我先做了 200 次请求的压力测试，记录延迟分布：

看完数据就清楚问题出在哪了：单任务输出 860 个 token，其中真正有价值的核心决策信息可能只占 10%-20%，其他全是过渡语、思考链、重复描述。这些多余 token 就是浪费，既是延迟浪费，也是成本浪费。

3.2 第一轮改造：意图识别换成分类器（效果最猛）

第一轮我只改了意图识别模块。做法是抛弃"让模型生成意图描述"，改成预定义 25 个意图类别，每个类别配 3-5 个示例表达，拼成选项式 prompt。要求模型只输出意图 ID，比如"INTENT_ORDER_STATUS"。

这里我没有用传统分类器，而是继续用同一个 7B 模型，但改变了输出约束。核心改动是加了"输出格式约束"正则：解析模型输出时，如果输出内容不在候选意图 ID 列表内，就判定为无效并强制重试一次。单纯这样就把意图识别这步的 token 消耗从平均 60 个降到了 6 个左右。

第一次实测让我有点惊讶：仅仅改了这一步，整个 Agent 的平均端到端延迟从 3.8 秒降到了 2.4 秒。原因很直接，因为意图识别是流程第一步，它输出了 6 个 token 之后后面所有流程才能启动，首跳延迟大幅缩短。

注意：改成选择题模式后，模型偶尔会输出"选项文本"之外的内容，比如重复问题、解释等。必须做好输出解析的容错，而不是假设模型永远听话。

3.3 第二轮改造：工具选择用约束解码

第二轮改造的是工具选择模块。我把 16 个工具名称固化成一个候选清单，每个工具配简短功能描述，让模型输出工具 ID（TOOL_01 这种格式）。

这一步我试过两种路径：

1. 纯 prompt 约束：在 prompt 里写明"只允许输出以下工具 ID 之一"，用正则兜底校验；
2. 约束解码：使用支持受限输出的推理框架，直接在解码阶段限制只能从候选词表里采样。

实测下来第二种的效果好得多。纯 prompt 约束偶尔还是会"越界"，而约束解码直接物理上禁止了非法输出。延迟差异也明显：普通生成工具名可能要 5-10 个 token，约束解码平均 1-2 个 token 就出结果，而且格式错误率基本为零。

这一轮改造后，单任务平均输出 token 从 860 降到了 520 左右，端到端延迟降到了 1.6 秒。

3.4 第三轮改造：推理断言改成判断题

第三轮是把 Agent 里的多个条件判断节点全部改成"判断题"。原本流程里有这么一段：

"用户是否提供了订单号？如果有则继续查询，如果没有则询问用户。"

这段逻辑原先是让模型"自由发挥"，输出一段包含判断结论的文本。我改成让模型直接输出一个词：HAS_ORDER_ID或NO_ORDER_ID。类似的判断还有：参数是否完整（COMPLETE/INCOMPLETE）、是否需要人工介入（HANDOVER/AUTO）。

这个改造的风险在于：选项之间的边界如果定义不清晰，模型就容易"乱选"。我的解决方法是每个判断都加一个"不确定"选项，并设定触发"不确定"时走澄清流程，而不是强行猜测。这一步改造后，输出 token 进一步降到了 380 个左右，端到端延迟降到了 0.9 秒。

3.5 最终效果：端到端延迟与成本变化

三轮改造做完整，我又做了一次同样的 200 次请求压力测试：

最终端到端延迟 350 毫秒，和最初 3.8 秒相比确实是 10 倍以上提升。这个幅度并不夸张，因为在生成长文本上压缩了 89% 的输出 token，时间自然就缩短了。而且并发场景下的收益比单请求更大，因为短输出释放了算力，同一个小模型部署实例能扛的并发数显著增加了。

4. 为什么能快 10 倍：从解码方式看本质收益

4.1 生成是"一步步写字"，选择是"按一下按钮"

从计算层面解释一下收益来源。LLM 的解码过程是这样的：

• 每生成一个 token，模型就要读取已经生成的全部上下文参与计算；
• 生成 100 个 token，本质上就是 100 串行前向计算；
• KV Cache 虽然能复用中间结果，但每步的注意力计算成本还是在线性增长。

做选择题时，模型输出的是一个选项或者选项 ID。这个 ID 在词表里是一个 token，甚至某些情况下可以是多个 token，但通常都被约束解码压到 1-3 个。这是一个从"输出 N 个 token"到"输出 1 个 token"的变化。我把这个变化叫"决策长度压缩"。

如果你熟悉 LLM 推理性能测试，会知道决定延迟的两个关键指标：首 token 延迟和生成吞吐。首 token 延迟由 prompt 长度和模型前向速度决定，生成吞吐决定了后续每个 token 要多久。选择题模式让生成吞吐的负担几乎消失，延迟自然主要由首 token 延迟决定。而后者的优化手段很多，包括 prompt 精简、前缀缓存、量化推理等。

4.2 收益不只是延迟：吞吐、成本和并发

把推理改成选择题后，很多人只盯着延迟看，但实际上对生产环境影响更大的是另外三件事：

第一，吞吐量上升。原来一个 agent 实例每秒只能处理 2 个并发请求，改造后同样显存下每秒能处理 20-30 个请求。这意味着可以大幅缩减部署实例数，节省显存和机器成本。

第二，输出成本下降。推理成本大致和生成 token 数成正比。输出 token 减少 89%，单位请求的推理成本就是原来的 10% 左右。如果业务量大，这个数字意味着月度成本从几万元降到几千元。

第三，可观测性变好。生成式 Agent 的输出是一大段自然语言，你很难追踪"它为什么选了这个工具"。选择题模式的输出是结构化 ID，配合日志可以做精细的路由分析，出问题时定位到具体决策节点，排障效率高得多。

4.3 为什么小模型收益尤其明显，大模型反而收益有限

这个优化思路对小模型和大模型都有效，但收益程度差别很大。我观察到的规律是：模型越小，收益越明显。

原因并不复杂。大模型单 token 生成速度可能很快（比如几 B 模型最慢，70B 模型如果没有加速则也慢，但部署门槛差异很大），且大模型在长文本推理上"思考质量"更高，压缩决策长度时可能损失理解能力。而小模型本身上下文建模能力和长文本生成能力就相对弱，你让它生成 500 个 token 的思考链，它中途可能就逻辑漂移了。改成选择题后，它只需要做判别，能力短板被绕开了，稳定性反而提升。

另外小模型的概率分布相对"置信度不够高"，生成长文本时累积误差很明显。但做选择题时，候选集内部分类通常比自由文本生成更符合小模型的能力分布。这也是为什么"Small Agent"在这个思路下尤其受益的根本原因。

5. 改造过程中的坑与排查技巧

5.1 候选选项覆盖不全导致"硬选"崩溃

选择题模式最大的坑就是候选集覆盖不全。我第一次做意图识别清单时，漏掉了一个低频意图："用户想投诉物流速度慢"。结果模型在处理这类请求时，只能在已有的意图里硬选一个，选了"查询物流"，后续流程就全错了。

排查方法：接入线上日志，定期统计模型选择结果的置信度分布，对低置信度样本做聚类分析。发现某个意图分类下频繁出现奇怪的输入，就要回到意图清单补充选项。在候选集设计上，宁多勿缺，并且始终保留兜底选项。没有兜底的选择题就是把模型逼进死胡同。

5.2 选项太多，选择准确率下降

候选选项并非越多越好。我做过一个实验：工具数量从 12 个增加到 30 个再增加到 50 个，模型的选择准确率随之下降。尤其当多个工具名相似时，比如"get_order"和"query_order"，模型容易混淆。

应对策略是分组分层的选择结构：第一层先选类别（订单类、商品类、支付类），第二层再选具体工具。把一次 50 选 1 拆成两次 5 选 1，准确率明显回升，延迟也没有增加多少。选项之间尽量使用语义差异明显的命名，避免 A/B 测试式模糊描述。

5.3 什么时候必须保留生成式推理

我也要泼一盆冷水：不是所有环节都适合改成选择题。

遇到这几类情况，保留生成式反而更合理：

• 开放域回答：用户问"这个产品的口碑怎么样"，你无法枚举所有可能的回答，只能生成；
• 复杂多跳推理：需要从多个信息源综合得出结论，选择题难以覆盖所有可能性；
• 创造性内容：生成总结、生成话术、润色文案，这种天生就是生成任务。

我最终落地的方案是混合式决策架构：流程类的判断全部选择题化，内容类输出保留生成式。每次任务大约 90% 的决策节点是选择题，剩下 10%（比如最终回复用户的文案）保留生成。这套方案既保证了速度，也没有牺牲用户的对话体验。

5.4 评测指标要跟着调整

改造完成后，评测方式也要变。传统的 Agent 评测喜欢看"回答质量分"，但选择题化的 Agent 你更需要关注：

• 意图识别准确率：选择的意图类别是否真的准确；
• 路由正确率：选中的工具是否是可执行且正确的；
• 兜底触发率：不应该触发兜底的样本里有多少误触发了；
• 无效输出率：模型输出不在候选集内的占比（约束解码后应该趋近于零）。

我建议在改造前后分别跑同一批回归测试集，用这些指标给效果做量化对比。我当时的经验是：改造后意图识别准确率基本持平或略升，路由正确率上升约 2-3 个百分点（因为格式错误少了），而兜底触发率需要控制好，过高说明候选集设计有问题。

5.5 别忘了 Prompt 里的"选择题题干"质量

最后一个很容易忽略的点：选择题选项是"静默知识"，但 prompt 里的选项描述同样会消耗 token。我一开始把每个工具的功能描述写得很详细，结果 prompt 越长，首 token 延迟越高。后来我把描述压缩成一句不超过 10 个词的功能说明，意图识别准确率没降，首 token 延迟反而改善了。

可以参考的优化思路是：高频选项给短描述，低频和易混淆选项给稍长描述，让模型的注意力集中在真正需要区分的信息上。另外，历史对话上下文如果很长，可以考虑裁剪掉与当前决策无关的轮次，因为选择题模式完全不需要依赖上下文重新推理。

我个人在实际操作中的体会是：做 Agent 优化不要去硬啃模型能力的天花板，而是要先"盘"一下整个决策流程里到底哪些环节真的需要生成。把能变成选择题的地方全部变成选择题，小型 Agent 的速度和稳定性提升是系统性的，不是某一个 trick 的功劳。如果你现在正被 Agent 延迟和成本问题困扰，建议先从意图识别这个环节下手试一次，大概率会有惊喜。这个方向后续还能扩展得更远，比如把整个决策链录成结构化日志做离线分析、针对高频错误分支做定制化的选项迭代，或者把选择题化后的决策数据收集起来做一个更小的专用分类模型，让 Agent 连大模型推理都不需要了。沿着这个思路走下去，小型 Agent 就真的可以变成又快又省的生产工具了。