ChengOS 有四种凭证类型，各司其职。大多数 401 和 403 的困惑都源于用错了类型，因此在开始排查之前值得先通读下表。

本文是一张地图：有哪些进程、后端由哪些 crate 组成，以及这些进程可以被编排成哪些部署形态。

chat/input 与 chat/output 是对话式工作流的两端：前者接收进来的消息与会话身份， 后者把回复送回同一个会话。chat/historysearch 是读取侧 —— 列出会话、检索消息，或取出某条命中附…

把技能当作可构建、可校验的对象，而不只是拿来运行。tools/skill 执行一个技能。 tools/writeskillpackage 产出技能包，tools/validateskillspec 在有人尝试发布或导入之…

工作区是其他一切的容器——文档、表格、会话、文件和知识库。知识库则是工作区范围内的向量集合：工作区中可被检索的那一半。

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

ChengOS 里的 RAG 就是五个节点、两条管线。索引管线在文档变化时运行；检索管线在每次提问时运行。二者在运行时除了共享读写的那个知识库之外，别无关联。

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

模型供应商在每套安装中配置一次，之后按节点选用。本文介绍供应商白名单、各供应商实际具备的能力，以及凭证如何挂接。

三个守住执行边界的节点。utils/credential 以引用方式注入已保存的密钥 —— 正因为有它，任何工作流都不需要把 API Key 明文填进普通字段。utils/approver 会让执行停下来等待人工判断， …