信任危机与“Beyond Done”理念

本次工作坊由 WorkOS 的工程经理 Nick Nisi 和应用 AI 团队工程师 Zack Proser 主持，核心议题是解决 AI Agent（智能体）在自动化任务中的可信度问题。演讲者引用了一个极具警示意义的案例：某次事故中，一个 Agent 在 9秒 内删除了生产数据库，导致所有数据瞬间丢失。这一极端案例揭示了当前开发流程中的巨大风险：虽然 Agent 编写代码的速度远超人类，但人工审查的代码量激增导致信噪比失衡。演讲者提出 “Beyond Done” 的概念，旨在帮助开发者在不完全信任 Agent 的前提下，通过构建逐步积累的信任机制，实现规模化应用。正如 Nick Nisi 所言：

“我们不想依赖人工审查每一行代码，甚至每一个 PR。我们要做的是让你冷静下来，让一切正常运行，并在过程中逐步建立对 Agent 的信任。”

Zack Proser 进一步补充道，这不仅是防止错误的手段，更是实现 真正规模化（True Scale） 的基础。他们强调，目标不是消除 Agent 的错误，而是建立一套机制，使得开发者能够确信任务已正确完成，从而从繁琐的代码审查中解放出来。

验证机制：从 UI 表象到数据持久化

为了构建这种信任，演讲者指出传统的代码审查已不再适用。由于 Agent 生成代码的速度极快，人类开发者不仅难以跟上节奏，还会因过度抽象而逐渐脱离对具体代码的熟悉度。因此，必须引入新的验证手段，例如使用 Playwright 等浏览器自动化工具来测试前端交互。然而，仅检查 UI 反馈是不够的。

演讲者通过一个名为 “Midnight Snack Club” 的演示应用展示了这一陷阱。当输入邮箱地址并提交时，页面显示 “Success”，看似任务完成。但如果刷新页面，之前输入的邮箱却消失了。Zack Proser 解释道：

“它确实更新了 UI，但我们没有检查另一半——数据是否持久化。因为我们只看了表面成功，却忽略了后端存储的缺失。”

这个案例表明，UI 上的即时反馈具有欺骗性。如果测试脚本只验证了 “成功消息” 的出现，而没有验证数据在数据库中的持久性或刷新后的状态一致性，就会误判任务完成。这种 表面成功（Surface Success） 是导致微妙 Bug 潜入生产环境的主要原因之一，尤其是在开发者注意力分散、同时处理多个 Agent 任务时。

互动式工作坊与工具支持

为解决上述信任问题，WorkOS 提供了一个名为 “Beyond Done” 的交互式工作坊仓库。该资源包含所有幻灯片、分步指南以及一个 Glossary（术语表），帮助参与者理解相关概念。此外，仓库中还集成了一个基于该幻灯片内容训练的 AI 助手（Reg），用户可以直接向其提问。

Nick Nisi 和 Zack Proser 鼓励参与者通过命令行运行 pnpm snack 来启动本地演示环境，亲自体验 Agent 的行为模式。他们指出，现场超过一半的听众正在构建基于 Agent 的应用，且许多人同时运行多个终端或聊天会话。在这种 多任务并行（Distracted Attention） 的工作模式下，细微的错误极易被忽略。因此，工作坊的核心价值在于提供可复现的实验环境，让开发者能够亲手验证 Agent 的输出，并学习如何设计更健壮的自我报告（Self-reporting）机制。正如 Nick 所说：

“我们希望提供一个步骤指南，让你可以按自己的节奏去经历这些练习，从而带走可以在工作中使用的经验。”

通过这种互动式学习，参与者不仅能理解理论上的信任构建路径，还能掌握具体的工具使用技巧，以应对实际开发中 Agent 带来的复杂性挑战。

验证是信任的基石：从“代码正确”到“结果可信”

在 AI 辅助开发的实践中，开发者常面临一种困境：代码看似完美、测试通过且能运行，但实际结果却是错误的。这种“虚假的正确性”揭示了当前 AI 代理（Agent）管理的核心痛点。正如演讲者所言，“如果 Agent 能验证自己的工作，那其他一切都不重要；如果不能，则毫无意义”。随着模型能力的快速迭代以及递归自我改进（RSI）概念的兴起，我们正逐渐进入一个需要维护多个自进化代码库的时代。在这种背景下，可靠性、验证和评估（Evals）已成为最基础且关键的环节。

