Agentic 运行时编排实战：从会话状态机到 K8s 落地

1. 从“ax”这个标题说起：一个被低估的运行时编排命题

第一次看到“ax”这个标题，很多人会一头雾水——两个字母，既不像产品名，也不像技术缩写。但把热搜词摊开来看，脉络就清楚了：agentic、orchestration、runtime、Kubernetes这几个词反复出现，再加上“karmada正式毕业”“agentic cloud坚实底座”这类社区动态，基本可以判断，这里讨论的“ax”指向的是Agentic 场景下的运行时编排层——一个把智能体（Agent）当作一等公民来调度、隔离、观测和治理的基础设施抽象。

我先把结论摆在前面：ax 不是一个具体的开源项目名，而是一类架构命题的代称——它回答的是“当你的系统里跑的不再是无状态微服务，而是一群会自己决策、自己调工具、自己写状态的 Agent 时，底层的 runtime 和 orchestration 该怎么设计”。这个问题在 2024 年之后变得极其现实，因为 Kubernetes 原生的 Pod/Deployment/Service 这套模型，是为“请求-响应”式服务设计的，它假设工作负载是幂等的、生命周期是确定的、资源占用是可预测的。而 Agent 恰恰相反：它会长时间挂起等外部事件、会动态拉起子任务、会在一次会话里消耗掉几十万 token 的算力、还会因为一次工具调用失败而进入重试循环。

所以这篇内容适合谁看？三类人：一是正在把 LLM 应用从 demo 推向生产的后端工程师，你会发现原来的 K8s 部署方式越来越别扭；二是做平台/基础设施的同学，你需要提前想清楚 Agent 的调度单元到底是什么；三是技术负责人，你要判断“现在要不要为 agentic 负载单独建一层 runtime”。我会从设计思路、核心机制、实操落地到踩坑排查，完整走一遍，尽量把每个“为什么这么设计”讲透。

2. 为什么传统 Kubernetes 模型撑不住 Agentic 负载

2.1 Agent 的工作负载特征和微服务根本不是一回事

要理解 ax 这类 runtime 存在的必要性，先得把 Agent 负载的“脾气”摸清楚。我把它和传统微服务做了个对照，这张表是我自己在做迁移评估时整理的，实测非常能说明问题：

这张表里最关键的一行是失败语义。微服务里一个请求失败，重试一次通常无害；但 Agent 执行到一半去调了一个“下单”工具，然后进程崩了，你重试整个 Agent 循环，就可能下两次单。这就是为什么 ax 这类 runtime 必须把执行步骤的持久化和副作用隔离做进核心，而不是像传统服务那样丢给业务层自己处理。

2.2 调度单元的选择：Pod 太重，函数太轻

那 Agent 到底该以什么为单位调度？我试过三种方案，各有取舍。

第一种是一个 Agent 一个 Pod。好处是隔离彻底，坏处是启动慢、资源浪费严重——一个 Agent 大部分时间在等 LLM 返回，Pod 却占着内存不放。第二种是一个 Agent 一个函数（Serverless）。启动快、按需计费，但函数天生无状态，而 Agent 恰恰需要跨步骤保持上下文，你得外挂一堆存储，延迟一下就上去了。第三种是一个会话（Session）一个轻量运行时，这也是我认为 ax 类架构最可能采用的形态：运行时本身很轻，但能挂载持久化的会话状态，支持挂起/恢复，资源按实际计算时段计费。

提示：如果你现在还在用“一个 Deployment 跑所有 Agent 请求”的方式，短期内没问题，但只要出现“某个 Agent 卡住导致整个副本不可用”的情况，就该考虑把调度粒度下沉到会话级了。

2.3 编排层要解决的三件事：路由、隔离、观测

把需求收敛一下，ax 这类 orchestration 层本质上要解决三个问题。路由：一个用户请求进来，该分配给哪个 Agent 实例？是新建还是复用已有会话？隔离：Agent A 调用的工具不能污染 Agent B 的上下文，一个 Agent 崩溃不能拖垮同节点的其他 Agent。观测：Agent 的执行链路是树状的（主任务派生子任务），传统 tracing 的线性 span 模型不够用，需要能表达“父子任务 + 工具调用 + 重试”的图结构。

