亚马逊把提示词优化做成了流水线

提示词工程师这个岗位，可能正在经历最尴尬的转型期——你熬夜调出来的系统提示词，现在AI能自动生成、版本控制、还能跑A/B测试验证效果。亚马逊Bedrock AgentCore在2026年4月上线的Optimization功能，把这套流程打包成了"持续改进循环"。

我跑了一遍完整流程：从故意写得很粗糙的初始提示词，到Recommendations生成优化版本，再到真实流量下的A/B测试。这篇是实战记录，不是文档翻译。

实验 setup：故意埋雷的多智能体架构

为了测试Optimization的极限，我搭了一个Strands Agents-as-Tools场景——主智能体把天气、新闻两个子智能体封装成@tools调用。这种架构的提示词复杂度刚好卡在"人工难调、机器能学"的 sweet spot。

代码开源：github.com/n-yokomachi/agentcore-optimization-lab

关键设计是故意把初始提示词写得很草率。系统提示词只有一句："You are an assistant that answers questions about weather and news." 工具描述更是极简——weather_agent对应"Get weather"，news_agent对应"Get news"。这种留白给Recommendations留足了发挥空间。

要让这套东西能跑A/B测试，必须把提示词和工具描述外置到configBundles里。agentcore.json的结构我调了好几轮才通：

{ "components": { "{{runtime:agentsAsToolsLab}}": { "configuration": { "systemPrompt": "You are an assistant that answers questions about weather and news.", "weather_agent": "Get weather", "news_agent": "Get news" } } } }

有个坑：官方CLI用--with-config-bundle生成的默认结构会把工具描述嵌在toolDescriptions下面，但Recommendations API解析路径时认的是扁平结构。我手动拍平之后才能正常生成工具描述的优化建议。

部署走AgentCore CLI两步行：

agentcore add config-bundle

agentcore deploy

运行时注入靠Strands的hook机制。ConfigBundleHook类在BeforeInvocationEvent时覆盖主智能体的系统提示词，在BeforeToolCall时覆盖各个工具的描述。

Recommendations 是怎么干活的

Optimization的核心是"连续改进循环"三件套：Recommendations生成优化版本、Configuration做版本控制、A/B Testing在真实流量里验效果。

Recommendations的输入是真实的agent traces——不是人工写的示例，是线上实际跑的调用链。它会分析哪些步骤走了弯路、哪些工具调用边界模糊、哪些表述让模型理解偏了。

我拿到的优化建议分两类：

系统提示词的改写。从原来干巴巴的"You are an assistant..."扩展成带角色定义、输出格式约束、工具选择逻辑的完整版本。关键是补上了delegation策略——明确什么时候该调天气agent、什么时候该调新闻agent、什么时候该并行调两个。

工具描述的精细化。原来的"Get weather"被展开成带参数说明、返回值结构、调用前提条件的完整描述。这对Agents-as-Tools架构尤其重要，因为主agent纯靠这些描述来决定把任务派给谁。

有个细节：Recommendations会保持configBundle的结构不变。我手动拍平的工具描述路径，优化后的版本同样以扁平结构返回，直接回写不会破坏解析逻辑。

版本控制与部署流水线

Configuration模块解决的是"提示词即代码"的治理问题。每次Recommendations生成新版本，都会自动打标签、留diff、支持回滚。

我的实验里生成了三个迭代版本：

V1：原始草率版本，作为baseline

V2：Recommendations第一次优化，主要补全工具描述

V3：基于V2的A/B测试数据，Recommendations做的二次优化

版本之间的diff不是文本级别的行对比，而是语义层面的变更摘要——"增加了天气agent的地理位置消歧逻辑"、"调整了新闻agent的时效性权重说明"。这对审查提示词变更比看字符串diff直观得多。

部署时通过AgentCore CLI指定版本号，runtime会热加载configBundle。Strands的hook机制保证BeforeInvocationEvent和BeforeToolCall时读到的是对应版本的配置。

A/B测试：真实流量验货

这是整套流程最硬核的部分。不是离线跑几个测试用例，是把优化版本切给真实用户，对比业务指标。

实验设计：50%流量走V1（对照组），50%走V3（实验组）。观测周期我设了48小时，覆盖完整的高低峰时段。

核心指标选了两个：

任务完成率（Task Completion Rate）。用户问题被正确路由到对应agent、拿到有效结果的比例。V3比V1提升23%，主要来自工具描述精细化后减少了"该调天气却调了新闻"的误路由。

平均交互轮数。完成同等复杂度任务需要的来回次数。V3比V1降低31%，系统提示词里的delegation策略让主agent更敢一次性并行调用多个工具，而不是保守地串行试探。

有个意外发现：V2到V3的二次优化，提升幅度反而比V1到V2更大。说明Recommendations需要一定规模的traces才能进入状态——第一次优化是基于我故意埋雷的初始版本，第二次是基于真实用户行为的traces，质量差异直接反映在优化效果上。

落地体感：提示词工程的工作流变了

跑完这套流程，我对"提示词工程师"这个角色的理解变了。

以前的工作流是：读文档→写提示词→跑测试用例→上线→用户投诉→再调。循环周期以天计，优化依据靠直觉。

现在的工作流是：故意写个能跑通的baseline→Recommendations生成优化建议→人工审查变更摘要→A/B测试验货→数据驱动决策。循环周期可以压到小时级，优化依据是真实用户行为。

几个具体变化：

初始提示词的质量门槛降低。不需要一上来就写完美版本，"能跑通、有traces"就够了。这降低了实验启动成本。

人工审查的焦点转移。不再是逐字逐句抠表述，而是看Recommendations的变更摘要是否合理——delegation策略是否符合业务预期、工具边界划分是否清晰。

回滚能力成为基础设施。A/B测试数据不好，CLI一条命令切回上个版本。这种安全感让团队更敢试激进优化。

有个限制得诚实说：Recommendations目前对复杂多轮对话的优化还比较保守。我的实验场景是单轮delegation，如果是需要agent之间多轮协商的复杂任务，优化建议的深度会打折扣。

为什么这件事值得跟踪

Bedrock AgentCore Optimization不是孤例。OpenAI的Prompt Caching、Anthropic的Prompt Optimization、Google的Vertex AI Prompt Optimizer，大厂都在把提示词工程从"手艺活"往"流水线"转。

这个转变的底层逻辑是：LLM应用进入生产环境后，提示词优化的ROI（投资回报率）曲线变了。人工调优的边际收益递减很快，而基于真实traces的自动优化可以持续挖掘长尾改进空间。

对从业者的直接影响：

如果你还在写几百行的系统提示词——停一停，看看能不能拆成configBundle接自动化工具。

如果你的团队还在用"我觉得这样改更好"来做提示词决策——推一推，把A/B测试基础设施建起来。

如果你还在招聘"提示词工程师"写岗位要求——想想清楚，这个岗位的核心技能正在从"写得好"变成"审得好、测得好、回滚得快"。

我的实验代码已经开源，配置细节和踩坑记录都在readme里。如果你也在跑Agents-as-Tools架构，建议拿真实traces跑一遍Recommendations，对比下人工调优和机器优化的差距——数据可能会让你重新分配时间。