Agent swarms and the new model economics智能体集群与新型模型经济学

Earlier this year, we ran experiments to test the limits of scaling agents to cooperate toward a goal. Our hypothesis was that this would unlock a new tier of task scale and complexity.今年早些时候，我们开展了多项实验，旨在测试智能体在协作完成目标方面的扩展极限。我们的假设是，这将解锁更高层级的任务规模与复杂度。

The flagship project was a long-running swarm building a web browser from scratch. It succeeded as a proof of concept, but fell far short of polished software.旗舰项目是一个长期运行的集群，任务是从零开始构建一个网页浏览器。它作为概念验证取得了成功，但距离精致的软件还有很大差距。

That work was deliberately empirical. We started from a blank canvas and hill-climbed toward a stable, effective system. Since then, our goal has been to understand the agent swarm well enough to engineer it deliberately.那项工作是有意为之的经验性探索。我们从空白画布开始，通过不断迭代（hill-climbing）迈向一个稳定且有效的系统。自那时起，我们的目标就是深入理解智能体集群，以便能够有意识地对其进行工程化设计。

To test that progress, we returned to a task the old swarm had struggled with: building SQLite from scratch, in Rust, from nothing but its documentation.为了验证这一进展，我们回到了旧集群曾难以攻克的任务：仅凭文档，用 Rust 从零开始构建 SQLite。

Our initial results have been promising. We ran the old and new swarms on the same task, with the same models and the same time budget, and measured how much of a held-out SQL test suite each could pass.初步结果令人振奋。我们在相同的任务、相同的模型以及相同的时间预算下，分别运行了旧集群和新集群，并测量了它们各自能通过多少 SQL 测试套件（held-out test suite）。

The new swarm did better in every model configuration. Using Grok 4.5, it reached 80% in four hours, while the old swarm spiraled and had to be paused before its second hour.在所有模型配置下，新集群的表现均优于旧集群。使用 Grok 4.5 时，新集群在四小时内达到了 80% 的通过率，而旧集群则陷入混乱，在第二个小时前就不得不被暂停。

We also varied which models did which jobs. In some runs, one model handled everything while in others, a frontier model planned while a fast, inexpensive model carried out the work. Every mix produced similar quality, but the costs varied enormously.¹我们还尝试了不同的模型任务分配方式。在某些运行中，由单一模型处理所有工作；而在另一些运行中，则由前沿模型负责规划，快速且低成本的模型负责执行。每种组合产生的质量相近，但成本差异巨大。1

#Trees and leaves# 树与叶

Descriptions of large tasks naturally take the shape of trees, with a goal at the root that subdivides recursively into basic units of work. Our swarm has two roles, both organized around that same tree-like decomposition:大型任务的描述自然呈现出树状结构：根节点是目标，通过递归细分为基础工作单元。我们的集群包含两种角色，均围绕这种树状分解进行组织：

• Planner agents, powered by the smartest models, split a goal into pieces and delegate them.规划智能体（Planner agents）：由最智能的模型驱动，负责将目标拆解并进行委派。
• Worker agents, generally powered by faster and less expensive models, execute those pieces.执行智能体（Worker agents）：通常由速度更快、成本更低的模型驱动，负责执行这些拆解后的任务。

The design is a superset of more rigid orchestration systems. Rather than imposing a fixed topology on the problem, the swarm’s shape grows to cover the problem’s contours, and compute and context scale in proportion to the task’s complexity.这种设计是更僵化编排系统的超集。集群不会强加固定的拓扑结构，而是随着问题的轮廓生长，计算资源和上下文也会根据任务复杂度按比例扩展。

We think this is why the design generalizes to tasks as diverse as building a browser, solving math problems, and optimizing GPU kernels. We’ve also used it internally to find and fix vulnerabilities in open-source software, raise test coverage on our own codebase, and generate billions of tokens of synthetic training data.我们认为这就是该设计能够推广到构建浏览器、解决数学问题以及优化 GPU 内核等多种任务的原因。我们在内部也利用它来发现并修复开源软件漏洞、提高自有代码库的测试覆盖率，以及生成数十亿 token 的合成训练数据。

#What the tree does for memory# 树结构对内存的作用

When a single agent takes on a complete task, it has to walk the entire tree itself, descending to each leaf while holding its ancestors, its current position, and the wider goal in context the whole time.当单个智能体承担完整任务时，它必须亲自遍历整棵树，在下潜到每个叶节点的同时，始终保持对祖先节点、当前位置以及整体目标的上下文感知。

