当你把一个原型AI袋里推向生产环境时，最核心的挑战是什么？答案通常绕不开一个词：质量评估。不过，这里的“质量”远不止语言表达是否流畅那么简单——尤其在金融这类高度专业化的领域里。

想象一下，一个市场情报袋里需要实时引用股票价格，且报价偏差必须控制在一个可配置的浮动区间内；它在访问金融资料前，必须走完强制性的经纪人身份识别流程；它返回的工具输出得严格遵循JSON schema；同时，还得千方百计地隐藏个人身份信息（PII）。这些要求，光靠大语言模型（LLM）那种“听起来差不多就行”的判断力是远远不够的。它们需要的是确定性的代码：同样的输入，永远给出同样的结果。这个时候，再强大的LLM-as-a-Judge，在简单直接的代码逻辑面前，也会显得既昂贵又低效。

用代码定制AI袋里的“硬标准”

Amazon Bedrock AgentCore Evaluations 提供了一个巧妙的解决方案：允许你通过自定义代码评估器，把AWS Lambda函数作为评估引擎。这意味着评估逻辑完全由你来掌控——无论是正则表达式校验、数据结构验证、外部数据查询、调用其他服务，还是执行复杂的业务规则，都尽在掌握。

这种评估方式的优势显而易见。同一个评估器可以反复使用，无需为每次请求消耗基础模型（FM）的Token。在按需评估模式下，它可以作为开发工作流和CI/CD流水线中的一道“关卡”；而在在线评估模式下，它又能实时对生产流量进行评分。无论你的袋里trace来自哪个框架，只要通过Lambda完全掌控逻辑，就能用自己的标准持续评估袋里质量。

接下来，我们通过一个金融领域的“市场情报袋里”实例，一步步实现四个基于Lambda的自定义代码评估器，将它们注册到AgentCore，并在按需和在线两种模式下运行。你还会看到，如何将这些代码评估器与内置评估器结合，以及如何调用其他AWS服务来实现基于事实的校验、PII检测和实时告警。

为什么需要“代码式”的确定性校验？

在探讨具体实现前，有必要先搞清楚，哪些场景是非代码评估器不可的。

首先是工具输出结构的校验。 袋里高度依赖来自搜索、检索或业务API的结构化输出（如JSON）。一旦契约变更、解析出bug或上游服务宕机，都可能产生畸形数据，而袋里很可能会把这些错误数据编入答案，造成严重的“一本正经地胡说八道”。对工具响应schema进行校验，在工具边界处就拦截结构性问题，这是代码评估器最擅长的。而LLM-as-a-Judge则负责评估答案的实用性和清晰度，两者正好形成互补。

其次，是数值的绝对精确性。 袋里经常需要引用价格、指标、阈值和配额，一个0.1%的偏差就可能彻底改变一项金融交易决策。LLM天生容易犯算术错误，但代码评估器可以调用参考系统，计算容差，并精确标记每一次出入。通过确定性方式验证数值准确性，是最有效、最可靠的手段。

再次，是工作流契约的合规性。 在严格遵守操作顺序和策略约束的袋里中，必须先识别用户身份才能读取敏感数据，必须先获取授权才能执行操作，必须按特定工具序列调用以维护数据完整性。验证这些工作流契约，需要检查一次会话中工具调用的完整序列。代码评估器能清晰地检查袋里是否遵循了流程，而LLM-as-a-Judge则负责衡量其沟通结果的好坏。

最后，是数据隐私的“红线”。 任何处理个人资料、文档或日志的袋里，都必须确保不泄露姓名、账户ID、联系方式或机密信息。一旦响应中暴露了这些数据，就是合规或安全层面的严重事故。代码评估器可以调用PII检测或秘密扫描服务，对响应内容实施硬性规则，这恰恰弥补了单纯依赖语言质量和有用性评分的不足。

总的来说，与LLM-as-a-Judge评估器搭配使用时，代码检查验证的是袋里“沟通得好不好”之外的层面——它是否遵守了契约、是否算对了数字、是否走对了流程、是否守住了数据底线。这种组合，将袋里的可靠性从“听起来对”提升到了“经契约验证”的层次。

