AI Agent 输出垃圾？问题在你舍不得烧 Token

作者：Systematic Long Short

编译：深潮 TechFlow

深潮导读：这篇文章的核心论点只有一句话：AI Agent 输出质量和你投入的 Token 数量成正比。

作者不是在泛泛谈理论，而是给出了两个可以今天就开始用的具体方法，并清楚地划定了 Token 堆不出来的边界——「新颖性问题」。

对正在用 Agent 写代码或跑工作流的读者，信息密度和可操作性都很高。

引言

好吧，你得承认这个标题确实挺吸引眼球——但说真的，这不是玩笑。

2023 年，当我们还在用 LLM 跑生产代码的时候，周围的人都惊掉了下巴，因为当时普遍的认知还是 LLM 只能产出没法用的垃圾。但我们知道一件别人没意识到的事：Agent 的输出质量，是你投入 Token 数量的函数。就这么简单。

你自己跑几个实验就能看出来。让 Agent 完成一个复杂的、有些冷门的编程任务——比如说，从头实现一个带约束条件的凸优化算法。先用最低思考档执行；再切到最高思考档，让它 review 自己的代码，看看能发现多少 bug。中档、高档都试一遍。你会直观地看到：bug 数量随着投入的 Token 量单调递减。

这不难理解，对吧？

Token 越多 = 错误越少。你可以把这个逻辑再推进一步，这基本上就是代码 review 产品背后那个（简化过的）核心思路。换一个全新的上下文，投入海量 Token（比如让它逐行解析代码，判断每一行是否有 bug）——这样基本可以抓出绝大多数、乃至全部的 bug。这个过程可以重复十次、一百次，每次都从「不同的角度」审视代码库，你最终能把所有 bug 都挖出来。

「多烧 Token 就能提升 Agent 质量」这个观点，还有一个实证支撑：那些声称能用 Agent 全程写代码直接推上生产的团队，要么是基础模型提供商本身，要么是资金极其充裕的公司。

所以，如果你还在为 Agent 跑不出生产级代码而苦恼——说句直白的，问题出在你身上。或者说，出在你钱包上。

怎么判断我烧的 Token 够不够

我写过一整篇文章说，问题绝对不在你搭的框架（harness），「保持简单」照样能做出优秀的东西，我现在仍然坚持这个观点。你读了那篇，照着做了，但还是对 Agent 的输出大失所望。你给我发了 DM，看到我已读但没回。

这篇，就是回复。

你的 Agent 表现差、解决不了问题，大多数情况下，就是因为你烧的 Token 不够。

解决一个问题需要投入多少 Token，完全取决于这个问题的规模、复杂度和新颖性。

「2+2 等于几？」不需要多少 Token。

「帮我写一个 bot，能扫描 Polymarket 和 Kalshi 之间的所有市场，找出在语义上相似、应该在同一事件前后结算的市场，设定无套利边界，一旦出现套利机会就以低延迟的方式自动交易」——这需要烧一大堆 Token。

我们在实践中发现了一件有意思的事。

如果你投入足够多的 Token 去处理由规模和复杂度引发的问题，Agent 无论如何都能解决。换句话说，如果你想构建一个极度复杂、有很多组件和代码行的东西，只要你往这些问题里砸足够多的 Token，它们最终都能被彻底解决。

这里有一个小但重要的例外。

你的问题不能太新颖。就目前阶段而言，任何数量的 Token 都无法解决「新颖性」问题。足够多的 Token 能把复杂性带来的错误降到零，但无法让 Agent 凭空发明它不知道的东西。

这个结论其实让我们松了口气。

我们花了极大精力，烧了——很多很多非常多——Token，想试试能不能在几乎不给引导的情况下让 Agent 还原出机构投资流程。这部分原因是想搞清楚，我们（作为量化研究员）离被 AI 完全取代还有多少年。结果发现，Agent 根本做不到接近一个像样的机构投资流程。我们认为这部分原因是它们从未见过这种东西——也就是说，机构投资流程在训练数据里根本不存在。

