CloudCode 一站式云端AI工作台

v0 到 v1

之前 v0 版本的时候（介绍在上面 v1 文章里），也是我初步入门 harness，几个头部 coding agent 也都用过了，那时候我的需求只是把 coding agent 挪到云端，释放我本地电脑，AMD 的机器，发热严重。这半年多时间，cloudcode 用的也很舒服，而且 cloudcode v1.0 版本也是从 v0 版本上热开发热更新来的，但是是完全不同的设计。之前的 v0 版本：

v0 版本很简单，最开始借助了 opencode web 来当作操作界面，本质上就是个基于 docker 的多 opencode web 实例管理工具。解决了它同域名下 opencode web 多实例管理的问题，现在他们也还不支持子路径部署，因为这涉及前端资源加载、数据存储等一系列问题，细节也挺多。后面我又接入了 cloudcli（一个第三方的多 agent web ui）来使用 Claude code 和 codex。

后面经过半年我通过 v0 cloudcode 做了很多事情，加上多了一些其他需求且接受了来自社区的一些 AI 经验和新闻，还有受不了 opencode 占用十几个 GB 的 SQLite 了，我准备了 v1.0 的重构。这次重构完全剔除了 opencode web、cloudcli 内置一套基于 pi 底座的 web ui，然后设计理念分为 3 部分。

设计理念

UI 风格是基于我之前断断续续关注的 Dear-ImGUI 的紧凑专业型风格，因为平常我都不开自己电脑，基本都是空闲的时候手机上操作一下，移动端优先。紧凑型的设计可以在移动端展示更多的内容。

然后就是场景，核心设计了三种使用场景，这也是我自己对 harness 理解的一份答卷，是我自己(可能的)需求的一个落地。

1. 工作台

工作台是我直接上手去处理需求和查看所有 agent 的会话使用的，还有便捷的文件管理和终端及简单的查看工作区变动用的工具，这是最直接的使用场景，人直接操作。

2. workflow

workflow 其实 v0 里面也有，但是 v0 我自己根本没用过（没有时间😂也不算有需求），只是让 AI 自己做出来自己测了一下。但是 v1.0 的 workflow 是真正可用的 workflow。

workflow 是借助 AI 处理标准化流程用的，bonds 是我做的一个 PRM 系统，它重写了 monicahq/monica 但是说实话我使用它的时间不超过 1h，因为我太忙了，没精力维护个人关系。但是他有几个忠实用户一直在提 issue，那我都不用也不看代码，怎么有用户用且实现正确的呢？因为我都是通过 opencode web、cloudcli 一步一步监督着实现的，AI 对方案的选择、AI 的实现、本质上就是我的 taste。其实我的 taste 就那几个，比如尽量减少持久化的数据，非必要不持久化，比如要做适合所有用户的通用能力而不是 issue 要求什么就实现什么等。我感觉上是完全可以标准化的，那么这个项目将变为一个完全自维护的项目。

所以我真正的让 workflow 变得能用，真正测试了它，这是 bonds 上的一个测试 PR，0 监督，全 AI 实现。workflow 的设计很大程度上源于我对 n8n 的使用体验，融合了 agent 节点，它也有几种 trigger。

3. 办公室

模型都是那个模型，你创建几个角色拉到一起结果就大于 1 了？哈哈，听我狡辩。

「办公室」解决的实际上是上下文隔离和注意力增强的问题，避免同一个会话上下文过长造成注意力偏移或者历史 context 的首因效应先入为主影响后续的对抗性操作。这个我也测试了但是目前我自己还没有一个明确需求不算深入验证。

总结

全局实现了全 agent 一处配置，AGENTS.md、MCP、Skills 的多处双向同步，一处配置所有实例所有 agnet 一起用。

workflow 和办公室也都有给各 agent 提供 mcp，都不需要人工一点一点创建。

整体底层都是借助 pi/claude/codex 的 harness，我只做缝纫工，借助他们的 compact 等的基础能力我更放心，不选择自己实现一个垃圾不可靠的 context 工程体系。

体验一下

okay，到这里可能有些同学已经心里痒痒了，也想在自己 8C16G 的服务器上体验一下？虽然 CloudCode 目前不准备开源，docker 中的代码也经过编译时混淆，但是仍然提供 docker 使用：

在 README 部分有部署说明。欢迎留言互相交流～