# Bub 深度对话：一个轻量级 AI Agent 框架的诞生与演进 上周我这边刚发了一篇用 Bub 和飞书搭建群聊机器人的实践，没成想这篇东西居然帮我们搭上了 Bub 开发团队的线。趁着这个机会，我和三位核心开发者聊了近两个小时，从项目起源聊到技术细节，从用户场景聊到未来规划。如果你对 Agent 框架感兴趣，或者正在寻找一个既能上手用、又能深入学的项目，这篇文章应该能给你不少启发。 先给没时间细看的朋友一个“懒人版”总结：这期专访主要聊了 Bub 是什么、它和普通聊天机器人或 Agent 框架有什么不同，以及它背后的 Ta pe 记忆机制和插件化设计。 简单来说，Bub 可以被理解成一个**以 channel 为中心的 AI Agent 框架**。它不是只在命令行里写代码的 Coding Agent，也不只是一个群聊机器人——它的野心是把不同的 IM、命令行、工具、记忆和运行上下文都连接起来，让用户能根据自己的场景定制一个专属的 Agent 版本。 几个核心点值得记住： - **Bub 的内核非常轻**。默认能力不多，很多功能通过插件扩展，比如飞书、QQ、企业微信、MCP、SQLite 等。 - **它特别重视 channel 的设计**。Agent 不一定每条消息都要回复，它能自己判断什么时候该说话、什么时候该闭嘴——这在群聊和多消息场景里太关键了。 - **Ta pe 是 Bub 最核心的设计**。它把上下文、记忆、运行 trace 和可观测性放在同一个数据底座里，Agent 可以回看自己的历史行为，也方便后续做 debug、检索和数据闭环。 - **Bub 更像一个可扩展框架，而不是一个成品机器人**。有人把它接到 IM 里做群聊助手，有人当 Coding Agent 用，还有人基于它做录屏总结、RAG topic 管理、企业微信/QQ 插件等。 - **它也是个非常适合学习 Agent 的项目**。代码规模相对可理解，内核清晰，比很多已经变得很复杂的 Agent 项目更适合作为学习入口。 如果只用一句话概括：Bub 不是在做一个万能聊天机器人，而是在探索一种更轻、更可定制、能把 channel、工具、记忆和运行 trace 串起来的 AI Agent 底座。 --- # Bub 是什么 **小七**：先给大家介绍一下 Bub 是什么。 **PsiACE**：Bub 其实是一个用来开发以 channel 为中心的 AI Agent 的框架，或者说它本身也是一个可以运行的项目。它和最近一些 Agent 框架的范式类似，可以通过 hooks 去替换里面的每一个阶段，或者给它注入一些能力。可以把它理解成一个 Python 版本的 Pi Agent，或者类似 OpenCode 这类项目里的一个核心部分。 **小七**：我之前听你解释过 Bub 这个名字的由来，也挺有意思的。 **PsiACE**：对。它最开始其实是一个 Coding Agent。去年年中的时候，命令行里的 Coding Agent 很火，比如 AMP 这种名字就很短，三个字母就能打出来。所以我当时也想找一个简短一点、又有点意思的名字。 Bub 这个词本身有点“小老弟”的感觉，稍微有点冒犯，但也挺贴切。现在你把它放进群聊，或者通过 IM channel 跟它对话，它确实像一个不那么聪明、但真的能干活的小老弟。 **小七**：Frost Ming 你有什么补充吗？感觉你们对 Bub 的理解可能各自有不同的重点。 **Frost Ming**：我觉得 Bub 和 OpenClaw、Hermes 这类项目相比，主要区别是它的 Harness 部分不会那么重。如果我们把 Harness 理解成“除了 model 之外的所有东西”，那 Bub 肯定也有 Harness，但它不会把记忆机制、自我学习机制这些东西都写死在里面。它更像一张白纸，给你很多定制的自由度。 # Bub 本该怎么用 **小七**：所以可以理解为 Bub 提供一些基础能力，用户可以根据自己的需求做自定义配置。那你们设计它的时候，有想过用户会怎么用吗？ **PsiACE**：有想过。明哥哥在这方面做了很多工作，比如方便用户制作插件、捆绑技能。 Bub 默认内核里提供的基础能力其实很少。比如 channel 默认只提供 Telegram 和命令行这两个。如果你想在飞书里用，就需要额外安装一个插件。我们的设想是：**用户可以捆绑我们提供的插件，或者根据自己的业务设计插件和技能，把 Bub 从一个只能做简单事情的工具，逐步变成一个在具体场景下能帮他解决问题的更大的 Harness**。 所以 0.3.0 之后，明哥哥完全重写过一版，我们就更明确地把 Bub 看成一个框架。它和其他框架一样：如果框架里有你需要的功能，你可以直接用；如果没有，你可以自己定义。只要内核足够稳定，上面做可插拔的东西就会比较有空间，也比较好玩。 不过从实际使用上看，很多用户其实还是 fork 一份，在上面改一改，甚至不改就直接跑。这和我们最开始期待的插件化、发行版式的用法还有一点偏差。 # 用户在怎么用 Bub **小七**：理想和现实总会有一点点偏差。我想知道目前你们看到的用户都是怎么用 Bub 的。 **yihong**：我先说一个不太一样的用法。我没有把它作为群聊工具，而是把它放进我们公司的一个项目里，当作 Coding Agent 来用。Bub 最早就有 Coding Agent 的能力，也支持读 skill。我把它放到公司的测试项目里，嵌入了一个对话框，背后跑的就是 Bub。那部分代码基本也是 AI 写的，我把想法告诉它，比如 Bub 有哪些功能、它应该怎么工作，然后它就把代码写出来了。测试下来差不多能跑，所以我就一直把 Bub 当 Coding Agent 用。 **小七**：我好奇，你为什么用 Bub，不用别的？ **yihong**：主要是 Bub 简洁，好定制。我希望有一个不需要我手动管理 memory 的 Agent。很多其他 Agent 需要你自己管理 memory，但 Bub 的 Ta pe 设计不需要我这么做。还有一个原因是它是 Python 写的。如果我用 Pi Agent，那整个东西都得用 TS，我不太想用 TS 写。 **小七**：你们应该接触到不少外部用户，有看到大家在做一些定制化开发吗？ **PsiACE**：我会定期观察用户到底怎么用。总体上，很多场景还是会变成聊天机器人或者类“龙虾”的形态，因为很多人确实会接 IM channel。 比如我们有 QQ 插件、WeCom 插件。有用户会在 QQ 里接一个云服务盯盘或者管理工具。他把 Bub 接到 QQ channel 里，然后对接一些 API。用户在 QQ 里给 Bub 发消息，比如想看云服务实例价格，Bub 就会去爬信息并返回。WeCom 插件可能更多是上班摸鱼视角下的东西。还有一些用户真的把 Ta pe native 的特性用得很好。 还有一个很有意思的用户项目 visual-base，是捕捉屏幕里的信息。底下是 Kimi 驱动的，因为 Kimi 有视觉能力。它会录屏，用 Kimi 定期总结屏幕信息。这个项目一开始有一版接到了 Ta pe 上，后来可能没有完全接，但里面会有录屏、提取信息，再加上 Kimi 集成的工具。 这个项目其实很符合我们对 Bub 的期待：不去动 Bub 的核心，而是在它上面扩展能力，让它变成对自己工作或生活有用的一个“Bub 发行版”。 **小七**：这个挺有意思的。 **PsiACE**：对，我个人也很喜欢那个项目。虽然我自己没有在用，但它是一个很标准的扩展 Bub 的方式。还有一些用户会写插件，对接不同 channel。现在有用户会把自己写的几个 Bub 插件捆绑在一个 Python project 里，做成一个可以分发的版本。我觉得这也属于我们预期里比较好的用法。 # 适合学习 Agent 的项目 **yihong**：我补充一个。Bub 不光是一个可以用的项目，它也是一个非常适合学习的项目。因为它有一个很好的代码内核，你会发现很多人会通过 Bub 学习怎么做一个 Coding Agent，怎么把 Coding Agent 变成一个通用 Agent。比如有人用 Rust 重写了 Bub，还有人用其他语言重写。 Bub 的代码很漂亮。你可以通过它理解什么是一个最小 Agent，什么是 AI native Agent，以及一个 AI native Agent 怎么通过 channel 把这些东西连接起来，变成一个类似“龙虾”的形态。你也会更容易理解“龙虾”是什么、记忆是什么。其实“龙虾”可以粗略理解成一个记忆系统、一个 Agent 和一个 channel 的组合。Bub 加上插件可能也就一万行左右，但“龙虾”已经八十多万行了，复杂度已经超出了很多人和 Agent 能理解的上限。 所以很多人会用 Bub 来学习 Agent。就像以前 Kimi 是一个很适合学习 Coding Agent 的工具，但现在 Kimi 已经变得非常复杂，甚至有点失控。现在 Bub 反而是一个很适合学习 Coding Agent 的工具，因为它有一个健壮又相对清晰的内核。 # Bub 是手搓出来的吗 **小七**：Bub 是你们手搓出来的吗？ **yihong**：对。第二版是 Frost 完全手搓出来的，第一版是 PsiACE 去年三四月份完全手搓出来的。他当时还做过一个分享。所以从 0.1 到后面这些版本，确实都有手搓的成分。 **Frost Ming**：我能说我是被你的“手搓 Agent”演讲带进门的吗？（补充说明：「手搓 Agent」为 yihong 在 OceanBase 嘉年华分享的「About Agent」主题演讲里的现场小彩蛋） **yihong**：好，谢谢。 **PsiACE**：如果细分一下，明哥哥写的那个版本应该算 0.3。0.2 其实是一个主要由 AI 生成的代码，加上明哥哥的一些修改。 最早的第一个版本，是受 AMP 那篇文章启发。当时命令行里工作的 Coding Agent 很火，我看到 AMP 那篇文章，说用四个工具就可以做 Agent，于是在去年年中就手写了一遍。手写完之后我发现一个问题：当时国内模型其实不太跟得上 AI 在命令行里工作的能力。但到了今年，再接各种模型，就发现效果已经明显变好了。 后来“龙虾”火的时候，我们想复刻龙虾。那个版本是 yihong 和 xuanwo 鼓励我做 Ta pe 这个想法。我快速实现原型的时候，基本就是把自己的想法图交给 AI，再用一些从明哥哥、piglei 那边抽取出来的 skills 去指导它，让它短平快地把东西搞出来。再后来到了 0.3，我们做了很大的架构调整，把它做得更框架化、更可定制。这个版本基本就是明哥哥手写出来的。 # 过去 3 个月的主要演进 **小七**：你刚刚其实回答了一部分历史问题，但我更想从产品侧问。很多人可能和我一样，是 2 月份才接触到 Bub。那从 2 月到现在，大概 3 个月时间，Bub 有哪些功能演变？现在已经到 0.3.8 了。 **PsiACE**：这个可以让明哥哥介绍，他在里面做了很多探索性的工作。 **Frost Ming**：从 baby Bub 到现在，有几个比较重要的改进。 第一个是它在**群聊里的定位**。我们做了一个关键改动：把 output 拿掉。传统“龙虾”是接受一个用户消息，然后通过 LLM generate 生成一段文本，再经过 Harness，通过注册的 Telegram channel 发成 Telegram 消息。它是从 input 到 output 的完整闭环，一个 input 必定对应一个 output。 Bub 做的事，是把这个 output 拿掉。发送消息、回复消息的能力变成了一个 tool，或者说 skill。Bub 自己决定在什么时机、以什么频率、要不要回复。为什么要这样？因为一问一答在私聊里比较合适。你给它发一个指令，当然会期待一个回应。但群聊不一样。群聊里可能一次收到好几条消息，如果每一条都必须回复，就会出现好几条相似回复，信噪比很低。所以我们要允许它不回复。**让它“闭嘴”，是一个很重要的能力**。 第二个重要改动是**框架化和插件系统**。我举一个最近体会比较深的例子：现在我们支持把 run model 的核心能力换成 Codex 或 Claude Code 这类 Agent。但把执行核心换成这类外部 Agent 之后，会遇到一个问题：它们未必能直接调用 Bub 内部的一些 tool，比如 Ta pe 的 tool 或其他内置 tool。所以我们支持以 MCP 的形式启动 Bub。这个 MCP Server 在 Bub 的概念里也是一个 channel。 如果你不用 Codex，那完全不需要这个能力。因为你用 Bub 内置 Agent，很容易调用自己的 tool。但一旦你用了 Codex 这种 Agent 能力，就需要 MCP。这也说明：有些能力只有在特定情况下才需要。如果所有能力都放到主仓库里，用户就会面对很多配置项。即使这些配置项默认是 disabled，也会带来杂音。框架化和插件化可以保证用户最开始看到的是一个简洁的配置界面。当他真的需要 Codex 这类能力时，再去安装 MCP 插件。 **小七**：用户是选择性去安装插件吗？ **Frost Ming**：对。我们会有一个插件市场，用户可以在里面看所有插件。 **PsiACE**：我补充一个小功能。明哥哥可能觉得它比较小，但我觉得最近很有意思，就是 **onboard 能力**。它其实是命令行里的一个子系统，和 install 这类能力类似，都是为了方便安装和配置插件。比如你启动 Bub 的时候，通常要写配置文件。但很多用户写不好配置文件，或者觉得这件事很麻烦。onboard 就像一个黑屏里的配置选单。它也可以通过插件扩展机制注入选项。你在命令行界面里按下去，就可以一步步填写：用哪个 provider、哪个 key、BOT 信息是什么。 我最近也在做一个基于 Bub 能力扩展的 DB native Harness，里面会有很多配置相关插件。插件对外发布时，最好有一个黑屏配置能力，能降低别人配置的复杂度。如果每个插件都有不同配置，但都能通过 onboard 组合起来，最后用户就能得到一个相对规整的配置文件。未来如果要做网页或者 App，这些配置字段也可以映射出去。我觉得这是一个很有价值的功能点。 # Bub 的记忆机制和 Ta pe 设计 **小七**：我对 Bub 知道的不多，但我觉得它的记忆系统挺好玩。你们能不能讲一下 Bub 的一些技术实现细节？ **PsiACE**：如果讲记忆这部分，首先要提 Ta pe 的设计。我过去一直做 DB 或数据相关的 Infra，所以我会本能地把上下文看成一堆带有典型数据库特征的字符串。在 Coding Agent 里，session 通常是一个 JSONL 文件，一行一行记录输入、输出、中间工具调用等内容。它其实是一个 agentic trace，反映了 Agent 完成任务过程中经历过的步骤。 我当时有两个想法。 第一个想法是：**这些数据最后其实要进到可观测系统里**。如果你真的要做应用，尤其是企业级应用，tracing 是很重要的一部分。而 tracing 和上下文有很多地方是重叠的。在数据系统里，一个很有意思的方向是把不同数据基础融合起来。比如 HTAP 是 TP 和 AP 的融合，还有一些产品会把 streaming 能力也融合进来。它们想达到的效果是：一份数据，尽管背后会经历不同处理，但最后可以用在不同场景里。 所以我会想：Agent 的上下文和可观测性，是不是也可以是一体的？这会带来一个好处：Bub 对自己的历史行为是可查看的。我们提供一些工具，或者封装一些 skills，它就能从自己的上下文里观测自己的行为。比如 debug 的时候，我们可以让它自己看 session 里经历过哪些事情。某个群聊 ID 对应的一条消息，让它做了什么、哪里没做好、哪里抛错了，都可以在私人会话里让它排查。它可以看 Ta pe 上的东西，画流程图，或者基于模型内化的知识告诉你发生了什么，以及可能怎么解决。 第二个想法是，**Ta pe 不是把不同主题硬隔离**。过去很多系统会人为划分会话阶段。但如果不及时清理或归档，讨论 topic 会非常分散。记忆系统很大一部分努力，就是让不同会话、不同 topic 能重新聚合。在 Ta pe 上，我们假设主题之间不是硬隔离。你可以继续和它对话。如果要区分主题，可以软性地加一个锚点。通过 handoff，让当前上下文聚焦在某个锚点之后的内容。锚点之后的内容会直接出现在模型的工作上下文里。 这样一方面可以利用模型前缀和 KV Cache，另一方面由于这是软截断，它也可以通过工具去扫描更早的内容。比如它知道自己的 schema，就可以扫 tool start、loop step，或者通过关键字、全文、embedding、混合检索等方式看历史会话内容。所以你讨论一个东西的时候，它有机会不需要你再补充很多历史资料，因为它能从自己的历史里找。 过去一年，记忆系统也有很多发展：从最开始只提取用户画像里的关键字，到记录工作里的重要信息，再到一些重要的个人设定需要和人确认。后来大家又意识到，memory 不是抽取完就结束，还要能关联到原始记录。而 Bub 是从底层 trace 的形态出发，把 memory、运行时上下文、可观测性这些东西用 Ta pe 抹平。 在 Ta pe 上，可以用锚点、handoff，以及锚点之间的 ID 关联，形成一个类似 graph 的形态。这也是我们寻找任务关联时很典型的一种方式。此外，我们最近还尝试把 Ta pe 上的数据导出，再分发到不同的对象存储上。这个功能也受到 Pi Agent 分享 agentic trace 的启发。 为什么要做这个？因为在 Agent 或模型侧，我们希望形成数据闭环。数据导出之后，可以用来做评估，也可以用于后续 RL 训练，提高模型解决任务时的 agentic 能力。过去这些数据系统比较分散，而 Ta pe 给了一个机会，把上下文、memory、observability 融合到一起。 # Comma Command：让人和 Agent 共享工具视图 **PsiACE**：另一个比较有意思的技术点，是我们很早做过的 comma command 机制。 最开始的设计预期是：如果我要在命令行里使用 Bub，那我本身就是技术用户。我可能知道一些命令行工具怎么用。有些一条命令就能解决的问题，我自己敲不一定比跟 AI 讨论更慢。Codex 也提供过类似能力，比如你在前面输入一个感叹号，就可以输入自己的命令。Bub 里叫 comma command，是因为我最开始希望它可以无感地替换到 shell 里。为了避免和现有字符冲突，我们用逗号 `,` 来作为前缀。 comma command 不只是让人输入熟悉的 bash 命令。更有意思的是，我们通过这个机制，**把 Agent 内部的工具也暴露出来了**。Agent 能调用的工具，比如和 Ta pe 相关的工具、网页搜索工具等，不光 Agent 能用，人也可以用。你看到 Agent 在 trace 里调用了某个工具，比如检索 Bub 是什么，你也可以用 comma command 做同样的事情。背后调用的是同一套工具、同一份代码。 也就是说，人和 AI 在完成任务时，至少在指令层面共享了同一个工具视图。我觉得在人和 Agent 协作的过程中，这很重要。为什么我们能信任一个人协作？因为人能做的事，我也能做。虽然实现质量上可能有差别，但我至少知道作为程序员我也能写。 使用 AI 时，一个很大的不安来自：我把任务交给它，它给了我一个不错的结果。但如果有一天 AI 从 loop 里消失了，我还能不能继续做？如果你有一份 trace，有同样的信息视图和同样的工具集，那你就有机会把“模型的脑袋”替换成“自己的脑袋”，继续把事情做完。handoff 不只是 Agent 从一个任务跳到另一个任务，也可以是 Agent 和人之间在同样的信息视图下交接任务。 即便有一天某个很复杂的 tool，人已经不太会直接拼出来了，也没有 AI 帮你，但通过 comma command 提供的简化视图，人仍然有机会复刻这件事，调用这个工具，拿到结果。从心理层面讲，这件事很有价值。哪怕现在很多工作会下放给 AI，但在心智上你知道：AI 能做到的事情，我也能做到。 # Bub 如何处理时间和存储 **小七**：我昨天发现 Bub 会说“昨天你跟我说的东西”。但我跟 Gemini 或 GPT 聊的时候，它们其实没有“昨天”的概念。所以 Bub 会处理时间戳吗？ **Frost Ming**：现在是有时间戳的。它会在上下文里插入当前时间戳。 **小七**：那记忆到底是怎么存的？是一个个文件，还是直接写进数据库？ **Frost Ming**：我们不限定存储介质。默认是 JSONL 文件，但你可以换成 SQLite，或者其他关系型数据库、非关系型数据库。你甚至可以把它存在某个网页上，或者 S3 上。 # 如何用好 Bub：延迟、模型和日志 **小七**：我用的时候发现 Bub 延迟有点高，不知道是不是我用得不太对。怎么用好 Bub？ **Frost Ming**：延迟这个问题，可能是你在和普通聊天机器人对比。作为 Harness，它要经历一系列步骤：判断任务意图、决定是否调工具等。它天生会比单纯回复的聊天机器人慢一些。 **小七**：我是和二三月份群聊里那个 Bub 对比。那时候感觉它 30 秒左右就返回了，但我自己部署到飞书里，经常要一两分钟才反馈。 **yihong**：可能是你用的模型太慢，tool calling 能力也太慢。你用 DeepSeek Flash 可能会快很多。 **Frost Ming**：有很多原因。一个是模型服务商本身的压力；另一个是上下文。Ta pe 越来越大，它记忆压力也会变大。如果一次要摄取很多东西，就会更慢。 **小七**：我只是问它在不在线，也要一两分钟。 **Frost Ming**：那你可以看 Ta pe 记录或者日志：它到底在做什么，为什么这么慢，经过了多少轮思考，每一轮在做什么。这些都会在 Ta pe 和日志里体现。 **PsiACE**：你现在用的是哪个模型？ **小七**：我自己用的是 MiniMax 2.7。 **PsiACE**：那可能要看 provider 速度，也要看模型能力。比如 tool calling 能不能 call 明白。如果它调用三四次都没成功，也会拖慢速度。另外，我们现在默认是 JSONL。对文件处理其实缺乏很多工具优化。这也是为什么我们想提供 DB 插件。DB 在查询上有全文索引、SQL 等优化，对于一定规模的数据查询有积累。 **小七**：那你们一般推荐用哪个模型？ **PsiACE**：模型上我们一直在换，一直在试。 **Frost Ming**：我们是吃百家饭长大的。 # 社区贡献和插件生态 **小七**：我看到 Bub 有一些 contributor 贡献的插件，这块有什么好分享的么？ **PsiACE**：我们最近才建微信群。之前主要是有人从 Telegram 过来，也有人看到宣传后，在 GitHub 上自己玩着玩着接进来。 我印象比较深的，首先是土拨鼠头像的那位。他其实没有直接用 Bub，而是比较深入地探索了 Bub 背后的 Ta pe 机制。他在他们内部 RAG 的 topic 管理场景里用了 Ta pe，还写了一篇非常业务驱动的文章，讲怎么利用 Ta pe 机制扩展到 RAG 场景，又能维持 Ta pe 里“所有消息汇聚到上下文”的假设。如果社区里有人想理解 Bub 的 Ta pe 如何扩展，那篇文章是一个很有意思的起点。 另外就是前面提到的那个录屏总结项目。社区里也有很多 channel 插件是外部贡献者做的。我们自己其实并没有努力去做各种插件。比如 QQ channel、WeCom channel、Redis 集成、飞书集成等，很多都是外部贡献者做的。飞书插件的作者平时会部署很多不同 Agent，好像 Alma、OpenClaw 也都有。他在自己使用过程中做了飞书插件，不光用了飞书插件，也用了 SQLite 插件。 **小七**：Frost Ming 要不要介绍一下插件机制？ **Frost Ming**：我觉得 Bub 的插件机制还是比较好用、也比较先进。我调研过其他 Harness 系统的插件机制，可以举两个例子。 一个是 Claude Code。它做插件系统比较早，但它很多东西依赖 JSON 配置和 Markdown 文件。Markdown 文件主要作为上下文注入，JSON 配置则取决于 Claude Code 本身开放了多少可调用点。比如 Claude Code 的 hooks 系统会定义很多 event，也就是调用 hook 的时机。你在 JSON 里写清楚哪个时机调用什么东西。这个东西可能是 shell 命令、prompt，或者 agent run。很多能力都依赖 Claude Code 预先定义好之后，你才能扩展。 另一个是 Pi Agent。Pi Agent 和 Bub 一样比较自由，很多扩展需要通过代码完成。你必须 hook 进它的库，调用它的一些核心能力，才能完成插件。所以它天生选择了 NPM package 这种分发形式。NPM package 的好处是可以定义 entry point 调用代码，可以增加依赖，也支持插件附带 skills。 Bub 和 Pi Agent 哲学比较像，所以我们也是用 package 的方式分发，只不过我们用的是 Python package。他们用 NPM package。Bub 插件的能力包括：指定依赖、通过 Python 模块调用 Bub 内部各种 hook、在插件中预置 skills。 比 Pi Agent 更进一步的是，Bub 的 skills 可以引用 GitHub 上已有的其他 skills，不一定要把 skill 文件都 copy 到插件仓库里。我们的实现方式是：打包工具会读取 pyproject.toml 里写的 skills 配置。这个配置可以引用某个 GitHub 仓库 URL，也可以引用这个仓库里某个路径下的具体 skill。打包工具读取到之后，会在打包时把 skill 下载下来，放到最终打包产物里。我觉得这是 Bub 插件比较方便的地方。 # 产品的取舍 **小七**：你们做 Bub 的过程中肯定会有取舍。有哪些功能以前想做，后来没做？或者做了之后又被砍掉？ **PsiACE**：从 0.3 到 0.3 的过程中，因为插件化，我们主动砍掉了一些东西。总体上，涉及 Agent Loop 里必须 built-in 的核心能力，我们会一直观察，也会谨慎加入。但不是核心 Loop 里的东西，大多数用户不需要感知的东西，最后都会变成插件，或者被砍掉。 比如 Discord 在 0.2 里是包在内核里的，但后来我们发现自己不用。那为什么还要包在里面？社区可能有人需要，但默认启动时，我们只关心一个简单 IM channel 和一个命令行 channel。其他 channel 就都移掉。最后保留下来的应该是一个很精简的核心，再加上一个我们自己一直在用、能持续吃狗粮、能测试改进是否引发不可控后果的 built-in Agent。其他东西基本不在核心关注范围内。 **Frost Ming**：要说删掉的，0.2 一开始 tool 里有一些文件搜索工具，比如 grep、glob，后面都删掉了。 **小七**：是因为太笨重吗？ **Frost Ming**：我们在使用中发现，LLM 对 shell 的使用意愿非常高。很多时候我们提供了 grep 工具，它也宁愿用 shell 的 grep。既然这样，不如把内置 grep 工具删掉，保持一个精简的最小工具集合。 # 未来计划：实时语音、Ta pe 格式化、多语言扩展和端侧设备 **小七**：未来有什么打算？ **Frost Ming**：我比较想做一个方向：real-time。利用 Omni 模型做端到端语音生成。不过这可能不适用于所有模型或所有场景，所以可能会作为单独分发版或者插件存在。因为一般这种端到端模型，工具调用能力不如普通模型那么好。但我们要的是端到端的快速回复能力，可以在其他能力上适当取舍。对于这种 Bub 分发版，我们就不一定要求它有很强的代码编写能力。 **小七**：PsiACE 有什么想做的吗？ **PsiACE**：我可能关注两个点。 第一个还是 Ta pe。Ta pe 可以提供 Agent 数据底座的抽象。在这个抽象上，会涉及数据流入、流出，以及数据在上下文中驻留的形式。现在 Ta pe 的注入形式是调用过程中一点一点注入进来，这不一定足够灵活。我们自己把它在上下文里的形式卡死了。虽然它能做到“一份数据到处使用”，但还不能很灵活地把各种场景端到端跑通。所以我会想，是不是可以把一些写死的逻辑释放掉。比如从 OpenTelemetry 这类可观测链路上拿到 Ta pe 信息。这就意味着 Ta pe 可能需要支持 format 能力。用户从不同数据源进来时，可以做一些简单定义，只要能挂载进来，后续的数据出入流程就会更顺畅。这个还没有完全想清楚，要看是否真的有强需求驱动。但作为实验性尝试，我觉得很有意思。 第二个点是扩展方式。现在 Bub 的扩展主要依赖 Python 或 skills。但社区里经常有人问：有没有其他语言版本？如果只是因为它不是某个语言写的，就重新写一份，其实意义不大。TS 用户可以去用 Pi Agent。其他语言社区也可能会各自用自己的方式，copy 几个 hook，接一个流行的 LLM provider。 但如果我们能提供用其他语言扩展 Bub 的能力，可能会更有意思。比如一个 coding team 更熟悉 Go 或 Ja va，那能不能让他们用熟悉的语言扩展 Bub？很多厂商会说：这个东西不是 Ja va 写的，我就没法用，我就要用 Ja va 写一个。这个需求听起来很抽象，但如果他们要二次开发，那么工程团队能理解插件或工具里面发生了什么行为，确实很重要。 另外，我也想看看端侧场景。比如具身设备，或者一些小设备，既有语音、视频、显示，又有简单运动能力。还有一些场景不能连接远端模型，可能需要一个本地小模型驱动 Bub 或类似产品完成任务。现在 Gemma、Mistral、千问都有小尺寸模型，这些模型大概率也会增强 agentic 能力，并且能在低资源设备上运行，比如树莓派或手机，占一两 G 内存就能跑。能不能在这些端侧设备上利用起来，是我比较想探索的方向。 （补充说明：专访完成于上周六，在这四天时间，PsiACE 已经跑通了这个想法，相关教程已在 Bub 官网上线。） # 小福利 **小七**：最后一个问题：你们最近有什么好东西可以分享吗？比如 coding skills、小工具，或者别的东西。 **yihong**：我最近没看到特别好玩的。我最近又回去关注 vector database 了。我看到 Jianyang Gao 写的一篇文章，关于 TurboQuant 和 RaBitQ，那篇 paper 非常 simple，也特别有意思。我最近几天一直在关注这个。其实它离大模型、离 coding 都挺远，但我觉得重新回到做技术最原始的快乐，还是挺有意思的。我决定最近完整看那篇 paper，尽量不用大模型，或者借助大模型但不让它写代码，从头学一遍如何把一篇 paper 实现出来。 **Frost Ming**：wey.gu（NowledgeMem 作者）做了一个开源的项目——con-terminal。如果用过著名的 AI 终端 Warp，你大概就知道 con 是什么了。wey 的这个和 Warp 相比没那么重，只做最需要的东西。性能上我用下来和 Ghostty 非常接近。我现在已经把 Ghostty 从 Dock 固定栏里去掉了，现在固定的是这个终端。 **小七**：PsiACE 有什么想分享的吗？ **PsiACE**：我说一点点心得分享吧。我觉得在这个 AI 快速变化、很多人都难免感到焦虑的阶段，有两个点比较重要。 第一个是**判断力**。现在很多具体代码可能都是 AI 生成的，很多细节也会逐渐失去掌控，变成更黑盒的东西。但本质上也许只是从一个黑盒换到另一个黑盒。过去你面对的是解释器、编译器这些黑盒。你对它们的行为有一定了解，你会它们的语法，所以你用自己写代码的形式工作。到了 AI 以后，你换成了另一个黑盒。你需要理解 AI 的 loop 里发生了什么，它是如何产生这些工作的。这个过程中，你的可见度会先下降，所以你会不舒服，会恐慌。但随着可见度恢复，你会发现，虽然工具不一样了，但你过去建立的行业理解、对事情的判断能力，仍然有用。你看到一个东西时，知道哪些地方可能做得好，哪些地方可能做得不好；你自己去做的时候，也能快速判断哪些决策更合理。 所以判断力很重要。之前大家说品味重要，尤其是在 vibe coding 里。但不管什么时候，你对做事情的判断力的坚持都很重要。你也会看到模型厂商到了现在这个阶段，coding 已经很卷了，短期内想再提升很多很难，因为重要的、有价值的语料大部分已经被吸收进去，只是质量参差不齐。所以他们会把目光投向其他领域。办法可能是收购一些在其他领域有成就的公司，获取他们怎么做事情的方法论、判断力；或者雇佣行业专家。这些专家不只是生产数据，他们对数据的判断、对行业的理解，反而是改善模型在特定行业表现的重要东西。所以抛开模型不谈，如果问这个时代怎么成长，我觉得判断力是很重要的。 第二个点，是**生活本身也很重要**。就像今天晚上炒鸡肉块炒得比较失败，但明天还可以尝试做新的菜式。作为人类而言，生活毕竟还是主旋律。像现在很多 Coding 工具公司都有额度开放，我也开始尝试：是不是还有机会在手写代码上找回一点东西？我觉得你要找到一个能让自己从浮躁状态里平静下来的手段。不管是读书、锻炼，还是像我这样，对过去写代码这件事还有一点不甘心。它会成为我平复状态的手段。比如照着一本书再打一段代码，或者自己再写点什么。当你觉得自己落在水里的时候，肯定希望抓到一点什么东西。那块木板就是一个寄托、一个锚点。它能保证你不要动不动就陷入恐慌里，让你有机会时不时浮到水面上换一口气。 --- 到此，和 Bub 团队的交流就结束了。如果你有什么想和其他开发者分享的，欢迎来找我们聊聊 Coding 和 AI 那些事。