企业官网建设流程全解析

HCC 2026 的议程方向出来后，我把几个老朋友拉了个线上会，大家口径几乎一致：算力竞争真真正正进入了下半场。去年大家关心的还是谁家预训练集群堆了多少卡，跑分又高了多少；今年话题已经变成了一件事——Agent 这类新应用形态，到底需要一个什么样的底座，才能跑得稳、扛得住并发、算得过来成本。

作为一个一直和模型部署、算力调度打交道的人，我把这个转变看得很重。大模型的能力从“能不能训出来”进入“好不好用、用不用得起”的阶段，技术上最大的变量，不是参数规模，而是 Agent 带来的消耗模型变化和工程复杂度的爆炸。这篇文章，我结合自己搭建 Agent 平台的经验，从华为全联接大会 2026 释放的方向切入，聊聊我眼中的 Agent 新底座应该长什么样，以及团队从零开始应该怎么落。

1. 算力竞争进入下半场，风向为什么变了

1.1 上半场比的是马力，下半场比的是扭矩

如果把训练大模型比作造赛车，上半场大家比的是发动机极限功率：堆卡、堆互联、堆显存，把预训练任务在更短时间内跑完。这个阶段，算力竞争的核心指标是总算力规模和效率，说白了就是“马力”。

但到了实际业务部署阶段，情况完全不同。一台赛车不可能一直全油门跑，它要过弯、要走走停停、要控制油耗。Agent 就是这辆需要精细化操控的车。它不会一次消费一个大任务，而是在一个很长的循环里，反复调用模型：先做意图识别，再拆解任务，然后调工具、读知识库、校验结果、生成回复，中间还可能失败重试。这种模式对算力的要求，不是“峰值多高”，而是“在复杂路况下的扭矩输出是否稳定”。

我自己搭建过客服 Agent，体感特别明显。一次简单的用户咨询，看起来只是聊天，但后台可能要经历 4 到 7 次模型调用，token 消耗轻松破万。一个线上对话系统如果同时有 500 个用户在线，每个用户平均 1 分钟产生 3 次交互，背后就是每分钟上千次的推理请求。传统那种“一台机器扛一个大请求”的思路，在这个场景下完全不够用。上半场可以不顾一切冲极限，下半场必须学会精打细算。

1.2 被 Agent 解构后的算力消耗模型

很多团队对 Agent 的成本预估，往往还停留在“一次对话 = 一次模型调用”的思维上，结果项目上线后账单吓人一跳。

我举一个实际项目里的估算例子。一个行业问答 Agent，任务链条大概是：

1. 根据用户问题，做一次意图识别（小模型，几百 token）
2. 命中知识库需求，做一次 embedding 检索（几百 token）
3. 把检索结果拼进上下文，交给主模型做生成（可能 3000 到 8000 token）
4. 生成结果后做一次合规检查（小模型再跑一遍）
5. 如果结果不达标，还要重试一轮

这样一整套下来，单个用户单次会话的主模型调用至少在 8000 token 左右，加上 RAG、意图识别、复核等环节，总 token 消耗可能是 1.5 万到 2 万。如果这个 Agent 一天服务 1 万个用户，每天就是 1 亿到 2 亿 token 级别的推理量。

这还只是模型层面的消耗。Agent 的算力底座还要覆盖 embedding 服务、rerank 服务、向量数据库查询、镜像沙盒启动、多模态转码等等。算力竞争进入下半场，本质上拼的是单位任务的处理成本和并发韧性，过去那种“买几台高配机器就够了”的思维早就过时了。

1.3 传统单体式算力架构，喂不饱 Agent

在 Agent 出现之前，大模型应用基本是“请求-响应”模式：一个请求进来，模型算完，放回结果，连接结束。这种模式下，算力资源可以通过传统的负载均衡、水平扩容来解决，架构相对直接。

Agent 的出现打破了这种稳态。它是一个有状态、自循环的执行体，可能同时要处理多路任务，需要长期记忆、工具状态、上下文缓存。这意味着：

• 请求不是一次性的，而是长连接、多轮内部决策
• 同一个 Agent 实例可能在多个对话间保留状态
• 推理服务需要支持动态 batch、注意力缓存、上下文复用
• 单一加速卡已经不够，需要 CPU、GPU、NPU 混合编排

我见过一个团队在 Agent 原型阶段跑得很顺，一上线并发 50 就开始崩溃，原因就是他们的架构还是单体服务的思路：一个 Agent 实例一个线程，一个线程串行调用模型，根本没有考虑任务队列和并发隔离。后来推翻重做，引入了异步任务队列、模型路由和异构算力调度，才算把并发扛住。这个案例很典型：Agent 的底座，注定不是把服务器数量翻倍就能解决的，它需要的是体系层面的重构。

