企业官网建设流程全解析

在业务迭代中，智能体（Agent）系统经常遇到一个很尴尬的问题：第一版效果不错，跑了两周后却越来越“笨”。不是模型变了，而是业务场景变了，而智能体还停在旧规则上。要让智能体持续保持高准确率，一个有效的思路是让它在运行过程中具备“自我改进”能力，而不是每次效果下降都靠人工重新调提示词。PILOT 框架正是围绕这个目标设计的一种架构模式。本文会从概念到代码，完整拆解如何在智能体运行过程中实现实时自我改进，并提供一个可以直接运行的 Python 示例项目。

1. 背景：智能体为什么需要“运行中的实时自我改进”

1.1 智能体系统的静态能力困境

先看一个很常见的场景。我们基于大模型搭建了一个客服问答智能体，初始版本使用了一套固定的系统提示词（System Prompt）和固定的温度参数（Temperature），在测试集上准确率能达到 90% 左右。上线之后，业务方不断补充新的商品、新的优惠规则、新的售后政策。随着时间推移，用户会问到越来越多开发阶段没预料到的问题。智能体面对这些新问题时，仍然按照旧规则输出，结果就是答非所问，准确率逐渐下降。

这种问题的根源是“策略静态化”：系统提示词、规则列表、工具调用方式、参数设置都是上线前确定好的，运行过程中不会根据实际反馈发生任何变化。传统的解决方式大概是两步：

1. 收集线上失败的日志。
2. 人工分析日志，重新修改提示词，再发版上线。

这个流程在早期没什么问题，但当任务量大、场景变化快时，人工维护成本会变得非常高。更关键的是，从发现问题到修复上线之间往往隔着好几个小时甚至几天，这期间智能体一直在用错误的策略服务用户。

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 兼容接口，需要安装 SDK

2.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 这个名称可以拆成五个部分，正好对应一个自我改进系统必须经历的五个阶段：

这五个阶段不是一次性流程，而是一个持续运行的闭环。每执行一次任务，系统就围绕这五个阶段转一圈，策略也随之微调。这也是“实时自我改进”和“离线微调”最本质的区别：离线微调需要经过训练、评估、发布流程，而 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_factory=lambda: datetime.datetime.now().isoformat()) @dataclass class ReflectionResult: """反思结果：包含质量分、发现的问题和建议""" score: float issues: List[str] = field(default_factory=list) suggestions: List[str] = field(default_factory=list) @dataclass class Policy: """智能体策略：提示词、参数、规则列表""" system_prompt: str temperature: float version: str rules: List[str] = field(default_factory=list) 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(score=score, issues=issues, suggestions=suggestions)

