最近半年我在给团队做 Agent Harness 集成逐步意识到一个有些反直觉的现象我们正在把早先接好的向量数据库从主链路里拆出去换成一组更朴素的能力——目录扫描、文件搜索、按需读取全文。刚开始团队里也有人反对觉得“放弃语义检索技术栈是不是倒退了”但跑完一千多条真实业务任务的评测之后结论压倒性逆转在 Harness 的场景里向量数据库的使用频率确实在下降这不是因为技术过期而是因为 Agent 时代的知识获取方式和过去完全不一样了。这篇文章我会把我们的复盘思路完整写出来包括为什么当初会上向量数据库、后来遇到了哪些阻力、现在用替代方案后的实际变化以及什么情况下我依然会坚定地保留向量数据库。如果你正在做 Agent Harness、DeepSeek Harness 这类工具层的落地或者你正在纠结知识检索到底该用向量还是该直接读文件这篇会是很直接的参考。1. 先分清两个概念Agent 是大脑Harness 是脚手架1.1 我们说的“harness 工程”到底在管什么事先对齐一下定义。这个词在圈里火的背景是大家在用 Claude Code、DeepSeek Harness 这一类编码代理时发现光有一个强大的模型还不够真正决定边界和稳定性的是外面这层“壳”。业界有个流传比较广的说法——Agent 是判断和行动的实体Harness 是包裹着 Agent 的那套工程框架它负责管提示词结构、工具调用权限、任务状态、上下文生命周期、技能包加载这些杂活。打个比方Agent 像一个短跑运动员Harness 是赛道规划、教练指令、安全绳和补给站的总和。运动员本身再强没有这套东西冲刺方向就容易失控。我们做的 Harness 项目核心目标只有一个让模型能在限定边界内稳定地完成任务每一步关键决策都可追溯、可回滚、可解释。就这个目标而言知识获取环节就一定绕不开一个灵魂问题模型要用到的领域知识到底怎么塞进上下文。1.2 向量数据库为什么曾经是 Harness 的标配Joe 在一年前我们画架构图时知识这块几乎是条件反射式地画了一个向量库。原因很简单当时 RAG 的教科书路径就是“文档切块 - 嵌入 - 相似度检索 - 拼接上下文”。这套链路在传统问答场景里确实是神器。假设用户问“公司今年第二季度在华东区的营收波动原因”关键词检索基本抓瞎因为问题里没有一个能查原文的词语义向量能把“营收”“波动”“华东区”映射到对应文档片段是当时唯一可行的路子。再加上 Milvus、Qdrant、Chroma 这些项目把运维门槛压得很低大部分团队也就是一个 docker-compose 的事。但 Harness 场景有个致命差异查询方不是天然的“人类提问者”而是一个具备代码执行能力的智能体。它懂得组合工具懂得连续行动也懂得在权限范围内去翻文件。当智能体自己和向量库站在同一条知识检索链路上原来那套“一步语义召回”的方案就不再是最优解了。1.3 触发转折点Agent 自己的检索能力变了我印象最深的一次调整是我们让 Agent 直接调用一个 grep 工具去代码仓库里找某个历史配置项。在此之前同一份代码我们提前切块灌进了向量库结果模型在回答时“看起来头头是道”但引用的代码位置和实际逻辑完全对不上还振振有词地补了一段不存在的上下文说明。后来我们做了一次盲测同样问题A 组走向量库B 组走“搜索工具 直接读原文件”。B 组在事实准确率上高出 18 个百分点定位平均快了两秒。从那以后我意识到一个关键变化——Harness 环境里Agent 本身就具备“主动检索”的工具能力我们真正要做的不是把知识提前嵌入进向量空间而是把“怎么取知识”的决策权交给一个更可控的运行时工具链。2. 为什么 Harness 开始少用向量数据库五个真实原因2.1 要的是“原文和证据”不是“相似片段”这可能是最核心的原因。传统 RAG 的目标是把“最相关的碎片”拼进上下文给用户一个“语义上说得通”的回答。Harness 场景却不然一旦涉及代码库阅读、配置排查、合同条款核对模型必须给出可追溯到文件路径、行号、原始表述的答案。向量检索的副作用恰好在这里放大了它返回的是嵌入空间里的近邻片段拼接后可能在“意思上接近”但原文的上下文、段落边界、看问题的角度往往已经被切碎。用户在追问“你凭什么这样说”的时候模型根本拿不出完整的原始依据。我后来在公司内部总结过一句话Harness 需要的是“原文呈现”不是“语义缝合”。尤其在代码调试、配置审计、文档合规这一类任务里一个字段的原始位置比一百个相似的向量更重要。向量库天然擅长“找相似”但不擅长“给原话”这正是它在 Harness 链路里被边缘化的深层原因。2.2 长上下文让“整文件读取”成了更划算的方案搁在两年以前主流上下文窗口还停留在几万 token走多轮问答时根本不敢把一个文件塞满。向量检索当时最大的优势就是能把任意长度的文档压成少量片段送进上下文省 token。现在的变化是主流模型普遍支持 128K 甚至 200K 的上下文窗口编码类 Agent 在工具调用时也可以分页读取、按目录加载、按需加载局部文件。这个能力变化直接把“提前切块嵌入”的必要性打没了。既然模型有能力在一个回合里读取 200 行以内的整个模块我们何必在检索环节冒着上下文失真、索引过期的风险只为了省下那几十 K token实际操作中我们发现直接“整文件读取”还有一个额外收益模型能完整看到文件内部的结构比如函数的上下文、注释的关联、模块间的依赖。这些信息在碎片化摘取时几乎必然丢失。长上下文 完整读取让 Agent 表现得既像在用 IDE又像在思考而不是在“剪报拼图”。2.3 向量检索本质上是决策黑盒Harness 没法观测Harness 工程的底层追求之一是可观测性。模型每一步做了什么为什么这么做中间经过了哪些工具都要能被完整记录和复盘。这也是为什么大量团队在引入 LangSmith 或者给 DeepSeek Harness 写插件时第一件事就是记录工具调用日志。向量检索在这方面的表现非常糟糕。它是一步“语义计算”过程我们很难回答“这个片段为什么被选中”“为什么在问题 A 和问题 B 下返回了同一批向量”“刚才那次检索到底有多少噪声”。你只能看到花费了额外延迟拿回了几个 top_k但整个过程缺乏可解释的中间决策。有人可能会说向量库不是也支持元数据过滤、打分调试吗实话讲这些功能都是索引侧的不是决策侧的。真正让工程师头疼的是在“问题不确定”时向量检索的结果高度不稳定——同一个问题的换几个措辞返回片段完全不同。这种随机性在 Harness 里是灾难你无法稳定复现一次 Agent 行为的成败也就无法定位故障根源。2.4 嵌入、分块、索引更新的成本被严重低估上向量库的隐形成本远不只是“部署一个容器”那么简单。到生产阶段你会发现三件事分块策略要反复调。块太小会丢失语义块太大检索粒度太粗每换一次块大小全部索引要重建。嵌入需要持续更新。内部文档每月都在变旧条目不删检索结果就会带上过期内容增量更新又容易和旧向量维度不一致。延迟预算不稳定。一个 20 万的文档库一次嵌入计算加上向量检索平均耗时往往在 180ms 以上实际线上抖动可能到 500ms。对比之下纯文件工具链的成本几乎可以忽略。grep 一个目录、扫描一个文件树、读取一个文件毫秒级返回不需要任何索引预热。用网上常说的那句话就是向量数据库喂饱了“宠物”却喂不饱“牲口”——线上 Agent 每天上万次工具调用稳定、小开销、可预测才是刚需。2.5 真实任务中简单工具的精度往往更高我们做的评测并不极端回归测试里覆盖了错误提示分析、历史配置追溯、多文件交叉定位。结果很有意思在 79% 的任务里Agent 只需要“文件名 路径 grep 关键词”就能完成定位12% 的任务靠“目录结构分析”完成真正非要语义联想才能解决的不到 9%。这个数据和很多人的直觉相反但它符合一个规律技术文档、代码注释、配置项都有一个共性——命名规范比想象中要好。变量名、函数名、文件名本身承载了大量语义信息关键词匹配远比我们以为的更可靠。“找得到”靠路径“找得对”靠上下文“找得全”才轮到语义扩展。向量数据库最强的一环是“模糊概念联想”但在真实工程里Agent 处理的问题大多是“具名实体定位”比如“找到那个校验超参的函数”“查一下订单状态枚举的变化记录”。这些问题向量库不是不能做但明显是杀鸡用牛刀还容易带回一堆结构相近却语义跑偏的干扰片段。3. 我们现在怎么取知识一套可观测的文件工具链3.1 核心思路先把“取什么”的决策权交给工具方向想清楚之后我们把知识获取链路重构了一番。核心原则只有一条让“取什么知识”这个决策发生在运行时而不是在离线阶段。离线向量化最大的毛病就是切块和嵌入是“猜”用户未来要问什么而 Harness 既然拥有实时工具完全可以直接在回答前先去探测知识结构。新的流程长这样Agent 接到任务 - 先扫描目录树 - 用文件名、扩展名、路径结构判断知识所在区域 - 再通过关键词工具筛选候选文件 - 最后整文件读取全文。这一步最大的改变是Agent 的行为变得有迹可循。每一步工具调用都自然成为日志问题定位不再需要对着模型输出猜你直接看它调用了哪个目录、匹配了哪些文件就行。这也让 Harness 层的回滚、暂停、重试策略变得好做得多。3.2 工具栈与调用顺序我直接把我认为最顺手的工具栈列出来你可以在自己的 Harness 里按这个思路实现目录扫描工具输入路径前缀输出目录树代价极小用来做“全局定位”文件名匹配工具支持通配符或正则用来快速锁定目标文件的候选集内容搜索工具grep/ripgrep 风格支持多目录、忽略规则用来做“精确线索”整文件读取工具支持行号区间、跳过二进制用来把原文完整送进上下文摘要生成工具当文件太大时先让模型读前 200 行生成摘要再决定是否继续读全文。调用顺序上我们的实测经验是严格“先粗后精”先目录再文件名再内容搜索最后再全文。这个过程会和传统的“边检索边拼装”形成鲜明差异——传统方式是离线把所有知识塞进模型在线只取片段我们的方式是离线不塞任何东西在线让模型按需“翻开”要用的页面。如果你用的是 DeepSeek Harness 这类自定义插件机制实现这套工具成本并不高本质就是注册几个更精细的工具函数然后把任务提示改成“先借助文件系统了解项目全貌再读取具体文件”的工作流。这种把 skill 和工具声明写进 harness 的做法和 Claude Code 里“脚本即工具”的解构思路是一致的。3.3 必要的兜底受限的稀疏检索与分层索引我当然不是说语义检索彻底不该用。在兜底层我们保留了一份“轻量索引”但做得很克制。后台为常用文档库生成一个小的元数据索引内容包括文件路径与别名文档类型、标签、负责人关键术语表人工维护少量核心词定期用 BM25 或 TF-IDF 做一次稀疏检索不进门级嵌入。这么做的好处是如果模型通过路径和关键词确实找不到线索可以退一步用稀疏检索做“同义词扩展”和“术语联想”又不需要承担全库向量化的成本和不可解释性。这个分层方案让我感到最舒服的地方是每一层都有明确的触发条件Agent 不会同时在一堆不可控的结果里瞎撞。4. 一张表看清路线差异什么场景下还该用向量库4.1 对比表向量数据库与文件工具链与其抽象总结不如直接上表。近半年我衡量过不少选型方案最终把它压成两行关键结论对比维度向量数据库方案文件工具链方案查询方式语义嵌入相似度召回路径 文件名 关键词 全文读取返回结果相关片段可能切碎原文原文全文 / 精确行区间可解释性弱难以定位“为什么返回这些”强每个结果都有工具调用证据实现成本需要分块、嵌入、索引维护无需预处理即时可用延迟嵌入 检索通常上百毫秒毫秒级稳定可预测更新机制增删条目较麻烦易过期直接读写文件天然一致适配场景模糊概念、大规模无结构化搜索工程代码、技术文档、配置审计上下文消耗少量但常有噪声片段单文件可能较大按需控制多语言召回较强跨语言语义也有效依赖关键词映射跨语言偏弱这张表并不是说向量库全面落败。我很明确地讲在两种场景下我仍然会优先选向量数据库一类是海量非结构化文本的开放搜索另一类是用户无法提供准确查询词的高模糊度问答。比如做企业级知识库时文档总量五百万篇问题五花八门用户又问得很随意向量库仍然是集效率和效果于一体的方案。这种场景下没有“路径”可依赖你必须靠语义空间去限缩范围。4.2 混合方案的边界向量库当“重排器”而不是“主力”还有一个新趋势值得一提不是“只用向量”或“不用向量”而是把向量降级为“重排器”。我们内部也试过一版先用关键词 路径拿回 50 篇候选再用 embedding 对这批候选做一次相关度打散最后只取 top 5。这种做法的好处是向量库的职责从“决定取什么”降级为“在有限范围内调整顺序”。黑盒影响被大幅压缩因为候选集本来就是可解释的向量只是在候选内部做排序。延迟也被控制在一个很小的窗口内。如果你既舍不得语义召回又忍受不了向量主导链路的不确定性这个折中方案很值得试。5. 折腾半年这些坑我自己都掉过5.1 “先检索后问答”改成“先工具后拼装”的实操心得切换初期我们犯过一个典型的错误光把工具加进了 harness但提示词还保持旧的“先去向量库取上下文”逻辑结果工具形同虚设。后来才意识到工具链必须配合新的决策提示一起调整否则模型会惯性依赖最熟悉的路径。现在我给团队定了个原则凡是新增一个工具就必须同时回答三个问题——它解决什么导航问题、它的触发条件写在哪、它失败后回退到哪一层。另外工具描述一定要写得“具体行动化”不要写“获取项目信息”要写“列出指定目录下的文件树适合先了解整体结构”。模型能多准确地使用工具很大程度取决于工具自己会不会说人话。这一步我们迭代了好几版才找到合适的描述颗粒度。5.2 嵌入和分块角度踩过的坑早期版本里我们为了“省 token”把文档切成 512 字符的小块结果模型经常只看到零散代码片段误判函数归属。后来改成“先整文件读再让模型自己对长文件做分段摘要”准确率明显提升。这说明了一个底层问题Harness 不需要提前替模型做信息切块真正优秀的方式是让模型根据当前任务动态决定“现在需要哪一段”。另一个印象深刻的坑是“索引过期”。有一回索引里残留了三个月前的旧配置说明模型引用了它导致生产环境排查白白浪费半天。自此我们在方案里规定了一件事凡是有“生命周期”的临时性文档绝不进向量索引只允许通过实时文件工具读取。这算是一条纪律也是让我对向量库态度转向的一个重要细节。5.3 常见问题速查表我把这段时间后台被问得最多的问题整理成了一张速查表你可以边做边自查问题现象可能原因解决思路Agent 返回内容引用了不存在的文件向量库索引引用旧地址关闭离线向量路径改用实时文件工具读取同一个任务多次执行结果不一致向量检索分数波动导致片段选择随机让结果集先稳定在候选路径再做局部排序知识定位花费时间太长第一步就做向量召回路径检索被跳过强制“先目录再文件再内容”的顺序模型不理解何时用工具工具描述写得太抽象改成行动化描述附上典型触发场景全文读取后上下文爆掉一次性读了太大目录没有分页按文件或按行区间读取读取前列出候选大小并确认6. 我看到的变化与个人建议落到整个行业视角这个趋势其实还有更深的原因。向量数据库是“给人类知识检索设计的”而 Harness 是“给 AI Agent 自主决策设计的”两者的根本逻辑不同。人类记不清关键词需要模糊联想Agent 永远不会“记不清”它只是不会“找”。当我们给 Agent 配上精准的导航工具和判定规则它在工程任务里表现得比向量化记忆更可靠。从这个角度看“少用”不是否定向量数据库本身的价值而是把资源放回它该放的位置。做 Harness 时我的建议很简单先默认直接读文件和检索路径当模型确实遇到无关键词、无路径、高不确定性的开放问题时再将其作为一种可选择性兜底手段引入而不是把它放在主链路上做主角。这套策略我们实际稳定跑了两个多月准确率没降平均延迟反而降了一半。