智能OnCall Agent开发实战经验总结

agent">一、从痛点出发：为什么OnCall需要Agent

传统OnCall值班存在三类典型痛点：

1. 人力成本高：告警是7×24小时出现的，但人只能排班值守，夜间响应慢、疲劳作战，团队长期背着值班负担；
2. 经验强依赖：故障排查高度依赖个人对系统的熟悉程度，新人面对告警无从下手，资深同学离职就出现知识断层；
3. 重复劳动多：大量告警其实是历史已知问题的复发，每次都要人工把排查路径重新走一遍，性价比极低。

Agent的核心价值在于：以大模型为“大脑”，把散落在知识库、监控系统、日志服务、工单平台里的能力串联起来，把“自动应答”和“智能排查”变成一条流水线。目标不是取代人，而是把人从重复劳动中解放出来，只处理真正需要人类决策的部分。

二、架构设计：三大核心Agent的分工与协同

第一条经验：不要一上来就幻想一个全能Agent，先按职责拆分。

• 知识库Agent：管“知道什么”。基于RAG，从故障预案、历史案例、操作手册、内部Wiki中检索依据，回答“这是什么问题、之前是怎么处理的”；
• 对话Agent：管“怎么沟通”。作为统一入口做意图识别与路由，理解值守同学模糊的提问，必要时多轮澄清，并把中间过程与结论组织成人类可读的报告；
• 运维Agent：管“能做什么”。把监控查询、日志检索、服务状态检查、工单创建等操作封装成工具，按排查逻辑逐步调用。

协同链路示意：

用户提问
   -> 对话Agent意图识别与路由
   -> 知识库Agent检索依据 / 运维Agent调用工具查现场
   -> 结果汇总
   -> 对话Agent生成"结论 + 依据 + 建议动作"
   -> 低置信度时转人工

两种组织方式的取舍：多Agent编排职责清晰、各自上下文干净，适合能力域较多的大型系统；单Agent多工具实现简单、链路短，适合初期快速落地。实践建议是：先单Agent多工具跑通闭环，规模上来后再拆分——过早拆分只会引入复杂的路由问题。

三、核心技术拆解：把名词变成原理

1. System Prompt与User Prompt：角色与任务的分界线

System Prompt定义Agent的身份、职责边界、输出格式与安全约束，全局生效；User Prompt承载当次任务输入。常见错误是把关键约束写在对话内容里，多轮之后模型就“忘掉”了规则。一个可参考的System Prompt骨架：

# 角色
你是团队OnCall助手，负责告警答疑与初步排查。
# 可用工具
- query_monitor：查询监控指标
- search_logs：检索日志
- search_kb：检索知识库
# 行为约束
1. 不确定时明确说明，禁止编造指标数值与故障原因；
2. 所有结论必须来自工具返回结果或知识库检索内容；
3. 只读操作自动执行，写操作（重启、变更）必须请求人工确认。
# 输出格式
按"结论 / 依据 / 建议动作"三段式输出。

经验：把Prompt当代码管理——版本化、变量化、可回归测试。改一句话都可能导致行为漂移，没有评测就上线等于裸奔。

2. Function Calling与Tools：让模型有手

原理：应用层把工具的名称、用途、参数结构随请求一并传给模型；模型在需要时输出结构化的“调用意图”而非自然语言；真正执行由应用代码完成，再把结果回喂给模型继续推理。模型只“点菜”，不“下厨”——这一点决定了所有安全控制都必须在应用层实现。

工具设计的实战经验：

• 工具描述就是给模型看的API文档，参数含义、取值范围要写清楚，模糊描述必然带来错误调用；
• 单个Agent的工具数量要克制，工具过多会显著增加选错工具的概率，可按域拆分或加一层工具路由；
• 工具返回内容要做裁剪，只返回与问题相关的字段——把整段日志原文塞进上下文是最常见的成本杀手；
• 读写分级：只读工具放开自动调用，写操作必须走人工确认。

