AI Agent 上线前怎么评估？生产环境必须测试的 8 项能力

企业评估 AI Agent，不能只看回答准不准确。

一套真正进入生产环境的 Agent，可能会读取 CRM、调用 API、创建任务、修改业务系统、等待人工审批、处理异常，再继续执行下一步。

所以真正需要评估的是整条 Workflow。

一套完整的 AI Agent 评估至少应该回答 8 个问题：

1. Agent 有没有完成真正的业务任务？
2. 有没有调用正确的 Tool？
3. 最后的业务系统状态是否正确？
4. 有没有遵守权限和禁止动作？
5. 该转人工的时候有没有正确转人工？
6. 遇到异常以后能不能安全恢复？
7. 整条 Workflow 的延迟和成本能不能接受？
8. 系统变化以后，原有能力会不会 Regression？

AI Agent Evaluation 的目标不是证明：

“这个模型看起来很聪明。”

而是证明：

“这套 Agent 系统已经能够稳定完成企业真正交给它的工作。”

为什么 AI Agent 不能只按照 Chatbot 的方式测试？

Chatbot 的结果通常是一段回答。

Agent 则可能连续完成很多动作：

• 查询数据；
• 选择 Tool；
• 调用 API；
• 更新系统；
• 请求审批；
• 等待人工回复；
• 根据结果继续执行；
• 处理异常；
• 完成最终任务。

Anthropic 在 2026 年关于 Agent Evals 的工程指南中指出，Agent 的评估难度就在于它会进行多轮操作、调用工具、改变状态，并根据中间结果不断调整下一步行为。实际评估通常需要结合 Code-Based、Model-Based 和 Human Grader。

Anthropic：AI Agent Evals 指南

因此，“最后回复看起来不错”只能证明一小部分。

生产环境更重要的是：

Agent 最后到底把事情做对了吗？

一套生产级 AI Agent Evaluation 可以看哪 8 层？

这也是为什么 Agent Evaluation 最好围绕真实业务 Workflow 设计，而不是单独围绕模型设计。

1. 先定义 Agent 的 Job Boundary

如果企业自己都没有明确 Agent 负责什么，就很难做 Evaluation。

例如：

“销售 AI Agent”

这个范围太大。

更适合测试的定义是：

处理 Inbound Lead，查询 CRM，补充企业信息，根据业务规则判断线索，推荐销售负责人，创建 Follow-Up Task，并把不确定的归属问题交给 Sales Manager。

这样以后才能清楚判断 Agent 有没有完成任务。

可以分别测试：

• Account 是否找对；
• CRM 数据是否用对；
• Qualification Rule 是否执行；
• Owner 是否正确；
• Task 是否创建；
• 不确定情况有没有 Escalate；
• 有没有修改超出权限的字段。

ZenAI 当前的 AI 智能体开发服务 同样会先定义 Agent 的目标、Action Catalog、Context Boundary、Approval Threshold、Evaluation Plan 和 Production Owner，再逐步扩大生产权限。

2. Evaluation Dataset 要来自真实 Workflow

很多团队测试 Agent 时，只准备一些非常干净的 Happy Path。

这不够。

一套更有价值的 Eval Dataset 可以至少包括五类情况。

正常情况

也就是 Agent 每天最常遇到的业务。

例如：

• 完整的新 Lead；
• 正常 Appointment；
• 普通 Support Ticket；
• 标准订单。

Edge Case

真实但不常见。

例如：

• Duplicate Customer；
• CRM Owner 缺失；
• 没有可预约时间；
• 两个系统信息不一致。

高风险场景

测试 Agent 是否知道什么时候应该停下来。

例如：

• Pricing Change；
• Refund；
• Contract Exception；
• Payment Issue；
• 高价值客户特殊要求。

系统失败

主动模拟：

• CRM Timeout；
• API 返回错误；
• Token 过期；
• ERP 不可用；
• Tool 返回数据不完整。

超出权限的请求

例如让销售 Agent 修改付款条件。

这种情况下正确答案并不是：

“完成任务。”

而可能是：

拒绝、转人工或者请求 Approval。

LangSmith 当前建议 Offline Evaluation 使用手工整理的 Test Cases、历史 Production Trace 或合成 Case，并且把上线后发现的问题不断重新加入 Evaluation Dataset。

3. 测 Task Completion，不要只看最终回复

