Meta的最新应用是论坛
- 为了建立论坛，Meta工程师采用了全新的工作方式，将AI agent带入开发周期。
我们分享如何与代理AI建立论坛的见解：我们如何调整密码库、测试的框架和内部工具
论坛是一个独立的团体应用程序，将AI agent视为工程过程的参与者
这个实验需要成功的定义，我们测量了经核实的、为生产做好准备的结果——这些变化是建立、通过测试和进行生存审查的结果。
从Human-In-The-Loop到Human-On-The-Loop 从Human-Oop到Human-Oon-The-Loo
将AI指向编码步骤，随着我们把方法推广到执行阶段——规划、建设、测试和核查，我们的成果变得更加复杂。 最清楚的看这个转变的方法就是谁拥有每个步骤。
有了人性化，工程师驱动每个步骤，AI通过自动完成一个功能，建议一个固定，或者回答一个问题来协助它内部。 每个迭代都以驾驶者的速度前进。
agent通过人对流，运行迭代本身——计划，执行，建设，测试，正确，重复——同时工程师设定目标，观察运行，漂流时步入，批准结果。 个人的工作从执行步骤转向拥有结果和持有质量棒。 这是我们正在向着的目标，而不是一个完整的状态：一些阶段在今天是自主运行的，而另一些阶段则仍然在每个周期中保留一名工程师。
工程师监理时，工作会严格按顺序进行。 过去一次运行一个循环的周期会重叠，工程师的时间会转向方向和判断，而不是坐在循环中。 但只有能相信回来的事才能维持下去没有验证，AI生成的代码就产生了一个熟悉的问题——令人耳熟能详的输出，没有人证实实际的作品，工程师随后必须读取，调试，并经常丢弃。 微弱的信号不会消除限制；它们会从写入代码转移到审查看起来已经完成且没有完成的代码。
因此，我们设定了核查，而不是汇编。 编译并非终点线，Agents在工程师看到之前检查他们自己的作品，这意味着所达到的检讨是一套较小的更高自信的结果，而不是一叠输出来筛选通过。 少则生成，少则丢弃。 每一个运出的结果都有一个工程师签字；我们努力使签字迅速和证据确凿，并附有建设结果、测试结果和记录的与改变有关的核查会议。
与每个循环外的工程师，循环必须自己安全运行。 4种能力使得有可能：
规划作为技术规格：代理执行需要极其精确。 一个工程师可能通过直觉解决的模糊性导致agent故障。 我们投资了严格的上游分解和机读环境，这收紧了工程师和agents的工程环路。
循环内部的自动核查是增强力：我们把自动通过/失效信号——构建状态，单位测试，和UI光谱匹配——直接整合到agent循环中。 这使得能够同步发展，提出随时可审查的牵引请求，并有预先的试验计划和记录的核查会议。 核查是很难得到正确的部分，我们有多少可以安全地接通环路是通过我们有多少可以信任核查者来控制的。
agents的模拟用户测试：我们部署导航agents，它与直播的应用完全像一个人会那样互动。 这些agents执行动作，读取屏幕，并报告回归。 导航agents能够持续运行相同的验证路径。
代理生产业务：发布后，agents帮助自动化根-原因分析。 当有人使用Forum提交反馈时，agents使用该反馈来调查可能的回归。 agents随后将分析转交决定下一步行动的工程师。
操作模式
这种所有权模式需要具有五个关键组成部分的机制：
- 规则是永久的项目指令。 agent重复两次以上错误时，我们为每个人编码一次更正。
——技能将团队常规变为可负载步骤 agent可以引用。
- Agents将以前需要人工通行证的检查自动化。
- 命令连锁技能和agents进入工作流程。 他们评估复杂性，复制一个bug，计划和实施一个固定，创建拉力请求，并运行一个多阶段的审查。
- 钩子是自动触发器，如每次agent转弯后运行一个插件，安装前检查模拟器连接，创建拉动请求前验证测试。
使环境适应模式
最大的收益来自改变我们的代码和工具，而不是我们的提示。
我们努力让论坛的代码库尽可能直截了当，并选择将建筑中的关键部分模块化，以获得经过战斗测试的基础设施的好处，我们从零开始重建，用再利用来换取代理吞吐量，Agents从他们读的代码中学习规律。 一次和以后的agent会话都会修补一个弱的图案，继承了改进；在agent接下来写的所有东西中留下它和同样的快捷键显示。
给 agents 工具，而不是描述：我们的主要失败模式是 agent 丢失了应用程序中它所在位置的跟踪——当被要求更改组主屏幕时编辑家用种子，或者猜测屏幕坐标。 因此，我们没有给agent描述这个应用，而是给了它一些工具来检查：从模拟器中读取活视图等级，列出实际在屏幕上的元素，并查看一个目标视图的路径——全部在它行动之前。 错误的编辑急剧下降。 在agents触碰我们的系统的地方，我们采用了同样的方法：给agent一个直接检查状态的方法，而不是一个说明理由的方法。
安全AI原型的构建层隔离：随着论坛向生产发展成熟，我们希望早期原型和agent生成的实验有空间运行，同时将生产应用严格限制在完成，审查的工作。 我们想要一个更强的保障而不是仅仅地标原型代码仍然存在在生产建筑。 我们的解决方案是一个单独的建筑口味，一个沙盒应用，它与生产完全共享相同的代码库，框架和设计系统，但完全通过插件/口袋架构将生产建筑的原型代码编译出来。
这一次给了我们三件事：
- 设计者和跨功能伙伴可以自由使用AI工具的原型，而不需要每个变化的循环中有一个工程师。
- 沙盒里建造的任何东西都可以直接移植到生产上而不重建。
任何原型代码都无法崩溃生产应用程序
模式让我们保持快速的AI迭代因为我们有真正的人使用应用程序来保护。
以 AI 压力测试查找真实错误
适应环境所做的不仅仅是使agent更快地与它一起建造——它使得agent成为了测试器。 我们并没有指出一个具体的缺陷。 相反，我们设定了模仿真实用户行为的可重复的压力情景(侵略性滚动，随机分组浏览，快速导航，重复媒体加载)，并例行运行于构建之间。 因为这些运行产生一致的信号(crashes，内存增长，页面断层，UI回归),agent可以分解异常，缩小到触发序列，然后调查根源。
一个这样的运行浮出一个记忆问题。 agent隔离了一个repro，提出一个固定，并验证它——所有开发期间，在应用到达用户之前。 固定在物质上降低了端侧内存的增殖，并跨过反复的应力会话的页面断层。
虽然工程师们做出了建筑决定，但检测和回归监测是自动化和可重复的；一旦检测到异常，agent可以复制隔离，提出用同样的吊带进行固定校验。
将同样的纪律应用于论坛的种子
我们在两个地方应用了人对人的方法：
构建堆栈：Agents绘制了建筑选择和权衡图；工程师随后评价和选择。 我们故意使人类成为目标——决定一个好结果看起来像是产品判断，而不是系统应该为自己定义的东西。
操作堆栈：曾经需要任何工程师知道相关代码路径的问题，现在去调查agent，它收集它需要的东西，并张贴一个带有建议修正的写法。 在手评了一批真正的调查后，我们到达了一个工作流程，其中agent压缩机械工作，并向工程师提供结构化的笔记，然后由工程师验证一个发现是真正的错误还是有意的权衡。
质量的改善并没有更好的刺激。 这是背景。 直到我们给agent同样的代码指针，例问，这个类别的质量急剧上升。 与人类登船的区别在于，你训练一次，以后的每一场课都从它开始。
有用吗？
除了更快的运输，我们运送了清洁剂。 持续的核查在开发过程中而不是在发布之后浮现出系统性问题——如上面的记忆瓶颈。 结果出现在业绩简介中：
- 质量，早期发现：自主应力测试循环在开发期间而不是在发布后被捕获并固定了前述内存问题，大致将内存使用量和页断面减半。
- 速度：论坛在8周内与脸书小组达成核心功能均等
- 持续时间：发布后，agent驱动的调查帮助了工程师分解和root-cause用户反馈。
AI所做的不仅仅是生成代码。 它收紧了我们的质量循环，帮助一个小团队提供高质量的应用与更少的持续重做。
什么工作，什么没有
鸣谢
我们感谢内哈里卡·辛哈，简库，江阳，郭绍章，泽亚章，金纳里·詹格拉，卢荣辉的宝贵贡献。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
- Meta’s newest app, Forum, is for anyone who wants to go deeper into the conversations in their Facebook groups.
- To build Forum, Meta engineers adopted a whole new way of working by bringing an AI agent into the development cycle.
- We’re sharing insights into what it took to build Forum with agentic AI: how we adapted the codebase, tested frameworks and internal tooling for agentic execution, what worked, and what didn’t.
Forum is a standalone Groups app that a small team built from scratch. It’s also where we tested a different way of working: treating an AI agent as a participant in the engineering process rather than a faster way to type.
That experiment needed a definition of success, and ours wasn’t code volume. We measured verified, production-ready outcomes — changes that build, pass tests, and survive review.
From Human-In-The-Loop to Human-On-The-Loop
Pointing AI at the coding step alone doesn’t change much. Our results compounded as we extended the approach to the stages around implementation — planning, building, testing, and verification. The clearest way to see the shift is in who owns each step.
With human-in-the-loop, the engineer drives every step and the AI assists inside it by autocompleting a function, suggesting a fix, or answering a question. Each iteration advances at the pace of the person driving it.
With human-on-the-loop, the agent runs the iteration itself — plan, implement, build, test, correct, repeat — while the engineer sets the goal, watches the run, steps in when it drifts, and approves the result. The person’s job moves from executing the steps to owning the outcome and holding the quality bar. This is the target we are driving toward, not a finished state: some stages run autonomously today, while others still keep an engineer in each iteration.
When the engineer supervises, work stops being strictly sequential. Cycles that used to run one at a time can overlap, and an engineer’s time goes to direction and judgment rather than to sitting through the loop. But that only holds if what comes back can be trusted. Without verification, AI-generated code creates a familiar problem — plausible output that no one has confirmed actually works, which an engineer then has to read, debug, and often discard. Weak signals don’t remove the constraint; they move it from writing code to reviewing code that looks finished and isn’t.
So we set the bar at verification rather than compilation. Compiling isn’t the finish line — a task is complete only once automated tests and visual checks have passed. Agents check their own work before an engineer sees it, which means what reaches review is a smaller set of higher-confidence results rather than a pile of output to sift through. Less gets generated, and less gets discarded. Every shipped outcome still carries an engineer’s sign-off; our effort went into making that sign-off fast and well-evidenced, with build results, test outcomes, and recorded verification sessions attached to the change.
With the engineer outside of every cycle, the loop has to run safely on its own. Four capabilities make that possible:
Planning as technical specification: Agentic execution requires extreme precision. Ambiguity that an engineer might resolve through intuition results in agent failure. We invested in rigorous upstream decomposition and machine-readable context, which tightened the engineering loop for engineers and agents alike.
Automated verification inside the loop is the force multiplier: We integrated automated pass/fail signals — build status, unit tests, and UI spec matching — directly into the agent loop. This enabled asynchronous development producing ready-to-review pull requests with pre-populated test plans and recorded verification sessions. Verification is the hard part to get right, and how much we can safely hand to the loop is gated by how much we can trust the verifiers.
Simulated user testing with agents: We deployed navigation agents that interact with the live app exactly like a person would. These agents perform actions, read the screen, and report regressions. Navigation agents are able to run the same verification paths continuously.
Agentic production operations: After launch, agents help automate root-cause analysis. When someone using Forum submits feedback, the agents use that feedback to investigate possible regressions. The agents then forward the analysis to engineers who decide the next course of action.
The Operating Model
That ownership model needs machinery with five key components:
- Rules are permanent project instructions. When the agent repeats a mistake more than twice, we encode the correction once, for everyone.
- Skills turn team conventions into loadable steps the agent can invoke.
- Agents automate checks that previously required a manual pass.
- Commands chain skills and agents into workflows. They assess complexity, reproduce a bug, plan and implement a fix, create the pull request, and run a multi-stage review.
- Hooks are automated triggers, such as running a linter after every agent turn, checking simulator connectivity before install, and validating tests before a pull request is created.
Adapting the Environment to the Models
The biggest gains came from changing our code and tooling, not our prompts.
Architectural legibility over inherited complexity: We worked to keep Forum’s codebase as straightforward as possible and chose to modularize key pieces of the architecture in order to get the benefits of battle-tested infrastructure while also letting the agents plug and play easily. Where we couldn’t easily do so, we rebuilt from scratch, trading reuse for agentic throughput, and it proved rewarding in development speed. Agents learn patterns from the code they read. Fix a weak pattern once and every future agent session inherits the improvement; leave it and the same shortcut shows up in everything the agent writes next.
Give agents tools, not descriptions: Our main failure mode was the agent losing track of where it was in the app — editing the home feed when asked to change the group home screen, or guessing at screen coordinates. So instead of describing the app to the agent, we gave it tools to check: read the live view hierarchy from the simulator, list the elements actually on screen, and look up the path to a target view — all before it acts. Misdirected edits dropped sharply. We applied the same approach wherever agents touched our systems: give the agent a way to check state directly rather than a description to reason from.
Build-level isolation for safe AI prototyping: As Forum matured toward production, we wanted early-stage prototypes and agent-generated experiments to have room to run while keeping the production app strictly limited to finished, reviewed work. We wanted a stronger guarantee than feature gating alone, where prototype code still exists inside the production build. Our solution was a separate build flavor, a sandbox app that shares the exact same codebase, frameworks, and design system as production, but compiles prototype code out of the production build entirely via a plugin/socket architecture.
This gave us three things at once:
- Designers and cross-functional partners could prototype freely using AI tools without needing an engineer in the loop for each change.
- Anything built in the sandbox could be ported directly to production with no rebuild.
- No prototype code could crash the production app because it physically didn’t exist in that build.
The pattern let us keep fast AI iteration after we had real people using the app to protect.
Finding Real Bugs With AI Stress Testing
Adapting the environment did more than make the agent faster to build with — it made the agent a tester. We didn’t point it at one specific defect. Instead, we set up repeatable stress scenarios that mimic real user behavior (aggressive scrolling, random group browsing, rapid navigation, repeated media loading) and ran them routinely across builds. Because these runs produce consistent signals (crashes, memory growth, page faults, UI regressions), the agent can triage anomalies, narrow to the triggering sequence, and then investigate the root cause.
One such run surfaced a memory issue. The agent isolated a repro, proposed a fix, and verified it — all during development, before the app reached users. The fix materially reduced on-device memory growth and page faults across repeated stress sessions.
While engineers made the architectural decisions, the detection and regression monitoring were automated and repeatable; once an anomaly was detected, the agent could reproduce → isolate → propose a fix → verify with the same harness.
Applying the Same Discipline to Forum’s Feed
We applied the human-on-the-loop approach in two places:
Building the stack: Agents mapped the architectural options and trade-offs; engineers then evaluated and chose. What we deliberately kept human was the target — deciding what a good outcome looks like is a product judgment, not something the system should define for itself.
Operating the stack: Questions that used to require whichever engineer knew the relevant code path now go to an investigation agent that gathers what it needs and posts a write-up with suggested fixes. After hand-scoring a batch of real investigations we arrived at a workflow where the agent compresses the mechanical work and delivers a structured write-up to an engineer, who then validates whether a finding is a real bug or an intentional trade-off.
What improved quality wasn’t better prompting. It was context. One recurring category of investigation came back weak until we gave the agent the same pointers to the relevant code, example queries, and design docs that we’d give any new engineer on day one. The quality of that category jumped. The difference from human onboarding is that you train once, and every future session starts from it.
Did It Work?
Beyond shipping faster, we shipped cleaner. Continuous verification surfaced systemic issues — like the memory bottleneck above — during development rather than after launch. The results show up in the performance profile:
- Quality, found early: The autonomous stress-testing loop caught and fixed the aforementioned memory issue during development rather than post-launch, roughly halving memory use and page faults.
- Velocity: Forum reached core feature parity with Facebook Groups in eight weeks, with AI handling much of the routine implementation so engineers could focus on architecture, product decisions, and quality.
- Leverage that lasted: After launch, agent-driven investigation helped engineers triage and root-cause user feedback.
The AI did more than generate code. It tightened our quality loop, helping a small team deliver a high-quality app with less ongoing rework.
What Worked, and What Did Not
Acknowledgements
We thank Neeharika Sinha, Jane Kou, Gang Yang, Guohao Zhang, Zeya Zhang, Kinnary Jangla, andYonghui Lu for their valuable contributions.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.