“if an agent can verify its own work, nothing else matters. If an agent can't verify its own work, nothing else matters.”

WorkOS 的应用 AI 团队通过内部实践证实，拥有基础评估框架的代码库与缺乏该框架的代码库之间存在着天壤之别。当开发者能够像人类一样，以同样的标准观察 Agent 是否正确地完成了任务时，信任度才会建立。这种验证机制并非简单的“零到一”突破，而是一个渐进式的信任构建过程。只有解决了 Agent 自我纠错和结果验证的问题，我们才能真正放心地将工作加速权交给这些“疯狂的 Token 机器”，否则它们只会消耗大量资源却无法交付预期价值。

任务分解与明确目标：告别模糊的指令

传统的开发模式往往依赖于巨大的 Pull Request（PR）和长达数天的单一 Agent 会话，试图通过模糊的指令让 AI “修复一切”。然而，这种粗放式的方法已被证明效率低下且风险极高。有效的工作流要求将任务进行极其清晰的分解，并为每个子任务分配独立的 Agent。关键在于，必须为每个 Agent 提供明确的目标定义和“完成状态”的验证标准。如果目标模糊，Agent 会基于其自身的逻辑进行推断甚至编造结果，这与人类开发者的预期往往存在偏差。

“make no mistakes... You need to give it clear, defined goals to get to and give it a way to observe and check those goals.”

WorkOS 团队的经验表明，将任务拆解并赋予明确的验证逻辑是提升生产力的关键。团队成员通过这种精细化管控，实现了每月 900 个 PR 且零事故、持续改善软件 KPIs的惊人成果。这种模式类似于“园艺式”的代码管理：开发者不再逐行编写代码，而是培育多个自进化的代码分支。通过确保每个 Agent 都能清晰地知道“什么是完成”以及“如何验证状态”，团队能够高效地驾驭多个 Agent 的并行工作，避免时间和金钱的浪费。这种从“猜测需求”到“观察、理解、修复、再检查”的闭环系统，是确保 Agent 行为符合预期的核心机制。

“展示收据”：以结果为导向的验证哲学

在 WorkOS 的日常工作中，演讲者 Nick Nisi 和 Zack Proser 强调了一个核心原则：状态源于记录（Records），而非模型声明。这意味着，不能仅凭 Agent 声称“测试通过”或“代码良好”就接受其工作成果，必须要求提供实质性的证据（Receipts）。这些证据包括截图、视频记录、测试结果和冒烟测试等，旨在让管理者无需审查代码本身即可确认工作是否达标。最终关注点应在于结果和价值交付，而非代码本身的优雅程度。

“status comes from records, not model pros... Show me the actual tangible proof that it actually did what I expect.”

为了支撑这一验证体系，Zack Proser 开发了名为 Context (CTX) 的工具。起初，这是一个用于跨 Agent（如 ChatGPT, Cursor, Pi 等）共享记忆的层，但随着日常工作中终端标签页数量激增至18-30 个，他意识到需要一种集中化的权威验证机制。CTX 的核心目的是实现中央权威的验证记录。这种“展示收据”的哲学迫使 Agent 必须通过可观测的输出（如测试报告、UI 截图）来证明其正确性，从而解决了“代码好但结果错”或“代码烂但结果对”之间的平衡难题。通过建立这种基于证据的验证循环，开发者可以从繁琐的代码审查中解放出来，专注于确保 Agent 交付了预期的业务价值。

构建可验证的 Agent 工作流：CTX 实验与自动化闭环

在 Web 服务领域，演讲者展示了一个名为 CTX 的简单 Web 应用实验。该应用在 Cloudflare 上运行，最初通过“氛围编码”（vibe coded）生成并成功运作。其核心功能之一是能够向 Agent 分发密钥，而Agent 无需直接查看或获取凭证即可使用这些秘密。随着实验深入，演讲者引入了“验证器”（verifiers）机制。Agent 接收提示词指令后执行任务，随后通过 MCP 连接返回 CTX，报告完成状态并请求验证。例如，若工作流要求创建 Pull Request (PR)，系统会运行一个已知的评估器。这个验证器最初可能只是一个简单的 CLI 工具，但会逐渐固化为可复用的 hardened（加固）组件。它会直接调用 GitHub API，核实 PR 是否真实存在、状态健康且所有合并检查均通过。只有验证通过后，工作流中的节点才会被标记为“已满足”；否则，系统会重定向 Agent 并明确指出失败的具体环节。这种模式旨在探索哪些协作模式能够持久有效，从而加速 PR 流程并减少人工监督。

