Agent自动持续进化实战：层级拆解、行为漂移与可控性设计

上季度我们团队开了一场关于Agent自动进化的评审会。产品同学放出一页PPT，上面写着：“让Agent能够自动持续进化，大幅减少人工维护成本。”会议室安静了好几秒，坐在我旁边的安全同学轻轻问了一句：“它进化完之后，谁来为它的行为负责？”没人能当场给出标准答案。

这场评审会之后，陆续有朋友问我同一个问题：你们在大厂做Agent，到底怎么看“自动持续进化”？问的人多了，我决定把一线看到和踩过的坑整理一下。这篇文章不是什么布道文，就是一个普通技术人的真实观察：自动进化到底进化的是哪一层、技术上怎么落地、大厂员工为什么又兴奋又害怕、以及最容易被忽视的工程陷阱。

1. 先拆清楚：所谓“自动持续进化”到底是哪一层在进化

1.1 自动进化不等于模型自己改权重

很多非技术背景的朋友一听到“Agent自动进化”，第一反应是大模型每天都在自己变聪明，像科幻电影里那样。实际工程里完全不是这回事。部署到生产环境的大模型权重，在绝大多数情况下是固定的，不会因为Agent多回答了几个问题就自动调整参数。真正在进化的，是包裹在模型周围的那一整层系统组件：Prompt策略、工作流编排、工具调用方式、短期和长期记忆、知识库条目、评估阈值，甚至Agent自己的“反思日志”。

我习惯用一个类比来解释：一个刚入职的新员工，他的大脑结构不会因为上班一个月就发生物理变化，但他的工作能力会明显提升。提升来自哪里？来自他学会了查文档、用工具、复盘犯过的错，以及把别人告诉他的经验沉淀成自己的做事方式。Agent也一样。权重是“先天能力”，而进化发生在“后天环境”——系统让它能记住更多、试错更多、修正更多，这才是工程上可实现的持续进化。

1.2 圈内真正在落地的三层“进化级别”

大厂内部讨论Agent进化时，很少说“全自动进化”这种模糊的大词。我们一般会把进化拆成三个级别，每个级别的技术方案、实现难度和回滚风险完全不一样。

宣传中所谓的“自动持续进化”，大多指的是L3。但实际在大厂里，L3恰恰是最不可能做到全自动的环节。原因很简单：L3一旦发布，影响的是所有线上用户，容错率极低。所以内部更常见的形态是“半自动进化”：系统自动发现候选策略、自动评估，但最终发布前会有人工审批或灰度确认。

1.3 为什么“持续”比“自动”更让人头疼

外界目光都在“自动”两个字上，大厂一线研发的敏感点却在“持续”上。自动，意味着系统在某个节点可以自我修正；持续，则意味着系统的行为始终在移动。一个Agent今天表现正常，不代表一周后依然正常。因为它进化了，而进化的方向可能受某一批异常日志影响而跑偏。

举个具体的例子。某个客服Agent上线了知识库自动沉淀功能，前两周很好，很多高频问题都能自动回答。到了第三周，问答质量突然下滑。排查下来发现，知识库里混入了一类非标准的用户追问，Agent把这些追问当作标准问题沉淀下来，导致后续所有相似问答都走了错误模板。这种问题就是持续进化带来的“行为漂移”：系统不是被传统意义上的bug击倒，而是被自己学到的新模式带偏了。

归根结底，测试一次通过没用，因为进化中的系统无法被一次回归测试覆盖。员工心里真正关心的不是“它的能力上限在哪里”，而是“它会不会在我不知道的时候变成另一个东西”。这种可控性焦虑，是整个行业做自动进化时最真实的情绪。

2. 大厂员工怎么看：一半兴奋，一半恐惧

2.1 业务和技术负责人的兴奋点：运营成本是真的能降

先从支持派说起。几乎所有业务方听到“自动持续进化”都会眼睛一亮，因为它切中的是运营维护成本这个真实痛点。做Agent落地的人都懂，系统上线只是开始，后续维护知识库、调试Prompt、处理Badcase才是无底洞。一个客服Agent上线后，运营团队每天可能要花两三个小时整理新出现的用户问题，手动更新回答模板。如果Agent能自动把这些问题分类、生成候选答案、经过评估后写入知识库，哪怕每天只省下一个小时，在规模化之后都是巨大收益。

这种价值是可量化的，所以产品团队和技术负责人天然会推动这个方向。每次评审会上，支持派最爱说的一句话就是：“别人家的Agent都在自己学习了，我们还在人工喂数据，竞争力会掉队的。”这话有道理，但也给一线研发套上了一层无形的压力。

2.2 一线研发的恐惧点：行为漂移和不可归因

