用 Amazon Bedrock AgentCore 自动判定 AI 生成质量：从一道小学数学题说起

摘要：在许多团队引入生成式 AI 到内容生产流程时，都会遇到同一个问题,自动检查能确认答案、格式和结构是否正确，却无法判定过程性内容是否正确。 本文以一个 K12 备课场景为例，介绍一套把 “讲解质量” 转化为可判定断言的工程方法，并说明如何在 Amazon Bedrock Agentcore 上落地这套判定链路。全文围绕一道小学数学题展开。我们从这份产物出发，逐步拆解问题的性质、五步判定方法、AWS 能力对应、一个已跑通的 workshop 实测结果，以及这套方法的边界。

1. 引言

在许多团队引入生成式 AI 到内容生产流程时，都会遇到同一个问题：自动检查能确认答案、格式和结构是否正确，却无法判定过程性内容是否正确。 本文以一个 K12 备课场景为例，介绍一套把 “讲解质量” 转化为可判定断言的工程方法，并说明如何在 Amazon Bedrock Agentcore 上落地这套判定链路。

全文围绕一道小学数学题展开。这道题的 Agent 产物答案正确、格式完整、自动检查全部通过——但解释过程有两处错误，不可用于课堂。我们从这份产物出发，逐步拆解问题的性质、五步判定方法、AWS 能力对应、一个已跑通的 workshop 实测结果，以及这套方法的边界。

2.一个具体的失败例子

题目如下:

一个无盖圆柱形水桶,底面直径 10 厘米，高 20 厘米，需要在内壁刷油漆，每平方厘米 0.05 元(π 取 3.14)。请先判断需要计算几个底面，再分步求出刷油漆的总费用(保留精确值，不作货币四舍五入)。

Agent 给出的答案是 35.325 元，数值正确：一个底面 78.5 平方厘米加侧面 628 平方厘米，合计 706.5 平方厘米，乘 0.05 即 35.325 元。

它给出的解释是:

无盖桶内壁包含两个底面和侧面，直径 10 厘米所以半径 10 厘米，据此费用为 35.325 元。

两句话里有两处错误，且都落在题目明确要考的知识点上：无盖桶的内壁是一个底面加侧面，不是两个底面；直径 10 厘米对应半径 5 厘米，不是 10 厘米。一份错误的推导但是给出了正确答案，学生按这个思路做下一道题必然出错。

这个错误对于老师来说是显而易见的；对机器而言，校验答案是否等于 35.325 只需一行代码，校验这段解释是否成立，则需要另一套机制。

2.1 为什么这是工程问题而非个案

有三个原因使它无法归类为个案：

第一：内容质量不是简单的非黑即白。答案、格式、题量、章节完整性都可以用代码稳定判定；而决定内容能否使用的往往是产物中的过程性信息是否正确、活动是否针对学生薄弱点、诊断是否有依据，而这些目前主要依赖人工。

第二：人工复核的成本不随规模摊薄。教师完整复核一份 AI 备课材料（教案、练习、解析）所需时间与自己编写相差不大，而 Agent 单晚可产出数十份。审核速度限制生成规模，而内容团队完全不可能放弃审核。

第三：形式合规的错误代价最高。上述样本格式完整、答案正确、术语齐备、自动检查全部通过，但不可用于课堂。只检查形式的评估体系会优先放行这类内容。

因此真正的问题是：业务上的要求”好不好“能否批量判定。

3. 如何把业务要求拆成可判定的断言

回到最初的水桶题，把“讲解质量好不好”听起来很主观，但是进行分析后后，它由三条各自独立成立的要求组成。对上述题目：

第三条很关键。一旦拆到这个粒度，”答案对但解释错”就不再是一个模糊感受，而是一条可以被证伪的断言——而且要求评分器指出原文位置。

评分器对水桶题样本的判定结果(已脱敏):

