走出单一大模型：真正能投产的架构

整整两年，行业衡量进步只看一个数字：谁的模型更大。如今，头部模型在多数基准测试上只差几分，真正把 AI 放进生产的团队，关心的早已是另一个问题。他们不再追问哪个模型最强，而是琢磨怎样让几个模型协同运转，又怎样证明这套系统值得投入。

这一转变有了名字：AI 编排。它把各有专长的模型和工具组织成一个系统，由专门的一层来决定何时运行什么。论光鲜，它不及前沿模型的发布会；论与价值和风险的距离，它却近得多。

这件事关乎动手搭建的人，也关乎最后拍板签字的人。编排不会凭空让系统变聪明。它增加的是活动部件，而每个活动部件，都是一个有人替您做主的环节。AI 项目为何失败，研究结论相当直白，矛头并不指向模型。

据部分估算，超过 80% 的 AI 项目以失败告终，大约是不涉及 AI 的 IT 项目失败率的两倍。

来源：兰德公司（RAND Corporation），《人工智能项目失败的根本原因》，2024 年 8 月

兰德访谈了 65 位从业至少 5 年的数据科学家和工程师。结论是：技术大体管用，出问题的是围绕技术的组织。生成式 AI 浪潮并没有让这幅图景好看多少。

约 95% 的企业表示，生成式 AI 试点没有给损益表带来任何可衡量的回报。

来源：麻省理工学院 NANDA 项目，《生成式 AI 鸿沟：企业 AI 现状》，2025 年

编排是让系统跨过演示阶段的架构；可一旦草率上马，它也会把五个新决策点埋进一张无人过问的架构图里。本文要谈的，就是如何做到前者，同时避开后者。文中数据均在引用处注明日期，每季度复核。

三层架构，一层管一个决定

凡是走进生产的编排系统，都可以归入同样的三层。名称暂且放一边，要紧的是每一层抛给您的那个问题。

模型会推理，却不能自己动手；工具让它动起来；编排层则决定哪个模型处理哪项任务、何时调用工具、出了故障如何收场。系统真正的智能就在这最后一层，而团队在这一层投入得往往最少。

一个模型身兼数职，难免顾此失彼

单一模型的好处一目了然：一次集成，一张发票，只需操心一样东西。现实却没这么省事。

拿客服运营来说。它要读出消息里的情绪，调出准确的信息，起草回复，并在发出前把关。前沿模型四件事都能上手，但这是四份不同的工作，各有各的失败方式：为写好回复而调校的模型，与为准确分类而调校的模型，取舍并不一样。所以，能在生产中站稳的系统，大多把工作分给多个模型，而不是孤注一掷押在一个模型上。

第二个理由，最先触动的是财务总监：每项任务都动用最强的模型，开销不菲，而多数任务根本用不着。这里的差距绝非零头。

如今，最便宜的生产级模型与前沿旗舰模型之间，每 token 价差已超过 100 倍，在部分实际任务上还要更大。

来源：作者分析，依据各主要模型厂商公布的 API 价目表，2026 年年中

简单的活交给便宜模型，难题才请出昂贵模型，这早已不只是优化，而是一道分水岭：一边的系统能自负盈亏，另一边在后台悄悄失血。团队之所以要做编排，很大程度上正是为此。

一年之内，放弃大部分 AI 项目的企业占比从 17% 跃升至 42%。

来源：标普全球市场财智（S&P Global Market Intelligence），《Voice of the Enterprise》，2025 年 10 月

顺带说说模型名称，这本身就是一块好用的试金石。截至发稿，前沿阵营是个紧凑的小圈子：Claude Opus、GPT-5、Gemini、Grok，身后还跟着一批价格更低、实力不俗的选手。这个排名差不多每月洗一次牌，凡是替您钦定唯一赢家的文章，都在不声不响地给自己贴上过期标签。经得起时间的，不是今天谁领先，而是系统要做到随时能换掉一个模型，因为您迟早要换。绑死单一供应商的系统，是一个日后还得推翻的决定。

给模型的行动立规矩

语言模型负责思考，工具负责动手。这一层囊括模型伸向外部世界的一切手段：网页搜索、数据库查询、API 调用、代码沙箱、文件系统。助手搜索网页或运行代码，靠的就是这一层。

