引言
他是一位园丁，花园里有两条小径。第一条用石板铺得整整齐齐，从门口直通玫瑰丛，每一步都踩得踏实，不会迷路，也不会踩到花。第二条只是草地上被踩出的痕迹，弯弯曲曲，有时通向池塘，有时通向那棵老橡树，有时干脆消失在灌木丛里——但偶尔，它会带你发现一片你从未见过的薰衣草。
来问路的人问他："我该走哪条？"
他笑笑说："如果你只想看玫瑰，走石板路。如果你想看看花园里还有什么，走草地。但记住——草地上有泥，也可能有蛇。"
Agent 和 Workflow 的选择，本质上就是这个问题的技术版本。
TL;DR
判断一个场景需不需要 Agent，拆到每个节点上问：这个节点出错代价有多高？输出能不能被验证？出错代价高、结果可验证，就锁死流程并加 evaluator；出错代价高但不可验证，就不要交给 Agent；出错代价可控、验证或人工筛选能兜住时，Agent 的自由度才有价值。
Agent 最容易被误用的时候，是它第一次看起来像一个完整系统。
开发者写了一串 prompt：先查资料，再分析，再输出。中间可能还接了搜索、知识库、代码执行器。流程跑通之后，这东西看起来很像 Agent。它会调用模型，会使用工具，会生成结果，甚至会在日志里留下几轮"思考"。
从架构上看，它可能只是一个 workflow。
一旦把 workflow 当成 Agent，我们会在错误的位置给系统自由度，在真正需要动态判断的地方把流程写死。流程到底由谁决定，才是关键。
用 prompt 串起来，不等于 Agent
只要一个流程里有 LLM、有工具、有多步执行，就容易把它叫成 Agent。Anthropic 的 Building Effective Agents 和 OpenAI 的 Practical Guide to Building Agents 给了一个更冷的判断标准。
Workflow 是 LLM 和工具沿着预定义代码路径运行。
Agent 是 LLM 根据当前状态，动态决定下一步流程和工具使用。
差别就在这里。
如果开发者已经写死了"先检索、再总结、再生成报告"，模型只是在每个节点里完成局部文本任务，那它更像 workflow。即使每一步都用了 LLM，它也没有真正管理流程。
如果系统只给模型目标、工具和边界，让模型根据任务状态判断下一步该查资料、该问人、该调用工具、该停止，才更接近 Agent。
Workflow 的路径在代码里。Agent 的路径在模型的决策里。
写文章这个例子，能看出上限在哪里
假设我要让系统写一篇文章。
Workflow 的做法很自然：开发者定义流程。
先搜集资料，再读取示例，再模仿风格，最后输出成文。这个流程稳定、可控、容易调试。每一步出了问题，都能定位到具体节点。
整个流程依赖开发者对"好文章"的理解。
如果我定义的流程只有"搜资料 → 看示例 → 模仿写作"，那系统很难跳出这条路径。它不会主动怀疑这个题目是否应该换角度，也不会判断资料是否已经足够，更不会因为读到了用户过去的文章而调整叙述重心。它可以执行得很稳，但它的上限被我写进了流程里。
Agent 的做法：
我只给目标：写一篇适合某个读者的文章。它可能直接用已有知识写，也可能先去搜资料；可能先翻用户过去的笔记，也可能先拆出一个论证结构；它还可能在写到一半时发现原始问题太宽，转而先提出一个更尖锐的中心判断。
这带来了不确定性。
它可能远超我的预设，也可能偏离到不该去的地方。Agent 的价值和风险来自同一个源头：它在路径之间做选择。
写文章这个场景，要拆开看：哪些步骤需要稳定执行，哪些步骤需要超出开发者预设的判断。
比如资料抓取可以是 workflow，事实核对可以是 workflow，风格改写可以带一点 Agent 自由度，选题和结构重组则更适合交给 Agent。
一个系统不必整体是 Agent。它可以只在某几个节点上让模型真正拥有决策权。
Agent 和 Workflow 不是对立关系
很多架构讨论会把 Agent 和 workflow 放成二选一。这个框架太窄。
Agent 可以内嵌 workflow。我们可以用 prompt、skill 或系统指令，引导 Agent 按某条建议路径工作。比如规定"先读项目 README，再查配置，再跑验证命令"。这本质上是在给 Agent 一条 workflow 式的轨道。
但要注意，这只是建议，不是硬约束。
因为 LLM 仍然可能偏离路径。你规定"查询失败就查知识库"，它可能判断真正的问题是网络配置，于是先去修复连接。这个偏离有时是聪明，有时是事故。关键看这个节点能不能承受这种自由度。
反过来，workflow 也可以内嵌 Agent。
一个总体流程可以很固定：输入任务、拉取资料、生成报告、发送审核。但在某个节点里，比如"判断当前资料是否足够"或"给出改进建议"，可以放一个 Agent 进去，让它根据上下文做分支判断。
每个节点需要多大的自由度，才是架构问题。
如果一个节点只需要稳定地搬运数据，就不该给 Agent 太多空间。
如果一个节点需要在不完整信息里做判断，就不应该用僵硬流程假装稳定。
如果一个节点会影响后续所有结果，就必须先考虑验证和兜底。
架构是在每个节点上分配自由度。
确定性和可能性，是同一把刀的两面
Workflow 带来确定性。
它把任务拆成固定步骤，让系统行为更容易预测。你知道它什么时候检索，什么时候总结，什么时候输出。出错时也更容易定位：是检索没拿到结果，还是总结节点写偏了，还是输出格式不符合要求。
Agent 带来可能性。
它可以根据当前状态改路径，可以在信息不足时追问，可以发现流程设计者没想到的角度，也可以在某些任务里给出超过开发者认知上限的结果。
两者结合时，问题在这里。
Workflow 约束太死，Agent 会退化成一个昂贵的 workflow executor。它只是把本来可以用代码完成的流程，用更贵、更不稳定的模型走了一遍。
Agent 自由度太高，又会产生创造性偏离。
这种偏离在低风险任务里可能是惊喜，在高风险任务里就是灾难。比如处理退款请求时，如果 Agent 不只是判断用户是否符合条件，而是自作主张发挽留邮件、调整会员等级、重新解释退款政策，那它是越权。
Anthropic 说：Agent 的自主性适合在可信环境里扩展任务。关键词是 trusted。
OpenAI 那篇实践指南里花了很大篇幅讲 guardrails，比如 relevance classifier、safety classifier、tool safeguards，本质上也是在回答同一个问题：如果系统要让模型动态决策，就必须先定义哪些地方不能让它乱动。
Agent 的自由度应该和环境可信度、错误可恢复性、验证机制一起设计。
我现在用两个维度决定自由度
要不要让某个节点变成 Agent，我现在主要看两个维度。
第一个是出错代价。
这个节点如果错了，下游能不能救回来？如果找错了竞品、删错了文件、给错了用户权限，后面再聪明也很难补救。这样的节点不能因为"Agent 可能更灵活"就放开。
第二个是可验证性。
这个节点的输出有没有客观标准判断对错？有些任务可以验证，比如"是否找到指定三个竞品""JSON 是否符合 schema""测试是否通过"。有些任务很难验证，比如"这个分析是否有洞察""这个建议是否有价值"。
两个维度交叉起来，大概是这样：
| | 可验证 | 不可验证 | |---|---|---| | 出错代价高 | 锁死流程 + evaluator 验证 | 锁死，尽量别让 Agent 做 | | 出错代价低 | 放开一点 + 自动校验 | 放开，让 Agent 扩展可能性 |
高代价、可验证的节点，适合 workflow 加 evaluator。比如打分、格式转换、权限判断、固定对象选择。流程应该尽量锁死，输出再用 evaluator-optimizer 或规则校验。
高代价、不可验证的节点，最好不要交给 Agent。因为它错了很贵，又没人能自动判断它错没错。这种地方通常需要人介入，或者先把任务拆成可验证子问题。
低代价、可验证的节点，可以给 Agent 一些自由度。它可以尝试不同方法，但结果必须通过自动校验。
低代价、不可验证的节点，才是 Agent 真正适合发挥的地方。比如开放式分析、初稿建议、探索性总结。错了可以筛掉，对了可能带来新的角度。
这个判断框架把 Agent 放到它最值钱的位置。
例子：竞品 API 设计分析报告
假设我要做一个任务：对比我司和三个竞品的 API 设计风格、优劣、改进建议。
这听起来很适合 Agent。它需要检索资料、理解文档、做横向比较、写报告。如果直接把整个任务交给一个 Agent，它也许能跑出一个看起来不错的结果。
但真正拆开后，里面每个节点需要的自由度不一样。
节点一：找到三个竞品。
这个节点应该锁死。
竞品是确定的三个，不需要 Agent 发挥。找错竞品，后面的分析全废。这个错误代价很高，而且可验证：是不是这三个对象，一查就知道。
这里应该用 workflow。要么直接传入竞品列表，要么从配置里读。找不到文档时，不要让 Agent 自己换一个"差不多"的竞品，向使用者汇报，让人补充资料。
这里的自由度越高，系统越危险。
节点二：分析各自特征、优劣、共同点和不同点。
这个节点可以放开。
API 设计分析没有唯一标准答案。一个好的分析可能从开发者体验入手，也可能从商业定位、生态兼容性、认证方式、错误码设计、文档结构、SDK 支持入手。
如果我把分析角度写死，报告会很稳，但也容易窄。Agent 的价值就在这里：它可以从多个视角里动态选择，甚至补充我没想到的维度。
这个节点出错代价相对低。分析不全面，不会直接毁掉后续流程，人可以筛选和修正。
这里适合给 Agent 更高自由度。
节点三：按权重打分评比。
这个节点应该锁死并验证。
打分一旦进入最终报告，就会影响结论。分数看起来客观，实际很容易被模型写得像"有依据"，但权重和理由并不稳定。
评分标准要提前定义。比如文档完整度 30%、错误处理 20%、认证体验 20%、SDK 生态 15%、迁移成本 15%。Agent 可以根据标准打分，但打完之后要再过 evaluator。
Evaluator 不一定判断"最终分数是不是唯一正确"，但至少要检查：理由是否引用了前面分析，权重是否被遵守，分数和证据是否矛盾。
如果 evaluator 不通过，就重新打分。
这里不让 Agent 独自完成闭环。
节点四：归纳总结，给出改进建议。
这个节点可以再次放开。
改进建议不是一个可精确验证的输出。它更像从前面材料中抽象出方向。比如是否应该优化认证体验，是否应该降低首次接入成本，是否应该重写错误码文档，是否应该提供迁移指南。
这里出错代价相对低，因为建议可以由人筛选。Agent 可以大胆一点，提出多个方向。真正进入执行计划前，再由人或另一个评审节点收束。
混合架构的做法：把报告拆成多个节点，给每个节点分配不同自由度。
两篇文章真正达成共识的地方
Anthropic 和 OpenAI 在核心工程判断上很一致。
第一，从简单开始。
不要一开始就上 autonomous agent。先看单次 LLM 调用加检索和示例是否够用。不够，再引入 workflow。workflow 也不够，再把某些节点升级成 Agent。
复杂度应该是被问题逼出来的。
第二，渐进式增加复杂度。
Anthropic 把常见模式拆成 prompt chaining、routing、parallelization、orchestrator-workers、evaluator-optimizer，最后才是 autonomous agent。这个顺序很重要。
它是复杂度阶梯。
第三，工具设计重于 prompt 设计。
Anthropic 提到，他们在 SWE-bench 相关项目上花在工具优化上的时间比 prompt 更多。这个经验很硬。
Agent 的能力不只取决于模型怎么想，也取决于工具接口是否清楚、参数是否符合模型决策、错误返回是否可恢复。如果工具设计混乱，再聪明的模型也只是在不稳定接口上试探。
第四，guardrails 是架构的一部分。
Hook、evaluator、human-in-the-loop、安全分类器、工具保护，都不是上线前补的一层胶带。只要系统允许模型动态决策，guardrails 就应该和主流程一起设计。
没有 guardrails 的 Agent 是没有刹车。
园丁后来在两条路之间种了一排薰衣草。来问路的人不再非此即彼——他们可以走一段石板路，再拐进草地；也可以在草地上走累了，回到石板路上歇歇。花园因此大了许多，因为人们开始发现：玫瑰丛旁边有一片薄荷，池塘里住着青蛙，而那棵老橡树的树洞里，藏着一窝刺猬。
Agent 和 Workflow 从来不是敌人。它们是同一片花园里的两条路。真正的问题不是选哪条，而是知道什么时候该走石板、什么时候该踩草地、什么时候该停下来，看看周围还有什么。
而好的架构师，就是那个在两路之间种薰衣草的人。
最后
Agent 不是 workflow 的升级版。它们是两种不同的控制方式。Workflow 把路径交给开发者，Agent 把一部分路径交给模型。
我的场景需要 Agent，理由只有一个：某些节点需要在不完整信息里动态判断，需要超出开发者预设的分析角度，并且它们的出错代价、验证方式和兜底机制允许这种自由度存在。
没有这些条件，workflow 更好。
一个好的 Agent 系统知道哪些地方该自由、哪些地方必须锁死。让模型知道每一条路的边界在哪里，比让它多走几条路更难。