1. 为什么 agentic 场景的推理不能拿对话场景的思路来套先说一个我在项目里反复遇到的现象同一个 LLM同一套权重在聊天界面测得好好的一放进 agent 循环里就“变笨了”要么答非所问要么来回重复调用要么 token 消耗暴涨。很多人第一反应是“模型不行”或者“prompt 没写对”但论文提醒我们问题很可能出在inference 的策略strategy和任务结构不匹配。对话场景的推理本质上是“单轮-多轮”的输入输出映射模型吃进一段上下文吐出一段文本。但 agentic 任务里的推理是嵌套在“感知-决策-行动-观察”循环里的模型每次生成的结果都会被解析成结构化 action再触发工具调用工具结果又作为新的输入回合回来。这个结构差异直接带来了三组对话场景里几乎不存在的压力生成结果的“可控性”要求更高不能自由发挥必须输出合法、无歧义、符合工具 schema 的文本否则后续解析直接崩上下文是动态拼接的工具返回、错误信息、中间推理过程都会进上下文导致推理状态不断膨胀或者说“污染”推理延迟会被放大一次 agent 循环里可能要做多次 LLM 调用每次几百毫秒到几秒的延迟乘上循环步数用户体感就是灾难。论文提出 functional taxonomy 的第一步就是把 agentic inference 和这些普通生成任务区分开先定义清楚“这个任务在功能上要求什么”再去选 inference 配置。这也是我觉得全文最有价值的思维转换不要先问“我用什么模型”先问“我在让模型完成什么功能”。我自己把这个思路落地成一句话对话场景的 inference 是“尽力生成”agent 场景的 inference 是“受约束生成 状态管理”。你一旦带着这个视角去看很多配置选择temperature、max tokens、stop sequences、JSON mode、tool calling 格式就都能对号入座了。2. 论文核心拆解functional taxonomy 到底分了哪些类论文的 taxonomy 不是一个树状列表那么简单它更像一个多维度刻画“agentic inference 任务”的坐标系。我按照自己的理解把它整理成四个核心维度这四个维度基本覆盖了你在真实项目里会遇到的绝大多数决策点。2.1 按任务功能分the task space第一个维度是任务功能task function论文把 agent 中 LLM 承担的功能拆成几种典型类型我结合自己的实践给它们起了更好记的名字功能类型我的理解典型场景规划Planning把高层目标拆成可执行步骤任务分解、路线规划推理Reasoning基于已有信息做逻辑推断代码调试、数学推导决策Decision-making从多个候选中选择下一步动作工具选择、分支判断记忆Memory总结、压缩、提取信息对话摘要、状态更新生成Generation产出面向用户的最终内容写报告、回答问题为什么这个分类重要因为不同功能对 inference 的“质量要求”是不一样的。规划任务需要模型能输出结构化的步骤推理任务需要模型能“想得久一点”更多 reasoning tokens决策任务需要模型能稳定输出格式化动作记忆任务则更看重压缩率和信息保真度。实操提醒我在做一个自动化测试 agent 时发现同一个模型做“规划”和“决策”时表现差异巨大。原因在于我一开始把所有任务都塞进同一个 prompt 模板用一个 temperature 配置。后来按论文思路把任务拆开让规划任务走较长的 CoT 路径允许更多推理 token决策任务走严格的 JSON mode 低 temperature效果立刻好了很多。这就是“任务功能 - inference 策略”映射的实际价值。2.2 按推理策略分the strategy space第二个维度是推理策略inference strategy它描述的是“这次推理采用什么样的生成路径”。论文其实鼓励我们把这个空间细看因为同一任务功能可以对应多种策略而不同策略的成本、质量、延迟差异巨大。我见过的常见策略包括Direct generation直接生成一次调用直接输出答案不做额外推理链。适合简单决策、格式化输出。Chain-of-thought思维链让模型先生成推理过程再给出结论。适合需要逻辑推断的任务但 token 成本高。ReAct / Tool loop工具交互循环推理和工具调用交替进行模型每步决定调用什么工具、观察什么结果。这是 agent 任务最典型的策略。Self-consistency自洽性采样多次采样取多数答案。适合需要高可靠性的任务但成本倍数增长。Reflection反思模型先生成方案再让自己或另一个模型评估与修正。适合复杂任务但延迟高。核心观点论文和我的体会一致策略选择本质是在质量、延迟、成本三者之间做权衡而 taxonomy 的意义是让这个权衡变得可见、可比较。我在实际项目里经常把“策略”当成一个可替换的模块而不是“模型能力的一部分”这样每次实验都能精确控制变量。2.3 按交互结构分the interaction space第三个维度我称为“交互结构”interaction structure它描述的是 LLM 输出与外部环境工具、代码执行器、知识库之间的交互方式。论文里其实强调了不同结构对推理的约束差异我在实践中体会到这个维度最容易被人忽略。几种典型的交互结构单次生成single-turn模型只看一次输入一次输出例如把自然语言转成 SQL。多轮生成multi-turn模型和用户或环境多次交换消息但工具返回不改变模型内部推理状态。例如多轮对话。工具调用tool use模型输出结构化工具调用参数外部系统执行后把结果注入下一轮。例如搜索、计算器、API 调用。动态代码执行code execution模型生成代码解释器执行执行结果含报错回传给模型。例如 Code Interpreter 类应用。关键点交互结构决定了“我们不能只优化单次生成的准确率还要考虑整条执行链的鲁棒性”。我踩过的坑是模型单次 tool call 准确率有 90%看起来不错但 agent 一个任务要调用 5 次工具链式的整体成功率就掉到 59%问题就出在中间任何一次失败都会累积。2.4 按约束条件分the constraint space最后一个维度是约束条件也就是这次推理要满足的“硬性要求”。论文里虽然没有用一个单独章节来标榜它但通篇都在强调 context window、token budget、schema 约束、安全性等因素对推理策略选择的影响。我整理的常见约束Context window 限制一次性装不下所有历史记录时怎么截断或压缩。Token budget 限制单次调用的最大输出长度、总预算。Schema 约束输出必须是合法 JSON、必须符合函数签名。时延约束latency SLA必须在多少毫秒内返回结果。局部性约束是否需要本地推理、离线可用、隐私保护。实操意义这些约束不是“理想配置”而是决定你选不选某个策略的硬门槛。例如自洽性采样策略需要 5 次模型调用如果单次延迟 2 秒总延迟就 10 秒这在大多数交互式 agent 场景不可接受。论文的 taxonomy 帮我把这类取舍提前到设计阶段而不是上线前才发现。3. 把 taxonomy 落到真实项目我自己的一套思考模板理论讲完必须有能用的东西。我在读完论文后结合自己的 agent 项目整理了一套“面对任意 agentic LLM 任务时的分类与决策模板”这里直接分享出来。3.1 第一步给任务做“功能定位”打开一个 agent 项目时我第一件事不是选模型而是拿下面几个问题做筛选这个 agent 的每个 LLM 调用点属于哪类功能规划 / 推理 / 决策 / 记忆 / 生成每个调用点的输出要被谁消费人看、还是被代码解析每个调用点的输入上下文来源是什么历史对话、工具返回、静态知识这一个步骤看似简单但它直接决定了后面所有 inference 配置。比如“给用户生成摘要”和“从工具返回中提取结构化事实”虽然都用 LLM但前者要 temperature 高一点、输出可以自然语言后者要 temperature 低、必须走 JSON mode。功能定位错了后面全错。3.2 第二步评估交互结构画出数据流我在白板上画过太多 agent 架构图了现在固定用两类符号LLM 节点和工具/环境节点箭头表示数据流向和回合数。对每个 LLM 节点问三个问题它会被调用多少次单次还是循环它的输出直接进入什么工具执行器另一个 LLM 的上下文最终用户它的上下文里有哪些可变部分工具结果、错误信息、中间推理链这类“数据流画图”的价值是让你看到inference 的失败会以什么方式传播。我在做客服 agent 时就靠这张图发现一个“信息提取”节点的 JSON schema 偶尔输出非法格式导致后面“意图分类”节点拿到残缺上下文最后用户收到完全离谱的答复。没有数据流图这种跨环节的 bug 极难定位。3.3 第三步选定策略、约束与评测指标在功能与结构明确后才进入配置选择。我常用一张决策表来收敛“可能方案”问题需要考虑的内容这个任务能接受多长延迟决定能否用多轮采样、反思、长 CoT输出被代码解析吗决定是否强制 JSON mode / tool calling 格式失败容忍度多高决定是否加验证、重试、自洽性采样token 成本是否有预算决定上下文压缩策略与输出长度上限是否涉及多步工具调用决定是否做错误注入测试和链路回退拿这张表做完一轮之后“用哪个模型、什么样的推理配置”往往就不再依赖直觉了而是变成一道有约束最优化题。我在多个项目里验证过光是这一步就能砍掉不少“试来试去”的瞎调试时间。3.4 第四步做“功能级”评测而不是“模型级”评测这个可能是全文我最希望大家带走的一点评测 agent 里的 LLM绝对不能用单纯的“单轮回答准确率”。论文的 taxonomy 暗示了更细的评测维度我自己整理的输出质量评估维度包括单次生成正确性某次工具调用的参数是否合法、是否正确。链路完成率给定一个 goalagent 能否在 K 步内完成而不是中途放弃。回退鲁棒性工具失败后agent 是否知道换一种方式而不是重复同样的错误。上下文管理质量长任务中agent 是否能保持关键信息不丢、不混淆。资源效率完成相同目标消耗多少 token、多少次调用、多少秒。我把这套维度写成了小评测脚本跑在测试 agent 的回归集上。一开始也是懵的后来发现不同维度会暴露完全不同的 bug 类别链路完成率低往往是“策略”问题单次生成正确率低往往是“格式/提示”问题资源效率差往往是“上下文管理”问题。4. 基于 taxonomy 的实操几个可以直接抄的配置经验光有思维框架还不够我把论文思路映射到具体配置写几个我测试下来稳定有效的“经验配方”。注意这些都是“起点值”具体任务要微调。4.1 “规划子 agent”怎么配功能把用户目标拆成步骤。交互结构单轮生成偶尔两轮。输出结构化步骤列表。我推荐的配置方向使用 CoT 前缀但限定输出格式比如“请先分析然后以 JSON 数组输出步骤”temperature 设在 0.3~0.5保留一点多样性但又不会太发散max tokens 要足够覆盖“分析 结构化步骤”尽量给充足避免截断结果加一层 schema 校验非法格式自动重试一次。踩坑记录我之前把 temperature 设成 0.7结果模型在“步骤”里出现了“如果可能的话”“大概”这类模糊表达下游解析器直接放弃。后来降到 0.3 并强制 JSON schema几乎没再出过这类问题。4.2 “决策/工具选择”怎么配功能从候选工具列表里选一个并给出参数。交互结构单次生成输出是函数调用。输出结构化 action。我的配置经验temperature 尽量低0.0~0.2因为选择工具这种任务不需要创造力使用原生 tool calling 或结构化输出不要用自然语言描述动作stop sequences 和输出长度要配合函数调用格式下输出长度通常不会太长但解析失败时要有重试机制如果工具很多超过 20 个建议做工具列表裁剪而不是把全部工具描述塞给模型。踩坑记录工具一多模型开始“幻觉工具”生成一个完全不存在的工具名。后来我把“可用工具列表 严格限定只能选列表内工具”直接写进 system prompt并在验证阶段做集合检查幻觉才被压下去。4.3 “记忆压缩”怎么配功能把长上下文压缩成更短的状态。交互结构单轮。输出自然语言/结构化摘要。我的配置经验temperature 可稍高0.5因为摘要需要保留语义但允许表述变化关键是给出“压缩要求”要保留哪些字段、丢掉哪些字段、长度上限多少大上下文先做切块摘要再做二次合并避免一次性压缩导致信息丢失每次压缩后建议做一轮 QA 校验问几个关键信息验证摘要是否保留。踩坑记录早期我直接让模型把 2 万 token 历史压成 500 token结果用户姓名、订单号这些关键实体丢失。后来改成 “先切片摘要 - 再合并 - 校验关键实体” 三步走信息保真率高了很多。4.4 “反思/自修正”怎么配功能对已有输出做质量检查与修正。交互结构多轮需要额外生成。输出修正后的结果。我的建议反思步用低 temperature0.2避免“过度修正”把检查标准写清楚比如“输出是否包含完整工具调用参数是否有空字段是否符合用户约束”限制最多反思一轮防止 agent 陷入“无限自省”配合外部校验器比如 JSON validator、单元测试比“让模型自主判断好坏”更可靠。踩坑记录我见过一个 agent 生成代码然后反思步骤说“代码没问题”但实际语法都错了。从那以后我坚持在反思环节引入代码执行器和测试用例让外部工具当裁判模型只负责生成候选。5. 常见问题排查与避坑实录下面这些问题是真项目里高频出现的我把排查思路和临时止血方案一并写出来当成速查表用。5.1 Agent 一直重复调用同一个工具现象模型反复调用同一个工具参数几乎一样像是“卡住了”。排查路径工具返回的内容是不是太复杂模型没抓到关键变化上下文里是否有上次调用的完整记录导致模型觉得“还没完成”Stop condition 有没有设定最大循环步数没有的话agent 会一直跑。止血方案设置 max iterations比如 5 步每次工具返回后强制注入“当前状态摘要”而不是塞全部原始返回。5.2 输出偶尔不合法JSON 解析失败现象明明开了 JSON mode偶尔还是出现非法 JSON 或多余前缀。排查路径确认是否用的是原生 tool calling / structured output而不是“靠 prompt 让模型输出 JSON”看是不是输出被截断了max tokens 不够截断的 JSON 必然非法若上下文里有少数非 JSON 示例模型可能被带偏。止血方案在应用层加“解析失败自动重试”最多 2 次如果重试还失败降级为单次自然语言回答并提示用户稍后重试。5.3 Agent 在长任务中“忘记”早期关键信息现象任务执行到后半段agent 开始忽略早期用户指令或重复已经完成的步骤。排查路径上下文是否过长触发了截断策略把早期关键指令截掉了是否有专门的“全局状态”节点持续跟踪目标而不是只靠上下文窗口总结/压缩环节是否把关键字段丢了止血方案把用户目标单独放在一个“锁定区块”每次循环都重复注入关键实体同步到一个外部状态存储如数据库避免只依赖上下文。5.4 延迟太高用户等不起现象一次 agent 任务要 10 多秒甚至 30 秒才能返回。排查路径统计一次任务平均调用了几次 LLM找出“调用放大”的环节是否可以使用更小的模型/蒸馏模型处理“记忆压缩”这类轻量任务是否可以用流式输出让用户先看到中间过程止血方案把最耗时的节点换成更快的模型或更短的 CoT引入并行工具调用多个无依赖工具同时执行而不是串行。5.5 模型“幻觉工具”或输出列表外的动作现象模型生成了根本不存在或未授权的工具名导致执行器拒绝、agent 崩溃。排查路径可用工具列表是否在 prompt 里明确且唯一工具描述是否过于模糊让模型以为“可以发明新工具”是否用了旧版 function calling 格式和当前 API 不完全兼容止血方案应用层做工具名白名单校验遇到白名单外动作直接报错并把报错作为观察结果回传给模型模型通常能自我纠正。6. 我对 taxonomy 的一些延伸思考论文的价值不只在于分类本身更在于它给了我们一套“对话语言”。我在团队内部现在提“这个节点是 decision 类做 tool-calling 策略”这样的说法大家立刻知道要关注什么比之前“这里用 LLM 处理一下”清晰太多了。我认为 taxonomy 未来很有希望往这几个方向延伸评测标准统一如果大家都用同一套功能分类agent 的 benchmark 就会有可比的维度不会出现“我们的 agent 准确率 95%”但其实测的是单轮问答这种错位。推理引擎感知的调度器未来推理框架可以接收“任务分类元数据”自动选择策略、模型甚至压缩方案。我在想象的形态是agent 框架向推理引擎传递“这是一个 decision 任务 低延迟追求 输出必须是 JSON”推理引擎据此自动配置 temperature、采样方式、缓存策略。成本-质量-延迟的可视化分析把每个 LLM 节点标上分类标签后很容易在 dashboard 上看出来哪类任务最烧钱、哪类最慢、哪类失败率最高。这在优化时就是一张活地图。坦白说当前多数 agent 框架和推理 API 还没有把 taxonomy 作为一等公民来描述任务类型大部分时候我们要自己把分类映射到具体参数。但这种“自己接口化”的功夫恰恰是让 agent 项目从“能跑”走到“可控、可优化”的关键一步。7. 最后的实操小结这篇论文我读了两遍第一遍觉得“就是分类整理”第二遍发现它其实在教你怎么用分类思维去配置和诊断 agent。我提炼出三个最想让你记住的点先功能定位再谈模型和参数。不要一上来就纠结用 GPT 还是开源模型先问“这个调用点在 agent 里承担什么功能、输出给谁消费、上下文会怎么变”。把 inference 策略当成可替换组件。同一个模型可以配 direct generation、CoT、tool loop、reflection 等不同策略你的目标是如何在质量、延迟、成本三个约束下选出组合。评测一定分功能、分链路来做。单轮正确率只是基础要加上链路完成率、回退鲁棒性、上下文管理质量、资源效率这些维度才能真实反映 agent 在生产环境的表现。我在实际项目里验证下来这套思路不能说让我“不再遇到问题”但确实让问题的定位从“玄学”变成了“分类学”。一次 agent 表现异常我现在会先问是任务功能定位错了还是策略选得和约束不匹配还是交互结构的失败传播没处理好问完这三句大多数问题基本都有方向了。最后再分享一个我这段时间养成的习惯每次新开一个 agent 项目先花 30 分钟把“每个 LLM 节点的功能分类、交互结构、约束、策略、评测维度”写成一页 Markdown 文档贴在项目 README 里。这页文档在后面的调试、评审、交接里帮了我大忙强烈建议你也试试。