在AI产品纷纷陷入工具堆砌的竞赛时，Yunjue-Agent以空壳之姿杀出重围，凭借推理阶段的原位自进化能力惊艳全场。本文将深度解析这个基于Gemini Pro的异类系统如何通过零启动造工具、二元反馈机制和EGL动态刹车等创新设计，在开放任务中实现屠榜表现，同时揭示其背后隐藏的成本陷阱与场景局限，为AI产品经理提供全新思考维度。

作为生成式AI浪潮里的产品经理，过去一年我最直观的感受是：大家都在疯狂给Agent“塞装备”。

从各大厂争相发布的 Tool-use更新，到Anthropic力推的Skills机制，再到各类业务线里写得密密麻麻的固定工作流。我们似乎达成了一个隐性共识：Agent要足够聪明，前提是人类得提前给它配齐足够多、足够好用的工具。

直到最近，我在刷论文和开源项目时，注意到了一个反直觉的“异类”——Yunjue-Agent。

在近期大模型打榜的腥风血雨中，这个基于 Gemini 3 Pro 后端的系统，在极具挑战的 HLE 评测中拿下了第二名，并在 DeepSearchQA 上把 Gemini 3 Pro 本体的成绩硬生生拔高了 17.4%。

但它最让我震撼的不是跑分，而是它的出厂设置：它是一个彻头彻尾的“空壳”。

没有预装任何高阶技能，没有人类手写的精巧Workflow。面对开放式的复杂任务，它完全是从一个“空工具库”零启动。

这就引出了一个极其硬核、且关乎下一代产品形态的问题：当大家都在卷预设工具时，为什么一个纯靠“现编”的空壳系统，反而在开放任务里活下来，甚至屠榜了？

这篇文章，我想借着拆解 Yunjue-Agent，聊聊AI产品正在发生的范式转移，以及繁荣跑分背后，那些不能忽视的隐患与局限。

一、被热炒的“预装技能”与它的长尾泥潭

要理解“空壳”的价值，得先看看我们现在是怎么做Agent的。

目前的行业主流做法，我称之为“保姆式外挂”。不管是做基于RAG的客服Agent，还是做数据分析Agent，产品经理和研发的核心工作之一，就是去预判用户场景，然后封装API：

用户要查天气？我们写个 get_weather 工具。

用户要查数据库？我们封装个 sql_query 工具。

这种做法在封闭场景、高频需求下非常有效。但一旦把Agent扔进真实的、开放式的业务“旷野”，问题就来了。

真实世界的需求是极其长尾的。你预设了100个工具，用户偏偏需要第101个。此时，没有预装对应工具的Agent就像被拔了网线，只能给你返回一句抱歉的废话。

我们试图用穷举法去对抗世界的复杂性，这在逻辑上就是行不通的。 传统的自进化通常发生在“训练阶段”，需要专家提前圈定进化领域，需要极其昂贵的高质量外部监督数据。

而 Yunjue-Agent 给出了一条完全相反的解题思路。

二、“原位自进化”：一种零启动的暴力美学

Yunjue-Agent 的核心卖点只有一句话：把“自进化”从训练阶段，搬到了推理阶段。

它不依赖 Ground-truth 标签，而是把连续的任务交互当成一条经验流。在这个过程中，它展现出了一种“遇到河现场造桥，过河后把造桥手艺刻进DNA”的暴力美学。

拆开来看，这个系统靠的是四个核心角色的精密配合：

1. 执行器： 负责接客和干活。拿到任务后，先看手里现有的工具能不能搞定。
2. 工具合成器： 如果执行器发现缺工具，合成器马上“现场写代码”，生成一个新的工具。
3. 验证器： 新工具靠谱吗？验证器会跑一遍代码执行，用客观的运行结果来校验。
4. 归纳器： 任务成功后，归纳器出场。它把这次成功的经验、生成的工具剥离出特定的上下文，沉淀成可复用的“通用原始能力”，塞进原本空空如也的工具库里。

这就是它的“零启动造工具”支柱。从0到1，从1到N，遇到需要特定工具的任务，它直接进化出需要的工具，全程无需人工标注。

为了让这个过程更高效，它还引入了“并行批进化”：把相似的任务打包成一个batch一起跑，跑完得到一个大经验包。这就好比让人类同时做10套相似的模拟卷，做完后总结出通用的解题套路。