We think this explains why long-running single agents drift. They can either focus on the work in front of them and lose sight of the bigger picture, or hold the big picture and do a worse job on the piece.我们认为这解释了为什么长期运行的单一智能体会发生漂移。它们要么专注于眼前的工作而忽略了大局，要么顾及大局却在具体细节上表现不佳。

In a swarm, a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend all its context on one narrow piece of work.在集群中，规划者从不参与实现，因此其上下文不会被底层细节填满；而执行者从不参与规划，因此可以将全部上下文用于处理单一细分任务。

We suspect the ability to scale the agent swarm comes from this context efficiency, more than from parallelism itself. That efficiency is present in the swarm at every scale, which is why this decomposition helps agent performance even on moderately sized tasks.我们怀疑智能体集群的可扩展性更多源于这种上下文效率，而非并行本身。这种效率在不同规模的集群中都存在，这就是为什么这种分解方式即使在中等规模的任务中也能提升智能体性能。

There are echoes of this structure elsewhere. The economist Ronald Coase, asking why firms exist at all, argued that coordination costs grow faster than the work itself, so organizations settle into tiers of bounded units rather than letting everyone talk to everyone.这种结构在其他领域也有回响。经济学家罗纳德·科斯（Ronald Coase）在探讨企业为何存在时指出，协调成本的增长速度快于工作本身，因此组织会形成层级化的有限单元，而不是让每个人都与所有人沟通。

#A version control system for agents# 智能体的版本控制系统

In an earlier post about the swarm, we noted that tools like Git and Cargo rely on coarse locks for concurrency control. This is fine for one developer but unworkable for the volume of work produced by hundreds of concurrent agents.在之前关于集群的文章中，我们提到 Git 和 Cargo 等工具依赖粗粒度锁来进行并发控制。这对单个开发者来说没问题，但对于数百个并发智能体产生的工作量来说是行不通的。

The browser swarm from earlier this year peaked at roughly 1,000 commits per hour on Git. The new system peaks at around 1,000 commits per second.今年早些时候的浏览器集群在 Git 上的提交峰值约为每小时 1,000 次。而新系统每秒的提交峰值可达 1,000 次。

To facilitate this rate of activity, we built a new version control system (VCS) from scratch. Throughput was not the only reason to own this layer. Every change in the system passes through the VCS, so it is where collisions first become visible, and several of the coordination mechanisms in the next section are implemented directly inside of it.为了促进这种活跃度，我们从零构建了一个新的版本控制系统（VCS）。吞吐量并不是我们拥有这一层的唯一原因。系统中的每一次变更都会经过 VCS，因此这里是冲突首次显现的地方，下一节中提到的几种协调机制也直接在 VCS 内部实现。

#Failure modes at 1,000 commits per second# 每秒 1,000 次提交下的失效模式

Human engineering teams have standard coordination mechanisms like code review, ownership, standups, and merge queues. Those systems work at human tempo, but at the commit-rate of the swarm, we see failure modes that human teams don’t routinely encounter.人类工程团队拥有代码审查、所有权、站会和合并队列等标准协调机制。这些系统在人类节奏下运作良好，但在集群的提交速率下，我们观察到了人类团队通常不会遇到的失效模式。

#Split-brain design# 分裂大脑设计

Two planners, unaware of each other, implement the same concept in different ways in different parts of the codebase.两个互不知情的规划者在代码库的不同部分以不同方式实现了同一个概念。

We fixed this through prompting. Planners make design decisions themselves rather than delegating them, and we require them to ensure that no two delegated subtrees decide the same question.我们通过提示词（prompting）解决了这个问题。规划者自行做出设计决策而非委派，并且我们要求它们确保没有两个被委派的子树在决定同一个问题。

#Contention between planners# 规划者之间的争用

A harder form of contention is when two planners know about each other and fight through back-and-forth changes over the same files.一种更难处理的争用形式是：两个规划者彼此知晓，并针对同一文件通过反复修改进行“斗争”。

The problem is two pictures of reality, and merge tooling can't fix a disagreement. Instead, we have agents record decisions in shared design docs. Code that depends on a decision carries a compile-checked reference back to its doc. When planners unknowingly contradict each other, a reconciler merges the docs and the references propagate the resolution downstream.问题在于存在两种对现实的认知，而合并工具无法解决分歧。因此，我们让智能体将决策记录在共享的设计文档中。依赖于某项决策的代码会携带一个经编译检查的引用指向该文档。当规划者在不知情的情况下产生矛盾时，协调者会合并文档，引用则将解决方案传播到下游。

