How Meta Built Forum With AI-Native Engineering

Meta如何通过AI原生工程构建Forum - Meta工程实践

POSTED ON

OCTOBER 15, 2026

TO

Android

,

iOS

ML Applications

Web

Meta如何通过AI原生工程构建Forum

.entry-meta

.entry-header

By

Shengbo Guo

Bohou Luo

Shubhojeet Sarkar

Vivian Qu

Max (Xiangjun) Fan

Prerna Jain

Mike Plumpe

Chinmay Abhyankar

Rish Tandon

• Forum是Meta最新推出的独立应用，专为希望深入参与Facebook群组讨论的用户设计。
• 为构建Forum，Meta工程师通过将AI代理引入开发流程，采用了全新的工作方式。
• 我们将分享使用智能体AI构建Forum的洞察：我们如何调整代码库、测试框架和内部工具以支持智能体执行，哪些方法有效，哪些需要改进。

Forum是由一个小团队从零开始构建的独立群组应用。同时，这也是我们测试新型工作模式的试验场：将AI代理视为工程流程的参与者，而非仅仅是提高打字速度的工具。

这个实验需要明确的成功定义，而我们的标准不是代码量。我们衡量的是经过验证、可投入生产的成果——那些能够构建、通过测试并经受审查的变更。

从人机协作到人机分离

仅将AI应用于编码环节改变有限。当我们将这种方法扩展到实现阶段的上下游环节（规划、构建、测试和验证）时，效果呈指数级增长。最直观的转变体现在每个环节的负责人上。

在"人机协作"模式下，工程师主导每个步骤，AI通过自动补全函数、建议修复方案或回答问题提供辅助。每次迭代的进度取决于工程师的节奏。

在"人机分离"模式下，AI代理自主完成整个迭代流程——规划、实现、构建、测试、修正、重复——而工程师只需设定目标、监控执行过程、在偏离轨道时介入干预，并最终批准结果。工程师的职责从执行具体步骤转变为把控最终结果和质量标准。这是我们正在推进的目标，而非终点：目前部分环节已实现自主运行，其他环节仍在每个迭代中保留工程师参与。

当工程师转为监督角色时，工作流程不再严格线性。原本需要串行执行的环节可以并行处理，工程师的时间更多用于方向把控和判断决策，而非机械地重复流程。但这种模式成立的前提是输出结果可被信任。缺乏验证的AI生成代码会带来熟悉的困境——生成看似合理但未经验证的代码，工程师随后需要阅读、调试并经常弃用这些代码。弱信号并未消除约束，只是将约束点从编写代码转移到审查那些看似完成实则无效的代码上。

因此我们将标准设为验证而非编译。编译不是终点——只有在自动化测试和视觉检查都通过后，任务才算真正完成。在工程师查看代码前，智能体会先自行验证工作成果。这意味着进入审查环节的代码是经过筛选的高质量候选结果，而非需要逐一筛选的大量输出。生成的代码更少，被弃用的代码也更少。每个上线的成果仍然需要工程师的确认；我们的努力方向是让这个确认过程既快速又证据充分，每个变更都附带构建结果、测试结果和记录的验证会话。

在工程师置身于循环之外的情况下，循环必须能够自主安全地运行。四项能力使这一目标成为可能：

以技术规格进行规划：代理执行需要极高的精确度。工程师可能通过直觉解决的模糊性会导致代理失败。我们投入了严格的上游分解和机器可读上下文，这使工程师和代理的工程循环都更加紧密。

循环内的自动化验证是倍增器：我们将自动化通过/失败信号（构建状态、单元测试和UI规格匹配）直接集成到代理循环中。这使得异步开发能够生成带有预填充测试计划和记录验证会话的待审拉取请求。验证是正确实现的关键难点，我们能安全地交给循环处理的内容取决于对验证者的信任程度。

与代理进行模拟用户测试：我们部署了导航代理，它们与实时应用的交互方式与真人完全一致。这些代理执行操作、读取屏幕并报告回归问题。导航代理能够持续运行相同的验证路径。

代理生产运营：发布后，代理有助于自动化根本原因分析。当有人在论坛提交反馈时，代理会利用这些反馈调查可能的回归问题。随后，代理将分析结果转发给工程师，由工程师决定下一步行动。

运营模型

该所有权模型需要包含五个关键组件的机制：

• 规则：是永久性的项目指令。当代理重复犯错超过两次时，我们只需一次性编码修正方案，适用于所有人。
• 技能：将团队惯例转化为代理可调用的可加载步骤。
• 代理：自动化原本需要人工执行的检查。
• 命令：将技能和代理串联成工作流。它们评估复杂度、复现错误、规划并实施修复、创建拉取请求并执行多阶段评审。
• 钩子：是自动化触发器，例如每次代理执行后运行代码检查器，在安装前检查模拟器连接性，在创建拉取请求前验证测试。

适应环境到模型

最大的收益来自于改变代码和工具，而非提示语。