{
  "id": "explanation.conclusion",
  "status": "FAIL",
  "reason": "答案35.325元数值正确，但解释依据两个底面、半径10厘米得出结论，推导与该正确值不符，仅答案正确不构成支持。",
  "evidence": [
    { "pointer": "/artifacts/practice-set.json/tiers/0/questions/0/explanation",
      "quote": "无盖桶内壁包含两个底面和侧面，直径10厘米所以半径10厘米，据此费用为35.325元。" },
    { "pointer": "/artifacts/practice-set.json/tiers/0/questions/0/answer",
      "quote": "35.325元" }
  ],
  "title": "结论有据"
}

两条 evidence 分别指向错误的解释和正确的答案，结论由两个可回溯的位置共同支撑，任何人都可以按指针自行复核。我们用这个案列想要解释的是，“解释过程必须成立” 这条要求，需要拆解为断言，就是可判定的。

3.1 五步方法

如何把业务需求转化为断言，靠的不是换一个更强的模型。我们在下面提供一个方法“五步方法”，尝试把业务需求分析拆解为可判的断言。

第一步：划界

把一份材料的全部要求分为两类：规则（代码）判断和语义（模型）判断。

代码可判定的部分包括产物是否齐全、JSON 能否解析、教案环节是否完整、各环节时长之和是否等于课时、版本与引用是否可解析。必须读懂内容才能判定的部分包括推理是否正确、活动是否针对薄弱点。这一类全部用确定性检查实现并作为硬门禁。把这些交给大语言模型，不仅多花钱，还多了一层不确定性，出错时你分不清是它没读懂内容还是字段解析出了问题。

模型判断不等于直接交给模型。必须理解内容才能判的：推理过程对不对、教学活动是否真的针对学生薄弱点。但即便是这部分，也不是直接丢给模型就完了。交出去之前还要再收一次口径——先用代码从结构化产物中逐条列出待核的知识表述，把分母固定下来；其中机械可判的引用和版本仍然归代码；只有”这条表述是否被来源支持”这类真正需要理解内容的判断，才交给模型。范围收得越小，判定越稳，也越容易定位错在哪一条。

语义判断的结果单独报告，不与规格判断合并计分。它可以阻断发布，但语义判定的高分不能抵消规则判断的失败。至于模型接手之后如何保证它真的在判、判不准时如何表达、判定如何进入发布决策，是后面四步的内容。

第二步：断言化

领域专家给出的通常是意图，例如“解释要讲得清楚”、“要结合学情”。这类表述既无可观察动作，也没有可以定位的实现位置， 需要拆成若干可分别被证伪的要求。前述题目拆为对象识别、推导一致、结论有据；”结合学情”也可拆为薄弱点是否落成具体任务、教学是否先集体后独立作业、分步支持是否匹配学情。

两个常见错误：一是复合目标未拆分，”覆盖核心目标，并且把薄弱点变成任务”是两项义务，只检查前半句会放过完全未涉及薄弱点的产物；二是把专家个人做法写成唯一答案，导致采用其他同样有效方法的产出被判不合格，判定规则中应明确允许有依据的等效做法。

第三步：证据契约

规则是很简单：任何”满足”的判定都必须附上原文位置及该位置的原文引用。仅有标题、目标、题号或教师说明都不构成证据。

这一步针对的最常见失效不是判错，而是根本没有判定。被评 Agent 会把要求复述进产物，例如在教师说明中写入”本课结合学情提供分步支持”，而活动中没有落实；评分器也可能编造引文，给出产物中并不存在的引用。要求”通过必须指出原文”同时封堵了这两条路径，评分器必须实际读取材料，才能给出判定。

第四步：状态设计

“通过”与“不通过”两种状态不足以描述判定结果，至少需要区分三种情况：1）不满足：产物可读但明确缺少所需活动或解释，记为不满足；2）无法判定：证据不足以判断，记为无法判定，而不是填入默认分；3）技术错误：评分器自身出错或返回无效结果，记为技术错误，而非质量不合格。