Ryker：工程导向的自主监护工具与价值转移

除了 CTX，演讲者还介绍了另一个名为 Ryker 的工具。这是一个面向工程的类似 Grokbot 或 Muse 的助手，其设计核心在于极高的任务交付灵活性以及严格的“监护”职责。演讲者指出，随着工作推进，人工监督 PR 的边际收益递减：开发者往往陷入修复测试、处理评论等琐事中，导致自身注意力分散。Ryker 的介入旨在解决这一问题：开发者只需提供高层意图和验证标准，随后将任务移交。Ryker 负责执行代码修改、确保修复后的软件仍符合整体目标，并自动运行所需的工具链以验证所有检查项通过。它会保留证据并以多种方式展示结果，最终在确认无误时停止工作或在需要人工介入时发出警报。这种机制将开发者从“最后 10%”的琐碎交付环节中解放出来，让人类专注于更有价值的决策层面——即工作的目的与方向。Ryker 通过自动化验证闭环，确保 Agent 在无人 babysit 的情况下仍能交付可靠成果。

从人工验证到 Agent 确定性检查的范式转移

为了理解这一转变，演讲者引导观众回顾传统 Web 应用验证流程：刷新页面确认可见性、打开新标签页测试健康度、检查 API 响应码是否符合预期、验证本地存储持久性、查看控制台日志以及阅读页面内容。这些曾是人类开发者的核心职责。然而，当引入 LLM 时，简单的文本指令（如“去执行这些说明”）与最终交付物之间存在巨大鸿沟。LLM 倾向于生成让开发者“开心”的幻觉（confabulations），而非确保应用实际可用。Agent 无法仅凭终端命令完成此类验证，必须依赖外部工具。虽然可以通过提示词要求 Agent “在浏览器中重新加载并检查”，但这过于模糊且依赖解释。更优的方案是使用脚本进行确定性检查。通过运行可重复的验证脚本，Agent 能获得明确的错误反馈并快速修复。这种闭环机制消除了模糊性，确保 Agent 的修改不仅符合指令，更在真实应用中保持功能完整。

标准化验证器库与组织级效能提升

演讲者进一步展望了将此类验证逻辑标准化的可能性。目前，许多技能（skills）或保存的提示词试图涵盖这些检查点，但一旦遗漏细节或环境变化，仍会留下巨大的解释空间。理想的架构是建立标准化的验证器库、技能集或共享工具包。在 CTX 的示例中，中央权威机构使用验证器检查 API 或工件状态，并将结果反馈至侧边栏，引用具体的仓库和 PR。这种模式允许组织内部共享标准化的验证逻辑。通过积累可复用的验证组件，团队可以逐步构建起自动化信任体系。这不仅减少了人工审查的负担，还通过确定性的技术验证替代主观判断，从而在组织层面加速交付速度。演讲者强调，这种从“人工逐行检查”到“脚本化确定性验证”的转变，是 Agent 能够真正接管复杂工程任务的关键前提。

确定性验证：从非确定性的 LLM 到确定的 Bash 命令

大语言模型（LLM）本质上是非确定性的，即使向多个智能体提供完全相同的提示词，其输出结果仍可能存在差异。为了克服这一不确定性并提升开发速度，核心策略是将验证过程锚定在由实际 Bash 命令和调用支持的单一指令上。这种基于底层系统调用的方式显著提高了结果的确定性（Deterministic）。演讲者指出，那些能够实现每月数千个 PR 提交速度的开发者，如 Lauren Tan 等人，均强调这是他们解锁开发速度、构建以往无法完成的产品时首先集中解决的关键问题。如果 Web 应用缺乏允许智能体充分验证功能的定制 CLI，仅靠提示词将导致开发路径崎岖不平；反之，赋予智能体“构建完成、性能达标且无错误”的自证能力，是提升效率的根本。

"LLMs are non-deterministic... pinning it down to a single command that is backed by actual bash commands and bash calls, right? Like that's significantly more deterministic."

