一条入站消息必须回答两个彼此独立的问题：它属于哪一个会话？ 以及 该运行哪一个工作流？ 把二者混为一谈是网关建模中最常见的错误，ChengOS 刻意让它们分开。

这些是把数据送进工作流的节点。io/inputtext 承载你在画布上直接填写的文本或 JSON 字面量； io/fileupload 把上传的文件转成持久化的工件引用；io/readfile 读取服务端本来就能看到的路…

Docker 模式把每个 ChengOS 服务都作为容器运行在 Docker Compose 之下。它是推荐的生产部署方式：版本被固定到确切的镜像标签，数据存储默认绑定在回环地址上，更新与回滚替换的是整个镜像，而...

一次执行有三种彼此独立的视图，而本页最重要的一点就是：它们从不混为一谈。

你不需要部署工作流才能验证它是否可用。运行可以直接在编辑器里发起，事件在发生的同时通过 WebSocket 回传，因此调试是「观察然后阅读」，而不是从一个最终错误字符串里猜。

ChengOS 通过单个管理脚本 chengos.sh 安装，两种部署模式都由它处理。本文介绍在单台机器上把系统跑起来的最快路径。如果你已经确定要用容器，可以直接跳到 Docker 部署。

Hub 是用一个节点代表许多可调用操作，这样智能体能拿到一整箱工具，而画布不必为每个工具长出一个节点。 tools/toolhub 暴露的工具，要么来自当前生效的 Skill 声明，要么来自工作流作者的配置...

ChengOS 的后端是一套六边形架构（端口与适配器）加领域驱动设计。在这个项目里这不是口号——它由 crate 依赖图强制保证：cheng-core 不依赖数据库、不依赖 HTTP、不依赖文件系统，因此一条领...

工作区工具中与文件无关的那一半，而且刻意做得不对称：tools/workspacegit、 tools/workspacemarkdown、tools/workspacepreview 提供的都是只读操作， 而任何可能改…

cheng CLI 不必与 ChengOS 服务器跑在同一台机器上。一旦不在同一台，有一个问题决定了其余一切：工作流读文件时，读的是谁的磁盘？