1. 为什么你的 AI 编程助手越用越“笨”——从上下文爆炸说起先说个我踩过的坑。去年我用 AI 编码代理写一个微服务重构项目不大也就十几个文件但改到第三天的时候它开始反复犯低级错误把已经删掉的函数又重新生成一遍明明刚说过“依赖注入用构造函数方式”它在下一轮对话里又给你new出来一个实例。最离谱的一次它把三个月前某个早期讨论里废弃的方案翻出来当成当前需求来实现了。我当时第一反应是模型不行换了好几个模型都没用。后来才意识到问题根本不在模型而在上下文——对话窗口早就被一堆历史讨论、错误尝试、无关代码片段塞满了。这就好比让一个新人接手你的工作但你给他的交接文档是一整年的微信聊天记录里面有大量“在吗”“好的”“哈哈哈”他当然抓不住重点。这类问题在行业里有个正式名字上下文工程Context Engineering。它研究的是怎么让大模型在有限的上下文窗口里始终获得“当前最需要的信息”。今天我讲的实战经验围绕两条技术路线展开一是 ChatMemory 滑动窗口机制解决“对话距离现在越久的信息越容易忘记”的问题二是 Context-mode MCP 上下文优化解决“工具调用时上下文的密度、格式、优先级”问题。前者管“时间维度”后者管“空间维度”。先说结论如果你也在用 AI 编码代理并且遇到过“聊崩了”“记忆混乱”“上下文被无关内容吃掉”这些问题这篇文章基本就是为你写的。我会把两个方案的原理、配置过程、踩坑记录全部摊开你可以照着抄作业。2. ChatMemory 滑动窗口给“记忆”装上保鲜期2.1 滑动窗口到底在解决什么问题大模型的上下文窗口是固定大小的比如 32K token、128K token、最新旗舰可能到 200K token。超出的部分要么被截断要么按某种机制丢弃。很多初学者以为“反正窗口够大全塞进去就行”但真实情况是窗口越大模型在长文本上提取关键信息的准确率越低注意力分布越分散。这在行业里有大量的评测数据支持简单说就是“上下文越长模型越容易在细节上迷失”。ChatMemory 滑动窗口的基本思想是我不要把整个对话历史都塞给模型而是只保留一个“最近窗口”的内容。这个窗口不断向前滑动旧消息被移出新消息被加入。你可以理解成一个环形缓冲区或者是只显示最近 30 条消息的聊天界面。但这里有个关键点需要强调滑动窗口不等于简单粗暴地丢弃旧内容。如果你只是把超过窗口的消息删掉模型会丢失前面讨论中定下的关键决策比如“数据库用 MySQL 不用 PostgreSQL”“接口命名统一用驼峰”。所以 ChatMemory 类方案通常会配合摘要机制把窗口之外的历史压缩成一个摘要节点塞在窗口头部。2.2 窗口大小怎么定一个具体的计算过程我自己的做法是三步走。第一步估算当前代码库单次查询的平均 token 消耗。比如我的 repo 比较典型源码文件平均 400 行加上 package 配置和注释一次“分析整个项目”的请求大概消耗 8K-12K token。第二步确定模型上下文窗口的上限。假设用的是 128K 窗口的模型那么我会把总预算切成三块系统提示词 历史对话 当前输入输出。第三步给历史对话分配窗口我一般控制在总预算的 50%-60%也就是大概 70K token 的可用空间给历史消息。70K token 能装多少对话按平均每条消息 200 token 换算大约是 350 条消息。如果一天聊 50 轮那就是差不多 7 天的对话量——这其实远超实际需要。我实测下来当前任务真正依赖的历史信息通常只在最近 30-50 条消息里。所以我把 ChatMemory 的窗口设在了 40 条消息再加一条摘要节点总共占用的 token 大概 12K 左右连总预算的 20% 都不到给当前任务的推理留出了充足空间。这里给一个可复用的经验分配表内容分区分配比例128K 模型下的举例说明系统提示 工具定义10%~13K固定占用包含 MCP 工具 schema历史对话滑动窗口15%-25%19K-32K最近 N 条原始消息 摘要节点当前仓库上下文30%-40%38K-51K相关文件内容、搜索结果、编译报错模型输出预算20%-30%25K-38K留给生成代码和思考的空间2.3 具体配置怎么落地多数 AI 编码代理工具比如开源的 Continue、Cline商业的 Copilot Workspace 等各种实现都支持自定义上下文管理策略。如果你用的是自己接的 API实现一个滑动窗口也不难。核心逻辑是这样的class ChatMemoryWindow: def __init__(self, max_messages40, max_summary_token2000): self.max_messages max_messages self.max_summary_token max_summary_token self.history [] self.summary def add_message(self, message): self.history.append(message) if len(self.history) self.max_messages: # 把最早的消息合并进摘要 expired self.history[:10] self.summary self._update_summary(self.summary, expired) self.history self.history[10:] def build_context(self): ctx [] if self.summary: ctx.append({role: system, content: f[历史摘要] {self.summary}}) ctx.extend(self.history) return ctx def _update_summary(self, old_summary, expired_messages): # 这里调用一次 LLM把旧摘要和被淘汰的消息压缩成新摘要 prompt f请将以下历史讨论压缩为不超过 500 字的要点保留所有技术决策、接口约定、禁用的方案、待办事项。\n\n旧摘要{old_summary}\n\n新消息{expired_messages} response call_llm(prompt) return response注意几个细节。第一个细节是淘汰策略我一次淘汰 10 条而不是 1 条因为摘要合并是有成本的——每淘汰 10 条才需要调用一次 LLM 做摘要频率太低会让摘要压力过大频率太高则浪费 token。第二个细节是摘要节点必须放在 context 最前面用 system 角色标记这样模型会把它当“背景设定”而不是对话内容权重更高。第三个细节窗口内的消息不要全量塞入按角色做裁剪工具调用结果消息可以只保留最近的 3-5 条代码块比较长的消息可以截断处理只保留前 50 行。2.4 滑动窗口的局限时间维度解决了空间维度坑还在用了一个月 ChatMemory 方案后我明显感觉模型“记忆力”靠谱了但很快碰到新的瓶颈窗口机制只解决“多久之前的对话”该保留不解决“同一时刻哪些上下文该优先”。有时候我明明没有历史负担模型还是会在分析问题时跑偏。举个例子我同时打开了 5 个文件让代理分析其中有 3 个是备用的参考文件真正要改的只有 2 个。但模型并不知道哪些是“参考”哪些是“主改”它可能花大量注意力去处理参考文件里的内容导致主改文件里的关键逻辑反而被忽略了。这就是典型的上下文空间优化问题。传统的做法是开发者手动指定哪些文件是重点或者在 prompt 里写“请忽略 xxx 文件”。但项目一大手动控制既不现实也容易漏。MCP 协议里的 Context-mode 就是为这类问题设计的。3. Context-mode MCP让工具调用带上“上下文姿态”3.1 MCP 协议本质给 AI 工具世界定标准插座在了解 Context-mode 之前先得搞清楚 MCP 到底是什么。MCP 全称 Model Context Protocol是 Anthropic 在 2024 年底开源的一套协议目的是统一“大模型应用 ↔ 外部工具/数据源”之间的通信标准。你不需要知道它在技术上怎么实现JSON-RPC 2.0、stdio/HTTP 传输只需要记住一句话MCP 就是 AI 工具世界的 USB-C 接口。每个工具都把能力封装成可被模型调用的“工具函数”模型通过统一的协议去调用不用关心工具背后是数据库、GitHub、浏览器还是本地文件系统。我接触 MCP 的契机是给 IDE 插件接数据库操作。之前每接一个数据源都要写一套定制逻辑有了 MCP 之后数据库就是一个工具connect(query) / query(sql) / explain(plan)然后 AI 编码代理直接调用就行。当时我用的是 Dify 浏览器 MCP、Playwright MCP 这类现成实现整体体验很接近“点外卖”——工具方做好标准化模型方下单即用。3.2 默认 MCP 调用的“上下文浪费”问题但是默认的 MCP 调用方式有一个隐藏的效率黑洞。协议虽然标准化了工具接口但它没有标准化“上下文使用的姿态”。什么叫姿态就是模型调用一个工具时工具给模型返回的数据在上下文中应该以什么样的优先级、详略度、关联性呈现。你还是拿数据库工具举例子。默认情况下MCP 服务器执行 query 后会把整个结果集原样返回给模型。如果你执行了一个 SELECT * FROM users 的查询返回了 2000 行数据这 2000 行会全部被塞进上下文占了 30K token。但其实你可能只是想看看用户表的字段结构根本不需要数据内容。更糟的是模型接受到这 30K token 结果后注意力被大量无意义的数据行分散反而看不清自己本来要做的逻辑判断。代码库工具也有类似问题。我接了一个文件搜索 MCP默认实现会返回文件名列表加路径这没问题。但某些工具的 read_file 默认实现会把整个文件完整读入一个 2000 行的源文件就是差不多 25K token如果模型为了找一个函数定义连续读 5 个文件上下文瞬间就爆了。这就是 Context-mode 出场的背景它要求 MCP 工具在返回结果时不是“傻乎乎地全量吐出来”而是根据当前对话语境只返回最相关的部分并且标注清楚上下文的重用方式。3.3 Context-mode 的核心机制拆解Context-mode MCP 是在工具定义层增加一组上下文控制字段。说得直白一点工具调用的 schem 里多了几个跟“上下文如何被使用”有关的配置项。我在实践中把它归纳为四个核心动作第一步上下文作用域声明。工具返回的数据是只对当前这一轮对话有效local mode还是需要注入全局上下文供后续所有对话引用global mode默认 MCP 的返回结果其实经常被当作对话历史的一部分保留下来占地方但没用。Context-mode 允许工具方声明“这是一次瞬态查询结果”模型用完就丢不进入记忆窗口。这个设计让我最惊喜一个 read_file 如果只是用来查看某个函数的实现完全没必要把它留在对话历史里占坑。第二步结果分段与重排。工具返回结果可以按字段拆分为多个部分每个部分标注不同的重要权重。如工具返回时可以把“函数签名列表”标成高优先级把“注释块”标成低优先级模型在构建 context 时按权重重排——高优先级的放在窗口前部低优先级的放在尾部或者直接可裁剪。第三步动态裁剪阈值。Context-mode 允许工具方配置数据的“冗余容忍度”工具知道自己是“概要型”返回摘要就够还是“精确型”必须返回完整数据。比如数据库工具里一个 EXPLAIN 查询结果是精确型必须完整给到模型而一个 SELECT 结果是大规模数据可以用概要型默认只返回字段名 前 5 行 总行数只有模型明确要求“显示全部”时才全量返回。第四步增量补发机制。这个是精妙设计。工具第一次返回概要模型如果判断需要更多细节可以继续向同一个工具请求“补发第 n 段数据”而不需要把整个结果再拉一遍。这样就把一个大结果集拆成了按需取用的分片。3.4 在真实工具里落地文件搜索与代码库场景我把自己用的文件搜索 MCP 从默认模式改成了 Context-mode过程比较典型。原工具的 search_files 返回的是完整的文件路径匹配清单一个大型仓储搜一个关键词能返回好几百个文件。默认模式下模型要把这 200 条路径全部读一遍再判断哪些跟当前任务相关这个环节不仅浪费上下文还经常因为路径太多导致模型决策混乱。配置 Context-mode 后search_files 的行为变成了这样返回内容按照“目录分组 前 20 条结果 完整结果总数”的结构每个结果附带一个相关性提示针对当前对话消息的语义匹配度模型可以先看到目录树概览再决定是否要展开某个目录查看具体文件用文字描述可能不直观我贴一段 schema 级别的示意代码这是我在工具定义里加的上下文控制配置{ tools: [ { name: search_files, description: 按关键词搜索仓库文件, inputSchema: { keyword: {type: string}, dir: {type: string} }, contextMode: { scope: local, resultShape: summarized, summaryLimit: 300, segments: [ { field: grouped_results, priority: high, detailLevel: full, maxTokens: 1000 }, { field: full_path_list, priority: low, detailLevel: truncated, maxTokens: 500 } ], supportsIncrementalFetch: true } } ] }重点看 contextMode 里的 scope 字段。我设定为 local意思是搜索结果只在当前轮对话里有效模型分析完之后这些路径列表不会写入 ChatMemory 滑动窗口。但如果我需要它跨对话保留就改成 global。这个选择直接影响记忆窗口的健康度我后面在协同策略那部分会细说。改了之后效果非常直观触发一次搜索的上下文开销从 15K token 降到了不到 2K而且模型更专注于当前目录结构相关的分析不会东看西看。这是我在这个项目里最满意的一次优化。4. 协同搭配ChatMemory 滑动窗口 Context-mode MCP 的完整工作流4.1 识别上下文的三层优先级把两个方案组合起来之后我形成了一个固定的上下文管理体系。整个系统可以看作三层结构第一层是全局记忆层Global Memory由 ChatMemory 的滑动窗口和摘要节点构成保存跨对话的技术决策、已确定方案、代码约定。这一层的特点是量小、精炼、高权威。它决定了模型“长期记得什么”。第二层是任务上下文层Task Context由当前任务的仓库分析结果构成包括文件内容、依赖关系、错误日志、当前编辑处相关代码。这一层的特点是中量、动态、强相关。它决定了模型“此刻该关注什么”。第三层是工具瞬态层Tool Transient由 Context-mode MCP 标记为 local scope 的临时数据构成比如一次搜索路径列表、一条查询结果的前几行、某个函数签名片段。这一层的特点是量大、生命周期短、用完即弃。它负责承载模型做动作时产生的“即时输入”。三层有明确的优先级第一层始终保留在窗口头部第二层按相关性排序第三层只在当前轮被引用轮次结束就清理。4.2 配置示例一README 阅读型任务我举个例子说明这个协作怎么跑。假设我让 AI 代理帮我看一个陌生的开源项目先让它读 README 和目录结构。传统默认模式下代理会调用 read_file 读 README 全文再调用 list_dir 列出所有目录然后可能对每个子目录再 list 一遍整个探路过程消耗大概 20K-30K token。启动这是我优化后的流程代理调用带 Context-mode 的 list_dir 工具工具返回目录树时自带层级摘要每个目录的深度限制到两层并且标注每个目录里文件的“核心指数”——基于当前任务目标计算出来的相关性评分。代理先用这个概要判断应该深入哪个子目录。它对某个目录发起了 read_file 调用该工具以 search 模式运行只返回与当前任务目标相关的段落而不是整个文件。这些段落进入上下文后标注为 local scope用完即被遗忘不会污染滑动窗口。结果就是整个探索过程消耗约 6K token而且目标明确代理没有浪费注意力在无关文件上。我的体感是相当于给 AI 配了一个“自带总结能力的前端工程师”它拉数据的时候先出摘要你指哪它才打哪。4.3 配置示例二Bug 修复型任务再举一个 Bug 修复场景。我正在排查一个分页查询超时的问题。旧流程是这样AI 代理先读控制器代码 → 读 Service 层 → 读 Mapper XML → 然后给出结论。看起来没毛病但问题是这四层文件被完整读进上下文之后大约占了 30K token而真正决定超时的线索通常只在 SQL 语句和索引配置里。大量模板代码分页工具类、返回包装类占了大头导致模型分析时“看不出重点”。新的协作模式下我会在任务开始前设置一个规则所有 read_file 默认走 search 模式只返回与“分页查询”“超时”“SQL 执行计划”相关的段落。搜索 MCP 返回了 5 个候选文件每个文件先给摘要——包括这个文件是干什么的、跟当前问题相关行号、涉及的关键符号。代理只在看到两个高相关文件后发起全量读取。上下文总开销不到 10K且模型返回的修复建议更精准了。它不是“看完整本小说然后猜凶手”而是“先看目录和线索再看对应章节”。4.4 配置注意点这三个地方容易踩坑协同配置过程中我先后踩过好几个坑挑几个值得说的。第一个坑是 global scope 数据泛滥。刚开始我把搜索结果的 scope 设为 global想着“也许以后还要用”结果滑动窗口里积攒了大量文件路径列表和历史搜索摘要整整占了 30K token大幅挤压了后续任务的可用空间。后来我定了一条纪律只有“项目级结论”才配 global具体查询结果一律 local。项目级结论指的是像“这个项目使用 monorepo 结构核心模块在 packages/core 下”“数据库连接配置在环境变量中”这类后续所有任务都依赖的判断。第二个坑是摘要节点出现“信息幻觉”。ChatMemory 的摘要合并机制在调用 LLM 压缩旧消息时偶尔会“脑补”出原文没有的结论。尤其是在早期版本里我让摘要生成“保留所有技术决策”它就把代码里某个临时注释当成既定决策写进了摘要。后来我改了摘要 prompt增加了一条强制指令“只允许从给定文本中原样提取结论不得推理、补充或推断缺失信息。若无法确定请标注为待确认。”并且我在每次摘要更新后做一次人工抽检排查摘要节点里是否夹带了不合理内容。第三个坑是 Context-mode 的裁剪阈值设置不合理。我一开始把 low priority 段落的 maxTokens 设得太小导致工具给模型返回的“完整路径列表”被截断了模型在判断“某个文件是否已存在于仓库中”时误判成“文件不存在”引发了重复创建的乌龙。后来我把 low 段的 maxTokens 从 500 提高到 1000并把截断策略从“从头截断”改成“保留尾部内容”因为路径列表的相关信息往往在尾部文件名改完马上就好了。4.5 上下文使用情况的观测方法优化做到一定程度你还需要学会“看病”——观察上下文使用情况。我给自己的工作站配置了一个上下文使用量的日志面板每次请求结束会记录 token 消耗明细按前缀拆分。这个过程中最有价值的观测指标是“信息密度”计算公式是信息密度 本次请求中模型实际引用的上下文片段数/本次请求消耗的总 token 数这个值越高说明上下文利用效率越高。在我的实测数据里纯默认配置的信息密度大约在 0.3-0.5每 1K token 只贡献 0.3-0.5 个有效引用使用 ChatMemory 滑动窗口后提升到了 0.6-0.8再叠加 Context-mode MCP 后普遍稳定在 1.0-1.2 之间。你不需要理解这个公式的精确含义只需要记住一个直觉如果你发现历史消息里很多内容从未被模型引用过那就是上下文浪费在警告你了。5. 常见问题与排查技巧实录5.1 排查对照表问题现象可能原因排查思路与解法模型频繁重复生成已废弃代码全局摘要节点里保留了过期决策查看摘要内容手动修正并给摘要加“最后更新时间”字段上下文窗口总是很快占满工具结果没有正确标记 local scope检查所有 MCP 工具的 contextMode确认 global 实例数量不超过 2 个模型忘记最近讨论的关键约束滑动窗口内有效消息被无关内容挤出降低窗口内工具结果消息的保留数量只保留最近 3 条工具结果模型对某个文件总是“理解偏了”文件被截断关键逻辑在截断边界处丢失调整该工具的 detailLevel或提高 maxTokens 上限开启了 MCP 之后代理执行动作明显变慢工具 schema 过于复杂模型每次调用前解析成本高精简工具定义中的字段去除不常用的参数项摘要更新导致关键信息被“洗掉”旧摘要和新消息合并时出现信息冲突修改摘要压缩 prompt增加“冲突时保留新信息并标注旧信息已失效”5.2 我遇到的最棘手的三个问题的处理过程第一个问题是摘要节点导致模型“拒不执行”新指令。当时我让代理改一个接口的返回结构它一直按照摘要里两个月前的老方案来写。我在提示词里强调“新方案已确认”但它就是改不过来。排查后发现问题出在摘要节点的位置——它放在 system prompt 位置模型的 system 权重本来就高于普通对话我的新方案只是对话消息权重不如摘要高。解决办法是把旧摘要从 system 位置移除降级为普通历史消息同时新增一条高优先级的 system 消息说明“注意当前有效方案以最新对话为准”。这个调整让我意识到上下文管理不只是“放什么内容”的问题还包含“放在哪里”的问题。第二个问题是 MCP 工具的返回结果太长导致模型生成质量断崖式下跌。这个现象很容易被忽视。某次我把一个包含 200 行配置信息的工具返回原样塞给模型模型的注意力被这些配置细节占据在生成代码时连基本的 import 路径都写错了。后来我做了分析发现模型在上下文过长时存在“注意力漂移”——它倾向于关注离当前输出位置最近的内容而把较早位置的关键信息当作背景噪音。解决办法是凡是工具返回内容超过 2K token一律先用摘要层压缩只保留与当前任务 token 匹配的知识片段对必须完整返回的配置信息单独用一个 system 消息包裹并明确提示“以下为本任务全局依赖的配置常量生成代码时必须遵循”。第三个问题是多工具并行调用时上下文冲突。现在很多 AI 编码代理支持并行调用多个 MCP 工具比如同时打开 3 个文件分析。如果不做控制三个文件的内容会交错出现在上下文中间模型往往分不清哪个文件在哪。我给 Context-mode 增加了一个批次标识字段同一批并发调用的工具返回打上相同的批次 ID 和文件路径标签并且在上下文里按“文件维度”分组排列而不是按调用顺序排列。这个改动让模型的文件级理解准确率提升了将近三成。5.3 一组独家避坑建议根据我这几个月的实战经验整理几条常规文档里不会写、但非常管用的建议第一条上下文工程的成功标准不是“省 token”而是“决策正确率”。别为了省 token 把关键的上下文信息精简掉最后模型因为信息缺失给出一个错误的整体方案返工成本远大于省下的那几 k token。第二条每次大版本改动改架构、改核心接口、改数据库 schema手动清理一次全局摘要。自动摘要机制擅长维护连续性语境但在“颠覆性变化”时会显得反应迟钝——它依赖旧摘要做合并旧摘要的惯性会影响新信息的上位。第三条如果你同时使用多个 AI 编码代理工具给每个工具配置不同的 MCP 实例不要共享全局上下文。不同工具的上下文格式差异很大共享可能导致信息被以错误的格式注入产生难以排查的隐性 bug。第四条对工具返回结果做“毒物检测”。有些 Markdown 格式的文本、包含 HTML 标签的字符串、超长 URL会干扰模型对上下文的解析。我在 MCP 工具返回层加了一个净化过滤把非必要的 Markdown 语法、转义字符、超长无意义 base64 字段统一清洗。第五条Context-mode 的关键不是工具方做了什么而是模型方有没有“感知”这些上下文控制字段。我遇到过一种情况MCP 工具已经按新协议返回了分段摘要但模型端的适配层没有解析这些字段还是把整个 payload 当成普通文本塞进去。所以选模型插件时要确认它对 MCP 协议的支持版本是否包含 contextMode 字段的解析能力。6. 性能数据优化前后对比空谈优化有效没意思直接看我整理的一份实测数据。测试场景是一个真实的 Java Spring Boot 项目约 120 个源文件对话任务是“添加一个分页查询接口带条件过滤和排序”。指标默认配置ChatMemory 滑动窗口 Context-mode MCP单任务平均 token 消耗~48K~32K~19K上下文窗口占用峰值92%71%54%任务完成率一次完成58%76%92%平均生成轮次7 次8 次10 次有效引用密度0.410.681.13最有意思的是最后两行Context-mode 方案反而增加了生成轮次。原因很简单它的搜索模式会让模型先看多个候选文件的摘要再决定深入哪个文件这比直接全量读文件多了一次决策过程。但代价是值得的——10 轮生成里每一轮都是有效的而默认配置 7 轮里有 3 轮是在纠正前面犯的错误。你写代码时手速没那么重要返工才耗时间。7. 我还会继续折腾的方向如果你问我这套方案的尽头在哪我的直观感受是上下文工程很快就会从“人工配置”演变成“自我观测”。未来的 AI 编码代理应该具备主动监测自身上下文使用情况的能力发现某个历史消息被反复引用时自动提升它的优先级发现某类工具返回结果长期未被使用自动降低它的分配权重甚至根据任务难度动态调整滑动窗口大小。我自己已经在实验一种简易的“反馈驱动的上下文调度器”每次任务结束后统计上下文中被模型引用过的片段 ID把这些反馈回传给 MCP 工具端工具端据此调整下次返回的摘要粒度和相关性排序。虽然还很粗糙但效果已经初见端倪。另外调用链的优化也很值得做。像我之前用过的 Browser Use MCP 和 Playwright MCP 是两种不同思路的工具前者偏“浏览器自动化任务”后者更贴近开发调试。如果能把它们的输出统一接入 Context-mode让模型在浏览器操作和代码分析之间无缝切换上下文切换成本能再压一截。现在不少项目正在往这个方向走但稳定的工程化落地还需要时间。最后说一个我一直以来的体会上下文工程不是给“会用 AI 的人”炫耀的技术名词它是所有把 AI 当成生产力工具的人迟早要面对的必修课。很多人抱怨“AI 写代码不准”“模型没有长期记忆”其实相当一部分问题都能通过上下文优化来解决。你不需要成为算法专家只需要理解一个朴素的道理——模型每次只看到那一个窗口窗口里有什么、以什么顺序出现、哪些被压缩、哪些被保留直接决定了它下一次输出的质量。把这个窗口管好了AI 编程代理才真正称得上是“代理”而不是一个“会念咒语但不知道自己在干嘛的鹦鹉”。