- Meta 的最新应用 Forum，面向所有想深入参与 Facebook 群组对话的人。
- 为了打造 Forum，Meta 工程师引入 AI 智能体参与开发周期，采用了一套全新的工作方式。
- 我们将分享使用智能体式 AI 打造 Forum 的经验：如何调整代码库、测试适用于智能体执行的框架和内部工具，哪些做法奏效，哪些没有。
Forum 是一款独立的群组应用，由一个小团队从零打造。这里也是我们测试新工作方式的地方：将 AI 智能体视为工程流程中的参与者，而不是更快的打字工具。
这项实验需要明确成功的定义，而我们的衡量标准不是代码量。我们衡量的是经过验证、可用于生产环境的成果 â 能够构建、通过测试并经得起审查的改动。
仅让 AI 参与编码步骤，改变并不大。随着我们把这种方法扩展到实现前后的各个阶段 â 规划、构建、测试和验证，效果逐步累积。要看清这种转变，最直观的方式是看每个步骤由谁负责。
采用人参与环路时，工程师主导每个步骤，AI 在其中提供协助，例如自动补全函数、建议修复方法或回答问题。每次迭代的进展都受主导者的节奏限制。
采用人监督环路时，智能体自行运行迭代 â 规划、实现、构建、测试、修正、重复 â 工程师设定目标、观察运行情况、在偏离方向时介入，并批准结果。人的职责从执行步骤转为对结果负责并把守质量标准。这是我们正在努力实现的目标，并非已经完成的状态：目前有些阶段可以自主运行，另一些阶段的每次迭代仍需要工程师参与。
由工程师监督时，工作不再严格按顺序进行。过去一次只能运行一个的循环现在可以并行，工程师也能把时间用于指导和判断，而不是坐等循环完成。但这只有在返回结果值得信赖时才成立。缺少验证时，AI 生成的代码会带来一个熟悉的问题 â 看似合理的输出无人确认是否真的可用，工程师随后还得阅读、调试，往往最后只能丢弃。薄弱的信号并没有消除瓶颈，只是把瓶颈从编写代码转移到审查那些看似完成、实际却未完成的代码。
因此，我们把门槛设在验证，而不是编译。编译并非终点 â 只有自动化测试和视觉检查都通过，任务才算完成。工程师看到结果前，智能体会先检查自己的工作，因此送审的是数量更少、可信度更高的结果，而不是一堆需要筛选的输出。生成得更少，丢弃的也更少。每项交付成果仍须由工程师签字确认；我们投入精力，让这一确认过程更快且有充分证据支持，并将构建结果、测试结果和记录下来的验证会话附在改动上。
工程师不再参与每个循环后，循环就必须能够安全地独立运行。四项能力让这成为可能：
**将规划作为技术规格：**智能体式执行要求极高的精确度。工程师可能凭直觉消除的歧义，会导致智能体执行失败。我们投入精力进行严格的前期任务拆解，并提供机器可读的上下文，从而同时收紧工程师与智能体的工程循环。
**环路内的自动化验证是放大效能的关键：**我们将自动化的通过/失败信号 â 构建状态、单元测试和 UI 规格匹配 â 直接集成到智能体循环中。这使异步开发成为可能，并能生成已准备好供审查的拉取请求，其中预先填入了测试计划和记录下来的验证会话。验证是最难做好的一环，而我们能安全交由循环处理多少工作，取决于我们对验证器的信任程度。
**由智能体模拟用户测试：**我们部署了导航智能体，让它们像人一样与线上应用互动。这些智能体执行操作、读取屏幕并报告回归问题。导航智能体可以持续运行相同的验证路径。Â
**智能体式生产运维：**发布后，智能体帮助自动化根因分析。Forum 用户提交反馈时，智能体会利用这些反馈调查可能的回归问题。随后，智能体会把分析转交给工程师，由他们决定下一步行动。ÂÂ
这种责任归属模式需要由五个关键组件构成的工具体系：
- 规则是永久性的项目指令。当智能体重复犯错超过两次，我们就把修正方法记录下来，供所有人使用。
- 技能将团队惯例转化为可加载、可由智能体调用的步骤。
- 智能体自动执行以前需要人工检查的事项。Â
- 命令将技能和智能体串联成工作流。它们会评估复杂度、复现错误、规划并实现修复、创建拉取请求，并执行多阶段审查。
- 钩子是自动触发器，例如在每轮智能体运行后执行代码检查器、安装前检查模拟器连接，以及创建拉取请求前验证测试。
最大的提升来自修改代码和工具，而非提示词。Â
**优先考虑架构清晰易懂，而不是继承复杂性：**我们努力让 Forum 的代码库尽可能直观，并选择将架构中的关键部分模块化，以兼得经过实战检验的基础设施带来的好处，同时让智能体能够轻松接入和组合使用。无法轻松做到这一点的地方，我们就从零重建，以复用为代价换取智能体执行吞吐量；事实证明，这提升了开发速度，值得投入。智能体会从所读代码中学习模式。修正一次薄弱模式，之后每次智能体会话都会继承这项改进；若放任不管，同样的捷径就会出现在智能体之后写下的所有内容中。Â
**给智能体工具，而不是描述：**我们遇到的主要问题是智能体会弄错自己在应用中的位置 â 被要求修改群组主页时却去编辑动态主页，或者猜测屏幕坐标。因此，我们没有向智能体描述应用，而是给它检查工具：读取模拟器中的实时视图层级、列出屏幕上实际显示的元素，并查找目标视图的路径 â 在采取行动前完成这些检查。误操作大幅减少。我们把同样的方法用在智能体接触系统的各个环节：让智能体直接检查状态，而不是只给它一段描述供其推断。
在构建层面隔离，以安全进行 AI 原型开发：随着 Forum 逐渐成熟并迈向生产环境，我们希望早期原型和智能体生成的实验有足够空间运行，同时严格确保生产应用只包含完成并经过审查的工作。我们希望比单靠功能开关提供更强的保障，因为使用功能开关时，原型代码仍存在于生产构建中。我们的解决方案是采用独立构建变体：一个沙盒应用，与生产环境共享完全相同的代码库、框架和设计系统，但通过插件/套接字架构将原型代码完全从生产构建中编译排除。Â
这让我们同时实现了三件事：Â
- 设计师和跨职能合作伙伴可以自由使用 AI 工具制作原型，无需每次改动都让工程师参与。Â
- 在沙盒中构建的任何内容都可以直接移植到生产环境，无需重新构建。Â
- 原型代码在生产构建中根本不存在，因此不可能导致生产应用崩溃。Â
这种模式让我们在已有真实用户使用应用的情况下，仍能保持快速的 AI 迭代，以便及时保护用户。
调整环境不只是让智能体更快地参与构建 â 还让智能体成为测试人员。我们没有让它针对某个特定缺陷，而是设置了可重复的压力场景，模拟真实用户行为（快速连续滚动、随机浏览群组、快速导航、反复加载媒体），并定期在不同构建版本上运行。由于这些运行会产生一致的信号（崩溃、内存增长、页面错误、UI 回归），智能体可以对异常分类、缩小到触发问题的操作序列，再调查根本原因。
其中一次运行发现了内存问题。智能体定位并复现了问题，提出修复方案并完成验证 â 全部在开发期间、应用触达用户之前完成。该修复显著降低了多次压力测试期间设备端的内存增长和页面错误。
工程师负责架构决策，而检测与回归监控则实现了自动化和可重复执行；一旦发现异常，智能体便可按同一套测试工具链复现 â 定位 â 提出修复方案 â 验证。
我们在两个方面采用了人监督环路的方式：
**构建技术栈：**智能体梳理架构选项及其权衡，随后由工程师评估并作出选择。我们有意保留由人来设定目标 â 判断什么样的结果才算好，是产品层面的判断，不应由系统自行定义。
**运维技术栈：**过去需要由熟悉相关代码路径的工程师回答的问题，现在交给调查智能体处理。它会收集所需信息，并发布包含建议修复方法的报告。我们对一批真实调查进行人工评分后，形成了一套工作流：智能体压缩机械性工作，并向工程师提交结构化报告；工程师随后验证调查结果究竟是真实错误，还是有意为之的权衡。Â
提升质量的关键不是更好的提示词，而是上下文。有一类调查结果一直不理想，直到我们给智能体提供了相关代码位置、示例查询和设计文档的指引，就像第一天带新工程师入职时会提供的资料一样。该类调查的质量随之大幅提升。与人工入职培训的区别在于，训练一次之后，每次未来的会话都会从这些资料开始。
除了更快交付，我们交付的质量也更高。持续验证在开发期间就发现了系统性问题 â 例如上述内存瓶颈 â 而不是等到发布后才发现。结果反映在性能指标中：
- **及早发现质量问题：**自主压力测试循环在开发期间而非发布后发现并修复了前述内存问题，内存使用量和页面错误大约减半。
- **速度：**Forum 在八周内实现了与 Facebook 群组核心功能对等，AI 负责大量常规实现工作，让工程师能够专注于架构、产品决策和质量。
- **持久的效能提升：**发布后，由智能体驱动的调查帮助工程师对用户反馈进行分类并找出根本原因。Â
AI 做的不只是生成代码。它还收紧了我们的质量循环，帮助小团队以更少的持续返工交付高质量应用。
我们感谢 Neeharika Sinha*、* Jane Kou*、* Gang Yang*、* Guohao Zhang*、* Zeya Zhang*、* Kinnary Jangla 和 Yonghui Lu 的宝贵贡献。Â
这篇文章 《Meta 如何以 AI 原生工程方式构建 Forum》最初发表于 Meta 工程。