企业官网建设流程全解析

做 Agent 的人迟早会撞上一堵墙：功能好像都通了，但你根本说不清它到底行不行。手动喂十几条测试用例、肉眼盯着日志看结果，一次两次还行，等 Agent 要接工具、要处理几十步长任务、要面对真实用户各种奇怪输入的时候，这种土办法马上崩盘——你不知道哪次改动改坏了东西，也不知道当前版本离上线标准还差多少。Anthropic 公开的 Agent Eval 方法，正是把这件原本很靠感觉的事，变成一套从任务定义、评测用例设计、自动判分到持续改进的工程化流程。这篇分享里，我会按这套思路，结合自己做 Agent 评测的实操经验，把每个环节拆开讲透，争取让你看完就能直接照着搭一套适合自己的评测体系。

1. 先搞清楚：Agent 评测难在哪，为什么必须体系化

很多人一开始对 Agent 评测的态度是：不就是拿几个 case 跑一下，看看输出对不对吗。这话对了一半。对单轮问答模型，这个思路勉强够用；对 Agent 来说，这种想法会很快让你在第一个真实项目里栽跟头。想做好评测，得先明白 Agent 和普通语言模型在"被评测"这件事上到底差在哪。

1.1 单轮问答评测与 Agent 评测的本质差异

单轮问答的评测，本质上是一次"输入-输出"比对。你给模型一句 prompt，它吐一段回答，你拿参考答案或者规则去判断对错，整个过程是一个静态快照。

Agent 完全不是这么回事。它在一次任务里会经历多轮推理、多次工具调用、环境状态变化，甚至中途还要根据返回结果调整策略。这就像单轮问答是改一篇作文，而 Agent 评测是验收一条流水线——你不仅要看最终产品合不合格，还要看中间每一道工序有没有跑偏。

有一回我调试一个需要联网查资料再汇总的 Agent，跑出来的报告本身完全正确，但我翻日志发现它先调用了一个错误接口拿数据，发现不对又绕回来用正确接口。最终结果对，过程却在浪费时间和 token。如果只看最终输出，这种低效行为永远不会被发现，积累到一定程度就变成线上成本失控。多步任务的错误会逐层叠加，任何一个环节的微小偏差都可能在后续步骤中被放大，这是 Agent 评测比传统评测难一个量级的根本原因。

1.2 一套体系化评测要解决的四个实际问题

你需要的不是"更多测试用例"，而是一套能回答以下四个问题的机制。

• 回归检测：这次改了 prompt 或换了模型，哪些已有能力被破坏？没有持续评测，你根本不知道一次"优化"是不是在拆东墙补西墙。
• 能力边界：当前版本到底能处理什么任务、处理到什么程度？这个结论不能靠感觉，得有覆盖各种任务类型和难度等级的评测数据支撑。
• 迭代依据：当你要在提示词方案和代码方案之间做选择，或者要对比两个不同版本的工具调用策略时，评测结果是你唯一能站得住脚的判断依据。
• 上线信心：发布前你总得回答"能不能上"这个问题，量化指标比"我大概试了试没什么问题"有说服力得多。

这四个问题环环相扣。没有回归检测，迭代就是在黑箱里乱撞；没有能力边界认知，上线就是在赌运气。所以问题的关键不是选什么评测工具，而是流程本身——从定义任务的那一刻开始，评测就已经在发生了。

2. 整体思路拆解：这套评测方法的骨架是什么

Anthropic 那篇 Agent Eval 分享里最触动我的，不是某个具体的评测技术，而是他们把整个流程串成了一条清晰的链路：先定义任务，再构造评测用例，接着设计判分逻辑，最后用持续改进把整个系统盘活。这个顺序本身就是学问。

2.1 把"任务定义"放在最前面，是被逼出来的

Agent 评测的第一步不是写代码，而是写清楚任务到底是什么。听起来像废话，但真正做过的人都知道，这是整个流程里最容易被跳过、也最致命的一步。

如果你把任务定义成"回答用户的问题"，那么评测标准就是"答得对不对"，等于什么都没定义。但如果你把任务定义为"在不超过 5 轮交互、只允许调用这三个工具的前提下，从用户提供的报销单据中提取金额、类别和日期，并按模板提交申请"，你的评测用例、判分逻辑、失败分析就全部有了锚点。

