像搜索一样简单，百度网络运维的 AI 智能体设计和实践

　　1.一个典型的运维场景

　　「推理任务 job-0bb39798bbfe6a4e 今天凌晨 2 点半的时延有问题吗?」

　　这是在运维中常见的一个场景。以前，我们的运维团队会登录高性能网络时延平台，输入任务 ID 和时间查询热力图。运维团队再根据经验进行人工分析，查看是否有异常的时延数据。

　　从下文的热力图中，我们可以看到同一 TOR 组中服务器(对角线上的方块)之间访问时延很少，跨 TOR 组的服务器之间的时延稍微大一些，跨房间的服务器之间的时延会更大，没有明显异常的时延数据。

　　当然这需要有经验的、熟悉网络拓扑的运维同学才能从图中解析出这些信息，其他同学并不知道这张图隐含的意义。

　　现在，我们只需在「灵犀智能体平台」的对话框中输入全文开头的这句话，灵犀智能体就能够自动进行查询和分析，给出一个全面的分析报告。

　　如果我们把时延和拓扑数据交给 LLM 进行分析，它会结合拓扑对时延数据进行分析，并且给出最终的结论：当前每一组的时延是否正常，时延数据是否符合实际数据、如果有异常，是哪一组或者哪些组有异常，该怎么检查，LLM 会分析得明明白白的。

　　2.百度网络运维体系建设回顾和发展

　　一直以来，百度智能云系统部物理网络监控团队负责了百度物理网络故障监控和定位。

　　2.1手工处理时期

　　最早我们的物理网络运维更多的通过人工的方式进行排障，基本依赖业务的保障和业务提供的现象，进行人工的分析登录设备进行检查，或者通过经验积累编写了一些脚本半自动的进行故障定位。

　　这是网管最原始的一种状态，也是物理网络建设之初的必经之路。因为是手工处理，故障的发现、定位和处理都需要耗费非常长的时间。

　　2.2.网管平台建设期

　　随着云的快速发展，对网络稳定性的需求越来越高，我们针对各种场景开发了各种监控平台，并逐渐演化处理了黑盒和白盒两个方向：

　　白盒方法主要针对交换机等网络设备的日志进行分析、对网络的设备的指标进行采集和告警、对流量进行监控、对高性能网络和服务器的指标进行采集等等。

　　黑盒方式主要通过探测的方法，通过 PingMesh、雷达扫描等方式对骨干网、机房、网关等场景进行秒级的故障监控和定位、对改包、大包、回切等特殊场景进行监控、提供各种定位工具进行分析、提供时延数据进行性能分析。

　　随着公司网络、机房规模的逐步扩大，我们开发了十几个网络监控平台、覆盖了数十个网络监控场景。

　　针对物理网络精细化的监控，这些平台为运维同学提供及时和准确的告警和定位信息，并且联动自动止损平台进行自动化的止损。网管平台为百度网络的稳定性提供了全面的快速的「监控 – 定位 – 止损」能力。

　　2.3.大模型和智能体探索期

　　24 年我们第一时间引入大模型能力，通过大模型进行故障的综合定位。

　　随着 25 年各种通用智能体和垂类智能体的不断涌现，我们也针对的物理网络网管方向，探索和推出了针对网管和运维方法的智能体 –「灵犀智能体」，期望利用大模型和智能体的技术，深度挖掘物理网络网管和运维的能力，提供更智能更便捷的运维功能。

　　针对各种场景的深度分析：利用网管平台的各种采集的数据，使用大模型进行深度分析，生成有深度的分析报告。

　　针对长尾故障的定位分析：因为大模型推理的时效性比较慢，不太适合秒级的告警。但是对于长尾的故障，比如不容易定位的改包、未知的轻微的丢包行为等，可以利用大模型，结合网管平台的各种数据，让大模型进行细致的分析和故障定位。

　　网络故障综合门户：我们的平台不仅仅为运维团队使用，其他部门都可以使用。但是他们可能不了解物理网络的内部细节，更希望能够通过自然语言进行咨询。所以利用大模型，我们可以将用户的自然语言生成物理网络的概念，进而调用相应的网管平台的服务，生成查询的结果，然后图文并茂的将结果以更容易理解的方式返回给用户。

　　灵犀智能体采用 Chat 模式，和用户的交互通过一个对话框完成。用户在对话框中输入网管运维相关的问题，灵犀智能体制定「推理 – 计划 – 行动」计划，按照计划调用相应的工具，最终输出一个推理的结果

　　3.灵犀智能体架构设计

