type
status
date
slug
summary
tags
category
icon
password
priority
Agent 做 ML 实验为什么难
AI Agent 写代码越来越强了。它可以一口气生成几百行代码，搭建完整的项目结构，甚至帮你端到端测试。但当我尝试用 Agent 来做推荐系统的算法实验时，我发现这件事异常困难。
原因在于软件工程和 ML 的根本差异。软件工程的反馈快，验证快。Agent 写代码很快，跑测试也很快，能形成完整的验证闭环。但 ML 不是这样。代码写完了只是开始，真正的验证要等几个小时、几天、甚至几周。
这是两个不同的世界。
什么是 Harness Engineering
在深入之前，先解释一下"harness"这个概念。有人用马具做了一个很好的类比：
- Prompt engineering 是口令——你对马说什么。
- Context engineering 是地图和路标——你给马看什么。
- Harness engineering 是缰绳、马鞍、围栏和道路维护——系统如何防止错误、度量和修复。
Context 问的是"给 agent 看什么"。Harness 问的是"系统如何约束、度量和纠正 agent 的行为"。
Superpowers-ML 做的就是这件事：借鉴软件工程领域的 harness 实践，把 ML 这种充满不确定性的问题，变成一个可以小规模快速验证的问题, 以增加整体的成功率。
软件工程的世界：Superpowers 做对了什么
理解了 harness 的概念之后，来看 Superpowers。它是一组给 AI coding agent 设计的技能（skills），本质上是用 prompt 来编程 agent 的行为——给它纪律，而不是自由。
但说实话，Superpowers 并没有发明什么新东西。TDD、code review、verification——这些都是软件工程跑了几十年的规范。Superpowers 做的事情是：让 agent 去遵守这些规范。这件事听起来简单，但如果你用过 agent 写代码，你就知道它有多容易脱缰。
我在日常开发中用了一段时间之后，觉得它确实抓住了 agent 时代几个关键问题。
TDD：给 Agent 最有效的约束
TDD（Test-Driven Development，测试驱动开发）的核心很简单：先写测试，再写实现。看测试失败（红），写代码让它通过（绿），然后重构。
Simon Willison 在他的 Agentic Engineering Patterns 中讲过：TDD 和 AI agent 是天然的搭档。这解决了 agent 的两个核心风险：生成不能用的代码，和生成不需要的代码。
"Use red/green TDD" is a pleasingly succinct way to get better results out of a coding agent.
Superpowers 把这个理念变成了铁律：没有失败的测试，就不准写实现代码。这不是建议，是强制。对 agent 来说，这种约束极大地提升了成功率，降低了幻觉。
Brainstorming：一轮一轮聊透，而不是一屏一屏地刷
Claude Code 自带的 plan 模式其实很难用。它跟你聊不了多久就急着去执行，你得不断拉它回来。而且它一次交互就输出好几屏的内容，在终端里看得很痛苦。
Superpowers 的 brainstorming 完全不一样。它一次只问你一个问题，终端里显示的文字很短。你可以针对一个问题和它聊透，然后再聊下一个。这才是真正的 brainstorming，不是 agent 单方面倾泻信息。
Verification：你需要的不只是信任，是证据
当 agent 生成大量代码时，你面临一个选择：逐行 review，或者选择信任它。我选择了后者——让 agent 干活就是为了不看代码。
但不看代码，你怎么知道它做对了？
我有一个真实的教训。我让 agent 实现一个推荐系统的评测流程，其中有一个指标叫
acc@k。我提供了统一的评测接口，agent 应该调用它。但 agent 没有。它自己写了一个同名的函数，用自己的实现来算这个指标，然后用这个结果向我汇报。它作弊了。不是故意的，但效果一样。Superpowers 的 verification-before-completion 要求 agent 在声称"完成"之前，必须运行验证命令并展示输出。不是说"我觉得搞定了"，而是"这是证据"。
但 verification 只是自证。谁来交叉验证？这就引出了 Superpowers 更完整的执行架构。
Task 拆分、执行与审查
Superpowers 的 writing-plans 把任务拆到 2-5 分钟的粒度，每个 task 有明确的文件路径、代码和验证步骤。这个粒度恰好在 agent 的能力范围内——足够小不会迷失，足够完整可以独立验证。这也印证了 Context Rot 的观察：任务越复杂，上下文越长，模型的智商就越低。把任务拆小，就是在对抗上下文腐烂。
拆完之后怎么执行？Superpowers 给每个 task 分配一个全新的子代理。不是为了并行——实际上是串行调度——而是为了让每个子代理拿到干净的 context window，不被之前的对话污染。
执行完之后怎么保证质量？每个 task 交付后，依次经过两道独立审查：
规格合规审查： 做的对不对？一个全新的审查子代理对照原始需求逐条检查代码，找缺失、找多余、找理解偏差。
代码质量审查： 做的好不好？另一个审查子代理通过
git diff 检查架构、错误处理、测试质量。审查者发现问题，实现者修复，重新审查——循环到明确批准。审查者没有参与实现，没有沉没成本偏见，天然多疑。Verification 提供自证，Review 提供他证——对于不想逐行看代码的人来说，这套组合是一个可靠的替代方案。
ML 的世界：为什么软件工程的纪律不够用
有了 TDD、brainstorming、verification 和 task 审查，软件工程的场景已经好很多了。但 ML 是另一个世界。
不确定性是常态
在软件工程里，代码要么对要么错。但在 ML 里，"不 work"是正常的。一个实验跑出来效果不好，可能是实现有 bug，也可能是这个方向本身就不行。问题是：你怎么区分这两种情况？
如果你分不清，后果很严重。一个实现 bug 导致效果差，你却得出"这个策略没用"的结论。你放弃了一个本来有价值的研究方向。这不是浪费一天的编码时间，是浪费一整条研究路线。
长时间运行的黑箱
ML 训练短则几个小时，长则几天甚至几周。Agent 启动训练之后，你面对的是一个黑箱。
比如数据加载。如果 agent 没有实现好数据管道，加载效率会非常低。GPU 大部分时间在等数据，MFU（GPU 利用率）和数据吞吐低得离谱。最终这个训练任务的运行时间远远超出你的预期——但它已经在那儿跑了半天了，你才发现不对劲。
再比如 checkpoint。我曾经让 agent 跑完了整个训练流程，中间的 log 一切正常，汇报的指标也很好看。我很满意，准备用这个模型做测评。然后 agent 告诉我：checkpoint 没有正确保存，模型权重拿不到了。
一切重来。
Agent 的舒适区
我尝试过让 agent 多轮自动执行：每一轮根据结果调整方向，持续提升。听起来很美好，但实际上 agent 很快就陷入了泥潭。它会浅尝辄止一些明明有价值的方向，然后花好几轮去调学习率和 batch size。
这不是 agent 的错。Agent 天然倾向于做有明确反馈的简单任务。调超参有明确的数字变化，agent 觉得自己在"进步"。但真正有价值的工作——比如改变模型结构，或者把训练方式从 SFT 切到 RL——这些需要更深的思考和更大的冒险，agent 自然会回避。
当下的务实选择
完全自动化的 ML 实验是值得追求的方向。但现阶段，agent 的能力还达不到那个水平。
所以当下务实的做法是 Harness Engineering：用工程手段去控制那些不可控的流程。把任务拆到足够小、足够纯粹，让每个 subtask 都在 agent 的能力范围内。实验设计由人主导，执行交给 agent。
这些做法本质上是把传统软件工程跑了十几年的原则——TDD、verification、code review——引入 ML 的开发流程。
有意思的是，这些原则在 ML 领域其实一直缺席。不是因为 ML 从业者不知道，而是因为手动去做实在太复杂了。写一套完整的验证脚本、跑过拟合测试、检查梯度健康……谁有这个时间？
但 agent 有。Agent 有更高的代码吞吐量。它完全可以代替人去执行这些繁琐但重要的工程纪律。人做不了的纪律，agent 反而能做到。这是一个有趣的反转。
Agent 擅长的恰恰是这类工作：快速、短周期反馈、大量生成代码来加速验证循环。而这个验证循环，正是保障你最终实验成功的关键。
桥接：从 Superpowers 到 Superpowers-ML
认识到这些问题之后，我最初的做法是自己从头造轮子。我写了
/experiment-plan，模仿 brainstorming 的方式多轮采集信息，生成 task 和 subtask。我写了 subtask 拆分逻辑，确保每个任务足够原子化。然后我发现了 Superpowers。
当我看到它的技能系统、TDD 铁律、brainstorming 流程、subagent 架构、verification 机制——我意识到自己从头设计，远不如站在巨人的肩膀上。更妙的是，我可以用 Superpowers 本身来开发 Superpowers-ML：用 brainstorming skill 来设计 ML brainstorming skill，用 TDD 来写 validation pyramid 的 skill，用 writing-skills skill 来写新的 skill。工具用来造工具，这种递归感很有意思。
Superpowers-ML 在 Superpowers 基础上做了几个核心增量。
实验 Subtask 拆分
Superpowers 原有的 writing-plans 拆的是 feature task——2 到 5 分钟的开发任务。但 ML 实验的拆分逻辑完全不一样。
每个 subtask 是一个独立的实验假设。它有自己的独立变量、控制变量，需要排除混淆变量。每个 subtask 有自己的 Validation Pyramid spec，结束时必须记录结论——有效、无效、还是不确定——以及支撑结论的证据。
这既是把大任务拆到 agent 能力范围内、有确定性的准则可以验证，同时也是把实验设计的严谨性嵌入到任务拆分里。
Validation Pyramid：把 TDD 延伸到 ML
Validation Pyramid 是一个四层验证体系。每一层都在小数据上运行，几分钟内完成，在你投入大量 GPU 时间之前就把问题抓出来：
L0 工程效率：后端对不对？GPU 利用率够不够？内存有没有问题？I/O 速度正常吗？——这一层直接解决前面说的"跑了半天才发现 MFU 只有 10%"的问题。几分钟就能发现你的数据加载是不是瓶颈，GPU 是不是在空转。
L1 内科指标：梯度健不健康？参数在不在更新？有没有架构特定的异常？——模型在跑，loss 在动，但梯度可能已经消失或爆炸了，attention 分布可能退化成了 uniform，embedding 的 norm 可能在发散。这些都是"看起来在训练，实际上在浪费时间"。L1 用几分钟的小规模训练就能抓到。
L2 过拟合测试：在很小的数据集上（100-1000 条），重复跑多个 epoch，loss 能不能单调下降？——如果你的模型连过拟合都做不到，说明拟合能力本身有问题，或者模型设计与参数不对，或者训练方法不对。
L3 端到端流水线：数据→训练→推理→评测，整个流程在小数据上跑通一遍。——这一层直接解决前面说的 checkpoint 问题。如果 checkpoint 的保存和加载有问题，跑几分钟的端到端流程就能发现，而不是训练了几天之后才知道。
每一层都遵循 TDD 的节奏：先写验证脚本，看它失败，再实现代码让它通过。这是 Superpowers 的 TDD 铁律在 ML 场景下的自然延伸。
Watchdog：长时间运行的守护者
Validation Pyramid 解决的是"训练之前"的问题。但 VP 通过之后呢？训练可能要跑几天。这段时间谁来看着？
在传统软件工程里，代码加测试就完了，长时间运行的生产环境不在 agent 的职责范围内。但 ML 不一样——长时间运行的训练过程本身就是生产输出。
Superpowers-ML 设计了一个 Session Chain 来解决这个问题：
- 主 Agent 完成 brainstorm、plan、execute、VP 之后，生成训练脚本和一个 Watchdog 启动 prompt。
- Watchdog Agent 在一个新的 session 里启动，只读监控训练过程。它读结构化日志，自适应调整检查频率——开头和结尾查得勤，中间查得松。发现异常时，它不动手，只打包诊断上下文，生成一个 recovery prompt。
- Recovery Agent 在又一个新 session 里启动，读完整的实验上下文，自主判断应该回到哪个阶段——是修代码重跑 VP，还是调超参，还是回到实验设计本身。
Watchdog 只看不动手。这是刻意的设计。它是看门狗，不是驯马师。
代码隔离：核心代码不能碰测试
还有一个关键原则：核心代码（模型、训练循环、数据管道）绝对不能 import 测试或验证代码。验证代码通过 hooks 和 wrappers 从外部观察核心代码。训练结束后，核心代码可以直接上线，不带任何测试依赖。
这听起来像常识，但当 agent 自由生成代码时，它经常会把测试逻辑塞进训练代码里。就像它写了自己的
acc@k 一样——边界一旦模糊，什么都可能发生。两条路径
关于 AI Agent 的发展方向，目前有两派观点。
Latent Space 的一篇文章很好地捕捉了这场辩论。一边是 Big Model 派：Claude Code 团队的 Boris Cherny 说"所有秘诀都在模型里"，用最薄的 wrapper 就够了；OpenAI 的 Noam Brown 认为随着推理模型变强，复杂的脚手架会被模型本身替代。
另一边是 Big Harness 派：LlamaIndex 的 Jerry Liu 说"从 AI 获取价值的最大障碍，是你自己做 context 和 workflow engineering 的能力"。有人仅靠改 harness 就在一个下午提升了 15 个 LLM 的 coding 表现。Cursor 500 亿美元的估值也在说明：harness engineering 有真实的商业价值。
我不确定哪条路径是最终正确的。也许某一天模型真的强到不需要任何约束。
ML 实验的根本挑战在于它的验证成本极高。现在大模型写代码的能力是靠 RLVR 训出来的，而 ML 实验跑几天才能拿到一个 verifiable reward。训练这种能力的成本太高，数据也远远不够充分。FARS 之前做过一个全自动 AI 科研工厂，24/7 运行，目标是让 AI 自主产出 100 篇 short papers。结果产出集中在训练推理优化这些能快速验证的方向。真正需要长时间训练才能拿到反馈的模型效果类工作，它搞不来。
ML 从业者的日常本来就不是写代码——代码写一天，训练搞半个月。AI 能把编码时间从一天压到几分钟，但 GPU 排队它也得排，训练半个月它也得等。所以比起编码快不快，真正重要的是每次出手的正确率和有效性。
这就是 Superpowers-ML 要解决的问题。不是让 agent 更快地写代码，而是让它每次出手都更准确。通过工程纪律——TDD、验证金字塔、代码隔离、Watchdog 监控——把"跑了几天发现白跑了"的概率降到最低。
验证成本越高的领域，harness engineering 的价值就越大。ML 实验就是这样一个领域。