#Merge conflicts# 合并冲突

Within the swarm, agents constantly collide on the same files. In order to resolve a collision they would have to stop, absorb the other agent's context, and merge around it. Worker agents are bad at this and, in practice, either overwrite the other change or abandon their own.在集群内部，智能体会不断在同一文件上发生碰撞。为了解决冲突，它们必须停止工作、吸收对方的上下文并进行合并。执行智能体不擅长此道，在实践中，它们要么覆盖对方的变更，要么放弃自己的工作。

To fix this, we created a system where a neutral third-party agent intervenes on merge conflicts and resolves them on behalf of all parties. Its only goal is to be impartial and efficient, similar to the way merge queues work in engineering teams.为了解决这个问题，我们创建了一个系统，由中立的第三方智能体介入合并冲突并代表各方进行解决。其唯一目标是保持公正和高效，类似于工程团队中的合并队列。

#Megafiles# 超大文件（Megafiles）

Some files are particularly popular places for agents to work. Each agent might add only a small amount of code, and no single agent is responsible for keeping the files small.有些文件是智能体工作的热门区域。每个智能体可能只增加少量代码，且没有单一智能体负责保持文件精简。

These “megafiles” choke everything. They’re expensive to transport, diff, and merge, and become the site of constant collisions.这些“超大文件”会阻塞一切。它们在传输、差异对比和合并时成本高昂，并成为持续发生碰撞的场所。

To fix this, we gave worker agents a way to flag bloated files. Once flagged, we block new commits and an outside agent decomposes the overgrown file into smaller modules.为了解决这个问题，我们让执行智能体能够标记臃肿的文件。一旦被标记，我们会阻止新的提交，并由外部智能体将过大的文件分解为更小的模块。

#Ossification# 僵化

Agents have learned, from working in existing codebases with humans in the loop, not to touch core code even when it needs to change.智能体在与人类合作的现有代码库中工作时已经学会：即使核心代码需要更改，也不要触碰它。

To fix this, we license intentional breakage. An agent that judges a core change worthwhile can make a focused patch outside its scope and leave a comment explaining why it did it.为了解决这个问题，我们允许“有意破坏”。如果智能体认为核心变更值得进行，它可以进行超出其范围的针对性修补，并留下注释解释原因。

The compiler carries the change through the rest of the system, and everything depending on the old design fails to build. Each agent that hits one of those errors finds the comment, reads the reasoning, and updates its own piece of work to match.编译器会将该变更传播到系统的其余部分，所有依赖旧设计的模块都会构建失败。每个遇到这些错误的智能体都会找到注释，阅读理由，并更新自己的工作以匹配新设计。

#Review lenses# 审查视角（Review lenses）

In a system that is both long-running and multi-agent, errors accumulate, and the swarm needs a way to correct itself before small mistakes become foundational.在一个既长期运行又多智能体的系统中，错误会不断累积，集群需要在小错误变成基础性问题之前进行自我修正。

We experimented with many kinds of review lenses, such as giving a review agent the worker's full transcript, or only its output, or nothing but the codebase. We also tried reviewers running on different models, with different training and a different personality.我们尝试了多种审查视角，例如给审查智能体提供执行者的完整记录、仅提供输出，或者只提供代码库。我们还尝试了让运行在不同模型、拥有不同训练背景和不同“性格”的审查者进行审查。

No single lens catches everything, but decorrelated lenses stack, the way self-driving systems reach above-human reliability without any single perfect component. The compute spent on review is high return, since review is much cheaper than the work it audits. We suspect this stacked review system was a major contributor to the sustained quality of the runs.没有单一的视角能捕捉到所有问题，但去相关（decorrelated）的视角叠加在一起，就像自动驾驶系统无需单一完美的组件也能达到超越人类的可靠性一样。审查所花费的计算资源回报率很高，因为审查成本远低于其审计的工作量。我们怀疑这种叠加审查系统是运行质量得以持续的关键因素。

#Letting agents shape the environment# 让智能体塑造环境

Stigmergy is the mechanism by which swarm organisms like ants and termites coordinate without direct communication. They shape the environment, and the environment shapes the next organism.“共生行为”（Stigmergy）是蚂蚁和白蚁等集群生物在没有直接沟通的情况下进行协调的机制。它们塑造环境，而环境则塑造下一个生物。

