本文来自 Meta 网络基础设施团队，合作者包括来自约翰霍普金斯大学、哈佛大学、石溪大学的研究者。通讯作者为 Meta 研究科学家王兆东。

该团队提出了 Confucius——一个面向超大规模网络管理的多智能体 LLM 框架。其核心思路是将网络管理任务建模为有向无环图（DAG），通过 LLM 自然语言理解能力连接现有工具，在不重新发明轮子的前提下实现意图驱动的网络管理。该框架已在 Meta 生产环境运行两年，接入了超过 60 个网络管理应用。

据作者所知，这是首个关于在超大规模网络中部署多智能体 LLM 的系统性报告。

目前该研究已被 SIGCOMM 2025 正式接收。

论文链接：https://doi.org/10.1145/3718958.3750537

从实际问题出发：Meta 的网络管理有多复杂

网络管理不是一个抽象的研究课题。在 Meta 这种规模的基础设施中，它是一个每天都在发生的工程现实——而且远比想象中棘手。

以容量规划（Capacity What-if Analysis）为例。当 Meta 决定建设新的 AI 数据中心时，网络团队需要回答一个问题：骨干网拓扑该怎么改，才能让新区域以合适的带宽与其他区域互联？这听起来只是一个问题，但它会拆解成一连串子任务：先拉取当前拓扑、预测未来流量、在拓扑上叠加假设变更、跑故障模拟、对比多组结果。每个子任务还有多个变体——需求预测用 p90 还是 p95，故障模拟用哪种韧性策略。传统做法下，工程师得手动串联数十个工具，耗费数小时甚至数天。

故障诊断同样令人头疼。假设 Instagram 有一批推理请求失败了，工程师要排查原因。光定位问题就要走四步：先找出受影响的主机属于哪个区域、哪个前缀，然后检查 TCP 重传是不是有异常，再查 NetNORAD 数据看有没有丢包，最后还得翻网络变更日志看有没有关联操作。每一步查的是不同的数据集，需要的领域知识也不一样。

更麻烦的是，Meta 的网络数据模型 Robotron 里有几十万个模型实例。光是找到「对的那个」，就需要专门的检索手段。而且网络管理容不得半点差错——设备排空操作搞错了会丢包，路由配错了会制造黑洞。完全交给 AI？想都别想。

Confucius 的设计出发点就来自这些实际痛点。它的核心理念很朴素：LLM 负责推理，事实性知识交给现有工具和数据库。不替代，只桥接。

技术方案：多智能体 + DAG + 三类 DSL

用 DAG 组织工作流

Confucius 把网络管理任务建模为有向无环图（DAG）。每个节点是一个子任务，节点之间通过输入输出依赖自动确定执行顺序，互相独立的子任务可以并行跑。

框架的基础抽象类叫 Analect——取自《论语》的英文 Analects，算是给框架起名时埋了个彩蛋。它基于 Pydantic 构建，所有原语（Primitives）都继承自这个基类。

规划阶段有两个关键原语。一个是 Ensemble，并行调用多个 LLM 处理同一任务再合并结果——支持四种模式，从「谁快用谁」到「全部返回供人工审查」不等。另一个是 Orchestrator，让 LLM 自己决定调用哪些 Building Block、按什么顺序调用。前者追求可靠，后者追求灵活。

Confucius 还用 RAG 从数百个已有工作流中检索推荐最相关的模板。毕竟写工作流最难的不是写代码，而是不知道该用哪个。

不造新工具，而是连接已有的

这是 Confucius 最务实的设计决策。Meta 内部有几百个网络管理工具，API 和 CLI 五花八门。与其重新开发，不如让 LLM 学会用它们。

但问题在于，这些工具接受的是结构化的领域特定语言（DSL），不是自然语言。Confucius 识别出三类在网络管理中反复出现的 DSL：

第一类是网络拓扑图。用 Thrift 定义的图结构，包含区域、节点、链路和流量。修改拓扑用 TML（Topology Modification Language），一种 Python-based DSL。有意思的是，拓扑中的命名惯例本身就包含了领域知识——比如区域名通常是机场代码（ATN），L1 节点由区域代码加数字组成（ATN1）。Confucius 把这些惯例显式写进 prompt，让 LLM 能读懂。