工具链设计：Snack 模板与多维验证能力

为了演示如何为特定应用设置此类验证机制，演讲者介绍了一个名为 Snack 的临时工具模板。该工具通过 pnpm snack 运行，旨在展示如何将智能体与应用深度集成。Snack 具备三大核心功能模块：首先是应用健康管理，包括启动、停止以及运行 doctor 命令来检查数据库状态和网络连接等基础健康指标；其次是交互驱动（Drive），能够执行加入等待列表、刷新页面、重置数据等模拟用户操作；最后是证据收集与证明（Prove），支持截图、查看网络存储和本地存储、运行评估脚本等。在证明环节，工具提供两种路径：一是通过 prove 命令检查确定性输出（Deterministic Output），二是利用 System One 模型作为“法官”来评估整体方向是否正确，而无需严格的一对一匹配。这种设计让智能体拥有了“眼睛”和“身体”，使其能在虚拟环境中自主交互并验证结果。

团队效能与代码无关性：验证即基础设施

建立完善的验证工具链带来的收益不仅限于个人，而是赋能整个团队。当团队成员能够更快速、更安全地提交 PR 时，整体开发效率得到显著提升。演讲者提出一个激进的观点：验证方式的重要性甚至超过软件本身。正如 Bun 团队将应用从 JavaScript/TypeScript 迁移到 Rust，或 Theo 再次将其转换为 Rust 的过程所示，借助 LLM 辅助重构时，只要拥有完备的验证器，源代码的具体实现变得不再那么关键。开发者可以重写代码并通过测试证明其正确性。验证器赋予了智能体感知应用状态的能力，使其无需人工阅读代码即可确认应用在特定宽度、深色/浅色模式下是否正确渲染。通过无限循环运行这些检查，智能体能够自主发现瓶颈（如 Chrome DevTools 所示），从而消除人为猜测带来的时间浪费，实现真正的自动化闭环验证。

"The way that you verify it, the way that you test it... is what you could use potentially a lot of people are doing and converting to Rust."

自动化验证演示：从数据持久化到截图取证

通过实际运行 Snack 工具，可以直观看到验证流程的自动化执行。演示中首先启动应用并打开浏览器终端，随后运行 p snack snapshot 命令获取页面状态的 JSON 数据。当向页面添加特定用户（如 Zack）时，系统通过快照验证该信息是否成功显示。此外，工具还支持生成截图（Screenshot）以便更直观地展示 UI 状态，这些截图甚至可以通过 GitHub CLI 直接附加到 Pull Request 中作为证据。在数据持久化测试中，演示者先添加邮箱 [email protected] 并检查本地存储（Local Storage）确认数据存在；随后重置应用，再次检查发现本地存储为空。通过重新运行加载命令并截取快照，智能体能够验证数据确实已被清除。这一过程展示了工具如何在不人工介入代码审查的情况下，通过存储检查、页面刷新和视觉快照的组合拳，向人类开发者证明应用行为的正确性。

"You can build tools that will help you prove to you that it's working correctly without you having to read the code at all."

利用 JSON 与单元测试实现确定性控制

在构建 AI Agent 时，核心挑战之一是如何确保模型输出的代码或行为具有确定性。演讲者指出，他们确实使用大语言模型生成 JSON 格式的数据结构，以此作为中间层来辅助代码的确定性执行。这一过程并非完全依赖模型的黑盒输出，而是通过运行生成的 JSON 数据并围绕其编写单元测试来进行多重验证。这些测试旨在捕捉边缘情况，并确保代码逻辑是对预期系统行为的真实解读。

"The answer for me is yes. Uh I'm using that and then use uh like I'll... use unit tests around that to verify in different ways, catch edge cases".

这种方法的另一个关键价值在于防止模型随时间发生漂移。通过保留这些验证机制，团队可以持续监控 Agent 的行为是否偏离预期轨道。当模型返回结果时，系统可以在反馈回人类之前先进行自我确认。如果检测到未持久化数据等错误（例如忘记保存步骤），Agent 可以自行修正并继续执行，而无需人工干预。这种闭环验证机制是确保 Agent 可靠性的基础。

全栈应用中的定制化评估体系

