http://www.heyuan110.com/zh/tags/ai-coding-agents/Recent content in AI Coding Agents on Bruce AI 工程笔记HugozhTue, 16 Jun 2026 11:00:00 +0800http://www.heyuan110.com/zh/posts/ai/2026-06-16-context-engineering-2026/Tue, 16 Jun 2026 11:00:00 +0800http://www.heyuan110.com/zh/posts/ai/2026-06-16-context-engineering-2026/<p><img src="http://www.heyuan110.com/posts/ai/2026-06-16-context-engineering-2026/cover.webp" alt="面向编码 Agent 的上下文工程 2026：把上下文窗口当预算管理" loading="lazy" decoding="async" fetchpriority="low" width="1200" height="630" /> </p> <p>关于 2026 年的编码 Agent，有一个不太舒服的事实：模型很少是瓶颈。决定 Claude Code、Codex 或 Cursor 能否干净地完成一次跨文件重构、还是空转一小时的，是你摆在它面前的东西。Anthropic 2026 年的 Agentic Coding 报告把上下文工程称为「2026 年的承重技能」，数据也支持这个说法——维护良好上下文文件的团队，出错率低 40%，任务完成速度快 55%。</p> <p>今年早些时候我写过一篇<a href="http://www.heyuan110.com/zh/posts/ai/2026-02-24-context-engineering-deep-dive/">偏理论的上下文工程深潜</a>，讲的是失效模式和「Specs 是新的源代码」这套论证。这篇正好相反：它是给真正在跑编码 Agent 的人准备的 2026 实战手册——哪些技巧真有效、有什么数据佐证、哪些流行做法其实是让 Agent 悄悄变差的伪工作。我的核心主张很简单：<strong>别再把上下文窗口当成一个要装满的桶，把它当成一份要花的预算。</strong></p> <h2 id="2026-年的上下文工程从写文档到管预算">2026 年的上下文工程：从写文档到管预算<a href="#2026-%e5%b9%b4%e7%9a%84%e4%b8%8a%e4%b8%8b%e6%96%87%e5%b7%a5%e7%a8%8b%e4%bb%8e%e5%86%99%e6%96%87%e6%a1%a3%e5%88%b0%e7%ae%a1%e9%a2%84%e7%ae%97" class="anchor" aria-hidden="true"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path d="M15 7h3a5 5 0 0 1 5 5 5 5 0 0 1-5 5h-3m-6 0H6a5 5 0 0 1-5-5 5 5 0 0 1 5-5h3"></path> <line x1="8" y1="12" x2="16" y2="12"></line> </svg></a></h2> <p>两年前，「上下文工程」大体就是写好文档、写个像样的系统提示词。这个理解现在已经危险地不完整了。2026 年最关键的变化是：编码 Agent 跑得<em>很长</em>。一次 Claude Code 会话可以在七个小时里啃完一个 1250 万行的代码库，调用工具几百次。在这样的循环里，上下文窗口不是你一次性准备好的简报——它是一份会不断被填满、会退化、必须一轮一轮主动管理的实时资源。</p>