AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
Key takeaways Teams of agents unlock a new axis of inference-time scaling. On challenging coding tasks, well-organized teams outperform single agents, with gains of up to ~10 percentage points on ProgramBench. But these gains come at 3–7× higher cost. The question is not whether more agents help, but how to make that additional compute count. Where you allocate agents matters more than how many you add. On ProgramBench, delegating only exploration and planning matches the performance of delegating planning, implementation, and verification together at half the cost. Collaboration pays off most when agents target the task's actual bottleneck. A strong lead with cheap workers delivers near-frontier performance at 70% lower cost. A Sol lead coordinating 16 inexpensive Luna planning workers reaches 61.8% reward, compared with 63.2% for an all-Sol team delegating every stage, while reducing cost from $510 to $155. Agent teams are building software In the past year, teams of coding agents have moved from interesting demos to building large-scale software projects. Sixteen Claude agents wrote a 100,000-line C compiler that can build the Linux kernel, in a project that took about 2,000 agent sessions and $20,000 in API costs [1]. Cursor ran hundreds of agents that together wrote a web browser from scratch, more than a million lines of code, in about a week [2]. Bun was ported from Zig to Rust in 11 days, with 64 Claude agents running in parallel at its peak [3]. Each of these teams produced working software, but they differ from one another in many ways at once, from the models and roles to the scope of the projects themselves. The C compiler's agents worked as peers with no orchestrator and claimed tasks through lock files. Cursor used a hierarchical structure, with planners recursively decomposing work into subtasks delegated to hundreds of worker agents. Bun assigned fixed roles, giving each piece of work to one implementer, two adversarial reviewers, and one fixer. Comparing them, however, says little about which design choices mattered or what they cost compared to a single agent. Factory's study of their own multi-agent system, which cycles an orchestrator, an implementer, and a validator in a fixed loop, shows how large that cost can be [4]. On one task, rebuilding the geospatial library GDAL, their three-role team more than doubled the reward achieved by a single agent, nearly reaching behavioral parity with the reference program, but cost 14 times as much and took 13 times as long. So agent teams can do more than a single agent, but they cost more to run and usually take longer. This raises an important question: if a team of agents is a new way to spend inference compute, how should it be organized to be both effective and efficient? To answer it, we built a controlled testbed and ran teams of coding agents on it. Figure 1. An illustrative run of a coding-agent team. A lead hands out work to its workers, who explore the original program, write code, and check it in a shared workspace. A controlled testbed A minimal harness We built a deliberately minimal harness, inspired by mini-SWE-agent [5], so that we could change one design choice at a time. Every agent works through a simple bash tool, in one workspace shared by the whole team. One agent, the lead, receives the task and hands out work with a delegate_agent tool. A worker sees only the subtask it is given and reports back when it is done. Given the task, the lead dynamically decides how many workers to spawn, what each one does, and how to consolidate what they return.1 Each delegate_agent call either starts a new worker with a fresh context window or resumes a worker the lead has used before. A resumed worker keeps its prior context, so the lead can follow up with an agent that already knows part of the program. For example, the lead can ask a worker to fix the bugs in the code it wrote, instead of briefing a new worker from scratch. From there, we vary five things: Where the lead uses workers. We instruct the lead agent with two main prompts, which differ in how much guidance they give. The minimal prompt tells the lead that it is in charge of a team and asks it to give workers distinct, independent tasks, but leaves everything else, from how many workers to use to how to decompose the task, to the lead. The PIV prompt adds a structured workflow of exploring and planning (P), implementing (I), and verifying (V), and asks the lead to use workers in all three stages. How the lead waits. A blocking lead waits for its workers to report back and does nothing in the meantime. An asynchronous lead keeps working while they run, and has two more tools, wait_for_updates to wait for the next report and list_agents to check on its workers. Which models play which role. Does every agent on the team need the strongest, most expensive model? We test this with two kinds of teams. In a homogeneous team, the lead and its workers all run the same model. In a heterogeneous team, the lead keeps the strong model, but the workers run a cheaper one. Think of a senior engineer who directs the work and makes critical decisions, with junior engineers doing most of the legwork. How many workers there are. Is a bigger team always better? To explore this, we compare two setups. In the first, the lead decides on its own how many workers it needs. In the second, we fix the team size at two, four, eight, or sixteen workers and see how reward and cost change as the team grows. How agents communicate. By default, all communication goes through the lead, which hands out each subtask and receives each worker's report. In one set of runs, we provide agents with a send_message tool and let them message each other directly. Figure 2. Two leads hand out the same subtasks, and each worker run takes the same time. The blocking lead sits idle until its workers report back. The asynchronous lead keeps working and starts the second round as soon as the first reports arrive. Bars are spans of work, downward arrows are calls to delegate_agent, and upward arrows carry reports back to the lead. Timings are illustrative. ProgramBench We test these choices on ProgramBench [6], a benchmark of 200 programs to rebuild from scratch. In each task, the agent starts from an empty workspace with the original program's executable, which it can run but not read, and that program's documentation. It has to probe the program to discover its interface, edge cases, and behavior, then write a new implementation that behaves the same way. We score each task by the share of a hidden suite of behavioral tests that the rebuilt program passes, and average this score over tasks to get the reward we report throughout.2 The tasks range from small command-line utilities like jq and ripgrep to large systems like SQLite, FFmpeg, and the PHP interpreter. The most challenging remain far out of reach. On FFmpeg, the best entry on the public leaderboard passes about 10% of tests. Each task needs all three stages of the workflow, figuring out what the program does, writing it, and checking it against the original. That makes ProgramBench a good testbed for seeing which stages benefit from extra agents. Figure 3. One ProgramBench task, dsq, a command-line tool that runs SQL queries over JSON, CSV, and other data files. The top panel is a solo Sol agent with the minimal prompt, and the bottom panel an asynchronous Sol team with the PIV prompt. The solo agent writes its program as one Python file, while the team splits it into modules, some written by workers. The team panel follows the files of one run, commands are simplified from the agents' own, and timings are illustrative. We focus primarily on three GPT-5.6 models, Luna, Terra, and Sol, in increasing order of capability and cost. Unless noted otherwise, we ran each configuration three times on all 200 ProgramBench tasks and report averages over the three runs for reward, total cost, and total wall-clock time. A single task's score varied from run to run with a standard deviation of about 6 points, but the benchmark-wide average was far steadier, with a standard deviation of 0.5 points for a typical configuration and 1.4 for the noisiest. Every configuration ran on the same tasks, so we compare each team with its solo baseline task by task and report 95% confidence intervals of those differences. We also ran Commit0-Lite [7], a set of 16 Python libraries whose implementations have been removed. The agent is given each library's repository skeleton, documentation, and unit tests, and has to fill in the code so that the tests pass. In ProgramBench, the agent has to work out what to build by running the original program. In Commit0, these provided materials spell it out, so the benchmark shows whether the same stages pay off when the specification is already given. With only 16 tasks, we use it as a secondary check. Teams outperform solo agents, at a cost We start with the simplest comparison, a single Sol agent against a team of Sol agents. With the same minimal prompt, a blocking team passed 61.8% of tests on average, against 52.1% for the solo agent. Giving the solo agent the PIV prompt closed part of that gap (57.7%), but a blocking team with the PIV prompt still came out about 5 points ahead (63.1%). We also ran both prompts with an asynchronous lead, which can keep working while its workers run. All four Sol teams cost between 4 and 7 times as much as the corresponding solo agent. With the PIV prompt, the asynchronous team finished in 19.5% less time than the blocking one and reached about the same reward. With the minimal prompt, the asynchronous team finished in 60% less time, but its lead did more of the work itself, delegating just 4.4 times per task, compared to 6.1 for the blocking lead. Its team gained only 3.8 points over the minimally prompted solo agent, against 9.7 for the blocking team, and at 55.9% it even fell below the PIV-prompted solo agent (57.7%). Figure 4. Mean reward against inference cost (left) and wall-clock time (right), each the total for all 200 tasks averaged over three runs. Error bars are 95% intervals of each team's paired per-task difference from the corresponding solo agent. Workers pay off most in planning To find out where workers pay off, we instructed the lead to delegate subtasks to workers in just a single stage, while doing the other two stages itself. Under exploration and planning (P), workers run the program to learn its behavior and draft a plan, and the lead implements and verifies. Under implementation (I), workers write the code. Under verification (V), workers test the lead's implementation. Planning was the clear winner. Among asynchronous teams, a lead that delegates only planning matched the reward of one that delegates every stage (63.6% against 63.2%) at half the cost ($249 against $510). Measured as reward gained per $100 of added cost, planning was about twice as efficient as the next-best stage.3 Figure 5. Asynchronous Sol teams that delegate one stage or all three. Means over three runs. Lines run from the solo PIV agent to each team. The dashed arrow runs from the PIV team to the planning team, which costs half as much. Error bars are paired 95% intervals relative to the solo PIV agent. For example, on dsq, the solo agent with the PIV prompt passed 60% of its tests on average. Teams that delegate only planning passed 79% with an asynchronous lead and 76% with a blocking one, and each of their six runs beat every solo run. Teams that delegate implementation or verification passed only 58% to 71%. The reason lies in the benchmark's design. The target program is a black box, so its behavior has to be discovered by running it. Planning workers do this in parallel, each probing a different part of the program's interface and handing the lead what it found. The lead then writes the code itself, with a much fuller pi [truncated for AI cost control]