最近把自己做的项目 Pragma 正式公开了，你觉得有意思或者对你有帮助的话求个 star ，有兴趣的也欢迎提交 pr：
https://github.com/pqpo/pragma
Pragma 不是想再做一个 Claude Code 或 Codex ，而是想解决一个我在长期使用 AI Agent 时越来越明显的问题：
不同 Agent 很强，但工作方式、上下文和经验都被困在各自的 Session 里。
比如一个开发任务可能是：
Claude Code 做需求分析
↓
Codex 做技术方案
↓
Codex 实现代码
↓
Claude Code 做独立 Review
每一步可以使用不同的模型、不同的 Harness 。
真正麻烦的不是怎么调用它们，而是：
前一个 Agent 学到的东西，怎么让后一个 Agent 继续利用？
不迁移 Session ，而是迁移工作语义
一开始很自然会想到：能不能把 Claude Code 的 Session 直接交给 Codex ？
但不同 Harness 有完全不同的 Session 、Message 、Tool Call 、Compaction 等内部机制，而且真正有价值的通常也不是完整的聊天记录。
比如一次任务中发现：
这个项目不能使用 UUID ，
因为历史数据和接口都依赖 ULID 。
真正值得留下的是这个事实。
或者一次排障过程：
修改方案
→ 测试失败
→ 找到历史兼容逻辑
→ 调整实现
→ 最终通过
值得留下的是这次经验，而不是几十轮聊天记录。
所以 Pragma 的核心思路是：
不迁移 Session ，而是迁移工作语义。
所有 Harness 进入同一条 Memory Pipeline
Pragma 会把 Claude Code 、Codex 、PI 等不同 Runtime 的执行过程归一化，最终进入统一的 Memory Pipeline：
Claude Code / Codex / PI
↓
Execution
↓
Evidence
↓
Memory
Memory 目前主要分成两类：
Episodic Memory
记录「以前发生过什么」，例如一次任务的目标、尝试、失败、恢复和最终结果。
Semantic Memory
记录「现在认为哪些事情是真的」，例如项目约束、用户偏好和稳定事实。
所以最终不会存在：
Claude Code Memory
Codex Memory
而只有：
Pragma Memory
下一次无论换成 Codex 、Claude Code ，还是未来其他 Harness ，都可以继续利用这些经验。
Context 和 Memory 是两回事
这个边界我觉得也很重要。
刚刚生成的：
requirements.md
architecture.md
review findings
TODO
属于当前任务的 Context，应该直接在 Agent 之间流动。
而：
这个项目过去踩过什么坑
用户长期有什么偏好
什么方案以前失败过
有哪些稳定约束
才更适合进入 Memory。
我现在会简单理解成：
Context 是这次工作正在知道什么。
Memory 是过去的工作有什么值得继续知道。
最后
Pragma 想做的事情其实可以浓缩成一句话：
让 AI 的工作方式和经验脱离某个具体 Agent ，变成可以持续积累、复用和迁移的资产。
模型和 Agent Harness 会不断变化。
今天是 Claude Code 、Codex ，明天一定还会有更好的工具。
但如果每换一个工具，我们积累的经验就重新归零，那其实很可惜。
所以我更希望最终留下来的不是某一个 Agent ，而是：
Workflow
+ Context
+ Memory
+ Evaluation
项目目前还在比较早期，欢迎讨论这种跨 Harness 的 Context / Memory 设计。
GitHub：
Select Language