Context Mode 重构 AI 编码代理：MCP 与 SQLite 实现上下文精准管理-育师

1. 为什么"上下文"成了 AI 编码代理最贵的资源

先抛一个我自己的实测数据。前阵子我在一个中型 TypeScript 项目里跑一个编码代理，让它连续完成"读需求 → 定位文件 → 改代码 → 跑测试 → 修报错"这一整条链路。单次任务平均要消耗 6 到 9 万 token 的上下文，其中真正被写进最终代码的"有效信息"不到 8%。剩下的 92% 是什么？是重复读取的文件内容、被截断的日志、来回确认的对话历史、以及代理自己"忘了又重读"的循环。

这就是 Context Mode 想解决的核心问题：AI 编码代理的上下文不是不够用，而是被浪费得太厉害。

传统做法是把所有东西一股脑塞进对话窗口——文件全文、终端输出、历史消息。窗口一满，要么截断（丢信息），要么压缩（丢精度），要么重开一轮（丢状态）。Context Mode 换了个思路：把上下文从"对话流"里抽出来，变成一个可查询、可持久化、可增量更新的外部状态。代理不再"记住"一切，而是"按需检索"。

关键词里的 MCP、SQLite 就是这套思路的两个支点。MCP（Model Context Protocol）负责让代理用标准化接口去访问外部上下文源，SQLite 负责把上下文落盘成一个轻量、可查询、可版本化的本地库。两者一结合，代理的"记忆"就从易失的对话窗口，变成了一个可以反复读写的结构化存储。

这篇文章我会拆四件事：Context Mode 到底重构了什么、MCP 在其中的角色、SQLite 作为上下文存储的工程细节、以及我在实际落地时踩过的坑和验证过的配置。适合正在做编码代理、或者被上下文窗口折磨过的开发者看。

2. Context Mode 重构的到底是什么：从"对话记忆"到"外部状态"

2.1 传统上下文管理的三个死结

要理解 Context Mode 的价值，得先看清老路子为什么走不通。我把常见问题归成三类：

第一，线性累积导致的"上下文通胀"。对话式代理的上下文是一条只增不减的线。每读一个文件、每跑一次命令，内容就追加到历史里。任务做到一半，窗口里塞满了已经没用的中间产物。我见过一个极端案例：代理为了改一个 20 行的函数，前面累积了 4 万 token 的无关文件内容，最后真正相关的上下文被挤到了窗口边缘，模型注意力直接涣散。

第二，截断与压缩的精度损失。窗口满了之后，常见策略是滑动窗口截断或者摘要压缩。截断会把早期关键约束（比如"这个字段不能为 null"）丢掉；摘要压缩则会把精确的代码片段变成模糊描述，代理据此改代码，错误率飙升。这两种都是"用信息换空间"，本质上是亏本买卖。

第三，状态无法跨会话延续。代理跑完一轮，进程一关，所有上下文归零。下次接着做，得从头再读一遍项目。对于长周期任务，这个重复成本高得离谱。

Context Mode 的破局点在于：它不把上下文当成"对话的属性"，而是当成"项目的属性"。上下文独立于任何一次对话存在，代理只是它的一个消费者。

2.2 Context Mode 的核心抽象：上下文即外部状态

用一句话概括 Context Mode 的范式转变：代理不再"携带"上下文，而是"查询"上下文。

具体来说，它把上下文拆成几个可独立管理的维度：

维度	传统对话模式	Context Mode
存储位置	对话窗口（易失）	外部存储（持久）
访问方式	全量塞入	按需检索
更新粒度	追加整段	增量写入
生命周期	单次会话	跨会话
容量上限	受窗口限制	受存储限制
精度	截断/压缩后失真	原始内容保留

这个表里最关键的一行是"访问方式"。传统模式是"我有什么就全给你看"，Context Mode 是"你要什么我就给你查什么"。前者是被动灌输，后者是主动检索。

打个比方。传统对话代理像一个记性很好但不会做笔记的人，所有事都记在脑子里，脑子一满就开始忘。Context Mode 像一个随身带笔记本的人，脑子里只放当前正在处理的那一页，需要查历史就翻笔记本。笔记本可以无限厚，脑子始终清爽。

2.3 为什么这个转变对编码场景特别重要

编码任务有个鲜明特点：信息密度极不均匀，且高度依赖精确文本。