　　整个灵犀智能体采用 Multi-Agent pattern、ReAct pattern、Planning pattern 和 Tool Use pattern 实现。

　　智能体接收到用户的 Prompt 后，调用 LLM 进行推理和计划(planning)，得到下一步 Action。在执行下一步的 Action，通过 MCP 调用相应的外部服务(tool use)，得到服务器的结果，再交给 LLM 进行观察和分析(ReAct)，然后确定是否进行下一步计划，或者已经完成任务返回给用户。

　　让我们以文章最开始的时延查询任务为例，逐步介绍整个的流程：

　　第 1 步：用户输入「推理任务 job-0bb39798bbfe6a4e 今天凌晨 2 点半的时延有问题吗?」，提交给灵犀智能体。

　　第 2 步：灵犀智能体让大模型进行推理和计划，以便确定下一步的 Action。

　　这一步我们会把我们实现的 Thinking Tool 以及其它的 MCP 工具的信息、系统提示词和用户的 Prompt 提交给 LLM。

　　大模型会返回整个任务的计划，需要的步骤以及下一步要执行的 Action。

　　灵犀智能体会把 Thinking Tool 的信息附加在消息中，再次请求 LLM，获取到下一步要调用的 MCP 工具(时延监控 MCP)和参数(job ID 和时间戳)

　　第 3 步：灵犀智能体调用时延监控 MCP，并传入 job ID 和时间戳参数，这里使用的是 MCP 协议。

　　第 4 步：时延监控 MCP 首先查询网管时延平台，得到此任务在查询时间点的时延数据。

　　第 5 步：时延监控 MCP 再根据 job ID，查询拓扑信息，包括网络信息以及房间信息。

　　第 6 步：这里有两种处理方式，我们采用 b 方式处理。一是容易进行业务隔离，负责时延的小组有相关的经验，可以让他们去实现时延监控 MCP，而不是下文介绍的前端优化，避免让 LLM 生成 HTML 代码，优化体验。

　　a：直接把时延数据和拓扑信息返回给灵犀智能体，灵犀智能体调用 LLM 进行分析，再调用报告生成 MCP;

　　b：时延 MCP 拿到 job 的时延数据和拓扑数据后，自己调用 LLM 进行分析，生成分析报告，返回灵犀智能体。

　　第 7 步：智能体拿到 MCP 工具的返回结果后，再调用 LLM，确定是否完成任务，还是再执行下一步的 Action。

　　第 8 步：如果任务已经执行完或者达到最大的执行步骤，灵犀智能体把结果返回给用户。

　　3.1. LLM 大模型的选型

　　在灵犀智能体的设计中，我们并没有将其绑定到某一个特定大模型上，架构之初便确立了模型无关的核心设计，使其能够无缝集成并智能调用业界最前沿的大语言模型。

　　当前，线上运行的灵犀智能体采用 OpenAI API 兼容的接口，使用百度千帆大模型平台支持的各种模型和 API。实践中，我们采用 DeepSeek-v3 模型作为智能体的主要模型进行推理，使用 ERNIE-4.5-turbo-128k 进行特定场景的数据分析，使用 tao-8k embeddings 模型进行 RAG 相关的探索。

　　3.2.设计模式

　　Multi-Agent pattern、ReAct pattern、Planning pattern 和 Tool Use pattern 是常用的智能体设计中的模式，而且经常会被组合起来使用。在灵犀智能体中，我们也采用了这几种模式。

　　Multi-Agent pattern：Multi-Agent pattern 涉及多个智能体协作，每个智能体可能有不同角色，智能体组合起来处理大型复杂的任务。灵犀智能体通过 A2A 实现其它智能体的接入，比如智能网关智能体、变更操作智能体等，用来处理网关类问题和变更操作的问题。

　　ReAct pattern：ReAct pattern(Reasoning and Acting，推理与行动)也是一种智能体实现的常见模式，它将 LLM 的推理能力与使用工具执行动作的能力结合在一起。它通过迭代式地进行推理、行动和观察来运作，以模仿人类解决问题的方式。这种方法使得代理能够通过利用外部工具并保留先前步骤中的信息，来动态地调整其处理复杂任务的方法。ReAct 的工作原理：

　　推理(Reasoning)：代理分析一个任务，并将其分解为更小的步骤，根据可用的信息和工具来决定采取何种行动。

　　行动(Action)：代理使用工具(如搜索引擎、数据库或其他 API)与外部环境互动，以收集信息或执行特定任务。

　　观察(Observation)：代理观察其行动的结果，并将相关信息存储在记忆中以备将来使用。

