AI智能体 - 评估与监控 初探

在 2025 年的 AI 工业界，我们已经达成了一个共识：构建一个 Agent 可能只需要一个周末，但让它稳定地跑在生产环境里，需要一整套严密的评估与监控体系。

由于智能体具有随机性（Stochastic nature）和自主性（Autonomy），传统的软件 QA（质量保证）方法在面对它们时往往显得苍白无力。本方案将基于《评估与监控》的核心理念，结合业界最前沿的Contractor（承包商）模型和LLM-as-a-Judge范式，为您拆解一套完整的工业级设计。
为什么评估与监控（Evaluation and Monitoring） 被视为智能体通向工程化成熟的“最后一公里”，目前这部分也是大部分人忽略或认为难度一般的环节，但它其实是业界较难的痛点，做好该环节比预训练环节还要困难重重，这里就是初探。

一、 评估体系的基石：多维度指标（KPI）设计

评估一个智能体不能只看“答案对不对”，必须建立一套立体的指标矩阵。

1. 核心性能指标 (Efficiency & Cost)

• TTFT (Time to First Token)：首字响应延迟。对于交互式 Agent，这决定了用户的第一感知。

• End-to-End Latency：整个任务流（可能包含多次工具调用）的总耗时。

• Token Efficiency：衡量智能体是否在做“无效思考”。

  • 公式：
    Efficiency=Total_Information_GainTotal_Tokens_UsedEfficiency = \frac{Total\_Information\_Gain}{Total\_Tokens\_Used}Efficiency=Total_Tokens_UsedTotal_Information_Gain​

• Resolution Rate (解决率)：在不经过人工干预的情况下，智能体独立完成任务的比例。

2. 语义与质量指标 (Quality)

• 忠实度 (Faithfulness)：特别是在 RAG 场景下，回答是否严格基于参考资料。
• 相关性 (Relevance)：回答是否精准命中了用户的意图。
• 幻觉率 (Hallucination Rate)：经过事实核查后的错误陈述占比。

3. 工具调用准确性 (Tool Accuracy)

• 参数召回率：智能体是否传对了 API 所需的所有必要参数。
• 调用序列正确性：在复杂任务中，先查数据库还是先调搜索引擎，逻辑是否闭环。

二、 轨迹评估（Trajectory Evaluation）：解剖智能体的思考过程

如果说结果评估是“看分值”，那么轨迹评估就是“看监控”。评估智能体在达成目标的过程中，步子走得对不对。

1. 轨迹匹配模式

在业界，我们通常将智能体的实际行动轨迹与“黄金轨迹（Ground Truth Trajectory）”进行对比：

• 精确匹配 (Exact Match)：适用于金融、医疗等严谨领域。步骤顺序必须完全一致。
• 集合匹配 (Set Match)：只要用到的工具都对了，顺序不限。
• 逻辑剪枝 (Logic Pruning)：自动识别并扣除轨迹中的“冗余步骤”（如反复调用同一个报错的 API）。

2. 实战案例：自动化对账 Agent

• 预期轨迹：[SQL查询] -> [数据对比] -> [生成报告]。
• 实际轨迹：[SQL查询] -> [SQL查询(重试)] -> [搜索Google如何对账(异常)] -> [生成错误报告]。
• 评估结论：轨迹失控，得分为 0.2。原因是数据库权限配置错误导致 Agent 陷入了异常推理。

三、 LLM-as-a-Judge：构建自动化“裁判”系统

面对“有用性”、“礼貌程度”等主观指标，人工评估难以扩展。我们采用高性能模型（如 Gemini 2.5 Pro）作为“裁判”。

1. 评判标准（Rubric）的工业级设计

不要简单问 LLM “这个好不好”，要提供细颗粒度的量表。

量表示例：客服智能体同理心评估

• 1分：机械化回复，完全忽略用户不满情绪。
• 3分：有礼貌用语，但无法针对用户具体问题表示遗憾。
• 5分：准确识别情绪，首先安抚用户，并在解决问题后主动提供补偿方案。

2. 裁判流程架构

1. 输入：用户原始查询 + 智能体完整轨迹 + 最终答案。
2. 参考：业务 SOP（标准作业程序）文档。
3. 输出：结构化 JSON，包含各维度得分、扣分理由及改进建议。