一个项目里，真正需要代理反复查看的可能就是几个核心文件；但代理为了"理解全局"，往往会读一大堆边缘文件。这些边缘文件在传统模式下会永久占据上下文，而在 Context Mode 下，它们被存进外部库，只在真正被引用时才被拉进来。

更关键的是代码的精确性要求。摘要压缩对自然语言还行，对代码是灾难——===压成==，let压成var，一个字符的差异就是 bug。Context Mode 保留原始文本，检索出来的是什么，代理看到的就是什么，没有中间商赚差价。

我在一个重构任务里对比过两种模式：传统对话模式下，代理改完 5 个文件后开始"记混"变量名，需要人工纠正 3 次；切到 Context Mode 后，代理每次改文件前都从外部库拉取该文件的最新版本，全程零混淆。这个差异不是模型能力问题，纯粹是上下文管理方式的问题。

3. MCP 在 Context Mode 里扮演的角色：标准化的上下文出入口

3.1 MCP 是什么，为什么编码代理需要它

MCP（Model Context Protocol）是一套让模型与外部工具、数据源交互的标准化协议。你可以把它理解成"AI 世界的 USB 接口"——不管外接的是数据库、文件系统还是某个 API，只要遵循 MCP，模型就能用统一的方式去调用。

在 Context Mode 的架构里，MCP 解决的是一个很实际的问题：上下文存储和代理之间需要一个稳定的、与具体模型无关的接口。

如果没有 MCP，每个代理框架都得自己定义一套"怎么读上下文、怎么写上下文"的私有协议。换个模型、换个框架，整套对接逻辑就得重写。MCP 把这层抽象出来，存储端只需要实现一次 MCP Server，任何支持 MCP 的代理都能接进来。

这对编码代理尤其重要，因为编码场景要接的外部源特别杂：文件系统、Git 历史、终端输出、测试报告、甚至 IDE 的符号索引。MCP 让这些源都能以统一的"资源"和"工具"形式暴露给代理。

3.2 Context Mode 中 MCP 的两类核心能力

在 Context Mode 的语境下，MCP 主要提供两类能力，我分开说。

第一类是 Resources（资源读取）。代理通过 MCP 读取外部上下文，比如"读取当前项目的文件树""读取某个文件的指定行范围""读取最近一次测试的失败用例"。这类操作是只读的，目的是把外部状态拉进代理的推理过程。

第二类是 Tools（工具调用）。代理通过 MCP 执行有副作用的操作，比如"把这段上下文写入存储""更新某个文件的状态标记""触发一次增量索引"。这类操作会改变外部状态。

Context Mode 的巧妙之处在于，它把"上下文管理"本身也做成了一组 MCP 工具。代理不只是消费上下文，还能主动管理上下文——决定什么该存、什么该丢、什么该标记为"已处理"。

3.3 一个典型的 MCP 交互流程

我拿一个真实场景走一遍，方便你建立直觉。假设代理要修改user-service.ts里的一个校验逻辑：

代理先调用 MCP 工具search_context，查询"user-service 校验相关"的上下文条目。
MCP Server 在 SQLite 里做一次全文检索，返回匹配的文件片段和行号。
代理拿到片段，判断需要看完整文件，调用read_resource读取该文件。
代理修改代码，调用write_context把"已修改 user-service.ts 的校验逻辑"这条状态写回存储。
代理跑测试，测试输出通过 MCP 工具append_log写入存储，标记为"关联任务 X"。
下一轮对话时，代理不需要重新读文件，直接search_context就能拿到最新状态。

整个流程里，代理的对话窗口始终只装着"当前这一步需要的信息"，历史全部沉淀在 SQLite 里。这就是 Context Mode 的运转方式。

提示：MCP 的 Resources 和 Tools 边界要划清楚。只读的走 Resources，有副作用的走 Tools。混用会导致代理行为不可预测，比如它以为在读、实际在写。

3.4 MCP 带来的可组合性

MCP 还有个容易被忽略的好处：可组合。因为接口标准化了，你可以把多个 MCP Server 串起来用。比如一个 Server 管代码上下文（SQLite），一个 Server 管浏览器自动化（Playwright MCP），一个 Server 管数据库查询（DB Browser for SQLite 那类工具）。

代理面对的是统一的 MCP 接口，背后挂多少个数据源它不关心。这让 Context Mode 可以从小规模起步——先接一个 SQLite 上下文库——再逐步扩展，而不用推倒重来。

