不靠“vibe”写代码如何让 AI Agent 攻克复杂代码库写在开始笔者平时使用 Codex、Claude Code、Pi 等编码 Agent 工具时总会遇到同一个问题简单场景可以胜任但在复杂业务背景下Agent 编码很难达到想要的结果——经常出现失忆、幻觉、注意力不集中、过度设计等问题导致代码不得不返工。因此想参考技术大佬面对这些问题时是怎么决策的。视频来自YouTube AI Engineer的 Vibes Allowed: Solving Hard Problems in Complex Codebases演讲者Dexter Horthy是一位美国科技创业者、软件工程师主要活跃在 AI Agent和开发者工具领域。 他的主要身份HumanLayer 创始人兼 CEO曾任 Replicated 高管/工程负责人相关职位AI Agent 社区的活跃人物文章概要AI 在新项目中往往表现不错但进入历史悠久、关系复杂的代码库后很容易制造返工与技术债。问题不只在模型能力更在于上下文错误、缺失、噪声和失败对话都会影响 Agent 的下一步选择。Dex 提出用 intentional compaction有意压缩、subagent子代理和 Research–Plan–Implement 工作流让 Agent 尽可能始终处于高质量上下文中。一、背景AI 让我们写得更多还是返工得更多AI 确实能快速生成代码搭一个新页面、写一段脚本、补一个简单接口通常都能很快交付看起来不错的结果。但一旦放进真实且复杂的工程环境情况可能迅速恶化没有找到真正应该修改的文件理解了局部代码却误判了系统整体的数据流重复实现代码库中已有的能力为了完成当前任务绕开既有架构生成的代码暂时能运行却增加了后续维护成本开发者不得不反复解释、纠正和返工。slop看似交付实则返工演讲开头引用了一项针对约 10 万名开发者的调查结论是AI 让团队交付了更多代码但其中相当一部分工作是在重做前一周交付的低质量内容。这类产出被称为slop它不只是“写得不好看的代码”还包括没有充分理解代码库便生成的修改看似完成任务、实际上需要持续返工的实现导致 codebase churn代码库反复变动的低质量产出不符合既有架构与约束的代码。Greenfield 与 BrownfieldGreenfieldBrownfield codebase定义从零开始的新项目持续演进多年的既有系统特点历史约束少、代码规模小模型容易掌握全局大量历史设计、分散在多模块的业务规则、不明显的调用关系、兼容性约束、隐含约定与技术债AI 可以很好地完成一个新的小型项目但如果让它进入一个已有十年历史的 Java 代码库结果可能完全不同。本次分享要解决的核心问题如何让今天的模型在复杂棕地代码库中解决真正困难的问题同时减少 slop 和返工二、结果从“不好用”到 23 倍吞吐量Dex 坦言他第一次使用 Claude Code 时并没有留下特别深刻的印象认可产品体验、也能看出进步但不认为足以改变软件开发方式。后来他所在的三人团队花了八周时间重新设计工作流带来了约23 倍的吞吐量提升——交付速度快到不得不改变协作方式甚至重新设计整个软件开发流程。团队逐渐收敛出的目标让 AI 能在 brownfield codebase 中工作让 AI 能解决复杂问题尽量避免 slop维持团队的 mental alignment心智对齐尽可能把有意义的工作交给 AI发挥 token 的杠杆价值。整场分享把整套实践概括为Advanced context engineering for coding agents面向编码代理的高级上下文工程三、分析真正的痛点不是模型不会写而是上下文一团乱1. 最典型的情况纠正循环大多数人使用 coding agent 时都会经历下面的循环提出需求 ↓ Agent 给出错误实现 ↓ 指出错误并补充说明 ↓ Agent 再次修改 ↓ 发现新的错误 ↓ 继续纠正直到上下文耗尽或开发者放弃看起来是在“逐步逼近正确答案”但实际只会越来越乱。问题在于它能否记得自己搜过哪些文件、运行过哪些命令、采用过哪些错误假设、用户如何否定了这些假设答案往往是不能——上下文已经脏了只能重新开个窗口保留原任务和已确认的事实丢弃无效探索再从正确方向重新开始。但直接重启也有代价新的 Agent 必须重新搜索代码、理解调用关系、定位文件。于是提出了intentional compaction有意压缩。2. 上下文压缩的核心概念Context EngineeringLLM 是stateless无状态的。Dex 曾把 LLM 类比为 pure function——虽然输出具有非确定性严格来说不是纯函数但确实可以视为无状态的。对 coding agent 来说每一步都可能面临很多选择接下来读哪个文件是否继续搜索应该调用哪个工具其中可能同时存在数百个合理选择和数百个错误选择。影响模型下一步输出的核心信息完全来自当前对话中已有的内容。因此更高质量的上下文 Token ⟶ 更高概率的正确输出 Token \text{更高质量的上下文 Token} \longrightarrow \text{更高概率的正确输出 Token}更高质量的上下文Token⟶更高概率的正确输出Token上下文工程就是优化输入的 token让结果更接近正确。怎么定义“正确的输入”从 4 个方面切入维度含义Correctness正确性上下文中的事实必须正确Completeness完整性必须包含解决任务所需的关键文件、调用关系和约束Size大小上下文应尽可能精简避免噪声占用有限空间Trajectory轨迹对话历史应该尽量呈现正确、稳定的推进方向这 4 点不可能同时满足——正确性、完整性、轨迹都满足时上下文就不可能短了。所以要尽可能舍弃部分上下文、保留关键正确的信息但不能压缩得太短。短而错误的上下文并不好正确但略长的上下文也可能优于精简却缺失关键约束的上下文。3. 不要在错误的轨迹上继续争论假设对话一直是Agent做出一个错误修改 → 用户指出错误 Agent再次做出错误修改 → 用户再次指出错误 Agent又一次做出错误修改 → 用户继续指出错误从人类视角看我们是在耐心地纠正模型但从模型视角看当前上下文展示的连续模式是模型犯错 → 用户批评 → 模型犯错 → 用户批评。模型可能继续生成最符合这段对话轨迹的内容——再做错一件事让用户继续纠正。这并不意味着模型真的拥有这种意图而是说明对话历史不仅记录事实也在塑造后续输出的统计轨迹。因此一旦对话长期陷入“生成—否定—再生成—再否定”最合理的处理方式可能不是继续争论而是提取已确认的正确事实删除错误假设与无效探索启动新的上下文从正确轨迹重新开始。4. 模型会随着上下文变长而变得愚蠢以 Claude Code 为例上下文窗口大约为 168,000 tokens其中一部分还要为输出和压缩预留。问题是模型智力并不会等到上下文完全耗尽才下降注意力会被不断分散。Dex 给出的经验性判断对某些复杂任务而言上下文使用到约 40% 附近时就可能开始出现 diminishing returns边际收益递减。为什么模型智商会下降上下文不断增长 ↓ 噪声和历史信息不断累积 ↓ 模型定位关键事实的难度提高 ↓ 复杂任务更早出现性能衰减这是最常见的上下文杀手搜索和定位文件理解代码流编辑文件的过程测试输出构建输出MCP 工具返回的大量 JSON。如果 coding agent 配置了太多 MCP 工具并让它们持续向上下文中注入垃圾Agent 甚至可能从任务一开始就站在垃圾堆里。所以工具越多不一定越强——不能转化为有效决策的信息只是在消耗上下文预算。四、解决三个方法方法一Intentional Compaction有意压缩什么是有意压缩无论当前任务是否已经跑偏都主动让 Agent 将现有上下文压缩成一份 Markdown 文档随后拿着这份上下文开始新的工作区域——相当于给 Agent 一个清晰的背景、目标、规范。旧上下文 ├── 文件搜索记录 ├── 完整文件内容 ├── 构建与测试输出 ├── 错误尝试 └── 已确认事实 │ ▼ Intentional Compaction │ ▼ 压缩后的 Markdown ├── 当前任务 ├── 已确认结论 ├── 关键文件与行号 ├── 相关代码流 └── 下一步工作 │ ▼ 新 Agent 直接继续这样新 Agent 不必重新进行所有搜索也不必继承旧上下文中的大量噪声。一份好的压缩结果应该包含什么当前究竟在解决什么问题哪些文件与问题直接相关相关代码位于哪些行哪些代码流与当前任务有关。可直接使用的模板# 当前任务 描述需要解决的问题。 ## 已确认事实 - 已经通过代码验证的事实 - 当前系统的相关行为 - 不能违反的现有约束 ## 关键位置 - path/to/file-a: 与问题相关的代码位置 - path/to/file-b: 调用方或依赖位置 ## 相关代码流 说明请求、数据或状态如何经过相关模块。 ## 当前进度 - 已完成 - 待完成 ## 下一步 给出下一阶段应处理的具体事项。人工审核压缩最关键的不在于短而在于正确。压缩并不会自动保证正确——如果旧上下文中已经存在误解模型可能把误解一并写入摘要未经审核便交给新 Agent只是把错误从长上下文迁移到了短上下文。所以必须人工审核才能拿到正确的交接文档。方法二Subagent——它是上下文隔离器提到 subagent子代理我们会下意识地按岗位创建角色来并行执行、加快开发效率比如前端/后端/QA/数据科学子代理。Dex 纠正了这一点Subagents are not for anthropomorphizing roles. They are for controlling context.子代理不是为了把角色拟人化而是为了控制上下文。正确的用途假设主 Agent 正在解决一个复杂问题但需要先了解某个功能在大型代码库中如何工作主 Agent 可以创建一个独立的子上下文主 Agent │ ├── 任务实现当前功能 │ └── 派生子 Agent 查清楚这个功能在代码库中是如何实现的子 Agent 可以在自己的上下文中完成高消耗工作搜索大量文件、阅读完整代码、追踪调用链、理解代码库结构、排除不相关模块。然后它不把所有过程原样传回主 Agent只返回一个精简结论目标逻辑位于某文件关键入口是某函数相关调用关系如下主 Agent 接下来只需阅读这个文件。主 Agent 因此不必承担搜索过程中产生的上下文负担可以直接读取最相关的文件并开始工作。子代理的本质从上下文工程角度看子代理是一个“信息漏斗”大量代码与搜索结果 │ ▼ 子 Agent 隔离处理 │ ▼ 少量、高密度、任务相关的信息 │ ▼ 主 Agent它就是一个上下文隔离器防止主 Agent 被垃圾污染。但使用子代理也需要注意返回结果的正确定性。方法三Frequent Intentional Compaction频繁有意压缩单次压缩只能解决某一个节点上的上下文膨胀。Dex 进一步提出不要等上下文被垃圾堆满了才开始压缩。压缩不再是异常处理动作而是开发流程的一部分开发者要有意且主动地压缩。与其让一个 Agent 在同一个对话中完成理解代码库 → 设计方案 → 修改代码 → 运行测试不如在不同阶段之间主动建立边界每个阶段只保留下一阶段需要的信息。这就引出了整场演讲最重要的工作流Research → Plan → Implement五、实践三阶段工作流 Research、Plan、Implement阶段一Research目标理解系统如何工作找到真正相关的文件理清代码流保持客观不急于提出修改方案。这一阶段可能需要大量搜索和阅读也因此很容易产生大量上下文。合理的做法是让研究过程独立运行最后输出一份高密度的研究文档。可直接使用的模板# Research目标问题 ## 系统当前行为 说明相关功能目前如何运行。 ## 关键文件 - path/to/file-a - path/to/file-b ## 代码流 入口 → 中间处理 → 数据写入或输出 ## 与问题直接相关的事实 - 事实一 - 事实二 ## 尚未确认的问题 - 待确认事项一 - 待确认事项二阶段二Plan在理解代码结构后就可以开始规划怎么开发了务必澄清所有需求。plan Outline the exact steps —— 列出准确的步骤。阶段三Implement规划清楚之后就可以开发然后再验收。三个阶段是怎么连接的每个阶段都拿到正确的输入、工作并产生正确的结果Research 上下文 ├── 大量搜索 ├── 阅读代码 └── 输出压缩后的研究结论 │ ▼ Plan 上下文 ├── 使用研究结论 └── 输出明确实施步骤 │ ▼ Implement 上下文 ├── 使用研究结论与计划 └── 聚焦代码修改每一次阶段切换都可以成为一次intentional compaction。六、总结长期任务或复杂项目中怎么用 AI Coding为什么 AI 在复杂代码库里容易制造 slop因为它经常需要同时承担四类工作搜索代码理解系统设计方案编写并验证代码。如果所有过程都发生在同一个上下文里模型需要一边处理当前任务一边背负所有历史搜索、错误输出和工具结果。随着上下文增长它做出错误下一步选择的概率也会提高。Dex 的方案可以概括为复杂任务 │ ├── 用 subagent 隔离高消耗搜索 ├── 用 intentional compaction 提炼有效信息 ├── 用 Research 建立客观理解 ├── 用 Plan 固化下一步路径 └── 用 Implement 聚焦执行其本质很简单在开发中不断保持输入的正确和简洁。