四、 生产环境监控（Observability）：漂移与异常检测

智能体上线后，环境是动态的。我们需要一套类似 Datadog 的实时监控系统。

1. 漂移检测 (Drift Detection)

• 概念漂移：用户的提问习惯变了。例如，原本问技术问题的人突然开始问优惠政策，Agent 原有的知识库可能失效。
• 性能漂移：随着底层模型版本更新（甚至是静默更新），同样的提示词效果变差了。

2. 异常行为警报

• 递归死循环：Agent 在两个工具调用之间反复横跳（例如 A 依赖 B，B 又依赖 A）。
• 费用熔断：单个会话消耗 Token 超过阈值（如 $5），强制中断并介入人工。
• 合规性围栏：实时检测 Agent 输出是否包含敏感词、隐私数据或违规指令。

五、 进阶设计：从“智能体”到“高级承包商 (Contractor)”

这是 2025 年企业级 AI 的核心演进。我们要把智能体当作一个法律意义上的外包公司来管理。

1. 合约 (Contract) 的编码化

不再是模糊的指令，而是一份数字合约：

• 交付物 (Deliverables)：“一份包含 5 个维度分析的行业研究报告”。
• 约束条件 (Constraints)：“禁止引用维基百科，必须使用 Bloomberg 数据”。
• 控制权 (Controls)：“单次运行成本不得超过 $1”。

2. 智能体之间的子合约分解

一个“主承包商 Agent”接收任务，并与多个“子承包商 Agent”签订合约。

• 案例：软件开发 Agent 接收“开发电商网站”的主合约。
• 子合约 A：交付前端组件库。
• 子合约 B：交付高并发数据库索引。
• 评估方式：每个子合约完成后，由主 Agent 按照合约准则进行验收，不合格则打回重做。

六、 研发工作流集成：Google ADK 实践

在实际开发中，我们建议将评估嵌入 CI/CD 流水线。

1. 交互式创建 (ADK Web)：开发者在 UI 中调试出满意的结果，一键点击“Save as Evalset”。
2. 程序化测试 (Pytest)：每次代码提交时，后台自动跑一遍所有的评估集。

deftest_agent_performance():evaluator=AgentEvaluator(agent_id="finance_bot")results=evaluator.run_evalset("q4_audit_set")assertresults.overall_score>0.85assertresults.max_latency<5.0

3. 持续回归：即使代码没变，也要定期重跑评估集，以监测底层模型是否发生“静默退化”。

实际案例

针对电商客服场景，使用Google ADK (Agent Development Kit)落地自动化评估流水线，不仅仅是写几个测试用例，而是要构建一套从“对话采集”到“自动评分”再到“回归校验”的闭环工程。

以下是贴合电商实际开发场景的完整落地方案：

1️⃣、 电商客服智能体架构与“合约”定义

在开始评估前，我们先定义一个典型的电商客服智能体及其合约 (Contract)。这确保了评估是有据可依的，而不是盲目的。

1. 智能体能力范围

• 工具 A (check_order)：查询订单状态、物流信息。
• 工具 B (process_refund)：发起退款（需符合 7 天无理由且未发货/已退货）。
• 工具 C (knowledge_search)：检索优惠券规则、尺码建议。

2. 承包商合约 (Agent Contract)

在 ADK 中，我们为退款逻辑定义严格的约束：

合约约束：只有当订单状态为DELIVERED且签收时间 <7天时，才允许调用process_refund。严禁在未确认用户实名信息前修改退款路径。

2️⃣、 落地步骤：从手动到全自动

第一步：使用adk web采集“黄金标准” (Gold Set)

不要手动写复杂的测试 JSON。首先运行adk web进入交互式界面。

1. 模拟对话：开发者扮演用户，输入：“我 3 天前买的衣服质量不好，帮我退款。”
2. 引导推理：确保 Agent 正确调用了check_order-> 确认日期 -> 调用process_refund。
3. 保存会话：在Eval选项卡中，点击“Create Evaluation Set”，命名为refund_policy_v1.evalset.json。
   • 这会自动捕获：用户输入、Agent 的思考过程（Thought）、工具调用参数、以及最终生成的完美回复。

