当前位置：首页 > news >正文

项目推荐：BettaFish (微舆) - 当多智能体遇上“论坛”协作机制

news 2025/11/7 9:08:29

大家好！最近在逛 GitHub 时，我发现了一个非常有意思的多智能体（Multi-Agent）项目——BettaFish (微舆)。

项目地址：https://github.com/666ghj/BettaFish

作为一个对 AI Agent 充满好奇的开发者，我深入研究了它的代码和架构（感谢项目作者和相关分析报告！）。BettaFish 不仅仅是一个简单的 Agent 链，它实现了一种我称之为“论坛协作机制”的模式，让多个 Agent 像一个专业团队一样开“圆桌会议”，共同解决复杂的舆情分析任务。

今天，我就和大家分享一下这个项目的亮点、架构，以及它带给我的一些启发。

1. BettaFish 要解决什么问题？

传统的舆情分析往往是手动的，或者依赖单一的爬虫+数据看板。而简单的 AI Agent 链（如 A -> B -> C）又太“死板”，无法应对复杂、多变、需要综合研判的任务。

BettaFish 的目标是构建一个自动化、多维度、有深度的舆情分析系统。它模拟了一个专业分析团队，团队里有5个“人”，每个人各司其职。

2. 认识一下这个“分析团队”：5大核心Agent

BettaFish 的核心是5个各具特色的 Agent，每个 Agent 都有自己的“专业”和“工具”：

QueryEngine (网页搜索专家)
- 职责：负责全网的广度搜索。
- 工具：使用 Tavily 搜索 API，精通各种网页、新闻搜索。
- 大脑 (LLM)：倾向于使用 DeepSeek 这样的强推理模型。
MediaEngine (多模态分析师)
- 职责：专门处理图片、视频和结构化信息卡片（如天气、股票）。
- 工具：使用 Bocha 多模态搜索 API。
- 大脑 (LLM)：配置为 Gemini，充分利用其强大的多模态能力。
InsightEngine (数据库侦探)
- 职责：深度挖掘项目私有的舆情数据库（这很关键，说明它能结合内部数据）。
- 工具：MediaCrawlerDB 查询工具、多语言情感分析模块。
- 大脑 (LLM)：使用 Kimi，对中文和长文本理解更出色。
ForumEngine (灵魂人物：论坛主持人)
- 职责：这是整个系统的“灵魂”！它不直接做研究，而是“主持会议”。
- 大脑 (LLM)：使用 Qwen3，擅长总结和引导。
ReportEngine (首席报告撰写人)
- 职责：收集所有人的研究成果和讨论纪要，撰写最终的精美报告。
- 工具：动态模板选择、HTML生成。
- 大脑 (LLM)：使用 Gemini 来确保生成内容的质量。

3. 这场“圆桌会议”是如何开的？

这套机制最巧妙的地方在于 Agent 间的协作方式。它没有使用复杂的消息队列或直接 API 调用，而是巧妙地使用了基于文件的异步通信，模拟了一个“论坛”。

整个工作流是这样的：

发布任务：用户通过 Flask 主应用提交一个查询（比如“分析一下最近某款新车的市场反响”）。
分头研究：QueryEngine、MediaEngine 和 InsightEngine 三个分析师并行启动，开始从各自的领域（网页、多模态、私有库）收集信息。
上“论坛”发言：每当一个分析师有了一个阶段性的小结（比如 QueryEngine 找到了几篇关键新闻），它会把这个总结（Summary）写入自己的日志文件 (.log)。
“主持人”登场：ForumEngine（主持人）在后台实时监控这三个日志文件。
主持总结：当“主持人”收集到足够多的“发言”（比如5条）后，它会触发自己的 LLM 大脑，对所有人的发言进行一次分析、总结、识别冲突，并提出新的研究方向（比如：“我注意到网页组和数据库组的结论有差异，媒体组能不能找找相关的视频证据？”）。
发布“会议纪要”：主持人把自己的总结和引导性发言，写入一个公共的 forum.log 文件。
迭代深化：三个分析师在各自的研究循环中，会定期通过 forum_reader 工具去“刷论坛”，看看“主持人”有没有发新帖子。一旦读到新引导，它们就会调整自己的研究方向，进行更深度的挖掘。
生成报告：当所有分析师都完成了自己的工作，ReportEngine（撰写人）登场。它会收集所有人的最终报告（Markdown 格式）以及 forum.log 里的全部讨论记录，选择一个合适的模板，生成一份包含深度洞察和分析过程的 HTML 报告。

[图片：一个描述上述流程的架构图或数据流图] (博客备注：这里可以放一张你自己绘制的流程图，基于报告中的架构图进行美化)

4. 架构与技术栈亮点

浏览 BettaFish 的代码库，我发现了一些非常务实和巧妙的设计：

混合框架：主应用使用 Flask + Socket.IO，提供统一入口和实时日志推送；而每个分析师 Agent 则运行在独立的 Streamlit 应用中。这极大方便了对单个 Agent 的调试和交互。
异构LLM：项目没有“迷信”某一个特定模型，而是根据不同 Agent 的任务（推理、视觉、总结）配置了不同的 LLM (DeepSeek, Gemini, Kimi, Qwen)，这是非常实用和降本增效的做法。
节点式设计：每个 Agent 内部的逻辑（如：首次搜索、反思、总结）都被抽象成了 BaseNode。这使得 Agent 的工作流变得非常清晰，易于扩展和维护。
状态持久化：每个 Agent 的工作状态（State 类）都会被实时保存为 JSON。这意味着即使任务中途失败，也可以从断点恢复，非常“皮实”。

5. 我的思考与启发：BettaFish 的“进化”空间

BettaFish 已经是一个完成度非常高且设计精良的系统，它给了我很多关于多智能体协作的启发。

我最喜欢的地方：

“论坛机制”是一个天才的设计。它解耦了所有 Agent，Agent 之间不需要知道彼此的存在，它们只需要“向论坛发言”和“从论坛获取指引”。这种“主持-参与者”模式，比僵硬的“A到B”链条，或混乱的“全体@全体”广播，都要来得优雅和可控。它本质上实现了一种**“群体链式思考”（Group Chain-of-Thought）**。

如果我是作者，我会如何迭代？（基于剖析报告的建议）

通信升级（v2.0）：目前基于文件的通信机制虽然简单可靠，但在高并发下可能会有 I/O 瓶颈和延迟。我会考虑将 forum.log 升级为 Redis 的 Pub/Sub 或 Stream，实现更低延迟的消息队列。
服务化与并行（v2.1）：
- 将 Streamlit UI 与 Agent 核心逻辑分离，把每个 Agent 打包成独立的 FastAPI 微服务，并使用 Docker 容器化。
- Agent 内部的 Node 节点目前是顺序执行的，但很多步骤（比如对多个段落的搜索）完全可以并行。我会引入 asyncio 来实现节点的异步并行处理，大幅提升执行效率。
引入缓存（v2.2）：对于 LLM 的响应和代价高昂的搜索/数据库查询，引入 Redis 缓存是必不可少的，可以有效降低成本和延迟。