AI最难的部分不是模型本身——而是搭建那些不起眼的”管道工程”，防止你的智能体丢失上下文、把事情搞砸。

2024年的大部分时间里，我都坚信自己清楚最难的部分在哪里。

当时我在独自开发Flow Orchestra，一个AI驱动的内容工作流平台，所有东西都是我一个人做的：检索组件、生成智能体、调度层、自主内容流水线。在我看来，工程挑战非常明确——让大语言模型按我的需要行事。提示词架构、模型选型，复杂性就在这里，或者说我当时是这么认为的。

我完全错了。

模型运行得很好，事实上，它们反而是最简单的部分，真正差点把我逼疯的是编排层。让系统中的每一个智能体都能正确接收、理解并把上下文传递给链路上的下一个，这件事消耗了我几周的计划外时间，迫使我重新思考核心架构，也让我对多智能体AI系统究竟是怎么失败的，有了比过去三十年技术生涯中任何事都更深的理解。

智能体之间的上下文传递——这才是问题所在，听起来像是个管道细节，其实不是，这正是一个系统能否在规模化环境中真正运行，与只能产出漂亮的演示但一上线就崩盘之间的区别。

我分享这些，是因为当前大多数在构建AI系统的企业，正在犯完全相同的错误，只不过他们有更大的团队、投入了更多的资金。

错误的问题仍然占上风

走进任何一场企业AI规划会议，话题的中心都是模型。选哪个大语言模型?私有还是开源?微调还是基座?这些都是合理的问题，但它们并不能决定你的AI系统能否在生产规模上跨越整个业务职能正常运转。

德勤的《2026年企业AI现状报告》基于对24个国家3235名高管的调查发现，只有20%的企业从AI投资中看到了实际营收影响，而74%的企业表示营收增长仍然只是一个愿望。一项被广泛引用的企业部署分析显示，从试点到生产的成功率仅为12%。那些失败项目中的模型本身并不是问题——它们往往非常优秀，问题出在模型周围的一切：协调基础设施、工作流设计、智能体之间的连接架构。

模型不是你的竞争优势，编排层才是，大多数企业仍然在优化错误的东西。

你没法编排一个本身就有缺陷的工作流

这是我反复见过的一个模式，一个企业有一套运转低效的工作流：审批缓慢、文档在系统间丢失、团队之间的交接产生重复和错误，然后他们决定在上面叠加AI。

他们搭建了一个检索智能体，加了一个生成组件，接入自动化，演示效果和PPT里承诺的一模一样。

然后他们推向生产，结果以全新的、更快的、更昂贵的方式失败了。

发生了什么?AI忠实地自动化了一个本身就有缺陷的流程，它现在以机器速度做着人类以人类速度都做不好的事情，阶段之间传递的上下文到达时已经不完整，任务被路由到了错误的地方。以前需要一周才能累积的错误，现在几分钟就能累积起来。

AI没有制造这些问题，它只是放大了已经存在的问题，你没法把协调基础设施硬拧到一个本身就不合理的流程上，工作流必须先被重新设计，这个顺序不可商量，但大多数企业都跳过了它。

当我重建Flow Orchestra的编排层时，我明确了真正不可商量的三件事。

第一，智能体之间必须有明确定义的上下文契约。系统中的每一个智能体都必须确切知道它从前一步接收到什么、被期望产出什么、以及信息在流水线中以什么格式流转，这不是提示词工程的决定，而是架构决定，而且必须在其他任何东西之前确定。没有它，你就是在赌每个智能体能正确理解上一个智能体的意思。小规模时，这种侥幸有时能撑住，生产规模时，撑不住。

第二，路由层不能只是另一个大语言模型。大多数团队会构建一个编排智能体来协调其他智能体，而这个编排器本身就是一个大语言模型，带着所有随之而来的概率波动性来做路由决策。对于业务关键型工作流，这是一个隐患。路由逻辑在需要确定性的地方必须是确定性的：规则、分类器、工作流引擎。模型处理语言，路由层处理逻辑。这不应该是同一个组件。我见过生产系统在规模化时失败，正是因为编排器在理解语言上很出色，但在高负载下做可靠路由时却不一致。

第三，必须有一个能在智能体切换中存活的记忆层。在流水线中跨越三个智能体的上下文，必须在每一跳中完整通过，这意味着状态必须存储在智能体外部：会话存储、结构化数据库，链路上的每一个智能体都能一致地读写。如果你的智能体只能访问其即时上下文窗口中的内容，你的系统就会在最糟糕的时刻遗忘，而且它不会告诉你它忘了，它会输出微妙错误的结果，直到下游某个地方明显出了问题。

这些都不是什么光鲜的组件，没人会在技术大会上做关于上下文契约的演讲，但正是这些东西，让能跑起来的系统和跑不起来的系统之间有了区别。

从画出上下文流向开始

在你的团队再建一个智能体或再评估一个模型之前：先画出你的上下文流向。

不是任务流，不是功能列表，而是上下文流。

画出系统中的每一个智能体，画出进入每一个智能体的信息，画出它产出什么、向前传递什么，画出在每次转换时共享理解发生了什么，画出当某一步失败时会发生什么，这张图不需要好看，需要诚实。一个智能体在哪里把任务交给下一个?如果这次交接失败会怎样?然后呢?系统会恢复还是只是安静地输出垃圾?这三个问题能告诉你的架构信息，比任何技术评审都多。如果你能在纸上回答它们，你就可以开始构建。如果不能，你还没准备好。如果你已经构建了但仍然答不上来，你就找到了你的问题。

我和每一位对AI部署感到沮丧的CIO交谈时，他们都有同样的表面症状：智能体单独运行时没问题，组合在一起就失败。修复方案从来不是换一个更好的模型，永远是同一个：回到上下文流向，把它当作它实际上就是的基础设施来设计。

两年后，没人会记得他们在2025年选了哪个模型，他们只会记得自己的系统到底能不能用。

去建那个空中交通管制系统吧，先从画出上下文流向开始。

文章来自：51CTO