- 1:一、框架选择
- 1.1:1.大模型应用平台 Dify
- 1.2:2.微信聊天接口 Gewechat
- 1.3:3.聊天机器人 Dify-on-wechat
- 2:二、安装
- 3:三、配置Dify应用
- 4:附加 function calling 与 React对比
- 4.1:1. 定位与目标
- 4.2:2. 交互方式
- 4.3:3. 流程复杂度
- 4.4:4. 实现示例
- 4.5:5. 优缺点对比
- 4.6:6. 适用场景
- 4.7:总结
一、框架选择
-
1.大模型应用平台 Dify
网址：https://dify.ai
Dify 是一个开源的 LLM 应用开发平台，提供从 Agent 构建到 AI 工作流编排、RAG 检索、模型管理等能力，轻松构建和运营生成式 AI 原生应用。比 LangChain 更易用。 由于 Dify 内置了构建 LLM 应用所需的关键技术栈，包括对数百个模型的支持、直观的 Prompt 编排界面、高质量的 RAG 引擎、稳健的 Agent 框架、灵活的流程编排，并同时提供了一套易用的界面和 API。这为开发者节省了许多重复造轮子的时间，使其可以专注在创新和业务需求上。 -
2.微信聊天接口 Gewechat
网址：https://github.com/Devo919/Gewechat
gewechat的作用是模拟一个微信客户端，并向外提供一系列的功能接口，如：登录、获取好友列表、接收消息、发送消息（文字、图片、链接）等等。
框架优势
简单易用，无接入难度。比itchat安全，不易封号，区别于其他开源项目，本框架无需用户安装电脑微信，无需安装手机破解插件，只需扫码登录即可使用，操作简单。
主要功能
-
-
- 消息自动化：可向指定对象（好友、群组）发送文本、图片、文件、emoji 表情、小程序、语音等消息。
- 自定义消息处理：支持自动回复、自定义关键词回复、AI 回复、各种自定义类型、RPA 自动化业务交互。
- 群管理及好友管理：设置好友备注、邀请好友统计、拉好友进群等。
-
-
3.聊天机器人 Dify-on-wechat
网址：https://github.com/hanfangyuan4396/dify-on-wechat
作为连接Dify和gewechat的桥梁，把收到的消息转成Dify API需要的格式，再把Dify返回的内容转成gewechat的格式。
二、安装
Dify、gewechat、dify-on-wechat采用 Docker 进行安装。
- Dify安装
- 1.下载源码 2.修改环境参数.env文件 3.使用docker compose创建docker服务。
- gewechat安装
- 拉取镜像
docker pull http://registry.cn-hangzhou.aliyuncs.com/gewe/gewe:latest docker tag http://registry.cn-hangzhou.aliyuncs.com/gewe/gewe gewe
- 运行镜像容器
mkdir -p /root/temp docker run -itd -v /root/temp:/root/temp -p 2531:2531 -p 2532:2532 --privileged=true --name=gewe gewe /usr/sbin/init
- 将容器设置成开机运行
docker update --restart=always gewe
- dify-on-wechat安装
- 1.下载源码 2.修改环境变量.evn 3.使用docker运行服务。
{
"channel_type": "gewechat",
"dify_api_base": "http://dify/v1",
"dify_api_key": "dify应用的key",
"dify_app_type": "agent/chatbot/workflow 根据dify创建的应用类型选择",
"gewechat_app_id": "gewechat生成的ipad设备id，初始不用填gewechat返回后自动传入",
"gewechat_base_url": "http://gewechat:2536/v2/api",
"gewechat_callback_url": "http://dify-on-chat:9919/v2/api/callback/collect",
"gewechat_download_url": "http://gewechat:2537/download",
"gewechat_token": "gewechat微信id，用来区分微信账户",
其余参数根据实际情况自行配置...
}
三、配置Dify应用
dify应用创建可以查看官方文档https://docs.dify.ai/zh-hans
使用dify创建的应用交互方式有多种：1.使用dify提供的界面 2.使用dify提供的iframe代码嵌入到已有的web页面中 3.使用api的方式
dify-on-wechat使用的是api的方式，dify-on-wechat已经提供好对接接口了，只需要配置app-key就可以。
附加 function calling 与 React对比
大语言模型（LLM）的工具调用能力是其扩展功能边界的关键技术，Function Calling和ReAct是两种典型的实现方式。以下是两者的对比分析：
1. 定位与目标
| 维度 | Function Calling | ReAct |
|---|---|---|
| 核心目标 | 结构化调用外部工具（API/函数） | 结合推理（Reasoning）和行动（Acting）解决问题 |
| 设计理念 | 工具导向：模型直接触发预定义的工具调用 | 过程导向：模型自主规划推理步骤和工具调用 |
| 适用场景 | 简单、明确的工具调用需求（如天气查询、计算器） | 复杂、多步骤的任务（如数据分析、多工具协作） |
2. 交互方式
| 维度 | Function Calling | ReAct |
|---|---|---|
| 输入输出格式 | 依赖结构化输入/输出（如JSON Schema） | 基于自然语言生成推理步骤和动作指令 |
| 调用过程 | 模型直接返回工具名和参数，开发者执行工具并反馈结果 | 模型自主生成推理链（如“Think: ...”）和动作（如“Action: call_api(...)”） |
| 灵活性 | 工具需预先定义，调用逻辑固定 | 动态生成调用步骤，支持多工具组合和复杂逻辑 |
3. 流程复杂度
| 维度 | Function Calling | ReAct |
|---|---|---|
| 单次调用 | 单次请求-响应，适合简单任务 | 可能需多轮交互（思考→行动→观察→再思考） |
| 错误处理 | 依赖开发者处理工具调用失败 | 模型可通过推理修正错误（如参数错误后重新尝试） |
| 可解释性 | 黑盒调用，缺乏中间过程展示 | 白盒过程，推理链提供透明解释 |
4. 实现示例
Function Calling
# 预定义工具（如天气查询）
tools = [{
"name": "get_weather",
"parameters": {"location": "string"}
}]
# 模型返回结构化调用请求
response = llm.generate(
query="北京天气如何？",
tools=tools
)
# 输出示例：{"name": "get_weather", "parameters": {"location": "北京"}}
ReAct
用户问：上海人口比北京多吗？
模型输出：
Think: 需要分别查询上海和北京的人口数据，再比较。
Action: call_api("get_population", {"city": "上海"})
Observation: 上海人口为2487万。
Think: 现在查询北京的人口。
Action: call_api("get_population", {"city": "北京"})
Observation: 北京人口为2184万。
Think: 比较结果：上海人口更多。
Answer: 上海人口（2487万）比北京（2184万）多。
5. 优缺点对比
| 维度 | Function Calling | ReAct |
|---|---|---|
| 优点 | - 开发简单，适合标准化工具 - 低延迟 |
- 灵活处理复杂任务 - 支持自主纠错和推理 |
| 缺点 | - 依赖预定义工具 - 无法处理多步骤逻辑 |
- 生成过程长，延迟高 - 需要解析自然语言输出 |
6. 适用场景
- Function Calling：
适合工具接口固定、任务简单的场景（如查询类API、计算器）。 - ReAct：
适合需动态规划、多工具协作的任务（如复杂问题解答、数据分析）。
总结
- 选择Function Calling：若需求明确、工具固定，追求快速开发和高效率。
- 选择ReAct：若任务复杂、需动态推理，且对可解释性要求高。
- 混合使用：实践中可结合两者（如用ReAct规划流程，用Function Calling执行具体调用）。