agent-">企业级智能 OnCall Agent 的设计思路与落地经验

智能 OnCall Agent 并不是一个只停留在演示阶段的对话机器人，而是一套面向企业真实运维场景的自动化助手。它的核心目标很明确：降低 OnCall 值班的人力成本，缩短故障发现与排查周期，并把分散在文档、监控、日志、变更记录里的信息整合成一个可执行的处置链路。

很多团队在做 Agent 时，最初遇到的问题并不是“模型不够强”，而是没有想清楚三件事：这个 Agent 到底替谁干活、它最容易在哪一步出错、它失败时人类怎么接管。下面围绕这些问题，拆解一套相对完整的企业级 OnCall Agent 设计思路。

一、先定义 Agent 的边界，而不是先堆模型

OnCall 场景非常容易把范围做大。报警接入、告警聚类、根因分析、自动修复、值班通知、复盘报告，每一块都能单独做一个系统。如果一开始就把这些全部塞进一个 Agent，最终会得到一个什么都想管、但什么都管不稳的“大模型中间层”。

比较务实的做法是划分三类 Agent：

1. 知识库 Agent：负责回答“这个报错是什么意思”“这个服务归谁”“历史上怎么处理过”等检索型问题。
2. 对话 Agent：承接用户自然语言输入，识别意图、补全上下文、将任务分发给其他 Agent 或工具。
3. 运维 Agent：负责执行具体动作，比如查询监控指标、拉取日志、检查变更记录、触发预案或生成处置建议。

这三类 Agent 的关系不是并列的，而是以对话 Agent 作为入口，知识库 Agent 提供背景信息，运维 Agent 完成执行与验证。这样划分后，每一类 Agent 的失败边界也会更清晰。

二、上下文设计比模型选择更关键

OnCall 场景下，模型能力往往不是瓶颈，上下文质量才是。值班同学问一句“支付服务是不是挂了”，如果 Agent 不知道当前时间、不知道关联告警、不知道最近一次发布记录，它只能泛泛回答一段正确但没用的排查建议。

因此，在设计阶段需要重点建立三层上下文：

• 组织上下文：服务归属、负责人、值班表、业务域、SLO 目标等。
• 实时上下文：当前活跃告警、监控指标趋势、最近部署、配置变更、日志错误率等。
• 历史上下文：相似告警的处置记录、相关故障复盘、知识库条目、人工备注等。

这些上下文不是一次性全部塞入提示词，而是随着任务推进按需加载。比如在识别到“支付服务错误率升高”后，再拉取近 30 分钟的网关日志、错误码分布和最近一次发布单。否则 Token 很快被无关信息占满，模型开始出现明显的“注意力稀释”。

三、让工具调用可验证、可回滚

企业级 Agent 与 Demo 的重要差别在于：工具执行必须可验证、可追踪、可停止。

一个反面例子是，Agent 判断磁盘使用率过高，于是自行调用清理脚本。即使判断正确，这种直接执行也可能带来风险。更合理的方式是分级执行：

只读操作：默认允许
低风险操作：需要用户确认
高风险操作：禁止自动执行，只生成方案

具体到实现上，可以为每个工具标注风险等级。比如查询监控数据属于只读操作，重启服务属于高风险操作。Agent 在调用工具前需要输出 action，运行时根据风险等级决定是否中断等待人工确认。

同时，每次工具调用都要记录输入、输出、耗时和结果状态。这样即使模型推理出现偏差，也能通过执行日志快速定位是“理解错”还是“工具失败”。

rag-oncall-">四、RAG 在 OnCall 场景中要解决“版本漂移”

知识库 Agent 并不是简单地把文档切片后塞进向量库。运维知识最大的问题是版本漂移：旧的 Runbook 可能已经不适配新的服务拓扑，错误码表可能落后于最新代码，历史故障记录可能包含错误结论。

因此，在设计知识库检索时需要考虑几个点：

• 文档需要带元数据，包括更新时间、适用服务、维护人、运行环境；
• 检索结果要与当前服务版本或部署环境做过滤，避免返回过期内容；
• 对于“历史上怎么处理”这类经验性问题，需要同时返回处置结果与有效性标注；
• 如果知识库没有高置信度结果，Agent 应当明确回答“未找到可靠记录”，而不是生成一段看似合理的操作步骤。

