Agent 记忆作为文件格式:跨工具互通协议正在成为工程新基线·企业级AI Agent智能体开发-XFPENG

2026 年 9 月,Y Combinator W26 批次出了一家叫 Skillsync 的创业公司,做的事是把 AI 编程助手的会话跨工具搬运——从 Claude Code 搬到 Codex,从 Cursor 搬到 Claude,中间连同消息、推理、工具调用一起转,目标是从中断点继续。同期,HN 上另一些项目正在尝试另一件事:把 AGENTS.md 这种已经被 6 万多个仓库采纳的事实标准,从"被 Agent 读来作为上下文"推进到"被基础设施执行"。再早一些,做 Harness Engineering 的 AgentProto 项目已经在尝试给基于 markdown 的 Agent 规范定义一套可互操作的基元,提议像以太坊当年推出 EIP 那样,把 SKILL.md、DESIGN.md、IDENTITY.md 这些散乱的扩展收编到一套通用接口里。三件事合在一起,构成 2026 年下半年 Agent 工程化最值得关注的一条主线:Agent 的记忆正在变成一种文件格式,围绕它的互通协议正在成为新的工程基线。

这条主线之所以重要,是因为过去两年 AI 编程助手的快速演进留下了一个巨大的债:每个 Agent 都有自己的会话格式、自己的 SKILL.md 变体、自己的 memory store,数据可以本地存储但不能互通,工程师对工具的依赖与对工具里沉淀的"上下文资产"被悄悄绑定在一起。直到要离开的那个瞬间——订阅涨价、模型下线、Agent 厂商被并购——才意识到自己几个月的会话被困在只有那个工具能读的格式里,迁移成本与"重做"无异。这正是 Skillsync、AgentMD、AgentProto 三家在不同层面动手的根本动机。

Skillsync:Agent 会话作为可移植单元

Skillsync 由 Nars 和 Nishant 在 YC W26 启动,核心定位是把 Agent 会话做成可移植单元。两位创始人在创业前的开源支付编排项目在 GitHub 上拿到了 3 万多颗星,做的事是让商户在不同支付处理器之间路由、避免被单一供应商锁定。进了 YC 之后他们想做别的事,但越深入使用 AI 编程助手,越觉得这是同一个问题从另一面又出现了:你的上下文被锁在你最初打开的那个 Agent 里,因为每个 Agent 用不同的方式存会话,这些东西根本无法迁移。

Skillsync 做的事是充当通用转换器——把整个会话连同所有消息、推理、工具调用一起搬过去,让用户能从中断点继续。它把所有会话集中到同一个地方,变得可搜索;它拆出每个会话到底在承载什么,包括到底加载了哪些 SKILL,让过时的上下文变得容易发现;它支持创建共享工作区,在团队里同步会话,让团队可以搭建闭环系统。整套本地优先,只在主动分享到工作区时才离开本机。

核心是一个叫 txcript 的开源 Rust 引擎,把一个 Agent 的磁盘会话格式翻译成另一个 Agent 的格式,映射会话、推理、工具历史。可以把它想成 ffmpeg 或者 pandoc,但是给 Agent 会话用的。在引擎之上是本地优先的桌面应用:Agent 会话通常分散在不同工具各自的文件夹里,用人类读不懂的格式存储,这个应用把它们集中起来,用能读懂的 UI 呈现对话、推理、工具调用,让你能回看发生了什么、把会话搬到另一个 Agent、或者跟同事分享。

更关键的是 Skill 与 memory 的存储形式:被存为可移植的、人类可读的、用户自己拥有的 markdown,通过 MCP 暴露给任何 Agent 用于搜索与按需检索。会话翻译完全在本机跑,只有用户主动分享到团队工作区的内容才会离开。这套架构的核心命题是:会话一旦可移植,它就不再是一次性日志,而是真正能被构建起来的东西——你能看到自己工作方式的模式,把会话交接给同事,让非技术同事接上工程师留下的进度。会话正是协作的最小单元,而现在它正在被扔掉。

已经被大家看到的使用场景

从 Skillsync 团队观察到的用户使用模式,有几类最常见。第一类是会话在 Claude Code、Codex、Cursor 之间中段迁移——尤其是当一家到达使用上限、想用另一家继续时。第二类是在浏览器里的 Claude Chat 里先思考一个问题,然后把整条对话交给 Claude Code 或 Codex 去落地实现。第三类是团队内部的研究会话共享:每个人都把自己的会话上传,这样同事以及同事的 Agent 就能基于彼此的工作继续推进,而不是每个人重做一遍同样的研究。这三类场景共同指向一个事实:在 Agent 已经是日常生产工具的现实里,会话不是日志,是团队知识资产;不能搬运这件事本身,就是知识资产的折旧。

