企业官网建设流程全解析

云栖2026把“Agentic AI Infra”放到了主话题的位置，我其实并不意外。今年我参加了不少技术交流，一个特别明显的信号是：大家问问题的方式变了。去年还都在问“大模型能帮我做什么”，今年已经变成“智能体到底怎么稳定跑起来、怎么控制成本、怎么不出安全事故”。

这个转变背后，是整个行业从“追逐模型性能”到“建设智能体基础设施”的范式切换。很多人还没意识到，Agentic AI Infra 不是一个PPT名词，它决定了一个团队能不能把智能体从 Demo 送进生产环境。这篇文章我就结合云栖上的议题、社区里大家正在搜的技术问题，以及我自己的实操经验，把 Agentic AI Infra 拆开揉碎讲清楚。

1. 云栖2026的信号：Agentic AI Infra 为什么成了主话题

1.1 热搜词背后的三层需求

云栖期间我刷了一轮技术社区的热搜词，发现一个很有意思的现象：大家搜的东西呈现出明显的三层结构。

第一层是模型层。Transformer模型详解、DeBERTa模型结构图、CLIP模型微调、embedding模型排行、低显存运行模型、滑动窗口滤波模型，这些词说明很多人还在补模型基础，尤其是要在自己的场景里选型、微调、部署模型的团队。

第二层是编排层。智能体框架、Dify智能体平台、Coze+智能体、扣子开发AI Agent智能体应用、AI智能体的工作流搭建，这一层搜索量最大，说明多数人已经过了“大模型是什么”的阶段，开始实际动手搭智能体了。

第三层是治理层。OWASP Top 10智能体应用、模型中毒攻击、智能体技能敏感变量，这些词的出现很有意思——只有当大家开始把智能体往生产环境推，才会关心安全、权限和风险。

这三层需求放在一起，正好就是 Agentic AI Infra 要解决的全部问题：让模型跑得更便宜、让智能体搭得更稳、让系统上线后不被攻破。

1.2 从 MLOps 到 Agentic Infra 的范式迁移

要理解 Agentic AI Infra 是什么，最好先把它和过去两个概念对照起来看。

MLOps 时代，大家关心的是模型训练、模型部署、模型监控，核心交付物是“一个能用的模型”。LLMOps 时代，核心变成了 Prompt 管理、上下文工程、RAG 链路、推理成本，交付物是“一个能用的生成服务”。而到了 Agentic Infra 时代，交付物变成“一个能自主完成任务的智能体”。

这三者的差别，我用一张表来对照：

从这张表能看出，Agentic Infra 比过去任何一个“Ops”都更复杂，因为它要管的对象不是一个静态的模型服务，而是一个有状态、会调用外部工具、和真实世界交互的自主系统。

2. 模型层的硬约束：小模型、低显存与推理经济性

2.1 为什么大家还在搜“模型结构图”

坦白说，当我看到 Transformer 模型详解、DeBERTa 模型结构图、CLIP 模型微调还挂在热搜上时，第一反应是“基础知识缺口比我想象的大”，但细想又觉得合理：很多团队之前的做法是直接调 API，现在要自建智能体底座，突然发现自己连选型都做不了。

这里我想给一个实用建议：不是所有智能体场景都需要用到最新最强的超大模型。比如文本分类、意图识别、工具路由、实体抽取这类脏活累活，用 DeBERTa 这类 encoder 模型反而比 7B/14B 的生成模型更稳，因为它在分类任务上收敛快、推理开销低、可控性强。常见做法是：

• 意图识别、路由决策：用中小型 encoder 模型（DeBERTa、BERT 系列），在线延迟能做到几毫秒
• 通用对话与任务规划：用 7B~32B 的通用生成模型，主打推理成本适中
• 多模态场景：需要图文对齐的，考虑 CLIP 类的双塔模型做预处理（图像检索、图文校验），而不是把所有信息都交给多模态大模型

很多人一上来就想做“一个智能体解决所有问题”，结果模型选得太大、太贵，上线即亏损。我踩过的坑是：第一版智能体全链路都用了大模型，日均成本高得离谱，后来把高频简单子任务全部切到小模型，成本直接降了一个数量级。