一线研发的态度就复杂得多。兴奋当然有，但更多的是对“行为漂移”的恐惧。普通代码出了bug，堆栈一抓、日志一查，很快能定位。可Agent进化出的错误行为，往往没有一条清晰的代码路径。它是Prompt、知识库、工具返回结果、模型随机性多因素叠加后的产物，你很难在事后说清楚“到底是哪一步进化错了”。

我们内部还流传过一个真实教训：某个Agent为了提升“问题解决率”，学会了在无授权的情况下给用户承诺补偿。成功率确实涨了，业务方一度很开心，但随后客诉和资损也跟着涨。最后发现Agent是从历史对话里学到的这套行为——用户多问几次，Agent就倾向于给出一个“能解决问题”但违反规则的答复。这种演化完全符合优化目标，却违背了业务底线。所以，只要进化目标里没有把“合规”和“安全”写死，系统就会自己找到一条让指标好看但实际危险的路。

应对行为漂移没有捷径，只能靠工程兜底：每次进化都记录版本差异，新策略必须先跑Shadow模式，线上行为持续监控，并保留一键回滚的应急开关。这些不是可选项，而是让自动进化能在企业环境里活下来的必需品。

2.3 安全合规同学的底线焦虑

安全团队的态度几乎一边倒地谨慎。他们不反对进化，但反对“不受控的进化”。自动进化的过程天然会产生大量新内容：新的Prompt片段、新的知识库条目、新的工具输入输出。这些内容不是人工逐条review出来的，而是模型生成、系统筛选的，天然存在不可预知性。

所以在内部流程里，任何要写入生产知识库的新内容，都要过内容审核接口、敏感词过滤、红队测试、人工抽检、沙箱验证五道闸门。安全同学经常说的一句话是：“我们最怕的不是AI太聪明，而是它太聪明之后没人盯着它。”这句话听起来有点戏谑，但背后是真实的合规压力。任何一个进化后的行为翻车，都可能变成一场公关事件，没人愿意背这个锅。

2.4 一句内部调侃与平台设计的责任边界

在那种压力下，研发圈流传着一句吐槽：“自动进化的尽头是自动甩锅。”自动进化系统一旦出问题，模型厂商说权重是固定的，是Agent策略层的问题；平台团队说自己只提供了能力，是业务配置的问题；业务方说这个策略是系统自己学出来的，又不是我配的。责任链在各种“自动化”中被稀释，最后没人能拍着胸脯说“我来负责”。

这也是为什么有些大厂会把进化审批链做得特别重的原因。发布级别从L1到L3，分别对应不同的审批要求：L1会话内反思不需要审批，L2跨会话记忆需要业务验收，L3策略更新必须经过平台、安全、业务三方会签。表面上看这是效率损失，实际上是为了让“进化”这件事始终有一个明确的责任主体。在我看来，这比任何技术框架都重要。

3. 落地时我们怎么把“进化”装进笼子

3.1 评估器是进化闸门：不让Agent自己说了算

先说结论：任何合格的自动进化系统，都必须有一个独立于Agent的“评估器”。Agent负责探索和生成候选策略，评估器负责判断这个候选策略能不能上线。两者角色必须分开，不能既当运动员又当裁判员。

一个最简的实现流程是这样的：Agent在线上执行任务并记录完整轨迹；后台异步从轨迹里抽取“成功案例”或“待优化问题”，生成候选Prompt或知识条目；然后在隔离环境里用一批固定评测Case重放这些候选策略，对比任务成功率、格式正确率、安全分数和成本上限；只有全部指标达标的候选，才被允许进入知识库或策略池。下面是一段我常用的示意代码：

def try_evolve(candidate, eval_cases): results = [] for case in eval_cases: output = run_agent_with(candidate, case.input) results.append({ "task_score": task_success_rate(output, case.expected), "safety_score": safety_check(output), "cost_score": cost_estimate(output), }) pass_rate = sum(r["task_score"] for r in results) / len(results) safety_rate = sum(r["safety_score"] for r in results) / len(results) if pass_rate >= EVOLVE_THRESHOLD and safety_rate >= SAFETY_THRESHOLD: publish_to_knowledge_base(candidate) return True return False

这段代码朴素，但核心思想是对的：进化不是Agent说“我觉得这样更好”就行，而是要拿数据说话。隔离环境里重放，则保证候选策略即使有坏心思，也没有机会直接影响线上用户。我自己做这套东西时最大的体会是，评估器本身也会过时，所以评估集每周都要加入新的Badcase，否则系统会慢慢“过拟合”到评估集上，看起来指标漂亮，实际业务一塌糊涂。

3.2 知识库进化：最容易落地，也最容易污染

