企业官网建设流程全解析

从云栖2026的日程公开之后，我身边技术群里讨论最密集的词，已经从“大模型”悄悄变成了“Agentic AI Infra”。这个词拆开看，一半是智能体，一半是基础设施。过去两年，大家还在比模型排行榜，比谁的推理分数更高；到了2026年，更真实的矛盾变成：模型已经能写代码、能推理、能调用工具，为什么放到业务里，还是一个“看起来很聪明但用不起来”的demo？答案几乎都在模型外围的基础设施上——没有稳定的记忆，没有可控的编排，没有能承接业务规则的工具层，模型本身的创新能力完全释放不出来。

Agentic AI Infra，就是补上这层短板的整套工程体系，包含模型服务、智能体运行时、数据反馈闭环、可观测性和安全控制。云栖2026把“加速模型与智能体创新”作为主题，背后就是在强调：模型创新不再是单点训练，而是需要一套系统来支撑；智能体也不再是单个Prompt技巧，而是一整套可运行、可扩展、可治理的软件框架。这篇文章我会站在做工程和产品落地的角度，把Agentic AI Infra拆开来讲，结合我实际搭建智能体平台的经验，把关键点、坑和参考方案都写出来。

1. 为什么说Agentic AI Infra是2026年的基础设施主线

智能体这个概念并不新，但2026年谈智能体和三年前完全是两码事。三年前做一个问答机器人，核心工作就是选模型、写Prompt、接知识库。到了2026年，如果还是这套思路，基本只能做内部玩具。现实中的智能体要能连续执行多步任务：先拆解目标，查内部系统，读文档，算数据，再调接口写回结果，最后还要有失败重试和结果汇报。它本质上是一个长期运行、有状态的程序，模型只是这个程序里的“决策引擎”。

所以云栖2026把Agentic AI Infra单独拎出来，是因为行业意识到一个很朴素的问题：智能体交付的是确定性结果，不是一段概率文本。模型输出天然有不确定性，而基础设施的作用，就是把这种不确定性控制在业务可接受的边界之内。比如工具输出的格式必须解析成结构化数据，动作必须经过权限校验，每一步的上下文必须持久化，执行失败时必须有回退策略。这些逻辑如果写在应用层，每个智能体重写一遍，项目必然失控。

1.1 从“模型能做什么”到“智能体能交付什么”

过去衡量模型创新，大家习惯看Benchmark。同一道数学题、同一份代码题，分数涨两分就是新闻。但到了真实业务里，模型能力只是起点。一个采购审批智能体，模型能理解“请帮我核对这个供应商的资质”，这件事情早就没难度了；真正有难度的是：它需要知道从哪个接口取供应商数据，怎么判断资质过期，超过多少金额要触发多人审批，审批不通过时怎么向用户说明原因。这些能力都不在模型的权重里，而在基础设施里。

我见过不少团队踩同一个坑：先花大量精力选了一个“聪明”的模型，然后把智能体的所有逻辑都堆在Prompt里。结果模型一升级，Prompt全乱；业务规则一变，Prompt要重写；工具一多，模型开始在无关函数之间摇摆。这个坑的本质，就是没有把智能体当作系统工程来设计，而是当成了Prompt实验。

1.2 智能体基建的分层：算力、模型服务、运行时、数据闭环

我习惯把Agentic AI Infra分成四层看，这样出了问题能快速定位，也和别人讨论时不容易鸡同鸭讲。

• 算力层：GPU调度、低显存推理、模型量化、弹性扩缩容。这一层直接决定智能体的单位成本。
• 模型服务层：基座模型、精调模型、Embedding模型、重排模型的统一接入，以及路由、缓存、限流。
• 运行时层：智能体的状态管理、步骤编排、工具调用、权限、记忆和对话管理。
• 数据闭环层：交互日志采集、人工标注、评测集构建、模型迭代和数据回流。

这四层互相咬合。缺算力，智能体跑不起来；缺模型服务，每个业务都要自己部署一套模型，浪费严重；缺运行时，智能体无法变成可维护的系统；缺数据闭环，模型能力就一直停在原地。云栖2026大量议题都在谈这四层的具体实践，说明行业已经从“单点工具比拼”进入“基础设施竞争”阶段。

