Mole 把深度研究 Agent 搬进终端

近日，一款名为 Mole 的开源项目出现在开发者社区，它把 Deep Research 从网页里的功能按钮，变成了可以在终端中启动的研究 Agent。开发者输入一个问题后，Mole 的目标不是立即吐出一段答案，而是围绕问题持续搜索、阅读、判断信息缺口，再整理出一份研究结果。

Mole 是一个运行在命令行环境中的深度研究 Agent。 项目由开发者 Lajos Deme 发起，代码已发布在 GitHub，定位非常直接：让用户不必离开终端，就能执行包含多轮检索与信息综合的复杂研究任务。

截至 2026 年 8 月 14 日，Mole 仍然是一个偏早期的开发者项目，而不是已经打磨成熟的商业研究产品。它目前最值得关注的地方，不是跑分超过了哪款闭源服务，而是把深度研究能力放回了开发者熟悉的本地工作流：终端、脚本、文件和自动化任务。

它不是在终端里套一个聊天框

Deep Research Agent 是一种能够自主拆解问题、调用检索工具、反复阅读资料并生成综合报告的智能体。 它与普通联网问答的差别，不是有没有搜索按钮，而是能否形成完整的研究循环。

传统搜索引擎通常返回一组链接，普通聊天机器人通常根据一次检索生成答案；深度研究 Agent 则需要先判断问题由哪些子问题组成，再分别寻找资料。第一轮搜索结束后，它还要检查证据是否充分、来源是否互相矛盾，以及哪些结论仍然缺少支持。

这类系统的典型工作流可以概括为：

用户问题
  ↓
拆分研究任务
  ↓
搜索并筛选来源
  ↓
阅读、提取与交叉验证
  ↓
判断信息是否充分
  ├─ 否：调整关键词并继续搜索
  └─ 是：生成带有依据的研究结果

Mole 的核心卖点是把上述循环放进命令行，而不是把网页搜索结果换一种方式显示出来。 这意味着它面对的主要用户不是偶尔查资料的普通消费者，而是已经习惯在终端中完成开发、运维、数据处理和知识管理的技术用户。

这个区别看起来只是交互界面不同，实际影响却很大。网页产品通常把搜索过程、上下文管理和报告保存封装在自己的产品里；终端工具则更容易与现有目录、Shell 脚本、定时任务、版本控制和文本处理工具衔接。

例如，开发者可以围绕一个新数据库做技术选型研究，安全团队可以持续跟踪某类漏洞的披露情况，产品团队也可以把竞品资料整理成固定格式。对这类重复任务来说，能否接入工作流，往往比回答页面是否漂亮更重要。

Mole 真正有价值的是工作流位置

命令行界面（CLI）是一种通过文本命令操作软件的交互方式。 对普通用户来说，CLI 的学习成本高于网页；对开发者来说，它却意味着可组合、可批处理和可追踪。

Mole 选择终端作为入口，至少带来了三项现实价值。

第一，研究任务可以与项目上下文放在一起。开发者不需要在浏览器和代码仓库之间来回复制材料，而是可以在当前工作目录中发起调研，并根据项目的实际问题组织输入与结果。

第二，文本输出天然适合继续加工。只要研究结果能够稳定地写入 Markdown、纯文本或结构化文件，后续就可以进入文档生成、人工审阅、差异比较和版本管理流程。这里的重点不是终端更“极客”，而是文本文件比封闭网页会话更容易成为工程资产。

第三，CLI 更适合无人值守任务。技术雷达、依赖风险追踪、论文更新和竞品动态都不是只查一次的问题，而是需要每周甚至每天重复执行。终端 Agent 可以成为自动化链路中的一环，网页里的研究按钮则通常需要用户主动触发。

Mole 因此更像研究基础设施，而不是又一个 AI 搜索网站。 这也是它与 OpenAI Deep Research、Gemini Deep Research，以及 Perplexity 一类产品最关键的差异。

