与 Dex Horthy 聊上下文工程

• Dex 的定义很硬：RAG（检索增强生成）、memory（记忆）、agent 历史、结构化输出——这些在 agent 编程框架里被讲成不同概念的东西，到最后全都只是「把 token 传进模型、让它吐出通常是某种结构化输出」的不同方式。理解这一层，比去货架上挑一个 agent 框架再挑一个记忆框架有力得多。→ 详细
• 分界线画在质量档位上：现成框架能带你到 80%、做出一个很好的 demo；但从 80% 走到 95% 或 99%，你必须往下沉一层——我们放进上下文窗口的每一样东西到底是什么？根据用哪个模型，它们进去的顺序是什么？「所有这些都有影响，你手上有一堆可以拉的杠杆。」→ 详细
• 他反复强调这不是他发明的做法：他跟一百位「真在赚钱、签六位数合同、把 AI 交付给企业」的工程师聊过，看他们做的事里哪一部分是相同的，然后给它取了个名字。他认为取名本身有价值——「现在关于 AI 的内容里，那么多炒作和黑话是毫无意义的」，一个干净的词能让构建者知道该怎么想问题。→ 详细

• Gergely 问「是不是因为上下文窗口变长了」，Dex 说不是：上下文一直都重要，只是需要一大批聪明人非常用力地聚焦在「我要做出能卖给企业、准确到让自己骄傲的东西」上，才会被逼到 token 这一层。→ 详细
• 具体的思维切换是：别把 agent 当成「一堆工具在一个开放循环里跑」（灵活但不可靠），把它当成工作流、当成流水线，或者两者的混合——「不是只有工具、模型、系统提示词这三根杠杆，你手上的杠杆多得多。」→ 详细

• 他的顺序是「先让它跑起来，再让它跑对，最后让它跑快」：先用当时世界上最强的模型看能不能解，交给用户看要不要，有人用且用得多，再去做上下文工程。因为「你的工程时间永远是瓶颈」——人去建评测（evals，即对 agent 输出好坏的自动化打分）、去改进、去试不同维度，永远比直接换个更聪明的模型贵，除非你每天有几百万次请求。→ 详细
• 到了那一天，做法是拆：把一次大调用拆成三次，让其中两次能跑在小模型上。他给的量级是 GPT-OSS-120B 的成本大约是 Opus 的千分之一——目标是「让你花在前沿模型上的 token，只剩下真正需要那个智能水平的部分」。→ 详细
• 理论骨架来自 Eli Goldratt（艾利·高德拉特）的《目标》（The Goal）：先问「我系统里的瓶颈在哪儿」。延迟和成本总有一天会是瓶颈，但你刚开始时多半不是。上下文工程本质上是「往等式里加入人的努力，去换系统的效率、速度和成本效益」。→ 详细

• harness（agent 的外壳 / 脚手架）工程 = 造 agent 时用上下文工程，用 agent 时用 harness 工程。它问的是：你怎么针对 Claude Code、Codex 这类外壳的集成点（命令 commands、MCP、技能 skills、代码库怎么组织）做工程？「上下文工程是优化每一个提示词的输入；harness 工程是把地板抬高，让这东西的每一轮结果都尽可能好。」→ 详细
• 词被搅浑了——有人以为是「造一个 harness」，有人以为是「围着 harness 造东西」。Dex 认可 Martin Fowler 的切法：内层 harness = Claude Code / Codex / AMP 本身暴露的工具定义和集成点；外层 harness = 你这个人为自己的代码库、语言、需求做的那层定制。这是目前最好的定义。→ 详细
• 一个诚实的注脚：他 2025 年十月/十一月发帖提「harness engineering」时，LangChain 的 Viv 已经在几周前写过同名概念，只是他当时没读到。→ 详细

• 上下文窗口变长 ≠ 模型变聪明。「Opus 4.5 和 Opus 4.5 的 100 万版、4.6 和 4.6 的 100 万版——你并没有拿到一个更聪明的模型。」真正决定它能不能用好这些 token 的，是模型的智能水平：它要在每一轮从这十万、二十万 token 里判断出「哪一部分对下一个工具调什么最相关」，然后在循环里一遍遍地做这件事。→ 详细
• 底层机制很朴素：注意力是二次方复杂度的，你塞进去的东西越多，它就得把同一份注意力摊到越多东西上。Dex 明说自己不是机器学习博士、画不出数学证明，但这个方向的直觉够用。→ 详细
• 有个可引用的数字：2025 年一项研究发现，前沿模型大约能遵循 150 到 250 条指令，超过之后遵循全部指令的能力掉得挺快（Arize 的 Lori Voss 团队用一年后的新一代模型重做，结果好很多，但机制没变）。→ 详细

