agent-">企业级智能OnCall Agent开发经验与架构实践

智能OnCall Agent并不是一个简单的对话机器人，而是一套面向企业级运维场景的自动化助手系统。它的核心价值在于将传统OnCall值班中大量重复、低效的人工排查工作，转化为由多个Agent协同完成的自动化流程。对于开发者而言，构建这样一个系统，难点不在于调用某个大模型接口，而在于如何把知识库、对话能力、运维操作三者有机整合，形成稳定、可扩展、可观测的工程体系。

本文结合一个实际企业级项目的设计经验，从系统架构、Agent职责划分、提示词工程、工具调用、RAG、设计模式以及面试准备等维度，整理一套可复用的实践经验。

一、为什么要做智能OnCall Agent

传统OnCall值班存在几个明显痛点：

1. 人工值守成本高：团队需要安排人员7×24小时待命，但大部分告警并非真正紧急故障，人力浪费严重。
2. 排查链路长：接到告警后，值班人员需要登录多个平台查看监控、日志、变更记录，再结合经验判断根因，平均排查时间可能达到数十分钟。
3. 知识沉淀困难：老员工的排查经验往往存在脑子里，没有结构化的知识库，人员流动会导致经验流失。
4. 重复问题反复处理：大量相似问题反复出现，每次都需要从头排查。

智能OnCall Agent的目标就是通过AI能力将这些环节自动化：自动应答常见问题、自动执行标准化排查流程、自动关联历史知识，最终降低对人工值守的依赖。值得注意的是，这类系统不是为了完全替代人，而是先承担“第一道过滤”的角色，让人聚焦在真正复杂的问题上。

二、整体架构设计

企业级Agent系统不能只用一个模型调用就完事，需要分层设计。一个典型的智能OnCall Agent架构通常包含以下层次。

2.1 接入层

接入层负责接收来自不同渠道的事件和请求。对于OnCall场景，输入可能来自：

• 告警系统推送的告警事件；
• 用户在聊天工具中主动发起的提问；
• 定时巡检任务触发的异常检测结果；
• 其他内部系统通过API回调触发的请求。

接入层需要做统一的消息标准化处理，将不同来源的数据转换为内部统一格式，包括事件类型、时间戳、来源系统、原始载荷、严重级别等字段。

2.2 调度层

调度层是系统的中枢，负责将标准化后的请求路由到合适的Agent。这里的关键设计是意图识别与分级：一个进来的请求到底是简单问答、复杂排查还是运维操作，需要先做一层判断。

工程上可以采用“规则先行、模型兜底”的策略。对于能通过关键词、正则、来源系统直接判定的请求，直接走规则路由，降低延迟；对于规则无法覆盖的情况，使用大模型进行意图分类，再做路由。

2.3 Agent执行层

执行层包含三类核心Agent，后面会详细展开：

• 知识库Agent：负责从企业知识库中检索相关文档、历史工单、FAQ，并生成回答。
• 对话Agent：负责与用户进行多轮交互，澄清问题、确认意图、引导排查。
• 运维Agent：负责实际执行运维动作，如查询监控数据、拉取日志、检查服务状态，甚至执行预定义的修复操作。

2.4 工具层

工具层是Agent与真实世界交互的桥梁。工具的设计质量直接决定了Agent的可用性。工具可以是查询类（只读操作），也可以是执行类（写操作）。对于运维场景，工具层需要特别关注：

• 权限控制：哪些工具可以被自动调用，哪些需要人工确认；
• 超时与重试机制；
• 返回结果的格式化与截断；
• 审计日志。

2.5 数据层

数据层包括知识库的向量数据、历史工单的结构化数据、告警记录、会话上下文等。对于RAG场景，知识库的构建和更新策略是数据层的重点。

三、三类核心Agent的职责设计

3.1 知识库Agent

知识库Agent的核心能力是从海量企业文档中快速定位相关内容并生成回答。它的设计要点包括：

知识入库流程远比检索本身更重要。企业文档往往格式混乱，有Markdown、PDF、Wiki页面、代码仓库中的README等。入库前需要统一做分段、清洗、元数据标注。分段策略直接影响检索质量，通常建议按语义段落而非固定字数切分，同时保留标题层级作为上下文。

检索策略上，单一向量检索往往不够。实践中比较有效的做法是混合检索：向量检索负责语义相近的内容，关键词检索负责精确匹配（如错误码、接口名、配置项），然后将两路结果做融合排序。

回答生成时，需要严格控制引用来源。每个回答最好附带引用的文档片段和来源链接，方便用户核验，也方便后续优化检索策略。

3.2 对话Agent

对话Agent负责管理多轮交互流程。它不能只做简单的问答，而是要根据当前场景动态决定下一步动作。几个关键设计：

