Agent 的上下文窗口不够用怎么办？

先这样答

上下文不够时，第一反应不该是「找更长窗口的模型」，而是先做上下文工程：多数 Agent 的上下文是被工具结果和无筛选的历史撑爆的，这些内容大部分和当前决策无关。

具体四个手法，按实施顺序讲。

裁剪：保留系统提示、任务目标、最近几轮完整轨迹，更早的轮次只保留动作和结论、丢弃冗长的工具输出。这是最便宜的一步，很多场景只靠这一步就够。

压缩：把要长期保留的大块内容摘要化，比如把几十轮的排查过程压成一段「已确认的事实和排除的方向」，替换原文进上下文。摘要要结构化（事实/结论/待办），纯段落摘要会丢关键细节。

外置：状态不放上下文里，放外部存储。任务清单、检索结果、中间产出写成文件或数据库记录，上下文里只留引用和摘要，需要时再取。现在流行的做法是让 Agent 自己维护一份任务清单文件，每轮只读这份清单来恢复进度。

分流：一个大任务拆成几个子任务，每个子任务开独立的干净上下文跑，只把结论汇总回主任务。子 Agent 的价值主要就在这里：每个子任务拿到干净的上下文，而不是人多力量大。

面试官会怎么追问

• 压缩会不会丢掉关键信息？ 会，所以压缩要按任务类型定制保留项：排查类保留「已排除项」，写作类保留风格要求和素材引用。压缩后建议跑一遍评测集验证。
• 长上下文模型（百万 token 级）能不能直接解决问题？ 缓解不解决：长上下文中间信息的利用率会下降、成本和延迟线性涨、噪音多了指令遵从也会变差。窗口大是给了你更多腾挪空间，不是让你什么都往里塞。
• 工具结果怎么减负？ 设计工具时就分层：先返回摘要和字段，模型需要明细再翻页拉全量；把「返回 500 行 JSON」改成「返回前 20 行 + 总数 + 查询参数」。

回答的坑

• 只答「换长窗口模型」。工程手段优先于堆窗口，答出这一层，面试官才会相信你真的维护过系统。
• 没提「让 Agent 自管状态」。任务清单外置是这两年很主流的做法，提出来很加分。