14 篇博文 含有标签「软件架构」

系列终章：至此，我们已经完成了 nanobot 基础架构的 10 篇深度解析。从仅仅 3400 行代码的极简内核，到能够连接四大主流平台的通用 Agent，我们见证了一个 AI 助手的诞生。但这仅仅是开始。

系列导读：在上一篇，我们解决了记忆持久化的问题。现在，我们来到整个系统的"心脏"——大语言模型（LLM）。OpenAI, Anthropic, Gemini, DeepSeek, Groq... 新模型层出不穷，API 各有千秋。nanobot 如何从容应对？答案就是 Provider 层。

系列导读：在上一篇，我们解决了 nanobot 与世界的连接问题。但一个真正的智能助手，不仅要能"听"和"说"，还要能"记住"。如果你告诉它你的名字，第二天它却忘了，那体验简直糟糕透顶。本篇将深入探讨 nanobot 的记忆系统。

系列导读：在上一篇《消息总线与事件系统》中，我们构建了 nanobot 的通信骨干。现在，我们要把这个骨干连接到真实世界——Telegram、Discord、WhatsApp 和飞书。这就是 Channel Adapter（渠道适配器） 的工作。

系列导读：在前面的文章中，我们介绍了 Agent 核心引擎和工具系统。那么，各个组件之间是如何通信的？如何确保系统的高内聚低耦合？答案就是 Message Bus（消息总线）。

系列导读：在上一篇《Agent 核心引擎解析》中，我们了解了 nanobot 的大脑是如何工作的。但光有大脑是不够的，AI 还需要"双手"来与现实世界交互——读写文件、搜索网络、执行命令。本篇将深入探讨 nanobot 的工具系统，这是 Agent 能力扩展的关键。

系列导读：在上一篇《架构总览与模块划分》中，我们从宏观视角认识了 nanobot 的四层架构。现在，让我们深入核心引擎层——agent/ 模块，揭开 nanobot "智能"的神秘面纱。这里是 AI 助手真正"思考"的地方。

系列导读：在前三篇文章中，我们了解了 nanobot 的设计哲学、完成了安装配置、并学会了接入多个聊天渠道。现在是时候打开引擎盖，看看这台"极简机器"是如何运转的了。本文将带你从宏观视角审视 nanobot 的整体架构——先见森林，再见树木。

系列导读：在上一篇文章中，我们完成了 nanobot 的基础安装和配置，实现了命令行对话。但真正的 AI 助手应该能在你常用的聊天工具中随时待命——Telegram、Discord、WhatsApp、飞书……本文将手把手教你配置每个渠道，让 nanobot 真正"无处不在"。

系列导读：在上一篇文章中，我们认识了 nanobot——一个仅用 3400 行代码实现的超轻量级 AI 助手。现在，让我们卷起袖子，一步步把它跑起来！本文将从环境准备到第一次成功对话，手把手带你完成整个配置过程。

系列导读：欢迎来到 nanobot 深度解析系列！这是第一篇文章，我们将从宏观视角认识这个项目——它是什么、为什么诞生、以及它如何用极简的代码量实现了完整的 AI 助手功能。如果你曾好奇"一个真正能用的 AI Agent 到底需要多少代码"，这篇文章会给你一个令人惊喜的答案。

MCP是什么​

MCP 是一种开放协议，它规范了应用程序如何向大语言模型提供上下文。可以把 MCP 想象成人工智能应用的 USB-C 端口。就像 USB-C 为连接设备与各种外设和配件提供了一种标准化方式一样，MCP 为将人工智能模型与不同的数据源和工具连接起来提供了一种标准化方式。

本文介绍了C++设计模式的六大原则，包括单一职责、里氏替换、依赖倒置、接口隔离、迪米特法则和开放封闭原则，并对常用的设计模式进行分类讲解。

SOLID是五条原则的英文首字母拼接，这五条原则指的是：

• SRP：单一职责原则

  一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。这样，每个软件模块都有且只有一个需要被改变的理由。

• OCP：开闭原则

  核心要素是：如果软件系统想要更容易被改变，那么其设计就必须允许新增代码来修改系统行为，而非只能靠修改原来的代码。

• LSP：里氏替换原则

  如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换。

• ISP：接口隔离原则

  这项设计原则主要告诫软件设计师应该在设计中避免不必要的依赖。

• DIP：依赖反转原则

  该设计原则指出高层策略性的代码不应该依赖实现底层细节的代码，恰恰相反，那些实现底层细节的代码应该依赖高层策略性的代码。

SOLID原则的主要作用就是告诉我们如何将数据和函数组织成为类，以及如何将这些类链接起来成为程序。下面会分别介绍这五条设计的原则，以及给出相应的代码示例。