用 Opus 5.5 调度 105 个 Agent 将 1
I had Opus 5.5 send out 𝟭𝟬𝟱 𝗮𝗴𝗲𝗻𝘁𝘀 across dynamic workflows and turn 1,500+ of m…
这篇详细拆解了多 Agent 协作的具体分工、Token 消耗控制策略以及可复用的 Prompt 结构，对想尝试复杂 AI 工作流的创作者有很高的参考价值。
I had Opus 5.5 send out 𝟭𝟬𝟱 𝗮𝗴𝗲𝗻𝘁𝘀 across dynamic workflows and turn 1,500+ of my posts into a repo of 66 skills.
我让 Opus 5.5 在动态工作流中派出 𝟭𝟬𝟱 个代理，并将我的 1,500 多篇帖子转化为包含 66 项技能的代码库。
For step one, mining the material, I ran 71 agents, 8 at a time. One pass alone burned about 12M tokens. I hit my usage limit twice and was stuck for hours.
第一步是挖掘素材，我运行了 71 个代理，每次 8 个。仅一轮就消耗了约 12M token。我两次触达使用限额，被困住了好几个小时。
Then I saw I was burning through my weekly limit too fast, so I switched build and QA to 𝗴𝗿𝗼𝘂𝗽𝘀 𝗼𝗳 𝟯. Not one of those 24 agents threw an error. That actually surprised me.
然后我发现自己每周的限额消耗得太快，于是将构建和 QA 改为每组 𝟯 个代理。这 24 个代理中没有一个是报错的。这确实让我感到惊讶。
How the work was split (5 workflows, just over 7 hours of run time combined): → Mining (71): read posts, articles and drafts in batches, picked out the methods that could become skills, and sorted them into 14 categories → Planning (9): 4 designers each drafted a version, a chief architect wrote the blueprint, 3 critics flagged 50 problems, and the fixes went into the final plan → Scaffold (1): set up the repo skeleton and validation scripts before anyone else started → Build (21): 3 lanes in parallel, one agent at a time in each lane, one writing and one reviewing → QA (3): each checked one area and never edited another's files
工作是如何分配的（5 个工作流，总运行时间略超过 7 小时）： → 挖掘（71）：分批阅读帖子、文章和草稿，挑选出可转化为技能的方法，并将其归类为 14 类 → 规划（9）：4 位设计师各起草一个版本，首席架构师编写蓝图，3 位评论员标记出 50 个问题，修复方案纳入最终计划 → 脚手架（1）：在其他人开始之前搭建代码库骨架和验证脚本 → 构建（21）：3 条并行通道，每条通道一次运行一个代理，一人编写，一人审查 → QA（3）：各自检查一个领域，从不编辑他人的文件
Now I match every agent's effort to its job: low for mechanical work like mining, medium for writing, high for review, xhigh for the final decision.
现在我将每个代理的工作量与其职责相匹配：挖掘等机械性工作为低，写作为中，审查为高，最终决策为极高。
That said, I'm still checking whether these skills actually work well. Running this on my own account is just one example. The same approach can be applied to any kind of work that builds up over time. Once I've confirmed the material is genuinely useful, I'll probably put the site up so everyone can browse it.
话虽如此，我仍在验证这些技能是否真正好用。在我的个人账号上运行这只是其中一个例子。同样的方法可以应用于任何随时间积累的工作类型。一旦我确认这些素材确实有用，我可能会把网站上线，供所有人浏览。
Send this prompt to Claude Code. Keep the word ultracode in it and it'll run as a dynamic workflow 👇
将此提示词发送给 Claude Code。保留其中的 ultracode 一词，它将以动态工作流的方式运行 👇
"ultracode: Turn [your material] into [what you want to make]. Work in 5 stages: mine the material, plan, scaffold, build, QA. - Run at most 3 agents at once in each group. If there's more work, queue it and start the next agent only when one finishes. - Each agent writes a done marker when it finishes, so a rerun skips work that's already done. - Effort: low for mining, medium for writing, high for review, xhigh for the final decision. - For the plan, have several agents each draft a version, then send in agents whose only job is to find problems. Show me the workflow script and who does what first. Don't run anything until I confirm."
"ultracode：将 [你的素材] 转化为 [你想制作的内容]。分 5 个阶段进行：挖掘素材、规划、搭建脚手架、构建、QA。 - 每组同时运行的代理不超过 3 个。如果工作量更大，请将其排队，仅在某个代理完成后才启动下一个代理。 - 每个代理在完成时会写入一个完成标记，以便重新运行时跳过已完成的工作。 - 工作量：挖掘为低，写作为中，审查为高，最终决策为极高。 - 对于规划阶段，让多个代理各自起草一个版本，然后派遣专门负责查找问题的代理介入。 先向我展示工作流脚本以及各自的职责。在我确认之前不要运行任何东西。"
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力