ByteByteGo Newsletter

An Ex-Meta L8’s Agentic Engineering Setup

8.5内容质量
An Ex-Meta L8’s Agentic Engineering Setup

TL;DR · AI 摘要

前Meta高级工程师分享其基于智能体的工程实践,显著提升开发效率并实现高质量代码输出。

核心要点

  • 使用智能体后,每天可产出30+高质量PR,效率显著提升。
  • 不再亲自编写大部分代码,而是像工程经理一样指挥智能体团队。
  • 所有工具均为免费开源,适合个人和团队探索使用。

结构提纲

按章节快速跳转。

  1. 作者介绍其从Meta离职后,专注于基于智能体的工程实践。

  2. 使用智能体后,作者每天能产出30+高质量PR,效率显著提升。

  3. 作者不再亲自编写代码,而是像工程经理一样指挥智能体团队。

  4. 作者使用的工具均为免费开源,适合个人和团队探索使用。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 基于智能体的工程实践
    • 生产力提升
      • 每天产出30+高质量PR
    • 工作方式转变
      • 指挥智能体团队
    • 工具与开源
      • 免费开源工具

金句 / Highlights

值得收藏与分享的关键句。

#AI#工程实践#智能体#开源工具
打开原文

前Meta L8工程师的智能工程设置

ByteByteGo

2026年6月23日

新年新指标:评估智能时代AI搜索(赞助)

大多数团队通过运行几个测试查询并希望得到最好的结果来选择一个搜索提供商——这是一条导致幻觉和不可预测失败的配方。来自You.com的这篇技术指南为你提供了评估AI搜索和检索的精确框架。

你将获得:

  • 一个四阶段的AI搜索评估框架
  • 如何构建一组黄金查询以预测实际性能
  • 用于衡量准确性的指标和代码

从“看起来不错”到“已被证明的质量”。

学习如何运行评估

这是由Kun Chen撰写的一篇客座文章,他曾是Meta、Microsoft和Atlassian的L8级首席工程师,领导开发了Atlassian的AI SDLC产品Rovo Dev。此后,他离开了大科技公司,开始独立开发,并全身心投入智能工程。下面,他逐步介绍了他的完整设置。你可以在X上关注他,并在YouTube上订阅他,他分享自己的智能工程工作流程、他构建的开源工具以及他对AI和软件工艺的看法。下面请看Kun的分享。

大家好,我是Kun。为了提供背景,我在公司内部以及许多客户的工程组织中,花了多年时间推动代理在成千上万工程师中的采用。独立开发实际上让我更加深入地使用代理。

使用代理对我的生产力带来的差异是:以前,想象自己能交付30多个高质量的PR并达到我自己的标准是很难的,现在这已成为一个缓慢的一天。我已经达到了一种持续的流畅状态,唯一剩下的瓶颈就是我思维的质量和速度。

这一切并不是来自一个单一的技巧或使用某种热门工具。它来自于一个漫长而常常混乱的过程,以弄清楚什么在现实世界中真正有效,而不是仅仅在演示中听起来不错。简短的版本是,我现在不再亲自编写大部分代码,而是开始像一个工程经理一样,指挥一个代理团队。我停留在决定构建什么以及是否良好的层面,并构建了工具来处理几乎所有中间的事情。

这段旅程中有趣的部分是,我必须消除所有摩擦才能达到这个点。因此,在这篇文章中,我试图逐步分享我为专业和个人项目所做的一切。

如果你也在努力让与代理一起工作更加高效和愉快,我希望这能给你一个起点,并为你节省一些探索的时间。

一些澄清

首先,我在这里分享的是我的个人设置。对我有效的方法可能并不适合每个人。我按照原样分享我的工作流程,主要是希望它能作为有用的参考或灵感,即使你最终没有使用相同的工具。

其次,我与本文中提到的任何第三方产品都没有任何关联,我构建的工具都是免费和开源的。我分享这些特定产品,是因为它们确实是我在设置中使用的。它们通常并不是解决这些问题的唯一选择,因此我鼓励每个人根据自己的兴趣和需求研究不同的选项。

