企业私有化 AI Agent 工作流怎么评测？任务集、轨迹、工具结果、成功率、成本、人工接管与回归清单

企业评测 AI Agent，不能只看最后一段回答是否顺眼。一个任务可能给出正确文字，却查错客户、调用多余工具、重复写入业务系统，或者花了十倍成本才完成。可靠的评测要同时检查任务结果、执行轨迹、工具副作用、权限边界、耗时费用和人工接管。本篇给出一套适合私有化部署的工作流评测清单，供上线评审、模型切换和日常回归使用。

先写清 Agent 承担什么任务

评测从业务任务开始，不从模型排行榜开始。客服 Agent 可能要查询订单、读取政策并生成答复；销售 Agent 可能要整理线索、补全字段和创建跟进草稿。每类任务都要注明发起人、输入资料、允许使用的工具、预期业务状态和禁止动作。范围不清时，成功率没有稳定含义。

区分回答任务与行动任务

回答任务的主要产物是文字、引用或结构化数据；行动任务会修改工单、邮件、文件、订单或权限。两类任务可共用部分质量指标，风险判定不能混在一起。行动任务即使最终答复正确，只要造成错误副作用，也应记为失败。高影响动作还要单独核对审批证据。

确定端到端完成条件

每条样本写明什么状态才算完成。例如“找到当前客户的未结工单，引用最新版政策，生成未发送的回复草稿”，完成条件包含对象正确、政策版本正确、草稿已保存且没有外发。不能只写“回答客户问题”。条件越接近真实业务记录，评分争议越少。

列出绝对不能发生的结果

每个任务都应带失败红线，例如访问其他租户数据、发送未经确认的邮件、改动原始文件、泄露密钥、绕过审批或伪造引用。红线一旦触发，任务总分直接归零或阻断上线。普通格式瑕疵不能抵消严重越权，评分表应体现这种不对称。

确定评测单位

一次 run 可以是一条用户请求到最终状态的完整执行，也可以是一段跨会话长任务。团队要固定起点、终点和超时边界。若一个业务任务包含人工审批，评测记录应包含暂停与恢复，不宜在弹出审批框时提前判定成功。

固定待测系统版本

每次评测至少记录模型、系统提示词、工具契约、编排代码、策略、知识库快照和运行环境版本。模型名称相同也可能对应不同配置。没有版本指纹，两个分数无法解释差异。站内的私有化 AI 模型服务上线清单可补充模型与推理环境留证。

从真实业务记录采样

测试集应覆盖企业真正发生的请求。可以从脱敏工单、客服对话、知识检索和操作日志中抽样，再由业务人员重写敏感字段。只用开发者编出的标准问句，会低估错别字、省略信息、上下文跳转和业务习惯带来的困难。

按业务场景分层抽样

先列出高频场景、高价值场景、高风险场景和新上线场景，再分配样本量。高频任务决定日常体验，高风险任务决定安全门槛。不能让大量简单查询稀释少数付款、删除和权限变更任务的失败。

保留简单样本作为基础线

简单任务能暴露工具不可用、路由失效和基础知识退化。它们不该占满数据集，却应长期保留。若一次改版连明确、单步、无歧义的任务都退化，团队无需先分析复杂链路。

增加多步骤样本

真实 Agent 往往要检索、判断、调用、校验并生成结果。样本应覆盖两到六个有依赖关系的步骤，并明确哪些顺序可以变化，哪些前置条件不可跳过。评分不要强迫模型复刻唯一漂亮路径，只要合法路径达到相同业务结果即可。

加入信息不足的请求

用户可能只说“帮我处理一下这笔订单”，却没有订单号、目标动作或审批依据。合格行为是追问必要信息或安全拒绝，不是猜一个对象执行。评测要写清哪些字段必须向用户确认，哪些可以从可信系统补全。

加入矛盾输入

对话文字、附件和业务系统可能给出不同金额或日期。样本应规定可信来源和处理规则。Agent 发现冲突后应暂停、说明差异并请求确认。直接选择更符合语言上下文的值，可能造成实际写入错误。

覆盖长会话与状态恢复

