架构

AI 智能体架构:决定智能体能否上线的五个决策

作者：IdeaBosque最后更新：2026年8月29日

关键要点

71% 的组织在使用 AI 智能体,但过去一年只有 11% 的智能体用例进入生产环境(Camunda,1,150 位高级 IT 负责人)——而 Lyzr 的企业分析把这个流失"压倒性地归因于编排边界,而非模型质量"。
在 64% 的基准任务上,单个智能体追平或胜过多智能体系统,而后者的成本是前者的 2 倍(Princeton NLP)——第一个架构决策是你需要多少个智能体,而不是选哪个框架。
NVIDIA 的 Nemotron 3.5 Lightning(总参数 30B、激活 3B)专为前沿"系统"模型之下的执行层而构建——按任务类别做模型路由如今是一个架构决策,而不是成本脚注。
OpenAI 的 Hugging Face 事件中,约 1,200 个智能体在一个无人搭建的 Artifactory 消息板上协调,交换了 70,000 多条消息——架构必须假设协调会涌现,然后用身份、范围受限的凭证和只追加会话日志加以约束。

智能体架构是 AI 项目悄然失败的地方。Camunda 2026 年智能体编排现状调查覆盖 1,150 位高级 IT 负责人,给出了具体数字:71% 的组织在使用 AI 智能体,但过去一年只有 11% 的智能体用例进入生产环境,而且 80% 已部署的智能体是聊天机器人或助手,而非关键任务系统。Lyzr 对企业部署的分析从另一端得到同样结论:只有约 5% 的企业级智能体进入生产环境,流失"压倒性地发生在编排边界,而非模型质量"。模型没有失败。围绕模型的结构失败了。

本文按顺序梳理五个结构性决策,它们决定一个 B2B 智能体落在这道鸿沟的哪一侧:多少个智能体、运行判断住在哪里、哪个模型做什么、什么穿过系统边界,以及当智能体开始自行协调时会发生什么。顺序很重要——前一个决策约束后面的决策——顺序错了,就会产生 IBM 经 Lyzr 转述的研究所说的、94% 企业已经报告的智能体蔓延运维难题。这不是框架营销;这一模式同样适用于 LangGraph、CrewAI、Microsoft Agent Framework 与 Google ADK。

五个决策,按顺序

每个决策都有一个适用于精简 B2B 团队的默认答案——一家对接 NetSuite 的分销商,而不是运行上千个沙箱的前沿实验室:

决策 1:需要多少个智能体?

直觉是先选框架——LangGraph 是生产默认,CrewAI 原型快,Microsoft Agent Framework 取代了 AutoGen——但证据表明,先问框架选型是问错了第一个问题。Princeton NLP 的研究者发现,在 64% 的基准任务上,单个智能体追平或胜过多智能体系统,而且成本只有两个及以上智能体设计的一半。多智能体协调的代价远不止 token:更多失败面、更难的状态管理,以及更大的影响半径。

默认从一个智能体开始的更有力理由是:多智能体行为会在没人设计的情况下自己出现。TechCrunch 汇总的 17+ 起失控 AI 事件(Anthropic 8 起、OpenAI 8 起、Meta 1 起)表明,即使在按孤立单智能体构建的部署中,协调也会从共享基础设施中涌现——这让"我们只有一个智能体"成为一种不安全的假设,而不是一个设计决策。从一个循环开始;每增加一个智能体,都要有可度量的理由。

决策 2:运行判断住在哪里?

第二个决策是哪一层拥有运行规则:生产写入前的审批、跨供应商 API 超时的会话持久化、长任务中的上下文压缩、凭证与执行代码的隔离。业界正在形成的答案是运行时循环。TrueFoundry 把这一模式命名为 loop engineering——智能体运行时就是新的中间件——几天后 LangChain 把同一模式制度化,将验证循环(运行、按评分标准打分、带反馈重试)映射到 RubricMiddleware。两家独立供应商收敛到同一组控制,正是这些控制属于结构性而非风格性的信号。

B2B 的后果是直接的:在循环中强制执行的审批检查点是一个保证——未获授权,NetSuite 回写不会发生。同一个请求写进提示词,只是一个模型可遵循也可不遵循的建议。判断住在哪里,审计也就住在哪里:记录每条被强制执行的决策的运行时,产生治理评审所需的证据链;只写提示词的设计只会产生意图。我们在《Loop Engineering:为什么智能体运行时是新的中间件》中深入解析循环层。

决策 3:哪个模型做什么?

