企业官网建设流程全解析

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

第一次看到"ax"这个标题，绝大多数人的反应是懵的——两个字母，没有正文，没有关键词，没有摘要，只有一串热搜词在旁边晃悠：agentic、orchestration、runtime、Kubernetes。这种信息密度极低的输入，恰恰是最考验拆解能力的场景。我的判断是，"ax"在这里不是某个具体产品的名字，而是一个运行时层面的抽象代号，它指向的是当前云原生与智能体编排交汇处最核心的那层东西：Agent eXecution，也就是智能体的执行运行时。

为什么这么判断？把热搜词串起来看就清楚了。"agentic orchestration runtime"这三个词放在一起，描述的是一个完整的执行链路：智能体负责决策，编排层负责调度，运行时负责真正把活干出来。而"Kubernetes"和"Karmada正式毕业"这两个词的出现，说明这套东西是跑在容器编排体系之上的。再结合"agentic cloud坚实底座"这种表述，基本可以确定，"ax"讨论的是如何在Kubernetes这类基础设施之上，构建一个能承载智能体工作负载的执行运行时。

这个方向为什么现在这么热？因为过去两年大家做智能体，大多停留在"调API、拼Prompt、串工作流"的层面，本质上还是无状态的函数调用。但真正的生产级智能体需要的是：长时间运行、有状态、能自我恢复、能横向扩展、能和其他智能体协作。这些需求，传统的工作流引擎给不了，必须下沉到运行时层去解决。而运行时层最成熟的载体，就是Kubernetes。所以"ax"这个标题背后，其实是一个很硬核的工程命题：把智能体当成一等公民的工作负载，跑在云原生的调度体系里。

这篇文章适合谁看？如果你只是想让ChatGPT帮你写个周报，那可以划走了。但如果你正在设计一个需要7x24小时运行、要处理成千上万并发任务、还要保证故障自愈的智能体系统，那这里面的东西你迟早要面对。我会从运行时的本质讲起，拆解它和传统容器运行时的区别，然后落到Kubernetes上的具体实现路径，最后分享几个我在实际搭建中踩过的坑。全程不堆术语，尽量说人话。

2. 智能体运行时到底在"运行"什么：和容器运行时掰扯清楚

2.1 容器运行时管的是进程，智能体运行时管的是"意图"

要理解"ax"这类运行时，得先搞清楚它和Docker、containerd这些容器运行时的本质区别。容器运行时解决的是一个很具体的问题：给我一个镜像，我把它变成一个隔离的进程，管好它的生命周期、资源限制、网络和存储。它的输入是镜像，输出是进程，中间是标准化的OCI规范。这套东西非常成熟，成熟到你已经不需要关心它怎么工作了。

但智能体运行时的输入不是镜像，而是一个任务意图。比如"帮我分析这份财报并生成摘要"，这是一个意图，不是一个可执行文件。运行时需要做的是：理解这个意图、拆解成子步骤、决定用哪个模型、调用哪些工具、在什么时机把中间结果传给下一步、失败了怎么重试、超时了怎么降级。这些决策在容器运行时里根本不存在，因为容器运行时假设你已经把逻辑写死在镜像里了。

所以智能体运行时的核心职责，是在意图和执行之间架一层翻译和调度。这层东西要处理的是不确定性：模型可能返回乱七八糟的东西，工具可能超时，外部API可能限流，任务可能中途需要人工介入。容器运行时面对的是确定性的进程，智能体运行时面对的是概率性的行为。这是两者最根本的分野。

2.2 为什么不能直接用工作流引擎凑合

有人会说，那用Airflow、Argo Workflows这类工作流引擎不就行了？它们也能编排任务、处理依赖、做重试。这个思路在简单场景下能跑通，但一旦智能体的行为变得动态，就会撞墙。

