Agent Trust Ladder 与米其林厨房（细读版）

嘉宾履历（按口述）：Meta（React）→ 休整约一个月时做 side project → 2025 年 3 月加入 Cursor → 先修 agents window 性能 → 再做 Grokbot。早期技能仍开源在 GitHub potato/noodle（含 skills 与 brain 目录）。字幕里 Cursor 与 SpaceX AI 并提，按口述保留。

时间来自英文字幕轴。总长约 65 分钟。

对方问了什么： 你如何爬 trust ladder？加入 SpaceX/Cursor 后如何继续放大？

嘉宾怎么答： 故事从加入 Cursor 之前就开始。Meta 之后休整约一个月，做 side project。当时（约 1–2 月）社区热衷自建 orchestrator（agents window 尚未流行）。

嘉宾想让 AI coding 更高效。却发现自己把大量时间花在微管一个 agent 上。也很难度量 skill 的真实影响。等于在盲飞。

关键转折：

1. 蒸馏自己： skill 的入口是「让 agent 更像我写代码、更像我做 workflow」。
2. 进 Cursor 后放弃个人 skill： 以为不相关；修 agents window 性能时又掉回人手模式（看 flame graph、heap snapshot）。
3. Meat proxy 觉醒（约 4:35）： 自己夹在 agent 与 Chrome DevTools 之间。加入约在 3 月，这件事约在 4 月初。
4. 旧教训回归： 做 Grokbot 时发现早期 skill 里关于 verification、严谨流程的部分仍然关键。Frontier agent 也爱抄近路；技能要让「容易做的事 = 正确的事」。

爬梯时反复问：我在哪里变成瓶颈？如何让 agent 用真实数据自己回答问题，而不是猜？

对方问了什么： 很多人觉得依赖 AI 后，领域专长变没用。你怎么看？

嘉宾怎么答： 领域专长更重要。模型越强，瓶颈越少在 agent 能力，越多在「你能否把意图与目标说清楚，让 agent 能执行」。医生、律师等非工程专家，只要略懂技术并能说清愿景，也能建出好产品。瓶颈是意图与愿景向 agent 的传递。

Matt 补充：他长期痴迷用词。某个词一旦被 agent「钩住」，会进入 thinking traces 并被强化。例子：

• TDD： 不一定是「该不该用 TDD」，而是让 agent 用另一套优先级去想测试。
• Grilling： 帮 agent 理解你的思路，并提出你可确认的词。
• Tautological tests（同义反复测试）： Lauren 很讨厌 agent 写的无用测试；「tautology」这个词把大量意图压进一个标签。

机制：自然语言与编程语言在 agent 时代汇合；skill 本质上是用语言写流程。戏剧/语言训练（Matt 提 drama degree）在此有用，因为你在压缩意图。

对方问了什么： 想从每天 1–5 个 agent 扩到上百并行。为什么你用 Michelin kitchen，而不是 software factory？

嘉宾怎么答： 不是说「软件工厂」不准确，而是工厂常让人联想到低质量、少工艺。嘉宾在意用户体验与工艺。米其林厨房更有志向感，也更贴 trust ladder：

刀具 = skill、CLI、harness、代码约束。钝刀 + 截止日期 = 只能长期卡在微管层。嘉宾明确：你名字仍挂在产出上；声誉仍在；所以厨房怎么摆，就是新产品配方。

Matt 对齐点：很多人以为「模型公司的 harness 已经够好，我改不了」。嘉宾路线是：你可以改 agent 运行的环境（仓库结构、lint、验证工具），让它能自检。

对方问了什么： 验证具体长什么样？普通人怎么改善厨房？

嘉宾怎么答： 即使不用 PSAC，工具箱里最重要的 skill 也应是 verification。含义：给 agent「手和眼」——能跑代码、像真人用户一样交互、debug、拿 trace/snapshot。

为什么它能爬梯：how / why / unslop 一类 skill 再好，若人仍是输出与现实之间的代理，agent 就看不到结果，也就无法迭代。所谓 loop，关键一段是 verification：agent 能自检，你才离开回路。

具体例子（Cursor agents window 性能）：

