ChengOS 在 MCP 上是双向的：

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

有两种不同的机制把人放进回路：

chengflow/openapi.yaml 是 REST API 的 OpenAPI 3.0.3 规范，Makefile 能把它变成 Swagger UI、Redoc、Postman 集合、生成的 SDK、Markdo…

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

ChengOS 里有三样东西都叫「版本」，把它们混在一起会造成真实的困惑：

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

ui/rbacguard 决定用户能否抵达某条路由。它输出 GuardResult，连到 ui/route 节点的 guards 端口：

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

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