[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-892":3,"consumer-news-interaction-892":41,"consumer-news-related-892":44},{"detail":4,"item":36},{"card":5,"schemaVersion":23,"fields":24,"content":30},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":15,"href":16,"sourceName":12,"meta":17,"metrics":20,"tags":21,"resolved":22},"NEWS_ARTICLE:892","news","NEWS_ARTICLE",892,"资讯","zg 正式开源：本地检索，不止于关键词","博客园","🚀 zg（zvec-grep）正式开源！\n　\n我们打磨了一款面向人与 AI Agent 的「本地检索工具」——  \n默认在本机完成索引与检索，既能理解模糊意图，也保留 rg 的精确与高效。\n　\n🔒 本地优先：文件处理、索引和检索均在设备内完成，代码与文档无需上传，保护隐私与数据安全。\n　\n⚡️","https:\u002F\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fpng\u002F24957442\u002F1786498962962-a148a454-6626-4fdc-81ff-e95a9f71c9cd.png","","\u002Fnews\u002F892",[18,19],"2026","数据与架构",{},[19],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":25,"categoryName":19,"summary":13,"description":13,"publishTime":26,"updateTime":27,"sourceUrl":28,"language":29},"DashVector","2026-08-31T16:22","2026-09-02T20:37:54","https:\u002F\u002Fwww.cnblogs.com\u002FDashVector\u002Fp\u002F22776544","中文",{"format":31,"policy":32,"normalized":22,"html":33,"text":34,"wordCount":35,"hasBody":22},"HTML","NEWS_CONTENT_V1","\u003Cblockquote>\n \u003Cp>\u003Cstrong>摘要\u003C\u002Fstrong>：人与 Agent 所需的信息，往往散落在大量本地文件中，准确、高效地定位这些信息并不容易。\u003Cstrong>zg（zvec-grep）\u003C\u002Fstrong> 是面向人与 Agent 的本地优先检索基础设施，基于 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Falibaba\u002Fzvec\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>Zvec\u003C\u002Fstrong>\u003C\u002Fa> 提供的向量检索与 BM25 能力，并结合 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FBurntSushi\u002Fripgrep\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>ripgrep（rg）\u003C\u002Fstrong>\u003C\u002Fa>，从代码、文档等本地内容中提取并组织信息，减少搜索轮次与上下文消耗，帮助人与 Agent 高效地发现和定位所需内容。\u003Cstrong>zg 现已开源\u003C\u002Fstrong>，欢迎体验，也期待你的反馈与贡献！\u003C\u002Fp>\n\u003C\u002Fblockquote>\n背景\n\u003Cp>\u003Cstrong>rg\u003C\u002Fstrong> 凭借出色的性能与穷尽式匹配能力，已成为开发者和 Agent 检索本地内容的重要基础工具。对于函数名、配置名、错误信息或文档原文等明确目标，rg 能够提供快速、准确且可验证的结果。\u003C\u002Fp>\n\u003Cp>随着 Agent 开始处理代码理解、故障定位、知识问答和资料分析等复杂任务，检索输入逐渐从明确的符号或文本，转变为对业务现象、实现意图和知识概念的自然语言描述。\u003C\u002Fp>\n\u003Cp>这类查询与代码或文档中的实际表述往往缺乏直接的词汇对应。例如，“恢复主题偏好”的实现可能被定义为 \u003Ccode>hydratePreferences\u003C\u002Fcode>，而用户询问的“访问权限申请流程”，在文档中可能被表述为“账号授权与审批”。在缺少准确关键词时，仅依赖文本匹配容易遗漏相关内容；扩大搜索范围，又会产生大量缺少相关性排序的结果。\u003C\u002Fp>\n\u003Cp>为定位所需信息，Agent 往往需要多轮构造查询、执行搜索并读取文件，再从分散的文本匹配中整理相关上下文。这不仅增加了工具调用、响应时间与上下文消耗，也可能导致 Agent 基于不完整的信息得出结论。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"\" src=\"https:\u002F\u002Fi1.wp.com\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fpng\u002F24957442\u002F1786498962962-a148a454-6626-4fdc-81ff-e95a9f71c9cd.png?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>\n\u003Cp>因此，本地内容检索需要在保留 rg 精确、快速和穷尽能力的基础上，进一步具备 \u003Cstrong>语义发现、相关性排序与上下文组织能力\u003C\u002Fstrong>。这正是 zg 希望解决的问题。\u003C\u002Fp>\nWhat is zg?\n\u003Cp>为解决上述问题，我们开源了 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>zg（zvec-grep）\u003C\u002Fstrong>\u003C\u002Fa>：一套面向人与 Agent 的本地优先检索基础设施。zg 对代码、文档等本地内容进行提取、组织与索引，并通过 CLI 与 MCP 提供语义检索、BM25、混合检索和 rg 精确匹配能力，让本地检索从关键词匹配延伸至意图发现、相关结果排序与精确验证。\u003C\u002Fp>\n\u003Cp>zg 的核心设计目标是 \u003Cstrong>让分散在本地文件中的信息能够被高效发现和准确定位\u003C\u002Fstrong>，设计宗旨包括：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>全流程检索\u003C\u002Fstrong>：面向从模糊探索、相关性收敛到精确验证的完整过程，提供语义检索、BM25、混合检索与 rg 等不同能力；让每个阶段都能采用适合的检索方式，减少关键词猜测、重复搜索与结果遗漏；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>多文件格式支持\u003C\u002Fstrong>：面向代码、文档与结构化数据等多类文件格式，采用可扩展的内容提取机制，并尽可能保留符号、标题、层级与元数据；让更多本地文件转化为结构清晰、可准确定位的检索内容，持续拓展 zg 可检索的信息边界；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>上下文高效\u003C\u002Fstrong>：对多路检索结果进行融合、排序并按需提供预览，同时保留来源与位置；让人与 Agent 更快获得任务所需的信息，减少无关内容带来的阅读、工具调用与 Token 消耗；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>本地优先\u003C\u002Fstrong>：文件扫描、索引与本地 Embedding 默认在设备内完成，远程内容传输必须经过显式授权；在保障隐私的同时，让用户始终掌握数据流向。\u003C\u002Fli>\n\u003C\u002Ful>\nWhy zg?\n\u003Cp>基于上述设计目标，zg 的首个开源版本从代码与文本内容入手，提供向量检索、BM25 与 rg，支持通过 CLI 和 MCP 在 macOS、Linux 与 Windows 上使用，并具备本地 Embedding、嵌入式索引与增量更新能力。下面将从上手体验、检索与内容覆盖、检索效率与成本，以及本地运行与数据隐私四个方面展开。\u003C\u002Fp>\n\u003Ch2>三步上手，人与 Agent 即刻可用\u003C\u002Fh2>\n\u003Cp>zg 支持 \u003Cstrong>macOS、Linux 和 Windows\u003C\u002Fstrong>，面向开发者提供 \u003Cstrong>CLI\u003C\u002Fstrong>，面向 Agent 提供 \u003Cstrong>MCP\u003C\u002Fstrong>。无需手工部署服务或编写集成配置，\u003Ccode>zg install\u003C\u002Fcode> 即可自动发现 Codex、Claude Code、Cursor 和 OpenCode，完成 MCP 配置。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"\" src=\"https:\u002F\u002Fi1.wp.com\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fgif\u002F24957442\u002F1787801931776-c1e2a6a9-2a9f-484f-bb55-1a43b9a5e213.gif?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>\n\u003Cp>从安装到开始检索只需三步：\u003C\u002Fp>\n\u003Cpre>\u003Ccode># 1. 安装 zg\nnpm install -g @zvec\u002Fzvec-grep\n# 自动发现本机已安装的 Agent，并完成 MCP 配置；\n# 也可以指定目标，例如：zg install --target codex --yes\nzg install\n\n# 2. 为当前工作区建立本地索引\ncd your-repository\n# 默认使用轻量本地模型 local\u002Fpotion-code-16m-v2\nzg index\n\n# 3. 通过 CLI 或 Agent 开始检索\n# 方式一：在终端中通过 CLI 检索\nzg query --human \"theme preference persistence on startup\"\n# 方式二：在已连接的 Agent 中直接提问，Agent 会按需通过 MCP 调用 zg\n# 示例提示词：Find how theme preferences are restored on startup.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>同一份本地索引也可由已连接的 Agent 通过 MCP 直接使用，无需重复构建和配置。\u003C\u002Fp>\n\u003Ch2>多种搜索、多类内容，一个入口\u003C\u002Fh2>\n\u003Cp>复杂检索往往不是一次搜索就能完成。Agent 从任务描述出发，在探索过程中逐步获得相关方向、关键词和明确目标；zg 提供语义检索、BM25、混合检索与 rg，让不同阶段都能采用适合的检索能力。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"\" src=\"https:\u002F\u002Fi1.wp.com\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fpng\u002F24957442\u002F1786948979247-05d9477e-dbe0-4df0-b66f-e0da47f4d009.png?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>\n\u003Cp>这并非一条必须依次执行的固定流程。Agent 可以根据已有线索直接进入相应阶段，也可以在信息不足时继续探索；用户在 CLI 中同样可以按需选择这些能力，从模糊意图出发，逐步发现并准确定位所需内容。\u003C\u002Fp>\n\u003Cp>zg 的检索对象也不局限于代码。针对不同内容，zg 会采用相应的提取与组织方式：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>\u003Cstrong>内容类型\u003C\u002Fstrong>\u003C\u002Fth>\n   \u003Cth>\u003Cstrong>当前支持\u003C\u002Fstrong>\u003C\u002Fth>\n   \u003Cth>\u003Cstrong>提取方式\u003C\u002Fstrong>\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>代码\u003C\u002Ftd>\n   \u003Ctd>C\u002FC++、Go、Java、JavaScript\u002FTypeScript、Python、Rust，以及 Vue、Svelte 组件文件\u003C\u002Ftd>\n   \u003Ctd>对支持结构解析的语言提取符号、签名与层级信息；从 Vue、Svelte 中提取脚本内容；其他代码按通用文本处理\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>文档\u003C\u002Ftd>\n   \u003Ctd>Markdown、纯文本、RST、HTML\u002FXML\u003C\u002Ftd>\n   \u003Ctd>Markdown 按标题与章节提取，其他文档切分为可定位的文本片段\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>文本与数据文件\u003C\u002Ftd>\n   \u003Ctd>CSV、JSON、TOML、YAML，以及其他可识别为文本的文件\u003C\u002Ftd>\n   \u003Ctd>通过通用文本提取参与索引\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>代码仓库、项目文档、研究资料与本地知识库都可以成为检索对象；路径、Glob、文件类型和忽略规则可以进一步限定检索范围，让内容覆盖的扩大不以增加结果噪声为代价。\u003C\u002Fp>\n\u003Ch2>少走弯路，更省 Token 与时间\u003C\u002Fh2>\n\u003Cp>zg 关注的不只是单次查询速度，更是 Agent 完成整个任务所需的搜索轮次、Token 与时间。为减少反复尝试关键词、读取无关文件和拼接上下文产生的消耗，zg 对完整检索链路进行了针对性优化：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>检索决策优化\u003C\u002Fstrong>：通过 MCP 工具描述与使用指引，帮助 Agent 根据问题中是否存在明确关键词、位置或符号，选择适合的检索方式，并在信息充分时停止搜索，减少无效试探；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>召回与排序优化\u003C\u002Fstrong>：联合 BM25 与向量检索生成候选结果，通过 RRF（Reciprocal Rank Fusion）完成多路结果融合、去重与统一排序，让相关内容更早出现，减少无关文件读取；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>内容组织优化\u003C\u002Fstrong>：按代码符号、文档章节等结构提取可独立定位的信息单元，并保留文件路径与来源位置，减少 Agent 从完整文件中手工拼接上下文的成本；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>上下文输出优化\u003C\u002Fstrong>：默认返回经过排序的紧凑结果与有限预览，需要时再读取完整内容，避免大量无关文本直接进入 Agent 上下文。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些优化最终需要在完整任务中体现价值，而不只是让单次查询看起来更快。为此，我们在代码仓库问答 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\u002Fblob\u002Fmain\u002Fbenchmarks\u002Fswe-qa-bench\u002FREADME_CN.md\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>SWE-QA-Bench\u003C\u002Fstrong>\u003C\u002Fa> 和深度研究问答 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\u002Fblob\u002Fmain\u002Fbenchmarks\u002Fbrowse-comp-plus\u002FREADME_CN.md\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>BrowseComp-Plus\u003C\u002Fstrong>\u003C\u002Fa> 上进行了配对 A\u002FB 评测。其中，SWE-QA-Bench 包含 20 个真实代码仓库问答任务，要求 Agent 跨文件定位实现并完成多步推理；BrowseComp-Plus 包含 80 个深度研究问题，要求 Agent 从大规模固定语料中检索并整合多文档证据。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"\" src=\"https:\u002F\u002Fi1.wp.com\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fsvg\u002F24957442\u002F1787897229523-7b6e5e6c-ab6c-4971-af93-2f2afc48e423.svg?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>评测说明\u003C\u002Fstrong>：每组实验均保持 Agent、模型、Prompt、运行环境与任务限制一致。Baseline 使用 Agent 的标准工具，zg 方案仅增加预建索引、MCP 工具与使用指引。预建索引会产生一次性时间与计算开销，远程 Embedding 还会带来 Token 与调用费用；但索引可跨查询和 Agent 任务复用，后续仅需增量处理变化内容，成本经持续摊薄后通常可以忽略，因此未计入上表。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>在 SWE-QA-Bench 中，zg 在将\u003Cstrong>工具调用减少超过一半、输入 Token 减少近一半\u003C\u002Fstrong>的同时，评审得分提升了 1.50 分；在 BrowseComp-Plus 中，准确率由 98.67% 提升至 99.00%，\u003Cstrong>输入 Token 减少 37.56%、工具调用减少 43.52%、Agent 耗时减少 38.58%\u003C\u002Fstrong>。两项结果表明，zg 能够在\u003Cstrong>代码与非代码场景中减少无效搜索和上下文消耗，同时保持任务质量\u003C\u002Fstrong>。完整评测协议、指标定义与复现方式参见\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\u002Fblob\u002Fmain\u002Fbenchmarks\u002FREADME_CN.md\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>性能测试文档\u003C\u002Fstrong>\u003C\u002Fa>。\u003C\u002Fp>\n\u003Ch2>本地优先，数据流向由你决定\u003C\u002Fh2>\n\u003Cp>代码、内部文档等本地内容往往包含未公开或敏感信息，检索过程中的数据流向至关重要。因此，zg 将本地处理设为默认：\u003Cstrong>文件扫描、内容提取、本地 Embedding、索引与检索均在设备内完成\u003C\u002Fstrong>，完整流程无需上传内容或依赖外部服务。\u003C\u002Fp>\n\u003Cp>\u003Cimg alt=\"\" src=\"https:\u002F\u002Fi1.wp.com\u002Fintranetproxy.alipay.com\u002Fskylark\u002Flark\u002F0\u002F2026\u002Fpng\u002F24957442\u002F1786953865501-83356fe3-87b5-43c0-9407-562a29d2f9fe.png?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>\n\u003Cp>这套本地路径由端侧模型与嵌入式索引实现：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>本地 Embedding\u003C\u002Fstrong>：内置十一种端侧模型，覆盖代码、文档、多语言、长输入与轻量运行等不同需求。默认的 \u003Ccode>local\u002Fpotion-code-16m-v2\u003C\u002Fcode> 是 16M 级静态模型，本地缓存约 32 MiB，无需 GPU 即可运行；在 SWE-QA-Bench 上，它在取得\u003Cstrong>接近 \u003Cstrong>\u003Ccode>**qwen\u002Fqwen3.7-text-embedding**\u003C\u002Fcode>\u003C\u002Fstrong> 的任务效果\u003C\u002Fstrong>的同时，\u003Cstrong>大幅缩短 Embedding 耗时并免去远程调用成本\u003C\u002Fstrong>，以 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fdjango\u002Fdjango\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">Django\u003C\u002Fa> 仓库（3,457 个文件）为例，在 Apple M4 Pro 上完整索引耗时不超过半分钟；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>端侧存储与检索\u003C\u002Fstrong>：Zvec 以嵌入式方式将向量与 BM25 索引存储在设备内，无需部署和维护独立数据库服务。CLI 与 MCP 可以复用同一份本地索引，让人与 Agent 的核心检索流程无需依赖外部存储服务。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>在默认本地路径之外，zg 也保留了模型选择的灵活性。当本地模型无法满足检索质量、多语言覆盖或设备资源条件时，用户可以按需使用远程 Embedding。远程能力不会自动启用，相关文本或查询只有在显式授权后才会离开设备，从而兼顾能力扩展与数据隐私。\u003C\u002Fp>\n现状与规划\n\u003Cp>目前，zg 已覆盖本地检索的核心链路，并在此基础上向更完整的检索基础设施演进。下表对比了不同工具的产品侧重与能力边界，同时标明 zg 的现有能力与后续方向。\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>\u003Cstrong>类别\u003C\u002Fstrong>\u003C\u002Fth>\n   \u003Cth>\u003Cstrong>核心能力\u003C\u002Fstrong>\u003C\u002Fth>\n   \u003Cth>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>zg\u003C\u002Fstrong>\u003C\u002Fa>\u003C\u002Fth>\n   \u003Cth>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FBurntSushi\u002Fripgrep\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>rg\u003C\u002Fstrong>\u003C\u002Fa>\u003C\u002Fth>\n   \u003Cth>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FMinishLab\u002Fsemble\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>Semble\u003C\u002Fstrong>\u003C\u002Fa>\u003C\u002Fth>\n   \u003Cth>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Ftobi\u002Fqmd\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>qmd\u003C\u002Fstrong>\u003C\u002Fa>\u003C\u002Fth>\n   \u003Cth>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fcolbymchenry\u002Fcodegraph\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">\u003Cstrong>CodeGraph\u003C\u002Fstrong>\u003C\u002Fa>\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>使用方式\u003C\u002Ftd>\n   \u003Ctd>CLI\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>MCP\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>本地优先\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>检索能力\u003C\u002Ftd>\n   \u003Ctd>语义检索\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>BM25\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>混合检索\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>正则穷尽匹配\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>图检索\u003C\u002Ftd>\n   \u003Ctd>❌*\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>查询改写\u003C\u002Ftd>\n   \u003Ctd>❌*\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>模型重排\u003C\u002Ftd>\n   \u003Ctd>❌*\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>属性过滤\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>Medium\u003C\u002Ftd>\n   \u003Ctd>Medium\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>内容与索引\u003C\u002Ftd>\n   \u003Ctd>Embedding 丰富度\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>—\u003C\u002Ftd>\n   \u003Ctd>Poor\u003C\u002Ftd>\n   \u003Ctd>Medium\u003C\u002Ftd>\n   \u003Ctd>—\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>代码结构提取\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>Medium\u003C\u002Ftd>\n   \u003Ctd>Medium\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>文本结构提取\u003C\u002Ftd>\n   \u003Ctd>\u003Cstrong>High\u003C\u002Fstrong>\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>Poor\u003C\u002Ftd>\n   \u003Ctd>Medium\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>原生 PDF \u002F Office 内容提取\u003C\u002Ftd>\n   \u003Ctd>❌*\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>图片与多模态检索\u003C\u002Ftd>\n   \u003Ctd>❌*\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>增量索引\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>—\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>\u003C\u002Ftd>\n   \u003Ctd>自动刷新与查询新鲜度\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>—\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n   \u003Ctd>❌\u003C\u002Ftd>\n   \u003Ctd>✅\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cblockquote>\n \u003Cp>✅ \u002F ❌ 表示当前是否支持，❌* 表示 zg 已规划但尚未支持；High \u002F Medium \u002F Poor 表示能力深度。定级分别考察属性过滤的可用维度、Embedding 的模型覆盖与配置能力，以及代码和文本的格式覆盖、识别粒度、结构化切分与元数据保留。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>面向更完整的检索基础设施，zg 将重点推进四个方向：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>增强检索能力\u003C\u002Fstrong>：在 BM25、向量检索与 rg 之外，引入图检索和更多结构化信号，完善查询规划、结果融合、重排与解释能力，更好地覆盖从模糊探索到精确验证的完整过程；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>拓展内容边界\u003C\u002Fstrong>：逐步支持 PDF、Word、PowerPoint，并完善图片 OCR、版面结构提取与跨模态理解，让更多本地信息能够被提取、组织和检索；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>提高上下文效率\u003C\u002Fstrong>：持续优化结果去重、组织、预览与上下文选择，提高有效信息密度，让 Agent 用更少的搜索轮次和 Token 获得任务所需的信息；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>增强本地能力\u003C\u002Fstrong>：持续优化本地模型、索引效率与资源占用，在完善 macOS、Windows 和 Linux 体验的同时，探索适配 iOS、Android 及更多资源受限的本地运行环境。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>与此同时，安装、升级、卸载、增量索引、并发访问、服务自恢复、运行诊断与索引兼容等基础工程也会持续打磨，为上述能力提供顺畅、一致的使用体验。\u003C\u002Fp>\n加入我们\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">zg\u003C\u002Fa> 基于 Apache 2.0 协议开源。项目仍在起步阶段，我们尤其期待这些反馈与贡献：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>\u003Cstrong>真实场景\u003C\u002Fstrong>：分享 zg 在大型代码库、知识库或 Agent 工作流中的效果与问题；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>检索评测\u003C\u002Fstrong>：共同完善搜索质量、性能与 Agent 上下文效率的可复现 Benchmark；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>代码与文档\u003C\u002Fstrong>：贡献新格式提取、模型支持、Agent 集成、缺陷修复与教程；\u003C\u002Fli>\n \u003Cli>\u003Cstrong>产品方向\u003C\u002Fstrong>：告诉我们哪些检索任务最难、哪些结果最有用，以及哪些默认行为仍不够自然。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>项目地址\u003C\u002Fstrong>：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fzvec-ai\u002Fzvec-grep\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">github.com\u002Fzvec-ai\u002Fzvec-grep\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>💬&#xa0;DingTalk-钉钉交流群\u003C\u002Fstrong>\u003Cbr>\u003Cimg alt=\"zvec钉钉交流群\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F3446468\u002F202608\u002F3446468-20260820100545904-1123265009.png?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>\n\u003Cp>\u003Cstrong>📱&#xa0;WeChat-微信公众号\u003C\u002Fstrong>\u003Cbr>\u003Cimg alt=\"zvec微信公众号\" src=\"https:\u002F\u002Fi1.wp.com\u002Fimg2024.cnblogs.com\u002Fblog\u002F3446468\u002F202608\u002F3446468-20260826143454579-361518584.jpg?w=720&amp;quality=65&amp;strip=all\">\u003C\u002Fp>","摘要：人与 Agent 所需的信息，往往散落在大量本地文件中，准确、高效地定位这些信息并不容易。zg（zvec-grep） 是面向人与 Agent 的本地优先检索基础设施，基于 Zvec 提供的向量检索与 BM25 能力，并结合 ripgrep（rg），从代码、文档等本地内容中提取并组织信息，减少搜索轮次与上下文消耗，帮助人与 Agent 高效地发现和定位所需内容。zg 现已开源，欢迎体验，也期待你的反馈与贡献！ 背景 rg 凭借出色的性能与穷尽式匹配能力，已成为开发者和 Agent 检索本地内容的重要基础工具。对于函数名、配置名、错误信息或文档原文等明确目标，rg 能够提供快速、准确且可验证的结果。 随着 Agent 开始处理代码理解、故障定位、知识问答和资料分析等复杂任务，检索输入逐渐从明确的符号或文本，转变为对业务现象、实现意图和知识概念的自然语言描述。 这类查询与代码或文档中的实际表述往往缺乏直接的词汇对应。例如，“恢复主题偏好”的实现可能被定义为 hydratePreferences，而用户询问的“访问权限申请流程”，在文档中可能被表述为“账号授权与审批”。在缺少准确关键词时，仅依赖文本匹配容易遗漏相关内容；扩大搜索范围，又会产生大量缺少相关性排序的结果。 为定位所需信息，Agent 往往需要多轮构造查询、执行搜索并读取文件，再从分散的文本匹配中整理相关上下文。这不仅增加了工具调用、响应时间与上下文消耗，也可能导致 Agent 基于不完整的信息得出结论。 因此，本地内容检索需要在保留 rg 精确、快速和穷尽能力的基础上，进一步具备 语义发现、相关性排序与上下文组织能力。这正是 zg 希望解决的问题。 What is zg? 为解决上述问题，我们开源了 zg（zvec-grep）：一套面向人与 Agent 的本地优先检索基础设施。zg 对代码、文档等本地内容进行提取、组织与索引，并通过 CLI 与 MCP 提供语义检索、BM25、混合检索和 rg 精确匹配能力，让本地检索从关键词匹配延伸至意图发现、相关结果排序与精确验证。 zg 的核心设计目标是 让分散在本地文件中的信息能够被高效发现和准确定位，设计宗旨包括： 全流程检索：面向从模糊探索、相关性收敛到精确验证的完整过程，提供语义检索、BM25、混合检索与 rg 等不同能力；让每个阶段都能采用适合的检索方式，减少关键词猜测、重复搜索与结果遗漏； 多文件格式支持：面向代码、文档与结构化数据等多类文件格式，采用可扩展的内容提取机制，并尽可能保留符号、标题、层级与元数据；让更多本地文件转化为结构清晰、可准确定位的检索内容，持续拓展 zg 可检索的信息边界； 上下文高效：对多路检索结果进行融合、排序并按需提供预览，同时保留来源与位置；让人与 Agent 更快获得任务所需的信息，减少无关内容带来的阅读、工具调用与 Token 消耗； 本地优先：文件扫描、索引与本地 Embedding 默认在设备内完成，远程内容传输必须经过显式授权；在保障隐私的同时，让用户始终掌握数据流向。 Why zg? 基于上述设计目标，zg 的首个开源版本从代码与文本内容入手，提供向量检索、BM25 与 rg，支持通过 CLI 和 MCP 在 macOS、Linux 与 Windows 上使用，并具备本地 Embedding、嵌入式索引与增量更新能力。下面将从上手体验、检索与内容覆盖、检索效率与成本，以及本地运行与数据隐私四个方面展开。 三步上手，人与 Agent 即刻可用 zg 支持 macOS、Linux 和 Windows，面向开发者提供 CLI，面向 Agent 提供 MCP。无需手工部署服务或编写集成配置，zg install 即可自动发现 Codex、Claude Code、Cursor 和 OpenCode，完成 MCP 配置。 从安装到开始检索只需三步： # 1. 安装 zg npm install -g @zvec\u002Fzvec-grep # 自动发现本机已安装的 Agent，并完成 MCP 配置； # 也可以指定目标，例如：zg install --target codex --yes zg install # 2. 为当前工作区建立本地索引 cd your-repository # 默认使用轻量本地模型 local\u002Fpotion-code-16m-v2 zg index # 3. 通过 CLI 或 Agent 开始检索 # 方式一：在终端中通过 CLI 检索 zg query --human \"theme preference persistence on startup\" # 方式二：在已连接的 Agent 中直接提问，Agent 会按需通过 MCP 调用 zg # 示例提示词：Find how theme preferences are restored on startup. 同一份本地索引也可由已连接的 Agent 通过 MCP 直接使用，无需重复构建和配置。 多种搜索、多类内容，一个入口 复杂检索往往不是一次搜索就能完成。Agent 从任务描述出发，在探索过程中逐步获得相关方向、关键词和明确目标；zg 提供语义检索、BM25、混合检索与 rg，让不同阶段都能采用适合的检索能力。 这并非一条必须依次执行的固定流程。Agent 可以根据已有线索直接进入相应阶段，也可以在信息不足时继续探索；用户在 CLI 中同样可以按需选择这些能力，从模糊意图出发，逐步发现并准确定位所需内容。 zg 的检索对象也不局限于代码。针对不同内容，zg 会采用相应的提取与组织方式： 内容类型 当前支持 提取方式 代码 C\u002FC++、Go、Java、JavaScript\u002FTypeScript、Python、Rust，以及 Vue、Svelte 组件文件 对支持结构解析的语言提取符号、签名与层级信息；从 Vue、Svelte 中提取脚本内容；其他代码按通用文本处理 文档 Markdown、纯文本、RST、HTML\u002FXML Markdown 按标题与章节提取，其他文档切分为可定位的文本片段 文本与数据文件 CSV、JSON、TOML、YAML，以及其他可识别为文本的文件 通过通用文本提取参与索引 代码仓库、项目文档、研究资料与本地知识库都可以成为检索对象；路径、Glob、文件类型和忽略规则可以进一步限定检索范围，让内容覆盖的扩大不以增加结果噪声为代价。 少走弯路，更省 Token 与时间 zg 关注的不只是单次查询速度，更是 Agent 完成整个任务所需的搜索轮次、Token 与时间。为减少反复尝试关键词、读取无关文件和拼接上下文产生的消耗，zg 对完整检索链路进行了针对性优化： 检索决策优化：通过 MCP 工具描述与使用指引，帮助 Agent 根据问题中是否存在明确关键词、位置或符号，选择适合的检索方式，并在信息充分时停止搜索，减少无效试探； 召回与排序优化：联合 BM25 与向量检索生成候选结果，通过 RRF（Reciprocal Rank Fusion）完成多路结果融合、去重与统一排序，让相关内容更早出现，减少无关文件读取； 内容组织优化：按代码符号、文档章节等结构提取可独立定位的信息单元，并保留文件路径与来源位置，减少 Agent 从完整文件中手工拼接上下文的成本； 上下文输出优化：默认返回经过排序的紧凑结果与有限预览，需要时再读取完整内容，避免大量无关文本直接进入 Agent 上下文。 这些优化最终需要在完整任务中体现价值，而不只是让单次查询看起来更快。为此，我们在代码仓库问答 SWE-QA-Bench 和深度研究问答 BrowseComp-Plus 上进行了配对 A\u002FB 评测。其中，SWE-QA-Bench 包含 20 个真实代码仓库问答任务，要求 Agent 跨文件定位实现并完成多步推理；BrowseComp-Plus 包含 80 个深度研究问题，要求 Agent 从大规模固定语料中检索并整合多文档证据。 评测说明：每组实验均保持 Agent、模型、Prompt、运行环境与任务限制一致。Baseline 使用 Agent 的标准工具，zg 方案仅增加预建索引、MCP 工具与使用指引。预建索引会产生一次性时间与计算开销，远程 Embedding 还会带来 Token 与调用费用；但索引可跨查询和 Agent 任务复用，后续仅需增量处理变化内容，成本经持续摊薄后通常可以忽略，因此未计入上表。 在 SWE-QA-Bench 中，zg 在将工具调用减少超过一半、输入 Token 减少近一半的同时，评审得分提升了 1.50 分；在 BrowseComp-Plus 中，准确率由 98.67% 提升至 99.00%，输入 Token 减少 37.56%、工具调用减少 43.52%、Agent 耗时减少 38.58%。两项结果表明，zg 能够在代码与非代码场景中减少无效搜索和上下文消耗，同时保持任务质量。完整评测协议、指标定义与复现方式参见性能测试文档。 本地优先，数据流向由你决定 代码、内部文档等本地内容往往包含未公开或敏感信息，检索过程中的数据流向至关重要。因此，zg 将本地处理设为默认：文件扫描、内容提取、本地 Embedding、索引与检索均在设备内完成，完整流程无需上传内容或依赖外部服务。 这套本地路径由端侧模型与嵌入式索引实现： 本地 Embedding：内置十一种端侧模型，覆盖代码、文档、多语言、长输入与轻量运行等不同需求。默认的 local\u002Fpotion-code-16m-v2 是 16M 级静态模型，本地缓存约 32 MiB，无需 GPU 即可运行；在 SWE-QA-Bench 上，它在取得接近 **qwen\u002Fqwen3.7-text-embedding** 的任务效果的同时，大幅缩短 Embedding 耗时并免去远程调用成本，以 Django 仓库（3,457 个文件）为例，在 Apple M4 Pro 上完整索引耗时不超过半分钟； 端侧存储与检索：Zvec 以嵌入式方式将向量与 BM25 索引存储在设备内，无需部署和维护独立数据库服务。CLI 与 MCP 可以复用同一份本地索引，让人与 Agent 的核心检索流程无需依赖外部存储服务。 在默认本地路径之外，zg 也保留了模型选择的灵活性。当本地模型无法满足检索质量、多语言覆盖或设备资源条件时，用户可以按需使用远程 Embedding。远程能力不会自动启用，相关文本或查询只有在显式授权后才会离开设备，从而兼顾能力扩展与数据隐私。 现状与规划 目前，zg 已覆盖本地检索的核心链路，并在此基础上向更完整的检索基础设施演进。下表对比了不同工具的产品侧重与能力边界，同时标明 zg 的现有能力与后续方向。 类别 核心能力 zg rg Semble qmd CodeGraph 使用方式 CLI ✅ ✅ ✅ ✅ ✅ MCP ✅ ❌ ✅ ✅ ✅ 本地优先 ✅ ✅ ✅ ✅ ✅ 检索能力 语义检索 ✅ ❌ ✅ ✅ ❌ BM25 ✅ ❌ ✅ ✅ ✅ 混合检索 ✅ ❌ ✅ ✅ ❌ 正则穷尽匹配 ✅ ✅ ❌ ❌ ❌ 图检索 ❌* ❌ ❌ ❌ ✅ 查询改写 ❌* ❌ ❌ ✅ ❌ 模型重排 ❌* ❌ ❌ ✅ ❌ 属性过滤 High High Medium Medium High 内容与索引 Embedding 丰富度 High — Poor Medium — 代码结构提取 High ❌ Medium Medium High 文本结构提取 High ❌ Poor Medium ❌ 原生 PDF \u002F Office 内容提取 ❌* ❌ ❌ ❌ ❌ 图片与多模态检索 ❌* ❌ ❌ ❌ ❌ 增量索引 ✅ — ✅ ✅ ✅ 自动刷新与查询新鲜度 ✅ — ✅ ❌ ✅ ✅ \u002F ❌ 表示当前是否支持，❌* 表示 zg 已规划但尚未支持；High \u002F Medium \u002F Poor 表示能力深度。定级分别考察属性过滤的可用维度、Embedding 的模型覆盖与配置能力，以及代码和文本的格式覆盖、识别粒度、结构化切分与元数据保留。 面向更完整的检索基础设施，zg 将重点推进四个方向： 增强检索能力：在 BM25、向量检索与 rg 之外，引入图检索和更多结构化信号，完善查询规划、结果融合、重排与解释能力，更好地覆盖从模糊探索到精确验证的完整过程； 拓展内容边界：逐步支持 PDF、Word、PowerPoint，并完善图片 OCR、版面结构提取与跨模态理解，让更多本地信息能够被提取、组织和检索； 提高上下文效率：持续优化结果去重、组织、预览与上下文选择，提高有效信息密度，让 Agent 用更少的搜索轮次和 Token 获得任务所需的信息； 增强本地能力：持续优化本地模型、索引效率与资源占用，在完善 macOS、Windows 和 Linux 体验的同时，探索适配 iOS、Android 及更多资源受限的本地运行环境。 与此同时，安装、升级、卸载、增量索引、并发访问、服务自恢复、运行诊断与索引兼容等基础工程也会持续打磨，为上述能力提供顺畅、一致的使用体验。 加入我们 zg 基于 Apache 2.0 协议开源。项目仍在起步阶段，我们尤其期待这些反馈与贡献： 真实场景：分享 zg 在大型代码库、知识库或 Agent 工作流中的效果与问题； 检索评测：共同完善搜索质量、性能与 Agent 上下文效率的可复现 Benchmark； 代码与文档：贡献新格式提取、模型支持、Agent 集成、缺陷修复与教程； 产品方向：告诉我们哪些检索任务最难、哪些结果最有用，以及哪些默认行为仍不够自然。 项目地址：github.com\u002Fzvec-ai\u002Fzvec-grep 💬 DingTalk-钉钉交流群 📱 WeChat-微信公众号",5218,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":16,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":40},"2026 · 数据与架构","#2563eb","16 \u002F 10",[19],{"targetType":8,"targetId":9,"likedByMe":42,"likeCount":43,"commentCount":43,"contentLikeCount":43,"contentCommentCount":43,"sourceLikeCount":43,"sourceCommentCount":43},false,0,[45,52,58,64,70,79,85,92],{"id":46,"kind":7,"title":47,"summary":48,"image":49,"href":50,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":51},"NEWS_ARTICLE:842","几何分布：从“等一个结果”开始","你有没有过这样的经历？ 在游戏里抽卡，抽了多少次才终于出货？ 站在路边等公交车，第几辆来的才是你要坐的那一路？ 给客户打电话，打到第几个才终于接通？ 刷短视频时，刷了多少条才刷到自己想看的内容？ 这些场景背后，都藏着一个共同的概率模型——几何分布（Geometric Distribution）。 几","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F83005\u002F202609\u002F83005-20260902112922617-1277310049.png","\u002Fnews\u002F842",[19],{"id":53,"kind":7,"title":54,"summary":55,"image":15,"href":56,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":57},"NEWS_ARTICLE:884","OSS 文件上传的几个风险点和解决方案","〇、前言 OSS 作为海量数据的承载平台，一旦配置不当，可能引发敏感数据泄露、恶意文件上传、巨额流量盗刷甚至数据被勒索加密等严重后果。 了解这些风险并非杞人忧天，而是帮助开发者和运维人员在使用 OSS 时建立正确的安全思维——从凭证管理、权限控制、访问策略到上传校验，每一个环节都可能在疏忽中成为攻击","\u002Fnews\u002F884",[19],{"id":59,"kind":7,"title":60,"summary":61,"image":15,"href":62,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":63},"NEWS_ARTICLE:899","C# U9 二次开发","U9 是用友 U9 Cloud，基于BEAS 开发平台，底层 C# + .NET Framework，服务端是 IIS+WCF，数据库 SqlServer；二次开发分：插件扩展、WebService 接口、单据扩展、自定义页面、外部程序调用 U9 接口。 ⚠️ U9 二次开发不建议直接修改 U9 原","\u002Fnews\u002F899",[19],{"id":65,"kind":7,"title":66,"summary":67,"image":15,"href":68,"meta":37,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":69},"NEWS_ARTICLE:925","订单的含金量在分化","复杂的流程，在产品设计阶段就需要综合考虑多方面的建议，前期业务和技术的介入，避免产品层面出现合理但不合适的设计，过繁或者过简都不利于整体的迭代节奏。","\u002Fnews\u002F925",[19],{"id":71,"kind":7,"title":72,"summary":73,"image":74,"href":75,"meta":76,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":77},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[78],"人工智能",{"id":80,"kind":7,"title":81,"summary":82,"image":15,"href":83,"meta":18,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":84},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":18,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":91},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":93,"kind":7,"title":94,"summary":95,"image":15,"href":96,"meta":97,"badge":10,"author":12,"stats":-1,"accent":38,"coverRatio":39,"tags":98},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[99],"软件开发"]