编辑器：测试运行与调试

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

你不需要部署工作流才能验证它是否可用。运行可以直接在编辑器里发起，事件在发生的同时通过 WebSocket 回传，因此调试是「观察然后阅读」，而不是从一个最终错误字符串里猜。

从编辑器运行

先保存，然后在控制面板中运行。当已有执行处于运行中、已暂停或等待评审状态时，运行会被阻止，因此你不会不小心把同一张图的两次运行叠在一起。如果工作流从未保存过，保存会作为运行的一部分完成。

观察运行过程

执行面板显示实时状态、进度和耗时。运行推进时画布会自我标注：每个节点依次经过 waiting → ready → running → completed / failed / skipped，而彼此之间没有依赖关系的节点会同时亮起——这往往是你第一次注意到自己的图比想象中更并行（或更不并行）。

流式节点会被特殊处理。模型节点逐 token 输出（NODE_STREAM_START，然后 NODE_STREAM_CHUNK，最后 NODE_STREAM_COMPLETE），所以你看到的是文字逐渐出现，而不是等待整段响应。

智能体节点上报的信息更多：每轮迭代的事件、工具调用的开始/完成/失败、轮次边界，以及上下文窗口状态。对智能体而言，这个事件流就是调试界面——参见 ReAct 智能体指南。

控制一次运行

waiting_for_review 是一个正常状态，不是卡住了：某个节点请求了人工决策。审批卡片会出现在面板中，你回答之后运行继续。

读懂一次失败

点击失败的节点。执行详情会显示错误以及该节点实际收到的输入，而后者通常就是决定性线索——多数失败源于某个值不符合你的预期，而非节点本身有问题。

从那里向外排查：

• 输入不对？ 问题在上游。顺着连线回溯，检查那个节点的输出。
• 输入没问题但节点失败了？ 问题在配置或外部服务。
• 节点被跳过了？ 某个条件分支绕过了它。这往往是正确的；如果不是，检查路由节点的条件。

日志查看器显示本次运行的日志输出，结果预览显示产出的值。开发过程中不妨插入 utils/preview 节点——预览节点的存在意义就是让中间值可见，而事后把它拿掉不会有任何代价。

轨迹

除了实时视图，每次执行都会保留一份持久轨迹：

轨迹能在浏览器刷新后留存，这对长时间的智能体运行很重要：关闭标签页不会丢失运行本身或其历史。编辑器会重新连接并重新加入事件流。如果事件流静默 30 秒，客户端会与 API 做一次对账，而不是无限等待——这样断开的连接会呈现真实状态，而不是一个转圈的图标。

常见的首次运行失败

下一步

• 执行模型——为什么节点按那个顺序运行。
• 执行失败排查——更深入的诊断路径。
• 节点配置——面板细节。