AWS详解AgentCore系统提示词优化器：AppWorld最高 95.83%，6 分钟方案快 18 倍
Amazon Bedrock AgentCore的系统提示词优化器用生产轨迹自动改写系统提示词，并通过平台护栏审查；AWS公布其在AppWorld和WebShop两个公开基准上的结果，Single Agent Reflector六分钟达到 81.55%，Sub-Agent Reflector达到 95.83%。
AI解读：这套东西解决的是一个很具体的体力活：agent表现不好时，以前得人工翻很长的运行轨迹，找到出错的地方，改提示词、改工具描述，再跑一遍评测看有没有变好。AgentCore optimization把这些步骤接了起来——从生产轨迹里提出配置修改建议，经过离线批量评测和线上A/B测试验证，赢了的版本才推上去。
优化器内部的“反思器”不是把轨迹压缩后再喂给模型，而是把完整轨迹放到文件系统里，给它一个shell工具，让它自己用grep、cat、diff去翻。这样做的理由是轨迹太长，几十条就超上下文窗口，与其截断，不如让模型自己决定看哪段、比什么。
两个反射器设计的取舍很直白。Single Agent Reflector一趟读完整个轨迹集，效率最高：AppWorld上 6 分 20 秒、20 轮达到 81.55%，比GEPA快 18 倍、比MIPROv2快 36 倍，分数还略高或持平。
Sub-Agent Reflector则给每条轨迹派一个独立上下文的子agent，做表层、轮次级、认知级三层分析，再由编排器汇总去重，分数更高，AppWorld到 95.83%，但时间涨到 193 分钟。
护栏部分值得单独看：候选提示词比上一版长超过 20% 直接打回、要过安全检查、不能逐字复用轨迹里的原句。放宽安全限制去换评测分，正是这类自动优化最容易被带偏的方向，AWS把这三条写成硬规则。
对真正要用的人，最有用的是两个数字门槛：起步轨迹集建议 10 到 50 条多样化样本；标量奖励之外，可以把评测理由、人工标注、用户抱怨这类自由文本一起写进轨迹文件，反射器会读。Sub-Agent Reflector目前只是Strands开源仓库里的实验性初步发布，不是托管功能。
普通读者不用为此做什么。这条新闻的实际影响面是有agent生产流量的团队：他们现在多了一条从轨迹到配置改动的自动化路径，代价是要接受护栏带来的限制，以及Sub-Agent方案多出来的优化时间。
AWS发布了一篇技术文章，作为AgentCore optimization上线文章的配套，详细解释Amazon Bedrock AgentCore中系统提示词优化器（system prompt optimizer）的推荐引擎如何工作，并公布该优化器在AppWorld和WebShop两个公开基准上的评测结果。文章作者为Han Ding。
文章介绍，改进一个评分低的agent传统上是人工流程：查看很长的轨迹，找出agent出错的位置，逐个调整提示词、工具描述和技能等组件，再重新运行评测确认是否改善。AgentCore optimization允许用生产轨迹提出配置修改建议，通过离线批量评测和线上真实流量的A/B测试进行验证，然后推广胜出的版本。
AgentCore Observability提供agent行为的可见性，评测提供agent质量信号。文章称，建议、配置包和A/B测试验证共同构成改进agent的工作流。系统提示词优化器使用记录在AgentCore Observability中的agent轨迹，结合奖励信号，生成改进后的系统提示词。
优化器由agentic reflector执行，它是优化器的推理组件：审查被评测的agent行为，识别区分成功与失败运行的模式，并提出对agent配置的针对性修改。在系统提示词优化工作流中，其主要输出是修改后的系统提示词，外加一份说明，解释为何这些修改应能提升agent质量。
文章给出的核心设计选择是：agent轨迹往往很长，几十条就可能超出模型上下文窗口，因此不把每条轨迹直接塞进反射器提示词。与其截断或预先摘要轨迹，完整的轨迹语料通过文件系统提供给反射器。具体做法是：评测器给一批轨迹打分并写入反射器agent可访问的目录，反射器获得一个shell工具、被指向该目录，并被要求通过检查轨迹中的成功与失败模式来提出配置更新。反射器可以按需检查语料，包括列出文件、用grep搜索、用cat读取轨迹、用diff比较输出，以及有选择地检查成功和失败运行。文章称，他们没有强加固定的信号提取或轨迹摘要流水线，而是由反射器决定哪些证据重要、做哪些比较，以及如何把发现转化为配置修改。
文章提到，任何建议在应用前都必须通过平台级护栏。负责任AI的考虑属于该工作流的一部分：建议应先审查和测试再使用，护栏会在候选更新被推广前对其进行筛查。
Single Agent Reflector：一轮读完整个轨迹集，AppWorld 6分 20 秒达 81.55%
Single Agent Reflector是当前AgentCore optimization中驱动系统提示词推荐的组件。一个反射器agent在单次通过中处理完整轨迹集：它查看分数分布，深入单条轨迹中最有信息量的片段，对比成功与失败，返回一套连贯的agent配置修改。
每个优化epoch重复这一循环：给轨迹打分、反思、接受通过护栏的修改。文章称，可以运行更多epoch，用优化时间换取进一步的質量提升。
在AppWorld基准上，Single Agent Reflector达到 81.55%，用时 6 分钟、20 轮；文章称这相比GEPA有 18 倍加速，相比MIPROv2有 36 倍加速，且分数相当或更好。在WebShop上，它用时 5 轮、1 分钟墙钟时间达到 78.31%。文章称该变体适合想要快速迭代周期的场景。
Sub-Agent Reflector：每条轨迹独立分析，AppWorld到 95.83%，用时约 193 分钟
Sub-Agent Reflector扩展了Single Agent Reflector。它用一群agent动态探索轨迹集的不同部分，以牺牲部分效率换取更高的质量上限。文章解释其动机：单次反射器通过可能只关注它检查的前 5 到 10 条轨迹中的模式，而遗漏只出现在语料较小部分的失败模式。
每个子agent对单条轨迹做三层分析：表层，提取奖励、难度和结果；轮次级，定位轨迹偏离最优路径的决策点，使用jq、grep等shell命令解析rollout JSON；认知层，诊断agent在该决策点失败的原因并给出反思性指导。每个子agent返回一条简洁发现和一条纠正规则。由于每个子agent在自己的上下文窗口中运行，它可以专注一条轨迹而不受其他轨迹影响。编排器汇总发现、归纳重复模式、去重，并把结果凝练为配置修改。
文章称该实验性功能已作为初步版本发布在Strands开源GitHub仓库中。
在AppWorld上，Sub-Agent Reflector达到 95.83%，比基线提升 23 个百分点，比次优方法高 16 个百分点；在WebShop上达到 79.15%，比基线提升 4 个百分点。文章称逐轨迹的子agent分析在AppWorld上效果最明显，那里的失败模式多样，单次反射器通过可能漏掉少数派模式。
成本方面：在AppWorld上它使用与GEPA和MIPROv2相同的 100 轮，完成时间快于MIPROv2；在WebShop上其约 20 分钟的墙钟时间不到两个基线中任一个的一半，尽管做了更广泛的轨迹分析。
护栏：超过 20% 长度增长即被拒绝，禁止逐字复用轨迹原句
文章指出，未经约束的配置优化会以可预测的方式漂移：优化后提示词可能变长，提示词可能引用轨迹中的词句作为示例，安全约束可能为了追求评测分数而被放宽或软化。
因此每个候选更新被接受前都要经过基于评分标准的护栏筛查：长度上限，候选版本比上一版配置增长超过 20% 即被拒绝，并会要求优化器收紧；安全检查，候选在推广前对照安全标准筛查；禁止逐字短语，候选不能复用被优化轨迹中的原句，以帮助防止过度拟合训练轨迹的表面特征。
评测设置：AppWorld与WebShop，对照GEPA和MIPROv2
评测在AppWorld和WebShop两个公开基准上进行，对照两个已有基线GEPA和MIPROv2。文章称，对每个方法都扫描了配置空间，报告最佳结果及其轮数和墙钟优化时间。
配置单位为n_samples × epochs，适用于Single Agent Reflector和Sub-Agent Reflector；对GEPA和MIPROv2则是n_samples × iterations。文章称扫描了n_samples从 5 到 50、epochs或iterations从 1 到 10。反射器模型为Opus 4.6，任务模型为Sonnet 4.5。
AppWorld基线为 72.62%：GEPA 79.63%（配置 20×5，100 轮，108 分钟），MIPROv2 74.40%（20×5，100 轮，216 分钟），Single Agent Reflector 81.55%（20×1，20 轮，6 分钟），Sub-Agent Reflector 95.83%（10×10，100 轮，193 分钟）。
WebShop基线为 75.03%：GEPA 74.77%（10×5，50 轮，48 分钟），MIPROv2 72.12%（5×5，25 轮，60 分钟），Single Agent Reflector 78.31%（5×1，5 轮，1 分钟），Sub-Agent Reflector 79.15%（20×10，200 轮，约 20 分钟）。文章称加粗表示每个基准的最高分。
文章总结两个模式：Single Agent Reflector提供最佳的质量成本权衡，适合快速迭代；Sub-Agent Reflector在两个基准上都取得最高质量，其逐轨迹分析对AppWorld影响最大。文章称这些结果反映了两种设计：整体集反思带来效率，子agent分解通过在汇总前独立分析每条轨迹提高了质量上限。
使用建议：先用 10 到 50 条轨迹，非标量奖励也可写入轨迹文件
文章给出的建议包括：从较小的轨迹集开始，经验上 10 到 50 条多样化轨迹可作为有用的起点，只有建议过于狭窄时才扩大集合。
在适当情况下使用不止标量奖励：反射器把轨迹当文件读取，因此写入轨迹的任何信号它都能获得；除标量分数外，自由文本反馈，例如评测理由、人工标注或用户抱怨，可以放进同一个轨迹文件供反思使用。
审查和验证建议：使用推荐说明、离线评测和受控A/B测试来评估候选配置，然后才推广到生产。对多样化失败模式使用独立的轨迹分析：当不同轨迹子集揭示不同失败模式时，可以考虑实验性的开源Sub-Agent Reflector。
把分析扩展到系统提示词之外：轨迹证据也可以识别改进工具描述和可复用技能的机会；评估这类配置修改时应用相同的护栏和验证工作流。先从托管优化工作流开始：对多数生产用例，AgentCore optimization提供了从轨迹到建议和验证的推荐路径；有特殊研究或集成限制的团队可以把相同的轨迹、评测和验证模式用于自定义反思工作流。
文章称AgentCore optimization把基于轨迹的证据与推荐的配置更新及验证工作流连接起来，并给出开始使用的入口：Amazon Bedrock AgentCore详情页、优化文档、Amazon Bedrock AgentCore控制台和AgentCore示例仓库。