AGENTS.md:6 万仓库的事实标准,正在向"可执行"演进

AGENTS.md 是当下 AI 编程工具的事实标准——超过 6 万个仓库用 Cursor、Codex 等工具接受它作为 Agent 的项目说明。早期它只是被 Agent 读来作为上下文,告诉 Agent 这个项目用什么命令构建、怎么测试、lint 是什么。2026 年 2 月 HN 上出现了一个叫 AgentMD 的项目,把这件事往前推了一步:它解析、校验并执行 AGENTS.md 文件,跑它描述的构建、测试、lint 命令,同时内嵌护栏和治理。具体能力包括解析与校验 AGENTS.md(YAML frontmatter、章节、命令)、沙箱化执行(默认拦截危险模式)、提供执行历史、成功率、ROI 指标的 dashboard,以及 GitHub App、Slack 审批、对敏感操作的人工兜底。

AgentMD 的产品形态有两层:开源核心采用 MIT 协议,云端 dashboard 给团队用。它代表了一个清晰的趋势——AGENTS.md 不再只是文档,它正在变成可执行规范,工程师写完一次,基础设施就可以反复调用、监控、审批、审计。这件事的工业意义在于:把 Agent 的项目知识从"自然语言描述"提到"机器可解析 + 机器可执行",才能让大团队真正把 AI 编程工具规模化使用,而不只是让每个工程师在自己的角落里凭直觉写 markdown。

AgentProto:Harness Engineering 与 .MD 规范的标准化呼吁

另一条线来自 AgentProto 的 Jérémy,他观察到 2026 年 Agent 生态的 markdown 规范正在以每周一个的频率出现——SKILL.md、DESIGN.md、COMPANY.md、BRAIN.md、SOUL.md,一个比一个新,长得都差不多,但实现方式各自不同。他把这种状态类比成以太坊早年还没有 ERC 的时候:每个团队做的事都差不多,但互不兼容,最后以太坊基金会推出 EIP(以太坊改进提案)这套标准化的智能合约接口注册机制,行业才稳下来。AgentProto 因此发起了 agentproto.sh/docs,试图定义一组可互操作的基元:可组合、可扩展,像 IDENTITY.md 这种可以由用户自由创建任意层,而不是写死一套固定预设。

AgentProto 的最终愿景更激进:这些规范的标准本身也能被定义为规范。举例,TOOL.md 声明自己的代码,能通过 adapter 转换成 ai-sdk 或 mastra 工具,这样 Agent 可以轻松给自己加方法、修 bug、部署——物理上拥有对所有组件的访问权限,包括 memory、runtime、sandbox、CLI 等。这种"让 Agent 拥有自己的物理 IO"的设计哲学,跟 Skillsync 的"会话可移植"和 AgentMD 的"规范可执行"一起,构成 2026 年 Agent 工程化的三股推进力。

Jérémy 同时在做的 Harness Engineering 实践

Jérémy 在提出标准呼吁的同时,自己也在实践一条叫 Harness Engineering 的路。他说他经常同时开 6 个 Claude Code 终端,疲于每隔几分钟去检查 Agent 是不是卡在"我应该继续吗?"这种无意义的确认上——他需要一种让长任务更自主的方案。AgentProto CLI 因此做的不只是 Claude Code 的编排层,而是一个 harness-agnostic 层:可以在 Claude Code 之上或之下 spawn Hermes、Deepseek、Codex、Claw 等任意 CLI,任意模型、任意 provider 都能挂上来,Anthropic、OpenAI、OpenRouter、Kimi、Zai、Xai 都被支持。从这个角度看,AgentProto 解决的是"Agent 运行时"层面的互通,Skillsync 解决的是"会话内容"层面的互通,AgentMD 解决的是"项目规范"层面的互通,三者覆盖了 Agent 互通问题里的三个不同切面。

为什么这件事现在变得紧迫

Agent 互通问题在 2024、2025 年并不紧迫,因为那时候主流 Agent 还不多、用法相对一致。但到了 2026 年,Claude Code、Codex、Cursor、Aider、Cline、Windsurf、Continue 等同时存在,每个都有自己的 SKILL、自己的 memory store、自己的 hook 协议、自己的 sub-agent 协议、自己的成本模型。工程师在多任务、多项目、多角色之间切换时,已经在无意识中被这些工具瓜分。Skillsync 创始人观察到一个反直觉的现象:人们在被锁定之前,从来不会意识到自己被锁了——直到试图离开,发现几个月的会话被卡在只有那个工具能读的格式里。

