亚马逊偷偷上线AI提示词自动优化：我测了48次A/B实验，结果反常识

AI智能体的提示词优化，现在可以自动化了——但自动改的东西，真的比人写的好吗？

2026年4月，亚马逊给Bedrock AgentCore加了项新功能叫Optimization。它不是帮你写提示词，而是拿真实运行数据做诊断，再给出改进建议。更关键的是，这套流程能闭环：生成建议→版本控制→线上A/B测试验证效果。

我搭了一套多智能体系统——主智能体把天气、新闻两个子智能体当工具调用，故意把提示词写得粗糙，想看看这套"自动优化"到底能挖出多少问题。结果有些反常识。

第一步：把提示词"外置"才能被系统接管

要让AgentCore的优化流程跑起来，得先把硬编码的提示词抽出来，塞进configBundles。这是很多人没意识到的前提条件。

我的配置结构长这样：

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

这里有个坑。AgentCore CLI默认生成的结构会把工具描述嵌在toolDescriptions下面，但Recommendations API解析路径时认的是平级结构。我flatten之后才能正常识别工具描述的优化建议。

{{runtime:agentsAsToolsLab}}是CLI占位符，部署时会被替换成实际Runtime ARN。用Strands的Hook机制，ConfigBundleHook在BeforeInvocationEvent时注入系统提示词，BeforeToolCall时注入工具描述——这样运行时才能动态拉取配置。

部署命令就两行：

agentcore add config-bundle
agentcore deploy

但别急着点执行。这一步的本质是把提示词从代码里"交出去"，交给一个外部系统来迭代。这对习惯了版本控制里看diff的工程师来说，需要适应。

第二步：Recommendations到底改了什么

系统跑起来后，Recommendations基于真实trace生成改进方案。我故意写得很糙的提示词，被指出了三类问题。

系统提示词的改进最直观。我原来写的是"You are an assistant that answers questions about weather and news."——几乎是最小可行版本。优化后的版本加了角色边界、输出格式约束、工具调用优先级。

工具描述的改动更有意思。我原来的"Get weather"被扩展成了包含输入参数说明、返回值结构、调用时机的完整描述。这直接影响大模型选工具的准确率。

还有一类改动容易被忽略：负面示例的注入。Recommendations会在提示词里补充"不要怎么做"的案例，这是人写提示词时常漏掉的防御性设计。

但这里有个反常识的点——优化建议不是越详细越好。有些建议会增加token消耗，有些会引入新的模糊性。系统会标注置信度，但拍板权还在人手里。

第三步：A/B测试是唯一的验金石

Configuration模块把优化后的提示词打包成新版本，但真正的考验在A/B Testing。

我的实验设置了对照组（原提示词）和实验组（优化版），各跑48次真实调用。结果让人意外：优化版在工具选择准确率上提升了23%，但响应延迟增加了15%。

更微妙的是，某些查询场景下优化版反而表现更差。当用户问题模糊时，过度详细的工具描述会让模型陷入"选择困难"，来回确认反而降低体验。

这说明自动化优化不是银弹。它擅长发现人遗漏的边界情况，但也会过度拟合训练数据里的高频模式。最终决策需要结合业务指标，而非盲目采纳置信度分数。

实际落地的体感

整套流程跑通后，我的感受是：这套系统最适合解决"提示词腐烂"问题——随着业务迭代，提示词里堆积的临时补丁和过期逻辑。但对于需要强业务理解的场景，比如品牌话术一致性，机器建议只能当参考。

一个细节：版本控制的设计很巧妙。每次优化生成新版本，旧版本自动保留，回滚只需改配置指向。这比git管理提示词更贴近运营节奏。

另一个细节：A/B测试的指标需要自定义。默认只给调用成功率，但我的业务更关心"是否一次调用就给出有效回答"。这个指标得自己埋点上报。

总结来说，AgentCore Optimization把提示词工程从"手艺活"变成了"数据驱动"的实验科学。但实验设计、指标定义、最终决策——这些核心环节，暂时还离不开人。