这三件事里，观测是最容易被低估的。我踩过的坑是：Agent 上线后行为诡异，但日志里只有“调用了工具 X”，看不到它为什么调、调之前推理了什么。后来我们强制把每一步的“思考-行动-观察”三元组都打点，才定位到是提示词里一个边界条件没覆盖。所以 ax 的观测设计，必须从第一天就把 Agent 的决策过程当作一等数据。

3. ax 运行时编排的核心机制拆解

3.1 会话状态机：把 Agent 循环变成可恢复的步骤

ax 最核心的抽象，我认为是把 Agent 的执行循环建模成一个持久化的状态机。传统做法是写个 while 循环，LLM 返回工具调用就执行，执行完再喂回去。这个循环一旦进程挂了，全部丢失。ax 的思路是：每一步（一次 LLM 调用、一次工具执行）都是一个状态转移，转移前后的状态都落盘。

具体来说，一个会话的状态至少包含：当前步骤序号、对话历史、待执行的工具调用、已产生的副作用记录、token 消耗计数。每次状态转移前先写 WAL（预写日志），转移成功后再更新主状态。这样即使运行时崩溃，重启后也能从最后一个完整步骤恢复，而不是从头再来。

这里有个关键设计决策：副作用记录必须和状态转移在同一个事务里。否则会出现“工具执行成功了但状态没更新”的不一致。我的做法是给每个工具调用分配一个幂等键（idempotency key），工具侧支持按这个键去重，这样即使重放也不会重复下单。

3.2 工具调用的沙箱与配额：别让一个 Agent 拖垮整个集群

Agent 最危险的地方在于它会自主调用工具，而工具可能访问外部系统、消耗真实资源。ax 的隔离机制我建议分三层来做。

第一层是进程级隔离：每个会话的运行时跑在独立的轻量沙箱里（可以是容器，也可以是更轻的 microVM），限制 CPU、内存上限。第二层是网络级隔离：工具调用走统一的出口代理，代理层做白名单和限流，Agent 不能直接访问任意地址。第三层是配额级隔离：给每个会话设置 token 预算、工具调用次数上限、总执行时长上限，超了就强制终止并告警。

注意：配额一定要设“硬上限”而不是“软提醒”。我见过一个 Agent 因为工具返回了异常格式，陷入重试循环，一晚上烧掉了几百万 token。软提醒根本拦不住，必须硬熔断。

3.3 多 Agent 协作的编排：树状任务图怎么调度

当系统里不止一个 Agent，而是主 Agent 派生子 Agent 时，编排就变成了一个动态任务图的调度问题。ax 需要支持：父任务创建子任务、子任务并发执行、父任务等待子任务结果、任一子任务失败时的回滚或降级策略。

我的实践经验是，不要用 K8s 的 Job 来表达子任务，因为 Job 的创建有延迟（秒级），而 Agent 派生子任务可能非常频繁。更好的做法是在 runtime 内部维护一个任务队列，子任务作为队列里的一个条目，由同一批 worker 消费。这样调度延迟在毫秒级，而且任务图的状态和会话状态在同一个存储里，一致性更好。

至于并发控制，我建议给每个会话设一个“最大并发子任务数”，默认 3 到 5。设太大，LLM 的 rate limit 会先扛不住；设太小，复杂任务的执行时间会拉长。这个值需要根据你的 LLM 配额和任务复杂度实测调优。

4. 落地实操：从零搭一个最小可用的 ax 运行时

4.1 环境准备与依赖选型

先说环境。我假设你已经有一个可用的 Kubernetes 集群（1.26 及以上都行，热词里提到的 v1.26.0 是常见版本）。但要注意，ax 运行时本身不一定非要跑在 K8s 上，如果你的规模不大，用 Docker Compose 甚至裸机进程都能跑。K8s 的价值在于多节点调度和故障自愈，规模上来了再上。

