应用发布工作流

适用版本：ChengOS v0.1.0+ ｜ 最后核对：2026-08-12 ｜ 来源：chengflow-ui/src/features/apps、crates/cheng-nodes/src/nodes/builtin/ui、crates/cheng-api/src/rest/handlers/ui_routes

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

三种发布方式

按受众来选：

让工作流具备可发布条件

先做两件事，顺序如下。

把状态设为 active。 新建的工作流是 draft。draft 用于搭建；active 声明它已可被执行、可被其他东西引用。发布了一个 draft，是「已发布应用看起来什么也不做」最常见的原因。

确定入口点。 由哪个节点接收外部输入，决定了什么样的发布形态是合理的——表单用 io/input_text，对话用 chat/input，外部应用消息用 GatewayReceiverNode。

构建页面

九个 ui/* 节点组合成一个页面。它们是静态页面骨架生成器，而不是运行时页面引擎：它们收集配置并输出可序列化的 PageLayout JSON。所有运行时工作——加载页面配置、应用运营层覆盖、执行 data loader——都由前端负责。

正是这种拆分让页面很快：校验全部在构建时完成，运行时零成本。

把各区域节点连进 ui/page_root，再用一个 ui/route 给它一个路径。已发布的路由通过 GET /api/v1/routes/by-path 解析。

ui/page_root 分三层校验，全部在构建时完成：字段格式（hex 颜色、URL、枚举值）、区域依赖（布局模板与你实际提供的区域相冲突），以及深层语义检查（菜单项 key 重复、modal id 冲突）。一个会渲染出错的页面会直接构建失败。

访问控制

ui/rbac_guard 输出一个 GuardResult，连接到 ui/route 节点的 guards 端口。规则可以检查角色、检查权限、匹配用户属性或求值动态表达式，并且每个 guard 都声明自己的失败动作——因此「无权限」可以是跳转，而不是走进死胡同。

Guard 在服务端求值。guard 是访问控制决策，不是界面提示：在浏览器里隐藏一个控件不构成保护，真正拦住请求的是 guard。

发布为对话界面

除了构建页面，你也可以把工作流绑定到一个渠道，由网关渲染对话界面。渠道带有 channelId（消息来自哪个应用）和 boundWorkflowId（运行哪个工作流）——在渠道配置阶段绑定，绝不推断。参见网关模型和 SDK 快速开始。

WhatsApp、Telegram、Slack、钉钉和企业微信都走这条路线（它们都有第一方适配器），嵌入式网页组件也是。

发布为 API

任何 active 工作流本身就可以通过 REST 执行：

curl -X POST http://127.0.0.1:3000/api/v1/executions \
  -H 'Authorization: Bearer <token>' \
  -H 'X-Workspace-Id: <workspace-uuid>' \
  -H 'Content-Type: application/json' \
  -d '{"workflow_id": "<uuid>", "inputs": {"user_input": "hello"}}'

订阅 /ws/executions 获取实时结果，或轮询 GET /api/v1/executions/:id。在 MCP_ENABLED=true 时，工作流还会暴露为 MCP 工具，于是外部智能体调用你的工作流，就像你的智能体调用任何东西一样。

模板

把工作流标记为模板，可以让它成为别人的起点（PUT /api/v1/workflows/:id/template）。GET /api/v1/workflows/templates 是公开且无需认证的，这正是模板库能在登录之前加载出来的原因。

下一步

• 网关模型——应用、渠道与会话。
• SDK 快速开始——嵌入一个对话界面。
• REST API 总览——支撑上述一切的接口。