2. 算明白 Agent 的“新底座”，到底包括什么

2.1 推理调度：异构算力的一体化编排

Agent 的场景里，模型调用频率高、但单次计算量相对分散，而且不同环节对模型的要求差异巨大。意图识别用 7B 小模型就够了，复杂推理可能要 70B 甚至更大参数的模型，某些端侧场景甚至只能跑量化后的轻量模型。

一个合格的 Agent 底座，要有统一的推理调度层。这里说的不是简单的负载均衡，而是按任务复杂度做动态路由。我团队里面的经验是：把模型抽象成“算子”，上层 Agent 引擎按需调度，底层对接不同芯片的推理引擎。业务方不用管具体跑在哪张卡上，只需要声明任务对时延、成本、精度的要求。

异构算力编排最大的优点，是能根据每个模型调用的特点选择更合适的硬件。比如 embedding、rerank 这类密集型计算，CPU 和小算力卡就能扛；长上下文生成，需要大显存；工具调用的函数判断，中等模型就能处理。把这些算力揉在一起，按优先级和成本统一分配，是底座的核心能力之一。

2.2 上下文与记忆：不应只是提示词里的拼接

Agent 的记忆问题，很多人只停留在“把历史聊天记录拼进 prompt”的阶段。这种做法在小规模场景下还好，一旦上下文变长，token 消耗和首字延迟都会迅速恶化。真正的新底座，必须把记忆当成独立基础设施来建。

我分为两层来看。工作记忆：当前任务循环中需要频繁读取的中间状态，建议放在内存级缓存或者 KV Cache 管理系统里，而不是全部塞进模型上下文。长期记忆：跨会话的偏好、事实、历史决策，需要向量化后进入向量库，按相关性做检索召回。

这里有个常见误区：为了“记住更多”，一味扩大上下文窗口，结果成本直线上升，速度直线下降。合理的做法是把记忆分层次：频繁访问的放缓存，不频繁的放向量库，真正核心的才拼进上下文。很多团队在 Agent 记忆的架构设计上，踩了不少坑，归根结底是没有把“记忆”当作一层独立服务来做。

2.3 工具调用与外部系统的安全互操作

Agent 的能力上限，很大程度上取决于它能调用多少外部工具。查天气、调数据库、发邮件、操作工单系统，这些能力不是模型自带，而是靠一套工具集成机制暴露给 Agent 的。

但这会带来强烈的安全问题。我在生产环境里见过的最危险的一次，是 Agent 因为 prompt 注入，把内部 CRM 系统的数据查询条件改掉了，险些造成数据越权。后来我们从头搭建了一套工具网关，所有工具调用都必须经过三层检查：身份鉴权、参数模式校验、结果脱敏。任何不符合预定义 schema 的调用，直接拦截。

所以，Agent 底座里的工具调用层，不只是简单的 HTTP 请求封装。它要包含协议适配、权限控制、审计日志、超时熔断、失败重试等多种能力。一个 Agent 平台如果缺少这一层，哪怕模型再强，也不敢真正放到业务环境里跑。

2.4 可观测性、评测与安全护栏

Agent 的不可预测性远超传统软件。同一个输入，可能走完全不同的内部路径，AI 的每一步决策都需要被追踪和复盘。传统监控只记录接口时延和错误码，完全不够用。

新的底座要提供 LLM 调用链追踪，能看到每一次工具调用的输入输出、token 消耗、延迟分布。还要有评测闭环，离线准备一批覆盖典型场景的评测集，每次模型或策略调整，都要跑一遍评测，看任务完成率、工具调用准确率是否下降。

安全护栏更是个大工程。我常用的方法包括：输出内容合规检查、敏感信息脱敏、危险工具调用二次确认。可悲的是，很多团队直到出事了才想起来补这一层，其实一开始就应该把护栏嵌入底座，而不是后续打补丁。

2.5 Agent 运行时：有状态任务的中心枢纽

Agent 运行的实质，是一长串不确定的异步步骤的有序执行。它可能需要等待人工审批、需要跨服务轮询、需要支持任务暂停和恢复。这些需求已经超出了普通 Web 服务的能力范围。

所以 Agent 新底座里，一定要有专门设计的 Agent Runtime，提供任务队列、状态存储、事件驱动、断点续跑等能力。我之前在一个审批流 Agent 里，就因为没有状态持久化，服务一重启所有进行中的任务全部丢失，用户审批到一半，流程直接断了。后来引入了任务持久化和事件总线，才解决。

