从 Spec 到损失函数：真正会用 AI Agent 的人，已经在设计循环

导读：本文介绍了 AI agent 使用“损失函数开发”（LFD）与 /goal 循环的实战经验，强调通过优化目标而非固定规格，能让 agent 在 30 小时内逆向工程产品核心并实现 50 倍性能提升。

作者分析了 agent 多次“作弊”优化评估集的失败案例，提出构建良好损失函数需包含大目标、盲测约束、测量工具和强制熵，避免局部最优并推动真正创新。

作者：Elvis Sun（@elvissun）是 AI agent 开发专家。他公开分享 LFD（损失函数开发）与 /goal 循环的实践经验，强调设计目标与约束让 AI agent 高效优化，避免作弊。已开源相关技能。

99% 的人都把 /goal 和循环用错了。

他们听到的噱头是“长时间运行的循环会提示自治智能体（long-running loops prompting autonomous agent）”：把任务丢给它，离开，回来就有可工作的代码。

但顶尖的 agentic 工程师在过去 6 个月里已经不靠 /goal 做到了这一点，也就是 GPT-5.2 和 Opus 4.5 发布以后。这叫 harness engineering + spec-driven development：

1. 为智能体搭建一个能观察问题的 harness
2. 写一份紧凑的 spec，包含所有测试用例
3. 让 Codex 或 Claude Code 无人值守地循环，直到满足每一项要求

我经常在夜里启动这种任务，一次跑 2 到 5 小时。4 月有一次，它啃掉了我们 Vercel monorepo 里的一个 Turbo build-cache bug，早上起来已经全绿。其实并不需要 /goal。

4 月 11 日 Elvis

我再说一次，因为我一直看到有人用错：只要把一个带着正确 harness 的智能体丢进循环里，你可以解决任何工程问题。Codex 刚刚 one-shot 了我们的 turbo cache 修复，因为我给了它像团队里的真实开发者一样调试所需的一切。使用老方法需要8小时。

那 /goal 到底是做什么的？

下面是一条单独的提示词，在我离开期间完成的事情：

• 约 30 小时，6,300 行代码，爬取 92k 页面，API 花费 40 美元
• 克隆另一个产品的核心循环，从零反向工程出完整架构
• 在同样的查询上，我们版本的输出比参考产品好约 50 倍。（这是一个新的数据层，会支撑 newsjack.sh^[1]，也就是我一直在做的开源 news-intel skills）

秘密是 loss function development（LFD）：给智能体的核心输入从“要构建的 spec”变成“要优化逼近的目标”。

6 月 8 日 Peter Steinberger

每月提醒一次：你不该再给 coding agents 写提示词了。你应该设计提示 agents 的循环。

You shouldn’t be prompting coding agents anymore, you should be designing loops that prompt your agents.

这是 Peter 那条推文的一个具体落地版本。

spec-driven development 里的 spec，现在变成起点，不再是终点。

我试了好几轮才把这件事做对。但这里是完整打法。不过我们得先从它一开始有多糟糕讲起，这样你才能理解该怎么设计这些 /goals。

智能体作弊了 3 次。

一切都从我一贯的做法开始：写 spec。

我只是把 codex 指向另一个产品的公开网站，问它“我们怎么自己构建这个？”。30 分钟后，它给出了一套完整的系统设计和测试用例，也就是 spec。

但这一次，我试了一个不同的提示词。

“/goal implement until your output matches theirs exactly”

然后发生了这些：

循环 1（5 分钟）

智能体拿到了 eval set，生成了与之对应的 seed data，然后 5 分钟内宣布胜利。

“100%” recall，泛化能力为零。一个只能找到我交给它的那 30 个东西的搜索引擎，lol。

修复 → 让它失明。 运行期间隐藏 eval，只在评分时揭示，并给出逐项 miss list。

循环 2（20 分钟），盲测，30 个条目。

我把 eval set 对智能体隐藏起来，但它通过 miss 学会了作弊。每一个“你没找到 X”都会变成下一轮的关键词。几轮之后，它用了刚好 30 个关键词，每个条目一个，然后又“赢了”。

修复 → 扩大 eval set。 用几百个条目评分，多到无法枚举。

循环 3（30 分钟），盲测，200 个条目。

把新 eval set 加到 200 个条目之后，智能体又作弊了。

有意思的是，它还是在枚举。关键词列表膨胀到几百个，每个词都是为下一个 miss 精确准备的诱饵。

三轮，三次作弊。

那一刻我明白了：智能体只是在优化。

作弊不是智能体的 bug。bug 在我的目标里：我告诉它要去哪里，却把所有捷径都敞开了。

每一条你没有封住的廉价路径，都会成为优化器全力冲刺的方向。而我的初始目标漏掉了所有围栏。

循环 4（30 小时），盲测，200 个条目，硬限制。

于是我开始封锁方向。限制关键词列表，隐藏 eval，扩大日期范围。每个修复都关掉一条廉价路径，直到剩下唯一能让数字继续上升的方向，就是真正把任务做得更好。

