跳到正文
观猹观猹学社

让评测成为 Agent 迭代的主控回路

从一次“看起来正确”的回答走向可统计、可诊断、可回归的评测体系，让真实失败持续推动 Agent 迭代。

✦全文约 6100 字 阅读需 20 分钟 Derrick 最近更新 2026.08

01课程介绍#

本节课围绕 Agent Evals 展开：怎样定义评测标准、沉淀真实测试集、记录完整运行轨迹，并用数据定位幻觉、漏答、错答和流程卡点。

评测不是开发结束后的检查，而是决定下一步修什么、如何验证以及何时可以交付的主控回路。

你将学到什么

  • 建立适用于企业真实场景的 Agent 评测维度与流程。
  • 用评测数据定位问题，并区分规则、知识、模型与工具层故障。
  • 建立异常监控、回归测试和 Skill 迭代机制。
  • 理解 Demo 走向生产所需的可靠性、安全与验收边界。

02课程回放#

正在准备课程回放…
本节课的核心判断 Agent 的黑盒、随机性和长链路特征决定了：一次成功不能证明系统可靠，一次修复也不能证明整体变好。 评测不是开发末尾的验收动作，而是决定下一步开发什么、怎样修改以及何时可以交付的主控回路。

03课程课件#

完整课件正在载入…

04一个智能客服为何越修问题越多#

课程用“能否加钱发顺丰”的电商客服案例，展示了 Agent 从 Demo 走向真实业务时会连续暴露的四类问题。

  1. 规则没有被定义 用户追问“补差价能否发顺丰”，知识库只有默认圆通规则。开发者只能临时向商家确认并补充政策。
  2. 计算过程正确，业务结果错误 Agent 能按距离和重量算价格，却没有处理滑雪板等超长尺寸，最终金额与真实报价相差很大。
  3. 局部信息正确，整体目标失败 价格计算无误，但用户要求一天内从上海送到新疆，物流时效根本无法满足。
  4. 修复知识后，交互体验退化 Agent 把新增的所有规则一次性输出两百多字，事实更完整，却没有直接回答用户的简单问题。

开发者在每一步都响应迅速：发现问题、确认业务、修改规则、重新测试。问题不在于工程师不努力，而在于把传统软件中“发现 Bug 后逐个修复”的思路直接套在概率系统上，无法证明系统整体正在变好。

测试可以证明问题存在，却不能证明问题不存在；对 Agent 来说，一次通过甚至只能说明这一次采样通过。

05为什么 Agent 不能只靠传统测试#

特征 带来的问题 评测上的要求
黑盒 无法像确定性程序一样形式化证明内部推理完全正确 通过真实输入输出和运行轨迹做经验测量
随机性 同一输入多次运行可能得到不同答案和路径 重复采样，用成功率、分布和置信区间表达结果
耦合性 修改一个 Prompt、Skill 或知识片段，可能影响其他任务 局部评测之后仍要跑整体回归
隐性标准 客户往往说不清什么是好，但看到结果后能指出不满意 尽快提供可讨论的 MVP，在反馈中形成标准
分布漂移 模型、用户行为、知识与产品定位持续变化 评测集需要更新、重加权和退役机制

如果重复运行后 95% 正常、5% 失败，问题就不再是简单的“有无 Bug”，而是：这 5% 会造成什么业务后果，人工兜底成本是多少，客户能否接受，以及怎样缩小高风险失败的比例。

验证才是 Agent 开发的瓶颈

AI 让生成代码、文档和方案变得便宜，但验证成本并没有同比下降。一家工厂每天能生产 100 个部件、却只能检查 10 个，真实产能仍由质检能力决定。Agent 开发也是如此：生成速度越快，越需要把投资放在评测、诊断和反馈闭环上。

不要把大量评测误认为前期设计失败 对概率系统而言，测试、观察、修改和再次验证本来就是主要工作。课程给出的经验判断是，成熟项目可能把大部分时间投入评测与迭代，而不是一次性实现功能。

06什么是评测驱动开发（EDD）#

Evaluation-Driven Development 的关键不是“多写几个测试”，而是让评测从开发末尾的质量门禁，变成开发全过程的控制回路。

