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

未關閉
  • 哪裡不對？
#3,782 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
25/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
rust
領域
ai-infra-agents

研究方向

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 小時 20 分鐘
30 天內合併 PR
373

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

GCWing/OpenBitFun 的其他 Issue

查看 GCWing/OpenBitFun 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。