Cloudflare Agents 与 Workflows 的比较，在交互式助手开始执行超出对话时长的工作时尤其有用。智能体可能需要解释进展，后台过程则需要应对中断并等待批准。这些责任相互关联，却具有不同的生命周期。
使用 Agents 提供持续交互的身份，接收事件并与用户交流。当执行模式适合时，使用 Workflows 运行持久的后台步骤序列，包括等待和重试。当对话与长期任务需要独立推进时，可以组合两者，并让外部业务影响始终能够明确核对。
设想员工申请一项供应商评估。助手询问缺失信息并显示状态，评估任务收集记录、准备报告，再等待同事作出决定。关闭浏览器不应丢失任务，重新连接也不应再次启动评估。
本文用这个假设设计解释边界，不假定每个助手都需要两种产品，也不认为持久执行会使所有外部操作都能安全重复。
Cloudflare Agents 与 Workflows：比较生命周期
Cloudflare 的 Agents 与 Workflows 文档 描述了互补角色：Agents 支持持续交互与身份，Workflows 支持持久后台执行。选择起始模板之前，应先根据这些角色作出选择。
对于供应商评估，对话有面向员工的生命周期，任务则有业务生命周期。员工可能断开连接，另一位有权限的同事可能复核结果，而原始聊天结束后，评估仍可能继续等待。
| 要求 | Agent 的责任 | Workflow 的责任 |
|---|---|---|
| 向员工提问澄清 | 展示问题并接收回复 | 在适当时等待必需任务输入 |
| 显示进展 | 展示当前任务状态 | 记录已定义步骤中的进展 |
| 应对浏览器关闭 | 将已授权用户重新连接到任务 | 按执行契约继续或等待 |
| 处理批准 | 展示精确建议与调用者上下文 | 按任务规则执行获准状态转换 |
| 解释失败 | 为用户提供有用下一步 | 保留失败阶段与恢复证据 |
表格描述的是建议分工，并不意味着采用 SDK 就会自动获得应用权限模型或业务状态台账。
从任务记录开始，而不是聊天记录
为评估分配稳定的任务编号。以无须重读对话即可理解的形式，存储负责人、来源版本、请求结果与当前状态。聊天记录可以解释意图，但不应成为已接受工作的唯一记录。
用户界面应区分正在讨论的请求与已被接受的任务。如果员工点击提交后响应丢失，重连时必须能确认任务是否存在。让模型从最后一条聊天消息推断这一点并不可靠。
定义对流程负责人有意义的状态，例如等待输入、收集证据、待复核、已批准、已拒绝和失败。明确谁可以转换状态，以及需要什么证据。
任务编号应在对话界面改变后仍然有效。之后的邮件或仪表盘可以展示同一项已接受评估，但不能成为决定任务行为的第二个权威来源。
让持久步骤足够小，以便解释
Workflows 概览 介绍了持久的多步骤执行。将这一能力用于输入、输出和恢复行为明确的步骤。若一个巨大步骤同时收集来源、生成文字并修改多个系统，失败时就很难检查。
对于评估，应将获取来源记录、生成报告和执行已批准业务决策分开。记录报告基于哪些来源版本。来源变化后的重试，应遵循明确策略，不能悄悄生成不同评估。
不能将持久保存的步骤结果，与外部副作用已经发生的证据混淆。目标系统可能刚接受请求，调用进程就丢失响应。应用需要操作编号或其他核对方式来确定发生了什么。
能够让下一步明确的步骤边界才有用。如果运维人员无法判断应重试、更新证据还是联系复核者，边界很可能缺少业务上下文。
将批准作为版本化业务事件
批准应对应精确评估版本与拟议后果。如果复核者打开页面后，来源记录或报告发生变化，应要求应用先解决不一致，再继续执行。
事件到达时，应认证复核者并检查其任务权限。标识评估的 URL 不足以构成批准权限。不要让工具结果或生成的句子替代同事批准。
| 批准条件 | 预期响应 |
|---|---|
| 当前报告且复核者有权限 | 接受允许的状态转换 |
| 打开页面后报告被替换 | 要求复核当前版本 |
| 重复批准事件 | 返回已确认结果，不产生另一次影响 |
| 复核者已无权限 | 拒绝状态转换 |
| 评估已被拒绝或取消 | 遵循已记录的终态策略 |
取消也应类似处理。停止未来步骤，并不一定撤销外部系统已经接受的请求。向用户说明哪些工作已停止，哪些结果仍需核对。
从权威状态重新连接
员工返回时，按其当前权限加载任务状态，显示最近记录的阶段与观察时间。对话摘要可以提供帮助，但不应根据猜测覆盖任务记录。
将进展通知与权威状态分开。错过通知不应意味着错过任务状态转换；反过来，收到通知也不应授权收件人查看底层供应商记录。
测试等待期间、失败之后，以及另一位同事操作之后的重连。加入试图提交旧决定的过时浏览器标签页。这些是跨班次、跨团队业务流程的正常运行条件。
关于更广泛的结果测试，我们的智能体评估指南 解释了为什么仅有工具调用成功还不够。这里的关键，是正确任务是否继续，以及用户是否看到真实状态。
选择满足需求的最小架构
执行简短查询的助手，未必需要单独后台工作流；定时数据转换，未必需要对话智能体。同时添加两者，会增加需要维护的配置、状态关系与事故路径。
| 负载 | 合理起点 | 添加另一层的理由 |
|---|---|---|
| 交互式查询 | 已认证应用或智能体 | 工作必须在交互之后继续 |
| 定时处理 | 后台工作流 | 用户需要实时任务交互 |
| 批准较多的评估 | 独立任务状态与持久处理 | 智能体可改善澄清和状态展示 |
| 开放式对话 | 具有有限工具的智能体 | 某项已接受任务需要独立执行 |
架构应使责任更清晰。如果没人能解释是智能体还是工作流负责当前任务状态，应先写明契约，再增加工具调用。
为协调和故障测试编制预算
系统数量、任务转换、批准角色及外部不确定结果越多，实施成本越高。聊天文字数量不能很好地代表这些工作。
要求 GBP 估算，分别列出任务设计、智能体交互、工作流执行、目标集成与验收。计入依赖版本维护，以及部署时处理已在运行任务的流程。
应为选定服务和负载核实当前用量费用，分别估算等待、重复尝试、推理、存储与观察工作。很少运行的后台任务，仍可能因为业务后果重要而需要细致支持。
有用的试点应演示关闭浏览器、进程中断、重复批准与目标超时，并让运维人员无需重建聊天就能找到评估、确定下一项安全操作。
我们可以通过范围明确的 AI 集成试点 定义这一契约。请提供任务阶段、关联系统和批准角色，索取智能体工作流方案 。让运行时选择服从团队实际需要完成的工作。
常见问题
Agents 与 Workflows 是竞争产品吗？ 两者优势不同，也能协同工作。Agents 适合持续交互与身份，Workflows 适合持久后台步骤序列。应根据应用生命周期选择组合，不能假设每项任务都需要两者。
每个 AI 助手都需要 Workflow 吗？ 不是。简短交互任务可能无需它即可处理。当已接受工作必须独立继续、等待事件或通过明确阶段恢复时，再考虑持久后台处理。
持久执行能防止重复业务操作吗？ 仍须仔细判断外部系统的行为。即使响应丢失，目标仍可能完成请求。对有重大影响的操作，应使用稳定操作编号和已记录的核对策略。
批准状态应该存在哪里？ 存放在关联精确建议版本和复核者的权威任务记录中。对话可以展示并解释决定，但不应成为批准的唯一记录。
用户关闭浏览器后会怎样？ 应用应独立于连接保留已接受工作。用户返回时，认证用户并加载当前任务状态，而不是重启作业或让模型猜测进展。
试点应该测试什么？ 测试正常流程，以及断开连接、处理中断、过时批准、重复事件与目标结果不确定。报告应说明每个状态由哪个组件负责，以及运维人员如何恢复。
组合实现需要多少钱？ 成本取决于任务转换、系统集成、权限角色与恢复要求。应索取范围明确的 GBP 估算，分别列出交互、处理、验收与支持工作，而不是只按聊天功能报价。