第三种最易被忽略，代价也是最大的。评分器故障时返回一个看似可用的数值,比直接失败更危险。此外，若某案例的预期行为本身是正确拒绝，其结果应为”不适用”而非 0 分，否则等于把正确行为记为失败。

第五步：闭环

判定需要参与发布决策，而不是生成无人查阅的报表。

机械检查、行为与责任硬门禁、语义质量趋势、成本与性能——四类结果分开报告，不计总分。一旦允许计总分，语义分就会变成掩盖硬门禁失败的工具。

评分器本身上线前也要过准入。方法是成对构造样本：每条边界配一个应通过的和一个应不通过的，两者尽可能接近，只有正例是无效的。同时要量化稳定性——拿同一份材料重复判定多次，如果评分器自身的噪声比你要检测的改进幅度还大，那这个改进就没法被测出来。没通过准入的评分器不参与发布决策。

3.2 三条通用原则

这三条不只适用于教育场景。判定放射报告的描述是否支持其结论、合同审查意见是否引用正确条款、投研摘要的论断是否有来源,同样适用。

4. 在 AWS 上的实现路径

方法有了，落地需要的不是一个评分模型，而是一条可追溯、可重放、可门禁的证据链：（1）没有完整归档就没有证据,只能重跑；（2）重跑结果与上次不一致则无法比较；（3）领域判断必须自建，但需接入托管管道；（4）授权依据必须来自被评对象无法修改的位置；（5）评分器参与发布决策，即属于生产组件，需要可发版、可审计。

逐环对应关系如下。

4.1 AWS 相关产品和服务介绍

Amazon Bedrock AgentCore 是一个面向生产的 Agent 平台，用于构建、部署和运行 Agent，与开发框架和基础模型无关（Strands Agents、LangGraph、CrewAI、LlamaIndex 等都支持），不需要自行管理底层基础设施。它由一组可单独使用、也可组合使用的模块化服务构成，涵盖运行（Harness、Runtime）、记忆与工具（Memory、Gateway、Code Interpreter、Browser）、安全与治理（Identity、Payments）、以及可观测与质量（Observability、Evaluations、Optimization）。本文用到的是其中的 Evaluations，并配合 Runtime 的归档与 Observability 的轨迹采集。

Amazon Bedrock AgentCore Evaluations 是这个平台里的质量度量层：一个面向 Agent 的自动化评估服务，衡量 Agent 与工具在不同输入和场景下完成任务、处理边界情况、保持输出可靠性的表现，并把结果统一汇入由 Amazon CloudWatch 支撑的 Observability。它与托管 Agent 的 Runtime、采集调用轨迹的 Observability 并列，补齐了“构建 → 部署 → 观测 → 评估”这条闭环。它读取 Agent 已经产生的调用轨迹（Strands Agents 或 LangGraph 框架产生、以 OpenTelemetry 或 OpenInference 标准 instrument 的 session/trace/span）来打分，默认使用 LLM-as-a-judge，也可以选择用 AWS Lambda 承载的 code-based evaluator 做确定性判定。这正好对应本文“通用语义交给内置评分器、领域判定自建 Lambda”的分工。

它提供三种评估模式，覆盖不同阶段：

• On-demand（按需）：调用时把某个 session 的 span 数据直接传入 API，选定评分器，同步返回结果。适合 CI/CD 的质量门禁。
• Online（在线）：按配置的采样率持续监控生产流量，结果写入 CloudWatch，用于趋势监控。
• Batch（批量）：在一个异步作业里对多个 session 打分，由服务端从 CloudWatch Logs 发现 session，返回聚合结果与单 session 明细。适合建立基线和做发布前后的回归对比。

三者的关键区别在数据来源：On-demand 由调用方直接提供 span；Online 与 Batch 都从 CloudWatch 读取已经产生的轨迹。这引出下一节的一点——Batch 读的是存量遥测，不会重新运行 Agent。

4.2 Batch 读取已产生的遥测，不重新运行 Agent

