动态工作流：自己构建 Agent，还是直接用工作区？

你好，我是 Nova。Dynamic Workflows 刚刚随 Claude Code 发布。如果你是在自己的技术栈里跑 AI 的单人创业者，真正的问题不是"这酷不酷"——而是：你该自己构建子 Agent 编排，还是说你真正需要的，其实是一个能把你工作端到端跑完的工作区。功能上线后，我一直在自己的项目上试用这个研究预览。下面是我在你在"构建还是使用"上押注之前，会怎么盘算这件事。

Dynamic Workflows 到底是什么

简单版：在 Claude Code 里，你现在可以让 Claude"创建一个工作流"——它不再是一个模型一步步地啃你的任务，而是当场写出一份编排脚本。这份脚本会一次性派生出最多 16 个并行子 Agent，单次运行上限 1,000 个，中间结果存在脚本变量里，而不是塞进 Claude 的上下文窗口。最后，你拿到一份汇总报告。

它以研究预览的形式提供于 Max、Team 和 Enterprise 计划（Pro 不在名单上），外加 API、Bedrock、Vertex AI 与 Microsoft Foundry。Max 和 Team 上默认开启；Enterprise 管理员需要手动打开。它要求 Claude Code v2.1.154 或更高版本。发布文档还提醒：工作流会比标准会话烧掉多得多的 token——Anthropic 自己就建议先用一个有边界的任务校准一下，再对整个仓库做审计。

最后这一点很要紧。能力是真的。成本结构也是真的。

为什么子 Agent 听起来很强，却会带来复杂度

我懂它为什么让人兴奋。第一次看着一个工作流在一个小任务上扇出、带回一个经过验证的结果时，我诚实的反应是：_好吧，这确实挺聪明的。_互相独立的 Agent 从不同角度工作，然后对抗性 Agent 再试着驳倒这些发现——这类模式确实能把你带出单 Agent 的幻觉循环。

但有一件事，没人写进发布博客里：从你用子 Agent 构建的那一刻起，你就签下了三类新的工作。

第一类是划定范围。工作流默认不是"发完就不管"。你得限定 Agent 能碰什么、什么算完成、以及它们的产出如何被复核。一次划得太松的运行，会乐呵呵地派出 200 个 Agent，去调查一个你一个 prompt 就能回答的问题。

第二类是成本监控。每个 Agent 都要付自己的上下文开销。我看过的发布报道在这一点上是一致的——多 Agent 运行可能比单 Agent 会话贵一个数量级。对代码库规模的迁移来说这没问题；对"让我拿周二这批内容试试水"来说，就远没那么划算。

第三类是维护。一旦工作流成为你实际工作方式的一部分，你就拥有它了。模型更新了、工具清单变了、你的工作流不再干它以前干的事了——那都是要你去调试的问题。

这些都不是在贬低这个功能。它们只是塞不进一条发布推文的那部分。

构建路线：编排什么时候才真的划算

构建确实有它的理由。如果你的工作涉及一个代码库、一批研究语料，或一种复杂到确实需要扇出的反复调查模式，Dynamic Workflows 比你从零手搓一套 Agent 框架要省力得多。编排脚本替你扛下了主循环、分支和中间状态——这部分你不用自己接线。

当三件事同时成立时，构建路线才是对的：

你的工作规模大到单会话单模型确实扛不住——整个代码库的迁移、多来源调查、横跨数百文件的审计。你在 Claude Code（或 API）里足够自如，以至于"Claude 写了份跑子 Agent 的脚本"这句话不会让你心里打鼓。而且这个任务会反复出现——因为设计一套工作流的回报，主要在你第二次、第三次、第十次跑它的时候兑现。

这三条里缺任何一条，构建路线都会显得比它能省下的活更沉重。而这恰恰是我觉得被轻描淡写掉的部分。

工作区路线：当你要的是结果，不是搭建

据我观察，我认识的大多数单人创业者（哪怕嘴上不说）最终落在这里：他们不想搭一套 Agent 技术栈。他们想让自己的工作往前走。这个差别很重要。

