Advanced Context Engineering for Agents
Aug 25, 2025, 视频： Advanced Context Engineering for Agents (YouTube)
开场与背景
- 演讲者：Dex（Human Layer 创始人，YC F24）。
- “Context Engineering（上下文工程）”一词的来历：源自 2022-04-22 的《12-actor agents / Principles of reliable LLM applications》小宣言；2022-06-04 把一场演讲标题改为 “context engineering”。
- 主题：在当下模型能力下，如何通过“上下文工程”把编码类 Agent的产出拉到可用的上限。
行业观察与两场参考演讲
推荐 1：Sean Grove – “The New Code”
- 观点：我们在“vibe coding（聊天式编程）”上方式不对——如果你花两小时跟 Agent 聊天得到代码，然后把所有提示词丢掉，只保留编译产物，就像只提交 .jar 而丢掉源码。
- 启示：在“AI 写更多代码”的未来，**规格说明（specs）**才是最关键的“源码”。
推荐 2：斯坦福研究（10 万名开发者、从大厂到创业公司）
- 发现：AI 编程带来大量返工（rework）；在复杂/遗留（brownfield）场景甚至适得其反，会拖慢进度。
- 现实共识：适合原型，不适合大型/复杂/遗留代码库（至少在当下）。
个人实践转变：被迫采用“Spec-first Development”
- 背景：与“最强 AI coder 之一”合作，几天一发 2 万行 Go 的 PR（含并发、关停顺序等复杂系统逻辑），几乎无法逐行评审。
- 变革：转向先写规格（我仍然看所有测试，但不再逐行看实现）。
- 成果：约 8 周完成转型；效率起飞；演讲者本人连续提交 6 个 PR，近两个月几乎不打开非 Markdown 文件。
目标（被现实“强制”设定）
- 能在大型复杂代码库中有效工作；
- 能解决复杂问题；
- 零糊弄（no slop），直达生产质量；
- 团队共识一致（mental alignment）；
- 大胆花 token（最大化上下文质量）。
最朴素的用法：与 Agent 来回“吼”
- 症状：跑偏、上下文耗尽、不断纠正。
- 粗暴改进：**及时“重开一个干净上下文”**并加上“不要再尝试 X”的约束；当你看到明显跑偏迹象，说明该重开了。
有意识的“紧凑化（Intentional Compaction）”
思路：不是简单 Slash-compact；而是把关键信息写入“进度文件（progress file）”，作为下一轮/下一个 Agent的“上手包”。
需要紧凑化的对象：
- 查找/定位信息、系统流向理解、具体编辑/操作步骤；
- MCP 工具若返回巨型 JSON，会大量吞噬上下文——要提炼。
目的：把“无结构、冗长、嘈杂”的过程信息，变成结构化、可携带、低体积的“意图与现状快照”。
为什么一切都围绕上下文？
- 观点：LLM 更像纯函数（除温度等少量参数），输出质量几乎只取决于输入上下文质量。
- 优化四要素：正确性、完整性、体积、轨迹（trajectory）。
- 反面层级：坏信息 > 缺信息 > 噪音过多。
- 经验法则（Jeff Huntley / SourceAMP）：约 170k token 的可用窗口——把“做活儿”的 token 占比压低（让模型少做无效阅读/搜索，多做决策/实现），效果更好。
- 例子：Ralph Wiggum as a Software Engineer——“用同一提示循环跑一夜”之所以有效，是上下文与循环策略设计得当。
子 Agent（Sub-agents）做“行内紧凑化（Inline Compaction）”
- 常见用法：让子 Agent 专注搜寻定位（比如“某事在哪里发生/数据如何跨组件流动”），把高成本的搜索/阅读从父 Agent 上剥离。
- 理想返回：结构化清单（文件、行号、路径、因果/流向摘要）。
- 难点：“电话传话”问题——如何让父模型把“返回格式要求”准确传给子模型，避免失真与混乱。
更进一步：频繁且有意识的紧凑化（FIC — Frequent Intentional Compaction）
目标：上下文使用率长期 < 40%。
三阶段工作流：Research → Plan → Implement
Research（研究）：
- 产出：带文件名 + 行号的“系统工作原理与问题定位”说明，让后续步骤定点阅读，避免“全库乱搜”。
- 有公开的研究提示词（research prompt）与研究产出结构。
Plan（计划）：
- 产出：将进行的每一项变更（到文件/片段粒度）+ 逐步测试与验证方案；
- 计划应远短于最终代码改动量，但可完全覆盖意图与验证路径。
Implement（实现）：
- 边实现边更新计划（勾掉完成项、追加新上下文），持续保持**< 40%** 的上下文占用；
- 有公开的实现提示词（implement prompt）。
人在环：强制人工审阅“研究与计划”，比起审 2000 行代码，更容易更早截断错误轨迹。
线性工作流：按 Research → Plan → Implement 推进，每一步都可校验与复位。
代码评审的真正作用：
- 不只是找 bug，更是团队的“心智对齐（mental alignment）”，让每个人都理解系统为何这样改变。
- 我可以无法每天看 2000 行 Go，但我一定能看 200 行实现计划，并在更上游纠偏。
外部验证与案例
BAML 案例（与 YC 创始人 Vibbo(v)）
- 挑战：单发（one-shot）修复 30 万行“RS”代码库（注：应为 Rust/VS Code Remote？演讲原文简写“RS”）；
- 结果：PR 被 CTO 当场合并（在录制播客时已合并）；验证了该方法在遗留代码库也有效且“无糊弄”。
边界语言/编译器 CEO 合作
- 7 小时内交付 3.5 万行改动（部分生成、部分手写），相当于 1–2 周工作量；
- 实现目标级别能力：为一门语言增加 WASM 支持。
关键洞见（错误的放大性）
- 一行坏代码只是坏一行；
- 计划里一个坏点可带来数百行坏代码；
- 研究阶段一个误解可带来上千行坏代码。
- 因此要把精力前置到：界定正确问题 + 让 Agent 真懂系统如何工作。
流程治理：对 /cloud-md 与 slash 命令严格管理，投入数周打磨后才允许变更。
实绩与数据
- 既定目标全部达成（适配大库/复杂问题、生产质量、团队对齐）。
- “大胆花 token”：小团队一月内消耗大量 credit，物有所值（节省工程时间）。
- 新人效应：实习生 Sam 第一天交付 2 个 PR，第八天单日 10 个 PR——工作流可复制、可放大。
展望
- 编码 Agent 可能趋于“商品化”；真正困难的是团队与流程的再造（不舒服但必要）。
- 我们正与从 6 人 YC 团队到千人上市公司的组织合作，帮助落地这种转型。
- 预告：明日将举办 “hyper-engineering” 活动（名额将满，找我自荐可争取席位）；有一支90 分钟长视频进一步详谈。
方法论清单（可执行要点）
总原则：一切皆“上下文工程”。
策略组合：
- 及时重启上下文（跑偏即重开）；
- 进度文件做有意识紧凑化，替代盲目 compact；
- 用 Sub-agents 把“重读/检索”外包，父代理只做决策/实现；
- FIC 工作流（Research/Plan/Implement）+ 上下文<40% 的红线；
- 人审研究与计划，在“高杠杆处”截断错误；
- 度量 token 使用结构：尽量减少“机械阅读/搜索”的 token，把窗口让给“有效指令/结构化知识”。
一句话总结
- 当下最有效的“AI 编码”不是靠更聪明的 Agent，而是靠更聪明的上下文：让模型始终拿到正确、完整、紧凑、可执行轨迹的输入，并把团队共识固化在“研究与计划”的可审阅工件里。
[00:00–00:42] 开场与术语来源
[00:43–01:31] “接下来是什么”与两场参考演讲
推荐 2 个今年最喜欢、也比《12-Factor Agents》观看量更高的演讲：
- Sean Grove – The New Code：强调“规格（spec）才是核心产物”，不要把对话式“vibe coding”的临时提示词当产出。(AI Native Dev, Reddit)
- Stanford 研究（10 万开发者）：大规模真实世界数据表明，AI 编程收益伴随大量返工（rework），在复杂/存量（brownfield）场景甚至可能适得其反。(YouTube, Class Central)
[01:31–03:44] 背景现实与目标
- 许多团队的共识：AI 编码适合原型，不太适合大型仓库/复杂系统；例如 Replit 的观点——产品经理用 AI 快速做原型，最终工程师重写进生产。（视频中转述）(YouTube)
- Dex 与顶尖 AI 程序员协作：频繁收到 2 万行 Go 代码 PR，无法逐行审；被迫采用 spec-first。经过 ~8 周转型，只审测试与规格而非每行代码，效率飞升；Dex 自称上周四一天合并 6 个 PR，近两个月几乎不打开非 Markdown 文件。（经验分享）(YouTube)
- 明确五个目标：能在大仓库工作、能解复杂问题、无糊弄（no slop）、可上产线、全员对齐；以及尽量多花 token（本次是“高级”上下文工程）。(YouTube)
[04:05–05:25] 最朴素与“重开局”的做法
- 朴素用法：与代理反复对话直至上下文耗尽或放弃。
- 改进一：当发现跑偏时，重置上下文重新来（“try again, but don’t do X”）。
- 何时重置：出现明显“走丢/自我纠缠”的迹象就应重开。（经验性启发）(YouTube)
[05:04–06:18] “有意压缩（Intentional Compaction）”与进度文件
- 不使用“/compact”这类黑盒压缩；而是明确把关键进展落盘成进度文件（progress file），用它来引导下一次/下级代理承接工作。
- 关注上下文窗口占用：查找文件、理解流程、编辑/工作痕迹，以及MCP 工具返回的大 JSON都会淹没上下文，因此需要选择性纳入。(YouTube)
[06:01–06:54] 原因：LLM 是“纯函数”，一切皆上下文工程
- 除模型/温度外，效果几乎只由输入上下文质量决定；编码代理持续在“选工具/做编辑”循环中，上下文决定下一步是否正确。
- 目标：在正确性、完整性、体积、轨迹四维上优化上下文；最糟的是错误信息，其次缺失信息，再次噪声。(YouTube)
[06:54–07:35] Token 预算直觉与“Ralph Wiggum”方法
- 经验公式：可用 ~170k tokens；真正做工作的 token 越少，质量越高（把“搜、读、找”的开销外包）。
- Jeff Huntley 提出的**“Ralph Wiggum 当软件工程师”：把同一提示词循环跑一整晚也能得到出奇好的结果——若你理解上下文窗口**，这是种聪明的用法。(Geoffrey Huntley)
[07:35–08:44] 子代理（Sub-agents）的“内联压缩”
- 常见任务：定位信息或跨组件信息流，由父代理通过工具把指令转给子代理去搜，子代理返回精炼结果（如文件与行号），父代理据此继续，无需把大段上下文塞回窗口。
- 难点：传话游戏——必须在父→子提示里约定返回格式/粒度，否则不稳定。(YouTube)
[08:44–10:22] 最有效的方法：高频、主动的上下文管理
目标：上下文利用率 < 40%。
三阶段工作流：Research → Plan → Implement。
- Research（调研）：产出研究文件（含文件名+行号，告诉后续代理去哪里看）。
- Plan（计划）：列出将修改的一切（文件/片段），并明确测试与验证步骤；计划通常远短于实际代码变更。
- Implement（实现）：按计划写代码；若需要长流程，持续更新计划（标注已完成、下一步），让新上下文保持干净有序。
以上三套提示词已开源（CLAUDE.md 与相关 /slash 命令）。(YouTube)
[10:22–10:48] 必要的人审与线性流程
- 这些方法不是魔法，必须认真阅读与审核；相较于审 2000 行 PR，审 200 行实现计划更容易尽早发现问题并保持团队一致性。(YouTube)
[10:48–12:01] 实战案例 1（BAML/Boundary 生态）
[12:01–12:56] 关键洞见：错误的“层级放大”
- 代码里的一行坏改动只是“一行坏代码”；
- 计划里一个坏片段可能扩散成数百行坏代码；
- 研究里一个坏结论/误解，可能带来上千行坏代码。
- 因此应把更多精力前移：定义正确问题 → 让代理理解系统 → 再开写。团队会严控 CLAUDE.md 与 /slash 命令的变更，并只审研究与计划以保证认知对齐。(YouTube)
[12:56–13:40] 结果回顾
- 目标均达成：支持大仓库/复杂问题、生产级质量与团队对齐；确实花了很多 token/credits，但带来显著工程师时间节省；新人上手快（实习生首日就合并 2 个 PR，第 8 天达 10 个/天）；讲者本人几乎只看规格不看代码。(YouTube)
[13:40–14:20] 展望与资源
相关外部参考
- 12-Factor Agents 原始仓库与理念（Dex/ Human Layer）：上下文工程是让 LLM 应用更可靠/可维护的工程实践集合。(GitHub)
- The New Code（规格驱动开发）：把规格作为一等产物的趋势与要点。(AI Native Dev, Reddit)
- Stanford “10 万开发者”研究演讲：在复杂/存量场景，AI 可能导致返工/减速；在简单/绿地任务上收益更明显。(YouTube, Class Central)
- “Ralph Wiggum”方法（Geoffrey Huntley）：理解上下文窗口后，循环长跑同一提示也是一种有效工程策略。(Geoffrey Huntley)