AI 智能體羣組是否不應照搬人類企業層級?
Are We Making a Fundamental Mistake by Modelling AI Agent Swarms on Human Corporate Hierarchies?
Tim Gaul 以編碼智能體實驗探討,AI 智能體羣組是否應避免照搬人類企業層級,改以共享工作空間協調。他以 Beads 管理任務與依賴、Agent Mail 保存協作對話、Git 管理程式碼;首次運行產出大量超出所需的程式碼、測試和文件,暴露工作範圍膨脹等問題。作者提出限制子智能體數量、工作範圍及輸出,並建議以相同任務比較層級式、共享看板和混合式協作。
Code. Tests. Documentation. They kept coming. And coming. And coming. Coherent work, far more than I needed. I'd given a group of coding agents an intent, a shared board and room to recruit help. They chose their own work and roles. I'd barely given them a finish line.
The two intrepid Saffas in the banner are looking at the choice that led me there: a manager relaying every note, or a wall where a discovery can wait for whoever needs it. To see why I tried the wall, rewind to an incident I couldn't get out of my head.
The noticeboard I couldn't stop thinking about
During an internal cybersecurity evaluation, OpenAI agents that were meant to be isolated found a way to leave messages for one another in a shared package repository. They developed an improvised board, shared findings and organised workstreams. The activity escalated into the Hugging Face security incident. In an independent investigation, METR describes agents taking actions that risked failing their own assigned tasks to generate information for the group. OpenAI has also described agents using public wiki pages as shared boards in other cases.
That is a serious failure of containment, with real people and systems on the receiving end. I wouldn't hold up the outcome as a model to copy. What caught my attention was the shape of the coordination. Agents found a persistent place to leave clues, picked up each other's work and sometimes put a collective objective ahead of their own run. No manager had been appointed to read every note and forward it to the right specialist.
It made me ask an uncomfortable question: if agents can coordinate this way when nobody wanted them to, what might a carefully bounded version look like when we do want them to collaborate? First, I had to ask why we keep reaching for the org chart.
Why do we keep drawing org charts?
The corporate diagram is understandable. Human hierarchies deal with limits on attention, memory, availability and communication. A manager keeps priorities straight and takes responsibility. Every relay also takes time: receive the update, compress it, work out who needs it, pass it on, then wait for the answer.
Agents have limits, too: context windows, inference cost, reliability, permissions and compute. A manager can help, particularly when authority or sequence matters. But a permanent relay is only one way to deal with those limits. A persistent shared environment lets an agent publish what it learned once, where another agent can find it, decide whether to take it on and choose the role the work needs.
So I tried a considerably less dramatic version
Here was the wiring. Beads held the tasks, their dependencies and the claims that told the others who was doing what. Agent Mail held the conversations and findings around that work. Git held the code changes. OpenCode, Claude Code and Codex were ways of running the agents, not departments with assigned jobs. The agents picked pieces, took on the roles those pieces needed and recruited subagents for smaller jobs. One could coordinate that little group while the rest of the board carried on.
The part I found most convincing was that a useful note could outlive the agent that wrote it. Another agent could find it later and carry on, without me introducing the two. For someone who has spent years watching context disappear into meetings and chat threads, that felt rather promising.
At first the output looked like a win. Code, documentation and tests arrived quickly, and the pieces held together. Then I saw the scale of it.
That was my road-to-Damascus moment. I'd recreated the coordination conditions that had caught my attention in the Hugging Face incident: a persistent shared space, agents picking up one another's work and recruiting more help. Mine wasn't a security incident. But I'd watched that capacity for self-organisation amplify an overbroad brief. The agents were eager to satisfy it; every useful-looking addition seemed to invite another. They could coordinate. I hadn't told them when to stop.
I've since pulled the scale back. Autonomy can make a team move quickly and keep its work connected, but it needs an enclosure: limits on how many helpers an agent can spawn, how far it can stretch the scope, and how much documentation and testing a task actually warrants. The aim is useful work with a clear definition of done.
The redesign adds limits on helpers, scope and output before the next run.
Let the work do the introductions
That first run overshot, but the coordination pattern is still tempting. Picture an ordinary software change. An agent chooses to make it, then publishes the commit, its intent and the tests it ran. Another picks up testing, reproduces a defect and posts the failing case. A third decides the change needs a security look and spots an implication the tester wasn't looking for. Whoever has the right context can claim the fix and link a new commit to the evidence. Beads tracks the claims, Agent Mail carries the findings, and Git identifies the code they're about. Those are jobs the agents took on, not profiles they were given at the door.
Agents can discover work asynchronously. Responsibility for the outcome stays explicit.
An old idea with new tools
The mechanism has older relatives. In blackboard architecture, independent knowledge sources add partial results to a shared representation of a problem. Stigmergy describes coordination through traces left in an environment, an idea developed from observing social insects. Neither analogy tells me whether language-model agents will collaborate well. But look at that trail through the Cape fynbos: one agent leaves a useful clue, another finds it later, and neither needs to know who comes next.
The clue matters because the next traveller can find and check it.
Gas City shows another way to orchestrate agents around durable work. Beads gives tasks, dependencies and atomic claims a home that outlives an agent's session. Agent Mail is the shared home for conversation: its persistent, searchable threads can carry discoveries, problems, opportunities, proposals and decisions linked to evidence. Those are the pieces I used, and why this feels possible now in a way it didn't when every agent's world ended with its chat window.
But durable records alone aren't the whole proposal. I haven't yet shown how an agent discovers a relevant Mail thread when nobody knew to address it to them, or how a correction reaches every agent that relied on a plausible but wrong finding. That calls for clear habits about what goes into Mail, what becomes a Bead and how the records point to each other.
Where the fences go
My experiment exposed the friendly version of the failure: duplicated effort, scope creep, too much documentation and tests without a clear stopping rule. A shared board can also spread misinformation, run up inference costs or leave two agents working from conflicting decisions. The Hugging Face incident shows the much more serious version when objectives, access and containment go wrong.
That means limits on parallel workers, scope, budgets and permissions. Beads already provides a clear claim on a piece of work; the agents need to use those claims consistently, release abandoned work and link their findings to evidence. When a Mail finding is wrong or out of date, its correction must reach the agents relying on it. It also means arbitration when agents disagree, controlled sequencing where it matters, and human approval for consequential actions. Some tasks really do need a single authority.
I still want management of the system. Humans set the intent: the outcome that matters, the boundaries and what counts as done. They set priorities and acceptable risks, judge whether the result is any good, and remain accountable for what gets released. A manager can set the route and the rules without carrying every note from one traveller to another.
How I'd test this properly
My first run gave me a useful lesson, not a controlled comparison. To find out which coordination shape actually works, I'd give the same representative jobs to three arrangements: a manager-led hierarchy, a shared blackboard and a hybrid where agents discover routine work but conflicts and consequential steps go through a designated authority. Keep the human-set intent, agents, models, tools and resources the same. Measure the quality of accepted outcomes, elapsed time, inference cost, duplicate work, recovery after interruption, human intervention and how far errors propagate.
I'd read the failures as closely as the averages. Did the shared space surface a security concern sooner, or amplify a false one? Did a manager prevent conflict, or become the queue? Did the hybrid keep authority clear while letting specialists discover one another's work?
I don't assume decentralisation wins. A hierarchy may be cheaper or safer for small, sequential jobs. A shared environment may help when discoveries arrive unpredictably and specialists can work in parallel. The design ought to follow the work and its constraints.
For now, I have a promising mechanism, a memorable pile of output and a better idea of where the fences belong. Humans still provide intent, judgement, accountability and governance. I'm curious how far agents can take the rest when we stop drawing miniature corporations by reflex.
On my list are Zed's Delta, Happier, Gas City and OpenAI's Symphony, and I suspect I've missed plenty. If you've tried one of them, I'd love to hear what worked and where it fell down.
What else should I look at if I want agents to choose work, share discoveries and stay within human intent?
Read this article on my blog: Are We Making a Fundamental Mistake by Modelling AI Agent Swarms on Human Corporate Hierarchies?
Connect with me on LinkedIn.
來源:DEV Community · dev.to