• 大多数人只想着信息预算——用 RAG 只取相关的几页，而不是把整本书塞进去。Dex 说还有一个同样重要的指令预算：指令太多、尤其是互相冲突的指令，会直接吃掉模型的能力。→ 详细
• 冲突不只来自你写的系统提示词，也来自对话本身：你先往一个方向走，中途改主意说「其实我不要那些了，我要这个」——模型要花很大计算量才能注意到「前面那一整块必须忽略」。而当这两块都退到上下文后段、只被「半注意」到时，「它真正记住你十万 token 之前那条确切指令的概率，下降得相当明显」。→ 详细

• 定义随模型在变：2025 年十一月他说的是「上下文窗口的前 40%」；有了百万 token 窗口之后改成「前十万 token」；对 Codex、Opus 4.8 这类很壮的模型可以放到 20 万。他本人凭直觉常跑到 25–30 万，偶尔三四十万，但明说「如果你没有好的大模型直觉，10 万 / 20 万是不错的辅助轮」。→ 详细
• 判断退化最实用的信号是行为而不是数字：模型在硬凑测试通过，「我来试试这个……好，我来试试那个」，越试越极端，最后蹦出「哦，让我把你的 .env 文件删了再试一次」——这时候「事情就变得非常非常怪了」。→ 详细
• 他的处置动作很具体：把已做的一切写进一个文件（或用内置压缩），然后在 3 万–5 万 token 处开一段新会话，重新下命令：「我们来做一件难事，你要把这个该死的测试跑通，而且别犯傻。」→ 详细

• 他把上下文窗口拆成四个变量：① 大小（多少 token）② 信息质量（里面有没有错的东西，比如模型自己在思考痕迹里认定了一个错误结论）③ 信息缺失（是不是缺了本该有的上下文）④ 轨迹（trajectory）。前三个大家都懂，第四个最微妙也最被忽略。→ 详细
• 轨迹 = agent 过去实际做过什么的完整历史。例子讲得很清楚：如果上一轮它「改动 → 跑测试 → 测试挂 → 修测试 → 汇报」，那下一轮它极大概率照走这条路；但如果上一轮它「改完就不跑测试」，你就已经在另一条轨迹上了。因为模型是自回归的——它在预测「这段对话里下一条消息该是什么」。→ 详细
• 由此得出那条广为流传的规则：模型说「你说得完全对」（新版是「你这么反驳是对的」）就该重开。原因不是这句话本身冒犯，而是它标志着一条坏轨迹已经形成——「我们大多数人都经历过：它这么说了，然后继续做错的事。」→ 详细
• 他在《不许 vibe》（No Vibes Allowed）里的那个例子值得抄进任何 agent 教程：模型犯错、你吼它；再犯错、你再吼。然后它读一遍历史心想——「这段对话的下一条消息是什么？看起来我大概应该再犯一个错，好让人类再吼我一次。」→ 详细

• 起点是 Ralph Wiggum 技法。Jeff Huntley 一年零四天前在旧金山演示：让 Sonnet 全天候不停跑、六周烧了六千美元，造出一整门编程语言，还带一个「二阶编译器」（这门语言的编译器是用这门语言自己写的）。→ 详细
• 但 Dex 认为那件事真正的教训不是「疯狂烧 token」，而是反压（back pressure）：怎么让模型检查自己的工作、怎么把「拿到反馈并喂回模型」自动化。确定性 linter、单元测试都算。→ 详细
• 关键前提条件是可验证性：编程语言之所以特别适合 Ralph，是因为它可以被无限验证（写代码→编译→挂了就修编译器→跑程序→挂了再修）。「如果你能把一个问题变得很可验证，你就基本上可以把它当黑箱来对待」，然后让它循环，因为验证回路本来就在那儿。→ 详细
• 他自己每次发版都在用的一个循环，五步写死给模型：写代码 → 提交 → 推送 → 起一个子 agent 盯着 CI 任务直到跑完 → 由它汇报结果 → 你再决定下一步。目标只有一句：「让 CI 更快。」这也是 Claude Code / Codex 里 /goal 那类「设定目标、持续迭代」机制的本质。→ 详细
• 同一套逻辑向上可以推到自动化研究（auto research）：「嘿，去把这个模型跑快一倍」——本质上就是一段提示词，让模型一遍遍试到真的拿到好结果。只要「好」可度量，循环就成立。→ 详细