这一点带来两项实际能力。一是可以回头补评历史运行，新加了一条断言，不需要重跑过去几个月的生成任务，直接读归档就能评估历史产出。二是评估存量流量不用再付一次生成成本。相比之下，本地”跑两个版本对比”的批处理方式会重新运行 Agent，用途不同，不能互相替代。

4.3 领域断言必须自建

AWS 提供了内置评分器，覆盖 session 级，trace 级以及 tool_call 级。 15 个是 LLM judge，3 个 Trajectory 是程序化。

SESSION 级（4 个）——判整段会话

TRACE 级（10 个） ：判单轮回复

TOOL_CALL 级：判单次工具调用

如何选择：

• 线上流量（没有标准答案）：只能用无参考模式。质量与安全维度、Correctness/GSR 的无参考模式。Online 不支持通用 ground truth 提交。
• 离线回归（有标准答案）：Correctness 带 expectedResponse、GSR 带 assertions、三个 Trajectory* 带 expectedTrajectory。三个 Trajectory 限定在 Evaluate/Batch 路径。
• 成本敏感：优先三个 Trajectory，零 LLM 调用。

而这些 AWS 内置的评估器用于覆盖通用不变量：是否遵循指令、是否脱离来源、是否该拒绝而未拒绝。它们无法判定”这个活动是否针对底面数量这一薄弱点”，因为通用评分器不掌握具体领域的质量定义。因此思路就清楚了：通用判定用内置评分器，领域判定自己写，两者运行在同一条托管管道上。自建部分可实现为不依赖 AWS 的纯逻辑核，本地用于调试，云端以 Lambda 封装接入托管评估，保证本地与云端判定逻辑同源，线上误判可在本地复现。

4.4 授权来源必须独立于被评对象

判定”是否沿用教师已确认的偏好”时，不能去读 Agent 自己生成的教师说明，这是被评者的自述。为了避免被 Agent 生成的数据影响评估结果，memory 的 write 和 caller 需要分离， 执行 Agent 的 runtime 不具备 memory 的写权限。 若被评对象可以修改用于评估它的依据，证据链即不成立。

[图 1 · 评估证据链：从生成到发布门禁。]

• 上半部为生成与归档：Strands Agents(工具只读)→ AgentCore Runtime → 产物归档至 Amazon S3(不可覆盖),调用轨迹与遥测进入 Amazon CloudWatch。
• 下半部为评估与门禁：evaluator 读归档取证，内部由 AWS Lambda 执行确定性检查、Amazon Bedrock 执行语义判定,两者分开报告、不算总分;判定连同原文引用进入 AgentCore Evaluations(Online 抽样 / Batch)，再进入发布门禁。
• 旁挂 AgentCore Memory 提供被评对象无法修改的授权依据，Bedrock Guardrails 提供确定性检测，其输出是信号而非结论。底部虚线为闭环：确认的失败经脱敏后回到回归集。

需要界定清楚 AWS 在这套方案中的角色：AWS 提供承载证据链的基础设施，包括执行、归档、托管评估、自建评分器接入点、独立授权来源，以及发版与审计能力。领域断言、rubric 和校准样本仍然需要团队和领域专家来产出。这部分工作量最大，也是本系列下一篇的重点。

5. Workshop 实测

为验证该方法能否被一个真实场景快速跑通，我们围绕一个教师备课 Agent 构建了 workshop，本文开头的水桶面积计算是其五个固定案例之一。

核心设计是让同一批 workshop 学员依次承担三种职责：教研，研发和运维。评估体系在实际项目中失败，最常见的原因就是分工错位：定义质量的人不了解发布决策门禁，建门禁的人不了解质量，而发布决策者两边都不参与。因此每位学员依次经历:

• 教研：阅读实际产物，裁定哪些是真实缺陷，并把确认的问题固化为回归案例。
• 研发：修改 Prompt，运行分层评估，进行版本对比。
• 运维：解释门禁阻断原因，决定发布策略（A/B 或 Canary）、是否发布及如何回滚。

