B端AI落地真正需要的，不是更聪明的Agent

2026 年 5 月 28 日，Anthropic 给 Claude Code 上线了一个很有意思的功能：Dynamic Workflows（动态工作流）。它最初以研究预览形式发布，官方页面目前已经更新为正式可用。

过去我们总喜欢把 Agent 和 Workflow 放在对立面：

• Agent 会思考、会随机应变，但不够稳定；
• Workflow 按固定路线执行，不够聪明，但足够可控。

但 Claude Code 的新做法，开始把这条边界打模糊了。

你只需要交代一个足够大的任务，Claude 就可以临时生成一套编排脚本，把工作拆给数十甚至数百个子 Agent 并行处理，再安排其他 Agent 交叉检查，最后汇总成一个结果。

Anthropic 举了一个很夸张的案例：Bun 创始人 Jarred Sumner 用动态工作流，把大约 75 万行代码从 Zig 迁移到了 Rust，11 天完成从第一次提交到合并，原有测试通过率达到 99.8%。当然，Anthropic 也特意提醒，这个版本当时还没有投入生产。

这个案例真正值得关注的，不只是“AI 又能多写多少代码”。

更重要的是，它说明了一件事：

Agent 和 Workflow 可能并不是两条互斥的技术路线。未来更常见的形态，很可能是 Agent 负责处理不确定性，Workflow 负责约束不确定性。

这也是我最近越来越强烈的感受：讨论 B 端 AI 落地时，如果还停留在“到底应该用 Agent，还是用工作流”，问题可能已经问偏了。

企业真正关心的从来不是技术名词，而是下面这几件事：

• 出错了，能不能及时发现？
• 为什么做出这个决定，能不能追溯？
• 执行到一半，能不能暂停？
• 关键动作发生之前，能不能让人确认？
• 换了模型、Prompt 或业务规则之后，结果会不会突然漂移？
• 真出了事故，谁来承担损失？

说到底，B 端需要的不是一个看起来很聪明的 Agent，而是一套可控地使用智能的生产系统。

Agent 的问题，不是它不够聪明

Agent 最有价值的地方，恰恰是它不会完全按照预设路线走。

它可以自己搜索资料、选择工具、修改计划，也可以根据执行结果临时调整下一步。面对需求模糊、信息不完整、路径无法提前写死的任务，这种能力非常有用。

比如：

• 阅读一个陌生代码库并定位 Bug；
• 调研十家竞争对手，归纳它们的产品差异；
• 根据客户官网、历史沟通和产品库，生成一封定制开发信；
• 从一堆格式混乱的合同中寻找异常条款。

这些任务的共同点是：你知道自己想要什么结果，但很难提前规定每一步具体怎么做。

问题也出在这里。

Agent 的路径不是完全预先确定的。同一个任务执行两次，它可能搜索不同的资料、调用不同的工具，最后给出不同的答案。

如果它只是帮工程师查 Bug，错了大不了重新来一次；但如果它要直接给一万名客户发邮件、修改商品价格、批准退款或者操作付款，风险就完全不是一个量级。

所以，真正的分界线不是“这个任务能不能交给 Agent”，而是：

这个环节允许多大概率的错误？一旦出错，损失是否可逆？

企业追求的也不只是“去人化”

很多人会说，企业上 AI 的核心诉求是“去人化”。

这个说法有一部分是对的，但太容易把问题说窄。

企业当然希望减少重复劳动，但它最终买单的通常不是“少几个人”，而是：

• 同样的人能不能处理更多业务；
• 交付时间能不能从三天缩短到三小时；
• 错误率能不能下降；
• 新员工能不能更快接手；
• 流程能不能被复制到更多部门和地区；
• 管理者能不能看见每一步发生了什么。

如果一个 AI 系统确实省了两个人，却需要另外三个人每天盯着它、救火、核对结果，那不叫自动化，只是换了一种加班方式。

因此，B 端真正想买到的是稳定的业务结果，而不是一场精彩的模型演示。

Workflow 的价值，是给智能装上护栏

