高级上下文工程 for Coding Agents
Source: Dev.to
请提供您希望翻译的正文内容，我将按照要求保留源链接、格式和技术术语进行简体中文翻译。
问题：生产力 ≠ 进展
大规模的开发者调查显示出一个一致的模式：
- AI 增加了交付的代码量
- 代码 churn（变动）增长得更快
- 团队反复重构 AI 生成的输出
- 老旧（brownfield）代码库受到的负面影响最严重
AI 在全新（greenfield）项目、原型和仪表盘上表现良好。但在受限于遗留系统的复杂环境中，天真的代理使用会变成一个 tech‑debt factory（技术债务工厂）。
这与许多资深工程师和创始人的实际经验相吻合。
为什么会这样：上下文是唯一的控制面
大型语言模型是：
- 无状态（会话之间没有记忆）
- 非确定性
它们完全受 当前上下文窗口 的支配。每一个决定——工具使用、文件编辑、幻觉——都由当前上下文中的 token 决定。
Better tokens in → better tokens out.
更多的 token 并 不 意味着更好的结果。
愚蠢区
随着上下文使用量增加，模型质量会下降。经验表明，这通常在 ≈ 40 % 的上下文窗口 左右开始，具体取决于任务复杂度。该区域被称为 愚蠢区。
常见原因
- 大型工具输出（JSON、UUID、日志）
- 未过滤的文件转储
- 重复的纠正循环
- MCPs 转储无关数据
- 充满噪声的长聊天记录
一旦进入愚蠢区，代理的可靠性会下降，无论模型质量如何。
轨迹重要性
LLM 在对话内部学习模式。如果对话看起来像：
- 模型犯了错误
- 人类斥责模型
- 模型再次犯错误
- 人类再次斥责
最可能的后续是…… 再次犯错误。
不良轨迹会强化失败模式。
这就是为什么重新启动会话或压缩上下文往往比持续纠正更有效。
有意压缩
有意压缩 是将上下文有意识地压缩为最小、信号强度高的表示。与其让对话不断增长，你可以：
- 将当前状态总结为 markdown 文档
- 以人为视角审阅并验证
- 使用该文档作为种子，开启全新上下文
需要压缩的内容
- 相关文件及行范围
- 已验证的架构行为
- 已做出的决策
- 明确的约束和非目标
不需要压缩的内容
- 原始日志
- 工具追踪
- 完整文件内容
- 重复的错误说明
压缩将探索转化为一次性成本，而非持续的开销。
子代理关注的是上下文，而非角色
子代理经常被误解。它们不是用于镜像人类角色，如“frontend agent”或“QA agent”。
它们的作用是：
- 分叉一个干净的上下文窗口
- 执行大规模的探索性读取
- 向父代理返回简洁的事实摘要
示例
-
子代理扫描大型代码库
-
返回：
“相关逻辑位于
foo/bar.ts:120–340，入口点是BazHandler”
父代理随后只读取重要的部分。这就是在不进入“笨区”的情况下扩展上下文的方式。
研究–计划–实施 工作流
此工作流并非“规范驱动开发”。该术语已出现语义扩散。
RPI 关注 在每个阶段进行系统化压缩。
研究：压缩真相
目标
- 了解系统 实际 的工作方式
- 确认权威文件和流程
- 消除假设
特征
- 阅读代码，而非文档
- 产出简短的研究成果
- 手动验证发现
如果代理没有准确的上下文进行入职，它们会捏造信息。这类似于 Memento：没有记忆，代理会编造叙事。
计划：压缩意图
计划是 最高杠杆的活动。
一个好的计划：
- 列出精确的步骤
- 引用具体的文件和代码片段
- 指定每次更改后的验证方式
- 明确失败模式
一个扎实的计划可以显著约束代理行为。糟糕的计划会产生数十行错误代码；糟糕的研究会产生数百行错误代码。
实施：机械执行
一旦计划正确：
- 执行变得机械化
- 上下文保持简小
- 可靠性提升
这正是令牌消耗真正产生价值的地方。
心智对齐与代码审查
代码审查主要是关于 共享理解，而不是语法。
随着 AI 输出规模的扩大，审查成千上万行代码变得不可持续。
高绩效团队
- 审查研究和计划
- 将代理对话记录或 AMP 线程附加到 PR 中
- 展示精确的步骤和测试结果
审查计划可以在吞吐量提升时保持架构的一致性。
限制：AI 并不能取代思考
AI 放大了已经完成的思考质量。在深度架构重构或具有隐藏不变式的遗留系统等情况下，团队必须首先回到人工设计。
- 没有完美的提示。
- 没有灵丹妙药。
- 思考无法外包。
选择合适的上下文工程层级
| 任务类型 | 推荐方法 |
|---|---|
| UI 调整 | 直接指令 |
| 小功能 | 轻量计划 |
| 跨仓库更改 | Research + plan |
| 深度重构 | Full RPI + human design |
问题难度的上限随上下文纪律的提升而上升。
接下来会怎样
编码代理将会商品化。
真正的挑战在于适应：
- 团队工作流
- 软件开发生命周期（SDLC）流程
- 文化规范
如果不这样做，团队将面临：
- 初级成员交付低质量代码
- 高级成员进行清理
- 随着 AI 使用的增加，技术债务也会同步增长
这是一 工作流和领导力问题，而非单纯的技术问题。
关键要点
- 上下文是唯一重要的杠杆
- 更多的 token 往往会降低正确性
- 有意的压缩是强制性的
- 研究和规划是最高回报的活动
- AI 放大思考——它并不取代思考
来源与致谢
本文是对所引用演讲的忠实技术改编。
所有想法、术语和框架均来源于所引用的演讲。