所以，如果你的问题是新颖的，别指望靠堆 Token 来解决。你需要自己引导探索过程。但一旦你确定了实现方案，你就可以放心堆 Token 来执行——无论代码库多大、组件多复杂，都不是问题。

这里有一个简单的启发式原则：Token 预算应当与代码行数成正比地增长。

多烧的 Token 究竟在做什么

在实践中，额外的 Token 通常通过以下几种方式提升 Agent 的工程质量：

让它在同一次尝试中花更多时间推理，有机会自己发现错误逻辑。推理越深入 = 规划越好 = 一次命中的概率越高。

允许它进行多次独立尝试，走不同的解题路径。有些路径比另一些更好。允许不止一次尝试，它就能选出最优的。

类似地，更多的独立规划尝试让它可以放弃弱方向，保留最有希望的。

更多 Token 允许它用全新的上下文来 critique 自己之前的工作，给它一个改进的机会，而不是被卡在某条「推理惯性」里。

当然，还有我最喜欢的一点：更多 Token 意味着它可以用测试和工具来验证。实际运行代码看它是否跑通，是确认答案正确的最可靠方式。

这套逻辑能走通，是因为 Agent 的工程失败不是随机的。几乎总是因为过早选错了路径、没有检查这条路径是否真的走得通（在早期），或者没有足够的预算在发现错误后去恢复和回退。

故事就是这样。Token 字面意义上就是你买来的决策质量。把它想象成研究工作：如果你让一个人当场回答一个难题，答案的质量会随着时间压力增大而下降。

研究，归根结底，是产生「知道答案」这个基础的东西。人类花费生物意义上的时间来产出更好的答案，Agent 则花费更多计算时间来产出更好的答案。

怎么提升你的 Agent

你可能还是半信半疑，但有很多论文支持这一点，说实话，「推理」调节旋钮的存在本身就是你需要的全部证明。

我特别喜欢的一篇论文，研究者用一小批精心策划的推理样本进行训练，然后用一种方法强制让模型在想停下来的时候继续思考——具体做法是在它想停的地方追加「Wait」（等等）。仅此一项，就让某个基准测试从 50%提升到了 57%。

我想说得尽量直白：如果你一直在抱怨 Agent 写的代码差强人意，单次最高思考档对你来说很可能还是不够。

我给你两个非常简单的解决方案。

简单做法一：WAIT（等等）

你今天就能开始做的最简单的事：搭一个自动循环——构建完之后，让 Agent 用全新上下文 review N 次，每次发现问题就修复。

如果你发现这个简单技巧改善了你的 Agent 工程效果，那你至少明白了，你的问题只是 Token 数量的问题——那就来加入烧 Token 俱乐部吧。

简单做法二：VERIFY（验证）

让 Agent 尽早、频繁地验证自己的工作。写测试来证明所选路径确实能跑通。这对高度复杂、深度嵌套的项目特别有用——一个函数可能被下游许多其他函数调用。能在上游抓住错误，能为你节省大量后续的计算时间（Token）。所以如果可以的话，在整个构建过程中到处设置「验证检查点」。

写完一段东西，主 Agent 说搞定了？让第二个 Agent 来验证一遍。不相关的思考流能覆盖系统性偏差的来源。

基本就这些了。关于这个话题我还能写很多，但我觉得只要意识到这两件事并好好落地执行，就能帮你解决 95%的问题。我坚信把简单的事情做到极致，再按需叠加复杂度。

我提到了「新颖性」是靠 Token 无法解决的问题，我想再强调一遍，因为你迟早会碰到这个坑，然后来跟我哭诉说堆 Token 没有用。

当你想解决的问题不在训练集里时，你才是那个真正需要提供解法的人。因此，领域专业知识依然极其重要。