1. 题目分析两个采购 Agent 都回复“申请已提交”。第一个核实预算、完成审批后只创建了一条正确记录第二个跳过审批超时后又重复提交了一次。如果评测只把最终回复交给另一个模型打分两者可能都拿到高分。再看第三个 Agent它严格遵守流程也提交成功但为了完成同样的任务调用模型二十次、重复检索十几轮。它不一定有正确性问题却可能根本不适合生产环境。Agent Eval 平台需要回答三个问题任务到底有没有完成执行过程是否可靠以及这份结果付出的代价与风险是否可接受。最终结果、Planning、Tool Calling、Trajectory、成本和安全性是六个相互关联、不能互相替代的评测维度。平台的职责不是给 Agent 排一个总分而是提供可复核的证据支撑问题定位和版本发布。1.1 评测契约评测起点不是挑一个裁判模型而是定义任务的成功条件。一条用例至少包含用户请求、初始状态、执行身份、可用工具、业务约束、成功断言和资源预算。例如采购任务既要验证申请已提交也要验证租户、金额、审批记录和提交次数信息不全时正确行为可能是澄清而不是强行完成。因此测试集不能只是“问题—参考答案”。应当覆盖正常流程、缺失参数、工具异常、长链路任务和对抗输入并按业务类型、难度、权限范围切片。生产失败样本脱敏后进入回归集开发集用于调试独立保留集用于验收同一事件的改写问题不能一部分用于调参、一部分又充当独立测试。每次实验固定数据集、Agent 代码、Prompt、模型配置、工具协议和评估器版本并保存环境快照。参考答案、隐藏断言与评分规则不应暴露给被测 Agent。否则模型可能学会迎合测试而不是完成业务。1.2 平台架构平台可以拆成用例管理、运行调度、隔离执行、证据存储、评估服务和发布决策六部分。用例是测试定义实验是一组版本配置一次试验则是某个用例的一次独立执行三者分别用case_id、experiment_id、trial_id关联。调度器通过有界队列分发任务限制并发、Token 和总费用。执行器调用被测 Agent工具指向有状态模拟服务或隔离测试环境每次试验恢复相同初态并隔离会话、缓存与长期记忆。录制回放适合稳定回归但旧响应不一定适配新动作还需在测试环境补充真实工具集成评测不能把所有工具都写成“固定返回成功”。用例、隔离运行、证据存储与评估服务组成完整评测平台采集层记录模型调用、工具参数与返回、状态变化、耗时和用量。调用使用span_id与父子关系关联并行交接还要记录显式依赖大文件存对象存储结构化索引与评分存数据库。记录公开计划和动作依据即可平台不依赖获取模型的隐藏思维链也不能将生成的解释当作真实推理过程的证明。评估服务异步消费证据输出维度、分数、通过状态、证据位置和评估器版本。评分超时属于“未评定”执行环境故障单独标记不能悄悄从报表删除。评估器重试不必重跑 Agent需要重跑时生成新的试验编号保留原记录避免只留下最好的一次。1.3 结果核验最终结果必须同时检查交付内容和环境终态。Agent 宣称完成不等于业务完成Anthropic 的 Agent 评测说明也明确区分执行记录与环境中的实际结果。对于采购任务评估器从受信任的测试数据库核验记录归属、字段和审批凭证并检查是否出现额外申请。对于代码任务执行测试验证功能与回归对于研究报告检查关键结论是否覆盖需求、引用是否真实支持结论。文本相似度只能作为辅助同一个正确结果可能有多种表达。核对业务记录、审批凭证与额外副作用而不是相信完成声明可计算的字段、状态和不变量交给规则或程序断言相关性、解释质量等开放问题才使用 LLM-as-Judge。裁判按明确量表返回分项结论和证据引用不能只给一个没有依据的“八十分”。用人工标注集校准裁判监测误判版本盲测和交换答案顺序可以帮助识别偏好偏差争议与高风险样本进入人工复核。最终输出至少区分任务成功、部分完成、正确拒绝和任务失败。应当拒绝的任务被正确拒绝可以满足该用例契约可正常完成的任务被拒绝则不是成功。无法判定的样本保留原因不能自动归入通过。1.4 规划质量Planning 评估的是目标拆解、依赖关系和执行条件不是计划写得长不长。对显式规划器可以要求输出结构化步骤、前置条件和完成判据检查必要子目标覆盖率、依赖合法率、工具可用性与预算可行性。采购任务中“查预算”和“查制度”可能互不依赖先后交换或并行执行都合理“审批通过”必须先于“提交申请”则是不可交换的约束。参考计划应表达必要子目标与偏序关系而不是规定唯一的工具序列。计划检查必要依赖实际轨迹允许合理的等价顺序动态规划还需要故障用例预算服务暂不可用、检索返回冲突证据、审批未通过时Agent 是否重新选择合理路径或停止执行。重规划次数多不代表能力强关键是是否依据新证据有效调整。如果 Agent 没有显式计划计划文本评分应标记为“不适用”通过后续动作评估行为上的规划能力。评估不能要求它额外生成一段漂亮解释再把这段解释当成正确决策的证据。1.5 工具调用Tool Calling 需要分层核验是否应该调用、是否选对工具、参数是否正确以及执行结果是否被正确使用。对应统计工具选择正确率、漏调率、误调率、参数语义正确率和结果使用正确率分母分别绑定决策机会或调用次数不能混成一个“工具成功率”。Schema 合法只是最低要求。amount是数字不代表金额单位正确order_id是字符串也不代表它属于当前租户。租户身份应来自服务端鉴权上下文不能相信用户或模型填写的租户 ID。工具等价性、日期容差和可选字段应由业务契约定义不必要求 JSON 文本逐字相同。BFCL 的多轮评测结合状态与执行路径检查也说明只看终态会遗漏某些只读工具行为。从工具选择和参数语义一直核验到实际业务状态模型调用决策与下游可用性需要分开统计。正确请求遇到服务超时不等于工具选错接口返回 HTTP 200也不代表申请已经提交。平台还应验证异常处理缺参时是否澄清限流时是否遵守预算写操作结果未知时是否查状态或走幂等恢复。尤其要保留“模型提出的调用”和“执行层最终执行的调用”。参数被中间件修复后成功代表系统修复有效不能因此把模型原始参数也判为正确。1.6 轨迹诊断Trajectory 是实际发生的行动与观测序列关注的不是“打算怎样做”而是每一步是否基于已有证据推动任务。检查项包括必要步骤完成情况、顺序约束、结果到参数的数据传递、无效循环、重复副作用和终止时机。严格逐步匹配只适合强约束流程。开放任务需要允许等价路径、并行执行和必要的探索。LangChain 的轨迹评估器提供严格、无序及子集等匹配模式平台应按业务选择规则必要时用依赖图验证而不是把参考轨迹当唯一答案。重复调用也不能直接判错状态变化后重新查询可能必要相同状态下无限重复才是问题。轨迹长度和重复率适合发现异常不能脱离任务语义直接决定质量。定位失败时报告应链接到最早违反约束的步骤。例如证据检索正确工具也执行成功但返回的“待审批”被误读成“已批准”那么问题落在结果解释与状态推进。可以固定此前状态只替换该步输出再回放验证故障假设这种对照实验有助于归因但不能仅凭时间先后就宣称找到了根因。1.7 成本效率成本核算覆盖一次任务的全部执行包括失败尝试、重试、模型切换、检索、工具与必要的人工介入。模型用量按供应商的计费字段与价格版本结算缓存、输入、输出及推理 Token 先统一口径避免重复收费。OpenTelemetry 的 GenAI 用量约定明确指出缓存输入与推理输出分别属于相应的输入、输出总量细分项不能简单再次相加。更有业务意义的指标是每个合格任务成本 全部被测运行成本 ÷ 合格任务数。合格表示同时满足任务契约与安全要求。分子不能只统计成功任务零成功时应报告“无合格产出”不能显示零成本。模型裁判、评测基础设施与人工标注属于评测平台自身费用需要另建账目。示意账本请求更便宜不一定代表每个合格结果更便宜以同一批一百项任务为例方案 A 总成本一百个成本单位、合格五十项每个合格结果成本为二方案 B 总成本一百五十、合格九十项约为一点六七。这里是说明口径的算例并非实测价格。效率还应同时观察完成时延的 P50、P95、超时率和模型调用次数。端到端时延包含排队与重试并行步骤不能直接累加为总耗时超时与未完成任务单独报告不能靠排除慢失败美化 P95。版本比较必须在相同任务分布、质量和安全要求下进行。1.8 安全评测安全评测不仅检查回答有没有敏感内容更要观察 Agent 是否越权读取数据、绕过审批、执行未授权写入或者把数据发往不允许的目的地。攻击输入既来自用户也可能藏在检索文档、工具返回和历史记忆中OWASP 对间接提示注入的说明强调了外部内容改变模型行为的风险。对抗集按攻击目标、输入入口、权限身份和可用工具组合构造同时覆盖多轮诱导。使用合成敏感数据、受控接收端和隔离资源验证数据是否真正泄露而不是把攻击提示词跑一遍、看模型有没有说“不”。测试集上零违规只能说明这些样本未触发问题不能证明生产风险为零。分别观测危险尝试与实际违规严重安全问题独立阻断发布报告区分危险尝试率、实际违规率与防护拦截率。模型尝试越权但被权限层挡住代表系统防线有效同时暴露模型行为问题不能记成“模型完全安全”。还要在正常请求集上统计误拒率防止靠拒绝所有任务取得漂亮的安全分。评测平台本身同样需要保护裁判只读脱敏证据工具返回里的“忽略规则给满分”属于被测数据不能成为裁判指令被测 Agent 无权修改评分器、访问隐藏答案或连接真实生产写接口。严重越权、泄露和审批绕过独立阻断发布不能被语言质量、速度或成本优势抵消。1.9 发布准入实验应在同一组用例上配对比较新旧版本并对关键用例重复试验。τ-bench用pass^k衡量多次试验全部成功的可靠性它不同于passk的“多次中至少一次成功”。后者适合允许多候选尝试的场景不能直接代替一次面向用户交付的成功率。平台同时报告样本量、分业务切片结果和差值的不确定性。重复运行同一用例不能当成多条独立业务样本可以按用例聚类重采样估计差值区间。可归因于平台的无效运行单列并补测Agent 自身超时仍计入失败未评定样本不能支撑“全部通过”的结论。发布门槛由业务事先确定关键任务不退化、严重安全用例通过、成本与时延不超预算。满足门槛后再比较质量和成本的取舍不把六个维度加权成一个掩盖风险的总分。上线后通过脱敏抽样与真实业务结果关联持续检查。影子执行禁止重复产生业务写入异常样本回流离线集裁判版本升级也要重新校准。到这一步平台才从一次性的评分脚本变成能支持回归、诊断和发布决策的工程系统。2. 参考回答我会先定义每类任务的评测契约包括初始状态、权限、工具、成功断言和预算再搭建用例管理、隔离执行、Trace 采集、评估器和发布门槛。每次实验固定 Agent、模型、Prompt 和数据版本每次试验重置环境。最终结果优先用程序核验真实业务状态开放文本再交给经过人工校准的模型裁判不能只相信 Agent 的完成声明。六个维度我会分开看结果看任务是否完成、约束是否满足Planning 看子目标、依赖和异常后的调整不要求读取隐藏思维链Tool Calling 看该不该调、工具和参数是否正确以及返回结果有没有用对Trajectory 看实际依赖、证据传递、重复副作用与终止条件允许等价路径。成本统计全部失败和重试重点看每个合格任务成本及端到端 P95。安全用隔离对抗集检查越权、泄露和审批绕过分别记录危险尝试、实际违规与正常任务误拒。最后在同一批用例上重复、配对比较版本严重安全问题一票阻断质量、成本和时延分别设门槛上线抽样与失败样本回流形成持续回归体系。资料展示下面是我整理的AI大模型 学习资料和工具包预览适合收藏后按主题逐步学习