线上 trace 里看到一批低质量回答，Agent 能给出一版更好的 system prompt。下一步能不能直接替换生产配置？我的答案是：不能。
AWS 9 月 16 日发布的 AgentCore Optimization 示例，值得看的不是“AI 可以优化提示词”这句营销话，而是它把流程放在了正确的位置：从生产 traces 发现问题、提出候选改动、验证，然后再晋升。优化建议不是发布指令。
很多团队在提示词迭代上踩过同一个坑：线上遇到失败案例，改一段 system prompt，感觉回复更顺了，就直接上线。这样做很快，但很难知道提升来自哪里，也不知道它有没有悄悄损伤别的任务、工具调用或安全边界。
把 AWS 的思路抽成不绑定厂商的生产闭环，其实只有五步。
1. 先从 trace 定义问题，不要从“感觉不好”开始
不要把“模型最近变笨了”当问题描述。至少拆成：
- 哪一类用户任务失败；
- 失败发生在回答、路由、工具选择还是参数填写；
- 失败样本占多少，集中在哪个版本、模型或工具；
- 正常样本的基线是什么。
没有基线的优化，本质是在随机改配置。
2. 一次只验证一个假设
例如，低质量的原因究竟是 system prompt 没有规定输出格式，还是工具描述太模糊？这两件事不要一起改。
每个候选改动都写成一句可证伪的话：
在不降低工具调用成功率的前提下，补充“先核对来源再输出”的指令，可以降低该类事实错误。
这能让评测结果有解释力。否则即使分数上涨，也无法复用经验。
3. 回放代表性样本，同时守住反向指标
评测集不要只放让你不满意的 trace，也要保留原本做得好的任务，以及高风险边界样本。一次提示词改动可能让某类问答更完整，却让响应变慢、变长，或误触发工具。
至少同时看三类指标：目标任务的成功率、关键工具调用是否仍正确、成本和延迟有没有越过可接受范围。若业务有合规或安全要求，再加入人工复核或专门的安全评测。
4. 让人审“改了什么”，而不是只看总分
候选 prompt 应该和原版本并排展示：改动了哪一句，想解决什么问题，在哪些样本上变好，哪些样本变差。
这一步不是形式主义。提示词往往同时承担角色、工具边界、输出格式和拒答规则；一段看起来无害的改写，也可能扩大工具权限，或把原本应确认的动作推向自动执行。
5. 小流量晋升，并准备回滚
离线通过不等于线上安全。先在明确范围内灰度，持续观察新 trace；一旦关键指标恶化，就能回到上一个已知稳定版本。
一个最小的变更记录可以写成这样：
变更：要求回答前列出证据来源；不确定时标记待确认
假设：降低检索型任务中的无依据结论
离线集：80 条代表性 trace + 20 条边界样本
守门指标：工具选择准确率不下降；P95 延迟增加不超过既定预算
发布：5% 流量灰度，观察 24 小时
回滚：异常时恢复 prompt-v17
这里最重要的不是数字本身，而是每次改动都能被复现、被解释、被撤销。
结语
Agent 用生产数据提出优化建议很有价值，但它不该拥有“自己优化、自己上线、自己宣布成功”的闭环。生产 traces 是发现问题的入口；评测、人工审查、灰度和回滚，才是把建议变成可靠变更的门。
AWS 的 AgentCore 示例提供的是一条具体实现路径；上面这套五步可用于任何带 trace、评测和版本管理的 Agent 系统。别把提示词优化当文案润色，它是一次生产变更。
来源：AWS《Optimizing agent system prompts with Amazon Bedrock AgentCore》（2026-09-16）。本文的五步闭环为基于该文生产 trace、验证与晋升思路提炼的通用工程建议，不代表 AWS 的逐字操作说明。
aws.amazon.com/blogs/machi…
