AI 智能体持续评估：实用方法

可靠的 AI 智能体应以其产出的结果来衡量，而不是以回答是否流畅来衡量。这个区别看似简单，却会改变自动化的设计方式。一个智能体可以写出令人信服的回复、在技术上无误地调用工具，却仍然取消错误的订单、错误分类一个 lead，或在错误的系统中创建工单。

将智能体投入生产的压力，让这一问题变得更加明显。在 LangChain 的报告 State of Agent Engineering 2026 中，57% 的受访者表示已经有智能体运行在生产环境中。然而，尽管 89% 的受访者报告具备某种程度的可观测性，只有 52.4% 会使用测试集执行离线评估。这个缺口至关重要：记录事件不等于证明质量。

持续评估是连接业务意图、智能体行为与运营结果的系统。它应在每一次重要变更之前、期间和之后运行：包括模型、prompt、工具、策略、集成、知识库或路由规则。

AI 智能体应评估什么

直接的答案是：评估任务、轨迹以及对流程产生的效果。单独的最终回答很少足够。

智能体在一个序列中行动。它理解请求、选择上下文、决定是否使用工具、执行操作、处理部分返回结果，并结束或转交案件。每一步都可能引入故障。因此，分析单元不只是生成的文本，而是完整的执行过程。

有三个实用层面：

• 结果质量：目标是否达成？对于客服智能体，请求是否被正确解决。对于销售智能体，lead 是否按照正确标准完成资格判定。
• 轨迹质量：智能体是否使用了正确的信息源、工具和权限？一个轨迹是对决策、工具调用、消息和中间状态按顺序形成的记录。
• 运营质量：智能体是否遵守成本、延迟、安全性和尝试次数的限制？

2026 年 6 月发布的研究 Monitoring Agentic Systems Before They're Reliable 提出，应从质量、适当性和效率三个维度观察智能体系统，并覆盖三个范围：一次执行内部、不同执行之间，以及系统结构层面。其实际含义很直接：仅靠 API 错误面板，无法发现那些在技术上正确执行、但决策并不恰当的情况。

使用可观察的标准定义成功。“提供优质服务”是一种愿景。“正确分类意图、在 CRM 中登记请求，并在两分钟内将例外转交给人工”则是一项可评估的规范。

如何将业务目标转化为测试案例

直接的答案是：基于真实决策和相关例外构建评估集，而不仅是基于理想示例。

一个评估集是一组经过版本管理的案例，用于代表智能体必须解决的情形。每个案例应包含输入、可用上下文、允许使用的工具、通过标准，以及在适用时的执行后预期状态。

从五类案例开始：

1. 高频案例：代表主要业务量，并保护流程效率。
2. 关键案例：发生频率低，但具有较高的财务、法律或声誉影响。
3. 模糊案例：需要确认、检索额外上下文或转交人工。
4. 对抗性案例：包含冲突指令、不完整数据，以及诱导不当使用工具的尝试。
5. 生产故障：每一个已被理解的事故都应成为永久的回归案例。

最后一类最有价值。它将一次孤立故障转化为运营记忆。如果一个智能体应用了过期的商业政策，该案例不应在修复后消失。它应纳入测试套件，并在后续变更前执行。

避免接受任何“看似合理”文本的测试。在事务性任务中，标准必须覆盖最终状态。如果智能体声称更新了资料，请验证字段是否已在正确的系统中修改。如果它表示已发送提案，请验证收件人、文档以及所应用的商业规则。

2026 年 4 月的研究 AlphaEval: Evaluating Agents in Production 通过评估完整的智能体产品，而非仅评估模型，进一步强调了这一差异。感知到的表现取决于模型、指令、工具、界面、权限和环境共同构成的整体。

哪些指标能够揭示智能体是否在改进

直接的答案是：结合业务、质量、风险和效率指标。单一的正确率会制造盲区。

第一个指标应反映流程的目的。它可以是首次联系解决率、合格转化率、处理时长、收入挽回、返工减少或文档合规性。这就是结果指标。

随后，跟踪质量指标：

• 正确完成率；
• 恰当人工转交率；
• 对政策和业务规则的遵循度；
• 信息源和工具的正确使用率；
• 已知故障复发率。

还应纳入风险指标。衡量被 guardrails 拦截的操作、超出范围的访问尝试、被撤销的修改、涉及敏感数据的案例，以及需要后续复核的决策。Guardrail 是限制危险操作的技术或流程规则，例如批准超过权限级别的折扣，或访问超出授权用途的数据。

最后，跟踪效率：端到端延迟、每项完成任务的成本、工具调用次数、尝试次数和放弃率。一个解决更多案例、却将成本和延迟提高三倍的智能体，可能会降低整体流程的表现。

不要设定“95% 正确率”这样的通用目标。容错度应随操作而变化。一个总结会议的智能体可以接受更主观的评估。一个更新资料、放行付款或为客户提供合同指引的智能体，则需要更严格的标准、状态确认和自主性限制。

