GitHub 揭示了多代理 AI 工作流程在生产中失败的原因

GitHub 的工程团队发布了一份技术分析报告，解释了多代理 AI 系统在生产中持续失败的原因，而且与模型能力无关。根据该公司 2026 年 2 月 24 日的分析，大多数故障都可以追溯到开发人员在从单代理架构扩展到多代理架构时忽略的结构组件缺失。

对于加密货币建设者来说，时机很重要。随着自主交易机器人、DeFi 代理和人工智能驱动的协议治理系统的激增，GitHub 发现的同样的工程故障正在导致区块链应用程序崩溃。一名经纪人关闭了另一名经纪人刚刚开仓的头寸。治理提案通过了验证，但未能通过无人预料的下游检查。

核心问题

“当代理开始处理相关任务（分类问题、提出更改建议、运行检查）时，他们就开始对状态、排序和验证做出隐式假设，”GitHub 的 Gwen Davis 写道。如果没有明确的指令和接口，在共享状态上运行的代理会产生不可预测的结果。

这反映了最近行业研究的结果。 2025 年 6 月对多代理 LLM 挑战的分析强调，协调开销和上下文管理是主要的失败向量，特别是当代理具有相互竞争的目标或在扩展操作中丢失对话历史记录时。

三种实际有效的模式

基于自然语言的类型化模式。 代理交换混乱的 JSON 或不一致的字段名称会立即破坏工作流程。 GitHub 建议严格的类型定义，这些定义在无效负载上会快速失败，而不是向下游传播不良数据。

行动模式胜过模糊的意图。 “分析这个问题并帮助团队采取行动”对人类来说听起来很清楚。不同的代理将其解释为关闭、分配、升级或不采取任何行动——每一个都是合理的，没有一个是可自动化的。将输出限制为明确的操作集可以消除歧义。

用于执行的模型上下文协议。 类型化模式和操作约束只有在一致执行的情况下才有效。 MCP 在执行前验证每个工具调用，防止代理发明字段或跨接口漂移。

为什么加密货币开发人员应该关心

2025 年 8 月关于扩展多代理系统的研究将错误传播确定为一个关键漏洞——通过后续决策级联的单一幻觉。对于管理真实资本的交易系统来说，这并不是调试上的不便。这是一个清算事件。

GitHub 的核心见解直接适用：将代理视为分布式系统组件，而不是聊天界面。这意味着针对部分故障进行设计，记录中间状态，并期望重试为正常操作而不是异常。

模型上下文协议文档现已通过 GitHub Copilot 提供，提供了一种标准化的代理工具交互方法，区块链开发人员可以采用该方法来实现链上自动化。

图片来源：Shutterstock