让你的 Agent 学会去搜索

1. 用几个简单的 Skill 提升 Agent 的科研表现

2026 年 10 月 20 日，论文 Automating ML for Science: Can Frontier Agents Climb Scientific Hills in the Wild? 发布在 arXiv 上（arXiv:2610.28763）。 论文的实验覆盖 11 个科学领域、20 个基准测试，研究前沿 Coding Agent 能否从各基准上已发表的最佳模型出发，自主把它继续改进。

论文为 Agent 加入了三个针对性的 Skill：Research Ideation（研究构思）、Experiment Management（实验管理）和 Scheduled Checklists（定时检查清单）。加入前后，Agent 在 20 个基准上的平均相对提升如下：

论文还总结了 Agent 的三种失败模式：

1. 新颖性判断失准（Novelty Miscalibration）：Agent 对“新颖”的判断与人类系统性错位，常把成熟的常规技巧当成创新（论文中的例子是把余弦学习率调度当成突破）。
2. 资源利用不足（Resource Under-utilization）：GPU 经常闲置，本可并行的实验被串行执行，或者造成 CPU/GPU 资源争用。
3. 探索坍缩（Exploration Collapse）：随着运行推进，Agent 的策略越收越窄，很快锁定熟悉的局部优化方式反复调参，却很少从领域本身寻找新的突破口。

2. 为什么广度搜索可能提升工程质量？

将上述理论挪日常工程里，表现为：Agent 在还没有搞清楚状况的情况下，直接开始动手写代码。

我以为，同过要求Agent在代码任务前进行广度搜索则可以带来改善。

1. 减少重复造轮子

   Agent 可能花几个小时实现一套任务调度、重试或状态管理机制，却不知道已有成熟组件解决了其中的大部分问题。广度搜索可以帮助它识别已有方案，把工作重心转向差异化需求。

2. 扩大架构决策的候选空间

   Agent 往往能针对一个方案写出完整设计，却未必认真比较另外两种架构。先搜索已有实践，可以把决策从“这个方案能不能实现”提升到“为什么这个方案比其他方案更适合”。

3. 提前发现隐藏成本

   开源项目的 Issues、迁移指南、安全公告和设计讨论，往往会揭示 README 没有强调的兼容性、性能和维护问题。这些信息尤其有助于避免架构级错误。

4. 获得超出模型训练知识的实践经验

   Agent 的内部知识可能不包含某个框架近期发生的重大 API 变更，或者社区已经放弃的设计模式。经过验证的外部信息可以帮助它更新判断。

但任需要注意的是：

搜索到成熟方案，不等于必须引入成熟方案。

我建议的做法是学习其中的架构模式、规范和设计经验；至多借鉴开源项目的具体实现细节。

3. 如何设计一个工程用的 Skill

我把它定义为一道 Architecture Discovery Gate（架构发现关卡），流程如下：

1. 理解需求和当前代码库：先了解已有实现、技术栈和限制条件。
2. 判断是否需要外部调研：根据新颖程度、决策风险和现有知识是否充分来决定是否触发。
3. 分三类来源进行调研：
   • 标准与规范：RFC、官方文档
   • 开源生态：代码、版本、维护状况
   • 反面证据：Issues、漏洞、局限
4. 比较候选方案并记录 ADR：在“复用现有方案、自己实现、保持现状”三类选择中，至少比较其中适用的几种，并用 ADR（架构决策记录）留下决策依据。
5. 小规模验证 → 实现 → 独立测试：用实际的工程证据证明方案可行，而不是拿搜索结果当作正确性的证明。

另外：如果你的组织有自己的代码库，那就先搜内部，再搜外部。

如果还想再往前走一步呢？

那就让多个 SubAgent 分头去寻找不同的答案。

但我建议在这里加一条约束：多个 Agent 不能只是搜索同样的关键词，再通过投票决定哪个方案更好。

因为这样得到的结果往往高度重复。

为每个 Agent 分配各自独立的搜索目标，比如，对应上面第 3 步的三类来源：一个查标准与规范，一个查开源生态，一个专门找反面证据。

4. 不要让她们进行无监督的对抗竞争

我做过一个实验。起初，我只是搭了一个让几个 AI 相互对抗、直到达成共识的舞台。

几个实验议题意外地得出了还不错的结论，于是我交给她们一项任务——做一个文档平台，用来对文档进行归类整理并生成报告。

在来自三家不同厂商的顶级模型耗光了三个 20 美元档订阅的周额度之后（我不知道为什么她们要搞这么久，但出于好奇我并没有终止她们的狂欢），她们交给我一个处处防范极端情况的、必须有完美输入才能得到结果的、对每一段数据做多次哈希校验的、用户操作全靠代码指令的、每添加一次内容都要由三家厂商的 Agent 在三个完全隔离的沙箱里以安全模式各自给出意见再投票决定的，对碳基生物极度不友好的贵物。

这个文档平台经历了一种典型的架构膨胀：

• 一个 Agent 提出数据完整性风险，于是增加哈希校验。
• 另一个 Agent 提出单点决策风险，于是增加多 Agent 审批。
• 第三个 Agent 提出审批过程中的安全风险，于是增加隔离机制。
• 最终，系统的每一部分都有了充分的技术理由，却没有人负责回答：用户只是想把文档整理好，为什么要经过这么多关卡？

原因很简单：开发流程中没有任何一个角色有权判断一个风险是否值得解决，以及为了解决它最多可以牺牲什么。

这就形成了一种特殊的古德哈特定律（Goodhart’s Law）现象：当架构正确性、风险覆盖率和审查一致性被当成优化目标时，真正重要的用户价值就会逐渐被挤出优化过程。

回到第一节引用的论文：Research Ideation Skill 在任务开始时促使 Agent 扩大探索空间，每小时触发一次的定时检查清单则用来发现 Agent 是否又陷入了机械调参。论文也承认，这些 Skill 是从 Claude Code 的运行轨迹中总结出来的，效果不一定能完全迁移到其他任务和 Agent 上。

我们更应该从论文中学习的是最小的有效行为干预，而不是模仿一套越来越复杂的人类社会治理体系。

5. 我现在的工作流

写这篇文章时，我自己的 Vibe Coding 工作流大致如下：

0. 产品意图与边界：我要完成什么？哪些事情必须简单？哪些事情先放着不管？
1. 调查：Main Agent 确定项目阶段、现有技术栈与交付范围，同时派出一个 Research SubAgent，搜索现有方案、维护状况与工程经验。
2. 技术方案比较与架构决策：由我和 Main Agent 负责决策，优先满足产品目标，控制依赖与复杂度。
3. 拷打环节：一个 Skeptic SubAgent 负责提出有边界的反对意见。
4. 交付判断：检查操作链路是否走得通，判断能否交付。

所以，在让你的 Agent 写下第一行代码之前，先让它学会去搜索。