把 Agent Runtime 理解成“操作系统内核”最准确：它管理进程（Agent 实例）、管理文件（记忆）、管理网络（工具调用）、管理异常（重试与恢复）。没有这个内核，Agent 就只能停留在 Demo 阶段。

2.6 开发协同与评测迭代：底座要能“养”Agent

前面的底层能力再强，如果开发者上手困难，也没法推广。好的底座，还要给开发提供舒适的上层工具：Agent 编排框架、调试界面、技能注册中心、版本发布机制。

这里我想说一句大实话：主流 Agent 框架的抽象层次不一样，千万不要一上来就全家桶。我们在生产环境最终没有完全依赖框架，而是走“轻量编排 + 深度自研”的路线。框架负责把工具注册、任务循环、错误处理标准化，核心业务逻辑全部自己控制。这样一年做下来，稳定性比纯靠框架高了不少。

新底座还应该具备拥挤的安全能力，例如对提示注入的防护、对 Agent 生成代码的沙盒隔离、对敏感操作的综合溯源。安全不应该是某一个环节的事，而应该融入开发、测试、上线的整个链路。

3. 从华为全联接大会 2026 看底座方向的三点前瞻

3.1 议题从“模型能力”转移到“推理效率”

华为全联接大会一向是这个行业的风向标之一。从 2026 年已经能看到的信息和行业节奏来看，我的判断是，大会的核心主线会从单纯的模型能力展示，转向推理效率与落地形态的比拼。

为什么要这么说？因为 Agent 是一个吃推理算力的大户，而推理算力恰恰是当前成本焦虑最重的环节。一个完整的 Agent 任务，涉及多次模型调用和多轮工具往返，如果推理效率提升一倍，Agent 的整体成本和时延可能下降 40% 到 60%。这比单纯把模型参数做大更有商业价值。可预见的是，围绕盘古系列模型的推理优化、模型压缩和算子融合，以及针对长上下文的 KV Cache 压缩，会成为重头戏。

3.2 一个以 Agent 为中心的跨端算力底座

华为的生态优势在于云端、边缘和端侧都有完整的硬件布局。2026 年的底座讨论，大概率不会再像过去那样把云端算力和端侧算力割裂开来说，而是强调一体化协同调度。

我的理解是，Agent 会出现在手机、平板、车机、摄像头等各种终端上，但终端算力有限，不可能跑完整的大模型。所以底座需要做“端侧感知 + 云端推理 + 边侧缓存”的分布式协同。比如一个视觉 Agent，在端侧做画面捕捉和轻量目标检测，把关键帧上传到云侧做深层理解，再结合用户画像做回复生成，最后把结果缓存到边缘节点，降低重复请求。

这个思路特别符合 Agent 的商业场景。Agent 是面向高频交互的，不可能每个请求都穿到云端再绕回来。跨端算力调度，会成为新一代 Agent 底座的基本功。

3.3 生态层面的“Agent Runtime”化

在更宏观的层面，我看好整个产业从“操作系统适配 App”向“平台承载 Agent”迁移。华为全联接大会展示的不只是芯片和服务器，更是把连接能力、应用生态、开发者工具串起来的工作流。

具体来说，就是给 Agent 提供一套标准的运行环境：设备连接协议、工具开放 API、状态同步机制、内容安全策略，都成为底座的一部分。Agent 不再是开发者自己拼凑的东西，而是平台上层原生的业务形态。

对开发者而言，这种趋势意味着选用底座时，要重点关注它的生态开放程度和工具接入标准化程度。底座不是选最贵的，而是选最适合 Agent 长期演进的。

4. 实操：给你的 Agent 搭一个真实可用的底座

4.1 先算清并发和成本账，再定技术选型

很多团队搭建 Agent 底座，第一步就错了：他们先买卡、选框架，然后才面对成本失控的尴尬。正确做法是先用业务指标倒推算力需求。

公式可以简化成下面这个样子。

单任务平均 Token 消耗 = 主模型输入 + 主模型输出 + 工具参数解析 + 重试损耗 单实例峰值并发 = 日活用户 × 每日人均任务数 × 峰值系数 / 单任务平均耗时 日算力成本 = 单任务平均 Token 消耗 × 日任务总量 × 单 Token 成本

我一般会把这个公式做成脚本，放在需求评审阶段跑一遍。它给出的数字可能不非常精确，但能帮团队判断：是买 GPU 服务器，还是直接调用现成的模型 API，还是混合部署。

实际项目里，我见过不少团队把成本压不住的 point，归结为“模型太贵”，其实是没有做好缓存和数据压缩。先把账算明白，整个底座架构都清晰了。

4.2 编排层选型要有所克制

到了 Agent 编排这块，热门的框架比如 LangChain、LangGraph、CrewAI、AutoGen，各有拥趸。我的建议是：先跑通最简单的版本，再按需引入框架，不要一开始就铺开。

