CompozyOS 教程:先理清 v0.3 beta,再启动常驻 Agent
CompozyOS 不是另一个模型,也不是替你写代码的新 agent。它在 Claude Code、OpenClaw、Hermes 等 ACP agent CLI 外面增加一个常驻 daemon,让 session、task、Loop、memory、审批和运行记录在终端关闭后仍有统一归属。
1. daemon 为什么是核心
web、CLI、HTTP/SSE、Unix domain socket、MCP 等入口都把命令交给 home-scoped daemon。daemon 解析工作区,应用权限和运行策略,协调 agent CLI,再把事件和资源状态存进本地 SQLite。浏览器和终端读的是同一份状态,不各自维护一个会话副本。
这使 cron、webhook、trigger 和 Loop 能脱离某一个打开的终端继续管理。它也意味着 daemon 拿到的目录、密钥和执行权限必须提前限定;“能持续运行”同时放大了错误权限的影响。
2. 不要从旧安装通道猜版本
v0.3 beta 期间,Homebrew 仍提供 v0.2;go install ...@latest 也解析到 v0.2 稳定线。macOS/Linux 可用官方 verified installer,它会固定最新 beta 并检查 Sigstore provenance:
curl -fsSL https://compozy.com/install.sh | sh
也可以明确装 npm beta:
npm install -g @compozy/cli@beta
走 Go 时必须把占位符换成 release 页的完整 beta tag。安装后用 compozy version 确认版本,不要根据命令是否存在判断自己装的是哪一代。
3. 创建第一个持久 session
先在测试仓库操作,完成 home 初始化并启动 daemon:
compozy install compozy daemon start compozy doctor -o json
检查输出中的 provider、agent 和 workspace,再创建 session:
compozy session new --agent general --name first-run
全局配置位于 ~/.compozy/config.toml,工作区可用 .compozy/config.toml 覆盖,显式命令参数优先级最高。使用 compozy config validate 和 compozy config show -o json 查看最终值,比猜某个文件是否生效可靠。
4. v0.2 迁移不是覆盖安装
v0.3 把 Markdown task 导入 durable task,并通过 Loop 执行;它不会恢复 v0.2 的 tasks run pipeline。旧 workflow-memory 文件仍是普通仓库文件,也不会偷偷导入成新的运行状态。
因此升级前要读官方 migration guide,备份 v0.2 home,列出 agent、task、memory 与自动化入口,再在单独目录验证。正式切换前保留旧分支和回滚点。
5. Agent、扩展和远程边界
可复用 agent 定义放在 ~/.compozy/agents/<name>/ 或工作区的 .compozy/agents/<name>/。工作区定义会整体覆盖同名全局定义。扩展可以增加工具和运行行为,daemon 管理发现、启用、信任与生命周期,但可执行扩展本质上仍是代码。
本地优先不等于完全离线。模型 provider 会接收提示与上下文,扩展可访问自己的外部服务,Gateway 能配对设备并开放显式选择的私有或公共 surface。每增加一层,重新检查密钥、路径、审批和日志。
6. 商业化与验证边界
官方仓库和文档当前提供 MIT 源码、安装器、npm 与 Go 安装路径,没有在主流程中设置价格、充值、付费额度或订阅转售入口,本轮不按严重商业漏斗隔离。实际运行仍可能需要用户自己的模型服务账户。
7. 与 OpenHands 对比
OpenHands本身是软件开发 agent 平台,agent 可以改代码、执行命令、浏览网页,并可通过 Docker、CLI、headless 或 GitHub Action 使用。CompozyOS 更偏向已有 ACP agent CLI 外面的运行和监督层。
需要一套现成的软件开发 agent 时先评估 OpenHands。已经使用 Claude Code、OpenClaw 或 Hermes,需要统一管理持续任务、审批和状态时,CompozyOS 的 daemon 模型更贴近问题。
这里仅补原教程没有展开的事实和边界。安装命令与操作步骤仍以前文为准。
先判断这个项目是否适合你
适合谁用
适合需要让已有 agent CLI 跨终端保存会话、按 cron/webhook 运行、保留审批与产物记录的开发团队。单次问答或临时改一个文件时,直接使用原 agent CLI 通常更省维护;CompozyOS 的价值出现在需要常驻状态和统一监督时。
采用建议
CompozyOS 适合已经有 agent CLI、又确实需要常驻任务、审批和可追踪状态的团队。当前最大成本是 beta 迁移与权限设计;先在单独仓库跑一个 session,确认 provider、workspace 和写权限,再考虑 cron、Gateway 或扩展。
原教程未展开的系统信息
核心功能
daemon 持有状态
终端关闭后 session 与 Loop 仍归 daemon 管理;事件、资源和工作区边界由同一运行时保存。
技术栈和运行条件
语言
Go daemon/CLI + Bun/Vite web UI
框架
ACP-compatible agent runtime、HTTP/SSE、UDS、MCP
关键依赖
- macOS 或 Linux 的已验证安装器,或 Node/npm、Go 源码安装路径
- 至少一个受支持且已认证的 agent CLI/provider
- 本地 daemon 与可写的 Compozy home/workspace
- 可选 Gateway 用于远程访问
运行环境
SQLite-backed 本地状态;provider、Gateway 与可执行扩展会引入外部网络或代码执行边界
常见问题
CompozyOS v0.3 beta 能直接覆盖 v0.2.15 吗?
不应直接覆盖。官方要求先读 migration guide;v0.3 使用 daemon、durable task 和 Loop,不会恢复 v0.2 的 tasks run 流程。
为什么 Homebrew 或 go install @latest 装不到 v0.3?
beta 期间两者仍指向 v0.2 稳定线。应使用 verified installer、npm 的 @beta,或显式 release tag。
关闭终端后 CompozyOS 的任务还会继续吗?
session 和 Loop 归 daemon 管理,终端关闭不会自动删除状态;是否继续执行仍由 daemon、触发条件和权限决定。
CompozyOS 默认会把工作区上传到云端吗?
官方描述为本地优先,状态默认在本机;外部模型 provider、扩展或显式 Gateway 仍会产生外部数据边界。