We had encoded rules like “keep notes” and “document decisions” in earlier runs because they seemed obviously good. In retrospect, they were letting agents institutionalize knowledge for their future selves and teammates.在早期的实验中，我们编码了诸如“记笔记”和“记录决策”之类的规则，因为它们看起来很有益处。回顾来看，这些规则实际上是让智能体为未来的自己和队友制度化了知识。

We pushed this further with an experiment in self-authored, shared context we call the Field Guide. It’s a folder owned entirely by the agents, whose index.md is automatically injected into every agent at start. It is the agents’ job to curate what goes into the guide and their only constraint is a line budget.我们通过一项关于“自撰共享上下文”的实验进一步推动了这一点，我们称之为“现场指南”（Field Guide）。这是一个完全由智能体拥有的文件夹，其 index.md 会在每个智能体启动时自动注入。智能体的任务是策划指南内容，唯一的约束是行数预算。

The underlying logic of the guide is that model weights are frozen, so it’s precisely surprise encounters that are worth capturing so the next agent trajectory is shorter.指南背后的逻辑是：模型权重是固定的，因此正是那些意外的遭遇才值得捕捉，从而缩短下一个智能体的轨迹。

The Field Guide is an early experiment with promising results. We’d expect the benefits to be even larger on codebases agents don’t fully own. Training models to write for their successors, where better capture leads to better rewards, is an interesting follow-up area of research.“现场指南”是一项早期实验，结果令人期待。我们预计在智能体不完全拥有的代码库中，其益处会更大。训练模型为继任者编写文档，使更好的捕捉带来更好的奖励，这是一个值得进一步研究的方向。

#The SQLite experiment# SQLite 实验

We instructed the new version of the swarm, equipped with all the improvements described above, to implement the whole of the 835-page SQLite manual in Rust. We withheld the source code, test suites, SQLite binary, and internet access.我们指示配备了上述所有改进的新版集群，用 Rust 实现 835 页的 SQLite 手册。我们没有提供源代码、测试套件、SQLite 二进制文件，也不允许访问互联网。

To measure progress, we graded against sqllogictest, a test suite from the SQLite project built to check that different database engines return the same results for the same queries. It contains millions of queries with known correct answers, and the grade is the fraction the swarm's database gets right. Progress shows up as a rising curve over the course of a run.为了衡量进展，我们使用 sqllogictest 进行评分，这是 SQLite 项目的一个测试套件，旨在检查不同的数据库引擎对相同的查询是否返回相同的结果。它包含数百万个已知正确答案的查询，分数即为集群数据库答对的比例。进展表现为运行过程中的上升曲线。

The swarm was never told the suite existed. After each run, we manually reviewed the code and the run itself, checking for cheating and shortcuts, and confirming the system was built out evenly, rather than just in the places where the tests look.集群事先并不知道该套件的存在。每次运行后，我们会手动审查代码和运行过程，检查是否存在作弊和捷径，并确认系统是均匀构建的，而不是仅仅在测试覆盖的地方进行了构建。

As you read the curves, keep in mind that agents chose their own strategies. Some built broad foundations and scored low for hours before a late spike while others went deep on one area, scored early, then plateaued while filling in the rest. Trends matter more than exact scores at exact moments.在阅读曲线时，请记住智能体选择了自己的策略。有些构建了广泛的基础，在数小时内得分较低，随后出现后期激增；而另一些则深入单一领域，早期得分，随后在填充其余部分时进入平台期。趋势比特定时刻的精确分数更重要。

#Results across model mixes# 不同模型组合的结果

We tested four configurations spanning capability and cost:我们测试了四种涵盖不同能力和成本的配置：

1. GPT-5.5 as both planner and worker. A strong frontier model throughout.²GPT-5.5 同时担任规划者和执行者。全程使用强大的前沿模型。2
2. Grok 4.5 as both planner and worker. Our cost-efficient frontier model, as a comparison point.Grok 4.5 同时担任规划者和执行者。作为对比点，这是我们成本效益最高的前沿模型。
3. Opus 4.8 as planner and Composer 2.5 as worker. Frontier judgment paired with efficient execution.Opus 4.8 担任规划者，Composer 2.5 担任执行者。前沿判断力与高效执行力的结合。
4. Fable 5 as planner and Composer 2.5 as worker. To see whether a next-tier planner makes the hybrid more or less worthwhile.Fable 5 担任规划者，Composer 2.5 担任执行者。旨在观察更高层级的规划者是否会让混合模式更具价值。

