企业官网建设流程全解析

导读：「Agent」任务做不好，升级模型之外，还有三条值得检验的路线：迭代解决方案、改善执行环境、搜索执行框架。但现有材料不足以证明它们更便宜、更有效。真正该比较的，是哪种改动能以可接受的总成本，提高任务交付率。

任务失败了，第一反应是换更强的模型。这个决定很顺手：改一个模型名称，就能继续跑。

麻烦在于，如果失败来自工具反馈缺失、状态丢失或错误的重试流程，换模型究竟是在解决问题，还是在给问题加预算？

我不反对为模型能力付费，但我反对还没定位失败原因，就把采购升级当成技术诊断。

01 先拆开失败，再讨论升级

「Agent」失败，不该只留下一个“模型不够聪明”的结论。至少要拆开四层：模型能力、解决方案、执行环境、执行框架。

「模型能力」决定它能否理解需求、推理约束、生成有效动作。「解决方案」是这一次任务采取的具体路径：先查什么、改哪里、怎样验证。

「执行环境」决定它能接触什么。文件是否完整，工具输出是否清楚，测试能否运行，失败后有没有可恢复的状态，都属于这一层。

「执行框架」则控制它怎样行动：何时调用工具、如何传递状态、什么时候反思、遇错怎样重试，以及何时停止。

这几层会交叉，但不能混成一团。可以用一个假设场景理解：让「Agent」修复程序，测试工具只返回“失败”，没有错误位置。

此时该检验的，首先是补全反馈能否改善结果。如果反馈充分、状态完整，它仍然无法理解约束，升级模型才有更明确的理由。

我之前写过《DeepSeek DSec：Agent规模化，为什么先卡在执行环境？》。这里延续同一个判断：工程系统必须进入评估范围。

先确定是哪一层失效，再决定把钱花在哪一层。

这也是三项研究值得放在一起看的原因：它们把优化对象，从模型本身扩展到了模型周围。

02 AREX-2：反思有没有产生更好的方案

给定材料将「AREX-2」的研究对象概括为：智能体在测试阶段，迭代完善当前解决方案的能力。

这里的「测试时自我改进」，首先指向任务执行中的方案改进。它不能直接被写成“模型学会了新能力”，更不能据此断言模型权重保持不变；该研究的具体设置待核实。

材料把「反思」描述为生成优于当前方案的新方案。这个定义很关键：输出一段检讨，不等于完成改进。

“我应该更仔细”没有验收价值。下一版是否修复了错误，是否保住原有正确结果，是否更接近交付要求，才值得计分。

对「长周期任务」，还得看改进能否持续。某一轮成功，不代表后续不会退化；最终成功，也不代表中间没有依赖人工救场。

我对“反思次数更多，所以能力更强”这类结论一直保留意见。次数是投入，改进才是产出，两者不能互相替代。

按照这条路线设计实验，至少需要比较初始方案、迭代方案和相同预算下的重复尝试，并记录每轮结果。

否则，无法区分收益来自有效反思，还是仅仅多试了几次。

已有积累也提醒我们：朴素迭代可能对少量测试用例过拟合。我的建议是把参与改进的测试与最终验收测试分开，检查是否只是迎合了眼前反馈。

上述内容是验收建议。所列「AREX-2」论文编号与描述的对应关系，以及提升幅度、任务范围和统计可靠性，均待核实。

03 Builder：让模型拥有更好的工作条件

第二条路线更接近系统架构问题：模型不变，能不能通过改善工作条件，提高任务表现？

给定材料中的「测试时 AI4AI」研究，由「Builder」为「Target」构建执行环境，并明确指出两者的模型权重均保持固定。

这个条件让研究问题更清楚：关注的是环境设计，而不是把模型升级混进优化过程。

但「权重固定」不等于「成本固定」。构建环境要调用多少次模型、投入多少搜索和调试、是否需要人工筛选，现有材料没有给出。

可以设想一个工程例子：同样是修复错误，一种环境提供杂乱日志，另一种提供结构化报错、可重复测试和清晰的工具接口。

这说明环境设计可以改变什么；它不是该论文的实验结果，不能拿来充当性能证据。

更值得关注的，是材料提到的「元技能」：能否把「Builder」设计环境的经验，转化成之后可复用的方法。

这比保存一次成功配置更进一步。一次配置可能只适合当前任务；复用能力则需要面对新任务、新约束，仍然找到有帮助的设计。

我更看重这一层。否则，每次都重新摸索一套环境，所谓自动优化只是把人工试错搬进模型调用账单。

验证时，应比较首次构建与复用经验的投入，并在未参与构建的任务上验收。具体方法、复用收益与适用边界待核实。

