斯坦福 DeLM：去中心化多 Agent，成本砍半的架构秘密
📌 “Shared failures, verified gists, no boss”——这是斯坦福团队给多 Agent 协作的新定义。让 Agent 们共享失败经验、自发协作、不要中心控制器。成本直接砍半。
传统多 Agent 架构的问题
过去两年，多 Agent 系统的标准架构长这样：
一个中心协调器（Orchestrator）负责：接收用户任务 → 分解子任务 → 分配给各个 Agent → 收集结果 → 整合输出。每轮协作中，协调器都要调用一次 LLM——通常是最强的模型，因为它的判断直接影响全局结果。
这个架构的效率瓶颈很明显：
- 协调器是性能瓶颈：每次协调都要调大模型 → 延迟累加
- 协调器是成本黑洞：强的协调模型 API 调用占多 Agent 系统总 token 消费的 40-60%
- 协调器是单点故障：它坏了，整个系统停摆
- 通信冗余：Agent → 协调器 → Agent 的三角通信中，大量信息被重复编码
斯坦福 DeLM（Decentralized Language Model coordination）试图用一种更"生物"的方式解决这个问题。
DeLM 的核心设计
DeLM 不需要中心协调器。取而代之的是两个共享机制：
① Shared Failures（共享失败记录）
每个 Agent 的执行结果（成功或失败）都被写入一个共享的"经验日志"。其他 Agent 在开始自己的子任务前，可以先读这个日志——知道什么方法已经被试过、什么已经失败了，避免重复犯错。
这跟人类团队协作的逻辑一样：不需要一个经理盯着每个人，只要所有人把自己的进展和失败透明地写在一个共享文档里。
② Verified Gists（验证摘要）
Agent 完成子任务后，生成一个简短的结构化摘要（gist），包含：做了什么、结果是什么、置信度多少。下一个 Agent 可以基于这个摘要决定自己的行动策略，而不是重新读原始输出。
关键设计：gist 是机器可验证的——包含一个校验字段，让后续 Agent 能快速验证"这个摘要是否准确反映了原始结果"，不需要信任。
为什么成本能砍半
技术报告的核心数据：
| 指标 | 中心化多 Agent | DeLM |
|---|---|---|
| 协调层 LLM 调用次数/任务 | 8-15 次 | 0 次 |
| 总 token 消费 | 基准线 | -47% |
| 任务完成率（复杂任务） | 78% | 82% |
| 平均延迟 | 基准线 | -35% |
成本节省主要来自两个地方：
砍掉了协调器的全部 LLM 调用。在 5 个 Agent 协作的典型任务中，中心协调器通常要调用 8-15 次，每次数百到数千 token。这些全没了。
Agent 间通信更高效。不再是"发完整结果 → 协调器理解 → 转述给下一个 Agent"的三角路径，而是 Agent 直接读共享日志和 gist——信息一次写入，多次消费。
对独立开发者的实战意义
如果你在做多 Agent 产品（客服分流、代码审查流水线、内容生产 pipeline），DeLM 的架构有直接参考价值：
能用 DeLM 的场景：
- Agent 之间的任务可以天然并行化（各自独立处理不同的数据/用户/文件，只在关键节点汇合）
- 错误是有价值的信号（知道"什么不行"跟知道"什么行"一样重要）
- 不需要实时、紧密的协同（Agent 之间可以接受几十毫秒的延迟读共享日志）
不适合 DeLM 的场景：
- 需要全局一致性的实时决策（如金融交易）
- Agent 之间存在复杂的前后依赖关系（A 的输出必须被 B 立刻消费，不能等 B 自己去日志里找）
- 安全合规要求每个决策都有明确的责任人（去中心化 = 不好追溯"谁"做了"什么决定"）
简化实现思路（不需要等斯坦福开源）：
如果你在做一个多 Agent 产品，现在就可以从 DeLM 中受益——不是用整个框架，而是引入两个设计：
- 给所有 Agent 一个共享的"错误日志"文件（SQLite 表），任何 Agent 在执行前先查"这个已经被试过吗？"
- 让 Agent 的输出只包含"结论 + 置信度 + 可验证字段"，而不是冗长的完整推理过程
这两件事不需要新框架，不需要新依赖，不需要改业务逻辑。但效果可能跟 DeLM 一样：减少协调层的 API 调用，降低 token 消费。
参考来源：
最后更新：2026-06-21
保持关注，记得把网址 （17you.com） 加收藏夹！有空经常来网站看看！我们每天都分享最新鲜、最实用的AI知识、最新动态、最新技术，以及最新的应用场景。