更新是仅升级、经过校验且可恢复的。在新版本通过校验之前不会发生任何不可逆的操作，在新版本被证明健康之前也不会把它记录为已安装。

同一套内核有两种用法。tools/fileopshub 把操作作为字段传入，这正是智能体需要的形态 —— 一个节点、多种操作，并且失败时返回结构化信息，说明这次调用能否原样重试。 而单独的节点适合手工...

翻译由一个节点承担，具体提供商通过字段选择：既可以用复用现有模型凭据的 LLM 提供商， 也可以直连 DeepL、百度、Google 的厂商 API。取舍很明确 —— 处理普通文本时厂商 API 更便宜、更稳定...

表格是 ChengOS 中与文档相对的结构化数据形态：它是 Airtable 意义上的多维表格——有类型的列、有序的记录、可保存的视图——而不是一张由零散单元格组成的电子表格。

与系统之外打交道的一组。tools/http 是原始请求；tools/web 高一层， 提供抓取、提取正文、爬取、下载等操作 —— 当你要的是内容而不是响应体时优先用它。 tools/fetchrepository 拉取…

几乎每一次 ChengOS 安装失败都是四件事之一：端口已被占用、数据库连不上、占位密钥没改，或者某个路径在两个进程眼中含义不同。在往下细读之前，先按下面的分诊步骤过一遍。

只能在编辑器里运行的工作流，是给你自己用的工具。发布把它变成别人可以使用的东西——一个带 URL 的页面、一个对话界面，或者一个供其他系统调用的接口。

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

这些节点决定数据流向何处、以什么形状到达。utils/conditionrouter 是确定性分支 —— 简单模式是一条规则配一对真/假输出，高级模式是多规则 switch，每个分支一个输出端口。 只要规则能写下...

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