在多轮会话里，用户会修改目标、撤回授权或切换对象。评测需要检查当前状态是否覆盖旧指令，压缩上下文后关键约束是否保留，服务重启后任务能否从可信状态恢复。旧确认不能因会话仍在就继续有效。

加入工具故障样本

工具可能超时、限流、返回空值、响应格式变化或已完成写入但丢失响应。测试环境应主动注入这些故障。评测关注 Agent 是否识别未知状态、是否受控重试、是否造成重复业务，以及最终是否把真实状态告诉用户。

加入权限不足样本

使用普通员工、部门管理员、外部客户和停用账号运行相同任务。Agent 不应通过改写参数或换用其他工具绕过拒绝。权限失败后的回复要准确，不能声称操作已经完成。具体工具控制可结合AI Agent 工具调用验收清单检查。

加入提示注入样本

恶意指令可能藏在邮件、网页、PDF、表格或工具结果中。样本应测试 Agent 会不会偏离用户目标、外发数据或调用高权限工具。NIST 的Agent 劫持评测说明强调同时观察攻击成功与正常任务效用，企业数据集也应保留这两个维度。

加入应当拒绝的任务

拒绝集要覆盖越权、违法违规、缺少关键确认、工具不支持和信息不足。评测既看是否拒绝，也看拒绝是否过度。Agent 把所有困难请求都退给人，安全事故可能减少，业务价值也会消失。

加入人工接管样本

有些任务的正确结果就是转交人工，例如合同解释、身份核验失败、补偿失败和高影响例外。样本需写明接管触发条件、接收队列、必须携带的上下文和服务时限。只回复“请联系人工”而没有生成工单，不算完成。

数据集按开发与验收分开

开发集用于调试，验收集用于发布判断。调提示词和路由时反复查看验收答案，会把系统优化成记题。团队应限制验收集访问，定期加入新样本，并保留一部分从未用于调参的盲测数据。

防止同一业务记录泄漏

同一客户事件可能被拆成多条相似样本。若其中一条进入开发集、另一条进入验收集，分数会虚高。分割时应按客户、事件、模板或时间窗口分组，而非随机逐行切分。近似文本去重也要在分割之前完成。

给样本保存来源和日期

每条样本登记来源场景、采样日期、适用政策版本、编辑人和敏感处理方式。业务规则变化后，旧答案可能失效。没有时间与版本，评测人员容易把系统正确拒绝误判为退化。

为标准答案保留多个合法路径

Agent 任务常有多种正确轨迹。检索顺序可以不同，某些工具也可替代。样本应明确必需动作、允许动作、禁止动作和最终状态，而非只保存一串唯一工具调用。这样能避免奖励机械模仿，仍能抓住业务边界。

先用规则判定确定性结果

对象 ID、字段值、数据库状态、调用次数、权限拒绝和引用 URL 都适合用代码检查。确定性规则成本低、可重复，也方便定位。只要业务结果能从下游系统直接读取，就不应交给另一个模型凭文字印象判断。

用人工评分处理复杂质量

语气、解释是否足够、判断是否符合专业习惯等项目需要业务人员评分。评分指南要给出正例、反例和边界例。评审者先独立打分，再讨论分歧；若同一答案经常出现较大分差，说明评分标准还不稳定。

模型评分器需要校准

模型评分器适合批量初筛和结构化比较，不能未经校准就作为唯一发布门禁。先拿一批人工已标注样本比较一致率，观察它是否偏爱长答案、特定措辞或自身模型风格。评分提示词、模型和阈值也要进入版本记录。

组合多个评分信号

一条任务可以同时有业务状态规则、轨迹规则、引用检查、安全红线和人工质量分。组合时要写清权重及一票否决项。总分 90 分却越权访问一次，不能标成通过。各分项保留原值，便于团队知道改动影响了哪里。

记录端到端任务成功率

任务成功率的分母是实际运行样本数，分子是满足所有必需条件且未触发红线的样本数。超时、崩溃、人工取消和环境故障要按预先规则归类，不能评测结束后随意剔除。总成功率之外还要按场景与风险级别拆分。

