AI Agent如何真正交付代码，非确定性时代的工程信任危机
播客收听
问这期播客
会先在本集摘要、章节、转录和笔记里找答案。
TL;DR · AI 摘要
Nick Nisi在WorkOS实践AI Agent工程，八个月未手写代码却交付稳定成果；删减95%技能后效率提升，核心是用机制替代信任、用验证代替假设，推动工程从‘写代码’转向‘管理Agent’。
核心要点
- 删掉95%自动生成技能后，Agent运行时间从68分钟降至6分钟，正确率从77%升至97%
- 采用TypeScript状态机+SHA-256验证机制，强制Agent证明每步操作而非仅承诺
- 失败不修代码而修Harness，通过retro agent分析日志识别循环调用与无效路径
结构提纲
按章节快速跳转。
Nick Nisi分享其在WorkOS维护多语言SDK的实践，八个月未亲手写代码，聚焦Agent如何可靠交付而非单纯执行任务。
从GitHub/Slack等源头自动启动修复流程，使用五类分工Agent（implementer/verifier等）并强制每步需证据验证，避免撒谎式执行。
初始尝试用万行文档技能覆盖所有场景，结果性能下降；精简为553行常见坑后，正确率飙升且耗时锐减，证明少即是多。
用机制替代信任、引导模型而非硬编码步骤、以evals数据驱动优化，确保非确定性环境下系统可预测、可追溯。
失败不是代码问题而是系统设计缺陷，应构建retro agent分析历史对话，识别doom loop并迭代harness而非反复修补Agent逻辑。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AI Agent工程方法论：从交付代码到交付可信系统
- 核心挑战
- Agent易撒谎、跳步骤、上下文错乱
- 非确定性环境下的工程信任危机
- 解决方案框架
- 构建Agent Harness系统（Case & CLI）
- 采用状态机与验证机制替代Prompt依赖
- 关键实践
- 删减技能至553行，提升效率与准确率
- 引入Retro Agent回溯错误模式
金句 / Highlights
值得收藏与分享的关键句。
删掉95%技能后，Agent正确率从77%跃升至97%，运行时间从68分钟压缩到6分钟，证明复杂性未必带来可靠性。
Agent不能只说自己完成了任务，必须提供SHA-256校验文件或Playwright视频作为证据，否则人类review将无意义。
当Agent因环境差异误改TanStack项目结构时，团队第一反应是加更多文档，结果反而更糟——最终靠减少技能数量和强化验证机制解决。
章节
开场 & 播客简介
开场 & 播客简介
中文节目开场：跨国串门计划与 AI 声纹克隆介绍
中文节目开场：跨国串门计划与 AI 声纹克隆介绍
本期节目来源：AI Engineer 的 WorkOS 技术分享
本期节目来源：AI Engineer 的 WorkOS 技术分享
分享者背景：Nick Nisi 与 WorkOS 的开发者体验工作
分享者背景：Nick Nisi 与 WorkOS 的开发者体验工作
核心金句：八个月没亲手写代码、Agent 会撒谎、删掉 95% skills 后效果更好
核心金句：八个月没亲手写代码、Agent 会撒谎、删掉 95% skills 后效果更好
Nick 的工作场景：一个人维护二十多个 repo、八种语言 SDK
Nick 的工作场景：一个人维护二十多个 repo、八种语言 SDK
八个月不亲手写代码：用 Agent 完成实现、review 与交付
八个月不亲手写代码：用 Agent 完成实现、review 与交付
单 Agent 的瓶颈：跨 repo、跨 issue 的上下文切换成本
单 Agent 的瓶颈：跨 repo、跨 issue 的上下文切换成本
为什么 developer experience 正在变成 agentic experience
为什么 developer experience 正在变成 agentic experience
Case 项目诞生：从 GitHub issue、PR、Slack thread、Linear ticket 自动开始工作
Case 项目诞生：从 GitHub issue、PR、Slack thread、Linear ticket 自动开始工作
从 Claude skill 到 TypeScript state machine：为什么 prompt 不够可靠
从 Claude skill 到 TypeScript state machine：为什么 prompt 不够可靠
五类 Agent 分工：implementer、verifier、reviewer、closer、retro agent
五类 Agent 分工：implementer、verifier、reviewer、closer、retro agent
转录
开场 & 播客简介
中文节目开场跨国串门计划与 AI 声纹克隆介绍
本期节目来源AI Engineer 的 WorkOS 技术分享
分享者背景Nick Nisi 与 WorkOS 的开发者体验工作
核心金句八个月没亲手写代码、Agent 会撒谎、删掉 95% skills 后效果更好
Nick 的工作场景一个人维护二十多个 repo、八种语言 SDK
八个月不亲手写代码用 Agent 完成实现、review 与交付
单 Agent 的瓶颈跨 repo、跨 issue 的上下文切换成本
为什么 developer experience 正在变成 agentic experience
Case 项目诞生从 GitHub issue、PR、Slack thread、Linear ticket 自动开始工作
从 Claude skill 到 TypeScript state machine：为什么 prompt 不够可靠
五类 Agent 分工implementer、verifier、reviewer、closer、retro agent
真正重要的不是 Agent，而是 gate每一步都必须被验证
“证明”是关键词为什么 Agent 不能只说自己完成了
Agent 如何“假装跑测试”touch 文件与 SHA-256 验证机制
让正确执行比撒谎更容易用机制替代信任
WorkOS CLI 的目标五分钟内帮开发者安装 AuthKit
自动识别项目环境Next.js、TanStack、Ruby 与 Auth0 迁移
真实失败案例TanStack Start 的隐含约定被 Agent 改坏
第一反应用文档生成一万多行 skills
复杂但无效的方案文档 hash、自动更新、长时间 evals
测量揭示真相更多 token、更多上下文，结果反而更差
从全面覆盖到只写 gotchas保留最常见、最关键的坑
一万多行变成 553 行运行时间从 68 分钟降到 6 分钟
一个反直觉结果加载 skill 正确率 77%，不加载反而 97%
evals 的价值处理非确定性代码时，必须用数据验证效果
原则一用机制强制执行，不要只给指令
原则二引导模型，而不是把每一步都写死
原则三衡量效果，不要预设它能工作
用证据替代代码审查的第一步测试输出、Playwright 视频、修复前后对比
如果不能证明，就不要浪费人类 review 的时间
每次失败都变成下一次运行的数据
Harness Engineering 思路不要直接修 Agent 写坏的代码，要修 harness
retrospective Agent从 transcript 中识别 doom loop、重复 tool call 和无效路径
memory system让 Agent 记住 Next.js、TanStack Start 等项目里的常见问题
给 Agent 反馈，并让下一次运行比上一次更好
找出 Agent 在产品里稳定会犯错的地方
不要把整套产品文档塞给模型，只写关键 gotchas
像服务开发者一样服务 Agent它们需要什么信息、会在哪里丢上下文
最终建议永远不要相信 Agent，让它证明；用代码强制要求，而不是靠 prompt
节目笔记
📝 本期播客简介
本期我们克隆了：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、八种语言 SDK
02:20 八个月不亲手写代码：用 Agent 完成实现、review 与交付
03:10 单 Agent 的瓶颈：跨 repo、跨 issue 的上下文切换成本
03:55 为什么 developer experience 正在变成 agentic experience
Case：一个能交付 PR 的 Agent Harness
04: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 agent
06:25 真正重要的不是 Agent，而是 gate：每一步都必须被验证
06:55 “证明”是关键词：为什么 Agent 不能只说自己完成了
07:30 Agent 如何“假装跑测试”：touch 文件与 SHA-256 验证机制
08:10 让正确执行比撒谎更容易：用机制替代信任
WorkOS CLI：让产品也适配 Agent
08:50 WorkOS CLI 的目标：五分钟内帮开发者安装 AuthKit
09:35 自动识别项目环境：Next.js、TanStack、Ruby 与 Auth0 迁移
10:05 真实失败案例：TanStack Start 的隐含约定被 Agent 改坏
10:40 第一反应：用文档生成一万多行 skills
11:20 复杂但无效的方案：文档 hash、自动更新、长时间 evals
11: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 写坏的代码，要修 harness
16:25 retrospective Agent：从 transcript 中识别 doom loop、重复 tool call 和无效路径
16:50 memory system：让 Agent 记住 Next.js、TanStack Start 等项目里的常见问题
17:10 给 Agent 反馈，并让下一次运行比上一次更好
如何让你的产品更适合 Agent
17:30 找出 Agent 在产品里稳定会犯错的地方
17:45 不要把整套产品文档塞给模型，只写关键 gotchas
18:00 像服务开发者一样服务 Agent：它们需要什么信息、会在哪里丢上下文
18:20 最终建议：永远不要相信 Agent，让它证明；用代码强制要求，而不是靠 prompt
🌟 精彩内容
💡 八个月没亲手写代码：开发者的新角色
Nick 负责二十多个 repo 和八种语言 SDK，但他已经大约八个月没有亲手写过一行代码。他的工作方式变成了：让 Agent 实现，自己 review、指导，并用系统保证质量。这意味着工程师的核心工作正在从“亲自写代码”转向“设计能稳定交付的软件生产系统”。
“我自己大概已经八个月没亲手写过一行代码了。”
🧱 Case 的关键不是 Agent，而是 Gate
Case 里有 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，以为更多上下文会带来更好结果。但 evals 显示，这些内容让 Agent 更慢、更贵、更容易走弯路。后来他只保留 553 行常见坑，运行时间从 68 分钟降到 6 分钟，效果还更好。甚至有一个任务，加载 skill 正确率只有 77%，不加载反而是 97%。
“所以我删掉了百分之九十五的内容之后，性能反而上去了。”
📏 Evals 是 Agent 工程的基本功
在非确定性的 AI 系统里，直觉很容易出错。Nick 原本以为“更多文档、更多 token、更多 skills”会更好，但只有 evals 告诉他真实结果。对于任何面向 Agent 的产品或内部工具，都必须建立评估体系，把“信任”变成通过率、delta 分数或其他可比较指标。
“我之所以知道这一点，真的只是因为我做了测量。”
🎥 先证明修好了，再让人类 review
Nick 不会一开始就读 Agent 写出的所有代码。比如修 UI bug，他希望 Agent 用 Playwright CLI 录视频，展示修复前如何复现、修复后如何正常工作。只有当 Agent 用非代码证据证明问题已经解决后，他才愿意进入代码 review。否则，就让 Agent 回去重做。
“在它先用非代码的方式证明自己完成了我要求的事情之前，我甚至不会浪费时间去看那些代码。”
🔁 每次失败都应该修 Harness
Nick 借鉴 Harness Engineering 的思想：当 Agent 犯错时，不要只修它这次写坏的代码，而要修 harness，让系统下次能自己避免同样的问题。Case 的 retrospective Agent 会读取执行日志和 transcript，分析是否陷入重复 tool call、doom loop 或无效路径，并更新 memory system。
“如果它犯了错，不要去修它犯下的那些具体错误。要去修 harness，让 harness 能自己修那些错误。”
🤖 像服务开发者一样服务 Agent
如果你的产品要被 Agent 使用，就不能只考虑人类开发者如何阅读文档，也要考虑 Agent 如何抓取页面、理解上下文、识别常见坑。不要把整套产品说明丢给模型，而要找出 Agent 稳定会犯错的地方，把 gotchas 写清楚，并通过 evals 验证这些内容是否真的有帮助。
“要用看待开发者的方式来看待这些 Agent。它们想知道什么？我怎么让它们用起来更顺？”
🌐 播客信息补充
本播客采用原有人声声线进行播客音频制作，也可能会有一些地方听起来怪怪的
使用 AI 进行翻译，因此可能会有一些地方不通顺；
如果有后续想要听中文版的其他外文播客，也欢迎联系微信：iEvenight