一开始我差点把 Ryan Stevens 这篇扫过去。标题平淡，平台是 dev.to，作者也不是什么学术明星。直到看见他把两个数字放在同一张表里：一个任务，纯靠通用技能，通过率 0%；塞进一组可复用的工作流记忆，通过率直接 100%。另一个任务，本来 75%，因为混入上个月的具体操作细节，掉到 25%。同一套记忆系统，一个动作是对的，一个动作是错的，但幅度都大到不该忽略。这堵墙后面有东西了。
我不太想把它概括成“做 agent 需要评测”。这种话谁都说过，说了等于没说。这篇文章真正在说的是，把 agent 开发当成 ML 开发来对待：先有数据集，再有训练循环，最后才是模型——顺序不对，你就只是在搭一个会动的 demo。而且 agent 这行最麻烦的地方在于，它没有天然的 ground truth。你写个分类器，label 是现成的；但你要 agent 去结账、去对账、去跨系统同步，什么算对、什么算错，得你自己先把它钉死。很多人就是在这里偷懒了，用直觉代替流程，上线翻车。
他拿 Ramp Stack 做例子。这个例子不炫但足够实在。他们不是先写代码，而是先坐下来，把记账工作拆成四类：对账、数据录入、差异分析、日程与应计。每类工作的人工流程、判断标准、失败模式，先写明白。拿应付账款对账来说：未付账单总共 3,500，分类账显示 3,000，代理要找出这 500 的缺口，然后记录更正。这个任务放在传统 bench 上不算难，但它有一个很微妙的点——不是“回答问题”，而是“介入一个状态并留下正确的新状态”。你没理解人工流程，就设计不出这种任务来。这跟看一个 LLM 能不能答对 openbook 题，完全不是一个层次。
接着就是这个评测的统一结构：业务数据进数据库，代理通过工具处理这些状态，评测者再对输出打分。这话听起来像正确的废话，但它是全文的承重墙。因为有了这个结构，评测才不再是“我换个 prompt 试试效果”，而是“我在一个可复现的环境里，让一个 agent 跑一段流程，然后看结果”。这个结构把 agent 评测从模型评估里剥出来了：你要评的不是孤立的一句话，而是它和工具、ERP 状态交互之后产生的结果。
但这里有个非常现实的坑：产品上线前，你哪来的真实业务数据？答案是造。作者造了六个合成企业，叫 worlds。其中一个世界观是一个家居用品 DTC 品牌，通过 Shopify、亚马逊和批发渠道卖货，配有完整账簿、仿真交易、杂乱的 Excel 文件。重点不是仿真，是杂乱。太干净的数据会让代理在离线环境里分数很高，一上线就被真实世界的脏数据打回原形。这跟训练数据分布和测试分布不一致是同一类问题，但在 agent 场景里更隐蔽，因为“脏”不是随机噪声，是那种你没想到过、真实用户会甩给你的结构性混乱。你要是拿一堆干净数据喂出来的判断，基本等于在实验室里培养温室花朵。
评测案例四部分：任务请求、代理可访问的合成 ERP 与业务数据、代理执行步骤的轨迹、评分规则。评分规则这一栏，他写了一句我特别认同：由领域专家编写，因为他们更清楚真实复核者会拒绝什么。这个细节的意义，比它看起来大得多。因为评分规则本质上是在给 agent 系统定义“好”的含义。你找不懂业务的人来写，写出来的就是“有没有提到这个关键词”，而不是“在真实结账流程里，这个操作会不会被会计打回来”。六项标准里过四项，如果只是 pass/fail，你就只知道它挂了；但如果是 rubric，你就能看到它漏了哪两项。这个差值，才是你下一个迭代该改的位置。这是真金白银的信息量，不是美化表格。
写到这里，我猜很多人会以为，有了评测就该去选最好的模型。但这篇文章打了一记回马枪：选模型只是评测的第一个用途，收益最大的环节其实是调运行框架——技能、工具、基础设施，用更低的成本和延迟拿到不差的结果。这其实是在说，base 模型的能力是给定的，你能动的是外层工程；评测让你能调这三个东西，而且用数据说话，而不是感觉。
然后才是真正让我停下来看的数据：技能消融。八个技能砍到四个，平均分提高 2.8；部分技能是负贡献；没有一个技能在所有世界上都最优。这很反直觉——多几个技能不是应该更稳吗？实际是有些技能互相打架、有些技能给模型增加了错误的路标。还有一条，把最大的电子表格技能压缩 61%，质量基本不变，每月省约 3 万。这是在说，工程师的直觉“加技能总会帮上忙”是错的，真正有价值的是“表面区域缩小”。
但这些都不是最狠的。最狠的是记忆评测。
我们通常不测记忆，不是因为不重要，而是因为很难在静态的单轮任务里测——记忆需要时间推进。你问 agent 一个任务，它从零开始，用不着记什么；但你让它跨月结账，它就必须记住上个月的某些事，同时忘掉另一些。作者干脆做了一个滚动世界：同一个企业往前走一个月，agent 完成当月结账、写下一段经验，然后在下月任务里被重新评分。这相当于给评测装了一个时间轴，把“状态”这个维度暴露出来。这个设计非常妙，也非常昂贵。
记忆规则，他说得特别克制：记忆应保留业务如何运作，而金额等当期数据必须重新获取。这句话我读了半天，越读越觉得它重。很多人对 agent 记忆的想象，是“把之前的所有上下文存起来”，但真实系统里，你不可能也不应该存所有。业务运作是结构，值得存；当期数字是状态，必须每次从数据源重新读。你要存错了，不是没帮助，是负帮助。证据就是开头那组数字：保留可复用工作流记忆，某项任务通过率从 0% 到 100%；混入上月具体操作细节，另一项任务从 75% 掉到 25%。这个对比比任何理论都像刀子：前者是完全对，后者是真的会坏。
他们的操作，是从历史轨迹里提炼记忆、剔除各期间专属金额。这样处理之后，平均得分比只靠技能高 5.7 分。别小看这 5.7，是在同一个评测环境里，纯记忆这个增量带来的稳健提升。而且这两个记忆变体，是很多团队会踩的两个坑：要么不存任何流程，每次从头猜；要么把上一次运行的所有细节原样塞进去，变成记忆污染。前者失败，是因为丢掉结构；后者失败，是因为拿过期状态冒充结构化经验。
说到这，我想把这篇东西拉回地面。对我们这些实际做 agent 的人来说，这篇文章给的最重要的不是一个新技巧，而是一套纪律。你手里有一个会自己调工具的 agent 系统，你觉得它还行，但每次上线都会做错一些事。你现在的选择可能是：继续调 prompt、换个模型、加几个 skill。但文章告诉你，最该做的可能是先把你人工流程写出来，造几个脏脏的 worlds，写一套专家 rubric，然后每一次改动都跑一致的那几个任务。这个做法笨重，但它是把你从“拍脑袋”拉到“看得见差距”的唯一通道。
我不是说每个人都要做到六个合成世界、滚动月份。但至少可以从一个最小版本开始：一个真实业务里的任务，一个状态明确的小闭环，一个由懂行业的人写的评分表。然后固定下来，每次改动都重新跑。没有这一步，你对自己的系统到底有没有变好，其实是一无所知。你不是在做工程，你是在玩胶水。
这篇文章我不打算给“方法论清单”的收尾，那太干净了。回到开头那两个数字：记忆系统里存什么，可以是 0 和 100 的差别，也可以是 75 和 25 的差别。你不能指望 prompt 替你把这件事想清楚。现在最值得写的不是下一段胶水代码，而是你那个业务的准确描述。这墙我替你拆到这儿，剩下的你得自己走。