最近在做 Workrun 的时候，我越来越频繁地问自己一个问题：
用户只是想完成一件事，为什么要先学会搭建一个工作流？
这个问题有点尴尬，因为 Workrun 原本就在做这件事：提供一个可视化画布，让用户添加节点、配置模型、接入工具，再通过连线把它们组织成可以执行的流程。
从工程角度看，这套设计很自然。节点承担处理逻辑，连线表达执行顺序，状态负责数据共享。需要模型就放一个 Agent 节点，需要调用应用就接入对应能力，需要人工参与就增加一个交互节点。
但随着功能逐渐丰富，我发现，Workrun 虽然提供了不少 AI 能力，使用方式却仍然很传统。
用户需要先理解系统，再想办法使用系统完成自己的工作。
这篇文章想聊聊我为什么开始重新设计 Workrun，以及目前的一些思考和实践。相关功能还在持续迭代，很多问题也没有最终答案。
有了 Agent 节点，应用就算 AI 化了吗？
最初，我把很多精力放在节点能力上。
Agent 能接哪些模型，工具如何挂载，MCP 如何接入，Skills 怎样使用，节点之间如何共享数据。这些工作都很重要，缺了它们，工作流就只能停留在画布上。
先看一个 Workrun 现有能力的演示：查询天气，再根据天气规划行程。这个流程通过可视化编辑器配置，节点负责不同的处理步骤，工具提供实际能力，连线组织执行顺序。
受素材大小限制，压缩后比较模糊，如果想查看更清楚的演示视频，可以直接进入 Workrun 的官网查看： workrun-docs.pages.dev/#an-everyda…
这个流程可以正常运行，但在点击运行之前，用户需要先把它搭建出来。
随着节点和能力越来越丰富，配置时需要做的选择也越来越多。面对一个任务，用户得先判断：
- 应该使用普通 Agent，还是具备代码执行能力的节点？
- 需要接入哪些工具？
- 输入文件怎样交给处理节点？
- 上一个节点的结果，怎样让下一个节点访问？
- 哪些字段应该作为最终输出？
对熟悉系统的人来说，这些配置都有明确的含义。但用户最初表达的需求，可能只有一句话：
帮我处理这份资料，整理成一份报告。
从这句话到一张可执行的流程图，中间还隔着一段不小的距离。而在原来的设计里，这段距离主要由用户自己走完。
我开始觉得，仅仅把模型放进节点，并没有充分改变这个应用的使用方式。
AI 已经能够理解自然语言、选择工具，也能够根据反馈修改方案。既然如此，Workrun 是否可以承担更多配置工作，让用户直接从目标开始？
我想先改变入口
重新设计时，我首先把目标放到了对话上。
用户打开 Workrun，可以直接说自己要做什么。系统理解任务、检查输入，再判断接下来应该怎样处理。
这里有一个很容易被忽略的细节：并不是每个任务都需要创建 Workflow。
如果用户只是临时处理一份文件，现有能力足以完成，那么直接完成就好。为了处理一次任务，先创建一个工作流，再执行它，会多出一份需要管理的定义。
只有当用户表达出复用或自动化的需要时，Workflow 才应该成为讨论的重点。
下面这段视频展示了我正在迭代的交互。我先上传一份销售数据，提出一个普通需求：
帮我分析一下这份销售数据。
这时，系统直接处理当前任务。随后，我补充了另一个需求：
以后要重复做，整理成流程，先不要运行。
系统由此进入规划阶段，检查可用能力，形成方案，等待用户确认后再创建 Workflow。
受素材大小限制，动图只展示最终的对话记录和生成结果，没有完整录下等待与执行过程。压缩后部分文字较小，下面会结合流程图说明设计。
动图对应的演示视频原件上传到了 Github，如果有需要可以自行查看（会触发下载）：github.com/1111mp/work…
整个过程中，用户表达的是自己要做什么，以及希望何时创建、是否运行。具体使用哪些节点、怎样配置工具、如何传递数据，由系统根据 Workrun 的实际能力决定。
其中，“先不要运行”是一个明确边界。创建完成后，用户得到的是一份可以查看、修改和重复使用的 Workflow。执行需要后续单独提出，不能因为流程已经保存，就自动开始运行。
这段演示也是近期开发中使用的测试场景之一。它能展示目前的交互方式，但自主编排的稳定性和结果正确性仍需要在更多任务中验证。
我希望产品逐步形成这样的处理路径：
graph TD
A[用户通过对话表达需求] --> B[主 Agent 理解目标并检查输入]
B --> C{是否需要复用或自动化}
C -->|一次性任务| D[使用现有能力直接处理]
D --> E[交付结果]
C -->|需要复用| F[发现已有 Workflow 和相关能力]
F --> G{已有流程是否适合}
G -->|适合| H[选择已有 Workflow]
G -->|不适合| I[规划并讨论方案]
I --> J[用户确认当前版本]
J --> K[配置 校验并保存 Workflow]
H --> L{当前是否授权执行}
K --> L
L -->|是| M[执行并交付实际结果]
L -->|否| N[保留定义 等待后续使用]
复用在这里同样重要。如果已有合适的 Workflow，就应该优先使用，而不是每次都重新生成。
这也是我现在对 Everything is workflow 的理解：系统能够把工作组织成流程，并在需要的时候将它沉淀下来。用户不必在每一次请求中主动考虑流程。
AI 主导编排之后，画布怎么办？
我并不打算放弃可视化编辑器。
自己开发和调试 Workrun 时，画布依然很有用。它能直接展示执行顺序、处理边界和节点配置。某个步骤失败了，也更容易找到问题发生在哪里。
只是它在产品中的角色需要调整。
过去，画布是用户表达需求的主要入口。以后，它可以更多地承担检查、修改和调试的职责。
AI 配好了一个 Workflow，用户可以打开它，查看实际使用了什么能力，修改某个节点的指令，调整分支条件，或者限制某些数据的访问范围。
这带来了一项很重要的设计要求：
AI 创建出来的 Workflow，应该与用户手动创建的 Workflow 使用同一套能力和配置。
我不希望维护两套系统。一套给用户在画布里使用，另一套藏在 Agent 后面，依靠特殊协议完成执行。
否则，之后很容易遇到一连串问题：自动生成的流程能不能在编辑器里修改？用户修改之后，Agent 能不能理解？两条执行路径的行为是否一致？
目前选择的方向是让 AI 配置普通的 Workflow。节点、连线、输入输出和状态权限，都沿用 Workrun 已有的原生能力。
这样，用户随时可以接手，系统也有一份明确的定义可以保存、检查和执行。
从一句话到一个流程，中间需要讨论
开始做对话式编排之后，我发现，“理解一句话，然后生成流程”这个描述还是过于简单了。
用户的输入经常是不完整的。一次性任务中可以接受的临时判断，放进一个要反复执行的流程里，可能就成了长期存在的错误假设。
例如：
- 以后输入文件的格式会不会变化？
- 遇到缺失数据，应该停止还是继续？
- 结果需要一段文字，还是一个供其他系统读取的文件？
- 某些外部操作是否需要人工确认？
这些问题不能全部交给模型猜，也不适合变成一张冗长的必填表单。
我更希望模型能够判断：哪些信息可以自己检查，哪些可以采用明确的默认值，哪些确实需要用户决定。
因此，目前采用了三个 Agent 分工：
| 角色 | 主要职责 |
|---|---|
| 主 Agent | 理解意图、处理直接任务、维持对话并协调后续动作 |
| Planning Agent | 发现能力、检查输入、提出问题、形成并修订方案 |
| Workflow Agent | 根据已确认方案完成配置、校验和保存 |
实现上使用 adk-rust 的原生 sub_agent 机制。各自的代码、工具和 Skills 分开组织，能够执行的动作也有不同边界。
规划阶段允许探索和调整。真正进入编排阶段时，则需要依据用户确认的内容落地。
整体协作过程如下：
graph TD
A[用户提出复用需求] --> B[主 Agent]
B -->|委托规划| C[Planning Agent]
C --> D[发现能力 检查输入 形成方案]
D --> E[保存方案版本]
E --> F[原生检查点暂停 展示方案卡片]
F --> G{用户反馈}
G -->|补充信息或修改| H[Planning Agent 修订方案]
H --> E
G -->|确认当前版本| I[原生机制记录创建授权]
I --> J[主 Agent 委托 Workflow Agent]
J --> K[配置节点 校验并修复]
K --> L[保存普通 Workflow]
L --> M[返回 Workflow ID 与未验证事项]
用户不需要告诉 Planning Agent 应该选择哪种节点。但如果不同选择会明显改变结果、成本或外部影响，系统就应该解释清楚。
同时，回答问题不能被当作确认方案。
用户补充了一个条件，只说明方案获得了新信息，并不意味着用户已经接受修改后的全部内容。
确认之后创建，创建之后也不一定执行
这部分看起来像交互细节，实际实现时却很容易出问题。
用户说“整理成流程，先不要运行”，至少包含两个独立要求：创建一个可复用的定义，以及暂时不要执行它。
方案确认又是更前面的一步。
目前，我通过 ADK Graph 和 SQLite 检查点管理这段生命周期。保存方案后，调用会在原生检查点暂停，由界面展示方案卡片。用户可以继续反馈，也可以确认当前版本。
确认后，才进入 Workflow 的配置和保存阶段。
这里没有让模型再生成一遍方案总结。已经有了一份可以审查的方案，就让它成为这个阶段的交付物。
执行授权单独处理。Workflow 保存成功后，系统返回定义和保存结果，等待用户后续提出运行请求。
这种区分也会影响后续对话。
用户要求运行一个已有流程，不能顺带获得重新创建或修改它的授权。某个流程尚未创建，系统也不能因为收到一句“执行一下”，就跳过方案确认。
这些边界仅靠提示词约定并不够，所以我把它们落实在原生任务状态和检查点机制中。模型负责理解与决策，系统负责约束当前可以发生的动作。
模型需要先理解 Workrun
自主编排过程中，一个很直接的教训是：不能假设模型天然知道如何使用这个产品。
模型可能知道工作流是什么，也熟悉常见的 Agent 框架，但这些知识未必对应 Workrun 的实际行为。
以数据传递为例，Workrun 已经有自己的状态机制：
- 运行输入进入 global state。
- 节点输出默认位于私有 namespace。
- 需要共享时，可以发布到 global，或者配置允许访问的节点。
- 执行顺序由连线决定，数据可见性由状态配置决定。
这些能力本来就存在。自主编排需要做的是理解它们，然后配置它们。
如果模型配置错了，就再增加一套自动映射或隐式传递逻辑，系统会逐渐变得难以解释。用户在画布里看到一套规则，实际运行却可能依靠另一套处理才能成功。
所以，我开始把现有能力整理成模型可以按需读取的资料。
目前大致分为四层：
| 资料 | 回答的问题 |
|---|---|
| 能力总览 | Workrun 有哪些能力，应该去哪里发现？ |
| 角色 Skills | 如何规划、配置和交付？ |
| 节点参考 | 某个节点支持哪些字段，有什么限制？ |
| 动态资源发现 | 当前工作区实际有哪些模型、App、工具和 Skills？ |
静态资料与动态发现共同支持编排，最终仍然落到同一份原生定义上：
graph TD
A[角色 Skills 与共享能力总览] -.-> B[规划与编排 Agent]
C[原生节点契约] --> D[生成的节点参考]
D -.->|按需读取| B
E[工作区动态资源发现] -.->|真实 ID 与资源契约| B
B --> F[原生 Workflow 文档]
F --> G[结构校验与原生编译]
G -->|发现问题| B
G -->|校验通过后保存| H[普通 Workflow 目录]
H --> I[可视化编辑器]
I -->|修改并保存| H
H -->|单独授权执行| J[原生 Workflow 执行器]
J --> K[运行回执 输出与文件产物]
节点参考尽量从原生契约生成，由 generate-workflow-reference.mjs 集成进开发和打包流程。这样可以减少手写文档与代码分别维护带来的偏差。
读取时先提供摘要，需要使用某个节点，再加载详细内容。像 CodeAct 这样的受限运行环境，也需要让模型在规划和配置时了解其支持范围，不能凭一般的 Python 使用经验猜测依赖是否可用。
静态资料不能代替动态发现。文档里介绍了某种工具，不代表用户当前已经安装、配置好了它。
同样，给一个 Agent 配置了 Skill，也不能想当然地认为它已经具备 Skill 所描述的执行能力。它依赖哪些工具、工具是否可用、是否实际配置到了节点上，都需要检查。
“流程跑完了”只是验证的开始
实际测试中，最让我警惕的不是执行报错，而是流程显示完成，输出却没有满足需求。
这类问题有时很隐蔽。
一个普通 Agent 可以生成结构完整、语言流畅的报告。即使没有执行可靠的计算，它也可能写出“已完成自动化计算”。运行系统看到节点正常返回，会将这一轮标记为完成。
但用户关心的是结果对不对。
这让我逐渐把几个判断拆开：
| 判断 | 能说明什么 |
|---|---|
| 配置校验通过 | 当前定义被校验器和编译器接受 |
| 节点执行完成 | 技术执行正常结束 |
| 所需输出存在 | 声明的结果实际产生 |
| 验收条件得到验证 | 有证据支持任务达成 |
它们需要不同的证据。
结构校验可以发现字段、连接和资源引用的问题，却不能保证处理方法合理。执行完成可以证明技术链路结束，却不能证明计算、解释或外部操作符合预期。
尤其是需要精确、可重复处理的工作，必须有真正适合的执行能力。指令里写着“请准确计算”，并不会让普通模型节点自动获得计算工具。
我也不希望因此规定所有任务必须使用某一种节点。语言生成、数据转换、工具查询、文件处理，本来就有不同的需求。系统应该提供清楚的能力契约，让模型选择合适的方法，再根据任务留下必要的结果和验证证据。
目前已经有一些本地测试，用来检查角色隔离、方案确认、原生状态、暂停恢复和子 Workflow 复用等行为。
不过，这些测试有明确边界。它们能验证机制，不能据此宣布模型已经具备稳定的自主编排能力。后者还需要在不同任务和不同输入下持续评估。
增加更多规则，也可能让事情变复杂
迭代过程中，我也走过一段弯路。
每发现一个问题，就很容易想到再补一段提示词、增加一份记录，或者加入一个新的检查机制。单独看，每项都有理由；放在一起，系统却越来越难理解。
后来我做了一轮减法审查。
有些诊断能力进入了正常请求的关键路径，有些上下文会自动回放大量历史内容，角色说明和 Skills 里也出现了不少重复要求。
它们增加了维护成本，却没有直接证明自主编排变得更可靠。
于是，我撤掉了部分额外机制，也重新压缩了知识资料：
- 角色说明集中表达职责、授权和交接边界。
- Skills 说明工作方法与必要步骤。
- 具体字段和限制留在原生参考中。
- 真实资源信息通过动态发现取得。
这次调整没有改变节点的状态机制，也没有增加新的工作流协议。
我现在更关注一个实际问题：模型需要某条信息时，能否找到明确、准确的来源？
文档更多不一定更好，文本更短也不能直接等同于效果更好。最终仍然要看它能不能被正确理解，并落实为可用配置。
我现在怎样看待手动编排
回到标题里的问题：AI 时代，我们还需要手动编排 Workflow 吗？
我的答案是，仍然需要保留，但不应该要求每个用户从这里开始。
对熟悉系统、需要精细控制的人来说，手动编辑会一直有价值。对于只想表达目标、获得结果的人来说，系统应该承担更多理解和配置工作。
Workrun 这次重设计，尝试让这两种使用方式共存：
用户从对话开始，和系统一起明确需求；AI 发现已有能力，提出方案，在确认后配置出普通的 Workflow；需要检查、修改或调试时，再回到可视化编辑器。
目前这条链路正在逐步落地，自主编排的稳定性、能力选择和结果验证还在持续迭代。我还不能说，用户随便描述一件事，Workrun 就一定能够生成一个可靠的自动化流程。
但现在的方向比之前更清楚了。
我希望用户最终保存下来的，是一份自己看得懂、改得动，并且换一份输入仍然有用的工作流程。为了得到它，用户不必先学会 Workrun 的每一个配置项。
👉 Workrun GitHub 项目地址：github.com/1111mp/work…
👉 Workrun 官网地址：workrun-docs.pages.dev
