#631.深入理解 Context engineering

#631.深入理解 Context engineering

94分钟 ·
播放数333
·
评论数0

📝 本期播客简介

本期我们克隆了:知名播客 The Pragmatic Engineer Context engineering with Dex Horthy

原内容更新时间:2026-07-15

本期嘉宾是 HumanLayer 创始人、“上下文工程”一词的提出者 Dex Horthy。主持人是《The Pragmatic Engineer》的作者 Gergely Orosz。Dex 可能是目前把“让 AI Agent 全自动写代码”这件事推得最远的人之一——他曾在 2025 年搭建了一个“关灯软件工厂”,让 Agent 在没有人类审查的情况下连续数月提交代码,但四个月后,他不得不亲手把它关掉,因为代码库已经烂到跑不动了。

这期节目不是泛泛地聊 AI 编程趋势,而是从上下文工程、封装工程、循环工程这些正在重塑开发方式的核心概念出发,坦诚地复盘了哪些做法真的管用、哪些只是看起来很美的陷阱。如果你正在思考怎么把 AI Agent 集成到自己的开发流程里,或者想知道“让 AI 全自动写代码”的极限到底在哪里,这期会提供大量一手经验和极具操作性的判断。

👨‍⚕️ 本期嘉宾

Dex Horthy,HumanLayer 联合创始人兼 CEO,“上下文工程”这个词的提出者。他曾在 Replicator 从工程师做到产品经理,有深厚的平台工程和面向客户的经验。过去两年,他跟数百位 AI 工程师深入交流,并亲自带队测试了许多前沿的 AI 编程想法,对用 LLM 构建软件这件事有着极其务实的理解。

⏱️ 时间戳

开场 & 嘉宾背景

01:20 什么是上下文工程?

03:45 Dex 的编程启蒙:从 NASA 月球车寻路算法说起

06:11 为什么 Dex 从第一份工作起就痴迷于“软件工厂”

12 要素 Agent 宣言与上下文工程

15:15 “12 要素 Agent 宣言”是怎么来的

18:40 12 条原则中最关键的一条:掌控你的 context window

21:54 上下文工程到底是什么?把层层抽象拆开来看

22:59 为什么上下文工程最近一年才被广泛讨论

24:42 成本与上下文工程的关系:先跑起来,再做对,最后再提速

封装工程与上下文的物理边界

26:26 什么是封装工程?Martin Fowler 的内封装与外封装

28:59 上下文的物理特性:smart zone 和 dumb zone 的边界在哪

30:37 信息预算 vs 指令预算:两种不同的上下文消耗

01:10:03 什么是 smart zone,什么是 dumb zone?前 10 万 token 是关键

循环工程:从 Ralph Wiggum 到慢循环

33:28 循环工程的核心:让模型检查自己的工作

36:43 Dex 团队每晚运行的“慢循环”:早上醒来看到代码变好的 PR

39:13 循环工程的陷阱:代码多到读不过来,三到六个月后代码库崩溃

软件工厂与暗工厂

45:10 软件工厂的历史:从 1968 年 NATO 会议到 DevOps 再到 Agent 工厂

50:01 Agent 化工厂如何把“人”从流程中替换掉

51:42 关灯软件工厂的真相:Dex 团队 2025 年 7 月搭建,11 月关掉

01:15:29 什么是暗工厂?全自动化、没有人类、连灯都没有

Token Harder vs Token Smarter

01:14:31 Token harder:把云订阅额度榨干,最大化 token 利用率

01:16:31 Token smarter:在保持控制和质量的前提下,从 AI 榨取价值

01:19:30 AI 垃圾:垃圾进,垃圾出。把思考外包出去,得到的只会是垃圾

HumanLayer 与 AI 时代的协作方式

01:22:07 HumanLayer 是什么?帮工程师在复杂代码库里解决难题

01:23:46 我们是不是该干掉 pull request?为 Agent 重新设计 IDE

01:28:44 硅谷的地理优势:人群密度让一切自然发生

🌟 精彩内容

💡 “你用的 context window 越少,得到的结果就越好”

Dex 将 context window 划分为 smart zone(前 10 万 token)和 dumb zone(超出部分)。一旦内容堆到 dumb zone,模型就会犯迷糊、表现退化。他建议频繁进行“有意识的压缩”——把研究结果浓缩成文档,开新会话继续工作,始终待在 smart zone 里。

“你用的 context window 越少,得到的结果就越好。”

💡 “我们在 2025 年 7 月搭了一个关灯软件工厂,到 11 月就把它关掉了”

Dex 团队真的试过让 Agent 全自动写代码、不读任何 PR。结果三到六个月后,代码库变得一团糟,重写比修更容易。他总结:模型在 SweeBench 这类基准上训练,擅长修单次 bug,但完全不懂怎么写“三个月后还能维护”的代码。

“循环的问题在于,到某个节点,你会生成太多代码,多到你根本读不过来。”

💡 “慢循环”:每天早上醒来,代码库都比昨天好一点点

与其让 Agent 跑三天产出一个六万行的 PR 没人敢审,Dex 团队的做法是设一个 cron 定时任务,每晚跑一次,修一个问题或一种反模式,提一个小 PR。团队早上醒来看到四个小 PR,每个都能轻松审查。这是循环工程最务实的落地方式。

“我们每天早上醒来都会看到一个 PR,让代码库变好一点点。”

💡 “如果你把思考外包出去,你得到的就会是垃圾”

Dex 强调,AI 能帮你写代码、写规格、写 PRD,但垃圾进垃圾出的规则不变。他的方法是:从两句话的想法开始,用 AI 扩展成一页文档,确认后再扩展成三页,再扩展成十页大纲——每一步都有人类把关,逐步压缩不确定性。

“如果你把自己的思考外包出去,你得到的就会是垃圾。”

💡 “Token smarter 不是不用 AI,而是在不关灯的情况下榨出尽可能多的价值”

Dex 区分了两种路线:token harder 是堆 token、关灯、把人拿掉;token smarter 是保持人的控制、品味和判断力,同时用 AI 把速度提升两到三倍。他追求的是找到正确的杠杆点——在规划上花一小时,能在实现阶段省下四小时的返工。

“怎么在不关灯的情况下,从 AI 那里榨出尽可能多的价值?”

💡 “软件工厂”这个词来自 1968 年的一次 NATO 会议

用工厂的类比来让软件去构建软件,这个想法已经超过六十年了。从 DevOps 到 CI/CD 再到今天的 Agent 工厂,每一代人都在尝试把构建软件的循环自动化得更彻底。AI Agent 不过是又一次尝试——虽然很可能是最成功的一次。

“软件工厂最早的定义、第一次被用,是 1968 年的一次 NATO 会议。”

💡 “一旦模型跟你说‘你说得完全对’,你就该重新开始了”

Dex 观察到,当模型开始犯蠢、不断重复错误时,问题出在 context window 的四个因素:token 数量、信息质量、信息缺失、以及对话轨迹。模型是自回归的,如果历史记录里它犯错你骂它,它就会预测“下一句我该再犯个错好让人类来骂我”。这时候最好的做法是压缩产物、开新会话。

“你说得完全正确,永远是模型在你指出它错得离谱时的标准回应。”

🌐 播客信息补充

本播客采用原有人声声线进行播客音频制作,也可能会有一些地方听起来怪怪的

使用 AI 进行翻译,因此可能会有一些地方不通顺;

如果有后续想要听中文版的其他外文播客,也欢迎联系微信:iEvenight