官方更新 AWS ML Blog Wed, 16 Sep 2026 正文 ok 2050 words

使用 Amazon Bedrock AgentCore 优化 Agent 系统提示词

英文标题:Optimizing agent system prompts with Amazon Bedrock AgentCore

Amazon Bedrock AgentCore 的系统提示词优化器可基于生产追踪记录和奖励信号,自动提出 Agent 配置修改建议,并通过离线批量评估和在线 A/B 测试验证后再推广。该优化器采用 Reflector 推理组件:Single Agent Reflector 在完整追踪集上进行一次整体分析,Sub-Agent Reflector 则通过多 Agent 分析单条追踪以发现更多长尾失败模式。基准测试显示,Single Agent Reflector 在质量与成本之间具备最佳平衡,在 AppWorld 上以 6 分钟、20 个 turns 达到 81.55%;Sub-Agent Reflector 则在 AppWorld 和 WebShop 上取得最高分,分别为 95.83% 和 79.15%。这一机制为开发者提供了从真实 Agent 运行数据中发现问题、生成提示词改进方案、进行安全验证并逐步上线的工程化闭环。
打开原文相关 4.5 · 机会 2
media1.3 MB media101.1 KB media124.1 KB media345.0 KB media141.2 KB media346.5 KB media351.3 KB media206.0 KB media82.8 KB media88.6 KB media112.4 KB media21.9 KB media22.8 KB media24.6 KB media205.2 KB

中文

在一篇此前的发布文章中,我们介绍了 AgentCore optimization。它是 Amazon Bedrock AgentCore 的一项功能,可帮助您提升 Agent 的质量。过去,改进低分 Agent 通常是一个手动过程:您需要审查冗长的追踪记录,找出 Agent 出错的位置,调整提示词、工具描述和技能等单独组件,再重新运行评估以确认是否有所改进。

借助 AgentCore optimization,您可以使用生产追踪记录提出配置修改建议,通过离线批量评估和面向真实流量的在线 A/B 测试进行验证,并推广其中的优胜方案。Amazon Bedrock AgentCore 的 AgentCore Observability 功能可提供对 Agent 行为的可见性,而评估则提供 Agent 质量信号。结合建议、配置包,以及通过 A/B 测试 进行的验证,可形成一套改进 Agent 的工作流。

AgentCore 中的系统提示词优化器会使用记录在 AgentCore Observability 中的 Agent 追踪记录及奖励信号,生成改进后的系统提示词。以 market trends agent 为例,建议会将现有系统提示词与修订版本进行比较,并解释促成这些改动的追踪模式。

market trends agent 的原始系统提示词与推荐系统提示词对照图

图 1:一项建议将 market trends 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 也是此工作流的一部分。建议在使用前应经过审查和测试,本文稍后介绍的护栏会在候选更新被推广前对其进行筛查。

单 Agent Reflector

Single Agent Reflector 目前负责驱动 AgentCore optimization 中的系统提示词建议。一个 Reflector Agent 会在单次遍历中处理完整追踪集:它审视分数分布,深入分析单条追踪记录中信息量最大的片段,对比成功与失败案例,并返回一套连贯的 Agent 配置修改建议。每个优化 epoch 都会重复这一周期:为追踪记录评分、反思分析,并接受通过护栏的修改。您可以运行更多 epoch,以更多优化时间换取进一步的质量提升。

图 3 展示了这一流程。经过评估的追踪记录被写入一个共享目录,单个 Reflector 在其中检查证据并生成推荐配置修改。护栏会在这些修改被接受之前对其进行筛查。

图 3:Single Agent Reflector 分析经过评估的追踪记录,并返回经护栏约束的配置修改

子 Agent Reflector

Sub-Agent Reflector 是对 Single Agent Reflector 的扩展。它通过使用一个 swarm Agent 群动态探索追踪集的不同部分,以牺牲部分效率为代价获得更高的质量上限。一次 Reflector 处理可能会重点关注其最先检查的 5–10 条追踪记录中的模式,从而遗漏只出现在较小部分语料中的失败模式。

每个子 Agent 会对单条追踪记录进行三级分析:

  1. **表层:**提取奖励、难度和结果。
  2. **轮次层面:**使用 jq 和 grep 等 shell 命令解析 rollout JSON,定位轨迹偏离最优路径的决策点。
  3. **认知层面:**诊断 Agent 为何在该决策点失败,并提供反思性指导。

