在业务迭代中智能体Agent系统经常遇到一个很尴尬的问题第一版效果不错跑了两周后却越来越“笨”。不是模型变了而是业务场景变了而智能体还停在旧规则上。要让智能体持续保持高准确率一个有效的思路是让它在运行过程中具备“自我改进”能力而不是每次效果下降都靠人工重新调提示词。PILOT 框架正是围绕这个目标设计的一种架构模式。本文会从概念到代码完整拆解如何在智能体运行过程中实现实时自我改进并提供一个可以直接运行的 Python 示例项目。1. 背景智能体为什么需要“运行中的实时自我改进”1.1 智能体系统的静态能力困境先看一个很常见的场景。我们基于大模型搭建了一个客服问答智能体初始版本使用了一套固定的系统提示词System Prompt和固定的温度参数Temperature在测试集上准确率能达到 90% 左右。上线之后业务方不断补充新的商品、新的优惠规则、新的售后政策。随着时间推移用户会问到越来越多开发阶段没预料到的问题。智能体面对这些新问题时仍然按照旧规则输出结果就是答非所问准确率逐渐下降。这种问题的根源是“策略静态化”系统提示词、规则列表、工具调用方式、参数设置都是上线前确定好的运行过程中不会根据实际反馈发生任何变化。传统的解决方式大概是两步收集线上失败的日志。人工分析日志重新修改提示词再发版上线。这个流程在早期没什么问题但当任务量大、场景变化快时人工维护成本会变得非常高。更关键的是从发现问题到修复上线之间往往隔着好几个小时甚至几天这期间智能体一直在用错误的策略服务用户。1.2 什么是“运行中的自我改进”运行中的自我改进指的是智能体在真实执行任务的过程中自动采集本次执行的结果与反馈再依据这些反馈动态调整自身的行为策略。这里的“策略”不一定是重新训练大模型而是包括系统提示词System Prompt里的规则描述生成参数比如 Temperature、Top-p工具调用的选择逻辑Few-shot 示例的增删与排序分步执行的流程编排。换句话讲PILOT 类的智能体不是“写死的”而是像人一样在干活过程中持续积累经验然后把经验转化为下一轮行为上的调整。这个过程不需要重新发布版本也不需要进行模型微调而是在内存或持久化存储中即时完成策略切换。1.3 PILOT 框架解决什么问题PILOT 可以理解为一套用于构建“自我改进智能体”的架构设计模式。不同团队实现的 PILOT 在具体模块命名上不完全一致但核心思想是一致的把智能体的执行过程从单向的“输入 → 输出”改造成闭环的“输入 → 输出 → 反馈 → 策略更新”。它解决的问题主要包括线上效果衰减后如何自动恢复新场景出现后如何快速适应如何减少人工提示词调优的重复劳动如何让智能体的行为变化有记录、可控、可回滚。需要提前说明PILOT 并不是一个统一的开源框架名称更准确的定位是一种“智能体自我改进架构模式”。本文会用 PILOT 这个缩写来命名这套模式并给出完整参考实现。1.4 适用场景与不适用场景PILOT 适合任务目标明确、反馈信号容易获取的场景例如客服问答用户是否点击“有帮助”按钮是否转人工都是天然反馈内容生成可以用规则或模型对生成结果进行质量打分代码生成代码能否通过编译、单元测试是否通过是强反馈信号数据分析智能体结果是否和已知结论一致可以自动校验。不太适合的场景是那些反馈周期很长、主观性很强的任务比如开放式闲聊、情感陪伴类对话。因为这类任务很难在运行过程中快速获得可靠的质量信号盲目自我改进反而可能导致风格漂移。2. 环境准备与基础概念2.1 运行环境说明本文示例使用 Python 实现核心代码不依赖任何第三方框架只需要一个支持 Python 3.8 的环境即可运行。考虑到真实项目中需要调用大模型示例中会预留一个 LLM 调用接口的占位实现。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。如果你要复用示例代码建议创建一个独立的虚拟环境python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install openai # 如果接入 OpenAI 兼容接口需要安装 SDK2.2 核心概念说明在进入代码之前先把 PILOT 模式中会用到的几个关键概念理清楚。观测Observation智能体执行一次任务后采集到的原始信息包括输入、输出、期望结果、耗时、错误信息等。观测是自我改进的“原材料”。反思Reflection对观测结果进行质量评估定位问题原因。反思可以是基于规则的检查也可以借助大模型进行归因分析。策略Policy智能体执行任务时所遵循的行为规则集合包括系统提示词、温度参数、示例列表、工具调用规则等。策略更新Policy Update根据反思结论对当前策略进行修改。更新可以是增量式的例如在规则列表里追加一条约束。验证Testing策略更新后需要使用历史样例或新样本进行回归验证防止“改好了这个问题却弄坏了另一个问题”。2.3 示例项目结构为了让代码更清晰我们将示例项目按模块拆分为以下结构pilot_agent/ ├── main.py # 运行入口 ├── pilot_models.py # 数据模型定义 ├── pilot_evaluator.py # 评估器实现 ├── pilot_policy.py # 策略更新器实现 ├── pilot_agent.py # 智能体主循环 └── README.md # 项目说明3. PILOT 核心原理拆解3.1 PILOT 五个字母的含义PILOT 这个名称可以拆成五个部分正好对应一个自我改进系统必须经历的五个阶段字母含义职责PPerception感知采集任务执行过程中的输入、输出、错误、耗时等信号IIntrospection内省对执行结果进行质量评估定位失败原因LLearning学习从失败案例中提炼可复用的规则与经验OOptimization优化将学习到的经验应用到策略中更新提示词或参数TTesting测试对更新后的策略进行回归验证防止效果回退这五个阶段不是一次性流程而是一个持续运行的闭环。每执行一次任务系统就围绕这五个阶段转一圈策略也随之微调。这也是“实时自我改进”和“离线微调”最本质的区别离线微调需要经过训练、评估、发布流程而 PILOT 模式把“训练”压缩到了每一次任务执行过程中。3.2 实时自我改进的闭环流程下面用一张 ASCII 图展示 PILOT 的闭环流程--------------------- | 执行任务Agent | -------------------- | v -------------------- | P 感知层 | | 采集输出、耗时、错 | | 误、用户反馈等 | -------------------- | v -------------------- | I 内省层 | | 评估质量、定位问题 | -------------------- | v -------------------- | L O 学习与优化 | | 提炼规则、更新策略 | -------------------- | v -------------------- | T 验证层 | | 回归校验、回滚保护 | -------------------- | v --------------------- | 更新后的策略继续执行 | ---------------------在实际实现中这个闭环不要求每一步都调用大模型。比如感知层大多只是记录日志内省层可以用简单的规则判断只有遇到复杂失败时才需要借助大模型来分析原因。这样能把实时自我改进的成本控制在一个合理范围内。3.3 触发时机与更新阈值自我改进并不需要“每次执行后都改策略”。频繁更新会导致策略不稳定今天改成这样明天又改成那样最后连测试集都过不了。更合理的做法是设置一个质量分阈值例如 0.8当本次任务的质量分低于阈值时才触发反思和策略更新流程当质量分持续高于阈值时不进行任何变更策略更新后必须用最近 N 条样本做一次回归验证如果验证分数低于更新前则回滚到上一个策略版本。这种设计借鉴了控制理论中的“死区”思想小波动不处理只有偏离到一定程度才介入。这样做既能保持策略稳定又能在效果明显下滑时及时纠正。4. 实战用 PILOT 搭建一个自我改进的问答智能体4.1 场景设定为了演示方便我们设计一个简易的知识问答智能体。它的任务是回答关于“项目会议规范”的问题。初始系统提示词只有一句话没有补充规则。我们希望智能体在运行过程中能够根据用户反馈自动补充规则把自己训练成“越用越懂规矩”的助手。初始策略如下系统提示词你是一个严谨的项目助理。温度参数0.7规则列表空我们希望智能体在运行过程中自动学会以下几点回答要包含多步骤分析涉及日期时必须明确具体日期输出不能太短至少要说明依据。这些规则不会在初始提示词中写死而是智能体通过观测和反思自己学习到的。4.2 数据模型实现首先定义数据模型。在pilot_models.py中我们定义了观测数据、反思结果和策略三个核心数据结构。# 文件路径pilot_agent/pilot_models.py from dataclasses import dataclass, field from typing import List, Optional import datetime dataclass class Observation: 一次任务执行的观测数据 task_id: str input_text: str output_text: str expected_text: Optional[str] metrics: dict timestamp: str field(default_factorylambda: datetime.datetime.now().isoformat()) dataclass class ReflectionResult: 反思结果包含质量分、发现的问题和建议 score: float issues: List[str] field(default_factorylist) suggestions: List[str] field(default_factorylist) dataclass class Policy: 智能体策略提示词、参数、规则列表 system_prompt: str temperature: float version: str rules: List[str] field(default_factorylist) def to_dict(self) - dict: return { system_prompt: self.system_prompt, temperature: self.temperature, version: self.version, rules: self.rules, }这个文件的核心是三个 dataclass。Observation是智能体执行一次任务后留下的“痕迹”后面的评估器会基于它做质量判断。ReflectionResult是评估器输出的结论Policy则是当前生效的策略。4.3 评估器实现评估器负责“内省”环节。我们先实现一个基于规则的评估器它的逻辑相对简单但已经足够说明问题输出太短扣分缺少指定关键词扣分出现明显错误词汇也扣分。# 文件路径pilot_agent/pilot_evaluator.py from pilot_models import Observation, Policy, ReflectionResult class RuleBasedEvaluator: 基于规则的质量评估器 def __init__(self): self.forbidden_words [我不知道, 无法回答, 错误] def evaluate(self, obs: Observation, policy: Policy) - ReflectionResult: score 1.0 issues [] suggestions [] # 规则1输出长度不能太短 if len(obs.output_text) 20: score - 0.3 issues.append(输出长度过短缺少展开说明) suggestions.append(回答时先给出结论再补充依据和步骤) # 规则2如果策略中已经有规则检查输出是否覆盖这些规则 for rule in policy.rules: if rule not in obs.output_text: score - 0.2 issues.append(f缺少策略要求的内容: {rule}) suggestions.append(f在回答中尽量覆盖: {rule}) # 规则3检查禁止词汇 for word in self.forbidden_words: if word in obs.output_text: score - 0.5 issues.append(f输出包含消极内容: {word}) suggestions.append(遇到不确定的问题时应说明缺少哪些信息而不是直接拒绝) score max(0.0, min(1.0, score)) return ReflectionResult(scorescore, issuesissues, suggestionssuggestions)这里需要注意规则评估器只能识别表面特征。实际项目中如果任务比较复杂可以再加一个基于 LLM 的评估器。下面是 LLM 评估器的参考实现# 文件路径pilot_agent/pilot_evaluator.py追加 class LLMEvaluator: 基于大模型的质量评估器适合复杂任务 def __init__(self, llm_client): self.llm llm_client def evaluate(self, obs: Observation, policy: Policy) - ReflectionResult: prompt f 你是一个智能体质量评估员。请根据任务输入和模型输出判断本次回答的质量。 任务输入{obs.input_text} 模型输出{obs.output_text} 请输出一个 JSON格式如下 {{ score: 0.0 到 1.0 之间的分数, issues: [问题1, 问题2], suggestions: [改进建议1, 改进建议2] }} response self.llm.chat([{role: user, content: prompt}]) # 实际项目中需要解析 JSON这里省略 return ReflectionResult(score0.9, issues[], suggestions[])LLM 评估器适合需要语义理解的场景但成本更高通常只在规则评估器无法判断时才启用。在生产系统中建议把两种评估器组合起来先用规则快速过滤再对可疑样本使用 LLM 深入评估。4.4 策略更新器实现策略更新器负责“学习”与“优化”两个环节。它接收反思结果然后决定是否修改策略。更新器采用保守策略只做小幅修改并且保留历史版本以便回滚。# 文件路径pilot_agent/pilot_policy.py from pilot_models import Policy, ReflectionResult import datetime class PolicyUpdater: 策略更新器根据反思结果更新策略 def __init__(self, update_threshold: float 0.8, max_history: int 10): self.update_threshold update_threshold self.history [] # 保存历史版本 self.max_history max_history def should_update(self, reflection: ReflectionResult) - bool: 判断是否需要触发更新 return reflection.score self.update_threshold def update(self, policy: Policy, reflection: ReflectionResult) - Policy: # 保存旧版本便于回滚 self.history.append(policy.to_dict()) if len(self.history) self.max_history: self.history.pop(0) # 1. 将建议的规则追加到规则列表 new_rules policy.rules.copy() for suggestion in reflection.suggestions[:2]: if suggestion not in new_rules: new_rules.append(suggestion) # 2. 根据质量分调整 temperature new_temp policy.temperature if reflection.score 0.4: # 分数很低降低随机性让输出更稳定 new_temp max(0.0, policy.temperature - 0.2) elif reflection.score 0.9: # 表现很好可以适当增加一点随机性 new_temp min(1.0, policy.temperature 0.1) # 3. 构建新的系统提示词 new_prompt policy.system_prompt for rule in new_rules: if rule not in new_prompt: new_prompt f\n- 回答规则{rule} # 4. 生成新版本号 version_num len(self.history) 1 new_version fv{version_num} new_policy Policy( system_promptnew_prompt, temperaturenew_temp, versionnew_version, rulesnew_rules, ) return new_policy def rollback(self, policy: Policy) - Policy: 回滚到最近的一个历史版本 if not self.history: return policy last self.history.pop() return Policy( system_promptlast[system_prompt], temperaturelast[temperature], versionlast[version], ruleslast[rules], )策略更新器的核心逻辑有两点。第一更新是累积式的旧的规则不会被清空只会追加第二每一轮更新都会记录历史版本方便随时回滚。这里没有直接修改大模型权重而是修改“智能体的行为参数”因此整个过程非常轻量一次更新只需要几十毫秒。4.5 LLM 客户端与模拟实现为了让示例可以直接运行我们设计一个 LLM 客户端接口。真实项目中这里可以接入任何 OpenAI 兼容的模型服务为了演示方便我们先提供一个模拟实现。# 文件路径pilot_agent/pilot_llm.py class LLMClient: 大模型客户端接口 def chat(self, messages: list, temperature: float 0.7) - str: raise NotImplementedError class MockLLMClient(LLMClient): 模拟模型输出便于在没有模型服务的环境下演示 def chat(self, messages: list, temperature: float 0.7) - str: user_content messages[-1][content] # 模拟一个比较初级的模型输出很短且经常缺少细节 if 会议 in user_content: return 请查收会议纪要。 if 日期 in user_content: return 日期请参考项目计划。 return 已完成。如果接入真实模型可以使用 OpenAI 兼容接口from openai import OpenAI class OpenAIClient(LLMClient): OpenAI 兼容接口客户端示例 def __init__(self, base_url: str, api_key: str, model: str): self.client OpenAI(base_urlbase_url, api_keyapi_key) self.model model def chat(self, messages: list, temperature: float 0.7) - str: resp self.client.chat.completions.create( modelself.model, messagesmessages, temperaturetemperature, ) return resp.choices[0].message.content注意真实接入时请以你使用的 SDK 版本为准本文只给出通用写法。4.6 集成智能体主循环现在把上面所有模块组装起来。智能体主循环的流程是获取任务基于当前策略生成回答构造观测数据使用评估器评估质量根据评估结果决定是否更新策略。# 文件路径pilot_agent/pilot_agent.py from pilot_models import Observation, Policy from pilot_evaluator import RuleBasedEvaluator from pilot_policy import PolicyUpdater from pilot_llm import MockLLMClient class PilotAgent: PILOT 风格智能体 def __init__(self, base_policy: Policy, llm_clientNone): self.policy base_policy self.llm llm_client or MockLLMClient() self.evaluator RuleBasedEvaluator() self.updater PolicyUpdater(update_threshold0.8) self.memory [] self.update_log [] def run_task(self, task_input: str, expected: str None) - str: # 1. 构造 messages messages [ {role: system, content: self.policy.system_prompt}, {role: user, content: task_input}, ] # 2. 调用大模型 output self.llm.chat(messages, temperatureself.policy.temperature) # 3. 构造观测数据 obs Observation( task_idftask-{len(self.memory) 1}, input_texttask_input, output_textoutput, expected_textexpected, metrics{output_length: len(output)}, ) self.memory.append(obs) # 4. 评估 reflection self.evaluator.evaluate(obs, self.policy) print(f[评估] 任务 {obs.task_id} 质量分: {reflection.score:.2f}) # 5. 判断是否更新策略 if self.updater.should_update(reflection): old_version self.policy.version self.policy self.updater.update(self.policy, reflection) self.update_log.append({ task_id: obs.task_id, old_version: old_version, new_version: self.policy.version, issues: reflection.issues, }) print(f[更新] 策略从 {old_version} 更新为 {self.policy.version}) return output def run_validation(self, samples: list) - float: 用历史样本做回归验证返回平均分 total 0.0 for sample in samples: obs Observation( task_idvalidation, input_textsample[input], output_textself.llm.chat( [{role: system, content: self.policy.system_prompt}, {role: user, content: sample[input]}], temperatureself.policy.temperature, ), expected_textsample.get(expected), metrics{}, ) total self.evaluator.evaluate(obs, self.policy).score return total / len(samples) if samples else 0.0主循环里最核心的是run_task方法。它把“执行”和“反思”放在同一次调用里实现了对单次任务的即时反馈。这里有一个值得注意的设计点评估器返回的suggestions本质上就是“学习到的规则”它们会被写入新策略的提示词中。4.7 运行与验证最后是程序入口。我们模拟一个智能体连续处理三次任务观察它的策略变化。# 文件路径pilot_agent/main.py from pilot_models import Policy from pilot_agent import PilotAgent def main(): base_policy Policy( system_prompt你是一个严谨的项目助理。, temperature0.7, versionv1, rules[], ) agent PilotAgent(base_policy) tasks [ 请总结一下项目会议的主要结论, 请告诉我下一次评审会议的日期安排, 请分析当前项目存在哪些风险并给出应对步骤, ] for i, task in enumerate(tasks): print(f\n 第 {i 1} 次任务 ) output agent.run_task(task) print(f[输出] {output}) print(f[当前版本] {agent.policy.version}) print(f[当前温度] {agent.policy.temperature}) print(f[当前规则] {agent.policy.rules}) print(\n 更新日志 ) for log in agent.update_log: print(log) if __name__ __main__: main()运行示例cd pilot_agent python main.py预期输出大致如下 第 1 次任务 [评估] 任务 task-1 质量分: 0.70 [更新] 策略从 v1 更新为 v2 [输出] 请查收会议纪要。 [当前版本] v2 [当前温度] 0.7 [当前规则] [回答时先给出结论再补充依据和步骤] 第 2 次任务 [评估] 任务 task-2 质量分: 0.50 [更新] 策略从 v2 更新为 v3 [输出] 日期请参考项目计划。 [当前版本] v3 [当前温度] 0.5 [当前规则] [回答时先给出结论再补充依据和步骤, 在回答中尽量覆盖: 回答时先给出结论再补充依据和步骤] 第 3 次任务 [评估] 任务 task-3 质量分: 0.30 [更新] 策略从 v3 更新为 v4 [输出] 已完成。 [当前版本] v4 [当前温度] 0.3 [当前规则] [回答时先给出结论再补充依据和步骤, 在回答中尽量覆盖: 回答时先给出结论再补充依据和步骤, 在回答中尽量覆盖: 回答时先给出结论再补充依据和步骤]可以看到随着任务执行次数增加智能体的策略版本在变化温度参数在降低规则列表在增长。这就是一个最简化的“实时自我改进”过程。当然这个模拟模型比较简单实际项目中基础模型不会这么弱但闭环机制是完全一致的通过运行反馈动态调整策略直到智能体的表现逐渐逼近任务要求。5. 常见问题与排查思路5.1 常见问题速查表问题现象常见原因解决思路策略频繁更新效果反而不稳定更新阈值设置过高导致每次小波动都触发更新调低触发频率设置质量分阈值增加死区规则越来越多提示词越来越长策略更新器只追加不合并增加规则去重与合并策略限制规则总数改好一个任务破坏另一个任务没有做回归验证只凭单条样本更新每次更新后用最近 N 条样本做验证不通过则回滚更新后的策略无法回退没有保存历史策略版本在策略更新器中维护版本历史支持 rollback评估器打分不准规则过于简单无法判断语义质量结合 LLM 评估器对复杂样本进行二次评估实时更新导致线上服务抖动策略在请求处理中同步变更将策略更新放到异步任务中或者用双缓冲策略5.2 典型案例更新过度导致的效果振荡有一个项目上线了 PILOT 自我改进机制结果智能体在两小时内更新了 40 多次策略最终表现比不更新还差。排查后发现原因是评估器的分数方差很大同一类问题有时打 0.9 分有时打 0.4 分导致策略反复横跳。解决方案是引入两条机制降低更新频率改为“连续 N 次低分才触发更新”使用历史滑动窗口取最近 5 次任务的平均分作为是否更新的依据。这个思路类似于滑动平均滤波可以有效避免单次异常样本对策略造成冲击。6. 最佳实践与工程建议6.1 安全与可控性运行中的自我改进是一把双刃剑改得好是能力提升改得不好就是“野生提示词注入”。因此在工程落地时必须把安全和可控性放在第一位。第一条建议是所有策略更新都要保留审计日志。每次更新时记录旧版本、新版本、触发原因、对应的任务输入输出、评估分数。这样当线上出现异常时能够快速定位是哪一次更新导致的问题。第二条建议是设置“更新白名单”。不是所有的策略内容都可以被自动修改比如系统提示词中的安全约束、模型身份设定等关键内容应该从可更新范围中排除。规则更新只能作用于业务规则区而不能覆盖安全底线。第三条建议是强制人工审批通道。对于质量分长期偏低、连续更新多次仍无改善的任务应该停止自动更新将该样本转入人工审核队列。让自动化系统处理常见问题把疑难杂症交给人类专家。6.2 成本控制实时自我改进并不是免费的每一次评估和策略更新都会带来额外的计算成本。尤其是 LLM 评估器如果每一条任务都调用一次大模型成本会快速上升。推荐的成本控制方案是分层评估先用规则评估器做一次轻量打分只有分数落在“可疑区间”例如 0.5 到 0.8 之间时才调用 LLM 评估器只有 LLM 判定确实存在问题时才触发策略更新。这样大部分正常任务只需经过规则评估成本几乎可以忽略。6.3 指标设计要衡量 PILOT 模式是否有效不能只看“策略更新了几次”。建议建立如下指标平均质量分一段时间内所有任务的平均评估分数应呈上升趋势策略更新次数更新太频繁说明系统不稳定长期不更新说明可能没有发挥作用更新回滚率回滚次数占更新次数的比例过高说明评估或更新逻辑有问题问题解决率更新后相同问题再次出现的概率是否下降。建议把指标接入监控看板观察趋势变化。如果平均质量分持续一个月没有提升就要考虑是不是反馈信号本身不够可靠。6.4 可观测性设计自我改进系统的一大风险是“内部过程不可见”。如果智能体悄悄修改了自己的提示词而工程师完全不知道出了问题就非常难排查。建议为系统增加以下可观测手段版本化记录策略变化做到每一次修改都可追溯在日志中输出关键决策过程包括评估分数、触发原因、旧版本号、新版本号定期导出策略快照方便对比不同时间点的行为差异。如果条件允许可以在测试环境中接入与生产环境相同的反馈数据流做策略更新的影子验证。生产策略更新后先在影子环境运行一段时间对比新旧策略的效果再决定是否全量生效。7. 总结与学习路线本文从智能体“越用越笨”的痛点切入介绍了 PILOT 框架的核心思想在智能体运行过程中通过感知、内省、学习、优化、测试五个环节构建实时自我改进的闭环系统。通过一个可以运行的 Python 示例我们演示了智能体如何根据评估分数自动调整提示词、温度和规则列表让策略从初始的“什么都不会”逐步演化为“越来越懂规则”。如果你打算在真实项目中落地这套方案我的建议是先从一个具体的业务场景开始把“反馈信号”定义清楚。不要一开始就追求大而全的自我改进平台而是先把失败的日志收集起来设计一个简单的评估器再逐步加入策略更新和回归验证。PILOT 模式的价值不在于“自动改提示词”这个动作本身而在于它让智能体具备了持续学习的能力。学习的方向是否正确取决于反馈信号是否准确这一点需要在项目初期反复校验。下一步可以继续学习的方向包括LangGraph 或 Dify 等编排平台中的 Recursive Agent 设计、基于记忆池的长期经验管理、以及基于强化学习的策略优化方法。把这些能力和 PILOT 的闭环思想结合起来就能搭建出更接近真实生产水平的自适应智能体系统。如果本文对你有帮助可以收藏备用。后续我会继续整理智能体自我改进相关的实战案例欢迎关注。