Claude团队任务框架设计专属协同解决方案

# 为什么单一的袋里会失败？ 在2024年到2025年的大部分时间里，答案都出奇地一致：把任务交给一个袋里，用上最大的上下文窗口，然后等着。有时候确实能跑通，但更多时候，模型会在中途悄悄丢掉线索。 Anthropic直接点出了这个问题的本质：**长周期任务**要求袋里在多个步骤之间保持**连贯性**，这往往超出了上下文窗口的可靠支撑范围。更大的窗口有帮助，但解决不了根本问题。 Anthropic之前已经发布过一些辅助工具。**子袋里**允许主袋里把侧线任务委托给独立的执行者，每个子袋里都有自己的新上下文，然后把摘要回传给主线对话。**技能**把可重复的工作流打包成Markdown文件——一个Claude可以按需执行的配方。**袋里团队**走得更远：多个独立的Claude会话，各自拥有独立的上下文窗口，通过共享任务列表协调，甚至可以直接互相发消息。 > 这些都是实实在在的进步。但每个工具仍然撞上了同一面结构天花板。 使用**子袋里**时，编排的Claude会话仍然掌握着整个计划。从执行者返回的每个结果都落进主对话的上下文窗口。无论是**子袋里**、**技能**还是**袋里团队**，Claude都是编排者：它逐轮决定接下来要生成或分配什么任务，所有结果都堆积在上下文中。这意味着编排上下文会随着袋里数量的增加而膨胀，最终触及上限。结果就是，编排质量下降，同样的失败模式卷土重来。 Anthropic识别出了三个在单个上下文窗口——无论属于单个袋里还是领导小型团队的编排者——需要处理规模过大、难以清晰追踪的任务时，会稳定出现的失败模式。这就是三种常见失败模式的来源（图1）。 *图1：单个意识，单个上下文窗口——以及在大任务中悄悄失败的三种方式。* - 首先是**袋里懒惰**。它开始执行任务，但没有彻底完成。可能中途停下、跳过某些文件，或者假设剩余的工作大同小异。然后自信满满地说整个任务已经做完。这就像一个人只检查了长表格的一部分，却在整张表上都标注“已审核”。 - 其次是**自我偏好偏差**。AI在评判自己的输出时并不那么严格。如果问它“你遵循了指示吗？”，它通常会回答“是”，因为它倾向于给自己打圆场。它可能忽略自己的错误，或者高估答案的质量。 - 第三是**目标漂移**。在长时间的任务中，AI会慢慢忘记最初的目标。它可能记得主要任务，但忘记了重要的细节，比如“不要包含X”、“不要跳过任何文件”或“只使用这种格式”。会话或任务越长，这种漂移就越容易发生。 这些不是缺陷。这就是当计划仅仅是一个想法，而想法会退化时，必然发生的事情。 这种成本在2026年初变得无法忽视，当时Bun的创造者Jarred Sumner需要将大约75万行Zig代码逐文件地移植到Rust。过去，这样的任务需要一个团队花上几个月。Sumner的模式很简单：做一个小单元的工作，运行一次对抗性审查，然后应用修改。他后来称**动态工作流**是“当前可靠地使用袋里完成中大型项目的最高水平”。结果是：75万行Rust代码，99.8%的现有测试套件通过，从第一次提交到合并只用了11天。 关键思路在于，Claude不必把整个计划都记在脑子里。**工作流把计划搬到了代码里**。脚本掌管循环、分支和中间结果。Claude只需要处理当前步骤和最终的合成。计划变成了一个Ja vaScript文件。它不会遗忘，不会漂移，也不会半途而废然后声称任务完成。 这就是**动态工作流**要解决的问题。也是这篇文章要讲的内容。 读完这篇文章，你会准确理解子袋里、技能和袋里团队在哪里到达极限，以及为什么会这样——不是模糊的感觉，而是一个你可以应用于自身任务的结构化论证。你会掌握能覆盖大部分实际工作流问题的**六种组合模式**，知道如何写一个确实能生成有用编排脚本的工作流提示，以及如何避免新手最容易犯的两个昂贵错误。你还会知道什么时候工作流根本不是正确的工具——因为**动态工作流**消耗的token量远大于标准会话，在错误的任务上使用它本身就是一种失败。 ## 什么是动态工作流 动态工作流就像用一个专注的小团队替换一个筋疲力尽的人。 不是让一个AI从头到尾扛下整个项目，而是把工作拆成干净的小块。一个袋里处理一项任务。另一个袋里检查结果。再一个袋里推动工作向前推进。这样一来，没有人会在中途感到疲倦、开始偷工减料。没有人会仅仅因为答案是自己写的就给自己满分。也没有人会忘记最初的要求，因为每个袋里只需记住自己那一个清晰的任务。 Claude的**动态工作流**帮助你做到这一点。它把工作分给一群拥有新上下文的Claude。每个处理一个更小的部分，另一个层面检查工作，然后把结果合并成一个答案返回给你。 这里的核心概念是**编排脚本**。编排脚本是围绕模型的脚手架部分：决定任务如何规划、拆分、检查和执行的部分。默认的Claude Code编排脚本主要针对编码任务。Anthropic团队发现，这些动态编排脚本“有时对非技术性工作甚至更有用”。于是他们现场创建了它，根据你给的任务来定制它的形状。 在深入之前，有必要把工作流和其他几个经常混在一起的词区分开。工具、袋里、编排脚本和工作流常常被当作同义词使用，但实际并非如此。把它们分开的最简洁方式——借用了AlphaSignal的框架——是问一个问题：**谁掌握着计划？**（图2） *图2：一个问题——谁掌握着计划？* - **子袋里**是主Claude为某个具体任务派出的帮手。计划仍然留在主Claude手里。子袋里完成自己的部分，把结果发送回来，这个结果会出现在你的聊天对话中。基本上是一次性任务。如下表所示，子袋里不能创建自己的助手，也不能与其他子袋里对话。 - **袋里团队**则不同。它是一群Claude并肩工作，作为平级伙伴协调。计划不存于某一个Claude内部。它存在于它们之间。它们可以互相发消息，随着工作进展调整，并在一个更大的共享任务中持续推进。这更像是把一个项目交给一个小组。 - **动态工作流**又不一样。Claude为任务自己编写一个小型Ja vaScript程序。在这种情况下，计划存于代码之中。袋里们在一旁工作，它们的输出被存储在变量里，只有**最终的合并答案**会返回给你。 **袋里团队**和**动态工作流**看起来很相似，但它们完全是两回事。看下表就能明白。 | | **子袋里** | **袋里团队** | **动态工作流** | | :--- | :--- | :--- | :--- | | **谁掌握计划** | 主Claude（编排者），在它的脑子里 | 平级伙伴之间 | 一个Ja vaScript程序 | | **生命周期** | 一次性任务，一件差事 | 长期运行，持续进行 | 运行一次，返回一个答案 | | **互相沟通？** | 不可以——编排者负责所有路由，子袋里甚至不能生成自己的子袋里 | 可以——它们作为平级伙伴随时间协调 | 不可以——袋里们在脚本变量中独立工作；只有最终结果返回 | | **感觉像** | 你交给一项任务的实习生 | 共享项目上的同事 | 你设计的一条装配线 | 你可能还会问另一个问题：**动态**是什么？**动态 vs. 静态**有什么不同？ 你本来就可以自己构建一个编排脚本。你可以接入Agent SDK，或者在一个循环里运行`claude -p`，创建一个固定系统反复使用。那就是**静态编排脚本**：有用、可重复，但需要提前设计好。 **动态编排脚本则是相反的**。Claude在当下构建编排脚本，根据你刚给的任务来打造它。它规划结构、拆分工作、运行袋里、检查输出，然后当任务完成时就把编排脚本扔掉——除非你按`保存`键。 **静态编排脚本是通用的；动态的则是定制化的、一次性的。** Claude现在之所以能构建动态工作流，是因为Opus 4.8已经足够强大，能够实时构建出正确的编排脚本——正如Anthropic团队所说，“能够智能地编写一个为你用例量身定制的编排脚本”。 --- ## 真正的考验 ### 让动态工作流真正有用的几种模式 Anthropic介绍了6种工作流模式，我对其中的一些进行了测试，来直观地展示它们是如何工作的： - **扇出与综合**——拆分工作，然后合并。每个部分都有自己的袋里和干净的上下文；最终的合成者等待所有袋里完成后再合并结果。 - **对抗性验证**——针对每一个发现，派出一个专门负责证伪它的袋里。一个怀疑者来检查乐观者。 - **分类与行动**——先用分类袋里对每个条目进行分门别类，然后路由到正确的处理者。就像前台的作用。 - **生成与筛选**——先广泛头脑风暴，然后按照一个规则表进行筛选：去重、验证、只留下经得起审查的内容。 - **锦标赛**——生成N个袋里，每个袋里用不同的方式尝试同一个任务，然后让一个裁判袋里对它们进行两两比较，直到选出胜者。对审美评判和命名任务很有用。 - **循环直到完成**——对于规模未知的工作，持续派出袋里，直到满足停止条件（没有新发现、没有更多错误），而不是固定执行多少次。 **扇出与综合**很可能是最常见的模式。一个任务拆分成多个袋里，每个袋里拥有**自己干净的上下文**，这样它们就不会互相污染，然后一个**综合步骤**——这个步骤**等待所有袋里**——将他们的工作合并成一个结果（图3）。 *图3：扇出与综合：拆分为干净的上下文袋里，然后一个屏障合并所有人的工作。* 而**对抗性验证**是另一个常见的模式（图4）。 *图4：对抗性验证：一个发现面对一群反驳者；多数反驳则淘汰，其余幸存。* ### 在非技术问题上的实战 理解动态工作流最快的办法，是在一个跟代码毫无关系的问题上使用它。 我给了Claude一个餐厅订阅模式的商业计划书，要求它从三个敌对的视角同时对这个想法进行批判：一个风险规避的投资者、一个苛求的顾客、一个现有的竞争对手。每个袋里独立工作。然后一个最终的合成者把所有结果汇总起来，返回了三个最有力的反对意见以及回应方式。 来看这次运行（图5），加速版本： *图5：扇出与综合：三个批评者同时从不同角度攻击一个商业计划；一个Opus袋里进行综合。4个袋里，~262k tokens，~13秒。* 这是**扇出与综合**模式：三个袋里从不同视角覆盖同一个问题，然后一个袋里综合结果。整个运行大约花了十三秒。 重要的不是速度，而是隔离。因为袋里们不共享同一个上下文窗口，它们不会悄悄影响彼此，也不会削弱彼此的结论。每个都带回了截然不同的视角。 结果如下： 1. **投资者攻击了数据**：**经济模型太脆弱，抗不住用户流失。** 每月29美元，大约40%的利润率，产品每个客户每月只产生约11.60美元的毛利润。而获客成本是35美元，所以业务需要客户留存足够长的时间，让用户生命周期价值明显超过获客成本。但食品订阅通常面临高流失率，一个留存表现不佳的月份就可能把模型拖到亏损线以下。**回应：** 在规模化之前先解决单位经济问题：通过年费计划或附加服务提高单用户收入，证明低队列流失率，并明确计算LTV与CAC的对比关系。 2. **顾客攻击了价值**：方案的宣传过于强调“轮换菜单”和“碳中和配送”这类概念。这些在PPT里听起来不错，但可能不是顾客选晚餐时最在乎的事。多数顾客想要的是速度、灵活性、以及减少每天的选择困难。**回应：** 让价值主张更接地气：突出节省的时间、便利性，以及这项服务如何让平日的晚餐变得更轻松。 3. **竞争对手攻击了护城河**：轮换菜单和碳中和配送很快就能被模仿。这两样都很难创造切换成本。一个更大的竞争对手可以模仿这些表面特征、压低价格，或者把这项服务打包进现有的配送网络中。**回应：** 建立更强的护城河：基于城市的物流密度、个性化、切换积分，或者让用户产生习惯、使其更难被取代。 这就是这个工作流有价值的地方。它给出的不只是“关于商业计划书的反馈”。它从三个不同的压力点给出了三种不同的反对意见：经济效益、客户价值和防御性。一次普通的对话很可能会把这些混合成一个礼貌的、略有用处的评论。而工作流让分歧变得更尖锐。最棒的部分是：我一行代码都没写。 ### 如何启用动态工作流 设置很简单。把模型切换到**Opus 4.8**（后面会解释原因），你有三种方式触发工作流。最可靠的方式就是直接在提示中**加上`workflow`这个词**。另一种方式是把努力度设为**`ultracode`**，这会开启超高推理能力，让Claude自己决定是否需要构建一个工作流。不过使用`ultracode`要谨慎——它消耗更多token，所以在你需要自动编排时才用它。 第三种方式是如果你之前运行过一个不错的工作流并保存了它，可以通过`/＜名称＞`再次触发。有两个保存位置：`.claude/workflows/`（项目共享；克隆了该仓库的人都可以访问）和`~/.claude/workflows/`（个人使用；所有项目都能访问，但只有你能用）。 为什么Opus 4.8如此重要，是因为**编排者的工作是最难的**。它不仅仅是回答问题，还要决定如何拆分任务、编写工作流脚本、给子袋里分配任务、选择工具、跟踪输出以及综合最终结果。所以模式是：**把最强的模型用于编排，然后在子任务范围更窄时，用更小或更便宜的模型来担当工作袋里**。 ### 我们来测试一下 #### 默认方法 目标：我使用一个多文件代码仓库，要求Claude运行工作流，利用扇出与综合和对抗性验证来审计这个仓库。 **提示：使用工作流审计这个仓库：扇出查找器并验证每个发现，综合生成一个按严重程度排序的报告。使用200k token。** *图6：Claude Code对工作流创建的回应。* 如图5所示，Claude创建了一个包含3个阶段的工作流：查找 → 验证 → 综合；并使用了6个查找器对应6个维度：安全、正确性、数据完整性、可访问性、代码质量、仓库卫生。因为我没有指定要Claude具体查看哪些方面，它自动提出了这6个维度。 它开始运行工作流。要查看进度，使用命令`/workflows`。 *图7：工作流进度。* 在`/workflows`里（图7），6个袋里正在运行，但问题是它们全都是Opus 4.8，每个大约消耗50k tokens。我的预算很快就会见底。 2分钟后，查找袋里全部完成，找到了**50个候选问题**（图8）。结果就是，每个问题都需要运行一个验证袋里来检查是否真实存在还是误报。而且全都是Opus 4.8。 这通常是不必要的。编排者需要最强的模型来设计工作流、拆分任务、管理袋里和综合结果。但很多验证任务范围更窄：检查这一个问题、审查证据、断定它是否成立。对于这种专注的任务，一个更便宜的模型通常就足够了。 因此，在下一个测试中，我更换了工作袋里为**Sonnet**。目的不是削弱工作流，而是把Opus用在最关键的环节——编排和综合——而在重复性的验证工作中使用更便宜的模型。 *图8：查找袋里的结果。* #### 为袋里使用更便宜的模型 再次尝试，这次袋里用Sonnet，编排和综合用Opus。 **提示：使用工作流审计这个仓库：扇出查找器并验证每个发现，综合生成按严重程度排序的报告。使用200k token。所有袋里用Sonnet，编排和综合用Opus。** 在图9中，Claude提供了**7个Sonnet 4.6的查找袋里，耗时254k tokens，在接近5分17秒后找到了71个候选问题**。Sonnet运行确实比Opus要花更多时间。 *图9：使用Sonnet的查找袋里。* 你可以通过工作流窗口查看每个问题的验证详情，如图10所示。 *图10：验证窗口。* 71个问题的验证过程大约消耗了近150万tokens。花费比Opus少得多，但查找袋里的运行时间显著更长。 以下是综合者（Opus 4.8）的结果，见图11。 *图11：综合结果。* 重要的事情是：在让Claude开始修改代码之前，你必须阅读它生成的报告，进行审查和修订。 查找袋里仍然检测到了几个问题，这些后续被验证袋里确认为有效。然而，有些问题是应用程序本身的固有特性，意味着它们只能保持那个样子，检测出来除了增加我们更多检查工作之外毫无意义。因此，我想在工作流运行之前就添加一些约束，以便这些不会被扫描出来。 #### 运行前修改工作流 **提示：使用工作流审计这个仓库：扇出查找器并验证每个发现，综合生成一个按严重程度排序的报告。使用200k token。所有袋里用Sonnet，编排和综合用Opus。编写工作流并给我链接，让我能在运行前访问并修改它。** *图12：Claude在提供工作流脚本供修改后停止。* 完美。Claude给出了工作流脚本让我审查和修改，然后我再告诉Claude运行它（直接说`run the workflow`即可）（图12）。 我用了一个更短的代码库和更简单的提示，来演示Ja vaScript工作流文件的组成部分，如图13。 *图13：扇出与综合——逐行剖析，然后运行（4个袋里，~262k tokens，~13秒）。* 对于我的测试代码库，以下是我想修改的范围： `{key: 'correctness', prompt: \`检查正确性/逻辑错误。关注点：基于日期的确定性每日选择、洗牌行为、"最近5个排除"的历史逻辑（不小心多一位、换行的处理、按衣柜分别隔离）、衣柜与性别的切换、2件/3件套过滤器、按小时自动切换主题（6am-6pm边界）、localStorage键处理。追踪边界情况（空男式衣柜、所有服装最近都穿过）。读取app.js和collection.js。\`,},{key: 'docs-accuracy', prompt: \`检查文档准确性。将README.md和docs/*.md的声明与实际代码行为进行比较。关注点：描述的功能与实现不符、错误的localStorage键、过时的配置、不起作用的部署步骤、过时的计数（"所有40套衣服"）。读取README.md、docs/codebase-summary.md、docs/deployment-guide.md，然后与代码进行验证。\`,},` 我移除了：`洗牌行为、按小时自动切换主题（6am-6pm边界）、追踪边界情况（空男式衣柜、所有服装最近都穿过）`以及整个`'docs-accuracy'`。我也检查了Ja vaScript文件中的其他地方，确保以上提到的点已被移除。 你也可以让Claude来排除这些，但这很简单，我更喜欢自己动手。 这样，查找袋里要检查的方面从7个减少到6个，并且其中一个方面的范围变小了（图14）。 *图14：工作流运行过程。* 六个查找袋里发现了**44个不同的候选问题，并确认了40个**。整个过程调用了51个袋里，耗时9分52秒，消耗了约166万tokens。 #### 与单个袋里运行对比 我让**同一个代码库在单个袋里中一次性运行**，没有团队，没有验证。它发现了**47个问题**——比工作流的44个更多——只用了三分之一的tokens。但是，因为没有运行验证，在这47个问题中，有同样的**2个错误发现**，而在工作流中被验证袋里正确捕获并移除了。我在下面的图表中显示了差异，以便更直观地比较（图15）。 *图15：单个袋里与工作流的对比。* 如果你的重点是原始覆盖率且不介意自己审查，那么单个袋里是更经济的选择，但需要在质量上做出一些权衡。 ## 何时使用工作流 **动态工作流**消耗的tokens比正常的Claude Code会话多得多。这是因为它们在后台运行多个子袋里，每个都有自己的独立上下文窗口。所以不应该在每项任务上都使用。如果这样做了，你可能会在短短几个小时内烧光配额。更好的方法是只在任务确实需要多个袋里并行工作时才使用。有几个关键信号可以帮助你判断何时值得使用工作流，如图16所示。 *图16：何时使用动态工作流。* - 第一个信号是**任务可以拆分为相互独立的部分**。如果每个袋里都依赖另一个袋里的输出，它们大部分时间都会在等待对方。到那时，启动工作流就没什么价值了，因为失去了主要优势：并行工作。任务之间相互依赖越少，工作流就越有用。你获得更好的并行性，结果也返回得更快。 - 第二个信号是**任务是否足够大，需要一个以上的上下文窗口**。工作流运行多个子袋里，每个子袋里都有自己的新上下文窗口。只有当任务规模足够大，值得被拆分成块时，这才有意义。否则，你只是在白白花费额外的时间和tokens。这也有用，因为每个子袋里只返回它的最终结果。它的详细推理过程留在自己的工作文件中，不会进入主上下文窗口——除非你主动要求。这保持了主对话的简洁，为最终的合成留出了更多空间。 - 下一个信号是**任务是否需要验证**。在某些情况下，错误的答案是代价高昂的。你不会希望基于一个不靠谱的安全发现、一个虚假的错误报告或一个有风险的迁移计划而贸然前进。对于这样的任务，使用额外的袋里来交叉验证结果是值得的。但验证不是免费的。更多袋里意味着更多tokens和更多时间。所以任务应该值得被这样检查。不要仅仅因为你最近听某个AI技术CEO说更多tokens意味着更多钱，就盲目派出五个袋里。 - 最后一个信号是**任务是否确定性的**。工作流使用代码以固定结构调用袋里。所以如果任务有明确的形态，可以拆解成已知的步骤，工作流很合适。但如果任务需要袋里在运行时决定下一步做什么，那么工作流可能不是合适的工具。一个有用的思考方式是判断**任务是宽的还是深的**。一个宽的任务可以拆分成大量同时运行的小任务。这正是工作流的强项。它们并行调用多个袋里，让每个处理自己的部分，然后把结果整合起来。一个深的任务则是一步一步来的。每一步都依赖于之前发生的事情。对于这种任务，`/goal`命令通常是更好的选择。它一次处理一个任务并持续推进，而不是试图并行运行很多事情。 --- ## 我们能经济地使用动态工作流吗？ **动态工作流**确实很昂贵，但我想测试 **最便宜的模型，Haiku，能否节省tokens和成本**。编排者和综合者不可更改，它们必须是**Opus**，这是没得商量的。因此，让我们尝试将子袋里换成**Haiku**。 令人惊讶的是，工作流在约7.5分钟内完成——调用了37个袋里。它用了37个袋里，消耗135万tokens。它找到了23个候选问题，比上面的**Sonnet**运行少很多，并且全部23个都通过了验证。 但成本的故事并不像“更便宜的模型，更便宜的工作流”那么简单。**Haiku**用了135万tokens只找到23个问题。**Sonnet**版本用了166万tokens找到了40个问题。所以，即使**Haiku**每个token更便宜，**token效率却更差**。它需要更多的轮次来做同样类型的分析工作，而每一轮都意味着重新读取更多的上下文。教训很简单：一个更小的模型在实践中并不自动意味着更便宜。如果它需要更多步骤来思考任务，它很快就会消掉自己的价格优势。 **Haiku**每个tokens的成本大约只有**Sonnet**的三分之一。从纸面上看，这似乎是个轻松的选择。但在这次测试中，**Haiku**大约多用了1.5倍的tokens。这两个数字几乎相互抵消。结果，**Haiku**的扇出运行大致与**Sonnet**成本相同，可能便宜大约10%，实时速度也只快一点点。所以“把所有任务路由到最小的模型”并不是一个可靠的规则。一个更小的模型如果需要更多token来完成工作，它的价格优势就会消失。 还有一个关于质量的要点，我认为非常重要。两个版本都出现的问题有14个。这相当令人惊讶，表明当袋里彼此隔离时，他们确实在高效工作。然而，也有2个问题是两个版本有分歧的。令人惊讶的是，**Haiku**在两者上都是正确的，而**Sonnet**却是错误的。这并不表明谁更好，更像是模型的表现并非100%如预期般一致。其中一个原因是我给了Claude一个模糊而宽泛的提示。因此，接下来我将用一个更具体的方面来测试。 **新提示：以安全漏洞方面审计这个仓库，包括密钥、认证、注入、依赖项、数据处理，使用工作流：扇出查找器并验证每个发现，综合生成一个按严重程度排序的报告。使用200k token。所有袋里用Haiku，编排和综合用Opus。编写工作流并给我链接，让我能在运行前访问并修改它。** **Haiku**的运行情况： - 15个袋里，约57.2万子袋里token，约3.5分钟实际运行时间 - 5个Haiku查找器 → Haiku对抗性验证器 → Opus综合者 - 9个初始发现 → 3个确认，6个被反驳。所有“高”评级都被移除。 对于**Sonnet**袋里： - 23个袋里，两轮共约130万tokens。约2.51分钟。 - 5个Sonnet查找器 → Sonnet对抗性验证器 → Opus综合者 - 18个初始发现 → 13个确认，5个被驳回 → 去重后剩下8个不同问题。没有严重/高的评级存活过对抗性验证。 一个重要的细节：Haiku运行中确认的所有3个问题，在Sonnet运行中也都被发现了。这比之前的运行要一致得多。一个可能的原因是，这次提示给了袋里一个具体的调查角度，而不是要求他们从宏观视角查看整个系统。这是合理的。工作流使用了5个袋里，每个只专注于安全的一个方面。因为范围更窄，袋里可以在同一类型的问题上挖得更深，而不是把注意力分散到过多的可能问题类别上。当一个袋里不必被迫在广泛的表面上进行优先级排序时，它自然会花更多的推理预算来处理被明确分配的具体问题——这导向了更彻底、更可重复的发现。 所以，即使你在使用带有隔离子袋里的**动态工作流**，你的提示仍然需要尽可能具体。更狭窄的提示减少了这种差异，推动袋里得出更一致的结论——这正是当一致性和可靠性至关重要时你所需要的。 --- ## 运行后保留好的工作流 一个有用的、被保存下来的工作流应该感觉像项目自动化，而不是某次幸运运行的记录。它应该足够干净，让另一个团队成员打开后能迅速理解：谁拥有它、它期望什么输入、允许使用哪些工具、每个子袋里负责什么、以及在调用任务完成之前需要达到什么级别的证据。 如果工作流运行得很好并且你想复用它，在工作流菜单中按**s**键将其保存到`~/.claude/workflows`。如果你的目标是向团队分享方法并使其更容易在类似任务中复用时，你也可以将脚本移入一个技能中。 但是，不要仅仅因为第一次运行成功了就保存它。一次成功的运行只证明了它曾经起过效。当编排本身具有价值时才保存它：当脚本比从头再写一次普通的Claude Code提示更容易检查、复用和改进的时候。 以下是一些提示示例供你参考。当你想要使用其中一条时，请加入自己的细节： > **压力测试一个计划：** “把下面的计划拿出来，运行一个工作流，让独立的袋里分别从不同角度批评它——一个持怀疑态度的投资者、一个苛求的顾客、一个现有的竞争对手——每个独立进行。然后综合出三个最尖锐的反对意见和针对每个意见的最有力的回应。” > > **审计一个仓库：** “运行一个工作流来审计这个仓库。扇出袋里针对逻辑错误、不安全的路径、弱认证、缺失授权、泄露的密钥、有风险的依赖项和数据泄露。针对每个发现，派出一个单独的袋里进行对抗性验证——尝试证伪它。综合生成一个按严重程度排序的报告，包含文件路径和修复方法。`使用200k tokens`。” > > **使其更便宜：** “构建时让查找袋里运行在`model: 'haiku'`上，而编排者保持在Opus 4.8并做最终综合。报告token消耗和实际运行时间。” > > **复现一个不稳定的测试：** “这个测试大约每50次运行中会失败1次。建立一个工作流来复现它——形成理论，并在工作树中进行对抗性测试。`/goal`在找到一个有效的理论之前不要停止。” > > **验证一个草稿：** “通读这篇草稿，使用一个工作流来验证每一个技术声明是否与代码库和来源一致。我不想发布任何错误的东西。” > > **按真实优先级排序（锦标赛）：** “我有一个发现/选项的列表。使用一个工作流来按[实际可利用性/影响/其他关键指标]对它们排序——但不是给每个打分，而是运行一个两两比赛，按获胜排名。然后显示前三名并说明原因。” > > **根因分析一个幽灵错误：** “这个bug是间歇性的，明显的原因看起来不对。使用一个工作流：根据证据来拆分调查——一个袋里负责症状，一个负责代码，一个负责数据/日志——然后让单独的袋里尝试反驳每个理论，综合出最终存活的根因。” > > **安全地分类积压问题：** “使用一个工作流来分类这个积压问题：对每个条目进行分类（立即修复/升级/需要决策），去重归为同类，并路由。任何读取非信任输入的条目必须是只读的——将它和提出修改建议的部分分开。” > > **根据任务形态进行路由：** “使用一个工作流，让分类器查看每个任务并路由到最便宜的能胜任的模型——小型模型处理机械性工作，Opus处理模糊的、安全关键型的推理——然后每个在选定的模型上运行。” > > **检查规则手册：** “使用一个工作流，对照我们的CLAUDE.md中的规则检查这段代码——每条规则一个验证器，外加一个搜索误报的怀疑者。我更关心不要大惊小怪，而不是捕捉每一个不重要的细节。” --- ## 来源 1. Thariq Shihipar & Sid Bidasaria (Anthropic), “A harness for every task: dynamic workflows in Claude Code”——关于原因、模式、提示技巧、保存/分享。 2. Factory.ai, “The Context Window Problem: Scaling Agents Beyond Token Limits”. 3. Engineering at Anthropic, “Effective context engineering for AI agents”. 4. Chroma Technical Report, “Context Rot: How Increasing Input Tokens Impacts LLM Performance”. 5. Anthropic, “Building effective agents”——关于底层编排模式的背景知识。 6. Anthropic, “Introducing dynamic workflows in Claude Code.”