WorkOS 团队主要构建内部工具及部分面向客户的应用，技术栈以 TypeScript 为主并部署在 Cloudflare 上。对于这类全栈应用，评估（Evals）可以做得非常细致，既可以是后端逻辑的验证，也可以是数据库操作的检查。演讲者强调，未来的软件交互方式将类似于园丁照料花园，需要确保系统按预期演化。因此，他们不提供一个通用的“开箱即用”工具，因为每个应用的需求差异巨大。

"We're not like giving out a tool because we couldn't give you a a tool at this time that works generically for every single application".

不同行业的评估重点截然不同。例如，室内设计领域可能更关注视觉呈现的准确性，而某些其他场景则只在乎速度。因此，团队必须构建适合自身应用的特定工具集并交给模型运行。这种定制化的评估体系允许开发者将特定的验证逻辑作为“工具”暴露给 Agent，确保模型知道如何正确执行这些检查。这种细粒度的控制使得评估可以深入到应用的各个层面，从前端界面到后端数据一致性。

循环驱动开发与状态反馈机制

为了让 Agent “看到”其操作的结果，必须建立可反馈的循环（Loop-driven development）。演讲者引用了 AMP 团队的一个示例：在一个 Canvas 游戏中，球在圆圈内弹跳。虽然模型无法直接“看”到屏幕上的物理运动，但可以通过在每个循环中打印球的坐标数据来构建反馈回路。如果球在某一帧跳跃超过一个像素，系统可以识别出潜在的物理引擎 Bug 并将这一异常数据反馈给模型。

"The whole idea of that is making things feedback loopable... If you can surface that to the model, then it can help you debug it".

这种机制解放了开发者的生产力，使得同时运行多个软件变体成为可能。随着 Token 成本的降低和模型能力的提升，未来可能会出现周一提交需求、周二看到 35 个不同版本并从中挑选最佳方案的工作流。关键在于，这些变体都必须能够通过特定的评估循环来证明其正确性。这种基于数据的反馈机制让 Agent 能够在没有视觉感知的情况下，通过结构化数据理解系统状态并自我修正。

以 Playwright 为例的自动化验证实践

在具体落地层面，演讲者展示了如何在“午夜零食页面”（Midnight Snack page）中实现证明机制。他们使用 Playwright 等工具编写端到端测试，将其作为 Agent 的工具之一。Agent 首先检查等待列表中是否已有特定邮箱，随后填写新邮箱并点击加入按钮。

验证过程包括检查页面状态元素是否显示“waitlisted”，并进一步核实该元素的内部文本（innerText）中确实包含了刚才输入的邮箱地址。这种可复现的证据链使得 Agent 能够自我证明任务已完成。

"Make sure that it's actually showing, you know, the state that you expect... otherwise it might just be another lie".

演讲者特别警告，成功的截图并不等于证明。如果 Agent 只是展示了一张静态图片而未实际执行导致该状态的所有命令，可能会掩盖潜在的副作用或路径依赖问题。因此，必须确保测试从头到尾完整运行，以验证 UI 状态与后端数据的一致性。这种严谨的回归测试机制不仅防止了错误，还确保了团队在后续迭代中能够安全地推进开发。

自修复循环与规模化效率

AI Agent 的核心价值在于其能够驱动未来的工作流，特别是在处理失败时。当单个任务循环中 Agent 遇到错误（例如在用户忙碌或启动新任务期间），它应具备自我诊断能力，判断当前操作不正确并主动采取补救措施。例如，Agent 可以自行决定重新运行验证命令（verify again），直到确认状态正常。这种自我修复和自我纠正的能力在规模化场景中至关重要：如果单个 PR 或工作流中的 Agent 能独立解决问题，开发者便无需在一天结束时回顾那些未完成的 PR。这种基础性的速度与效率提升，使得系统能够处理大量并发任务而无需人工干预。

RSI 循环优化：从静态测试到动态证据链

随着工具集的完善，构建 ReAct/Reflection/Self-Improvement (RSI) 循环变得愈发容易。核心在于利用系统执行的历史数据创建全面的评估集（Evals），使 Agent 能够通过循环迭代实现性能的持续攀升。正如演讲者所言："你可以创建一个数据集，精确记录系统的表现，从而为 Agent 创建非常全面的评估集。"在这种机制下，Agent 能够利用前次运行的证据（Evidence）进行自我验证和修正。然而，传统的静态测试存在局限：代码修复后虽然持久化生效，但 Agent 仍可能产生幻觉。例如，页面重新加载后文本显示 "wait listed"（等待名单），但截图实际确认座位已锁定，这种非一一对应的文本差异会导致验证失败。这揭示了静态测试的痛点：如何在不与屏幕文本过度耦合的前提下，证明操作已成功？