代码评估器的工作原理

一个代码评估器本质上就是一个Lambda函数，它被注册到AgentCore的控制平面。当评估运行时，AgentCore会扮演一个IAM角色，调用这个Lambda，并传入包含袋里OpenTelemetry（OTel）span的负载。随后，Lambda的响应会被写入CloudWatch Logs，作为评估结果。

这个负载结构包含schema版本、评估器ID、名称、评估级别，以及一个包含会话OTel span数组的评估输入对象。对于trace级别的评估器，还有一个单独的评估目标字段来指定要评分的trace。对于session级别的评估器，AgentCore会省略目标，由Lambda对整个对话进行评分。

Lambda的响应也必须遵循一个固定契约。成功时，返回一个字典，包含一个标签（如PASS或FAIL）、一个可选的0.0–1.0之间的数值分数，以及一个可选的解释字符串。失败时，则返回一个包含错误代码和错误信息的字典。每个成功响应都必须包含标签。分数和解释字段虽然是可选的，但它们会直接反馈到CloudWatch指标和AgentCore可观察性仪表盘中，对于排查低分原因非常有帮助。

每个评估器在注册时，可以选择三个级别之一：TRACE（单次用户交互）、TOOL_CALL（单次工具调用）或SESSION（整个会话）。下图清晰地展示了这种层级关系：

如果你想让同一个Lambda在多个级别上工作，只需为每个级别单独注册，指向同一个函数即可。

按需评估与在线评估

AgentCore Evaluations 同时支持按需和在线两种模式。一个评估器ID，既可用于开发、测试，也可作为CI/CD流水线的“门禁”，还能用于持续的生产监控。Lambda的契约（包括负载、响应格式和IAM配置）在两种模式下完全一致。下面的流程图展示了在线评估的端到端流程，按需评估的路径与之类似，只不过将“定时采样”步骤替换为Evaluate API调用。

按需评估的场景

按需评估适用于三个典型场景：

• 开发与调试： 在开发过程中，可以针对特定会话或trace，即时调用一个或多个评估器，快速验证代码改动是否引入了问题。
• CI/CD流水线门禁： 在部署之前，将通过性测试作为流水线的一步。如果关键评估器（如schema校验、PII检测）返回FAIL，则阻止部署。
• 回归测试： 定期或针对已知问题场景，运行一组评估器，确保没有新的回归问题引入。

需要注意的是，一次按需调用最多可以引用10个评估器（包括代码类和内置类）。例如，对于市场趋势袋里，可以在部署前一次性运行Helpfulness和Correctness两个内置评估器，外加四个代码评估器。合并后的结果能在一次运行中确认语言质量、工具契约完整性、价格准确性、工作流顺序和PII安全性。

在线评估的配置

在线评估则持续对实时袋里流量进行采样，并按设定时间表对配置好的评估器进行评分。要设置在线评估，需要一次性通过AgentCore控制面板创建一个在线评估配置，指定以下内容：

• 数据源： 可以直接指向AgentCore Runtime上的袋里，或者引用该袋里使用的CloudWatch日志组。AgentCore会通过这些设置找到已完成的会话，对代表一次完整对话的span进行分组并执行评估。
• 采样率： 可以在0.01%到100%之间精细调整，以控制被评估的流量比例。
• 会话超时： 告诉AgentCore在最后一个span之后等待多久，才将会话视为完成。这个超时时间应与袋里的典型会话时长匹配，以避免对仍在进行中的会话评分。
• IAM角色： AgentCore会使用配置中定义的角色来调用Lambda和写入CloudWatch日志。

配置启用后，AgentCore会为你处理定期的评估工作。对于每个采样到的会话，它从CloudWatch读取span，调用你配置的每个评估器，并将评估结果写入一个专用的CloudWatch日志组。每个评估器的分数还会以Embedded Metric Format出现在CloudWatch的Bedrock-AgentCore/Evaluations命名空间下，按键值为评估器名称和配置ID。有了这些指标，你就能构建统一的仪表盘，将schema有效性、工作流合规性、PII清洁度与Helpfulness和Correctness放在一起看。还可以配置CloudWatch告警，当某个关键质量维度跌破阈值时，自动通知运维人员。