2. 支撑智能体创新的关键设施：六个不能回避的工程问题

智能体创新看着是算法问题，做起来全是工程问题。下面六个问题，是我在多个项目里反复踩过的，也基本是Agentic AI Infra需要覆盖的最小集合。

2.1 模型服务层：低显存与轻量化部署不是伪需求

别一上来就说要搞千亿参数模型。实际场景往往相反：智能体每执行一步都要调用模型，如果每个请求都打超大模型，延迟和成本都扛不住。我实际用的策略是“按任务分档”：复杂规划用能力最强的模型，频率低；意图判断、实体抽取、路由分类用中小模型，频率高；工具结果的格式化，直接用小模型甚至规则。Transformer架构至今仍是大多数模型服务的基础，但部署时已经不是非要用原版FP16权重，量化、蒸馏、LoRA微调都是模型服务层常做的事情。

我个人的经验是：先在低显存环境里跑通推理，再考虑上生产。Ollama这类工具对本地起模型很友好，下载后在本地试跑，GGUF量化格式能明显把显存占用降下来。当时用一张24G的卡跑7B级模型，量化后流畅执行工具调用完全没问题。关键点在于：模型服务层必须做“路由”，不是所有请求都要走最强模型。Embedding模型也一样，排行榜可以看，但真正要选哪个，得拿自己的业务文档做检索实验，用召回率去判断，而不是只看分数。

2.2 上下文与记忆：滑动窗口只是及格线

很多智能体第一版聊不了几十轮就崩溃，原因就在上下文。模型上下文长度虽然越来越长，但长上下文不等于长记忆。滑动窗口只解决“塞不下”的问题，解决不了“记不住重点”的问题。我把记忆分成三层：

• 短期记忆：当前任务的上下文，通常存在运行时的状态里，任务结束可清理。
• 长期记忆：用户偏好、历史事实、业务实体，写入向量库或结构化存储。
• 工作记忆：正在执行的多步计划，需要支持暂停、恢复和更新。

典型的做法是，每轮对话后把关键信息剪接成摘要，同时把结构化信息，比如用户ID、订单状态，写到独立字段。别把对话原文全部塞进Prompt，那既浪费Token，也干扰模型注意力。这里的“滑动窗口”可以简单理解为按最近N轮或N个Token截取，但想想就知道，用户5小时前提的要求，早就滑出去了，所以要配合记忆数据库才能完成跨会话任务。很多平台层面的智能体开发套件也意识到这一点，像Dify、扣子这类工具能快速搭出带记忆原型，但生产级记忆方案往往还是需要自己设计存储结构和读取策略。

2.3 工具调用：让模型会“用系统”

智能体价值的核心之一，是把模型和现有系统打通。工具调用必须作为基建能力来建设，而不是在Prompt里写“你可以调用以下函数”就完事。我强调几个容易忽略的点：

• 工具描述要规范，参数要用JSON Schema定义，让模型能稳定生成结构化调用。
• 工具返回结果要设计成“机器可读+人类可读”双轨，比如返回结构化数据之外，附一段摘要文本，模型可以直接引用。
• 工具执行要有超时和幂等控制，防止模型重复调用造成重复扣款、重复发消息。
• 权限要前置，智能体只能调用当前用户有权限的操作，这个校验不能放在工具内部，要在运行时拦截。

很多团队觉得工具调用是模型能力问题，实际上模型已经把函数调用学得很好了，80%的失败发生在工具定义不清、返回格式混乱、超时不处理这些基建问题上。另一个容易被忽略的是状态存储。状态到底放Redis还是数据库，取决于并发和持久化要求。如果状态只放在进程内存里，服务一重启，任务就全丢了，这在生产环境是致命的。

2.4 多智能体编排：从单点智能到协作

单智能体能做客服问答、文档助手，但复杂业务流程通常要用多智能体。常见模式有两种：

• 编排者模式：一个主智能体负责任务拆解，把子任务发给不同的专业智能体，最后汇总。
• 协作模式：多个智能体通过事件总线或共享黑板交换消息，各自完成自己的专业动作。