工作流引擎的核心假设是DAG是预先定义好的。你在写工作流的时候，就已经知道第一步做什么、第二步做什么、条件分支怎么走。但智能体的特点是，它可能根据中间结果动态决定下一步。比如一个研究型智能体，它搜到第一轮资料后，可能决定再搜一轮，也可能决定直接开始写报告，这个决策是运行时才产生的，你没法提前画进DAG里。

另一个问题是状态。工作流引擎的状态通常是存在数据库里的结构化数据，而智能体的状态要复杂得多：对话历史、工具调用记录、中间推理链、向量检索的上下文。这些状态需要被高效地读写、版本化、甚至回滚。工作流引擎的状态管理机制是为任务编排设计的，不是为智能体的认知状态设计的。

所以"ax"这类运行时的价值就体现出来了：它把动态决策和状态管理作为一等公民，而不是事后打补丁。这也是为什么热搜里会出现"agentic rag"这个词——检索增强本身就是一个需要运行时动态决策的过程，检索几次、检索什么、怎么融合，都是运行时的事。

2.3 运行时的四个核心能力模块

拆到具体实现层面，一个智能体运行时至少要提供四块能力。我用一个表格来对照说明，这样比纯文字清楚：

这四块里，最容易被低估的是状态持久化。很多人做原型的时候把状态放在内存里，跑得好好的，一上生产就出问题。因为智能体的执行时间可能很长，几分钟到几小时都有，这期间Pod可能被驱逐、节点可能宕机、网络可能抖动。状态必须能在这些故障中存活下来，并且能被另一个实例接管继续执行。这就要求状态存储必须是外部的、持久的、支持并发访问的。

可观测性也是重灾区。智能体的执行链路比普通微服务长得多，一次任务可能涉及几十次模型调用和工具调用。如果没有分布式追踪，出了问题你根本不知道是哪一步卡住了。而且智能体的日志和普通应用的日志不一样，它需要记录推理过程、工具输入输出、决策依据，这些信息的体量很大，需要专门的采样和存储策略。

3. 把智能体塞进Kubernetes：调度层的真实挑战

3.1 为什么是Kubernetes，而不是自己造轮子

热搜里"Kubernetes"和"Karmada正式毕业"同时出现，不是偶然。Karmada是华为云主导的多集群编排项目，它毕业意味着云原生社区对多集群调度的认可。而智能体运行时选择Kubernetes作为底座，理由很实在：你需要的所有基础设施能力，Kubernetes都已经有了。

服务发现、负载均衡、滚动更新、健康检查、资源配额、密钥管理、网络策略——这些能力如果自己造，没个一两年下不来，而且大概率造得不如Kubernetes稳。智能体运行时的独特需求，其实只占整个系统的一小部分，大部分基础设施需求是通用的。站在Kubernetes的肩膀上，你只需要专注解决那20%的独特问题。

但这里有个前提：你得接受Kubernetes的抽象模型。Kubernetes的世界观是声明式的，你告诉它"我要3个副本"，它负责维持这个状态。智能体的执行是命令式的，"执行这个任务"，这两者需要一层适配。常见的做法是定义一个CRD（自定义资源），比如叫AgentTask，然后写一个Controller来监听这个资源，把它翻译成实际的执行动作。这样智能体任务就变成了Kubernetes的一等公民，能享受所有的调度和运维能力。

3.2 Pod不是为长任务设计的，这是个硬伤

把智能体跑在Pod里，第一个撞上的问题就是Pod的生命周期假设。Kubernetes默认Pod是相对短命的，它假设你的进程会快速处理完请求然后退出，或者至少是稳定的长期服务。但智能体任务可能跑几个小时，中间还可能因为等待外部事件而挂起。这时候Pod的探针机制就会误判，以为你挂了，然后重启你。

我踩过这个坑。当时做一个文档分析智能体，处理一份大文档要40分钟，结果Pod的liveness探针设的是30秒超时，每30秒就被重启一次，任务永远跑不完。后来改成用startup探针给足启动时间，liveness探针改成检查心跳而不是检查进程存活，才解决。