EDD 主循环 定义最小契约 → 快速做出 MVP → 构建评测集 → 批量运行并定位失败 → 修改系统 → 全量回归 → 更新评测集与交付边界。
  1. 尽快得到可讨论对象先实现最短核心路径，不等待所有需求和例外都被提前穷举。
  2. 让失败暴露真实需求把用户、业务专家和生产反馈转化为具体样本，而不是只记录一句“效果不好”。
  3. 用数据选择下一步根据失败频率、风险、影响层级和修复成本决定迭代优先级。
  4. 每次修改都跑回归验证目标问题是否改善，同时检查原有能力有没有退化。
  5. 让测试集一起进化业务目标和使用方式变化时，评测权重、样本和标准也必须调整。

MVP 先约定五件事

前期不必写出完整系统规范，但必须形成最小契约，让开发、评测和客户反馈围绕同一个边界。

目标Agent 为谁完成什么任务，解决哪一段业务问题。
完成标准怎样算任务完成，哪些核心场景必须覆盖。
禁止事项不能做哪些判断、承诺、数据访问和外部操作。
可用能力允许调用哪些知识、Skill、工具、模型和系统。
人工批准哪些情况必须澄清、转人工或等待明确授权。

例如电商客服 MVP 可以先约定：覆盖最常见的发货问题；只根据可追溯政策回答；规则之外不做断言；允许查询发货知识库；涉及特殊尺寸、时效承诺和价格例外时转人工。

07先留痕，才有可能系统分析#

开发过程中的需求讨论、方案取舍、错误、修复和评测结果都应被记录。文档暂时不用并不可怕；真正危险的是需要回顾时发现没有证据，无法解释为什么这样设计，也无法判断旧问题是否重新出现。

Open仍在讨论的问题、假设、风险和待验证事项。
Decisions已经做出的决策、依据、负责人和影响范围。
Resolved已经解决的问题、修复方式和对应回归用例。
Archive已失效但仍需追溯的方案与评测；退役不等于删除。

Codex、Claude Code 等工具通常也会在本地保存会话记录。它们可以作为原始证据，让另一个 Agent 只分析用户输入、决策变化或失败路径。但聊天记录不能替代结构化文档：文档读取更快、边界更清晰，也更适合团队协作与版本管理。

08评测对象是完整运行轨迹#

普通对话常被简化成“输入—输出”，企业 Agent 则还包含模型、Runtime、环境、检索、Skill、工具、状态与人工动作。只检查最终答案，可能把碰巧猜对的结果误判为系统能力。

  1. 输入与上下文用户表达、系统指令、历史状态和可见业务数据是否正确。
  2. 意图与规划是否识别出真实任务，是否选择了合理步骤和停止条件。
  3. 知识检索有没有找到正确证据，排序、时效和引用是否可靠。
  4. Skill 与工具调用是否调用正确能力、使用正确参数，是否出现绕路或多余调用。
  5. 中间状态每一步输出是否足以支撑下一步，错误有没有在链路中被放大。
  6. 最终结果事实、格式、语气、业务价值和风险是否满足契约。
  7. 运行环境模型版本、知识版本、接口、网络、权限和外部系统是否正常。

路由评测也应检查“走到了正确目标”之外的效率：如果 Agent 最终选对了 Skill，却先读取许多无关文档、经历多次无效调用，结果虽然正确，成本和延迟仍然不合格。

09构建第一版评测集#

青春版：先覆盖四种回答边界

  1. 可以直接回答 信息完整、规则明确，Agent 应给出简洁而正确的结果。
  2. 需要先澄清 缺少尺寸、地点、时间或对象等关键条件，不能直接下结论。
  3. 只能回答一部分 已知信息可以回答，但必须明确未覆盖部分与下一步动作。
  4. 不能回答 超出业务范围、证据不足或风险过高时，应拒绝、转人工或说明边界。

进阶版：让评测具备诊断能力

维度 要解决的问题 示例
真实案例 系统是否解决用户实际遇到的问题 历史咨询、人工工单、真实失败会话
边界与长尾 主流程之外的少见条件是否被正确处理 新疆、超长件、极端时效、大批量订单
诊断样本 失败时能否定位到意图、检索、工具或生成层 专门验证知识命中或数据清洗的单阶段题
保密与抗过拟合 开发者是否只适配了自己熟悉的题型 专家持有集、盲测样本、未公开组合
新鲜度 模型、政策、用户和系统变化后是否仍然有效 定期加入新规则、新接口和近期线上案例