按我这里用这个词的方式，工作区是那种已经横跨你的日历、文件、周期性任务和上下文的东西——它把这些转成行动，而你不用写编排逻辑。你不是在设计主循环，而是在用一个已经按"一人公司真实会做的那类活"塑形好的主循环：会前准备、客户跟进、内容批量生产、交付检查点、没人碰就会越积越多的周期性运营。**Floatboat**是这个类别里的一个例子，它的定位正卡在那个缝隙上——"这事排上了"和"这事做完了"之间的那一层。同一片空间里也开始出现别的产品。

权衡是真实的。你对精确编排形态的控制变少了。但你也不再交维护税了。对大量单人工作来说，这是对的那笔交易——因为瓶颈不是_"我需要更强大的 Agent 协调"，而是"这周我有十一件周期性的事，而记得它们的人只有我一个"_。

那是另一个问题。它值得另一个工具。

给单人创业者的决策框架

如果只能给朋友一个过滤器来做这个决定，我会说：先问你自己，你到底想从一周里移除掉什么。不是"什么听起来很强大"——而是"到底是什么具体地在啃你的时间"。

然后把它过一遍下面四道检查。

任务重复度、复核需求、权限、维护

**重复度。**这是你会跑五次以上的任务吗？如果是，设计一套工作流就挣回了它的价值。如果不是——比如一次性审计或一次性迁移——单个 Claude Code 会话（哪怕很长）通常是更便宜的答案。工作流奖励重复。它不奖励新鲜。

**复核需求。**你对中间步骤需要看到多少？Dynamic Workflows 的设计恰恰就是让你_看不到_逐步过程——脚本握着计划，你拿到最终报告。对仓库级工作这是特性；但如果你的工作属于那种需要在中途抓住模型推理过程出错的那类，这就是缺陷。诚实面对自己属于哪一种。

**权限与范围。**这东西被允许碰什么？工作流脚本不能直接碰文件系统或 shell——只有 Agent 能。这对安全是好事，但也意味着你现在要考虑 Agent 级权限了——这是你以前根本不用想的事。如果你的工作涉及客户数据、客户系统，或任何"错一步就有外部后果"的东西，划定范围这件事的负担不小。

**维护。**它坏了谁来调试？如果答案是"我，而且我还有别的事要忙"，工作区默认胜出。如果答案是"我，而且这本身就是我的手艺"，那你就去构建。

我认识的大多数单人创业者属于前一个阵营，只是没说出口。

如果你已经动手构建了怎么办

也许你已经在某个子 Agent 方案上投入了几个周末。我在相近的工具上也有过同样的经历。几个诚实的自问：

你搭出来的东西，省下的时间真的比维护它花掉的时间多吗？跟踪记录两周。如果答案不清楚，那这本身就是答案。你用它是因为它好用，还是因为你不愿承认自己搭过头了？这是个值得问自己的问题。同样的结果，能不能由一个不需要你亲自维持其运转的工作区来实现？

你不必扔掉它。你可以把它保留在真正需要扇出的部分——仓库级审计、深度研究、多角度调查——然后把日常执行挪到一个不需要你维护它的地方。不同的层，不同的工具。这是允许的。

这就是我目前的立场。如果你本来就生活在 Claude Code 里、又处于它设计所对应的规模，Dynamic Workflows 确实很有意思。但对我聊过的大多数单人创业者来说，更诚实的答案是：你需要的不是一种更强大的 Agent 协调方式。你需要的是更少的事情从指缝里漏掉。这不是同一个问题，也没有同一个答案。

在往任何一个方向投入之前，都值得去查官方 Claude Code 文档——研究预览会变，尤其是 Dynamic Workflows 的定价与计划可用性，最好对着最新文档确认，而不是照着某篇发布稿（包括这篇）里写的来。

延伸阅读

不招人也能扩大一人业务规模

Claude Managed Agents：对一人公司意味着什么

一人公司如何靠 AI 像团队一样运转

为什么一人公司需要一个工作区 Agent

工作区 Agent vs 工作流构建工具：一份清晰的对比