HCC 2026 的议程方向出来后我把几个老朋友拉了个线上会大家口径几乎一致算力竞争真真正正进入了下半场。去年大家关心的还是谁家预训练集群堆了多少卡跑分又高了多少今年话题已经变成了一件事——Agent 这类新应用形态到底需要一个什么样的底座才能跑得稳、扛得住并发、算得过来成本。作为一个一直和模型部署、算力调度打交道的人我把这个转变看得很重。大模型的能力从“能不能训出来”进入“好不好用、用不用得起”的阶段技术上最大的变量不是参数规模而是 Agent 带来的消耗模型变化和工程复杂度的爆炸。这篇文章我结合自己搭建 Agent 平台的经验从华为全联接大会 2026 释放的方向切入聊聊我眼中的 Agent 新底座应该长什么样以及团队从零开始应该怎么落。1. 算力竞争进入下半场风向为什么变了1.1 上半场比的是马力下半场比的是扭矩如果把训练大模型比作造赛车上半场大家比的是发动机极限功率堆卡、堆互联、堆显存把预训练任务在更短时间内跑完。这个阶段算力竞争的核心指标是总算力规模和效率说白了就是“马力”。但到了实际业务部署阶段情况完全不同。一台赛车不可能一直全油门跑它要过弯、要走走停停、要控制油耗。Agent 就是这辆需要精细化操控的车。它不会一次消费一个大任务而是在一个很长的循环里反复调用模型先做意图识别再拆解任务然后调工具、读知识库、校验结果、生成回复中间还可能失败重试。这种模式对算力的要求不是“峰值多高”而是“在复杂路况下的扭矩输出是否稳定”。我自己搭建过客服 Agent体感特别明显。一次简单的用户咨询看起来只是聊天但后台可能要经历 4 到 7 次模型调用token 消耗轻松破万。一个线上对话系统如果同时有 500 个用户在线每个用户平均 1 分钟产生 3 次交互背后就是每分钟上千次的推理请求。传统那种“一台机器扛一个大请求”的思路在这个场景下完全不够用。上半场可以不顾一切冲极限下半场必须学会精打细算。1.2 被 Agent 解构后的算力消耗模型很多团队对 Agent 的成本预估往往还停留在“一次对话 一次模型调用”的思维上结果项目上线后账单吓人一跳。我举一个实际项目里的估算例子。一个行业问答 Agent任务链条大概是根据用户问题做一次意图识别小模型几百 token命中知识库需求做一次 embedding 检索几百 token把检索结果拼进上下文交给主模型做生成可能 3000 到 8000 token生成结果后做一次合规检查小模型再跑一遍如果结果不达标还要重试一轮这样一整套下来单个用户单次会话的主模型调用至少在 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各有拥趸。我的建议是先跑通最简单的版本再按需引入框架不要一开始就铺开。给出一个比较通用的评估维度大家可以参考。框架适合场景需要注意的风险LangChain / LangGraph快速原型、标准工具链组装抽象层级多排错困难CrewAI多角色协作型 Agent角色定义过重灵活性不足AutoGen多智能体对话与编程任务调用链复杂不适合简单业务自研轻量编排生产环境长期稳定运行开发成本高需沉淀组件我自己现在的主力路线是用 LangGraph 做流程编排的原型验证生产环境逐步替换为自研的轻量状态机。不是框架不好而是生产环境要求的可控粒度太高框架通用抽象往往不够用。4.3 记忆和缓存先行别只盯着模型搭底座初期容易忽略记忆和缓存基础设施等上线之后才发现成本结构不合理。这块我建议一开始就规划好用 Redis 或类似的 KV 存储做短期上下文缓存用向量库做长期记忆检索对高频相似请求做语义缓存命中后直接返回旧答案对 Agent 的中间推理结果做持久化方便任务断点续跑语义缓存是个我很想强调的点。在很多知识问答场景里超过 30% 的请求和过往问题语义接近命中语义缓存可以直接省掉一轮模型推理。底座里加上这个能力对成本和延迟的改善非常可观。4.4 上线前把评测集做成“库存”而不是“补测”Agent 上线最怕什么最怕线上出现问题你无法判断是模型问题、工具问题还是上下文问题。所以评测集必须提前沉淀。我的做法是把所有线上真实的成功和失败案例按场景归类成评测集每次更新模型镜像或 Agent 策略都全量跑一遍回归。评测指标不建议只有“答案对不对”还要看工具调用准确率是否用了正确的工具、传了正确的参数任务完成率是否完成用户的核心目标无效步数是否出现无意义的循环调用成本超支率是否超过单任务预算这套评测闭环建起来之后Agent 的迭代速度才能提上来。它和代码 CI 一样是底座的一部分不是可选项。5. 踩坑记录Agent 底座常见问题速查典型表现直接原因常规解法我的额外提醒并发一高就超时Agent 调用模型是长耗时操作却用了同步等待引入异步任务队列和事件驱动加机器只是治标要先把任务调度做对上下文越长越卡历史消息全塞进大模型 prompt做分层记忆和上下文缓存第一优先是省 token其次才是保准确率RAG 召不回内容embedding 模型和检索策略不匹配调整分块长度增加 rerank 环节评测集里必须包含检索质量用例成本一天飙到几万没有单任务预算控制给每个任务设置 Token 上限和模型路由策略落到代码里做熔断不能只靠人工盯Agent 调用危险工具prompt 注入或工具权限过大工具网关统一鉴权、参数校验和脱敏最小权限原则默认拒绝高敏操作服务重启任务全丢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 的新底座本质上是把过去几年大模型积累的认知沉淀成一套可运营的业务基础设施。模型会快速迭代框架会不断变化但底座层面的工程量会长期构成一个团队的核心壁垒。别总盯着谁家的模型又强了一点把任务跑稳、把成本算清、把安全守住比什么都实在。