更严重的是,Skill、memory、上下文这类沉淀资产会随着时间复利——你用的越久、积累越多,迁移成本越高。这跟传统的数据迁移完全不同:传统数据库迁移有标准的 SQL、标准的 ETL;Agent 上下文没有等价的标准,SKILL.md 在不同工具里字段名都不一样,有的叫 skill.title,有的叫 skill.name,要做 hydration 时还要写一堆 plumbing 来解析不同 AGENTS.md 变体。这种基础设施层的缺失,正在变成 2026 年下半年 Agent 规模化的最大隐性瓶颈之一。

三种思路的关键差异与互补

Skillsync 的解决思路是"翻译"——承认现在的格式不可互通,那就用 txcript 当 ffmpeg,把所有格式桥接到彼此。这种方式的好处是今天就能用、立刻能跑,代价是任何一种格式升级都要在 txcript 里加新适配器,长期维护成本与各上游 Agent 的演化速度成正比。AgentMD 的解决思路是"抽象成可执行规范"——把 AGENTS.md 从 markdown 提示词变成带 frontmatter 的结构化规范,通过沙箱化执行 + dashboard 把它纳入 CI/CD,这是面向"项目级重复使用"的方向,长期来看,它是把 Skill 沉淀往基础设施层推。AgentProto 的解决思路是"定义基元"——类似以太坊的 EIP,把 IDENTITY.md、TOOL.md 这些散乱的 .MD 收编到一套互操作的原语集合里,这种方式的长期收益最大,但需要生态共识,起步最慢。

三条路并不互斥——一个工程师完全可能既用 Skillsync 搬运会话、又把项目规范写成 AgentMD 可执行形式、还在 AgentProto 的 IDENTITY.md 里声明自己的 Agent 身份。短期看 Skillsync 解决最痛,中期看 AgentMD 把规范从"自然语言"提到"机器可执行",长期看 AgentProto 的标准化基元能从根本上消解互通问题。三家分别在交互层、执行层、协议层切入,共同把"Agent 记忆作为文件格式"这件事从工程愿景推向工程基线。

对企业落地 Agent 的实际启示

对正在考虑把 Agent 引入生产链路的企业,这三条线的启示各有侧重。第一,会话即资产——把 Agent 的会话视为团队知识资产,而非一次性日志;在引入 Agent 的第一天就考虑未来可能的迁移成本,避免把整个团队锁在单一工具上。第二,Skill 沉淀要走结构化——把项目的 Skill、构建命令、测试规范写成带 frontmatter 的 AGENTS.md 而不是纯散文 markdown,这是为未来纳入 CI/CD、执行审计、权限审批做准备。第三,身份与协议要可声明——Agent 自身的 IDENTITY、能力、可用工具应该在某种声明文件里,而非代码里的隐式约定,这是未来在多个 Agent 之间做权限编排、能力路由的前提。

更深一层,企业应该开始把"Agent 上下文治理"当作一个独立的工程领域来建设,而不是把它当作某个具体 Agent 工具的附属能力。这件事的成熟度直接决定了 Agent 在企业里能不能从"个人提效工具"走到"团队生产工具"。当一个团队的所有 Agent 上下文都不可移植、不可执行、不可声明时,这个团队名义上在使用 Agent,实际上是在被 Agent 厂商的演进路径绑定——这跟 2010 年代企业被单一数据库厂商绑定的剧本如出一辙,但因为 Agent 演化的速度更快,问题会以更短的周期爆发。

可移植性的边际收益曲线

需要诚实指出的是,跨工具互通不是免费的午餐。会话翻译会损失一些工具特有的"语言习惯"——比如 Claude Code 的 reasoning trace 格式跟 Codex 不一样,翻译后可能损失一些上下文细节。Skill 标准化会引入抽象层,带来额外学习成本。规范执行会引入沙箱,带来性能开销。互通的代价是,工程师在不同工具之间迁移时,不再享受"这一家独有的最佳体验",而是拿到一个"在所有工具里都够用的平均体验"。

这条边际收益曲线决定了一个团队何时应该投入互通工作:沉淀越多、切换越多、规模越大,互通的边际收益越高;沉淀少、只用一个工具、规模小,投入互通的回报还不明显。Skillsync 之所以能在 2026 年 9 月成立,正是因为 Agent 沉淀的临界点已经到了——大量个人开发者、创业团队、中小企业已经积累了足够多的会话,开始有动力去做"我已经离不开这个工具,但我需要能离开"的工作。这是从工具时代走向基础设施时代的转折信号。