项目详情

为了让这篇文章更具实际性和可操作性,我将通过一个我正在积极构建的真实项目来向你展示我的工作流程。这个项目叫做“Hi Bit”:一个我为儿子开发的AI导师,用来教他如何进行智能体工程。在文章的其余部分,我将从想法到合并的PR,逐步展示Hi Bit项目中一个特定图像输入功能的实现过程,让你能够亲身了解我的智能体工作流程。

当规则失效时,AI会接棒(赞助内容)

当确定性代码触及知识的边界时会发生什么?在这场实时网络研讨会中,你将看到一个基于Temporal实体工作流模式的植物健康监测系统,其中每个植物都是一个长期运行、防崩溃的工作流,它会轮询传感器、触发警报,并且仅在规则用尽时才回退到GPT-4o。

架构非常清晰:首先使用结构化数据,其次使用AI。边界是可以审计的。状态在任何情况下都能保存下来。无论你是在构建病人监测器、供应链检测器,还是任何偶尔需要更智能答案的长期运行过程,这里的模式都可以直接应用。

7月9日,加入我们。

从终端开始

在开发者社区中,关于终端与GUI的争论一直持续不断。

我显然有偏见,因为我从几乎30年前就开始编程,并且多年来在以终端为中心的工作流程上建立了数十年的肌肉记忆。不过,我也偶尔尝试过GUI,从Visual Basic、Visual Studio,到Atom,再到最新的Codex应用。

我坚持使用终端的原因非常简单。当我的双手始终留在键盘上时,我的流程和专注度最好。虽然有些GUI也可以通过键盘快捷键完成所有操作,但它们在这方面非常不一致,这使得难以建立牢固的肌肉记忆。

终端模拟器

多年来我一直使用的终端模拟器是WezTerm。

这是我唯一找到的高性能、高度可定制,并且即使在被迫使用Windows时也能稳定运行的终端。我将其作为单个无边框窗口运行:没有标签页、标题栏或状态栏,真的没有任何多余的东西。

智能体工具

我使用Claude Code来调用Anthropic的模型,对于其他所有内容,我使用OpenCode。

如今,CLI智能体工具已经非常商品化,你使用任何一种都不会出错。我下面分享的几乎所有内容都可以与你找到的任何主流工具兼容。

事实上,我甚至建议避免一些只有部分智能体才有的“花哨”功能,比如自动管理内存。它们往往设计成将你锁定在特定的供应商上,而实际上,你能够切换到任何表现更好的新模型(即使来自不同供应商)会带来很多好处。我努力让我的整个工作流程与智能体无关,这样我就没有切换成本。最终哪款模型会胜出还远未可知,而作为用户,如果你可以使用任何可用的模型,而不是被锁定在某一特定模型上,你将处于一个更好的位置。

  • snacks.nvim:我使用它的选择器来查找文件和在代码库中进行搜索

Tmux

我不让终端模拟器管理标签页,因为我在 tmux 中管理所有会话、窗口、标签页和面板。它是我在整个设置中最有力量的原始工具之一,它同时解锁了以下几项功能:

  • 以我喜欢的方式将终端窗口分割成多个面板
  • 通过键盘完全控制整个终端体验
  • 持久化工作会话和布局
  • 从其他设备访问相同的会话(稍后会详细介绍)

一个流行的替代方案是 Zellij,但 tmux 已经运行得足够好,以至于我没有切换。一旦进入 tmux,我会在左侧创建一个分割用于代理,在右侧创建一个分割用于 Neovim,并将不同的任务分配到不同的标签页中,这些标签页我通常在顶部进行管理。

基本提示

我们现在在终端中,代理正在等待指令。我需要做的就是写一个提示。听起来很容易,对吧?

实际上,你如何编写提示是你工作效率和结果质量之间最重要的杠杆之一。所以让我分享一些对我影响很大的事情。

使用语音输入

多年来,打字一直是我的主要输入方式。但过去几年里,语音识别模型真的改变了游戏规则。你现在可以在 Mac 上免费本地运行高质量的模型,这些模型生成输出的速度非常快。

