云栖2026主论坛散场时我旁边两位工程师正在争论Agent编排框架该自研还是用平台。这个画面几乎是今年整场大会的一个缩影模型发布的新闻仍然不少但展台前排队的人、技术沙龙里提问的人更多在关心同一个问题——智能体到底能不能稳定、便宜、可控地跑在生产环境里。Agentic AI Infra这个词在Keynote里被反复提及官方口径很明确2026是工业智能体从概念演示走向工程化落地的分水岭而基础设施是这轮竞赛真正的起跑线。这篇文章我把在云栖2026现场看到听到的东西加上自己回来之后动手验证的经验整理成一份尽量落到实处的参考。无论你是正在做Agent产品准备搭建团队自己的智能体开发环境还是刚把Agentic AI Infra加入学习清单这篇都可以作为阶段性的落地手册来看。1. 云栖2026的信号模型不缺想象力缺的是能跑的地基1.1 工业智能体分水岭共识是怎么形成的前两年聊大模型大家比的是谁家榜单更高谁能写诗修图做视频。到2025年下半年风向很明显变了榜单分数高的模型未必产线好用会聊天和能把活干完是两种完全不同的能力。云栖2026的Keynote里反复引用一句话——2026是工业智能体从概念演示走向工程化落地的分水岭。这句话能被大家反复传播恰恰是因为过去一年有太多团队栽在同一个地方Demo里什么都会一接真实业务就暴露问题API不稳定、工具调用错乱、成本失控。模型能力已经不是瓶颈把模型组织起来稳定干活的那层基础设施才是瓶颈。这一点在模型侧也有佐证。DeepSeek公开的智能体训练新方法重点早已不是把单轮问答刷得更高而是让模型更稳定地遵循工具调用和任务拆分的指令。连头部模型团队都把优化目标转向工具调用准确率和任务完成率说明行业共识确实变了模型再聪明也只是组件基础设施才是让组件协同运转的骨架。1.2 从会场热搜看需求迁移我这次特意看了一圈云栖期间的热搜词和论坛提问很有意思。智能体、AI智能体、智能体开发、智能体搭建、智能体框架这些词长期霸榜与此同时低显存运行模型Ollama下载模型国内镜像evaluation智能体添加方法论这类偏工程侧的词也挤了进来。去年大家还在搜大模型API怎么接今年变成了智能体工作流怎么搭模型怎么在自己的机器上跑起来。这本质上是需求从模型层往基础设施层迁移。大家不再满足于调用一个AI接口而是想拥有一个能稳定复现流程、能被业务规则约束、能插进CRM/ERP系统里的执行单元。哪怕只看热词你也能发现很多人已经开始认真挑选能嵌入系统的模型实体比如jev模型到底开不开源、能不能本地部署这类问题能上热搜说明大家关心的是工程落地不只是聊天体验。1.3 Agentic AI Infra的边界不是什么万能银弹Agentic AI Infra这个概念很容易被讲泛。为了避免虚我给它划一个边界它不是某一个大模型不是某一个Agent框架也不是一句营销口号而是支撑智能体从开发、调试、部署、评估到运维的完整技术栈。它至少包括模型接入层、推理调度层、编排执行层、工具与记忆层以及评估可观测层。打个比方模型是发动机智能体是整车Agentic AI Infra是高速公路网。发动机再好没有路网车也跑不起来。过去两年我们都在比发动机排量2026年开始该修路了。这篇文章后面的内容就是围绕这条路网怎么修展开的。2. 模型、推理、编排、工具记忆四层地基各在解决什么2.1 模型层从一个模型打天下到异构模型按需组合智能体应用里的模型不存在唯一答案。主对话可以挂通用大模型意图识别也许用一个小分类模型更快更省OCR、照片修复这类图像任务得单独挂视觉模型时序数据可能要用TCN或者滑动窗口滤波模型传统结构化预测上LightGBM回归反而更稳。我见过不少成熟团队的模型层实际是多模型共存的一个总路由负责分流把不同请求交给不同规模的模型处理。这么做不是因为炫技而是算账。大模型推理成本高、延迟大如果所有流量都走旗舰模型一个销售智能体每天几万次调用成本直接失控。模型层的加速价值就是提供标准的接入层、路由规则和降级策略默认用小模型扛量复杂环节才升级到大模型。社区里那些热度很高的模型讨论比如照片修复模型、各种量化版本本质上都是在回答同一个问题这个任务到底需要多大的模型才划算。2.2 推理层低显存跑模型不是省钱是门槛低显存运行模型在热搜里高频出现背后是大多数人要面对的现实约束不是所有团队都买得起A100集群更多的场景是一块24G显卡甚至一台16G内存的电脑就得把模型跑起来。量化、KV Cache优化、投机采样、滑动窗口都是为了在有限资源里压出更多吞吐。我整理了一个常见的选型参考按显存/内存需求量来分档模型档位常见量化内存/显存需求典型用途7BQ4_K_M5-6GB意图识别、路由、入门测试14BQ4_K_M10-12GB客服、销售辅助、长上下文任务32BQ4_K_M20-24GB复杂规划、多步工具调用70BQ4_K_M40GB生产级复杂Agent建议上服务器注意这只是单卡静态加载的估算实际还要算上KV Cache和并发建议至少再留30%余量。推理层的本质是把单位Token成本打下来因为Agent循环天然烧Token推理效率直接决定你能不能量产。2.3 编排层Agent框架编排的不是API是状态机很多人以为Agent框架就是把LLM API串起来这是误解。真实情况是智能体本质上是一个循环感知、决策、执行、反思。编排层要管的是这个循环的状态——当前在第几步、下一步做什么、工具返回异常怎么处理、最大轮数是多少。Dify这类平台把循环画成了可视化画布降低了上手门槛社区里新冒出来的hermes这类智能体框架核心卖点也是让多步任务的可控性变强而不是把模型变聪明。所以选框架时不要只数它接了多少个模型API要看它对状态、重试、并行、人工介入的支持。一旦Agent在生产环境跑起来你会发现在画布上画流程是最简单的事真正难的是当流程出错时你能不能在五分钟内定位到是哪一步出了问题。编排层的成熟度决定了你的智能体是在按剧本走还是在现场即兴发挥。2.4 工具与记忆层智能体的手和记事本工具层解决的是智能体能不能干活——查数据库、发邮件、调用内部业务API、读写工单系统。记忆层解决的是这次交互和过去的关系——短期记忆是当前会话上下文长期记忆是向量库里的历史事实。像照片修复这类图像能力要接进产品通常也要封装成标准工具插件。这一层最容易被低估但生产环境里我看到的大部分故障其实是工具描述不准确、返回结果结构不匹配、记忆读写冲突造成的。Infra的加速价值在这里体现得很实在把工具注册、参数校验、结果解析做成标准动作。智能体要少一点手滑不能只靠模型聪明还得靠工具接口定义得足够严谨。3. 从0搭一套Agentic Infra开源工具链的实测选型3.1 平台派还是代码派先想清楚团队位置每次聊到落地第一个问题都是用现成平台还是自己写代码。我给一个判断逻辑团队1-3人业务方经常改流程优先用Dify这类可视化编排平台先把流程跑通。有五名以上AI工程师业务对响应延迟和稳定性非常敏感可以用代码方案自己控制调度细节。折中方案平台定流程代码写工具和插件。大多数团队走到后面都会落在这个位置。我的倾向是先别急着自研。第一版用平台把流程、Prompt、评估集都沉淀下来当平台开始限制你的时候比如并发上不去、日志不够细、定制困难再迁到代码迁移成本是可控的。空手自研最大的风险不是技术难度而是你还没搞清楚业务流程就先被技术细节拖住了。3.2 Ollama开源模型的本地推理组合本地推理我目前用得最顺的组合是Ollama加开源模型。Ollama的价值在于把进程管理、并发请求排队、模型常驻内存这些琐事都替你管好了你只需要关心模型本身。上手很简单ollama pull qwen2.5:7b-instruct-q4_K_M如果你的网络环境拉不动官方源别硬磕。更省事的做法是先用镜像源把GGUF模型文件下载下来再通过Modelfile导入# 使用镜像加速下载模型文件 export HF_ENDPOINThttps://hf-mirror.com # 下载 qwen2.5-7b-instruct 的 GGUF 文件后写一个 Modelfile FROM ./qwen2.5-7b-instruct-q4_k_m.gguf # 导入到 Ollama ollama create qwen25-7b -f Modelfile导入之后Python调用也非常简单import requests resp requests.post( http://localhost:11434/api/generate, json{ model: qwen25-7b, prompt: 判断这句话属于哪个意图客户问价格能不能便宜点, stream: False, }, ) print(resp.json()[response])这套组合最大的优势是隐私和数据安全。业务数据不出内网这对很多公司来说是硬性要求也是为什么本地推理在销售、客服、医疗等场景里特别受欢迎。当然也要认清边界本地小模型的单点能力确实不如云端旗舰API所以更合理的定位是让小模型承担大量重复、低难度的任务把少量复杂请求留给云端大模型。3.3 案例销售智能体从搭建到内测用一套实际的业务流程说明会更直观。我搭过一个销售智能体需求是销售助理要把客户线索按质量分级外呼前生成客户背景摘要通话结束后自动总结并回写CRM。流程设计分五步线索进入确定客户基本信息和来源渠道。信息补全调用客户管理系统的API拉取历史订单和互动记录。线索分级用小模型判断线索质量是高、中、低。生成外呼大纲用7B模型基于客户画像生成开场白和沟通重点。人工确认后外呼通话结束自动总结回写CRM。在Dify这类平台里这个流程就是一条可视化的流水线开始节点、工具节点、LLM节点、条件分支、结束节点。工具节点连接HTTP请求LLM节点写清楚System Prompt和输出JSON格式条件分支根据分级结果走不同处理路径。几个我当时踩过、也更容易被忽略的细节工具调用的返回一定要配解析脚本外部API要设超时和重试分级结果要落到结构化字段里不要让模型自由发挥。比如客户等级这个字段必须在Prompt里限定只能返回high、medium、low三个值否则模型会给你返回很高还行这种没法入库的文本。内测阶段我找了最近一个月100条真实线索跑了一遍再人工抽了20条对比分级准确率。同时建了一个评估集合包括每条线索期望的分级结果、期望的输出JSON结构以后每次改Prompt都自动跑一遍。提示搭智能体的第一步往往不是调大模型而是把工具接口和数据结构定义清楚。模型很聪明但工具接口定义得不稳定它再聪明也白搭。4. 真正的分水岭不在演示在评估、可观测和成本4.1 Evaluation没有考官的智能体上线等于开盲盒云栖期间evaluation智能体添加方法论能成为热搜词说明大家都在找评估的答案。Evaluation不是上线前跑几个测试用例而是要建一套可持续的回归体系。最简闭环是四步建回归集围绕核心场景至少50条用例起步要包含正常输入、模糊输入和极端输入。别只写我们想象中的理想case。指标拆细工具调用准确率、任务完成率、格式合法率、平均轮数分开统计而不是只看一个总分。自动化评估用LLM-as-judge给每条用例打分低于阈值就报警。Bad case回流每一条线上的坏case都加进回归集形成数据飞轮。DeepSeek公开的智能体训练方法论其实也验证了这条路把工具调用准确率和任务完成率拆成单独的评测指标针对性训练效果比笼统的单一总分好得多。模型团队都这么干了应用团队更没理由凭感觉上线。4.2 可观测性你不该只知道它答错了智能体出问题最痛苦的一点是你只知道它答错了不知道它是在哪一步错的。是意图识别错了工具返回超时Prompt没约束住还是总结模型把关键信息丢了没有可观测性这些问题全是黑盒。我自己的做法是在编排层加事件钩子把每次模型调用、每个工具返回、每个条件分支命中的结果都写成结构化JSON日志。字段至少包含任务ID、步骤ID、模型名称、输入摘要、输出摘要、Token数、耗时、错误信息。字段结构一定要稳定不然事后分析依然是一场灾难。有了这套日志你才能回答最关键的三个问题智能体到底想了什么、做了什么、卡在了哪里。没有这三件事任何关于优化的讨论都是空谈。4.3 成本与延迟Agent放大效应下的隐形天花板成本这件事太容易被低估了。一个规划-调工具-总结的Agent循环Token消耗可能是单次对话的10倍以上。我见过一个团队上线销售智能体每天处理1000条线索每条跑5轮循环每轮几千Token月底账单出来全傻了。我整理了一个简易的估算思路场景平均轮数单轮Token每日请求数月Token量估单轮问答1120010003600万简单Agent4200010002.4亿复杂Agent835005004.2亿这只是一个估算思路具体数值要看模型和Prompt设计但Agent放大效应是客观存在的。成本优化的方向也很明确用小模型做路由和前置任务大模型只处理真正复杂的环节相同Query和上下文直接走缓存设置最大轮数和总Token预算防止死循环烧钱流式输出缓解等待感批量任务放到低峰期执行。配合推理层的量化优化通常能省30%到50%的成本。5. 几个绕不开的坑以及给2026年的落地建议5.1 三个真实踩过的坑第一个坑是Agent死循环。工具返回了错误码Agent没有正确解析陷入了失败-重试-失败的循环足足跑了12次才触发轮数上限一次对话烧掉了几万Token。修复方式很朴素工具节点加异常分支失败就直接返回给用户或转人工而不是让模型自行决策无限重试。智能体需要被约束这种约束不是限制智能而是保护系统。第二个坑是幻觉数据写进业务系统。我曾经让销售智能体自动回写CRM结果它把客户行业、联系人职务都脑补出来写进了正式字段。后来在工具调用层加了输出schema强校验非预期字段直接拒绝写入。模型可以自由回答开放式问题但不能自由修改业务数据这是一条必须守住的底线。第三个坑是测试集和线上数据脱节。第一版评估集全部来自我们自己写的用例改了几轮之后测试通过率到了95%上线一周效果却很差。原因很直接真实客户的问题分布和我们写的理想用例完全不同。后来把线上bad case全部捞回评估集反复校准效果才慢慢起来。5.2 给不同阶段团队的落地顺序按团队成熟度给三档建议第一档还在概念验证阶段的团队不要纠结自研平台用一个可视化平台加一个主流API模型先跑通业务闭环。这个阶段的目的不是炫技是验证流程值不值得自动化。第二档已经上线了单点智能体的团队优先补评估集和日志链路。没有考官的智能体接口做得再漂亮也上不了量。第三档想做多Agent协同的团队先别急着造多Agent宇宙把单个Agent的可靠性和成本做到可控再说。多个不稳定的Agent编排在一起失败率是按指数级扩大的。这个账算清楚再做决定不迟。云栖2026给我的最大感受不是又冒出了什么黑科技而是整个行业终于开始承认把智能体工程化地跑起来是一件需要长期投入的苦活。模型层、推理层、编排层、工具记忆层每一项单拎出来都不算新概念但要让它们结合成一套可控、可评估、可预算的基础设施确实需要认真打磨。如果你正准备动手我的建议很简单先别追新框架拿一套成熟的工具链或者代码骨架把第一个完整流程跑通从一开始就把评估、日志和成本预算放进去。这些东西一开始不做后面再补成本会翻倍。2026年拼的已经不是谁模型大而是谁的基础设施更能扛事。
