AutoAgent的意义：从“手工调Agent”走向“自动进化Agent系统”

这篇文章的重量不在于“又一个 Agent 框架”，而在于它把一个长期被默认为“只能靠手艺”的工作——调 Agent——第一次明确地改写成了一种可以自动化、可迭代、可规模化的系统形态：让 Agent 自己优化 Agent。

我们过去谈 Agent，总在谈能力：会不会用工具、会不会拆解任务、会不会写代码、会不会调用 API。AutoAgent 讨论的却是另一件事：能力从哪里来。当能力的来源从“人手工调”迁移到“系统自动进化”，Agent 工程就不再是一门“会的人很少”的手艺活，而更像软件工程早期从“手工部署”走向“CI/CD”的那次跃迁。

把“调Agent”翻译成一个系统问题

你可以把一个 Agent 看成一个可执行程序，但它真正决定表现的，往往不是模型本身，而是它外面的那圈“运行框架”：提示词、工具集合、调用顺序、验证机制、失败回滚、上下文管理、多 Agent 分工……这些东西在行业里有个很贴切的词：harness。

过去的主流做法是：人类工程师盯着失败案例，改 prompt，换工具，改流程，再跑一次。效果确实能上去，但它有三个天然的天花板：

• 它依赖直觉：工程师用“人类的合理性”去猜“模型的决策方式”，猜对了是经验，猜错了就是错误先验。
• 它不可规模化：一套 harness 适配一个领域就要反复打磨；换领域，重来。
• 它不可持续迭代：人会疲惫，会厌烦，会停在一个“差不多能用”的局部最优。

AutoAgent 做的第一件事，就是把这件事重新命名：我们不是在“调模型”，而是在优化一个运行系统。而优化系统，最强的方法从来不是“手改参数”，而是“让系统自己在评测里进化”。

AutoAgent到底是什么：不是框架，而是“优化工厂”

AutoAgent 的结构很简单，但它的分层非常关键：

• task agent：真正执行任务的智能体。它可能一开始很朴素，甚至只会几个工具。
• meta-agent：不直接解决任务，而是负责不断修改 task agent 的 harness，并用评测结果筛选出更好的版本。

它的输入也很“工程化”：一个任务领域 + 一组评测（evals）。系统在沙箱里运行，meta-agent 可以并行开大量实验：每一次实验都对 harness 做一次改动，然后把改动后的 task agent 拉去跑 eval，收集分数与失败轨迹，再决定保留还是回滚。

这听起来像“自动化调参”，但它比调参更像“自动化科研”：一个模型在研究如何让另一个模型在特定任务上表现更好，并且这个研究过程是持续迭代、可并行探索的。

关键机制：自我进化循环靠的不是分数，而是失败轨迹

如果你只给一个系统“分数”，它能做的优化很有限，因为它不知道为什么失败。AutoAgent 的关键资源不是 score，而是 execution trace（失败轨迹）。

它的循环可以抽象成六步：

• meta-agent 修改 harness（prompt/工具/编排/验证/协作方式等）
• task agent 跑评测
• 收集 score + traces
• meta-agent 阅读 trace，定位失败发生在哪一步、为什么偏离
• 决定保留/回滚/改方向
• 重复，并行探索

这里 trace 的角色不是“日志”，而是“行为解释层”。它让优化从 blind search 变成一种结构化进化：你不再是在黑箱里胡乱试，而是在读懂失败之后，做针对性修补。

这一点会直接改变我们看待 Agent 的方式：真正可优化的对象，不是“让模型更聪明”，而是让系统的失败更可见、可解释、可被修复。

为什么它可能跑赢人类：模型正在理解模型

传统 harness engineering 的痛点，是工程师用自己的认知去解释模型的行为。很多时候，这是一种误译：你以为它“没理解”，它可能是“理解了但选择了另一条路”；你以为它“应该这么做”，它可能是“在另一种内在策略下更倾向那样做”。

AutoAgent 的 meta-agent 有一个人类不具备的优势：它可以直接读取 task agent 的 reasoning trace，从而形成作者称为 model empathy（模型共情）——不是同情，而是对“另一个模型如何决策”的内在理解。