评测样本从哪里来

AI 生成快速扩展常规、随机和格式变化样本，但不能独立代表真实分布。
生产失败最有价值的反馈来源；清洗后加入回归集，避免同一问题重复出现。
领域专家提供模型和开发者难以想到的判断角度、隐性规则与高风险案例。
组合变异把多个因素组合，例如地区、尺寸、时效和批量采购同时出现。
盲注入在团队不知情时注入受控异常，检验系统和评审流程是否真的能发现问题。

课程借鉴 LIGO 的盲注入案例：研究团队曾在观测设备中接收一个高度逼真的模拟信号，在不知情的情况下完成分析与同行评审，最终再揭示这是一次对检测能力和流程可靠性的测试。企业 Agent 也可以使用受控的错误数据、接口异常或隐藏样本，验证团队是否只会在已知问题上表现良好。

不要把测试集变成训练答案 如果所有样本和标准都持续暴露给开发过程，系统可能只是在适配固定题目。应分离开发集、回归集与保密验证集，并持续用新的真实流量检查体验是否真的改善。

10如何判断失败发生在哪一层#

评测结果不应只有“通过/失败”。每次运行至少要区分以下结果，避免把环境问题误判成模型问题，也避免在标准未定义时强行给系统打分。

结果类型 含义 下一步
任务通过 环境正常，轨迹和结果满足标准 保留结果，继续观察统计稳定性
任务失败 意图、检索、工具、状态或生成结果不正确 定位责任层并增加回归案例
环境失败 接口、网络、权限、数据或测试基础设施异常 修复环境后重跑，不能计入模型能力
评估器失败 Judge 超时、规则冲突或自动评分本身不可信 修复评估器并人工复核相关结果
标准未定义 利益相关者尚未对“正确”形成共识 补业务决策，不把它伪装成技术 Bug
取舍变化 质量、语气、延迟、成本之间需要重新权衡 调整目标与权重，并记录决策依据

代码、LLM Judge 与人工怎样协作

  1. 确定性规则交给代码格式、字段、数值范围、引用存在性、工具参数和权限边界用断言检查。
  2. 开放质量交给 LLM Judge相关性、完整性、语气和解释质量可由强模型按量表初筛。
  3. 关键样本交给领域专家高风险、标准争议、Judge 不一致和业务长尾由真人裁决。
  4. 用人工结果校准 Judge比较自动评分与专家评分，持续修订量表、示例和适用范围。

项目早期可以使用更强模型作为 Judge，先提高诊断质量；流程稳定后，再评估是否用更低成本模型承接部分明确任务。无论使用什么模型，都不能把自动评分当成无条件真值。

11评测集本身也要版本化#

  1. 新增发现未覆盖问题时加入新案例，记录来源与影响。
  2. 升级高风险或高频问题提高严重级别，进入发布阻断集。
  3. 转为回归问题解决后不要删除，继续验证它不会在后续修改中复发。
  4. 重新加权产品从辅助人工作业转向自动执行时，任务分布和风险权重必须变化。
  5. 修订案例、答案或评分标准本身有误时，修正并留下变更原因。
  6. 退役归档确定不再适用的内容移入 Archive；保留历史，不直接删除。

每次评测应记录模型版本、Prompt/Skill 版本、知识版本、环境、样本版本和代码 commit。否则分数变化后无法判断究竟是哪一项改变带来的结果。

12安全评测是另一套问题#

任务评测问的是“系统能否完成工作”；安全评测问的是“攻击者能否让系统做不该做的事，以及暴露面和后果是什么”。二者会共享日志与测试基础设施，但威胁模型、样本和修复方式都不同。

威胁建模攻击者是谁、能接触什么入口、希望获取或改变什么。
提示词注入外部内容能否覆盖系统规则，诱导泄露指令、知识或凭据。
工具与权限Agent 能否越权读取、写入、删除、付款或对外发布。
沙箱与联网代码执行、文件访问和网络能力是否被限制在必要范围。
可接受风险不存在绝对安全；根据用户、数据和业务后果决定防护强度。
评测只能发现风险，不能代替安全工程 测出越权或注入问题后，通常还要修改权限、网络、沙箱、密钥、接口和产品流程。不要只靠更长的 Prompt 或私有 Skill 保护敏感能力。

