强Agent做自主机器学习，到底需要多复杂的脚手架？

一个被忽视的问题：脚手架越复杂越好吗？

自主机器学习工程（Autonomous Machine Learning Engineering, MLE）正在成为AI Agent领域的热门战场。近年来，各类MLE Agent在公开排行榜上取得了显著进展，频繁刷新成绩。但在这背后，有一个值得深思的趋势：为了让Agent在长周期任务中持续推进、突破大语言模型（LLM）原生能力的限制，研究者们不断堆叠越来越复杂的"脚手架"（harness）——多Agent编排系统、专用的检索子Agent、精细的任务分解模块等等。

这些机制确实带来了可观的性能提升，但也引出了一个关键问题：一个足够强的Agent，究竟需要多厚重的脚手架才能胜任自主机器学习工程？ 当底层LLM本身能力在持续增强时，这些外部结构是否仍是必需，还是逐渐成为冗余甚至负担？

复杂脚手架的由来

MLE任务本质上是一类长周期（long-horizon）工作：从理解问题、设计方案、编写代码、训练模型，到调试、评估和迭代优化，整个过程往往需要数十甚至上百步的连续决策。早期的LLM在这类任务上容易出现"进展停滞"（progress stagnation）——跑着跑着就陷入重复、迷失方向，或是无法从错误中恢复。

为了应对这些短板，业界的主流思路是"围绕模型加装备"：

• 多Agent编排器：将复杂任务拆分给不同角色的Agent协作完成，比如规划者、执行者、审查者分工。
• 专用检索子Agent：负责从文档、历史经验或外部知识库中拉取相关信息，弥补模型上下文和知识的局限。
• 复杂的状态管理与记忆机制：帮助Agent在长流程中保持一致性。

这套做法的逻辑是：既然单个LLM调用能力有限，那就用工程化的系统架构来补足。于是脚手架越做越大，系统也越来越像一个精密的流水线。

长周期任务对LLM的挑战在技术层面有更深层的根源。LLM的单次推理本质上是无状态的——每次调用只能处理有限的上下文窗口，无法天然保持跨步骤的工作记忆。当MLE任务需要跨越数十轮迭代（例如先探索数据、再调整特征工程、再训练、再根据验证集结果回溯修改流程），这种无状态性会导致模型"遗忘"早期决策的前提，从而产生前后矛盾的操作，或在局部优化中迷失全局目标。多Agent编排架构试图用系统工程的方式来外置这种记忆与协调能力：将全局状态存储在外部数据结构中，由编排层负责在不同Agent调用之间传递上下文。这一设计思路借鉴了传统软件工程中"单一职责"与"关注点分离"的原则，在早期LLM能力有限时确实有效降低了单次调用的复杂度，但代价是整个系统的行为难以端到端追踪。

被冷落的另一条路：更原始但更强的编码Agent

与堆叠复杂脚手架相对的，是一条长期被忽视的技术路线——更原始（primitive）但能力更强的编码Agent。

这类Agent的核心理念是让LLM直接接触执行环境，通过最基础的几个原语（primitives）操作系统：

• read：读取文件内容
• write：写入或修改文件
• bash：执行命令行指令

换句话说，不给模型套上层层中介，而是把它当作一个拥有终端访问权限的工程师，让它自己读代码、写代码、跑命令、看结果。这种极简的交互方式，赋予了Agent极高的自由度和灵活性。

随着底层LLM编码与推理能力的快速提升，这种"轻脚手架、重模型"的路线值得重新审视。一个足够强的模型，配上直接的环境访问权限，或许就能完成那些此前需要复杂多Agent系统才能处理的任务。

这种以read/write/bash为核心原语的交互模式，与Unix哲学高度契合——"做好一件事、通过文件系统和管道组合工具"。Agent通过bash可以调用任意命令行工具（conda、pip、git、nvidia-smi等），通过read/write直接操作代码文件与日志，整个执行环境就是Agent的"工作台"，无需任何中间层转译。这种设计的关键优势在于反馈环路极短：模型执行一条命令后立即看到标准输出或报错，可以在下一步直接根据结果调整策略，这与人类工程师在终端工作的方式几乎一致。SWE-bench等代码Agent基准测试的发展也印证了这一趋势——排名靠前的系统往往在工具接口上保持极简，将复杂度压在模型的推理能力上，而非外部编排逻辑上。

核心权衡：能力在模型里，还是在系统里？

这个问题的本质，是一场关于"智能应该放在哪里"的权衡。

重脚手架路线把大量智能和逻辑固化在系统架构中。它的优势是可控、可解释、对模型能力的依赖相对较低；劣势是系统复杂、维护成本高，而且这些精心设计的流程可能随着模型能力进步而迅速过时——你为弥补旧模型缺陷而搭建的结构，在新模型面前可能纯属多余。

轻脚手架 + 强编码Agent路线则把赌注压在模型本身。它结构简单、泛化性强、能随模型升级"水涨船高"；但它对底层模型的要求极高，一旦模型能力不足，就容易在长周期任务中失控或停滞。

这恰恰是当前Agent工程领域最核心的张力：当模型越来越强，我们到底应该继续加厚脚手架，还是该为模型"减负"，相信它能自主完成更多？

这一张力在AI系统设计中并非首次出现，类似的争论曾发生在深度学习与特征工程之间：早期机器学习严重依赖人工设计的特征提取流程（即"系统里的智能"），而深度学习的崛起证明足够大的模型配合足够多的数据，可以将这些手工规则逐一内化。MLE Agent领域正在经历类似的拐点。值得注意的是，"脚手架复杂度"与"系统性能"之间的关系并非单调递增——过度的任务分解可能切断Agent在完整上下文中进行整体性推理的能力，多个子Agent之间的接口损耗也可能抵消专业化分工带来的收益。因此，这不仅是模型能力与工程能力的权衡，也是"整体涌现能力"与"分解可控性"之间的深层取舍。

对实践者的启示

对于正在构建MLE Agent或其他自主Agent系统的团队，这个讨论提供了几点实际参考：

其一，不要默认"越复杂越好"。复杂的多Agent编排带来排行榜分数的同时，也带来了调试困难、成本上升和脆弱性。在采用前应当评估：这些机制究竟是在补模型的短板，还是在重复模型已经具备的能力。

其二，用最新一代模型重新测试简单基线。许多复杂脚手架是基于早期模型设计的，值得用"直接给模型read/write/bash权限"的极简方案做对照实验，看看差距是否已经缩小甚至反转。

其三，关注长期可维护性。面向快速演进的模型生态，过度定制化的系统架构可能成为技术债。保持架构的简洁，往往意味着更好的前瞻适应性。

结语

"一个强Agent需要多少脚手架"并不是一个能给出标准答案的问题，它取决于任务难度、模型代际和成本约束。但这个追问本身提醒我们：在狂热堆叠Agent工程机制的当下，重新审视那条"让强模型直接干活"的朴素路线，可能会带来意想不到的效率与简洁。随着LLM原生能力持续突破，答案的天平或许正在悄然倾斜。