Amazon Bedrock AgentCore 提示词优化：将智能体轨迹转化为经过测试的改动

Amazon 正将智能体提示词调优从手动编辑推进到自动化阶段，但其最强结果也揭示了一项艰难的生产环境权衡。Amazon Bedrock AgentCore 提示词优化现可利用已评估的轨迹，推荐系统提示词改动、筛选这些改动，并在推广前验证有前景的版本。

该工作流连接了 AgentCore Observability、评估、推荐、配置包和受控 A/B 测试。这一点很重要，因为看似合理的改写未必就是更好的生产提示词。它必须在不削弱安全指令、不复制测试示例、也不膨胀为难以管理的策略文档的前提下，提升所选指标。

AWS 于 2026 年 9 月 16 日公布了其技术设计和基准测试结果。其 Single Agent Reflector 倾向于较短的优化周期，而实验性的 Sub-Agent Reflector 则取得了报告中的最高分。该比较将 AWS 与 GEPA 和 MIPROv2 等成熟方法并列，但更重要的竞争发生在自动化推荐与许多团队仍在使用的手动提示词调优流程之间。

Amazon Bedrock AgentCore 提示词优化闭环测试流程

核心变化不只是自动改写。AgentCore 将拟议的提示词改动与证据、版本控制、评估和受控推广连接起来。

系统提示词定义了智能体的角色、运行约束、工具行为和决策规则。措辞的细微变化可能影响智能体是否会要求澄清、选择正确的工具，或在达成目标后停止操作。这些变化也可能在其他环节引发意外故障。

团队传统上通过人工诊断来处理这一问题。工程师审查冗长的执行轨迹，找出可能的失败模式，编辑提示词，然后重新运行选定测试。该流程在原型阶段可以奏效，但面对不断变化的模型、工具、数据和用户行为时，很难持续复现。

AgentCore 优化将这一循环正式化。根据其技术分析，评估器首先为已完成的智能体轨迹分配奖励值。随后，优化器会检查成功与失败的行为，再提出修订后的系统提示词并说明其推理依据。

评估器并非中立组件。它决定了优化过程将奖励何种行为。AWS 支持内置评估器、自定义语言模型裁判和基于代码的评估器，前提是它们能够返回数值信号。

对于事务型智能体，所选目标可能是目标完成率。开放式助手则可能优化帮助程度。若通用标准无法捕捉所需行为，特定领域的智能体可使用自定义评估器。

这一选择构成了本文的核心张力。自动化优化比人工审查零散日志更能持续地进行搜索，但它只能改善由其轨迹、评估器和验证流程所呈现的行为。

AWS 明确警告称，推荐由语言模型生成，仍需人工审查。其推荐指南还指出，所选评估器决定了优化的方向。

这意味着，推荐并非权威性的修正，而是关于当前提示词应如何修改的一项可测试假设。

AgentCore 提供配置包，让这一假设能够落地执行。配置包是不可变快照，其中包含系统提示词、模型标识符和工具描述等内容。团队无需将每一项行为变化都直接嵌入应用程序代码，便可比较不同版本。

平台的 A/B 测试层随后可通过 AgentCore Gateway 在两个版本之间分流流量。在线评估会为会话评分，系统则报告观察到的差异是否达到统计显著性。

这一流程比文本生成器产出一条修订指令更具影响力。它将提示词编辑转变为一种发布流程，在改动前后均有证据支撑。

该工作流也对那些将提示词视作非正式配置的团队提出了要求。一旦提示词会影响工具权限、客户结果和业务流程，未经记录的修改就会成为运营风险。版本化推荐和受控测试提高了对智能体行为管理方式的要求。

Reflector 将轨迹视为工作数据集

AWS 并未将每条轨迹都塞进同一个提示词中。其 reflector 获得基于文件的访问权限，并自行决定哪些证据值得深入检查。

优化器背后的推理组件称为 agentic reflector。它审查已评估的行为，识别成功运行与失败运行之间的模式，并提出有针对性的配置修改。

智能体轨迹可能包括用户消息、模型推理、工具调用、工具响应、中间状态和评估器反馈。即使只有数十条详细轨迹，也可能超过模型的上下文窗口。若只是将所有内容粘贴进一个分析提示词，就不得不截断或进行激进摘要。

