被普遍忽略的问题:Coding Agent 没有"昨天" 企业里推 Coding Agent 一段时间后,几乎所有落地团队都会撞上同一堵墙:今天的会话里,Agent 和工程师一起做了一个清晰的架构决策、写了一段被审过的核心模块、把一条部署规则讨论完了;明天新开一个会话,Agent 完全不知道这些事发生过。它会重新建议一个不同的架构,会重新写一个功能重复的模块,会重新把那条已经被否掉的方案端出来。
被普遍忽略的问题:Coding Agent 没有"昨天"
企业里推 Coding Agent 一段时间后,几乎所有落地团队都会撞上同一堵墙:今天的会话里,Agent 和工程师一起做了一个清晰的架构决策、写了一段被审过的核心模块、把一条部署规则讨论完了;明天新开一个会话,Agent 完全不知道这些事发生过。它会重新建议一个不同的架构,会重新写一个功能重复的模块,会重新把那条已经被否掉的方案端出来。
这并不是模型不够聪明,而是会话本身没有外延。任何一段会话的上下文窗口都是有限的,窗口一关,Agent 关于这个项目的所有理解都跟着蒸发——架构决策、领域约束、操作规范,这些本该长期沉淀进项目资产的东西,全部跟着会话一起消失了。
过去一年,两种"记忆"方案都撞上了自己的天花板
围绕这个问题,过去一年行业里集中走过两条路,各自撞上了清晰的天花板。第一条是"平铺文件"路线——把 Agent 需要长期记住的事写成一堆 Markdown,塞进项目根目录的 CLAUDE.md、AGENTS.md、.cursorrules 这类指令文件里。这一路线的代表产品是 Claude Code、Cursor、Windsurf、Cline。优势是落地极轻:有文件系统就有这套,Agent 自己用工具读写就行。但随着项目长大,这些指令文件会不可控地膨胀到两万 token 量级,挤占上下文窗口、稀释 Agent 注意力、触发"lost-in-the-middle"注意力失效。
第二条是"向量数据库 + 后台守护"路线——把每一轮对话拆成片段、向量化、丢进专门的存储层,会话时按相似度检索召回。代表产品是 Mem0、Letta、Zep。优势是召回路径理论上更稳。但代价是给 Coding Agent 这种本该轻量级嵌入 IDE 的工具,引入了一整套 Python/Node 重运行时、Docker 容器、私有存储孤岛、外加每次召回 200 到 800 毫秒的额外开销,还有按调用量计费的 embedding 成本。
这两条路线都没有解决 Coding Agent 的实际需要:够轻、够稳、够可审计,而且能跟着项目的 Git 仓库一起被版本管理。
OKF Agent Memory 把"记忆"做成一类新的项目资产
2026 年 9 月初出现的一个新项目,把"Coding Agent 的持久化记忆"这件事重新组织成了一类可治理的项目资产。它没有走上述两条路线,而是把项目自身的 Git 仓库改造成结构化、可自我校验的知识语料库——基于一套名为 OKF(Open Knowledge Format)的开放规范 v0.2。整套实现是一个零依赖的 Go 二进制,启动后内存占用不到 15 MB,冷启动时间在 4 毫秒级。
它的工作方式是:在项目根目录下建一个 knowledge/ 目录,所有需要长期保存的"项目记忆"都以人类可读的 Markdown 文件形式落地,带 YAML frontmatter 元数据、带标签。这些文件本身被 Git 正常追踪——git diff、git blame、code review 这套现有的工程治理工具链直接就能用,审计 Agent 的"记忆"和审计普通代码完全一样。
对 Agent 的接口是一组 MCP 工具:okf_search 用于 BM25 文本检索,okf_show 用于读具体一条,okf_create 用于新增,okf_validate 用于校验。整个搜索是纯内存的 BM25,响应时间在 300 微秒级,不需要 embedding API、不需要网络、不需要专用运行时。
"渐进式披露"为什么是 Coding Agent 的关键
这套设计里最值得花笔墨讲的一点叫 progressive disclosure——不是把整套知识平铺到上下文窗口里,而是 Agent 启动时只加载一份"知识索引",真正需要某条具体概念时再单独把那条拉进上下文。一次检索命中只占约 300 token,而不是把整个知识库一股脑压进去。
这个细节是整个设计能落地的关键:它解决了"平铺文件"路线膨胀的根因——不是 Markdown 不能记,而是把所有 Markdown 同时塞进上下文窗口,模型就注意力失效。渐进式披露把"知识总量"和"上下文用量"解耦:项目记忆可以堆到几十万 token,但单次会话只承担 300 token 的检索命中,Agent 注意力不会被淹没。
对比之下,平铺文件路线做不到这一点的根本原因不是它不想,而是它在协议层没有"索引 vs 全文"的分层——CLAUDE.md 就是被完整加载的;向量数据库路线能做到检索召回,但每次召回的延迟和按次计费的 embedding 成本让它在 Coding Agent 这种高频短会话场景里显得过重。
信任分级:人类规则 vs Agent 草稿,在文件层就要分清
另一项容易被忽略、但实际落地时极其重要的设计是"信任分级"。OKF 把知识库里的每一条都打上来源标记:verified: human:... 表示这是人类写下的"硬规则",比如团队约定的部署流程、不能修改的命名空间、必须保留的接口形态;generated: agent:... 表示这是 Agent 自己从前几轮会话里沉淀出来的版本号草稿,比如"这个项目用了某种特殊的依赖注入写法"。
这个区分为什么关键?因为任何长期记忆系统都会撞上一个共同问题——Agent 自己写的"经验"和人类定的"规则"如果不分开,Agent 在后续会话里会把自己的经验当作规则来遵循,把临时性的工程猜测沉淀成事实性的项目约束,几年下来整个知识库就自我污染了。信任分级在文件层就把这两类内容物理分开,Agent 检索时也能分别按权重处理。
从 Git-native 记忆层看 Coding Agent Harness 的状态延续
把视野拉宽一些。OKF 这类设计的更深一层意义是它改变了 Coding Agent Harness(也就是承载 Agent 的 IDE 客户端、执行循环、工具集成的整套运行环境)的状态设计。
过去的 Harness 状态是"会话内状态"——会话窗口里有什么、Harness 就知道什么;窗口一关,Harness 对项目的理解归零。这相当于 Harness 永远是个新员工,每天入职、从不积累。
而 Git-native 持久化记忆层把 Harness 的状态从"会话内"扩展到了"会话间"——知识库里的每一条都是 Harness 的跨会话记忆,Harness 在任何一个会话里搜一下、调一下,就能把昨天的理解接上。这种状态延续不是通过把对话历史整个保留下来实现的(那样上下文窗口会被淹没),而是通过把对话中"值得长期保留"的那部分沉淀成结构化的项目资产,让 Harness 在每次启动时按需取用。
这相当于把 Harness 从"会话级智能体"重构成了"项目级智能体"——它的工作单位不再是一段会话,而是整个项目周期。这是一种真正意义上的工程新样本,因为它把 Agent 的能力边界从"完成单次任务"推到了"维护一个长期演进的工程产物"。
记忆层的工程新基线:四件不能省
结合 OKF 这类 Git-native 设计的实践,可以把"持久化记忆层"的工程新基线画成四件不能省的事。第一件,知识存储必须跟项目仓库同源——知识文件和代码文件共用 Git 版本管理、共用 diff 工具、共用 code review 流程。理由很直接:如果记忆不跟着代码一起进版本管理,那么工程师在审代码时永远看不到 Agent 在记忆里偷偷改了什么,审计就缺一条腿。
第二件,索引和全文必须分层——会话启动只加载索引,具体概念按需加载 300 token 量级的命中条。理由前面已经讲清楚,这是把"知识总量"和"上下文用量"解耦的唯一办法。
第三件,信任分级必须在文件层就分清——人类规则和 Agent 草稿用不同的 frontmatter 字段分开,Agent 检索时按权重分别处理。理由是任何长期记忆系统都会自我污染,不分级的知识库三年后必然退化成一堆 Agent 自己的工程猜测。
第四件,接口必须走 MCP 这套开放协议——okf_search、okf_show、okf_create、okf_validate 这些工具名要让任何兼容 MCP 的 Coding Agent(Claude Code、Cursor、Windsurf、本地模型驱动的 Agent)都能直接调用。理由是记忆层不应该绑死某一类产品,它是项目级资产,谁用项目就应该谁能调。
为什么 BM25 比 Embedding 更适合 Coding Agent 的记忆检索
这里有一个值得展开的工程取舍:为什么 OKF 选择 BM25,而不是看起来更"现代"的 embedding 检索?回答这个问题需要回到 Coding Agent 检索记忆时的实际需求。
Coding Agent 检索记忆时,大多数场景是在找"某个具体的命名、某个具体的接口形态、某个具体的错误码、某个具体的部署命令"——这些都是字面意义上的精确匹配。BM25 是经典的信息检索算法,在这种字面匹配场景里召回精度远高于 embedding;并且 BM25 的检索成本在 300 微秒级、纯内存、零网络,可以放在 Coding Agent 的热路径上每次工具调用都跑。
Embedding 检索的优势在语义层面——能召回"字面不同但语义相近"的内容。但代价是每次召回都要走一次 embedding 模型推理、产生一次网络或跨进程调用、增加 200 到 800 毫秒延迟、按调用量计费。在 Coding Agent 的高频短会话场景下,这个开销几乎和主 Agent 推理本身的开销相当。
所以取舍很清晰:当你的记忆库主要是项目里的命名、规则、命令、接口、错误码这类"字面确定性高"的内容时,BM25 是更合算的工具;当你的记忆库主要是"用户偏好"这类"语义确定但字面模糊"的内容时,embedding 才有不可替代的价值。OKF 的 BM25 选择,正好对应 Coding Agent 实际需要的检索模式。
从单 Agent 到多 Agent:记忆层在团队协作场景里的下一步
把视野再拉宽一些。Git-native 记忆层的下一阶段价值,在多 Agent 团队协作场景里会进一步显现。一个真实的工程团队里,通常会有多个 Agent 角色同时在工作——一个写代码的 Agent、一个做 code review 的 Agent、一个跑测试的 Agent、一个部署的 Agent。这些 Agent 在会话间互相交接工作时,过去只能靠"把上下文复制粘贴一遍"这种脆弱的做法。
有了 Git-native 记忆层,这些 Agent 可以共享同一份项目知识库——code review Agent 检索"这个项目的命名约定",部署 Agent 检索"这个项目的环境变量清单",它们看到的是同一份被 Git 版本管理的内容。任何一方在某次会话里发现了一条新约束(比如"这个项目的所有外部 API 调用都必须走幂等封装"),只要按 verified: human:... 或 generated: agent:... 的格式新增一条知识,其他 Agent 在下一次会话启动时就能搜到。
这种"知识共享"在过去依赖向量数据库的方案里是脆的——每一方都要跑自己的 embedding 模型、自己的存储后端,数据格式私有,跨 Agent 互通基本只能靠人肉复制。Git-native + Markdown 的好处是:知识本身就是人类可读的,任何 Agent、任何 IDE、任何工程师、任何 code review 工具,都能直接读懂。这是 Git-native 记忆层在长期演化中的真正优势——它把记忆变成了项目级别的公共资产,而不是某一类 Agent 的私有后端。
Harness 状态跨会话延续的三道关
基于上述设计,Coding Agent Harness 的状态要在跨会话延续,必须同时过三道关。第一道关是"沉淀关":Harness 必须能把每一轮会话中"值得长期保留"的部分,按结构化格式落进项目仓库。这要求 Harness 在每轮会话结束时,自动判断"这一轮有没有新东西值得记",有就触发 okf_create 写入知识库;没有就跳过。这一关的工程难点不在写入本身,而在判断"什么值得记"——沉淀太激进会污染知识库,沉淀太保守会漏掉关键经验。
第二道关是"召回关":Harness 必须能在新会话启动时,按当前任务主动从知识库里检索相关条目,而不是等用户问起来。这一关的工程难点在检索策略——按字面匹配、按标签过滤、按时间衰减、按信任分级加权,这些权重怎么分配直接决定了 Harness 在新会话里能不能"接上昨天的理解"。
第三道关是"审计关":Harness 必须能回答"我为什么记得这条"——这条知识是哪一轮会话里沉淀的、是谁写下的、之后被引用过几次、是否被人工 review 过。这一关的工程难点在元数据完整性和 Git 历史的可追溯性——Git-native 设计在这里有天然优势,因为 git log 直接就能给出完整的写入历史。
三道关中任意一道缺失,Harness 的跨会话状态延续就会退化成"看起来接上了、其实已经污染了"的样子。
落地到企业 Coding Agent 项目的三个起步动作
把这套工程基线落到企业的实际 Coding Agent 项目里,可以拆成三个起步动作。第一个动作是盘点现有项目里所有"Agent 应该记住但实际每次都靠人复述"的事——架构决策、命名约定、部署流程、外部接口契约、错误码表。把这些梳理出来,就是知识库的初始种子。
第二个动作是引入 Git-native 持久化记忆层,作为项目仓库的常规资产——knowledge/ 目录进 Git、CI 流程里加 okf_validate、知识库结构本身纳入 code review。短期内先用 BM25 检索解决命名、约定、命令、错误码这类字面确定性高的检索需求。
第三个动作是给 Harness 加沉淀关、召回关、审计关三道闸门——每轮会话结束时自动评估是否有新条目需要写入知识库、新会话启动时按当前任务检索相关条目、每条知识都能追溯到来源会话和来源角色。这三道闸门在第一版不要求做得很精细,但必须从一开始就建——一旦项目长大再补,知识库的污染清理成本会指数级上升。
结语
Coding Agent 的能力在过去两年被显著推前,从"按提示词写一段代码"推到"在 IDE 里持续维护一个项目的演进"。每推前一步,工程侧的支撑基线就必须同步推前一步。把"记忆"做成一个独立的向量数据库后端,这种思路在 2026 年 9 月这次 Git-native 设计的实践之后已经被反复证明不可持续。把记忆做成项目仓库里一类可被 Git 版本管理、可被 code review 审计、可被任何兼容 MCP 的 Agent 共享的常规资产,才是当下能落地的工程基线。
任何企业 Coding Agent 项目,只要涉及会话间的状态延续,工程基线就必须做到这四条——Git-native 知识存储、索引与全文分层、信任分级在文件层分清、MCP 开放接口——否则,今天不是项目知识库的污染,也会是几个月后的污染。