1. 对照社区里 Andrej Karpathy 的 AutoResearch 一类「可评分、可连续改进」思路。
2. 这是嘉宾加入 Cursor 后第一个真正帮他上 trust ladder 的 skill。
3. 团队现状：几乎每个 Cursor / SpaceX AI 应用都有 verification skill，且自动维护，成了关键基础设施。

对方问了什么： talk 里有自定义 CLI。它做什么？为何挖这么深？

嘉宾怎么答： 灵感来自约去年末到今年初的上下文焦虑：compaction/summarization 还差，社区有梗——一旦 summarize，后半段 session 会变笨。于是想省上下文。

现在 harness 的摘要更好了，但 CLI 仍有价值。核心原则：把工作看成梯度——

• 需判断： 拼上下文、做决策 → 留给 agent。
• 确定性： 机械变换、固定步骤 → 写成脚本/CLI。

验证 CLI 本身「不神秘」：主要是 Playwright、Chrome DevTools Protocol 与一堆 API 胶水。价值在于：

1. 隐藏细节： skill 保持小；复杂确定步骤进脚本。
2. 一致性： 早期无 CLI 时，每次验证都「重建世界」，每个 agent 写法不同。
3. 速度： agent 反复写脚本、试错、用完丢弃，既费上下文也费时间。
4. 迁移场景： 技术栈迁移时，AST/code mod 这类机械变换更适合脚本，而不是每次让 agent 即兴发明。

嘉宾原则：高效分配确定性与非确定性；让 agent 在非确定性处发光。Skill ≈ 轻量说明 + 如何使用这些自定义工具的包装。

对方问了什么： 环境（lint、抽象、自建框架）相对「直接写功能」有多重要？

嘉宾怎么答： 工程师的新工作很大一块是环境。若还没建立对 agent 的信任与工具，你会卡在 trust ladder 低层，只能微管；没有余力思考更高层生产力。

类比：

• 开发者不学 VS Code / Vim / Git，只用记事本 → 钝刀。
• 切蒜很慢 → 该买压蒜器；工具存在是有原因的。
• 米其林厨房若不给厨具，每个帮厨都会自创一套乱法。

TypeScript 平行：嘉宾喜欢 type narrowing——从宽类型收到窄类型。「只有一种合法形状」。约束仓库空间，类似缩小可能类型集合。

Dune（约 29:33）： 非开源。内部 Electron 应用框架，像「自家的 Next.js」。特点：

• 很严的 lint
• 约定模式：每个 feature 进自己的目录；有 registry / 爬代码发现 feature
• 目标：几乎只有一种写法，难写出坏代码
• 灵感：Grokbot 早期约 8 个 God file，每个至少约 1 万行；观察 agent 失败后拆分，避免继续往巨文件追加

操作循环如下。盯着 agent 失败。退后一步。问如何变成 lint，或如何让仓库让这件事不可能。再写进环境。

不要堆成长规则让模型去「记住」。好处：规则在环境里「撞到」才生效。不占用 agent 长期记忆带宽。

Matt 对齐定义：好仓库 = 容易改、且改时不容易搞砸；护栏把人与 agent 都收进窄路径。

对方问了什么： 量从哪来？难道每月手开 2500 个 chat？有没有自动触发？

嘉宾怎么答： 高 PR 量的前提是厨房与刀具已就绪。先建好一家餐厅，才开第二、第三家。每个大 project / 大 chat ≈ 一家餐厅；人在多家之间「直升机巡视」，介入深度不同。

内环（inner loop）： agent 工程师按意图（或其快照）在仓库里写代码。问题：意图快照会过期。

外环（outer loop）： bug 报告、功能请求、基础设施限制出现在 Slack、Linear、X、邮件等。长期由人当渡船，把上下文搬回内环。

连接方式（例子）：

1. Slack MCP 或自建 harness 订阅频道。
2. 告知 agent：有某类 bug 就去分诊、用 verification 复现、确认 main 上是否仍存在（排除用户环境/依赖问题）。
3. Grokbot（字幕亦作 GraphBot）一类带 connector 的工具拉邮件、日历、Slack、Linear 等，再把上下文送给 Cursor projects。
4. Cursor projects = 云端 coordinator：有自己的计算机；像主厨/chief of staff——少亲自写码，多派活、监督、传上下文。
5. 一次涌入约 30 个相关 issue 时，coordinator 可选拓扑：不必一 issue 一 agent（易重复劳动、丢「更高层问题」线索）；可归并相关报告再派工。