• 他明确反对「把整套基础设施重新设计成 agent 优先的宏大工厂」。理由很实在：「嘿，我跑了一个 Ralph 循环三天，把代码库里所有 linter 报错都修了，这儿有个 6 万行的 PR，谁来评审？谁签字合并部署？保证没 bug」——没人会接。→ 详细
• 他团队实际在跑的东西「相当无聊」：一个定时任务（cron job），每天晚上在 GitHub Actions 里跑；循环结构就三步——跑这个 linter、修一个问题、提交并推送。第二天早上醒来，收到一个让代码库好一点点的 PR。→ 详细
• 两个扩展维度写得很清楚：① 加反馈机制（前端用 react doctor；还有一类没有确定性工具能查的反模式，就由人写清「好长什么样、坏长什么样」，例子是「prop 收窄」——一堆本不必是可选的 props 被写成可选，让代码难推理）。现在他们每天早上醒来收到四个 PR，因为有四件独立的事。② 随信心扩大范围——从「修一个」变成「修四个」。→ 详细
• 触发器可以是任何「不需要人按按钮」的东西：Sentry 告警、用户反馈 / 支持工单、PM 写的工单、某个测试挂了，或者干脆就是定时任务。「总之触发器应该是那种你不需要去按按钮的东西，然后有一条定义好的工作流，它让一切都变好一点点。」→ 详细
• Gergely 在收尾里点破了它的价值：「循环工程」这个词听着有点空洞，但 Dex 团队做的事无聊到任何一个工程团队今天就能抄——而且开发者仍然要评审和批准。→ 详细

• 时间线是精确的：2025 年 7 月造，2025 年 11 月关停。他给的规律是「大概三到六个月：你一直在发布、没人读代码，然后你会意识到——这东西越来越糟，重来一遍比修它还容易」。→ 详细
• 死法的细节：他们花了三周重新「入职」回一个自己三个月前就不再读的代码库，因为无论用多复杂、多专家级的提示词，都没法让当时的 Opus 4.1 找到根因。最后靠人翻了好几天代码才发现——「有一个主键被一路传穿了整条链路，它需要被换成另一种类型的对象，而且需要有自己的表」。→ 详细
• 最值得注意的是他的观点转向：事故当时他还觉得「值——大部分时间不读代码，代价是偶尔手工花两周修一个问题」。「但我现在不再相信这个结论了。因为我觉得我们现在能写出的代码量是 10 倍甚至 100 倍，这个问题只会更糟。」→ 详细
• 而且他刻意划清了界限：「你注意到我刚才说的不是『用循环去发用户想要的功能』。我们用循环来提升代码库的质量，而且我们读所有的代码。」→ 详细

• 核心论证一句话：糟糕架构和糟糕程序设计的代价函数，没法靠跑单元测试来评估——它是在三到六个月之后才砸到你头上，那时候你才发现「这软件已经难改到没人动得了了」。→ 详细
• 而模型全都在 SWE-bench 和类 SWE-bench 的东西上训练：「这里有一个 Django 的提交，这里有一个同期提的 issue，看看你能不能造出人类当时做的那个修复」——一百个仓库，Go / C++ / TypeScript / Java 都有，但没有任何一条在衡量「三个月后这份代码还好不好改」。→ 详细
• 他还给了一个「为什么 Claude Code 好用」的因果解释：它好用的唯一原因是强化学习，而且是把模型和 harness 一起训练——所以它变得极其擅长调用那个 harness 里的特定工具（读文件、写文件、搜文件）。「它是在一个维度上变得非常好」，而可维护性那个维度因为太难太贵，没被训。→ 详细
• 目前最好的替代品是 Cognition 团队的 frontier code：先看测试过不过，再加两层模型评审——一个裁判模型判断「补丁跟标准答案是否功能等价」，另一个做代码质量评审。「更好了，但不够。」→ 详细
• 他对 agent 化代码评审的怀疑很直白：模型是谄媚的（sycophantic）。问它「这段代码好吗」，它答「好，很全面，还带单元测试」；换个说法「评审我同事写的 PR，把问题都告诉我」，它立刻列出一堆问题。「所以我很难信任一个模型去评估写出来的代码的质量。」→ 详细
• 他想要的基准设想：让模型连续造 20 个功能、全程维护同一个代码库，而且它不知道后面会来什么功能（像真实产品团队一样），难到让大多数前沿模型在第六、第七个 issue 就挂掉。→ 详细