每个子 Agent 都会返回简明的发现和一条纠正规则。由于每个子 Agent 都在各自的上下文窗口中运行,因此可以专注于一条追踪记录,而不受其他记录影响。编排器会汇总这些发现,归纳反复出现的模式,去除重复内容,并将所得洞见压缩为配置修改。

图 4 展示了多 Agent 流程。编排器将单条追踪记录分析委派给子 Agent,收集其发现,并将这些发现综合成一套经护栏约束的配置修改。

图 4:Sub-Agent Reflector 使用独立的追踪记录分析来指导经护栏约束的配置修改

我们已在 Strands 开源 GitHub 仓库中,以初步版本形式发布这一实验性功能。

护栏

朴素的配置优化会以可预测的方式发生漂移:优化后提示词可能变得更长,提示词可能会引用追踪记录中的术语作为示例,而安全约束可能会为了追求评估器分数而被放松或弱化。我们会在每项候选更新被接受前,对其应用基于规则量表的护栏:

  • **长度上限。**如果候选方案使配置相较于上一版本增长超过 20%,则会被拒绝,并要求优化器将其进一步精简。
  • **安全检查。**候选方案在推广前会接受安全标准筛查。
  • **不得直接复用追踪记录中的短语。**候选方案不能复用其优化所针对追踪记录中的完全相同短语。这有助于防止模型对训练追踪记录表层特征过拟合。

评估结果

我们在两个公开基准——AppWorld 和 WebShop——上,对 Single Agent Reflector、Sub-Agent Reflector 以及两个成熟基线方案 GEPA 和 MIPROv2 进行了评估。对于每种方法,我们扫描了配置空间,并报告其最佳结果,以及对应的 turns 数量和实际优化耗时。

有两个明显模式:

**Single Agent Reflector 在质量与成本之间提供了最佳权衡。**在 AppWorld 上,它以 6 分钟和 20 个 turns 达到 81.55%,在获得相当或更好分数的前提下,相比 GEPA 加速 18 倍、相比 MIPROv2 加速 36 倍。在 WebShop 上,它以 5 个 turns 和 1 分钟实际耗时达到 78.31%。当您希望快速迭代时,该变体非常适合。

**Sub-Agent Reflector 在两个基准上均获得最高质量。**在 AppWorld 上,它达到 95.83%,比基线高 23 个百分点,比次优方法高 16 个百分点。在 WebShop 上,它达到 79.15%,比基线高 4 个百分点。逐追踪记录的子 Agent 分析在 AppWorld 上效果最显著,因为该基准的失败模式多样,而单次 Reflector 处理可能遗漏少数模式。

这些结果反映了前文介绍的两种设计。全量集合反思赋予 Single Agent Reflector 高效率:与迭代式方法相比,它只需更少的 turns 和分钟数即可达到有竞争力的分数。子 Agent 分解则通过在汇总发现前独立分析每条追踪记录,为 Sub-Agent Reflector 带来更高的质量上限。这种方法有助于识别对大量追踪记录进行单次处理时可能遗漏的失败模式。

图 5 总结了四种方法在 AppWorld 和 WebShop 上的对比。Sub-Agent Reflector 获得最高成功率;在 AppWorld 和 WebShop 两个基准中,Single Agent Reflector 与 Sub-Agent Reflector 均优于 GEPA 和 MIPROv2。

GEPA、MIPROv2、Single Agent Reflector 和 Sub-Agent Reflector 在 AppWorld 上的成功率和优化时间

图 5:四种方法在 AppWorld 和 WebShop 上的性能对比

图 6 对比了四种方法消耗的 turns 数量和实际优化耗时。Single Agent Reflector 是效率最高的选项,在两个基准上均使用最少的 turns 和最短的实际耗时。Sub-Agent Reflector 也保持了有竞争力的优化成本:在 AppWorld 上,它与 GEPA 和 MIPROv2 一样使用 100 个 turns,但完成速度快于 MIPROv2;在 WebShop 上,尽管进行了更广泛的追踪记录分析,其约 20 分钟的实际耗时仍不足任一基线方案的一半。

GEPA、MIPROv2、Single Agent Reflector 和 Sub-Agent Reflector 在 WebShop 上的奖励和优化时间

图 6:四种方法在 AppWorld 和 WebShop 上消耗的 turns 与实际优化耗时

