判断资料任务该用工作流还是 Agent：用一套验收标准做架构选择
课程归属：打造能干活的 Agent｜第 2 节
处理资料时，很多需求看起来都像“让 AI 帮我分析”：有的只需按固定步骤读取文件、提取字段并生成报告；有的却需要根据资料内容决定下一步查什么、调用哪个工具，甚至在发现信息不足时换一种办法。本文用同一个“资料分析任务助手”案例，给出一套可执行的判断方法，最后形成明确的架构选择和验收清单。
一、先把问题说清楚：任务步骤是否能提前确定？
这里的“工作流”指由程序预先规定主要执行路径的流程，例如读取文件、提取要点、校验字段、生成报告；“Agent”指模型在执行过程中，根据目标和当前观察结果决定下一步行动，并可调用受限工具的系统。
两者不是“有没有大模型”的区别。工作流同样可以在某些节点调用大模型；Agent 也通常需要程序提供工具、状态管理和安全边界。真正的区别是：谁决定运行时的下一步？如果主要由预先写好的代码决定，是工作流；如果模型会根据中间结果动态选择行动，则更接近 Agent。这个区分与 LangChain/LangGraph 和 Anthropic 对两类模式的公开说明一致，参考文末资料。
二、用同一份资料需求比较两种方案
假设我们要处理data/input/中的教学资料，可能包含一份说明文本和一份 CSV。任务目标是生成report.md，其中包含资料摘要、关键数字、异常提醒和来源记录。
图 1：谁决定下一步？
观察重点不是流程里是否出现 LLM，而是分支由谁控制。工作流可以包含“让模型总结文本”这样的节点；Agent 则可能在读取文本后决定继续分析 CSV、搜索某个关键词，或者因证据不足而请求补充资料。
表 1：用任务特征做初筛
| 判断维度 | 更适合工作流 | 更适合 Agent |
|---|---|---|
| 步骤顺序 | 稳定，能事先列出 | 取决于中间结果 |
| 分支规则 | 可用明确条件表达 | 需要结合上下文判断 |
| 工具选择 | 每一步工具已确定 | 运行时可能选择不同工具 |
| 失败处理 | 重试、跳过、终止规则明确 | 需要根据错误尝试其他路径 |
| 可审计性 | 希望每次执行路径高度一致 | 接受路径不同，但要求记录决策 |
| 风险边界 | 自动化动作固定、容易限定 | 需要严格限制可用工具和行动范围 |
这张表用于初筛，不是打分竞赛。只要某个关键动作涉及付款、删除、对外发送或修改业务数据，即使采用 Agent，也应把授权与确认放在程序控制层，不能把“模型说可以”当成权限。
三、把需求拆成可观察的步骤
架构选择前，先把一句模糊需求改写成输入、动作、结果和验收条件。否则很容易把“分析资料”误判成必须使用 Agent 的复杂任务。
表 2：本案例的任务契约
| 项目 | 教学案例定义 |
|---|---|
| 输入 | data/input/brief.txt与data/input/metrics.csv |
| 目标 | 输出一份可核对的资料分析报告 |
| 必须动作 | 读取文本、统计 CSV、汇总发现、校验报告 |
| 输出 | output/<task_id>/report.md、summary.json、run.log |
| 来源证据 | 报告中的文件名、CSV 使用的列名及统计口径 |
| 成功条件 | 必需文件存在、字段完整、数字可由输入重算 |
| 失败条件 | 输入缺失、列不存在、数据无法解析或报告校验失败 |
注意，以上是教学任务契约，不代表已经运行过某个项目。后续章节会逐步实现公共接口；本节的目标是先确定架构，不提前引入 LangGraph、SQLite 或模型 SDK。
图 2：固定路径的工作流
这个流程的路径基本稳定，失败分支也可以提前定义。即便“整理摘要”使用大模型，整体仍可作为工作流实现，因为模型没有负责决定系统下一步调用什么工具。
四、什么时候值得引入 Agent？
现在把任务稍微改一下：用户只说“帮我分析这批资料，找出最值得关注的问题”。资料可能有文本、CSV，也可能有多份文件；异常出现在哪里并不确定。助手需要先读资料，再根据发现决定进一步计算、检查相关字段、回看原文，最后判断证据是否足够。
图 3：动态决策的 Agent 闭环
Agent 的关键不是“让模型自由发挥”，而是形成受约束的观察—行动—反馈循环。模型可以提出下一步，程序必须校验工具名称、参数、文件范围、调用次数和停止条件；工具结果也必须被检查，不能只凭模型的自然语言断言任务已完成。
表 3：把同一需求改成 Agent 后，契约哪里变化？
| 项目 | 固定工作流 | Agent 方案 |
|---|---|---|
| 任务输入 | 指定文件和固定分析目标 | 目标可以较开放，但仍需明确范围 |
| 下一步决策 | 程序按既定顺序执行 | 模型结合工具结果选择允许的下一步 |
| 工具调用 | 固定调用集合和顺序 | 可从白名单中动态选择 |
| 停止条件 | 到达流程末端或明确错误分支 | 目标满足、步数耗尽、超时或需要人工介入 |
| 验收方式 | 检查固定步骤及输出 | 除输出外，还检查调用轨迹、证据和停止原因 |
动态决策并不意味着 Agent 一定更准确。它带来的是处理路径的灵活性，同时增加了模型调用、错误分支、测试覆盖和调试的复杂度。
五、做出选择：一套可以落地的决策流程
可以按以下顺序判断，不必先比较框架或模型品牌。
- 列出必须完成的动作。如果能稳定写成“读取—计算—生成—校验”，先从工作流开始。
- 找出真正不确定的环节。输入内容不同，不等于流程必须动态；如果差异能用字段检查和条件分支表达，仍然可以是工作流。
- 确认动态选择是否有价值。只有当模型选择下一步工具或策略，能解决固定分支难以覆盖的问题时，Agent 才值得考虑。
- 计算错误成本。如果误操作代价高，优先让程序控制关键路径；需要 Agent 时，把高风险动作设计为只读、草稿或人工确认。
- 设计可验收的停止条件。无论哪种架构，都要定义最大执行步数、超时、输入边界、输出校验和失败状态。
表 4：决策记录模板
| 问题 | 本案例的判断 | 设计结论 |
|---|---|---|
| 资料格式是否明确？ | 文本和 CSV 已知 | 可以固定读取入口 |
| 分析步骤是否稳定？ | 摘要、统计、报告、校验顺序固定 | 主线采用工作流 |
| 是否需要动态挑选工具？ | 基础任务不需要 | 暂不引入 Agent 循环 |
| 是否存在探索性问题？ | 用户可能要求追查异常原因 | 可作为后续 Agent 扩展点 |
| 如何控制风险？ | 只读教学文件，输出写入指定目录 | 限定路径并校验输出 |
因此，本课程的第一版“资料分析任务助手”应从普通 Python 函数和固定执行流程开始。先确保输入可读、统计正确、报告可验收，再在确有动态决策需求时引入 Agent 循环。后续学习顺序也会沿着这个原则推进：先定义工具契约，再接入模型，最后才讨论循环、图编排和持久化。
六、如何验证选择不是拍脑袋？
架构选择需要用任务样例验证，而不是只凭“Agent 更智能”这样的印象。建议先准备一组小型测试：正常资料、缺失文件、CSV 缺列、空数据，以及一个需要进一步追查的开放问题。
表 5：最小验收集
| 用例 | 输入变化 | 预期判定 |
|---|---|---|
| 正常用例 | 文本和 CSV 都有效 | 报告存在，统计可复算，来源清楚 |
| 缺文件 | 删除或改名一个输入文件 | 明确失败，不生成伪成功状态 |
| 缺列 | CSV 缺少约定字段 | 指出缺失列，停止相关统计 |
| 空数据 | CSV 只有表头 | 输出明确的空数据说明，不除以零 |
| 开放追查 | 要求解释异常，原因未知 | 若需动态选择多种工具，可评估 Agent 是否有实际价值 |
验收时，状态completed只能在必需输出通过检查后设置。工具函数返回ok只表示单次工具操作成功，并不等于整个任务完成。这个区分能避免出现“文件读取成功，但报告没生成，任务却显示成功”的问题。
图 4：失败也必须有明确出口
图中的运行器是程序控制层，负责协调工具、记录结果和判定状态；工具只报告自己的执行结果；校验器根据真实文件和字段做验收。即使以后把固定流程升级为 Agent，这几项职责也不应该交给模型的口头承诺。
七、常见误区与边界
误区 1：只要使用大模型就是 Agent
不是。固定流程中用模型提取摘要或分类，仍然可以是工作流。判断依据是模型是否掌握运行时的行动选择权，而不是系统里是否调用了 LLM。
误区 2：步骤多就必须用 Agent
步骤多可能只说明流程复杂。只要顺序稳定、分支可描述、失败策略可预先定义，普通函数或工作流通常更容易测试和排错。复杂度本身不是引入自主决策的理由。
误区 3：Agent 可以自己判断任务是否成功
模型可以提出“看起来已完成”，但成功状态必须由程序根据客观条件判定，例如文件存在、JSON 可解析、必要字段齐全、数字能由原始数据复算。涉及外部写入时，还应单独验证授权与实际执行结果。
误区 4：选择了 Agent 就不用设计工作流
实际系统经常是混合结构：外层工作流负责输入检查、权限、超时、日志和交付；其中一个受限 Agent 负责处理开放式分析。这样既保留动态处理能力，也不把所有控制权交给模型。
八、本节交付结论
对“读取固定文本和 CSV，生成可验证报告”的第一版任务助手，选择工作流优先。原因是输入类型、核心步骤和验收规则都可以事先确定。只有当需求扩展到“根据未知发现动态选择调查路径”时，再通过测试证明 Agent 的灵活性值得额外成本。
本节的验收产物不是一段看似聪明的回答，而是一份架构决策记录：明确输入、步骤、输出、失败条件和升级触发点。后续实现时，所有工具都应返回结构化结果，任务状态由程序维护，报告必须经过实际检查后才标记完成。
参考资料
- LangChain 文档，Workflows and agents：https://github.com/langchain-ai/docs/blob/main/src/oss/langgraph/workflows-agents.mdx
- Anthropic，Building effective agents：https://www.anthropic.com/engineering/building-effective-agents
- OpenAI，A practical guide to building AI agents：https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
- OpenAI Developers，Building agents：https://developers.openai.com/tracks/building-agents
