一、"能跑通"的 Agent，为什么仍然在赔钱

2026 年下半年，Agent 的讨论重心已经明显从"能不能做"转向"划不划算、稳不稳定"。落过地的人都知道两件事最扎心：

1. 推理成本失控。一个复杂办公任务动辄几十轮工具调用，如果每轮都打最贵的旗舰模型，单次任务成本可能是人工的数十倍。
2. 失败无法沉淀。任务挂了，只能人工翻日志、改提示词、补工具、再重跑；下一批任务又把同样的坑踩一遍。

近期两个开放的技术动作，恰好分别打在"降本"和"进化"这两个点上，值得展开聊聊。

二、HydraFusion：把"选模型"从静态配置变成运行时调度

2026 年 9 月初，GitHub 在 Copilot CLI 中放出 Project HydraFusion 研究预览。它的核心不是训一个新模型，而是把多模型编排做成运行时决策，内置三种执行模式：

Cascade 的调度逻辑抽象出来非常简单：

def cascade(task, small, large):
    draft = small.run(task)                       # 廉价模型先出草稿
    if quality_score(draft) >= task.threshold:    # 门限内的结果直接返回
        return draft, "small"
    return large.run(task), "large"               # 只在必要时付高价

真正难的是 quality_score：GitHub 的做法是让评测信号来自任务本身可验证的产物（编译是否通过、测试是否全绿、终端命令是否返回预期），而不是再挂一个"裁判模型"评估——后者省不下钱，还引入新误差。

按官方披露，HydraFusion 在 TerminalBench 2.1、DeepSWE、CheckpointBench 三个基准上取得与 Claude Opus 5 相当或更好的结果，而估算 Token 成本降低 36%～67%。这个区间的下限和上限，本质取决于你任务集合里"简单任务"的占比——任务越同质，编排收益越小。

三、RSI：给 Agent 装一个"错题本"

另一个方向来自开源 Agent 平台 openJiuwen 首发的双维度 RSI（Recursive Self-Improvement，递归自我改进）框架。它要解决的是"交付即定型"：让智能体从真实任务的成败反馈中自动生成改进方案、执行验证、只保留有效改进。

它的工程骨架分四层协作：

• 任务层：定义优化什么、怎么评价、能用多少资源；
• 迭代优化层：决定下一步试什么、哪些改动可以采纳；
• 执行层：实际尝试优化并检测结果；
• 基础框架层：运行、模型与上下文、沙箱隔离、状态恢复、可观测性。

用户侧的使用路径被压成了四步：准备一份包含用例知识、任务要求、评测方式、参考答案与评分规则的 JSON 评测集 → 在"实验"页选择 Harness 优化，指定优化模型、测试模型、初始插件与最大迭代轮次 → 观察得分、搜索树与模型用量 → 把验证有效的最优 Harness 作为插件包热加载。

效果上，基于 SWE-bench Lite，Harness 优化把通过率从 61.0% 提升到 87.0%；优化后的 Harness 冻结下来，在 Evo-Bench General 64 道独立题上的单次执行通过率也从 60.9% 提升到 71.9%。后一个数字更关键——它说明改进是可迁移的，而不是对评测集的过拟合。

四、三条落地心得

1. 先有评测集，再谈自我改进。没有可验证的评分规则，自动化迭代只会放大噪声。哪怕先手写 30 条带参考答案的用例，也比空转强。
2. 降本靠分级，不靠降级。全局换成小模型省下的钱，会被返工和人工兜底吃掉；Cascade 的价值在于把"贵模型的调用次数"变成可调参数。
3. 改进必须版本化、可回滚。Harness、提示词、工具描述都应视为可发布、可回滚的产物，每一次优化都要有证据链，否则线上一次"优化"就可能变成一次故障。

结语

多模型编排解决的是"这一次任务花多少钱"，递归自我改进解决的是"下一次任务能不能更好"。两者叠加，构成 Agent 从演示走向生产的两条基础能力线。2026 年剩下的时间，比拼的不再是谁的 Demo 更炫，而是谁的评测集更扎实、谁的调度策略更精细。

技术标签：#AIAgent #多模型编排 #Token成本优化 #递归自我改进 #Harness #SWEbench #LLM工程化 #开源框架