基准 指标 GEPA MIPROv2 Single Agent Reflector(我们的方案) Sub-Agent Reflector(我们的方案)
AppWorld(基线 72.62%) 成功率 79.63% 74.40% 81.55% 95.83%
配置 20 × 5 20 × 5 20 × 1 10 × 10
turns 数量 100 100 20 100
优化时间 108 分钟 216 分钟 6 分钟 193 分钟
WebShop(基线 75.03%) 奖励 74.77% 72.12% 78.31% 79.15%
配置 10 × 5 5 × 5 5 × 1 20 × 10
turns 数量 50 25 5 200
优化时间 48 分钟 60 分钟 1 分钟 ~20 分钟

表 1:每种方法在各基准上的最佳结果,以及产生该结果的配置。基线分数以括号标示,加粗表示每个基准上的最高分。对于每个基准,我们报告核心指标、配置、总 turns 数量和实际优化耗时。对于 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 将追踪记录作为文件读取,因此写入追踪记录的任何信号都可供其使用。除标量分数外,还可以将自由文本反馈——例如评估器理由、人工标注或用户投诉——纳入同一条追踪记录。

English / 原文

In a previous launch post, we introduced AgentCore optimization, a capability of Amazon Bedrock AgentCore that can help you improve the quality of your agents. Improving a low-scoring agent has traditionally been a manual process. You review long traces to find where the agent goes wrong, tune individual components such as prompts, tool descriptions, and skills, and rerun evaluations to check for improvement.

With AgentCore optimization, you can use production traces to propose configuration changes, validate them through offline batch evaluation and online A/B testing on live traffic, and promote the winners. AgentCore Observability, a capability of Amazon Bedrock AgentCore, provides visibility into agent behavior, and evaluations provide signals about agent quality. Together, recommendations, configuration bundles, and validation through A/B testing provide a workflow for improving an agent.

The system prompt optimizer in AgentCore uses agent traces recorded in AgentCore Observability together with a reward signal to produce an improved system prompt. For the market trends agent, the recommendation compares an existing system prompt with a revised version and explains the trace patterns that motivated the changes.

Original system prompt beside a recommended system prompt for the market trends agent

Figure 1: A recommendation compares the existing system prompt with a revised prompt for the market trends agent

The recommendation interface also provides an explanation of the proposed changes, so you can review the reasoning before deciding whether to test the recommendation.

Explanation panel accompanying a system prompt recommendation

Figure 2: An explanation accompanies the recommended system prompt to support review and validation

This post is a technical companion to the launch post. We take a deeper look at the system prompt optimizer and explain how its recommendation engine works. We also share evaluation results for the Single Agent Reflector and the experimental, open source Sub-Agent Reflector on two publicly available benchmarks, alongside GEPA and MIPROv2.

Optimizer design

The system prompt optimizer is executed by an agentic reflector, the reasoning component of the optimizer. It reviews evaluated agent behavior, identifies patterns that distinguish successful runs from failures, and proposes targeted changes to the agent configuration. In the system-prompt optimization workflow, its primary output is a revised system prompt accompanied by an explanation of why the proposed changes should improve agent quality.

Agent traces are often lengthy, and even a few dozen can quickly exceed a model’s context window. Passing every trace directly into the reflector prompt is therefore impractical. Instead of truncating or pre-summarizing traces to fit, the complete trace corpus is made available to the reflector through a filesystem.

The design uses a minimal workflow. An evaluator scores a collection of traces and writes them to a directory accessible to the reflector agent. The reflector is given a shell tool, directed to that directory, and instructed to propose updates to the agent configuration by examining patterns of success and failure across the traces.

The reflector can inspect the corpus as needed. It can list files, search with grep, read traces with cat, compare outputs with diff, and selectively examine successful and unsuccessful runs. We don’t impose a fixed signal-extraction or trace-summarization pipeline. Instead, the reflector determines which evidence matters, what comparisons to make, and how to translate those findings into configuration changes.

It then returns proposed edits to the agent configuration. Before any proposal can be applied, it must pass through platform-level guardrails.

Responsible AI considerations are part of this workflow. Recommendations should be reviewed and tested before use, and the guardrails described later in this post screen candidate updates before they can be promoted.

Single agent reflector

