Why Multi-Agent?
传统的 AI 对话都是一对一的 — 你问，它答。但现实中的问题往往需要多角度思考。一个技术决策，理性的分析师和创造性的探索者会给出截然不同的建议；一个创意方案，批评者和实用主义者会看到完全不同的盲点。
这个项目的核心问题是：如果我们让多个具有不同人格和专长的 AI 智能体一起讨论，能不能得到比单一 AI 更全面、更有洞见的答案？
这就是 Pluralistic AI Reasoning — 多元化 AI 推理。
Architecture Decisions
Flutter for Everything
选择 Flutter 不是因为它是最流行的，而是因为我们需要真正的跨平台 — Web、iOS、Android、桌面端全覆盖。Multi-Agent Chat 作为一个协作讨论工具，用户可能在手机上快速发起讨论，在桌面上深度参与辩论，或者通过 Web 端分享给没有安装 App 的朋友。
Material 3 的设计语言给了我们统一且现代的 UI 基础，dark/light 主题切换也变得自然。
Firebase as the Invisible Backend
我们选择了 Serverless 架构 — Firebase 提供认证、数据库、实时同步，不需要自己维护任何服务器。Firestore 的 snapshot listener 让多用户实时协作变得简单：
// 毫秒级的实时同步就这么简单
firestore.collection('messages').snapshots().listen((snapshot) {
// 所有群组成员同时看到新消息
});
Unified SSE Engine
一个关键的技术决策：用一个统一的方法处理所有 LLM 提供商。Kimi、DeepSeek、Qwen、Doubao 都支持 OpenAI 兼容的接口，所以我们的 SSE 流式引擎只需要一个核心方法：
Stream<String> _callLLMStream(String endpoint, Map payload) async* {
// 统一处理所有提供商的流式响应
}
只有 Doubao 需要一点点特殊处理（endpoint ID），其余完全通用。
The Interesting Parts
Context Engineering — 上下文工程
LLM 的上下文窗口是有限的。当讨论超过 10 轮时，我们把历史消息压缩成摘要，再用滑动窗口保留最近 6 条消息。这样既保持了对话的连贯性，又不会超出 token 限制。
每条消息在发送给 LLM 时会被分配不同的角色（system/user/assistant），这取决于消息的来源 — 这直接影响 LLM 的回复质量。
@Mention System
@AgentName 触发特定智能体回复，@UserName 将该用户最近的发言注入上下文。这个设计灵感来自团队协作工具中的 @ 提及功能，但在 AI 对话场景下有了新的意义 — 你可以指挥特定的 AI 人格来回应特定的问题。
AI-Assisted Development
这个项目本身也是 AI 协作的一次实践。开发过程中使用了四种不同的 AI 工具：
- Gemini Deep Research — 前期调研和技术选型
- Claude Code — 核心架构和复杂逻辑实现
- Kiro — UI 组件和交互设计
- Antigravity — 调试和优化
这恰好呼应了项目的核心理念：不同的 AI 有不同的擅长领域，协作比单打独斗更有效。
What I Learned
上下文管理是 LLM 应用的核心难题 — 不仅仅是技术问题，更是设计问题。如何在不丢失关键信息的前提下压缩对话历史，这需要精心设计。
Serverless 架构适合快速原型 — Firebase 让我们跳过了后端开发的复杂性，直接专注于产品逻辑。但也有代价：数据模型的设计受到 Firestore 的约束。
多智能体系统的 prompt 设计比想象中更微妙 — 每个智能体的人格设定不仅要定义它的专业领域，还要定义它的表达风格和论证方式，这样对话才会有真正的多样性。
AI 辅助开发改变了编程的方式 — 不是替代开发者，而是让开发者更像一个架构师和指挥者，把实现细节交给 AI，自己专注于设计和决策。
Next Steps
- 添加本地加密存储 API Key
- 支持更多 LLM 提供商（GPT-4, Claude 等）
- 实现讨论结果的智能聚合和可视化
- 探索语音对话模式