预定义的工作流
这就涉及工作流与自主 Agent 的区别。
先想象一项比较固定的工作：每次选中一场会议，把会议资料整理成通知，保存为草稿。用户已经选定了具体会议，输出格式和保存位置也有明确规定。
开发者可以预先安排：
读取选中会议 → 检查必要字段 → 生成通知 → 核对内容 → 保存草稿
这些步骤连接起来，就是一个工作流。工作流把任务安排成预先定义的处理过程，程序按照设计好的顺序和条件，组织各个步骤。
这里的“预先定义”，不意味着每次输入、输出都一样。不同会议会有不同的日期和地点，模型生成的句子也可能不同，但执行路径的主要安排，是开发者事先设计的。
例如，通知格式可以要求包含会议主题、日期、时间和地点。生成通知这一环节使用语言模型，保存文件这一环节使用普通程序。整个工作流虽然用了 AI，仍然可以保持明确的步骤结构。
工作流也可以有分支。
如果会议资料缺少地点，程序可以走“提示补充地点”的路径；如果所有字段齐全，就继续生成；如果文件名已经存在，就按事先规定的规则处理。这些分支可以让流程适应多种情况。
工作流还可以包含循环。例如，检查通知是否遗漏日期；如果遗漏，则把检查结果交回生成环节再修改，达到重试上限就停止。存在循环，并不会自动把一个工作流变成自主 Agent。
判断时需要关注：后续步骤的选择空间由谁安排，模型又参与决定了多少。 不能只看有没有循环、分支或者工具调用。工作流中的预定义步骤与条件分支
Agent 中的动态选择
接着把任务稍微换一下。用户说：
请查清下一次项目例会的安排。资料如果有冲突，继续核对，最后整理出可以使用的通知草稿。
这次，用户没有提前选中具体会议。系统可能从日历里找到两场相似记录，也可能发现日历和项目文档写着不同时间。需要读取哪些资料、查几次、是否需要追问，都受到实际结果影响。
如果采用大模型 Agent 的组织方式，模型可以根据当前信息，参与选择下一步：先查看候选会议详情，还是读取最近更新的项目文档；已有证据是否足够，还是需要继续核实。
在本系列采用的工程区分中，自主 Agent 更强调模型根据任务与中间结果，动态参与安排过程和工具使用。 这里的“自主”指被允许的选择空间，并不意味着它不受程序控制。工作流与 Agent 的架构区分
路线、复杂度与模型路由
用这个例子比较两种方式，会更容易理解。
一种工作流可以规定：始终先查日历，再查项目文档；若时间不一致，就交给用户确认。这条路径对开发者来说比较明确，遇到预料之外的情况时，需要修改流程或交给其他处理机制。
Agent 可以得到“找到有依据的会议安排”这一目标，以及查询工具、资料范围和停止条件。它在读取资料后，根据得到的内容，决定下一项有用的操作。执行路径有一部分在运行时才确定。
但这不表示 Agent 面对任何冲突，都能可靠地判断谁对谁错。日历和文档也许分别记录了不同会议，也许某份资料已经过期。模型需要利用可用依据，而系统要允许它表达仍然无法确认的部分。
同样，工作流也不一定简单或能力弱。一个设计周全的工作流，可以处理很多已知情况，接入多个模型、工具和人工环节。固定路径在重复性强、要求稳定的任务里，往往很有价值。
相反，一个任务步骤不多，也可以包含模型的动态选择。Agent 的区别不取决于代码有几行、界面看起来多复杂，或者输出有多长。
还有一种特别容易混淆的情况：让模型选择几个事先定义好的分支。
例如，模型先判断用户是在“新建通知”“修改通知”还是“查询草稿”，程序再把请求交给对应流程。模型确实作了分类，但后续路线仍然主要由开发者预先组织。
这类设计通常称为路由，是工作流常见的一种组织方法。它说明，模型参与了一次判断，不等于整个系统都具备很高的自主程度。分析时要看完整执行过程，而不是单独截取某一次模型调用。模型路由与工作流组合
组合方式与权限边界
真实系统还可以把两种方式组合起来。
例如，应用先通过固定步骤验证账号和工具权限，再让一个受限 Agent 查清会议安排；资料足够以后，使用固定格式生成草稿，再由程序检查必要字段并保存。
在这个设计里，开放一些的是资料查证过程，而登录检查、权限边界和最终保存规则仍然明确。没有必要把整套软件都变成同一种执行方式。
当人们说“这个 Agent 很自主”时，也可以继续追问：它能自主选择资料，还是能自主决定发给谁？它能修改草稿，还是能修改日历？不同动作对应不同权限，不能把一个环节的自主性推广到所有环节。
对于会议通知，系统可以允许它自行读取已有授权范围内的资料、比较内容和生成草稿，但发送通知仍然按具体授权执行。是否需要人工参与，应结合实际要求和操作影响设计，不能机械地让每一次查询都等待批准。
怎样按任务做取舍
工作流与 Agent 的取舍，也需要看任务本身。
如果用户已经选定会议，字段完整，目标只是生成规定格式的通知，一个清楚的工作流可能就足够。把本来确定的路径交给模型反复选择，未必带来额外收益，还可能增加调用和检查工作。
如果每次需要阅读的资料、查证顺序和后续动作都明显不同，允许模型动态组织过程，才可能帮助系统应对这些变化。是否真的更有效，需要在代表性的任务上比较完成率、耗时、费用和错误情况。
所以，选择之前应先说明任务的变化来自哪里。变化的是通知文案，可能只需要一个模型调用；变化的是几个明确类别，可能适合路由；变化的是查证过程中不断出现的新问题，才值得进一步考虑 Agent 的动态处理。
“能处理变化”也不意味着没有边界。系统仍然需要限定资料范围、可用动作和停止条件。在规定范围内找不到答案时，说明缺少什么，比不断换关键词继续查更有用。
流程与运行设施
学习时还可以把“流程”和“运行设施”分开。流程说明任务怎样推进；运行设施负责让它真正运行，包括接收结果、保存状态、处理超时或暂停。无论采用工作流还是 Agent，这些工程问题都可能存在。
因此，我们不必给每一个产品贴上绝对标签。不同资料会使用不同范围的 Agent 定义，一些产品也同时具备多种执行方式。对理解和开发更有帮助的，是把具体路径画出来，找出预先规定的部分和运行时决定的部分。
以后看到一个演示，可以试着观察它遇到新情况以后怎样处理。是从既定分支里选一条，还是会根据证据组织新的工具使用过程？它是否能把结果接回后续步骤？程序又限制了哪些动作？这些细节比产品名字更能说明系统的工作方式。
下一篇进入 01.08：目标、环境、观察、动作与反馈。我们会把会议任务中的这些要素逐一对应起来，进一步理解 Agent 究竟在与什么交互。
当前学习编号：01.07 工作流与自主 Agent 的区别。
下一学习编号：01.08 目标、环境、观察、动作与反馈。后续还有其他学习编号。
关联分支：预定义路径关联 18.05 路由与条件分支、18.06 顺序、并行与扇出汇总、18.07 状态机与有向图编排；动态组织关联 18.03 任务拆解与依赖关系、18.04 Plan-and-Execute、18.08 计划修订与失败重规划。
自主程度与实际取舍，还关联 01.11 自主程度与人工参与边界、01.12 Agent 的适用条件与复杂度取舍、18.10 停止条件与完成判定、23.17 时延、吞吐、成本与质量权衡、26.08 框架、平台与直接 API 的取舍。