给出一个比较通用的评估维度，大家可以参考。

我自己现在的主力路线是：用 LangGraph 做流程编排的原型验证，生产环境逐步替换为自研的轻量状态机。不是框架不好，而是生产环境要求的可控粒度太高，框架通用抽象往往不够用。

4.3 记忆和缓存先行，别只盯着模型

搭底座初期，容易忽略记忆和缓存基础设施，等上线之后才发现成本结构不合理。这块我建议一开始就规划好：

• 用 Redis 或类似的 KV 存储做短期上下文缓存
• 用向量库做长期记忆检索
• 对高频相似请求做语义缓存，命中后直接返回旧答案
• 对 Agent 的中间推理结果做持久化，方便任务断点续跑

语义缓存是个我很想强调的点。在很多知识问答场景里，超过 30% 的请求和过往问题语义接近，命中语义缓存可以直接省掉一轮模型推理。底座里加上这个能力，对成本和延迟的改善非常可观。

4.4 上线前，把评测集做成“库存”，而不是“补测”

Agent 上线最怕什么？最怕线上出现问题，你无法判断是模型问题、工具问题还是上下文问题。所以评测集必须提前沉淀。

我的做法是，把所有线上真实的成功和失败案例，按场景归类成评测集，每次更新模型镜像或 Agent 策略，都全量跑一遍回归。评测指标不建议只有“答案对不对”，还要看：

• 工具调用准确率：是否用了正确的工具、传了正确的参数
• 任务完成率：是否完成用户的核心目标
• 无效步数：是否出现无意义的循环调用
• 成本超支率：是否超过单任务预算

这套评测闭环建起来之后，Agent 的迭代速度才能提上来。它和代码 CI 一样，是底座的一部分，不是可选项。

5. 踩坑记录：Agent 底座常见问题速查

5.1 并发问题，先把“任务”和“请求”分开

写 Agent 服务时，最容易犯的一个错误，是把 Agent 的“一次完整任务”当成一个普通 HTTP 请求来处理。Agent 的完整执行可能持续几十秒甚至几分钟，如果用同步线程占住资源，几千并发就能把服务打崩。

我从之前的经历里学到的策略是：外部请求只负责“提交任务”和“查询状态”，背后用任务队列驱动 Agent 执行。任务有独立的生命周期、超时机制和重试策略，前端通过事件或轮询获取结果。这套模式下，并发能力和后端线程数彻底解耦，扩容只用加 worker 节点，比较清爽。

5.2 上下文窗口不是越大越好

很多 Agent 在长时间对话后性能下降，大家第一反应是“上下文不够，再大一点”。但实际问题是，上下文越大，首字延迟越高，成本越贵，而且模型注意力容易被噪音干扰。

不要试图用“大窗口”解决所有问题。更靠谱的做法是给 Agent 做信息筛选，把对话历史变成摘要，或者把关键信息抽出来存进记忆库，只把当前任务最相关的部分送进模型。这件事我踩过好多次坑之后才想明白：底座的核心价值不是让模型什么都记得，而是让模型记得该记得的东西。

5.3 安全措施要在第一天就设计

这里分享一个比较惨痛的案例。我们曾经在某次分享会上公开过 Agent 生成报告的功能，结果有用户诱导 Agent 读取一个预设的恶意文件，差点把内部 API Key 泄露出来。从那以后，所有工具调用的入参都强制走 schema 校验，输出走敏感信息过滤，高危工具默认二次确认。

安全这事，真的不能等出事了再补。Agent 越聪明，权限越要收得紧。这是底座设计里我认为最不该省钱的地方。

5.4 成本控制，落到代码而不是口头

成本失控这个问题，几乎每家做 Agent 的团队都经历过。我刚带项目的时候，喜欢事后看账单，然后被财务骂一顿。后来我把成本控制落到了代码层：

• 每个任务设置 token 预算，超了就结束任务或转人工
• 模型调用前先查语义缓存
• 大规模任务走批处理，避开实时高峰计费
• 按用户维度做配额，防止单用户消耗过多

把这四件事变成自动化策略后，账单基本稳定在预测范围内。算力竞争进入下半场，不能只会买算力，更会“用”算力，这可是实打实的竞争力。

我个人在实际落地中的体会是，Agent 的新底座，本质上是把过去几年大模型积累的认知，沉淀成一套可运营的业务基础设施。模型会快速迭代，框架会不断变化，但底座层面的工程量，会长期构成一个团队的核心壁垒。别总盯着谁家的模型又强了一点，把任务跑稳、把成本算清、把安全守住，比什么都实在。