最近 K8s 社区那场关于 Agent Substrate 的对谈我反反复复看了三遍。Kubernetes 之父 Brendan Burns 出来聊“为什么要在 K8s 之上给 Agent 造一层新原语”几乎每一句话都戳在我过去一年做 AI infra 踩过的坑上。过去一年我所在的团队一直在折腾 Agent 平台的底层早期方案就是“把 Agent 当作普通 Pod 跑”后来被多轮会话、记忆持久化、工具权限、多 Agent 协作连续打脸才意识到 Agent 这类工作负载和传统无状态服务有本质区别。这场对谈最大的价值不是讲了一个酷炫的新项目而是用一群人最有说服力的历史视角说清了“原语缺失”这件事。Kubernetes 之所以能统治容器世界是因为它在进程之上抽象出了 Pod、Service、Deployment 这些稳定原语。而 Agent 时代我们其实还在拿这些为“无状态进程”设计的原语硬套“有状态、会推理、能调用工具、还会自己决定下一步做什么”的智能体中间产生的摩擦就是大家天天在群里吐槽的“Agent 没跑几天就崩了”“会话状态不知道放哪”“两个 Agent 互相调参数调死循环”。这篇文章把我对这场对谈的理解以及过去一年在 K8s 上落地 Agent 平台的实操经验一起沉淀下来。我会先拆解“为什么 K8s 现有原语不够用”再梳理 Agent Substrate 这批新原语到底应该长什么样最后给出一个今天就能在 K8s 上动手实现的模拟方案和避坑清单。适合正在做 Agent 平台、AI infra、或者负责把 LLM 应用工程化的同学尤其是那些已经被“Pod 崩了重启但 Agent 忘了自己是谁”折磨过的人。1. 一场对谈引发的思考K8s 和 Agent 之间到底缺了什么1.1 为什么是“K8s 之父”站出来聊 Agent如果抛开标题里的光环这场对谈真正吸引我的是说话人的身份。Brendan Burns 是看着 K8s 从 Borg 论文变成行业标准的亲历者他比绝大多数人都清楚“原语”对一个基础设施层意味着什么。他在对话里反复强调一个观点Kubernetes 解决的是“进程”的编排问题而 Agent 和普通进程最大的不同在于Agent 的行为不是完全确定的它不是一个“启动后按代码路径跑完就退出”的程序而是一个“根据输入、上下文和工具返回结果不断决策”的循环。这个区别听起来很简单但影响非常深远。K8s 里最核心的编排单位是 PodPod 的假设是“里面跑的进程是无状态的、可替换的、死了重启一个新的就行”。可 Agent 一旦跑了多轮对话积累了用户偏好、调用了外部工具、产生了中间推理状态这个“进程”就不能随便被替换。你可能遇到过这种情况模型服务本身好好的Pod 因为节点抖动被重新调度新的 Pod 起来了但 Agent 的会话上下文全没了用户下一句话发过来它像失忆一样重新打招呼。这不是 Bug是我们没有为 Agent 提供正确的编排原语造成的必然结果。对谈里有一句话让我印象很深大意是说我们不该问“Agent 能不能跑在 K8s 上”而该问“K8s 上缺了哪些让 Agent 能好好跑的零件”。这个视角把问题从“容器运行时适配”拉升到了“平台语义设计”这才是真正的 K8s 人思考问题的方式。1.2 Agent 不是“跑在 K8s 里”就够了很多团队的 Agent 落地路径和我最初一样写一个 Python/Node 服务里面封装 LLM 调用、工具调用、会话逻辑然后打一个镜像丢进 K8s配个 Deployment 和 Service觉得万事大吉。Demo 阶段确实能跑一上真实流量就开始连环翻车。问题出在哪Deployment 语义里只有“副本数”和“滚动更新”它不知道一个 Agent 实例正在跟某个用户进行一场有状态的对话也不知道这次对话中还持有了哪些外部工具的资源。HPA 根据 CPU 和内存扩容但 Agent 的瓶颈往往是 LLM 的限流配额、外部 API 的并发限制这类“非 CPU 类”指标。Pod 的重启策略翻来覆去就是 Always/OnFailure/Never但 Agent 需要的是“断点续跑”需要重启后能把之前的会话状态、推理轨迹、工具调用结果重新加载回来。还有一个被低估的地方是观测性。传统服务你打点 QPS、延迟、错误率就够了Agent 你至少还要知道它现在处于思考的哪个阶段、准备调哪个工具、工具返回了什么、它下一步的决策依据是什么。这些信息如果不成为平台原语的一部分而是散落在业务日志里那你根本没法定位一次 Agent 行为异常是模型问题、提示词问题、还是工具链路问题。“跑在 K8s 里”和“被 K8s 正确编排”是两码事。前者是所有 AI 应用都能做到的后者才是 Agent Substrate 想解决的。1.3 Substrate 这个词的真正含义Substrate 直译是“基底”“底层”在生物学里指酶作用的底物在材料学里指衬底。用在 Agent 领域它的意思很明确Agent 不是凭空生长的它需要一个承载它运行、记忆、通信、权限、评估的系统性底座。这个底座不是某一个组件而是一组统一的抽象让上层应用和下层基础设施可以围绕这些抽象协作。你可以把它理解为“Agent 的操作系统”。传统操作系统给进程提供了文件、网络、内存、进程间通信这些原语Agent Substrate 要做的就是给 Agent 提供会话生命周期、持久记忆、Agent 间通信、工具调用策略、权限边界、评估反馈这些原语。K8s 对容器的价值是“把基础设施变成 API”Agent Substrate 对 Agent 的价值是把“智能体运行所需的各种能力变成一组标准 API”。理解了这层再看对谈里提到的各种设计就顺了。Brendan 强调“不要重新发明容器但要重新抽象工作负载”意思是底层调度、资源隔离、节点管理这些 K8s 已经解决得很好的部分继续用但在更上层要为 Agent 这类新工作负载定义新的对象和生命周期模型。所谓“在 K8s 之上造一层新原语”指的是用 CRD、Operator、控制器这种 K8s 天然支持的方式扩展语义而不是另起炉灶再造一套调度系统。2. K8s 现有原语面对 Agent 的四个“不够用”2.1 Pod 描述的是“进程”不是“智能体”Pod 是 K8s 的最小调度单位一个 Pod 里可以有一个或多个容器共享网络和存储。这套模型对微服务非常合适因为微服务的核心假设就是“实例无状态状态放外部存储”。但 Agent 的天然形态是“一个拥有身份、记忆和行为策略的实体”它不完全等价于一个运行中的进程。举个例子同一个 Agent 服务可以同时服务一万个用户会话每个会话是一个独立的 Agent 执行上下文。这时候 Pod 的数量对应的是“服务实例数”而不是“Agent 会话数”。你需要一个能表达“当前有多少个活跃 Agent 会话、每个会话的状态在哪、什么时候销毁”的原语。Pod 没有这个语义kubectl scale 调整的是副本数但无法告诉你某一会话是否已经超出最大轮数、是否需要归档。另一个问题是身份。传统 Pod 的身份由 Deployment 和 label 决定替换后身份基本没意义。但 Agent 有身份它有名字、性格设定、偏好、历史记忆甚至对外部系统来说它有 API 凭证和权限。Pod 的 uid 每次重建都会变没法承载 Agent 身份。你需要的是一个类似 AgentProfile 的持久对象它记录 Agent 的静态配置和动态状态而 Pod 只是它某一次运行的载体。2.2 Service/Ingress 解决南北流量解决不了 Agent 之间的网状通信K8s 的 Service 解决的是“客户端如何访问一组 Pod”的问题Ingress 解决的是“外部流量如何进入集群”的问题它们本质上是南北向的。但 Agent 系统里大量的通信是东西向的一个主 Agent 拆解任务后要调用多个子 Agent子 Agent 之间要交换中间结果Agent 要回调外部系统获取数据。这种通信模式有几个特点第一通信关系是动态的Agent 根据任务现场决定接下来要联系谁而不是启动时静态配置好第二消息不是简单的请求-响应而是带有上下文的异步消息接收方可能需要较长时间思考后才会回复第三通信本身有语义比如“这是一个任务委派”“这是一个结果回传”“这是一个需要确认的问题”这些语义如果只用 HTTP 裸请求来表达那 Agent 框架层就要重复造轮子。Service Mesh 能解决一部分流量治理问题但它管的是 TCP/HTTP 层不懂 Agent 的消息语义。K8s 也没有内置的“Agent 目录”或“Agent 能力发现”机制。你在对谈里能感受到他们的主张需要一个类似 AgentLink 的原语让 Agent 之间可以按名字、按能力、按任务上下文进行寻址和通信并且通信过程能被记录、审计、限流。2.3 Deployment/StatefulSet 管“实例数”管不了“会话生命周期”在 K8s 里如果你要跑一个有状态服务通常会用 StatefulSet配合 PVC 来保证每个实例有独立的存储。但 Agent 的状态模型比这复杂得多。Agent 状态不是一个固定大小的数据库文件而是由多轮对话历史、短期工作记忆、长期用户档案、工具调用轨迹、当前执行计划组成的复合体而且这些信息有各自的更新频率和持久化要求。Deployment 的滚动更新策略也不适配 Agent。你更新一个 Agent 的提示词或者工具列表不能简单粗暴地把所有实例滚动重启因为正在进行的会话需要平滑迁移。理想情况下新版本的 Agent 应该接管新的会话老版本继续处理存量会话直到它们自然结束而不是把用户和 Agent 的“关系”一刀切断。还有扩缩容。Deployment 和 HPA 只关心“实例数量”但 Agent 场景更自然的指标是“活跃会话数”“等待外部工具响应的会话数”“队列深度”。我曾经试过用自定义指标给基于会话数的 Agent 做 HPAKEDA 确实能造这种 trigger但总感觉是拿胶水粘出来的因为底层的 Workload 抽象并不真正理解会话生命周期。2.4 Namespace/NetworkPolicy 的隔离粒度对 Agent 太粗K8s 的 Namespace 是资源隔离和权限控制的主要边界NetworkPolicy 可以做到 IP 和端口级别的网络隔离。但 Agent 场景的隔离维度要更细不同的 Agent 可能共享同一个命名空间却需要不同的工具权限和数据访问范围同一个 Agent 在不同任务里可能被授予不同的权限级别。比如你有两个 Agent一个负责处理客户订单一个负责内部知识库问答。它们跑在同一个 Namespace 里但前者只能调用订单 API后者只能查知识库。这种能力的差异如果只靠 NetworkPolicy 来限制粒度根本不够。你需要的是在 Agent 对象上直接声明它的工具白名单、数据域、模型配额、调用外部服务的凭证。这就是 AgentPolicy 原语要承担的角色。另外K8s 的 RBAC 针对的是“用户操作 K8s 资源”而 Agent 需要的是“Agent 对外部业务系统”的权限模型。这两个体系要打通但又不能混在一起。现有的 Secret、ServiceAccount 可以解决一部分凭证问题但缺少“这个 Agent 在什么情况下可以用这个凭证”这种策略性约束而这恰好是 Agent 安全里最核心的问题。场景维度K8s 现有原语Agent 需要的新原语运行单位Pod无状态进程AgentRun有状态智能体执行单元身份与配置Deployment ConfigMapAgent/AgentProfile持久身份会话状态PVC / 外部存储手工管理AgentState/Memory一等公民服务发现Service / IngressAgentLink按能力寻址隔离与策略Namespace / NetworkPolicyAgentPolicy工具、数据、模型、凭证扩缩容依据CPU / 内存 / 自定义指标会话数 / 任务队列 / 模型限流3. Agent Substrate 新原语拆解给 Agent 造专用“操作系统”3.1 AgentRun一次性任务还是长驻服务Agent Substrate 里我认为最基础的原语是 AgentRun它定义一个 Agent 的一次具体执行生命周期。一个 AgentRun 可能对应一次用户请求、一个自动触发的后台任务或者一个持续运行的多轮工作流。它和 Pod 最大的区别是Pod 的生命周期是“进程从启动到退出”AgentRun 的生命周期是“目标从开始到完成”。AgentRun 要回答的关键问题包括这个 Agent 实例用的是哪个 AgentProfile、模型配置、工具集合它最多允许几轮推理超时时间是多少它的上下文窗口有多大它允许消费多少资源它的执行结果要回到哪里这些信息组合在一起就是一个可以被调度的、可以被审计的、可以被重启恢复的 Agent 执行单元。在我脑中这很像批处理里的 Job但比 Job 智能得多。Job 定义了 Pod 的完成条件AgentRun 定义了 Agent 的完成条件——可能是用户说“结束对话”可能是任务目标达成可能是达到最大轮数也可能是被管理员中止。对于长期运行的客服 AgentAgentRun 可能对应一段连续会话对于离线批量任务型 AgentAgentRun 可能就对应一次任务执行。平台围绕 AgentRun 可以做优雅终止、状态持久化、失败重试和资源回收。apiVersion: substrate.example.com/v1alpha1 kind: AgentRun metadata: name: support-agent-20250401-001 namespace: ai-team spec: agentRef: name: customer-support version: v2 session: timeoutSeconds: 3600 maxTurns: 50 modelRef: name: llm-main provider: internal toolsRef: - order-lookup - refund-api policyRef: name: support-policy resources: cpu: 2 memory: 4Gi status: phase: Running currentStep: tool-call toolName: order-lookup turnCount: 12 lastHeartbeat: 2025-04-01T12:34:56Z这段 YAML 是我结合对谈思路做的模拟示例不代表真实项目接口但能帮我们理解 AgentRun 到底“多管了多少事”。status 里不只有 Pod 的 Ready 状态还有 Agent 当前的推理轮次、正在执行的动作、最近一次心跳。有了这些运维才能真正回答“这个 Agent 到底卡在哪了”。3.2 AgentState / Memory持久状态的一等公民K8s 里 PersistentVolumeClaim 是“一等公民”你可以直接声明我要多大存储。Agent Substrate 里对应的原语是 AgentState但它比 PVC 更明确它要区分短期工作记忆、中期会话状态、长期用户档案和持久知识库。短期工作记忆可以存在于 AgentRun 的上下文缓存里跟着 Run 走中期会话状态要在 Agent 和用户的对话过程中持续保存确保 Pod 重启后会话可以恢复长期记忆是跨会话的Agent 记住用户偏好、历史决策、项目背景。这三类数据的访问频率、一致性要求、备份策略完全不同不应该混在一个对象里。实操中我们会把长期记忆放到外部存储向量数据库用于语义检索、关系库用于结构化偏好、对象存储用于对话历史归档。但平台层要提供统一的读写原语让 Agent 代码调用的是“memory.get(key, namespaceuser_123)”而不是直接拼 SQL 或调向量库 SDK。这样后续你想把底层的存储从一个向量库换成另一个Agent 业务代码不需要改一行。AgentState 还必须处理并发和一致性问题。一个用户的两个请求可能触发两个 AgentRun 同时更新同一个记忆如果不加版本控制可能会互相覆盖。我见过最粗暴的解法是给整个用户加锁结果就是同一用户的请求全部串行体验很差。正确的做法应该是按字段级版本号做条件更新或者用事件溯源的方式合并记忆变更。3.3 AgentLink / AgentMeshAgent 之间的寻址与通信对谈里有个观点我很认同单个 Agent 的能力再强也无法覆盖复杂系统的所有需求产业链最终会走向多 Agent 协作。而 K8s 现有的 Service 模型并不能很好地支撑这种协作。AgentLink 设计上的核心是为每个 Agent 提供一个逻辑地址这个地址与它的运行位置解耦。Agent A 想要调用“订单查询 Agent”它不需要知道对方跑在哪个节点、哪个 Pod只需要通过某种目录服务做能力寻址。K8s DNS 能做一部分但 Agent 目录不只是 DNS它还要带元数据这个 Agent 当前忙不忙、支持哪些工具、有什么输入输出约束、是否接受委派。通信协议方面我倾向于基于消息队列而不是直接 HTTP。因为 Agent 的处理时间不可控LLM 一次推理可能要几秒一个复杂子 Agent 可能要几十秒直接 HTTP 同步等待会浪费大量连接资源。基于消息的异步通信能让 Agent 之间解耦主 Agent 发出任务后可以订阅结果事件。K8s 生态里 Kafka、NATS、RabbitMQ 都是现成的底座但平台层需要给它们包一层 Agent 语义让消息带上任务 ID、协议版本、上下文快照、安全令牌。另一个容易忽略的点是通信的审计与追溯。多 Agent 协作一旦出问题你得能回放整个消息链路。所以每个 Agent 间消息都应该有不可变的 trace ID并且在平台层长期保存。这在技术实现上不复杂但如果不从原语层面强制业务代码往往会嫌麻烦而不打。3.4 AgentPolicy准入、配额与安全边界如果说 AgentRun 是“执行力”AgentLink 是“协作力”那 AgentPolicy 就是“安全感”。Agent 可以调用工具、访问数据、调用模型这些都是有成本、有风险的行为必须受策略约束。AgentPolicy 可以定义以下内容这个 Agent 允许调用哪些工具每个工具的频率限制是多少这个 Agent 可以访问哪些数据域不能访问哪些这个 Agent 使用哪个模型服务最大 token 预算是多少在什么条件下这个 Agent 可以升级权限、需要谁审批外部工具的凭证从哪获取是否允许缓存。安全方面的挑战在于Agent 的工具调用是动态产生的你没办法在部署前穷举所有可能的调用。所以策略必须能实时评估“这次调用是否被允许”而不是静态绑定在镜像里。K8s 生态里的 OPA/Gatekeeper、Kyverno 可以做准入控制但对 Agent 来说策略评估的时机不止是创建时还包括运行中的每一次工具调用和每一次数据访问。作为平台方我在落地的时候给出的最小可行方案是Agent 的所有工具调用都经过一个统一的 ToolGatewayToolGateway 根据 AgentPolicy 做鉴权和限流。Agent 本身永远不直接持有外部 API 凭证它只持有 ToolGateway 签发的短期令牌令牌作用域精确到“哪几个工具、多长时间、调用多少次”。这样即使某个 Agent 的提示注入导致它想调用危险工具ToolGateway 也能拦下来。3.5 和 Kubernetes 原生原语的关系不是替代是组合有人听到“给 Agent 造新原语”第一反应是“又来一个想替代 K8s 的东西”。对谈里其实说得很清楚不是替代而是在 K8s 的能力之上延伸。AgentRun 最终还是要调度成 Pod 去跑AgentState 最终要落到 PVC 或外部存储AgentLink 的服务发现最终还是要依赖 K8s DNS 或 etcdAgentPolicy 的执行最终还是要靠 RBAC、NetworkPolicy、Secret 来承载。正确的做法是把 Agent 原语定义成 CRD用 Operator 控制器把 Agent 原语翻译成 K8s 原生资源。Operator 负责监听 AgentRun 的创建为它创建相应的 Deployment 或 StatefulSet并把 AgentState 对应的存储挂载进去。上层用户面对的是 Agent 语义底层平台复用 K8s 的调度、自愈、滚动升级能力。这样你既没有丢掉 K8s 生态也不用逼着用户去理解 Pod 的细节。对平台团队成员来说这种架构还有个好处你可以分阶段交付。先做 AgentRun 和 Operator把生命周期管理落地再做 AgentLink把通信打通最后做 AgentPolicy把安全和治理补上。每块都能独立产生价值不用等一个“大而全”的平台。4. 如果今天就要落地怎么在 K8s 上“模拟”这套原语4.1 最小闭环用 CRD Operator 定义 AgentRun真实场景中你不可能等社区标准定了再动手。我的建议是先搭一个最小闭环写一个 AgentRun CRD再写一个简单的 Operator把 AgentRun 转换成 Deployment 加 PVC。今天就能用后续标准演进时再迁移。CRD 的 schema 不要一上来就设计得很复杂先包含最关键字段agent 镜像地址、模型配置、工具白名单、会话超时、内存/CPU 配额、持久状态开关。我第一版就吃了设计过度的亏字段写了一堆结果 Agent 团队根本填不满最后还得我来维护默认值。最小可用版本比完美版本更有价值。Operator 的实现可以用 kubebuilder 或者 operator-sdk核心逻辑并不复杂watch AgentRun 资源创建对应的 Deployment 和 PVC更新 AgentRun 的 status。难一点的地方在于“会话恢复”如果 Pod 被重启新 Pod 启动时要能读取 PVC 里的会话快照并带着完整上下文继续服务。这部分建议在 Agent 框架层配合Agent 启动时先尝试从固定路径加载 state 文件存在就恢复不存在就初始化新会话。# 创建 AgentRun 资源 kubectl apply -f agentrun.yaml # 观察状态流转 kubectl get agentruns.substrate.example.com -n ai-team -w # 查看某个 AgentRun 的详细信息 kubectl describe agentruns.substrate.example.com support-agent-20250401-001 # 查看对应 Pod 日志 kubectl logs -l substrate.agent/run-idsupport-agent-20250401-001 --tail100这套流程跑通之后你就有了一台“能感知 Agent 会话”的 K8s 控制面。Agent 团队不再关心 Pod 叫什么、PVC 怎么挂他们只需要提交 AgentRun平台自动处理其余部分。4.2 记忆层选型与挂载设计记忆层是 Agent 平台最容易纠结的地方因为市面上选项太多Redis、PostgreSQL、Elasticsearch、Milvus、Chroma、MongoDB。我的经验是先按数据类型拆不要一个库解决所有问题。对话历史和事件流用普通的关系库或对象存储量大但没有高并发检索需求用户偏好和结构化属性用 Redis 或键值库访问延迟要低需要语义检索的长期知识用向量数据库。平台层封装的时候可以做成类似存储适配器的接口内部实现可替换。PVC 能不能做记忆层短期可以但我不建议把重要记忆放在本地 PVC 上。原因一是节点故障时 PVC 的恢复涉及存储迁移耗时不可控原因二是多个 AgentRun 可能要共享同一份记忆PVC 的 ReadWriteOnce 模式不方便原因三是 Agent 平台大概率要跨集群容灾本地 PVC 根本不是对手。所以我的方案是Pod 本地 emptyDir 只放临时工作缓存重要状态实时同步到独立的状态服务PVC 主要供 Agent 框架写入可恢复的会话快照。还有一个设计细节记忆的写入要支持事务和版本号。Agent 的决策链很长期间用户可能又发来一条消息如果你不加并发控制后完成的写入可能会覆盖先完成的。我们在代码里用类似 CAS 的机制每次写入都带上 based_on_version发现版本冲突就把两个版本做合并或者把冲突事件抛给上层 Agent 决策。4.3 通信层从 Service Mesh 到消息总线Agent 之间的通信体系我建议分两步走。第一步先引入消息总线保证 Agent 之间能异步收发任务和结果。这一步技术上很成熟NATS 或者 Redis Streams 都能胜任关键是消息格式要标准化消息头里必须带 taskId、senderAgent、receiverAgent、contextVersion、timestamp。有了这五个字段审计和追踪就有基础。第二步才考虑做 Agent 目录和动态寻址。这一步的价值在于让主 Agent 能动态发现“谁能完成这个子任务”。实现上可以借用 K8s 的 Service 加上自定义元数据为每个 Agent 创建一个 Service同时在 Service 的 annotation 里注册它的能力描述然后做一个轻量级目录服务读取这些信息。Agent 发起协作时先向目录服务问“谁支持 refund 这个工具”拿到候选列表后再投递消息。关于 Service Mesh它主要管的是东西向流量的安全、重试和可观测性。如果 Agent 问的通信走 HTTP 同步调用把 Agent 纳入 Service Mesh 是有好处的。但如果是异步消息模式Service Mesh 的熔断和重试语义就派不上大用场这时候需要的是消息队列自己的限流和死信处理。所以不要盲目迷信 Service Mesh先搞清楚你的 Agent 协作是同步还是异步。4.4 可观测性日志/链路/评估三板斧Agent 的可观测性比传统服务多一个维度不仅要看系统健康还要看智能体行为是否合理。我把它拆成三条线系统可观测性、行为可观测性、质量可观测性。系统可观测性沿用 K8s 那套metrics、logs、traces 三件套关注 CPU、内存、LLM 调用时延、Token 消耗量。行为可观测性要记录 Agent 每一步的决策过程它接收了什么输入、选择了什么工具、工具返回了什么、最终生成了什么决策。我会强制要求所有 Agent 运行时把决策轨迹以结构化日志输出方便回放。质量可观测性是最容易被忽略的。Agent 的响应没有简单的“对错”之分需要引入评估体系对简单任务可以做规则校验比如是否包含必要字段对复杂对话可以接离线评估模型定期抽样打分。评估结果要回写到 AgentRun 的 status 里这样平台才能在发布新提示词版本时比较新旧版本的质量分数决定是否灰度放量。4.5 一套可复制的参考架构把上面这些串起来我脑子里比较稳定的一套拓扑是这样的用户请求进入 API GatewayGateway 创建或关联一个 AgentRunAgentRun 被 Operator 翻译成实际 PodPod 内的 Agent 运行时负责 LLM 交互和工具调用AgentState 服务负责记忆的存取ToolGateway 作为所有外部调用的唯一出入口AgentLink 目录服务负责多 Agent 协作的寻址可观测性组件采集系统和行为日志。这套架构不需要一次全部建设可以按“单 Agent 跑通 → 有状态 → 可协作 → 有治理”的顺序推进。每一步都能看到明确的收益也让团队技术在演进中逐步沉淀。关键是不要用“我们还没有标准”当借口拖延K8s 自己也是从 Borg 论文里的一个小原型长成今天的规模的。5. 实际踩坑记录与排查清单5.1 Agent 优雅退出比容器退出难十倍K8s 里给 Pod 配 preStop hook 和 terminationGracePeriodSeconds对普通服务来说已经够用。但 Agent 多了一步它可能正在调用外部工具可能正在生成一段长回复退出前必须决定是否保存当前进度、是否需要回滚半成品、是否需要通知上下游 Agent。我们遇到过一次线上事故Agent 在调用外部支付接口的途中Pod 因节点排空被 evict视同进程被强杀。结果订单那边生成了支付请求Agent 这边没来得及记录状态用户回头来查订单时 Agent 一脸懵。后来我们的解决方案是在 AgentRun 上显式声明 gracefulTimeout让 Operator 在收到 Pod 删除请求后先通知 Agent 暂停推理、落盘状态、归还工具令牌再真正停止容器。这个通知必须走业务级信号不能只依赖 SIGTERM因为 Agent 的状态往往跨多个服务需要协调处理。5.2 并发执行时的资源配额审计Agent 和传统服务的资源画像完全两样。传统服务 CPU 是主要资源Agent 这边模型调用次数和 Token 消耗可能比 CPU 更容易成为瓶颈。K8s 的 ResourceQuota 能限制 CPU 和内存但没法直接限制“每个 AgentRun 最多调用模型 500 次”。我们的做法是在平台层做配额核算每个 AgentRun 创建时分配一个预算包含 token 上限、工具调用次数上限、总耗时上限。Agent 运行时要通过平台中间件上报消耗超过预算就自动降级或者中止任务。这个机制帮我们解决了一个很现实的问题某些 Agent 在缺少明确约束时会因为提示词写得不好陷入无限循环一次任务把一个月预算烧光。预算体系的本质是给不可控的行为加一个硬边界。5.3 多 Agent 协作时的循环依赖和调用风暴多 Agent 协作上线后最典型的故障是两个 Agent 互相丢任务谁也不真正推进形成逻辑死循环。更隐蔽的是“扇爆”一个主 Agent 同时给 30 个子 Agent 下达任务子 Agent 各自执行时又产生新的子任务数量指数级增长直接把消息总线打爆。排查这类问题最重要的就是链路 ID 和深度限制。我们在 AgentLink 的消息头里加了 hopCount 字段每经过一个 Agent 加一超过阈值直接拒收并上报异常。同时在主 Agent 侧限制每轮最多生成多少个子任务。这套约束让协作系统的行为变得可预测也让异常能被快速发现。5.4 误删状态存储导致 Agent 身份丢失这是我在测试环境犯过一次的低级错误清理资源时执行了 kubectl delete pvc --all结果把十几个 Agent 的长期记忆全删了。Agent 本身还能启动但所有用户偏好、历史对话都没了对用户的回答变成“我们不认识”。这次事故让我明白Agent 状态存储必须在平台层面做保护核心记忆卷加上 finalizer删除 Agent 前必须先导出归档生产环境的存储开启跨集群备份任何批量删除操作必须经过策略审核。5.5 常见问题速查表现象可能原因快速排查动作Agent 重启后失忆会话状态没有持久化检查 AgentState 是否挂载、启动时是否执行恢复逻辑Agent 长时间无响应卡在等待工具返回查看当前的 tool-call 状态、外部 API 是否超时多个 Agent 互相反复调用缺少协作终止条件检查 hopCount、任务超时、死循环检测Token 消耗异常飙升提示词循环、无预算约束查看 AgentRun 配额、审计工具调用频率工具调用被拒绝但无日志策略评估链路断了查看 ToolGateway 日志、确认 AgentPolicy 已生效会话恢复后上下文错乱记忆版本冲突、覆盖写入检查版本号、事件合并策略排查 Agent 问题时我自己的习惯是先用 kubectl describe agentrun 看当前阶段再用行为日志回放最后几轮决策最后才去看系统指标。顺序反了很容易被 CPU 占用、Pod 重启这类表面现象带偏浪费半天时间才发现根本原因是工具返回的格式不满足提示词里的要求。把 Agent 当成真正的 Workload而不是 Pod 的附属品是我这一年最大的体会。Agent Substrate 里的很多原语现在看像是一种“理想标准”但哪怕只吸收了其中一部分设计思路也能让平台的稳定性上一个台阶。先跑起来在真实流量里迭代你很快会知道自己缺的到底是哪个零件。