Conductor OSS：把本地 AI coding agent 变成可观察的工作台
AI coding agent 真正开始干活以后，麻烦往往不在“能不能生成代码”，而在你怎么同时看住多个会改文件、会跑命令、会开 dev server 的会话。
一个终端里跑 Claude Code，另一个终端里跑 Codex，再开一个 Gemini 试替代方案；每个 agent 都在不同目录里改代码，测试结果、preview URL、diff、任务说明和 reviewer feedback 散在 shell scrollback、浏览器 tab 和 Git 状态里。人类可以勉强靠习惯记住，但一旦并发多起来，真正缺的是一个本地控制面：能启动 session、隔离 worktree、看到原生终端、收拢 diff，并且在需要时从手机或另一台机器接回同一个本地 runtime。
今天想记下的 charannyk06/conductor-oss 就是切这块的工具。它把自己定义为 local-first control surface for real AI coding agents，支持 Claude Code、Codex、Gemini 等 coding CLI，通过 workspace、git worktree、native PTY、preview、diff、restore、paired-device bridge、MCP server 和 ACP server，把 agent 会话从一堆散落终端收进一个 dashboard。
按 GitHub repository API、README、LICENSE、release API、tags API、languages API 和 commits API 在 2026-07-11 能核验的公开信息，charannyk06/conductor-oss 当前有 41 stars、10 forks。仓库主语言是 Rust，同时有较多 TypeScript 前端代码；许可证是 Apache-2.0。仓库创建于 2026-03-01 20:03:24 UTC，最近 push 是 2026-07-11 09:32:58 UTC。默认分支 main 的最新提交是 04871809，提交时间 2026-07-11 09:07:30 UTC。最新 GitHub release 是 v0.61.14，发布时间为 2026-07-11 09:36:21 UTC，最新 tag 也指向 v0.61.14。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | charannyk06/conductor-oss |
| 定位 | 本地优先的 AI coding agent workspace、terminal、diff 与 session 控制台 |
| Stars | 41 |
| Forks | 10 |
| 主语言 | Rust |
| 许可证 | Apache-2.0 |
| 仓库创建时间 | 2026-03-01 20:03:24 UTC |
| 最近 push | 2026-07-11 09:32:58 UTC |
| 最新 main 提交 | 04871809，2026-07-11 09:07:30 UTC |
| 最新版本 | v0.61.14 |
| 版本发布时间 | 2026-07-11 09:36:21 UTC |
| 核心能力 | workspace、git worktree、native PTY、diff、preview、paired-device bridge、MCP server、ACP server |
它解决的是 agent 并发后的管理问题
很多 AI coding 工具都在强调模型能力和补全质量，Conductor OSS 关心的是另一个层面：当你已经决定让 agent 在真实仓库里跑，怎么让这些会话更容易被启动、观察、恢复和收尾。
README 描述的主流程很直接：打开 Conductor，添加 workspace，选择 GitHub 仓库或本地文件夹，然后在这个 workspace 下启动或恢复 agent session。每个 session 里有真实终端、overview、preview 和 diff。这里的关键是“真实终端”，它不是把 agent 输出塞进一个假 chat shell，而是通过 native PTY 让 Claude Code、Codex、Gemini 等 CLI 以原本的终端方式运行。对依赖 TUI、approval prompt、resize、restore 的 coding agent 来说，这个差别很实际。
它还用 git worktree 隔离并发 session。这个设计适合今天的 agent 工作流：同一个 repo 上可能同时跑 bug fix、refactor、dependency upgrade 和 reviewer feedback。如果全挤在一个 working tree，冲突和误操作会很快失控；如果每个 session 有自己的 worktree，至少文件层面的并发边界更清楚。Conductor 不是操作系统 sandbox，README 也明确提醒 agent 仍然以本地账号权限运行，但 worktree 对管理 Git 改动仍然有价值。
local-first 不是没有远程，而是 runtime 留在自己机器
Conductor OSS 有两种使用方式。第一种是在同一台机器上跑 local dashboard，直接用 npx --yes --registry=https://registry.npmjs.org conductor-oss@latest 或安装全局包后 co start --open。第二种是 hosted dashboard 加 paired-device bridge，用另一台电脑或手机打开 dashboard，但实际 repo、terminal 和 agent 仍然跑在自己的机器上。
这个边界很重要。它不是把代码默认搬进一个 cloud IDE，而是把远程访问做成连接本地 runtime 的 bridge。README 里也说明，本地状态会落在普通文件里，例如 conductor.yaml、CONDUCTOR.md 和 .conductor/conductor.db。对团队评估来说，这比“把仓库交给一个云端 agent 平台”更容易接受，至少可以先从本机、个人仓库和低风险任务开始试。
但 paired-device bridge 仍然是远程访问能力，不应该被理解成零风险。README 提到如果只是转发本地 dashboard 端口，Conductor 会把它视作 remote access 并要求额外身份层；远程使用时应通过官方 paired flow，或把自托管 dashboard 放在 Clerk、Cloudflare Access 这类身份保护后面。换句话说，它的 local-first 是部署和数据位置上的选择，不是权限治理的替代品。
Markdown board 和 CLI 让它不只是一个 UI
Conductor OSS 还保留了一个很程序员化的入口：CONDUCTOR.md。默认 scaffold 里有 Inbox、Ready to Dispatch、Dispatching、In Progress、Review、Done 这样的任务流。如果你喜欢把计划写在 Markdown 里，再把任务 dispatch 给 agent，这个设计比单纯 dashboard 更贴近实际工作方式。
CLI 也比较完整：co init 初始化 workspace，co spawn 启动新 agent session，co list 和 co status 查看状态，co send 给运行中的 session 发消息，co feedback 把 reviewer feedback 发回去并重新排队，co retry、co restore、co kill、co cleanup 处理会话生命周期。它还提供 co mcp-server 和 co acp-server，说明作者不是只想做一个桌面壳，而是想把 session runtime 也暴露给其他工具。
这点对 heavy agent user 有意义。随着你让 agent 处理更多 issue，真正需要的不是更多聊天窗口，而是 session 管理：哪个任务在跑，在哪个 worktree，当前 diff 是什么，preview 是否可用，失败后能不能恢复，reviewer feedback 有没有回到正确的 session。Conductor OSS 把这些动作收进一套命令和 UI，方向是对的。
适合什么场景
第一类场景是个人开发者同时使用多个 coding CLI。比如你已经在不同任务里切换 Claude Code、Codex 和 Gemini，希望它们都能从同一个 workspace 面板启动、观察和收尾。Conductor OSS 的价值不是替代这些 CLI，而是给它们一个共同控制台。
第二类场景是多分支或多任务并行。git worktree 管理、diff 视图和 preview surface 能让你更容易判断每个 agent session 到底改了什么，而不是在一个仓库目录里反复 git status 和找 terminal scrollback。
第三类场景是移动或跨设备查看。paired-device bridge 适合“代码和 agent 跑在家里或办公室机器上，但我想从另一台设备查看进度、发一句反馈、看一下 diff”的场景。它不应该拿来绕过身份和网络边界，但作为受控远程入口很实用。
第四类场景是想把 agent session 接进更大工作流的团队。MCP/ACP server、CLI 和 Markdown board 给了后续集成空间：你可以从自己的调度器创建任务，也可以把 status、feedback、restore 这些动作接到内部工具里。
需要注意的地方
第一，项目很新，也很小。仓库创建于 2026-03-01，当前只有 41 stars。虽然 release 节奏非常快，最新版本已经到 v0.61.14，但这更像快速迭代期的工具，而不是已经稳定多年的平台。试用时要固定版本，并准备好导出或回退路径。
第二，它不是安全 sandbox。README 明确说 worktree 能隔离并发 Git 修改，但 agent 仍然以本地账号权限运行。自动 permission mode 也是一个显式信任决定。不要因为有 dashboard 和 worktree，就默认 agent 对文件系统、网络或凭据的访问已经被完整限制。
第三，平台和运行时要看清。README 写到发布 launcher 需要 Node.js >= 20.9.0，并包含 macOS、Linux x64 和 Windows x64 的 native backend。其他平台可以从源码构建，但这意味着你要接受更多本地环境差异。
第四，hosted dashboard 与 bridge flow 需要单独评估。项目强调 repos、terminals 和 agents 留在 paired machine 上，但远程控制面本身仍然涉及 relay、身份和访问策略。真正接触私有仓库前，先用测试仓库跑通，确认日志、端口、会话恢复和访问控制行为。
小结
Conductor OSS 有意思的地方，是它没有试图做“又一个 AI coder”，而是给现有 coding CLI 补控制面。Claude Code、Codex、Gemini 这些工具负责写代码，Conductor 负责 workspace、session、terminal、diff、preview、feedback 和 restore。
如果你已经开始并发使用多个 AI coding agent，或者希望把 agent session 从散落终端收进一个本地优先的工作台，charannyk06/conductor-oss 值得小规模试一下。它现在还年轻，但问题选得很准：agent 越能干，人越需要一个地方看清它们正在对仓库做什么。