你说话的速度比打字快得多,所以将语音作为主要输入方式是提高生产力最简单的方法之一。这不仅适用于提示代理,也适用于其他过去需要打字的任何事情。例如,这篇文章大部分是通过语音撰写的。

我使用的解决方案是 OpenSuperWhisper,它完全免费,并且在本地运行 Whisper 模型(turbo v3 large)。我设置了一个热键来触发它,现在我可以在任何可以打字的地方直接说话。还有许多其他免费和付费选项,也能提供很好的体验。

像经理一样委派任务

对于许多新晋的技术主管和人员经理来说,第一个挑战是委派任务。与代理的互动方式也是如此。

我看到人们在向人类和代理委派任务时最常见的错误包括:

  • 要求执行一个动作,而不是一个结果;
  • 没有解释“为什么”。
  • 拿回控制权。

比如“重命名这个变量。”这是一个有效的提示,但它有几个问题:

  • 代理在几秒钟内完成任务,然后再次等待你。它节省的时间几乎和你自己做一样少,而你仍然是瓶颈。
  • 没有“为什么”。你是想为了可读性而重命名?为了遵循团队的惯例?因为有一个你还没提到的未来计划?没有“为什么”,代理就无法建议更好的方案,也不知道下一次如何正确执行。

如果你是在遵循某种惯例,一个更好的提示会是:“让我们审查这段代码,并确保变量命名遵循这个惯例 <link_to_document>。”

这解释了原因,提供了必要的背景,并要求一个结果而不是一个动作。代理可以运行更长时间,以更符合你的目标的方式完成更多任务,并在整个会话中遵循该惯例,而不是为你制造更多问题。

另一种失败模式是重新夺回控制权。当出现错误时,人们会立即想到亲自去做。这种情况经常发生在与初级工程师一起工作的新人技术负责人身上。他们可以通过亲自接手来更快地完成任务,但这样做会使他们成为瓶颈,无法实现扩展。人们在使用人工智能时也会遇到同样的问题:他们看到代理执行了错误的操作,就转而手动执行,从而从未真正发挥代理所带来的杠杆效应。

正确的方法是给予反馈,并帮助对方改进。使用代理时,这实际上更容易实现。你可以直接写入代理的记忆文件(CLAUDE.md 或 AGENTS.md),或者让代理反思自己的错误并更新该文件,以确保同样的错误不再发生。

规划复杂的工作

我现在正在构建的功能是图像输入。我希望 Hi Bit 的聊天框能够接受从剪贴板粘贴的图像,或者打开文件选择器或相机。这比我想象中代理能够一次性完成的功能要复杂一些。起初,我也并不清楚按钮应该放在哪里,或者附加的图像应该是什么样子。

这种情况经常发生:一些我确实无法在一开始就完整描述解决方案的问题。这可能是一个全新的项目,一次重大重构,或者是一个现有系统上的大型功能。在这些情况下,我会与代理合作,先制定一个计划。

在代理社区中,有一种观点是反对技术规划的。他们更倾向于“直接与你的代理对话”。

我选择的是另一种方式,原因如下。当你只是与代理对话时,你必须保持在一个交互会话中。你不断被拉回到对话中,经过几轮之后,很难跟踪实际的计划是什么。终端中的一长段文本也难以解析,而且很难提供有针对性的反馈。

相反,我会在前期集中一段时间,将计划制定到一个自信的状态,这样我就可以将其交给代理进行完全自主的实现,直到完成之前不再干预。这也让我能够并行运行其他任务,而无需频繁切换上下文。

很长一段时间,我都是通过让代理在一个 Markdown 文件中撰写提案,然后对其进行质疑和迭代来完成这项工作的。这方法有效,但现在我有了更好的方法。受到一篇关于使用 HTML 作为交互式工件的文章的启发,我开发了一个名为 Lavish Editor 的工具,用于与代理协作处理任何复杂任务。

因此,我不再让代理“在 Markdown 文件中起草技术计划”,而是让代理“使用 npx lavish-axi 起草技术计划”。Lavish 会引导代理将计划渲染为一个交互式 HTML 页面,并在我的浏览器中打开。它甚至鼓励代理匹配当前项目的外观和感觉,因此 UI 功能的计划在视觉上与实际应用保持一致,这使得判断选项变得容易得多。