更麻烦的是优雅退出。Kubernetes在驱逐Pod的时候会给一个terminationGracePeriod，默认30秒。但智能体任务可能正在调用一个外部API，或者正在写状态，30秒根本不够。你需要把这个时间调大，同时在代码里实现信号处理，收到SIGTERM后先把当前步骤做完、状态存好、再退出。如果任务实在做不完，还得支持检查点恢复，下次启动时从上次的断点继续。

3.3 多智能体协作时的调度难题

单个智能体还好说，多个智能体协作的时候，调度就复杂了。假设你有三个智能体：一个负责规划，一个负责执行，一个负责审核。它们之间需要传递消息、共享状态、协调节奏。在Kubernetes里，这涉及到几个层面的问题。

第一是服务发现。智能体A怎么找到智能体B？用Service还是用Headless Service？如果智能体是动态创建的，Service可能来不及创建。这时候可能需要用StatefulSet加稳定的网络标识，或者干脆走消息队列解耦。

第二是资源竞争。多个智能体可能同时调用同一个外部API，触发限流。这时候需要在运行时层做令牌桶或者漏桶的限流，而且这个限流器得是分布式的，不能每个Pod自己算自己的。常见的做法是用Redis做集中式限流，或者用Istio这类服务网格在sidecar层做。

第三是死锁检测。智能体A等智能体B的结果，智能体B等智能体A的结果，这种循环依赖在动态决策的场景下很容易出现。运行时需要有能力检测这种循环，并且打破它——要么超时，要么降级，要么人工介入。这个在传统工作流里靠DAG的静态分析就能避免，但在动态智能体场景下必须运行时检测。

4. 状态、记忆与上下文：运行时里最容易被做烂的部分

4.1 对话历史不是简单的追加日志

智能体的状态管理，很多人第一反应是"存个对话历史不就行了"。但真做起来，对话历史的管理比想象中复杂得多。首先是体量问题：一个长任务的对话历史可能几十万token，你不可能每次都全量传给模型，成本和延迟都受不了。所以需要上下文窗口管理，决定哪些历史保留、哪些摘要、哪些丢弃。

这个决策本身就是个技术活。简单的做法是滑动窗口，只保留最近N轮。但这样会丢失早期的关键信息。好一点的做法是做分层摘要：近期的保留原文，中期的做摘要，远期的只保留关键结论。再高级一点，用向量检索，把历史存进向量库，需要的时候检索相关片段。这就是热搜里"agentic rag"的实际应用场景——不是简单的文档检索，而是对智能体自身记忆的检索。

其次是一致性问题。多个智能体可能同时读写同一份状态，需要处理并发冲突。用乐观锁还是悲观锁？用CRDT还是用版本号？这些在分布式系统里是老问题，但在智能体场景下有新特点：状态的更新频率高、粒度细、而且经常是追加式的。所以事件溯源模式在这里特别合适——不存最终状态，存状态变化的事件流，需要的时候重放。这样天然支持并发追加，也方便做审计和回滚。

4.2 检查点机制：让长任务能"续命"

检查点是长任务运行时的生命线。没有检查点，一个跑了两小时的任务因为节点故障挂了，就得从头再来，这在生产环境是不可接受的。检查点的设计要考虑几个维度。

粒度：太粗了恢复时浪费算力，太细了存储和序列化开销大。我的经验是，在步骤边界做检查点比较合适，也就是一个完整的"思考-行动-观察"循环结束后存一次。这样恢复时最多重做一个步骤，开销可控。

存储位置：本地磁盘不行，因为Pod可能被调度到别的节点。必须存到外部，比如对象存储、分布式文件系统、或者专门的检查点服务。存的时候要注意序列化格式，用JSON还是Protobuf还是MessagePack，取决于你的状态复杂度和性能要求。