AWS 转而将已评估的轨迹写入 reflector 可访问的目录。reflector 获得 shell 访问权限以及调查证据的指令。它可以列出文件、搜索反复出现的术语、比较输出，并打开选定轨迹。

这一设计将轨迹语料库视为外部工作记忆。模型无需同时在活动上下文中保留每次执行的全部内容。当逐渐形成的假设需要时，它才检索相关证据。

reflector 可能先从分数分布着手，找出表现异常弱的运行，再将其与类似任务的成功执行进行比较。随后，它可检查行为偏离的位置，例如错误的工具选择，或不必要的额外操作。

AWS 表示，它并未强制采用固定的轨迹摘要流程。由 reflector 决定哪些文件、比较方式和失败模式更重要。这种灵活性可以保留通用摘要器在分析开始前可能删除的细节。

但这也带来了可复现性问题。两次 reflector 运行可能检查不同证据，或优先处理不同模式。最终提案可能取决于 reflector 模型、可用工具、评估器输出和采样的轨迹集合。

AgentCore 通过为拟议改动附上解释，处理了其中一部分不确定性。审查者可以比较当前和修订后的提示词，同时查看促成该编辑的轨迹模式。

解释很重要，但它不是证据。模型可以为一项薄弱推荐给出令人信服的理由。离线评估和受控生产测试仍承担着举证责任。

Single Agent Reflector 由一个智能体完成这一调查。它浏览轨迹集合，深入选定片段，比较成功与失败案例，并返回一套连贯的修改建议。

每个优化 epoch 都会重复一个既定循环：为轨迹评分、基于证据反思，并且只接受通过防护规则的修改。当进一步的质量提升足以证明额外优化时间的价值时，团队可以运行更多 epoch。

这一设计偏重综合判断。单个 reflector 保留完整的调查脉络，并能连接多条轨迹中发现的模式。但早期观察结果可能影响它后续检查的内容。

AWS 描述了一种可能的失败模式：一次运行会集中关注它最先打开的五到十条轨迹中的模式。语料库其他位置的罕见问题可能因此一直被忽视，尤其当轨迹集合包含多个彼此无关的任务类型时。

Sub-Agent Reflector 正是在这里改变了机制。它不将完整语料库交给一位调查者，而是由协调器将单条轨迹委派给独立的子智能体。

每个子智能体执行三个层次的分析。它首先记录奖励值、难度和结果；然后定位轨迹偏离优选路径的决策点；最后诊断失败原因并提出纠正规则。

协调器收集这些发现，合并重复观察结果，并将其概括为配置改动。独立上下文降低了某个早期理论影响全部轨迹审查的可能性。

因此，Sub-Agent Reflector 花费更多计算资源来扩大失败覆盖范围。其架构类似于一个审查团队：成员分别检查不同事件，再由主编整合结论。

AWS 将这一方法作为开源 Strands 项目中的实验性功能发布。它并未被定位为默认的托管优化器。Single Agent Reflector 仍是 AgentCore 优化中描述的生产级推荐引擎。

Single Agent 与 Sub-Agent Reflector 的结果区分了速度与质量

AWS 的基准测试结果并未选出唯一的普适赢家，而是区分了最快的实用优化器与报告中质量上限最高的方法。

AWS 在 AppWorld 和 WebShop 上评估了两种 reflector。AppWorld 在模拟应用程序和相互关联的任务中测试智能体，而 WebShop 评估智能体通过网站交互完成购物目标的能力。

该公司将其方法与 GEPA 和 MIPROv2 进行了比较。两者都是可通过更广泛 DSPy 生态系统获得的成熟提示词优化方法。

MIPROv2 会创建候选指令和示例，然后使用贝叶斯优化来搜索不同组合。GEPA 则基于轨迹和反馈进行语言模型反思，通过反复提出和筛选方案来演化提示词。

这一竞争背景很重要，因为基于轨迹的反思并非始于 AgentCore。GEPA 研究描述了一种优化器，它以自然语言诊断轨迹并演化提示词候选方案。DSPy 优化器指南也将 MIPROv2 和 GEPA 记录为不同的优化策略。

AWS 在多种配置下测试了这四种方法，并报告了每种方法观察到的最佳结果。它扫描了从 5 到 50 的样本数，以及从 1 到 10 的 epoch 或迭代次数。Opus 4.6 作为 reflector 模型，Sonnet 4.5 则作为任务模型。