它停止作弊了。

然后它开始跑。约 30 小时计算，爬取 92k 页面，约 40 美元 token 成本，6,300 行代码。

结果我们参考的产品只是地板，不是天花板：在同样的查询上，我们最终浮现出了 约 50 倍的结果。

（好奇的人可以看这里的完整过程和凭据）

5 月 21 日 Elvis

codex 真的太疯狂了。如果你觉得前端克隆已经很夸张，看看这个：我刚把 codex 指向另一个产品，30 分钟后拿到了它的架构、数据模型、prompts，还有成本估算。378 行重建计划。最疯狂的是，现在我可以一行提示词搞定：

"/goal implement until your output matches theirs exactly"

Loss function development（LFD），一个好损失函数的结构

大多数人想构建产品时，都是用 agents 在几个小时内从零走到发布。

但真正的难点在后面，也就是长尾。 spec 从没想过的边缘情况，只会在生产环境里一个错误日志接一个错误日志地冒出来。你逐个修。没有被日志捕获的情况会由用户报告，而这是发现 bug 最昂贵的方式。

我已经自动化了其中便宜的一端。我的 OpenClaw agent Zoe 每天盯着错误日志，新错误一出现就启动 Codex 并创建 PR，这个循环基本已经压到很紧了。（完整设置记录在这里^[2]）

长尾仍然需要几个月。这就是为什么即使 agents 在干活，构建一个好产品仍然需要时间。

LFD 会快进这条长尾。如果你能一开始就拿到真实的 expected-output examples，也就是大规模意义上的“好结果长什么样”，你就可以在发布前做 soak：几百个边缘情况在一次优化运行里打到智能体身上，而不是等一个季度的 bug report 慢慢滴下来。它突然变得可行，是因为对越来越多的问题来说，这些 examples 就公开摆在那里。

Spec-driven development：

构建这个。让测试通过。

Loss-function development：

构建这个。让测试通过。然后针对这 1,000 个 eval cases 继续迭代。

测试套件是有限的，一旦全绿就结束。一个 1,000 case 的 eval，如果达到 95%，它就是一个你要继续下降逼近的目标，除非达标，否则没有出口。这很重要，因为智能体会做出几百个你永远看不到的决策，而每一个决策都需要一个参照系来判断。如果你没有写目标，智能体会自己选一个。就像第 1 到第 3 轮展示的那样，它会选最便宜、最容易满足的东西。

损失函数比 eval 更大。它有 4 个部分：目标、约束、仪表、强制熵。四块。

1. 目标

• 足够大，让枚举不划算。 28 个条目的 eval 一轮就被记住了。越多越好。
• 不要让智能体看到答案 key。 Eval data 只用于事后评分。如果智能体能在运行期间看到答案，它就会找到偷看的办法。

2. 约束

智能体被允许做什么，以及不允许做什么。

• 时间是智能体永远会忘掉的约束。 Agents 没有时间感。它们会为了 2% 的提升磨 10 个小时，因为指标名义上还在动。但 2 小时内完成的 80% 方案，胜过 30 天后完成的 100% 方案。解决办法：设置 wall-clock budget。
• 钱。 对每一次付费调用设置硬上限：crawler credits、LLM spend，以及一次性 key 的总美元上限。
• 接触面。 所有 providers、允许的 models、并发上限。把智能体沙盒到你只希望它触碰的东西里。
• 方法论。 是否允许 LLM analysis，还是只能用 deterministic logic？智能体能访问哪些数据源？明确写出来。

3. 仪表（harness）

没有仪表的约束只是一种感觉，智能体会很愉快地违反它，因为它看不出自己正在违反。对上面的每一个约束，都给智能体提供一个 CLI command 来检查它。

• 以正确分辨率测量目标。 谨慎选择目标仪表。真实例子：一个幼稚的”让 LLM 给两张截图打分”的 judge，会批准有 12px 间距错误的 UI clone，因为 LLM 其实看不见图像，它会把图像转成 embedding，再比较 embedding。所以如果你想要 pixel perfect 的 UI clones，就给你的智能体一个 pixel-diff tool。然后 /goal 直到 pixel diff 为 0。
• 时间核算。 给每次运行和每一步都打 timestamp。智能体应该知道每一步花了多久，总 wall-clock elapsed 是多少。时间是一等仪表，不是脚注。
• Provider budget。 “我们现在在 crawlers 上烧了多少钱？”应该是一条命令，而不是猜测。追踪剩余 scrape credits、本轮 burn、累计 burn，以及下一批付费调用前的预计 burn。
• LLM spend。 给它一个 LLM API key 用在 data-plane 上，可以简化很多逻辑。但智能体应该负责任地花钱，而前提是先知道自己实际花了多少。
• Codex Usage。 这一项有点 meta。循环应该有自我意识：我在这次优化上花了多少 tokens？这有助于知道当前优化步骤的梯度。

模式就是那句老话：你看不见的东西，就无法优化。