版本兼容：这个最容易被忽略。你的智能体代码升级了，状态结构变了，旧的检查点还能不能恢复？如果处理不好，升级一次所有在跑的任务全挂。解决办法是在检查点里带版本号，恢复时做迁移，或者干脆保证状态结构向后兼容。

4.3 记忆的冷热分离

智能体的记忆有冷热之分。热记忆是当前任务正在用的，需要低延迟访问，适合放内存或者Redis。冷记忆是历史积累的，访问频率低但体量大，适合放对象存储或者向量数据库。运行时需要自动在两者之间做迁移，把不常用的热记忆降冷，把需要的冷记忆升温。

这个机制听起来简单，做起来要考虑迁移时机和迁移成本。迁移太频繁，开销大；迁移太少，热存储爆掉。我的做法是设一个阈值，热记忆超过一定大小或者一定时间没被访问，就触发降冷。升温则是按需触发，检索命中冷数据时异步加载。这里的关键是异步，不能让升温阻塞主流程，否则延迟会很难看。

5. 可观测性：智能体出问题时你怎么知道

5.1 传统监控在智能体场景下的盲区

传统的APM工具监控的是请求延迟、错误率、吞吐量这些指标。这些指标在智能体场景下依然有用，但远远不够。因为智能体的问题往往不是"慢了"或者"挂了"，而是"想歪了"——它做出了一个不合理的决策，导致任务失败或者结果质量差。这种问题在传统指标上完全看不出来，延迟正常、错误率为零，但结果就是不对。

所以智能体的可观测性需要额外关注决策链路。每一次模型调用、每一次工具选择、每一次状态变更，都要记录下来，并且能串成一条完整的链路。这样出问题的时候，你能回放整个决策过程，看到是哪一步开始跑偏的。这比传统日志的体量大得多，所以需要采样策略——不是所有任务都全量记录，而是按比例采样，或者对失败任务全量记录、成功任务采样记录。

5.2 分布式追踪在智能体链路里的落地

分布式追踪（比如OpenTelemetry）在微服务里已经很成熟了，但用在智能体上有几个特殊点。第一是Span的粒度。一次智能体任务可能产生几百个Span，如果每个模型调用、每个工具调用都建Span，追踪系统的压力会很大。我的做法是把一个完整的"思考-行动-观察"循环作为一个Span，内部的关键调用作为Event记录，这样既保留了细节，又控制了Span数量。

第二是上下文传播。智能体之间的调用可能不是同步的HTTP调用，而是通过消息队列异步传递。这时候TraceContext需要手动注入到消息里，消费端再提取出来。这个在OpenTelemetry里有标准做法，但需要你在消息中间件层做适配。

第三是敏感信息脱敏。智能体的输入输出可能包含用户隐私、商业机密，追踪数据里不能明文存。需要在采集层做脱敏，或者用引用代替内容，真正的内容存在加密的存储里，追踪系统只存引用。

5.3 从日志到"决策回放"

我理想中的智能体可观测性，是能像看录像一样回放整个决策过程。这需要把日志、追踪、状态快照三者关联起来。具体来说，每个决策点记录：当时的输入是什么、考虑了哪些选项、为什么选了这个、结果如何。这些信息结构化存储，配合时间线视图，就能还原出完整的决策路径。

实现这个的关键是统一的事件模型。不要让日志、追踪、状态各存各的，而是定义一个统一的事件格式，所有组件都往这个格式上靠。这样查询和关联就简单了。代价是前期设计成本高，但后期排查问题的效率提升是数量级的。我在一个项目里这么做了之后，定位一个复杂问题的平均时间从几小时降到了十几分钟。

6. 实操中踩过的坑与几条硬经验

6.1 别把智能体当微服务写

最常见的错误是用写微服务的思路写智能体。微服务的假设是无状态、快速响应、幂等。智能体恰恰相反：有状态、长耗时、非幂等。如果你用微服务那套健康检查、超时重试、负载均衡策略，会处处碰壁。