The Single Agent Reflector drives system prompt recommendations in AgentCore optimization today. One reflector agent works through the full trace set in a single pass. It surveys the score distribution, drills into the most informative segments of individual traces, contrasts successes with failures, and returns one coherent set of edits to the agent configuration. Each optimization epoch repeats this cycle: score the traces, reflect, and accept the edits that pass the guardrails. You can run additional epochs to trade optimization time for further quality gains.

Figure 3 shows this flow. Evaluated traces are written to a shared directory, where a single reflector inspects the evidence and produces recommended configuration edits. The guardrails screen those edits before they’re accepted.

Figure 3: The Single Agent Reflector analyzes evaluated traces and returns guarded configuration edits

Sub-Agent Reflector

The Sub-Agent Reflector extends the Single Agent Reflector. It trades some efficiency for a higher quality ceiling by using a swarm of agents to explore different parts of the trace set dynamically. A single reflector pass can focus on patterns in the first 5–10 traces it examines and miss failure modes that appear only in a smaller portion of the corpus.

Each sub-agent performs a three-level analysis on a single trace:

  1. Surface: Extract the reward, difficulty, and outcome.
  2. Turn level: Locate the decision point where the trajectory diverged from the optimal path, using shell commands such as jq and grep to parse rollout JSON.
  3. Cognitive: Diagnose why the agent failed at that decision point and provide reflective guidance.

Each sub-agent returns a concise finding and a corrective rule. Because each sub-agent operates in its own context window, it can focus on one trace without being influenced by the others. The orchestrator aggregates the findings, generalizes recurring patterns, removes duplicates, and condenses the resulting insights into configuration changes.

Figure 4 shows the multi-agent flow. The orchestrator delegates individual trace analyses to sub-agents, collects their findings, and synthesizes the findings into a single set of guarded configuration edits.

Figure 4: The Sub-Agent Reflector uses independent trace analyses to inform guarded configuration edits

We have launched this experimental feature as a preliminary release in the Strands open-source GitHub repository.

Guardrails

Naive configuration optimization can drift in predictable ways: prompts can grow longer after optimization, prompts can quote terms from traces as examples, and safety constraints can be relaxed or softened in pursuit of an evaluator score. We apply rubric-based guardrails to every candidate update before it is accepted:

  • Length ceiling. A candidate that grows the configuration by more than 20 percent over the previous version is rejected, and the optimizer is asked to tighten it.
  • Safety check. Candidates are screened against safety standards before promotion.
  • No verbatim phrases from traces. Candidates can’t reuse exact phrases from the traces against which they were optimized. This helps prevent overfitting to surface features of the training traces.

Evaluation results

We evaluated the Single Agent Reflector and Sub-Agent Reflector alongside two established baselines, GEPA and MIPROv2, on two public benchmarks: AppWorld and WebShop. For each method, we swept the configuration space and reported the best result with its number of turns and wall-clock optimization time.

Two patterns stand out:

Single Agent Reflector offers the best quality-per-cost trade-off. On AppWorld, it reaches 81.55 percent in 6 minutes and 20 turns, an 18× speed-up over GEPA and a 36× speed-up over MIPROv2 for a comparable or better score. On WebShop, it reaches 78.31 percent with 5 turns and 1 minute of wall-clock time. This variant is well suited when you want fast iteration cycles.

Sub-Agent Reflector achieves the highest quality on both benchmarks. On AppWorld, it reaches 95.83 percent, a 23-point lift over the baseline and 16 points above the next-best method. On WebShop, it reaches 79.15 percent, a 4-point lift over the baseline. The per-trace sub-agent analysis has the greatest effect on AppWorld, where failure modes are diverse and a single reflector pass can miss minority patterns.

These results reflect the two designs described earlier. Whole-set reflection gives the Single Agent Reflector its efficiency: it requires far fewer turns and minutes than iterative methods to reach competitive scores. Sub-agent decomposition gives the Sub-Agent Reflector a higher quality ceiling by analyzing each trace independently before aggregating the findings. This approach helps it identify failure modes that a single pass over many traces can miss.

Figure 5 summarizes the AppWorld and WebShop comparison across the four methods. The Sub-Agent Reflector achieves the highest success rate, and, across both AppWorld and WebShop, the Single Agent Reflector and Sub-Agent Reflector outperform the GEPA and MIPROv2.

AppWorld success rates and optimization times for GEPA, MIPROv2, the Single Agent Reflector, and the Sub-Agent Reflector

Figure 5: Performance comparison on AppWorld and WebShop across the four methods

