运行健康与可观测性
数字员工出问题的方式和传统软件不一样：它很少「崩溃」，更常见的是「还在，但答得不对」或者「已读不回」。这一页说明系统提供哪些信号面、故障时按什么顺序查、以及为什么「明确报错」比「沉默」重要得多。
// 一句话理解
最难排查的故障不是宕机，是假活：进程在跑、端口在听、监控是绿的，但消息进不来或出不去。可观测性设计的第一目标就是让假活变成一个能被看见的红灯。
六个信号面
| 信号 | 回答什么 | 在哪看 |
|---|---|---|
| 请求日志 | 接口被调了吗、多快、返回了什么状态 | 平台日志 |
| 错误日志 | 唯一的真实错误出口，含堆栈 | 平台日志（不对外暴露细节） |
| 操作台账 | 有副作用的动作是否发生、结果如何 | 控制台 · 审计 |
| 服务器健康 | 机器活着吗、磁盘内存够吗 | 控制台 · 服务器 |
| 运行时健康 | 逐个数字员工的网关状态、进程、24 小时错误计数 | 控制台 · 服务器 · 运行时面板 |
| 通道存活 | 每条消息渠道连着没有、最后一次成功收发是什么时候 | 控制台 · 消息渠道 |
故障排查顺序
当有人报告「AI 不回复了」，按这个顺序查通常最快。顺序的依据是「越外层越容易坏」：
- 通道。先看消息渠道的存活状态与最后一次成功收发时间。断流是最常见的原因，而它的表现恰恰是「已读不回」。
- 运行时。看该数字员工所在服务器的运行时面板：网关状态、进程是否在、24 小时错误计数是否异常升高。
- 机器。看服务器本身：CPU 是否顶死、磁盘是否写满、内存是否耗尽。内存紧张的机器会表现为「时好时坏」。
- 凭证。看模型与外部服务的凭证是否过期。凭证类故障应当报告为「降级」而不是「全红」——系统还在，只是某条路走不通。
- 请求与错误日志。用请求标识把一次调用的完整链路串起来，定位到具体是哪一步失败。
// 假活的典型形态
网关进程存在但已经不再接收消息；产出任务卡在某一条坏记录上导致整台机器的统计停滞；一台内存紧张的机器上部分服务被系统回收但主进程仍在。这三种情况下常规存活探测都会返回正常——所以健康检查必须探测「最近一次真实成功」而不只是「进程是否存在」。
三条可观测性纪律
- 日志是结构化的单行记录。不写散文式的调试输出。每条日志一行、字段固定，才能被按请求标识串联、被按时间窗聚合。
- 错误不吞。服务端记录完整的错误与堆栈，客户端只看到不泄露内部结构的错误码。两者通过请求标识关联，排查时凭标识就能拿到全部细节。
- 日志里没有内容。路径、状态、耗时、计数可以进日志；文件内容、对话原文、凭证值永远不进。错误消息里也不允许拼接凭证或带凭据的地址。
健康与降级的区别
把所有异常都报成「故障」会让告警失去意义。系统区分三种状态：
| 状态 | 含义 | 该做什么 |
|---|---|---|
| 健康 | 各信号面正常，最近一次真实成功在预期窗口内 | 无 |
| 降级 | 部分能力不可用但主路可用：某个凭证过期、某条通道断开、某个数据源不可达 | 按影响范围通知对应负责人，不必全员告警 |
| 故障 | 主路不可用：机器不可达、运行时不响应、核心接口持续失败 | 按事故流程处理，先恢复再归因 |
运行时日志的边界
数字员工运行时产生的日志可能包含提示片段与文件路径。这类日志只过境不落库：可以在控制台按时间窗与级别查看，但不会写入平台的任何存储层。每一次查看动作本身进入操作台账，记录查看者、时间窗与文件名——但不记录内容。这样既保证了排障能力，也不让排障过程变成一条新的数据外流通道。