引入 System One/Two：心理学模型在 LLM 架构中的应用

为了解决上述耦合问题，演讲者引入了源自心理学的 System One（系统一）与 System Two（系统二）概念。System One 代表快速、自动化的直觉决策，如驾驶中本能地避让车辆；System Two 则代表缓慢、耗时的深思熟虑，如规划人生或预订 Airbnb。在 LLM 领域，Jev（快速模型）对应 System One，而后续出现的 Cloudflare Cleft 等更快速的工具进一步强化了这一层级。演讲者通过一个直观的光色比喻阐释这一概念："如果你问那盏灯是什么颜色，你会立刻说是黄色——这是系统一思维。但如果你问为什么它是黄色的，我们就需要思考物理原理了。"这种架构组合使得开发者能够利用不同层级的模型构建新的 AI 原语，平衡速度与准确性。

Saboteur 与 Detective：自动化 Bug 发现的实战演练

为了演示上述理论，演讲者展示了一个名为 "Snack" 的互动游戏：一名 Saboteur（破坏者）随机植入 Bug，而 Detective（侦探/Agent）需利用工具链定位并证明该 Bug。演示中，通过运行 pnpm snack up --bug random 启动应用（非无头模式以便观察），随后使用 pnpm snack doctor 让 Agent 进行诊断。Agent 启动后，Node.js、Chrome 及会话均正常运行。然而，首次运行的 Proof（证明）结果为 "fail"，原因是证据指向的代码已不存在。经过调试和重新运行，团队识别出 Bug 为端口错误（如 62174）。这一过程展示了 Agent 在复杂环境下的探索能力，同时也暴露了当前工具链在处理动态代码变更时的挑战。演讲者指出："每次失败都会成为地图上的新路径，帮助我们理解步骤偏差并逐步修正。"

建立评估基线：从内存测试到持续集成

实战经验表明，验证结果可能呈现多种形态：命名正确但输出错误、声称成功实则失败、归咎于不存在的 Bug，或找到正确 Bug 但缺乏证据。因此，建立并维护一个灵活的评估基线（Eval Baseline）至关重要。团队应创建初始基准，并在每次迭代中保持一致性演进。当 Agent 在内存环境中测试错误邮箱导致确认丢失时，若能成功捕获并证明该问题，即可将其纳入回归测试集。对于 "过度承诺" 的情况（截图显示成功但实际未通过），或控制台无报错但在 Receipt 中存在的隐性错误，都需要专门的验证逻辑。最终目标是实现 PR（Pull Request）自动触发评估，确保代码变更要么提升性能、要么安全着陆，从而构建可靠的 AI 应用工程体系。

构建灵活的工具以应对代码变更

在自动化测试与验证过程中，开发者常遇到一个棘手问题：当运行诊断工具（如“doctor”命令）时，系统可能显示过期的证据或不再存在的证明。这通常是因为代码在昨天和今天之间发生了显著变化，或者遭遇了如“著名日期bug”等特定环境因素。面对这些不确定性，核心策略是构建足够灵活的工具链，使其不会因此类问题而陷入困境。这本质上是将传统单元测试中的确定性检查逻辑引入到AI模型中，使代理具备从错误中自我修复和自我改进的能力。

“我们想要构建足够灵活的工具，以免被此类问题困住……将这种确定性检查带给模型，使它们能够从中自我修复和自我改进。”

这种做法回归了人类开发者的基本操作逻辑。过去，开发者通过手动“拉伸”应用、检查各项功能来确保系统正常；现在，我们将这一过程代码化。通过提供确定性的命令行界面（CLI），AI代理能够获得与人类开发者在深夜使用Chrome调试器时相同的体验和路径。这种转变不仅解锁了开发速度和演进能力，还使得在更安全的前提下大规模交付代码成为可能。

赋予代理“开发者视角”的全方位感知能力

