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

オープン
#3,782 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust

調査の方向性

Start by tracing how the desktop app's agent reads files and assembles conversation context; the issue does not identify specific files or tests. Compare that flow with the proposed indexing, structured extraction, range reads, and truncation approaches, then define scope and acceptance criteria before implementation. Done should mean relevant file context can be retrieved without routinely loading whole files, with tests showing the intended behavior.

索引モデルが issue の本文から書いたものです。

説明

Problem / opportunity
Image 从截图数据可以明显看到,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

主要言語
Rust
スター
2.3k
フォーク
236
平均マージ
12時間 24分
マージ済み PR(30日)
370

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

GCWing/OpenBitFun のほかの issue

GCWing/OpenBitFun の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。