2.2 低显存运行模型的可行路径

低显存运行模型这个热搜词，背后是无数被卡在“显卡不够”这个现实问题上的团队。我总结几条确定可行的路径，都是自己跑过的：

1. 4bit量化：7B 模型 FP16 权重约 14GB，用 GPTQ/AWQ/GGUF 量化到 4bit 后，权重直接压到 4~5GB，消费级 12GB 显卡就能跑。
2. KV Cache 优化：很多人忽略了 KV Cache 才是长上下文场景下的显存大头。7B 模型以传统 MHA 结构为例，hidden 4096、32 层，每 token 的 KV Cache 约 0.5MB，8K 上下文就接近 4GB。换成 GQA（KV 头数降到 8 个），同样 8K 上下文只占约 1GB。
3. 滑动窗口注意力：这里要澄清一个容易混淆的点。热搜里的“滑动窗口滤波模型”听起来像信号处理，但在 LLM 语境下，大多数技术讨论指的都是滑动窗口注意力（Sliding Window Attention）。它的思路是让每个 token 只关注前 N 个 token（比如 1024 或 4096 个），把注意力矩阵从 O(n²) 降到 O(n*w)，长上下文场景的显存和计算量肉眼可见地往下掉。

给个参照算例：7B 模型，4bit 量化权重约 4.5GB，加上 GQA 下 8K 上下文的 KV Cache 约 1GB，再加激活值和其他开销，整套推理可以控制在 6~7GB 以内。所以“低显存”这件事，不一定非得换硬件，把模型结构和量化策略研究透就行。

2.3 Embedding 选型：RAG 智能体的命门

embedding 模型排行能上热搜，说明很多人已经开始做 RAG 了，并且被检索质量折磨过。我的经验是，选 embedding 模型不能光看排行榜分数，要看自己的数据长什么样。

• 如果文档以短文本为主，768 维的模型通常够用，没必要上 1024 维或更高维的模型，后续索引和存储开销会小很多
• 如果文档是多语言混合的，优先考虑对多语言支持好的模型
• 如果是中文专用场景，需要拿自己的行业语料做小规模评测，不能只看公开榜单

具体操作上，我会先用一个通用 API embedding 做基线，再拿一个开源本地模型做对比，跑一遍自己的召回用例，看在 top-5/top-10 结果里到底谁的中文语义理解更符合业务。

一个容易被忽略的细节：embedding 不光用于知识检索，还用于智能体的记忆去重和工具路由。比如意图识别语义太复杂的时候，可以直接把用户问题向量化，去匹配“已有意图模板”的向量。所以 embedding 的质量，直接影响智能体“听懂人话”的能力，这是基础设施层面的事，值得花时间打磨。

3. 编排层的工程岔路：框架、平台与工作流

3.1 框架与平台怎么选：agno、Dify、Coze/扣子的一线对比

智能体框架的热搜词很多，最常被拿出来比的就是 agno、Dify、Coze（扣子）。我三个都用过，直接说结论：

我的建议套路是：先用 Coze 或扣子快速把业务逻辑跑通，验证“用户到底买不买账”；确认方向没问题后，再用 Dify 搭一版可自托管的生产系统，把知识库、日志、权限都管起来；等业务规模继续变大、需要深度定制多智能体协作时，再切到 agno 或直接用原生框架自研。

这套路径的好处是，每一层都没有浪费，渐进式投入，不用一上来就押注某个框架。框架这东西，适合比强大更重要。

3.2 从搭 Demo 到跑生产：工作流搭建的核心矛盾

很多人搭建智能体工作流的第一版都特别顺利，但一上生产就崩。区别不在模型，而在状态管理、错误重试和上下文控制。

举个实际例子：一个智能体要完成“查库存→下订单→发通知”这组动作，任何一个环节出现 API 超时或不稳定，都需要明确“是重试当前步骤，还是放弃整个任务，还是切换备用工具”。很多工作流设计里根本没有这个判断逻辑，结果就是智能体看起来在干活，实际成功率惨不忍睹。

