企业官网建设流程全解析

1. 从“ax”这个标题说起：一个被低估的运行时抽象层

第一次看到“ax”这个标题，很多人会一头雾水。它不像“Kubernetes 入门”那样直白，也不像“agentic rag”那样自带热度。但把热搜词摊开来看，ax、agentic、orchestration、runtime、Kubernetes 这几个词反复出现，指向的其实是同一件事：在 agentic 应用爆发之后，如何用一个统一的运行时抽象层，把调度、编排、执行这三件事重新组织起来。

我个人的判断是，ax 代表的是一类“agent 执行运行时”的设计思路。它要解决的问题很具体：当你的系统里不再只有一两个 LLM 调用，而是有几十上百个 agent 在跑任务，每个 agent 又可能调用工具、访问数据库、拉起容器、等待外部事件，这时候传统的“请求-响应”模型就撑不住了。你需要一个 runtime，负责把 agent 的生命周期管起来，把资源调度做掉，把编排逻辑从业务代码里抽出来。

这篇文章适合三类人看。第一类是正在做 agent 平台的后端工程师，你们大概率已经在手搓调度器了，看完可以对照一下有没有踩到同样的坑。第二类是做 Kubernetes 基础设施的同学，agentic cloud 这个概念迟早会落到你们的集群上，提前理解 runtime 层怎么和 K8s 对接有好处。第三类是技术负责人，需要判断“自研 runtime”和“复用现有编排系统”之间的边界在哪里。

我下面会按“设计思路 → 核心细节 → 实操落地 → 问题排查”这条线展开，尽量把每个决策背后的理由讲清楚，而不是只给结论。

2. 整体设计与思路拆解：为什么 agentic 场景需要独立的 runtime

2.1 从“函数调用”到“agent 生命周期”的范式转移

传统后端服务的执行单元是函数或请求。一个 HTTP 请求进来，走完业务逻辑，返回响应，生命周期结束。这个模型下，调度是操作系统和容器编排系统的事，应用层几乎不用操心。

Agent 完全不一样。一个 agent 被创建之后，它可能处于这些状态：等待 LLM 返回、等待工具执行、等待人工审批、等待外部事件、被挂起、被恢复、超时终止。它的执行时间可能是几百毫秒，也可能是几天。它占用的资源不是固定的 CPU 和内存，而是“上下文窗口 + 工具连接 + 中间状态”。

这就带来一个根本矛盾：Kubernetes 擅长管理长期运行的无状态服务，但不擅长管理大量短生命周期、状态复杂、需要频繁挂起恢复的执行单元。你当然可以把每个 agent 塞进一个 Pod，但 Pod 的启动开销、状态持久化、跨 Pod 的上下文传递都会变成噩梦。

ax 这类 runtime 的价值就在这里。它在 K8s 之上加了一层“agent 感知”的调度抽象，把 agent 的状态管理和资源调度分开处理。

2.2 为什么不是直接用 Kubernetes 的 Job 和 CronJob

我试过用 K8s 原生 Job 来跑 agent 任务，结论是：能跑，但很别扭。

Job 的设计假设是“任务会跑完”。但 agent 经常需要暂停等待外部输入，这时候 Job 要么一直占着 Pod，要么被删掉后状态丢失。CronJob 更不适合，它是按时间触发的，而 agent 的触发条件往往是事件驱动的。

还有一个更隐蔽的问题：调度粒度。K8s 的调度单位是 Pod，一个 Pod 里可能跑多个 agent。如果其中一个 agent 需要 GPU，另一个只需要 CPU，你没法在 Pod 内部做资源隔离。ax 这类 runtime 通常会把调度粒度下沉到“单个 agent 执行实例”，这样才能做到精细化的资源分配。

2.3 编排层和执行层的职责边界

这是设计时最容易搞混的地方。我的经验是划一条清晰的线：

很多团队一开始把这三层揉在一起，结果就是业务代码里到处是if agent.status == 'waiting'这种判断。ax 的思路是把状态机收进 runtime，业务层只负责定义“做什么”，不负责“怎么等”。

2.4 与 agentic cloud 的关系

热搜里提到“agentic cloud 坚实底座”，这个说法很准确。Agentic cloud 的核心不是“云”，而是“agent 原生的基础设施”。传统云提供的是虚拟机、容器、数据库，agentic cloud 需要额外提供：agent 注册与发现、上下文存储、工具网关、执行追踪。

