Amazon Bedrock AgentCore：生产追踪自动优化 Agent 系统提示词

在上一篇发布文章中，我们介绍了 AgentCore 优化（AgentCore optimization），这是 Amazon Bedrock AgentCore 的一项能力，可以帮助你提升 Agent 的质量。传统上，提升一个低分 Agent 是一个手动过程：你需要审查冗长的追踪记录来找到 Agent 出错的地方，调优单个组件（如提示词、工具描述和技能），然后重新运行评估来检查改进效果。

借助 AgentCore 优化，你可以使用生产追踪记录来提出配置变更建议，通过离线批量评估和在线 A/B 测试对真实流量进行验证，并推广胜出的方案。AgentCore 可观测性（AgentCore Observability）——同样是 Amazon Bedrock AgentCore 的一项能力——提供了对 Agent 行为的可见性，而评估则提供了关于 Agent 质量的各种信号。推荐、配置束以及通过 A/B 测试进行的验证，共同构成了一个改进 Agent 的工作流程。

AgentCore 中的系统提示词优化器使用记录在 AgentCore 可观测性中的 Agent 追踪记录，结合奖励信号，生成改进后的系统提示词。对于市场趋势 Agent，推荐将现有系统提示词与修订版本进行对比，并解释触发这些变更的追踪模式。

图 1：推荐将现有系统提示词与市场趋势 Agent 的修订提示词进行对比

推荐界面还提供了对拟议变更的解释，以便你在决定是否测试该推荐之前审查其推理过程。

图 2：解释伴随推荐的系统提示词，以支持审查和验证

本文是发布文章的技术配套。我们深入了解系统提示词优化器，并解释其推荐引擎的工作原理。我们还分享了 Single Agent Reflector 和实验性开源的 Sub-Agent Reflector 在两个公开基准测试上的评估结果，以及 GEPA 和 MIPROv2 的对比数据。

系统提示词优化器由一个 Agentic Reflector（优化器的推理组件）执行。它审查经过评估的 Agent 行为，识别区分成功运行与失败的模式，并提出对 Agent 配置的针对性变更。在系统提示词优化工作流中，它的主要输出是一条修订后的系统提示词，并附有解释说明这些拟议变更为何能够提升 Agent 质量。

Agent 追踪记录通常很长，即使几十条也很容易超出模型的上下文窗口。因此，将每条追踪记录直接传入 Reflector 提示词是不切实际的。设计没有选择截断或预摘要追踪记录来适应上下文，而是通过文件系统向 Reflector 提供完整的追踪语料库。

该设计采用最小化工作流。评估器对一批追踪记录打分，然后写入 Reflector Agent 可访问的目录。Reflector 被赋予一个 Shell 工具，指向该目录，并被指示通过检查跨追踪记录的成功和失败模式来提出对 Agent 配置的更新。

Reflector 可以按需检查语料库。它可以列出文件、用 grep 搜索、用 cat 读取追踪记录、用 diff 对比输出，并有选择地检查成功和不成功的运行。我们不施加固定的信号提取或追踪摘要流水线，而是让 Reflector 决定哪些证据重要、需要做什么对比，以及如何将这些发现转化为配置变更。

然后它返回对 Agent 配置的拟议编辑。在任何提案被应用之前，必须通过平台级的安全护栏。

负责任的 AI 考量是此工作流的一部分。推荐应在使用前经过审查和测试，下文描述的护栏会在候选更新被推广之前对其进行检查。

Single Agent Reflector

Single Agent Reflector 驱动着 AgentCore 优化中的系统提示词推荐。一个 Reflector Agent 在单次遍历中处理完整追踪集。它调查分数分布，深入研究单条追踪记录中最有信息的段落，将成功与失败进行对比，并返回一组连贯的 Agent 配置编辑。每次优化轮次重复这个循环：评估追踪记录、反思、接受通过护栏的编辑。你可以运行额外的轮次来以优化时间换取进一步的质量提升。

图 3 展示了这个流程。经过评估的追踪记录被写入共享目录，单个 Reflector 在那里检查证据并产生推荐配置编辑。护栏在编辑被接受之前对其进行筛选。

图 3：Single Agent Reflector 分析经过评估的追踪记录并返回有护栏保护的配置编辑

Sub-Agent Reflector

Sub-Agent Reflector 扩展了 Single Agent Reflector。它以一定的效率换取更高的质量上限，使用一群 Agent 动态探索追踪集的不同部分。单个 Reflector 的一次遍历可能聚焦于前 5-10 条追踪记录中的模式，而遗漏只出现在语料库中较小部分的失败模式。

每个子 Agent 对单条追踪记录执行三级分析：

Surface 层：提取奖励、难度和结果。

Turn 级：使用 jq 和 grep 等 Shell 命令解析 rollout JSON，定位轨迹偏离最优路径的决策点。

Cognitive 层：诊断 Agent 在该决策点失败的原因，并提供反思性指导。

每个子 Agent 返回一条简明的发现和一条纠正规则。由于每个子 Agent 在自己的上下文窗口中运行，它可以专注于单条追踪记录而不受其他记录的影响。编排器聚合各子 Agent 的发现，泛化重复出现的模式，去除重复项，并将生成的洞察凝练为配置变更。

图 4 展示了多 Agent 流程。编排器将单条追踪分析委托给子 Agent，收集它们的发现，并将这些发现综合为一套有护栏保护的配置编辑。