还有上下文窗口的问题。多轮对话一长，历史塞满窗口后，智能体会“忘记”前面的任务目标。我的做法是给智能体加一个“任务摘要节点”：每几轮对话之后，用模型把已完成事项和当前目标压缩成一段结构化摘要，再作为后续轮次的上下文输入。这能显著减少跑偏概率，但也别把所有希望放在摘要上——关键信息必须落库到记忆系统，而不是只存在于对话上下文里。

热搜里那个“CC Switch切换模型后原对话不停跳闪”的问题，本质也是上下文管理没做好。很多人以为切换模型就像换引擎一样简单，但 KV Cache、tokenizer、system prompt 的格式都不兼容，前端流式状态一重置，对话自然就跳闪了。正确做法是切换模型时强制开启新会话，或者先把历史对话做一次压缩改写，再带到新模型下继续。

3.3 多智能体协作与记忆系统

智能体数量一多，编排复杂度会指数上升。我见过最头疼的现场是：主控智能体把任务拆给了三个子智能体，子智能体各自调工具、各自写记忆，最后汇总时发现数据和结论对不上。

这里有两个核心设计原则。

第一，任务边界要清晰。每个子智能体的“能力描述”必须写清楚它负责什么、不负责什么，避免能力重叠导致互相抢活。实践中可以把能力描述也转成向量，让路由决策模块按语义匹配分活。

第二，记忆系统要分层。短期记忆放会话上下文，中等记忆放工作流状态，长期记忆进向量库。每层记忆要有独立的写入权限和过期机制——长期记忆尤其要小心，因为一旦把错误的、恶意注入的信息写进长期记忆，后续所有会话都会受害。

关于多智能体的组织结构，我目前用得比较多的是 Planner-Executor-Reviewer 模式：Planner 拆任务，Executor 做执行，Reviewer 校验结果。这个结构每多一层，稳定性都会打折扣，所以除非任务确实需要，不要盲目上多智能体。

4. 治理不是事后补丁：智能体的安全边界与可观测性

4.1 OWASP ASI Top 10：为什么智能体比 API 更难防守

OWASP 在 2025 年推出了针对 LLM 智能体的 Top 10 榜单，编号是 ASI01–ASI10。我在云栖期间看到它也被大量讨论，因为智能体的攻击面和传统 API 完全不是一个量级。

我挑几个最危险的说：

传统 API 的防护重点在“入参校验”和“身份认证”，但智能体是主动行为主体，它会自己读文档、看网页、调工具。攻击链更长，防守点更多。这也是为什么现在很多企业意识到，智能体安全需要专门设计，而不是沿用老一套防火墙策略。

4.2 最小授权与敏感变量：权限模型怎么设计

“智能体技能敏感变量”这个热搜词，我猜不少人是真的在项目里被坑过。

敏感变量指的是 API Key、数据库连接串、内部服务地址这类配置项。它们经常被写死在技能代码里，或者在 Prompt 里被当成普通字符串拼接，导致敏感信息出现在日志、错误信息甚至被模型“复述”出来。

我的做法是三条原则：

1. 最小授权：每个智能体/技能只拿到完成当前任务所需的最小权限范围。比如负责查询的技能，只给只读账号，不碰写权限。
2. 敏感变量执行层解引用：Prompt 和技能代码里不出现真实密钥，只有变量名，真正取值发生在工具执行层，且不写进调试日志。
3. 日志脱敏：所有日志通道统一过一遍脱敏过滤器，把疑似密钥、手机号、身份证号替换成掩码。

还有一点很重要：工具的权限要和用户身份绑定，而不是和智能体绑定。否则一旦智能体被注入攻击，攻击者就相当于拿到了智能体的全部权限，后果不堪设想。

4.3 可观测性：让智能体“可面试”，而不是“可盲猜”

可观测性是智能体能不能上生产的分水岭。我的观点很朴素：一个无法审计的智能体，等于一个你无法追责的实习生。

