AI Learn
Anthropic · Practical Tutorial

Use Claude Code Dynamic Workflows for a codebase-wide investigation

Use a coordinated multi-agent workflow for large investigations that benefit from parallel hypotheses and independent verification, then keep the final change set bounded.

Reviewed September 20, 2026Independent tutorialFeatures may vary
Not official support. AI Learn is an independent education site. Check the provider’s current documentation for plan-specific limits, pricing and feature availability.
Before you start

Dynamic workflows can consume substantially more usage than a normal session. Use them for problems that are too broad for a single pass—large audits, migrations or profiler-guided investigations—not for a five-line bug fix.

1. Write the global question and the evidence required for a finding to count

Define one system-level question and what counts as evidence before spawning agents. Examples include “why does checkout latency spike after deploys?” with acceptable evidence limited to traces, tests, code paths and dated logs.

2. Ask the workflow to split into independent investigations and adversarial verification roles

Decompose the question by subsystem and add at least one role whose job is to disprove the leading hypothesis. This prevents several agents from reinforcing the same attractive but weak explanation.

3. Set a token or effort budget and define protected files or systems

Set an effort/token budget and name protected files or systems. Exploration can expand rapidly, so a useful workflow has a point at which it must summarize what it knows instead of continuing indefinitely.

4. Let investigators gather evidence first; keep code edits out of the discovery phase

Keep discovery read-only: collect paths, call graphs, logs, tests and contradictory evidence without editing. Separating diagnosis from implementation makes it possible to judge whether the later patch actually follows from the evidence.

5. Review the consolidated findings, choose a subset, then implement and test in a separate bounded step

From the synthesis, choose only the smallest high-confidence implementation candidates. Move those into a separate coding step with normal tests and review rather than letting the research workflow rewrite the whole codebase.

Try this prompt

Create a dynamic workflow to investigate [problem] across this repository. Use separate agents for architecture, runtime evidence, tests and adversarial verification. Discovery is read-only. Set a budget of [budget]. Return only findings supported by file references or runtime evidence, then stop before implementation.

Common mistakes

Using workflows for trivial tasks; allowing discovery agents to edit overlapping files; no budget; accepting consensus without adversarial checking; implementing every finding in one enormous follow-up patch.

Finish check

The workflow produced a short list of independently checked findings with evidence, usage stayed within the chosen budget, and implementation remains a separate reviewable decision.

开始之前

Dynamic Workflows 的使用量可能明显高于普通会话。只在单次调查确实覆盖不了的问题上使用,例如大型审计、迁移或性能调查,不要拿来修一个五行代码的小 Bug。

1. 先写清全局问题,以及一条发现要被采纳必须满足什么证据标准

在启动多个智能体之前,先定义一个系统级问题以及“什么算证据”。例如研究“为什么部署后结账延迟升高”,并限定证据只能来自 Trace、测试、代码路径和带日期日志。

2. 要求 Workflow 拆成独立调查角色,并加入反向验证/质疑角色

按子系统拆分问题,并至少安排一个角色专门反驳当前最强假设。这样可以避免多个智能体同时强化一个听起来合理、但证据并不充分的解释。

3. 设置 Token 或努力预算,并标出受保护的文件和系统

提前设置工作量/Token 预算,并标记不得修改的文件或系统。探索很容易无限扩大,因此需要一个明确节点,到了就必须汇总现有证据,而不是继续挖下去。

4. 调查阶段先只收集证据,不要一边调查一边大范围改代码

Discovery 阶段保持只读:收集路径、调用关系、日志、测试和反证,不直接改代码。把诊断与实现分开,才能判断后续补丁是否真的由证据推导出来。

5. 审查合并后的发现,只选择一小部分进入单独的实现和测试阶段

从综合结论里只挑选最小、置信度最高的实现候选,再进入独立编码步骤并正常测试、Review。不要让研究工作流顺手重写整个代码库。

可以直接套用的提示词

创建一个 Dynamic Workflow 调查这个仓库中的 [问题]。分别使用架构、运行时证据、测试和反向质疑角色。调查阶段只读。预算:[budget]。只返回有文件引用或运行时证据支持的发现,然后在真正修改代码之前停止。

常见错误

小任务也用 Workflow;调查智能体同时修改重叠文件;没有预算;看到“大家都同意”就不做反向验证;把所有发现一次性塞进巨大补丁。

完成检查

Workflow 产出的是少量经过独立验证且有证据的发现,使用量在预算内,实现仍然是单独、可审查的决策。

開始之前

Dynamic Workflows 的使用量可能明顯高於普通會話。只在單次調查確實覆蓋不了的問題上使用,例如大型審計、遷移或性能調查,不要拿來修一個五行程式碼的小 Bug。

1. 先寫清全局問題,以及一條發現要被採納必須滿足甚麼證據標準

在啓動多個智能體之前,先定義一個系統級問題以及“甚麼算證據”。例如研究“為甚麼部署後結賬延遲升高”,並限定證據只能來自 Trace、測試、代碼路徑和帶日期日誌。

2. 要求 Workflow 拆成獨立調查角色,並加入反向驗證/質疑角色

按子系統拆分問題,並至少安排一個角色專門反駁當前最強假設。這樣可以避免多個智能體同時強化一個聽起來合理、但證據並不充分的解釋。

3. 設定 Token 或努力預算,並標出受保護的檔案和系統

提前設置工作量/Token 預算,並標記不得修改的檔案或系統。探索很容易無限擴大,因此需要一個明確節點,到了就必須匯總現有證據,而不是繼續挖下去。

4. 調查階段先只收集證據,不要一邊調查一邊大範圍改程式碼

Discovery 階段保持只讀:收集路徑、調用關係、日誌、測試和反證,不直接改代碼。把診斷與實現分開,才能判斷後續補丁是否真的由證據推導出來。

5. 審查合併後的發現,只選擇一小部分進入單獨的實現和測試階段

從綜合結論裡只挑選最小、置信度最高的實現候選,再進入獨立編碼步驟並正常測試、Review。不要讓研究工作流順手重寫整個代碼庫。

可以直接套用的提示詞

創建一個 Dynamic Workflow 調查這個儲存庫中的 [問題]。分別使用架構、執行階段證據、測試和反向質疑角色。調查階段只讀。預算:[budget]。只回傳有檔案引用或執行階段證據支援的發現,然後在真正修改程式碼之前停止。

常見錯誤

小任務也用 Workflow;調查智能體同時修改重疊檔案;沒有預算;看到“大家都同意”就不做反向驗證;把所有發現一次性塞進巨大補丁。

完成檢查

Workflow 產出的是少量經過獨立驗證且有證據的發現,使用量在預算內,實現仍然是單獨、可審查的決策。

Official references

Check current product details at the source

Related practical tutorials

Continue with another single-task workflow.

All tutorials →