与主流 Deep Research 产品相比，它更开放，也更粗糙

商业 Deep Research 产品是由模型、搜索索引、浏览器执行环境和引用系统共同组成的托管服务。 用户获得的是开箱即用的体验，但通常无法深入修改研究循环；Mole 代表的开源 CLI 路线则把更多控制权交给开发者，同时也把配置、稳定性和结果验收的责任交了回来。

| 产品或路线 | 主要入口 | 研究流程控制 | 自动化集成 | 成本结构 | 当前优势 | 主要短板 | |---|---|---|---|---|---|---| | Mole | 终端 CLI | 开发者可检查并改造项目代码 | 强，适合脚本和文件流程 | 项目本身未公布独立订阅价，实际成本取决于所接模型与搜索资源 | 开放、可组合、贴近本地工作流 | 早期项目，易用性与稳定性仍需验证 | | OpenAI Deep Research | ChatGPT 等官方界面 | 主要由平台控制 | 取决于官方提供的产品能力 | 按官方套餐与用量规则计算 | 模型推理、浏览和成品报告体验完整 | 流程定制空间有限 | | Gemini Deep Research | Gemini 及 Google 相关产品 | 主要由平台控制 | 与 Google 生态结合较紧 | 按官方套餐与产品规则计算 | 搜索生态与长上下文能力较强 | 对非 Google 工作流未必最顺手 | | Perplexity 研究类功能 | Web 与移动端 | 用户主要控制问题和追问 | 更偏最终用户搜索体验 | 按官方套餐规则计算 | 检索速度快，引用展示直观 | 深层流程改造能力有限 | | 自建研究 Agent | CLI、服务或内部平台 | 完全可控 | 最强 | 模型、搜索、计算与维护分别计费 | 能针对业务做深度定制 | 工程成本和评估成本最高 |

这张表也说明了一个容易被忽略的问题：开源不等于零成本。深度研究任务往往需要多次模型推理和多轮网页读取，一次任务产生的计算消耗可能明显高于一次普通问答。Mole 没有额外的软件订阅价格，并不代表研究过程本身没有成本。

Mole 目前也没有公开一套足以横向比较的标准化研究基准。 截至发稿，项目没有给出可以直接证明其在报告准确率、引用召回率、任务完成率或平均耗时上胜过商业产品的统一数据。因此，更准确的判断是：Mole 提供了一种值得关注的产品形态，但还不能仅凭演示或项目定位就认定它已经替代成熟的 Deep Research 服务。

深度研究的难点不在于“多搜几次”

研究循环（Agent Loop）是智能体在规划、执行、观察和调整之间反复迭代的过程。 一个深度研究 Agent 是否有用，主要取决于这个循环能否在正确的时间继续搜索，也能在证据已经充分时及时停止。

搜索次数太少，报告容易停留在常识层面；搜索次数太多，系统又可能不断阅读内容相似的页面，增加耗时和计算成本。真正困难的是让 Agent 知道自己缺什么，而不是机械地把同一个问题换十种关键词再搜一遍。

来源质量也是更棘手的问题。搜索结果中的高排名页面未必是原始来源，一篇二手报道可能引用另一篇二手报道，最后所有文章其实都来自同一份未经证实的材料。如果 Agent 只计算“找到了多少链接”，就会把来源数量误当成证据强度。

可靠的深度研究必须区分事实、推断和未知信息。 一个合格的研究结果应该告诉用户哪些数字来自官方材料，哪些判断是模型根据多条信息归纳得出，以及哪些问题在当前公开资料中仍然没有答案。

引用正确性同样不能被报告外观掩盖。一份排版完整、篇幅很长的报告，仍然可能存在引用页面没有支持对应结论、数据年份错位、把公司宣传当成独立验证等问题。对技术选型、合规调查和商业决策来说，这些错误比普通聊天中的措辞瑕疵严重得多。

终端形态让过程更容易审计，但不会自动变可靠

