1万美金的账单，烧麻了！bull这个skills让数据推理质量更好，更省！

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

现在的Agent已经很聪明了

先说清楚一件事：2026年的AI Agent，不是2023年的ChatGPT。

Codex、Claude Code、Cursor这些Agent，内置了大量工具能力。它们会用ripgrep搜代码、会分块读取大文件、会写Python脚本在本地执行、会用shell命令处理数据。不会傻到把一个10MB的日志文件一股脑塞进上下文。

但是，"聪明"和"够用"是两回事。

Agent的内置能力是通用的：读文件、搜文本、跑脚本。当数据处理需求超出这些通用能力时，Agent就开始用笨办法------多轮对话、反复读文件、写临时脚本、一步步拼凑结果。每一轮都在消耗推理token。

这不是LLM笨，是Agent手里的工具不够专业。

GitHub: github.com/agi-now/bul...

Agent内置能力的天花板在哪

以下几个场景，是当前主流Agent用内置工具处理时，效率明显不足的：

1. 结构化数据的聚合分析

Agent拿到一个5万行的NDJSON日志文件。要回答"哪个服务报错最多"。

Agent的做法：写一段Python脚本，用json模块逐行解析，用dict做计数，排序输出。这个过程中，Agent需要：推理数据结构→编写脚本→执行→可能debug→读取输出→再推理。一个简单的GROUP BY，Agent可能要花3-5轮推理才搞定。

如果再追问"按小时统计错误趋势"、"关联另一个文件做JOIN"呢？Agent得重新写脚本，每多一个需求就多几轮推理。

每一轮推理都是token。问题不是单次贵不贵，是积少成多。

一个数据分析任务如果需要5轮推理，每轮消耗几千token用于思考和生成脚本。同样的事情，一条SQL命令就能搞定：

bash 复制代码

bull sql import-ndjson logs access access.ndjson
bull sql query logs "SELECT service, COUNT(*) c FROM access WHERE level='ERROR' GROUP BY service ORDER BY c DESC LIMIT 5" --format json

Agent只需要推理一次：该用什么SQL。一轮推理 vs 五轮推理，token差距是5倍。

而且数据导入后就持久化了。追问"按小时统计"不用重新写脚本、重新读文件，直接再来一条SQL：

bash 复制代码

bull sql query logs "SELECT SUBSTR(timestamp,1,13) AS hour, COUNT(*) c FROM access WHERE level='ERROR' GROUP BY hour ORDER BY hour" --format json

2. 图结构的精确计算

200个微服务的依赖关系，要检测循环依赖、找最短路径、生成部署顺序。

Agent的内置工具里没有图算法。它只能用两种方式：

让LLM直接推理------对200个节点的图做最短路径，LLM是概率预测不是确定性计算，正确率没有保障。
写Python脚本用networkx------可以，但前提是环境里有Python和networkx。而且Agent每次都要写一段图处理代码，写完执行完再解析结果，又是好几轮推理。

bull把图算法封装成了CLI命令：

bash 复制代码

bull graph import-csv infra deps.csv
bull graph has-cycle infra           # 确定性布尔值
bull graph shortest-path infra A B   # Dijkstra最优解
bull graph toposort infra            # 确定性拓扑排序

一条命令一个结果，不需要Agent写任何代码。 has-cycle返回true就是有环，false就是没环。没有"可能"，没有"似乎"。

3. 大规模关键词检索

3万篇技术文档，要找所有提到"connection pool"的文档。

Agent有ripgrep，可以做文本搜索。但ripgrep是逐文件grep，返回的是原始文本行。如果要跨字段搜索、带评分排序、支持分页，ripgrep就不够用了。Agent得自己写逻辑来处理ripgrep的输出，又是多轮推理。

bull的全文索引一次建好，后续搜索毫秒级返回，带评分和字段过滤：

bash 复制代码

bull search create docs
bull search bulk docs all_docs.ndjson
bull search query docs "connection pool" --field title --field content --limit 10 --format json

说明：这是基于SQLite FTS5的关键词精确匹配，不是语义搜索。在技术文档中搜索配置项、错误码、API名称时，精确匹配比语义搜索更可靠。

4. 跨会话的数据持久化

这一点经常被忽略。

Agent写的Python脚本是一次性的。这次会话里处理了数据，下次会话数据就没了。如果用户明天回来追问"上次那个日志分析，再按region拆分看看"，Agent得重新读文件、重新处理。

bull的数据存在磁盘上。导入一次，长期可用。Agent可以跨会话持续查询同一份数据，不用每次重新导入。

这让Agent从"一次性分析工具"变成了"持续可用的数据环境"。

bull不是替代Agent，是给Agent加装备

打个比方：Agent是一个能力很强的工程师，内置工具（文件读写、ripgrep、Python执行）是他的基础工具箱。bull是一套专业电动工具------你可以用螺丝刀拧螺丝，但电钻更快更准。

bull作为skill的设计很关键。skills/目录里有机器可读的技能定义，Agent读取后能自主判断：

数据量大、需要聚合查询 → 用bull sql，一条SQL比写Python脚本省好几轮推理
需要图算法 → 用bull graph，确定性计算，不用LLM猜
需要关键词检索、带排序分页 → 用bull search
需要持久化中间结果 → 用bull kv
数据量小、一眼能看完 → 不用bull，直接在对话中处理

触发条件明确：仅在数据规模较大、需要专业引擎能力、或用户显式指定时使用。

零运行时依赖

还有一个实际问题：不是所有Agent运行环境都有Python。

Codex跑在OpenAI的云端沙箱里，Python是预装的。但很多企业自建的Agent跑在精简容器、CI流水线、安全沙箱中，这些环境出于安全和体积考虑，可能只有基础的shell工具。

bull是纯Go静态编译的8MB单文件，不依赖任何系统库。复制进去就能用，不需要安装任何运行时。

在有Python的环境里，bull让Agent少写脚本、少几轮推理。在没有Python的环境里，bull是Agent唯一的数据处理能力。

成本模型：减少推理轮次才是关键

和早期"把数据灌进上下文"的模式不同，现在Agent的成本主要来自推理轮次。每多一轮推理（思考→生成代码→执行→解析结果→再思考），就多消耗一批token。

bull的价值在于把多轮推理压缩成单轮：

任务	Agent写Python	Agent用bull
日志聚合分析	3-5轮推理（写脚本、debug、解析）	1轮推理（写一条SQL）
图循环检测	3轮推理（写networkx脚本、执行、解析）	1轮推理（调bull graph命令）
追问分析	重新写脚本，2-3轮	再来一条SQL，1轮
跨会话查询	从头再来	直接查，1轮

推理轮次减少，token消耗自然下降。积少成多，月度账单的差异会非常明显。

总结

当前的AI Agent已经很强了。内置的文件操作、文本搜索、代码执行能力覆盖了大量场景。

但在结构化数据聚合、图算法、全文检索、跨会话持久化这些专业场景下，内置能力不够用，Agent会退化到"写临时脚本、多轮试错"的模式，推理轮次和token消耗成倍增长。

bull做的事情很简单：给Agent加一套专业数据工具，让它在数据密集型任务中从多轮推理变成单轮推理。

5个引擎，72条命令，8MB二进制，零依赖。

推理轮次少了，token省了，结果还更准了------因为精确计算永远比写临时脚本再debug靠谱。

GitHub: github.com/agi-now/bul...

作者简介：小姐姐味道 (xjjdog)，AI重度使用者。我的个人微信xjjdog0，欢迎添加好友，进一步交流。