Meta 如何用 AI 原生工程方式打造 Forum
- Forum 面向所有想在 Facebook 群组里深入参与讨论的用户。
- 为了打造 Forum，Meta 工程师把 AI agent 引入开发流程，采用了一种全新的工作方式。
- 我们在此分享用 agentic AI 构建 Forum 的经验：如何调整代码库、测试框架和内部工具以适配 agent 执行，哪些做法有效，哪些无效。
Forum 是一款独立的 Groups 应用，由一个小团队从零搭建。它也是我们试验另一种工作方式的场所：把 AI agent 当作工程流程中的参与者，而不是一个打字更快的工具。
这场实验需要明确什么算成功，而我们的标准不是代码量。我们衡量的是经过验证、可上线的成果——能构建通过、测试通过、并通过 review 的改动。
从 Human-In-The-Loop 到 Human-On-The-Loop
只把 AI 用在写代码这一步，改变不大。当我们把这套方法扩展到实现前后的各个环节——规划、构建、测试、验证——效果才逐步叠加显现。看这个转变最直观的角度，是每一步由谁负责。
在 human-in-the-loop 模式下，工程师驱动每一步，AI 只在步骤内部辅助：自动补全一个函数、建议一个修复方案、回答一个问题。每次迭代的推进速度取决于驱动它的人。
在 human-on-the-loop 模式下，由 agent 自己跑完整个迭代——规划、实现、构建、测试、修正、循环往复——工程师则负责设定目标、观察执行过程、在跑偏时介入，并最终批准结果。人的职责从执行步骤，转变为掌控结果、守住质量标准。这是我们在努力达成的目标，而非已经完成的状态：目前有些环节已经可以自主运行，另一些环节的每次迭代仍需要工程师参与。
当工程师转为监督角色后，工作就不再严格按顺序进行。过去只能逐个执行的循环现在可以并行推进，工程师的时间也投入到方向把控和判断上，而不必守着整个循环。但前提是产出结果可信。缺乏验证的话，AI 生成的代码会带来一个老问题——看似合理却没人确认过真的能跑的输出，工程师还得去读、去调试，最后常常只能弃掉。微弱的信号并不能消除这个瓶颈，只是把它从写代码，转移到了审阅那些看似完成、实则不然的代码上。
因此，我们将标准定在验证而非编译上。编译并不是终点线——只有当自动化测试和视觉检查通过时，任务才算完成。Agent 会在工程师查看之前自查，这意味着提交评审的是数量更少、置信度更高的结果，而非一堆需要筛选的输出。生成的代码更少，被丢弃的也更少。每个交付的成果仍由工程师最终确认；我们把精力放在让这一确认过程变得快速且有据可依，包括附上构建结果、测试输出和记录的验证会话。
当工程师置身于每个循环之外时，循环必须能够安全地自主运行。以下四项能力使得这成为可能：
将规划视为技术规格：Agentic 执行需要极高的精度。工程师凭直觉就能化解的模糊性，会导致 Agent 失败。我们投入了大量精力进行严格的上游分解和创建机器可读的上下文，这收紧了工程师和 Agent 的工程循环。
循环内的自动化验证是倍增器：我们将自动化通过/失败信号——构建状态、单元测试和 UI 规格匹配——直接集成到 Agent 循环中。这实现了异步开发，产出的是带有预填测试计划和记录验证会话的、随时可供评审的 Pull Request。验证正确是最难的部分，我们能安全地交给循环多少取决于我们多大程度上能信任验证器。
Agent 模拟用户测试：我们部署了导航 Agent，它们像真人一样与实时的应用交互。这些 Agent 执行操作、读取屏幕并报告回归问题。导航 Agent 能够持续运行相同的验证路径。
Agentic 生产运维：上线后，Agent 协助自动化根因分析。当 Forum 的用户提交反馈时，Agent 利用这些反馈来调查可能的回归问题。随后，Agent 将分析结果转发给工程师，由工程师决定下一步行动。
运营模式
这种所有权模式需要由五个关键组件构成的机制：
- 规则是永久性的项目指令。当 Agent 重复同一错误超过两次时，我们将修正编码一次，供所有人使用。
- 技能将团队惯例转化为 Agent 可调用的可加载步骤。
- Agent 自动执行了原本需要人工复查的检查。
- 命令将技能与 Agent 串联成工作流：评估复杂度、复现 Bug、规划并实施修复、创建 Pull Request，以及执行多阶段审查。
- Hook 是自动化触发器，例如每次 Agent 响应后运行 Linter、安装前检查模拟器连接、创建 Pull Request 前验证测试。
让环境适应模型
最大的收益来自对代码和工具的改造，而非 Prompt 的优化。
架构的可读性优先于继承的复杂性：我们致力于让 Forum 的代码库尽可能简洁，并对架构的关键部分进行模块化。这样既能利用经过实战检验的基础设施，又能让 Agent 轻松“即插即用”。在无法轻松实现模块化的地方，我们选择从头重构，用复用性换取 Agent 的处理吞吐量，事实证明这在开发速度上回报丰厚。Agent 会从阅读的代码中学习模式。修正一处薄弱模式，后续每次 Agent 会话都会继承这一改进；若置之不理，同样的捷径会出现在 Agent 生成的后续所有代码中。
给 Agent 提供工具，而非描述：主要的失败模式是 Agent 失去对应用状态的追踪——比如被要求修改群组主页时却在编辑首页信息流，或盲目猜测屏幕坐标。因此，我们不向 Agent 描述应用，而是提供工具让其自行检查：从模拟器读取实时视图层级、列出屏幕上实际存在的元素、查找目标视图的路径——这一切都发生在采取行动之前。如此，错位编辑大幅减少。我们将这一方法应用于 Agent 接触的所有系统：给 Agent 直接检查状态的方式，而非让其基于描述进行推理。
构建级隔离以实现安全的 AI 原型开发：随着 Forum 迈向生产环境，我们希望早期原型和 Agent 生成的实验拥有运行空间，同时严格限制生产应用仅包含已完工、经审阅的代码。我们需要比 Feature Gating 更强的保证——后者仍允许原型代码存在于生产构建中。我们的解决方案是独立的 Build Flavor：一个沙盒应用，它与生产环境共享完全相同的代码库、框架和设计系统，但通过插件/Socket 架构，将原型代码完全从生产构建中剔除。
这一做法同时带来了三个好处：
- 设计师和跨职能合作伙伴可以随意用 AI 工具做原型，每次改动都不需要工程师参与。
- 沙箱里做出来的东西可以直接迁移到生产环境，无需重写。
- 原型代码不可能弄崩生产应用，因为它们压根不在这个构建里。
这个模式让我们在有了真实用户需要保护之后，依然能保持 AI 的快速迭代。
用 AI 压力测试发现真实 Bug
改造环境不仅让 agent 开发得更快，也让它成为了测试者。我们没有让它去修某个具体缺陷，而是搭建了一套可重复的压力场景来模拟真实用户行为（高频滚动、随机浏览群组、快速切换页面、反复加载媒体），并在每次构建时例行运行。由于这些运行能产生稳定的信号（崩溃、内存增长、缺页、UI 回归），agent 可以对异常进行分诊、定位触发序列，进而排查根因。
其中一次运行发现了一个内存问题。agent 复现了问题、提出修复方案并完成验证——全都在开发阶段完成，应用还没到用户手里。这个修复显著降低了多轮压力测试中的设备端内存增长和缺页次数。
架构决策由工程师来做，但异常检测和回归监控是自动化、可重复的；一旦发现异常，agent 就能用同一套测试框架完成复现 → 隔离 → 提出修复 → 验证的完整流程。
把同样的纪律应用到 Forum 的 Feed
我们在两个环节采用了 human-on-the-loop 的方式：
搭建技术栈：agent 梳理各种架构方案及其取舍，再由工程师评估和拍板。我们刻意保留给人的是目标本身——什么是好的结果，这是产品判断，不该由系统自己定义。
运维技术栈：过去那些要靠“恰好熟悉这段代码的工程师”才能回答的问题，现在交给一个调查 agent，它会自己收集所需信息，输出一份附修复建议的分析报告。我们对一批真实调查结果做了人工评分，最终形成了这样的工作流：agent 压缩机械性工作，产出结构化报告交给工程师，由工程师判断发现的问题是真实 Bug 还是合理的取舍。
提升质量的并非更优的 Prompt，而是上下文。有一类调查任务反复表现不佳，直到我们为 Agent 提供了与新工程师入职首日相同的指引——相关代码、示例查询和设计文档。该任务的质量因此大幅提升。这与人类入职的区别在于：只需培训一次，后续每次会话都从此基础开始。
效果如何？
除了交付更快，我们还实现了更干净的代码质量。持续验证机制在开发阶段而非上线后，暴露了系统性问题——例如前述的内存瓶颈。这些成果体现在性能剖析中：
- 质量早检：自主压力测试循环在开发期间而非上线后捕获并修复了上述内存问题，内存占用和页面错误大致减半。
- 速度：Forum 八周即实现了与 Facebook Groups 核心功能的对齐，AI 承担了大量常规实现工作，使工程师能够专注于架构、产品决策和质量。
- 持久的杠杆效应：上线后，Agent 驱动的调查协助工程师对用户反馈进行分诊和根因分析。
AI 的作用超越了代码生成。它收紧了我们的质量循环，帮助小团队以更少的返工交付高质量应用。
什么有效，什么无效
致谢
感谢 Neeharika Sinha, Jane Kou, Gang Yang, Guohao Zhang, Zeya Zhang, Kinnary Jangla 和 Yonghui Lu 的宝贵贡献。