可审计性是指用户能够检查 Agent 使用了哪些来源、执行了哪些步骤，以及结论如何形成。 开源和终端环境为可审计性创造了条件，但两者本身并不等于结果可靠。

Mole 的潜力在于，开发者可以围绕研究过程增加日志、来源白名单、任务预算、文件快照和人工确认节点。比如，涉及软件许可证时可以优先读取官方仓库；涉及上市公司数据时可以要求优先采用监管文件；涉及安全问题时可以把厂商公告与漏洞数据库交叉验证。

不过，用户仍然需要自己回答几个工程问题：任务失败后如何恢复，网页内容变化后能否复现，来源不可访问时如何处理，模型产生相互矛盾的判断时由谁裁决，以及输出文件是否包含不应保存的敏感信息。

终端 Agent 还会扩大工具权限带来的风险面。 如果一个研究工具能够读取本地文件、访问网络并写入目录，那么网页中的提示注入内容就可能影响它的行为。最稳妥的部署方式不是直接给予整个主目录的读写权限，而是使用隔离目录、最小权限和明确的允许列表。

这也是 Mole 现阶段与成熟商业产品的另一处差距。商业服务往往已经替用户处理了运行环境隔离、页面解析、失败重试和部分安全边界；开源 CLI 则要求使用者自己承担更多工程治理工作。

哪些人现在值得试，哪些人可以再等等

Mole 当前最适合愿意调试 Agent 工作流、并能人工核验结果的开发者。 如果你的研究任务具有重复性，最终结果又需要进入代码仓库、知识库或自动化流水线，那么终端形态确实比封闭网页更有吸引力。

以下场景更适合尝试 Mole：

• 对开源项目、技术框架或基础设施进行初步选型；
• 定期跟踪某个技术主题、论文方向或产品类别；
• 为内部文档收集公开资料，并保留后续人工编辑环节；
• 研究如何设计搜索、反思、引用和报告生成的 Agent 循环；
• 希望把研究结果纳入 Git、Markdown 或自动化任务的团队。

以下场景则不适合完全交给早期研究 Agent：

• 法律、医疗、投资等错误成本很高的最终判断；
• 需要访问大量付费数据库或企业内部敏感系统的任务；
• 对引用完整性、结果复现和审计记录有严格合规要求的生产环境；
• 用户不准备检查来源，只想直接复制最终结论的场景。

Mole 现阶段更像一个方向正确的开发者原型，而不是 Deep Research 的终局产品。 它把研究 Agent 从网页中的黑盒功能，拉回到可以观察、修改和组合的工程环境，这件事本身就有价值。

CLI 可能成为研究 Agent 的重要入口

研究 Agent 的下一轮竞争很可能不只发生在模型能力上，还会发生在工作流入口上。 网页适合一次性提问，IDE 适合围绕代码行动，终端则适合跨文件、跨工具和长时间运行的任务。

Mole 抓住的正是这个空位。它不需要在界面精致度上与 ChatGPT 或 Gemini 竞争，而是要证明三件事：研究过程足够可控，输出能够稳定进入后续流程，长期运行的成本与错误率处于可接受范围。

这三件事目前都还需要更多真实任务验证。尤其是来源质量、任务停止条件和失败恢复，决定了 Mole 最终会成为开发者长期使用的研究工具，还是只停留在一次有趣的 Show HN 展示。

我们的判断是，Mole 值得 Agent 开发者关注，但普通用户暂时没有必要为了终端形态迁移。 它的意义不是让命令行看起来更智能，而是提醒行业：Deep Research 不应该永远只是大平台里的一个按钮，它也可以成为可编排、可检查、可嵌入的基础能力。

参考来源

• Mole GitHub 项目仓库：项目代码、README、安装说明及后续更新的第一手来源。
• Mole GitHub Issues：用于查看开发者反馈、已知问题和项目维护进展。
• Deep Research Agent 概念与行业案例分析：补充了解多步骤互联网探索、信息整合与报告生成的典型 Agent 流程。