实验主线从冻结任务与评价口径开始，形成闭环：运行基线 → 教师裁定 → 固化 Golden Case → 分层评估 → 修复与回归 → 云端构建与发布 → 真实会话评估 → 教师复审。确认的失败经脱敏后回到回归集，下一轮从此继续。

架构分层如下。

这张表有一点值得关注：五个 evaluator 中只有教学语义那一个调用模型。教案结构、工具行为、Memory 证据三项全是确定性代码。这是五步中的第一步在真实部署中的形态，它从一条原则落实到而是一份资源清单。

[图 2 · Workshop 部署环境。]

• 方案包含三条链路：1）构建与发布（源码固 → CodeBuild 构建 → 核验 → CDK 发布）；2）Portal 访问（教师浏览器 → WAF / CloudFront → OAC 取私有页面，/api/* 经 HTTP API 的 JWT 校验再到 Lambda)；3）Agent 执行与评估（worker 调用 Runtime → 只读继承 Memory → 条件写入可信归档 → 托管评估按版本读归档）。
• 团队边界为应用资源与权限分组，不是 VPC 或子网。
• 实线为运行调用或数据传递，虚线为配置关联或发布依赖。

五个固定案例覆盖不同失败类型：标准备课、教材版本混用、解题解释(即本文案例)、跨会话偏好继承，以及一个应被正确拒绝的请求。

评估的职责边界

• 它承担筛除与定位：把违反硬性要求、缺少必需内容、推导与结论不一致的产出在进入人工环节之前拦下，并给出可回溯到原文的失败位置。前述样本中，评估把”答案对、解释错”这类最难由人工快速发现的缺陷，压缩成了一条带证据指针的判定。
• 评估不承担的是采纳决策和教学价值判断，这些交还给专家。自动评分通过，只意味着产出没有触发已定义的失败模式，不意味着教师应该直接拿来用，也不意味着教学效果已经改善。评估的价值在于：让专家把时间花在需要专业判断的材料上，而不是花在筛查格式和算式上。
• 它把发布授权交还给流程。在本体系中，发布是人工核验后的显式操作。门禁负责给出”没有已知阻断项”这一事实，是否发布由承担后果的人决定。
• 它对自身证据强度作显式限定。少量案例与少量评测会话足以发现缺陷，不足以支撑”新版本优于旧版本”这类统计结论;可比较的前提是同一任务、同一来源、同一 Agent 与 Runtime、同一 Judge 与 rubric，缺测不算改进，同分也不视为改善。同理,确定性检测器未命中只说明未命中,应作为信号计入,而不当作结论使用。能在报告中区分”已验证通过”与”尚未覆盖”,正是评估结论可用于决策的必要条件。

6. 系列后续

本系列下一篇《从业务要求到 evaluator：选型、自建与准入》，讲的就是把这套方法真正落到一个 evaluator 上。你会看到一条业务要求怎么依次走过四步：拆成可判的断言、选内置还是自建、把语义判断建出来、再让它通过校准准入。每一步都给判断依据：什么时候用内置评分器、什么时候必须自己建、以及为什么没通过校准的评分器不该参与发布决策。如果你手上正有一句说不清的质量要求要落地,那一篇是接着往下走的路。

➡️ 下一步行动：

相关产品：

• Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
• Amazon Bedrock AgentCore — 加快代理投入生产的速度
• AWS Lambda — 无需服务器即可运行代码
• Amazon CloudWatch — 可观测性工具
• Amazon Batch — 完全托管式批处理

相关文章：

• 从AI辅助编程到AI-DLC：紫讯落地 AI 原生研发新范式的实践
• AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第六篇
• 基于 Amazon Bedrock AgentCore 与 AWS DevOps Agent 打造对话式多账户运维助手
• 让 AI 代理自己付钱：基于Amazon Bedrock AgentCore与 x402 的Agentic Payment 方案
• 用 Amazon Bedrock AgentCore Payment 构建自主支付 AI Agent: x402 协议实战

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用