Token 应该有自己的工作

大家给 agent 系统调优的时候，几乎只有一个杠杆：加预算。想让任务完成得更好，就让 agent 多花点 token，或者换一个更贵的模型。Anthropic 平台工程负责人 Katelyn Lesse 和平台产品负责人 Angela Jiang 在 AI Engineer World’s Fair 主舞台上，把这个习惯动作背后的假设挑明了：它其实一直藏着一个没被说出口的前提，所有 token 都是可以互换的算力，花在哪儿都一样。她们想验证的问题很直接：这个假设站得住吗？

原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 01:56:51 开始）

Token 也能分工

她们给的答案是：给 token 分配工作。一个 agent 系统里如果所有 token 只干一件事，也就是执行，那确实是把它们当成同质化预算在花。但拿出一部分 token 让它们干别的活，情况就不一样了。两位讲者提出三种具体分工，称之为”策略”（strategy）：

advising（顾问）。执行者（executor）照常干活，但可以随时向顾问（adviser）求助，判断下一步走得对不对。举的例子是销售场景：一个理想的销售 agent 应该能主动提醒销售代表，某次跟进已经逾期，或者某笔交易正在停滞。顾问角色的活，就是持续检查各个环节是不是真的在正常运转。

grading（评分）。如果能提前把”好”定义成一份 rubric，执行者每完成一次任务，就交给评分者（grader）按 rubric 打分。做得好就通过，不够好就退回去重试。客服场景的例子是退款判断：公司通常有明确的退款标准，评分者的活，就是拿这份标准去核对客服 agent 的判断对不对，判断不对就让它再来一次。

dreaming（反思）是三种策略里最不像”干活”、最像”复盘”的一种。反思者（dreamer）不参与当次任务，只在执行者干完活之后，回头翻执行者的工作记录和对话过程（transcript），把里面能提炼出的经验写进记忆（memory），留给下一轮执行者去读。讲者拿招聘场景举例：候选人合不合适，往往要靠大量带反馈的互动才能判断准，反思者把这些互动沉淀成经验，下一轮筛选就会越来越准。

固定预算下，分工比加钱更管用

三种策略讲清楚之后，两位讲者拿一批金融分析类任务做基准测试，模拟一个真实的金融分析师完成同一批任务会表现如何。对照组是单纯执行（execute）。

第一轮实验很朴素：一次性（one-shot）跑完各个策略，让每种策略自己决定要花多少 token。结果 execute 只有 15% 准确率，而且它自己只肯花 3.9 万个 token；策略越复杂，自己选择花的预算也越大，dreaming 一路花到 60 万 token，准确率确实很高。但这轮对比说明不了太多。执行策略压根没打算多花钱，复杂策略天然花得多，预算不统一，谈不上公平比较。

于是她们把预算锁死：所有策略都用 dreaming 那次跑出来的 60 万 token 上限，重新跑一遍。这时候执行策略的准确率从 15% 涨到 76%，顾问和评分策略也从 60% 出头涨到接近 90%。如果 token 真的可以互换，同样的预算应该拿到同样的分数。但同一个预算下，execute 是 76 分，advise 是 89 分，13 分的差距没有消失，也没有大到让人拍案惊奇——它证明的是一件更朴素的事：“怎么分配 token”本身就是一个独立的杠杆，不完全能被”花多少”取代。

换一套严格的评分标准，差距被放大

接下来她们换了个更贴近真实业务的视角。金融分析这类任务里，80% 准确率听起来不错，但对一个真实的分析师没什么用。利润表算错一个数字，要么自己重新算一遍，要么把任务再跑一次，80% 正确和不正确其实没本质区别。所以她们把评分标准换成”要么 100% 正确算通过，差一点都算失败”。

在这套严格标准下，execute 的通过率是 42%，更复杂的策略最高能到 75%。她们还进一步算了一笔真实成本账：execute 通过率 42%，意味着平均要跑大约 3 次才能撞上一次满分答案；每次都要烧掉 60 万 token 的预算，算下来拿到一个真正能用的答案，实际要花掉约 180 万 token。相比之下，advise 和 grade 这两种策略虽然单次预算一样高，但因为通过率更高，总账反而更省——用更少的总 token 换到一个真正可用的结果。

这笔账带出的判断是：不同业务该在乎的东西不一样。如果最在意 token 花费，advising 更划算；如果更在意结果可靠、不能容忍失败，应该往 grading 或 dreaming 靠。两位讲者的收束很直接：token 不是同质化的燃料，给它们分配不同的工作、组合不同的策略，同一个预算下能拿到明显更好的结果。

这场分享在当天议程里的位置

这场排在 Harness Engineering 赛道，从一个比”agent 靠不靠谱”更底层的角度切入了同一个问题。大会上很多分享都在讨论怎么让 agent 更可靠，这场分享的说法是：可靠程度很大一部分取决于有没有把 token 的角色分好，而不是简单地砸预算。两位讲者展示的架构也印证了这一点：cloud managed agents 底层是单个 agent 的执行架构，上面再叠一层”meta harness”，专门负责多 agent 编排。执行者、顾问、评分者、反思者，本质上都是这层编排逻辑里可以自由组合的角色，讲者甚至现场演示了往里加一个新角色只是个组合问题。

我的延伸

这场分享的框架和最近几周读到的几篇 loop engineering 材料能对上号。Derek Nee 反对单一巨型 agent 那条推文讲的是组织层面的分工：不能靠一个拥有所有工具却没有责任感的 agent 运营公司，得用范围界定的工作者加证明账本。这次的 advise/grade/dream 三分工，是同一个反对”一个模型做一切”的判断，只是下沉到了单次任务里 token 的粒度。字节洪定坤那场演讲用 900 次对照实验证明，冻结模型和框架、只补 Harness 基建，可交付性能从 40~60 分跳到 80 分；这次冻结预算、只变策略，通过率从 42% 到 75%，是同一套”控制变量做实验”的方法论，结论也一致：怎么做比砸多少更决定结果。

grading 策略跟 sairahul1 那篇 loop engineering 综述里”subagent 让 maker 不等于 checker”的说法几乎是一回事——执行者和评分者分开，是防止 agent 自己给自己打高分的老办法，这次算是拿到了一组具体数字。dreaming 则很像 gabrielchua 那篇讲 Codex 内外循环的做法：outer loop 从人工审查里学东西，把批准过的经验写进一份 markdown，供下一次 inner loop 读取。不同的是，那篇文章特别强调”diff 不会自动变成教训，需要人筛选”——这提醒了一件这场分享没细讲的事：dreamer 写进 memory 的东西，如果没有人或某种机制把关，也可能把偶然的错误当成经验固化下去。

如果要落到具体判断：给 agent 系统调预算之前，先想清楚任务的错误容忍度是不是接近于零。容忍度低的场景，先加一个评分者角色，比无脑加预算更值。

原视频观看：https://www.youtube.com/watch?v=I2cbIws9j10