传统工作流的优势很直接：步骤明确、输入输出清楚、失败可以重试、责任容易定位。

但工作流也不是天然可靠。

只要其中加入了大模型节点，系统就仍然包含概率性。一个画得再整齐的 n8n 流程，也不能保证模型每次都做出相同判断。

因此，更现实的架构不是“全 Agent”或者“全工作流”，而是把一条业务流程拆成不同风险等级：

1. 确定性步骤交给代码。
   查数据库、校验字段、计算金额、判断权限，这些能写成明确规则的事情，不要让模型猜。

2. 模糊判断交给 Agent。
   信息检索、内容理解、意图识别、方案生成，这些无法完全写死的环节，让模型发挥能力。

3. 高风险动作设置审批。
   发信、付款、退款、删除数据、修改线上配置等动作，在执行前增加人工确认或更严格的机器校验。

4. 所有关键过程留下记录。
   使用了哪些数据、调用了什么工具、模型给出了什么理由、谁批准了最后的动作，都应该能够追溯。

5. 让失败可以回滚。
   企业系统不应只设计“成功路径”，还要提前设计超时、模型异常、接口失败和错误执行之后如何恢复。

这时，Workflow 不再只是一个拖拽出来的流程图，而是一套权限、状态、日志、评估和异常处理机制。

Claude Code 的动态工作流，带来了什么变化？

Claude Code 的 Dynamic Workflows 有意思的地方在于：工作流本身也可以由 Agent 动态生成。

传统工作流通常由人提前画好：

第一步做 A，成功后做 B，失败后转到 C。

动态工作流则更像一个临时组建的项目团队：

先理解目标，再拆分任务；能并行的并行；让不同 Agent 独立求解；再安排 Agent 检查和反驳；如果结论不一致，就继续迭代。

它适合代码库级别的 Bug 排查、大规模迁移、安全审计、性能优化等很难靠一条固定链路完成的任务。任务中断后还可以从已有进度继续，而不是从头开始。

但这不意味着企业终于可以把生产系统完全交给 Agent。

恰恰相反，动态工作流越强，治理就越重要。

数百个 Agent 并行工作，意味着更高的 Token 消耗、更多的工具调用、更复杂的权限边界，以及更大的错误扩散半径。Anthropic 也明确提醒，动态工作流会消耗远高于普通 Claude Code 会话的用量，首次触发时会展示即将运行的内容并要求用户确认，企业管理员也可以关闭这一能力。

所以它更像是在告诉我们：

Agent 的能力上限正在快速提高，但能力越强，越需要被放进一个可观察、可确认、可中止的执行框架里。

几种常见技术路线，应该怎么选？

先用一张表看清楚几种路线的位置：

对比维度	n8n / 低代码工作流	LangChain / 代码框架	LangGraph / 状态机	Claude Code / 动态工作流	原生脚本
主要形式	可视化 Web UI	纯代码 SDK	图结构状态机	交互式智能体 + 动态编排	Python / TypeScript 代码
拓扑结构	流程图，支持分支与循环	链式与组合式调用	节点 + 边，支持循环	按任务动态生成编排	任意代码逻辑
状态管理	节点数据传递与持久化	需按应用配置	全局状态、断点与恢复	会话与工作流进度	需自行实现
连接第三方	强，内置大量连接器	通过工具与集成扩展	通过工具与集成扩展	MCP、终端与外部工具	手动对接 API
人机交互	审批与等待节点	需要自行设计	支持中断后人工介入	交互确认与权限控制	需自行实现
灵活性	中	高	很高	很高	很高
可控性	高	较高	较高	中，取决于权限与审批	高
业务人员友好度	高	低	低	较低	低
更适合	清晰、连接器多的业务流程	代码化 AI 应用	复杂、长运行 Agent 流程	目标明确但路径未知的任务	简单、确定的小型任务

这张表不是给工具排名，而是帮助我们先判断业务问题属于哪一类。

1. 可视化低代码平台：先把业务跑起来