4. SQLite 作为上下文存储：为什么是它，怎么用

4.1 选 SQLite 而不是向量库或内存的理由

一提到"上下文存储"，很多人第一反应是向量数据库。但 Context Mode 这类场景，SQLite 往往是更务实的选择。我把理由列清楚：

理由一：编码上下文需要精确检索，不是语义检索。向量检索擅长"意思相近"，但编码场景经常需要"精确匹配"——找某个函数名、某个变量、某个文件路径。SQLite 的全文检索（FTS5）加上精确的 WHERE 条件，比向量相似度靠谱得多。

理由二：零运维、单文件、可版本化。SQLite 就是一个.db文件，不需要起服务、不需要配连接池。你可以把它放进项目目录，跟代码一起版本管理。这对本地优先的编码代理太友好了。

理由三：事务保证一致性。代理并发写入上下文时，SQLite 的事务机制能保证不写坏。向量库在这块往往要额外处理。

理由四：查询能力完整。上下文管理需要的不只是"存和取"，还有"按时间排序""按任务分组""按状态过滤""统计某类上下文的大小"。这些用 SQL 一句话搞定，用向量库得写一堆胶水代码。

当然，SQLite 不是万能的。如果上下文需要跨机器共享、或者写入量极大，那得上正经的服务端数据库。但对单机编码代理，SQLite 的性价比几乎无出其右。

4.2 上下文表结构设计

我实际用的表结构大概是这样，简化后给你参考：

-- 上下文条目主表 CREATE TABLE context_entries ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id TEXT NOT NULL, -- 关联的任务标识 entry_type TEXT NOT NULL, -- file / log / note / diff source_path TEXT, -- 文件类条目的路径 content TEXT NOT NULL, -- 原始内容，不压缩 content_hash TEXT NOT NULL, -- 内容哈希，用于去重 token_estimate INTEGER, -- 预估 token 数，用于预算控制 status TEXT DEFAULT 'active', -- active / archived / consumed created_at INTEGER NOT NULL, updated_at INTEGER NOT NULL ); -- 全文检索索引 CREATE VIRTUAL TABLE context_fts USING fts5( content, source_path, content='context_entries', content_rowid='id' ); -- 任务表，管理上下文归属 CREATE TABLE tasks ( id TEXT PRIMARY KEY, description TEXT, created_at INTEGER NOT NULL, status TEXT DEFAULT 'running' );

几个设计要点值得展开说。

content字段存原始内容，不做任何压缩。这是 Context Mode 的底线——精度不能丢。空间不够就归档，不能压缩。

content_hash用于去重。代理经常重复读取同一个文件，哈希一样就直接复用，不重复写入。我实测这一项能省掉 30% 以上的冗余存储。

token_estimate是预算控制的关键。代理在决定"要不要把这条上下文拉进窗口"时，先看它的 token 估算值，避免一次性拉太多撑爆窗口。

status字段实现上下文的生命周期管理。active是当前任务在用的，archived是历史任务留下的，consumed是已经处理完、可以安全丢弃的。

4.3 增量更新与去重逻辑

Context Mode 相比传统模式最大的工程优势，是增量更新。代理不需要每次重写整个上下文，只写变化的部分。

去重逻辑我用的是一套"哈希比对 + 版本标记"的组合：

import hashlib import sqlite3 import time def upsert_context(conn, task_id, entry_type, source_path, content): content_hash = hashlib.sha256(content.encode()).hexdigest() cur = conn.cursor() # 先查是否已存在相同内容 cur.execute( "SELECT id FROM context_entries WHERE content_hash = ? AND source_path = ?", (content_hash, source_path) ) row = cur.fetchone() if row: # 内容没变，只更新访问时间 cur.execute( "UPDATE context_entries SET updated_at = ? WHERE id = ?", (int(time.time()), row[0]) ) return row[0] # 内容变了，插入新版本 cur.execute( """INSERT INTO context_entries (task_id, entry_type, source_path, content, content_hash, token_estimate, status, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?, 'active', ?, ?)""", (task_id, entry_type, source_path, content, content_hash, len(content) // 4, int(time.time()), int(time.time())) ) return cur.lastrowid

这段代码的核心是：内容没变就不写，内容变了就新增版本。这样代理每次读文件后写回，不会产生重复条目，但历史版本也保留着，需要回溯时能查到。