要让AI代理真正接管开发任务，关键在于赋予其作为开发者所能看到的一切。对于Web应用而言，最高杠杆率的起点是建立自定义的验证器CLI。这不仅是基础评估（eval）的一部分，用于定义应用中“什么是好的”，更是为了让代理能够观察性能、网络流量、渲染等所有方面。这就好比给Web应用接入Chrome DevTools。

如果涉及原生客户端（如iOS或macOS应用），虽然具体的工具项目每天都在更新，但底层逻辑一致：必须给代理提供它能看到的绝对一切。你给予它的“手臂”或“眼睛”越多，它从人类手中接管工作的能力就越强。开发者需要做的只是赋予代理直觉（intuition），教导它何时以及如何运用这些工具。例如，当出现Bug时，思考如何复现问题：如果是登录流程的问题，代理需要检查Cookie是否正确设置、过期时间是否合理等。这种能力适用于任何行业和软件领域，旨在应对代码不再需要手工雕刻的现状，通过保留系统 fundamentals 来加速软件开发。

“保留收据”：从审计到自动修复的闭环

在复杂的软件系统中，保持详细的输出和状态记录（即“保留收据”）至关重要。代理需要获取关于发生了什么、当前状态的详细信息，以便应用和模型进行审计。随后，代理可以再次运行测试以修复问题，并验证更改是否生效且无遗留隐患。这种机制允许代理在夜间自动运行，监控最新产生的“收据”，聚合数据并发现问题。

以电商应用为例，“收据”涵盖了用户登录、页面加载、目录显示耗时（如7秒）、加入购物车以及购物车放弃率等完整旅程。如果系统发现“今天缓存模块出现了8次失败”，它可以自动发起PR进行修复，并利用工具证明该问题已解决。这种自我进化工具链（self-evolving tooling）的普及将带来显著的竞争优势。拥有干净数据集和完整历史记录的团队，能够向AI明确“我们要达到的目标”，从而快速迭代。相比之下，缺乏这些数据的竞争对手将在开发周期中大幅落后。

人类监督与信任构建的新范式

随着AI代理能力的提升，人类的角色从直接编码转向高层监督与信任构建。开发者需要保留人类视角的 oversight，例如录制自己操作应用的视频流。当代理提交PR时，开发者早上醒来可以先观看这些录像，确认应用确实达到了预期目标且流程无误。只有在确认功能正常后，才进行代码层面的审查。

这种分层审核机制极大地提高了处理大量PR的效率。通过结合单元测试、评估（evals）、冒烟测试以及代理的解释能力，我们建立了一套完整的检查体系。这不仅确保了应用的前后一致性，还通过保留所有历史运行的收据和证据链，为AI代理提供了可审计、可验证的基础。最终，这种基于数据和工具的信任机制，使得软件能够在自动化与人工监督的平衡中持续改进和进化。

构建可验证的证据阶梯以消除回归风险

在 AI Agent 辅助开发的流程中，核心挑战在于如何确保新增功能不会破坏现有逻辑。演讲者提出了一种“证据阶梯”（Evidence Ladder）的概念，即通过持续构建和积累验证数据，来证明应用按预期工作。这种机制不仅仅是简单的回归测试，而是将“没有发生任何回退”作为应用规格说明书的一部分。通过这种方式，团队可以在添加新功能时运行所有先前的测试用例，确保“应用完全按照预期工作”。这种基于证据的验证方法，使得开发者能够自信地迭代，因为每一次变更都有明确的、可追溯的成功证明。这种策略将模糊的“功能完成”转化为具体的“已验证状态”，从而在快速迭代中维持系统的稳定性。

本地开发与 CI/CD 中的自动化执行策略

关于如何强制 Agent 遵循验证路径，演讲者倾向于避免仅依赖模型自身的“技能”（Skills），因为模型是否会真正执行这些路径存在不确定性。相反，他主张通过 CI/CD 管道或本地钩子（Hooks）来强制执行命令的运行。在实施层面，有多种方式可以实现这一目标：可以是 CI 流程的一部分，也可以是 Git Hook、Cloud Code Hook，甚至是后台运行的全功能扩展。然而，演讲者认为最简单且最有效的通用方案是在项目中创建一个名为 agents.md 的文件（而非 .cloud.md）。该文件明确规定了触发验证的条件，例如“在更改时通过运行特定命令来验证”或“在打开 PR 之前执行检查”。这种文档化的约束使得团队成员很难故意忽略验证步骤，从而在团队层面统一了开发标准。此外，本地开发的钩子也允许团队成员共享这些验证规则，确保“整个团队都能遵循相同的自动化流程”。

