企业官网建设流程全解析

1. 从"ax"这个标题说起：一个被低估的运行时缩写

第一次看到"ax"这个标题，绝大多数人的反应是懵的——两个字母，没有正文，没有关键词，没有摘要，只有一串看起来八竿子打不着的热搜词。但如果你把热搜词里那些噪音过滤掉，剩下的东西其实指向非常明确：agentic、orchestration、runtime、Kubernetes。这四个词凑在一起，指向的是一个当下基础设施领域正在快速成型的方向——面向智能体（Agent）的编排运行时。

"ax"在这里我倾向于把它理解为一个面向 Agent 编排场景的运行时抽象层的代号。为什么这么说？因为热搜词里同时出现了agentic rag、karmada 正式毕业、agentic cloud这些信号，它们共同描述的是一个趋势：传统的容器编排（Kubernetes）解决的是"无状态/有状态服务怎么调度、怎么扩缩容"的问题，而 Agent 场景引入了一类全新的负载——它是有状态的、长生命周期的、需要工具调用能力的、需要记忆和上下文管理的。这类负载用 Deployment + Service 那套模型去套，会非常别扭。

所以这篇东西我想聊的不是某个具体产品的安装教程，而是当"Agent 运行时"这个概念落到 Kubernetes 上时，到底要解决哪些工程问题，以及一个叫 ax 的编排层应该长什么样。适合谁看？如果你已经在用 K8s 跑业务，现在团队开始往 Agent 方向做东西，发现 Pod 里塞个 Python 进程跑 Agent 越来越难管，那这篇就是写给你的。如果你只是听说过 agentic 这个词但没实际跑过，也能从里面拿到一套可落地的思路。

需要先说明一点：由于原始输入里项目正文和关键词都是空的，下面涉及的具体实现细节，是我基于当前 Agent 编排这个领域的常见工程实践做的合理补全，不是对某个特定产品的逆向。我会在关键地方标注哪些是通用做法、哪些是需要你按自己环境调整的。

2. Agent 负载和普通微服务到底差在哪

2.1 生命周期模型：从"请求-响应"到"会话-持续"

普通微服务的生命周期模型非常干净：进程起来，监听端口，收到请求，处理，返回，进程一直在那儿待命。K8s 的探针机制（liveness/readiness）就是为这个模型设计的——readiness 决定要不要把流量切进来，liveness 决定挂了要不要重启。

Agent 完全不是这个逻辑。一个 Agent 实例往往对应一个会话（session），这个会话可能持续几分钟，也可能持续几小时甚至几天。它中间会调用外部工具、会写记忆、会等待人工确认、会挂起等一个异步事件回来。你没法用"端口通不通"来判断它健不健康，因为一个正在等用户输入的 Agent，端口是通的，但它其实处于"挂起"状态，这时候你把它重启了，整个会话上下文就丢了。

这就是为什么热搜里会出现agentic orchestration这个词——编排层要理解的不再是"容器活着没"，而是"这个会话处于什么阶段"。我在实际项目里踩过最狠的一个坑，就是拿默认的 liveness probe 去探一个 Agent 容器，结果 Agent 在等一个耗时 90 秒的工具调用，探针 30 秒超时直接把它杀了，会话状态全丢。后来改成基于会话状态上报的健康检查才解决。

2.2 状态归属：状态到底该放哪

普通微服务的状态基本都外置了——数据库、Redis、对象存储。容器本身是无状态的，随便杀随便起。Agent 不行，Agent 的"记忆"和"上下文"是它之所以是它的核心。这里有个关键的设计决策：状态是放在 Agent 进程内存里，还是外置到运行时层？

放内存里，简单，但 Pod 一重启就没了，而且没法做水平扩展。外置到运行时层，复杂，但换来的是可迁移、可恢复、可观测。ax 这类编排层的核心价值，我认为就在这个"状态外置"上——它把会话状态、工具调用记录、记忆索引这些东西从 Agent 进程里抽出来，交给运行时统一管理，Agent 进程本身变成可以随时替换的"执行器"。

这个思路和当年把 session 从 Tomcat 内存里挪到 Redis 是一模一样的演进路径。区别在于 Agent 的状态结构更复杂，不是简单的 key-value，而是带时序、带引用、带向量索引的复合结构。

