我的个人项目 MiraMate 始于 2025 年五月，但在此之前，我已经花了大半年时间学习和探索相关的技术栈，包括 Langchain、ChromaDB 和 Faiss 等智能体（Agent）技术。这是我第一个真正意义上的完整个人项目，与我之前接触的以 Java 后端为主的练习项目截然不同。
这篇文章，我想记录一下它从 v1 到 v2 的一次彻底重构之旅。
V1 的诞生：一次对多 Agent 架构的探索
在项目初期，由于接触了 Autogen，与主流的单 Agent 架构截然不同，让我对多 Agent 架构有了一些美好的设想。我从 ChatGPT 爆火的 GPT-3.5 开始就密切关注 LLM 的发展，但始终觉得单个 LLM 的能力在”模仿真人情感表现”上还是非常不足。因此参考人类社会的分工协作，我认为多 LLM 的合作可能能带来优势，此时我对 LLM 的认知还没到真正的”Agent”的程度。我的想法是让多个 Agent 协同工作，共同扮演一个生动、丰富的 AI 角色。
基于这个想法，我选择了由微软开源的 autogen 框架，它正是为此类多 Agent 协作场景而设计的，该框架宣传的核心场景就是让多个不同角色的 LLM 像专家讨论一样在一个群聊里进行商讨，这也是我在项目开始前设想的 Agent 设计逻辑。
经过大约两个月的开发，MiraMate v1 诞生了。它具备了：
- 一个完整的 AI 对话流程。
- 一套基于向量数据库的记忆系统。
- 一个用 Electron 编写的 Windows 客户端。
在这个阶段，我犯了一个关键的错误：过度依赖 AI 辅助编程。主要是在我不熟悉的客户端开发部分，我使用 Electron 开发 Windows 客户端，由于不熟悉 TS 和 Web 开发，大部分代码都直接由 AI 生成，没有利用 LLM 进行充分的 review，并不彻底。这种并不熟练的“高效”的开发模式，为项目后期的困境埋下了伏笔。
当项目悄然变成“屎山”
v1 版本虽然功能可用，但很快就暴露出了一系列严重问题：
- 大量的隐形 BUG： AI 生成的代码逻辑不够严谨，导致许多难以追踪和修复的暗病。
- 拓展性极差： 混乱的代码结构使得添加新功能变得异常困难，每走一步都举步维艰。
- AI 表现不佳： 核心的 AI 体验，如记忆检索、对话流畅度和上下文管理，都存在明显的问题。
它逐渐变成了一座典型的“屎山”。
除此之外，我对多 Agent 架构的理解也加深了，我很意识到这个粗浅设计存在三个严重问题：
-
速度太慢，这几乎是最严重的问题，在单 LLM 直接输出的情况下可以通过流式输出实现减少用户等待回复的不好体验，但是这在多 LLM 讨论的情景下完全无效，多个 LLM 来回输出讨论会带来严重的首字延迟，即使尽可能地优化了流程、缩减流程、避免使用思考模型或启用思考模式、为不同角色分配不同尺寸的 LLM，首字延迟都在 20s 以上。
-
多 LLM 合作的效果并不如我想象中的好，几个不同职责的 LLM 在我尚且生疏的提示词设计能力下显得有些“多余”，而且他们对于各自关注的问题的细致分析反倒有些缺少了整体的考虑。
-
多 LLM 合作的工程复杂性较高，想要很好地发挥他们合作的效果要考虑的不只是给什么角色，决定什么发言顺序，这是一个极其复杂的工程难题，而设计一套完整的合作机制放在这个对话系统中又显得太过复杂，且由于第一个问题，也不能做太复杂的编排设计，陷入了死胡同。
恰逢那时我需要应对学校的考试，开发进度被迫停滞了一段时间。这段“冷却期”反而让我有机会沉下心来，重新审视 MiraMate 的未来。
决断：彻底重构
经过几周的思考，我得出了一个明确的结论：在现有基础上修修补补已经没有意义。我决定彻底重构整个项目。
这次重构的核心是放弃 autogen 的多 Agent 架构——它的实际表现并不如理论上那般理想。我选择了社区更成熟、生态更丰富的 Langchain 作为新的核心框架。
V2 的新生：回归代码的掌控
在新的 V2 项目中，我几乎重写了所有代码。借助 V1 的经验教训和新学习的知识，新项目的代码质量和逻辑性都有了质的飞跃，并且我做了一个核心改动：从多 Agent 架构改为 Langchain 的 LCEL 链式流程控制。
Agent 的核心逻辑从多 Agent 的对话交流改为流水线的文本处理，延续一部分 V1 原有思路并细化，先做用户情绪识别、上下文关键词识别，然后从记忆系统获取相关记忆信息，主 LLM 根据前两个环节获取的信息和对话上下文进行回答输出，输出完成后异步地处理，识别并提取本次对话的情绪情感、关键词、概括信息，用户提及的关键个人信息、偏好、需要记录的重大事件等内容存入记忆库。
因此为了优化模拟效果，我着重在以下几个方面进行了重新设计：
-
全新的情感与记忆系统： 我设计了一套“记忆系统 + 状态系统”相结合的情感管理机制。这套系统更符合人类的记忆习惯，能够让 AI 更智能地查询和利用记忆，从而做出更富有人情味的反馈。
-
自定义上下文管理： 我编写了一个自定义的上下文管理逻辑，它不再是简单的截断或压缩，而是能更好地模拟现实对话情景，适配了更具弹性的对话时间窗口。
-
可控且可拓展的对话流程： 我重新设计了整个对话流程，极大地加强了对 AI 行为的控制力。并且，在每一个模块和接口的设计上，我都预留了充足的拓展空间，为未来的功能迭代铺平了道路。
从 V2 的开发我加深了对大模型应用的理解，尤其在流程控制、LLM 能力、RAG 设计、对话系统设计等方面。
在这个项目中我深切感受到 Langchain 的强大，尤其是这些功能：
- 封装的 LLM 对象，Langchain 将 LLM API 抽象为 LLM 对象，在后续的调用中极大的简化了代码和思考理解负担。
- Runnable 管道设计，通过将每一段的业务处理封装为抽象的 Runnable 对象，利用 DAG（有向无环图）进行业务编排，自动传递每个环节的参数，这种抽象模式在一开始的接触中会比较难理解，但是熟悉后能带来很大的便利。
- 完善的工具类设计，Langchain 包含丰富的上下文管理相关工具、RAG 工具、LLM 调用方法，比如 RunnableWithMessageHistory，能配置自定义上下文管理类来实现极少代码的自动上下文注入、添加、管理等功能。
相比于 V1，V2 在项目水平上有了巨大的提升。这不仅仅是技术框架的更替和知识的学习深入，更是一次开发思想上的转变——从追求快速实现，到注重代码质量、可维护性和长期发展的回归。这次重构虽然耗费了巨大的精力，但它让 MiraMate 真正走上了一条可持续发展的道路。
你可以在 GitHub 上看到这两个截然不同的版本：