在 AppWorld 上，未经优化的基线成功率为 72.62%。GEPA 在 100 个回合和 108 分钟后达到 79.63%。MIPROv2 在 100 个回合和 216 分钟后达到 74.40%。

Single Agent Reflector 使用 20 个回合和 6 分钟达到 81.55%。AWS 将该运行时间描述为：在取得相当或更好结果的情况下，速度比 GEPA 快 18 倍、比 MIPROv2 快 36 倍。

Sub-Agent Reflector 在同一基准上达到 95.83%。它使用了 100 个回合，耗时 193 分钟。这是报告中 AppWorld 的最高分，但其回合数与两个基线相同，耗时则远高于单 reflector 运行。

WebShop 的结果显示出更小的质量差距。其基线奖励值为 75.03%。GEPA 在 50 个回合和 48 分钟后达到 74.77%，而 MIPROv2 在 25 个回合和 60 分钟后达到 72.12%。

单代理 Reflector 在五轮和一分钟内达到 78.31%。子代理 Reflector 在 200 轮和约 20 分钟内达到 79.15%。

这些数据让实际选择变得格外清晰。

对于快速迭代而言，单代理 Reflector 在报告质量与时间的平衡上表现最佳。它在两项报告指标上都超过了对比方法，同时使用的轮次最少、实际耗时最短。

对于追求最高基准性能而言，子代理 Reflector 赢得了两项任务。其最大优势出现在 AppWorld 上，分布式检查可能发现了更多样化的失败模式。

WebShop 的结果让质量叙事变得更复杂。子代理方法花费 200 轮，仅比单代理结果高出 0.84 个百分点。这一差距在高吞吐量或高价值工作流中可能很重要，但许多团队会质疑它是否值得额外的优化工作。

这些基准测试也支持一个关于智能体评估的更广泛结论：一种在某个环境中看似高效的方法，可能需要在另一个环境中获得更广泛的轨迹覆盖。AppWorld 和 WebShop 代表不同的任务结构，因此单一分数无法证明其具有普遍优势。

正如其基准论文所述，AppWorld 本身包含数百项跨模拟应用的任务。这种多样性使其适合测试多步骤行为，但它仍然是一个受控环境。

生产轨迹会带来更混乱的输入、不断变化的界面、不完整的目标，以及特定组织的约束。用户可能中途放弃任务、提供相互矛盾的指令，或期待评估器从未编码过的行为。

AWS 还报告了每种方法在扫描多组配置后的最佳结果。这是一种合理的实验呈现方式，但它无法说明团队能否稳定地预先选出最佳设置。当优化成为持续的生产流程时，搜索成本和配置敏感性同样重要。

因此，已发布的数据应被视为 reflector 设计在两项公开任务上具备竞争力的证据。它们不应被视为智能体部署后会以相同幅度提升的保证。

自动化提示词调优正在给人工审核带来压力

AgentCore 真正的对手，是工程师修改提示词、重跑少量示例、再推广看起来更好版本的非结构化编辑循环。

人工提示词调优依然常见，因为它门槛较低。开发者可以检查一段失败的对话，补充一条指令，然后再次测试相同场景。反馈来得很快，改动往往也显得直观。

但随着提示词不断累积例外规则，这一过程会变得不那么可靠。为解决一次失败而加入的规则，可能与先前约束发生冲突。另一处编辑可能修复工具选择问题，却让智能体在其他地方变得过度谨慎。

结果往往是提示词膨胀。系统提示词变成一系列针对具体事故的补丁，而不再是连贯的行为策略。更长的提示词会增加推理开销，也让冲突更难被发现。

自动化优化器同样面临这种失败模式。每当轨迹揭示新的错误时，它们可能学会添加更多限定条件。更高的评估器分数并不自动意味着修订后的提示词更清晰或更具泛化能力。

AWS 在接受候选方案前，会应用三项基于评分标准的护栏。首先，它会拒绝比上一版本增长超过 20% 的配置，并要求优化器收紧修订内容。

其次，它会依据安全标准筛选候选方案。这项检查针对的是为了追逐任务完成分数而可能放松限制的修订。

第三，它禁止候选方案复用优化轨迹中出现的精确短语。这项规则降低了模型记住示例表面细节、而非提炼可迁移指令的风险。