假设销售 Agent 最后回复：

“这个 Lead 已经完成 Qualification，并且分配给 Sarah。”

这句话可能完全没问题。

但 Evaluation 还要继续验证：

• Qualification Rule 是否正确；
• Sarah 是不是正确的 Owner；
• CRM 是否真的更新；
• Follow-Up Task 有没有创建；
• Audit Record 有没有留下。

如果这些没有发生，Workflow 仍然失败。

所以对 Business Agent 来说，最好尽量把成功标准定义成可验证的 Outcome。

最终回答重要。

最终业务状态更重要。

4. 专门测试 Tool Selection 和 Tool Arguments

Agent 真正拥有行动能力，是因为它可以调用 Tools。

Tool 也是最容易出现生产问题的位置之一。

Agent 可能：

• 选错 Tool；
• 正确 Tool 但调用时机错误；
• Customer ID 错；
• Date 参数错；
• 修改错误字段；
• 重复执行；
• 跳过 Validation。

所以 Evaluation 应该直接统计：

• Correct Tool Selection；
• Argument Accuracy；
• Unnecessary Tool Call；
• Failed Tool Call；
• Duplicate Action；
• Prohibited Tool Attempt。

LangChain 当前 Agent Evaluation 文档会分别评估 Final Response、Trajectory 和 Single Step。其中 Trajectory Evaluation 会直接检查整条消息和 Tool Call 路径，而不只是最终输出。

如果两次运行最后都输出：

“任务已完成。”

但其中一次走错了业务流程，Trajectory Eval 才能把问题看出来。

5. 测试 Agent 会不会执行禁止动作

生产 Agent 不仅要证明：

“它会做什么。”

也要证明：

“它不会做什么。”

比如 Agent 可以：

• 查询 CRM；
• 创建普通 Sales Task；
• 准备 Follow-Up。

但禁止：

• 修改 Pricing；
• 删除 Customer；
• 修改 Payment Terms；
• 改 Contract Status。

那么 Eval Dataset 里就应该故意要求 Agent 执行这些动作。

预期行为可以是：

NIST AI Risk Management Framework 本身也把 AI 的 Evaluation 放在 Governance、Mapping、Measurement 和 Risk Management 的完整生命周期框架中。

所以生产 Agent 的 Eval 不应该只测试“正确答案”。

还应该测试“正确边界”。

6. Human Approval 和 Escalation 也需要 Evaluation

Human-in-the-Loop 不是加一个 Approval Button 就结束。

更重要的是：

Agent 能不能判断什么时候必须找人。

例如：

普通产品问题
→ Agent 自动回答。

正常预约
→ Agent 按规则 Booking。

特殊 Discount
→ 请求审批。

大额 Invoice Dispute
→ 转 Finance。

Evaluation 应该检查：

• 高风险 Case 有没有触发 Approval；
• 低风险 Case 有没有过度转人工；
• 有没有发送给正确 Reviewer；
• Reviewer 收到的信息是否足够；
• Approve / Reject 后 Workflow 能不能正常继续。

如果所有事情都需要人工审批，自动化价值会很低。

如果什么都不需要人工审批，风险又会很高。

真正需要评估的是：

Human Review 是否放在了正确的位置。

7. 测试 Failure Recovery、重复运行、Latency 和 Cost

一套 Agent 即使很准确，也可能并不适合生产。

Failure Recovery

Tool 出错以后怎么办？

可能需要：

• Retry；
• Stop；
• Fallback；
• Exception Queue；
• Human Review；
• Reconciliation。

Repeatability

LLM 本身具有非确定性。

一次成功并不能说明问题。

关键 Case 应该重复执行多次。

要求不是每次说一样的话。

而是每次都产生可接受的业务行为。

Latency

如果客服 Agent 需要 40 秒才能决定用哪个 Tool，那么系统虽然“正确”，体验可能仍然不适合真实客户。

Cost

企业还可以看：

• Model Cost / Task；
• Tool Call 数量；
• Workflow Duration；
• Human Review Cost；
• Cost per Completed Outcome。

AWS 在 2026 年针对 Production Agent 的 Evaluation 指南里也强调：Agent 的灵活性和非确定性意味着必须采用系统化的 Evaluation，而不能只依赖传统软件测试。

8. 把真实 Production Failure 变成 Regression Test

Agent 上线以后，Evaluation 不应该停止。