ax 作为 runtime，处在这个栈的中间层。它向上承接编排系统的指令，向下调用 K8s 或其他执行后端。这个位置决定了它必须足够薄，薄到不会成为瓶颈；又必须足够厚，厚到能屏蔽底层差异。

3. 核心细节解析与实操要点：runtime 内部到底在做什么

3.1 Agent 状态机的设计

一个可靠的 agent runtime，核心是一个状态机。我见过的最小可用状态集是这样的：

• PENDING：已创建，等待调度
• RUNNING：正在执行
• WAITING：等待外部事件（LLM 返回、工具结果、人工输入）
• SUSPENDED：主动挂起，释放计算资源
• COMPLETED：正常结束
• FAILED：异常结束
• CANCELLED：被主动取消

关键点在于WAITING和SUSPENDED的区别。WAITING是等外部输入，agent 的逻辑还在内存里；SUSPENDED是把状态序列化到存储，计算资源完全释放。前者适合短等待（秒级），后者适合长等待（分钟到天级）。

注意：很多团队一开始只做WAITING，不做SUSPENDED，结果 agent 一多，内存直接爆掉。我的建议是第一天就把序列化机制设计进去，哪怕暂时不用。

3.2 上下文存储的选型

Agent 的上下文包括：对话历史、工具调用记录、中间变量、执行元数据。这些东西不能放在进程内存里，因为 agent 随时可能被调度到另一台机器。

选型上有几个方向：

• Redis：适合短生命周期、高频读写的上下文，但持久化能力弱
• PostgreSQL + JSONB：适合需要查询和审计的场景，写入延迟比 Redis 高
• 对象存储：适合大体积上下文（比如长文档），但读取延迟高
• 专用向量库：如果上下文需要做语义检索，可以叠加一层

我实际用下来，PostgreSQL + Redis 的组合最稳。热数据放 Redis，冷数据落 PG，序列化时写两边，恢复时优先读 Redis，miss 了再查 PG。这个方案的好处是运维简单，不需要引入新的存储系统。

3.3 调度器的核心逻辑

调度器要回答三个问题：哪个 agent 该跑、跑在哪、什么时候跑。

第一层是优先级队列。Agent 任务通常有优先级，比如用户直接触发的比后台批处理的优先级高。用优先队列做第一层过滤，避免低优先级任务饿死高优先级任务。

第二层是资源匹配。每个 agent 声明自己需要的资源：CPU、内存、GPU、工具连接数。调度器根据当前集群的可用资源做匹配。这里要注意，agent 的资源需求是动态的，执行过程中可能变化，所以调度器需要支持“重新调度”。

第三层是亲和性。有些 agent 需要访问特定的数据源，最好调度到离数据近的节点。有些 agent 之间有依赖关系，需要按顺序调度。这些规则用标签和选择器表达，不要硬编码。

3.4 与 Kubernetes 的对接方式

这是实操中最容易出问题的部分。有两种主流做法：

做法一：每个 agent 一个 Pod。优点是隔离性好，缺点是 Pod 启动慢（秒级），不适合短任务。适合长生命周期的 agent。

做法二：常驻 Worker Pod + 内部调度。每个节点跑一个常驻的 worker，worker 内部管理多个 agent 的执行。优点是启动快（毫秒级），缺点是隔离性弱，一个 agent 崩溃可能影响同 worker 的其他 agent。

我的建议是混合模式：短任务走常驻 worker，长任务走独立 Pod。Runtime 根据 agent 的预期生命周期自动选择执行模式。这个判断逻辑可以很简单：预估执行时间小于 30 秒的走 worker，大于 30 秒的走 Pod。

3.5 工具网关的设计

Agent 调用工具是高频操作。如果每个 agent 都直接连数据库、直接调 API，会有几个问题：连接数爆炸、权限难管理、调用难追踪。

工具网关的作用是把这些调用收口。Agent 不直接调工具，而是向网关发请求，网关负责鉴权、限流、重试、记录。这样做的额外好处是，网关可以做缓存——相同的工具调用直接返回缓存结果，省掉重复计算。

网关的接口设计要简单，我习惯用这样的结构：

{ "agent_id": "agent-123", "tool": "search", "params": {"query": "ax runtime"}, "timeout_ms": 5000 }

网关返回统一格式，包含结果、耗时、是否命中缓存。这样上层不用关心工具的具体实现。