如何评估主观回答，而不盲目信任另一个模型

直接的答案是：使用自动评估器实现规模化，但要通过持续的人工审核对其进行校准。

并非所有任务都有唯一答案。语气、清晰度、完整性、实用性和对上下文的适配性都是主观维度。在这些情况下，LLM 作为裁判可以将智能体输出与结构化评分量表进行比较。评分量表必须准确说明评估什么、哪些证据重要，以及哪些条件会导致回答不通过。

但评估器本身也会出错。它可能偏好冗长回答，将自信误认为准确，或复制模型自身的偏见。因此，自动判断不应被视为独立的真相。

稳健的实践包含四项控制：

1. 按任务使用具体标准，而不是要求泛泛地评估质量。
2. 分离内容、安全和执行评估。让一个裁判负责所有方面会削弱诊断能力。
3. 定期进行人工抽样，将自动结论与专家判断进行比较。
4. 衡量分歧。如果人工评估者之间存在分歧，质量规则仍然不够明确。

Anthropic 在一篇 2026 年 4 月的事后分析 中报告称，智能体产品中的质量问题起初难以与用户反馈的正常波动区分开来，内部评估也未能立即复现这些问题。这一教训很重要：当生产环境暴露出实验室未捕捉到的信号时，评估必须随之演进。

如何监控智能体，而不让可观测性变成噪声

直接的答案是：按异常、分布变化和业务影响进行监控。

可观测性是重建一个系统做了什么、以及为何得出某一结果的能力。对于智能体，这要求追踪模型版本、prompt、检索到的上下文、工具调用、权限、中间输出、最终结果以及后续反馈。

最常见的错误是保存所有轨迹，却不定义优先级。成熟的运营需要与故障假设相关联的告警。例如：

• 转交人工客服的数量突然增加；
• 在要求提供证据的主题中，无来源回复增加；
• 某项工具的使用偏离历史模式；
• 更换模型后完成率下降；
• 单次执行的尝试次数增加；
• 智能体的声明与系统中已确认状态不一致。

还应监控 drift，即行为随时间发生的偏移。它可能源于请求结构变化、知识库更新、新模型版本、集成变更或外部 API 性能恶化。智能体可能仍在“运行”，却依然交付更差的结果。

可观测性应支持版本之间的比较。如果不对 prompt、策略、工具和数据集进行版本管理，团队就无法将回归归因于可能的原因。目标不是积累日志，而是缩短从发现异常、理解其来源到实施安全修复之间的时间。

在不引入新回归的情况下，修复故障的运营周期是什么

直接的答案是：将每项变更视为可测试的假设，并通过渐进式发布推进。

这一周期从基线开始。在优化之前，按任务类型、用户细分、所用工具、成本、延迟和人工干预率记录当前表现。没有基线，改进只是一种印象。

随后，遵循严谨的节奏：

1. 对故障进行分类

确定故障属于理解、上下文检索、策略、工具、权限、集成还是体验问题。“智能体出错了”不是有用的诊断。

2. 创建或更新评估案例

使用安全数据复现故障。定义正确结果以及证明通过的信号。该案例将保护运营免于再次发生同类问题。

3. 在可能的情况下每次只改变一个变量

同时修改 prompt、模型、工具和规则会使因果归因变得困难。在关键流程中，优先采用受控实验。

4. 执行离线评估和集成测试

离线评估验证已知案例中的行为。集成测试则确认工具、权限和外部状态能否在真实环境中正常运行。

5. 逐步发布

使用有限比例的流量、缩小操作范围或扩大人工监督。自主性应随着性能证据增长，而不是基于声明的信心增长。

6. 重新评估对流程的影响

局部改进可能恶化整体运营。例如，如果智能体正确解决的案例变少，减少人工转交就是负面结果。

这一方法使智能体更接近关键系统中已熟知的一项原则：质量是一种需要持续验证的属性。对于编排多个步骤的运营，Centriu Flow 等平台可以集中管理规则、审批和控制点，但治理仍然依赖清晰的结果标准和活跃的评估周期。

未来 30 天从何开始

直接的答案是：选择一个范围明确的流程，定义一项结果指标，并构建一个规模小但具有代表性的测试套件。

第一周，梳理智能体所做的决策及其在流程中预期产生的效果。识别错误决策在哪些环节会带来最高成本。第二周，收集 30 到 50 个真实案例，包括错误、例外和模糊请求。第三周，为结果、策略、成本和延迟实施自动化标准。将人工审核保留给主观性更强和影响更大的案例。

第四周，在每次变更时执行测试套件，并建立分析生产故障的固定机制。不要试图一次衡量所有内容。初始收益来自于明确那些此前隐含的内容：智能体可以做出什么决策、在什么条件下做出，以及企业如何确认该决策是正确的。

可靠的智能体并非那些看起来最自主的智能体，而是那些不断积累证据证明其运营良好、能够识别边界，并在不重复同样错误的前提下持续改进的智能体。