Cellar - 给编码代理查询 JVM 依赖 API 的终端工具
AI 编码代理写 JVM 项目时，经常会卡在一个很具体的问题上：它知道项目依赖了某个库，却不确定某个类型、方法或参数签名到底长什么样。让模型自己猜 API 很危险；让它去解析 HTML 文档又慢又不稳定；让它读源码则需要先知道源码在哪里、版本是否匹配。
今天推荐的 VirtusLab/cellar 正好处理这个缝隙。它是一个命令行工具，用来查询 Maven artifact 或当前 JVM 项目的公开 API，并把类型签名、成员、文档和来源整理成 Markdown 输出。GitHub 页面当前显示项目约有 63 stars、8 forks，主要语言是 Scala，许可为 MPL-2.0。仓库创建于 2026 年 2 月 22 日，最近仍在 2026 年 5 月 27 日更新；release 页面当前指向 v0.1.0-M9。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | VirtusLab/cellar |
| Stars | 约 63 |
| Forks | 8 |
| 主要语言 | Scala |
| 许可 | MPL-2.0 |
| 创建时间 | 2026 年 2 月 22 日 |
| 最近更新 | 2026 年 5 月 27 日 |
| 最新 release | v0.1.0-M9 |
把“查 API”变成一个稳定命令
Cellar 的核心价值不是做一个新的文档站，而是把 API 查询变成可脚本化的终端命令。它可以查询外部 Maven 坐标，也可以在当前项目里自动识别 classpath，然后查询项目代码和依赖。
例如你可以用 cellar get-external org.typelevel:cats-core_3:2.10.0 cats.Monad 查询某个外部类型，也可以在项目根目录运行 cellar get --module core cats.Monad 查询当前项目上下文里的符号。返回结果是 Markdown，包含类型签名、flags、成员和文档片段，适合直接交给 LLM 或贴进调试记录。
这比让 agent 自由搜索要可控得多。命令输入里有明确的 artifact、package 和 symbol，输出格式也稳定。对于需要复现的代码生成流程来说，这种“一个命令拿到刚好够用的 API 信息”的工具，比泛泛地抓网页更容易接进 workflow。
支持 Scala 3、Scala 2 和 Java class
Cellar 目前重点支持 JVM 生态里的三类 artifact。Scala 3 的 TASTy 信息支持最完整，可以拿到签名、flags、companion、sealed hierarchy、given、extension 和 docstring。Scala 2 pickles 是 best-effort，类型信息可能不完整。Java .class 文件则可以提供较好的签名和成员信息。
这个范围很务实。JVM 项目里，AI agent 最容易出错的地方往往不是“不会写循环”，而是误用库 API：把 Scala 2 和 Scala 3 artifact 名称搞混，凭印象写不存在的方法，或者把 overload 参数顺序写错。Cellar 让 agent 可以先问真实 artifact，而不是在 prompt 里凭记忆补全。
它也不是只面向 AI。人类开发者在终端里快速确认某个依赖暴露了哪些类型、某个包下有哪些 top-level symbol、某个方法名出现在什么地方，也能直接用它省掉打开浏览器和切文档版本的步骤。
两种模式：项目内和外部依赖
Cellar 的命令分成 project-aware 和 external 两组。
Project-aware 命令在当前项目根目录运行，自动探测 Mill、sbt 或 scala-cli，抽取 classpath 后查询项目代码和依赖。常用命令包括 get、list 和 search。Mill 和 sbt 项目需要指定 --module，scala-cli 项目则不支持 module 参数。
External 命令则直接对 Maven 坐标工作，例如 get-external、list-external、search-external、get-source 和 deps。这适合 agent 在还没有完整项目环境时查询某个公开依赖，也适合写脚本时固定版本。
这两个模式覆盖了常见使用路径：如果你在现有项目里修改代码，就查当前项目 classpath；如果你只是要理解某个库，就查 Maven artifact。对于 agent 来说，二者都比“请上网看看文档”更容易约束。
输出面向 LLM 上下文
Cellar 的 README 明确把输出设计成 stdout 上的 Markdown，诊断信息放到 stderr。这个细节对 agent 很重要。很多 CLI 对人类友好，但会把进度、警告、彩色 UI 和结果混在一起，模型拿到之后还要清洗。
Cellar 的输出可以直接成为上下文材料：一个 heading 标出符号名，一个代码块给出签名，下面列出成员和文档。列表、搜索和依赖树命令也都有明确边界。对于需要把工具接入 Codex、Claude Code 或自定义 agent runner 的团队来说，这种 stdout/stderr 分离和 Markdown 格式会减少很多胶水代码。
更进一步，Cellar 还提供 --limit、--hide-inherited 和 --group-inherited 这类选项。它们能控制输出大小和继承成员的组织方式，避免一次查询把上下文塞满。Agent 工作流里，能控制工具输出的体积，往往和工具本身一样重要。
安装路径偏工程化
Cellar 提供了几种安装方式。推荐路径是通过 Coursier 安装贡献 channel 里的 native binary；也可以用 Nix 直接运行或安装；手动方式则是从 GitHub release 下载 native binary。项目还说明了源码构建方式，需要 JDK 17+ 和 Mill。
这些选择说明它目前更偏 Scala/JVM 开发者，而不是完全面向普通桌面用户。对目标用户来说这反而合理：如果团队已经使用 sbt、Mill、scala-cli、Coursier 或 Nix，Cellar 可以自然进入现有工具链。
需要注意的是，外部坐标必须写完整 artifact 名称，README 明确不支持 :: shorthand。也就是说 Scala 3 依赖要写成类似 org.typelevel:cats-core_3:2.10.0，Scala 2.13 则写成 org.typelevel:cats-core_2.13:2.10.0。这对人类稍微啰嗦，但对 agent 反而更明确。
适合什么场景
Cellar 最适合以下几类场景：
- AI 编码代理需要在生成代码前确认 JVM 依赖的真实 API；
- Scala 项目中经常需要查 TASTy、package、extension、given 或 companion 信息；
- Java/Scala 混合项目想在终端里快速列出类型成员；
- 团队希望把 API 查询固化成脚本或 agent tool，而不是依赖网页搜索；
- 代码审查时需要验证某个方法调用是否真的存在于当前依赖版本；
- LLM prompt 里只想注入必要签名，不想塞整页文档。
如果你主要写 JavaScript、Go 或 Rust，Cellar 不是你的工具。它的边界非常清楚：JVM artifact、Maven 坐标、Scala/Java 类型信息。也正因为边界窄，它才有机会比通用搜索更可靠。
需要注意的边界
Cellar 仍然是一个很年轻的项目，当前 star 和 fork 数都不高，release 还停留在 milestone 版本。把它放进关键 CI 或生产流程前，最好先在一个小项目里验证查询准确性、速度、缓存行为和构建工具兼容性。
Scala 2 的支持也需要谨慎看待。README 已经说明 Scala 2 pickles 是 best-effort，类型信息可能不完整。如果你的项目大量依赖复杂的 Scala 2 类型编码，不能把 Cellar 的输出当成唯一依据。
另外，Cellar 解决的是“查真实 API”问题，不是自动判断怎样正确使用 API。它能告诉 agent 某个方法存在、签名是什么、成员有哪些，但仍然需要模型或开发者理解语义、错误处理和业务上下文。
总结
VirtusLab/cellar 是一个小而明确的工具：把 JVM 依赖 API 查询从网页和猜测里拿出来，变成稳定的终端命令。对 AI 编码代理来说，它提供了一种更可靠的上下文来源；对 Scala 和 Java 开发者来说，它也是一个快速查看 artifact 和项目符号的 CLI。
它的吸引力不在于功能堆得多，而在于把一个 agent 很容易出错的环节收窄了：先查真实签名，再写代码。随着 coding agent 更深入地进入大型 JVM 代码库，这类“给模型提供精确局部事实”的工具会越来越有价值。