嘉宾强调：公司 brain / context graph 不必神话。实质是——把你本要亲手传递的信息，教给 agent 自己取。量来自这些回路，不是手点 2500 次「新对话」。

大解锁问题（倒推）： 如何让 agent 能 merge 自己的代码？别人一听 2500 立刻问「你怎么 review？」——所以要把「可自 merge」当作设计目标，而不是事后补丁。

管理平行：Netflix 时代常谈 context not control。控制=微管；上下文=教自足。迁到 agent 同样成立。

对方问了什么： 除了用户 bug，还有什么在推 PR？何时触发看代码的 agent？要不要每小时 cron？

嘉宾怎么答：

1. 2500 ≠ 2500 个功能。 大量是 gardening：整理环境、清坏模式、加约束。这帮你、帮 agent，也帮团队与新人。好环境让新人第一天就能产出。不必先开一堆低质量 PR。
2. 读代码也会触发工作。 例：React 有很多 footgun；有一个 agent 持续寻找坏模式。
3. 关键机制：先 append 到文档，不要立刻修。 隔几天再看，常发现「这些其实是同一类问题」。缓冲/队列逼你看大图；纯执行模式接单太快时会错过模式。
4. Chief of staff 的价值：既能执行，也能看森林。

对方问了什么： 2500 道菜你每道都尝了吗？这是不是 dark factory？

嘉宾怎么答： 你仍要不时品尝，但规模化后不可能每道都尝，尤其多家餐厅并行。重点变 sampling（抽样）：

1. 每天看一批 PR / 代码质量，严格审视。
2. 找低效与坏模式。
3. 纠偏对象是环境（skill、约束、lint、类型），不是单个 agent。
4. 偶发一次可放过；多个 agent 重复同一捷径/同一 workaround → 必须改厨房。

反复做完这个循环后，环境会强力引导默认正确行为，你才能走开。嘉宾明确：很难；不是装一套 PSAC 就行。需要持续观察失败并加护栏。

关于 dark factory：

• Matt 问：这不是灭灯工厂吧？
• Lauren：若 agent 可自 merge，夜晚继续工作，某种意义上变「暗」。他有超过约 10 个 chief of staff。分管性能、用户 bug，甚至「用另一语言重写玩玩」等。
• Full autopilot（PSAC）： 触发强验证环——每个 PR 拉起多个 verifier；fuzz（跑应用、像真人点击、找回归与实现 bug）；自修；再验证；直到可合入。很吃 token；可调成 1 个 verifier 或只做基本验证。
• 信心来自 verification + 环境 组合。早晨看 commit history；有问题再 revert、改 lint。
• 第一次开过夜很害怕（怕搞出严重故障）；需要勇气。现在睡得更好。
• 与 Karpathy「vibe coding / 代码几乎不存在」不同：嘉宾路线是 代码与环境本质重要；垃圾进垃圾出。更像调光开关：有的区域暗、有的亮。餐厅比喻仍更贴——老板仍会巡店试菜。抽样而不是阻塞式逐条审查。

对方问了什么： 医疗、法律、金融等安全敏感域，很多 PR 像 one-way door（难回滚、可能丢数据）。多数变更都难回滚时，还建议这样做吗？

嘉宾怎么答： 回到验证质量。在可程序化验证的域，one-way 可变相更像 two-way（你有证据才合入）。若极难程序化验证，就很难到达全 autopilot。软件工程相对可验证；数学的一部分（例如写证明）也可验证。嘉宾承认：没有完整答案，业界还要一起摸索。

前瞻：更多 agent-oriented 语言。例子：Bend——把编程与证明结合。过去证明常写在 Lean、TLA+ 等另一套语言里，再用 solver 检查（覆盖情形、竞态等）。若编译通过且证明显示正确，为何不 merge？但并非所有域都可验证。

对方问了什么： PSAC 与 Matt 的 skill 如何一起用？技能是不是「我的库 vs 你的库」？

双方对齐： Skill = 流程写成语言（多为 Markdown）。不是魔法；可编织、可组合。

嘉宾建议：