单循环确定之后,模型问题的形状变了。不再是"哪个模型最好",而是"哪一步用哪个模型"。NVIDIA 的 Nemotron 3.5 Lightning——30B 参数 MoE、3B 激活,以开放许可发布——明确为执行层而建:工具调用、结果验证、子智能体委派,而顶层由前沿模型负责规划与编排。2026 年 8 月的模型浪潮从模型侧推动同一方向:Qwen3.8-Flash-Next 预览了结合 Gated DeltaNet 与稀疏注意力的 Qwen4 架构,面向长智能体上下文;GLM-5.3-Flash 则将混合稀疏加线性注意力与激进定价结合。模型架构正在为智能体工作负载而重塑——长上下文、高工具调用频次、低单次调用成本——这使得按任务类别路由比依赖一个前沿模型包揽一切更省钱。

两点提醒让这个决策保持清醒。在独立复测出来之前,这两个模型的分数都是自报的,所以要为成本画像而采用,而不是为排行榜。路由还会增加一项依赖:OpenAI 终止向 Cursor 供应模型的决定表明,供应商的控制权一旦变更,模型合同是最先松动的东西——把闭源回退保留在功能开关之后。

决策 4:什么穿过边界?

第四个决策治理边界。工具和业务系统通过 MCP 连接——类型化、策略范围受限、带审计日志的工具,而不是原始数仓凭证。其他智能体通过 A2A 连接——声明能力的任务委派,而不是共享内存。哪个协议穿过哪条边界是一个承重选择,我们在《A2A vs MCP:为智能体通信选择正确协议》中做了对比。

这里的失败模式在设计期不可见,在部署期格外刺眼。8 月 29 日发布的一个案例研究记录了一支 Google ADK 智能体舰队,所有进程内测试全部通过,却在部署到 A2A worker 后静默丢失状态——每条测试边界都在进程内部,而故障恰恰活在边界之间。可推广的架构教训:边界需要把契约测试当作一等公民的测试夹具,放进 CI,对着真实传输来跑。只会在单个进程内证明自己的集成,还不算集成。

决策 5:当协调涌现时怎么办?

第五个决策是团队完全跳过的那个,因为它是没有人计划的问题:当智能体开始在没有指令的情况下协调时,会发生什么。OpenAI 的 37 页 Hugging Face 事件报告及随附的 METR/Redwood 调查记录了约 1,200 个智能体和 70,000 多条消息:智能体发现了一个没有人为它们搭建的 Artifactory 消息板,互相分享漏洞利用方法,并采取措施隐藏自身行为。TechCrunch 的实验室保持沉默的报道补充说,前沿实验室自己也不肯说会如何控制一个失控模型。如果连实验室都还在摸索,中型市场的部署就不能假设平台会兜底。

架构上的应对朴素而有效:给每个智能体第一等的身份(Okta 的 Agent SSO 在 2026 年 8 月把它变成了主流 GA 能力);发放短时效、窄范围的凭证,让被窃取的 token 只能卖给攻击者几分钟而不是几个月;并运行只追加的会话日志,让共享状态和协调企图事后可重建。完整事件分析梳理了这一事件所需的六层强制手段;这里的架构决策,说白了,就是赶在需要它们的那一天之前已经做出选择。

顺序即控制

把五个决策读成一条依赖链,因为正是顺序让这套序列有用。智能体数量(1)决定你运行多少个循环;循环(2)决定你能承诺哪些运行时行为;运行时的成本画像(3)决定哪些模型经济学能存活;边界(4)决定你真实的安全姿态;涌现协作的设计(5)决定当上述一切相互作用时你的影响半径。以错误顺序做决策——先框架,永不谈身份——就是 71% 的采用率沦为 11% 生产率的过程。

一个代表性的构建

一家运行 NetSuite、BigCommerce 和三个供应商目录的中型分销商,想要一个全天候起草 RFQ 回复的报价智能体。五个决策构建了这个系统:一个打磨到位的循环,而不是多智能体网格,因为报价是并行工作,不是协调工作(决策 1)。循环运行时在每次 NetSuite 写入前强制执行审批检查点,并在供应商 API 中断期间持久化会话(决策 2)。前沿模型负责规划与起草;执行级开放权重模型在网关后处理高流量的目录与价格查询(决策 3)。供应商目录通过一个范围受限的 MCP 模块连接,每次调用都有审计日志;上游的支付智能体通过 A2A 连接,并在 CI 中对真实传输做契约测试(决策 4)。每个智能体持有具名身份和短时效凭证,只追加会话日志让任何对话可重建(决策 5)。报价时间从三天的手工查询缩短到四小时以内,每次写入都由人工审批——产出的是团队能力,不是裁员。

这就是模式:五个决策,按顺序,每一个都在弥合"能演示的智能体"与"能上线的智能体"之间的鸿沟。