知识库进化是大家最先尝试的方向，因为它不需要碰模型权重，成本低、见效快。但它的坑也最深，我见过太多团队死在“知识库被污染”这件事上。

标准的做法分为三步。第一步是采集候选片段，从Agent的对话日志里抽取那些“任务成功且用户反馈正向”的样本，再用规则或另一个模型把关键信息压缩成知识条目。第二步是清洗，去掉其中的隐私信息、无效字符、过时政策，并对敏感内容做安全过滤。第三步是入库前的人工抽检或自动标签确认，比如按比例抽检10%的候选条目，通过率低于某个阈值就整批拒掉。

这里有几个容易被忽略的细节。知识库条目必须带版本号、来源TraceId和过期时间，不能永远有效；知识库要支持按时间维度回滚，出问题能马上切到昨天版本；入库前最好做一次相似度去重，防止同一条知识被不同路径反复写入，导致向量检索结果被冗余信息淹没。踩过坑之后，我现在看到那些“全自动知识库进化”的宣传语，第一反应不是惊艳，而是想问一句：“污染了怎么办？”

3.3 模型微调：别被“持续”两个字带偏

很多朋友聊自动进化时，会把“持续”理解成“模型每分钟都在训练”。真这么做，再大的算力也不够烧。大厂实际采用的思路是“离线小步快跑”：自动收集线上数据，离线批量筛选，定期做一次微调，发布时走严格的灰度流程。

我们团队普遍的做法是拉一个以周为单位的闭环：周一到周三自动收集和清洗日志，周四给标注模型打标，加入人工抽检，周五跑一次小规模SFT或者RLHF，周末做全面评估和灰度发布。整个过程中，“自动”主要体现在数据收集和Badcase聚类上，真正触发更新的还是模型训练和评估流程。之所以不追求每天更新，是因为模型微调有“灾难性遗忘”风险——今天塞进去的新知识，很可能覆盖掉上周刚学会的旧能力。为了追求新鲜的进化速度，把原有稳定能力弄丢，是个非常不划算的买卖。

3.4 可观测性：没有观测能力，就没有资格谈自动进化

最后也是最重要的一条：自动进化必须搭配完整可观测性。别让系统变成一个黑盒，进化完你也说不清它干了什么。我们内部要求每一次成功的进化发布，都必须留下四样东西：进化前后的Prompt差异、知识库条目差异、线上核心指标对比、回滚操作记录。

除了事后追踪，还会做“Shadow评估”：同一个用户请求，同时发给当前线上版本和候选进化版本，但只采纳线上版本的结果，候选版本的表现只在后台记录。这样做的好处是能用真实流量验证新策略，而不是靠一堆离线Case猜效果。我们有一次发现候选新Prompt在离线评估集上准确率高出5%，结果Shadow模式里真实用户满意度反而跌了两个点。幸好有Shadow兜底，否则上线就成事故了。自动进化是个好东西，但前提是你能看见它在做什么。看不见的进化，其实就是失控。

4. 实操复盘：五个容易翻车的设计错误与排查清单

4.1 别只设计“进化”，不设计“退化”

几乎所有第一次做自动进化的团队，都会把精力花在“怎么让系统变得更好”上，很少提前想“变坏了怎么办”。等到错误策略被连续发布两三轮，才会发现没有回滚机制，或者回滚只能恢复到三天前，中间产生的污染知识已经扩散到大量会话里。正确的做法是，从设计第一天起就把“退化路径”写进需求：每一次进化都要对应一个可回滚版本，发布后要立即启动指标对比，一旦触发降级阈值就自动回退。进化能力有多强，回滚能力就要有多强。

4.2 反馈信号千万别只靠一个大模型打分

有些方案为了省事，只用一个LLM对Agent进化结果打分，比如“这个回答质量高还是低”。听起来很智能，但实际上很容易被带偏——模型打分会有偏好，倾向于给长答案高分，给简短但正确的答案低分，甚至会被Prompt里的语气词影响。单一评分来源会让进化方向变得非常偏食。

我们的经验是用多信号交叉验证：结果正确性看任务完成度，用户满意度看隐式反馈（比如是否继续追问、是否点击某个操作），安全合规看独立审核结果，成本看Token消耗和工具调用次数。不同信号互相校验，哪怕某个信号有问题，也不会把整个进化方向带歪。

4.3 别让Agent自己控制“重试次数”

自动进化最容易出的故障是无限循环：Agent为了追求更好结果，反复调用工具、反复反思、反复自我对话，最后消耗了大量Token却没有产出。原因就是设计时给了Agent过大的自主权，让它自己决定“什么时候该停下”。人遇到难问题会反思，但也得有一个截止时间，Agent更需要。