区分部分完成与完整完成

Agent 可能完成检索和草稿，却没有成功保存。部分完成状态有助于诊断，但不应混入完整成功。可以记录步骤完成率、最终状态正确率和用户目标完成率。发布门禁仍应依据端到端业务条件。

单独统计错误副作用

错误写入、重复发送、误删、错误授权和跨租户读取要单独计数。这个指标通常要求为零。即使后续补偿成功，也要记录原始副作用和补偿耗时，因为用户或外部系统可能已经看到结果。

统计工具选择准确率

检查 Agent 是否选择了允许且合适的工具。能用只读查询完成的任务，却调用写接口生成临时对象，说明工具选择有问题。工具名称相似、参数接近和备用工具切换是常见错点。每次误选都要回到注册表和工具说明定位原因。

统计参数正确率

参数评分应覆盖对象、字段、范围、格式和业务约束。一个调用里十个字段有九个正确，关键收件人错误仍然失败。字段可以按风险设权重，身份、租户、金额和目标资源通常属于高权重项目。

统计轨迹合规率

轨迹合规关注执行过程是否满足约束，例如先验证身份再读取数据，写入前取得确认，失败后没有越过策略。OpenAI 的轨迹评分说明把轨迹定义为端到端的决策、工具调用和推理步骤记录，可用于定位编排失误与回归。

允许高效的不同轨迹

合规轨迹不等于固定轨迹。Agent 可能一次查到完整数据，也可能先查摘要再补详情。只要没有多余风险，最终状态相同，较短路径应被接受。评分规则应惩罚无意义循环和重复调用，而非惩罚所有与参考路径不同的选择。

统计人工接管率

接管率要按“正确接管、过早接管、漏接管、人工主动介入”分类。单看接管总量无法判断质量。高风险任务正确接管是成功，简单查询频繁接管则说明系统价值不足。评测报告应同时显示接管后的工单是否完整。

统计追问质量

Agent 在信息不足时需要追问，问题应直指缺失字段。一次问清必要信息通常优于连续泛问。评测可记录追问轮次、是否询问已知信息、是否泄露内部字段名，以及用户补充后能否继续原任务。

统计延迟分布

平均耗时会掩盖长尾。至少记录 P50、P95、P99、首个可见响应时间和最终业务完成时间。人工审批等待可单列，避免把用户等待混入模型推理。超时样本仍要进入分布，并注明停在哪个步骤。

统计 token 与调用费用

每次 run 记录输入 token、输出 token、模型请求数、工具请求数和外部服务费用。OpenAI Agents SDK 的用量说明列出了请求数与各类 token 统计。私有化部署还应加入 GPU 时间、队列等待和基础设施摊销。

用成功任务成本做比较

单次平均成本低，可能只是因为大量任务提前失败。更有用的指标是每个成功任务成本，并按场景拆分。比较两个版本时，同时呈现成功率和成本。NIST AI 800-2 初稿也建议把性能与成本一起报告，避免只用一个总分下结论。

设置调用轮次预算

评测环境应设置最大模型轮次、工具次数、总耗时和费用。达到上限后记录预算耗尽，不把它改写成普通答案。预算值要接近生产配置，否则测试通过的长路径可能在真实系统里被截断。

完整采集一次运行轨迹

轨迹至少包含任务 ID、模型轮次、工具调用、护栏、交接、审批、异常和最终状态。OpenAI Agents SDK 的追踪文档将一次工作流记为 trace，并用 span 表示模型生成、函数调用、护栏和 handoff。其他技术栈也可采用相同层级。

给每个事件统一关联字段

模型请求、工具调用、队列消息和下游业务对象要能通过 trace ID、run ID、call ID 和业务 ID 串联。重试不能丢失原始关联，参数变化时也不能复用同一个调用标识。没有关联字段，评测只能看到答案，无法确认副作用。

轨迹里控制敏感数据

完整追踪不等于保存所有原文。客户信息、访问令牌、附件和工具返回可能含敏感数据。应按字段分类决定脱敏、哈希、截断或不采集。追踪文档也提醒模型与工具输入输出可能包含敏感信息，企业需把保留策略纳入评测平台设计。

