Agent 持续进化：从运行轨迹到可发布能力
Agent 持续进化不是让生产系统“边跑边改自己”，而是把运行轨迹转化为有来源的候选修改，再经过独立验证、灰度和回滚，晋升为新的稳定能力。面试中要同时讲清学习信号、更新载体、发布门禁和不可自改的可信根。
一、先划边界：记住不等于学会
很多系统把聊天记录写进向量库，就宣称 Agent 会“持续学习”。这最多解决了信息留存，不代表能力真的改善。
| 对象 | 解决的问题 | 典型载体 | 生效范围 | 关键风险 |
|---|---|---|---|---|
| 会话上下文 | 当前任务下一步做什么 | messages、临时 state | 单次会话/任务 | 上下文膨胀、旧指令干扰 |
| 用户记忆 | 下次是否记得用户偏好与事实 | 记忆条目、情景摘要 | 用户/项目/租户 | 错误记忆、隐私和越权 |
| 经验资产 | 相似任务能否复用成功方法 | 知识、Prompt、Skill、代码 | 一类任务或一个 Agent 版本 | 规则冲突、错误经验固化 |
| 模型参数 | 是否获得跨任务的隐式行为能力 | SFT/RL/Adapter 权重 | 模型服务范围 | 遗忘、分布漂移、回滚昂贵 |
判断“系统是否在进化”，至少要看四件事：
- 更新：规则变化后能替换旧知识，而不是继续追加冲突条目。
- 迁移：经验能帮助没见过的新任务，而不是只记住原题答案。
- 保持：新能力上线后，旧任务和安全边界没有明显退化。
- 治理：每次变化都有证据、版本、验证结果和回滚路径。
三个容易混用的词也要分开：反馈回流只是让结果、纠正和投诉进入证据管道；在线学习描述能力在服务期间更新的时机，并不天然代表安全；持续进化则是从证据到候选隔离、验证、发布、回滚和淘汰的完整能力生命周期。线上反馈不得绕过这条生命周期，直接改写正式 Memory、Prompt、Skill、Harness 或模型参数。
因此，用户说“以后报告都先给结论”可以成为一条受控记忆；十次工单都因同一种工具参数错误而失败，才可能形成一个待验证的 Skill 或代码修改。两者不能混为一谈。
二、学习信号：从轨迹中提取什么
Agent 的轨迹包含输入、上下文版本、模型决策、工具调用、外部状态、人工修改和最终结果。持续进化不能只读最终回复，更不能把模型的“我完成了”当成成功证据。
| 证据层 | 回答的问题 | 高可信信号 | 不能单独作为真相的信号 |
|---|---|---|---|
| 结果证据 | 任务真的完成了吗 | 数据库状态、测试结果、业务回执；用户对主观质量的明确确认 | 模型自述、文风评分 |
| 过程证据 | 为什么成功或失败 | 工具参数、错误码、审批记录、重试与人工修改 | 隐藏推理文本、无来源总结 |
| 质量证据 | 这种做法值得推广吗 | 成本、延迟、安全事件、返工率、可维护性评审 | 单次点赞、代理指标短期上涨 |
推荐的证据处理管道：
原始轨迹 -> 脱敏与来源标记 -> 确定性结果校验 -> 聚类重复问题
-> 根因假设 -> 候选修改 -> 独立验证网页、邮件、RAG 文档和工具输出可能包含 Prompt Injection，只能作为“不可信事实材料”；模型反思可以提出假设，但不能批准自己的修改。只有外部状态、独立测试或经过授权的人类反馈，才能把候选经验推进到下一阶段。
还要保留失败和阴性结果。若日志只保存成功轨迹，离线学习会产生幸存者偏差：它可能反复采用一个“偶尔成功、经常超时”的策略，却看不到被丢弃的大量失败样本。
三、更新载体：知识、指令、程序还是参数
同一个 bad case 可以写到不同位置，但治理成本完全不同。默认原则是：选择影响面最小、最容易归因、验证和回滚的载体。
| 更新载体 | 适合内容 | 示例 | 验证方式 | 何时不要用 |
|---|---|---|---|---|
| 知识 | 可引用事实、案例、外部规则 | 新退款政策、已知故障解法 | 检索命中、引用准确、时效检查 | 事实需要确定性执行时 |
| Prompt / Skill | 可用语言描述、需判断何时使用的策略 | “退款前先核对订单主体” | 激活率、遵循率、边界用例 | 规则必须百分百强制时 |
| 程序 / Harness | 稳定流程、校验、权限和恢复逻辑 | 金额上限、幂等键、熔断器 | 单测、集成测试、沙箱回放 | 任务仍高度开放且规则不稳定时 |
| 模型参数 | 隐式、跨任务、规模化行为 | 工具选择、复杂规划习惯 | 留出集、对抗集、遗忘评估 | 样本少、规则常变、需即时撤回时 |
一个实用的选型顺序
是外部事实吗？ -> 知识，并保留来源与有效期
能写成局部自然语言策略吗？ -> Prompt/Skill，按场景加载
必须确定性执行吗？ -> 程序/Harness，模型无权绕过
是大量任务共有的隐式能力？ -> 数据充分后再考虑参数更新例如客服 Agent 多次超过退款上限：若只是政策变了，更新知识；若模型常忘记核对主体，新增局部 Skill；若退款金额绝不能越界，把校验写进 Tool Gateway；只有在大量不同业务中都表现出工具选择能力不足时，才考虑后训练。
不要每出现一个 bad case 就给全局 Prompt 加一条“军规”。规则会互相遮蔽、占用上下文，并破坏跨请求的稳定前缀，降低 Prefix/Prompt Cache 复用；是否影响单次推理中的 KV Cache，则取决于服务实现。规则堆叠到最后，往往没人说得清哪条规则产生了效果。
四、核心架构：在线执行与离线进化双循环
生产系统最重要的隔离是：在线循环完成任务，离线循环修改候选能力。 正式版本不在服务真实用户时直接改写自己。
┌──────── 在线稳定执行 ────────┐
用户请求 -> Agent Gateway -> Stable Agent -> Tool/业务系统 -> 结果
│ | | │
└───────+---------------+────────┘
v
防篡改证据索引、回执、人工纠正、版本信息
（业务内容按保留与删除策略治理）
|
v
┌──────────────────────── 离线进化控制面 ────────────────────────┐
│ 聚合与脱敏 -> 根因诊断 -> 生成候选 -> 回归/安全/留出集验证 │
│ | │
│ 拒绝 <-----+-----> Canary -> 晋升/回滚 │
└──────────────────────────────────────+─────────────────────────┘
|
Versioned Capability Registry
知识 / Prompt / Skill / Harness / 参数两条循环通过三个版本化资产连接：
- Evidence Store：保存脱敏轨迹、外部回执、人工纠正和来源引用。
- Capability Registry：保存正式与候选知识、Skill、代码和模型版本。
- Evaluation Registry：保存训练集之外的回归集、安全集、留出集和门槛版本。
在线 Agent 只读取 active 能力。离线控制面可以生成候选，但不能直接更改生产别名；发布服务依据独立评测结果和审批策略执行晋升。
五、候选能力的数据模型与生命周期
一条候选修改不应只是“把 Prompt 改成这样”，而应包含基线、证据、风险和验证结果：
{
"candidate_id": "cand_01K...",
"artifact_type": "skill",
"base_version": "refund-agent@42",
"evidence_refs": ["trace_188", "ticket_921"],
"change": { "skill": "verify_refund_subject", "revision": 3 },
"risk_level": "high",
"evaluation": {
"held_out_gain": 0.06,
"regression_rate": 0.0,
"safety_gate": "passed"
},
"status": "validated",
"rollback_to": "refund-agent@42"
}候选生命周期：
proposed -> validated -> canary -> active
| | | |
rejected rejected rolled_back deprecatedproposed：只有根因假设和候选 diff，不服务真实流量。validated：通过离线回归、安全和留出验证，仍未证明线上有效。canary：只进入受控租户或小比例流量，监测收益与副作用。active：成为稳定版本，但继续保留基线、证据和回滚目标。deprecated：被新规则替代或长期未使用；先停止激活，再按保留策略归档。
版本必须覆盖模型、系统 Prompt、Skill 集、工具 schema、策略、知识快照和评测门槛。只记录“模型版本变了”无法重放一次真实进化。
六、验证体系：既评更新器，也评任务 Agent
持续进化包含两个不同能力：
- 更新能力：离线更新器能否提出真正有价值的候选修改。
- 受益能力：任务 Agent 能否在正确场景激活并遵循新能力。
一个 Skill 写得正确但从未被路由命中，端到端结果仍不会变好；一个候选被频繁激活但本身错误，则会扩大事故。两者必须拆开评估。
| 指标 | 计算口径 | 主要诊断对象 |
|---|---|---|
| 候选修改有效率 | 独立验证通过候选 / 全部候选 | 更新器与根因诊断 |
| 产物激活率 | 应激活样本中实际加载候选的比例 | 检索、路由与上下文组装 |
| 规则遵循率 | 激活后动作满足新约束的比例 | 模型执行与 Tool Gateway |
| 留出任务增益 | 未参与候选生成的任务提升 | 泛化而非记题 |
| 旧能力回归率 | 原通过样本变失败的比例 | 冲突、遗忘与规则覆盖 |
| 安全退化率 | 越权、泄露、注入绕过的变化 | 安全门禁与策略 |
| 成本/延迟变化 | token、工具次数、P95 延迟差值 | 收益是否值得代价 |
| 在线业务收益 | 任务解决率、投诉率、人工接管率相对稳定版的变化 | Canary 是否产生真实价值 |
| 回滚率 | Canary/Active 后回滚版本比例 | 离线门禁有效性 |
评测集至少分四层：候选直接相关集、历史回归集、未见过的留出集和安全对抗集。生成候选使用的轨迹不能同时充当最终验收集，否则更新器很容易对已知 bad case 过拟合。
高风险修改的晋升门槛可以写成程序化策略：关键业务状态零回归、安全对抗不退化、收益达到最小阈值、成本不超过预算，并由独立 reviewer 或责任人批准。
七、安全边界：可信根不能参与自我修改
持续进化的危险不是一次回答错，而是把错误升级成长期规则。普通进化流程必须被限制在明确的写入集合内。
可生成候选但不能自行发布的对象：
- 领域知识、Prompt、Skill 和工作流局部配置。
- Harness 代码、工具描述、检索与路由策略。
- 训练数据候选与模型 Adapter。
不可由普通进化流程修改的可信根：
- 权限策略、审批规则和高风险动作边界。
- 评测器、测试用例、发布阈值和样本隔离规则。
- 防篡改的审计元数据、数据来源记录和版本签名；业务内容仍受保留与删除策略治理。
- 稳定版本备份、回滚通道和紧急停止开关。
如果一个 Agent 可以修改批准自己的评分器，它只需降低门槛就能“证明进步”；如果它能删除失败轨迹，就能制造虚假的成功率。评价器、证据和发布权必须与候选生成器隔离。
八、失败模式与修复策略
| 失败模式 | 典型表现 | 根因 | 修复 |
|---|---|---|---|
| 提示注入被固化 | 网页里的恶意指令变成长期 Skill | 不可信内容直接进入写入链路 | 来源分级、候选隔离、人工/安全审查 |
| 奖励投机 | 指标上涨但用户问题没解决 | 优化了代理指标 | 引入外部业务结果与多指标门禁 |
| 幸存者偏差 | 反复推广偶尔成功的高成本路径 | 失败轨迹被丢弃 | 保存阴性结果、停止原因和分母 |
| 自评自批 | 生成器总能通过自己的 Judge | 职责未隔离 | 独立 evaluator、确定性验证与抽检 |
| Prompt/Skill 膨胀 | 规则冲突、激活不稳定、成本上涨 | 只追加不整理 | 局部 diff、去重、作用域和过期策略 |
| 评测器污染 | 留出集越来越高，线上无提升 | 训练证据泄漏进验收集 | 数据血缘、冻结留出集、定期换题 |
| 灾难性遗忘 | 新场景提升，旧任务大幅退化 | 参数或规则覆盖过宽 | 分层回归、Adapter 隔离、快速回滚 |
| 版本不可复现 | 无法解释哪个变化导致退化 | 只保存最终文本 | 全栈版本、证据引用和原子发布 |
开放式研究、战略和复杂设计还存在“完成不等于进步”的问题。流程跑完、文档生成、单元测试通过，只说明可测代理目标达成；问题价值、长期维护和真实业务收益仍需要更慢的人类判断与延迟指标。
九、离线整理：合并、遗忘与能力保鲜
能力库不能只增不减。可以按时间、轨迹数量、错误率或容量触发一次离线整理周期：
- 定向：加载正式能力清单、所有权、不可修改边界和当前版本。
- 采集：只读取已脱敏、已评价且有来源的近期轨迹。
- 整合：聚类重复经验，识别冲突，优先生成局部候选 diff。
- 验证：在回归、留出和安全集上评测，高风险候选等待审批。
- 修剪：标记过期知识、重复 Skill 和长期未使用工具，重建索引并保留回滚版本。
这类过程有时被称为“睡眠学习”，但它只是在线采集与离线整合的类比，不代表 Agent 可以无监督地自我升级。低使用率也不能直接等同于无价值：应结合业务关键度、替代能力、最近验证时间和所有者确认决定归档。
十、系统设计题：企业客服 Agent 持续改进平台
需求与边界
客服 Agent 处理退款、物流和账户问题。平台希望从线上失败、客服改写和用户投诉中持续改进，但必须满足：单次用户输入不能直接修改生产策略；退款等写操作始终受确定性政策约束；每次更新可解释、可灰度、可回滚。
参考架构
Channel -> Agent Gateway -> Version Resolver -> Stable Agent Runtime
|-> Context/Skill Registry (read only)
|-> Policy-aware Tool Gateway
|-> Trace + Business Receipt Outbox
Evidence Pipeline -> Redaction -> Outcome Verifier -> Failure Cluster
-> Candidate Factory
-> Eval & Safety Lab
-> Approval/Release Controller
-> Version Registry关键数据流
- Gateway 固定本次运行的 Agent 全栈版本，任务中途不漂移。
- Tool Gateway 返回结构化回执；客服改写保存为带主体和原因的反馈事件。
- Evidence Pipeline 脱敏并关联
trace_id、业务结果和版本，不把自由文本直接当规则。 - Failure Cluster 只对重复、可归因问题触发候选生成；孤立故障继续积累证据。
- Candidate Factory 先决定改知识、Skill、Harness 还是参数，再生成最小 diff。
- Eval Lab 使用隔离的回归、留出和安全集；发布控制器只接收签名结果。
- 高风险候选经人工批准后进入指定租户 Canary；监控退化则自动切回
rollback_to。
上线门禁
| 门禁 | 示例要求 |
|---|---|
| 正确性 | 退款与身份核验关键样本零回归 |
| 泛化 | 留出任务有稳定增益，而非只修复原始工单 |
| 安全 | 注入、越权、敏感数据对抗集不退化 |
| 成本 | P95 token、延迟和工具次数在预算内 |
| 运维 | 可观测、可停止、可回滚且责任人明确 |
事故处置
若 Canary 投诉率升高，先冻结新晋升和候选生成，流量切回稳定版本；再按版本、租户、证据来源定位影响范围，撤销受污染的 Skill/知识索引，保留审计记录。修复后用事故样本扩充回归集，但仍要保留独立留出集，避免只会修这一道题。
十一、项目讲法
项目讲法模板
我们没有让线上 Agent 直接改 Prompt，而是建设了在线执行和离线进化双循环。在线只运行固定的稳定版本，记录工具回执、人工纠正和成本等可审计证据；离线按重复根因生成知识、Skill、Harness 或参数候选。候选先跑历史回归、独立留出和安全对抗集，再经审批进入租户级 Canary。评测既看候选本身是否有效，也看任务 Agent 能否正确激活和遵循。权限策略、评测门槛、审计日志与回滚备份属于可信根，进化流程无权修改。这样改进可以持续发生，但每次变化仍可解释、可验证、可回滚。
十二、与已有专题的分工
- Agent 记忆系统：记忆分类、写入、检索、更新和遗忘。
- 上下文工程：运行时信息的写入、选择、压缩与隔离。
- Agent 评估与可靠性工程：结果与轨迹评测、变更回归和上线门禁；本页负责候选如何从证据产生并贯穿能力生命周期。
- 耐久化 Agent 工作流：长任务检查点、恢复、重试与补偿。
- Agent Skills 生产治理：Skill 的发现、安装、版本和企业治理。
- Agent 可复现运行与配置溯源：全栈版本、证据链和重放。
- LLM 在线评估与灰度实验：线上实验、Canary 与发布门禁。
- LLM 数据标注与偏好数据运营：反馈进入数据、评测和训练资产的治理。
本页只负责把这些能力串成“证据 -> 候选 -> 验证 -> 发布 -> 整理”的持续进化生命周期。
十三、参考资料
- 李博杰：《深入理解 AI Agent：设计原理与工程实践》v1.3，第 8 章“Agent 的持续进化”，2026。
- Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023。
- Zhang et al., AFlow: Automating Agentic Workflow Generation, 2024。
- Zhang et al., Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models, 2025。
- Lee et al., Meta-Harness: End-to-End Optimization of Model Harnesses, 2026。
- Lin et al., Harness Updating Is Not Harness Benefit: Disentangling Evolution Capabilities in Self-Evolving LLM Agents, 2026。
高频追问
Q：持续进化和 Agent Memory 有什么区别？
Memory 保存可再次读取的信息；持续进化还要从多次证据中诊断根因、选择更新载体，并经过验证和发布。记住用户喜欢表格是记忆；把反复成功的分析步骤晋升为 Skill，才是能力更新。
Q：为什么不让 Agent 每次失败后自动改 Prompt？
单次失败可能是外部故障、偶发采样或恶意输入。立即改 Prompt 会过拟合并固化注入，还可能破坏旧能力。应先积累可信证据，生成候选 diff，再走独立回归和灰度。
Q：如何选择 Skill、代码还是微调？
需要模型按场景判断的语言策略放 Skill；必须强制且可程序化验证的规则放代码/Harness；跨任务、隐式且有大量高质量数据支撑的能力才考虑微调。默认选最小、最好回滚的载体。
Q：如何证明 Agent 真的学会了，而不是记住评测题？
隔离候选证据与留出集，改变用户、表述和局部环境测试迁移；同时测试旧能力保持、规则变化后的替换和安全边界。只在原始 bad case 上提升不算学会。
Q：为什么要拆“候选有效率”和“产物激活率”？
前者衡量更新器有没有提出好修改，后者衡量运行时能否在正确场景加载它。混成总分后，检索失败、模型不遵循和候选本身错误会无法区分。
Q：哪些东西绝不能让 Agent 自己改？
批准它的评测器、发布门槛、权限策略、审计证据、稳定备份和紧急停止开关。否则系统可以通过删失败样本或降门槛伪造进步。
Q：何时应该停止继续进化？
证据不足、留出收益不稳定、旧能力或安全退化、成本超过收益，或者评价目标本身无法可靠测量时，应停止自动晋升并转人工决策。
Q：能力库越来越大怎么办？
为知识和 Skill 设置作用域、所有者、来源、最后验证时间和过期状态；离线合并重复项、处理冲突、归档长期未用能力，并定期验证路由与工具仍然有效。