让 Agent 完整读取 60 集剧本、生成资产附录、运行覆盖校验，并在用户中途调整需求后继续工作，需要解决的不只是模型调用：材料放在哪里，中间结果怎样保留，脚本如何处理这些文件，多次执行又如何共享同一份任务状态？ 为此，我基于 Mastra + PostgreSQL + Node.js 自研了一套持久化 Agent 执行环境：用 提供可持久化的虚拟文件系统，用 限制运行级文件访问，用 AgentController 管理多轮会话，再通过自定义 为 Agent 提供 JavaScript 批处理能力。 这套方案的特点是：文件按会话持久化，计算按调用执行，所有读写共享同一工作区。 它不需要为每个会话启动完整 Linux 环境，就能支持材料阅读、文件生成、批量统计和交叉校验。具体分工如下： 存储与计算分离：文件由 PostgreSQL 持久化， 在 Worker Thread + 中执行短脚本；一次脚本结束不会带走任务文件。 工作区随任务延续：Controller 按 Session scope 动态解析 Workspace，

最近用 Claude Code 开发时，反复遇到同一个问题：让它用后台任务起的 dev 服务（server + 前端 dev server），跑着跑着就没了，任务通知里只有一句： 我的机器是 M5 + 32GB，按理说跑几个 dev 服务绰绰有余。于是花了点时间排查，结论有点意外： 杀掉进程的不是 macOS，而是 Claude Code 自己的「内存压力回收」机制，而且它明显误判了。 先排除「系统真的内存不够」 第一反应当然是怀疑系统 OOM。但几个证据都对不上。 系统日志里没有任何杀进程记录 macOS 真正因为内存不足杀进程时，内核会留下 / 相关日志。查了被杀前后几分钟： 结果是空的。系统在这段时间里一个进程都没杀。 进程是被 SIGTERM 正常停止的 服务端日志最后一行： 收到的是 ，不是系统强杀时的 服务自身才占 375MB，比启动时（744MB）还低，不存在内存泄漏 系统整体可用内存还有一半多 可用，怎么看都不像「内存不足」。 那内存到底去哪了？ 虽然没到 OOM 的程度，

这两天我在本机里注意到了一个目录：。 打开一看，里面是一个非常熟悉的结构： 第一反应很自然： 这是不是某种通用的 Agent 规范？如果我写一套 skills，是不是 Codex、Claude Code、Cursor 都能直接吃？ 答案是： 方向上越来越接近“通用”，但现实里还没有通用到可以完全无脑互换。 这篇文章就聊清楚三个问题： 到底是什么 为什么越来越像跨客户端的共同格式 Codex、Claude Code、Cursor 真正的兼容差异到底在哪 先说结论：它更像“开放约定”，不是“统一标准” 如果你去看本地的 skill 文件，大概率会发现两件事： 每个 skill 都是一个独立目录 核心入口是 有些 skill 里还会附带： 文档 示例代码 辅助脚本 模板文件 这说明它本质上不是一个“只写 prompt 的文本片段”，而是一个更接近“可复用能力包”的东西。 但这里要注意一个非常重要的区分： 是技能描述格式 是某些客户端约定会去扫描的目录 这两层不要混在一起。 很多人会误以为： 只要目录叫 ，所有 Agent 客户端就都会自动识别。

最近我在琢磨一件很具体、但又挺容易让人踩坑的事： 能不能给 、、 这些编程代理客户端，设计一套统一的 prompt 约束注入机制？ 更直白一点说，就是我们能不能只维护一份类似 的文件，然后让不同客户端在 session 初始化时都自动加载它？如果能，这件事会非常省心。团队可以有统一规范，个人也能有统一偏好，不用在每个客户端里重复维护一遍。 我先说结论： 没有一个被这三家共同官方约定的“统一文件标准”。 但它们的机制已经足够接近，完全可以通过一层很薄的适配，把这件事做成。 这篇文章就梳理一下三家的官方机制、它们的差异，以及我最终更推荐的一套落地方案。 先说结论 截至 ，如果问题是： 有没有一个像 这样的通用标准文件，可以被 Codex、Cursor、Claude Code CLI 一起原生自动加载？ 我的答案是： 没有跨客户端统一标准。 Codex 和 Cursor 都支持 ，但支持方式不完全一样。 Claude Code 的主机制不是 ，而是 。 如果想统一维护，最稳的办法不是赌一个文件名通吃，而是“单一真源 + 各端适配层”。 也就是说，

[](https://github.com/Hexi1997/agent-root-cli) 是一个很小的 CLI，用来解决一个很具体的问题： 如果同时在用 、、，全局指令应该维护在哪一份文件里？ 这类指令通常都比较稳定，比如： 默认用中文回答 改代码前先读上下文 commit 前先确认 搜索优先用 它们更像是长期工作流配置，而不是某次对话里的临时 prompt。 问题是，不同工具的接入方式并不一样： 使用 主要使用 主要使用 结果就是，同一套规则很容易被维护成几份，时间一长还会分叉。 这个项目做了什么？ 的做法很直接： 保留一份源文件，再把不同客户端接到这份源文件上。 默认约定如下： 源文件： Codex： Claude： Cursor：手动创建一条 User Rule，指向 这样一来，真正需要编辑的就只有 这一份。 怎么用？ 先安装： 初始化源文件： 建立链接： 如果只想先预览，不想直接写入文件，也可以用： 完成后，Codex 和 Claude 会共享同一份源文件内容；Cursor 只需要手动配一条 的 User Rule，也能接入这套规则。