评估 Gemini Enterprise 智能体：为什么运行轨迹比最终回答更重要

评估 Gemini Enterprise 智能体是一个系统且持续的过程：它不仅验证最终交付给用户的回答，也验证生产环境中可观察的工具调用轨迹。与仅基于“问答对”的评估不同，智能体分析还会检查执行期间记录的操作。

在当今的企业生态系统中，自主人工智能的部署已经从实验室实验转变为核心的业务运营架构。然而，这种转变为工程领域带来了深刻的挑战：如何确保自主智能体因正确的原因达成正确的结果？当模型可以访问私有数据库、事务型 API 以及 CRM 系统时，仅仅依赖其生成的最终文本质量是不可接受的架构风险。

智能体架构的本质决定了它包含多个对最终用户隐藏的处理步骤。智能体接收 prompt（提示词）、制定执行计划、选择工具、提取参数、执行操作、观察结果，最终合成回答。如果评估只关注这一链条的最后一环，就会忽略在执行轨迹中可能出现的严重延迟、Token 消耗过大、API 滥用以及潜在的安全漏洞。

“过程错误却得出正确答案”的危险性

运行 AI 智能体最大的风险在于，模型通过低效、不安全或带有幻觉的工具轨迹得出了技术上正确的答案。要在大规模扩展系统之前发现并纠正这种行为，评估指标必须深入检查每一个中间逻辑步骤，而不是仅仅关注系统的最终输出（output）。

为了更好地理解这种情况的严重性，试想一个内部支持智能体连接着两个系统：一个用于快速查询工单状态的 API（专为高并发、低延迟设计），以及一个包含公司全部历史数据的分析型数据库（专为夜间的繁重报表设计）。如果用户问“404 号工单的状态是什么？”，正确且最优的路径是智能体调用快速查询 API，并传递参数“404”。

然而，由于 prompt 工程的缺陷或模型对齐（alignment）问题，智能体可能会决定对分析型数据库进行全面的数据转储（dump），将数千条记录拉取到其 Token 上下文里，然后在内部搜索 404 号工单，最后向用户输出正确的答案：“404 号工单正在处理中”。从传统评估的角度来看（即比较生成的答案与预期答案），该智能体会获得满分。它表现得很有用、准确且有理有据。但从软件架构的角度来看，这个智能体执行了一项灾难性的操作，如果大规模执行，可能会导致数据库崩溃。

正因如此，现代智能体工程要求验证不能只停留在文本表面。团队需要观察已记录的工具调用序列及其结果。如果智能体遗漏预期工具、误用其他工具或改变预期顺序，即使最终回答看似令人满意，也应在评估流水线中标记该案例。

Agent Engine 中的轨迹评估（Trajectory Evaluation）是什么？

轨迹评估分析智能体可观察的路径：工具调用序列，包括所选工具、记录的参数和执行顺序。它补充最终回答评估，但并不声称能够访问模型的私有推理过程。

在 Agent Platform 文档中，评估、可观察性和追踪构成持续改进循环。实践中，轨迹是智能体已执行操作的可验证记录，可与团队定义的参考路径进行比较。

当我们在 Gemini Enterprise Agent Platform 中配置工具时，实际上是在给模型赋予“双手”。模型需要学会在正确的时间、以合适的力度、向着正确的方向使用这双手。轨迹评估过程正是用来监控这种动态学习曲线的。

在复杂的企业环境中，一条运行轨迹可能包含几十个步骤。一个金融智能体可能需要搜索报价、访问客户余额、计算转换率，然后生成报告。如果它弄错了这些调用的顺序（例如，在获取当日最新汇率之前就计算转换），即使数据提取本身是完美的，最终的结果也会是错误的。

结合回答指标与工具调用指标

将回答评估指标与轨迹分析结合起来，意味着为智能体创建一个全方位的计分卡。回答指标可确保用户获得流畅、准确的体验，而工具指标则可确保 IT 基础设施不会被人工智能压垮或误用。

在实践中，这需要一个包含两个维度的评估框架。一侧是针对具体用例选择的最终回答指标，例如事实依据、有效性或安全性。Google 表示 Agent Evaluation 支持预构建指标、自定义 Python 指标、LLM-as-a-judge 和自适应评分标准。

另一侧是轨迹标准：调用了哪些工具、使用了哪些参数以及执行顺序。团队可以先与参考轨迹进行精确比较；当存在多个有效路径时，再采用更灵活的标准。

下面的概念性测试用例将输入与预期路径分开记录：

{
  "prompt": "搜索目录并总结所请求的项目",
  "reference_trajectory": [
    { "tool": "search_catalog", "args": { "query": "所请求的项目" } }
  ]
}

这种组合方法可以防止在评估中出现假阳性。只有同时通过这两个标准的智能体才会被推向生产环境。这从根本上改变了 MLOps（机器学习运维）工作流，要求数据工程师、API 集成专家和 AI 工程师通力合作，共同定义模型的验收标准。

统一标准：从部署前 (Pre-deploy) 到部署后 (Pós-deploy)

在开发与生产监控阶段复用指标和验收标准，可以提高评估的一致性。参考数据集支持离线测试；在线监控则有助于在部署后发现性能下降和行为漂移。

在智能体工程中，一个常见的反模式（anti-pattern）是：在使用本地脚本进行受控环境测试时非常严格，但发布后，却仅仅关注响应时间和 HTTP 错误率等表面的遥测指标。Gemini Enterprise Agent Platform 在这方面提出了一种结构性的范式转变，旨在统一体验并为企业数据提供安全的基础设施。

为了确保在实验室中验证的行为能够转化为真实的生产环境表现，团队必须建立一套 AI CI/CD 流水线，将持续评估视为强制性要求，而不是可选功能。

这种统一架构的优势在于能够及早发现 Data Drift（数据漂移）或模型对指令遵循度的微妙退化。如果后端系统更改了 API 响应的格式，即使大语言模型仍然试图捏造一个看似合理的答案来掩盖错误，在线轨迹指标也会立即检测到智能体的“观察”阶段（observation）出现了故障。

以成熟的方式评估智能体需要严谨的工程规范。这意味着要放弃“大语言模型流利的语言能力等同于技术准确性”的错觉。智能体真正的智慧在于其能否以可预测、安全且可审计的方式与周围的世界进行交互——而这正是轨迹评估和 Vertex AI 的高级工具所致力于从头到尾衡量和保证的能力。

常见问题解答 (FAQ)

我们整理了 IT 经理和云架构师在实施自主智能体评估流水线时最常见的问题。