#Agent #软件工程 #验证 #代码架构
演讲者：Lauren（X：@poteto）。依据用户提供的 38 分钟中文字幕整理为可阅读文稿。保留论证顺序和关键例子，合并断句、重复与语气词，并将字幕中多种写法的产品名统一为 Grok @Bot。它是整理稿，不是逐字校对稿；专有名词和具体组织归属以原视频为准。原始字幕：
/home/hansong/.hermes/attachments/历史 _ X-zh-CN-translation.srt。
大家好，我是 Lauren，你可能在 X 上认识我，用户名是 poteto。我在 Grok @Bot 上工作。上个月，我向生产环境提交了 2000 个 PR。做到这件事，核心是信任：当我没有盯着 Agent 时，我能否相信它们仍然会交付高质量的工作？
如果把 Agent 的工作环境设计好，个人乃至整个团队都可能以更快的速度产出高质量代码。有人称之为软件工厂，我更喜欢米其林厨房。软件产品是创造性工作；即使我们不再亲手制作每个组件，仍要对最终结果负责。厨师如何分工、设备如何配置、人员如何训练、清洁和后勤如何安排，都会影响端上桌的菜。工程团队也一样，需要设计供 Agent 工作的环境。
六个月前，我刚加入 Cursor，面对的是一个全新的代码库和产品。当时团队正在开发新的 Agent 窗口，原有界面有不少性能问题。因为我此前在 React 团队工作过，经理希望我参与解决。很快我发现，排查性能的过程高度依赖手工操作：打开 Chrome DevTools、采集性能追踪和堆快照、找出热点。与此同时，PR 还在持续合并。面对不断变化的应用，我甚至难以判断性能何时发生了退化。
于是我想到：既然有 Agent，为什么不能让它自己运行应用、采集追踪、理解数据、定位热点，并反复改进性能？这成为我开始构建验证技能的起点。此后几个月，我的产出迅速提升。每月 2000 个 PR 从来不是预设目标；我逐渐意识到，自己打造的工具、技能和代码库改动，都是在解决同一件事：把工程师掌握的知识交给 Agent，让我不再成为每一步的瓶颈。
刚开始使用 Agent 时，很多人仍停留在一人看着一到五个 Agent 的阶段。你得照看每段对话，不断干预和纠偏；人一离开，工作就停下，或者 Agent 开始走偏。这个阶段尤其难突破，因为增加数量并不能补足信任。直接扩展到上百个子 Agent 或云端 Agent，可能得到的只是大量草率 PR、功能回退和线上漏洞。真正的问题是：如何使 Agent 的工作值得信任？
我从性能问题入手，意识到验证能力有不同层次。一端是实际运行应用、调试、采集追踪和堆快照，取得可观察的证据；另一端是形式化方法，例如使用 Lean、TLA+ 来检查业务不变量，证明系统始终符合约束。后者更难，也仍有开放问题；多数团队先把前者做好，就能取得很大进展。
我在 Cursor Agent 窗口上构建的第一个验证技能，字幕称为 Control Glass。它教 Agent 运行应用，并通过 Chrome DevTools Protocol 获取追踪数据。这个技能经过多次迭代，最终形成两个互相补足的部分。
第一部分是可复用的 CLI。Agent 需要稳定地启动应用、收集追踪和其他证据，判断代码是否按预期运行、性能指标是否达标。与其让每次会话临时编写一份脚本，不如把经过打磨的命令行工具放在技能目录里，让每个 Agent 都使用同一套经过验证的流程。当然，这套工具本身也得覆盖不同场景，可靠地操作应用。
第二部分是功能地图（feature map）。这个想法来自一个实际问题：用户在 Slack 中发来一张只露出界面局部的截图，再附上几个问号。Agent 虽然能运行应用，却不知道截图对应哪个功能，更无法判断用户到底想表达什么。功能地图相当于一份具体的产品记忆：应用有哪些功能，各自解决什么问题；用户通过什么键盘快捷键或 DOM 元素进入；相关操作会带来什么结果。它存放在代码库的技能目录中，并由自动化流程维护。
CLI 提供可重复的操作和证据，功能地图提供对产品及用户请求的理解。两者结合后，Agent 可以从模糊的内部或外部反馈出发，定位功能、操作应用、采集追踪、验证结果。这些控制与验证技能逐渐成为团队需要持续维护的基础设施。信任由此建立在 Agent 能拿出的证据上，而非它自己宣称已经完成。
验证首先解决正确性问题：例如结账按钮是否真的能完成购物车结账。实际运行并观察结果，可以给出经验证据。但功能正确并不自动说明性能良好，更不能说明代码质量足够高。
要让 Agent 像成熟工程师一样工作，还需要把调试、功能开发、原型设计等任务的工作方法编码进去。我创建的 pstack 插件是一组技能和操作手册，许多内容直接来自我自己做软件工程时的流程。它们教 Agent 按预期方式调查问题、实现功能、组织代码，并检查结果。
团队里有经验的工程师可以共同维护技能仓库，把个人做事方式变成团队可复用的能力。将工程工作流与验证技能结合，Agent 既能给出功能正确的证据，也能按照质量要求工作。性能方面还可以收集真实的数字、统计信息和遥测数据，而不是凭感觉判断。
不过，技能只是其中一层。更深的一层，是让代码库本身适合 Agent 工作。
如果相信未来大量代码会由 Agent 编写，工程团队就该设计一种让它们默认更容易做对的代码库。原因很简单：Agent 倾向于延续眼前已经存在的模式。它读到的文件会进入上下文，而它通常不会在每个 PR 里重构整个项目，只会沿着已有结构继续写。因此，代码库是最有力量的记忆之一。
当你反复纠正同一种错误，可以按约束强度思考几个层次：
字幕里把这些统称为几个方面，核心顺序是清楚的：先考虑能否用代码结构消除错误，再用静态分析拦住它，随后才把经验写成规则、BugBot 检查和技能。人工评论是发现待固化知识的来源，不是长期承载全部知识的地方。
我们在 Grok @Bot 的代码库中投入精力构建了 Dune，一个面向 Agent 的客户端框架。它受到 Cursor Agent 窗口性能问题的启发。一个重要观察是：Agent 喜欢走捷径。因此，与其一遍遍告诫它不要走捷径，不如把框架设计成正确路径最省力、错误路径受限制。
这样的代码库对习惯自由发挥的人类工程师可能显得繁琐，却能帮助上下文不足的 Agent 稳定交付。现在进入代码库提交功能的人也可能是设计师、产品经理或 CEO；带着少量上下文启动 Agent，仍应尽可能得到可靠结果。
代码库作为记忆有两面性。好的模式会被复制，坏的模式也会被复制。一个临时变通方案，或者解释变通方案的注释，原本只是局部处理；Agent 看见之后反复照搬，几天或几周后就可能变成事实上的全局约定。代码库应该保持在这样一种状态：下一个 Agent 复制现有模式时，你乐于看到它继续传播。
我曾以为 Agent 在代码里添加注释没什么问题。人类工程师也会用注释解释边界情况和必要的变通方案。但在 Cursor 代码库里，我发现 Agent 常把注释当作不解决根本问题的理由，只给代码打一个短期补丁。基于这种观察，Dune 对注释作了严格限制，演讲中提到的是禁止注释。这是针对其具体代码库和行为模式作出的选择，不能直接当作所有项目都适用的普遍规则。
团队需要有人承担园丁的角色：观察哪些坏模式会悄悄扩散，尽早处理。Dune 的原则可以归纳为三件事。首先，清理已有技术债务，避免 Agent 把债务当作范例。其次，为常见任务提供单一、清晰的推荐路径，让目录约定、依赖规则、lint 和 CI 一起引导它。再次，发现新坏模式时，先考虑写下约束阻止它继续扩散；即使暂时无法立刻清理全部历史代码，也能先止损，之后再逐步清理。
Dune 还把这些原则落实到具体架构中。功能代码集中放置，不同部分有明确入口与导入边界。比如在 Electron 应用中，主进程的代码不能随意进入渲染线程。Cursor Agent 窗口曾出现过慢代码意外导入渲染线程的问题，导致界面卡顿。为了达到每秒 60 帧，单帧预算约为 16 毫秒；每秒 120 帧时约为 8 毫秒。渲染线程需要避免长任务，必要时把工作拆成小块。Dune 通过导入约束和依赖关系检查守住边界，让曾经造成性能问题的模式更难重新出现。
Dune 的具体目录设计不是这场演讲的重点。更重要的是：团队可以把最优秀工程师掌握的经验，从风格指南和口头审查意见里提取出来，编码到框架、代码结构和自动约束中。代码库因此成为一份不断被后续 Agent 读取和延续的团队记忆。
当代码库、静态检查、规则、BugBot、技能和验证流程逐步配齐，团队就可以从每个 PR 都要人盯着，转向更高程度的并行工作。哪怕是上下文较少的 Agent，也有机会沿着现成路径交付合格代码。
米其林厨房的类比在这里仍然成立：为厨师配置工具、提供训练、安排动线；发现某个人总被同一处障碍绊倒，就改变厨房布局，避免其他人重复受影响。工程团队也应这样对待代码库和 Agent 的工作环境。
Grok @Bot 可以承担外循环的工作：连接 Slack、Datadog、Sentry、PlanetScale 等工具，收集产品和系统中的事件及上下文，进而启动云端 Agent。有些人称这为公司大脑；我认为未必需要先建设一套庞大基础设施。把现有工具接通，让 Agent 使用它们，再将外部事件和已经建立的工程约束连接起来，就可以逐步建立自己的米其林厨房。
例如，Grok @Bot 的例程可以订阅 Slack 讨论或 Sentry 警报，在事件出现时自动启动任务。Cursor 自动化和 SDK 也可以复用既有的 Agent 基础设施。各种约束与能力相互叠加后，团队可以自动复现缺陷报告、发起 PR，并把工程师从反复的机械处理里解放出来。
我希望大家记住一件事：Agent 的信任来自逐步建立的工作环境。每当你发现自己又在纠正 Agent，就不要只修这一次的输出。先问：能否调整架构或数据结构，让它以后无法再犯？能否用静态分析拦住？还有哪些判断需要写进规则、BugBot 或技能？是否具备验证工具，让它能自己拿出证据？
当这些层次共同工作时，人可以真正信任环境，允许 Agent 更自由地行动。这没有隐藏的捷径。我在 Grok @Bot 代码库上花了大量时间，才逐步达到这样的状态。希望这些经验能帮助你搭建自己的米其林厨房。
整理说明：本稿按字幕信息重组为章节和段落，省略重复口误与演示翻页语句，保留主要论点、案例、工具名、层次顺序及数值。字幕存在自动识别或翻译误差，特别是 Control Glass 的名称、组织归属及 Dune 个别架构名词，引用时请回看原视频核对。演讲视频链接未随字幕提供。