编排模式适合流程明确、边界清晰的业务；协作模式适合探索类任务，但可控性差。2026年很多讨论都在谈工业智能体，工业场景对确定性要求特别高，我见到的落地案例大多采用编排者模式，每个子智能体只做很小、很明确的事情，整条链路有状态机控制，这样出了问题能快速定位到是哪一步。基础设施要为编排提供状态，比如任务ID、节点ID、重试次数、执行记录，这些都要做持久化。否则一个服务重启，智能体就失忆了。

2.5 可观测性与评测：没有这些等于盲开

智能体是概率性系统，同一个Prompt可能走不同路径。所以可观测性不是可选项，而是基础设施。要把模型调用的输入输出、工具调用的参数、每一步的耗时、Token消耗、异常栈全部记录下来。等出问题的时候，这些日志能帮你还原现场，我无数次靠这个定位到“原来是在第四步工具返回了一个空列表”。

评测也是一样。不能只评测最终答得好不好，还要分步评测：意图识别对不对、参数提取准不准、工具选择对不对、最终答案是否忠于检索结果。评测集应该从真实业务日志里构建，而不是拿几个通用题目凑数。很多团队一开始觉得“智能体开发就是写写Prompt”，后来发现最难的是定义“什么算对”。这个问题越早想清楚，后面越省力。

2.6 数据闭环：模型持续创新的燃料

模型创新不是一次性训练完就结束。智能体跑起来之后，会沉淀大量交互数据，这些数据是继续精调小模型、优化Prompt和工具定义最宝贵的原料。我的建议是分三步：

第一，采集真实交互日志和用户反馈；第二，按错误类型打标签，比如“答非所问”“工具参数错”“拒绝执行错了”；第三，把这些清洗后的样本放进评测集，每周跑一次回归，看新模型、新Prompt有没有让指标变差。这个飞轮转起来，才是Agentic AI Infra“加速模型与智能体创新”的完整含义。只做模型不改数据，模型能力就是无源之水。

3. 从0到1搭建智能体基础设施：一条可复现的路径

很多朋友问我要参考架构，这里我给出一个个人比较推崇的“最简可用”方案。目标是让一个智能体能够完成“理解问题-检索资料-调用工具-输出结果”的闭环，且每一层都能被监控、被替换。

3.1 先定边界：单智能体还是多智能体

第一步别急着写代码，先画流程。列出智能体要完成的完整任务，把步骤拆出来。如果任务少于三个明确步骤，单智能体加工具就能解决；如果超过三层嵌套，或者多个角色需要不同权限和知识库，就考虑多智能体编排。我一般用一个表来辅助拆分：

这个表不是为了框死方案，而是帮你建立判断框架。很多时候业务看起来复杂，拆完发现还是单智能体能做。也有时候业务看起来简单，但权限严格按部门隔离，那也得走多智能体。

3.2 模型服务层配置：基座模型、Embedding 与排序

实际项目中，我至少会准备三类模型：

• 规划/推理模型：负责任务拆解和最终答案生成。能力优先，可以是大参数模型，用量最少。
• 轻量模型：负责任意意图分类、实体抽取、工具参数补全。用7B到20B的量化模型即可，速度快。
• Embedding模型：负责把文档分块、向量化。选择标准是检索效果，不是榜单分数。

另外，如果检索结果太多，可以加一个重排模型做相似度精排，保证给模型的上下文是最相关的。低显存环境可以用Ollama拉起量化版本，先在本地验证，再上云。生产环境建议用支持批处理和连续批处理的推理服务，避免每次请求都重新加载权重。算力层如果预算有限，优先保证规划模型的延迟，不要在小模型上过度投入。

3.3 智能体运行时：状态机、工具协议与回退

智能体运行时的核心，是把“模型决策”和“执行动作”拆开。我习惯用一个简单的循环来实现：

while task_not_done: plan = llm_plan(state) if plan.is_final: answer = llm_generate_answer(state) break result = execute_tool(plan.tool, plan.params) state.append(plan, result) state.save()

