自改进 Agent 是 2025 年到现在最容易被误读的技术方向之一。很多人以为只要把大模型 API 接上工具调用、加一个 Prompt再让 Agent 能保存几轮对话就算是“自改进”了。但真正做过 Agent 工程化的人会告诉你今天的 Agent 最大问题不是模型不够聪明而是它没有履历。它不知道昨天做砸了哪件事不知道哪种策略在什么场景下连续失败过也不知道自己当前的“行为状态”是怎么一步步演化来的。换句话说Agent 缺的是持久化经验而不仅仅是上下文窗口。这篇文章想讲清楚一个判断自改进 Agent 在架构本质上就是一个事件溯源系统。不是“可以借鉴事件溯源”不是“像事件溯源”而是它在数据模型、状态流转、回放回溯、审计回滚这几个层面和事件溯源几乎是同构的。理解这一点你会突然看明白很多 Agent 工程问题为什么经验容易丢、为什么状态永远不一致、为什么没有可回滚的“时光机”、为什么多 Agent 协作这么难。文章会先拆解“自改进 Agent”从热词到工程的三个层次再讲清楚事件溯源Event Sourcing到底解决什么问题然后给出两者的完整映射关系、一套可落地的架构设计以及一个 Python 最小可运行示例。最后是常见坑和工程建议。读完你可以直接把“事件日志 投影 重放 快照”这套思维带回自己的 Agent 项目里。1. 自改进 Agent一个被低估的工程难题“Self-Improving Agents”这几年已经从一个学术概念变成了产品卖点。各家的说法不太一样有的强调 Agent 能从错误中学习有的强调 Agent 能自动优化 Prompt有的强调 Agent 会自己写工具、自己调参数。最新的综述把这类系统按成熟度分了三个层次Self-Improving Agents在一个固定任务范围内Agent 能根据历史反馈调整自己的行为策略。Self-Evolving AgentsAgent 能扩展自己的工具集、技能边界甚至目标空间不只是改回答还能改“自己会做什么”。Meta-Evolving AgentsAgent 能改进自己“改进能力”的方式比如自动设计新的反思策略、自动选择经验复用方案。从这三个层次能看出一条清晰的主线越往上走Agent 越需要一个可靠、可追溯、可重放的历史记录。你不能让 Agent 变得更聪明却不告诉它自己过去经历过什么。问题是现在绝大多数 Agent 框架把“历史”存成了什么聊天记录、向量库、JSON 快照。这些方案有一个共同缺陷它们保存的是结果而不是过程。举一个实际场景。你让一个 Agent 负责生成招聘 JD。第一版它漏掉了岗位亮点你没有直接改代码而是在对话里说“你漏了亮点要加上”。第二次它加上了但是又写得太浮夸。第三次你说“亮点要真实、克制”。第四次它学会了但你又发现它把薪资范围写错了。这个过程里Agent 到底经历了什么如果用聊天记录存储Agent 是“靠当前对话上下文撑着”换一个任务、开一个新会话经验全部丢失。如果用向量库存储你存入的是每一次“修正后的最终结果”而不是“为什么修正”和“修正策略是什么”下次遇到类似问题它只是检索到一段相似文本并不知道这条经验是在什么场景下、因为什么漏洞被沉淀下来的。真正的自改进核心不是“输出变好了”而是行为策略发生了可解释、可追溯、可回滚的变更。这个变更必须是一个事件task_received、task_failed、lesson_learned、policy_updated。如果你把 Agent 的整个生命周期看成一条事件流你会发现它和事件溯源系统里的账本、订单流、状态机变更记录本质上是同一类东西。2. 事件溯源从金融系统到 AI Agent 的架构迁移事件溯源Event Sourcing简称 ES不是新概念。它最早被广泛采用是在金融、账务、订单这类对审计要求极高的系统里。传统开发模式是 CRUD数据库里保存“当前状态”每次修改直接覆盖旧值。订单表里有一行记录状态从“待支付”改成“已支付”你只看到最后的结果中间发生了什么需要靠操作日志去猜。事件溯源换了一种思路不保存当前状态只保存状态变化的事实。每一个事实都是不可变事件只能追加不能修改和删除。当前状态不是存储出来的而是从事件流里“投影”出来的。要理解一个系统为什么变成今天这样只需要回放它的事件流。核心概念有四个事件Event已经发生的、不可撤销的事实。比如OrderPlaced、PaymentReceived。事件名用过去时因为它描述的是过去。事件日志Event Log按顺序追加写入的持久化存储只追加Append-Only通常保证顺序和幂等。投影Projection从事件流推导出读模型或当前状态的机制。读模型可以是数据库表、内存对象、文件也可以是 Agent 的策略文本。快照Snapshot为了不让回放无限长定期把某个时点的状态保存下来下次重建状态时从快照开始再补充增量事件。两个关键特点决定了事件溯源系统的能力边界一是可完全重建。只要事件日志还在系统状态任何时刻都能被还原。二是可审计可回滚。因为事件不可变你可以知道每一次变更的完整上下文因为可以重建历史状态你也随时能回到旧版本。为什么不直接修改状态因为“修改”隐藏了过程而“过程”恰恰是经验、反思和优化的原材料。你只有知道自己从哪一步开始走偏才能知道该优化哪里。这个道理放到 Agent 上完全成立。3. 为什么自改进 Agent 本质上是 Event-Sourced 系统从架构维度看自改进 Agent 和事件溯源系统存在严格的同构映射。事件溯源概念Agent 系统中的对应物作用事件 EventAgent 的一次任务、一次失败、一次反思、一次策略更新记录 Agent 行为过程中发生了什么事件日志 Event LogAgent 行为历史存储比如 JSONL、事件表、Kafka Topic持久化保存 Agent 的全部经历追加写入 Append-OnlyAgent 不能修改已经发生的行为记录保证历史真实防止经验被污染投影 ProjectionAgent 当前策略、当前技能状态、当前向量索引、当前上下文从历史事件推导出“这一刻 Agent 是什么样”重放 Replay复盘历史任务、回放事件流、重建策略让 Agent 从过去经验中恢复状态快照 Snapshot定期保存的 Agent 策略快照、记忆快照避免每次启动都全量回放回滚 Rollback撤销错误策略更新防止一次坏经验永久污染 Agent这个映射不是比喻而是实打实的运行时机制。先看“状态”。一个自改进 Agent 的“状态”是什么是它的系统提示词吗是它的工具列表吗是它的长期记忆向量吗更准确地说Agent 状态应该是一段行为策略遇到什么类型的任务倾向于走哪条路径上次类似任务在哪个环节失败过这次要额外注意什么某个工具在什么条件下不可信。这些策略不会凭空产生它们是历史事件投影出来的结果。再看“自改进循环”。一次完整的自改进通常有四个步骤执行任务产生结果。评估结果判断成功还是失败。反思原因提炼教训。更新策略让下一次行为改变。这四个步骤单独看都不难难在把它们串成一个闭环。事情做砸了评估结果说“失败”反思说“缺少某类信息”然后呢如果这个“然后”不被持久化自改进就断裂了。事件溯源在这里提供的是一个稳定的“然后”把每一次失败、反思、策略更新都作为事件追加到日志里。下一次执行任务前Agent 通过投影机制读取这些事件自动生成当前策略。经验不是临时拼进来的 Prompt而是 Agent 状态的一部分。事件溯源的三个原则对应到 Agent 系统里也完全成立所有行为都有记录。你不能只记成功不记失败不能只记最终答案不记中间过程。失败事件往往是最有价值的反思原料。当前状态永远可以从事件流中重建。Agent 的策略、技能栈、记忆都应该能通过重放事件来恢复。如果你发现“它好像忘了我之前让它改过的话”那说明你的设计没有遵循事件溯源原则。任何改动都可以回滚。策略更新错了怎么办事件溯源给了你一个天然机制回到更新前那个策略事件的投影重新开始。这也是为什么“self-improving agents in the era of experience”这类综述会把收敛方向指向经验系统。当 Agent 的能力已经不是瓶颈经验的可持久化、可复用、可演化就是下一个瓶颈。而事件溯源是当前软件工程里最成熟的经验持久化范式。更稳妥的判断是Agent 的事件溯源不等于把订单系统那套东西原封不动搬过来但它提供了最重要的架构心智——把行为当作数据把经验当作状态把优化当作事件投影。4. 基于事件溯源的自改进 Agent 架构设计基于上面的判断我们可以设计一个真正事件溯源化的自改进 Agent 架构。它不依赖某个特定框架核心是六类组件。4.1 核心组件执行器Executor负责调用大模型、工具、外部 API完成用户任务。它是 Agent 的“手脚”本身不保存长期状态。事件记录器Event Recorder把执行器运行过程中的关键节点转换成事件追加写入事件存储。它负责回答“发生了什么”。事件存储Event Store只追加的存储层。最小时内可以用 JSONL 文件生产环境可以用 PostgreSQL 表、EventStoreDB或者 Kafka 配合对象存储。投影器Projector从事件流生成 Agent 当前状态。常见的投影结果是Agent 当前策略文本How to behave工具使用黑名单Which tool to avoid长期记忆索引What to recall计划模板How to plan反思引擎Reflection Engine周期性或按触发器读取事件流评估最近行为产出教训事件lesson_learned。它负责回答“为什么失败”。策略解析器Policy Resolver在每次执行前把当前策略解析进 Prompt、工具配置和记忆检索范围。它负责回答“Agent 现在是按什么规则在跑”。4.2 一次完整的自改进数据流以“让 Agent 写简历优化建议”为例事件流看起来像这样seq1 event_typetask_received payload{task: 优化这份产品经理简历} seq2 event_typetask_completed payload{output: 简历结构完整建议补充量化结果} seq3 event_typeeval_failed payload{reason: 缺少面试官视角的岗位匹配分析} seq4 event_typelesson_learned payload{suggestion: 简历优化类任务必须增加岗位JD匹配分析} seq5 event_typepolicy_updated payload{policy: 简历优化时先解析目标岗位JD再做匹配度分析}注意seq1 到 seq5 是一条不可变的事件流。第 6 次任务时投影器读取事件重建出策略“简历优化时先解析目标岗位 JD再做匹配度分析”。执行器按这个策略生成 Prompt。如果这次任务又暴露了新问题就继续追加eval_failed、lesson_learned、policy_updated。整个系统对事件流的依赖是硬性的没有事件流Agent 就不是“自改进”的它只是一个“带 Prompt 的 API 调用器”。4.3 事件设计与时态问题Agent 事件在设计时需要带几个关键字段event_id全局唯一用于幂等。agent_id区分不同 Agent 实例防止事件串流。event_type事件类型建议用过去时动词命名。payload事件事实只保存客观数据不保存推导结论。seqAgent 内的递增序号用于顺序重建。timestamp发生时间注意使用 UTC避免时区歧义。version事件结构版本用于未来格式迁移。这里要特别提醒事件只追加不代表不能写“坏事件”。系统里的反思引擎、评估器也可能出错产出错误的lesson_learned。所以事件源系统必须把“记录事件”和“执行策略”分开。策略更新时建议把“旧策略”“新策略”“更新原因”都放进 payload方便审计和回滚。5. 最小可运行示例事件驱动的自改进 Agent理论讲了很多现在用一个最小 Python 示例跑通“任务执行 → 失败评估 → 教训沉淀 → 策略更新 → 下次改进”的完整闭环。示例不依赖任何第三方库只用 Python 标准库便于你理解事件溯源如何驱动 Agent 行为变化。5.1 环境准备Python 3.10 及以上。不需要安装额外依赖。目录结构如下event_sourced_agent/ ├── agent.py # 主程序 ├── event_store.py # 事件模型与存储 └── demo_events.jsonl # 运行后生成的事件日志5.2 事件模型与事件存储文件路径event_store.py# file: event_store.py import json import uuid from datetime import datetime, timezone from pathlib import Path class AgentEvent: Agent 领域事件只追加不可修改。 def __init__(self, agent_id, event_type, payload, event_idNone, seq0, timestampNone): self.event_id event_id or str(uuid.uuid4()) self.agent_id agent_id self.event_type event_type self.payload payload self.seq seq self.timestamp timestamp or datetime.now(timezone.utc).isoformat() def to_json(self): return json.dumps( { event_id: self.event_id, agent_id: self.agent_id, event_type: self.event_type, payload: self.payload, seq: self.seq, timestamp: self.timestamp, }, ensure_asciiFalse, ) classmethod def from_json(cls, line): data json.loads(line) return cls( agent_iddata[agent_id], event_typedata[event_type], payloaddata[payload], event_iddata[event_id], seqdata[seq], timestampdata[timestamp], ) class JsonlEventStore: 基于 JSONL 的只追加事件存储适用于教学和小型实验。 def __init__(self, path: str demo_events.jsonl): self.path Path(path) self.path.touch(exist_okTrue) def append(self, agent_id: str, event_type: str, payload: dict) - AgentEvent: # 计算出该 agent 下一条事件的 seq seq self.next_seq(agent_id) event AgentEvent(agent_idagent_id, event_typeevent_type, payloadpayload, seqseq) with self.path.open(a, encodingutf-8) as f: f.write(event.to_json() \n) return event def read_events(self, agent_id: str): 按 seq 升序返回该 agent 的全部事件。 events [] with self.path.open(r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue event AgentEvent.from_json(line) if event.agent_id agent_id: events.append(event) events.sort(keylambda e: e.seq) return events def next_seq(self, agent_id: str) - int: events self.read_events(agent_id) return (events[-1].seq 1) if events else 1这里把AgentEvent设计成不可变对象JsonlEventStore只提供append和read_events没有update和delete。这就是事件溯源里最核心的“只追加”纪律。如果把read_events返回的列表直接修改再写回就破坏了事件日志的不可变性整个自改进机制就失去了可信基础。5.3 自改进 Agent 主循环文件路径agent.py# file: agent.py from event_store import JsonlEventStore def rule_based_llm(prompt: str) - str: 教学示例用的模拟大模型 它没有真实推理能力只会根据 Prompt 中是否出现“事件溯源”关键词来决定输出。 真实项目中请替换为对大模型 API 的调用。 if 事件溯源 in prompt: return 好的我理解了要使用事件溯源来记录 Agent 经验。 return 我完成了任务但没有特别说明。 class SelfImprovingAgent: def __init__(self, agent_id: str, store: JsonlEventStore, llm_call): self.agent_id agent_id self.store store self.llm_call llm_call # 启动时通过投影事件流重建当前策略 self.policy self._rebuild_policy() def _rebuild_policy(self) - str: 投影逻辑从事件流中重建 Agent 当前策略。 这里不修改历史事件只读取最后一个 policy_updated 事件。 events self.store.read_events(self.agent_id) policy_events [e for e in events if e.event_type policy_updated] if not policy_events: return 你是默认助手尽量给出准确、可验证的回答。 return policy_events[-1].payload[policy] def run(self, task: str) - str: 执行任务并记录事件。 self.store.append(self.agent_id, task_received, {task: task}) prompt f{self.policy}\n\n任务{task} output self.llm_call(prompt) self.store.append(self.agent_id, task_completed, {task: task, output: output}) return output def reflect(self, task: str, output: str, expected_fragment: str): 反思逻辑如果任务要求包含关键信息但输出中没有则记录教训并更新策略。 真实项目中这里可以换成基于 LLM 的自动评估器也可以请人工审核后触发。 if expected_fragment and expected_fragment not in output: suggestion f当任务涉及「{expected_fragment}」时必须明确提到该关键词。 # 教训事件保存反思结论 self.store.append( self.agent_id, lesson_learned, {task: task, output: output, suggestion: suggestion}, ) # 策略更新事件追加新策略 self.policy self.policy \n suggestion self.store.append( self.agent_id, policy_updated, {policy: self.policy, reason: suggestion}, ) return suggestion return None if __name__ __main__: store JsonlEventStore(demo_events.jsonl) agent SelfImprovingAgent(agent-001, store, rule_based_llm) for i in range(2): task 请说明 Agent 经验记录最合适的架构。 output agent.run(task) print(f第 {i 1} 轮输出{output}) reflection agent.reflect(task, output, expected_fragment事件溯源) if reflection: print(f反思完成策略已更新{reflection}) else: print(本轮无需更新策略) print(\n最终策略) print(agent.policy) print(\n事件流水) for e in store.read_events(agent-001): print(f[seq{e.seq}] type{e.event_type} payload{e.payload})代码里最值得注意的地方是_rebuild_policy和reflect的组合。_rebuild_policy是投影它读事件流生成当前策略reflect是反思它把lesson_learned事件和policy_updated事件追加进日志。Agent 的“自改进”不是靠硬改某个全局变量而是靠追加新事件让下次投影产生新策略。这正是事件溯源系统的状态演化方式。5.4 运行脚本在event_sourced_agent目录下执行python agent.py预期输出如下第 1 轮输出我完成了任务但没有特别说明。 反思完成策略已更新当任务涉及「事件溯源」时必须明确提到该关键词。 第 2 轮输出好的我理解了要使用事件溯源来记录 Agent 经验。 本轮无需更新策略 最终策略 你是默认助手尽量给出准确、可验证的回答。 当任务涉及「事件溯源」时必须明确提到该关键词。 事件流水 [seq1] typetask_received payload{task: 请说明 Agent 经验记录最合适的架构。} [seq2] typetask_completed payload{task: 请说明 Agent 经验记录最合适的架构。, output: 我完成了任务但没有特别说明。} [seq3] typelesson_learned payload{task: 请说明 Agent 经验记录最合适的架构。, output: 我完成了任务但没有特别说明。, suggestion: 当任务涉及「事件溯源」时必须明确提到该关键词。} [seq4] typepolicy_updated payload{policy: 你是默认助手尽量给出准确、可验证的回答。\n当任务涉及「事件溯源」时必须明确提到该关键词。, reason: 当任务涉及「事件溯源」时必须明确提到该关键词。} [seq5] typetask_received payload{task: 请说明 Agent 经验记录最合适的架构。} [seq6] typetask_completed payload{task: 请说明 Agent 经验记录最合适的架构。, output: 好的我理解了要使用事件溯源来记录 Agent 经验。}第一次运行时策略里没有“事件溯源”教训模拟 LLM 给出了一个不含关键词的回答。反思引擎检测到问题追加了lesson_learned和policy_updated事件。第二次运行时_rebuild_policy从事件流中读到了新策略Prompt 里包含了要提到的关键词模拟 LLM 因此给出了正确回答。Agent 的行为策略确实因为事件流发生了变化而且这个过程完整记录在demo_events.jsonl里。6. 运行结果与效果验证怎么判断这个场景是否“真正”验证了事件溯源驱动自改进第一看策略是否来自事件重建。把demo_events.jsonl删除重新运行python agent.py最终策略会回到默认状态因为没有可投影的事件。这说明 Agent 的状态完全由事件流派生这是事件溯源系统的标志性特征。第二看事件是否只追加。运行结束后打开demo_events.jsonl检查seq是否严格递增事件是否没有被修改。如果删除其中某条policy_updated事件再运行代码Agent 会丢失那次策略更新这说明行为状态依赖事件完整性。第三看能否回滚。把demo_events.jsonl中最后一条policy_updated事件所在的文件恢复到旧版本重启 Agent策略会回到更新前。这个特性在真实生产环境里非常有用——一次坏策略污染行为时你可以只回滚到出问题前的事件快照而不需要重训模型或重写代码。如果输出和预期不一致优先检查事件存储路径。Python 的JsonlEventStore默认写demo_events.jsonl如果脚本和工作目录不一致事件会被写到别的位置导致读不到历史。运行前可以打印Path(demo_events.jsonl).resolve()确认路径。7. 常见问题与排查思路问题现象可能原因排查方式解决方案事件文件越来越大启动越来越慢事件日志全量重放缺少快照查看read_events返回的事件总数定期持久化策略快照投影时从快照加增量事件恢复策略更新不生效投影逻辑读错了事件类型或位置检查_rebuild_policy中policy_updated过滤逻辑确保只取最后一个policy_updated事件并校验seq反思循环震荡策略反复追加冲突内容多条lesson_learned互相矛盾打印历史lesson_learned事件查冲突增加策略合并逻辑或引入人工审批环节多 Agent 事件串流agent_id过滤不严检查read_events是否按agent_id过滤所有读接口强制按agent_id 聚合 ID 隔离历史事件格式变了老日志解析失败事件结构没有版本字段查看from_json抛出的异常给事件增加version字段写迁移脚本生产环境事件存储性能不足JSONL 不适合高并发写入用压测工具看写入吞吐切换 PostgreSQL 或专用事件存储并做批量写入真实项目中最常被忽略的是事件结构演进。AI 项目迭代速度快你今天设计的lesson_learnedpayload 结构三个月后可能想加一个confidence字段。老的 JSONL 事件没有这个字段from_json一旦按强字段解析就会失败。更稳妥的做法是从第一天就给事件加version字段解析时根据版本做兼容处理。8. 最佳实践与工程建议8.1 事件命名和字段设计事件类型用过去时短语例如TaskReceived、TaskCompleted、LessonLearned、PolicyUpdated。Payload 里只保存事实不保存“还没有发生的判断”。比如eval_failed事件里应该记录评估指标和失败原因而不是记录“下一步应该怎么办”——那是policy_updated事件该承载的内容。8.2 快照策略事件日志无限增长是必然的。生产环境建议每 N 次policy_updated或在事件量达到阈值时把当前策略、记忆索引、技能清单打成快照。投影器优先从快照恢复然后只回放快照点之后的事件。快照本身也应该以一个事件类型如SnapshotCreated写入事件日志保持快照与事件流的一致性。8.3 反思与策略更新的安全边界自改进 Agent 的边界原则是Agent 可以记录事件但策略变更必须有约束。生产中建议让反思引擎先产出建议事件lesson_learned策略更新事件policy_updated可以由人工审核后写入或者由规则引擎校验通过后自动写入。不要允许 LLM 直接修改自己的系统 Prompt 文件。更好的做法是把策略放在独立存储中Agent 运行时只读取投影结果。更安全的做法是引入“策略版本”概念。每次policy_updated都生成一个新的 policy 版本旧版本保留在事件流里。上线后如果发现某条策略导致行为明显恶化可以立即切换到上一个版本。8.4 事件存储的选型教学和小型实验JSONL、SQLite 足够重点理解投影和追加语义。中等规模PostgreSQL 专门建事件表配合event_id唯一约束和(agent_id, seq)联合索引。高吞吐生产Kafka 做事件通道对象存储做长期归档另建投影库供查询。不管选哪个都要保证“只追加”纪律。你不能随手UPDATE一条历史事件否则经验的可信度就崩了。8.5 监控指标自改进 Agent 上线后建议至少监控以下指标event_growth_rate事件增长速度评估日志开销。policy_update_frequency策略更新频率过高说明反思引擎不稳定过低说明 Agent 没有在学习。task_success_rate任务成功率随策略更新的变化曲线。rollback_count策略回滚次数评估经验质量。projection_time一次状态重建耗时评估快照策略是否合理。对比优化前后要有明确基线。不要凭感受说“Agent 变聪明了”用同一组评测任务在不同策略版本下的成功率说话。8.6 多 Agent 与协作场景多 Agent 协作时每个 Agent 拥有独立的agent_id事件流共享的经验可以通过事件复制机制广播。一个 Agent 在实践中提炼出的lesson_learned可以转换成另一个 Agent 的初始策略事件。这就是“经验时代”的雏形Agent 不再是独立的个体而是一个由经验事件连接起来的系统。但要注意跨 Agent 经验复制必须保留来源agent_id否则出现策略冲突时无法追踪污染源头。9. 总结与后续学习方向回到开头那个判断自改进 Agent 本质上就是事件溯源系统。这个视角在工程上的价值非常直接——它把“怎么让 Agent 变聪明”这个模糊问题变成了“怎么设计好 Agent 事件流”这个具体问题。当你理解这一点以后再看自改进 Agent 领域里的各种方案会发现它们都在解决事件溯源早就解决过的问题如何保证事件顺序、如何做投影、如何做快照、如何回滚、如何审计。建议你下一步做两件事。第一把这篇的示例代码跑通然后尝试给它加上快照功能、策略冲突检测和策略回滚。跑通之后再思考一个问题如果真实环境里把rule_based_llm换成一个真实大模型事件溯源架构里哪个环节最容易被破坏答案大概率是评估器和反思引擎——它们生成的lesson_learned事件质量决定了整个自改进循环的迭代方向。第二去读关于 “Self-Improving Agents in the Era of Experience” 的相关综述把 self-improving、self-evolving 和 meta-evolving 三个层次放到事件溯源框架里对比。你会发现从 self-improving 到 meta-evolving 的演进本质上是 Agent 事件流从“记录行为”扩展到“记录改进行为的行为”。架构上仍然是那个简单法则一切皆事件状态皆投影经验可重放。Event-Sourced 不是一个只属于后端的持久化技巧它是 Agent 工程化绕不开的基本功。把 Agent 的事件日志当作核心资产来设计比纠结下一个大模型有多强更重要。建议把这篇文章收藏起来等你在自己的 Agent 项目里遇到“经验存不下来、状态对不上、改了回不去”这几个问题时再回来对照一遍。