Master Agent、任务看板、Advisor 三种模式，分野不在用几个模型，而在「下一步做什么」由谁决定：中心节点、共享状态，还是当前执行者。任务看板尤其不是简单的待办列表，它靠 PENDING→CLAIMED→RUNNING→SUCCEEDED/FAILED 状态机加锁或租约，才能在 Worker 崩溃时让任务被重新领取而不重复执行——这正是它能把调度权从中心下放出去的前提。

把决策集中到一个 Master、由它给 Agent 派活，这套结构在 Jenkins 里已经跑了十几年：Master 管任务调度、插件与作业配置，Agent 接指令在本地执行具体构建，靠分布多节点提吞吐。得物文章里的 Master Agent 模式本质是同一套控制论骨架搬进 LLM 场景——理解了 CI/CD 里 Master 不亲自干活、只做分发和编排，就懂了为什么它适合流程固定的任务。

Anthropic 阵营算的是另一笔账：面向开放式研究查询，LeadAgent 拆任务、动态生成子 Agent 并行检索，内部评测成功率提升约 90%，代价是巨量 token 和复杂运维。Cognition 阵营则从 Devin 写可运行代码的痛点出发喊「先别建」：任何上下文不一致都会直接变成编译或逻辑错误，子 Agent 之间的隐式依赖让协调成本吃掉收益。同一件事，一方看到弹性，一方看到脆弱。

UC 伯克利分析 5 个主流 MAS 框架、150 多个任务，归纳出 14 种失败模式，三大类里规范与系统设计问题占 41.8%、智能体间错位占 36.9%、任务验证缺陷占 21.3%——锅不在单个模型的幻觉，在协作机制本身。斯坦福 CooperBench 更直接：两个 AI 编程 Agent 协作时性能下降近一半，且开启通信有时反而加剧失败，死锁率从 25% 升到 65%。控制权下沉得越彻底，这类错位越难被中心发现。

当下能看到的关键变量是协议层：谷歌 2025 年 4 月发布 A2A，用 Agent Card 做能力发现、基于 HTTP/JSON-RPC/SSE 通信，同年 6 月移交 Linux 基金会，成员扩至 100 家以上，与 Anthropic 的 MCP 分层共存。但得物文章谈的是单系统内控制权分配，A2A 解决的是跨组织互操作，两者不在同一层。焦点会是企业到底需要跨厂商协作，还是先把内部编排跑稳——要等规模化落地案例才能看清。

得物把「上下文边界」列为划分 Agent 职责的关键，但边界划在哪一步才是真问题。一个可切入的实证是 Claude Code 的做法：父 Agent 的 allowedTools 不会自动传给子 Agent，「父权限不穿透」被写进注释；同进程并发靠 AsyncLocalStorage 给每条异步链独立存储，避免共享 AppState 串数据。也就是说，隔离不是靠约定，是靠运行时机制强制。那共享与隔离的权衡点该由谁定？