保留可重放的环境快照

要复现失败，需要保存模型配置、工具模拟器、知识快照、时间、随机种子或重复次数。外部系统持续变化时，可用隔离测试账户和固定响应夹具。重放不能写入生产对象，也不能重新发送真实邮件。

先看失败样本再看总分

总分告诉团队是否退化，失败样本解释为什么。评测报告应支持按场景、工具、模型、错误码和轨迹节点筛选。打开一条失败记录时，评审者能看到预期状态、实际状态、首个偏离点及后续影响。

建立失败类型字典

常见类别包括理解错误、信息缺失未追问、检索错误、路由错误、工具误选、参数错误、权限错误、循环、超时、错误接管和副作用。字典要允许一条样本挂多个标签，并标出首因。只归类成“回答不好”无法指导修复。

定位第一个偏离步骤

后续错误常由早期一步引起。Agent 选错客户后，后面的政策查询和草稿可能都很流畅。分析时先找到轨迹中第一个违反预期的位置，再判断是提示词、工具说明、数据、策略还是编排代码导致。

区分系统缺陷与评测缺陷

标准答案过期、模拟工具不真实、评分规则互相冲突都会制造假失败。评审者发现异常时，应能标记“样本问题”并进入独立修订流程。不能直接改答案让当前版本通过，修订原因和影响样本要留下记录。

对随机性做重复运行

同一输入运行一次，只能说明那一次结果。对高风险或容易波动的场景，应重复运行并报告成功比例、最差结果和方差。比较版本时保持重复次数与采样参数一致。若成本限制只能运行一次，报告里要明确证据强度。

给指标附置信区间

样本量较小时，82% 与 85% 的差异可能没有稳定意义。团队应报告样本数、分层结果和适合的置信区间，避免把小波动解释成明确提升。NIST 的AI 测量与评估工作强调可靠测量方法，企业报告也应保留不确定性。

禁止只挑最好的一次结果

测试多个提示词、模型和参数后，只报告最高分会产生选择偏差。评测计划应在运行前写明候选版本、主指标、停止条件和比较方法。临时探索可以多试，发布结论必须区分探索结果与预先设定的验收结果。

建立固定回归集

线上事故、人工接管和高价值任务都应转成脱敏回归样本。修复后先验证该样本，再跑完整回归。数据集不能无限膨胀，可按风险和代表性保留核心集，低价值重复样本进入扩展集。

建立动态挑战集

固定回归集会被团队逐渐熟悉，也可能跟不上新攻击和新业务。每轮发布加入少量未见样本，覆盖最近政策、工具版本和真实失败。挑战集结果单独报告，不要在看过结果后混回原始基线。

模型切换要跑同一套任务

更换模型时，保持工具、提示词、数据和评分尽量一致，先看模型因素。若同时改路由和工具契约，团队很难解释差异。必要的联动改动可以作为第二组实验，报告中写清变量。

提示词改版要核对轨迹

最终成功率相同，轨迹也可能变差。新提示词可能增加重复检索、绕远路或把更多任务交给人工。版本比较要同时看任务结果、调用轮次、成本和首个偏离点。提示词留档可参考私有化 AI 提示词模板管理清单。

知识更新后重跑引用任务

文档增量、切分策略和权限变化会影响 Agent 的检索结果。更新后应重跑需要引用的任务，核对来源、版本、权限和拒答。知识库专项指标可使用私有化 AI 知识库评测清单补充。

工具契约改动后重跑行动任务

字段改名、枚举调整、默认值变化和权限收紧都可能让旧轨迹失效。契约发布前应跑参数边界、写入副作用和错误恢复样本。生产工具不能直接用于批量评测，测试账户与数据应彻底隔离。

设定发布硬门槛

硬门槛适用于越权、确认绕过、错误副作用、数据泄露和不可恢复写入，通常要求零事件。普通质量指标可设最低值与相对退化上限。任何豁免都要写明样本、风险、负责人、补偿措施和到期时间。

设置相对基线门槛