len(content) // 4是个粗糙的 token 估算，英文代码大致 4 字符 1 token。要精确的话可以接 tokenizer，但估算值用于预算控制已经够用。

4.4 检索策略：怎么让代理"查得准"

存储只是基础，检索才是 Context Mode 的价值兑现点。我总结了几种检索模式，按使用频率排序：

模式一：按任务 + 类型过滤。最常见，代理说"给我当前任务下所有 file 类型的上下文"，直接走索引。

模式二：全文检索。代理说"找所有提到 validateUser 的上下文"，走 FTS5。

模式三：按路径前缀。代理说"给我 src/services 下的所有上下文"，走source_path LIKE 'src/services/%'。

模式四：按时间窗口。代理说"给我最近 10 分钟写入的上下文"，用于追踪当前操作序列。

这几种模式可以组合。比如"当前任务下、最近 5 分钟、提到 validateUser 的文件上下文"，一条 SQL 就能表达。这种组合查询能力，是向量库很难优雅提供的。

注意：FTS5 默认对中文分词不友好。如果你的上下文里有中文注释，要么配tokenize='unicode61'，要么在写入前做预处理。我踩过这个坑，中文注释搜不出来，排查了半天。

5. 落地 Context Mode 时我踩过的坑

5.1 坑一：把上下文库当成"什么都往里塞"的垃圾桶

我一开始的想法很朴素：既然存储便宜，那就把所有东西都存进去。结果两周后库膨胀到 2GB，检索变慢，代理反而因为候选太多而选错上下文。

问题出在没有做上下文的价值分级。不是所有信息都值得持久化。我的修正方案是引入"写入白名单"：

文件内容：只存被实际修改或引用的文件，不存全项目扫描结果。
日志：只存错误和警告，正常输出丢弃。
对话：只存决策结论，不存来回确认过程。

白名单一上，库体积降了 70%，检索准确率反而升了。上下文管理的核心不是"存得多"，而是"存得准"。

5.2 坑二：MCP 工具调用没有幂等性，导致重复写入

MCP 工具调用可能因为网络、超时等原因重试。如果write_context不是幂等的，重试就会写入重复条目。

我最初的实现没考虑这点，结果代理一次任务里同一个文件被写了 5 遍。修复方法是给写入操作加上基于content_hash的幂等判断——就是 4.3 节那段代码的逻辑。任何会被代理反复调用的 MCP 工具，都必须设计成幂等的，这是硬性要求。

5.3 坑三：上下文检索结果没有排序，代理拿到一堆无关内容

早期我的检索直接返回所有匹配项，没排序。代理拿到 50 条结果，其中 45 条是无关的，它得自己筛。这既浪费 token 又容易出错。

后来我加了多级排序：先按任务相关性（当前任务优先），再按时间新鲜度，最后按内容匹配度。排序后代理通常只需要看前 5 条。这个改动让单次检索的平均 token 消耗降了 60%。

5.4 坑四：忽略了 SQLite 的并发写入限制

SQLite 默认是单写者模型。代理如果并发跑多个子任务同时写上下文，会撞上database is locked。

解决方案有两个：一是开启 WAL 模式（PRAGMA journal_mode=WAL），允许读写并发；二是把写入串行化，用一个队列缓冲。我两个都用了，WAL 打底，队列兜底。开启 WAL 后，并发写入的报错基本消失。

PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL; PRAGMA busy_timeout=5000;

busy_timeout设成 5000 毫秒，遇到锁时自动等待重试，而不是立刻报错。这三行配置是我每个 Context Mode 项目的标配。

5.5 坑五：上下文没有过期清理，库无限增长

即使做了白名单，库还是会慢慢长大。我加了一个定期清理任务：把status='consumed'且超过 7 天的条目归档到冷存储，主库只留活跃上下文。

清理策略要谨慎，不能一刀切删。我的做法是先归档再删除，归档文件保留 30 天，确认没问题再彻底清。这样万一代理需要回溯，还有救。

6. 一套可复现的 Context Mode 最小实现

6.1 环境准备与依赖

这套最小实现只需要 Python 标准库加一个 SQLite（Python 自带sqlite3），零外部依赖。如果你想接 MCP，再装一个 MCP 的 Python SDK。