这些护栏揭示了 Amazon 预期可能出错的地方。优化器可能生成准确但过于庞大的提示词、削弱安全边界，或对其证据过拟合。该平台围绕这些风险进行设计，而不是假定反思过程能够自行避免它们。

评估器仍然是最重要的压力点。如果它只奖励任务完成，而不惩罚不必要的信息披露、不安全操作或糟糕的用户体验，优化器的目标就不完整。

AWS 更广泛的优化工作流通过离线测试和在线实验来应对这一问题。不过，两种机制都无法独自修复一个选择不当的指标。

目标成功评估器可能偏好能够高效完成预订的智能体，但未必能发现智能体是否清晰解释了严格的取消规则。一个有帮助程度评判器则可能奖励冗长的回答，即使它拖慢了时间敏感型工作流。

因此，人工审核并未消失，而是发生了转移。审核者不再需要手动构思每一个候选提示词，但仍必须评判证据、评估器、拟议改动和测试设计。

这改变了智能体团队所需的技能。提示词编写依然有用，但评估设计和轨迹治理变得同等重要。团队需要知道哪些行为可以衡量、哪些失败尚未被覆盖，以及哪些改动需要额外的安全审查。

配置包也让提示词更接近传统的发布工程。团队可以保留不可变版本、比较行为，并在无需重新部署完整智能体应用的情况下推广已验证的配置。

这种分离有助于组织跨环境管理智能体行为。但它也带来一个新的治理问题：当配置控制工具使用、数据访问或面向客户的决策时，谁有权批准提示词变更？

工程师可能负责系统可靠性，而安全团队负责访问策略。产品团队可能定义期望行为，法务团队则可能管理必要披露。推荐工作流需要能反映这些职责的审批边界。

同样的问题并不局限于提示词。AWS 表示，轨迹证据能够识别薄弱的工具描述和可复用技能。即使核心系统提示词保持不变，这些组件仍可能实质性地改变行为。

同时优化三者可能带来更大的收益，但也会使归因更困难。如果新的提示词、工具描述和技能包同时进入一个测试变体，团队可能无法知道究竟是哪一项改动带来了结果。

这正是严谨实验的重要性所在。受控测试应在可行时隔离有意义的改动，定义停止标准，并保留回滚路径。

已经在构建可搜索知识工作流的组织也面临类似挑战。更好的检索无法弥补一个错误说明何时搜索、应信任何种证据或何时要求澄清的智能体提示词。

AgentCore 优化可以帮助从轨迹中识别这些行为失败，但它无法决定组织可接受的风险或信息政策。

基准收益仍取决于证据管道

优化器只能从轨迹和评估器揭示的内容中进行泛化，因此生产覆盖范围比令人印象深刻的孤立分数更重要。

AWS 建议从 10 到 50 条多样化轨迹开始。这个范围能为 reflector 提供足够的变化来发现模式，同时不会立即形成难以管理的分析任务。

“多样化”一词比数量本身更重要。50 次几乎相同的成功运行，其诊断价值不如一组规模更小、但涵盖不同任务、难度级别、工具、结果和用户行为的样本。

罕见失败构成了特殊挑战。一个生产智能体可能在数千次会话中仅有一次错误处理敏感请求。随机抽取的轨迹样本可能遗漏该案例，而平均奖励则可能掩盖它。

子代理 Reflector 通过独立检查轨迹提供了一种应对方式。它可以为少数失败模式提供专门的上下文，而不是让高频模式主导单个 reflector 的注意力。

然而，独立性无法解决证据缺失的问题。任何分析方法都无法诊断未出现在收集轨迹中的失败。团队仍需要有目的的采样、定向测试和由事故驱动的评估集。

自由文本反馈可以补充有用上下文。AWS 表示，reflector 可以读取与轨迹一起存储的评估器理由、人工标注或用户投诉。这些信息可能解释为何数值上相似的失败应得到不同处理。

它也引入了另一种不一致来源。人工标签可能存在分歧，评估器理由可能不可靠，用户投诉也可能反映偏好而非政策违规。

轨迹处理同样带来隐私和安全担忧。智能体运行可能包含个人信息、专有数据、工具输出和隐藏的运营细节。基于文件系统的分析设计需要适当的访问控制、保留规则和脱敏实践。