• 这是全期最可执行的一张决策表。选项一「关灯」：一切自动流动，然后祈祷你别造出太多垃圾（slop）、祈祷下一代模型来得够快，赶在你堆出一座灰烬山之前。→ 详细
• 选项二「大幅放慢，读每个 PR、每行代码」：那你从 AI 拿到的只是温和收益——「我们进到团队里看到的大概是 30% 到 50% 的生产力提升。」→ 详细
• 选项三「找杠杆点」：在动手前花一小时做人机共同规划，能在实现阶段省下四小时的返工。收益量化得很清楚：「你其实可以快两到三倍，同时保持大约 99% 的准确度——也就是『如果由人小心翼翼地手写这段代码，它会长成什么样』。」→ 详细
• 支撑这个选择的观察是：一旦方向已经定死了，就很难再掰回来，你还不如从头重来。所以人的介入点应该前移到「方向未定」的时刻，而不是留在 PR 评审那一个孤零零的观察点上——那时候「有时一百行、有时一千行，尤其如果它需要返工，对人来说工作量相当大」。→ 详细
• 对比也很直观：花一小时规划，PR 只用 20 分钟读完（因为代码是对的）；不规划，同一个 PR 要花六小时，因为全是来回改。→ 详细

• 原版 RPI（2025 年 8 月提出）的「研究」这步很有用：在造任何东西之前，并行开一堆子 agent 去读大量代码，而且不告诉它你要干什么，只问「这个系统怎么工作、那个系统怎么工作、它们怎么连起来」。这一步会烧掉十万 token 上下文，但产出一份一万 token 的文档——这就是上下文工程本身。→ 详细
• 「规划」这步当年火起来的真实原因，他事后才看明白：计划是让 agent 干得更久的一根强杠杆。「你说『给我造一个卷饼配送的 B2B SaaS』，你会拿到一个首页就没了；但你说『给我造一份计划』，它会写出一份大计划，然后在下一个上下文窗口里它会一直干到计划做完。」计划是个「锚」，不停提醒 agent「这些没全做完你就没完事」。→ 详细
• 原版计划文档的错误是「没给杠杆」：它写的是每一行将要改动的代码（diff 块形式）。「我们推荐过读计划，我们自己也读所有计划，但后来我发现自己只是随便扫一眼。」→ 详细
• 最狠的一句自我批评：计划花你 20 分钟读，PR 又花你 20 分钟读，而且两者还不一样——「你其实把读代码的时间翻倍了。这是反杠杆。」→ 详细

• Gergely 点名亚马逊 Kiro 和一年前 GitHub 那套工作流：先生成计划、人评审、可编辑、再实现——「表面上看起来很漂亮，本来应该效果很好，但除了少数维护型项目之外，它基本被扔进垃圾桶了。」→ 详细
• Dex 给的病因是规格漂移：他在 spec kit 的一个 GitHub issue 上挂了一年，每隔几周就收到同一个抱怨——「我编辑规格，我编辑代码，代码和规格漂移了，我怎么让规格保持最新？」「本质上你现在有了两个事实源，它就不再有用了。」→ 详细
• 他对「常青文档」的判断很不留情：他见过有人努力维持文档 / 规格与代码一致，「我不觉得有谁真的觉得那很有用」。可以做，也能跑，但维护成本比例不划算——「我从没见过谁说『对，这太棒了，我们很庆幸有这个』」。永远把代码当唯一事实源。→ 详细
• 那这些文档的正确定位是什么？「战术执行文档」——做研究、做计划、做实现，然后把文档扔掉。下次要研究就从头再做一遍，因为「token 便宜，我的时间贵」，而复用一份跟代码库真实状态已不同步的研究，浪费的时间反而更多。→ 详细

• 定义：上下文变嘈杂时，刻意把有用的部分压缩成一份清晰的、标记好的产物，验证它，然后开一段全新的对话。目的只有一个——「尽可能多的工作要发生在聪明区，也就是上下文窗口的前十万 token 左右」。→ 详细
• 三段式的每一段都是在压缩不同的东西：研究文档压缩「代码库状态」；设计文档压缩「构建者意图」（高层规格 + 当前状态 → 期望终态 + 一堆模型提出的设计问题，「有点像一个非常彻底、甚至过度工程化的 plan mode」）；拿这两份开新会话再做规划——「我们知道终点长什么样，现在来拆解怎么走到那儿」。→ 详细
• 分工的依据是「模型在哪一步有短板」，讲得非常清楚：研究这步撒手不管（「我不读研究文档，模型在这件事上真的挺强」）；但设计终态——架构和程序设计——模型不擅长，「它们会做很多决定，有时对、有时错」，所以这一步必须人在环（human in the loop）。→ 详细

• 模型爱做「横向计划」：让它拆步骤，它会说「先做数据库，然后服务层，然后 API，然后前端」。问题是——「我们要在 2000 行代码之后才走到另一头，我到最后才能测试」，而且在已有代码库里，这意味着同时动系统的所有部分。→ 详细
• 人的拆法是纵向的：先做一个带假数据的 mock API 端点 → 把前端弄成想要的样子 → 造服务层把真实数据接通 → 数据库迁移建新表 → 加业务逻辑 → 加错误处理。他说这「跟模型的做法完全正交」——模型会在没有任何人看过代码的情况下就把数据库层和所有错误处理写完。→ 详细
• 判断标准是可验证性带来的心理安全：「我宁愿读五个独立的小 diff，每个我都能手工验证和探索，也不愿读 2000 行代码然后说『它不工作，我不知道哪儿出问题』——你也不知道哪儿出问题，因为代码是你写的、你本该写对。」→ 详细