2.3 工具调用：网络边界被打破了

普通微服务的网络边界很清晰：我这个服务只暴露一个 API，只调用下游那几个已知的服务。Agent 不一样，Agent 会动态调用工具，工具可能是内部的 HTTP 服务，可能是某个 CLI，可能是数据库查询，可能是外部 API。这意味着出站流量的目标是不确定的。

在 K8s 里，NetworkPolicy 默认是白名单模型，你得提前知道要放通哪些目标。Agent 场景下这个前提不成立。所以 ax 这类运行时通常要在编排层做一层工具代理（tool proxy），Agent 不直接出网，而是通过运行时提供的工具网关去调用，网关负责鉴权、限流、审计、重试。这样 NetworkPolicy 只需要放通到网关这一条路，安全边界重新变得可控。

2.4 资源画像：突发性和长尾

普通微服务的资源画像相对平稳，CPU 和内存的 request/limit 好估。Agent 的资源消耗是脉冲式的：大部分时间在等 LLM 返回或者等工具结果，CPU 几乎为零；但一旦开始处理上下文，尤其是做 RAG 检索和重排的时候，内存和 CPU 会瞬间冲高。

这就导致用 HPA 按 CPU 扩缩容基本失效——你按平均 CPU 扩容，它永远不触发；你按峰值扩容，平时又浪费得离谱。ax 这类运行时一般会引入基于队列深度和会话等待时长的扩缩容信号，而不是纯看资源指标。这个后面第 4 节会展开讲。

3. 把 Agent 塞进 Kubernetes：哪些原生能力能直接用，哪些必须绕开

3.1 能直接复用的：调度、隔离、镜像分发

先说好消息。K8s 有一大堆能力是可以直接拿来用的，不用重新造轮子：

• 调度器：Agent 执行器本质还是容器，nodeSelector、affinity、taint/toleration 这套调度语义完全适用。比如你想把需要 GPU 的推理型 Agent 调度到特定节点池，直接用 nodeAffinity 就行。
• 资源隔离：cgroup 层面的 CPU/内存隔离对 Agent 一样有效，防止某个失控的 Agent 把整台机器吃满。
• 镜像分发：Agent 执行器的镜像管理、版本管理、灰度发布，用现有的镜像仓库和 Deployment 滚动更新机制就够了。
• 配置与密钥：ConfigMap 和 Secret 挂载这套，管理 Agent 的模型端点、API Key 完全够用。

我在实际项目里的做法是：Agent 执行器本身就是一个标准的 Deployment，只不过它的副本数不由 HPA 控制，而是由 ax 运行时的会话调度器控制。这样既复用了 K8s 的容器管理能力，又不会被原生扩缩容逻辑带偏。

3.2 必须绕开的：Service 负载均衡和 readiness

前面提过，Agent 是有会话粘性的。K8s 的 Service 默认是随机负载均衡，一个会话的多次请求可能被分发到不同 Pod，上下文就对不上了。解决办法有两个：

一是会话亲和性（session affinity），Service 层面配sessionAffinity: ClientIP，但这个粒度太粗，同一个客户端的不同会话会被粘到同一个 Pod，反而造成不均。更靠谱的是在 ax 编排层做基于会话 ID 的路由，Agent 执行器不直接暴露 Service，而是通过运行时的路由层转发，路由层根据会话 ID 查表找到对应的执行器实例。

二是readiness 探针要重写。默认的 TCP 探针或者 HTTP 探针在这里都不合适，需要 Agent 执行器主动向运行时上报自己的状态：空闲、忙碌、挂起、异常。运行时根据这个状态决定要不要给它派新会话。这本质上是一个自定义的调度协议，而不是 K8s 原生的健康检查。

3.3 存储：会话状态的持久化选型

会话状态存哪，是个绕不开的问题。我见过几种做法，各有取舍：

ax 这类运行时通常采用分层存储：热状态放 Redis，温状态落关系库，冷状态归档到对象存储。会话活跃时全在 Redis，会话挂起超过阈值就下沉到关系库，超过更长时间就归档。这个分层策略的阈值需要根据你的会话时长分布来调，没有万能值。