The new harness outperformed the old in every mix.新框架在所有组合中的表现都优于旧框架。

The Fable 5 hybrid passed about two-thirds of the suite within the first hour. By the four-hour cutoff, the new runs sat between 73% and 85%, while the old runs ranged from 11% to 77%.Fable 5 混合模式在第一小时内通过了约三分之二的测试套件。到四小时截止时，新运行的通过率在 73% 到 85% 之间，而旧运行的通过率在 11% 到 77% 之间。

The old Grok 4.5 run was paused before its two-hour mark (more below). Every new configuration went on to pass 100% of the suite.旧的 Grok 4.5 运行在两小时前就被暂停（详见下文）。所有新的配置最终都通过了 100% 的套件。

In the future we’d like to run the full N×N matrix of planner-worker combinations. For this cycle, the comparison that matters is between harness versions, and the behavioral differences turned out to be much larger than the score differences suggest.未来我们希望运行完整的 N×N 规划者-执行者组合矩阵。对于本周期，关键的比较在于框架版本，行为差异远比分数差异所暗示的要大得多。

#A deep dive into the runs# 运行深度解析

Starting with the simplest measure of activity, we can see how the rate of commits varied for Grok 4.5 under the old harness versus the new. The old run produced 68,000 commits in its first two hours, roughly 70 times the new run's pace.从最简单的活动度量开始，我们可以看到 Grok 4.5 在旧框架和新框架下的提交速率差异。旧运行在前两小时产生了 68,000 次提交，大约是新运行速度的 70 倍。

One reading is that it was more productive. Another is that most of those commits were busywork (thrash, contention, churn).一种解读是它更具生产力。另一种解读是，这些提交大多是无用功（抖动、争用、搅动）。

The merge conflict data points to the latter interpretation. The old run accumulated more than 70,000 conflicts before we paused it, accelerating rather than stabilizing, while the new run logged fewer than a thousand over its full four hours.合并冲突数据支持后一种解释。旧运行在暂停前积累了超过 70,000 次冲突，且呈现加速而非趋稳的趋势；而新运行在完整的四小时内记录的冲突不到一千次。

The conflicts concentrated where files grew largest. In the old run, the biggest files kept growing for the entire run and its single hottest file collected 7,771 conflicts, touched by 1,173 different agents. In the new run, the most contested file in the whole codebase saw 47.冲突集中在文件最大的地方。在旧运行中，最大的文件在整个过程中不断增长，其最热门的文件收集了 7,771 次冲突，被 1,173 个不同的智能体触碰过。而在新运行中，整个代码库中争用最激烈的文件仅有 47 次冲突。

The old swarm's biggest coordination failure — split-brain, or planners duplicating each other's work — showed up in the package structure. Rust code is organized into packages called crates, and in a project like this, each crate is roughly one major component.旧集群最大的协调失败——分裂大脑（即规划者重复彼此的工作）——体现在包结构中。Rust 代码被组织成称为“crate”的包，在此类项目中，每个 crate 大致对应一个主要组件。

The old run sprawled to 54 crates, including three separate SQL packages. The new run settled on nine crates early and never added another.旧运行扩展到了 54 个 crate，包括三个独立的 SQL 包。新运行很早就确定了 9 个 crate，之后再未增加。

All of this shows up in the final codebase. In the Fable 5 mix, both the old and new swarms ultimately passed the full suite, but the old one needed 64,305 lines of engine code and the new one did it in 9,908. The Opus mix shows the same shape with 19,013 lines at a 97% grade under the old harness, and 4,645 lines at 100% under the new harness.所有这些都体现在最终的代码库中。在 Fable 5 组合中，旧集群和新集群最终都通过了全部套件，但旧集群需要 64,305 行引擎代码，而新集群仅用了 9,908 行。Opus 组合也呈现出相同的形态：旧框架下 19,013 行代码得分 97%，新框架下 4,645 行代码得分 100%。

#Model economics# 模型经济学

We said at the top that every model mix produced similar quality while the costs varied enormously, from $1,339 for the Opus 4.8 hybrid to $10,565 for GPT-5.5 alone. The token data shows where that difference comes from.我们在开头提到，每种模型组合产生的质量相近，但成本差异巨大，从 Opus 4.8 混合模式的 1,339 美元到仅使用 GPT-5.5 的 10,565 美元不等。Token 数据显示了差异的来源。