Figure 6 compares the number of turns consumed and the wall-clock optimization time across the four methods. The Single Agent Reflector is the most efficient option, using the fewest turns and the least wall-clock time on both benchmarks. The Sub-Agent Reflector also maintains a competitive optimization cost. On AppWorld, it uses the same 100 turns as GEPA and MIPROv2 and completes faster than MIPROv2. On WebShop, its approximately 20-minute wall-clock time is less than half that of either baseline, despite its more extensive trace analysis.

WebShop rewards and optimization times for GEPA, MIPROv2, the Single Agent Reflector, and the Sub-Agent Reflector

Figure 6: Turns consumed and wall-clock optimization time on AppWorld and WebShop across the four methods

| | GEPA | MIPROv2 | Single Agent Reflector (ours) | Sub-Agent Reflector (ours)
---|---|---|---|---|---
AppWorld (baseline 72.62%) | Success rate | 79.63% | 74.40% | 81.55% | 95.83%
| Configuration | 20 × 5 | 20 × 5 | 20 × 1 | 10 × 10
| Number of turns | 100 | 100 | 20 | 100
| Optimization time | 108 minutes | 216 minutes | 6 minutes | 193 minutes
WebShop (baseline 75.03%) | Reward | 74.77% | 72.12% | 78.31% | 79.15%
| Configuration | 10 × 5 | 5 × 5 | 5 × 1 | 20 × 10
| Number of turns | 50 | 25 | 5 | 200
| Optimization time | 48 minutes | 60 minutes | 1 minute | ~20 minutes

Table 1: Best result per method on each benchmark, with the configuration that produced it. Baseline scores are shown in parentheses, and bold indicates the highest score per benchmark. For each benchmark, we report the headline metric, the configuration, total turns, and wall-clock optimization time. Configurations aren_samples × epochs for the Single Agent Reflector and Sub-Agent Reflector and n_samples × iterations for GEPA and MIPROv2. We scanned n_samples from 5–50 and epochs or iterations from 1–10. The reflector model was Opus 4.6, and the task model was Sonnet 4.5.

Best practices and looking forward

  • Start with a small trace set. In our experience, 10–50 diverse traces can provide a useful starting point for optimization. Start small and grow the set only if the recommendations are too narrow.
  • Use more than a scalar reward when appropriate. The reflector reads traces as files, so any signal written into a trace is available to it. Alongside the scalar score, free-text feedback, such as an evaluator rationale, a human annotation, or a user complaint, can be included in the same trace file for reflection.
  • Review and validate recommendations. Use the recommendation explanation, offline evaluations, and controlled A/B testing to assess a proposed configuration before promoting it to production.
  • Use independent trace analysis for diverse failure modes. The experimental, open source Sub-Agent Reflector analyzes traces independently before aggregating the findings. Consider this approach when different subsets of traces reveal distinct failure patterns.
  • Extend the analysis beyond system prompts. Trace evidence can also identify opportunities to improve tool descriptions and reusable skills. Apply the same guardrails and validation workflow when evaluating these types of configuration changes.
  • Start with the managed optimization workflow. For most production use cases, AgentCore optimization provides the recommended path from traces to recommendations and validation. Teams with specialized research or integration constraints can apply the same trace, evaluation, and validation pattern to a custom reflection workflow.

AgentCore optimization connects trace-based evidence to recommended configuration updates and validation workflows. To get started, visit the Amazon Bedrock AgentCore detail page, read the optimization documentation, open the Amazon Bedrock AgentCore console, and explore the AgentCore samples repository.


About the authors

Han Ding

Han is a Senior Applied Scientist at AWS based in San Jose, specializing in agentic AI systems, reinforcement learning, and inference optimization. He led the science effort for the launch of AgentCore optimization. Previously, he led research and engineering initiatives in multimodal search at Amazon Retail. He holds multiple patents and has published extensively on these topics.

Yawei Wang

Yawei is a Senior Applied Scientist at AWS AI in California. His work focuses on AI research and product development, including model distillation, reinforcement learning, inference-time scaling, harness optimization, and benchmark development for agentic AI. His contributions have been incorporated into AWS products and shared through research publications and patents, delivering meaningful value to customers.

Panpan Xu

Panpan is a Principal Applied Scientist at AWS AI. Her latest research focuses on self-evolving agents and continuous learning, helping customers customize models and use agentic reinforcement learning in their agent-development workflows.