依赖选型上，我列一下我的推荐组合：

• 状态存储：PostgreSQL（会话状态、任务图）+ Redis（热状态缓存、分布式锁）。别用 etcd 存业务状态，它是给元数据用的。
• 消息队列：NATS 或 Redis Streams。NATS 更轻，适合任务分发；Kafka 太重，除非你已经有。
• 沙箱：gVisor 或 Firecracker。前者兼容性好，后者隔离强但启动稍慢。
• 观测：OpenTelemetry + 支持图结构的后端。传统 Jaeger 的线性 span 不够用，需要自己扩展 span 的父子关系。

提示：如果你只是想先验证概念，可以跳过沙箱，用进程级隔离 + 资源限制先跑起来，等验证完再补隔离层。别一上来就追求完美架构。

4.2 会话状态机的代码骨架

下面是我实际用过的一个简化版状态机骨架，用 Python 写，核心是“先写日志再执行”：

import json import uuid from dataclasses import dataclass, asdict @dataclass class SessionState: session_id: str step: int history: list pending_tool: dict | None side_effects: list token_used: int class SessionRuntime: def __init__(self, store, llm, tools): self.store = store # 持久化存储 self.llm = llm self.tools = tools def step(self, session_id: str): state = self.store.load(session_id) if state.token_used > TOKEN_BUDGET: raise BudgetExceeded(session_id) # 1. 调用 LLM，得到下一步动作 action = self.llm.invoke(state.history) # 2. 先写 WAL，记录即将执行的动作 wal_id = self.store.append_wal(session_id, action) # 3. 执行动作（可能是工具调用，也可能是结束） if action.type == "tool_call": idem_key = f"{session_id}:{state.step}" result = self.tools.call(action.name, action.args, idem_key) state.side_effects.append({"key": idem_key, "result": result}) state.history.append({"role": "tool", "content": result}) # 4. 提交状态转移 state.step += 1 state.token_used += action.token_cost self.store.commit(session_id, state, wal_id) return state

这段代码的关键点有三个：WAL 先于执行、幂等键绑定步骤号、状态提交是原子的。你可以把它理解成数据库的事务，只不过事务的“操作”是 LLM 调用和工具执行。

4.3 工具沙箱的配置参数与计算

沙箱的资源限制怎么定？我给一个实测的估算方法。假设你的 Agent 平均一次会话执行 20 步，每步 LLM 调用耗时 2 秒、工具调用耗时 1 秒，那么单会话的活跃计算时间约 60 秒。但会话可能挂起等待，挂起期间不该占 CPU。

所以沙箱的配置应该是：CPU 限制按峰值给（比如 1 核），内存按上下文大小给（比如 512MB 到 2GB），但空闲时允许被驱逐。具体内存估算：对话历史按每 1000 token 约 4KB 算，10 万 token 的上下文约 400KB，加上运行时开销，512MB 足够大多数场景。如果你的 Agent 会加载大文件到内存，再往上加。

网络出口代理的限流参数，我建议默认：每会话每秒最多 5 次工具调用，每分钟最多 100 次。这个值根据你的下游系统承受能力调整，但一定要有，否则一个失控的 Agent 能把下游打挂。

4.4 部署到 Kubernetes 的注意事项

如果你决定上 K8s，有几个坑要提前避开。第一，别用 Deployment 跑会话运行时，因为 Deployment 假设副本是对等的、无状态的，而会话是有状态的。用 StatefulSet 或者干脆用自定义控制器管理 Pod 生命周期。第二，探针要区分“存活”和“忙碌”，一个正在执行长任务的会话不该被 liveness probe 杀掉，建议用 readiness 表达“能否接受新会话”，用自定义的健康端点表达“当前会话是否正常”。

第三，资源请求和限制要拉开差距。Agent 负载是尖峰的，request 给低（比如 100m CPU），limit 给高（比如 2 核），让它在需要时能 burst，空闲时把资源让出来。第四，优雅终止要给足时间，Agent 执行到一半被 SIGKILL 会丢状态，terminationGracePeriodSeconds 建议设 60 秒以上，并在收到 SIGTERM 后停止接受新步骤、把当前步骤执行完再退出。

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

