技能砍一半反而涨 2.8 分：Ramp Stack 记账 Agent 的端到端评估实战
技能砍一半反而涨 2.8 分：Ramp Stack 记账 Agent 的端到端评估实战
你上一次改 prompt 之后，怎么判断 Agent 是变好了还是变坏了？
给 Agent 加功能容易，砍功能难。多数团队凭感觉做决定：新增一个 skill，试几个 case，看起来没问题就上线。Ramp 的 Stack 团队把这件事反着做——先造一个能反复跑的评估环境，再让数据决定每个技能的去留。结果有点反直觉：8 个 skill 砍到 4 个，均分涨了 2.8 分；最大的一个 skill 压缩 61%，质量基本没动，每个月省下约 3 万美元。
Stack 是 Ramp 推出的 AI 原生会计套件，核心是一个负责结账（book close）的 Agent：核对交易、对账、做调整分录、出报表。工程师 Ryan Stevens 写了两篇文章讲这套评估体系怎么搭、怎么用，一篇发在 Ramp 工程博客，一篇最近发在 dev.to。本文把两份材料合在一起拆解，顺便看看哪些流行技巧在数据面前没扛住。
本文提纲
- 先懂业务，再谈 Agent
- Worlds：给 Agent 造一家假公司
- 评估四要素：Task、World、Trajectory、Score
- 用评估做决策：两个热门思路没扛住
- Skill 消融与压缩：8 个砍到 4 个
- 记忆怎么测：roll-forward worlds
- 两份报告的数字差，恰好说明评估该怎么读
一、先懂业务，再谈 Agent
Ryan 把"最大的错误"放在第一条：自动化的流程，自己都没搞懂。写代码之前，你得能说清人类是怎么干这份活的。
Ramp Stack 要自动化的是记账。他们先把活儿分成四类：Reconciliation（对账）负责把两个来源的数据对齐、找出差异并解释或修正；Data Entry（数据录入）负责过账交易、日记账分录和供应商账单；Variance Analysis（差异分析）拿实际数对比预算或上期，解释驱动因素；Schedules and Accruals（底稿与应计）编制支持性底稿、计算应计项目。分类还有个隐藏好处：评估时四类任务均衡分布，Agent 在哪类工作上弱，一眼就能看出来。
每类再往下拆步骤。以应付账款对账为例：会计先拉出未付账单和 AP 明细账，放进表格逐条核对，对不上的逐一排查。账单合计 3,500 美元，台账只有 3,000 美元——工作就是找到那笔丢失的 500 美元账单并记录调整。拆出来的每一步，既是 Agent 要做的事，也是评估要检查的点。
二、Worlds：给 Agent 造一家假公司
为什么不直接跟 design partners 迭代？Ramp 试过传统路径，发现两个坑：会计流程因客户而异，很容易过拟合到单一客户的环境；反馈回路又慢又模糊，改了 prompt 或工具，要等用户再撞上同一个 case，才能推断改动有没有用。
基准相当于 ML 工程师手里的离线数据集：世界的一个静态快照，可以在客户上手之前反复爬坡，上线之后还能抓回归。
端到端评估在哪个阶段都长一个样：业务数据灌进数据库，Agent 通过工具操作这些状态，最后给产出打分。上线之前没有真实数据，只能模拟。Ramp 的答案是合成公司，他们叫 worlds。比如其中一家：DTC 家居品牌，通过 Shopify、Amazon 和批发三条渠道卖货，配了一整套账目、逼真的交易流水和乱糟糟的 Excel 文件。乱是故意的。按 Ryan 的说法，团队经常把测试数据做得太干净，离线看着挺好，碰上真实用户就露馅。
原始基准一共 8 个 worlds：6 个标准 world，外加 2 个 roll-forward world（讲记忆时会说它）。行业刻意拉得很开：
| World | 类型 | 业务 | 会计复杂点 | 任务数 | 评分标准数 |
|---|---|---|---|---|---|
| world_1 | 标准 | DTC 电商品牌 | Shopify + Amazon 多渠道收入、平台费对账、库存 COGS | 28 | 601 |
| world_2 | 标准 | B2B SaaS | 递延收入确认、Stripe 对账、股权激励摊销 | 34 | 488 |
| world_3 | 标准 | 中型物流公司 | 三实体 QBO 架构、关联往来对账、合并报表抵销 | 28 | 477 |
| world_4 | 标准 | 多址医疗机构 | 5 家保险付款方的 AR、合同调整与拒付管理 | 29 | 478 |
| world_5 | 标准 | 建筑公司 | 完工百分比法收入确认、WIP/POC 底稿、AIA G702/G703 | 28 | 284 |
| world_6 | 标准 | 餐饮集团 | 三门店 POS 日结对账、小费申报、礼品卡负债 | 30 | 373 |
| world_5_2 | 滚动 | 建筑公司（下一期） | 测试 WIP/POC 流程能否平移、不带走过期数字 | 30 | 353 |
| world_6_2 | 滚动 | 餐饮集团（下一期） | 测试 POS 对账流程能否平移 | 30 | 415 |
这一片基准共 237 个任务、3,469 条评分标准。
三、评估四要素：Task、World、Trajectory、Score
每个评估用例由四部分组成：
| 要素 | 内容 |
|---|---|
| Task | 任务请求，比如"对齐我们 2025 年 Q4 的应付账款和账单" |
| World | Agent 可访问的合成 ERP 与业务数据 |
| Trajectory | Agent 走的路径：读账单、匹配付款、排查差异 |
| Score | 会计专家写的评分标准，由 LLM judge 按最终产出打分 |
graph LR
A["Synthetic business
(world: ERP state + files)"] --> B["Agent
(model + skills + tools + memory)"]
B --> C["Trajectory
(tool calls and steps)"]
C --> D["Final output"]
D --> E["LLM judge
(accountant-written rubric)"]
E --> F["Score
(share of criteria met)"]
F --> G["Decisions
(model, skills, memory, prompt)"]
G --> B这套评估真正有用的地方在 rubric。pass/fail 只能告诉你挂了；六项标准（比如"Q4 应付余额正确""重复项已标记"）能告诉你 4/6，以及具体挂了哪两项。写标准的人必须是领域专家：只有真做过账的人知道，审阅者到底会因为什么打回一份底稿。
Ramp 博客里给过一个任务样例：对比 2024 年 10 月和 7 月，找出前五大差异，逐条判断是季节性还是意外，并解释驱动因素。Agent 可能要拉 P&L、翻 GL 明细、读库存计划模型、对照年度预算。对应的标准类似"把 Total Revenue 识别为前五差异""正确判断 10 月市场费用为意外项"。任务得分就是满足标准的比例。
四、用评估做决策：两个热门思路没扛住
评估的价值在于改变决策。第一个决策是选模型，基准跑分用的模型是 GPT 5.5；对比前沿模型时，Ramp 统一剥掉 skills 和 memory，只测模型本身的贡献。但 Ryan 认为真正的 alpha 在 harness 调优：围绕 skills、tools 和基础设施做优化，在低成本、低延迟的前提下把分数做上去。
几个流行思路先被证伪：
- GEPA 式自动调优（autoresearch）：训练时的收益迁移不到真实任务。Ryan 的原话很直接，他还没看到自动 prompt 优化有效的像样证据。
- 拉高 reasoning effort：准确率没变，成本上去了。
留下来的思路是把 Agent 当 ML 模型对待，把上下文当 feature 工程做。落到两件事上：skill 消融，和 skill 压缩。
Skill 消融：8 个砍到 4 个
做法完全是 feature selection 的路数：先拿掉全部 skills 跑基线，再每次只挂一个 skill 跑基准，得到每个 skill 的边际贡献。结果不好看：8 个 skill 里只有 2 个平均为正，1 个基本中性，其余平均都是负贡献，而且没有一个 skill 在所有 worlds 上都最好。有的 skill 甚至在拖后腿。
把留下的 4 个合成一个精简包再测：六个标准 world 上，均分比无 skill 基线高 2.8 分。拆开看每个 world，分化很夸张：医疗 world 涨 8.1 个百分点，建筑 world 涨 5.5，电商 world 反而跌 0.3。Ryan 特别强调，单个任务或单个 world 会给出完全错误的直觉，这就是为什么均值要靠很多个 world 撑住。
Skill 压缩：61% 砍下去，质量没动
最大的高负载 skill 是一个操作电子表格的 skill，14k 字符，几乎每个 session 都要加载。里面差不多一半是金融建模指导，跟记账结账无关，那是另一个产品线的活儿。
他们把它一拆为二：记账相关的表格指令留下，建模指导挪进一个更窄的独立模块，只在真正需要的场景加载。压缩之后，质量基本不变，token 成本每月省下约 3 万美元。
五、记忆怎么测：roll-forward worlds
记忆很少被评估，因为它需要时间流逝。这个月结账学到的经验，下个月还有用吗？有没有可能帮倒忙？
Ramp 的做法是 roll-forward worlds：同一家合成公司，时间推进一个月。Agent 先完成本月的 close，写下学到的东西，然后在新月份的任务上被打分。
他们学到的规则：记住这家公司怎么运转，但用新鲜数字。从历史 trajectory 提炼记忆、剔除具体期间数字之后，均分比只有 skills 的版本高 5.7 分。
正反两个例子都在 Ramp 博客里有原文。好例子是工伤险审计应计：新任务要求刷新 2025 年 1 月的工伤险应计，没有记忆的 Agent 得分 0%，带着记忆的 100%。那段记忆摘译如下（有删节）：
从
GL_Detail.xlsx拉取 8 至 12 月科目 5010（现场人工）和 6000（G&A 工资）的实际工资数，注意回冲未反转的上期工资应计，避免重复计算。按 12/5 基数年化修正后的工资。读工伤保险单，提取类目代码、类目占比、每 100 美元费率、经验修正系数和已缴保费。把年化工资分摊到类目，套用费率和经验修正，减去已缴保费，算出应计份额，与现有工伤审计应计对比，分摊到项目，最后给出分录：借 Insurance Allocated，贷 Accrued Project Costs。
这段记忆里有上期的细节，但可迁移的部分占主体：哪些 GL 科目重要、保单里哪些字段驱动计算、估算怎么成型、最后的会计处理是什么。它是可复用的工作流，不是一份过期答案。
坏例子是 AIA 进度账单复核。任务本身要求审阅当期 AIA 申请并判断是否需要调整，没记忆的 Agent 得了 75%，带着记忆的掉到 25%——记忆把上个月的 CO-001 重分类配方硬塞了过来，Agent 照方抓药，把这个月的账做成了上个月的。
所以别急着多写记忆。真正该写的是能泛化的内容：稳定的科目映射、文件命名约定、工作流模式、明确的步骤。至于特定期间的金额、客户名单、文件名、过期条款和一次性配方，要么强过滤，要么按任务级别显式关闭。
六、两份报告的数字差，恰好说明评估该怎么读
对照读两篇文章会发现一个细节：同一件事，数字对不上。dev.to 版本说技能精简带来 2.8 分提升、压缩 61%；Ramp 6 月的工程博客写的是 +2.3 个百分点（"当前清理后的快照"），电子表格 skill 从 14k 字符砍到 5k（64%）；记忆提升一处写 5.7 分，另一处写 56.0% 到 61.5%（+5.5pp）。
这不是谁写错了。基准是活的：world 配置重跑、任务池清理、模型换版本，数字就会漂。真正稳定可迁移的是方法论：一次只改一个变量、多个 world 撑均值、跟固定基线比。读任何团队的 evals 报告（包括这一篇），重点是方法——怎么搭基准、怎么比基线，数字本身会漂。
七、讨论区补刀：三个值得抄走的坑
这篇文章的评论区质量意外地高，有三条补充值得记下。
一是只看最终产出会让"凑对的答案"漏网。有读者指出，LLM judge 只看输出，会放过数字对但推理路径错的结果——正确的数字，破碎的 trajectory。他们的解法是在 trajectory 上也加断言，不只验产出。
二是 subagent 会绕过你的消融结论。如果 harness 把活儿交给 subagent，每个 subagent 开全新上下文、看不到主 Agent 已加载的 skills，那么在主 Agent 上做的 skill 消融，结论对 subagent 不成立。
三是给记忆标注来源（provenance）。有读者建议在评分里区分"可复用的工作流经验"和"必须重新抓取的期间数值"，让"用新鲜数字"从一句原则变成可观测的失败模式。
参考文档与链接
- Building Better Agents through End-to-End Evals (dev.to) — 本文主要依据，Ryan Stevens 2026-10-14 发布
- Stack Benchmarking (Ramp Engineering) — Ramp 工程博客原文，含 8 个 worlds 完整表格与记忆案例全文
- Ramp Stack 产品页 — Stack 套件与通用基准对比（对 Claude Code、Codex 的跑分）
- Building Fast & Accurate Agents with Prime-RL Post Training (Ramp Labs) — Ramp 的 RL 后训练研究，Fast Ask 案例
- GEPA: Reflective Prompt Evolution (arXiv) — 文中被证伪的 GEPA 式自动调优原始论文
- Your AI Product Needs Evals (Hamel Husain) — 领域专家写 rubric 方向的经典长文
- Claude Code Subagents 文档 — 评论区提到的 subagent 隔离上下文行为
- Daily Context (dev.to 出版物) — Ryan Stevens 发文的刊物
你的团队给 Agent 上 evals 了吗？评论区聊聊你们怎么评分。觉得有用点个赞，让更多人看到。
作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
