选题描述里所提到的「MemoBase」这一具体文件格式名称,在本任务可触达的一手信源中尚未找到来自发布方的正式规范或白皮书披露。本文围绕「Agent 状态被设计成文件格式」这一类工程方向,结合 Anthropic 在 2024-11 开源的 Model Context Protocol 里关于 Resources 原语的工程定义,以及 docmancer 在 Glama 自描述里给出的 canon

选题描述里所提到的「MemoBase」这一具体文件格式名称,在本任务可触达的一手信源中尚未找到来自发布方的正式规范或白皮书披露。本文围绕「Agent 状态被设计成文件格式」这一类工程方向,结合 Anthropic 在 2024-11 开源的 Model Context Protocol 里关于 Resources 原语的工程定义,以及 docmancer 在 Glama 自描述里给出的 canonical Markdown tree 工程范式,做一次通用格式设计思路的复盘;若读者希望了解 MemoBase 的具体规范,请回到发布方页面核实后再做判断。

把 Agent 状态设计成文件格式这件事,在 2026 年的工程社区里已经走过了从「实验性尝试」到「标准范式」的演进。早期的 Coding Agent 一般把内存存在 SQLite 或 JSON 文件里,内存结构与 Agent 客户端实现强耦合,跨客户端迁移代价极高;后来的 MCP Memory 类项目开始把内存抽象成 Tools / Resources / Prompts 三类原语,通过协议层标准化内存接口;再往后,以 docmancer 为代表的 Git 原生内存方案,把内存直接落到 Markdown 文件 + Git 仓库,让内存从「客户端私有」变成「客户端可共享」。MemoBase 这类「Agent 内存被设计成文件格式」的思路,正是这条演进路径的最新形态——把 Agent 状态用一种通用、人类可读、版本化友好的文件格式序列化。

Anthropic 在 2024-11-25 发布的《Introducing the Model Context Protocol》里给出了 MCP 的核心定义:MCP addresses this challenge. It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. The result is a simpler, more reliable way to give AI systems access to the data they need. 把这条原则映射到 Agent 状态序列化场景,意味着任何 Agent 内存格式都应当满足四条基本属性:协议层中立(不绑定某个特定 Agent 客户端)、人类可读(开发者可以打开文件肉眼查看)、版本化友好(与 Git 等版本控制系统天然兼容)、可跨会话迁移(从 A 客户端迁移到 B 客户端不需要复杂转换)。这四条属性是 MemoBase 这类格式的设计目标。

把视线从协议层拉到「Agent 状态序列化」的具体内容,可以拆成五类核心要素。第一类是「会话上下文」:Agent 在某次会话里的对话历史、用户消息、工具调用记录、模型思考日志;这是 Agent 状态里最大、最敏感、最容易被截断的部分。第二类是「长期记忆」:Agent 在多次会话里累积的事实性记忆(用户偏好、项目规约、命名风格);这是 MemoBase 格式区别于普通日志格式的关键部分。第三类是「任务状态」:Agent 正在执行的某个跨会话任务(例如「重写购物车模块」)的当前进度、下一步计划、依赖资源。第四类是「工具与凭证引用」:Agent 在执行任务时挂载的工具与凭证(指向真实存储,而非内嵌在状态里)。第五类是「元数据」:Agent 客户端版本、模型版本、序列化版本、创建时间、最后修改时间、所有者。这一类元数据是 Agent 状态在不同会话间迁移时保持兼容性的关键。

把视线从状态要素拉到序列化格式的具体设计选择,可以提炼出四条独立工程决策。第一条是「文本 vs 二进制」:文本格式(类似 JSON / YAML / Markdown)可读性高、可与 Git 兼容、diff 友好,但体积大、解析慢;二进制格式(MessagePack / Protocol Buffers / FlatBuffers)体积小、解析快,但人类不可读、diff 不友好。MemoBase 这类面向跨会话持久化的格式,通常偏向文本——可读性比体积更重要。第二条是「结构化 vs 半结构化」:完全结构化的 JSON Schema 易于校验但灵活性差,半结构化的 Markdown + Front Matter 在校验与灵活性之间取平衡。docmancer 走的就是半结构化路径,Glama 自描述里给出的 combines them into one canonical Markdown tree, serves grounded, cited recall 也对应这一选择。第三条是「分文件 vs 单文件」:单文件简单但体积膨胀后不可维护,分文件(按会话、按记忆类型、按任务)灵活但跨文件操作复杂。第四条是「加密 vs 明文」:Agent 状态里可能包含敏感信息(凭证、用户隐私),但全加密会让版本化与协作失效;部分加密(只加密凭证段)是一个常见折中方案。

