Agent 自迭代最大的幻觉，是把”上线”当成”毕业”。事实上，一个 Agent 不会因为跑了几个月就自动变聪明；它只会随着模型版本升级、政策悄悄变化、接口字段改动、上游数据漂移，而 silently 地越跑越歪。真正能让 Agent 持续变好的，不是让它自己改写 SOP，而是一套由执行轨迹、人工改写、评估集、版本更新和线上监控组成的、受控的数据飞轮。这篇写给所有已经被”它怎么越用越离谱”吓到过的负责人。
这篇是 Pangolinfo 企业 AI 转型系列的第八篇。前面我们聊过 AI 转型该先观察流程还是先重写 SOP（见 AI 转型 SOP 还是进入流程）、知识库为什么会失效（见 企业 AI 知识库治理）、以及权限审计与回滚（见 企业 Agent 权限管理）。那几篇解决的是”能不能安全上线”；这一篇解决的是上线之后更折磨人的问题：它怎么才能稳定地、可解释地、不翻车地变好？
上线后的 Agent，为什么可能越跑越歪？
先说一个我们反复撞见的反直觉事实：Agent 生产环境里最危险的，不是它第一天就错，而是它悄悄变差。我们把这种退化叫做”漂移”（drift），它至少有五个来源，而且每一个都不需要你改任何一行代码：
- 模型版本升级。你调用的底层模型换了一版，few-shot 行为、拒答边界、长上下文取舍全变了。上周还稳的 prompt，这周开始抽风。
- 政策与知识陈旧。亚马逊的类目规则、退款口径、广告政策，每季度都在变。Agent 脑子里的”正确”，可能已经过时三个月。
- 工具 schema 变更。下游 API 加了个必填字段、改了返回结构，Agent 没报错，但开始用错的字段做决策——这种错最隐蔽。
- 示例污染。你把历史对话塞进 few-shot 当范例，里面混了几条半年前的老答案，Agent 照着学，越学越旧。
- 上游数据漂移。它依赖的实时数据源换了口径，比如价格单位从 USD 变成本地币，Agent 一脸无辜地基于错误事实给出了”正确”的推理。
这就是为什么我们明确反对”让 Agent 自改 SOP”这种流行说法。让 Agent 自己改写自己的规则，等于让病人自己改处方——它既没有关于”上一版为什么这样写”的完整上下文，也没有能力评估一次改动会不会在另一个市场炸雷。Agent 自迭代的第一原则：任何会改变它行为的更新，都必须由人确认、有来源、可回滚，而不是由 Agent 在运行中自作主张。
Agent 自迭代的地基：一次执行该记录哪些 trace？
要谈 Agent 自迭代，先得谈可观察性。没有 trace，所谓”迭代”只是瞎猜。我们给客户落地时，要求每一次 Agent 执行至少落 8 个字段——少一个，后面那道”它为什么错”的题就解不出来：
| 字段 | 记录什么 | 不记的后果 | 用于哪种评估 |
|---|---|---|---|
| 输入上下文 | 用户原话、会话状态、触发场景 | 无法复现，归因无据 | 回归集、个案复盘 |
| 检索证据 | 它”看”了哪些文档/数据及版本号 | 分不清是事实错还是检索错 | 知识库质量、溯源 |
| 工具调用 | 调了哪个工具、传了什么参数、返回什么 | 工具层 bug 被模型背锅 | 工具 schema 回归 |
| 模型计划 | 中间推理、选了哪条分支 | 黑箱，无法判断逻辑断点 | 推理一致性 |
| 人工修改 | 人改了哪几个字、哪一步、为什么 | 最高价值的信号被丢掉 | 评估集构建、Skill 更新 |
| 最终动作 | 实际落库/外发的动作与结果 | 不知道”做了什么” | 业务结果归因 |
| 业务结果 | 退款是否争议、工单是否重开、ACOS 变化 | 无法判断”对不对” | 在线监控、ROI |
| 异常与超时 | 重试、降级、兜底、失败堆栈 | 稳定性盲区 | 可靠性看板 |
这 8 个字段里，人工修改和业务结果是最被低估的两个。前者是免费的、带着人类意图标签的训练信号；后者是把”Agent 觉得自己对”和”业务真的好”对齐的唯一锚点。我们见过太多团队只记了”调了什么工具”，结果出了事只能拍脑袋猜”是不是模型又抽了”。
Agent 自迭代的燃料：人工改写怎么变成高价值数据？
这里有个关键认知：人工改写（human correction）是 Agent 自迭代最金贵的燃料，但原始改写本身不是数据，经过策展（curation）的改写才是。直接把所有”人改过的地方”塞进评估集或知识库，你会收获一地鸡毛。我们建议四步策展：
- 标注意图：人改的是事实（检索错了）、流程（顺序错了）、表达（话术错了），还是策略（不该动这个动作）？同一处红字，含义天差地别。
- 去重与抽样：同一个 bug 被十个人改了十次，记一次就够了。我们要求评估集按失败模式聚类，而不是按工单数量堆。
- 归因到根因：是 prompt 诱导、工具返回错、还是知识过期？改错了地方，等于给错误答案打满分。
- 版本化：每条样本都带”适用模型版本 + 数据日期”，否则你拿三个月前的样本评今天的模型，只会得到噪声。
一个可落地的目标是：评估集至少 200 条、覆盖不少于 12 类失败模式。200 听起来多，但它是”每周能跑一次、且能看出趋势”的最小可用规模。低于这个数，你跑出来的”通过率 92%”毫无意义——样本太少，过拟合到几条个案而已。注意：评估集是分层抽样的人工标注集，不是”把所有线上改写自动入库”。这条纪律，决定了你的 Agent 自迭代是科学还是玄学。
离线评估、影子运行、A/B、线上监控——四层怎么叠？
很多人把”评估”简化成一次离线 benchmark，跑完就以为稳了。这远远不够。真正稳的 Agent 自迭代，是四层保险叠在一起，每一层挡不同的雷：
- 离线评估（每周回归）：固定拿那 200 条评估集，每次改 prompt/Skill 后全量跑一遍，盯通过率和各失败模式的变化。这是”发布前”的闸。
- 影子运行（Shadow，≥2 周）：新版本和老版本同时跑，新版本只记结果不落库，对比两者在实际流量上的差异。它回答”换上去会不会炸”，而不影响真实用户。
- A/B 测试（10% 小流量，≥1 周）：确认影子没炸后，放 10% 真实流量给新版本，看业务指标（争议率、重开率、转化）是否真变好，而不是”模型分”变好。
- 线上监控（持续）：全量上线后，盯人工改写率、异常率、业务结果分布。设告警阈值——比如人工改写率单周突增超过 15%，立刻回退到上一稳定版本。
这套组合的价值在于：它把”Agent 变好”从一句口号，变成了一条可观测、可拦截、可回退的流水线。我们见过最惨的事故，就是跳过了影子直接全量，结果一个 prompt 微调让退款误判率翻了三倍，而团队两天后才从客诉里发现。影子运行的两周，是这辈子最便宜的保险。
什么时候改 prompt、Skill、工具，还是知识库？
Agent 自迭代最容易犯的错，是”哪里错改哪里”——事实错了就狂调 prompt，结果把 prompt 搅成一锅粥。正确的做法是先判断失败类型，再选杠杆。我们内部用一张决策矩阵：
| 失败类型 | 优先改的杠杆 | 千万别做的 | 例子 |
|---|---|---|---|
| 事实性错误 | 知识库 / RAG 召回 | 往 prompt 里硬塞事实 | 引用了过期退款政策 |
| 流程性错误 | Skill / 工作流编排 | 指望模型”自己想对顺序” | 先发邮件后查库存 |
| 工具调用错 | 工具 schema / 权限 | 在 prompt 里反复叮嘱 | 传错市场参数 |
| 表达 / 策略错 | prompt / 系统设定 | 去动知识库 | 话术太硬、越权承诺 |
| 系统性漂移 | 评估集 + 周回归 + 回滚 | 临时打补丁 | 模型升级后全线退化 |
这张表的核心就一句：杠杆要对准失败的根因，而不是失败的现象。我们强烈建议把”更新什么”也写进版本记录——每次发版都标注”本次改了 prompt 第几段，为了修哪类失败，评估集通过率从 88% 到 91%”。没有这层记录，三个月后你根本不知道哪个改动救了命、哪个埋了雷。
为什么不能直接把错误案例喂给模型？
这是 Agent 自迭代里最反直觉、也最容易踩坑的一条。很多团队一听”用数据训练”，就把线上所有错误案例直接丢进训练集或知识库——这是给 Agent 喂毒。
原因有三。第一，错误案例本身带着噪声：那条错误可能是上游数据错了、是人手滑标错了、是那个用户本身在胡闹，你把它当 gold，模型学到的不是”正确做法”，而是”当时那次凑巧的歪打”。第二，错误案例严重不均衡——你收集到的全是出事的，正常样本很少，模型会过拟合到”怎么处理异常”而忘了”怎么正常干活”。第三，直接写进知识库的错误案例，会和正确知识打架，检索时谁先被召回全看运气。
正确的纪律是：错误案例先经过人工复核 + 分层抽样 + 根因归类，只有”来源清楚、人工确认、去重后”的样本，才进入评估集或知识/ Skill 更新。而且——这是和上一篇权限文章一脉相承的——每一次更新都要保留回滚点。Fine-tune 是重武器，绝大多数业务场景，先用 RAG / 知识库更新这种”可逆、可解释、可灰度”的杠杆，比一上来重训模型稳得多。我们也看过 arXiv 上关于 LLM 生产监控与自我改进的研究（如 2510.06674、2606.08867），结论和我们一线踩坑高度一致：没有可观察性和受控评估，”自改进”基本等于 uncontrolled drift。
一个具体例子：退款 Agent 的六周飞轮
光讲框架不够，给一个我们见过的真实节奏。某跨境客服的退款 Agent，想上线一版”更懂政策”的新 prompt。第 1–2 周影子运行：对比发现，新版本在”跨境礼品卡”场景的误拒率比老版本高 4 个百分点，但老版本在”重复退款”上漏得多——单看一边都会误判，必须并跑才能同时看见。第 3 周放 10% 流量 A/B：确认新版本整体争议率降了 1.8 个百分点、重开率降 0.6，业务指标真变好，不是”模型分”变好。第 4 周全量。
重点在第 5 周：模型供应商在一次例行升级里静默改了 refusal 边界，没人通知。监控看板显示人工改写率从 6% 跳到 19%，告警在当周触发，团队 2 小时内回退到上一稳定版，客户零感知。第 6 周，我们把那 13% 的新增人工改写逐条策展，建了 30 条新评估样本，归入”模型升级回归”这一类。下周回归跑完，全绿。这六周，没有一句”让 Agent 自己学”，全是受控飞轮在转——而它转出来的，是实打实可解释、可回退的变好。
独家观察：企业的”学习率”不由模型参数决定
做了一圈下来，我们越来越确信一件事：行业谈 Agent 自迭代，总在谈”模型会不会自己学””prompt 怎么写能让它更聪明”。但对企业来说，真正的瓶颈根本不在模型那边。
企业的”学习率”，不由模型的 learning rate 决定，而由业务能否稳定地记录和评价自己的决策决定。一个能完整记录每一次执行 trace、能持续用人工标注评估集做回归、能在漂移发生时两小时内回退的团队，哪怕用的是一年前的模型，它的 Agent 也会月月变好。反过来，一个每次出错都靠群里喊”谁又抽了”、没有任何评估集、没有任何版本记录的团队，模型再新，Agent 也只会原地打转甚至倒退。没有可观察性，所谓自迭代，只是不可解释的漂移换了个好听的名字。
对亚马逊电商 Agent 的启发
做亚马逊运营的团队，这套 Agent 自迭代框架几乎是照镜子。一个亚马逊运营 Agent 能碰的动作太多了：查 BSR、盯广告位、改竞价、读评论情感、甚至代发邮件给买家。它”变好”与否，取决于你有没有一套评估闭环——而这套闭环最缺的，往往是一个可靠的”地面真值”（ground truth）。
举个例子：Agent 建议你把某个词的竞价上调 10%，两周后 ACOS 真的降了，这算”对”吗？不一定——可能是季节因素。要判断 Agent 的竞价建议到底好不好，你得有连续、可信、跨 13 个市场的实时数据做对照，而不是让它自己抓网页猜。这正是我们建议把”实时事实层”和”决策 Agent”分开的原因：前者交给像 Amazon Data API 这样的实时数据层提供价格、排名、广告位、评论等可溯源的事实，后者——任何会改亚马逊后台的动作——必须走前面那套 trace 记录 + 人工改写策展 + 影子/A/B + 监控告警的飞轮。亚马逊政策随市场剧烈变化，正是”系统性漂移”的高发区，没有评估集和周回归，你的运营 Agent 会在你不知情时悄悄把预算烧穿。
另外，Agent 对评论情感的判定准不准、对”差评是否涉及合规”的判断对不对，这些都需要人工标注的评估集来持续校准。如果想把 Amazon 实时数据直接喂给 Agent 工作流，可以看 Amazon Data MCP 技术文档——它把数据层和 Agent 层之间的接口标准化了，至少让”Agent 基于哪版数据做决定”是可追溯的。
结论：Agent 自迭代治的是”可观察与可评价”，不是”让模型更努力”
回到开头那句话——别再相信”上线后它会自己变聪明”。Agent 不会因为跑得久就毕业；它只会因为你有了一套能记录 trace、策展人工改写、用评估集做回归、用影子/A/B 拦风险、用监控抓漂移的受控飞轮，才真的、稳定地、可解释地变好。把”自改 SOP”的浪漫收起来，把注意力放在动作层的可观察性上：每一次执行都留痕，每一条改写都标注意图，每一次发版都对准根因、留好回滚点。当你的业务能稳定地评价自己的决策，Agent 的学习率，才会真正掌握在你手里。
常见问题
Agent 上线后为什么反而越用越差？
不是它”变笨”，是漂移：模型升级、政策过期、工具字段变更、示例污染、数据口径变化，任何一个都会让它 silently 退化。靠运行时长不会变好，靠评估闭环才会。
一次执行最少要记哪些字段？
八项：输入上下文、检索证据、工具调用、模型计划、人工修改、最终动作、业务结果、异常超时。其中人工修改和业务结果最被低估，却是对齐”自认对”与”真的好”的关键。
人工改写能直接当训练数据吗？
不能直接用。原始改写是噪音，须经标注意图、去重抽样、根因归因、版本化四步策展，且评估集应分层抽样而非全量入库，否则会喂毒、过拟合到个案。
影子模式和 A/B 测试有什么区别？
影子只记结果不落库，对比新老版本差异但不影响真实用户，是”发布前”的闸；A/B 放 10% 真实流量看业务指标，是”小步验证”。两者都过不了才全量。
小团队没平台工程，怎么低成本做评估？
先别上重武器。从 200 条分层抽样评估集 + 每周一次手跑回归 + 人工改写率看板起步，工具调用和结果记 CSV 即可。等规模上来再上影子与 A/B，先有纪律再要平台。
延伸阅读：Amazon Data MCP 技术文档。本文为 Pangolinfo 企业 AI 转型系列子篇，支柱文章见 亚马逊企业 AI 转型，前篇见 AI 转型 SOP 还是进入流程、企业 AI 知识库治理 与 企业 Agent 权限管理。
