先删掉“无需维护”的承诺
客服 Prompt 很容易变成一堵补丁墙。产品规则调整后，旧指令里留下冲突；工具接口变了，Agent 还按原来的格式调用；用户换一种问法，意图分类又可能失效。所有问题都交给人逐条修，维护工作自然越积越多。
Self-Evolving Agent 提供了另一种处理方式。2026 年 3 月 16 日，YouTube 频道“系统在建”在相关视频中拆解了 Karpathy 的 Autoresearch、OpenAI 官方 Cookbook 和 EvoMap Evolver。三条路线可以抽出一条共同流程：发现问题、提出改动、验证结果，再保存表现更好的版本。
现有可引用材料没有给出客服维护人力下降 80% 的验证，也没有证明系统能够完全无人值守。更准确的目标是：少做反复手改 Prompt 的工作，把修改过程变成可检查、可测试、可回滚的版本发布。
自进化到底改了什么
Eigent 在自进化智能体的介绍中提到，许多已经部署的 Agent 从上线那一刻起就基本固定了：Prompt 由人编写，工具被硬编码，行为要等开发者发布新版本才会改变。
Self-Evolving Agent 可以更新的不只有 Prompt。《The What & When of Self-Evolving Agents》用一个 3×3 框架区分两件事：系统改了什么，以及这些改动会保留多久。放到客服场景里，边界可以这样划：
| 更新对象 | 客服里的具体问题 | 建议的上线边界 |
|---|---|---|
| Prompt 与回答策略 | 退换货口径含糊，追问条件遗漏 | Agent 生成候选版本，评估通过后再发布 |
| 工具描述与调用规则 | 该查政策库时却调用订单接口 | 必须用历史对话回放，检查是否误伤其他意图 |
| 记忆与检索策略 | 用户已经给出订单号，下一轮又被要求重复提供 | 限制保存范围，并单独检查隐私和错误记忆 |
| 模型权重与架构 | 需要更长期的能力变化 | 不建议作为客服项目的起点 |
多数团队可以先把范围锁定在 Prompt、工具描述和检索规则。改动范围越大，验证与回滚也会越难。
这四条线索，分别能借什么
Autoresearch、OpenAI Cookbook 和 EvoMap Evolver 在上述视频中被放在一起讨论。它们更适合当作自我改进的工程参照，不能直接视为已经验证过的客服产品。
- Autoresearch：适合用来理解反复试验、复盘结果和保留较优版本的思路。
- OpenAI Cookbook：如果团队已经在使用 OpenAI 的工程链路，可以从官方示例入手，把现有评估程序接到 Prompt 修改流程上。
- EvoMap Evolver：适合研究如何单独组织“演进”环节，而不是把修改逻辑全塞进主 Agent。
- Yunjue Agent：提出了 In-Situ，也就是原位自进化。根据项目介绍，它在推理过程中持续积累工具能力，无需外部监督，并开源了代码和 trace。
Yunjue Agent 在 HLE、DeepSearchQA、FinSearchComp、XBench ScienceQA 和 XBench DeepResearch 五个跨领域 benchmark 上取得了 SOTA 或接近 SOTA 的结果。这个成绩说明原位自进化路线具备研究价值，但它不是客服准确率，更不能直接换算成维护成本。客服团队仍要用自己的政策、工具和历史对话重新评估。
客服先跑通这条发布链
一套稳妥的自进化流程，可以压缩成下面这条链路：
对话 trace → 失败归因 → 候选改动 → 历史回放 → 影子流量 → 审批发布 → 监控与回滚
最先要补齐的是 trace。除了用户问题和最终答案，还应记录检索到的文档、工具调用参数、工具返回结果、转人工情况以及人工客服最终如何处理。没有这些信息，系统只能看到“用户不满意”，无法判断问题出在知识、工具还是上下文。
接下来是失败归因。评估器可以由规则、模型评审和人工标签共同组成，但输出要足够具体。例如，“回答不好”没有修改价值；“已经查到订单状态，但没有引用当前退货政策”才指向明确的改动位置。
Agent 可以据此生成候选 Prompt、工具说明或检索规则。候选版本不要直接写入生产环境。先用固定的历史对话回放，再接入影子流量观察结果。每次发布都应保留版本编号、改动内容、评估记录和回滚入口。
看一条退货对话怎么改
假设用户问：“这个订单还能退吗？”客服 Agent 成功调用了订单接口，却没有检索当前退货政策，最后给出一段模糊回答。
评估器应该把它标记为“订单工具调用成功，政策依据缺失”。随后生成的改动可以要求 Agent 在判断能否退货前，同时取得订单状态和有效政策。新版还要在过去的退货、换货和退款对话上回放，确认这条规则没有影响其他流程。
另一种情况是，用户已经提供订单号，下一轮只问“什么时候能到”，Agent 却再次索要订单信息。这里需要调整的是会话状态或记忆检索，不是继续往 System Prompt 里追加话术。
两类错误表面上都是“答得不好”，修改位置完全不同。自进化流程真正节省的，正是人工翻日志、猜原因和反复试词的时间。
别让 Agent 只追一个分数
“系统在建”的视频把“AI 会不会作弊”列为 Self-Evolving Agent 的关键问题之一。客服系统尤其容易遇到这种情况。
如果只看满意度，Agent 可能倾向于尽快转人工；如果只看工具调用成功率，它可能调用并不需要的接口；如果只比较答案与标准话术的相似度，系统又可能固守已经过期的表达。
评估时至少要同时检查政策是否正确、工具结果是否被正确使用、答案有没有依据、问题是否解决、是否发生不必要的转人工，以及人工抽查结果。退款条件、赔付标准、隐私要求等规则应保持为不可自动改写的约束。
记忆层也要单独设限。订单号、手机号和投诉记录不能因为检索效果更好，就被自动写入不受控制的长期记忆。系统可以提出调整建议，生产发布仍需保留人工闸门。
这些场景先别上自进化
- 反馈信号太弱或噪声太大：没有稳定的解决结果、人工标签或用户反馈，系统很难判断哪个版本更好。
- 每次话术变更都需要审计：医疗、法律等高合规场景可以使用 Agent 提出修改建议，但不适合自动发布。
- 对话很短，流程也很固定：简单查询用规则和检索就能完成，引入自进化只会增加测试与治理成本。
- 没有完整日志和版本回滚：看不到改动原因，也无法在出错后恢复旧版本。
- 知识库本身长期失准：Agent 再会改 Prompt，也无法修复错误的业务政策和过期文档。
维护岗位会换工作，不会消失
自进化客服的实际价值，是把维护人员从逐句调整 Prompt，转向定义评估规则、审核版本、处理例外和维护业务红线。Prompt 工程仍然存在，只是从手工作坊变成了有记录的发布流程。
更稳妥的起点，是先选一个边界清楚的意图，例如物流查询或退换货政策。让 Agent 负责发现失败和提出候选改动，由历史回放、影子测试与人工审批决定是否上线。等评估流程稳定后，再逐步开放工具规则和记忆策略的调整权限。
成熟的 Self-Evolving Agent 应该做到每次改动都有证据、有版本，也有退路。
