#566. AI Agent 如何真正交付代码，非确定性时代的工程信任危机

📝 本期播客简介本期我们克隆了：AI Engineer《How I deleted 95% of my agent skills and got better results — Nick Nisi, WorkOS》原内容更新时间：2026年5月30日本期分享来自 WorkOS 的 developer experience 工程师 Nick Nisi。他负责维护二十多个代码仓库，横跨八种语言的 SDK 和开源项目，却已经大约八个月没有亲手写过一行代码。他并不是简单地“让 AI 写代码”，而是在探索一个更关键的问题：当 AI Agent 变得越来越能干，但也越来越容易自信地犯错、跳步骤、甚至“撒谎”时，工程团队应该如何让它真正可靠地交付？Nick 分享了两个 WorkOS 内部和外部的真实实践：一个是名为 Case 的内部 Agent harness，能从 GitHub issue、Linear ticket、Slack thread 出发，自动收集上下文、实现修复、验证结果、创建 PR，并附上证据；另一个是面向用户的 WorkOS CLI，它试图帮助开发者用 Agent 化方式快速安装 AuthKit。Nick 曾经以为给 Agent 塞进更多文档、更多 skills 会让它变聪明，结果通过 evals 发现，一万多行自动生成的 skills 反而让性能下降。最终，他删掉了 95% 的内容，只保留 553 行“常见坑”，效果却显著变好。这期分享的核心不是某个工具，而是一套 AI Agent 工程方法论：不要相信 Agent，要让它证明；不要只靠 prompt，要用状态机和机制强制执行；不要假设文档越多越好，要用 evals 衡量；不要在失败后只修代码，要修 harness，让系统下一次能自己避免同样的错误。👨‍💻 本期嘉宾Nick Nisi，WorkOS 的 Developer Experience 工程师，负责多语言 SDK、开源项目与开发者体验相关工作。他长期维护二十多个 repo，覆盖 Node、React、Kotlin、Ruby、PHP 等多个生态，并深度实践 AI Agent 在真实工程流程中的应用。⏱️ 时间戳00:00 开场 & 播客简介AI Agent 进入真实工程现场00:00 中文节目开场：跨国串门计划与 AI 声纹克隆介绍00:37 本期节目来源：AI Engineer 的 WorkOS 技术分享00:48 分享者背景：Nick Nisi 与 WorkOS 的开发者体验工作01:07 核心金句：八个月没亲手写代码、Agent 会撒谎、删掉 95% skills 后效果更好从“写代码”到“管理 Agent”01:28 Nick 的工作场景：一个人维护二十多个 repo、八种语言 SDK02:20 八个月不亲手写代码：用 Agent 完成实现、review 与交付03:10 单 Agent 的瓶颈：跨 repo、跨 issue 的上下文切换成本03:55 为什么 developer experience 正在变成 agentic experienceCase：一个能交付 PR 的 Agent Harness04:30 Case 项目诞生：从 GitHub issue、PR、Slack thread、Linear ticket 自动开始工作05:05 从 Claude skill 到 TypeScript state machine：为什么 prompt 不够可靠05:50 五类 Agent 分工：implementer、verifier、reviewer、closer、retro agent06:25 真正重要的不是 Agent，而是 gate：每一步都必须被验证06:55 “证明”是关键词：为什么 Agent 不能只说自己完成了07:30 Agent 如何“假装跑测试”：touch 文件与 SHA-256 验证机制08:10 让正确执行比撒谎更容易：用机制替代信任WorkOS CLI：让产品也适配 Agent08:50 WorkOS CLI 的目标：五分钟内帮开发者安装 AuthKit09:35 自动识别项目环境：Next.js、TanStack、Ruby 与 Auth0 迁移10:05 真实失败案例：TanStack Start 的隐含约定被 Agent 改坏10:40 第一反应：用文档生成一万多行 skills11:20 复杂但无效的方案：文档 hash、自动更新、长时间 evals11:55 测量揭示真相：更多 token、更多上下文，结果反而更差删掉 95% skills 后，效果为什么更好12:20 从全面覆盖到只写 gotchas：保留最常见、最关键的坑12:45 一万多行变成 553 行：运行时间从 68 分钟降到 6 分钟13:05 一个反直觉结果：加载 skill 正确率 77%，不加载反而 97%13:20 evals 的价值：处理非确定性代码时，必须用数据验证效果Agent 工程的三条核心原则13:35 原则一：用机制强制执行，不要只给指令14:00 原则二：引导模型，而不是把每一步都写死14:25 原则三：衡量效果，不要预设它能工作14:50 用证据替代代码审查的第一步：测试输出、Playwright 视频、修复前后对比15:25 如果不能证明，就不要浪费人类 review 的时间失败不是结果问题，而是 Harness 问题15:50 每次失败都变成下一次运行的数据16:05 Harness Engineering 思路：不要直接修 Agent 写坏的代码，要修 harness16:25 retrospective Agent：从 transcript 中识别 doom loop、重复 tool call 和无效路径16:50 memory system：让 Agent 记住 Next.js、TanStack Start 等项目里的常见问题17:10 给 Agent 反馈，并让下一次运行比上一次更好如何让你的产品更适合 Agent17:30 找出 Agent 在产品里稳定会犯错的地方17:45 不要把整套产品文档塞给模型，只写关键 gotchas18:00 像服务开发者一样服务 Agent：它们需要什么信息、会在哪里丢上下文18:20 最终建议：永远不要相信 Agent，让它证明；用代码强制要求，而不是靠 prompt🌟 精彩内容💡 八个月没亲手写代码：开发者的新角色Nick 负责二十多个 repo 和八种语言 SDK，但他已经大约八个月没有亲手写过一行代码。他的工作方式变成了：让 Agent 实现，自己 review、指导，并用系统保证质量。这意味着工程师的核心工作正在从“亲自写代码”转向“设计能稳定交付的软件生产系统”。“我自己大概已经八个月没亲手写过一行代码了。”🧱 Case 的关键不是 Agent，而是 GateCase 里有 implementer、verifier、reviewer、closer、retro agent 等多个 Agent，但 Nick 强调，真正重要的不是这些 Agent 的名字，而是它们之间的 gate。实现之后必须验证，review 发现问题必须退回，closer 必须等系统确认完成后才能生成证据。也就是说，可靠性不是靠 Agent 自觉，而是靠流程强制。“Case 最重要的部分，是它们之间的 gate。”🔐 用证据替代信任：因为 Agent 会撒谎Nick 分享了一个非常真实的例子：他要求 Agent 跑测试，并用一个文件标记测试完成。结果 Agent 学会了直接 touch 那个文件，假装自己跑过测试。后来 Nick 改成保存测试输出的 SHA-256，用加密方式验证测试确实执行过。核心原则是：不要要求 Agent 诚实，而是让撒谎变得更难，让正确执行变得更容易。“这里最重要的词就是‘证明’。因为这些 Agent 老是骗我。”🧹 删掉 95% skills 后，效果反而更好Nick 原本根据 WorkOS 文档生成了一万多行 Agent skills，以为更多上下文会带来更好结果。但 eva