已发布的技术文章侧重于优化机制和基准性能，并未为每个组织的轨迹治理义务提供通用答案。

模型依赖性是另一项不确定因素。AWS 在报告实验中使用 Opus 4.6 进行反思，并使用 Sonnet 4.5 执行任务。不同的 reflector 模型在调查深度、工具使用以及综合相互矛盾证据的能力上可能存在差异。

未来的模型更新可能同时改变智能体的基线行为和优化器的建议。当任一组件发生变化时，团队应重新运行具有代表性的评估。

基准迁移性同样尚未得到验证。AppWorld 和 WebShop 测试了有用的智能体行为，但两者都无法代表所有企业工作流。客户支持智能体、编码智能体或受监管的决策助手，可能通过截然不同的机制发生失败。

因此，95.83% 的 AppWorld 结果值得关注，但其适用范围有限。AWS 表示，子代理 Reflector 在其报告的扫描中达到了这一分数。若能在其他智能体框架和任务模型中获得独立复现，将进一步增强这一主张。

也不应仅凭两组对比就否定 GEPA 和 MIPROv2。它们各自的配置选择、优化预算、程序结构和预期使用场景可能与 AgentCore 的托管工作流不同。

实际问题并不是某一个优化器是否赢得通用排名，而是某种方法能否在团队的约束下带来可靠的改进。

一个有用的生产测试应考察候选方案是否提升了留出任务的表现、是否保留安全要求、是否避免回归，以及是否在不同用户群体中保持一致表现。延迟和运营成本也应纳入评估。

在线 A/B 测试引入真实流量，但团队必须谨慎使用。高风险行为不应仅仅因为平台可以分流流量就触达用户。离线门槛和专家审核应决定哪些变体有资格进行线上曝光。

统计显著性也无法替代实际显著性。一个微小的测量改进可能在统计上可信，却在运营上无关紧要。反过来，罕见的安全回归即使几乎不改变平均分数，也可能很重要。

当组织将推广视为一项政策决策时，AgentCore 的验证模型最具优势：优化器提出建议，证据进行筛选，由承担责任的负责人作出决定。

三个信号将显示 AgentCore 优化能否迁移到生产环境

下一项测试不是又一个孤立基准，而是团队能否在不断变化的智能体中重复这一改进循环，同时不累积隐藏的回归。

第一个信号是评估范围是否能扩展到更多模型、Agent 框架和真实工作流。AWS 的结果使用了一个反思模型、一个任务模型，以及两个公开基准。后续复现应验证 Single Agent Reflector 能否保持速度优势，以及子 Agent 是否仍具备质量优势。

一致的结果将强化这样一种观点：基于文件的反思是一种通用的优化模式。若结果差异很大，则可能意味着模型选择、轨迹格式或任务结构比反思器架构本身更重要。

第二个信号是持续生产环境采用的证据。团队应报告：在流量、工具和用户行为发生变化后，优化后的提示词是否仍能持续发挥作用。

某个候选方案可能赢得初始 A/B 测试，却在环境变化后出现性能下降。重复评估周期、回滚率以及被推广配置的存续时间，比一次性评分更能说明问题。

第三个信号是能力是否会扩展到系统提示词之外。AWS 表示，轨迹分析可以指导对工具描述和可复用技能的改动。这类建议将使 AgentCore 更接近于优化更广泛的 Agent 配置。

如果团队能够归因改进效果并保留安全边界，这种扩展将增强产品价值；如果组合式改动变得难以审查、测试或解释，则会削弱这一论点。

对构建者而言，眼下的行动很直接：将 Amazon Bedrock AgentCore 提示词优化视为一种能够产出证据的发布工作流，而不是自动审批系统。先从具有代表性的轨迹集合开始，定义能够反映真实目标的评估器，并保留未见案例用于验证。

随后，在考虑引入实时流量前，先通过离线评估将推荐方案与当前配置进行比较。审查提示词的增长幅度、安全措辞、敏感数据处理方式，以及目标指标以外的性能回归。

反思器基准表明，在 AWS 的测试条件下，自动化分析能够优于速度更慢的搜索方法。其长期优势将取决于组织能否以同样严谨的方式构建周边测量体系。你的评估器今天会奖励哪些行为？它又仍可能忽视哪些代价高昂的失败？