几分钟后,代理在浏览器中打开了一个计划。它以目标和背景信息开头,标记了我需要做出的决策,然后列出了三种 UI 选项——一个“+”按钮菜单、一个始终可见的按钮组合和一个智能粘贴瓷砖,每种选项都附有优缺点以及代理的推荐。

真正的价值在于这种互动的来回交流。我喜欢选项 A 的小巧静止状态,但不喜欢它的菜单下拉并拉伸聊天区域。与其写一段文字描述我指的是哪个元素,我直接点击了页面上的那个元素并直接标注:“我们能不能把它改成一个浮在 + 按钮上方的覆盖层?”

代理几乎立刻就返回了我想要的修改版本,我只需点击按钮就完成了剩下的决策。能够如此丰富地与计划进行互动,而不是编辑一个 Markdown 文件,结果大大提高了我的工作效率,而且这种优势不仅仅局限于规划。我现在用 Lavish 进行头脑风暴、审查更改、生成数据报告,以及任何需要视觉化成果和紧密互动的场景。它彻底改变了我的工作方式。

实现

一旦计划明确,实现过程就完全自动化了,我基本上只需要等待代理完成任务后通知我即可。

这里有一点值得一提的是,对于每一个项目,我都会花很多精力确保代理能够端到端地验证自己的更改。以 Hi Bit 为例,我在仓库的 AGENTS.md 文件中保留了明确的指令,说明如何操作应用程序,因此像这样的更改会在返回给我之前由代理进行验证。我经常能实时观看代理通过操作真实应用、附加图像并检查新按钮的实际行为来测试自己的工作。

偶尔,任务过于复杂,无法很好地适应单一的上下文窗口。如果我让代理独自处理,它会填满上下文,发出非常大的请求,最终压缩以腾出空间,有时在这个过程中会丢失重要的上下文。Codex 和 Claude Code 的新 /goal 命令有所帮助,但在我使用它之前就已经有了更好的方法。

我称之为“晚安,玩得开心”,简称 gnhf。它是一个非常简单、长期运行的协调器,我为运行大型任务过夜而构建的;你只需用 gnhf <你的目标> 来调用它。

在内部,它的运作方式与 Ralph Loop 和 Autoresearch 模式类似。它将任务分解为小步骤,每个步骤都在一个新鲜的上下文窗口中运行,该窗口以一个通用的基础上下文和之前步骤的学习内容进行初始化。失败的尝试会自动回滚,下一次尝试会考虑到之前的失败。我还可以设置一个令牌预算,以免醒来时破产。当我回来时,会有一个结构良好的分支和一个 notes.md 文件,总结了所完成的工作。

我通常在以下三种情况下使用 gnhf:

  • 实现一个庞大的计划:gnhf “完全实现这个计划……”
  • 改进一个可衡量的指标,如减少代码行数、提高测试覆盖率、减少启动延迟或页面加载时间:gnhf “改进 <这个指标>,同时保持产品功能不变。”
  • 当你有一个能够对每次尝试进行评分的评估器时,运行大量离线实验。在一个项目中,我通过运行 50 多次布局实验并通过游戏模拟对每次实验进行评分,生成了一个游戏地图。如果手动照看这些实验,可能需要几周时间。

验证

回到图像任务:代理已经完成了工作,并且产生了较大的更改。现在该怎么办?这是许多人真正遇到瓶颈的地方:代码审查。代码实在太多,无法阅读,而且代码审查并不是工作的有趣部分。

我越来越确信,与代理(agents)合作意味着要像一个工程经理那样行事。大多数经理很少直接审查代码。他们让团队互相审查彼此的工作,并且在任何代码发布之前,都会要求提供证据证明它确实有效。AI也是如此,只不过开发者就是经理,而代理则是团队。你必须掌握使用代理来审查其他代理的代码、促使它们自我修正,并生成能证明功能确实有效的产物。

