云栖2026把主论坛的主题定在Agentic AI Infra上老实说我一点都不意外。过去两年大家聊模型、卷参数真正做过智能体项目的人多半会遇到同一个怪圈新出的模型看起来什么都会可真把它放进一个业务场景里让它持续干活翻车的往往是那些看起来最不起眼的地方——上下文管理、工具调用失败、记忆混乱、评测标准缺失。这次会议把“Infra”提出来等于公开承认了一个事实智能体创新不是再换一个更大的模型而是要把模型调度、工具调用、人机协作、评测反馈这些工程问题真正做成像样的底座。这个标题里有两个关键词值得细看一个是“模型”一个是“智能体”。过去这两件事经常被混为一谈好像模型大了智能体就自然强了。但做过项目的都清楚两者之间的鸿沟恰恰是最消耗精力的地方。我在这次云栖上最关注的不是又发布了哪个新模型而是那些关于智能体框架、部署工具、评价体系、生产级工作流的内容。这篇文章就围绕Agentic AI Infra这个主题把我看到的、用过的、踩过坑的东西串起来讲一遍既聊聊会议背后的思路也给准备动手搭智能体的朋友一些能直接用的经验。1. 为什么Agentic AI Infra会成为2026云栖的绝对主角1.1 模型能力过剩真正的瓶颈是工程底座先说说我对“Agentic AI Infra”这个提法的理解。它不是一个新名词包装而是把智能体开发里那些过去被当成“边角料”的事情正式提升到了基础设施的高度。什么是基础设施就是你不用每次从零开始造、出了问题可以追溯、换一个模型或换一个场景时能稳定复用的一整套东西。我做过的第一个智能体项目就是这样模型调通只花了两天后面整整一个月都在跟基础设施搏斗。你让模型写一段文案它能写得不错可你要它主动记住用户的偏好、在调用第三方接口失败时自动重试、在多轮对话里不丢失关键约束问题就全出来了。后来我才意识到智能体的上限往往不是模型决定的而是你给它的那套运行环境决定的。这次会议把焦点放在基础设施上其实是行业走到一个阶段的必然结果。模型的推理成本在降开源生态在成熟企业手里也攒了一两年的试用数据再不把调度、编排、评测这些工程问题系统化智能体永远只是一堆demo。换个说法当大家都用差不多的基座模型时谁能把工程底座做得更扎实谁才能真正把模型能力转化为业务价值。1.2 从单模型到多智能体Infra到底修在哪一层过去做AI应用多数是“单模型单任务”一个模型接收输入输出结果完事。智能体不一样它可能要在多轮对话中理解意图、调用多个工具、读取外部知识库、最后还要总结输出。这里面的每一步都可以出错而且错误会像滚雪球一样越滚越大。我常跟团队打一个比方模型像发动机智能体像整车。发动机性能再强没有底盘、转向、制动系统这辆车也上不了路。Agentic AI Infra就是那个底盘它得管住几件事模型怎么被调用、任务怎么被编排、记忆怎么存取、工具怎么连接、运行过程怎么被观测和评价。这次会上确实有人把Agentic AI Infra拆成了三个层面模型层、智能体框架层、工程观测层。我的实际经验也支持这个划分。模型层解决的是“用什么模型、以什么成本跑”框架层解决的是“智能体怎么思考、怎么行动、怎么记住”工程层解决的是“效果好不好、线上出问题能不能及时发现”。三层缺一不可只盯着任何一层都会翻车。1.3 “平台能解决80%剩下的20%才是分水岭”经常有人问我Dify这类智能体平台够不够用。我的回答是它们解决了80%的搭建效率问题但剩下的20%恰恰是决定项目生死的地方。比如工具的鉴权、任务队列、多智能体的状态同步、审计日志这些事平台给你抽象掉了可真到生产环境你还是得自己补。更关键的是平台抽象会掩盖一些细节。比如某个节点失败后智能体到底是重试、降级还是直接结束不同平台的默认策略不一样如果不理解底层的状态流转逻辑很容易出现“演示时一切正常、上线后频繁卡死”的现象。云栖讲Infra而不只讲框架本质上就是想把这个“剩下20%”当成一个正经工程来做而不是让开发者在每个项目里都吃一遍同样的亏。2. 从“模型”到“智能体”三层基础设施的拆解与实践2.1 模型层部署、推理与成本平衡模型层的核心不是“选最强模型”而是“用对模型”。现在API调用已经很成熟但许多团队出于成本、延迟和数据隐私的考虑都会选择本地部署一部分模型。这里最容易踩的坑就是低估显存需求。拿我常用的7B模型来说FP16精度大概要占用14GB显存量化到Q4之后能压到5GB左右推理效果在多数业务场景下并没有肉眼可见的下降。低显存运行模型是很多小团队的刚需我的建议是先量化再谈其它。Ollama在这块做得挺省心一条命令就能拉起模型服务不用手工配置Python环境、依赖库和推理框架。我平时做验证的流程是本地起一个量化模型先用几十条真实业务数据测试效果效果达标了再考虑接入正式系统这个流程能避免很多“部署了半天结果模型不合适”的返工。还要提醒一句Embedding模型别跟对话模型混为一谈。语义检索的质量直接决定了智能体能不能找到正确的记忆和知识。对话模型擅长生成不代表它做Embedding就好用。我见过一个团队用对话模型来算向量检索准确率惨不忍睹后来换成专门优化的Embedding模型效果立竿见影。术业有专攻基础设施的第一层就包含了这种“专业分工”。2.2 框架层编排、记忆与工具调用的关键细节框架层是Agentic AI Infra里最热闹、也最容易让人选择困难的地方。市面上的智能体框架多得眼花缭乱但判断框架成熟度的标准其实很朴素状态管理清不清楚、记忆机制能不能落地、工具调用有没有完善的失败处理。状态管理为什么重要因为智能体本质上是一个有状态的计算循环。用户说一句话模型要结合当前状态决定下一步动作动作执行完又要更新状态。如果框架把状态散落得到处都是或者干脆让你用全局变量凑合一旦并发上来状态错乱就是必然的。我倾向于用状态机的方式组织智能体流程把“等待用户输入-调用工具-生成回复-确认完成”几个状态明确画出来代码量和排查成本都会下降。记忆机制是另一个容易想当然的地方。很多团队的第一反应是“把全部历史对话都塞给模型”结果上下文越长模型的注意力越分散token成本也越高。更合理的方式是分层记忆短期记忆用一个滑动窗口保存最近几轮对话中期记忆由模型定期把关键信息提炼成摘要长期记忆放在外部向量库里需要时再检索出来。这个思路我们跑了半年稳定性和成本都比“全量保留”强太多。工具调用则要看失败处理。一次失败的API调用不应该让整个智能体崩溃而应该返回一个可读的错误信息让模型决定是重试、换工具还是向用户求助。听起来简单实际项目里坑极多。我们曾经在某个工具上连续失败三次还不降级直接把业务流程卡死了一个多小时后来才在框架层加了熔断和降级机制。2.3 工程层评测、监控与反馈闭环最容易被忽视的就是工程层。很多团队把智能体写出来之后发现效果不稳定一会儿好用一会儿不好用却又说不清哪里变了。我认为所有做智能体的团队第一个要搭起来的不是花哨的界面而是一套评估集。评估集怎么做把线上会遇到的高频问题整理成几百条测试用例每条用例标明输入、期望行为、判定标准。每次改模型、改提示词、改工作流都要跑一遍回归测试。没有这套东西你根本无法判断这次改动到底是变好还是变坏。我见过有些人改了一个提示词之后“感觉”效果好多了结果一跑回归5个指标掉了3个纯属错觉。监控也不能只看模型指标。智能体的运行日志里应该埋点记录每一轮状态迁移、每次工具调用的耗时和结果、每次模型输出的token数。这些数据攒起来之后不仅能做故障排查还能反过来改进评估集。每两周从线上日志里抽一批失败对话让团队判断失败原因再汇总成新用例加入回归集评估体系就会越来越贴近真实分布。2.4 三层Infra的职责边界参考表层级核心职责常见坑点我的推荐策略模型层推理、量化、部署、成本控制显存不足、推理延迟高、Embedding选错模型按任务复杂度分级路由量化模型先验证再上线框架层编排、记忆、工具调用状态丢失、上下文无限膨胀、工具失败无重试用状态机设计流程分层记忆工具层统一做熔断降级工程层评测、监控、安全、反馈无回归集、线上问题不可见、改动无法追溯从第一天建评估集埋点记录关键事件定期扩充用例三层之间不是孤立的。我在项目里的落地方式是模型层先通过Ollama做本地验证定好量化和部署方案框架层选一个支持自定义状态流的编排方案把状态迁移写清楚工程层用一套独立的日志系统记录关键事件评估集单独维护。三者之间用标准接口衔接后续换模型、换框架都不会伤筋动骨。3. 低显存环境下的模型与智能体实操全记录3.1 模型选型、下载与本地部署的完整过程很多朋友问我低显存运行模型怎么选我一般先反问一句你手上是什么显卡如果只是普通消费者级显卡就先别想20B以上的参数。我常用的组合是6G显存跑7B量化模型8G到10G显存可以尝试14B量化模型再往上就得好好掂量并发和延迟了。下载和部署模型我现在习惯用Ollama。它把模型管理、服务启动和API接口都封装好了适合快速验证。大概的流程是这样的# 查看有哪些可用模型 ollama list # 拉取一个量化好的7B模型 ollama pull qwen2.5:7b-instruct-q4_K_M # 启动本地模型服务默认端口11434 ollama run qwen2.5:7b-instruct-q4_K_M启动之后可以用任何支持OpenAI兼容接口的代码来调用本地模型。这里有个小细节不要一上来就追求超大模型。先用小模型跑通端到端流程确认业务逻辑没问题再根据评估结果决定要不要升级模型规模。这个顺序能让你的试错成本低很多。选型时要关注实际部署效果而不是只看榜单。有一些模型在公开benchmark上分数很高但放到中文业务场景里就是不对味。我建议从自己的评估集里挑50条最典型的用例让候选模型都跑一遍人工看输出质量。这一步花不了多少时间却比任何评测榜单都靠谱。3.2 工作流搭建先画状态流转再拖节点在Dify这类可视化平台上搭工作流最忌讳的是拿到就拖边拖边想。节点一多逻辑必然乱。我的习惯是先用一张图把状态流转写清楚用户输入进来之后处于什么状态什么条件下调用哪个工具工具失败之后跳转到哪个状态用户主动取消怎么回退。把这个流转图定下来再映射到平台节点上搭建过程会顺畅很多。写状态流转的时候我建议把异常路径和正常路径放在同等重要的位置。很多团队画的流转图只有“成功路径”一旦工具出错就不知道往哪走了。我会强制自己回答三个问题工具调用失败时智能体是自己重试、换工具还是直接告诉用户“办不了”如果用户中途改变主意前面已经收集的信息是保留还是清空多轮都没能完成任务时智能体能不能给出一个止损方案举个例子我曾经做一个售后客服智能体要求它先查询订单状态再根据状态决定退款还是换货。查询接口偶尔超时刚开始我们的处理是直接返回“系统繁忙”用户体验很糟糕。后来改成“查询失败时先重试一次再失败则降级为让用户描述订单号并生成人工工单”转化率一下子就好了。这就是状态流转设计的价值。3.3 工具调用与记忆管理的避坑清单工具调用和记忆管理表面上是两件事实际上经常纠缠在一起。我整理过一份避坑清单这次分享出来工具调用一定要有超时上限。有些接口慢到30秒才返回智能体会一直傻等白白消耗用户耐心。给每个工具设置合理的超时时间超时即视为失败进入降级分支。工具返回的结果不要全量塞进上下文。很多工具返回的是大段JSON直接丢给模型既浪费token又干扰判断。应该把结果先做摘要只把关键字段传给模型。记忆要区分“事实”和“推测”。用户说“我喜欢简约风格”这是事实系统从历史订单推测他“可能更倾向北欧风”这是推测。事实要存推测要标注置信度别让模型把推测当事实用。多轮对话的滑动窗口不是越长越好。窗口太长模型会被无关历史分散注意力窗口太短又会丢失关键约束。我一般控制在8轮到12轮具体按业务复杂度调。这里放一个我常用的滑动窗口记忆伪代码片段供参考def sliding_window(history, max_turns10, modelNone): if len(history) max_turns: return history tail history[-max_turns:] head history[:-max_turns] if model is not None: summary summarize_conversation(head, model) return [{role: system, content: f历史摘要: {summary}}] tail return tail做法很简单超出窗口长度的旧对话先由模型压缩成摘要作为系统提示词放在最前面再接最近的对话。这样既保留了长期上下文又不会让模型淹没在历史里。3.4 智能体评估方法论把评估集真正用起来关于智能体评估网上有些很好的方法论讨论。我听一个同行分享过“evaluation智能体添加方法论”的做法核心是给每个评估维度定义明确的任务模板。比如“用户明确要A但智能体给了B”属于目标偏离“用户要求查询订单智能体反复问无关问题”属于效率低下。每个模板配10到20条测试用例最终得分是加权综合指标。这个方法的优点是可解释性强团队内部对得分有共同理解。相比“这个智能体好不好用”这种主观判断用“目标偏离率从30%降到12%”来描述改进说服力完全不同。我在项目里也照这个思路建了评估集初始只用了一个下午两百条用例但后面每次迭代都有抓手返工率明显下降。还要定期扩充评估集尤其要从线上真实失败案例里补。比如智能体在某个问题上回答得离谱就把这个场景抽象成一条新用例。这么做会让评估集一直贴近真实分布而不是停留在理想化的测试题上。没有真实数据支撑的评估集看着再完善也只是一堆自嗨。常见失败类型判定标准示例改进方向目标偏离用户要退款智能体推荐优惠券加强意图识别工具选择前增加约束校验效率低下用户查订单连续问无关问题优化状态流转减少无效追问知识错误产品政策已更新智能体还在用旧话术接入知识库检索减少模型自由发挥工具失效查询接口返回空智能体假装成功增加失败识别与重试降级机制4. 2026智能体工程化从概念演示到交付的四个硬门槛4.1 工业智能体为什么要单独说这次云栖上有一个被反复提到的共识2026是工业智能体从概念演示走向工程化落地的分水岭。为什么单独强调“工业”两个字因为工业场景和消费场景的智能体要求完全不同消费场景偶尔答错可以重来工业场景一次误判可能造成连锁损失。工业智能体落地至少要跨过四个门槛。第一是数据不能随便出场很多制造企业的数据有合规要求模型推理必须本地化第二是7乘24小时的可用性系统不能因为推理服务挂了就停产第三是要能对接老旧的工控系统MES、ERP这些系统的接口往往又老又杂智能体要能适应第四是长周期任务的稳定性一个质检辅助流程可能要连续跑几个小时中途不能状态错乱。这些门槛没有一项是靠提高模型参数能解决的全都要靠基础设施层一个个补。所以我才说2026是分水岭——因为今年已经有越来越多的团队把这些事当成项目前期条件而不是上线前才补的补丁。4.2 我亲历的落地场景网络不稳定害惨了我们分享一个我自己的例子。去年我们做一个车间质检辅助项目模型精度反而不是最大的问题最大的问题是现场网络不稳定。车间里有一些区域信号很差推理服务一断整条辅助流程就跟着停工人只能干等。后来我们换了一种部署思路把轻量模型做成端侧部署直接跑在现场工控机上只在汇总统计时才把结果回传服务器。这样一来即使网络断了单台设备也能独立完成检测工作。这个经历给我的教训是智能体系统的架构设计一定要从运行环境倒着推而不是从模型能力正着推。先搞清楚现场有什么硬件、网络怎么样、数据能不能外传再决定模型放在哪儿、任务怎么编排。否则你做了一个技术演示时惊艳的方案到了真实环境却寸步难行。4.3 值得继续投入的框架与工具方向站在现在的节点往回看我建议团队关注三个工具方向一是支持多智能体编排的框架多个智能体协作时的状态同步、任务分配、结果汇总目前可用的成熟方案还不多二是把评测能力内置到开发流程里的平台让评估集和开发迭代绑定在一起而不是靠手动跑脚本三是本地模型服务管工具Ollama这类工具的成熟度已经足够让团队把验证成本压得很低。Dify这类平台也在往生产级走权限、审计、知识库管理都在补强值得持续跟踪。但要说依赖某个平台我又持保留态度。选择框架不是选最热门的而是选能让你把状态、记忆、工具调用三个核心逻辑写清楚的那个。如果某个框架逼你在系统提示词里塞一大堆状态管理代码那基本说明它的抽象还不够好尽快换掉。4.4 模型微调与智能体训练的正确心态DeepSeek公开AI智能体训练新方法之后很多人跑来问我“我们要不要也做微调”我通常泼一盆冷水先把检索、工具调用、评测做好再考虑微调。因为智能体项目的瓶颈多数在工程侧不在模型侧。只有当你几百条评估用例里有大批失败是因为模型对特定业务知识的理解不够这时候微调才有价值。如果真的要做也要遵循一套朴素流程先收集一批失败的对话标注期望行为构造微调数据集然后小步训练每个版本跑一次回归评估集用数据说话而不是凭感觉。模型能力的提升永远是加分项但不应该成为掩盖工程问题的遮羞布。我见过太多团队遇到效果不好就想着换大模型、做微调其实问题出在工具调用逻辑和记忆管理上白白浪费了好几个月的算力。5. 最后想分享的一点体会这次云栖听下来我最大的感受是Agentic AI Infra不是一个新名词包装它意味着我们做智能体的方式正在发生变化。过去是拿到一个模型迫不及待地写提示词现在要先想一想模型怎么接入、任务怎么编排、失败怎么恢复、效果怎么评估。这四件事想清楚了智能体才是真正的产品否则永远停留在玩具阶段。分享一个小技巧我每次接手新智能体项目第一周不会写任何业务代码只做三件事——跑通一个最小模型服务、写一份状态流转文档、建一个包含二十条用例的评估集。这套占位工作看起来慢但后面所有迭代都有抓手项目返工率显著下降。云栖2026把Agentic AI Infra摆到台前其实也是在说咱们这些做智能体的人该把地基认真打一打了。以上就是这次大会间隙基于我几个项目实践得到的一点朴素体会供同行参考。