• 他引用自己的话：「是，AI 能写你的代码，但它也能写你的规格和 PRD。同一条规则永远成立——垃圾进，垃圾出。如果你把思考外包出去，你得到的就是垃圾。」→ 详细
• 具体放大链是可以照抄的四级台阶：一句话或一段语音随口说的东西（平均就两句话）→ 用 AI 变成一页纸，确认这一页对 → 变成三页，确认三页对 → 变成十页的详细提纲 → 然后才能写出一百页份量的代码。→ 详细
• 关键提醒：不要在这些文档上死磕求完美。它们的作用是概率工程——「你在提高输出符合预期的概率、降低输出的不确定性」，随着描述越来越细，「可能落到的终态集合」被一路收敛掉。→ 详细
• 他顺手给了个人才判断：「真的很喜欢玩即时战略游戏的人，大概会很擅长用 AI」——因为你要在「战争迷雾」里做决策：我看到几条信息，所以 30% 概率是这样、40% 概率是那样，我怎么拿到更多信息重新计算概率、判断哪条路最可能通向成功。→ 详细

• token harder 的画像很生动：他在一个叫「hyper engineering」的群聊里，成员有六个 Claude Code 账号，把每一个的每五小时额度窗口都跑满、算好时间、额度一重置立刻开跑。→ 详细
• Dex 用《目标》的语言批它：这是在优化工厂里「某一个节点」的利用率，而不是端到端目标——「我们怎么交付价值、交付人们喜欢、稳定、能长久的东西」。关灯工厂同理：把人从代码评审里拿掉，只是为了往系统里推更多 token。→ 详细
• token smarter 的定义：在不关灯的前提下，从 AI 拿到尽可能多的价值——保住控制力、品味和判断力，理解系统架构，把十年软件工程攒下的看法应用到程序设计上，让你有信心「代码会随时间变得更好、更可维护」。→ 详细
• 他的类比是 Google SRE：目标不是把人从流程里拿掉，而是让人头按平方根 / 对数增长、而产出按线性增长——从「五个数据中心」到「50 个数据中心」，不是要 60 个人，是问「能不能用 10 到 12 个人」（Gergely 补充：Google 的 SRE 团队实际上是变大了的，只是没有线性变大）。→ 详细

• 词源很物理：有些汽车工厂全靠机器人造车，因为里面没有人，所以不开灯——「你走进去，没有灯，甚至连电灯开关都没有」。软件版就是：没有人的输入，原材料进去、汽车出来。→ 详细
• 重要的分寸感：微观上「黑循环」是好的——代码评审 agent 发现问题、回环给构建 agent 修好再回来，这个环不需要人。Dex 反对的只是「完整的黑灯工厂」，也就是完全不读任何代码那一档。→ 详细

• 前 AI 的工厂循环：工作来源（Linear / Jira）→ 架构评审与迭代规划 → 人领工单去做 → PR → 人评审 → CI → 上生产 → 用户抱怨进支持队列 → 回到工作跟踪系统；崩溃进监控栈 → 也回到跟踪系统。问题是每个环节延迟都长，「一个 bug 转回你手上可能要两三个月，修好可能要一两年」。→ 详细
• agent 化改造第一步：把「造东西的人」换成「造东西的 agent」，配上编排（orchestration）、沙盒、大模型、内层 harness、外层 harness（你给 agent 搭的开发环境，也许还有浏览器和录屏）。Cursor 的后台 agent 就是在内层 harness 外面搭的那层外层 harness。→ 详细
• 瓶颈随之搬家：构建从两小时 / 两天变成十分钟，于是瓶颈变成代码评审——那就往评审上砸 agent、再做 agent 化测试，让人只盯代码库里最关键的核心部分。→ 详细
• 再往上一层是把外部循环全部闭合：支持队列直连 agent（有人抱怨，agent 就去修）、Sentry / Datadog 的崩溃进跟踪系统被 agent 领走——「每次出问题，你就直接收到一个 PR」（他点名 Ramp 的 inspect 是这一档的代表）。而最后一层就是有人说「那我们试试关灯吧」：用户抱怨就是坏了，用户不抱怨就是好的，把整个系统当黑箱。→ 详细
• 他给团队的落地建议是增量而非重构：「如果你想做循环工程，你应该一次只造一个循环，并且保持它们小而受控。基本上，除了『别读代码了』这一条，其他建议都很好。」→ 详细

