[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 小时 24 分钟
30 天内合并 PR
370

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

GCWing/OpenBitFun 的其他 Issue

查看 GCWing/OpenBitFun 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。