Agent 云原生运行时智能体也需要健康检查一、Agent 服务不是普通脚本很多 Agent 原型从脚本开始能跑任务、能调用模型、能写结果。但一旦进入云原生环境它就要像普通服务一样接受健康检查、配置管理、日志、指标、灰度和回滚。智能不代表可以跳过工程纪律。Agent 服务的特殊之处在于状态长、调用链复杂、外部依赖多。模型、工具、检索、队列任何一环出问题都会影响结果。运行时必须把这些依赖纳入健康检查。二、健康检查要分层flowchart TD A[Agent Pod] -- B[liveness] A -- C[readiness] C -- D[模型路由] C -- E[工具服务] C -- F[向量检索] C -- G[队列]liveness 检查进程是否活着readiness 检查是否能接请求。Agent 的 readiness 不应只返回 200还要确认关键依赖可用。模型路由不可用时可以不接新任务工具服务不可用时可以降级到只读模式。健康检查也不能太重。每次检查都打真实模型会浪费成本还可能放大故障。可以检查路由状态、短超时探测和缓存状态关键是快速判断服务是否可用。三、任务状态要外置agent_task: id: task_7788 phase: tool_calling retry_count: 1 owner_pod: agent-5Agent 任务不能只放在 Pod 内存里。Pod 重启、驱逐、滚动发布都会丢状态。长任务要把状态写入外部存储Pod 只是执行者。这样服务重启后可以恢复或重新调度。还要设计幂等。工具调用已经执行但 Agent Pod 在记录结果前崩溃后续重试可能重复执行。工具层要有幂等键任务层要能识别未知状态并查询确认。pod restart - load task state - resume or reconcile四、发布要考虑长任务普通服务滚动发布时旧 Pod 停止接流量处理完请求后退出。Agent 长任务可能运行几分钟甚至更久需要 drain 机制。发布前标记旧 Pod 不接新任务等待当前任务完成或安全转移。指标要覆盖任务维度。任务成功率、平均步骤数、工具失败率、模型超时率、恢复次数都比普通 HTTP 状态码更能反映 Agent 健康度。配置也要外置。模型名称、工具白名单、最大步骤数、超时和降级策略不应该写死在镜像里。云原生运行时的优势是让策略能灰度调整而不是每次改预算都重新构建镜像。日志要记录任务链路但不能泄露完整用户内容。可以记录 task_id、step_id、工具名、耗时、状态和内容 hash。Agent 经常处理敏感输入观测设计必须同时考虑排障和隐私。多副本场景要避免重复消费。队列任务被一个 Pod 领取后要有租约和心跳。Pod 挂掉后租约过期其他 Pod 再接手。没有租约机制可能出现两个 Agent 同时执行同一任务。最后运行时要支持模式切换。依赖异常时进入只读模式模型异常时进入低成本模板模式工具异常时关闭写操作。运行时能降级Agent 才不会一出问题就整体停摆。资源隔离也要做好。不同租户、不同任务类型最好有独立队列或权重避免一个大任务占满所有 worker。云原生环境里可以用队列优先级、命名空间配额和 HPA 策略组合控制。安全上下文不能忽视。Agent Pod 如果能访问过多 Secret 或内部服务一次提示注入就可能扩大影响。运行时应限制服务账号权限只给当前任务需要的资源。智能体越能行动Kubernetes 权限越要收紧。五、总结Agent 云原生运行时要有分层健康检查、外置任务状态、幂等工具调用和长任务发布策略。智能体服务也要像普通生产服务一样可观测、可恢复、可回滚。会思考不等于可以不健康检查。