这会带来一个更深的结论：未来 Agent 系统的设计不再只是“功能组合”，而是“认知对齐”。同样的工具、同样的任务，不同的模型配对，优化效果可能完全不同，因为 meta-agent 能否准确预测 task agent 的行为模式，决定了它能不能给出有效改动。

当模型能力逼近或超过人类的 99th percentile，人类直觉这套老方法会越来越失效。系统需要通过自我探索去发现结构，而不是靠人类猜结构。

最有意思的部分：行为不是设计出来的，是“长出来的”

AutoAgent 的另一个启发是：当你把“提高分数”作为目标，并给系统提供足够多的试错空间，它会自己长出很多工程策略，而不是等你写进 prompt。

比如它会出现：

• spot checking：不跑全量 eval，而是挑关键样本做局部测试来省算力。
• verification loops：输出后自检，避免一次性提交。
• test generation：主动生成测试用例来验证答案。
• progressive disclosure：把长上下文写入文件，避免上下文爆炸。
• orchestration logic：任务复杂时拆分子 agent 做分工协作。

这些并不是“某个专家写的最佳实践”，而是系统在大量失败里发现的“更容易赢”的策略。它说明优化空间不只是局部参数，而是整体行为结构的自组织演化。

换句话说：你以为你在调 prompt，实际上你在培育一种工作方式。

分层是必须的：执行能力与改进能力不能绑在一个体内

AutoAgent 的关键实验结论之一是：单 agent 自我优化很容易失败，必须拆成 meta-agent + task agent。

原因很直观：task agent 的职责是“把事做出来”，meta-agent 的职责是“让系统变得更会做事”。如果把两者合并在一个体内，它往往会在“立刻完成任务”与“长期改进系统”之间摇摆，陷入保守与局部最优。

分层之后，meta-agent 才能跳出当前策略空间，对系统做结构级修改：不仅改几句话，而是改“流程、验证、工具边界、多 agent 协作方式”。

同时，trace 的质量决定上限：如果只给分数不给 trace，meta-agent 几乎无法有效改进，因为它不知道“为什么失败”。

这件事真正的意义：从“手工调Agent”到“自动进化Agent系统”

AutoAgent 的价值不在于让某个 benchmark 更高分，而在于它把 Agent 工程的主语改写了：

• 过去：工程师维护一个 Agent，通过手工调优维持可用。
• 未来：工程师维护一个“Agent 工厂”，不断生成和优化不同任务的专用 Agent。

人类的工作从“调 prompt、接工具、改流程”迁移到更上层的事情：定义 success criteria（评测标准），定义约束边界，定义系统不允许用的捷径，定义什么叫“长期价值”。

当 harness 的优化可以自动完成，企业真正会维护的，不是一个 Agent，而是一套能持续演化的系统：每个部门、每条流程、每个 API workflow，都可以拥有自己的 task agent，而 meta-agent 负责持续优化这些 agent 的性能。

这会极大降低 AI 应用工程成本，也会改变“agent infrastructure”这几个字的含义：基础设施不再是工具和链路，而是“让系统持续变强”的机制。

风险与边界：最危险的误读是把它当成万能调参器

这种系统最容易出现的风险，是 overfitting：meta-agent 可能学会针对 benchmark 做 hack，而不是提升真实能力。比如它优化的不是“更会做表格”，而是“更会迎合评分规则”。

因此，自动进化系统必须内置反思约束：

• 这个改动如果离开当前评测，还值不值？
• 这个提升是因为更可靠，还是因为更会投机？
• 失败轨迹显示的是能力缺陷，还是评测漏洞？

没有这些边界，进化会走向“更像考试机器”，而不是“更像可靠系统”。

终极拷问：你是在养一个Agent，还是在养一套会进化的系统？

如果把 Agent 当成一个员工，你会不断培训它；但如果把它当成一个系统，你会问的不是“这次能不能做出来”，而是：

这套系统是否具备自我纠错、自我验证、自我改进的机制？

AutoAgent 把问题从“怎么把这次做对”推进到了“怎么让系统越来越不靠人”。这不是一个框架的更新，这是一个时代的切换。