用 Amazon Bedrock AgentCore 自动判定 AI 生成质量：从一道小学数学题说起
内容提要
文章以一道小学数学题为例，指出AI生成内容虽答案正确、格式合规，但讲解过程可能出错，且自动检查难以发现。作者提出划界、断言化、证据契约、状态设计、闭环五步方法，将讲解质量拆解为可判定断言，并借助Amazon Bedrock AgentCore在AWS上落地评估链路，实现可追溯、可门禁的质量判定。
延伸解读
为什么“答案对、解释错”是工程问题
文章指出，自动检查能确认答案、格式和结构，却无法判定过程性内容是否正确。水桶题中，Agent答案35.325元正确，但解释误认为无盖桶内壁有两个底面、直径10厘米对应半径10厘米。这类错误落在题目要考的知识点上，学生按此思路做下一题必然出错。人工复核成本不随规模摊薄，而Agent可批量产出，因此需要将“讲解质量”拆解为可判定的断言，而非依赖更强模型。
五步方法：从主观要求到可证伪断言
文章提出划界、断言化、证据契约、状态设计、闭环五步。划界区分代码可判与语义判断，代码部分作硬门禁；断言化把“讲得清楚”拆为对象识别、推导一致、结论有据等可独立证伪的要求；证据契约要求任何“满足”判定必须附原文位置和引用；状态设计区分不满足、无法判定、技术错误；闭环让判定参与发布决策，且评分器需通过成对样本准入。
AWS实现：托管评估与自建断言的分工
文章说明，通用不变量（指令遵循、忠实度等）可用AgentCore Evaluations内置评分器，领域语义判断则需自建，以Lambda承载并接入托管管道。Batch模式读取已产生的遥测，不重新运行Agent，因此可补评历史运行且不付二次生成成本。授权依据须独立于被评对象，如Memory的write与caller分离，避免Agent自述影响评估。
评估的边界：筛除与定位，而非采纳决策
文章强调，评估承担筛除与定位，把违反硬性要求、推导与结论不一致的产出在人工前拦下，并给出可回溯原文的失败位置。但它不承担采纳决策和教学价值判断，自动评分通过只意味着未触发已定义失败模式，不意味着教师可直接使用。少量案例不足以支撑“新版本优于旧版本”的统计结论，缺测不算改进，同分也不视为改善。
Q&A
为什么自动检查无法发现AI生成内容中的过程性错误？
自动检查能确认答案、格式和结构是否正确，但无法判定过程性内容是否正确。例如水桶题中，Agent答案35.325元正确，但解释里说“无盖桶内壁包含两个底面”和“直径10厘米所以半径10厘米”都是错的。校验答案只需一行代码，校验解释是否成立则需要另一套机制。
如何把“讲解质量好不好”这种主观要求拆成可判定的断言？
通过五步方法：划界（区分代码可判和语义判断）、断言化（拆成可证伪的要求，如对象识别、推导一致、结论有据）、证据契约（判定必须附原文位置和引用）、状态设计（区分不满足、无法判定、技术错误）、闭环（判定参与发布决策）。
Amazon Bedrock AgentCore Evaluations 支持哪些评估模式？各适合什么场景？
支持三种模式：On-demand（按需）适合CI/CD质量门禁；Online（在线）按采样率持续监控生产流量，用于趋势监控；Batch（批量）异步对多个session打分，适合建立基线和发布前后回归对比。Online和Batch从CloudWatch读取已产生的轨迹，不重新运行Agent。
在AWS上落地这套判定链路需要哪些核心组件？
需要：AgentCore Runtime执行Agent并归档产物与轨迹；AgentCore Evaluations托管评估管道；内置评分器覆盖通用不变量；自建Lambda承载领域语义判断；Bedrock提供LLM推理；Guardrails做确定性检测；AgentCore Memory提供独立授权来源；CDK与CodeBuild负责评分器发版与审计。
为什么领域断言必须自建，不能直接用AWS内置评分器？
内置评分器覆盖通用不变量（如指令遵循、忠实度、拒绝等），但无法判定具体领域的质量定义，例如“这个活动是否针对底面数量这一薄弱点”。因此通用判定用内置评分器，领域判定需自建，两者运行在同一条托管管道上。
评估体系在实际项目中失败的最常见原因是什么？
最常见的原因是分工错位：定义质量的人不了解发布决策门禁，建门禁的人不了解质量，而发布决策者两边都不参与。因此workshop让学员依次承担教研、研发、运维三种职责来避免这一问题。
这套评估方法的边界是什么？评估不承担哪些职责？
评估承担筛除与定位，不承担采纳决策和教学价值判断。自动评分通过只意味着没有触发已定义的失败模式，不意味着教师应直接使用或教学效果改善。发布是人工核验后的显式操作，门禁只给出“没有已知阻断项”的事实。
