这篇是对论文 Evoflux: Inference-Time Evolution of Executable Tool Workflows for Compact Agents 的学习笔记。
它讨论的问题很具体：当我们让一个小模型在真实工具环境里完成任务时，为什么它常常能“看起来会调用工具”，但真正跑起来却失败？
论文的答案不是“再把模型做大一点”，也不是“多喂一些 tool calling 数据”。Evoflux 的核心思路更像传统软件工程里的调试循环：
工具调用不是一段文本，而是一张需要被解析、校验、执行、修复的工作流图。
如果把这个判断抓住，整篇论文就很好理解了。
1. 先把问题说清楚：工具调用不是写 JSON
很多人第一次接触 tool calling，会把它理解成“模型输出一个函数名和参数”。这个理解在简单 demo 里成立：天气查询、计算器、数据库查一条记录，模型只要选对工具、填对参数就行。
但真实 Agent 任务复杂得多。尤其到了 MCP 这类开放工具生态里，模型面对的不是三个固定函数，而是不断变化的工具目录、schema、参数约束、返回值结构和跨工具依赖。
一个真实任务可能长这样：
先找到相关资源
再根据资源 ID 查询细节
再把结果转成另一个工具需要的参数
再执行动作
最后基于真实执行结果回答用户这已经不是单次函数调用，而是一个工作流。中间任何一步坏掉，最终答案都可能不可信。
论文把紧凑模型常见失败拆得很清楚：
- 工具名看似合理，但目录里根本不存在。
- JSON 结构像那么回事，但不符合真实 schema。
- 参数漏了必填字段，或者字段类型错了。
- 多步调用之间的依赖断了，后一步引用不到前一步结果。
- 工具确实执行了，但模型最后没有基于执行证据回答。
- 模型直接给出答案，看起来流畅，其实跳过了必要工具。
这些失败有一个共同点：它们不是靠“语言更顺”就能解决的。模型输出的文本可以很像正确答案，但执行系统会用更硬的方式检验它：能不能解析、能不能校验、能不能跑、跑完结果能不能支持最终回答。
这也是 Evoflux 最有价值的出发点。它没有把小模型工具使用当成“生成质量问题”，而是当成“可执行工作流修复问题”。
2. Evoflux 的一句话：推理时演化工作流
Evoflux 做的事可以概括成：
先让模型提出一个候选工具工作流
再把它编译成可执行图
然后用校验器、执行器、评分器找出问题
接着对工作流做结构化修改
重复这个过程，直到找到更可执行、更有证据的方案这里的关键词是 推理时。
普通微调是在训练阶段改变模型参数。Evoflux 不改变模型本身，而是在每次任务执行时，围绕模型给出的候选方案做搜索、变异、执行反馈和修复。它更像是在模型外面包了一层“工作流进化器”。
这和 ReAct 那种“边想边调工具”也不完全一样。ReAct 主要让模型按思考-行动-观察的文本轨迹推进；Evoflux 更强调候选工作流本身是有类型、有依赖、有校验规则的图。图能被编译，能被局部修改，也能被执行系统打分。
所以 Evoflux 的基本对象不是一句 prompt，不是一条 chain-of-thought，而是一个 workflow graph。
3. 工作流图里到底有什么
论文里的工作流图可以理解成几类信息的组合：
- 每个节点调用哪个工具。
- 每个工具的参数是什么。
- 节点之间有什么依赖关系。
- 哪些输出会被后续步骤引用。
- 最终回答应该依赖哪些执行证据。
- 中间是否需要 validator 检查。
这种表示方式很重要，因为它给“修复”留下了空间。
如果模型只输出一整段文本，你很难精确修：到底是工具选错了，还是参数错了，还是步骤顺序错了？但如果输出是一张图，系统就能做局部操作。
Evoflux 的结构化编辑包括几类：
- 换工具：当前工具不匹配，就尝试同类或相邻工具。
- 改参数：补齐缺失字段，修正类型，从上游结果里重新绑定参数。
- 插入工具：发现缺少中间步骤，比如先搜索再读取详情。
- 删除工具：去掉无效或多余步骤。
- 重排步骤：修正依赖顺序。
- 插入校验器：在关键节点检查输出是否满足后续需求。
这其实很像人类调试自动化脚本。脚本失败后，我们不会整段重写，而是看报错、看输入输出、看依赖，然后改一个局部。Evoflux 把这个过程系统化了。
4. 执行反馈比“看起来合理”更重要
Evoflux 的另一个关键点是，它不只依赖语言模型自评。
候选工作流会经过一套 candidate builder 和执行环境：先做静态检查，看工具是否存在、schema 是否匹配、依赖是否能解析；再尽可能真实执行；执行后再根据结果、错误、证据覆盖情况给分。
这个分数不是单纯问模型“你觉得对不对”。它会利用更硬的信号：
- 编译是否成功。
- schema 校验是否通过。
- 工具执行是否报错。
- 后续节点是否拿到了需要的值。
- 最终答案是否引用了真实执行结果。
- 任务目标是否被满足。
对 Agent 系统来说，这是一个非常重要的工程分水岭。
只让模型生成方案，系统很容易被“像正确”的文本骗过去。让方案进入执行环境，错误会暴露得更早、更具体。Evoflux 的演化搜索正是围绕这些具体错误展开，而不是在抽象层面反复提示模型“请更仔细”。
5. 为什么不是直接微调
这篇论文最值得琢磨的实验结论之一，是监督微调和 DPO 并没有在这个任务上稳定解决问题。
论文在 MCP-Bench 上做评测。这个基准包含 live MCP servers 和约 250 个工具，强调真实工具目录、动态 schema、多跳执行和跨域编排。对于 held-out 任务，紧凑模型初始可执行率大约只有 3%。Evoflux 能把可执行率提升到大约 17% 到 24% 这个区间，而 SFT、SFT+DPO 这些训练式方法表现并不稳定，甚至出现退化。
这不代表微调没用，而是提醒我们：开放工具环境里，失败往往来自组合泛化和运行时约束。
训练数据可以教模型“以前见过的工具该怎么用”，但真实部署时工具目录会变，schema 会变，参数组合会变，任务目标也会变。模型在训练集里学到的模式，未必能覆盖新的执行边界。
Evoflux 选择在推理时搜索，有一个明显优势：它能看见当前这一次任务的真实错误。
微调：提前学一个总体习惯
Evoflux：当前任务失败在哪里，就围绕哪里修这也是它能打动我的地方。Agent 工程里很多问题不适合只靠“训练一个更会调用工具的模型”解决，因为工具世界本身是活的。你需要运行时反馈，需要把失败变成可操作证据。
6. Evoflux 和 ReAct 的差别
论文也拿 Evoflux 和 ReAct 做了比较。大致结论是：ReAct 有时能达到更高峰值，但方差更大、token 成本也更高；Evoflux 更关注紧凑模型在受控搜索下的可执行性提升。
我理解两者差异可以这样看：
ReAct 把工具使用放在一条线性对话轨迹里。模型看到观察结果后继续想，继续调用工具。它灵活，但也容易把错误带进下一轮自然语言上下文里。
Evoflux 把工具使用放在一个可编辑的结构里。系统可以维护多个候选图，对它们做局部变异、打分、剪枝和重组。它不像 ReAct 那么自然，但更利于工程系统做验证和搜索。
如果任务简单，ReAct 很直接。如果任务需要多工具依赖、schema 校验、失败修复、证据约束，Evoflux 这种“图 + 执行反馈 + 演化搜索”的形态更接近可靠工作流系统。
7. 我觉得最有迁移价值的三个观点
第一，不要把工具调用当成文本输出评测。
一个工具 Agent 的输出不是“它说了什么”，而是“它构造的执行计划有没有真的跑通”。所以评测也不应该只看答案相似度，而要看工具解析、schema、依赖、执行、证据链。
第二，失败信息是一等数据。
很多系统只记录最后成功或失败，但 Evoflux 暗示我们应该记录更细：哪个节点失败、失败类型是什么、参数缺什么、依赖断在哪里、哪个编辑修好了问题。这些数据以后可以反过来训练模型，也可以用于改工具描述、改 schema、改编排器。
第三，小模型不一定要一次生成完美答案。
小模型的优势是便宜、快、可本地部署，但它们在复杂工具编排上不稳定。Evoflux 展示了一种折中：让小模型先给出粗方案，再用外部搜索和执行反馈补足可靠性。它不是把小模型神化，而是承认小模型会错，然后设计一个能系统性修错的外壳。
8. 这篇论文的局限
Evoflux 的结果很有启发，但也不能过度解读。
第一，可执行率从 3% 提到 17% 到 24%，提升很明显，但离“可靠可上线”还很远。这说明问题确实难，也说明演化搜索不是银弹。
第二，推理时搜索会带来额外成本。它要维护候选集合、执行校验、做多轮编辑和评分。对一些简单任务，这可能比直接调用强模型更麻烦。
第三，它依赖可执行环境和清晰的工具反馈。如果工具本身报错不透明，或者执行副作用很危险，演化搜索就需要更强的沙箱、权限和回滚机制。
第四，评分器和 judge 仍然可能引入偏差。执行成功不等于任务正确；任务正确也不总能被简单规则判断。越接近开放任务，评估越难。
所以我不会把 Evoflux 理解成“以后所有 Agent 都该这么做”。更准确的说法是：当工具调用已经复杂到像工作流系统，而模型又不够强或不能承担高成本时，Evoflux 提供了一条很有工程味的路线。
9. 总结
Evoflux 这篇论文的价值，不在于又提出了一个更花哨的 Agent 框架，而在于它把问题重新摆正了：
工具 Agent 的核心不是生成一段漂亮文本，而是构造一个能被真实环境接受的可执行工作流。
一旦这样看，很多设计都会自然改变。我们会更重视 schema、依赖、执行证据、错误分类、局部修复、候选剪枝和运行时搜索。模型不再是唯一的智能来源，执行系统本身也参与了推理。
这可能是未来很多 Agent 系统会走向的形态：模型负责提出候选，环境负责揭示错误，搜索器负责修复结构，最终答案必须绑定真实执行证据。
小模型不会稳定用工具时，先别急着只想着微调。也许更值得先问一句：我们有没有把它的错误变成可修复的工作流反馈？