
某次大促期间,AIOps 系统突然"变笨"了——同样的告警,3 个月前能精准定位根因,现在却给出无关建议。排查后发现,系统的知识库没有更新机制,新故障模式无法被学习。引入 GEPA 自我进化机制后,系统每个月自动从新案例中学习,推理准确率从 68% 回升到 92%。
我负责的 AIOps 系统上线初期,Agent 只能处理预设的运维场景。但运维环境千变万化,静态规则永远跟不上新问题的出现速度。GEPA 闭环机制解决了这个矛盾。
GEPA 是 ICLR 2026 论文提出的智能体自我进化框架,四个阶段形成闭环:
阶段 | 英文 | 核心动作 | AIOps 场景 |
|---|---|---|---|
G | Generate | 生成解决方案 | 根据告警生成修复方案 |
E | Execute | 执行方案 | 执行修复操作 |
P | Plan | 规划改进 | 分析执行结果,规划优化 |
A | Adapt | 适应更新 | 更新记忆和技能库 |

关键洞察:传统 Agent 是"用完即弃",每次从零开始推理。GEPA 让 Agent 把每次经验沉淀为可复用的知识,越用越聪明。

图:GEPA 自我进化机制完整闭环架构,展示输入事件经过四步闭环流转,最终输出修复动作、新生技能和经验记录
为什么需要双层记忆?短期记忆保障当前任务上下文连贯,长期记忆实现跨任务知识复用。只有短期记忆会"健忘",只有长期记忆会"慢启动"。
为什么需要理清记忆流转流程?记忆从写入到迁移再到检索,涉及短期→长期→归档三条路径。画清楚流转逻辑,才能理解后面代码中 TTL 续期、迁移评估、Embedding 更新等设计的来龙去脉。

