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-5

Agent 任务不能只放在 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 云原生运行时要有分层健康检查、外置任务状态、幂等工具调用和长任务发布策略。

智能体服务也要像普通生产服务一样可观测、可恢复、可回滚。会思考不等于可以不健康检查。