第三章技术选型与核心组件

前两章主要回答的是 为什么做、做什么，那么从这一章开始，就真正进入技术部分。

这一章的目标不是讲代码，而是让读者知道：

为什么最终选择这一套技术栈，而不是网上那些五花八门的方案。

这一章的定位应该属于架构设计篇。

没有最好的技术，只有最适合当前阶段的技术。

很多人在做 AI Agent 时，一开始就陷入了一个误区。

今天看到 LangGraph 很火，就去研究 LangGraph；明天看到 AutoGen，又重新推倒重来；后天 MCP 火了，又开始全部重构。

最后折腾了几个月，AI 没做出来，时间倒是全部浪费了。

而我做这个企业微信 AI 助手时，给自己定了一条原则：

一切技术，只为解决问题服务。

所以，在真正开始开发之前，我先确定了整个系统应该满足哪些要求。

3.1 我希望它具备哪些能力？

我给整个 AI 助手列了一张需求清单。

第一，它必须能够接收企业微信消息。

用户发送一句话。

例如：

今天上海天气怎么样？

系统应该能够立即收到这条消息。

第二，它必须能够调用大模型。

收到消息之后，不是自己写死回复，而是把内容发送给 DeepSeek、OpenAI 或 Claude。

例如：

用户：
今天上海天气怎么样？

AI 返回：

今天上海多云，
最高温度 32℃，
建议......

整个过程完全自动完成。

第三，它必须支持上下文。

不能每一句话都是新的聊天。

例如：

用户：
帮我写一封邮件

AI：
好的，请告诉我主题。

用户：
离职申请

AI 必须知道：

第二句话是在继续第一句话。

所以：

必须保存 Session。

第四，它必须能够调用工具（Tool）。

例如：

查天气
查数据库
发邮件
查询库存
调用 ERP

未来这些都会变成 AI 的能力。

因此：

Agent 必须支持 Tool Calling。

第五，它必须方便以后扩展。

今天只有企业微信。

以后可能还有：

微信公众号
飞书
钉钉
Telegram
Slack
WhatsApp
Web Chat

所以：

消息入口不能写死。

必须做成统一 Gateway。

最后，也是最重要的一点。

整个系统必须：

稳定。

我不希望每天半夜两点服务器报警。

也不希望升级一个依赖，全系统崩掉。

所以：

稳定性，比炫技更重要。

3.2 为什么不用一堆现成平台？

很多朋友都会问：

为什么不用 Dify？

为什么不用 Coze？

为什么不用 FastGPT？

为什么不用 LangGraph？

其实，我一开始都试过。

它们都有自己的优点。

但是对于企业微信 AI 助手来说，都存在一些共同的问题。

例如：

很多平台都是：

平台
↓

调用 LLM

↓

输出

它们非常适合：

AI 工作流
AI 应用
ChatBot

但是：

对于企业微信来说。

真正困难的地方不是 AI。

而是：

消息入口。

例如：

企业微信要求：

URL 验证
AES 加密
签名校验
XML
回调
Token
EncodingAESKey

这些并不是 AI 平台负责的。

所以：

最后还是需要自己写接口。

既然入口必须自己写。

那么：

后面的 AI 部分，也可以自由选择。

这样系统反而更加灵活。

3.3 最终确定的整体架构

经过多次尝试，我最终确定了下面这套架构。

            企业微信

                 │

                 │ HTTPS

                 ▼

          OpenResty / Nginx

                 │

                 ▼

         FastAPI Gateway

                 │

        ┌──────────────┐
        │ 消息解密      │
        │ XML解析      │
        │ Session管理  │
        └──────────────┘

                 │

                 ▼

          AI Service

                 │

        ┌──────────────┐
        │ DeepSeek      │
        │ OpenAI        │
        │ Claude        │
        └──────────────┘

                 │

                 ▼

          Tool Manager

      ┌─────┬─────┬──────┐
      │天气 │数据库│ ERP │
      └─────┴─────┴──────┘

                 │

                 ▼

          回复企业微信

整个系统其实只有几个核心模块。

但是职责划分非常清晰。

