把 Agent 当服务运维：长期运行的工程纪律

多数人第一次跑 Agent 任务是这样的：写一段脚本，手动触发，看着它跑完，满意地关掉终端。这是 demo 思维。

麻烦出现在你开始依赖它的时候——定时跑、后台跑、让它操作真实数据、和下游系统集成。这个阶段，「模型能不能完成任务」已经不是主要问题，主要问题变成了：跑失败了我能不能发现？失败了能不能回退？有人权限太宽导致误操作了吗？上个版本和这个版本的行为差异在哪？

这些问题和传统服务运维完全一样，只是很多做 AI 工程的人没有意识到这一点，把 Agent 当「聪明脚本」在用，结果出了事就是一团乱。

四个运维域

我把长期运行的 Agent 系统拆成四个要管的领域：

生命周期：启动、暂停、停止、重启要有明确的操作方式，不能只靠 kill 进程。暂停要区分「软暂停」（当前任务跑完再停）和「硬停」（立即终止）。重启后要能从中断点续跑，不是从头来。

可观测性：三件套缺一不可——日志（发生了什么）、指标（健不健康）、追踪（为什么失败）。Agent 任务有个特殊的地方：一次「任务」可能跨越几十次工具调用，trace 必须把这整条链串起来，不然你根本分不清是哪一步出了问题。

安全边界：最小权限原则在这里比在普通服务里更重要，因为 Agent 有自主决策能力——给了多余权限，它在某个错误的推理链下真的可能去用。凭证要走环境注入，不硬编码；每个 Agent 实例只持有它那次任务需要的最小权限集；高风险操作要有硬断路器，不依赖模型「自己判断」要不要执行。

变更管理：这一条最容易被忽视。Agent 系统的「变更」不只是代码变更，还包括提示词变更、模型版本切换、工具 schema 变更。每次变更都要走灰度，要留审计日志，要有一键回滚路径。「我改了提示词效果应该更好」不是灰度的理由，「我观察了 100 次任务的成功率没有下降」才是。

五个基线指标

跑起来之后，持续追踪这五个数就够了：

• 成功率：最直接的健康信号
• 平均重试次数：这个数升高意味着某个环节开始不稳，还没挂但快了
• 恢复耗时：从失败到重新正常，这段时间越短，工程越健壮
• 单次成功任务的成本：防止模型在无效路径上反复打 token
• 失败类型分布：超时、权限拒绝、模型幻觉、下游不可用——各自占比，决定下一步优化重心

这五个指标的意义不只是监控，更是提前感知系统退化。成功率还没掉，但平均重试次数开始爬升，这就是信号。

出事了怎么处理

故障处理有一个反直觉的原则：先冻结，后诊断。

很多人第一反应是赶紧回滚或者赶紧修，结果是在系统还在混乱状态下做操作，把证据覆盖掉，或者引入更多变量。

我用的顺序是：

1. 先冻结新发布，防止问题扩散
2. 采集代表性的失败 trace，搞清楚是哪类失败、在哪个环节
3. 隔离失败的路由或任务类型，让其他部分继续跑
4. 用最小的变更修，不要顺手「重构」
5. 修完先跑回归测试和安全检查
6. 逐步恢复流量，观察指标是否回到基线

这个顺序和传统服务故障处理几乎相同。Agent 系统没有任何理由搞一套「AI 特供」的应急流程。

一句话心法

Agent 跑得越久、越自主，运维纪律就越重要——不是因为 AI 特殊，而是因为所有长期运行的系统都需要这些。