三、凭什么活下来？拆解其底层逻辑

看到这里，有经验的产品经理可能会立刻警惕：让AI自己写工具自己用？这不就是左脚踩右脚上天吗？长链路下模型一旦出现幻觉，不就彻底崩溃了？

为什么那些“一句话生成应用”的直出平台经常让用户陷入死循环，而 Yunjue-Agent 却能越跑越聪明？

它的命门，也是它最惊艳的设计，在于两个底层逻辑：

1. 确定的自动裁判：二元反馈机制

很多AI产品的失败，在于它们身处没有标准答案的泥潭。而 Yunjue-Agent 的监督信号，完全来自于代码执行的成功/失败这个客观二值信号。

报错了？那就是失败，打回去重写。跑通了？那就是成功。 正因为有代码执行器这个“铁面无私的裁判”，系统才有了可验证的奖励信号。 没有裁判，就没有可靠的自我纠偏；有了裁判，哪怕是粗糙的二元反馈，也足以引导Agent在推理时不断收敛。同时，系统设计上优先做工具进化，沉淀的是通用原始工具，这极大程度地抑制了长上下文带来的幻觉和策略漂移。

2. 知道何时停止：EGL测试时收敛监测

当Agent拥有了无限造工具的能力，很容易陷入“过度造轮子”的死循环，导致性能灾难。

Yunjue团队为此引入了一个极具工程美感的指标：Evolutionary Generality Loss 。 你可以把它理解为“推理阶段的Loss值”。系统会统计工具的使用频率，当它发现新造的工具越来越鸡肋时，EGL指标就会触发，告诉Agent：“你的工具库已经对这类任务收敛了，自动停止造工具，专心干活吧。”

这种“动态刹车”机制，是把学术概念转化为工程产品的神来之笔。

四、祛魅时刻：它是真范式，还是昂贵的“做题家”？

作为一个在业务一线摸爬滚打的产品经理，看完它惊艳的架构和HLE第二的跑分后，我的职业习惯让我必须泼一盆冷水。

Yunjue-Agent 确实完成了一次漂亮的范式转移，证明了“从零自举出通用能力”的可行性。但距离我们把它打包成C端产品或者企业级SaaS，中间还隔着几道叹息之墙。

隐忧一：成本极高的“做题家” 在推理时“现场造工具+验证+归纳”，还要跑Parallel Batch，这意味着什么？意味着极其恐怖的 Token 消耗和极高的推理延迟。 为了做对一道题，它可能在后台自己跟自己聊了几十轮，试错了上百次。这种计算成本在打榜时是可以接受的，但在实际商业部署中，用户的耐心只有几秒钟，企业也烧不起单次query几十美分的成本。它目前更像一个不计成本的“顶级做题家”，而不是流水线上的熟练工。

隐忧二：二元信号的局限性 Yunjue-Agent 的成功，高度绑定了“代码执行/检索”这类有明确对错标准的可验证任务。 但如果用户让它“写一篇能打动职场新人的软文”，或者“策划一个七夕营销活动”呢？这类任务没有非黑即白的 ground-truth。没有了“代码执行”这个客观裁判，它的“生成-验证-归纳”循环就会立刻瘫痪。换句话说，离开了理科考场，到了文科世界，这套机制依然会抓瞎。

隐忧三：过拟合的阴影 任何自报分数的自进化系统，都天然带有对评测集过拟合的风险。它在HLE和DeepSearchQA上的优异表现，还需要更多第三方社区在更广泛的非标准场景下进行复现。（虽然官方开源了代码和 trace，设置了专门的 reproduce 分支，但工业界需要看的是它在真实脏数据中的表现）。

五、写在最后：给产品经理的启示

不可否认，Yunjue-Agent 提供了一个极具启发性的思路：在AI能力跃迁的时代，产品经理不应该只想着怎么帮AI铺好铁轨，而应该思考怎么给AI造一台能自己铺轨道的车。

当我们把注意力从“预设技能”转移到“设计进化机制”时，我们才真正触碰到了AI Native产品的核心。

把“自进化”搬到推理时，把“造轮子”的权力还给大模型。虽然它现在还很贵、且偏科，但这绝对是一个值得我们持续盯紧的赛道。因为技术成本总会下降，而通往AGI的路上，终究没有那么多保姆。