原文标题：Capacity Efficiency at Meta: How Unified AI Agents Optimize Performance at Hyperscale
原文链接：https://engineering.fb.com/2026/04/16/developer-tools/capacity-efficiency-at-meta-how-unified-ai-agents-optimize-performance-at-hyperscale/
- 我们正在分享 Meta 容量效率计划的实践经验，我们构建了一个 AI Agent 平台，帮助在整个基础设施中自动化发现和修复性能问题。
- 通过将领域专业知识编码到统一的标准化工具接口中，这些 Agent 帮助节省电力，并将工程师从处理性能问题中解放出来，使其能够专注于创新新产品。
我们构建了一个统一的 AI Agent 平台，将资深效率工程师的领域专业知识编码为可复用、可组合的技能。这些 Agent 现在能自动化地发现和修复性能问题，已回收数百兆瓦（MW）的电力，并将原本需要数小时的人工回归调查压缩到数分钟内，使该计划能够在不按比例扩大人员编制的情况下，在越来越多的产品领域扩大兆瓦交付量。
在防守端，Meta 内部的回归检测工具 FBDetect 每周捕获数千个回归问题；更快的自动化解决意味着更少的兆瓦在整个集群中白白浪费。在进攻端，AI 辅助的机会解决方案正在每半年扩展到更多产品领域，处理越来越多工程师无法手动处理的优化机会。这就是 Meta 容量效率计划在不按比例增加团队的情况下不断提升兆瓦交付量的方式。最终目标是建立一个由 AI 处理长尾工作的自持续效率引擎。
以下是它的工作原理以及我们的未来方向：
- 超大规模的效率优化需要同时做好进攻（主动发现优化机会）和防守（捕获并缓解进入生产环境的回归问题）；AI 可以加速两者。
- 我们构建了一个统一平台，标准化的工具接口与编码的领域专业知识相结合，自动化两方面的调查工作。
- 这些 AI 系统现已成为容量效率计划的基础设施，已回收数百兆瓦的电力，足以为数十万美国家庭供电一年。
- 自动化诊断可以将约 10 小时的人工调查压缩至约 30 分钟，而 AI Agent 则完全自动化从效率机会发现到可审查拉取请求的完整流程。
容量效率计划介绍
当你发布的代码服务于超过 30 亿用户时，即使是 0.1% 的性能回归也会转化为巨大的额外电力消耗。
在 Meta 的容量效率组织中，我们将效率视为双向努力：
- 进攻： 主动寻找机会（通过代码变更）使现有系统更高效，并加以部署。
- 防守： 监控生产环境中的资源使用情况，检测回归问题，将其根因追溯到某个拉取请求，并部署缓解措施。
这些系统运行良好，多年来在 Meta 的效率工作中发挥了重要作用。然而，实际解决这些系统发现的问题引入了一个新的瓶颈：人类工程师的时间。
这些人工工程时间可能花费在以下任何活动上：
- 查询性能分析数据，寻找热点函数的优化机会。
- 审查效率机会的描述、文档和历史示例，了解实施优化的最佳方法。
- 检查近期的代码和配置部署，查看哪些可能导致资源使用的阶跃变化。
- 浏览近期的内部讨论，了解哪些上线功能可能与某个回归问题有关。
Meta 的许多工程师每天都在使用我们的效率工具处理这些问题。但无论工具质量多么高，当产品创新是首要任务时，工程师处理性能问题的时间是有限的。
我们开始思考：如果 AI 能够接管调查和解决工作会怎样？
进攻与防守共享相同的结构
突破在于我们意识到两个问题共享相同的结构：
这意味着我们不需要两套独立的 AI 系统，而只需要一个可以同时服务两者的平台。
我们在两个层次上构建了这个平台：
- MCP 工具：这些是 LLM 调用代码的标准化接口。每个工具做一件事：查询性能分析数据、获取实验结果、检索配置历史、搜索代码或提取文档。
- 技能（Skills）：这些将关于性能效率的领域专业知识进行编码。一个技能可以告诉 LLM 使用哪些工具以及如何解读结果。它捕获了有经验的工程师多年积累的推理模式，例如”对于端点延迟回归，查阅排名靠前的 GraphQL 端点”，或者”如果受影响的函数处理序列化，查找近期的 schema 变更”。
工具与技能结合在一起，将通用语言模型提升为能够运用通常由资深工程师掌握的领域专业知识的系统。同样的工具可以同时支持进攻和防守，区别只在于技能。
防守：在回归问题复合之前捕获它们
FBDetect 是 Meta 内部的回归检测工具，可以在嘈杂的生产环境中捕获小至 0.005% 的性能回归。它分析如下所示的时序数据：
当 FBDetect 发现回归时，我们立即尝试将其根因追溯到某个代码或配置变更；这是理解发生了什么的关键第一步。这主要通过传统技术完成，例如将回归函数与近期拉取请求进行关联。确定根因后，工程师通常会收到通知并被要求采取行动，例如优化近期的代码变更。我们增加了一个额外功能来加快这一过程：
AI 回归解决器
我们的 AI 回归解决器是 FBDetect 最新、最有前景的组件，它能自动生成一个拉取请求来前向修复回归问题。传统上，导致性能回归的根因（拉取请求）要么被回滚（降低工程速度），要么被忽视（不必要地增加基础设施资源消耗）。
现在，我们的内部编程 Agent 被激活来执行以下操作：
- 使用工具收集上下文： 查找回归的症状，例如发生回归的函数；查找回归的根因（一个拉取请求），包括被修改的确切文件和代码行。
- 使用技能应用领域专业知识： 针对特定代码库、编程语言或回归类型使用回归缓解知识。例如，来自日志记录的回归可以通过增加采样率来缓解。
- 创建解决方案： 生成一个新的拉取请求，发送给原始根因作者进行审查。
进攻：将机会转化为已交付的代码
在进攻侧，“效率机会”是提出的概念性代码变更，被认为可以提升现有代码的性能。我们构建了一个系统，工程师可以查看某个机会并请求 AI 生成实现它的拉取请求。原本需要数小时调查的工作，现在只需数分钟即可审查和部署。
这个流程与防守侧的 AI 回归解决器相对应：
-
使用工具收集上下文： AI Agent 查找：
- 机会元数据。
- 解释优化模式的文档。
- 展示类似机会如何被解决的示例。
- 涉及的具体文件和函数。
- 用于确认修复有效的验证标准。
-
使用技能应用领域专业知识： 使用专家工程师对特定类型效率机会的知识，将其编码为技能。例如，对给定函数进行记忆化以减少 CPU 使用。
-
创建解决方案： 生成带有防护措施的候选修复，验证语法和风格，确认它解决了正确的问题。在工程师的编辑器中显示生成的代码，可一键应用。
重要的是，我们使用与防守端相同的工具：性能分析数据、文档、代码搜索。区别在于技能。
统一平台，复合回报
我们共享工具和数据源的统一架构是一个清晰的抽象。每个现有和新的 Agent 都有一个简单的方式来通过我们构建的接口收集性能相关的上下文，无需重新发明轮子。
这篇文章聚焦于我们最初的使用场景：性能回归和机会。在一年之内，同样的基础支撑了更多应用：效率问题的对话式助手、容量规划 Agent、个性化机会推荐、引导式调查工作流以及 AI 辅助验证。每项新能力几乎不需要新的数据集成，因为它们只需将现有工具与新技能进行组合即可。
影响
容量效率计划的成果是显著的：我们已回收数百兆瓦的电力。进攻和防守两侧的 AI 系统都为支持这项工作做出了贡献。
但更深层的变化在于进攻和防守如何相互强化：原本花费早晨时间进行防守性分类的工程师，现在只需数分钟就能审查 AI 生成的分析。使用效率工具的工程师现在可以获得 AI 辅助的代码，而无需从零开始。令人望而生畏的”我从哪里开始？“的问题，已经被审查和部署高影响力修复所取代。