1. 每人要有自己的刀。 厨师换餐厅会带刀；信任首先是信任自己磨利的工具。
2. 组合例子：Matt 的 grill-me / docs / Wayfinder + PSAC 的执行类 skill；比例因人而异。
3. 从旧 transcript 挖流程： 看你纠正 agent、反复介入的位置；提炼成 lint 或新 skill。过去对话是「已物化的真实过程」，不是脑中抽象。
4. Recall skill： 做 Cursor 应用虚拟化时 bug 多；新 chat 总想带走旧 chat 上下文。Recall 把「去翻旧 transcript / 压缩迁移」收成 skill，避免每次写长篇说明。
5. 模型变强后：去年 skill 常塞具体命令；现在可删实现细节，聚焦步骤与真实流程。Skill 会越来越小、越可组合。可把 Wayfinder 与 potato mode 合成自己的 mode。

Matt 收束：若有「魔法」，只在选词与把抽象过程变成语言的思考；思考完成后，别人可以「顺走」表面的那层语言。

下列为中文忠实转述，不是装饰金句。按字幕大意，不编造。

1. 休整时我发现：自己把大量时间花在微管一个 agent 上，也很难度量 skill 的影响。
2. 我夹在 agent 与 Chrome DevTools 之间，成了 meat proxy；这让我很恼火。
3. Frontier agent 也爱抄近路；技能要让容易做的事变成正确的事。
4. 模型越强，瓶颈越少在 agent，越多在你能否把意图说清楚。
5. 我不喜欢「软件工厂」当主标签，不是因为它不准确，而是它常联想到低质量。
6. 没有 verification，agent 看不到自己的工作结果，就无法形成真正的 loop。
7. 把确定部分抽成 CLI，只把需要判断的部分留给 agent；skill 是薄包装。
8. 无 CLI 时，每个 agent 每次验证都重建世界，又慢又不一致。
9. 工程师的新工作很大一块是环境；不磨刀，就只能卡在微管层赶工期。
10. Dune 的目标是：约定 + 严 lint，让坏代码很难写出来；灵感来自早期 God file。
11. 外环信息不进内环时，你就得在 Slack/X 上收集上下文，再渡船给 agent。
12. 到达约 2000+ PR 的大解锁，是倒推「如何让 agent 能 merge 自己的代码」。
13. 2500 不全是功能 PR；大量是 gardening，服务整个团队与新人。
14. 先把坏模式记入文档再归类，往往比每个问题立刻开修更能看到大图。
15. Review 靠抽样：多个 agent 重复同一失败，就改厨房；偶发一次可以放过。

1. 先做 verification skill： 让 agent 能跑、能看、能点、能对照 rubric。做对：你离开后它仍能迭代，而不是停住等你。
2. 确定性进 CLI/脚本；skill 只留判断与用法。 做对：不同 agent 验证路径一致，且不再每次现场写一次性脚本。
3. 观察失败 → 写成 lint/类型收窄/目录约定。 做对：同类失败重复率下降，规则文件不必无限变长。
4. 区分内环与外环；用 connector/bot 把外环灌进内环。 做对：你不再手抄 Slack/邮件上下文；agent 能自己取真实数据。
5. 高吞吐前先问：agent 怎样才能 merge 自己的 PR？ 做对：合并门槛可用验证环表达，而不是「等我有空再看」。
6. Review 用抽样：找系统性问题，改环境。 做对：早报/commit 浏览能发现模式；你改的是 skill/lint，不是只改一个 PR。
7. Gardening 算产出。 做对：新人或新 agent 更少开低质量 PR；环境「撞规则」即可。
8. 坏模式先入缓冲文档，再周期性归类。 做对：你能说出「这 10 条其实是 2 类根因」。
9. 从旧对话挖纠正话术，压成 skill（如 recall）。 做对：你少写重复长提示；跨 chat 仍能接上关键上下文。
10. 可组合别人的 skill，但要磨自己的刀。 做对：你说得出为何留下某条规则，而不是整库盲装。
11. 领域难验证时，勿照搬过夜 autopilot。 做对：one-way door 仍有人审或更强证明/验证；你能解释回滚成本。

先磨刀（verification + 环境约束），再开连锁店（内外环 + coordinator）。量来自可验证的回路，不来自手点 2500 次「新对话」。难验证域先补验证，再谈过夜 merge。