在动态工作流中削减（Claude Code）代币支出80%
几天前偶然发现了一些非常有趣的东西，觉得这可能对其他使用Claude代码运行动态工作流的人也很有趣。工作流脚本本身是JavaScript。Claude代码了解这种格式，可以制作一个工具来组合工作流，而不是每次都通过大型语言模型（LLM）进行处理。
我成功实现了这个功能，并经过一些调整后，工作流执行和监控的令牌消耗减少到了之前的约20%，显著加快了速度（我们的大多数工作流以前需要5-6小时，现在只需20-40分钟）。
我们让Claude分析了过去几周的工作流（工作流执行记录在磁盘上，位于~/.claude/projects），并识别出它们之间的共性。结果发现实际上有三种工作流步骤，以各种临时方式完成。
- 代码变更代理/实施者/工作者 - 这个代理从计划中获取任务并执行；这样的代理可以并行运行。
- 检查门代理 - 这个代理试图弄清楚实施者代理做了什么，并评估不应并行执行的内容。
- 最终检查，负责部署、运行API测试等。
此外，Claude还可以从标准“代理”（来自./claude/agents）中组合工作流，而不是每次都通过LLM为工作流代理编写提示；因此我让它找出共性和变异性，它编写了三个代理脚本，后来我们将其减少到两个：
- workflow-worker - 获取计划的一部分，并仅限于对其自身计划/文件边界的写入和测试权限，不修复其他人可能正在做的事情，绝对不运行整个测试套件。
- workflow-gate - 从一组并行工作流代理获取结果，基于git中发生的变化运行串行验证（例如，如果任何www文件发生变化，则运行web测试；如果任何后端文件发生变化，则运行API测试等）。这以前每次都由LLM自定义编写，但我们将其移动到一个包含两个目标的makefile中，因此make workflow-serial-gate检查git树并对更改运行测试，make workflow-final-gate对所有内容运行清理测试，部署到暂存环境，运行部署后测试。
由于变异性移入了makefile，这两个代理定义变成了标准的100行markdown，LLM不再需要每次编写。
接下来，由于代理定义已标准化，我们让Claude实际编写了一个工具，读取包含步骤和依赖关系的计划文件，并直接编写工作流JavaScript。以前，复杂计划的返回时间通常需要10分钟，而现在只需一秒钟。
由于工作流代理提示是静态的且只编写一次，因此不会消耗令牌。由于整个测试运行的编排在makefile中，基于git变更，因此在这方面也不会消耗令牌。由于工作者代理获取计划和步骤编号，因此不会消耗令牌告诉它们该做什么（除了它们读取特定步骤，这个是不可避免的）。令牌几乎只在创建计划、狭义实施任务和上下文修复问题时消耗。
当命名代理作为工作流的一部分运行时，传递给预工具使用钩子的上下文包括代理的名称（例如，workflow-worker，workflow-gate），因此我们能够显著限制它们。例如，workflow-worker不允许运行make或整个测试套件，并发送消息将该任务委派给门代理。
最终结果令人惊叹，工作流运行得更快，消耗的令牌也远少于之前。Claude几乎自己编写了整个过程，因此如果你运行动态工作流，我绝对推荐这个实验。如果有人感兴趣，我很乐意提供更多信息。
查看原文
Discovered something very interesting by chance a few days ago, and thought it might be interesting for other people running dynamic workflows with claude code. The workflow scripts themselves are javascript. Claude code knows the format and it can make a tool that composes workflows instead of going through LLM each time.<p>I got it to do that, and with a few more tweaks it got the token spend for workflow execution and monitoring down to about 20% of what it was before, significantly speeding it up (most of our workflows used to take 5-6 hours, they now take 20-40 minutes).<p>We got Claude to analyze the workflows from the past few weeks (the workflow execution is on disk, in ~/.claude/projects) and identify commonalities between them. It turned out to be effectively 3 kinds of workflow steps, done in a million ad-hoc ways.<p>- a code change agent/implementer/worker - this takes a task from the plan and does it; such agents can run in parallel<p>- a check gate agent - this tries to figure out what the implementer agents did and evaluates things that should not be done in parallel<p>- the final check, which deploys, runs api tests etc.<p>It also turns out you that Claude can compose workflows out of standard "agents" (from ./claude/agents), not writing the prompts for workflow agents by LLM each time; so I asked it to figure out commonalities/variabilities, and it wrote 3 agent scripts, which we later reduced to two:<p>- workflow-worker - gets a piece of the plan and very tight permissions to only write and run tests for it's own part of the plan/file boundary, and not fix anything that others might be doing, and definitely not run the whole test suite<p>- workflow-gate - gets the results from parallel workflow agents in a group, runs serial verifications based on what changed in git (e.g. if any www files changed run web tests; if any backend files changed, run api tests etc. This used to be custom-written by LLM each time but we moved it to a makefile with two targets, so make workflow-serial-gate checks the git tree and runs tests for changes, make workflow-final-gate runs clean tests on everything, deploys to a staging environment, runs post-deployment tests<p>as the variability moved into the makefile, both of these agent definitions became standard 100-line markdown, that the LLM did not need to write each time.<p>next, since the agent definitions are standardized, we got claude to actually write a tool that would read out the plan file with steps and dependencies, and write the workflow javascript directly. previously it used to take 10 minutes for something like this to come back for complex plans, now it takes a second.<p>Since the workflow agent prompts are static and written once, no tokens get spent writing them. since the whole choreography of which tests to run when is in the makefile, based on git changes, no tokens get spent on that. since worker agents are getting the plan and a step number, no tokens are spent telling them what to do (besides them reading the specific step, but this is unavoidable). Tokens get spent pretty much only on creating the plan, narrow implementation tasks and contextually fixing issues.<p>When a named agent runs as part of the workflow, the context passed to pre-tool use hooks includes the name of the agent (e.g. workflow-worker, workflow-gate) so we were able to constrain them significantly. For example, workflow-worker is not allowed to run make, or run the entire test suite, with a message to delegate that to the gate agent.<p>The end result is amazing, workflows run much much faster and spend far fewer tokens than before. Claude pretty much wrote the whole thing itself, so I definitely recommend this as an experiment if you run dynamic workflows. Happy to provide any additional info if people are interested.