--- author: OOMOL author_url: https://oomol.com/zh-cn/about/ datePublished: 2026-10-06 title: AI Agent 时代，我们为什么还需要工作流？ description: Agent 也能通过定时任务运行。什么时候值得使用工作流？从固定业务规则、人工审批和版本维护出发，讨论 Open Flow 如何与 Agent 配合。 lang: zh-CN canonical_url: https://oomol.com/zh-cn/blog/open-flow-agent-era/ markdown_url: https://oomol.com/zh-cn/blog/open-flow-agent-era.md --- ![AI Agent 探索任务路径，并将明确的方法组织成包含触发、处理、审批和通知的工作流](/blog/open-flow-agent-era/zh-cn-cover.webp) 每天早上九点，让 Agent 分析订单并发送报告，配置一个定时任务就能启动。接入事件或 Webhook，也可以让它在数据变化后开始工作。 如果报告符合预期，处理过程也很简单，这样可能就够了。 运行一段时间后，要求可能变得更具体：退款率必须按统一口径计算，只分析指定范围的数据，给客户发送消息前必须审批。统计规则修改后，还需要查清哪些报告使用了旧版本。 这时要考虑的是：哪些步骤允许 Agent 当场判断，哪些步骤需要按已经确认的规则执行？任务等待审批时，状态存在哪里？换一个人维护，能否看懂它的处理过程？ 工作流提供了一种组织这些要求的方式。它把步骤、数据关系和审批条件明确保存下来，并由运行系统管理执行状态。Agent 可以参与构建，也可以在其中处理需要理解和判断的任务。 ## 已经确认的规则，按同一种方式执行 以订单日报为例，金额求和、状态分类、时间范围筛选，都有明确的规则。退款率的分母是全部订单，还是已支付订单？按下单时间还是退款时间统计？这些口径一旦确认，就应该落实到代码里。 Agent 也能调用这段代码。工作流进一步把它和其他步骤的关系保存下来：从哪里取数，计算结果交给哪个节点，什么条件下继续发送报告。检查时，可以逐项核对。 客户留言表达了什么、异常可能与哪些情况有关、摘要应该强调哪些内容，则可以交给 AI。比如先用代码筛选异常订单，再将这些记录作为模型输入，最后把摘要交给通知步骤。 这里的确定性体现在计算规则和执行结构上。模型生成的判断仍然可能变化，但它接收什么数据、承担什么任务，以及输出用于哪里，都有明确的位置。 ## 等待审批时，任务不能丢掉进度 把场景换成客户回复：Agent 已经读完邮件、查过订单，也起草好了回复，接下来等负责人批准。 负责人可能几个小时后才处理。系统需要保存这次任务使用的输入、已经生成的回复、完成到哪一步，以及批准或拒绝后该执行什么。恢复任务时，也应沿用这次运行的状态，避免重新执行前面已经完成的步骤。 这些机制可以在 Agent 系统中实现。选择工作流平台时，值得检查的是它已经提供了哪些状态管理能力，能否满足任务中途等待、人工决定和继续执行的需要。 Trigger 负责启动，通知或后续接口调用负责交付结果。定时、事件、Webhook 和轮询都可以用于启动 Agent 或流程；它们是自动化的组成部分。下面的流程图展示了启动之后，规则、AI、审批和通知如何连接。 ![定时、事件或轮询触发流程，依次获取数据、按规则处理、进行 AI 分析、按需审批，并通知结果](/blog/open-flow-agent-era/zh-cn-lifecycle.webp) *这是可自行构建的示例流程。触发方式按任务选择，审批为可选步骤；实际运行需配置数据源、模型服务和通知账号。* Open Flow 的 Approval 和 Wait 节点会持久化等待状态，确认后可以继续同一次运行，无需重跑已经完成的步骤。对于需要人工介入的任务，这是选择它时可以具体评估的能力。[查看审批与运行说明](https://github.com/oomol-lab/open-flow/blob/main/docs/README.zh-CN.md) ## 换一个人维护，还能看懂这项工作吗？ 任务刚开始时，你可能先让 Agent 试做几次，逐渐确认数据源、统计口径和报告格式。等其他人也要参与维护，就需要把这些决定留下来。 ![Agent 试做任务后，将固定规则、AI 输入和审批条件整理成可检查、可维护的流程](/blog/open-flow-agent-era/zh-cn-collaboration.webp) 维护者需要知道：哪个步骤读取订单，退款率在哪里计算，模型拿到了哪些数据，什么条件下会发送消息。流程图、输入映射和节点代码可以帮助回答这些问题。具体项目的说明和配置也要有人维护。 修改之后，还要知道每次运行使用了哪一版逻辑。例如，退款率的统计口径周一调整了，查看上周的日报时，就需要找到当时的代码和输入。把运行记录关联到具体版本，才能据此核对结果。 如果现有 Agent 系统已经提供了这些能力，可以继续沿用。工作流平台的价值，是把这些常用机制组织在一起，减少团队自行搭建和维护的工作。 ## 用 Open Flow 保存和运行这些流程 Open Flow 是 OOMOL 开源的工作流平台。你可以直接在 [OOMOL Flow](https://console.oomol.com/flows) 使用官方托管版，或到 [GitHub 仓库](https://github.com/oomol-lab/open-flow)查看源码与自部署说明。让 Agent 创建 Flow 后，可以在可视化工作台 Workbench 中查看和修改同一个流程。 Agent 通过 `oo flow` 创建节点、检查草稿、测试运行并查看结果。你打开 Workbench 后，可以检查它使用了哪些数据，某一步的代码如何处理，以及分支条件是否符合要求。兼容客户端也可以通过 Server 提供的 MCP 工具进行编排和运行。 对于前面的日报，Code Task 可以用 JavaScript 计算和转换数据，LLM Task 生成摘要。如果需要多次工具调用，可以使用 Agent Task。输入和输出具有明确的名称与类型，重复逻辑可以整理成子流程。 上线后，你还会需要修改流程。Open Flow 发布时会创建带版本的快照，供 Live 自动化运行。你可以继续编辑和测试草稿，准备好后再发布新版本。运行历史关联对应的修订版本，便于查明某份报告由哪一版代码和流程生成。 读取外部应用的数据和发送通知，需要配置相应账号与权限。Open Flow 通过 OpenConnector 等 Connector 运行时执行这些操作，账号凭据由 Connector 保管，Flow 引用连接标识。[查看 Open Flow 的能力与运行方式](https://github.com/oomol-lab/open-flow/blob/main/docs/README.zh-CN.md) 官方托管版由 OOMOL 负责运行部署。自行部署时，存储、备份、升级和服务连接由你的团队管理。项目采用 Apache-2.0 许可证，目前处于 Beta。账号连接与 Agent 配置步骤见 [Flow 入门指南](https://oomol.com/zh-cn/docs/flow/)。 ### 用一项实际任务试试 选一件需要固定规则或人工审批的重复工作，在 [OOMOL Flow](https://console.oomol.com/flows) 打开工作流，连接所需的数据源与通知账号，再把任务交给 Agent： > 为我创建一个订单日报 Flow：读取前一天的订单，按我确认的口径计算金额和退款率，让 AI 总结异常，再把报告发到指定的团队群。先创建草稿并测试，等我检查结果后再发布。 在 Workbench 中检查数据、代码和输出，确认这套流程符合你的要求。如果定时 Agent 已经够用，可以继续沿用；需要更明确的规则、审批和版本记录时，再决定启用这个 Flow。 - **[打开 OOMOL Flow，创建第一个工作流](https://console.oomol.com/flows)** - 希望自行部署或参与开发？[查看 Open Flow 源码与部署说明](https://github.com/oomol-lab/open-flow)。