过去两年的大部分时间里，把模型接上工具都是定制活，每个模型、每个工具都得从头来一遍。这笔账很快就算不下去：10 个模型乘以 100 个工具，就是 1000 个要搭建、要维护的集成。直到一项标准改写了局面。

• 此前：10 × 100 = 1,000 个集成，每个模型都要手工接上每个工具。
• 此后：MCP = 1 项标准，任何模型都经由同一个接口调用任何工具。

2024 年 11 月 25 日，Anthropic 推出模型上下文协议（Model Context Protocol，MCP），作为连接 AI 系统与外部工具和数据源的开放标准。

来源：Anthropic，MCP 发布公告，2024 年 11 月

MCP 本身不是编排模式，而是铺在各种模式底下的管道：任何模型都能用同一种方式调用任何工具，换掉哪一端都无须重建接口。

普及的速度说明了这一需求有多真切。OpenAI 和 Google 都在 2025 年宣布支持。同年 12 月，Anthropic 把协议移交给 Linux 基金会旗下的 Agentic AI Foundation，让它落在中立地带，不归任何一家厂商掌控，正如 HTTP 不属于任何人。对高管而言，要点只有一个，而且很实际。连接层正在变成通用品，这是好事：花在集成粘合上的预算会变少，更多资金可以投向真正让您与众不同的工作。

三种模式，各有用武之地

工具来了又走，底层模式却已稳定到足以据此做规划。值得了解的有三种，选哪一种看的是是否对症，而不是论高下。

多数生产系统三者兼而有之：整体是多智能体结构，单个智能体在内部做检索，彼此之间按顺序沟通。这里有意不点任何框架的名字。这一领域的工具不断洗牌：今年领跑新项目的图式框架，十八个月前还排不上号；今天开出的任何候选名单，等您真正动手时都已过时。不管最后入选的是哪个，先拿一个真实流程跑一遍，再交给一个没参与搭建的人，看看会怎样。

胜负手在路由器

弄懂这些模式是一回事。可一旦追问编排系统凭什么胜过单一模型，就会发现挑大梁的其实是一个组件。如果见供应商之前只能读本文一节，就读这一节。

姑且叫它路由器。它读取每个进来的请求，决定请求在系统里走哪条路。答案再完美，走错了路也无济于事。所以，决定整个系统值不值得建的，往往是这个组件，而不是它背后的模型。路由准确率是一道分水岭：一边的系统配得上它的复杂度，另一边只是用更慢、更贵的办法，拿到单一模型本来就能给的结果。

每个专用模型只碰得到自己擅长的问题，其余的都被路由器挡在门外。

以一款帮开发者调试的编程助手为例。单模型版本把代码和报错一股脑丢给一个模型，然后碰运气。编排版本先判断问题属于哪一类：语法错误交给轻量分析器；运行时错误触发一个检查程序状态的工具，再把结果交给推理模型；逻辑错误另走一条路，先搜索既往解法、检索上下文，再加以综合。每个专用模型只碰得到自己擅长的问题，其余的都被路由器挡在门外。

路由器靠什么决策？主流有三种做法。语义匹配把请求与各条路径的示例逐一比对，挑出最接近的一条，类别泾渭分明时速度很快。关键词匹配找的是明确信号，做法简单，只要信号可靠，效果稳得出人意料。用一个小而快的模型来当路由器，比关键词灵活，比单纯语义匹配可靠，代价只是多一点延迟。生产系统通常层层叠加：先用最快的办法，置信度不够就退到下一种，同时始终为真正说不清的请求留一条默认路径。

下面这段值得带进预算会。各团队为生成环节选哪个模型绞尽脑汁，却悄悄冷落了路由器。这是本末倒置。一个过得去的答案只要路由正确，每次都胜过路由错误的精彩答案。在我们自己的项目里，路由准确率是判断编排系统能否回本的指标；我们要注明，这是经验判断，而非测量得出的定律：下游模型好不好，远不如路由器能否把每个请求送到对的模型那里要紧。判断准确的简单路由器，胜过常常出错的聪明路由器。如果您认同这一点，具体的第一步就在下文，而且比您能买到的任何工具都便宜。

协调不等于管控

这中间有一个缺口，没有哪个框架会替您补上，而董事会偏偏会问到它。