4. 实操过程与核心环节实现：从零搭一个最小可用 runtime

4.1 环境准备与依赖清单

先列一下我实际用的技术栈，都是成熟组件，不追求新潮：

• 语言：Go（runtime 层对并发和性能要求高，Go 的 goroutine 模型很合适）
• 状态存储：PostgreSQL 15 + Redis 7
• 容器编排：Kubernetes 1.28+
• 消息队列：NATS（比 Kafka 轻，适合 agent 事件流）
• 可观测性：OpenTelemetry + Prometheus + Grafana

安装依赖时有个坑要注意：Kubernetes 的 device plugin 机制。如果你要让 agent 使用 GPU 或其他特殊设备，需要提前部署对应的 device plugin，否则调度器看不到这些资源。这个在热搜里也出现了，说明踩坑的人不少。

4.2 状态机的代码实现

核心状态机我用一个简单的表驱动方式实现，避免复杂的 if-else：

type AgentState string const ( StatePending AgentState = "PENDING" StateRunning AgentState = "RUNNING" StateWaiting AgentState = "WAITING" StateSuspended AgentState = "SUSPENDED" StateCompleted AgentState = "COMPLETED" StateFailed AgentState = "FAILED" ) var validTransitions = map[AgentState][]AgentState{ StatePending: {StateRunning, StateFailed}, StateRunning: {StateWaiting, StateSuspended, StateCompleted, StateFailed}, StateWaiting: {StateRunning, StateSuspended, StateFailed}, StateSuspended: {StateRunning, StateFailed}, StateCompleted: {}, StateFailed: {}, } func (s AgentState) CanTransitionTo(target AgentState) bool { for _, t := range validTransitions[s] { if t == target { return true } } return false }

这个表驱动的好处是，状态转换规则一目了然，加新状态时只改表不改逻辑。每次状态变更都写一条事件到 NATS，这样其他组件可以订阅状态变化做后续处理。

4.3 调度循环的实现

调度循环是一个常驻的 goroutine，每隔 100ms 跑一次：

func (s *Scheduler) loop() { ticker := time.NewTicker(100 * time.Millisecond) for range ticker.C { pending := s.store.ListPending(100) for _, agent := range pending { node := s.findBestNode(agent) if node == "" { continue } if err := s.dispatch(agent, node); err != nil { s.store.MarkFailed(agent.ID, err) continue } s.store.MarkRunning(agent.ID, node) } } }

findBestNode是核心。我的实现是先按资源需求过滤出候选节点，再按负载排序，选负载最低的。这里不要用复杂的打分函数，简单有效最重要。复杂的打分函数调试起来很痛苦，而且收益不明显。

4.4 上下文序列化的关键细节

序列化时最容易忽略的是版本兼容。Agent 的上下文结构会随着业务迭代变化，如果直接序列化 Go struct，升级后旧数据可能反序列化失败。

我的做法是加一个版本号字段，反序列化时根据版本号走不同的解析逻辑：

type Context struct { Version int `json:"version"` Data json.RawMessage `json:"data"` } func (c *Context) Unmarshal() (*AgentContext, error) { switch c.Version { case 1: var v1 AgentContextV1 if err := json.Unmarshal(c.Data, &v1); err != nil { return nil, err } return v1.ToCurrent(), nil case 2: var v2 AgentContext if err := json.Unmarshal(c.Data, &v2); err != nil { return nil, err } return &v2, nil default: return nil, fmt.Errorf("unsupported context version: %d", c.Version) } }

这个设计看起来啰嗦，但能省掉未来大量的数据迁移工作。我踩过一次坑，没有版本号，结果一次结构变更导致所有挂起的 agent 全部恢复失败。

4.5 与 K8s 的对接实操

对接 K8s 有两种方式：用 client-go 直接调 API，或者用 controller-runtime 写 operator。我推荐后者，因为 operator 模式天然支持声明式管理和状态同步。

关键配置项：

提示：如果遇到container runtime is not running这类错误，先检查节点上的容器运行时状态，再检查 kubelet 配置。这类问题通常和 runtime 层无关，是基础设施问题。

4.6 工具网关的限流实现

工具网关的限流用令牌桶算法，每个工具一个桶：

type RateLimiter struct { mu sync.Mutex buckets map[string]*rate.Limiter } func (r *RateLimiter) Allow(tool string) bool { r.mu.Lock() bucket, ok := r.buckets[tool] if !ok { bucket = rate.NewLimiter(rate.Limit(100), 200) r.buckets[tool] = bucket } r.mu.Unlock() return bucket.Allow() }

