LLM

这篇文章只讲一件事：怎么真的把 Agent 自改进搭出来。 不是论文综述，而是一条从采集、反思、归纳、激活到注入的完整工程路径，附带八条不可破坏的红线、一个真实的静默故障，以及从零复现的最小清单。 内容融合了公开研究范式与某企业级实现的真实工程经验（已做匿名化与通用化处理，不指向任何具体系统）。文末附参考资料与事实核查说明。 一、先说清楚：什么才叫「自改进」 我们对工具有一个朴素期待：越用越好用。 但今天绝大多数 Agent 不是这样。你用了三个月的 Agent，和第一天用它，感觉差不多。它不记得上周你纠正过它三次的同一个错误，不记得哪条路走过是死胡同。每次对话都像重新认识。 自改进要解决的就是这件事，一句话概括： 让 Agent 把「这次是怎么做成 / 做砸的」变成下次的先验。 Warp 团队把这个问题的根因说得更精准——反馈是无状态的（stateless）：会话结束后，人给 Agent 的反馈就消失了，那些最关键的上下文被直接踢出了 agentic loop。 他们还给出了一个很传神的症状描述：「80% 正确」陷阱。一次性写好的 prompt 能把任务做对约 80%，但剩下的 20% 会产生大量噪音，体验反而很差。而靠人工不断重写 prompt 来补那 20%，根本无法规模化。 它是一个闭环，六步： 图 1：六步闭环。注意三种颜色的分工——运行/留痕/注入在在线路径，反思/归纳在离线路径，而激活是人在环的显式决策。这个分工是整套架构最重要的决定。 学术上这个闭环被抽象为四个要素：System Inputs / Agent System / Environment / Optimiser（综述 arXiv:2508.07407）。你要优化的是前两者，信号来自环境，而"反思器"就是那个 Optimiser。 先划清一条边界，避免一开始就跑偏： 这是自改进 这不是自改进 沉淀「这类任务该先查再答」这样的方法论 记住「用户叫张三、住北京」这样的用户事实 经验归 Agent，跨用户复用 用户画像、个性化人设 提炼可复用的规则 把原始日志堆进 prompt 经验归 Agent，不归用户——这是最容易做错也最关键的一条立场，第四节第 1 步会详细展开为什么。 二、第一性问题：改什么？ 自改进不是一个动作，而是四个不同层级的动作。选错层级，项目基本就废了。 图 2：四层选型。越往上能力上限越高，但风险、成本和不可逆性也越高。 层级 改什么 代表工作 见效 风险 回滚 L1 上下文/经验 prompt、memory、经验手册、Skill 文件 ACE、ExpeL、Reflexion、GEPA；工业界：Warp 快 低 改一行文本 L2 技能/工具 技能库、自建工具 Voyager、SkillOpt 中 中 删掉技能 L3 架构/工作流 拓扑、节点，甚至自改代码 ADAS、Darwin Gödel Machine、AWM 慢 高 难 L4 权重 SFT / RL / 蒸馏 SEAL 慢且贵 高 需重训 结论很明确：绝大多数团队应该只做 L1，而且应该先只做 L1。 ...

一份关于 LLM Wiki 知识编译范式的完整学习文档。涵盖它是什么、思想起源、三层架构、三大操作、工程化落地、以及适用边界。 本文融合了 Karpathy 原始范式的公开资料与一套企业级 LLM Wiki 系统的真实工程实现（已做通用化脱敏）。文末附参考资料与事实核查说明。 一、一句话理解 LLM Wiki LLM Wiki 是一个「知识编译器」：它把杂乱的原始资料（raw）当作源代码，用一个受严格提示词约束的 LLM Agent 作为编译器，产出结构化、相互链接、可持续增量更新的知识库产物（wiki/docs），最后可发布到团队平台供人阅读。 用 Karpathy 本人的类比： “Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。” “LLM 是作者，人是主编。” 人负责机器做不好的事——策展（挑选高质量来源）、探索（决定研究方向）、提问（提出好问题）；LLM 负责那些"无人愿做、成本极低"的繁重簿记：总结、建立交叉引用、归档、记录变更。 二、核心洞察：编译知识，而非检索知识 这是整套范式的灵魂。 如果你用 RAG 搭过知识库，多半有过这种别扭感：明明是同一批文档，用户每问一次，系统就要重新检索、重新塞进上下文、让模型重新"读懂"一遍。答案用完即弃，下一次从零再来。 Karpathy 用一个精准的类比点破了这件事的荒谬： 这就像每次运行程序都重新解释一遍源代码，而不是先把它编译好。 RAG 是解释型语言，LLM Wiki 是编译型语言。 两种范式在"知识何时被处理"这件事上，存在根本分歧： 图 1：RAG 在「查询时」反复现读、不积累；LLM Wiki 在「摄取时」编译一次、之后反复复用并自我生长。 维度 传统 RAG（解释型） LLM Wiki（编译型） 知识处理时机 查询时——每次提问都重来 摄取时——每个源只处理一次 是否积累 不积累，每次从零"重新发现" 随每个源和每次查询复利增长 算力/Token 每次都加载大量原始文档 读索引即可导航，Token 大幅下降 基础设施 向量数据库、embedding 管道 零基础设施，纯 Markdown + Git 可读性 chunk 碎片，人难以直接阅读 人类可读的 wiki，可直接编辑、可 diff 矛盾与缺口 难以显式追踪 元数据里显式记录矛盾与待解问题 维护者 系统（黑盒） LLM（透明、有据可查） ⚠️ 预防针：社区里流传"Token 减少约 95%、比 RAG 高效约 70 倍"之类的说法，这些数字来自个别实践者的估算，并非严格基准测试，请当作"方向性直觉"而非"性能承诺"。 ...