3. MCP：工具接入的标准化

Function Calling解决“模型怎么调用工具”，但每个系统都自建一套工具接入与鉴权，重复成本很高。MCP（Model Context Protocol，模型上下文协议）这类标准化协议解决的是“工具怎么统一接入”：把模型与工具、数据源之间的连接方式标准化，工具提供方实现一次服务端即可被多个Agent复用，鉴权、传输、能力描述都有统一约定。实践建议是把内部监控、日志、工单等平台能力统一封装为标准化工具服务端，Agent侧按协议接入，避免每个Agent重复开发胶水代码。

rag-agent-">4. RAG：让Agent掌握私有知识

大模型不知道你们团队的内部故障案例，所以需要RAG（检索增强生成）：文档切分 → 向量化入库 → 检索 → 重排 → 生成，让模型“开卷考试”。踩坑总结：

• 切分策略的影响远大于模型差异：按语义与文档结构切分、保留标题层级作为上下文，比机械按固定字数切效果好得多；
• 只用向量检索不够：错误码、告警关键词这类精确匹配场景，关键词检索或混合检索往往更准，再叠加重排提升相关性；
• 回答要引用出处：附上来源文档与片段，让值守同学可以验证，这是建立信任的关键；
• 知识库治理优先于算法：过期文档比没有文档更可怕，错误答案会直接误导排查方向。

四、设计模式：ReAct与Plan-Execute怎么选

ReAct（Reasoning + Acting）的循环是：思考 → 行动 → 观察结果 → 再思考，直到得出结论。以“接口5xx飙升”告警为例：先查监控定位异常实例 → 拉取该实例错误日志 → 发现数据库连接超时 → 检索知识库匹配历史预案 → 输出结论。每一步都依赖上一步的观察，天然适合排查这种“事先不知道路径”的任务。

Plan-and-Execute则先让模型生成完整执行计划，再逐步执行，发现偏差时重新规划。适合步骤相对确定的长链路任务，比如例行巡检。

选型经验：排查类任务选ReAct；流程明确的任务选Plan-Execute或直接用确定性工作流编排，别让模型自由发挥；生产系统常用混合形态——外层做任务规划与拆解，内层子任务用反应式执行。无论哪种模式，都要设置最大步数与超时，防止模型陷入死循环空烧token。

五、工程落地避坑清单

1. 幻觉控制是第一优先级：通过检索提供事实依据、明确拒答策略、强制结论引用工具返回，让Agent宁可承认不知道，也不编造；
2. 没有可观测性就没有调试：完整记录每次推理的Prompt、工具调用链、参数、返回、token消耗与耗时，出问题能完整回放；
3. 评测先行：整理典型告警问答评测集，任何Prompt、模型或检索策略变更先跑回归，比肉眼评估靠谱得多；
4. 人机协同兜底：置信度低、超出权限范围、涉及写操作的场景一律转人工，Agent的定位是“一级响应助手”而非“无人值守”；
5. 控制成本与延迟：上下文不是越长越好，热点问题答案做缓存，工具返回做压缩；
6. 善用框架但别依赖框架：主流语言生态中都有成熟的大模型应用开发框架，提供Prompt模板、工具抽象、RAG组件与编排能力。建议先理解Function Calling、检索、编排的原生机制，再用框架提效——面试官问的是原理，不是API怎么调。

六、给学习者的路线建议

从概念到能力，建议按四个台阶递进：第一步搭最小RAG问答，吃透切分、检索、生成全链路；第二步做单工具Agent，彻底理解Function Calling的“请求—执行—回喂”闭环；第三步做多工具ReAct Agent，体会规划与纠错；第四步做多Agent协作系统，处理路由、上下文隔离与结果汇总。

每一步都问自己三个问题：模型怎么知道该调哪个工具？结果不对怎么归因？怎么证明比上一版更好？能把这三问答清楚，Agent开发的核心就算真正入门了——这些能力无论对实际项目还是求职面试，都是实打实的加分项。