限流参数要根据工具的实际承载能力设置。数据库查询可以放宽，外部 API 调用要收紧。我一般先设一个保守值，观察一周后再调整。

5. 常见问题与排查技巧实录

5.1 Agent 卡在 WAITING 状态不恢复

这是最常见的问题。排查顺序：

1. 检查事件是否真的到达了。看 NATS 的消费延迟，如果消息堆积，说明消费者处理不过来。
2. 检查状态存储是否可写。Redis 满了或者 PG 连接池耗尽都会导致状态更新失败。
3. 检查恢复逻辑是否有 bug。我遇到过一次，恢复时读取的 key 和写入时的 key 不一致，导致永远读不到。

速查表：

5.2 调度不均导致部分节点过载

调度器的负载评估如果只看 CPU，会忽略内存和 IO。我的做法是综合三个指标：CPU 使用率、内存使用率、当前 agent 数量。三个指标加权求和，权重根据实际负载调整。

还有一个隐蔽问题：调度抖动。如果两个节点的负载很接近，调度器可能反复把 agent 在两边倒腾。解决办法是加一个“粘性”机制，agent 一旦调度到某节点，除非节点故障，否则不迁移。

5.3 上下文丢失的几种场景

上下文丢失是最严重的问题，因为不可恢复。我总结了几种场景：

• 序列化时进程崩溃，写了一半
• 存储系统故障，写入的数据丢失
• 反序列化时结构不兼容，解析失败

第一种用事务解决，序列化和状态更新放在一个事务里。第二种用多副本存储，Redis 开 AOF，PG 开流复制。第三种用版本号解决，前面已经讲过。

注意：不要依赖单一存储。我现在的做法是 Redis 和 PG 双写，恢复时优先读 Redis，miss 了读 PG。虽然增加了一点写入开销，但可靠性提升明显。

5.4 与 K8s 交互时的权限问题

Runtime 需要操作 Pod、Service、ConfigMap 等资源，权限配置要遵循最小权限原则。常见的坑是用了 cluster-admin，虽然方便但风险大。

推荐的做法是创建一个专用的 ServiceAccount，只授予必要的权限：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: agent-runtime name: agent-runtime-role rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: [""] resources: ["configmaps"] verbs: ["get", "list", "watch"]

这个配置只允许在指定 namespace 内操作 Pod 和 ConfigMap，不涉及其他资源。

5.5 性能调优的几个关键参数

调优前先做基准测试，不要凭感觉调。我常用的基准场景是：1000 个 agent 并发执行，每个 agent 调用 5 次工具，平均执行时间 2 秒。

关键参数：

调优时一次只改一个参数，观察效果后再改下一个。同时改多个参数，出了问题很难定位。

5.6 可观测性建设

没有可观测性的 runtime 就是黑盒。我至少会埋这些指标：

• agent 创建速率、完成速率、失败速率
• 各状态的 agent 数量
• 调度延迟（从 PENDING 到 RUNNING 的时间）
• 工具调用延迟和成功率
• 上下文读写延迟

这些指标用 Prometheus 采集，Grafana 展示。告警规则设两条：失败率超过 5% 告警，调度延迟超过 1 秒告警。

6. 一些实操心得和后续扩展方向

做 runtime 这件事，我的核心体会是：不要追求大而全，先把状态机和调度器做扎实。我见过太多团队一上来就搞复杂的 DAG 编排、多租户隔离、可视化界面，结果核心的调度逻辑一堆 bug，agent 跑着跑着就丢了。

另一个体会是，存储的可靠性比性能重要。Runtime 的性能瓶颈通常在 LLM 调用和工具执行，不在状态存储。所以存储选型时优先考虑可靠性，Redis 开 AOF，PG 开同步复制，这些开销值得。

后续如果要扩展，我会优先做两件事。一是多集群调度，让 agent 可以跨集群执行，提高资源利用率。二是执行回放，把 agent 的完整执行过程录下来，出问题时可以回放分析。这两个功能对生产环境的价值很大。

最后分享一个小技巧：在开发阶段，把状态转换的日志级别调到 DEBUG，每次转换都打一条日志。这样排查问题时，直接 grep 日志就能看到完整的执行路径，比看代码快得多。上线后再调回 INFO，避免日志量过大。