　　迭代(Iteration)：代理重复「推理、行动、观察」的循环，直到达成预期目标或找到满意的解决方案。

　　我们通过在单次 Action 的执行中应用 ReAct 模式，将 Action 的执行结果提交给 LLM 观察分析，并保存在记忆中将来使用。

　　Planning pattern：Planning pattern 是当前智能体处理复杂任务的使用的一种模式。Anthropic 开发了一个专门用来实现 Think 的 MCP Tool，也就是大名鼎鼎的 Sequential Thinking，这个工具旨在通过结构化的思维过程帮助用户解决复杂问题，支持动态调整和分支推理。

　　灵犀智能体自己实现了一个更简单的 Thinking Tool, 因为我们只需要一个简单的推理和规划工具，所以我们使用 Go 语言实现了一个简单的工具如下：

　　Think Tool 引导了 LLM 进行推理和拆解任务，然后我们会在前端把 LLM 的思考、计划和行动打印出来。

　　扩展性好：灵犀智能体所有和外部资源交互的场景都通过 MCP Server 来实现，新的 MCP 服务都可以通过一行配置引入到灵犀智能体，具备了优异的扩展能力，比如下面 4 行代码配置了 4 个 MCP 工具。新增加一个 MCP 工具，只需在配置文件中增加一行，key 是工具的名称，value 值是 MCP 工具的地址：

　　可重用性：通过使用 MCP 协议，可以把我们既有的网管和运维服务封装成一个个的 MCP 服务，不但可以被灵犀智能体使用，而且还可以被其它 MCP Server调用，甚至可以被其它的智能体所调用。

　　便于工程管理和实现：整个网管和运维工作涉及到多个小组，如果小组围绕一个智能体项目开发，其实是一件非常难于管理的事情。但是通过使用 MCP 协议，每个小组可以开发自己的业务服务，再通过 MCP Server 方式提供出来，极大的减少了组之间的沟通成本。

　　3.3.前端开发

　　灵犀智能体的前端都是通过 Comate Zulu 实现的。对于展示 MCP Tool 的结果，我们希望能够使用漂亮的网页展示，比如下面的查询 IP 地理信息的页面

　　这些前端的实现并不是通过「报告生成 MCP」生成的。原因在于实际在运行中，我们发现将数据展示出复杂和漂亮的网页，大模型需要 2 分钟以上的时间，并且会耗费大量的输出 Token。

　　为了优化数据的展示，我们采用先将数据扔给大模型做时延分析，并生成 JSON 格式的数据。然后基于网页模版，用 JSON 数据进行模版填充，秒级生成一个漂亮的网页返回给用户。

　　4.展望

　　我们在开发灵犀智能体时候，也对目前流行的其它技术进行了探索，比如 A2A、RAG 等技术。

　　4.1.A2A

　　可以预见，在公司未来的生态中，会存在着各种各样的智能体，每个部门都会在这方面进行探索和开发。部门时间跨度越大，智能体之间的交流也越困难。

　　最近，谷歌联合50 多家技术合作伙伴以及领先服务提供商，发布了名为 Agent2Agent (A2A) 的全新开放协议。

　　A2A 是一个开放协议，是对 Anthropic 的模型上下文协议 MCP 的补充，借助 A2A 协议，开发者可以构建能够与使用该协议构建的任何其他智能体建立连接的智能体，让用户能够灵活地组合来自各种提供商的智能体。

　　比如我们正在构建故障问答的智能体，灵犀智能体就可以和它交互，任何提交给灵犀智能体的网络故障问题，都转交给故障问答智能体来处理。

　　灵犀智能体也通过一个 agents.json 配置文件集成其它智能体：

　　5.结语

　　时光回溯到 2009 年 8 月 18 日，百度提出了「框计算」的概念。用户只要在「百度框」中输入服务需求，系统就能明确识别这种需求，并将该需求分配给最优的内容资源或应用提供商处理，最终精准高效地返回给用户相匹配的结果。

　　这种高度智能的互联网需求交互模式，以及最简单可依赖的信息交互实现机制与过程，称之为「框计算」。

　　时间来到了 2025 年，这已经是「大模型的世界、应用的天下」。如何利用大模型，为框计算插上 AI 的翅膀，为框的计算赋能人工智能的能力，为用户提供更准确、更丰富、更多元化的查询结果?这正是「灵犀智能体」尝试探索的方向。 结合我们自身的网管运维工作方向，我们在网络运维领域实现了「AI 加持的框计算」进行了有益的实践。