在检索策略上，可以使用分阶段检索：先按服务名和错误码做精确过滤，再对候选内容做语义重排，最后通过规则约束输出格式。这样能在一定程度上兼顾准确率和召回率。

五、故障排查流程应当显式建模

如果让 Agent 自由发挥排查能力，它很容易在不同假设之间反复跳转。比如一会儿查 CPU，一会儿查网络，过几分钟又回到日志分析。这对值班同学来说不可控，也不容易判断进展。

更合适的做法是让 Agent 遵循显式的排查流程。例如：

Step 1: 确认影响面
Step 2: 检查最近变更
Step 3: 分析核心指标
Step 4: 下钻日志与错误分布
Step 5: 形成根因假设
Step 6: 执行验证动作
Step 7: 输出结论与建议

这种流程可以用 Plan-Execute 模式实现。模型先根据当前告警生成排查计划，再逐步执行。执行过程中，如果发现新证据，允许更新计划，但每一步的状态变化都要可见。这样人类值班同学能知道 Agent 当前在干什么、它已经排除了哪些可能、下一步打算做什么。

六、评估体系要围绕“能接管多少工作量”设计

很多 Agent 项目的评估方式是回答“像不像人”“流不流畅”。但在 OnCall 场景，业务价值更直接：它能否减少人工介入时间、提高第一次响应质量、缩短平均恢复时长。

建议从几个维度建立指标：

• 自动分类准确率：告警或问题能否被正确路由到对应处理类型；
• 首次响应可执行率：Agent 给出的结论是否包含可执行步骤，而不是泛泛建议；
• 知识命中率：知识库 Agent 是否返回了有效内容；
• 工具调用成功率：工具链路的失败率与超时率；
• 人工接管率：哪些问题最终仍需人工处理，原因是什么。

这些指标不需要一开始就追求很高，关键是可持续观测。当某个环节成功率偏低时，能反向驱动知识补齐、工具修复或流程优化。

七、面试与简历中最值得突出的技术点

如果在面试中介绍这个项目，不建议只罗列技术名词。相反，可以从几个工程问题切入，体现真正的深度：

• 如何设计多 Agent 之间的任务边界与通信协议；
• 如何处理工具调用失败与风险分级；
• 如何降低 RAG 检索中的过期内容干扰；
• 如何设计提示词让模型遵循固定排查流程；
• 如何评估 Agent 在真实值班中的效果；
• 如何让模型在不确定时表达“不知道”，而不是盲目生成操作。

这些问题比“我会用某个框架”更能说明你对 Agent 系统有完整认识。面试官在意的通常不是会不会调 API，而是有没有能力把一个模糊需求拆成可落地的系统，并控制它在生产环境中的风险。

八、实践中的常见误区

最后总结几个容易踩到的坑：

1. 盲目追求全自动。OnCall 场景中，自动化的目标不是替代人，而是压缩低效环节。保留人类确认点是工程成熟度，而不是功能缺陷。
2. 把提示词写得过长。过长的 system prompt 会让模型在长对话中逐渐丢失优先级。应根据任务阶段动态组装提示词。
3. 忽视工具返回结构。工具输出如果不做压缩和结构化，会迅速污染上下文。工具返回应尽量返回精简 JSON 或记录 ID，再由 Agent 按需查询详情。
4. 知识库与执行链路脱节。如果知识库说“执行 A 命令”，但工具层没有对应能力，Agent 仍无法落地。知识内容要与可执行工具保持一致。
5. 只做演示场景。演示时路径固定、数据干净，真实环境却是告警风暴、信息不全、权限复杂。要尽早引入真实干扰验证系统鲁棒性。

当这套机制逐渐稳定后，OnCall Agent 不再只是一个“问答机器人”，而是一个能参与值班、能沉淀知识、能持续改进的运维协同系统。它的技术价值不在模型层，而在如何把组织经验、实时数据和执行能力有机地编排到一条可信的处置链路中。