Agent DLC：检索精度满分却答不出问题时，评估框架该怎么设计

一个内部HR政策助手，回答三个问题：绩效评估、福利登记、病假证明。chunk级检索精度——衡量每个被检索到的文档块整体是否与问题相关——三个问题全部拿到1.00满分。如果发布门槛只看这个指标，三个答案都会通过。

但把每个文档块拆成单独事实再逐一检查必要性，fact级精度分别是0.59、0.53和0.09。第三个问题意味着检索到的材料中大约九成的具体事实与所问无关。chunk级精度只问'这段话是否切题'，不衡量'这段话里有多少内容真正有用'。

AWS工程团队在博客中用这个实测案例引出Agent DLC（Agent Development Lifecycle）框架的核心论点：传统单元测试和CI/CD对代理仍然必要，但三个特性使其不充分。第一，代理是非确定性的，相同输入可以产生不同输出和执行路径；第二，提示词、工具描述、检索设置或记忆配置的改动可以以文本审查无法察觉的方式改变行为；第三，模型端点、知识库和外部API可以独立于代码仓库发生变化并影响代理行为。

框架将开发活动组织为两个嵌套循环。内循环是：评分→检查路径→改一个变量→重新评估，在固定标准下改进代理。外循环是：定义→构建→评估→发布→观察→反馈，允许标准本身变化。作者举了一个容易混淆的例子：如果生产用户要求代理替家人查询信息，但没有任何标准覆盖这个场景，这是外循环问题——需要定义授权边界并补充示例，然后用内循环去满足更新后的标准。把两者搞混，团队会试图用提示词修改去填补一个缺失的标准。

回到病假证明那个案例。提示词修改后，绩效评估问题从0.83提升到0.87，fact级精度从0.59跳到0.85；但病假证明的groundedness从0.39降到0.31，fact级精度从0.09降到0.04——一个改动，两个相反结果。诊断指向知识覆盖缺口：语料库中根本没有专门的病假政策文档，只有休假管理政策中的简短提及。告诉模型'严格基于检索内容回答'无法凭空补充缺失信息。

评估标准被组织为五个维度——领域理解、质量、责任、成本、性能——和三个层级：硬约束（布尔值，违反即阻止发布）、发布门槛（k次运行的通过率阈值）、仅监控（追踪但不阻塞）。作者特别指出一个案例：福利登记答案以0.90的groundedness通过，但其中包含一句'我注意到你的档案显示你的首选联系方式是社交媒体'——不存在这样的档案。模型把政策文档中的一个选项与公共FAQ中一条无关回答拼合，包装成关于用户的事实。高分的groundedness没有捕捉到这个虚假个人声明。

框架的实际建议是：选一个明确范围的业务任务，用一周建立评估基线。前两天由业务负责人和工程师商定验收标准、层级和阈值，准备20到30个黄金示例。第三到五天实现评估器并反复运行黄金集，发布基线包括失败案例。第二周改一个变量、在相同条件下重新评估，记录发布决定及其证据。作者强调分数可在不同运行间波动，边界通过可能变成失败，应结合重复运行和底层证据来解读差异。