状态管理：多轮对话的状态需要持久化，包括当前所处的排查阶段、已收集的信息、已确认的事实等。状态不能只依赖模型自身的记忆，必须有外部结构化存储。

澄清策略：当用户描述模糊时，Agent需要主动提出澄清问题，而不是随意猜测。澄清问题应该简洁、可选项明确，避免开放式的“请详细描述”。

上下文压缩：长对话会累积大量上下文，需要在适当时候做摘要压缩，既保留关键信息，又控制token消耗。

3.3 运维Agent

运维Agent是所有Agent中风险最高的，因为它可能执行真实操作。设计核心要点：

分级执行策略：将运维操作分为只读查询和变更操作两类。只读操作（如查监控、查日志）可以自动执行；变更操作（如重启服务、修改配置）必须经过人工确认，或者只在特定条件下自动执行。

流程编排：复杂排查往往需要多步骤，运维Agent内部应支持流程编排能力，可以定义为有向图，节点是工具调用或条件判断，边是流转条件。这种编排可以是静态配置，也可以通过模型动态生成计划。

安全兜底：任何操作都要有超时限制和回滚机制。对于有副作用的操作，需记录完整的操作审计信息，包括触发人、触发时间、执行的工具、传入参数、执行结果。

四、提示词体系设计

提示词是Agent行为的关键控制点，需要系统化设计。

4.1 System Prompt分层

不建议把所有指令塞进一个巨大的System Prompt里。更合理的做法是分层组织：

• 全局层：定义Agent的角色边界、总体行为准则、禁止事项；
• 能力层：描述Agent具备哪些工具、分别用于什么场景；
• 任务层：针对具体任务类型的执行规范和输出格式要求。

分层的好处是便于维护和调试。当某个环节出问题时，只需要调整对应层次的提示词，不影响全局。

4.2 User Prompt的规范化

用户输入往往随意，直接喂给模型效果不佳。通常需要在User Prompt中注入结构化上下文：

• 当前时间、环境信息；
• 用户身份与权限范围；
• 近期相关告警或事件；
• 知识库检索到的候选片段；
• 当前对话状态摘要。

这种“组装式”的User Prompt让模型获得足够的决策依据，而不是只依赖用户那一句话。

4.3 输出格式控制

Agent的输出需要被后续程序解析，因此必须约定明确的输出格式。对于需要调用工具的场景，常见做法是让模型输出结构化JSON，包含tool_name和arguments字段。对于面向用户的回答，则要求自然语言加引用标注。

一个实用的经验是：在提示词中提供少量few-shot示例，同时对输出做格式校验，校验失败时自动重试或降级处理。

五、工具调用与Function Calling

工具调用是Agent从“会说”到“会做”的关键跨越。

5.1 工具定义规范

每个工具需要清晰的描述，包括：

• 功能说明：用一两句话说明工具做什么；
• 适用场景：什么情况下用这个工具，什么情况下不要用；
• 参数Schema：每个参数的类型、含义、是否必填、取值范围；
• 返回格式：返回结果的结构说明。

模型的工具选择准确性高度依赖这些描述的质量。描述要站在“模型如何理解”的角度来写，而不是站在开发者自身的知识背景下写。

5.2 工具结果的后处理

模型对工具返回结果的处理能力有限，特别是当返回数据量很大时。因此需要在模型看到结果之前做后处理：

• 截断超长内容，保留关键信息；
• 格式化数字，添加单位说明；
• 标注数据来源和时间；
• 对于异常结果（如工具执行失败），包装成友好提示。

5.3 多工具链式调用

复杂任务往往需要多个工具配合。例如“集群A的服务为什么突然CPU升高”这个问题，可能需要依次调用监控查询工具、日志查询工具、变更记录查询工具。模型需要具备规划能力来决定调用顺序，并在每个工具返回后动态调整计划。

工程上可以采用ReAct循环来实现：模型每步输出“思考-行动-观察”，程序执行行动后把观察结果反馈给模型，直到模型输出最终回答。

rag-">六、RAG落地中的实际经验

RAG概念不难理解，但落地效果差异很大。以下是几个关键经验。

6.1 文档处理质量决定上限

RAG的效果天花板取决于知识库的质量。实践中要注意：

• 文档需要去噪，移除页眉页脚、导航栏等无效信息；
• 代码块和表格需要特殊处理，不能当普通文本切分；
• 建议保留标题层级，在chunk的元数据中记录所属章节，方便后续上下文扩展。

6.2 检索不是越多越好

很多人倾向于召回更多的chunk喂给模型，但过多的上下文反而会稀释关键信息。通常需要结合问题复杂度动态调整召回数量。对于简单问题，Top 3-5个chunk足够；对于需要综合多个文档的问题，可以召回到10个左右，但要配合重排序。

