主页
0130 秒速览
01The 30-Second Version
Agent swarm(智能体群),就是让很多个 AI agent 同时朝一个目标干活。不是「一个 agent 跑得久一点」,而是「几十到上万个 agent 同时跑,最后把结果合起来」。
An agent swarm means many AI agents working toward one goal at the same time. Not "one agent running longer," but "dozens to tens of thousands of agents running concurrently, with their outputs merged at the end."
这个词最近突然变热,因为 2026 年 9 月 8 日 OpenAI 公布:他们用一个 约 1 万 agent 的协作群,在 88 小时内产出了 Navier–Stokes 千禧年问题的解答,并用 Lean 做了机器验证。这是目前公开可查的最大规模 agent 群体工程记录。
The term spiked because on September 8, 2026, OpenAI reported that a coordinating group of roughly 10,000 agents produced a resolution of the Navier–Stokes Millennium Prize Problem in 88 hours, machine-verified in Lean. It is the largest publicly documented agent-swarm engineering effort to date.
但同一周的 arXiv 论文给出了相反结论:在固定总模型调用次数的前提下,Planner-Executor-Critic 三角色团队相对单个 executor 的提升不显著(0.769 vs 0.754,p=0.80),而团队多花了 1.8 倍调用。
Yet an arXiv paper from the same week reached the opposite conclusion: under a fixed total number of model calls, a Planner-Executor-Critic team was not significantly better than a single executor (0.769 vs 0.754, p = 0.80) while spending 1.8× the evaluation calls.
堆 agent 数量只在一种任务形状上划算:验证一个候选答案很便宜,但找到候选答案的搜索空间极大。数学证明(Lean 可验证)、漏洞挖掘(exploit 能跑就是真的)、大规模重构(测试能过就是对的)属于这一类。反过来,如果验证本身也要靠模型判断,或者任务是线性、写多读少的,单个 agent 通常更便宜也更好控。
Adding agents pays off in exactly one task shape: verifying a candidate is cheap, while the search space for finding one is enormous. Math proofs (Lean-checkable), vulnerability discovery (an exploit either runs or it doesn't), large refactors (tests pass or they don't) all fit. Conversely, if verification itself requires a model's judgment, or the task is linear and write-heavy, a single agent is usually cheaper and far easier to control.
图 1:同一个任务的两条花钱路线。右侧「验证器」是整张图的关键——没有它,群体产出无法收敛。
Fig. 1: Two ways to spend on the same task. The verifier on the right is the crux — without it, swarm output never converges.
02为什么现在讨论它:一周内的三件事
02Why This, Why Now: Three Things in One Week
「多 agent 更强」这个说法流传了一年多,但一直缺少可对照的数字。2026 年 8 月中到 9 月初,三份材料在很短时间里同时落地,第一次让这个问题可以被认真讨论。
"Multi-agent is stronger" has circulated for over a year without comparable numbers behind it. Between mid-August and early September 2026, three pieces of material landed in quick succession and made the question answerable for the first time.
- 8 月 13 日 —— Anthropic Frontier Red Team 发布《Patterns and problems in emerging multiagent systems》,公开了 45 个 agent 协作找漏洞、80 个 agent 共建一款游戏、以及三个目标冲突的 agent 互相攻击的完整实验数据。
- 9 月 7 日 —— arXiv 同批出现三篇从不同角度削弱「多 agent 红利」的论文:等成本对照、角色可替换性、审阅者能力分层。
- 9 月 8 日 —— OpenAI 公布 Navier–Stokes 结果,首次披露万级 agent 群体的具体工程参数(消息数、token 数、时长、跨组授粉机制)。
- Aug 13 — Anthropic's Frontier Red Team published Patterns and problems in emerging multiagent systems, with full experimental data from 45 agents hunting vulnerabilities together, up to 80 agents co-building a game, and three goal-conflicted agents attacking one another.
- Sep 7 — Three arXiv papers landed in the same batch, each undercutting the "multi-agent dividend" from a different angle: equal-cost comparison, role interchangeability, and reviewer capability tiers.
- Sep 8 — OpenAI published its Navier–Stokes result, disclosing for the first time the concrete engineering parameters of a 10,000-agent swarm: message counts, token counts, wall-clock time, and the cross-pollination mechanism.
45 个协作 agent 用 2700 万 token 找到 266 个漏洞,独立并行方式用 650 万 token 找到 21 个——看起来协作赢麻了。但把协作群的产出限制在独立 agent 被指定搜索的同一批核心目录里之后,两种方法的「每个漏洞花多少 token」大致相当。两者只重合了 12 个漏洞,是互补关系,不是替代关系。
45 coordinating agents found 266 vulnerabilities over 27M tokens; independent parallel agents found 21 over 6.5M tokens — the swarm appears to win by a mile. But once the swarm's output is restricted to the same core directories the independent agents were told to search, the two methods are roughly comparable on tokens-per-vulnerability. Only 12 findings overlapped. They are complementary, not substitutes.
来源:Anthropic Research · Patterns and problems in emerging multiagent systems(2026-08-13)
Source: Anthropic Research · Patterns and problems in emerging multiagent systems (2026-08-13)
这句话为整篇文档定了调:群体的表观优势,很大一部分来自「它自己决定去哪找」,而不是「它人多」。把搜索范围拉平之后,人多带来的边际收益就没那么惊人了。
That framing sets the tone for the rest of this document: much of a swarm's apparent advantage comes from deciding where to look, not from having more heads. Normalize the search scope and the marginal return on headcount shrinks dramatically.
03核心概念:先把词说清楚
03Core Concepts: Getting the Words Straight
严格定义:一个去中心化的多 agent 系统——没有固定的中央规划者,agent 之间通过点对点通信、运行时协商角色来解决问题。
工程实践中的用法:这个词被放宽用来指「任何让多个 agent 并行干同一件事的编排系统」,包括一个 lead agent 拆任务、多个 worker 并行、结果再合并的层级式设计。本文档用宽泛定义。
Strictly: a decentralized multi-agent system — no fixed central planner; agents coordinate peer-to-peer and negotiate roles at runtime.
In engineering practice: the word is stretched to cover any orchestration where several agents work the same goal in parallel, including hierarchical designs where a lead decomposes the task, workers run concurrently, and outputs are merged. This document uses the loose sense.
为什么要区分?因为「纯 swarm」在需要审计、权限策略和回滚路径时几乎不可用。你真正会部署的,大概率是「主流程用编排器,复杂例外才交给一个专门的编排器」的混合形态。
Why does the distinction matter? Because a pure swarm is nearly unusable the moment you need audit trails, policy enforcement, and a rollback path. What you will actually deploy is almost certainly a hybrid: an orchestrator for the main flow, with a dedicated orchestrator reserved for complex exceptions.
四个必备组件
The four components every swarm needs
不管你用哪个框架,下面四块都得有——这不是选型问题,是结构问题。
Whatever framework you wrap around it, all four of these must exist. This isn't a vendor choice; it's structural.
来源:OpenHands · What Is an Agentic Swarm?(2026-07-11)(社区整理,其中引用的 Anthropic / Microsoft / LangChain 一手材料已核对链接)
Source: OpenHands · What Is an Agentic Swarm? (2026-07-11) — a community synthesis; the Anthropic / Microsoft / LangChain primary material it cites has been link-checked.
换个说法:用工程队打比方
Say it another way: the construction-crew analogy
04三组实证:同一个问题,两个方向的答案
04Three Studies: The Same Question, Two Answers
证据 A:一万个 agent 拿下 Navier–Stokes(支持堆量)
Evidence A: 10,000 agents crack Navier–Stokes (pro-scale)
一手来源2026 年 9 月 8 日,OpenAI 公布了三维不可压缩 Navier–Stokes 方程在光滑外力、有限能量下有限时间产生奇点的证明,对应千禧年问题官方表述中的 "C"(与 "D")分支,并附 Lean 形式化。
primaryOn September 8, 2026, OpenAI published a proof that the 3D incompressible Navier–Stokes equations, under smooth forcing with finite energy, can develop a singularity in finite time — establishing statements "C" (and "D") in the official Millennium Prize formulation, with a Lean formalization attached.
这套流程里有四个可复制的工程决策,比结果本身更值得抄:
Four reusable engineering decisions sit inside that run — worth copying more than the result itself:
- 强制方向多样性:不同 agent 组被喂以不同的问题变体——A/B 是「试着证明」,C/D 是「试着证否」。没有人事先知道哪边对,所以两边都派人。
- 先啃更简单的同族问题:先在 Euler 正则性(Navier–Stokes 去掉粘性项的极限)上取得突破,再把 Euler 的结论作为提示灌给 Navier–Stokes 组。
- 跨组授粉(cross-pollination):中途用 Codex 把各组最有用的中间结论抽取、合并,再作为后续 prompt 回灌。注意这里的关键:回灌的是 agent 自己的中间产物,不是人写的新提示。
- 热更换底座模型:过程中有更新训练好的内部模型可用时,直接把 agent 切到新模型上继续。
- Diversity enforced by construction: different groups were prompted with different variants — A/B ("try to prove"), C/D ("try to disprove"). Nobody knew which side was right, so both were staffed.
- Warm up on an easier sibling problem: they first broke Euler regularity (the zero-viscosity limit of Navier–Stokes), then fed the Euler result forward as a prompt to the Navier–Stokes groups.
- Cross-pollination: mid-run, Codex was used to extract and consolidate the most useful intermediate findings from each group and feed them back as follow-up prompts. The key detail: what gets fed back is the agents' own intermediate output, not fresh human prompting.
- Hot-swapping the base model: when a further-trained internal model became available during the effort, running agents were updated to it.
OpenAI 明确说明:用的不是 GPT-6 Astra,而是 8 月 28 日起才开始训练、且"显著强于 Astra"的内部模型,训练当时仍在进行。也就是说,这个结果里模型能力的贡献和群体规模的贡献是纠缠在一起的,无法从公开信息里拆开。把它当作「swarm 有效」的证据时,必须带上这个限定。
OpenAI states plainly that the system did not use GPT-6 Astra but an internal model whose training began on August 28 and which is "significantly more capable than Astra" — still training at the time. Which means the contribution of raw model capability and the contribution of swarm scale are entangled and cannot be separated from the public information. Cite this as evidence that swarms work only with that caveat attached.
来源:OpenAI · On the Navier–Stokes Millennium Prize Problem(2026-09-08);所有数字均为 OpenAI 自述,截至调研时无第三方复现。
Source: OpenAI · On the Navier–Stokes Millennium Prize Problem (2026-09-08). All figures are OpenAI's own; no third-party reproduction as of this writing.
图 2:整条路径的形状比规模更值得学——阶梯、重新分配、可验证终点。
Fig. 2: The shape of the run teaches more than its size — laddering, reallocation, and a verifiable endpoint.
证据 B:等成本对照下,多 agent 结构没有赢(反对堆量)
Evidence B: at equal cost, multi-agent structure does not win (anti-scale)
arXiv 2609.04217这篇论文指出了此前所有「多 agent 更强」结论的一个共同方法论漏洞:它们通常按「环境交互轮数」对齐,而不是按「模型调用次数」对齐——团队每一步要调用多次模型,等于白拿了额外算力。
arXiv 2609.04217The paper identifies a shared methodological hole in prior "multi-agent wins" claims: they typically align on environment rollouts, not on model calls — and a team makes several model calls per environment step, so it silently gets extra compute.
作者把 Planner-Executor-Critic 的三个角色 prompt 当作可进化对象(称为 MA-Evolve),在共享的冻结 7B 底座上做逐角色坐标上升优化,然后固定总模型调用次数与「只进化单个 executor」对比:
The authors treat the three role prompts of a Planner-Executor-Critic team as evolvable objects (MA-Evolve), optimize them by per-role coordinate ascent over a shared frozen 7B backbone, then compare against evolving a single executor under a fixed total number of model calls:
| 设定Setting | ALFWorld 分数ALFWorld score | 评估调用Eval calls | 结论Verdict |
|---|---|---|---|
| 单 executor(进化后)Single executor (evolved) | 0.754 | 1× | 显著优于未进化基线significantly beats unevolved baseline |
| 完整三角色团队Full three-role team | 0.769 | 1.8× | p = 0.80,不显著p = 0.80, not significant |
| 团队 + 2–3 倍免费算力Team + 2–3× free compute | — | 2–3× | 仅仅打平only matches |
| WebShop 环境WebShop environment | — | — | 进化无效,团队趋势更差evolution null; team trends worse |
最刺眼的是 leave-one-in 分析的结论:全部价值来自 executor。planner 和 critic 在优化过程中进化成了空 prompt 或低影响 prompt,极少改变 executor 的动作。也就是说,那两个角色不是「帮助有限」,而是被优化过程主动删掉了。
The sharpest finding comes from the leave-one-in analysis: all realized value comes from the executor. The planner and critic evolve into empty or low-impact prompts and rarely change the executor's action. Those roles weren't marginally useful — the optimizer actively deleted them.
来源:arXiv:2609.04217(2026-09-07)
Source: arXiv:2609.04217 (2026-09-07)
证据 C:审阅者(critic)只在一种配置下有用
Evidence C: a reviewer only helps in one configuration
arXiv 2609.04270证据 B 说 critic 没用,这篇说的是更精确的版本:critic 有没有用,取决于它和 executor 的「关系」。作者固定 100 道奥数题,把 reviewer 换成不同能力档位的模型,并逐条统计每次拒绝的后果:
arXiv 2609.04270Evidence B says the critic is useless. This paper gives the more precise version: whether a critic helps depends on its relationship to the executor. Holding 100 olympiad math problems fixed, the authors swap in reviewers across a capability range and score the outcome of every individual rejection:
| Reviewer 配置Reviewer setup | 最终准确率Final accuracy | 误拒自己正确答案False-reject rate | 净效果Net effect |
|---|---|---|---|
| 无 reviewer(基线)No reviewer (baseline) | 52% | — | — |
| 跨家族中档模型Cross-family mid-tier | 64% (+12pp, p=0.0005) | 2% | 零损坏,明确有效zero damage, clearly worth it |
| 同模型自审Same-model self-review | 无显著提升no significant gain | 35% | 检出率最高(0.85)却没收益highest recall (0.85), no payoff |
| 能力过低的 reviewerSub-floor reviewer | 0/100 个答案被改变0 of 100 answers changed | — | 完全惰性,token 成本翻倍inert; doubles token cost |
同模型自审为什么「看起来损坏率低」?作者给出了一个很有意思的机制解释:那是修订惰性的假象。18 个被误拒的正确答案里,executor 真的服从了修改意见的那 3 个全变错了;剩下 15 个它压根没理,于是原样存活。不是自审无害,是 executor 懒得听它的。
Why does self-review appear to cause little damage? The authors give a neat mechanistic answer: it's an artifact of revision inertia. Of 18 falsely rejected correct answers, the 3 where the executor actually complied all became wrong; the 15 it ignored survived untouched. Self-review isn't harmless — the executor just doesn't listen to it.
论文明确写道:这些发现描述的是「单一 executor-reviewer 配置在 100 道题上的表现」,应被当作受控试点,而不是关于验证环节的一般性结论。
The paper states plainly that these findings describe "a single executor-reviewer configuration on 100 problems" and should be read as a controlled pilot, not a general claim about verification stages.
来源:arXiv:2609.04270(2026-09-07)
Source: arXiv:2609.04270 (2026-09-07)
05判据:什么时候堆 agent 才划算
05The Decision Rule: When Scale Actually Pays
把上面三组证据合起来,能提炼出一条判据。它有两个维度:验证一个候选答案有多贵,以及找到候选答案要搜多大空间。
Put the three studies together and one rule falls out. It has two axes: how expensive it is to verify a candidate answer, and how large a space you must search to find one.
图 3:右下是唯一值得堆量的象限。右上最危险,因为它看起来最像右下。
Fig. 3: Bottom-right is the only quadrant worth scaling into. Top-right is the dangerous one — it looks a lot like bottom-right.
右上角那个陷阱区值得多说一句。Anthropic 的实验直接测过:让 10 到 80 个 agent 各带一台虚拟机、一个共享论坛和一个自建仓库,跑 12 小时共建一款文字冒险游戏,还试了「规定角色分工」和「指定一个 CEO」两种额外提示。结论是三种提示没什么区别,做出来的游戏一律很差——跑不到人类可接受的速度、界面难以理解、学习曲线陡峭。原文的判断很直接:模型在这个领域「品味很差」,目前仍需要大量人类指导。
The top-right trap deserves one more paragraph. Anthropic measured it directly: 10 to 80 agents, each with its own VM, a shared forum and a self-hosted repo, running 12 hours to co-build a text-based open-world game — with two extra prompt variants ("prescribed roles" and "a CEO hierarchy"). The result: the prompts barely mattered and every game was bad — too slow for human play, inscrutable interfaces, brutal learning curves. The paper's verdict is blunt: models have poor taste in this arena and still require significant human direction.
动手前先回答一个问题:「我能写出一段代码,来自动判断某个候选产出是好是坏吗?」
能 → 你在右侧,可以考虑并行;
只能靠另一个模型判断 → 你在上方,先想办法把验证做成确定性的;
连你自己都要看半天才能判断 → 别堆 agent,先把标准想清楚。
Before you build, answer one question: "Can I write code that automatically decides whether a candidate output is good?"
Yes → you're on the right side; parallelism is on the table.
Only another model can judge → you're on the top half; make verification deterministic first.
Even you need a long look to decide → don't add agents. Go define the criterion.
06怎么用:四种编排模式与它们的代价
06How To: Four Orchestration Patterns and Their Costs
确定该并行之后,下一个问题是「怎么连线」。业界反复出现的就四种,各自在成本、控制力和灵活性之间做不同的取舍。
Once you've decided to parallelize, the next question is wiring. Four patterns recur across the industry, each trading cost, control, and flexibility differently.
| 模式Pattern | 结构Structure | 优势Upside | 代价 / 失效点Cost / failure point |
|---|---|---|---|
| 层级式 一个老板多个工人Hierarchical one boss, many workers |
中央编排器分派给专职 subagent,再把结果缝合central orchestrator delegates to specialized subagents, stitches results | 责任链清晰;有单一位置可以推理整次运行;非阻塞 runner 让快的先走,时间与 token 都更省clear responsibility chain; one place to reason about the run; a non-blocking runner lets fast agents move ahead, saving both time and tokens | 成本仍高;静态层级随复杂度上升变脆still expensive; static hierarchies grow brittle as complexity climbs |
| 去中心 / 网状Decentralized / mesh | 点对点通信,运行时协商角色peer-to-peer, roles negotiated at runtime | 某些任务上优于监督者式,因为直接交接省掉一层翻译can edge out a supervisor on some tasks — direct handoffs skip a translation layer | 一旦需要策略执行、审计追踪和回滚路径就很难成立hard to justify the moment you need policy enforcement, audit trails, and rollback |
| 顺序 / 链式Sequential / chained | 固定顺序流水线,每个吃上一个的输出fixed pipeline, each stage consumes the previous output | 最便宜、最可预测——整个工作流在第一个 agent 跑之前就定死了cheapest and most predictable — the whole flow is defined before any agent runs | 放弃并行;总延迟是每一步之和no parallelism; total latency is the sum of every step |
| 按需孵化On-demand spawning | 顶层编排器随需要孵化 subagenttop-level orchestrator spawns subagents as needed | 应付事先无法完全规划的工作;每个新 subagent 拿到干净的上下文窗口handles work you can't fully plan up front; each fresh subagent gets a clean context window | 失控孵化——早期系统会为一个只需要一个 subagent 的查询启动几十个runaway spawning — early systems launched dozens of subagents for a query that needed one |
实践中多数团队是混着用:主流程走层级式编排,只把复杂例外交给一个专门的编排器处理。
In practice most teams mix them: hierarchical orchestration for the main flow, with a dedicated orchestrator reserved for complex exceptions.
成本结构:规划和执行要分开定价
Cost structure: price planning and execution separately
一个常被忽略的架构决策:不是每个 agent 都需要同等推理能力。常见做法是用更强的 planner 把工作拆成边界清晰的任务,把常规实现、搜索、校验交给更便宜的 worker 模型。planner 做的决策数量很少,worker 消耗绝大部分 token,因为它们执行了工作流的主体。
A commonly missed architectural decision: not every agent needs the same reasoning capability. The usual shape is a stronger planner that breaks work into well-scoped tasks, with routine implementation, search, and validation handed to cheaper worker models. The planner makes relatively few decisions; the workers burn most of the tokens because they execute the bulk of the workflow.
这把成本优化的问题从「选一个最好的模型」变成了「给每类工作匹配模型」——模型选型从采购问题变成了架构问题。
That shifts cost optimization from picking a single "best" model to matching models to the type of work each agent does — model selection becomes an architectural decision, not a procurement one.
token 预算是设计约束,不是事后补丁
Token budget is a design constraint, not an afterthought
Anthropic 的多 agent 研究系统(Opus 4 做 lead、Sonnet 4 做 subagent)在其内部研究评测上比单个 Opus 4 agent 高 90.2%——同一套配置烧掉了约 15 倍于普通对话的 token。
所以:从第一张草图起就把 token 预算当作设计约束,而不是事后再打补丁。
Anthropic's multi-agent research system (an Opus 4 lead with Sonnet 4 subagents) beat a single Opus 4 agent by 90.2% on its own internal research evaluation — and that same setup burned roughly 15× the tokens of a normal chat.
So: plan the token budget as a design constraint from your first sketch rather than patching it in later.
让 agent 不打架的三个控制
Three controls that stop agents from fighting
- 给工作排序:用依赖感知的排程,让并行的改动按正确顺序落地,而不是在 merge 时撞车。
- 隔离执行:agent 活动跑在沙箱里,权限按最小必要范围划定,而不是散在你的基础设施上。
- 留审计轨迹:把动作绑回触发它的工作流和人,事后能回答「谁跑了什么、对哪些仓库、花了多少」。
- Order the work: dependency-aware sequencing so parallel changes land in the right order instead of colliding in merge conflicts.
- Isolate execution: run agent activity in sandboxes with scoped, least-privilege permissions rather than loose on your infrastructure.
- Keep an audit trail: tie actions back to the workflow and the person who triggered them, so you can answer who ran what, against which repos, and at what cost.
文件冲突这一条有个具体解法:git worktree 给每个 agent 自己的工作目录、共用一个对象库,未提交的编辑对其他 agent 不可见。任务级的抢占则靠显式文件锁来「认领」工作。但要注意,git 抓不到「单独看每个都没问题、合起来就坏了」的那类改动——所以有些方案还会加一层写入时冲突检测。
There is a concrete fix for file conflicts: git worktrees give each agent its own working directory over one shared object store, so uncommitted edits stay invisible to the others. Task-level coordination can use explicit file locks so agents "claim" work. But note that git misses the class of edits that each look fine in isolation and break together — which is why some setups add write-time conflict detection on top.
来源:OpenHands · What Is an Agentic Swarm? · Anthropic · Building Effective AI Agents
Sources: OpenHands · What Is an Agentic Swarm? · Anthropic · Building Effective AI Agents
07四类失效模式:规模一上来就必然出现
07Four Failure Modes That Show Up as Soon as You Scale
这一节全部来自 Anthropic Frontier Red Team 的实测数据。它们不是「可能会发生的风险」,而是在受控实验里被反复观察到的行为。
Everything in this section comes from Anthropic's Frontier Red Team measurements. These are not hypothetical risks; they are behaviors observed repeatedly in controlled experiments.
图 4:四类失效来自同一个根因——agent 之间「太像」,而它们的目标却可能不一致。数据来源:Anthropic Frontier Red Team(2026-08-13)。
Fig. 4: All four trace to one root cause — agents are too alike, while their goals may not be. Data: Anthropic Frontier Red Team (2026-08-13).
为什么「低方差」是根因
Why low variance is the root cause
单个 agent 是低方差的:在人类会做出多样选择的情境里,它们往往做出相同的动作。区分一个 agent 和另一个的,只有上下文、脚手架、底座模型三样东西。这三样都一样时,不同 agent 会在非常大的动作空间里选出几乎相同的动作。
An individual agent is low variance: it often acts the same way in situations where different people would spread out. All that differentiates one agent from another is its context, its scaffolding, and the underlying model. When those are the same, different agents take nearly identical actions even in a very large action space.
推论很直接:当一个 agent 做出糟糕决策时,很可能许多 agent 都做出了同一个糟糕决策。本来是孤立的问题,迅速变成系统性失效。这也正是 OpenAI 在 Navier–Stokes 里刻意给不同组喂不同问题变体的原因——多样性必须人为构造,它不会自己出现。
The implication is direct: when one agent makes a bad call, many agents likely make the same bad call. What would have been an isolated problem becomes a systemic failure fast. This is precisely why OpenAI deliberately fed different problem variants to different groups in the Navier–Stokes run — diversity has to be constructed; it does not emerge on its own.
每个被测模型都抽象地知道信息源有自己的动机、共识不等于证据。缺的是——在没人提醒的情况下,主动照这个认知去行动的倾向。而且协调能力不会随智能提升自动出现,也不会随个体对齐自动出现。
Every model tested abstractly understands that information sources have their own incentives and that consensus is not evidence. What's missing is the disposition to act on that knowledge without being prompted. And coordination does not naturally emerge from stronger intelligence, nor from alignment at the individual level.
Salesforce Research 与 UNC 的 EvoHarnessBench(arXiv:2609.04280,9/7)把非平稳性放在外部供给的 harness(工具 / skills / 子 agent 三条轴)上,而不是任务流上。17 条演化流、802 任务、520 工具、42 skills、62 agents。三个持续存在的缺口:①仅仅扩充 harness 就会让此前已解决的任务退化(harness 诱发的遗忘);②自演化带来的收益在不同阶段、不同能力轴、不同环境上都不稳定;③保住旧能力与适应新能力会互相拉扯。
对独立开发者的直接含义:你每加一个 MCP server 或一个 skill,都可能让此前跑通的流程悄悄变差——这正是 Claude Code 的 /skill-doctor 这类工具存在的理由。
EvoHarnessBench from Salesforce Research and UNC (arXiv:2609.04280, Sep 7) places non-stationarity in the externally supplied harness (tools / skills / agents) rather than the task stream: 17 evolution streams, 802 tasks, 520 tools, 42 skills, 62 agents. Three persistent gaps: (1) harness expansion alone degrades previously solved tasks (harness-induced forgetting); (2) gains from self-evolving adaptation are inconsistent across stages, capability axes, and environments; (3) retention and adaptation pull against each other.
The direct implication for a solo developer: every MCP server or skill you add may quietly degrade a workflow that already worked — which is exactly why tools like Claude Code's /skill-doctor exist.
来源:Anthropic Research(2026-08-13) · arXiv:2609.04280(2026-09-07)
Sources: Anthropic Research (2026-08-13) · arXiv:2609.04280 (2026-09-07)
08框架与工具:一份快照,不是排名
08Frameworks: A Snapshot, Not a Ranking
框架层迭代极快,下面这份按快照看待,选型更多取决于你现有的技术栈而不是任何榜单。
The framework layer moves fast. Treat the list below as a snapshot; the right pick depends far more on your existing stack than on any leaderboard.
| 框架Framework | 核心原语Core primitives | 什么时候选它When to pick it |
|---|---|---|
| OpenHands | 开源平台 + Software Agent SDK,沙箱执行、可审阅产出open-source platform + Software Agent SDK, sandboxed execution, reviewable outputs | agent 需要在真实仓库里跑命令、产出能审阅的 diff,并最终进入受治理的团队工作流agents must operate on real repositories, run commands, produce reviewable output, and eventually move into governed team workflows |
| OpenAI Agents SDK | agents / handoffs / guardrails / tracing;实验性 Swarm 项目的继任者agents, handoffs, guardrails, tracing; successor to the experimental Swarm project | 要 provider 无关、跨大多数 LLM 都能跑you want provider-agnostic and it must run across most LLMs |
| LangGraph | 显式的节点-边图;一等公民支持 map-reduce fan-outexplicit node/edge graph; first-class map-reduce fan-out | 下游分支数量要到运行时才知道the number of downstream branches is unknown until runtime |
| Microsoft Agent Framework | 融合 AutoGen 与 Semantic Kernel 的多 agent / 工作流应用框架merges AutoGen and Semantic Kernel ideas for multi-agent and workflow apps | 已在微软生态里;版本相关的状态声明请以微软当前文档为准already in the Microsoft ecosystem; verify version-specific status claims against current Microsoft docs |
| CrewAI | 基于角色定义,支持顺序 / 层级 / 共识三种流程role-based definitions with sequential, hierarchical, and consensual processes | 角色分工很清晰时。务必设显式迭代与重试上限——不设的话一个重试的 agent 能把简单流程变成天价流程roles are cleanly separable. Set explicit iteration and retry limits — without them a retrying agent turns a simple flow into an expensive one |
| Google ADK | 开源 Agent Development Kit,面向多 agent 应用open-source Agent Development Kit for multi-agent applications | 主要在 Google Cloud 上开发you develop primarily on Google Cloud |
这些框架底下其实是同一个 reason-and-act 循环:agent 查询 LLM、采取动作、观察结果、迭代到任务完成。swarm 就是把这个循环同时复制很多份。换句话说,框架帮你解决的是编排和可观测,不是循环本身。
Underneath all of these sits the same reason-and-act loop: query the LLM, take an action, observe what happened, iterate until done. A swarm is that loop replicated across many agents at once. In other words, the framework buys you orchestration and observability, not the loop.
产品层面公开披露的 subagent 规模仍在几百量级——例如有资料称 Kimi K2.5 的 swarm 可扩展到 100 个 subagent、1500 个协调步,K2.6 把部署上限扩到 300 个 subagent、4000 个协调步。报道 OpenAI 的万级 agent 是内部研究配置,不是任何人现在能买到的产品能力。规划自己的系统时,请以「几个到几十个」为起点。
Publicly disclosed product-level subagent counts are still in the hundreds — one write-up describes Kimi K2.5's swarm scaling to 100 subagents and 1,500 coordinated steps, with K2.6 extending the envelope to 300 subagents and 4,000 steps. reported OpenAI's 10,000 agents were an internal research configuration, not a product capability anyone can buy today. Plan your own system starting from "a handful to a few dozen."
来源:OpenHands(2026-07-11);Kimi 规模数字为该文转述,未见一手确认。
Source: OpenHands (2026-07-11); the Kimi figures are as reported there, without primary confirmation.
09独立开发者怎么落地:一条不烧钱的路径
09A Solo Dev's Playbook: Scaling Without Burning Money
上面的东西大部分是实验室规模。对一个人的项目,可迁移的部分其实很具体。
Most of the above is lab-scale. For a one-person project, the transferable parts are quite concrete.
- 先给你的任务定一个「机器可判」的成功标准。 能写成一个跑得通的脚本(测试、类型检查、benchmark 分数、编译通过)就写出来。这一步做不到,后面全是浪费。
- 先用一个 agent 跑通一次,把循环看清楚。 只有在你能看见并约束每个 agent 在做什么之后,才扩到并行。
- 并行时用 git worktree 给每个 agent 独立工作目录。 未提交的编辑互不可见,冲突从「运行时打架」降级为「merge 时冲突」。
- 把 reviewer 换成跨家族模型,不要用同一个模型自审。 这是今日论文里性价比最高的一条:跨家族中档 reviewer +12pp 且零损坏;同模型自审检出率最高却零收益。
- 给 planner 用强模型,给 worker 用便宜模型。 planner 决策少,worker 烧掉绝大部分 token。
- 设死重试与迭代上限。 尤其在 CrewAI 这类框架上,不设上限的重试是最常见的账单爆炸来源。
- 加一层遥测,而不是靠感觉。 参考第 27 课(OpenTelemetry):按
agent.name拆 token 消耗,你会很快发现哪个角色在空转——就像论文里那个进化成空 prompt 的 planner。
- First define a machine-checkable success criterion. If it can be written as a script that runs (tests, type checks, a benchmark score, a successful compile), write it. Skip this and everything after is waste.
- Run it once with a single agent and watch the loop. Only fan out to parallel agents once you can see and constrain what each one is doing.
- When you do parallelize, give each agent its own git worktree. Uncommitted edits stay invisible to the others, downgrading conflicts from "runtime fights" to "merge conflicts."
- Make your reviewer a cross-family model; never same-model self-review. This is the highest-leverage line in this week's papers: a cross-family mid-tier reviewer gives +12pp with zero damage, while same-model self-review has the highest recall and zero payoff.
- Strong model for the planner, cheap models for the workers. The planner makes few decisions; the workers burn most of the tokens.
- Hard-cap retries and iterations. Especially on frameworks like CrewAI, uncapped retries are the single most common source of bill blowouts.
- Instrument it instead of guessing. Following Lesson 27 (OpenTelemetry): break token usage down by
agent.nameand you'll quickly find the role that's idling — much like the planner that evolved into an empty prompt in the paper.
本文档的证据基础,一半来自厂商自述(OpenAI、Anthropic 的实验都由它们自己设计、自己评测),一半来自小样本论文(证据 C 明确自称「100 道题上的受控试点」)。目前这个领域几乎没有第三方复现。把结论当作「有实测支撑的工作假设」,而不是定论。
Half the evidence here comes from vendor self-reports (OpenAI's and Anthropic's experiments were designed and scored by themselves), and half from small-sample papers (Evidence C explicitly calls itself "a controlled pilot on 100 problems"). There is almost no third-party reproduction in this area yet. Treat the conclusions as working hypotheses with measurements behind them, not as settled findings.
10学习资源
10Resources
- OpenAI · On the Navier–Stokes Millennium Prize Problem —— 万级 agent 群体的工程细节,建议直接读「How we found the proof」一节。
- Anthropic · Patterns and problems in emerging multiagent systems —— 目前公开材料里对群体失效模式记录最完整的一份。
- Anthropic · Building Effective AI Agents —— orchestrator-workers 模式的原始出处。
- Anthropic · Effective context engineering for AI agents —— 并行 subagent 各自隔离搜索上下文、只把提炼结果交回 lead 的做法。
- OpenHands · What Is an Agentic Swarm? —— 框架与模式的横向梳理,链接密度高,适合当索引用。
- arXiv:2609.04217 · 2609.04270 · 2609.05279 · 2609.04280 —— 本周的四篇「泼冷水」论文。
- arXiv:2609.04894 —— 综述《From Language Models to World-Acting Systems》,把 model / harness / environment 分开评估的框架。
- OpenAI · On the Navier–Stokes Millennium Prize Problem — engineering detail on the 10,000-agent swarm; go straight to "How we found the proof."
- Anthropic · Patterns and problems in emerging multiagent systems — the most complete public record of swarm failure modes to date.
- Anthropic · Building Effective AI Agents — the original source for the orchestrator-workers pattern.
- Anthropic · Effective context engineering for AI agents — on parallel subagents keeping isolated search contexts and returning only distilled results to the lead.
- OpenHands · What Is an Agentic Swarm? — a broad survey of frameworks and patterns; link-dense, useful as an index.
- arXiv:2609.04217 · 2609.04270 · 2609.05279 · 2609.04280 — this week's four cold-water papers.
- arXiv:2609.04894 — the review From Language Models to World-Acting Systems, which separates model / harness / environment for evaluation.