13Demo 与可交付产品的边界#

Demo 可以在限定输入、少量样本和受控环境中展示核心价值；可交付产品则要在约定范围内，以可接受的质量、成本和延迟稳定工作，并明确哪些情况需要人工介入。

判断项 Demo 可交付
场景范围 少数设计样本与理想路径 客户确认的核心、边界和失败场景
结果证据 一次成功演示 重复运行统计、专家评审与真实试用
过程可见性 只看最终输出 轨迹、版本、成本、错误和人工动作可追溯
失败处理 失败后开发者现场修复 拒答、澄清、重试、降级、转人工和恢复机制明确
验收边界 证明方向值得继续 客户按约定范围和指标确认可用

整体评测通过不意味着所有子模块都可以忽略，但时间有限时可以按风险抽取关键阶段。反过来，子模块全部通过也不能替代端到端评测，因为跨模块组合仍可能产生新的失败。

14MemU：从 Agent 记忆到企业 FDE 服务#

MemU 是面向 Agent 的开源记忆服务，希望让不同 Agent 和设备共享对用户的长期理解，逐步形成个人 LLM Wiki。记忆并没有统一标品：情感陪伴 Agent 更关注事件、偏好与关系，Coding Agent 更关注代码风格、项目决策和开发习惯，因此企业接入通常需要围绕场景定制。

B2B2C 为什么更难

面向企业产品、最终又服务消费者时，需求会同时受企业和终端用户影响。即使合同最初写清范围，消费者反馈、产品定位与业务策略仍会持续变化，记忆字段、权重和调用方式也要跟着调整。MemU 团队因此开始从单一 Memory 组件，扩展到更端到端的企业 Agent 服务。

FDE 同时承担咨询与工程交付

Forward Deployed Engineer 需要先进入业务现场，判断当前模型真正适合哪些场景、对齐预期并设计路径；然后把方案接入客户已有数据和系统，完成能持续使用的工程结果。

咨询价值识别高 ROI 场景、解释能力边界、定义阶段目标和风险。
交付价值补齐客户缺少的 Agent、全栈、集成和部署能力，并对结果负责。
情绪价值持续沟通、让进展可见、风险前置，并用客户理解的语言解释技术。
长期价值把一次交付变成信任、复购、行业 Know-how 和可复用产品资产。

结果价值决定项目能否验收和回款，沟通与信任决定客户是否继续合作。情绪价值不是一味态度友好，而是让客户始终知道发生了什么、为什么这样做、风险在哪里，以及下一步会看到什么。

15定制化服务怎样规模化#

传统定制项目难以扩张，是因为每一单都需要大量重复人力。AI Coding 降低了实现成本，但真正决定 FDE 公司能否规模化的，仍是服务过程能否标准化、组件能否复用，以及是否建立行业品牌和可信案例。

  1. 选择行业与高价值任务积累同类客户，而不是每次进入完全陌生的业务。
  2. 标准化需求发现沉淀访谈、上下文收集、评测和方案设计模板。
  3. 快速交付 POC组合标准产品、既有组件与 AI Coding，在短周期内提供可用证据。
  4. 从项目抽取共性把连接器、Skill、知识结构、评测集和 Runtime 能力模块化。
  5. 保留场景定制层针对客户流程、数据、权限和界面做低成本适配。
  6. 用案例建立信任让下一位同行客户看到真实结果、行业理解和持续服务能力。

面对已有数字化基础的企业，应尽量接入现有数据库、知识和业务系统，减少破坏性替换；仍依赖 Excel 和人工流程的企业，可能要先补数字化基础，再谈复杂 Agent。技术路线必须服从客户当前成熟度。

FDE 的能力结构正在变化

AI Coding 越强，单纯实现功能的稀缺性越低。FDE 更需要端到端全栈判断、需求表达、客户沟通、行业知识、评测能力和关系维护。客户希望听到的不只是“可以做”，而是服务方基于行业经验指出他们尚未发现的问题。

课程也提醒：Skill 与高质量会话可能成为模型未来最有价值的训练数据。使用 AI 放大个人 Know-how 的同时，要判断哪些经验可以公开复用，哪些涉及客户数据、商业秘密与长期竞争力，不能无边界地交给外部模型。