我在这个方面做过很多实验,结果发现有几个因素最为关键:

  • 在一个全新的上下文窗口中运行审查代理。如果你在编写代码的同一会话中进行审查,代理会受到刚刚所做内容的影响,并假设这些操作是被有意为之的。这就像让某人去检查自己的工作。他们虽然能发现一些问题,但效果远不如真正的同行评审。
  • 将模糊的、可能改变产品的决策升级给人类处理。审查者也会犯错。如果你让代理自动修复所有发现的问题,仿佛它们都有效,那么代理可能会偏离你真正想要的方向。将这些决策保留给人类处理,可以让你掌控模糊性。
  • 强制要求端到端的证据。目前的前沿模型在验证更改时,很大程度上依赖于单元测试,这可能是因为它们的训练方式。但我见过无数案例,每个单元测试都通过了,但产品仍然存在漏洞。你必须让代理证明更改确实能端到端地运行。

我将所有这些方法整合到我开发的一个开源工具中,名为 no-mistakes,我现在在图像更改上使用它。首先,我使用 neogit 插件快速扫描差异,并确保它大致符合我所要求的内容。有时代理会完全偏离正确的方向,这在一眼望去时就很明显。

如果看起来合理,我会运行 no-mistakes -y,它会处理其余部分:使用符合规范的提交信息将更改提交到一个描述性命名的分支中,重新基于最新的 main 分支并解决冲突,启动代理进行同行评审并自我修正明显错误,端到端测试更改并生成证据,填补文档空白,修复格式问题,推送代码,打开结构良好的 PR,并监督 CI 直到其变为绿色。

除了那些特意升级给我处理的决策外,所有操作都自动运行。

这个验证流程已成为我整个工作流程中最重要的部分之一。我自己的统计数据表明,通过 no-mistakes 工具推送的更改中,有 68% 存在错误。我真的无法想象没有它,我的代码库会变成什么样子。

并行处理

拥有一个完全自主的实现与验证流程,单个任务可能需要一些时间,这是一件好事,因为它让我可以同时运行更多任务。

处理代理状态

在 tmux 中,这意味着打开一个新窗口。终端标签页也能实现同样的并行处理。重要的是保持这些标签页可见,并在标签页标题中显示每个代理的状态。Claude Code 和 Codex 默认就支持这一点;对于不支持的框架,我编写了小型插件来实现相同的功能,并且我也让 no-mistakes 工具以自定义标题的方式报告其状态。

这个细节让我能够同时运行多个会话而不至于发疯。在任何时候,我都能看到哪些代理正在运行、哪些已经完成、哪些需要我的输入。几个 tmux 快捷键就能让我跳转到任意标签页。

管理工作树

并行运行代理的另一个问题是,当它们共享一个目录时,它们会互相干扰。

Git worktrees 的存在就是为了应对这个问题。worktree 是同一个仓库在另一个目录中的一个高效克隆,你可以在其中并行地进行工作。但 worktree 带来了很多认知负担:放在哪里、如何命名、创建新的还是复用旧的、哪些正在使用、哪些已安装了依赖项、env 文件是否已准备就绪。我真正想关注的是工作本身,而不是在哪里进行工作。

因此,我开发了另一个开源工具,名为 treehouse。你在一个仓库中,想要开始一个并行任务,只需运行 treehouse,它就会将你带入一个已准备好的 worktree。在幕后,它管理着一个 worktree 池,跟踪哪些是空闲的,尽可能复用一个空闲的 worktree(这样依赖项、构建产物和 env 文件已经就绪),并确保在将你带入之前与最新的主分支同步。我不需要考虑这些。我只需运行 treehouse 工具,然后开始工作。

我重复这个过程,通常会同时管理 5 到 10 个任务。我不需要频繁切换上下文,因为其中大多数任务直接进入一个干净的 PR,而不需要我参与。偶尔,no-mistakes 工具会将某些事情升级以等待我的决定,但大多数时候,我只是思考并编写下一条指令。

下面的图示试图展示我所提到的并行化角度:

过了一段时间,图像附件任务的流水线完成,并向我提交了一个准备合并的 PR。沿途已经发现了许多问题并自动修复了,所有内容都记录在 PR 上,因此我可以进行审核。此外,我最喜欢的部分是“测试”部分,其中包含证据(包括截图),证明该功能可以端到端地正常工作。

远程控制

每隔几周,我需要开车送我儿子去参加生日聚会,在那几个小时里,我发现自己几乎无事可做。他和朋友们玩得非常开心,而我则坐在一个没有 Wi-Fi 的地方,想念我的代理,想知道它们是否被阻塞并等待着我。

自从我设置了远程控制功能后,这种情况就停止了。我不使用 Claude Code 或 Codex 的内置远程功能,原因有几个:

  • 我希望所有代理都能使用一致的工作流程,而不是不同的应用程序,它们做着同样的事情,但由于不同公司希望将我锁定,所以彼此隔离。
  • 我想要真正的、完整的终端访问权限,而不是仅限于代理的视图,这样我也可以运行 treehouse、no-mistakes 和 gnhf。
  • 我希望在手机、笔记本电脑和 PC 之间实现完美的连续性。我儿子几乎没有耐心:如果他说是时候离开了,我就站起来离开。如果我在手机上只输入了一半的句子,我希望之后可以在 PC 上继续完成。

因此,我设置了 Tailscale,它将我的 PC、笔记本电脑和手机放在同一个私有网络中,它们可以安全地互相访问。然后我在它们之间使用 ssh(在 Mac 上只需启用“远程登录”)。在我的手机上,我使用一个 SSH 客户端连接到我的 Mac,连接到我的 tmux 会话,瞬间我就进入了同一个工作空间,拥有相同的标签页、相同的代理和相同的环境。

为了保持连接的稳定,我使用 mosh,它是在 SSH 之上的传输层,专门为在不稳定的网络上保持终端状态而构建的,这在蜂窝网络上非常重要。它提供了相同的体验,但更加稳定。

将所有内容整合在一起

那么,所有这些在正常的一天里是如何整合在一起的呢?

  • 通常,我开始是通过说话而不是打字,通过语音描述一个功能或一个复杂的重构。
  • 如果任务复杂,我会让代理在 Lavish Editor 中起草一个计划,并在浏览器中对其进行迭代,直到它正确为止。
  • 一旦计划确定,我会让代理直接执行,或者如果是较大的任务,就交给 gnhf 处理,而我则使用 treehouse 创建一个新的工作树,同时在 tmux 的另一个窗口中并行开始下一个任务。
  • 当代理完成任务后,我不会逐行阅读大量的差异。我会运行 no-mistakes,它会审查代码、进行端到端测试,并在我继续进行其他任务的同时,自动创建一个干净的 PR。
  • 当我离开 Mac 时,我会通过手机 SSH 连入,整个工作空间始终随我而行。

从高层次来看,整个工作流程如下:

每个工具都消除了一个特定的摩擦点,它们一起串联成一个流畅的工作流程,这是我真正享受的。我可以专注于决定要构建什么以及它是否良好,而大部分中间的步骤都可以自动运行。

结语

这就是我认为对我的工作流程产生重大影响的所有内容。回顾过去几年这些是如何逐步整合在一起的,我最大的体会是,随着模型的不断进步,围绕它们的工具和工作流程也会持续演变。今天有效的方法,可能几个月后就会变得过时。

同时,仅仅依赖像 Claude Code 和 Codex 这样的现成产品是远远不够的。总会有改进和更高效的工作流程,可以进一步推动代理的发展。我从构建自定义工具中受益良多,这些工具帮助我消除了遇到的每一个摩擦点。你可能会面临不同的问题,因为你在不同的项目上工作,流程也各不相同。

因此,我鼓励你永远不要接受任何会减慢你工作的东西。如果你的工作流程中的某个部分让你感到沮丧,很可能其他人也遇到了同样的问题。找到一个能解决这个问题的工具,或者自己构建一个并分享出去。我们正处于一场工业革命的中间阶段,这是最富有创造力和重新定义事物运作方式的时机。让我们一起探索和享受这个过程。