先理解
刚接触这个知识点
补齐先备概念，读原理与反例，再用自己的话解释为什么。
从核心原理开始 →知识目录选择核心方向与细分内容
理解 → 实现 → 排错 → 取舍
可执行验收与质量边界
把结果、权限、证据、资源成本和恢复能力转化为可判定条件，再组合成发布门禁。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
建议先理解：
RAG 的证据流与故障定位 →幂等、未知结果与任务恢复 →这个知识点，你想学到哪一步？
按当前基础选择起点，也可以依次深入。遇到不熟悉的概念，先回到核心原理；完成后用知识练习检查理解。
知识单元目录
LEARN · PRACTICE · REFLECT
知识学习与个人记录
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 可执行验收与质量边界
先理解核心原理
先备概念：业务后置条件、接口契约、回归测试
验收要把“成功”转换成外部可观察的事实。质量得分可用于比较，但越权、重复写入等禁止事实不能由流畅表达或其他高分抵消。
从接口断言走向任务断言
后端测试不会因为接口返回“已退款”就认定退款成功，还会核对交易记录。Agent 多了一层自然语言，同样需要把用户目标拆成可检查条件。生成报告的契约可以要求目标期间的数据覆盖完整、数字与来源对应、产物保存成功；允许不止一种措辞。
把禁止动作从平均分里拿出来
假设报告内容很完整，却读取了无权访问的薪资表。若把内容与权限各计一项平均，系统可能仍获得及格分；这是评分规则违背业务约束。先判权限与副作用硬门槛，再比较内容覆盖、解释质量与成本。硬门槛来自任务风险分析，并非所有评测都需要同一套阈值。
契约也需要反例
在同一数据初态分别提供正确报告、漏一部门的报告、引用不存在的报告、合规拒绝。检查验收器是否分得清。如果没有证据支撑结论，应允许“未知”并转复核；让裁判必须二选一只会把证据缺口藏进分数。以上是教学设计，未运行新评测。
用一个问题检查理解
Agent 如何定义可执行验收契约，避免只凭“回答看起来不错”上线？
先为任务定义输入环境、允许操作、最终业务结果及硬约束，再分别评测。业务结果要查数据库或产物，权限和禁止动作作为不能被平均分抵消的硬门槛，成本与时延记录分布和超限。固定数据、工具版本和用量口径，加入无权限、工具失败、取消和恢复样例。规则能判断的条件使用确定性校验；开放文本才使用人工或模型评分，并校准评审一致性。
实现与取舍
验收契约先描述任务世界
例如“查询项目告警并生成处理建议”，输入不止一句 prompt，还包括用户身份、授权项目、告警快照、工具契约、系统时间和允许预算。输出契约明确需要哪些告警、每条建议关联哪个证据、是否允许创建工单。业务后置条件用数据库记录或产物校验，而不是仅对最终文字做相似度比较。空结果、无权限和未知状态也要定义正确行为，系统主动拒绝不一定是失败。
结果质量和硬约束分别判定
建立 outcome、policy、grounding、budget、recovery 等维度。答案内容合理却读取了其他租户数据，必须判失败；成功创建工单但创建了两次，也不算通过。权限越界、未授权副作用与超过硬预算不能用高语言评分平均掉。证据引用和结构化字段用规则校验，开放式建议可用人工或经过校准的模型评审。LangSmith 提供最终响应、单步与轨迹等评测视角，工程上应根据任务契约组合，而不是认为某个单一 evaluator 足够。
数据集和执行环境需要版本记录
每个样例保留 case_id、数据版本、预期结果、允许工具、错误注入配置及是否为保留测试集。真实失败可经脱敏形成回归案例，避免只挑容易成功的题。模型、prompt、检索、工具 schema、状态机和数据源变化都可能影响行为，因此实验记录完整配置与轨迹。用于调参的数据与最终发布测试分开，避免不断修改系统去迎合一套固定答案。非确定性任务重复执行并记录方差，错误类型分组比一个平均成功率更有诊断价值。
发布门禁要能指向具体失败
先运行确定性检查，再运行成本较高的语义评审；失败输出包含 case_id、违反条件、相关工具调用和业务状态差异。门禁阈值根据产品风险确定，不能凭空给所有 Agent 一个通用百分比。上线后继续收集超时、重复副作用、拒绝率和用户纠正，按来源更新样例。以下代码把正确结果、授权、幂等和资源上限组合为硬判定，只是本地评分器，不是实际 Agent 平台；时延和花费必须来自可信采集，不能让被测 Agent 自报一个低数字就通过。
代码示例
业务后置条件与硬门槛评分器
Python 标准库可运行。输入应由测试工具和资源监控产生；示例不验证日志真实性，也不评审建议文字。
def evaluate(run):
checks = {
'outcome': set(run['ticket_ids']) == {'INC-42'},
'permission': set(run['read_projects']) <= {'p1'},
'no_duplicate': len(run['ticket_ids']) == len(set(run['ticket_ids'])),
'budget': run['cost'] <= 0.20 and run['duration_s'] <= 30,
}
return {'passed': all(checks.values()), 'failed': [k for k,v in checks.items() if not v]}
good = {'ticket_ids':['INC-42'], 'read_projects':['p1'], 'cost':0.10, 'duration_s':8}
bad = {**good, 'read_projects':['p1','p2']}
print(evaluate(good))
print(evaluate(bad))
预期输出
{'passed': True, 'failed': []}
{'passed': False, 'failed': ['permission']}工程推演
- 场景
- 假设工程场景：运维 Agent 可以生成建议并创建一次工单。
- 设计决策
- 数据库核对目标工单，授权读取与重复创建作为硬失败，文字建议另行评分。
- 验证目标
- 验收目标是同一正确答案在越权或重复操作时也被发布门禁拦截。
- 适用边界
- 这个评分器只覆盖声明的契约，不能证明未覆盖场景均可靠。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层没有唯一参考答案的系统设计建议如何评审？
开放任务没有唯一文本答案，需要解释契约如何容纳不同方案。
参考解答
按约束评审而非与某段文字相似：先约定负载、一致性、故障和成本条件，再查方案是否自洽、遗漏关键约束、取舍是否有理由。保存多个可接受方案以及明确错误的反例；不确定的边界交给专家复核，不能因采用不同框架就扣分。
沿着这个回答继续深入
第 2 层两个方案都满足约束，但一个更便宜，必须判它更好吗？
父问允许多个合法方案，下一步是合法方案之间如何排序。
参考解答
只在约定的目标和可信成本口径下比较。低成本方案若牺牲恢复时限或未来扩展能力，应先判断这些是否必需约束；约束都满足时可以报告成本优势，也可保留质量与维护成本的不同取舍，避免把未观测成本当零。
沿着这个回答继续深入
第 3 层成本只有供应商标价，没有实际调用量，能写“节省一半”吗？
父问使用成本排序，继续检验排序所需证据是否存在。
参考解答
不能。应记录实际请求、输入输出用量、缓存口径和重试，再算同一任务分布的成本差；只有标价时只能说明价格假设。若执行证据不足，将成本结论标为待验证，而不是给方案补一个准确百分比。
第 1 层如何防止模型评审更喜欢长答案而不是正确答案？
引入语义裁判后，必须继续检验评分是否偏向表达形式。
参考解答
把准确性、必要覆盖和冗余拆开，隐藏作者与模型身份，交换答案顺序，用内容等价但长度不同的校准对检查偏好。不能简单截断长答案，因为尾部可能有决定性限制；应看同一事实是否被正确支持，长度作为独立风格指标。
第 1 层上线指标变好但离线回归下降，如何判断数据分布变化？
固定契约上线后，还要区分行为变化与任务构成变化。
参考解答
先对齐成功定义、任务单位、时间窗和版本，再按任务类型、难度与用户群比较。线上总分可能因简单任务占比上升而变好。用固定旧分布复测，同时按当前分布抽样；若同层下降而总体上升，优先解释构成变化，不能直接宣称新版本更好。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
只读建议变成自动发信
改变的条件：输出从可审阅文本变为不可撤回的外部发送。
延伸问题：原有语言质量验收够用吗？
推导与参考解答
不够。新增收件人、授权目的、批准内容摘要与实际发信记录的硬检查，影子评测只调用替身。措辞质量仍可语义评审，但发错对象必须独立失败，不能靠正文正确抵消。先把目标外部状态写成契约，再选择验收方式。
保持不变的原理：成功由允许的业务事实定义，禁止动作独立判定。
没有标准答案的容量规划
改变的条件：未来负载不确定，合理方案存在多个。
延伸问题：怎样评审而不伪造精确真值？
推导与参考解答
提供负载区间和故障假设，检查容量推导、瓶颈识别与降级策略是否对应条件。将假设和已测数据分开，做参数变化后的敏感性推演；评分覆盖解释质量，不把某个数据库名称当唯一正确答案。
保持不变的原理：验收应检查约束与推导，不能以文本形式替代事实。
易错点
- 只评最终文字，不检查业务状态
- 越权被语言质量平均分抵消
- 测试环境和线上工具语义不同
- 持续用测试集调参却仍称为独立测试
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能把成功定义为可核对产物与明确约束的共同满足。
- 中高级信号
- 区分结构、内容、业务结果与禁止动作，并有可执行检查。
- 资深信号
- 能处理多个合法答案、评分误差及高风险独立门槛。
继续做进阶研究实验
让评测读取事件和实际效果
沿同一研究任务的实际检查点、事件和服务方回执，区分运行成功、结果契约和未评分的语义质量。
python3 cli.py memory-put
python3 cli.py submit
python3 cli.py run
python3 evaluate.py
python3 -m unittest discover -s . -p test_lab.py -v保留证据，逐条核对
- 从事件和检查点解释 passed 的各项依据。
- 分别指出 scope、引用、幂等效果和步骤预算的可信观测。
- semantic_support 与 model_quality 是 not_scored，不能把 passed 写成模型质量成绩。
默认使用确定性摘要函数和合成文档；评测真实运行轨迹与机械约束，没有验证真实模型的语义支持。
动手验证 按需完成 · 建议 15 分钟
为“生成并批准发布报告”写结果契约。
展开验收要求与检查点
- 只有生成文本不等于发布完成
- 必要引用可核对
- 未经批准发布独立判失败
重点检查
- 能把自然语言任务转成可判定业务后置条件
- 能区分质量分数与安全硬门槛
- 能建立版本化数据集与故障回归集合
- 能解释评审误差和线上分布变化