关键的细节有四个。第一，state必须持久化。可以是Redis、数据库或对象存储，至少要存任务ID、步骤序号、已执行的工具结果。第二，工具协议统一成JSON格式。模型输出函数名和参数后，运行时先校验，再执行，执行结果以结构化字段回填。第三，每一步都记录日志，包括模型输入输出、工具请求响应、耗时、Token。第四，设置兜底方案。当模型连续两次生成同样的无效工具调用时，不要再重试，直接转人工或给默认话术。

3.4 从demo到可用的三个关键动作

第一，把Prompt测试自动化。我见过太多团队在界面上手测，测了几个case觉得“差不多”，上线就翻车。应该把典型Case做成断言脚本，每次改Prompt或换模型，自动跑一遍。第二，单独建“工具沙箱”。工具调用出错是常态，沙箱环境可以模拟超时、返回错误、字段缺失，帮你观察模型在这些异常下的表现。第三，预设安全过滤器。不要等模型自己“道德自觉”，要在工具层和输出层都加规则：敏感操作需要二次确认，不允许调用的域直接拦截。这些动作做完，智能体才算从“能跑”变成“可用”。

4. 工程化落地中的常见问题与避坑经验

下面这些问题都是我实际踩过的，而且基本都很有代表性。如果你正在搭类似的东西，大概率也会撞上。

4.1 上下文爆掉：不是加长模型就能解决

有的团队把上下文长度从8K换成128K，结果效果反而下降。原因很简单：模型看到的信息太多，其中夹杂了无关内容，注意力被稀释。更合适的做法是分层管理。比如一个客服智能体，一开始把用户所有历史记录都放进Prompt，后来改成：只带最近3轮对话、用户当前订单摘要、售后政策片段，效果提升明显。长文本应该在检索和摘要阶段处理，而不是一股脑全给模型。

提示：把“信息召回”和“生成回答”分开。召回阶段的目标是挑出最相关的几条，生成阶段只需面对一个小而精的上下文。这条经验适用于绝大多数智能体任务。

4.2 工具调用失败的真正根因

工具调用失败，先别骂模型。查看日志你会发现，很多时候是参数类型对不上、字段名拼错、必填项缺失。模型从自然语言提取参数，本身会有一定错误率，所以工具层要做参数修正。我常用的技巧：在工具定义里为每个参数写清楚取值范围和示例；运行时如果检测到参数不合法，把错误信息返回给模型，让它重新生成。比如“日期应为YYYY-MM-DD格式，当前得到‘明天’”，模型会自动修正。这和人的工作方式一样，工具把报错信息说清楚，执行者才知道怎么改。

4.3 评测分数高，但用户不买账

用通用评测集跑出来的高分，和真实用户体验往往差很远。原因是评测集没有覆盖长尾Case。要解决，必须从线上日志里抽样补充评测集，并且按用户反馈对个案加权。我还发现，评测不能只看最终答案。比如一次执行链路里，前面的工具调用选错了，但最终答案瞎编对了，评测会误判成功。所以在评测系统里要按节点记录“步骤是否正确”，而不是仅比对了最终文本。

4.4 常见故障速查表

这个表不是标准答案，但能帮你快速建立排查顺序。做Agentic AI Infra，本质上就像在给智能体修“高速公路”：模型是引擎，基建是路网、指示牌和维修站。引擎再好，路不通，车也开不到终点。

5. 写在最后：我的一点个人体会

云栖2026把Agentic AI Infra放到主题位置，在我看来是一个明确信号：单点模型的优势窗口越来越短，真正的壁垒会沉淀在基础设施里。对我来说，2026年做模型和智能体创新，最值得关注的绝不是再调一个Prompt，而是把下面三件事想清楚：模型服务能不能按需路由；运行时能不能支撑复杂状态；数据能不能反哺模型迭代。如果这三件事成立了，一个几十人的团队也能做出很亮眼的智能体产品。如果这三件事没成立，再大的模型也救不了项目。

最后分享一个习惯：每次引入新的智能体框架或模型服务，我都会先花一天时间把它的可观测性补齐，再花一天时间写最小回归Case。这两天的投入，后面能省下两周的排查时间。这大概是我在Agentic AI Infra里最想提醒同行的一件事。