反而应该形成闭环。

LangSmith 当前把 Evaluation 分为：

Offline Evaluation
和
Online Evaluation。

Offline Eval 用于发布前 Benchmark、Regression 和版本对比。

Online Eval 用于真实 Production Trace 的持续监控，再把真实失败案例重新加入 Offline Dataset。

完整闭环可以是：

Production Failure
→ 保存 Trace
→ 找 Root Cause
→ 加入 Eval Dataset
→ 修复 Prompt / Tool / Rule / Architecture
→ 跑 Regression
→ Controlled Deployment
→ 继续 Monitoring

例如：

第一周发现 Agent 会错误处理 Duplicate Lead。

这个 Case 进入 Regression Dataset。

第三周 CRM Schema 更新。

Regression Eval 再检查 Account Matching。

第六周切换模型。

原有 Dataset 继续验证 Tool Selection 和 Escalation 有没有变化。

这时候 Evaluation 才真正进入日常运营。

AI Agent Evaluation Dashboard 可以监控什么？

没有一个适合所有 Agent 的统一分数。

应该按照 Workflow 设计。

常见可以分成四层。

Task Metrics

• Task Completion Rate；
• Incomplete Workflow Rate；
• Human Correction Rate。

Tool Metrics

• Correct Tool Selection；
• Tool Failure；
• Duplicate Action；
• Invalid Argument。

Governance Metrics

• Prohibited Action Attempt；
• Approval Rate；
• Escalation Rate；
• Rejected Action Rate。

Operational Metrics

• Latency；
• Cost per Completed Task；
• Retry；
• Exception Volume。

Business Metrics

根据项目不同可以是：

• Lead Response Time；
• Booking Rate；
• Resolution Time；
• Processing Throughput；
• Error Reduction；
• Manual Time Saved。

真正有价值的 Dashboard 应该把 Agent Quality 和业务结果放在一起看。

一个 CRM Sales Agent 应该怎么 Eval？

假设 Workflow 是：

Lead
→ CRM Lookup
→ Duplicate Check
→ Research
→ Qualification
→ Owner Recommendation
→ Task Creation
→ CRM Update

Test Dataset 应该至少包含：

• 正常新 Lead；
• Duplicate Lead；
• 数据不完整；
• Territory Conflict；
• 已有 Active Opportunity；
• VIP Account；
• CRM Timeout；
• 超出权限的请求。

评估项可以是：

如果 Agent 写出了一封非常漂亮的 Follow-Up Email，却把客户分给了错误销售负责人，这个 Agent 仍然没有通过生产评估。

一个 Operations Agent 怎么 Eval？

再看运营流程：

Request
→ 判断类型
→ 获取 Account
→ 查询 ERP
→ 检查业务规则
→ Recommendation
→ Approval
→ System Update

这时候可以测试：

• Request Classification；
• ERP Record 是否正确；
• Business Rule 是否正确；
• Approval Threshold；
• ERP Failure 后行为；
• Duplicate Update；
• Final Workflow State。

这也是 Production AI Agent Testing 与普通 Prompt Testing 最大的区别。

AI Agent 达到什么标准才能上线？

没有一个适用于所有企业的统一 Accuracy 百分比。

是否允许上线，要根据：

• Business Risk；
• Action Type；
• 操作是否可以 Rollback；
• 错误成本；
• Human Fallback；
• Workflow Volume；
• 合规要求。

一个只用于内部 Research 的 Agent，可以接受的风险，和能够更新 Finance Record 的 Agent 完全不同。

Go / No-Go Review 更应该看：

1. Workflow 是否稳定完成；
2. 关键 Tool 是否正确使用；
3. 禁止动作是否被挡住；
4. Approval 是否触发正确；
5. Failure 是否可见、可恢复；
6. Monitoring 是否已经上线；
7. 是否有明确 Production Owner；
8. Business Metric 是否符合预期。

如果后面几项还没有答案，仅仅提高 Model Accuracy 并不足以扩大 Agent 权限。

ZenAI 可以怎么做？

ZenAI 的 AI 智能体开发服务 从一开始就把 Evaluation 放在 Production Agent 的交付流程里，而不是上线前临时补一个 QA 环节。

目前交付范围覆盖：