第二步：配置评估标准 (test_config.json)

在你的 Agent 项目根目录下创建配置文件，定义“及格线”。

{"criteria":{"tool_trajectory_avg_score":1.0,// 轨迹得分：退款流程必须步步踩准，不许有多余动作"response_match_score":0.8,// 回复相似度：最终话术需与标准答案 80% 相似"llm_judged_empathy":4.0// 自定义指标：由 LLM 评判，同理心需达到 4 分（满分 5）}}

第三步：编写电商专用的 LLM 评判准则 (Custom Rubrics)

为了让自动化裁判（LLM-as-a-Judge）懂电商，我们需要在 ADK 中集成自定义 Rubric。

# rubrics/ecommerce_rubric.pyRUBRIC_REFUND_POLICY=""" 你是一名资深电商合规审计员。请根据以下标准评估 Agent： 1. 合规性：是否在退款前检查了 7 天有效期？(权重: 50%) 2. 准确性：退款金额是否计算正确？(权重: 30%) 3. 服务态度：是否使用了温和的抱歉语？(权重: 20%) 输出 1-5 分，并给出扣分详情。 """

3️⃣、 自动化流水线集成 (CI/CD)

一旦有了evalset.json和test_config.json，就可以将其接入自动化环境。

1. 命令行自动化执行

在你的 CI 脚本（如 GitHub Actions 或 Jenkins）中运行：

# 运行评估并生成详细报告adkeval./my_ecommerce_agent\./evalsets/refund_policy_v1.evalset.json\--config_file_path=./test_config.json\--print_detailed_results

2. 核心评估代码示例 (程序化接入)

如果你想在代码中根据评估结果决定是否“上线”新模型，可以使用 ADK 的AgentEvaluator：

fromgoogle.adk.evaluationimportAgentEvaluatorasyncdefrun_pipeline():evaluator=AgentEvaluator(agent_module_path="./my_agent")# 加载之前在 Web UI 保存的黄金数据集results=awaitevaluator.evaluate(eval_set_path="./evalsets/refund_policy_v1.evalset.json")forcaseinresults.eval_case_responses:print(f"Case:{case.name}, Passed:{case.is_passed}")# 如果轨迹得分低于 1.0，说明流程有错，触发预警ifcase.metrics['tool_trajectory_avg_score']<1.0:trigger_alert(f"退款流程逻辑发生漂移！建议人工检查。")# 触发警报逻辑 (例如发送到飞书/钉钉)

4️⃣、 实际场景中的“漂移监控”与异常处理

电商大促期间（如双11），由于规则变化（如“预售不退定金”），Agent 容易出现性能漂移。

5️⃣、案例总结：这套方案解决了什么问题？

1. 解决了“不敢改 Prompt”的问题：每次修改代码或 Prompt 后，一键运行adk eval，几秒内知道有没有搞坏原有的退款逻辑。
2. 解决了“评估全靠感觉”的问题：通过response_match_score(ROUGE) 和LLM-as-a-Judge，将质量量化。
3. 缩短了研发周期：以前需要测试人员手动测试，现在通过evalset.json实现了“录制一次，自动回归一万次”。

七、 总结与法则

评估与监控不是 Agent 的“附件”，而是其“核心”。

• Rule of Thumb 1：没法度量，就没法优化。如果你说你的 Agent “变聪明了”，请给出指标得分的变化。
• Rule of Thumb 2：评估要分层。单元测试测工具调用，集成测试测轨迹，LLM 评判测用户体验。
• Rule of Thumb 3：拥抱“承包商”思维。让智能体在明确的规则、预算和验收标准下运行，这是建立人类信任的唯一途径。

结语：智能体正在从“有趣的玩具”变成“可靠的劳动力”。通过这套评估与监控设计，我们可以将原本不可预测的 AI 行为，转化为可预测、可审计、高价值的业务成果。

参考资料：

1.Survey on Evaluation of LLM-based Agents, 2025. 2.Agent-as-a-Judge: Evaluate Agents with Agents, 2024. 3.Google ADK Documentation. 4.Antonio Gulli 《Agentic Design Patterns》