代表产品包括 n8n、Dify、Coze、Zapier、Make、Activepieces 等。

它们适合流程相对清晰、SaaS 连接较多、需要业务人员参与配置的场景，例如线索同步、内容审核、客服分流、表单处理和内部通知。

优势是上手快、流程直观、连接器丰富；问题是复杂逻辑一多，流程图也可能变得难以维护，多人协作、版本管理和多环境发布往往不如纯代码自然。

2. 代码化编排框架：把复杂性纳入工程体系

代表方案包括 LangGraph、各类 Agent SDK，以及团队自己构建的状态机和任务系统。

它们适合复杂分支、长时间运行、并行任务、断点恢复、精细权限控制等场景。

优势是可以进入 Git、测试、Code Review 和 CI/CD 体系；代价是研发门槛更高，业务规则的修改通常仍然依赖工程团队。

3. Claude Code 一类交互式 Agent：处理开放性任务

这类工具最擅长的是“目标明确、路径未知”的工作。它可以读取上下文、调用终端和外部工具，并根据结果不断调整计划。

Dynamic Workflows 又把它从“一个 Agent 连续工作”，推向了“临时生成一套多 Agent 编排”。

它很适合研发、研究、分析和复杂项目执行，但是否能进入核心生产链路，仍然取决于权限隔离、审批、日志、测试和回滚机制，而不是模型看起来有多聪明。

4. 原生脚本：简单场景不必过度设计

如果任务只是每天拉取一次数据、调用模型分类、再把结果写入表格，一段清楚的 Python 或 TypeScript 脚本可能已经够用。

纯脚本并不天然落后。真正的问题是，当任务开始出现队列、重试、状态恢复、人工审批和多个外部系统时，继续把所有逻辑塞进一个脚本，维护成本会迅速上升。

真正值得做的技术选型表

与其比较哪个框架“最先进”，不如先回答这些问题：

业务问题	更应该关注什么
流程是否可以提前写清楚？	固定工作流还是动态规划
错一次的损失有多大？	自动执行、机器复核还是人工审批
结果能否客观验证？	规则校验、测试集、评估模型或抽样检查
任务是否需要运行几小时甚至几天？	状态持久化、断点续跑和任务队列
是否会写入核心业务系统？	最小权限、沙箱、审批和回滚
业务规则是否经常变化？	低代码配置还是代码化管理
数据是否包含敏感信息？	数据分级、脱敏、访问控制和合规部署
运行成本是否可接受？	Token、并发、调用次数和人工复核成本

框架只是实现手段。真正决定系统能否上线的，是这些问题有没有被认真回答。

B端AI落地，最后拼的是系统能力

我现在越来越不相信“一套万能 Agent 接管所有业务”的故事。

但我也不认为未来只能靠人把每一条工作流提前画好。

更可能出现的形态是：

• 人定义目标、边界和责任；
• Agent 处理模糊、开放和需要推理的部分；
• Workflow 管理状态、权限和执行顺序；
• 代码负责不能出错的确定性规则；
• 人在高风险节点做最终确认；
• 评估系统持续检查效果有没有漂移。

Claude Code 的动态工作流，恰好把这个趋势摆到了台面上：Agent 正在学会创建 Workflow，而 Workflow 也正在变得更动态、更智能。

因此，B 端 AI 真正需要的，既不是单纯追求更强的 Agent，也不是回到僵硬的流程自动化。

它需要的是一种新的工程能力：

把不确定的智能，封装进确定的责任边界。

模型可以继续变，工具也一定会继续换。

但只要一套系统能够做到任务可拆解、过程可观察、风险可控制、结果可验证、失败可恢复，它才真正具备进入企业核心业务的资格。

---

参考资料

1. Anthropic，2026 年 5 月 28 日：Introducing dynamic workflows in Claude Code
2. Anthropic，2026 年 5 月 28 日：Introducing Claude Opus 4.8
3. Claude Code 文档：Automate workflows with hooks
4. Claude Code 文档：Create custom subagents
5. Claude Code 文档：Claude Code GitHub Actions