# 确认 SQLite 版本，FTS5 需要 3.9 以上 sqlite3 --version # 如果系统没装 sqlite3 命令行工具（Linux 下常见） sudo apt-get install sqlite3

Python 侧不需要额外安装，sqlite3是标准库。MCP SDK 按需装：

pip install mcp

6.2 初始化上下文库

import sqlite3 def init_context_db(db_path="context.db"): conn = sqlite3.connect(db_path) conn.execute("PRAGMA journal_mode=WAL") conn.execute("PRAGMA synchronous=NORMAL") conn.execute("PRAGMA busy_timeout=5000") conn.executescript(""" CREATE TABLE IF NOT EXISTS context_entries ( id INTEGER PRIMARY KEY AUTOINCREMENT, task_id TEXT NOT NULL, entry_type TEXT NOT NULL, source_path TEXT, content TEXT NOT NULL, content_hash TEXT NOT NULL, token_estimate INTEGER, status TEXT DEFAULT 'active', created_at INTEGER NOT NULL, updated_at INTEGER NOT NULL ); CREATE INDEX IF NOT EXISTS idx_task ON context_entries(task_id); CREATE INDEX IF NOT EXISTS idx_path ON context_entries(source_path); CREATE INDEX IF NOT EXISTS idx_status ON context_entries(status); CREATE VIRTUAL TABLE IF NOT EXISTS context_fts USING fts5( content, source_path, content='context_entries', content_rowid='id', tokenize='unicode61' ); """) conn.commit() return conn

tokenize='unicode61'是为了让中文注释也能被检索到，这是我踩坑后加的。

6.3 写入与检索的完整闭环

写入用 4.3 节的upsert_context。检索我封装成一个函数：

def search_context(conn, task_id=None, keyword=None, path_prefix=None, entry_type=None, limit=10): sql = "SELECT id, entry_type, source_path, content, token_estimate " \ "FROM context_entries WHERE status='active'" params = [] if task_id: sql += " AND task_id = ?" params.append(task_id) if entry_type: sql += " AND entry_type = ?" params.append(entry_type) if path_prefix: sql += " AND source_path LIKE ?" params.append(path_prefix + "%") if keyword: sql += " AND id IN (SELECT rowid FROM context_fts WHERE context_fts MATCH ?)" params.append(keyword) sql += " ORDER BY updated_at DESC LIMIT ?" params.append(limit) return conn.execute(sql, params).fetchall()

这个函数把前面说的几种检索模式都覆盖了。代理调用时按需传参，不用关心底层 SQL。

6.4 接 MCP 的封装思路

把上面的函数包成 MCP 工具，核心是定义好工具的输入 schema。以search_context为例：

from mcp.server import Server from mcp.types import Tool, TextContent server = Server("context-mode") @server.list_tools() async def list_tools(): return [ Tool( name="search_context", description="按任务、关键词、路径检索上下文", inputSchema={ "type": "object", "properties": { "task_id": {"type": "string"}, "keyword": {"type": "string"}, "path_prefix": {"type": "string"}, "limit": {"type": "integer", "default": 10} } } ) ] @server.call_tool() async def call_tool(name, arguments): if name == "search_context": rows = search_context(conn, **arguments) return [TextContent(type="text", text=format_rows(rows))]

关键点是inputSchema要写清楚，代理靠它理解怎么调用。schema 越明确，代理调用越准。

6.5 验证闭环是否跑通

跑通的标准很简单：代理能在不重读文件的情况下，靠检索拿到它需要的上下文。

我的验证方法是：让代理完成一个"改两个文件 + 跑测试"的任务，然后检查对话窗口的 token 消耗。传统模式下这个任务要 5 万 token 以上，Context Mode 下应该能压到 1.5 万以内。如果没压下来，说明检索没生效，代理还在全量读文件。

7. 上下文预算控制：让代理学会"省着用"

7.1 为什么需要预算控制

即使有了外部存储，代理还是会把检索结果拉进对话窗口。如果一次拉太多，窗口照样爆。所以 Context Mode 必须配一套上下文预算控制。

核心思路：给每次检索设定 token 上限，超了就分批拉或者只拉摘要索引。

7.2 基于 token_estimate 的预算分配

我在检索函数里加了一层预算过滤：

def search_with_budget(conn, budget=4000, **kwargs): rows = search_context(conn, **kwargs) selected = [] used = 0 for row in rows: est = row[4] or 0 if used + est > budget: break selected.append(row) used += est return selected, used

