理柴德波浪技术过去小半年，我花了很多时间在 AI 编程工具上，从最初的代码补全、单轮问答，到后来尝试把整个项目交给模型去重构。说实话，最让我头疼的从来不是模型写不出代码，而是它“管不住上下文”。项目一大，它就开始选择性失忆：前面刚确认过的设计约束，聊到第三轮就忘得干干净净；让它改一个函数，它顺手把旁边那个无关的配置也“优化”了。这些问题的根源往往不在模型能力，而在上下文管理。
最近一段时间，我开始尝试一种新的协作方式：把主模型拆成一个主代理和多个 Subagents，让不同角色各管一段上下文，配合“按需加载”的思路，情况一下子好了很多。这篇内容就从上下文管理这个硬瓶颈说起，聊聊我踩过哪些坑、总结出哪些实践，以及为什么 Subagents 协作架构会成为 AI Coding 下一个阶段的重点。
1. 上下文管理：AI 编程真正的硬瓶颈
1.1 上下文窗口再大，也装不下一个真实项目
很多人觉得，模型上下文窗口从几万 token 涨到几十万、上百万 token，问题就解决了。实际上完全不是这么回事。一个稍具规模的后端服务，光核心业务模块就有十几万行代码，如果再加上配置文件、数据库表结构、依赖清单、测试用例，总量轻易超过千万 token。哪怕窗口再翻几倍，也不可能把一个完整项目的所有细节都塞进去。
就算真的塞得进去，效果也不会好。上下文里塞了太多无关信息，模型在生成时会不断被干扰，注意力被均匀地打散到各个角落，最后该关注的核心逻辑反而没有被充分“看见”。我见过一个很典型的例子：让模型去修复一个订单超时问题，把整个服务端代码都喂给它，它折腾了半天，最后把错误定位在了一个根本不相干的缓存清理逻辑上，浪费了时间还引入了新 bug。
所以，上下文管理的第一课不是“装得下”，而是“装得准”。上下文窗口是珍贵资源，怎么让有限的 token 装下最有价值的信息，才是 AI Coding 工程化的核心问题。
1.2 代码的世界是张网，但模型的上下文是一条线
代码库本质上是一个高维信息网络：函数调用关系、继承体系、消息队列上下游、数据库外键关联……信息之间通过引用和依赖互相连接。可模型的上下文却是一条线性 token 流，它读代码的方式就像一个人顺着目录一页页翻书，只能看到眼前的文字，无法像人那样“跳着看”“回头看”。
最直接的后果是，模型对“隐式关联”的感知非常弱。比如你让它修改一个状态机的流转逻辑，它需要知道这个状态机被哪些入口触发、哪些状态迁移存在并发风险，这些信息分散在不同文件甚至不同服务里。如果上下文准备不充分，模型就只能根据手头这几段代码自行脑补，补出来的东西自然不靠谱。
这个问题不是靠“让模型更聪明”就能解决的，而是要靠工程手段去改变信息的供给方式：把代码网拆成一条条可消费的“知识片段”，再按任务意图组装成适合模型的上下文序列。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 我的上下文管理实践：不靠硬塞，靠分层组装
2.1 三层信息漏斗策略
跟 AI 协作的第一步，就是改变喂信息的习惯。我总结了一套“三层漏斗”的上下文组织方式，简单来说就是只给模型“刚好够用”的信息，而不是“尽可能多”的信息。
第一层是任务目标，用两三句话说明要做什么、验收标准是什么；第二层是相关代码摘要，把涉及模块的关键结构、核心函数职责浓缩成一段文字描述；第三层是精确代码片段，只放跟当前改动真正相关的函数实现、接口定义和关键调用点。
比如说让模型排查一个支付回调重复通知的问题。我不会把整个支付模块都丢给它，而是先说明“支付回调成功后会更新订单状态，