具体来说，重试要特别小心。微服务里重试是安全的，因为幂等。但智能体的一次工具调用可能有副作用，比如发了一封邮件、创建了一个订单，重试就会重复执行。所以智能体的重试必须区分可重试操作和不可重试操作，前者比如查询、检索，后者比如写入、发送。对于不可重试的，要么做幂等设计，要么记录已执行状态，重试时跳过。

6.2 资源限制要留足余量

智能体的资源消耗波动很大。一次简单的问答可能几百毫秒、几十MB内存，一次复杂的多步推理可能几分钟、几个GB内存。如果你按平均值设资源限制，复杂任务就会OOM被杀。我的做法是按P99设limit，按P50设request，这样大部分任务能快速调度，少数重任务也不会被杀。同时配合优先级队列，重要任务优先调度，避免被低优先级任务挤占资源。

CPU的限制也要注意。智能体本身的计算量不大，但如果你在本地跑embedding模型或者做向量检索，CPU消耗会很高。这时候要么把重计算拆到单独的Pod，要么用GPU节点，要么用外部服务。别让智能体Pod既做编排又做重计算，职责要分开。

6.3 版本升级要能灰度

智能体的行为对模型版本、Prompt版本、工具版本都很敏感。升级一次可能导致行为大变。所以升级必须能灰度，能回滚。具体做法是给每个智能体实例打上版本标签，流量按比例分配到不同版本，观察指标没问题再全量。回滚要能做到秒级，这要求状态存储兼容多版本，或者至少能快速迁移。

还有一个坑是模型API的版本。很多模型服务会悄悄更新版本，你的Prompt可能在新版本上表现不一样。所以要么锁定模型版本，要么做A/B测试持续监控效果。我见过一个案例，模型小版本更新后，一个关键任务的准确率从95%掉到70%，因为没有监控，一周后才发现。

6.4 成本控制是运行时的一部分

智能体跑起来之后，成本很容易失控。模型调用、向量检索、存储、网络，每一项都在烧钱。运行时需要内置成本控制：给每个任务设预算上限，超了就降级或者终止；给每个租户设配额，防止一个用户把资源吃光；做成本归因，知道钱花在哪了。

降级策略要提前设计好。预算不够的时候，是用小模型代替大模型，还是减少检索次数，还是缩短上下文？这些策略要在运行时里可配置，而不是硬编码。我一般会设三档：正常档用最好的配置，节约档用中等配置，极限档用最小配置保证基本可用。这样成本可控，体验也不会断崖式下跌。

7. 关于"ax"这类运行时，我个人的几点判断

做了几个智能体运行时相关的项目之后，我越来越觉得这个方向的核心难点不在技术，而在取舍。技术上，Kubernetes、消息队列、向量数据库、分布式追踪，这些组件都是现成的，拼起来就能跑。但拼的方式决定了系统的上限。

我的第一个判断是：运行时应该尽量薄。不要把太多业务逻辑塞进运行时，运行时只负责生命周期、调度、状态、可观测这四件事，业务逻辑放在智能体本身。这样运行时稳定，业务灵活。我见过把业务规则写进运行时的，结果每次业务调整都要改运行时，牵一发动全身。

第二个判断是：状态管理是分水岭。原型和生产的区别，八成在状态管理上。原型可以把状态放内存，生产必须外部化、持久化、可恢复。这块做扎实了，系统就稳了一大半。做不扎实，后面全是补丁。

第三个判断是：可观测性要前置。不要等出了问题才加日志，一开始就把事件模型设计好，把追踪埋点埋好。前期多花一周，后期省几个月。这个投入产出比，我试过几次，从来没亏过。

最后一个体会是关于节奏的。智能体运行时这个领域变化很快，新的模型、新的框架、新的基础设施层出不穷。但底层的那些问题——状态、调度、故障恢复、成本控制——是相对稳定的。把精力放在这些稳定问题上，比追新框架划算得多。框架会过时，工程能力不会。