引擎建立在一条明确的设计原则之上：静态在左，动态在右；状态兜底，调度闭环。 规划只做一次，离线且无副作用；调度在运行时进行；而持久化的状态机是让整套机制可恢复（而不仅仅是快）的关键...

工作流有四种启动方式：用户手动运行、渠道消息到达、另一个工作流把它当子流程调用，或者时钟到点。本页讲时钟。

编辑器里的对话面板不是硬拼在工作流引擎上的演示控件，而是一等的执行界面：你发一条消息就启动一次工作流运行，而这次运行产生的一切——流式 token、工具调用、智能体迭代、审批请求——都会...

渠道把一个外部即时通讯平台接到 ChengOS 的工作流上。消息从 Telegram 或 Slack 到达，平台特有的载荷被归一化成同一个消息模型，会话被解析出来，工作流随即运行。回复再沿同一个适配器发回去...

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

ChengOS 里的页面不是模板文件，而是工作流的输出：每个 UI 节点描述一个区域，ui/pageroot 把它们组装起来，产出 PageLayout JSON，再由运行时渲染。

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

网关 SDK（@chengflow/chat）用于把一个由 ChengOS 驱动的对话界面放进网页应用。它分三层，你按需选用：

SDK 是纯 TypeScript，不依赖任何框架。React hooks 和组件建立在它之上，但核心类在任何地方都能用。

网关是外部应用与 ChengOS 工作流之间的一层。它的全部职责就是映射：消息来自哪个应用、应该由哪个工作流处理、属于哪个会话。把这个模型理顺，多应用部署才不会变成猜谜。