把视线从工程决策拉到「跨会话状态序列化」的工程挑战,可以提炼出四类典型难题。第一类是「格式版本兼容」:Agent 客户端升级后,新格式必须能读取旧格式的 MemoBase 文件;这要求格式自带明确的版本号与升级路径。第二类是「跨客户端一致」:同一份 MemoBase 文件在 Claude Code / Cursor / Continue 等不同 Agent 客户端上读到的内容必须一致;这要求格式不依赖任何客户端私有扩展。第三类是「大规模场景下的可维护性」:Agent 在长期使用后状态文件可能膨胀到 MB / GB 级别,这时单文件可读性优势消失,需要拆分成多文件 + 索引文件。第四类是「协作场景下的并发写入」:多个 Agent 同时修改同一份 MemoBase 文件时,如何避免冲突?这要求格式天然支持 Git 等版本控制系统的合并算法,或者自带显式的锁机制。这四类难题里,前两类是「格式设计」问题,后两类是「工程基础设施」问题。

MemoBase 这类 Agent 状态文件格式与 Anthropic containment 报告里强调的五道防线有直接关系。第一道「网络层隔离」对应的是 Agent 状态文件的存储路径必须显式白名单化,任何 Agent 都不能把状态写到白名单之外的位置;这一条把 Agent 状态从「任意文件路径」收窄到「受控目录」。第二道「身份层隔离」对应的是 Agent 状态文件的所有权应当归属到 Agent 自身的 UID,与人类用户文件隔离。第三道「供应链层隔离」对应的是任何能读写 Agent 状态文件的 MCP 工具必须先注册到白名单。第四道「运行时监控」对应的是 Agent 状态文件的每一次读写都应当写入审计日志,并对异常事件(如状态文件大小超过 100MB、状态文件路径不在白名单内、状态文件版本号倒退)实时告警。第五道「模型层自觉」对应的是 Agent 在被告知「我可能正在被注入伪造状态」时主动停止并向人类求助。这五条防线让 MemoBase 这类格式不只是「序列化」,而是「可控序列化」。

把视线从格式与防线的对位拉到企业落地路径。一个严肃的「Agent 状态文件格式」项目,在企业落地时通常会走四步流程。第一步是「格式基线」:在企业内部定义一套 MemoBase-like 的状态格式规范,覆盖会话、长期记忆、任务状态、工具引用、元数据五类核心要素;这一步通常需要 200-500 行 Markdown / YAML 描述。第二步是「读写 SDK」:为 Claude Code / Cursor / Continue 等每种 Agent 客户端实现一个读写 SDK,负责把客户端私有状态转成统一格式;这一步通常需要 1000-3000 行 Python / TypeScript 代码。第三步是「存储与版本管理」:把状态文件存到企业内部 Git 仓库(可以是 Gitea / GitLab Self-Hosted),所有读写都通过 Git 操作;这一步与 docmancer 给出的 canonical Markdown tree 思路完全一致。第四步是「审计与告警」:把状态文件的读写接入企业 SOC,与现有的人员身份、设备指纹、网络出口审计打通。这四步走完,Agent 状态序列化就能从「客户端私有」升级到「企业可控」。

把视线从企业落地拉回到 Agent 工程的整体趋势。2026 年的 Agent 内存讨论里,有一个反复出现但很少被明说的判断:Agent 状态序列化的工程难度,远高于 Agent 状态本身的存在。状态本身只是「一段 JSON」,序列化则是「协议中立 + 人类可读 + 版本化友好 + 跨会话迁移 + 加密平衡 + 格式版本兼容 + 跨客户端一致 + 大规模可维护 + 并发写入」九层工程叠加,任何一层失守,前面八层全部白做。docmancer 在 Glama 自描述里给出的 canonical Markdown tree 与 grounded cited recall,正是这九层里「人类可读 + 版本化友好 + 跨会话迁移」三层的工程落地;MemoBase 这类新格式在这一坐标里扮演的角色,应当是「把所有九层一次性打包解决」。下一阶段的 Agent 内存工程,会越来越围绕「统一格式规范 + 跨客户端 SDK + Git 原生存储 + 企业审计告警」这四个轴心展开;MemoBase 这类格式的设计范式,会沿着这一框架被反复实践。

最后回到工程基线本身。Agent 状态文件格式的真正意义,从来不是格式本身多优雅、字段多么丰富,而是把 Agent 状态从客户端私有的「黑盒日志」转成企业可控的「通用资产」。把 Agent 状态存在客户端私有 SQLite / JSON 文件里,等于把 Agent 的所有记忆都锁死在客户端;一旦客户端被卸载、设备丢失、版本升级失败,Agent 的长期记忆就全部丢失——这是任何严肃 Agent 项目都无法承受的风险。MemoBase 这类格式的真正价值,正是给 Agent 状态一个可移植、可审计、可协作、可版本化的「通用容器」——这是 Agent 内存工程在 2026 年被重新定义的核心价值。