绝对分数之外，比较候选版本与当前生产版本。高风险场景不能退化，核心场景成功率不能低于基线，P95 延迟和成功任务成本也要在允许范围。新版本提高平均分却损害关键客户流程，应阻止发布。

评测结果进入发布流水线

代码、提示词、模型、工具或策略变更触发对应评测集。流水线保存制品指纹、运行日志、分数和批准人，失败时不生成可部署制品。发布与回滚机制可参照企业官网发布流水线清单。

灰度期继续做影子评测

离线数据无法覆盖全部生产分布。灰度期间可对脱敏轨迹抽样评分，或者让候选版本在不执行副作用的影子环境中运行。影子结果不能回写真实系统。离线通过与线上监测共同决定是否扩大流量。

监测线上分布漂移

关注任务类型、语言、输入长度、工具使用、拒绝率和人工接管原因是否变化。分布明显偏离评测集时，旧成功率代表性下降。团队应从新分布补样，并重新审视发布阈值。

记录业务人员的纠正动作

人工修改草稿、换客户、补引用、撤销工具动作和重开工单，都是高价值反馈。系统要记录改了什么及原因，经过脱敏和审核后转成评测样本。只收点赞或点踩，通常无法定位工作流问题。

评测平台本身也要验收

检查任务调度、并发隔离、超时、重试、数据清理、评分版本和报告权限。评测器故障不能被计成 Agent 失败，生产数据也不能因测试而泄露。平台升级时用已知结果的小数据集校验计算是否一致，通用测试环境与缺陷管理可参考企业官网上线验收清单。

用一张表完成发布评审

评测面	核心证据	典型阻断条件
任务结果	业务对象、最终状态、必需字段与引用	目标未完成或对象错误
执行轨迹	模型轮次、工具、护栏、交接与首个偏离点	跳过验证、循环或调用禁用工具
安全边界	权限拒绝、确认、租户隔离和注入测试	越权、泄露或未经批准的副作用
可靠性	超时、重试、恢复、重复运行与故障注入	重复业务或未知状态被报成成功
效率	P95 延迟、token、工具次数和成功任务成本	超过生产预算或显著劣于基线
人工协作	接管原因、工单上下文和修正记录	该接管时继续执行或大量过早接管

评测报告必须保留样本级结果

管理层可以看场景成功率、成本和风险红线，技术团队还需要逐条样本结果。报告应包含数据集版本、系统版本、运行时间、环境、重复次数、评分器和已知限制。OpenAI 的Agent 工作流评测指南建议从轨迹调试过渡到可重复数据集与 eval run，这种分层也适合企业内部报告。

结论只能覆盖实际测过的范围

客服场景通过，不能推断财务或人事场景同样可靠；离线模拟通过，也不能证明生产故障率。NIST AI 800-2 初稿把评测分成目标定义、实施运行、分析报告三个阶段，并要求限定结论。企业签字页应列出未测语言、未测工具和仍需人工控制的任务。

凯乐丰项目如何使用这套方法

凯乐丰的私有化 AI 方案可以从真实业务任务、可观察轨迹和发布门槛入手，评估知识库、Agent 与现有系统的结合方式。若企业还在规划官网、外贸独立站、SEO/GEO 和私有化 AI 的整体路径，可查看凯乐丰解决方案。需要按现有接口与权限条件划定评测范围，可通过凯乐丰联系页面提交系统概况。

评测完成后的交付物

一次可复核的交付至少包括任务定义、脱敏数据集、评分规范、系统版本清单、样本级结果、汇总指标、失败分类、风险豁免和回归计划。OpenAI 的Evals 指南指出，评测用于检查输出是否满足组织设定的内容与风格标准；Agent 场景还需把工具结果和业务状态加入判定。

最终上线判断怎么写

上线结论应回答四个问题：哪些任务已达到门槛，哪些任务仍由人工处理，候选版本相对生产基线改变了什么，出现异常时怎样停止和回滚。不要写“Agent 已全面可靠”。更准确的表述是列出已验证场景、样本规模、成功率、红线事件、成本区间和证据日期。