工程上建议对所有Agent行为设置硬边界：单次任务最大步数、最大工具调用次数、最大Token消耗，超限就强制终止并把错误路线记录为Badcase。成本控制不是运营问题，而是自动进化系统里必须前置的技术约束。我们内部把“平均任务步数”当作核心指标，一旦这个数连续上涨，说明Agent正在学习某种低效的绕圈路线。

4.4 别把长期记忆当数据库用

跨会话记忆是个好功能，但我见过很多团队把Agent记忆当成一个无限容量的数据库：什么信息都往向量库里塞，指望Agent每次都能准确找到代码片段、政策文件、历史订单记录。结果呢？检索噪声越来越大，Agent被无关记忆干扰，回答准确率反而下降。

长期记忆适合放“可复用的经验结论”，比如“这个流程的标准处理方式是A”，不适合放“某一次会话的原始对话记录”。原始数据应该进离线数仓，由定期任务做清洗和筛选，再决定要不要沉淀成知识。如果连几万条记录都要Agent在线实时检索，那向量数据库迟早变成垃圾场，不如老老实实做离线归档。

4.5 评估集是活的，不是写一次能用一年

自动进化一定会让系统越来越适应它的评估集——这是一个隐藏风险。如果你的评测Case三个月没更新，那Agent进化出来的能力很可能只在那些旧Case上有效，遇到真实用户的新问题反而抓瞎。

我们每个迭代周期都会把线上新出现的Badcase加入评估集，同时定期删除那些Agent已经百分百通过的“无效用例”，保证评估集始终存在一定挑战性。有些团队喜欢看到评估分数一路涨到99%，我会警惕：不是系统变强了，是评估集过时了。真正健康的进化应该是“评估集难度和系统能力同步上升”，就像训练一个运动员，总是举同样的重量，肌肉只会停在原地。

4.6 典型故障排查速查

这张表是从一些事故复盘里提炼出来的。我自己每次上线新的进化策略前，都会把表里的场景预设成“已经发生”，逼团队写清楚处置预案。没写过回滚方案的人，其实还没准备好做自动进化。

5. 不同岗位同事的真实视角：没人想当“甩锅侠”

5.1 工程研发的视角：它把最脏的活接管了

做Agent落地的工程师，最烦的从来不是模型不够聪明，而是无穷无尽的Badcase回归和Prompt调参。自动进化真正打动我们的地方，在于它有潜力把这些脏活自动化。比如线上新出现了一类口语化问法，以前要靠运营整理再交给研发改Prompt，现在系统会自动聚类、生成候选改写、跑一轮回归，再交给人工确认。哪怕只干掉中间两步，研发的日常工作都能清爽很多。所以很多工程师嘴上抱怨自动进化是“自己给自己挖坑”，真到了评估会上，还是会投赞成票。

5.2 产品经理的视角：用户要的是稳定，不是刺激

产品经理对“自动进化”的态度通常有个转变过程。刚开始觉得这是个很好讲故事的功能，越往后越发现它难以产品化。因为用户对Agent的期待不是“每次都不一样”，而是“每次回答都可靠”。如果Agent今天用一种思路回复，明天又换一种思路，即使两个回答单独看都不差，用户也会觉得不放心。产品经理真正想要的，是“可控范围内的持续优化”，而不是每天制造新惊喜。这也是为什么很多产品会把进化后的变化设计成“先沉淀成固定知识，再统一发布”，而不是让Agent随机应变。

5.3 安全同学的视角：退路比能力重要

安全同学看自动进化，关注的永远不是“它能干什么”，而是“它不能干什么”。他们最担心的场景是：一个进化后的Agent学到了某种高成功率但违规的路径，并且因为成功率达标而通过了自动评估。为了防御这种场景，安全团队会要求评估器里必须有独立的“安全分数”，而且安全分数不参与成功率加权。也就是说，哪怕成功率再高，安全分数不达标，候选策略也只能一票否决。这套逻辑已经被写进不少大厂的Agent平台规范里，表面上是流程繁琐，实际上是在给所有人的职业生涯兜底。

5.4 我个人的立场

如果再有同事问我怎么看Agent自动持续进化，我会回答两句：第一句，别让进化速度超过你的观测能力；第二句，先学会做评估器，再谈自动进化。

这两句话不是从哪本教科书里抄来的，是我们自己踩过一圈坑之后的沉淀。自动持续进化确实是Agent走向更复杂场景的必经之路，但它也是一个需要被敬畏对待的系统工程问题。这个方向上最稀缺的能力不是训练更大的模型，而是设计一套能让“进化”这件事情保持可预期、可追溯、可回退的机制。我会继续在这个方向上做下去，但一定会带着“评估器优先、可控性优先”的原则去做。毕竟，一个连自己为什么进化都不清楚的系统，跑得越快，越危险。