在 LLM 驱动的 Agent 开发与维护实践中，业界正面临一个公开的秘密：Agent 的自我进化存在物理天花板。
不管是使用经典的 Self-Refine（自我反思）还是 Single-turn QA（单轮问答反馈），Agent 的技能提升曲线往往在第一轮修改后就迅速饱和。即使继续注入测试用例，让大模型反复反思，其任务解决率也无法继续爬升。相反，频繁的修改还会导致技能文档出现"自我吞噬"，即前一轮刚修好的 Bug，在下一轮修改其他功能时又重新暴露。
近日，一篇名为《基于多轮交互反馈的自更新进化梯度》的论文，为打破这一瓶颈提供了工程层面的新视角。该研究指出，Agent 技能无法持续演化的根源在于反馈梯度的枯竭与文本知识库的结构性退化。通过引入多轮交互反馈与主动诊断治理，SkillEvo 成功在云服务等高复杂度业务场景中，将 Agent 任务解决率从初始的 30.0% 拉升至 81.8%。
Agent 的第二演进曲线难题
许多开发者以为，随着大模型底座能力的发展，大模型解决多轮交互任务已经轻而易举。但事实并非如此，在复杂的真实世界任务中，单靠底座大模型或简单的 Prompt 调试会迅速碰壁。
根据知名 Agent 评测基准 tau-bench 的官方数据，在模拟真实世界的航空服务多轮交互下，即使开启了最先进的 Tool Calling 接口策略，顶级大模型也表现得差强人意。GPT-4o 的 Pass^4（即连续 4 轮任务的稳定通过率）只有 20.0%，而 Claude 3.5 Sonnet 也只有 22.5%。这表明，在超过 77% 的多轮交互场景中，最顶尖的 Agent 最终都崩溃了。
这直接引出了 Agent 生命周期的 Day 2 运维难题：当 Agent 进入生产环境，面对成千上万意图未知的真实用户时，它的技能（Skills）如何能够安全、平稳且持续地进化？
传统自反思的梯度枯竭
为了让 Agent 进化，传统的直觉做法是"评估，然后让大模型自我反思并修改"。但这种自反思机制存在天然的物理局限：
- 反馈信号的单维化：单轮问答只能捕捉到用户在第一句话里暴露的问题。一旦 Agent 把这些表面问题修补好，第一轮的反馈梯度就消耗殆尽了。由于缺乏更深层次的交互测试，后续的自我迭代就失去了前行方向。
- 演化梯度的饱和：实验数据表明，单轮问答反馈在第四轮迭代时，任务解决率最终卡在 66.4% 无法动弹。而缺乏反馈闭环的纯"自我反思"，其解决率甚至在 58.8% 上下反复震荡，呈现明显的边际效应递减。
文本知识库的自我吞噬
在传统的进化框架中，治理手段往往只关注一个总体的"通过/失败"标量分数。然而，大模型以 Markdown 格式维护的技能文档在经过多轮修改后，其内部结构会出现三种灾难性的结构性退化，这是标量分数无法诊断也无法修复的：
- 知识膨胀（Knowledge Bloat）：由于缺乏对冗余规则的裁剪机制，大模型通常采取只增不减（Append-only）的妥协策略，导致文档越来越厚，最终撑爆上下文窗口或稀释模型的注意力焦点。
- 引用断裂（Reference Breakage）：在大模型修改规则的过程中，可能会删掉或者重命名某些关键节点，导致依赖这些节点的其他规则指向空值，引发系统崩溃。
- 事实过度泛化（Over-generalization）：为了修复某个特定的极端案例，大模型错误地将个性规则当成了共性规则写入，导致原本工作正常的通用场景大面积崩溃。
这种治理机制的缺失，导致 Agent 技能在反复修改中不断劣化，形成"修好一个，坏掉三个"的恶性循环。
交互轨迹：从"评估终点"到"反馈生成器"
在多轮交互自演化模式中，第一要务是重构"评估与进化"的关系。传统框架与 SkillEvo 在处理交互轨迹时存在本质分歧。
Figure 1: 传统模式与 SkillEvo 模式的梯度天花板对比。在多轮交互中，前一轮解决的缺陷能让对话向深处延伸，从而在新一轮暴露出下一层的隐蔽缺陷，产生自我更新的梯度。
以下 UML 状态对比图展示了这两者对轨迹数据的处理方式差异：
Figure 2: 传统模式与 SkillEvo 模式的 UML 活动流对比。传统模式直接抛弃轨迹，进化因失去新输入而终止；SkillEvo 将轨迹转化为反馈生成器，产生闭环演进。
从评估终点到反馈生成器
在传统的自动化评测中，模拟用户与 Agent 交互产生的轨迹仅仅被用来判定对错。一旦判定结束，整条对话记录就会被当作垃圾数据丢弃。
SkillEvo 认为，多轮交互能够产生一种"自我更新的梯度"。当第一轮修改让 Agent 具备了基础能力后，在第二轮测试中，模拟用户就能在对话中走得更远，进而激活更深层次的交互分支，暴露出隐藏在更深处的缺陷。每一轮的修改不仅消除了前期的 Bug 信号，同时也为下一轮创造了全新的错误反馈，从而实现了解决率的持续爬升。
为了实现这一目标，系统在底层构建了三个关键设计：
意图状态机（Intent State Machine）
模拟用户不能无逻辑地随机发言，否则测试的覆盖率将无从谈起。系统引入意图状态机来控制模拟用户的发言轨迹，强制引导对话覆盖高达 98.9% 的预设业务意图，确保每次测试都能戳中 Agent 的知识边界。
双向正交评估（Dual-sided Orthogonal Evaluation）
在自动化的多轮交互测试中，存在一个致命的问题：如果模拟用户的发言不够专业、或者本身存在语病，导致 Agent 答非所问，这究竟应该算作"模拟器的扭曲"还是"Agent 技能的缺失"？
如果不能将这两者剥离开，Agent 的技能就会被错误信号污染。系统通过双向正交评估，将"模拟器发言质量"与"Agent 答题表现"进行独立测量，确保只有那些被判定为 Agent 自身知识漏洞的错误，才会被保留并进入进化流程。
集体归因（Collective Attribution）
在获得大量的错误交互轨迹后，系统并不急于让大模型直接修改文档。因为单次错误的样本量太小，容易导致大模型进行前文提到的"事实过度泛化"。
集体归因模块会跨越成百上千条交互轨迹进行根因分析，将错误归纳为三类：
- 技能设计缺陷（属于可修复的知识漏洞，如未定义某 API 参数）；
- 模拟器自身故障（过滤，不进行修改）；
- 大模型底座能力受限（如推理能力不足，不属于技能文档的修复范畴）。
只有第一类"技能设计缺陷"才会被提炼成跨样本的共性知识，汇集成演化梯度写入技能文档。
可控治理：像编译器一样主动修复文档
大模型修改技能文档的本质是修改一个有向图（包括路由表、知识卡片与依赖引用）。SkillEvo 将文档视为一个结构化知识系统，并在底层实施主动治理与图诊断。
Figure 3: SkillEvo 系统架构。上层生成可信的多轮反馈来驱动文档修改；下层实施图结构诊断治理，主动修复知识膨胀与关系破裂。
双锚点事实一致性检验
每次大模型修改规则后，新规则必须同时验证两个硬性指标：
- 原始知识库锚点：新规则不能与业务的官方原始数据、原始配置产生事实性矛盾；
- 历史测试用例锚点：新规则不能导致过去已经跑通并验证通过的历史工单回归失败。
一旦一致性检验失败，系统会直接触发回滚或重新定向修改，从根本上防止了退化率的抬升。
图结构诊断与主动修复
对于软约束指标，系统从图论角度提供诊断并实施主动重构，而不是被动拒绝修改：
- 孤立文件剪枝：自动扫描文件拓扑结构，发现无主的孤立规则卡片（Orphan files）并予以清除，防止知识库冗余；
- 悬空引用自动修正：定位指向已删除规则的悬空引用（Dangling references），主动重定向到最接近的有效规则上；
- 知识膨胀控制：监控文件行数的变化率。如果发现某些节点的规则密度过大，自动启动重构算法将长规则拆分并重新构建拓扑。
这种治理手段把关注点从"标量分数"转回了"文本结构本身"。消融实验表明，去掉了这层治理防护，系统在第四轮迭代时的解决率会下跌 3.2 个百分点，且退化率（Regression Rate）与膨胀率（Bloat Rate）会呈指数级恶化。
工业级落地：腾讯云运维实践
这套自演化框架已经在腾讯云的真实生产环境中进行了实际部署，涵盖了 6 个主要的云服务类别、9 种不同的核心运维技能。
在包含 98 个技能文件的评测集上，各进化方法在四个迭代周期（R1 到 R4）内的通过率对比，展示了清晰的数据：
核心实验数据对比
- 初始状态（Init）：任务解决率仅为 30.0%。这是 Agent 尚未经过任何进化优化时的水平。
- 自我反思（Self-Reflection）：在没有外部反馈驱动的情况下，仅靠模型自我反思，解决率从第一轮的 59.2% 震荡到了第四轮的 58.8%，性能完全停滞。
- 单轮问答（Single-turn QA）：引入单轮反馈后，大模型修补了第一层漏洞，首轮拉升至 58.9%，第二轮爬升至 64.5%，随后迅速遭遇边际效应递减，第四轮卡死在 66.4%。
- SkillEvo（Full）：凭借多轮交互产生的持续演化梯度，首轮 59.4%，第二轮 71.3%，第三轮 77.9%，第四轮达到了 81.8%。
这证明了在高度严苛的云服务运维和排障场景下，以结构化文档为载体的 Agent 技能是可以实现可控、安全的自主进化的。
自动演化流水线 UML 顺序图与实践
在实际落地中，技术团队将这套机制设计为一套全自动闭环的自演进时序流水线。以下 UML 顺序图详细展示了从真实的客服工单出发，直至新技能测试通过并自动合并入生产分支的完整交互时序：
Figure 4: SkillEvo 自动化演化时序图。展示了场景生成、多轮交互、双向评估、共性归因以及最终图拓扑诊断的流转细节。
研发人员只需提供历史的用户工单，SkillEvo 就能自动生成模拟场景、跑通多轮交互、定位知识漏洞、修改文档并完成图结构校验。这一流水线降低了人工编写与维护 Prompt 的成本，也确保了 Agent 能力在频繁的版本迭代中不退化。
Agent 进化的本质是工程治理
长期以来，业界对 Agent 的优化直觉主要集中在两个极端：要么修改模型参数（如对底层 LLM 进行微调或强化学习），要么进行无休止的提示词调试（Prompt Engineering）。
SkillEvo 的成功提供了第三条演进路径：保持底层大模型参数不动，通过软件工程的手段来治理和演化 Agent 的技能知识库。
大模型的参数是通用的，而业务逻辑是不断发生变化且复杂的。试图将所有的业务逻辑通过微调强行灌入模型参数，或者塞进本就拥挤的 System Prompt 中，在工程上是不具备扩展性的。将业务逻辑抽象为结构化的有向图技能文档，并使用交互反馈来挖掘漏洞、使用拓扑校验来防范劣化，这套类似于经典软件工程的 CI/CD 体系，才是 Agent 得以走向大规模工业级落地的必由之路。
参考文献
Haverals, W. and Martin, M., “SkillEvo: Self-Renewing Evolution Gradients from Multi-Turn Interaction Feedback,” arXiv: 2608.13120, https://arxiv.org/abs/2608.13120