HN讨论 · 身份未知
动态工作流编排静态化：Claude Code 工作流 token 开销降至约 20%
运行 Claude Code 动态工作流的作者发现，工作流执行中的 token 与时间成本有很大一部分来自每次都让 LLM 重新生成代理提示词和编排；通过把工作流脚本作为 JavaScript 组合工具、将步骤固化到标准 agent 和 makefile，token 花费降到原先约 20%，执行速度显著提升。
查看原始信号hn:49587379
目标用户
用 Claude Code 运行多步、多代理动态工作流的开发者或小团队，关注长任务耗时与 token 成本。
潜在需求
需要把工作流编排、代理角色提示和测试门禁从每轮动态生成改为可复用的静态配置，让 LLM 只承担计划、实现与修复等必要环节，从而减少 token 消耗并缩短整体运行时间。
发生场景
动态工作流脚本本身就是 JavaScript，但默认每轮都经过 LLM 重新生成编排与提示；作者偶然发现 Claude Code 可以识别该格式并让工具直接组合工作流，再配合少量调整，工作流执行与监控的 token 消耗和耗时都大幅下降。
来源证据
作者发现，对于用 Claude Code 运行的动态工作流，可以让模型直接组合工作流脚本而不再每次通过 LLM 编排；经调整后，工作流执行与监控的 token 花费降到原先约 20%，速度显著提升。
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. 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 ithttps://news.ycombinator.com/item?id=49587379
为什么值得留意
这是一条可复现的完整优化路径：识别工作流步骤的公共类别、固化为标准 agent 和 makefile、再让模型编写工具把计划编译成工作流脚本。它说明 LLM 动态工作流的成本不只是调用次数问题，还可以从编排层整体静态化，适合独立开发者作为模式参考。
已有方案
- Claude Code 默认的动态工作流执行：每次由 LLM 生成代理提示词与测试编排
- 作者自建的静态工作流资产：标准 agent 定义 + makefile 双目标测试门禁 + 计划到 JavaScript 工作流的编译工具
可能延伸 · 模型推测
- 把“历史执行记录归纳→静态 agent+门禁生成”做成可复用脚手架或 CLI，输入 ~/.claude/projects 后自动产出优化配置
- 将该模式迁移到其他支持脚本化工作流的 LLM 代理平台，以通用方式复用编排静态化思路
目前未知
- 帖子为作者自述，评分 2、0 条评论，尚无其他团队复现验证
- 优化依赖 Claude Code 对 JavaScript 工作流与 pre-tool use hooks 的支持，可复制范围未知
- 作者没有说明工作流的规模、复杂度和失败率，单点经验能否推广待验证
继续核实
- 运行长时多代理 Claude Code 工作流的其他团队，是否在默认动态编排下遇到可比较的 token 与耗时压力？
- 把编排静态化后，在计划变更、异常修复或新步骤类型出现时是否会失去动态灵活性？
- Claude Code 后续版本是否会内置工作流模版或缓存能力，使这类自建优化变得不必要？
主题词
llm agent workflowstoken consumptionworkflow orchestrationagent prompt generationtest gatingworkflow performance