• 「软件工厂」第一次被定义是 1968 年的一场北约（NATO）会议——那时还没有 CI/CD、勉强有版本控制，但已经在讲「你需要造一套像工厂车间一样的步骤系统：编码、测试、验证、集成」。后来被东芝等一批公司采用。→ 详细
• 第二个时刻是 DevOps：Chef / Ansible / Puppet，「服务器磁盘到 90% → Nagios 告警 → 触发 Chef → 扩磁盘」，反馈循环早就存在了。→ 详细
• 第三个时刻在政府里：2018 年，时任美国空军首席软件官 Nick Chaillan 写了一篇一百页文章，主张国防部需要一座「DevSecOps 工厂」——Jenkins、代码质量扫描、安全扫描、CI/CD，把发布频率从「三个月或一年一次」拉到每天。目标是让 90% 的问题被自动化抓住，「而不是让人手工去找 SQL 注入」，顺带也是为了抢人才。→ 详细
• Gergely 的收尾判断：「用软件造软件、并拿工厂打比方」这个想法已经六十多年了，每一代人都试图把这个循环自动化得更多一点。AI agent 只是又一次尝试，尽管大概是最成功的一次。→ 详细

• 一、戳破炒作和黑话：去试、去跟真正在用这些东西的人聊，搞清楚哪些部分真的管用、真的有价值。→ 详细
• 二、保护有用的词：他借 Martin Fowler 的「语义扩散」（semantic diffusion）说——当 agent 这个词可以指聊天机器人、Slack 机器人、编码 agent、工具在循环里……它就什么都不是了。→ 详细
• 三、往自己工作的那一层再下探一层：他不训练模型，但知道 Transformer 怎么训练会指导他在上一层怎么造东西；为了理解软件工厂，他最近在深挖 RLVR（带可验证奖励的强化学习）——「不像 RLHF 还相当学术，RLVR 是这些实验室里训练模型的那台机器」，包括 frontier code、SWE marathon 这类新基准。→ 详细

• 起因是他 2024 年下半年的观察：LangChain / CrewAI 这类框架当时看起来势能巨大（CrewAI 的 Discord 有一万人，每个项目都有 Chroma DB 插件、Composio 插件），但他访谈的那些真在企业里赚钱的 AI 工程师，全都用了一两个月就扔掉框架、改回手写 API 调用，造出来的东西更像流水线和工作流。→ 详细
• 思想来源是 Boundary 的 Vibhav（「AI 界的 Protocol Buffers」）：「你 AI 工作流里的每一步，本质上都只是 token 进、token 出。你作为工程师的工作，就是搞清楚要放什么 token 进去，才能最大化『输出是好的』这个概率。」→ 详细
• 12 条完整列表（Gergely 现场念的）：自然语言到工具调用 / 拥有你的提示词 / 拥有你的上下文窗口 / 工具只是结构化输出 / 统一执行状态与业务状态 / 用简单 API 启动·暂停·恢复 / 用工具调用联系人类 / 拥有你的控制流 / 把错误压缩进上下文窗口 / 小而专注的 agent / 可从任何地方触发 / 在用户所在之处与他相遇 / 把 agent 做成无状态归约器（他自嘲最后一条严格讲应是 transducer）。→ 详细
• 一年后他挑出仍然最站得住的是第三条「拥有你的上下文窗口」：不管是 agent 还是流水线里的单步，「你唯一能影响输出质量的方式，就是极其在意输入、并且精心打磨输入」。发布路径：三月写、四月发 GitHub、Hacker News 首页挂两天、6 月 6 日在 AI Engineer 大会顶楼那个约一百人的小房间开讲。→ 详细

• 时间线：Dex 四月发文；一两周后 Shopify 的 Tobi Lütke 说他喜欢「上下文工程」这个想法；再过一周 Andrej Karpathy 说「我们该想的不是提示词工程，而是上下文工程」。Dex 的态度是「你没法真的拥有一个词，没人记得『提示词工程』是谁发明的」，Gergely 则在节目里明确记在他名下。→ 详细