图 4：Sub-Agent Reflector 使用独立的追踪分析来指导有护栏保护的配置编辑

我们已将该实验性功能作为初步版本在 Strands 开源 GitHub 仓库中发布。

护栏

朴素的配置优化可能以可预测的方式漂移：优化后提示词可能变长、提示词可能引用追踪记录中的术语作为示例、安全约束可能被松绑或软化以追求评估器分数。我们在每条候选更新被接受之前应用基于评分标准的护栏：

长度上限：如果候选配置比上一版本增长超过 20%，则拒绝，并要求优化器收紧。

安全检查：候选配置在推广前要根据安全标准进行筛选。

禁止追踪记录中的逐字短语：候选配置不能重用它们被优化的追踪记录中的确切短语。这有助于防止对训练追踪记录表面特征的过拟合。

评估结果

我们对 Single Agent Reflector 和 Sub-Agent Reflector 与两个已有基线（GEPA 和 MIPROv2）进行了评估，基准测试为 AppWorld 和 WebShop。对于每种方法，我们遍历配置空间并报告最佳结果及其轮次和优化耗时。

两个模式值得关注：

Single Agent Reflector 提供最佳质量-成本权衡。在 AppWorld 上，它在 6 分钟和 20 轮内达到 81.55%，与 GEPA 相比加速 18 倍，与 MIPROv2 相比加速 36 倍，而分数相当或更优。在 WebShop 上，它在 5 轮和 1 分钟内达到 78.31%。此变体非常适合需要快速迭代周期的场景。

Sub-Agent Reflector 在两个基准上达到最高质量。在 AppWorld 上，它达到 95.83%，比基线提升 23 点，比次优方法高 16 点。在 WebShop 上，它达到 79.15%，比基线提升 4 点。每追踪子 Agent 分析对 AppWorld 的影响最大，那里的失败模式多样，单次 Reflector 遍历可能遗漏少数模式。

这些结果反映了前文描述的两种设计。全集反思使 Single Agent Reflector 具备其效率：要达到具有竞争力的分数，它比迭代方法需要少得多的轮次和时间。子 Agent 分解使 Sub-Agent Reflector 具有更高的质量上限——它在聚合发现之前独立分析每条追踪记录。这种方法帮助它识别单次遍历许多追踪记录可能遗漏的失败模式。

图 5 总结了在两个基准测试上四种方法的比较。Sub-Agent Reflector 达到最高成功率，且在 AppWorld 和 WebShop 上，Single Agent Reflector 和 Sub-Agent Reflector 均优于 GEPA 和 MIPROv2。

图 5：四种方法在 AppWorld 和 WebShop 上的性能比较

图 6 比较了四种方法消耗的轮次和优化耗时。Single Agent Reflector 是最高效的选项，在两个基准上使用最少的轮次和最短的耗时。Sub-Agent Reflector 也保持有竞争力的优化成本。在 AppWorld 上，它使用与 GEPA 和 MIPROv2 相同的 100 轮，且比 MIPROv2 更快完成。在 WebShop 上，它约 20 分钟的耗时不到任一基线的一半，尽管它进行了更深入的追踪分析。

图 6：四种方法在 AppWorld 和 WebShop 上的轮次消耗和优化耗时比较

表 1：每种方法在每个基准上的最佳结果，以及产生该结果的配置。基线分数在括号中显示，加粗表示每个基准的最高分。对于每个基准，我们报告 headline 指标、配置、总轮次和优化耗时。Single Agent Reflector 和 Sub-Agent Reflector 的配置格式为 n_samples × epochs，GEPA 和 MIPROv2 的配置格式为 n_samples × iterations。我们扫描了 n_samples 从 5 到 50，epochs 或 iterations 从 1 到 10。Reflector 模型使用 Opus 4.6，任务模型使用 Sonnet 4.5。

最佳实践与展望

从小型追踪集开始。根据我们的经验，10-50 条多样化的追踪记录可以提供一个有用的优化起点。先从小规模开始，只有在推荐过于狭窄时才扩展集合。

在适当情况下使用标量奖励以外的信号。Reflector 将追踪记录作为文件读取，因此写入追踪的任何信号都可以被它使用。除了标量分数外，自由文本反馈（如评估器推理、人工标注或用户投诉）可以包含在同一追踪文件中供反思使用。

审查和验证推荐。在将拟议配置推广到生产环境之前，使用推荐解释、离线评估和受控 A/B 测试来评估该配置。

对多样化失败模式使用独立追踪分析。实验性开源的 Sub-Agent Reflector 在聚合发现之前独立分析追踪记录。当不同追踪子集揭示不同失败模式时，考虑使用这种方法。

将分析扩展到系统提示词之外。追踪证据也可以识别改进工具描述和可重用技能的机会。在评估这些类型的配置变更时，应用相同的护栏和验证工作流。

从托管优化工作流开始。对于大多数生产用例，AgentCore 优化提供了从追踪到推荐和验证的推荐路径。具有专门研究或集成约束的团队可以将相同的追踪、评估和验证模式应用到自定义反思工作流中。

AgentCore 优化将基于追踪的证据与推荐的配置更新和验证工作流连接起来。要开始使用，请访问 Amazon Bedrock AgentCore 详情页，阅读优化文档，打开 Amazon Bedrock AgentCore 控制台，并探索 AgentCore 示例仓库。