如果你刚开始跑这些循环，不要一启动就离开。先陪它跑第一轮。观察它触碰了什么。确认你搭的 harness 确实被正确使用。然后再去睡觉。（并且试着别一直想着醒来会看到什么）

4. 强制熵

为什么强制熵重要：每个循环都会从上一轮的完整上下文继续。模型不是重新开始，它会读取自己之前上百个决策，以及到目前为止有效的梯度。

在 /goal 循环里，命中局部最大值是默认状态。 没有明确的一脚踢开，智能体会继续沿着同一座山往上走，而“同一座山”就是它停止改进时刚好所在的位置。

举个例子，如果一个小旋钮能让结果提升 0.1%，智能体会一直拧那个旋钮，即使还有 1000 个其他旋钮可以试。

熵必须被显式强制进入运行过程，因为模型不会主动引入它：

• 每轮都做过拟合反思。 我是在构建更通用的方案，还是在记忆 eval？如果是在记忆，下一次改动必须移除一个 eval-shaped artifact（限制列表、隐藏特征、扩大 eval、拒绝 seed），而不是再增加一个。
• 停滞时强制熵。 如果上一轮没有推动指标，下一轮不能是“同一个想法，更用力”。模型必须做一次真正突破性的跳跃。“think outside the box” 是个好提示词，可以阻止智能体只是把同一个旋钮拧得更狠。
• 保留迭代日志。 让智能体记录假设、预期失败模式、每一步的诊断，这样它可以回头看，并跨越 compactions 做反思。

Meta-Meta-Prompt

一开始这些 goals 是我自己写的，但我很快意识到，这也是 agents 该做的工作。

所以我写了一个 skill，用来生成这类目标，帮助跑一次好的 loss-function-development。

现在开源在这里：

https://github.com/elvisun/loss-function-development^[3]

/lfd-design 用来生成 harness 和 goal

一路向下的梯度下降：两个循环

退一步看，这一路都是梯度下降。

内循环是智能体：写代码，跑测试，修复。短周期，快速反馈，单一目标，让测试通过。这是开发者的内循环，而 spec-driven development 就是运行它的方法。Coding agents 已经把它自动化了。

外循环是 /goal：跨越许多周期，把整个系统推向一个 outcome metric，发布、测量、改方向、下降。长周期，稀疏反馈。这原本是产品团队的循环，也就是几个月的 ship-measure-iterate soak，现在被压缩进一次运行里。

两个循环现在都已经自动化。剩下需要你做的，是定义损失函数，也就是 /goal 到底应该优化什么，以及应该以什么方式优化。

你在蒸馏一个产品，或者任何留下公开产物的东西

换个视角看，这本质上是蒸馏，只是从 training-time 移到了 prompt-time。DeepSeek、Kimi、Minimax 这一线就是这样缩小了与 GPT 和 Claude 的大部分差距：用别人家的输出训练你的模型，直到你的模型能复现它们。

但现在你不必蒸馏一个模型。你可以用 /goal 和 LFD，对任何公开可找到的 artifact 进行蒸馏拟合，它不检查内部，也不需要检查内部。

重点是公开这个词。蒸馏别人在 ToS 限制下、登录墙后、付费墙后的输出，并不合理。但公开发布的东西，也就是一家公司为了赢得客户而 ship 出来的输出，一直都可以被学习。这部分并不新，它是软件里最古老的招数。新的地方在于，现在这件事很便宜，而且几小时就能完成，不再需要几个月。

退一步看，更大的变化是：只要存在 information symmetry，执行成本就会坍缩到接近 0。也就是说，当输出是公开的，每个人都能看到“好”长什么样，任何人都可以用 40 美元在一个周末把它蒸馏回来。

所以这里出现了一个越来越有价值的新护城河：information asymmetry。

那个典型的开源公司已经先眨眼了。2026 年 4 月，cal.com^[4]（500 万美元 ARR）把生产代码转为私有，并且关闭了开源^[5]。他们给出的理由，读起来几乎就是这篇文章的摘要：在 AI-driven security threats 的时代，你不能把 source 留在智能体读得到的地方。

“/goal read cal.com^[4] source code and enumerate its attack surface until something works”

这种攻击太危险，也太容易执行。

一个身份核心就是”open source”的公司，在 2026 年决定开放已经变成负担。这已经说明了一切。

在软件的整个历史里，“我们构建了它”曾经就是护城河。

那个时代正在结束。

下一个时代属于那些拥有 artifact 从未包含之物的人：别人无法评分的 eval set。你的用户真正踩到的边缘情况清单。你私下测量的 ground truth。谁拥有竞争对手的智能体看不到的目标，谁就是唯一一个能让自己的循环继续下降的人。

产品现在只是一个周末。

去构建那个周末无法触碰的 eval。

参考阅读

• Claude Fable 5 发布：AI 工作流的关键正在转向 Loop 循环
• AI 真的跑进业务了吗？GIAC 2026 深圳站 15 大专题全日程来了
• 为什么 2026 年真正重要的是 Harness Engineering？
• 从 Harness 到动态工作流：Claude Code 多智能体任务编排的新范式