5.1 会话恢复后行为不一致怎么办

这是最常见的问题：运行时崩溃重启，从 WAL 恢复会话，但 Agent 后续的行为和崩溃前“预期”的不一样。原因通常是恢复时重放了非幂等的操作，或者LLM 本身有随机性（temperature > 0），同样的历史喂进去得到不同的输出。

解决办法有两个。一是所有副作用操作必须幂等，用步骤号做幂等键，重放时先查副作用记录，已执行过就直接返回缓存结果。二是关键决策点用 temperature=0，或者在 WAL 里记录 LLM 的原始输出，恢复时直接复用而不是重新调用。我倾向于后者，因为重新调用不仅浪费 token，还可能因为模型版本更新导致行为漂移。

5.2 工具调用超时和重试的边界

Agent 调工具超时了，该重试几次？我的经验是：读操作可以重试 2 到 3 次，写操作最多重试 1 次且必须幂等。而且重试要有退避，第一次等 1 秒，第二次等 3 秒，别密集重试把下游打挂。

更重要的是，超时时间要分层设置。LLM 调用超时可以设长一点（比如 60 秒），因为大模型本来就慢；工具调用超时要短（比如 10 秒），因为大部分工具是内部服务，慢就是有问题。如果工具确实需要长时间执行，应该改成异步模式：先提交任务拿个 task_id，然后轮询或等回调，而不是同步阻塞。

5.3 排查速查表

我把实际运维中遇到的问题整理成了一张表，方便你对照排查：

注意：排查 Agent 问题时，永远先看 WAL，再看日志。WAL 是事实来源，日志可能因为缓冲丢失。养成“WAL 优先”的习惯，能省掉大量猜测时间。

5.4 几个我踩过的坑

第一个坑是用 Redis 存会话状态但没设过期时间，结果内存越用越多，最后 OOM。后来改成“活跃会话在 Redis，冷会话落 PostgreSQL”，并给 Redis 设了 TTL。

第二个坑是工具调用的参数没做 schema 校验，LLM 偶尔生成格式不对的参数，工具直接抛异常，Agent 又重试，循环好几次。后来在工具入口加了严格的 JSON Schema 校验，不合法就直接返回错误让 LLM 修正，而不是让工具崩。

第三个坑是多 Agent 协作时没限制递归深度，主 Agent 派生子 Agent，子 Agent 又派生子 Agent，无限套娃。后来加了最大深度限制（默认 3 层），超过就拒绝创建。

6. 关于 ax 这类架构，我的一些个人判断

写到这里，我想分享几个不那么“技术”、但可能更有价值的判断。第一，ax 这类 runtime 短期内不会标准化，因为 Agent 的形态还在快速演化，今天的最佳实践明天可能就过时了。所以别急着追求“通用框架”，先把自己的场景跑通，把状态机和隔离层做扎实，上层怎么变都不怕。

第二，观测比调度更重要。很多人一上来就纠结“怎么调度 Agent”，但实际运维中，80% 的时间花在“搞明白 Agent 为什么这么干”上。把决策链路打点做透，比调度算法精妙更有用。

第三，别过度依赖 K8s。K8s 是好东西，但它的抽象是为微服务设计的，硬套到 Agent 上会有很多别扭。如果你的规模不大，一个简单的任务队列 + 状态存储 + 沙箱进程，可能比一整套 K8s 方案更可控。等规模真的上来了，再考虑用 K8s 做多节点调度。

最后分享一个小技巧：给每个会话打一个“成本标签”，记录它消耗的 token、工具调用次数、执行时长。跑一段时间后你会发现，少数会话消耗了大部分资源。针对这些“重会话”做优化（比如更激进的上下文裁剪、更严格的工具配额），投入产出比最高。这个思路我是从成本治理里学来的，用在 Agent 运维上同样管用。