今年每一份像样的编排框架对比，都得出同一个令人不安的结论：框架协调的是智能体做什么，却没有一个在原生层面管控高风险操作该不该发生。模型决定发一封邮件、改一条记录或触发一笔付款，它们照转不误。这项操作是否获准、能否撤回、事后能否核查，编排层都不会替您决定。您不决定，就没人决定。

具体说来，这个决策层包括三样东西，框架统统留给了您。

• 权限边界：智能体哪些操作可以自行执行，哪些必须先经人批准。
• 审计记录：每个智能体做了什么决定、为什么这样决定，都有记录。
• 人工检查点：凡涉及资金或客户的操作，系统执行之前须有人签批。

这些都不算新奇，却全部落在您这一边。多数团队要等出了事、覆水难收，才发现自己漏掉了这一步。

智能体越多，这件事越要紧。一个自动化放在哪儿都行，人工盯着就够。可一旦几十个同时运行、各自决策，您就需要一个地方把它们全部摆出来：跑了什么、哪里出错、每个智能体做了什么决定、理由何在。这一需求往往说来就来，到时再给一整批定制智能体逐个补上，本身就是一个项目。

说得再直白些：编排系统把决策分散到许多组件，决策一分散，就容易无从追查。动静大的故障，流程停摆、大声报错的那种，周二之前就能修好。真正可怕的是悄无声息的那种：某个智能体慢慢跑偏，做出错误判断，而任何地方都没有发出一点警示。日志、边界，以及对涉及资金或客户的操作设置人工检查点，都不是上线后再补的功能。正是它们把自动化系统和一笔负债区分开来，可工期一拖，最先被砍的偏偏也是它们。

何时该编排，何时不该

并不是每个应用都需要这些。回答常见问题的机器人，一个模型就够；给工单分类的分类器，一个模型就够；撰写商品描述的工具，同样一个模型就够。给它们套上编排层，除了复杂度，什么也得不到。

只有在下列任一情形成立时，编排才物有所值。

判断规则并不复杂：先用一个模型，碰到明确的瓶颈之前一直用下去。只有当复杂度能换来更好的结果、更低的账单，或者原本够不着的能力，才引入编排。说不出道理的复杂度不是架构，而是您无意中签下的一张维护账单。

如果您已经越过这条线，答案也是肯定的，第一步仍然不是挑框架，而是写出路由图：列出系统会收到哪几类请求、每类请求该走哪条路径、每条路径最便宜能用哪个模型。这张图半天就能画完，除了花心思不花一分钱，而它能告诉您的项目虚实，比任何工具评估都多。画不出来？那说明这套系统还不到动手的时候，您也刚刚省下了一笔许可费。

开工之前，先定叫停条件

以上种种，都以这套系统应当存在为前提。有时它并不该存在，而眼下是唯一能坦然说出这句话的时候：会议室里人人还很乐观，谁都还没有需要维护的立场。

编排会增加决策点，而每个决策点都对应一个可以提前回答的问题。选定模式之前，先写下什么样的结果意味着叫停。不是“如果行不通”这种话，而是一个数字，再加一个日期。按照我们的方法，通常是这三项：

• 质量底线：系统须在约定的周次前达标
• 成本上限：按每次运行计算，以业务量真正起来之后为准
• 交接测试：到约定日期，构建团队以外的任何人都能打开系统并看懂来龙去脉

第三项最常被跳过，却最有预判力。如果能读懂路由逻辑的只有写它的那个人，暴露的并不是工程投入不足，而是一年后由谁接管这套系统的问题；这个问题，再多工程投入也解决不了。

这正是 AZIMUTH 方法中的定方位（Bearing）阶段，详见“方法”页面。客户对这一阶段的争议比其他任何阶段都多，直到某个季度，它抢在项目自己垮掉之前把项目叫停。主动叫停一次押注，代价远低于任由整个计划漫无方向地拖下去，直到某位高层失去耐心、全盘取消；而目睹您果断拍板的董事会，下一次批您的申请也会更痛快。

要出现什么情况，我们才会叫停？写不出这句话的团队，无论选了什么工具，都还没准备好开工。

所以，架构问题要认真回答，因为它确实重要。只是请先把另一个问题的答案写下来，趁大家都还相信项目会成功。

最近审阅：2026 年 7 月。本栏目页面每季度重读一遍，所有更正都有记录，从不悄悄改动。如果这里的某个数字已经过时，那就是我们的差错，欢迎发邮件至 hello@bearingbridge.com 告知。