这篇文章原来是一篇很长的 OpenCode 配置介绍。我保留这个 permalink，但现在它的作用变了。
OpenCode 是我最早把 AI tooling 当成系统来看的地方之一，而不是只把它当作一个 chat window。我当时有不同的 agent role、不同权限、共享 prompt、MCP tools，以及一条用 Nix 在 NixOS 和 macOS 之间同步配置的路径。很多具体细节现在已经没有那么重要了。真正留下来的，是它让我更早意识到 boundary 的重要性。
当时的配置是什么样
原来的配置里有三个核心角色：
ask负责只读解释和检查plan负责架构判断和任务拆解build负责编辑、测试和实现
在这之外，我还放了 frontend、backend、ops、testing、debugging、code review、security、refactoring、documentation、migration、exploration 等 specialist agents。这个列表经常变化，这本身就是第一条教训：一个 multi-agent setup 并不会因为有很多名字就稳定。
这些角色只有在权限真的不同的时候才有意义。只读 reviewer 不应该能改文件。Planning agent 不应该悄悄跑破坏性命令。Builder 需要写入权限，但也必须有验证习惯。没有这些边界，所谓 multi-agent 只是把 failure mode 变得更混乱。
跨平台同步才是真正的约束
我当时在 NixOS 和 macOS 之间切换，所以配置必须能跨环境生存。OpenCode 的配置文件放在我的 Nix repo 里，再同步到每台机器的 ~/.config/opencode。
这听起来很普通，但很关键。如果一个工具只能在某台电脑上工作，因为 prompt、model setting 或 agent definition 都是手动改出来的，那它就不算真正属于我的 workflow。它只是把本地状态伪装成系统。
Nix 的价值在这里很直接：我能看到哪些文件定义了 agent system，能 diff，也能在机器之间迁移，而不是每次都靠记忆重建环境。
协议的重要性在于降低耦合
MCP 对我有用，是因为它让外部工具不再像一堆临时拼接。与其让每个 agent 都有自己的集成方式，不如让工具和 context 通过一个更统一的接口暴露出来。
我当时也关注 editor-agent protocol，原因类似。如果 agent 和某一个 editor、chat UI 或 provider 绑得太死，每次迁移都会很贵。协议不能解决 agency 里最难的问题，但它能让接口更容易推理。
这后来变成我看 AI tooling 的一个固定习惯：我不太关心一个工具单独看起来有多酷，我更关心它和系统其他部分之间有没有清楚的边界。
后来发生了什么
现在我的 workbench 已经不再把 OpenCode 当成完整答案。所有权划分更清楚了：
- Codex 负责交互式工程。
- Hermes 负责周期性 orchestration。
- Obsidian 保存人类可读的 second brain。
- CC Switch 负责共享 tooling 和 provider plumbing。
从这个后来的架构看，OpenCode 更像是同一方向上的早期实验。它让我意识到，“one AI workspace” 往往太模糊。更好的问题是：哪个组件拥有哪一类 state，它被允许写什么？
我会保留下来的东西
真正耐用的经验其实很小：
- Agent 名字没有权限边界重要。
- 跨平台配置应该被版本管理，而不是靠记忆。
- Tool protocol 的价值在于减少耦合。
- Orchestration 需要可观察状态，而不只是更多 prompt。
- 个人 AI 系统失败时，应该能被审计。
所以这篇文章现在更适合放在新的 personal AI workbench 旁边。OpenCode 不是最终架构，但它是让我看清架构的一段实验。
讨论