第二类是时间序列数据。存在 ODS（Operations Data Store）里，每个实体是一组 <时间, 值> 快照。查询这类数据涉及聚合、百分位计算、平滑等操作。

第三类是网络数据模型。Robotron 是几乎所有管理工具的底座，通过 ORM 层把高层网络设计意图映射为底层设备配置。LLM 把用户意图翻译成 Robotron 操作，Robotron 再翻译成设备配置——两层抽象，各司其职。

为了把自然语言翻译成这三种 DSL，Confucius 提供了三个原语：Translator 负责自然语言到结构化输出的转换，Selector 负责从大数据集中筛选相关选项，Collector 负责跟用户确认意图——毕竟自然语言天然有歧义，很多时候得追问几句才能搞清楚用户到底想干嘛。

六种提示工程技术的组合拳

光有翻译原语还不够，翻译质量取决于 prompt 怎么写。Confucius 对不同的 DSL 任务选用了不同的提示策略：

Zero-shot CoT 让模型翻译前先思考；Few-shot CoT 提供翻译示例；Contrastive CoT 故意给错误示例并告诉模型为什么错；Tool Calling 让 LLM 直接调 API 并根据返回结果自我纠错；Reason and Act 通过 Orchestrator 让 LLM 规划自己的行动；Code as Reasoning 则让 LLM 写代码而非直接改结构，生成的代码可以被编译器和人双重验证。

这些技术不是随便堆的。论文给出了一个具体案例：ODS 查询被拆成五个子任务——先用 Selector 缩小关键词范围，再用 Translator 识别具体实体，然后处理聚合算子、转换时间范围、最后做复杂数学变换。每一步都有对应的 prompt 策略。

记忆：树结构短期记忆 + 三种 RAG

短期记忆用层级树结构管理。每个 Analect 有自己的消息列表，同时可以访问父级和会话级的上下文。这种设计让不同子任务既能共享信息，又不会互相污染。

长期记忆靠 RAG。Confucius 提供了三种变体：最基础的 Naive RAG 就是向量存储加相似度搜索；Hybrid RAG 加了两阶段过滤——先搜再按新鲜度、评分等维度筛一轮，最后让 LLM 做语义精筛；Query Transformation 则先用 LLM 精炼用户查询再检索。

在 Wiki Q&A 任务中，向量存储包含 330 万个向量，内存占用 33.5 GB。这个规模下，单纯靠微调把知识塞进模型权重里，显然不如按需检索来得靠谱。

隐私方面，Confucius 用专门的脱敏服务自动替换 40 种敏感信息（IP、设备 ID、姓名、邮箱等），LLM 处理完再换回来。

验证：三道防线

网络操作不能出错，所以 Confucius 在验证上下了不少功夫。内置解析器检查 TML 语法，解析失败了就把报错信息喂回 LLM 让它自己改；外部 API 通过 Robotron 的 ORM 做读取验证，通过 dry-run 模式做写入验证；图验证器则检查拓扑的连通性和路径约束。三道防线，层层把关。

实验：提示工程 + RAG 全面碾压微调

Ensemble 多模型确实更稳

在 ODS 翻译任务上，把 Llama 3.1、Claude 3.5 Sonnet、Gemini 2.0 Flash 三个模型组成 Ensemble，ODS Reduction 得分 0.87，Transformation 得分 0.98，同时把标准误差分别降低了 34% 和 57.6%。多模型的好处不只是准确率更高，更重要的是输出更稳定。

这组对比值得细看

DSL 翻译的实验结果大概是全文最有说服力的部分。Confucius 用精心设计的 prompt，在 7 个基础模型上全面超越了 Meta 内部在领域数据上微调的模型：

TML（拓扑）最高提升 35%，ODS Transformation（时间序列转换）最高提升 22.4%，ODS Reduction（时间序列聚合）最高提升 23%，Robotron（数据模型）提升 13%。