架构可读性优于继承的复杂性：我们努力保持论坛代码库尽可能简洁，并选择对架构关键部分进行模块化，以获得经过实战检验的基础设施优势，同时让代理能够轻松插拔。在无法轻松实现模块化时，我们从头开始重建，以开发速度为代价换取代理吞吐量，结果证明这是值得的。代理会从阅读的代码中学习模式。修复一个薄弱模式后，所有未来的代理会话都会继承这一改进；若不修复，相同的快捷方式会出现在代理后续所有编写内容中。

为代理提供工具而非描述：我们的主要失败模式是代理在应用中迷失方向——在被要求更改群组首页时却去编辑首页动态，或猜测屏幕坐标。因此我们没有向代理描述应用界面，而是提供了检查工具：从模拟器中读取实时视图层级、列出屏幕上的实际元素、查找目标视图的路径——所有操作都在代理执行前完成。误操作率显著下降。我们在所有代理与系统交互的场景中都采用相同方法：直接为代理提供状态检查方式，而非依赖描述性说明进行推理。

构建级别的隔离实现安全AI原型开发：随着Forum向生产环境演进，我们希望早期原型和代理生成的实验能够拥有独立的运行空间，同时将生产应用严格限制在已完成且经过审核的工作范围内。我们希望获得比功能开关更强的保障机制，因为原型代码仍可能存在于生产构建中。我们的解决方案是创建独立的构建版本，一个与生产环境共享完全相同代码库、框架和设计系统的沙箱应用，但通过插件/套接字架构将原型代码完全排除在生产构建之外。

这使我们同时获得以下三重优势：

• 设计师和跨职能合作伙伴可以自由使用AI工具进行原型开发，无需每次更改都依赖工程师介入。
• 沙箱中开发的任何内容都可以直接移植到生产环境，无需重新构建。
• 由于原型代码在生产构建中物理上不存在，因此不会导致生产应用崩溃。

这种模式让我们在真实用户开始使用应用后仍能保持快速的AI迭代测试。

通过AI压力测试发现真实漏洞

环境改造不仅让代理更易构建，更使其成为测试工具。我们没有让它针对特定缺陷进行检测，而是设置了可重复的压力测试场景，模拟真实用户行为（激进滚动、随机群组浏览、快速导航、重复加载媒体内容），并在各版本中定期运行这些测试。由于这些测试会产生一致的信号（崩溃、内存增长、页面错误、UI回归），代理可以对异常进行分类，定位触发序列并进一步调查根本原因。

一次这样的测试发现了内存问题。代理隔离了复现步骤，提出修复方案并验证——这一切都在开发阶段完成，应用尚未上线。该修复方案显著降低了设备内存增长和页面错误率。

虽然工程师负责架构决策，但缺陷检测和回归监控已实现自动化和可重复性；一旦发现异常，代理即可通过相同测试框架实现：复现→隔离→提出修复方案→验证。

将相同方法论应用于Forum动态流

我们在两个场景中应用了人机协作的闭环机制：

构建技术栈：代理分析架构选项及权衡，工程师随后进行评估和选择。我们刻意保留人类判断的是目标定义——决定良好结果的形态属于产品判断，而非由系统自行定义。

运营堆栈：过去需要依赖熟悉相关代码路径的工程师来解答的问题，现在会转交给调查代理处理。该代理会主动收集所需信息，并撰写包含修复建议的分析报告。在对一批真实调查案例进行人工评分后，我们形成了一个高效的工作流程：代理通过简化机械性工作，将结构化报告提交给工程师，由工程师最终判断发现的问题是真实漏洞还是有意为之的权衡取舍。

质量提升的关键并非更好的提示词，而是上下文信息。我们发现有一类常见调查在获得与新工程师入职第一天相同的指引（包括相关代码、示例查询和设计文档）前表现欠佳。当代理获得这些关键信息后，该类问题的解决质量显著提升。与人工培训不同的是，AI训练只需一次，之后每次交互都能基于这个基础展开。

实际效果如何？

除了加快交付速度，我们还实现了更高质量的交付。持续验证机制在开发阶段就发现了系统性问题（如上述内存瓶颈），而非发布后才暴露。这些成果体现在性能分析中：

• 早期发现的质量问题：自主压力测试循环在开发阶段就检测并修复了前述内存问题，使内存使用量和页面错误数量减少约一半。
• 开发效率：论坛在八周内实现了与Facebook小组的核心功能对齐，AI处理了大量常规实现工作，使工程师能专注于架构设计、产品决策和质量把控。
• 持续价值：发布后，代理驱动的调查机制帮助工程师更高效地分类处理用户反馈并定位根本原因。

AI的作用远不止生成代码。它优化了我们的质量闭环，使小团队能够以更少的返工投入，交付高质量的应用程序。

成功经验与不足之处

致谢

我们感谢 Neeharika Sinha、Jane Kou、Gang Yang、Guohao Zhang、Zeya Zhang、Kinnary Jangla 和 Yonghui Lu 的宝贵贡献。