提示：会话状态里如果有向量索引，别直接塞 Redis。向量检索有专门的存储（比如各类向量库），Redis 只存指向向量库的引用 ID。我见过把 embedding 直接存 Redis 的，几百万条之后内存直接爆掉。

3.4 网络：工具网关的设计

前面提到工具调用要经过网关。这个网关的设计有几个要点：

• 鉴权：Agent 调用工具时带的是运行时分发的短期凭证，不是长期 API Key。凭证和会话绑定，会话结束凭证失效。
• 限流：按会话、按工具、按目标三个维度限流。防止某个 Agent 疯狂调用某个工具把下游打挂。
• 审计：每次工具调用都记录：哪个会话、调了什么工具、参数是什么、返回什么、耗时多少。这个日志在排查 Agent 行为异常时是救命稻草。
• 重试与熔断：工具调用失败要区分是"可重试"还是"不可重试"。网络超时可重试，参数错误不可重试。熔断按工具维度做，某个工具连续失败就暂时摘掉。

这套东西听起来像 API Gateway，确实可以基于现有的网关产品改，但凭证模型要重新设计，因为 Agent 的调用是代表某个会话发起的，不是代表某个用户。这个区别很关键，直接影响审计和权限模型。

4. 编排层的核心：会话调度器怎么设计

4.1 调度信号：别只看 CPU

会话调度器的输入信号，决定了整个系统的效率。我总结下来，有效的信号有这么几类：

• 待调度会话队列深度：有多少会话在等执行器。这是最直接的扩容信号。
• 执行器空闲率：当前有多少执行器处于空闲状态。空闲率持续为 0 说明该扩容，持续很高说明该缩容。
• 会话等待时长 P95：用户等多久才能拿到执行器。这个指标直接对应体验。
• 单会话资源画像：不同类型的 Agent 资源需求差异很大，调度时要匹配。

纯看 CPU 的问题是，Agent 大部分时间在等 IO（等 LLM、等工具），CPU 利用率天然就低。你按 CPU 扩容，永远扩不起来。我实测过一个场景：20 个执行器，CPU 平均利用率 8%，但会话队列已经排到 50 个，用户等待超过 2 分钟。这时候 CPU 指标完全失灵。

4.2 调度策略：优先级 + 抢占

会话之间是有优先级差异的。交互式会话（用户在等）优先级高，后台批处理会话优先级低。调度器要支持：

1. 优先级队列：高优先级会话先分配执行器。
2. 抢占：执行器不够时，低优先级的挂起会话可以被驱逐，腾出资源给高优先级。被驱逐的会话状态已经外置，重新调度后能恢复。
3. 配额：按租户/团队限制并发会话数，防止一个团队把资源吃光。

抢占这个能力是 ax 这类运行时相比原生 K8s 最大的增量。K8s 的抢占是 Pod 级别的，粒度太粗，而且抢占的是整个 Pod，会丢掉 Pod 里所有会话。ax 的抢占是会话级别的，只驱逐特定会话，其他会话不受影响。

4.3 执行器池化：冷启动怎么解

Agent 执行器冷启动是个大问题。一个执行器镜像可能好几个 G，拉镜像 + 启动进程 + 加载模型，几十秒起步。用户等不起。

常见的解法是预热池：维持一定数量的空闲执行器，随时待命。新会话来了直接从池里拿，不用等启动。池子大小根据流量波动来调，高峰期大一点，低谷期小一点。

但预热池有个成本问题：空闲执行器也占资源。折中方案是分级预热：热池（完全就绪，秒级响应）保持小规模，温池（进程已起但未加载模型）保持中等规模，冷池（只有镜像缓存）按需拉起。会话来了先看热池，没有就看温池，再没有才走冷启动。

这个分级策略的阈值需要根据你的流量特征调。我的经验是热池保持在 P50 并发量的 1.2 倍左右，温池保持在 P99 并发量的 0.5 倍左右，剩下的走冷启动。

4.4 故障恢复：会话怎么"续命"

执行器挂了，会话怎么办？这是 ax 运行时必须回答的问题。核心思路是状态外置 + 检查点：