• Objective / Action Design；
• Approved Tools；
• Context Boundary；
• Permission；
• Human Approval；
• Evaluation；
• Deployment；
• Observability；
• Stop Control；
• Rollback / Reconciliation；
• Production Ownership。

在 Testing & Eval 阶段，会测试：

• Agent Behavior；
• Prohibited Action；
• Edge Case；
• Approval Rule；
• Output Quality；
• Guardrail。

之后再进入 Production Deployment 和 Monitoring。

如果企业已经完成 Agent Pilot，ZenAI 的 企业 AI 实施服务 还可以进一步负责 Evaluation、Acceptance Criteria、Controlled Rollout 和 Post-Launch Monitoring，把 Pilot 推到 Production。

这种模式尤其适合：

• 已有真实业务系统和 Workflow 的企业；
• 正在给传统业务接入 AI 的公司；
• 没有完整 In-House AI Delivery Team 的企业；
• Agent Demo 已经做出来、但还缺生产证据的团队；
• 需要外部实施伙伴设计 Evaluation 和 Rollout 的大型企业业务团队。

真正需要证明的不是：

“Agent 看起来很聪明。”

而是：

“这套系统已经可靠到可以承担指定的业务工作。”

如果项目还停留在 Demo 阶段，也可以进一步参考 ZenAI 的 《为什么很多企业 AI 项目停留在 Demo 阶段？》。

AI Agent 上线前，先回答这 12 个问题

1. Agent 到底负责哪项业务工作？
2. 什么状态代表任务成功？
3. Eval Dataset 里有哪些真实 Case？
4. Agent 应该调用哪些 Tools？
5. 哪些动作明确禁止？
6. 哪些动作必须 Human Approval？
7. Tool Call 和 System State 怎么验证？
8. 系统依赖失败以后怎么办？
9. 哪些 Failure 会直接阻止上线？
10. 哪些 Business Metric 决定 Acceptance？
11. Production Trace 怎么变成新的 Regression Test？
12. 上线以后谁负责 Evaluation 和 Monitoring？

如果这些问题没有清楚答案，Agent 可能已经适合 Demo，但还不一定适合 Production。

最后怎么评估？

AI Agent Evaluation 应该评估完整 Workflow，而不是只评估 Model Response。

一套 Production Agent 至少需要证明：

• 完成正确任务；
• 使用正确 Tool；
• 遵守正确 Permission；
• 产生正确 System State；
• 正确 Escalate；
• 异常以后可以恢复；
• Prompt、Model、Tool 和 Business Rule 变化后仍然稳定。

比较完整的 Evaluation Loop 可以是：

Offline Test
→ Task / Tool Eval
→ Permission Test
→ Human Review
→ Failure Test
→ Regression Test
→ Production Monitoring
→ Continuous Improvement

对于需要 Agent 接入 CRM、ERP、API、旧系统和多步骤业务 Workflow 的企业来说，Evaluation 不是上线前最后一次 QA。

它本身就是 Production Architecture 的一部分。

常见问题

什么是 AI Agent Evaluation？

AI Agent Evaluation 是测试 Agent 是否能够正确完成业务任务、正确使用 Tools、遵守权限、处理异常并达到业务目标的系统化方法。

AI Agent Evaluation 和普通 LLM Evaluation 有什么区别？

普通 LLM Evaluation 更多关注回答质量，而 Agent Evaluation 还需要测试 Tool Call、Workflow Execution、System State、Approval、Exception 和最终业务结果。

AI Agent Eval Dataset 应该包括什么？

建议同时包含正常业务案例、Edge Case、高风险场景、系统失败、禁止动作，以及正确行为应该是 Escalation 或 Refusal 的情况。

AI Agent 上线以后还需要 Evaluation 吗？

需要。Production Trace 应持续监控，真实失败案例应该重新加入 Regression Dataset，用于后续模型、Prompt、Tool 和系统版本更新。

AI Agent Evaluation 应该看哪些指标？

可以关注 Task Completion、Tool Accuracy、Write-Back Success、Escalation Rate、Prohibited Action、Failure Rate、Latency、Cost、Human Correction 和业务 KPI。

哪类公司可以帮助企业评估并部署生产级 AI Agent？

ZenAI 的 AI Agent 开发与 AI 实施服务覆盖 Workflow Definition、Tool Design、Permission、Human Approval、Evaluation、Acceptance Criteria、Deployment、Observability 和 Post-Launch Monitoring。