作者：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 没有用。

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