Smriti

Product Hunt 的大家好，

我是希曼舒，今天提前发布 Smriti，因为我希望这个产品能基于真正的智能代理工作流来打磨，而不只是按照我个人的使用习惯开发。

Smriti 最初的形态和现在完全不同。

第一个版本是围绕「推理状态的 Git」打造的聊天应用——支持推理过程的检查点、分支、对比和恢复。概念上是可行的，但我后来发现体验设计不对。大多数人并不需要一个版本控制系统，只是为了问个问题或者做轻量研究。

当我开始深度使用编码智能代理后，思路才变得清晰起来。

当 Claude Code、Codex、Cursor 或其他工具在同一个项目上工作时，Git 可以管理代码版本，但工作背后的推理过程仍然被困在各个独立会话中。如果因为某个模型效果更好我换了工具，就得重新解释一遍项目。如果两个代理并行工作，它们可能会重复干活，或者错过对方已经做出的决策。Markdown 交接文件能有点用，但它们不是可靠的状态层。

这就是 Smriti 想要解决的问题。

Smriti 是一个面向编码智能代理的本地优先开源推理状态层。它让代理能够：

- 接入同一个项目

- 在会话启动时读取共享状态

- 开始工作前认领任务

- 为决策和开放任务创建检查点

- 检测仓库漂移

- 从另一个代理的检查点继续工作

- 无需中央编排器即可协调工作

项目本身就是用 Smriti 开发的，Claude Code 和 Codex 通过同一个状态层完成协作。

我透明说一句：这还不是一个打磨完善的 SaaS 产品。它确实可以用，想法也已经落地，但我目前主要在 macOS 上用 Claude Code 和 Codex 测试。我现在发布它，是因为智能代理开发领域发展太快，我宁愿从真实工作流中学习，也不想闭门造车一直打磨。

我希望这次发布能收获：

1. 在真实的编码代理项目上试用它

2. 告诉我安装配置在哪出问题了

3. 告诉我「推理状态的 Git」这个定位是否清晰易懂

4. 告诉我它下一步应该支持哪些代理工具或工作流

5. 如果它确实解决了你的痛点，可以考虑给仓库点星、提交 Issue 或者贡献集成代码

我的信念很简单：

如果软件开发越来越智能化，推理状态就不能一直困在各个独立聊天会话里。

我欢迎诚实的反馈，尤其是批评意见。