导读「Agent」任务做不好升级模型之外还有三条值得检验的路线迭代解决方案、改善执行环境、搜索执行框架。但现有材料不足以证明它们更便宜、更有效。真正该比较的是哪种改动能以可接受的总成本提高任务交付率。任务失败了第一反应是换更强的模型。这个决定很顺手改一个模型名称就能继续跑。麻烦在于如果失败来自工具反馈缺失、状态丢失或错误的重试流程换模型究竟是在解决问题还是在给问题加预算我不反对为模型能力付费但我反对还没定位失败原因就把采购升级当成技术诊断。01 先拆开失败再讨论升级「Agent」失败不该只留下一个“模型不够聪明”的结论。至少要拆开四层模型能力、解决方案、执行环境、执行框架。「模型能力」决定它能否理解需求、推理约束、生成有效动作。「解决方案」是这一次任务采取的具体路径先查什么、改哪里、怎样验证。「执行环境」决定它能接触什么。文件是否完整工具输出是否清楚测试能否运行失败后有没有可恢复的状态都属于这一层。「执行框架」则控制它怎样行动何时调用工具、如何传递状态、什么时候反思、遇错怎样重试以及何时停止。这几层会交叉但不能混成一团。可以用一个假设场景理解让「Agent」修复程序测试工具只返回“失败”没有错误位置。此时该检验的首先是补全反馈能否改善结果。如果反馈充分、状态完整它仍然无法理解约束升级模型才有更明确的理由。我之前写过《DeepSeek DSecAgent规模化为什么先卡在执行环境》。这里延续同一个判断工程系统必须进入评估范围。先确定是哪一层失效再决定把钱花在哪一层。这也是三项研究值得放在一起看的原因它们把优化对象从模型本身扩展到了模型周围。02 AREX-2反思有没有产生更好的方案给定材料将「AREX-2」的研究对象概括为智能体在测试阶段迭代完善当前解决方案的能力。这里的「测试时自我改进」首先指向任务执行中的方案改进。它不能直接被写成“模型学会了新能力”更不能据此断言模型权重保持不变该研究的具体设置待核实。材料把「反思」描述为生成优于当前方案的新方案。这个定义很关键输出一段检讨不等于完成改进。“我应该更仔细”没有验收价值。下一版是否修复了错误是否保住原有正确结果是否更接近交付要求才值得计分。对「长周期任务」还得看改进能否持续。某一轮成功不代表后续不会退化最终成功也不代表中间没有依赖人工救场。我对“反思次数更多所以能力更强”这类结论一直保留意见。次数是投入改进才是产出两者不能互相替代。按照这条路线设计实验至少需要比较初始方案、迭代方案和相同预算下的重复尝试并记录每轮结果。否则无法区分收益来自有效反思还是仅仅多试了几次。已有积累也提醒我们朴素迭代可能对少量测试用例过拟合。我的建议是把参与改进的测试与最终验收测试分开检查是否只是迎合了眼前反馈。上述内容是验收建议。所列「AREX-2」论文编号与描述的对应关系以及提升幅度、任务范围和统计可靠性均待核实。03 Builder让模型拥有更好的工作条件第二条路线更接近系统架构问题模型不变能不能通过改善工作条件提高任务表现给定材料中的「测试时 AI4AI」研究由「Builder」为「Target」构建执行环境并明确指出两者的模型权重均保持固定。这个条件让研究问题更清楚关注的是环境设计而不是把模型升级混进优化过程。但「权重固定」不等于「成本固定」。构建环境要调用多少次模型、投入多少搜索和调试、是否需要人工筛选现有材料没有给出。可以设想一个工程例子同样是修复错误一种环境提供杂乱日志另一种提供结构化报错、可重复测试和清晰的工具接口。这说明环境设计可以改变什么它不是该论文的实验结果不能拿来充当性能证据。更值得关注的是材料提到的「元技能」能否把「Builder」设计环境的经验转化成之后可复用的方法。这比保存一次成功配置更进一步。一次配置可能只适合当前任务复用能力则需要面对新任务、新约束仍然找到有帮助的设计。我更看重这一层。否则每次都重新摸索一套环境所谓自动优化只是把人工试错搬进模型调用账单。验证时应比较首次构建与复用经验的投入并在未参与构建的任务上验收。具体方法、复用收益与适用边界待核实。04 MILO框架能自动发现账单也要跟着算第三条路线把优化对象放在「执行框架」上。「MILO」研究通过编排多智能体演化自动发现框架。给定材料指出智能体系统由模型与控制执行、环境交互的框架共同组成框架设计的组合搜索空间较大人工投入较高。这很好理解。是否设置独立验证步骤、何时压缩上下文、怎样重试、如何交接状态都可能成为设计选择。这些选择叠加起来就不再是“调一句提示词”那么简单。而材料还指出模型变化后框架往往需要重复设计。「MILO」因此提供了一条自动化搜索路线。但自动发现框架与找到经济上划算的框架是两回事。搜索阶段可能生成多个候选执行阶段也可能增加协调、验证或重试。具体额外开销现有材料没有披露待核实。自动化搜索减少了多少人工必须和它增加了多少计算一起核算。验收还要防止框架只适合参与搜索的任务。应当保留独立任务并检查换任务类型、换模型之后是否仍有效。已有积累中的「EvoSteer」还尝试在运行中演化通信图。它提示我们编排本身也可以成为优化对象但其稳定性与成本同样缺少材料支持。所以对「MILO」目前更稳妥的评价是值得检验的框架设计路线。搜索成本、性能增益和跨模型迁移效果均待核实。05 对照实验先固定条件再谈谁值得买三条路线分别改变方案、环境与框架。要回答“是否必须升级模型”就需要把升级模型也放进同一组对照。我建议先建立基线固定任务、初始状态、验收规则和预算。保留失败轨迹别让成功率掩盖失败原因。方案迭代、环境设计和框架搜索先使用同一个目标模型升级模型作为独立实验组保留原有环境与框架。第一轮尽量只改变一个变量。否则模型、工具和流程同时调整最后即使成功也不知道该为谁付费。实验组主要改动需要单独记录的投入基线组当前模型与流程当前完整投入模型升级组更换目标模型调用与适配投入方案迭代组增加改进轮次反思、重试与验证环境设计组调整执行环境「Builder」构建投入框架搜索组搜索执行框架搜索与候选评估所有组都记录任务成功率、总耗时、模型调用成本、工具与运行资源成本以及人工投入。这里还要做两种比较相同预算下谁交付得更多达到相近成功率时谁花费更少。两种问题不能混成一个排名。我的判断是「单次调用价格」不适合单独决定采购。便宜的调用如果需要大量重试最终账单未必便宜。反过来更贵的模型如果减少重试和人工接管也可能有价值。这是应检验的成本关系现有素材没有足够数据给出胜负。06 不同业务应该从不同瓶颈开始对开发者答案可以很明确任务失败不足以构成必须升级模型的证据。但“先别升级”也不能变成信仰。方案、环境和框架有各自的适用前提应该根据失败轨迹选择实验起点。如果工具反馈不完整、文件缺失或状态传递出错先检验环境与框架。至少要让模型拥有完成任务所需的信息和动作条件。如果反馈清楚、验收可执行而当前方案能通过迭代逐步改善可以检验方案优化。但必须限制轮次并检查是否破坏已有结果。如果工作流需要频繁适配人工框架设计成为持续负担可以考虑自动搜索。搜索投入应与预计复用次数一起评估。如果充分信息、合理流程和可用工具都已具备错误仍集中在任务理解或推理上就该把升级模型作为重点对照。我更愿意给技术负责人一张失败分布表而不是一张模型榜单。榜单告诉你谁值得关注失败分布才告诉你当前系统该改哪里。创业团队还要把人工接管算进去谁检查结果、谁处理异常、谁承担返工都属于交付成本。这三项研究提供的是优化问题的不同入口。现有材料不能证明三者都在固定权重下有效也不能证明它们比升级模型更便宜。值得付费的是经过验收的交付能力。模型升级和系统优化都应该接受同一套账本检验。结语让「Agent」变强不必把升级模型当成唯一入口。先拆开失败再分别检验方案、环境与框架最后用成功率、耗时和总成本做决定。研究方向值得关注但缺失的实验与成本证据不能用热情补齐。互动话题你的「Agent」最近一次失败主要卡在模型理解、工具反馈、状态管理还是执行流程如果只能先改一项你会选什么如果觉得有价值欢迎「点赞」「在看」「转发」三连 ↓参考来源AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective TasksarXiv cs.AIAREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective TasksHugging Face 每日论文Learning Meta-Skills for Agent Harness Design in Test-Time AI4AIHugging Face 每日论文MILO: Automated Harness Discovery via Orchestrated Multi-Agent EvolutionHugging Face 每日论文