• 会话的每一步关键操作（工具调用完成、LLM 返回、记忆写入）都往运行时上报，运行时持久化。
• 执行器挂了，运行时根据最后检查点重建会话，调度到新执行器。
• 重建时要注意幂等性：如果挂的时候正在执行一个工具调用，重建后这个调用要不要重发？取决于工具是否幂等。非幂等工具需要运行时记录"已发起未确认"的状态，重建后先查询实际结果再决定。

这套机制实现起来不简单，但它是 Agent 运行时区别于普通容器编排的核心价值。没有它，Agent 就是个脆弱的玩具。

5. 多集群视角：为什么热搜里会出现 Karmada

热搜词里有一条karmada 正式毕业，这不是巧合。Agent 编排和 Karmada 这类多集群编排框架的交集，在于Agent 的算力需求是地理分布和弹性波动的。

5.1 单集群的天花板

单集群跑 Agent 有几个硬约束：

• GPU 资源有限：一个集群的 GPU 卡数是有上限的，Agent 推理需求增长很快，单集群很快就不够。
• 故障域集中：单集群挂了，所有 Agent 全挂。虽然 K8s 本身高可用，但集群级别的故障（比如控制面被误操作）还是会发生。
• 成本优化空间小：不同云厂商、不同区域的 GPU 价格差异很大，单集群没法利用这个差异。

5.2 多集群编排要解决什么

Karmada 这类框架解决的是"把工作负载分发到多个集群"的问题。对 Agent 场景来说，它要额外解决：

• 会话的跨集群迁移：会话状态外置之后，理论上可以在集群 A 挂起、在集群 B 恢复。但网络延迟和状态同步是挑战。
• 全局调度：根据各集群的实时负载和成本，决定新会话调度到哪个集群。
• 故障转移：集群 A 不可用，会话自动在集群 B 重建。

ax 运行时如果要做多集群，和 Karmada 的集成点主要在调度决策和状态同步这两层。Karmada 负责把执行器 Deployment 分发到各集群，ax 负责决定会话去哪个集群的执行器。

5.3 实际落地的坑

多集群听起来美好，实际落地有几个坑：

• 状态同步延迟：会话状态在集群 A 写入，集群 B 读取，中间有延迟。如果会话迁移时状态还没同步完，会读到旧状态。解法是迁移前做一次强制同步。
• 网络分区：集群之间网络断了，会话怎么办？通常策略是"就地继续"，不迁移，等网络恢复再同步。
• 成本核算：多集群之后，成本归属变复杂。需要给每个会话打上集群标签，才能算清楚账。

我的建议是：别一上来就搞多集群。单集群先把会话调度、状态外置、故障恢复这套跑通，等真的遇到单集群天花板了再上多集群。多集群的复杂度是单集群的好几倍，过早引入会拖慢迭代。

6. 可观测性：Agent 运行时怎么"看得见"

6.1 传统三件套的局限

Metrics、Logging、Tracing 这套在 Agent 场景下都有局限：

• Metrics：传统的 QPS、延迟、错误率还是有用，但不够。你需要的是"会话维度的指标"——会话时长分布、会话成功率、会话中断率、工具调用成功率。
• Logging：Agent 的日志量巨大，一次会话可能产生几万行日志。全量收集成本高，需要采样和分级。
• Tracing：Agent 的调用链是动态的，工具调用是运行时决定的，传统的静态埋点不够用。需要运行时自动注入 trace context。

6.2 会话级别的可观测性

ax 运行时应该提供会话视角的可观测性。也就是说，你能查一个具体会话的完整生命周期：

• 什么时候创建，什么时候结束
• 中间经历了哪些状态转换
• 调用了哪些工具，每次调用的输入输出
• 消耗了多少 token，多少 GPU 时间
• 如果失败了，失败在哪一步

这个能力对排查问题极其重要。我遇到过 Agent 行为异常的情况，最后就是靠会话级别的 trace 定位到是某个工具返回了格式不对的数据，导致 Agent 解析失败进入死循环。

6.3 成本可观测性

Agent 的成本结构比普通服务复杂：有 GPU 成本、有 LLM API 成本、有工具调用成本、有存储成本。这些成本要能归集到会话、归集到租户。