实战：市场趋势袋里

为了演示整个流程，我们以“市场趋势袋里”为例。这是一个基于LangGraph构建、部署在Amazon Bedrock AgentCore Runtime上的投资智能助手。它可以为金融经纪人提供股票数据、多渠道新闻分析，并利用AgentCore Memory存储经纪人资料，根据每个经纪人的策略、兴趣和风险承受能力进行个性化分析。

这个袋里暴露了多个工具，用于股票价格检索、财经新闻搜索、经纪人身份提取、资料读写和市场简报生成。LangGraph的OTel instrumentation通过AgentCore Observability将span发布到CloudWatch，完美地演示了代码评估器和LLM-as-a-Judge评估器的集成。

示例中包含了四个评估器，覆盖了前面讨论的所有关键维度：schema验证、数值准确性、工作流合规性和PII检测。整个动手实践大约需要45分钟，按默认采样率计算，AWS费用不到5美元。

从开发到生产的实践路径

开始评估生产环境中的袋里后，你会发现有些质量问题来自主观判断，比如“语气是否友好”、“解释是否清晰”；而另一些则完全是刚性的、基于规则的，比如“格式是否正确”、“流程是否走完”。AgentCore的自定义代码评估器正是为应对后者而设计的。

添加这些评估器的流程是固定的，无论你是构建第一个，还是搭建完整的评估套件。核心思路是：先识别出那些需要零歧义的确定性质量维度，比如精确的数据约束、结构性的工具调用顺序要求、以及PII合规等硬性规定。与此同时，继续保持对主观维度（如有用性、语气、连贯性等）使用内置的或自定义的LLM-as-a-Judge评估器。

在确定维度后，接下来选择一个合适的评估级别：

这种映射关系能确保每个业务规则都能在袋里生命周期的合适节点上得到有效检查。

在实际部署中，一个稳健的策略是：先通过按需评估让评估器在真实流量上“磨合”一段时间。在将其与部署决策或告警挂钩前，先用一组已知的会话进行测试，确认它能稳定地捕获你所关心的特定问题，并且其解释能清晰指出出问题的span或工具调用。如果评估器需要调用外部系统（如PII检测器或策略引擎），这也是验证权限、超时等集成细节的最佳时机。

随后，可以将其集成到CI/CD流水线中作为部署门禁。当评估器在预发布阶段标记了关键问题时，流水线就可以直接中断运行。这样，在改动进入生产环境之前，就能强制保证schema有效性、数值正确性或PII卫生等硬性要求。

最后，当你对评估器的行为模式有了足够信心后，就可以将其“晋升”到在线评估模式，让它对真实生产流量进行持续评分。这时，采样率就成了平衡覆盖率和成本的关键：低流量袋里通常可以设为100%，确保每个会话都被检查；而高流量袋里则建议保持在10–20%左右，在保证信号强度的同时控制预算。

一旦在线评估运转起来，结果会落入专用的日志组，每个评估器的分数也会以CloudWatch指标的形式呈现。这些指标是构建仪表盘、设置告警的原始素材。当某个指标跌破了你设定的阈值时，团队可以第一时间收到通知。到了这一步，你的评估器就不再是隐藏在幕后的小众工具，而变成了可见、可追踪的信号——当需要判断质量是否发生漂移、系统是否满足特定用例的合规标准时，可以直接拿来作为依据。

代码评估器将AgentCore的覆盖范围扩展到了需要确定性逻辑的质量维度。在按需模式下，它们是开发阶段的检查工具和CI/CD的部署“门禁”，能够返回同步的分数和针对性的解释。在在线模式下，同一个注册好的评估器可以与内置的LLM-as-a-Judge评估器协同工作，对生产会话进行实时评分，并将结果以指标形式呈现。将逻辑部署在自有的Lambda中，意味着你可以随着业务规则的变化灵活调整检查逻辑。同一份评估器注册，既能服务本地开发，又能服务CI/CD门禁，还能用于持续的生产监控，为整个团队提供了一个从原型到规模化的一致质量信号。