• 一句话定位：AI IDE + 协作平台 + 「你软件工厂的积木」，面向「在复杂代码库里解难题」的工程师。他把构建者分两类——造副业项目的 vibe coder，和造生产软件的人（东西坏了要罚几百万美元）；HumanLayer 服务后者，承诺是「解得快 2–3 倍，同时不掉进垃圾堆」。→ 详细
• 他昨天刚发的挑衅：「各位，我们是不是该干掉 pull request？」理由是很多编辑器都是「从一个文本框开始、往上焊一个 agent 标签页」，而未来的 IDE 应该从零为 agent 设计——先问「什么样的 IDE 是为帮助开发者管理 agent 的工作而设计的」，再问「怎么让它变成实时协作的」（同步引擎、持久化流）。→ 详细
• 产品形态：一个云平台，有 Google 文档式的可评论组件，agent 能在里面直接呈现原型图、mermaid 图、HTML；所有人的会话互相可见。他用了两个类比——多人协作像 Figma；而「你不必在每一场对话里也能知道正在发生什么、看到在意的就跳进去」是 Slack 相对邮件的优势。→ 详细
• 他对现状的批评一针见血：「就算我们管它叫敏捷，它其实很瀑布：PRD、ARD、工单，每个人去造一天，然后你拿到 PR，然后一个人评审它。」他想要的是「一锅汤」——而那个世界的数据模型是 agent 轨迹（trace）+ 文档 + 把它们归组的任务和项目 + 到处流动的真实 Git diff（「为什么我要一次性评审所有代码？」）。→ 详细
• 值得注意的是他不认为 AI 让评审会议消失，恰恰相反：「优秀的工程团队几十年来一直在做设计评审、写两页或十页文档、做迭代规划拆工单——这一切 AI 都能帮忙。如果你只是用 AI 来写代码，你就错过了 AI 能给整个软件开发生命周期带来的很多好处。」→ 详细
• Gergely 的类比：这像当年 GitHub 之于软件团队——GitHub 之前各团队在孤岛里工作（有的只有一块贴便利贴的板），GitHub 之后你随时能看到某个团队的 PR 在飞、能加入、有历史。Dex 想做的是「更连续、更实时、更协作」的版本，而不是 pull request 这种离散的工作单元。（顺带的冷知识：pull request 是 GitHub 发明的，不是 Git 的一部分；在那之前是把 Git 补丁邮件发给 Linus。）→ 详细

• 物理本科生，17 岁在 NASA 喷气推进实验室实习，为月球南极地形图写了一个「非常朴素、很烂的」Dijkstra 寻路算法，给月球车找不违反坡度限制的路线——那时他还没翻过一本 CS 教材。→ 详细
• 第一份工作在芝加哥 Sprout Social 的 API 平台团队，两三个月就看出公司里最有价值的人是在建开发者平台（CI/CD、沙盒、预览环境）的人，从此对「软件工厂」着魔。他对「我讨厌 CI/CD」那类工程师的反驳是：「作为软件工程师我们是懒的，要干杠杆最高的事——造那个造东西的东西。」→ 详细
• Replicated 四年：先做两年核心工程（在 Kubernetes 之前自研容器编排器，让企业能像装 GitHub Enterprise 一样把 SaaS 装进自己的数据中心），因为跟 CTO 在「软件工厂」上吵太多而转做第一个面向客户的工程师，三个月见遍卡住的客户、成交 12 单，CEO 让他把这个组织建到 25 人。→ 详细
• 然后他主动「走向黑暗面」当产品经理，因为公司要转 PLG（产品驱动增长），而他在客户战壕里泡了四年、攒了一长串路线图看法。他明确反驳「做面向客户的事会毁掉技术公信力」这个恐惧。→ 详细
• 转岗还有个私人动机，来自他做音乐制作人的叔叔 Mitchell Froom（跟 Randy Newman 等人合作过）的一段话：「要在某件事上做到非常好，你必须让它成为你唯一做的事——晚上周末弹吉他想搞乐队的人大概率永远达不到卓越。」于是他没去读「怎么变得不那么内向」的自助书，而是直接把「跟人说话、交朋友、解决他们的问题」变成自己的工作。副作用是逼自己变得有条理（他自嘲「所以我才能同时跑 30 个 Claude」）。「我推荐每个人至少花一两年去做真正面向客户的事。」→ 详细
• HumanLayer 的前身是 2020 年 11 月创立的数据工程公司 Metalytics（严格说是同一家公司换了使命），赶上 dbt 那波数据工程热潮退去、大家发现「这类工具的 TAM（总可寻址市场）没有想象中大」，融资和拿客户都难。→ 详细
• HumanLayer 最初的产品形态也值得记：「像 PagerDuty，但不是『谁值班修服务器』，而是『谁值班批准这个 agent』」——为后台跑的「外循环 agent」提供批准 / 拒绝 / 升级 / 转派 / 延后的路由机制。2024 年秋天带着这个想法进的 YC。→ 详细

