曾经我以为，随着Agent能力越来越强，工作流这种”老古董”，会被慢慢淘汰，直到我前段时间开始定制B端Agent，才意识到：让企业真正用起来，卡住的不是模型够不够聪明，而是两件事——系统够不够稳定可靠，以及不同环节能接受多高的容错率。
过去我们习惯把Agent和Workflow放在一张对立表里。Agent会自己规划、会临场调整；Workflow按预设路线往下走，没那么灵活，但更容易掌控。
前几天Claude Code发布了Dynamic Workflows（动态工作流），反响很大，官方举的案例效果很炸裂。
Bun创始人Jarred Sumner用它把大约75万行代码从Zig迁移到Rust，从第一次提交到合并只用了11天。
75万行代码，11天，99.8%的测试通过率。
一下又让无数人唤醒了对工作流的热情。
Agent还是Workflow？这个问题已经有点过时了
Dynamic Workflows把这条线打模糊了。
现在，Claude可以先理解一个大任务，临时写出编排脚本，再把工作分给数十个甚至数百个子Agent。有的负责干活，有的负责复核，结果冲突了还可以继续迭代。工作流不再完全由人提前画好，而是可以由Agent当场生成。
所以，问题已经不是“Agent还是Workflow”。
更有用的问法是：哪些不确定性可以交给Agent，又该把它关在什么样的责任边界里？
B端落地，看中的可控性、容错率
最近在帮外贸公司做获客Agent，业务并不复杂，就是用Agent搜索潜在客户，获取其信息后，写定制开发信，然后批量发出去。
一开始先用Agent来做，调了几次就跑通链路了，然后就是加定时任务定期运行即可，但是真正跑起来就知道，稳定性堪忧，经常会遇到各种各样的问题，而且层出不穷。
拆开来看，前面搜索、筛选潜在客户这些探索性动作，Agent怎么选词、读哪几个页面，出错了还能重来，顶多是效率损耗。稍微往后一步，自动发信时称呼写错、把竞争对手当目标客户，会让人尴尬，但还能补救。真正危险的是再往后——一旦Agent开始处理报价策略、商务条款，填错了价格、承诺了不该承诺的交货条件，这才是没有撤回机会、也没有人能出来兜底的那种错误。
同一个Agent，前面是效率工具，后面就可能成为业务事故的起点。区别不在于模型变笨了，而在于它获得了更大的行动权限——而权限背后，是必须有人兜底的责任。
这才是B端AI落地最该先问的三个问题：
这一步允许多大概率的错误？
一旦出错，损失是否可逆？
出了问题，谁来负责？
Coding，修复Bug、整理资料、生成草稿，容错率可以高一些。发信、改价、退款、付款、删数据，就不能只靠”模型大部分时候是对的”。
而企业愿意为一套系统付钱，也从来不是因为它省了几个人。
企业买的不仅仅是”去人化”，而是少救几次火
很多AI项目立项时，算的是能省多少人。但真正上线之后，更值得算的是：错一次要多少人来补，多久能发现，会不会直接伤到业务。
如果一个AI系统省了两个人，却要另外三个人每天盯着它、救火、核对结果，那不叫自动化，只是换了一种加班方式。
所以我不太赞成把“去人化”当成B端AI的最终目标。企业真正愿意持续付钱的，是错误更少（更可控）、流程能复制，以及出问题时找得到原因。
这些，靠模型变聪明解决不了。Workflow的价值在这里——不是让系统突然变得更可靠，而是让每一层的容错边界变得清晰：任务走到哪了，哪一步出了错，谁批准了最后的动作，以及现在还能不能撤回。
把一条业务流程拆成三层
一条真正要进生产的AI流程，不应该从头到尾都由模型决定。
第一层，确定性规则交给代码/工作流。
查数据库、校验字段、计算金额、判断权限，这些能写成明确条件的事，就不要让模型猜。
第二层，模糊判断交给Agent。
理解客户意图、读非结构化文档、搜索信息、生成方案，这些路径很难提前写死，才是Agent应该发挥的地方。
第三层，高风险动作交给审批、日志和回滚。
发送、付款、退款、删除、修改线上配置，执行前要有卡点，执行后要有记录，做错了要有恢复路径。
这三层不一定对应三个产品，也不一定要用同一套框架。关键是：对可靠性要求高的部分，用确定性结构来约束；容错率低的动作，必须有人工卡点兜底——不能把所有风险都压给模型。
Dynamic Workflows把Agent的上限抬高了，也把这个问题放大了。数百个Agent并行工作，带来的不只是速度，还有更高的Token消耗、更多的工具调用和更大的错误扩散范围。Anthropic在产品里保留了执行前确认和管理员禁用能力，这本身就说明：能力越强，越不能绕开权限和责任。
工具怎么选？业务说了算
下面这张表适合快速查阅，但不是产品排名。
按照我的经验，我自己会优先看四件事。
一个每天定时拉数据、分类、写入表格的小任务，一段清楚的Python或TypeScript可能就够了，没必要一开始就搭一套Agent平台。
流程已经说得清、需要连接很多SaaS、运营人员也要参与调整，n8n、Dify、Coze、Zapier、Make这类可视化工具通常更快。不过流程图一旦长到需要拖着画布找上一个节点，就该警惕维护成本了。
如果任务要跑几个小时甚至几天，中间有复杂分支、并行和人工介入，就要考虑LangGraph或团队自己的状态机。这时候真正值钱的不是“图”这个概念，而是断点恢复、测试、版本管理和失败处理。
只有在“目标清楚，路径实在无法提前写死”时，Claude Code和Dynamic Workflows这类交互式Agent才会显出真正优势。它适合研发、研究、安全审计和大规模迁移，却不会因为能并行调度几百个Agent，就自动获得生产系统的信任。
工具最后怎么选，我会先问四个问题：这件事能不能提前写清楚？模型犯错后会造成多少损失？结果能不能用规则或测试验证？真出了问题，能不能停下来改回去？
这四个问题，本质上都在问可靠性和容错率。答不上来，选哪个框架都只是提前购买安心。
B端AI落地，最后拼的是收场能力
Claude Code的动态工作流说明，Agent正在变得更会拆任务、更会组织其他Agent，也更能处理以前难以自动化的开放性工作。这很重要，但还不是全部。
真正能进企业核心链路的系统，不一定是模型最聪明的那个，而是出了问题之后，你知道去哪里查，知道怎么停，也真的能改回来。
Agent可以继续处理不确定性。但企业必须把这种不确定的智能，放进确定的责任边界里。"