这个结果说明一个问题：至少在网络管理这类垂直领域，与其花大量算力微调，不如把领域知识通过 prompt + RAG 注入。而且 prompt 工程方案的好处是可以随时换基础模型——微调模型绑定了训练数据，灵活性差得多。

CoT 提示在 92.4% 的数据点上带来了提升，但也有少数翻车的案例。论文举了个例子：用户说「count data points in the last 10 minutes」，正确的 ODS 转换是 count(10m)，但 CoT 会让模型把 prompt 里见过的其他操作也带上，变成 latest(10m), count(10m)。想多了，反而搞砸了。

RAG 同样优于微调

在知识检索任务上，Hybrid RAG 在 Netgram 上提升 3%，Query Transformation 在 Wiki Q&A 上把分数从 0.73 拉到 0.77。跟 DSL 翻译实验的结论一致：检索比微调更适合注入领域知识。

生产数据：4160 个用户，3100 万条消息

Confucius 已服务 4160 名用户，月活 2630，累计产生 241,380 个会话和超过 3100 万条消息。AI 与人类消息比达到 20.54——意味着 LLM 平均每收到一次人工输入，就能自动完成 20 步操作。

不过不同任务的自动化程度差异很大。容量规划这个比例是 7.65，故障诊断只有 2.46。后者更低不意外——排障本身就更依赖人的判断力。

Confucius 平均每周帮工程师省下 17 小时。

指标	数值
总用户数	4,160
月活用户	2,630
总会话数	241,380
总消息数	31,620,000
接入应用数	64
AI/人类消息比	20.54

经验教训：什么管用，什么不行

论文的 Section 8 坦诚分享了不少实战经验，这里挑几个有意思的。

复用 + 检索是真正管用的模式。很多网络应用其实都在做同一件事：基于已有的内容生成类似的新内容——照着现有模型写新模型、参考现有配置生成新配置、从已有工作流组合新工作流。Confucius 的 embedding + RAG 方案跟这个模式天然契合。

集成现有工具是推广的关键。一开始用户会来尝鲜，但很难养成习惯。真正留住用户的是把 LLM 接入已有的自动化系统。论文举了个例子：维护事件解析器（parse 厂商邮件、生成结构化工单）被嵌入工单管理系统后，每天被调用几百次。

故障诊断是最难啃的骨头。在这类任务上，LLM 面临的对手是领域专家——而专家本身也是基础模型和命令行的高手。让 LLM 给专家当 copilot，价值有限。论文打了个比方：就像 ChatGPT 能帮学生改作文，但帮不了专业作家。而且最难的网络问题本身就没有结构化的排查步骤，MOP 覆盖不到，LLM 自然也无能为力。

三个顽固问题。第一，长会话中上下文会丢失。比如用户说「查某个时间段的丢包」，随着排查步骤越走越远，「某个时间段」这个约束可能被后续操作遗忘。第二，幻觉。LLM 找不到答案时不会坦诚说「我不知道」，而是编一个——这跟系统设计里「尽早失败」的原则完全矛盾。第三，隐私边界模糊。不同数据有不同的访问权限，LLM 在这方面没有清晰的意识。

总结

Confucius 的核心贡献可以归纳为三个方面。

在系统层面，它提出了多智能体 + DAG 的任务分解范式，通过 Ensemble 和 Orchestrator 两个原语分别实现了高可靠和高灵活的规划。

在工具对接层面，它识别了网络管理中三类反复出现的 DSL（拓扑图、时间序列、数据模型），并通过 Translator、Selector、Collector 三个原语实现了自然语言到结构化数据的高精度桥接。

在知识注入层面，它用实验证明了一件事：在网络管理这个垂直领域，精心设计的 prompt + RAG 比在领域数据上微调更有效，最高提升达 35%。

同时，两年生产部署、64 个应用、3100 万条消息的实践数据，为「LLM 能不能在要求极高可靠性的基础设施场景中真正落地」这个问题提供了一个相当有说服力的肯定回答。