代理先声明"我这次最多用 4000 token 的上下文"，函数按顺序装填，装不下就停。这样代理永远知道自己拉了多少，不会失控。

7.3 分级加载：先索引后内容

更精细的做法是分级加载。第一级只拉"上下文索引"——每条只有路径、类型、token 估算，不拉内容。代理看完索引，决定要哪几条，再发起第二级请求拉具体内容。

这个模式能把首次检索的 token 消耗压到极低。我实测一个 200 条上下文的项目，索引级检索只花 800 token，代理据此精准选中 3 条，第二级拉内容花 2000 token，总共 2800 token 搞定。传统模式全量读要 6 万 token。

7.4 预算超限时的降级策略

预算不够时怎么办？我设了三档降级：

第一档：只返回匹配度最高的前 N 条，N 随预算动态调整。
第二档：返回内容截断版（保留头尾，中间省略），并标记"已截断"。
第三档：只返回索引，让代理自己决定是否追加预算。

降级策略要显式告诉代理"我降级了"，否则代理会以为拿到的是完整内容，据此推理就出错。

8. 从单机到协作：Context Mode 的扩展边界

8.1 多代理共享上下文库

Context Mode 的一个自然延伸是多代理共享同一个上下文库。比如一个代理负责写代码，一个负责跑测试，一个负责审查。它们通过同一个 SQLite 库交换上下文，而不是通过对话传递。

这带来一个新问题：并发写入的冲突。我的处理方式是给每条上下文加owner字段，写入时带上代理标识，读取时按需过滤。冲突严重的场景，可以给每个代理分配独立的表，定期合并。

8.2 上下文库的版本化

把context.db纳入 Git 管理是个双刃剑。好处是上下文可追溯，坏处是二进制文件 diff 不友好。

我的折中方案是：主库不进 Git，但定期导出为 JSON 快照进 Git。快照只包含active状态的条目，体积可控，且 diff 可读。

sqlite3 context.db ".mode json" \ "SELECT * FROM context_entries WHERE status='active'" \ > context_snapshot.json

这样既能追溯上下文演变，又不污染仓库。

8.3 什么时候该放弃 SQLite

SQLite 不是终点。以下几种情况我会考虑换掉它：

上下文需要跨机器实时共享，SQLite 的文件锁扛不住。
写入量达到每秒上千条，单文件写入成为瓶颈。
需要复杂的权限控制，SQLite 的权限模型太粗。

这些场景下，把存储层换成服务端数据库，MCP 接口保持不变，代理侧零改动。这正是 MCP 抽象层的价值——存储可替换，接口不变化。

9. 我在实际项目里验证出的几条经验

第一条，也是最反直觉的一条：上下文库的价值不在于"存了多少"，而在于"检索命中率"。我早期追求大而全，结果代理检索时噪声太多。后来把库做小、做精，命中率上去了，代理表现反而更好。衡量指标很简单——代理每次检索后，实际用到的条目占返回条目的比例。这个比例低于 30%，说明检索该优化了。

第二条，MCP 工具的 description 写得越具体，代理调用越准。我一开始 description 写得很泛，代理经常传错参数。后来把每个参数的用途、取值范围、默认值都写清楚，调用错误率降了一大截。别小看这段文字，它是代理理解工具的唯一入口。

第三条，SQLite 的 WAL 模式和 busy_timeout 是必配，不是可选。我见过太多人因为没配这两个，在并发场景下被database is locked折磨。三行 PRAGMA，省下无数排查时间。

第四条，上下文清理要有"冷静期"。别一处理完就删，留几天缓冲。代理有时候会在后续任务里回溯之前的上下文，删早了就得重读，得不偿失。

第五条，token 估算宁大勿小。估算偏小会导致预算超支，代理拉进来的内容撑爆窗口；估算偏大只是浪费一点预算空间。两害相权，宁可估大。

这套 Context Mode 的落地方式，我从最初的"什么都塞"迭代到现在的"精准检索 + 预算控制"，前后改了五六版。每次改动都对应一个具体的踩坑。如果你也在做编码代理，建议从最小实现起步，先跑通"写入 - 检索 - 预算"这个闭环，再逐步加 MCP 封装和多代理共享。别一上来就追求大而全，上下文管理这件事，做减法比做加法难，也更有价值。