Coven：给 Codex、Claude Code 和 Copilot CLI 一间受项目边界约束的工作室
现在的 coding agent 有一个很实际的管理问题：同一个仓库里，你可能今天开 Codex，明天用 Claude Code，偶尔再试 Copilot CLI。每个工具都有自己的登录、终端、会话记录和工作目录假设。真正容易丢掉的不是模型回答，而是“这个会话究竟在哪个项目里、做过什么、能否被另一个工具接手”的边界。
今天看的是 OpenCoven/coven。它把自己定义为 project-scoped coding-agent session 的 local harness substrate：不是再包一层聊天 UI，而是由本地 Rust daemon 负责项目边界、cwd validation、PTY lifecycle、event logging、SQLite persistence 和 IPC enforcement；CLI 则是便利层。README 目前聚焦 Codex、Claude Code 与 GitHub Copilot CLI，并为将来的 adapter 留出契约。
按 GitHub repository、README、LICENSE、main 分支 Atom commit feed 和 Releases 页面在 2026-09-11 18:25 Asia/Shanghai 可核验的信息，OpenCoven/coven 当前有 47 stars、26 forks，主要语言是 Rust，license 是 MIT。仓库创建于 2026-04-27 05:18:06 UTC；latest push 为 2026-09-11 10:21:57 UTC。最新 main commit 是 7928c4e8，时间 2026-09-11 10:18:35 UTC，信息为 chore(deps-dev): bump openclaw to 2026.9.1 (#946)。最新 GitHub Release 是 v0.4.3，发布于 2026-09-02 21:34:02 UTC。项目仍处于 pre-1.0 阶段，README 也明确提醒预期会有 rough edges。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | OpenCoven/coven |
| 定位 | 面向项目边界的本地 coding-agent session runtime |
| Stars / Forks | 47 / 26 |
| 主要语言 | Rust |
| 许可证 | MIT |
| 创建时间 | 2026-04-27 05:18:06 UTC |
| Latest push | 2026-09-11 10:21:57 UTC |
| 最新 commit | 7928c4e8，chore(deps-dev): bump openclaw to 2026.9.1 (#946) |
| 最新 Release | v0.4.3，2026-09-02 21:34:02 UTC |
| 安装入口 | npm install -g @opencoven/cli |
| 支持重点 | Codex、Claude Code、GitHub Copilot CLI |
重点不是统一模型，而是统一会话的所有权
许多 agent launcher 的价值在于方便切换模型；Coven 更有意思的取舍是把“谁拥有会话约束”放在前面。README 写得很清楚：你选择 harness，但 Coven 负责 session。Rust daemon 是 authority boundary，安全决策只向 daemon 收敛，不能由上层客户端反向决定。
这对一台日常开发机很有意义。比如你想让 Codex 修测试，再让 Claude Code 做一次代码审阅，重要的不是它们看起来在同一个 dashboard 里，而是启动的 cwd、项目身份、PTY 生命周期与持久记录有同一个本地权威。换 agent 时不必把“上一次到底在哪个 repo 做了什么”也一起交给新的工具猜。
最短路径是先让本地守护进程接管一条会话
README 给出的基本流程很克制：全局安装 @opencoven/cli，进入项目目录，用 coven setup codex 完成 provider 自己的登录，接着执行 coven doctor 检查环境，启动 coven daemon start，最后用 coven run codex "fix the failing tests" 发起会话。coven sessions 用来浏览和管理 session，结束后可停止 daemon。
这里有个值得保留的边界：登录仍属于 provider；Coven 不宣称替你接管账号或密钥。它做的是把已可运行的 harness 放到同一个本地项目生命周期里。对于已经使用多套 agent CLI 的人，这比“再记住一个 Web 服务地址”更贴近日常工作。
SQLite 和记忆面板带来的是可检查性，也带来数据责任
项目把 event logging 和 SQLite persistence 放进核心，而 memory dashboard 是单独、可选的 companion。这个设计能让会话跨终端、跨工具存续，也让排障和协作不只依赖滚走的 terminal buffer。但它绝不等于“记录得越多越安全”。
README 的安全提示很具体：session log 会捕获 harness output；即便 API 显示前会对 event payload 做 redaction，秘密如果出现在 prompt 或输出里，仍不该被输入。它还建议不要在敏感仓库里运行不受信任的 harness 或 prompt。换句话说，local-first 解决的是控制位置，不会自动消除日志、权限和第三方 agent 的风险。
适合先在哪些场景试
它很适合两类人。第一类是经常在同一台机器的多个 repo 间切换、又想轮流使用 Codex、Claude Code 和 Copilot CLI 的开发者：先在一个非敏感项目验证 doctor、daemon 和 session list 是否真的改善了上下文交接。第二类是做内部 agent workflow 的团队：可以研究它的 harness adapter contract 和 daemon authority model，而不是把自己的安全约束埋在某个 UI 的按钮逻辑里。
不要一开始就把它当作多人协作平台、密钥保险箱或 agent sandbox。它还未到 1.0，Linux 发行版与运行环境也要按官方安装文档核对；而且无论 session manager 多完善，agent 能访问的文件、命令和网络权限仍应由项目与系统层单独约束。
总结
Coven 的小众价值在于它没有试图发明又一个 agent，而是给现有 agent CLI 加上一层可明确归属的本地项目会话。若你的痛点是多个 coding harness 各自留下半截上下文、却没有统一的项目边界和生命周期，这个 Rust daemon + CLI 的方向值得在安全的试验仓库里跑一遍。