图:双层记忆系统的完整流转路径,从短期记忆写入到长期记忆迁移,再到归档清理的完整生命周期
"""
GEPA 记忆管理系统
短期记忆(Redis)+ 长期记忆(PostgreSQL + ChromaDB)
"""
import json
import hashlib
from datetime import datetime, timedelta
from dataclasses import dataclass, field
from typing import Optional
import redis
import psycopg2
import chromadb
@dataclass
class MemoryEntry:
"""记忆条目"""
id: str
content: str
category: str # experience / skill / pitfall
tags: list[str] = field(default_factory=list)
success_rate: float = 0.0
usage_count: int = 0
created_at: datetime = field(default_factory=datetime.now)
updated_at: datetime = field(default_factory=datetime.now)
class MemoryManager:
"""双层记忆管理器"""
def __init__(self, redis_url: str, pg_dsn: str,
chroma_path: str):
# 短期记忆:Redis(TTL 1 小时)
self.redis = redis.from_url(redis_url)
self.redis_ttl = timedelta(hours=1)
# 长期记忆:PostgreSQL(结构化存储)
self.pg = psycopg2.connect(pg_dsn)
# 长期记忆:ChromaDB(向量检索)
self.chroma = chromadb.PersistentClient(path=chroma_path)
self.collection = self.chroma.get_or_create_collection(
name="ops_experience",
metadata={"hnsw:space": "cosine"}
)
# ---- 短期记忆操作 ----
def set_short_term(self, session_id: str,
key: str, value: dict):
"""写入短期记忆"""
redis_key = f"short:{session_id}:{key}"
self.redis.setex(
redis_key,
int(self.redis_ttl.total_seconds()),
json.dumps(value, ensure_ascii=False)
)
def get_short_term(self, session_id: str,
key: str) -> Optional[dict]:
"""读取短期记忆"""
redis_key = f"short:{session_id}:{key}"
data = self.redis.get(redis_key)
return json.loads(data) if data else None
# ---- 长期记忆操作 ----
def save_long_term(self, entry: MemoryEntry):
"""保存到长期记忆(双写:PG + ChromaDB)"""
# 写入 PostgreSQL
with self.pg.cursor() as cur:
cur.execute("""
INSERT INTO memory_entries
(id, content, category, tags,
success_rate, usage_count, created_at, updated_at)
VALUES (%s, %s, %s, %s, %s, %s, %s, %s)
ON CONFLICT (id) DO UPDATE SET
usage_count = memory_entries.usage_count + 1,
success_rate = %s,
updated_at = %s
""", (
entry.id, entry.content, entry.category,
json.dumps(entry.tags), entry.success_rate,
entry.usage_count, entry.created_at,
entry.updated_at,
entry.success_rate, entry.updated_at
))
self.pg.commit()
# 写入 ChromaDB(向量索引)
self.collection.upsert(
ids=[entry.id],
documents=[entry.content],
metadatas=[{
"category": entry.category,
"success_rate": entry.success_rate,
"tags": ",".join(entry.tags),
}]
)
def search_long_term(self, query: str,
top_k: int = 5) -> list[MemoryEntry]:
"""向量检索长期记忆"""
results = self.collection.query(
query_texts=[query],
n_results=top_k,
where={"success_rate": {"$gte": 0.6}}
)
entries = []
for i, doc_id in enumerate(results["ids"][0]):
meta = results["metadatas"][0][i]
entries.append(MemoryEntry(
id=doc_id,
content=results["documents"][0][i],
category=meta["category"],
tags=meta.get("tags", "").split(","),
success_rate=meta.get("success_rate", 0.0),
))
return entries
为什么 Generate 要检索记忆而不是直接用 LLM 推理?纯 LLM 推理每次从零开始,无法复用历史经验。检索记忆后,LLM 可以在已有方案基础上优化,效果提升显著。
class GEPACycle:
"""GEPA 四步闭环引擎"""
def __init__(self, memory: MemoryManager, llm_client):
self.memory = memory
self.llm = llm_client
def generate(self, session_id: str,
alert_context: dict) -> dict:
"""Generate: 生成候选方案"""
# 1. 检索长期记忆中的相似经验
similar = self.memory.search_long_term(
query=alert_context["description"],
top_k=3
)
# 2. 读取短期记忆中的当前会话上下文
session_ctx = self.memory.get_short_term(
session_id, "context"
) or {}
# 3. 组装 prompt,让 LLM 基于经验生成方案
experience_refs = "\n".join([
f"- [{e.category}] {e.content} "
f"(成功率: {e.success_rate:.0%})"
for e in similar
])
prompt = f"""
当前告警: {alert_context['description']}
告警级别: {alert_context['severity']}
服务名称: {alert_context['service']}
历史相似经验:
{experience_refs}
当前会话上下文:
{json.dumps(session_ctx, ensure_ascii=False)}
请基于以上经验,生成修复方案。
输出格式: JSON,包含 steps 和 risk_level。
"""
response = self.llm.chat(prompt)
plan = json.loads(response)
# 4. 写入短期记忆
self.memory.set_short_term(
session_id, "generated_plan", plan
)
return plan
为什么 Adapt 要同时更新成功和失败的经验?成功经验用于复用,失败经验用于避坑。只记录成功,Agent 会重复踩坑;只记录失败,Agent 不敢尝试。
def adapt(self, session_id: str,
execution_result: dict):
"""Adapt: 适应更新,将经验写入长期记忆"""
plan = self.memory.get_short_term(
session_id, "generated_plan"
)
alert_ctx = self.memory.get_short_term(
session_id, "alert_context"
)
success = execution_result.get("status") == "success"
# 计算成功率(结合历史数据)
entry_id = hashlib.md5(
(alert_ctx["description"] +
str(plan.get("steps", []))).encode()
).hexdigest()[:12]
# 构建记忆条目
if success:
content = (
f"告警: {alert_ctx['description']}\n"
f"方案: {json.dumps(plan['steps'], ensure_ascii=False)}\n"
f"结果: 修复成功,耗时 {execution_result.get('duration_sec')}s"
)
category = "experience"
else:
content = (
f"告警: {alert_ctx['description']}\n"
f"方案: {json.dumps(plan['steps'], ensure_ascii=False)}\n"
f"结果: 修复失败,原因: {execution_result.get('error')}\n"
f"避坑建议: {execution_result.get('suggestion', '无')}"
)
category = "pitfall"
entry = MemoryEntry(
id=entry_id,
content=content,
category=category,
tags=[
alert_ctx.get("service", ""),
alert_ctx.get("severity", ""),
plan.get("risk_level", ""),
],
success_rate=1.0 if success else 0.0,
usage_count=1,
)
self.memory.save_long_term(entry)
GEPA 闭环运行一段时间后,高频场景的经验可以提炼为可复用技能:
为什么要把经验升级为技能?经验是自然语言描述,每次检索后还需 LLM 解析。技能是结构化 YAML,可以直接执行,响应速度从秒级降到毫秒级。
class SkillAutoGenerator:
"""技能自动生成器
当同一场景的经验累积 3 次以上,
自动提炼为结构化技能
"""
def __init__(self, memory: MemoryManager, llm_client):
self.memory = memory
self.llm = llm_client
def check_and_generate(self, alert_type: str):
"""检查是否有足够经验生成技能"""
# 查询该告警类型的成功经验
similar = self.memory.search_long_term(
query=alert_type, top_k=10
)
success_entries = [
e for e in similar
if e.category == "experience"
and e.success_rate >= 0.8
]
# 累积 3 次以上成功经验,触发技能生成
if len(success_entries) >= 3:
return self._generate_skill(
alert_type, success_entries
)
return None
def _generate_skill(self, alert_type: str,
entries: list[MemoryEntry]) -> dict:
"""基于经验生成技能"""
experience_text = "\n\n".join([
f"经验{i+1}: {e.content}"
for i, e in enumerate(entries)
])
prompt = f"""
告警类型: {alert_type}
以下为多次成功修复的经验总结:
{experience_text}
请提炼为标准化的运维技能,输出 YAML 格式。
包含: name, description, params, steps, rollback。
"""
skill_yaml = self.llm.chat(prompt)
# 保存为技能记忆
skill_entry = MemoryEntry(
id=f"skill-{alert_type}",
content=skill_yaml,
category="skill",
tags=[alert_type, "auto-generated"],
success_rate=1.0,
usage_count=0,
)
self.memory.save_long_term(skill_entry)
return {"skill_name": alert_type, "yaml": skill_yaml}
现象:系统运行 3 个月后,ChromaDB 查询 RT 从 50ms 飙到 800ms,Generate 阶段严重超时。
原因:所有经验无差别入库,包含大量低价值条目(重复告警、无效方案),向量库膨胀后检索效率急剧下降。
解决:增加记忆准入门槛和定期清理:
def save_long_term(self, entry: MemoryEntry):
# 准入门槛:相似度 < 0.7 的才入库(避免重复)
existing = self.collection.query(
query_texts=[entry.content],
n_results=1,
)
if existing["distances"][0]:
min_dist = min(existing["distances"][0])
if min_dist < 0.3: # 高度相似,跳过
return
# 正常保存逻辑
...
def cleanup_low_value(self, days: int = 90):
"""定期清理低价值记忆"""
with self.pg.cursor() as cur:
cur.execute("""
DELETE FROM memory_entries
WHERE success_rate < 0.3
AND usage_count < 2
AND updated_at < NOW() - INTERVAL '%s days'
""", (days,))
deleted = cur.rowcount
self.pg.commit()
return deleted
提醒:建议每周执行一次清理,保留成功率 >= 0.3 或使用次数 >= 2 的记忆。
现象:复杂故障排查跨 30+ 分钟,Agent 中途"忘了"之前分析过的信息,重复排查同一日志。
原因:Redis 短期记忆 TTL 设为 1 小时,但部分操作(等待人工审批)会中断流程,实际会话远超 1 小时。
解决:TTL 自动续期机制:
def get_short_term(self, session_id: str,
key: str) -> Optional[dict]:
redis_key = f"short:{session_id}:{key}"
data = self.redis.get(redis_key)
if data:
# 每次读取时自动续期 1 小时
self.redis.expire(
redis_key,
int(self.redis_ttl.total_seconds())
)
return json.loads(data) if data else None
提醒:同时设置确保上限 TTL(如 4 小时),防止僵尸会话占满 Redis 内存。
现象:系统自动生成了一个"磁盘满时删除日志文件"的技能,执行后把关键审计日志也删了。
原因:3 次成功经验都恰好是清理非关键日志,但 LLM 提炼技能时没有加入安全约束,生成了一刀切的删除策略。
解决:技能生成后增加人工审批环节:
def _generate_skill(self, alert_type, entries):
skill_yaml = self.llm.chat(prompt)
# 强制加入安全约束模板
skill_dict = yaml.safe_load(skill_yaml)
safety_check = {
"safety": {
"require_approval": True, # 生成的技能默认需审批
"blocked_actions": ["rm -rf", "DROP TABLE", "DELETE WITHOUT WHERE"],
"max_risk_level": "medium",
}
}
skill_dict.update(safety_check)
# 写入待审批队列,而非直接生效
self._save_to_approval_queue(skill_dict)
return skill_dict
提醒:自动生成的技能应该走和手写 Runbook 一样的审批流程,不能因为"自动"就绕过安全网。

图:GEPA 自我进化机制运行前后性能对比,各项指标均有显著提升
指标 | 初始状态 | 运行 1 个月 | 运行 3 个月 | 提升幅度 |
|---|---|---|---|---|
告警自动修复率 | 35% | 58% | 72% | +106% |
方案生成 RT | 4.2s | 2.8s | 1.5s | 降低 64% |
重复故障 MTTR | 45min | 18min | 5min | 降低 89% |
技能库数量 | 0 | 12 | 38 | - |
人工介入率 | 65% | 42% | 28% | 降低 57% |
测试环境:阿里云 ECS 4C8G | PostgreSQL RDS 4C16G | Redis 8G 主从版 | 40+ 服务器集群
GEPA 闭环机制让 AIOps 系统从"被动执行"进化为"主动学习":
适用场景:运维场景多变、需要持续优化响应策略的团队
不适用场景:运维场景高度稳定、规则已充分覆盖的团队
💬 你在 AIOps 系统中用过自我学习机制吗?遇到过哪些坑?欢迎评论区交流~ 💡 下期预告:Hermes Agent vs OpenClaw:2026 年开源运维 Agent 横评,从架构设计、功能对比、性能测试到选型建议全解析。