01｜从告警到自动排查：agent 要解决什么

凌晨两点，值班手机弹出一条告警：

[CRITICAL] nginx-05: 502 Bad Gateway on /api/order
upstream: 10.0.0.12:8080
first_seen: 2026-06-26 14:32:01

传统脚本处理这条告警，靠关键词匹配：看到 "502" 就重启 nginx，看到 "timeout" 就扩容。脚本能这么做，是因为它不需要理解告警在说什么，只需要把症状映射到预设动作。

但真实排查不是这样的。一个运维人员看到这条告警，脑子里走的是另一条路：502 是网关错误，问题大概率在上游而不是 nginx 本身；upstream 指向 10.0.0.12:8080，先看这个端口活不活；如果是应用没响应，再看应用日志有没有 OOM 或死锁。这条路径不是固定的，它取决于告警里的对象、上下文和经验。

脚本能做的是"匹配症状触发动作"，做不了的是"理解告警、判断方向、组织证据"。这一层脑力劳动，就是 agent 要替代的部分。

agent 不是更强的脚本

很多人把 agent 理解成"加了 AI 的脚本"，这是第一个要纠正的认知。

脚本是确定性的：输入 A 一定触发动作 B，规则写死在代码里。agent 是不同的工作方式：它读告警，理解现象和涉及对象，决定查什么、怎么查，把查到的证据组织成结论。整个过程中"查什么、怎么查"不是写死的，是模型根据当前告警判断出来的。

差别在哪？看一个具体场景。同样是 502 告警，如果 upstream 是一个数据库连接池打满的应用，和 upstream 是一个 OOM 重启中的应用，排查方向完全不同。脚本只能两个都查一遍，或者靠人提前写好分支。agent 能从告警文本和初步查询里判断出更可能是哪种，先查那个方向。

这不是说 agent 比脚本强。脚本的好处是确定、可预测、成本低——能写死规则的场景，脚本永远比 agent 合适。agent 的价值在那些"规则写不完、需要判断"的场景。告警排查恰好是这种场景：故障组合太多，没法为每种组合预设动作。

一条链路，四个问题

把"收到告警到给出排查报告"这条链路拆开，会看到四个 agent 必须回答的问题：

1. 任务怎么说清楚——告警进来，怎么让模型准确理解"要排查什么"，而不是把症状当原因、把建议当事实。
2. 模型看到什么材料——排查要查日志、指标、Runbook。哪些材料该放进上下文，哪些不该，模型面前的信息怎么管理。
3. 怎么一步步做——查一步、看结果、决定下一步，这个循环怎么设计才能收敛、出错怎么办、什么时候停。
4. 怎么安全地做——让 agent 执行命令、改配置时，怎么防止它干出危险操作，多个 agent 协作时怎么不互相踩踏。

这四个问题对应本系列的四个阶段：提示词设计、上下文设计、循环与控制设计、工程化与协作设计。每个阶段解决一个问题，合在一起才是一个能跑的 agent。

一个贯穿全系列的项目

光讲概念容易空，本系列串一个具体项目：ops-assistant，一个运维排查助手。从一条告警出发，读资料、调工具、生成带证据的排查报告。

这个项目不是最后才出现的，而是跟着概念一起长。第一篇跑通一次模型调用，后面每篇加一个设计决策，到第四阶段末尾 ops-assistant 就成形了。每篇给一段最小可跑骨架验证设计能落地，不追求实现完整——代码 AI 能敲，设计判断 AI 敲不出来，本系列讲的是后者。

agent 的能力半径

最后要明确 agent 能做什么、不能做什么，避免期待落空。

能做的：从告警里提取现象和涉及对象、决定查哪些资料、把查到的证据组织成结构化结论、区分已确认事实和待验证推断。

不能做的：替代真实的环境操作验证。agent 说"建议检查 upstream 端口连通性"，不等于它检查过了。报告里的"建议检查项"是推断，不是已执行的结果。这个区分贯穿全系列——agent 产出的是带证据的排查建议，最终决策和执行仍由人负责。

下一篇先把一次模型调用在本机跑通。讨论 agent 怎么理解任务之前，得先让调用本身稳定工作——配置、环境、错误分类这些不弄清楚，后面的设计都悬空。