大代码库探索（考点 5.4）· CCAF 备考

本页目录5

这个考点是什么

「大代码库探索」考的是：当代码库或文档体量远超一次性能塞进上下文窗口时，agent 该如何定位信息、维持推理一致性，并在长会话或多轮交互中恢复此前的发现。

核心不是「怎么读文件」这类操作细节（站内指南已讲 subagent 调用方式），而是三条互相配合的机制：增量检索（每次只取当下需要的部分，而不是一次性通读全部）、探索笔记 / scratchpad（把中途发现的具体事实外部化到文件里，防止随会话变长而被稀释）、以及子代理隔离（把大范围搜索丢给独立上下文的 subagent，只把结论带回主会话）。

这三者对应的失败模式也各不相同：

长会话里「答案变得笼统、开始援引通用套路而非之前找到的具体类」，是上下文退化（context degradation / lost-in-the-middle），不是速率限制或工具选择问题；
工具与连接器过多导致选错，是工具暴露过载，该靠动态工具发现收窄可见集合，而不是靠更详细的描述文案；
文件变更后的增量更新，考的是「resume 会话 + 明确告知变化范围」这条最省算力的路径，而不是全量重跑或局部隔离分析；
跨多个 MCP server 的数据发现，考的是 Tools（模型主动调用的动作）与 Resources（可先列出 / 读取的应用态数据）之间的边界。

为什么考

这个考点的题目通常给一个「看似合理但机制不对」的场景：agent 表现没有报错，却在语义上开始跑偏（援引通用知识而非会话内具体发现）；或者是在效率取舍上给出直觉答案（全量重跑 vs 增量更新；逐个工具调用摸索 vs 一次性拿到目录）。

干扰项常常混淆「识别症状」与「选对补救」：比如把上下文退化误诊成速率限制，把工具过载误诊成描述不够详细，把 MCP 数据发现的正确做法（Resources）误答成「再造一个发现用的 Tool」——形式上像是修了问题，实际只是把同一个瓶颈换了个位置。

核心辨析

1
上下文退化 vs 速率限制
症状是关键区分点——退化表现为「流畅但走样」（开始泛泛而谈、援引通用模式，和早期具体发现对不上），速率限制表现为报错、被限流或请求失败。前者的修法是外部化记忆（用 scratchpad 持续记录关键发现），不是重试或调整限速。
2
工具暴露过载
当工具数量达到几十个时，提示词层面「请先搜索」的约束通常不够用，因为模型每一轮仍要在全量工具集合里做选择。正确杠杆是架构层面收窄可见集合（按请求动态匹配，只暴露相关子集，如题面中的 search_connectors），而不是给每个工具写更详细的描述——后者不减少候选数量，只增加每轮的 token 成本。
3
全量重跑 vs 增量更新 vs 局部隔离
三者都「看起来可行」但只有一种最优。全量重跑丢弃了未变更文件已经算过的有效上下文；局部隔离（只喂改动的几个文件）丢的是跨文件关系（共享类型、调用方、导入）；正确做法是 resume 既有会话、明确点出变了哪几个文件、要求 agent 结合此前发现做针对性复核。
4
MCP 的 Tools 与 Resources 不是同一件事
Tools 是模型主动调用去执行动作的接口，每次调用都占一次往返和上下文；Resources 是可以先被列出 / 读取的应用态数据（如文档、schema、工单目录）。用「再造一个发现用的 Tool」去解决数据发现问题，只是把同一次往返换了个名字，并没有减少探索开销。
5
子代理隔离要解决的是「主上下文别被中间过程污染」，不是「任务该怎么拆」
如果拆分依据是范围、边界事先未知的动态分解，那属于编排模式（orchestrator-workers）那条轴的问题；本考点默认任务范围已大致已知，重点在于把大范围搜索的中间读取隔离到独立上下文，只把结论带回主会话。

反模式对照

常见做法

会话变长后模型开始给出笼统答案时，靠反复重申系统提示或直接推倒重来解决

正确做法

让 agent 把中途关键发现持续写入一个笔记 / scratchpad 文件，随时可回读，不依赖它还留在注意力窗口里

笼统化是上下文位置退化的信号，不是提示不够强；外部化记忆让具体事实脱离上下文位置的影响。

常见做法

工具选错时，给每个连接器补充更详细的描述，或者把几十个工具收口成一个万能路由工具

正确做法

提供一个搜索 / 发现类工具，按请求动态匹配后只把相关子集加入可见工具集

前者要么不减少候选数量，要么破坏了单个工具的参数 schema；只有动态收窄可见集合才是从根源缩小决策空间。

常见做法

文件改动后，要么把整个会话推倒重开，要么只把改动的那几个文件单独喂给 agent

正确做法

resume 原会话，明确说明哪几个文件变了，让 agent 结合已有发现只复核这部分增量

前者浪费了未变更文件的有效分析，后者丢了跨文件的共享上下文，只有 resume + 明确增量能两者兼顾。

常见做法

多个 MCP server 之间靠 agent 自己反复试探性调用去摸清有什么数据

正确做法

把每个 server 的数据目录发布为 MCP Resource，让 agent 先列出 / 读取看清楚有什么，再做针对性 Tool 调用

试探性调用本身就是要消除的开销，再造一个用于发现的 Tool 并不能省掉这次往返。

练这个考点

练习模式支持按考点专练（需 Google 登录，不占用正式考机会）。

专练考点 5.4

该考点的公开题（免登录，含完整解析）：