[Feature]: 使用结构化读取和索引维护代替全量读 #3782

Problem / opportunity

从截图数据可以明显看到，OpenBitFun 的“提示词构成”中，“文件 43%”是最大的占比，典型提示词高达 121K。这意味着每次对话都在“拖”着大量文件内容在跑。虽然“读文件多”本身是 Agent 的常见能力，但在 magpie 的观测视角下，这往往意味着输入端的 Token 消耗会非常可观。如果读入的文件并没有被高效利用（例如产生大量冗余），就会造成 Token 的浪费。

Proposed behavior

从“全量读取”转向“按需检索与结构化摘要”。它们不再让 Agent 动辄把整个文件塞进上下文，而是通过索引、符号提取、范围读取或强制拦截，只给模型看真正需要的那一小块。

• AST 结构化提取（只给骨架，不给血肉）
• 语义检索与索引（只取相关片段）；与其让 Agent 盲猜去读文件，不如先建索引，让它“问”出相关代码。Harness 在后台对仓库建立向量或符号索引。当 Agent 需要信息时，通过语义搜索（如 memory_query）直接返回最相关的代码块（chunk），并附带文件路径和行号，而不是整个文件。
• 数据支撑：ContextOS 的实测显示，相比传统的“Grep 搜索 + 全文件读取”，这种语义检索方式平均每次查询的 Token 消耗从 2,891 降到 1,054（降低约 64%），且准确率更高。
• 强制门禁与范围读取（物理拦截全量读取）
• 大结果转储与截断（溢出处理）

原始链接：https://chat.deepseek.com/share/ng5kcltilw0mlug2ru

Product surface

Desktop app

Details, examples, or constraints

No response