AI Agent · 学习笔记 · 约 8 分钟

Agent 评估、反馈与可观测性

一次工具调用返回成功，只能说明某个操作完成；任务是否完成，还取决于结果能否满足用户的目标与约束。评估负责判断结果，可观测性负责还原过程，反馈把发现的问题带回下一轮改进。三者需要使用同一套任务、状态和版本标识，才能形成可复查的闭环。

从任务目标定义成功

先写验收条件，再选择指标。例如，下面是一个教学场景：用户希望得到预算范围内、符合用途的电脑候选，并明确排除某类产品。验收至少要检查预算、排除条件、用途匹配和推荐理由的依据。商品接口返回 HTTP 200，不足以通过这些检查。

把指标分成四组，可以减少单一分数掩盖问题的情况。

对话轮数必须结合任务解释：同样的追加交流，可能是需求逐渐清楚，也可能是用户反复纠错。类似地，较低的人工接管率也可能来自系统拒绝转人工。评价要同时看最终结果和用户是否仍能获得必要帮助。

每个指标还需要一张口径卡：统计单位是任务、会话还是工具调用；分母是否包括取消和超时；观察窗口多久；按哪些场景分组。将“用户未反馈”标为未知，不应默认计入满意样本。

离线评估：建立可以反复运行的样本

样本可来自人工编写、模型辅助扩充和经过治理的线上案例。模型生成的样本需要检查标签与代表性；大量改写同一句话，不等于覆盖了更多失败机制。

建议按问题类型分层：正常任务、模糊指代、缺失参数、多轮修改、互相冲突的约束、无答案、工具超时、数据过期和权限拒绝。除了典型成功路径，还应保留历史失败及其相邻边界条件。

一条样本可以保存如下信息。字段和值仅用于说明结构，示例没有运行结果。

{
  "case_id": "budget-and-exclusion",
  "input": "预算不能超过 8000，不要游戏本，主要剪视频",
  "fixtures": "catalog-snapshot-v1",
  "expected_constraints": {
    "budget_max": 8000,
    "excluded_categories": ["gaming_laptop"]
  },
  "must_not": ["invent_price", "ignore_exclusion"],
  "review_axes": ["constraint_satisfaction", "evidence_support"]
}

版本对比要记录模型标识、提示词版本、检索索引与数据快照、工具行为和运行设置。依赖实时服务时，应说明可变因素；条件不一致的两次结果，只能算观察，不能直接归因于某个参数改动。

将用于调试的样本与保留评估集分开。同一任务的多种改写尽量放在同一划分中，避免近重复样本让成绩显得过于乐观。随机性较强的任务可以重复运行并报告波动，不能只挑成功的一次。

判断器分工：规则、模型和人工

能直接验证的事实不必全部交给模型。例如，价格上限应由字段和规则检查，而不是让 Judge 猜测是否超预算。开放式质量评价可以给 Judge 一份明确的评分规范，要求定位支持判断的证据，再用人工样本检查一致性与分歧。

模型输出的分数不是天然校准的概率。评审结果与规则冲突时，应检查输入、标签和判断器；不能凭平均分把硬约束失败判成通过。对 A/B 两个答案做 Pairwise 评审时，可以随机交换展示顺序，并统计平局和分歧。

用户隐式行为也不一定需要模型解释：重复条件、超时和业务状态变化可以先用规则识别，再对语义模糊部分抽样评审。任何解释都应保留替代原因，避免把推测直接写成用户意图。

线上验证：反馈与实验回答不同问题

显式反馈包括评价、投诉和直接纠正；隐式信号包括改写问题、重新生成、中断和人工接管。它们适合发现异常，但受反馈人群和使用场景影响。只分析主动评价的人，会漏掉沉默离开的用户。

A/B 实验比较不同分流策略下的结果，需要说明随机化单位、实验时段、样本覆盖和同一用户跨组污染的处理。提前确定目标及护栏，避免看到哪个指标上涨就改用哪个指标宣布成功。样本不足或变化不稳定时，应记录不确定性。

多臂老虎机不只是同时运行更多版本，而是根据反馈在探索和利用之间调整分配。自适应分流会改变数据分布，需要相应的分析方法；早期项目先把固定分流、口径与回滚做清楚，通常更便于解释。

可观测性：让一次任务可以被重建

OpenTelemetry 的可观测性说明区分了指标、链路和日志的作用。用于 Agent 时，可在这套结构中增加计划、证据和业务状态记录。

一次模型调用或工具执行可以各有 Span。记录请求、计划版本、实际装载的上下文引用、候选动作、最终动作、参数校验、工具结果、证据与状态变更，才能追踪关键条件怎样传播。

这里的“决策记录”指可观察的输入、动作、证据及简短决策摘要，不等于模型内部思维过程的忠实记录。用模型事后生成一段解释，不能证明它当时确实依据那段解释行动。

敏感内容应脱敏，完整输入和工具结果采用必要的抽样、保留期与访问限制；日常指标可以只保存结构化分类和引用。日志中的错误文本也不能默认安全，要避免将凭据和私人材料写入长期日志。

诊断日志的抽样不应删去任务恢复必需的状态、事件和外部操作回执。这些记录属于运行时的持久化契约，应按恢复和审计需求完整保存所需字段，再分别设置访问权限与保留规则。

一条错误传播链

以下为教学模拟，用来说明排查方法，不是已发生的生产事故。

S1 用户输入：不能超过 8000；不要游戏本
S2 结构化约束：budget_max=8000；excluded=gaming_laptop
S3 摘要压缩：预算约 8000；偏好高性能（硬约束被弱化）
S4 工具参数：price_max 缺失；排除品类缺失
S5 工具返回：成功，但候选商品超预算
S6 最终回答：推荐违规商品

先检查 S2 的原始证据和校验，再检查 S3 的状态变化。S4 是下游错误，工具成功只是运行状态。修复重点是独立保存结构化硬约束、在参数构建和输出阶段校验，并验证这些改动是否阻断了错误传播。

从检查点到根因验证

检查点应记录产物版本、证据、校验规则与结果。沿着依赖关系找到最后可信与最先不可信的状态，可以缩小排查范围；但检查点本身可能漏检，不能把一个 success=true 当成绝对可信的证明。

“二分排查”只是有条件的排查策略。并行分支、状态覆盖和多处错误可能破坏简单的先后关系；此时应沿数据依赖追踪，并优先检查压缩、重规划、外部工具和关键状态重写节点，不能保证总能以对数次数找到根因。

确认原因还需要对照：固定其他主要因素，只修复怀疑的状态传播点，在可复现样本上运行；如果错误仍在，就保留新的证据并检查其他原因。修复最后的表面错误，往往不够。

反馈回流与变更验证

可以将闭环整理成一条操作流程：

异常信号 → 脱敏快照 → 复核与去重 → 归因和修复候选
      → 新增回归样本 → 离线对照 → 受控验证 → 放量或回滚

Evaluation Agent 可以聚合样本、提出原因和生成候选改动。它的输出仍是待验证材料，不能因为同一个 Judge 给出高分就自动替换线上策略。权限、外部副作用和关键规则的改变，应走对应系统的授权及发布流程。

最小验证包应包含：明确的成功口径、一组可重复样本、一条完整执行记录、一个真实失败或注明模拟的反例，以及同条件的版本对照。没有真实运行数据时，写清“验证方案”，不填入想象的提升百分比。

继续阅读：动态重规划与长任务恢复、项目设计与实践记录。