KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
07. 怎样建立 Agent 的质量门禁？ — keel 龙骨
“回答看起来不错”不是生产验收。长上下文、检索、compaction、工具和恢复会互相影响，必须有固定数据集、基线、成本和失败门禁，才能证明优化真的带来提升。
“回答看起来不错”不是生产验收。长上下文、检索、compaction、工具和恢复会互相影响，必须有固定数据集、基线、成本和失败门禁，才能证明优化真的带来提升。
指标分层
| 层次 | 指标 | 失败含义 |
|---|---|---|
| 事实与权限 | Recall@k、ACL leakage、citation precision | 找不到关键证据、越权或伪造引用 |
| 运行可靠性 | replay 一致性、重复 effect、恢复时间、迟到 ack | 崩溃后丢步、重复副作用或无法接管 |
| 模型与上下文 | task success、关键事实召回、compaction 保真度 | 摘要改变事实或 JIT 丢失必要证据 |
| 运营成本 | input/output token、延迟、poll 次数、单运行成本 | 质量提升无法覆盖资源开销 |
LongBench提醒长上下文评估要按任务和长度分层；Lost in the Middle则说明把内容放进窗口不等于模型会有效使用。评估集应包含短/长、证据在开头/中部/结尾、权限拒绝、重复唤醒和 worker 重启样本。
门禁而不是报表
把阈值写成发布策略，例如：
recall_at_k >= baseline
citation_precision == 1.0
acl_leakage == 0
duplicate_effects == 0
cost <= budget
p95_latency <= SLO
任一硬安全项失败即拒绝；质量项可以按业务降级，但必须留下原因和版本。项目的 QualityGate 与 06_evaluation_gate.py 用确定性数据演示这个闭环：指标计算、失败列表和 passed 结果可以进入 CI。
追踪和归因
每次运行需要关联 run、model、retriever、compaction policy、tool task 和 trace/span。至少记录估算 token 与 provider 实际 usage、候选 chunk、被丢弃项及原因、lease attempt 和最终 receipt。OpenTelemetry 的 GenAI semantic conventions可作为跨模型、工具和检索的属性对齐起点。
本章实践
建立 20 条最小诊断数据集，分别跑 full history、JIT retrieval、JIT+compaction 三个版本；输出质量、token、延迟和恢复对照表。每次策略修改必须能回答“哪个指标变了、为什么、是否值得发布”。
本章检查点
- 质量提升来自更多 token 还是更好的检索？如何做消融？
- citation precision 很高但 Recall 很低时，门禁应如何处理？
- SLO 失败后是停止运行、降级回答，还是转人工？依据是什么？