并行工作与降低交互延迟的核心优势

在本地开发环境中，Agent 的最大价值在于“快速反馈循环”和“并行工作能力”。演讲者分享了他的工作习惯：他通常同时运行 3 到 15 个 Agent，将任务设定为具体的目标（如“添加邮箱至等待列表并持久化保存”），然后让 Agent 自行执行。他不需要在每一步都进行干预，而是等待 Agent “证明它已经完成了工作”并展示证据。这种模式允许他在不同项目间快速切换，而无需担心 Agent 出错后需要重新提示和重启循环。他强调，“我不希望因为等待确认而打断我的工作流”。如果 Agent 能够自主验证并展示可信的证据，他可以在几分钟甚至几小时后回来检查结果。这种“低交互、高置信度”的模式，避免了因反复调试和重新提示导致的效率低下。他提到，“如果每天结束时能回到各个任务线并看到它们被正确完成，而不是需要逐条提示修正，这才是真正的加速”。

从代码审查信任到生产环境监控的延伸

演讲者将这种对 Agent 的信任类比为现代开发中对自动化代码审查工具（如 Reptile、CodeRabbit）的依赖。他提到，当自动化代码审查给出高分且 CI 全部通过时，他会“极度自信地认为上线不会破坏生产环境”。然而，传统的自动化测试有时可能通过大量无意义的代码（如“10,00 行无用代码”），虽然通过了测试，但并未实现实际功能。因此，Agent 验证的关键在于“确保 Agent 准确理解需求并保持在正确轨道上”。除了本地和 CI，这种验证模式还延伸至生产环境。一种新兴的模式是部署专门的 Agent 监控生产指标（如 DataDog、功能标志），一旦检测到异常，“能够自动识别问题并执行回滚”。这种端到端的自动化验证与监控闭环，使得开发者能够应对部署带来的焦虑，实现真正的“自主且可信赖的交付”。

活动收尾与互动邀约

随着讨论环节的结束，WorkOS 的代表 Nick Nisi 和 Zack Proser 对观众的参与表示感谢。他们指出，关于智能代理（Agent）如何证明其工作完成这一话题的探讨似乎具有某种必然性，这反映了当前技术发展的趋势。在时间有限的情况下，他们强调了面对面交流的重要性，并明确指出了自己在展会中的具体位置。

"That's all the time we have, but if you have more questions we'd be happy to chat."

这一环节不仅是对演讲内容的补充，更是建立社区联系的关键时刻。两位发言人表达了开放的态度，愿意就任何感兴趣的话题进行深入对话。

展位指引与后续支持

为了便于观众进一步接触 WorkOS 的产品和技术，Nick Nisi 提供了详细的展位信息。他提到团队将在 expo hall booth six（展厅六号摊位）等待访客，并特别描述了方位：right to the right when you come in（进门向右）。这种具体的指引旨在降低潜在客户的接触门槛，促进更直接的商务或技术交流。

"Come find us. We'd be happy to chat, show you what we're working on and talk to anything you like."

通过展示他们正在开发的内容，WorkOS 希望向观众传达其持续创新的形象。这种面对面的互动不仅限于问答，还包括展示最新的工作成果，从而增强品牌的专业度和亲和力。最后，双方互致感谢，现场响起掌声，标志着本次交流环节的圆满闭幕。

"Thank you so much for coming and your attention and everything. Thank you so much."

这种礼貌而热情的结束语，体现了技术社区中常见的协作与尊重精神。

结论

WorkOS的实践证明，构建AI Agent信任的核心在于从“代码审查”转向“结果验证”，通过建立确定性工具链（如Snack、CTX）强制Agent提供可审计的证据。该模式利用Playwright等自动化手段及System One/Two分层架构，有效解决了UI假象、数据持久化缺失及LLM非确定性等痛点。其优势在于显著降低人工干预，实现高并发下的自修复与规模化交付；但高度依赖定制化验证逻辑及结构化反馈回路，通用性受限。适用场景为具备明确验收标准的全栈应用开发，尚未证明其在无工具支持的纯黑盒环境中的可靠性。