生命周期与健康检查

五种状态

一条部署记录的状态是这几个之一：

源码DeploymentStatusagent-runtime/management/openjiuwen_runtime/management/models/enums.py:16@0a47a523

running 不等于能用

进程起来了，不代表智能体能回答问题：可能还在加载模型配置、连接数据库。所以部署管理器在部署器报告成功之后，还要等它就绪：

1. 读部署记录，状态是 running
2. 有访问地址的话，请求 地址/health，返回 2xx 才算就绪
3. 不满足就等 20 秒再查；状态变成 failed 立即报错
4. 600 秒还没就绪，报超时；外层把状态标为 failed

源码_wait_until_deployment_readyagent-runtime/management/openjiuwen_runtime/management/manager.py:387@0a47a523

探活还有一个贴心的兜底：配置的对外 IP 可能被本机访问策略拦住，主地址探活失败时，会把主机换成 127.0.0.1、端口不变再试一次。

源码_check_health_endpointagent-runtime/management/openjiuwen_runtime/management/manager.py:365@0a47a523

子进程部署器自己也有一道检查：启动后等 2 秒，如果进程已经退出，就从日志文件里读出错误信息，直接判失败。

停止与删除

查询状态时，策略层还会问一次部署器"实际状态"：如果实际已经停了而记录还是别的，就把记录改成 stopped。

企业运维要补什么

Runtime 给的是"拉起、等就绪、停止、删除"这些基本动作。生产环境通常还要自己补：

• 持续健康检查：上面的探活只发生在部署时；运行中的实例要靠容器平台的探针或外部监控
• 重启策略：本关核实的子进程部署器里没有看到进程退出后自动拉起的逻辑；用 Kubernetes 部署时，由集群的 Deployment 负责重建 Pod
• 团队里的异常：智能体"活着但卡住"这种情况，探活发现不了，要靠 agent-core 的 ReliabilityRail

动手：预测部署结果

小结

• 部署完成要等到 running 且 /health 通过，默认最多 600 秒。
• 失败、超时都会把记录标成 failed；子进程起来 2 秒就退出会被立刻发现。
• 部署时探活只是第一道检查，运行中的健康要靠平台探针和监控。