• 地点：他没有强观点，把问题转给 Paul Graham 在瑞典讲「为什么旧金山很酷」的那场演讲（付出先行的文化、人们仅因你在这里就更认真对待你）。他自己的体验是「从没感觉跟我的人如此契合」，关键词是临界质量——朋友晚上过来在办公室坐到十一点一起 hack，「这在别的任何地方都做不到」。→ 详细
• 招聘标准（对判断「AI 时代招什么人」很有信息量）：找软件基本功扎实的人——分布式系统、CS 与操作系统核心。「我们可以在几个月内教会一个人成为很好的 AI 开发者，但你很难在三个月内把一个 CS 本科教给一个人。」→ 详细
• 他兴奋的问题空间：实时、云、沙盒、同步这些「过去几年才真正变扎实的新积木」——他们是 Electric SQL 团队的粉丝、durable streams（持久化流）的用户，想造「更铺开、更分布式、几乎去中心化」的系统，因为编码 agent 需要能在任何地方跑、跑长跑短、按需或按计划跑，还都属于同一个「大脑」。（自嘲：「我们做的事有些部分非常无聊，比如所有数据都在 Postgres 里。」）→ 详细
• 新原语需要时间：Gergely 类比云——AWS 2006 年出来，Kubernetes 是十年之后才有的。→ 详细
• 一段本期最好笑的插曲，也是「工具的路径依赖」的注脚：他本科时学校强制用 Subversion，因为 Subversion 的发明者是芝加哥大学的人；他毕业后第二年学校把所有人换成了 Git——「靠，我为了某人的自尊心学了个没用的东西。」→ 详细

• Gergely 给了一张很实用的分层图：最落后的团队只是「开发开始用 Claude Code 或 Codex 写得更快」；中间一层还改造了部署和反馈环节；最靠前的一批，agent 已经能一枪修掉 bug。他的判断是——每个在做生产软件的团队都在疯狂试验，只是节奏不同；一头是「大部分环节都有 agent」的 AI 原生新公司，另一头是「只在少数几个地方放了 agent」的谨慎派。→ 详细
• Dex 对这张图的回应就是本期的操作纪律：「如果你想做循环工程，你应该一次只造一个循环，并且保持它们小而受控。基本上，除了『别读代码了』这一条，其他建议都很好。」——把支持工单变成系统里的工单、再变成 PR，都可以；唯独别把「人读代码」这一环删掉。→ 详细

• Gergely 的类比很贴：资深工程师之所以要好几年养成，就是因为「你现在犯的小错误怎么滚雪球滚成后面的灾难」需要时间才被砸中；前 AI 时代我们常说技术债会把公司拖慢到被超车、或者困在两年的重构里发不出新功能。Dex 承认「有可能 GPT-7 会解决这个问题」，但在那之前，关灯就是在用一个你看不见的时间尺度借债。→ 详细
• 他也点名了自己最在意、但业界讨论不足的一层：不只是系统架构，还有「程序设计」（program design）——接口在哪儿、缝在哪儿、怎么做依赖注入。「软件工程之所以在 1970 年代被发明出来，就是因为我们意识到需要一些技术，来避免『一大坨意大利面』这个问题。」→ 详细
• 另一条容易被忽略的直觉论：坏模式是靠「凌晨三点调试过它们」学会的（引自 Netflix 的 Jake 在 AI Engineer Code 的演讲）——「没有比亲自熬过那个不管用的东西更好的学习方式」。这也解释了为什么模型学不会：它没熬过。→ 详细

书单（唯一的推荐问）：Dex 最近常聊的是 Martin Fowler《重构》（Refactoring）——因为团队大量时间花在「改进现有代码的设计」、琢磨怎么让模型写出易维护易读易懂的代码。他还补了一句更宽的判断：他们在重读软件工程经典——《重构》《代码整洁之道》（Clean Code）《程序员修炼之道》（The Pragmatic Programmer）——「我觉得这些东西现在比以往任何时候都更相关。」→ 详细

Gergely 的三点收尾：

1. 反差最大的一点：Dex 是 agent 编码非常坚定的信徒，却正是他在警告「停止读代码，你大概有三到六个月，之后代码库就会变成重写比修复更容易」——而这来自第一手的关灯工厂失败经验。→ 详细
2. 最可抄的一点：慢循环。「循环工程」这个词听着空洞，但他们做的事无聊到任何团队今天就能采用——每晚一个 cron、修一个反模式、开一个小 PR，开发者仍然评审和批准。→ 详细
3. 最有历史感的一点：「软件工厂」来自 1968 年北约会议，这个想法已经六十多年，每一代人都在把这个循环自动化得更多一点，AI agent 只是又一次尝试——「尽管大概是最成功的一次」。→ 详细

其他被提到的资源：Paul Graham 讲「为什么旧金山很酷」的瑞典演讲（Gergely 说会放 show notes）；Dex 自己的 12-factor agents GitHub 仓库；他的文章《不许 vibe》（No Vibes Allowed）。