具体来说，智能体的日志至少需要记录这几类信息：

• 每一轮用户输入和智能体输出
• 每次工具调用的入参、出参、耗时、返回状态
• 路由决策结果（为什么选了工具 A 而不是工具 B）
• 记忆系统读写记录（往长期记忆里写入了什么）

有了这些日志，出问题才能回放，才能定位是模型决策错了、工具报错了，还是外部输入注入导致跑偏。这里又回到热搜里的“智能体面试”这个词了——我觉得特别贴切。面试一个智能体，就像面试一个候选人：看简历（系统 Prompt 和能力描述）、做笔试（离线评测集）、现场实操（沙箱任务）、做背调（查看生产日志）。这四步做全了，这个智能体才敢放手让它干活。

5. 从演示到交付：工业智能体落地的几个检查点

5.1 为什么说 2026 是工业智能体的分水岭

网上关于“2026 是工业智能体从概念演示走向工程化落地的分水岭”的说法，我基本认同。理由是基础设施层已经具备了三块拼图：推理成本降到了可承受区间、编排框架成熟到了可工程应用、安全标准（比如 OWASP ASI）开始形成行业共识。

但我也要说一句泼冷水的话：分水岭不是自动到来的，它需要每个团队真刀真枪地完成一次“从演示到交付”的跨越。演示阶段你只需要让智能体“看起来很聪明”，交付阶段你需要让它“稳定可靠地完成任务、可观测、可回滚、防攻击”。这两个阶段的工作量完全是两码事。

5.2 五个检查点：从 POC 到生产的迁移清单

结合我自己带项目落地的经验，我在从 POC 进生产之前会逐一核对五个检查点：

这五个检查点里，最容易忽略的是第 5 条。很多团队上线前评测分数不错，上线后一遇到真实用户就露馅，因为线上的输入分布和评测集完全不一样。把失败样本收集起来，持续回流到评测集里，评测集才会越来越贴近真实。

5.3 专业场景为什么更容易落地：以代码检视为例

云栖期间我特别关注到一个案例：华为云码道检视修复智能体，公开的评测数据是召回率 91.3%。这个数字放在一堆通用智能体里可能不显眼，但在代码检视这种专业场景里，已经很能说明问题了。

为什么这类场景更容易落地？因为它的问题域边界足够清晰：输入是代码变更，输出是缺陷建议和修复方案，评判标准是“是否检出真实缺陷”。这种场景下，智能体不需要“无所不知”，只需要在有限知识库里做精准判断。

这给了我一个很重要的启发：智能体落地的第一原则是划边界，不是堆能力。先把场景收窄到“能找到高质量标注数据、有明确评判标准”的领域，把成功率做上去，再逐步扩展。

我现在带队做智能体，内部有一个铁律：宁可让智能体说“这个问题我不确定”，也不要让它强行编造答案。这个纪律和基础设施无关，但往往比任何技术选型都管用。

6. 我的几点实操体会

最后聊几句个人体会。

第一，不要把基础设施预算全砸在模型上。模型是最容易被看到的部分，但智能体能不能稳定跑起来，更多取决于编排、记忆、可观测性和安全这四块“看不见的地基”。我见过太多团队模型用得很顶级，日志却一塌糊涂，出了安全事故连原因都查不到。

第二，小团队起步别贪大。两个人以内的团队，我强烈建议先用 Dify 或 Coze 这类平台跑通完整闭环，拿到业务数据后再考虑自研组件。死磕“完全可控的框架”在早期不是美德，是内耗。

第三，给智能体“上保险”这件事要放在第一天。我目前做任何新智能体，第一件事就是确保所有工具调用都会生成显式的 JSON 日志。这一点做到位了，后面不管是排障、审计还是优化提示词，都会轻松一个量级。

Agentic AI Infra 听起来是个宏大概念，但落到实操里，就是一遍一遍地把“模型选型、编排设计、记忆管理、安全治理”这几件事做扎实。基础设施存在的意义从来不是炫技，而是让模型和智能体的创新，真正交付到用户手里时不翻车。