715
2📝 本期播客简介
本期我们克隆了：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 在真实工程流程中的应用。
⏱️ 时间戳
开场 & 播客简介
AI Agent 进入真实工程现场
中文节目开场：跨国串门计划与 AI 声纹克隆介绍
本期节目来源：AI Engineer 的 WorkOS 技术分享
分享者背景：Nick Nisi 与 WorkOS 的开发者体验工作
核心金句：八个月没亲手写代码、Agent 会撒谎、删掉 95% skills 后效果更好
从“写代码”到“管理 Agent”
Nick 的工作场景：一个人维护二十多个 repo、八种语言 SDK
八个月不亲手写代码：用 Agent 完成实现、review 与交付
单 Agent 的瓶颈：跨 repo、跨 issue 的上下文切换成本
为什么 developer experience 正在变成 agentic experience
Case：一个能交付 PR 的 Agent Harness
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：让产品也适配 Agent
WorkOS CLI 的目标：五分钟内帮开发者安装 AuthKit
自动识别项目环境：Next.js、TanStack、Ruby 与 Auth0 迁移
真实失败案例：TanStack Start 的隐含约定被 Agent 改坏
第一反应：用文档生成一万多行 skills
复杂但无效的方案：文档 hash、自动更新、长时间 evals
测量揭示真相：更多 token、更多上下文，结果反而更差
删掉 95% skills 后，效果为什么更好
从全面覆盖到只写 gotchas：保留最常见、最关键的坑
一万多行变成 553 行：运行时间从 68 分钟降到 6 分钟
一个反直觉结果：加载 skill 正确率 77%，不加载反而 97%
evals 的价值：处理非确定性代码时，必须用数据验证效果
Agent 工程的三条核心原则
原则一：用机制强制执行，不要只给指令
原则二：引导模型，而不是把每一步都写死
原则三：衡量效果，不要预设它能工作
用证据替代代码审查的第一步：测试输出、Playwright 视频、修复前后对比
如果不能证明，就不要浪费人类 review 的时间
失败不是结果问题，而是 Harness 问题
每次失败都变成下一次运行的数据
Harness Engineering 思路：不要直接修 Agent 写坏的代码，要修 harness
retrospective Agent：从 transcript 中识别 doom loop、重复 tool call 和无效路径
memory system：让 Agent 记住 Next.js、TanStack Start 等项目里的常见问题
给 Agent 反馈，并让下一次运行比上一次更好
如何让你的产品更适合 Agent
找出 Agent 在产品里稳定会犯错的地方
不要把整套产品文档塞给模型，只写关键 gotchas
像服务开发者一样服务 Agent：它们需要什么信息、会在哪里丢上下文
最终建议：永远不要相信 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