这不是理论上的美好愿望，而是被真实教训逼出来的。我见过太多项目，Agent 行为诡异，团队争论半天"它到底算不算做对了"，最后发现根因是任务描述本身就含混不清——有人理解成要直接给结论，有人理解成要先查库再给结论。任务定义清楚之后，一半的评测争议自动消失。

2.2 两种评测形态：结果导向与轨迹导向

在实际搭建评测时，你会发现评测用例天然分成两类，一类只看最终结果，一类要管中间过程。两种形态各有适用场景，我整理了个对照表。

实际项目里我不会二选一，而是混合使用：以结果导向评测决定"过不过"，以轨迹导向评测回答"为什么挂"。结果导向的用例负责守底线，轨迹导向的用例负责挖细节。比如判断一个检索增强型 Agent，结果导向只看最终答案是否覆盖关键信息点，轨迹导向则检查它有没有在检索阶段就漏掉关键文档——后者往往是前者失败的真正原因。

2.3 评测粒度分层：从单步到端到端

除了评测形态，评测粒度也得分层。我把 Agent 评测分成三个层级：

• 组件级：单独测某一个环节，比如路由判断是否准确、单次工具调用的参数是否正确、检索结果相关性是否达标。这类评测跑得快、反馈快，适合开发过程中频繁执行。
• 任务级：跑完整条任务链路，看最终目标能否达成。这是评测体系的核心，直接反映用户可感知的效果。
• 系统级：把多个任务组合起来，考察资源消耗、并发表现、稳定性、超时率等。这类评测最接近生产环境，也最贵，通常放在发布前执行。

分层带来的最大好处是反馈速度的优化。你不需要每次改代码都跑一遍完整的端到端评测，组件级用例几十秒就能给结果，等组件都绿了再跑任务级和系统级，省时省力。我见过有人把所有评测都堆到端到端，结果一次改动要等半小时才能知道结果，迭代效率低到令人绝望。

3. 任务定义与评测用例设计：动手前最重要的 50%

如果问我评测体系里哪部分投入产出比最高，我会毫不犹豫地说：任务定义和评测用例设计。这部分做好，后续的判分和持续改进都是水到渠成；这部分糊弄过去，后面每一步都在还债。

3.1 怎样写一份"可判读"的任务说明书

一份能直接指导评测的任务说明书，至少包含这样几个模块：

• 目标（一句话可验证）：例如"根据用户上传的报销单据图片，提取金额、类别、日期并生成报销申请草稿"。这句话必须可以判定真伪，不能出现"提供帮助""给出建议"这种含糊表述。
• 可用资源：明确列出可调用的工具清单、数据范围、权限边界。Agent 只能用定义好的工具，这是评测的硬约束。
• 约束条件：包括最大交互轮数、超时时间、预算上限、合规要求。这些约束本身就是评测的一部分。
• 成功标准：这是最关键也最容易偷懒的模块。要写"满足以下全部条件才算成功"，而不是"尽量表现好"。
• 边界与反例：明确哪些情况不算成功。比如"用户提供的单据模糊无法识别时，必须主动询问，而不是猜测填写"，这就堵住了 Agent 乱猜的后路。

拿某客服工单自动处理 Agent 举例，任务说明书的成功标准大致是：准确识别工单类型、在允许的工具范围内查询用户信息、给出符合话术规范的回复、涉及退款时必须转人工并在回复中明确说明。你看，这样定义完之后，评测用例和判分逻辑几乎是顺理成章的事。

3.2 评测用例的三类来源

评测用例不能拍脑袋凭空编，我常用的来源有三个，按优先级排序：

• 真实日志沉淀：从线上日志里挑出成功和失败的真实任务，这是最有价值的用例来源。因为它代表真实的用户分布，包含各种预料之外的输入方式。我每个迭代周期都会从日志里随机采样一批任务补充进评测集。
• 人工构造变体：围绕核心任务人工制造变体，换表达方式、换数据格式、换边界条件。比如测试报销提取，就要覆盖手写体模糊、多币种金额、缺少日期等各种情况。变体的目的是逼出 Agent 的薄弱点。
• 合成难度递增序列：从单步任务开始，逐步叠加难度——增加检索步骤、增加多工具协作、引入冲突信息、设置需要拒绝执行的场景。这类用例用来探能力上限。