这里需要注意，规则评估器只能识别表面特征。实际项目中，如果任务比较复杂，可以再加一个基于 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(score=0.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 = f"v{version_num}" new_policy = Policy( system_prompt=new_prompt, temperature=new_temp, version=new_version, rules=new_rules, ) return new_policy def rollback(self, policy: Policy) -> Policy: """回滚到最近的一个历史版本""" if not self.history: return policy last = self.history.pop() return Policy( system_prompt=last["system_prompt"], temperature=last["temperature"], version=last["version"], rules=last["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_url=base_url, api_key=api_key) self.model = model def chat(self, messages: list, temperature: float = 0.7) -> str: resp = self.client.chat.completions.create( model=self.model, messages=messages, temperature=temperature, ) return resp.choices[0].message.content

注意，真实接入时请以你使用的 SDK 版本为准，本文只给出通用写法。

4.6 集成智能体主循环

现在把上面所有模块组装起来。智能体主循环的流程是：

1. 获取任务；
2. 基于当前策略生成回答；
3. 构造观测数据；
4. 使用评估器评估质量；
5. 根据评估结果决定是否更新策略。

# 文件路径：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_client=None): self.policy = base_policy self.llm = llm_client or MockLLMClient() self.evaluator = RuleBasedEvaluator() self.updater = PolicyUpdater(update_threshold=0.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, temperature=self.policy.temperature) # 3. 构造观测数据 obs = Observation( task_id=f"task-{len(self.memory) + 1}", input_text=task_input, output_text=output, expected_text=expected, 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_id="validation", input_text=sample["input"], output_text=self.llm.chat( [{"role": "system", "content": self.policy.system_prompt}, {"role": "user", "content": sample["input"]}], temperature=self.policy.temperature, ), expected_text=sample.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="你是一个严谨的项目助理。", temperature=0.7, version="v1", 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 常见问题速查表

5.2 典型案例：更新过度导致的效果振荡

有一个项目上线了 PILOT 自我改进机制，结果智能体在两小时内更新了 40 多次策略，最终表现比不更新还差。排查后发现原因是评估器的分数方差很大，同一类问题有时打 0.9 分，有时打 0.4 分，导致策略反复横跳。

解决方案是引入两条机制：

1. 降低更新频率，改为“连续 N 次低分才触发更新”；
2. 使用历史滑动窗口，取最近 5 次任务的平均分作为是否更新的依据。

这个思路类似于滑动平均滤波，可以有效避免单次异常样本对策略造成冲击。

6. 最佳实践与工程建议

6.1 安全与可控性

运行中的自我改进是一把双刃剑：改得好是能力提升，改得不好就是“野生提示词注入”。因此在工程落地时，必须把安全和可控性放在第一位。

第一条建议是所有策略更新都要保留审计日志。每次更新时，记录旧版本、新版本、触发原因、对应的任务输入输出、评估分数。这样当线上出现异常时，能够快速定位是哪一次更新导致的问题。

第二条建议是设置“更新白名单”。不是所有的策略内容都可以被自动修改，比如系统提示词中的安全约束、模型身份设定等关键内容，应该从可更新范围中排除。规则更新只能作用于业务规则区，而不能覆盖安全底线。

第三条建议是强制人工审批通道。对于质量分长期偏低、连续更新多次仍无改善的任务，应该停止自动更新，将该样本转入人工审核队列。让自动化系统处理常见问题，把疑难杂症交给人类专家。

6.2 成本控制

实时自我改进并不是免费的，每一次评估和策略更新都会带来额外的计算成本。尤其是 LLM 评估器，如果每一条任务都调用一次大模型，成本会快速上升。

推荐的成本控制方案是分层评估：

1. 先用规则评估器做一次轻量打分；
2. 只有分数落在“可疑区间”（例如 0.5 到 0.8 之间）时，才调用 LLM 评估器；
3. 只有 LLM 判定确实存在问题时，才触发策略更新。

这样大部分正常任务只需经过规则评估，成本几乎可以忽略。

6.3 指标设计

要衡量 PILOT 模式是否有效，不能只看“策略更新了几次”。建议建立如下指标：

• 平均质量分：一段时间内所有任务的平均评估分数，应呈上升趋势；
• 策略更新次数：更新太频繁说明系统不稳定，长期不更新说明可能没有发挥作用；
• 更新回滚率：回滚次数占更新次数的比例，过高说明评估或更新逻辑有问题；
• 问题解决率：更新后，相同问题再次出现的概率是否下降。

建议把指标接入监控看板，观察趋势变化。如果平均质量分持续一个月没有提升，就要考虑是不是反馈信号本身不够可靠。

6.4 可观测性设计

自我改进系统的一大风险是“内部过程不可见”。如果智能体悄悄修改了自己的提示词，而工程师完全不知道，出了问题就非常难排查。

建议为系统增加以下可观测手段：

• 版本化记录策略变化，做到每一次修改都可追溯；
• 在日志中输出关键决策过程，包括评估分数、触发原因、旧版本号、新版本号；
• 定期导出策略快照，方便对比不同时间点的行为差异。

如果条件允许，可以在测试环境中接入与生产环境相同的反馈数据流，做策略更新的影子验证。生产策略更新后，先在影子环境运行一段时间，对比新旧策略的效果，再决定是否全量生效。

7. 总结与学习路线

本文从智能体“越用越笨”的痛点切入，介绍了 PILOT 框架的核心思想：在智能体运行过程中，通过感知、内省、学习、优化、测试五个环节，构建实时自我改进的闭环系统。通过一个可以运行的 Python 示例，我们演示了智能体如何根据评估分数自动调整提示词、温度和规则列表，让策略从初始的“什么都不会”逐步演化为“越来越懂规则”。

如果你打算在真实项目中落地这套方案，我的建议是：先从一个具体的业务场景开始，把“反馈信号”定义清楚。不要一开始就追求大而全的自我改进平台，而是先把失败的日志收集起来，设计一个简单的评估器，再逐步加入策略更新和回归验证。PILOT 模式的价值不在于“自动改提示词”这个动作本身，而在于它让智能体具备了持续学习的能力。学习的方向是否正确，取决于反馈信号是否准确，这一点需要在项目初期反复校验。

下一步可以继续学习的方向包括：LangGraph 或 Dify 等编排平台中的 Recursive Agent 设计、基于记忆池的长期经验管理、以及基于强化学习的策略优化方法。把这些能力和 PILOT 的闭环思想结合起来，就能搭建出更接近真实生产水平的自适应智能体系统。

如果本文对你有帮助，可以收藏备用。后续我会继续整理智能体自我改进相关的实战案例，欢迎关注。