The structure of the spend was consistent across every run, with workers carrying at least 69% of the tokens, and over 90% in most.支出结构在每次运行中都很一致，执行者消耗了至少 69% 的 token，大多数情况下超过 90%。

But the dollars split differently than the tokens, because planner tokens cost more. In the Opus 4.8 and Composer 2.5 mix, the Opus-as-planner produced a small fraction of the tokens but roughly two-thirds of the cost, while Composer-as-worker handled the vast majority of the tokens for the remaining third of the cost.但美元支出与 token 分配不同，因为规划者 token 更贵。在 Opus 4.8 和 Composer 2.5 的组合中，Opus 作为规划者产生的 token 占比很少，但成本却占了约三分之二；而 Composer 作为执行者处理了绝大多数 token，成本仅占剩余的三分之一。

Few moments in a large task genuinely require frontier intelligence, such as the original decomposition, the design decisions, and certain trade-offs. Once a frontier planner has collapsed the ambiguity into a detailed, explicit instruction, less expensive models simply have to follow it. This is a huge potential source of cost savings. In the run that used GPT-5.5 for both planners and workers, the workers alone cost $9,373. In the run where Opus 4.8 did the planning and Composer 2.5 did the work, the entire worker fleet cost $411.大型任务中很少有时刻真正需要前沿智能，例如最初的分解、设计决策和某些权衡。一旦前沿规划者将模糊性压缩为详细、明确的指令，成本较低的模型只需执行即可。这是巨大的潜在成本节省来源。在同时使用 GPT-5.5 作为规划者和执行者的运行中，仅执行者成本就高达 9,373 美元。而在 Opus 4.8 规划、Composer 2.5 执行的运行中，整个执行者集群的成本仅为 411 美元。

One detail worth noting comes from comparing the two hybrid runs. The Fable 5 planner ran up a slightly smaller bill than the Opus 4.8 planner, despite roughly twice the per-token price, because it used far fewer planning tokens. But the Fable run's workers went through several times as many tokens, and the run as a whole came out substantially more expensive.对比两次混合运行有一个值得注意的细节。Fable 5 规划者的账单比 Opus 4.8 规划者略低，尽管其每 token 价格高出约一倍，这是因为它使用的规划 token 少得多。但 Fable 运行中的执行者消耗了多出几倍的 token，导致整体运行成本大幅上升。

#Specs as prompts# 规格说明即提示词

Each jump in AI capability has raised the level of abstraction at which an engineer can work.人工智能能力的每一次飞跃都提升了工程师的工作抽象层级。

Autocomplete let engineers work one line of code at a time. Early models raised that to a block of code, and agents raised it to a file or a feature.自动补全让工程师可以逐行编写代码。早期模型将其提升到代码块级别，而智能体则将其提升到文件或功能级别。

With swarms, the unit of work becomes the spec.对于集群而言，工作单元变成了规格说明（spec）。

For that to work, the swarm has to actually follow the spec, which is what much of this post is about. We gave the swarm 835 pages of prose and it came back with a database. What was scarce in this experiment, and what we expect to be scarce in software engineering going forward, is the right description of intent.要实现这一点，集群必须真正遵循规格说明，这正是本文大部分内容的主题。我们给集群提供了 835 页的文本，它返回了一个数据库。在此实验中，以及我们预期的未来软件工程中，稀缺的是对意图的正确描述。

Seen this way, the swarm starts to resemble a compiler. A compiler translates source code down to machine code through a series of intermediate steps. The swarm does something similar with intent. Planners parse a goal into task trees, then lower it step by step into executable work. The difference is that a compiler preserves meaning at every step while the swarm is probabilistic at every one. Everything described in this post exists to close that gap.从这个角度看，集群开始类似于编译器。编译器通过一系列中间步骤将源代码翻译成机器码。集群对意图也做了类似的事情。规划者将目标解析为任务树，然后一步步将其降级为可执行的工作。不同之处在于，编译器在每一步都保留了意义，而集群在每一步都是概率性的。本文描述的一切都是为了缩小这一差距。

We invite you to explore the swarm's output. The codebase from the solo Opus 4.8 run is public at github.com/cursor/minisqlite. Based on our initial glance it looks great, but we have not done a deeper manual analysis. Take your own look, and tell us what you find.我们邀请您探索集群的输出。单独 Opus 4.8 运行的代码库已在 github.com/cursor/minisqlite 公开。根据我们初步浏览，它看起来很棒，但我们尚未进行更深入的手动分析。请亲自查看，并告诉我们您的发现。