无论用例来自哪里，我要求每一条都必须能回答两个问题：它在测什么能力？什么行为算通过？回答不了这两个问题的用例，趁早删掉，留着只会制造噪音。

3.3 成功标准的可操作化：把"好"变成"可判断"

很多人写成功标准时喜欢用形容词，"准确""合理""流畅"，这些词在评测里毫无意义。你要做的，是把宏观描述逐步拆解成可验证的具体条件。

以"正确调用工具"这个标准为例，拆解之后至少包括三层：用了正确的工具（该调提交接口时没有调查询接口）、传了正确的参数（金额字段没有塞进备注字段）、在正确的时机调用（没有在用户还没确认前就提交）。每一层都可以写成具体断言。

下面是一条任务级评测里很典型的断言逻辑：

def assert_task_success(trace, result): # 1. 最终结果结构必须完整 assert result["status"] == "submitted" assert set(result["fields"]).issuperset({"amount", "category", "date"}) # 2. 关键工具调用必须发生，且顺序正确 tool_names = [call["name"] for call in trace["tool_calls"]] assert "extract_receipt" in tool_names assert tool_names.index("submit_expense") > tool_names.index("extract_receipt") # 3. 交互轮次不能超限 assert len(trace["turns"]) <= 5 # 4. 不得出现越权操作 assert not any(call["name"] == "quote_price" for call in trace["tool_calls"])

要注意的是，断言不是越多越好。写得太细会过度编码实现细节，比如强制要求 Agent 必须用某种特定方式思考，反而让评测集变得脆弱。我的经验是：断言覆盖"任务的必要条件和结果质量"，至于 Agent 用什么路径达到结果，留给轨迹评测单独去管。

4. 自动判分与轨迹采集：评测运行的工程化

任务定义和用例设计做好之后，接下来的问题就是怎么把评测跑起来、跑得稳。这一环节最考验工程功底，因为评测系统本身也是一个系统，它也会出错、也会不稳定。

4.1 规则断言与 LLM 打分器怎么配合

判分方式我通常按输出类型分两派。

结构化输出用规则断言。只要 Agent 的输出是 JSON、是字段化数据，就用代码直接校验 schema、校验必填字段、校验值域。规则断言快、稳定、无歧义，一个字段对就是对错就是错。这里面有个实用技巧：在评测环境里把 Agent 的最终输出解析成统一的数据结构再交给断言函数，不要直接拿原始文本做字符串匹配，后者会死得很惨。

开放式输出用 LLM 打分器。汇总报告、邮件草稿、话术回复这类内容没有标准答案，只能让一个语言模型当评委。但 LLM 打分器有个著名的问题——不稳定。同一个回答，换个 prompt 或换个顺序，分数可能就变了。我在实践里总结了几个稳住的要点：

• 打分器温度设为 0，关掉随机性；
• 在打分 prompt 里先写明评分卡（rubric），再让模型给出判定理由，最后给出分数；
• 给打分器提供几个已标注的示例，示例的形态要覆盖高分、低分、临界三种情况；
• 多条用例运行时随机打乱顺序，避免位置偏差。

一个简化版的打分器 prompt 长这样：

judge_prompt = f""" 请根据以下评分标准，判定 Agent 回复是否成功完成任务。 评分标准（满足任意一条即判失败）： 1. 回复未给出用户问题对应的明确方案； 2. 方案引用了不存在的数据或字段； 3. 需要转人工的场景（退款、投诉）未明确提示转接。 请先陈述判定理由，再输出 PASS 或 FAIL。 Agent 回复： {agent_response} """

这样做的核心思路是：把主观判断尽可能变成客观条件，让打分器的自由裁量空间最小化。你给它的约束越清晰，它的结果越稳定。

4.2 运行时钩子：评测不能只盯最终输出

前面说过，Agent 评测要看轨迹。轨迹从哪来？从运行时埋点来。评测系统必须在 Agent 的整个执行过程中插入钩子，记录每一步的关键信息。

我在评测框架里最少会埋三类钩子：工具调用前、工具调用后、任务结束。工具调用前记录 Agent 的推理意图和将要执行的调用，用来判断"该不该调"；工具调用后记录返回内容和状态，判断"调得好不好"；任务结束时汇总轮次、耗时、token 消耗。一个简单的拦截逻辑可以这样写：