04 MILO：框架能自动发现，账单也要跟着算

第三条路线把优化对象放在「执行框架」上。「MILO」研究通过编排多智能体演化，自动发现框架。

给定材料指出，智能体系统由模型与控制执行、环境交互的框架共同组成；框架设计的组合搜索空间较大，人工投入较高。

这很好理解。是否设置独立验证步骤、何时压缩上下文、怎样重试、如何交接状态，都可能成为设计选择。

这些选择叠加起来，就不再是“调一句提示词”那么简单。而材料还指出，模型变化后，框架往往需要重复设计。

「MILO」因此提供了一条自动化搜索路线。但自动发现框架，与找到经济上划算的框架，是两回事。

搜索阶段可能生成多个候选，执行阶段也可能增加协调、验证或重试。具体额外开销，现有材料没有披露，待核实。

自动化搜索减少了多少人工，必须和它增加了多少计算一起核算。

验收还要防止框架只适合参与搜索的任务。应当保留独立任务，并检查换任务类型、换模型之后是否仍有效。

已有积累中的「EvoSteer」还尝试在运行中演化通信图。它提示我们，编排本身也可以成为优化对象；但其稳定性与成本同样缺少材料支持。

所以，对「MILO」目前更稳妥的评价是：值得检验的框架设计路线。搜索成本、性能增益和跨模型迁移效果，均待核实。

05 对照实验：先固定条件，再谈谁值得买

三条路线分别改变方案、环境与框架。要回答“是否必须升级模型”，就需要把升级模型也放进同一组对照。

我建议先建立基线：固定任务、初始状态、验收规则和预算。保留失败轨迹，别让成功率掩盖失败原因。

方案迭代、环境设计和框架搜索，先使用同一个目标模型；升级模型作为独立实验组，保留原有环境与框架。

第一轮尽量只改变一个变量。否则，模型、工具和流程同时调整，最后即使成功，也不知道该为谁付费。

所有组都记录任务成功率、总耗时、模型调用成本、工具与运行资源成本，以及人工投入。

这里还要做两种比较：相同预算下，谁交付得更多；达到相近成功率时，谁花费更少。两种问题不能混成一个排名。

我的判断是，「单次调用价格」不适合单独决定采购。便宜的调用如果需要大量重试，最终账单未必便宜。

反过来，更贵的模型如果减少重试和人工接管，也可能有价值。这是应检验的成本关系，现有素材没有足够数据给出胜负。

06 不同业务，应该从不同瓶颈开始

对开发者，答案可以很明确：任务失败，不足以构成必须升级模型的证据。

但“先别升级”也不能变成信仰。方案、环境和框架有各自的适用前提，应该根据失败轨迹选择实验起点。

如果工具反馈不完整、文件缺失或状态传递出错，先检验环境与框架。至少要让模型拥有完成任务所需的信息和动作条件。

如果反馈清楚、验收可执行，而当前方案能通过迭代逐步改善，可以检验方案优化。但必须限制轮次，并检查是否破坏已有结果。

如果工作流需要频繁适配，人工框架设计成为持续负担，可以考虑自动搜索。搜索投入应与预计复用次数一起评估。

如果充分信息、合理流程和可用工具都已具备，错误仍集中在任务理解或推理上，就该把升级模型作为重点对照。

我更愿意给技术负责人一张失败分布表，而不是一张模型榜单。榜单告诉你谁值得关注，失败分布才告诉你当前系统该改哪里。

创业团队还要把人工接管算进去：谁检查结果、谁处理异常、谁承担返工，都属于交付成本。

这三项研究提供的是优化问题的不同入口。现有材料不能证明三者都在固定权重下有效，也不能证明它们比升级模型更便宜。

值得付费的，是经过验收的交付能力。模型升级和系统优化，都应该接受同一套账本检验。

结语：让「Agent」变强，不必把升级模型当成唯一入口。先拆开失败，再分别检验方案、环境与框架，最后用成功率、耗时和总成本做决定。研究方向值得关注，但缺失的实验与成本证据，不能用热情补齐。

💬互动话题：你的「Agent」最近一次失败，主要卡在模型理解、工具反馈、状态管理，还是执行流程？如果只能先改一项，你会选什么？

如果觉得有价值，欢迎「点赞」「在看」「转发」三连 ↓

参考来源：

• AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective Tasks（arXiv cs.AI）
• AREX-2: Advancing Self-Improving Agents through Long-Horizon Reflective Tasks（Hugging Face 每日论文）
• Learning Meta-Skills for Agent Harness Design in Test-Time AI4AI（Hugging Face 每日论文）
• MILO: Automated Harness Discovery via Orchestrated Multi-Agent Evolution（Hugging Face 每日论文）