在结构化数据查询任务中，纯SQL代理以100%准确率完胜Bash代理（52.7%），但混合使用SQL与文件系统操作的AI代理通过自我验证机制实现稳定可靠输出，揭示出工具组合优于单一抽象的核心设计原则。
一次真实评测显示，单靠bash处理结构化数据效率与准确率受限，SQL在清晰结构下表现稳定，bash在探索与核查阶段释放价值，混合方案通过自校验机制实现持续高准确度，评测本身成为系统进化引擎。
实验背景：为什么文件系统突然成了AI圈新宠
最近AI圈子里悄悄流行一个说法：“只要给AI一个终端和文件系统，它就能搞定一切。”
这个想法听起来挺酷——毕竟大语言模型在训练时啃过海量代码，对cd、ls、grep这些命令熟得像自家厨房的锅碗瓢盆。
模型训练数据长期浸泡在代码仓库、终端操作、沙箱环境之中，于是模型天然掌握目录结构感、命令组合感、管道流转感。把真实世界的数据映射成文件与目录，智能体进入后通过搜索、读取、拼装上下文完成任务，这条路线在客服记录、销售通话、日志分析等场景里呈现极强吸引力。
这种方式的优势来自直观性。文件就是上下文，路径就是线索，grep就是探测雷达。
信息随着需求逐步加载，token使用看上去具备弹性。正因为这种顺手感，社区逐渐形成一种共识：文件系统加bash或许成为通用抽象层。有人甚至觉得，连数据库都不用建了，直接把客户工单、销售记录全扔进文件夹，让AI用Bash翻箱倒柜找答案就行。
直觉强烈时，验证价值同步上升。于是实验目标非常明确：当问题指向半结构化、可查询的数据集合时，这套抽象是否依然占据优势。
三种智能体路线：规则统一，能力分流
Vercel团队联合Braintrust公司决定认真测试这个假设，于是搭了个评测平台，拿GitHub上的Issue和Pull Request数据当考题，看三种不同类型的AI代理谁能答得又快又准。
第一条路线是SQL智能体。数据以SQLite形式存在，智能体直接生成SQL查询语句完成任务。这条路线代表经典结构化查询范式。
第二条路线是bash智能体。数据以JSON文件形式分布在文件系统中，智能体仅使用bash工具完成所有操作。find、grep、jq、awk、xargs轮番登场，形成复杂命令链。
第三条路线是文件系统智能体。工具能力限定在搜索与读取文件层面，缺少完整shell自由度，更像“安全模式文件助手”。
三种智能体面对相同问题，评测维度包含准确率、token消耗、成本与执行时间。
结果出人意料：
- 最“土”的SQL代理不仅全对，还省时省钱；在结构化查询任务中，SQL拥有明显效率优势。
- 而那个满嘴awk、xargs、jq高级命令的Bash代理，反而频频翻车，准确率刚过一半。
这场实验不光比出了工具优劣，更意外发现：让AI同时拥有数据库和文件系统这两只“手”，它竟然学会了自己检查作业，成了最靠谱的答题选手。
为什么Bash会翻车？问题出在工具之外！三大坑一个没躲过
深入排查才发现，Bash代理栽在几个意想不到的地方。
首先是性能瓶颈：系统里有六万八千个文件，每次执行stat()检查文件属性都要卡半天，导致本该毫秒级完成的命令超时十秒。后来just-bash工具紧急优化才缓解这个问题。
其次是缺乏数据结构指引：Bash代理根本不知道JSON文件里到底有哪些字段、格式长什么样，就算加上示例命令和Schema说明，效果提升也有限。
最尴尬的是评分标准本身有漏洞——人工复核时发现，有些题目的“标准答案”其实错了，或者AI找到了额外正确结果却被判错。比如“哪个仓库有最多独立问题报告者”这题，到底是按组织还是按单个仓库统计根本没说清；还有几道题的预期输出和实际数据对不上。这些问题修正后，Bash的表现才有所回升，但依然追不上SQL。
修正后差距缩小，方向更清晰：随着工具性能优化、schema信息补充、评测纠偏完成，bash路线准确率获得明显提升。
虽然整体效率差距依然存在，但问题焦点逐渐从“bash行不行”转向“什么时候适合用”。
这时一个新想法出现：工具选择是否需要二选一。
混合路线登场：让智能体自己选工具
既然单一工具各有短板，何不让AI同时拥有两种能力？
混合智能体同时拥有bash与SQLite访问能力。新登场的“混合代理”既能直接查SQLite数据库，又能随时跳进文件系统用grep验证结果。面对问题时，智能体自行判断适合路径。
这一招立刻见效：它每次跑完SQL查询，都会去原始JSON文件里grep关键词二次确认。比如SQL返回某个Issue编号，它就去对应文件里翻原文看是否真提到“security”。这种自我检查机制让它稳稳守住100%准确率，连纯SQL偶尔犯的小错都能揪出来。
实验中观察到一个有趣行为模式。智能体往往先用SQL快速算出结果，然后切换到文件系统，通过grep与文本搜索进行抽样核查。这种自我验证流程显著提升最终答案稳定性。
结果显示，混合路线在准确率维度保持满覆盖表现，与纯SQL持平。同时通过双路径核查机制捕捉到个别SQL路径遗漏的问题。
代价同样清晰。因为要反复思考“该用哪个工具”以及“要不要再验一遍”，Token用量翻了一倍。混合路线token消耗约为纯SQL的两倍。
但比起可能出错的风险，多花点计算资源显然更值得。这就像考试时学霸做完选择题还要回头验算，虽然慢一点，但确保每道题都踩在得分点上。
整个实验过程中，评判标准逐渐转向长期稳定性与可解释性。
- SQL路线在结构化数据查询中依然是最直接方案。语义清晰、执行高效、资源可控。
- bash路线在探索与验证阶段展现独特价值。文件视角帮助发现边界情况、数据异常与评测问题本身。
混合路线通过自校验机制，成为综合可靠性最高方案。
真正的赢家并非某个工具，而是评测流程本身。多轮反馈让工具、数据、问题同时进化。
对智能体设计的启示：抽象匹配比技巧重要
当数据结构清晰时，结构化查询工具具备天然优势。
当任务包含探索、不确定性与验证需求时，文件系统与shell能力提供灵活观察视角。
智能体能力设计重点转向：让模型在合适阶段选择合适抽象，并建立自检路径。
如果手头数据有固定格式、字段清晰、关系明确，毫不犹豫上SQL。建个SQLite数据库，写好Schema，让AI直接查询，省时省力又准确。
如果数据杂乱无章、格式多变，或者需要频繁探索未知结构，文件系统配合Bash更合适。
但最佳实践是两者结合：主查询走SQL，关键结果用Bash抽样验证。尤其在金融、医疗等容错率极低的领域，这种双重保障必不可少。
另外务必给Bash代理提供完整的数据Schema说明，否则它就像蒙眼摸象，再强的命令技巧也白搭。最后别忘了优化文件操作——批量处理前先过滤无关目录，避免遍历数万文件拖慢速度。