6.3 评估体系不可省略

没有评估体系的RAG就是盲调。评估至少包含两个层面：

• 检索评估：用一批标注好的问题，看相关文档是否出现在Top K结果中；
• 生成评估：用LLM对生成回答的准确性、完整性做自动评分，辅以人工抽检。

评估集需要覆盖常见问题类型和边缘case，并随着系统迭代持续扩充。

七、Agent设计模式的落地思考

设计模式是对常见问题的抽象解决方案。在Agent开发中，两种模式值得深入理解。

7.1 ReAct模式

ReAct将推理和行动交替进行，核心循环是：

Thought -> Action -> Observation -> Thought -> ... -> Final Answer

每一步模型先进行思考，决定调用什么工具，观察工具返回结果后再继续思考。这种模式的优点是灵活，不依赖预设流程，适合开放性问题。代价是循环次数不可控，有时会陷入死循环，需要设置最大步数限制和看门狗机制。

7.2 Plan-Execute模式

Plan-Execute先让模型生成完整计划，然后按计划逐步执行，中间可以加入计划修正机制。这种模式适合流程相对确定的场景，例如标准化的故障排查流程。它的优点是可预测、可审计，缺点是灵活性不足，当计划中途失效时需要重新规划。

实际项目中，两种模式可以结合：先用规则判断任务类型，结构化任务走Plan-Execute，开放性任务走ReAct。这种混合策略在稳定性和灵活性之间取得平衡。

八、企业级工程化考量

8.1 可观测性

Agent系统的调试比传统系统更难，因为模型行为具有不确定性。必须在关键环节埋设日志：

• 每次模型调用的输入输出快照；
• 每个工具调用的参数、返回、耗时；
• 每次意图分类和路由决策的结果；
• 每轮对话的完整上下文。

这些日志是事后分析问题、优化提示词和工具的基础。

8.2 成本控制

大模型调用有成本，Agent系统尤其容易产生大量token消耗。控制手段包括：

• 对简单问题采用轻量模型或路由到缓存答案；
• 对长上下文做压缩；
• 限制最大循环次数和单次输出长度；
• 监控每类请求的平均token消耗，识别异常模式。

8.3 安全与权限

运维Agent涉及敏感操作，安全设计必须前置：

• 最小权限原则，Agent只拥有完成任务所需的最小权限集；
• 危险操作的二次确认机制；
• 完整的操作审计日志；
• 输入注入防护，防止攻击者通过构造提示词绕过权限限制。

九、面试准备的核心思路

掌握了上述工程实践后，面试时可以从几个维度组织回答。

项目背景与价值方面，要能说清楚解决什么问题、为什么传统方案不够、引入Agent后带来了哪些可量化的改善。准备一组数据，比如告警自动处理率从多少提升到多少、平均响应时间从多少降到多少。

技术选型的理由方面，要能解释为什么采用某类架构而不是另一种。例如为什么选择混合检索而不是纯向量检索，为什么用分层提示词而不是单一大提示词。面试官想听的不是“我用了什么”，而是“我为什么这么选”。

难点与解决方案方面，准备2-3个有深度的技术难点。比如模型幻觉如何控制、工具调用失败如何兜底、知识库冷启动如何解决。每个难点都要能讲出：问题现象、定位过程、尝试过的方案、最终方案、效果对比。

对底层原理的理解方面，不要停留在“会调用API”。要理解Agent循环的本质、Function Calling的底层机制（模型只是输出结构化意图，实际调用由程序执行）、RAG中向量检索的基本原理。这些原理层面的理解才是区分度所在。

十、总结

构建企业级智能OnCall Agent是一项系统化工程，远不止调用大模型接口那么简单。它的核心挑战在于：如何让模型在真实企业环境中变得可控、可靠、可审计。

从实践来看，有几个判断值得重视：

• 知识库质量往往比模型选择更重要；
• 工具设计的好坏直接决定Agent的实际能力边界；
• 提示词工程需要体系化管理，而不是零散调整；
• Agent设计模式的选择要基于场景特征，而非盲目跟风；
• 评估体系和可观测性是持续优化的前提。

对于开发者个人而言，完整经历一个企业级Agent从设计到落地的过程，不仅掌握了Agent、RAG、工具调用等热点技术，更重要的是建立了一套“如何让AI在真实场景中产生价值”的方法论。这套方法论在面试中能够清晰表达，在工作中有实际产出，才是这个项目最大的价值所在。

企业级Agent开发仍然处于快速演进的阶段，没有一劳永逸的方案。持续迭代、持续评估、持续优化，才是构建高质量AI应用的正确姿态。