def before_tool_call(context, call): context.record_intent(call["reasoning"]) if call["name"] not in context.allowed_tools: # 调用白名单之外的接口直接判失败 return {"action": "abort", "reason": "tool_not_allowed"}

钩子设计有个重要原则：评测用的钩子和生产环境的日志埋点尽量共用一套基础设施。否则你评测时看到的行为轨迹和线上真实行为可能不一致，评测就失真了。另外，完整轨迹必须落库保存，这不仅是定位问题的手段，更是后续复现失败用例的数据基础。没有轨迹，评测结果就只是一个没有证据的结论。

4.3 评测运行与结果管理的工程化细节

评测代码写好了，怎么跑、怎么管理结果，同样有一堆学问。我踩过不少坑之后，固定下来一套做法：

• 固定一切可固定的东西。模型版本、温度参数、随机种子、工具列表版本，全部固定并在评测记录里写明。不然出了结果差异，你都不知道是哪一层变了。
• 对非确定性结果做重复实验。Agent 天然有随机性，单次 PASS/FAIL 不能说明问题。重要用例至少要跑 3 次，取多数结果或稳定率作为最终指标。
• 评测结果落库。每次运行的时间、版本、通过率、完整轨迹、判分明细全部入库。这是持续改进环节的数据基础，没有历史数据，你就没法做回归对比。
• 定义统一的指标口径。我常用的是：主任务通过率（端到端成功比例）、工具调用成功率（单个工具调用被判定为正确的比例）、平均交互轮次、超时率。这四个指标能覆盖大部分 Agent 的核心表现。

工程化做到这个程度，评测本身才算一个可信的测量工具。否则它只是一个偶尔跑一下的脚本，提供不了可供决策的信号。

5. 持续改进：让评测真正驱动迭代

评测体系建起来只是开始，真正让它发挥价值的是持续改进这个环节。如果评测结果出来没人看、看完没动作，那整套体系就只是个昂贵的摆设。我从实践里总结出的核心是：把评测当成一个活的系统，每周都要喂东西进去、每周都要做清理。

5.1 建立评测评审的固定节奏

我习惯每周固定一个半小时做评测评审，雷打不动。这个评审不是把通过率看一遍就完事，而是逐条过新增失败和争议用例，做三件事：

• 分类失败原因。把每一条失败明确归到"真回归"、"评测用例本身有问题"、"模型能力确实不足"三类。真回归要马上查代码或配置变更；评测用例有问题要改用例改标准；模型能力不足则排进迭代计划。
• 回填真实新任务。从本周线上日志里采样新的真实任务，人工标注后加入评测集。只有不断把真实分布喂进来，评测才不会慢慢脱离实际。
• 清理失效用例。那些连续多次全过、且不再对应任何能力风险的用例，降级或移除；那些反复被改来改去的用例，停下来问一句"是不是原来的成功标准就没定对"。

评审之后，失败的案例进入两个去向：修正评测标准，或者修复模型行为。然后重新跑一轮评测验证。这个"失败案例 → 分析归类 → 修正评测或修复模型 → 回归验证"的循环，就是持续改进的核心节拍。我见过最快把 Agent 质量拉起来的团队，不是他们模型调参多厉害，而是这个循环跑得又勤又准。

5.2 一次典型迭代：从"评测误判"到"能力提升"

光讲流程有点抽象，说个我实际遇到的案例。某项目的客服工单 Agent，端到端通过率一度停在 91%，其中"退款类工单"这一个分类的失败率占了七成。一开始判断是 Agent 不会处理退款，团队猛调 prompt，调了两周效果甚微。

后来做了一次深度的失败用例分析，把每一条失败轨迹都翻出来看，发现问题根本不是 Agent 不会处理退款，而是评测标准定义错了。原任务说明书里的成功标准写着"回复必须包含明确解决方案"，可公司政策要求退款类工单必须优先引导转人工，禁止直接在回复里承诺退款。Agent 行为完全正确，却因为评测用例的成功标准没跟上业务规则，被判成失败。