做法是在会话创建时打上成本标签，每次产生成本的操作都往这个标签上累加。最后按租户、按团队、按项目出成本报表。这个能力在 Agent 大规模铺开之后是刚需，因为 LLM API 的账单很容易失控。

7. 落地路线：从零到一怎么走

7.1 阶段一：单机跑通

别急着上 K8s。先在一台机器上把 Agent 执行器、状态存储、工具网关这套跑通。这个阶段的目标是验证核心逻辑：会话能不能创建、状态能不能持久化、工具能不能调用、挂了能不能恢复。

这个阶段用 Docker Compose 就够了，别过度设计。

7.2 阶段二：单集群 K8s 化

把执行器容器化，用 Deployment 管理，状态存储用集群内的 Redis 和 PG。这个阶段要解决：

• 执行器的镜像构建和分发
• 会话调度器的实现（可以先简单点，按队列深度扩容）
• 工具网关的部署
• 基础的可观测性

这个阶段最容易踩的坑是探针配置，前面说过，别用默认探针。

7.3 阶段三：调度优化

引入优先级队列、抢占、预热池。这个阶段的目标是提升资源利用率和用户体验。需要大量的压测和调参。

7.4 阶段四：多集群

等单集群真的不够用了，再考虑多集群。这时候你已经有了足够的运维经验和监控数据，知道瓶颈在哪，多集群的决策会更有依据。

8. 几个我踩过的坑和对应的解法

8.1 坑一：会话状态序列化格式选错

一开始我用 JSON 存会话状态，简单直观。但会话状态里有大量嵌套结构和二进制数据（比如向量），JSON 序列化又慢又占空间。后来换成 MessagePack，体积小了 40%，序列化速度快了一倍多。

选型建议：如果状态结构简单，JSON 够用；如果有二进制或大量嵌套，考虑 MessagePack 或 Protobuf。

8.2 坑二：工具调用没有超时

早期版本工具调用没设超时，某个工具挂了导致 Agent 一直等，执行器被占住，新会话进不来，整个系统雪崩。后来强制所有工具调用必须有超时，超时后走降级逻辑。

8.3 坑三：会话 ID 生成有碰撞

用时间戳生成会话 ID，高并发下出现碰撞，两个会话共用了同一个状态，数据串了。后来换成 UUID v4，问题消失。这个坑很低级，但确实发生过。

8.4 坑四：忘记限制单会话资源

某个 Agent 进入死循环，疯狂调用工具，把整个执行器的 CPU 吃满，影响了同执行器上的其他会话。后来给每个会话加了资源配额，超了直接挂起。

8.5 坑五：状态存储没做容量规划

会话状态越积越多，Redis 内存爆了，触发淘汰策略，把活跃会话的状态也淘汰了。后来做了分层存储，冷会话下沉到关系库，Redis 只留热数据。

9. 关于 ax 这个名字和它代表的方向

回到标题。"ax"这两个字母本身没有太多信息量，但它背后的东西——agentic orchestration runtime——是当下基础设施领域一个真实且快速演进的方向。热搜词里那些看似无关的条目，其实都在从不同角度指向同一个趋势：Agent 正在从 demo 走向生产，而生产化需要一套专门的运行时基础设施。

这套基础设施的核心命题，我总结成三句话：

• 状态要外置，Agent 进程要变成可替换的执行器。
• 调度要看会话，不能只看 CPU 和内存。
• 可观测性要到会话粒度，否则出了问题根本没法查。

这三件事做好了，Agent 才真正具备生产可用性。做不好，就永远停留在"能跑 demo 但不敢上量"的阶段。

我在实际项目里最大的体会是：别把 Agent 当成普通微服务来管。它的生命周期、状态模型、资源画像、故障模式都不一样。用管微服务的思路去管 Agent，会处处别扭。反过来，一旦你接受了"会话是一等公民"这个前提，很多设计决策就顺理成章了。

最后分享一个实用的小技巧：在会话调度器里加一个"会话年龄"指标，统计所有活跃会话从创建到现在的时间。如果这个指标的 P99 持续增长，说明有会话卡住了没正常结束，通常是某个工具调用没超时或者某个状态转换逻辑有 bug。这个指标帮我抓到过好几次隐蔽的问题。