每一层只做自己的事情。

这也是大型系统设计的重要原则：

高内聚，低耦合。

3.4 为什么选择 FastAPI？

这里很多人会问：

为什么不用 Flask？

毕竟 Flask 更简单。

我的答案很直接：

因为 FastAPI 更适合现代 AI 应用。

它有几个明显优势。

第一：

异步。

调用 AI 接口，本身就是网络 IO。

FastAPI 天然支持 async。

高并发性能明显更好。

第二：

类型提示。

接口参数一目了然。

开发效率非常高。

第三：

自动生成 API 文档。

启动以后。

直接访问：

/docs

所有接口立即可见。

调试效率极高。

第四：

社区已经成为 AI 项目的事实标准。

几乎所有新的 AI SDK。

第一时间都会支持 FastAPI。

因此：

我没有理由继续使用 Flask。

3.5 为什么选择 OpenResty？

很多教程直接暴露 Python 服务。

例如：

公网直接访问。

这种方式我并不推荐。

我的做法是：

Internet

↓

443 HTTPS

↓

OpenResty

↓

127.0.0.1:8000

这样做有几个好处。

第一：

SSL 全部交给 OpenResty。

第二：

统一域名。

第三：

统一日志。

第四：

支持限流。

第五：

以后可以做负载均衡。

甚至：

未来增加多个 AI 节点。

都不需要修改 Python。

OpenResty 就可以完成流量分发。

3.6 为什么选择 DeepSeek？

目前的大模型越来越多。

OpenAI。

Claude。

Gemini。

Qwen。

DeepSeek。

为什么最终选择 DeepSeek？

原因很简单。

对于国内开发者来说。

它具有几个明显优势。

首先：

中文能力非常强。

其次：

API 成本低。

第三：

响应速度快。

第四：

兼容 OpenAI API。

意味着：

几乎所有 SDK。

都可以直接接入。

未来如果更换模型。

甚至不用改业务代码。

只需要修改：

Base URL

API Key

Model Name

即可完成切换。

这种架构叫做：

模型解耦。

3.7 为什么不用 LangChain？

很多 AI 教程都会使用 LangChain。

它确实很强。

但是：

对于当前这个项目。

我最终没有采用。

原因只有一句话。

过度设计。

我们的需求其实很简单。

收到消息

↓

调用模型

↓

返回结果

整个流程不到几十行代码。

如果引入 LangChain。

反而会增加：

学习成本
调试成本
升级成本
依赖冲突

等未来真正需要：

Memory
Agent
Tool Calling
多 Agent

再逐步引入也完全来得及。

软件开发中有一句经典的话：

You Aren’t Gonna Need It（YAGNI）——你不会需要它。

提前设计大量暂时用不到的能力，往往会让系统变得更复杂，而不是更优秀。

本章小结

技术选型，并不是追逐最新、最热门的框架，而是根据项目目标做出权衡。

对于企业微信 AI 助手来说，我们真正需要的是一套能够长期稳定运行、便于扩展、易于维护的架构。

因此，本书最终采用了以下核心技术组合：

OpenResty：统一 HTTPS 入口、反向代理、安全控制与流量管理。
FastAPI：实现企业微信回调接口、消息处理和 AI 服务。
DeepSeek（兼容 OpenAI API）：作为默认的大模型服务，同时保留切换其他模型的能力。
企业微信回调机制：负责消息接收、AES 解密、签名校验和响应。
Tool Manager（工具层）：统一封装天气查询、数据库、ERP、邮件等业务能力。
Session 管理：维护多轮对话上下文，为后续 Agent 能力打下基础。

这套架构遵循了"入口统一、业务解耦、模型可替换、工具可扩展"的设计思想，也将成为后续所有章节实现的基础。

下一章，我们将正式进入系统架构设计，逐步搭建整个企业微信 AI 助手的完整工程框架。

这一章已经完成了技术选型部分。下一章建议进入《第四章：系统整体架构设计》，将开始绘制整体架构图，并详细拆解消息流、模块职责、目录结构以及部署拓扑，为后续编码做好准备。

第三章 技术选型与核心组件