修正成功标准、把"退款类工单正确转人工"设为有效终态之后，通过率数据一瞬间变得真实了，模型改动也终于有了正确的反馈信号。这个案例给我的教训很深刻：评测用例不是石头刻的，它必须随着业务规则和任务定义的进化而进化。持续改进不只是改模型，改评测本身同样是改进。

5.3 防止评测集过拟合与退化的三条红线

评测集用久了，会慢慢丧失区分度，最后变成一块谁都能过的牌子。我给自己定了三条红线，触犯任何一条都要立刻处理。

• 评测集不能当训练集用。反复对着同一个评测集调 prompt、调参数，本质上就是在过拟合这几十条用例。评测分数看起来漂亮，换一批新任务立刻现原形。解决方法是留一个固定的 holdout 集——从评测集里划出一部分不参与日常调试，只在里程碑节点跑一次。
• 定期从真实分布采样刷新评测集。评测集必须是一个不断进化的活样本，而不是一个固化的存档。真实任务分布变了，评测集不变，评测就变成自欺欺人。
• 监控评测有效性与业务指标的联动。如果某个阶段的评测通过率一直在涨，但线上用户的成功率、投诉量没有同步变好，那你就要警惕：评测集很可能已经失真了。评测的价值最终要体现在真实世界的表现上，这条不成立，上面的努力全部白费。

三条红线本质上是一条：永远不要让评测脱离它服务的对象。评测是手段，真实任务是目的。

6. 常见问题与排查技巧实录

最后这部分是踩坑实录。我把自己在做 Agent 评测过程中遇到过的高频问题整理成了一张速查表，后面再挑三个最典型的展开讲。

6.1 评测用例模棱两可怎么判

这是最隐蔽也最普遍的问题。一看评测用例好像写了，细看全是"合理判断""适当处理"这类虚词，判分的人或判分的模型只能靠猜。结果就是同一个用例，不同人标注结果不一样，评测结果根本不可信。

我的解法很朴素：把成功标准改写成一组二值条件，每个条件只能回答"是"或"否"。同时给每条用例配上至少一个"通过示例"和一个"失败示例"。这两个示例的价值在于把抽象标准落到具体形态上。另外，评审会上但凡出现判定争议，不争论，直接改用例——要么补充条件，要么调整示例，定稿后写进用例描述里。这种"争议即更新"的机制让评测标准越来越清晰。

6.2 评测结果忽高忽低、复现困难

Agent 评测的非确定性来源很多：模型采样的随机性、工具调用返回时间不同、并行执行时共享状态被改动、第三方服务限流等等。如果你不做控制，评测结果就是一片噪声。

我的处理方式分三层：入口层把随机种子、模型版本、温度全部固定；执行层对关键用例做多次重复，取稳定通过率而不是单次结果；分析层把每一次执行的完整轨迹存下来，失败时能精确重放，而不是只能看一个秃秃的 FAIL。这里有个容易忽略的点：第三方工具调用的返回内容也要记录。没有它，很多偶发失败根本没法定位到底是不是外部服务抽风。

6.3 评测集越来越臃肿，跑一次要很久

评测集不会自然保持精简，它会不断膨胀——每周都加新用例，但几乎没人删用例。几个月之后，跑一轮完整评测成了煎熬，大家开始跳过评测，体系就名存实亡了。

我用的是三层评测策略：smoke 层只有十几条最核心的用例，每次代码改动都跑，几分钟出结果；full 层包含全部任务级用例，每日跑一次；nightly 层包含系统级和压力类用例，每晚跑一次。新增用例先进 full 层观察，连续一段时间不出问题再降级或移除。这个策略保证了反馈速度和覆盖度的平衡，评测才不会演化成负担。说到底，评测体系能不能坚持下去，取决于它跑起来有多省事，而不是它有多全面。

我自己在实际搭建这套流程时最深的一个体会是：Agent 评测表面上是在测 Agent，实际上是在逼你把任务本身想清楚。很多项目的问题根本不是模型不够强，而是任务定义模糊、成功标准含糊、行为边界不清——评测体系把这些问题全部暴露出来。所以哪怕你暂时不打算做完整评测，也建议从"写清楚任务说明书"开始，这一个小动作就能帮你避免大量的无效迭代。如果再贪心一点，给每条评测用例记一笔"为什么加它"的日志，三个月后回头看，你会感谢现在的自己。