1. 先想清楚你接入的到底是“微信”还是“微信生态”先说结论这篇想讲的事就是把一个本地跑起来的大语言模型接到微信生态里让它替你回复消息。模型名字我用的“龙虾”——这是社区里对某类开源中文大模型的一个通称别较真你可以理解成“本地部署的开源对话模型”的代号。重点是整条链路怎么打通、怎么合规、怎么让新手不掉进坑里。我最初的想法很简单能不能让我自己的微信收到消息之后自动让AI帮我回于是先搜了一圈。结果发现大部分号称“个人微信接入AI”的方案走的路子都让人很不踏实——要么是模拟网页版微信协议要么是抓客户端数据搞HOOK。这些方案确实能跑看起来也方便但本质是在和微信的安全机制对着干。轻则频繁“操作频繁”验证重则直接封号。我见过有人折腾了半个月号一封前功尽弃。所以各位接AI没问题但接的通道必须是官方允许的这一条不能妥协。那普通人到底能走哪些官方路线说白了微信生态里真正开放了消息回调、能实时收发消息的入口主要就是两个方向方案适合场景门槛风险个人微信自动化模拟协议想直接控制自己微信App低工具现成高容易封号企业微信自建应用个人/小团队做AI助理、客服机器人中要写点代码低官方API公众号/服务号面向粉丝的自动回复较高认证门槛低但接口权限受限我个人实测下来个人想玩得顺、体验又接近微信聊天的就是企业微信自建应用这条路。客户那边看到的是普通微信聊天窗口你这边通过官方API收发消息完全在规则内运行。这也就是标题里“官方合规直连”的真正含义——不是绕过微信而是站在微信生态的官方接口上把AI挂进去。2. “龙虾”模型的本地部署一台普通电脑就能跑2.1 为什么我选本地模型而不是接云端API其实一开始我也动过接云端大模型API的念头注册方便、效果也好。但后来算了笔账每天几百条消息长上下文聊天一个月下来API费用足够吃好几顿小龙虾了。而且消息全要经过第三方服务器虽然大厂不会乱看但心里总归不太踏实。本地模型的好处就出来了模型文件下载到自己电脑或服务器上对话请求走本地地址完成数据不出内网运行过程完全可见——用的是哪个模型文件、每次推理消耗多少token、回复逻辑是什么全都可以查这就是标题里“模型运行清晰”的意思。那为什么选“龙虾”系列因为我需要的是中文对话效果好、体量适中、消费级硬件能跑的模型。现在的开源社区里有很多好选择我用的这个7B规模的量化版就是典型代表单个权重文件大约4~6GB笔记本的显卡就能跑对话质量对个人助理场景完全够用。提示别盲目追求大模型。7B量化版在很多场景下比14B半精度版更实用因为回复速度快微信场景下体验更流畅。2.2 Ollama部署一行命令拉模型如果你完全没接触过模型部署听我说别自己去下载权重再折腾推理脚本直接用Ollama这类一键部署工具就行。它把模型管理、下载、启动、本地API全封装好了装完不用配环境终端里敲命令就能跑。具体步骤很简单到Ollama官网下载对应操作系统Windows/macOS/Linux的安装包双击安装命令行里出现ollama命令就算成功。打开终端输入ollama run lobster:7b-chat-q4_K_M第一次运行会自动下载模型权重下载完成后直接进入对话界面你打一句它回一句。退出对话输入/bye查看已装模型用ollama list。如果你只有CPU没有独立显卡也别灰心选更小的3B/4B蒸馏版内存16GB就能跑速度虽然谈不上飞快但日常回复够用了。我自己是在一台8GB显存的老电脑上跑的量化版模型加载后占用不到6GB显存推理时生成速度大概十几token每秒普通对话完全能接受。2.3 确认本地API已经可用Ollama装好模型之后默认会在本地监听11434端口它同时提供了一个兼容OpenAI格式的HTTP接口。验证方式很简单另开一个终端执行curl http://127.0.0.1:11434/api/generate -d { model: lobster:7b-chat-q4_K_M, prompt: 你好介绍一下你自己, stream: false }如果返回一段JSON里面有response: ...说明本地模型服务已经就绪了。这就是后面微信消息和模型之间的桥梁——你只需要写一个小程序把微信收到的文字转发给这个接口再把接口返回的文字发回微信。这一步跑通之后相当于你在自家电脑里养了一只“龙虾”它随时等你来投喂问题。2.4 给“龙虾”定制一个说话风格直接用的模型回复风格偏“通用助手”放到微信场景里显得太正式。我更希望它像个朋友说话简短、口语化、不端架子。Ollama支持通过Modelfile定制角色设定操作不复杂。新建一个Modelfile文件内容写FROM lobster:7b-chat-q4_K_M SYSTEM 你是我微信上的个人AI助理名字叫小龙虾。 回答要求 1. 简短口语化像朋友聊天不要用“您好”“亲爱的”这类客套词 2. 如果用户问复杂问题可以分点说明但每点不超过两行 3. 不确定的事直接说不知道不要编。然后在终端执行ollama create lobster-assistant -f Modelfile ollama run lobster-assistant这样你本地就有了一个带“人设”的模型实例后续程序调用时把模型名从lobster:7b-chat-q4_K_M改成lobster-assistant就行。3. 企业微信侧配置百分之八十的人卡在这一步3.1 注册企业微信、创建自建应用模型准备好了接下来是微信侧。企业微信个人也是可以注册的不用非得是公司。流程是下载企业微信App并注册一个企业哪怕只有你一个人也算一个企业。登录企业微信管理后台找到“应用管理” - “自建应用” - 创建应用。应用创建完成后你会拿到一个AgentId应用ID和Secret应用密钥这俩是关键凭证先记下来。自建应用在管理后台里有点像“一个小机器人账号”它可以收到成员发给它的消息也能主动向成员发消息还能被添加到微信客户联系人里。我们就是拿它当AI助理的“替身”。3.2 配置接收消息服务器从验证URL开始这是整个接入流程里最容易劝退新手的地方。很多教程在这里直接甩一个加密解密的代码把人看晕。我的建议是开发联调阶段先用明文模式跑通逻辑再考虑加密。在企业微信管理后台的自建应用配置页里找到“接收消息服务器配置”需要填三样东西URL你的服务地址必须是一个公网能访问到的HTTP地址端口建议用80或443。Token自己随便填一个字符串相当于一个简单的口令。EncodingAESKey点随机生成即可。URL验证的逻辑是这样的企业微信用GET请求访问你的URL并且在URL里带上echostr参数。你的服务只需要原样把这个参数返回给企业微信就算验证通过。这就像微信端喊了一声“暗号”你回答一声“暗号收到”双方就算握手成功了。我第一次试的时候URL填的是自己电脑的本地地址结果一直验证失败。后来才明白企业微信服务器在公网上它访问不到我电脑的局域网地址。解决思路有两个一是把服务部署到一台云服务器上二是在本地做内网映射。新手我强烈建议直接上云服务器最便宜的那种1核2G的都够跑这个中间服务一个月成本很低还省去各种公网网关的麻烦。如果非要在本地调试可以用frp这类开源内网穿透工具把本机的服务端口映射到一台有公网IP的机器上但配置起来多一层工作新手别一开始就碰。我用一个极简的Flask服务演示验证过程from flask import Flask, request app Flask(__name__) app.route(/wechat, methods[GET]) def verify_url(): # 企业微信验证URL时会带 echostr 参数原样返回即可 echostr request.args.get(echostr) return echostr or if __name__ __main__: app.run(host0.0.0.0, port80)把这个代码跑在云服务器上URL填http://你的域名或IP/wechat在后台点“保存”。如果后台显示“验证成功”说明第一步通了。注意企业微信要求回调URL必须能公网访问并且参数名必须严格使用echostr。有的老教程写的是echo_str照抄就会验证失败这种细节一旦踩了排查起来很折磨人。3.3 明确“明文模式”的意义在接收消息配置里企业微信支持选择“明文模式”或“加密模式”。明文模式下企业微信推给你的消息是直接可读的JSON你不需要处理AES加解密返回回复时直接返回明文JSON即可。缺点是这样的配置不太适合生产环境消息内容理论上容易被中间人截获而且企业微信官方本身也更建议用加密模式。我的路线是先用明文模式把全流程跑通让AI回复能成功推到聊天窗口再去研究加密。这样一次只面对一个问题排查起来不会一头雾水。等你在明文模式下实现了“发消息-收到回复”的全链路再切换加密模式无非是多写一段加解密工具函数而已。4. 中间服务把微信消息转给“龙虾”再把回复转回来4.1 整体架构一句话讲清楚整个系统的调用关系是这样的微信用户或你自己在聊天窗口给企业微信应用发消息 - 企业微信服务器把这条消息POST到你的回调URL - 你的中间服务Flask提取文本内容 - 把文本发给本地Ollama的“龙虾”模型 - 模型返回回复文本 - 中间服务把回复字符串包装成企业微信要求的JSON格式作为HTTP响应返回 - 企业微信服务器把回复推送到用户的聊天窗口。注意这里说的“微信用户”有两种情况如果你把应用发给你的微信客户那客户用微信就能直接和企业微信应用聊天如果只是自己测试那在企业微信App里给自己的应用发消息也行。4.2 核心代码实现明文模式下接收消息其实就是一个POST请求。企业微信用JSON体把消息推过来文本消息的关键字段是MsgType、Content、FromUserName、ToUserName。把第2章讲过的Ollama调用和第3章的回调服务拼在一起就是一个完整的中间服务from flask import Flask, request import requests import time app Flask(__name__) OLLAMA_URL http://127.0.0.1:11434/api/generate MODEL_NAME lobster-assistant def chat_with_lobster(prompt): r requests.post( OLLAMA_URL, json{ model: MODEL_NAME, prompt: prompt, stream: False }, timeout30 ) data r.json() return data.get(response, 抱歉我刚刚走神了再说一遍) app.route(/wechat, methods[GET, POST]) def wechat_callback(): if request.method GET: # URL验证 return request.args.get(echostr, ) # POST收到消息 data request.get_json() if not data: return error msg_type data.get(MsgType) content data.get(Content, ).strip() from_user data.get(FromUserName, ) to_user data.get(ToUserName, ) if msg_type text and content: reply chat_with_lobster(content) return { ToUserName: from_user, FromUserName: to_user, CreateTime: int(time.time()), MsgType: text, Content: reply } # 非文本消息暂不处理 return ok if __name__ __main__: app.run(host0.0.0.0, port80)跑起来之后再做一次测试在企业微信里给应用发一条“你好”正常情况下几秒后就能收到龙虾模型的回复。这里有个容易忽略的坑被动回复必须要在5秒内响应。Ollama是本地推理如果显卡性能一般或者模型首次加载还没驻留内存生成一个稍微长一点的回答很容易超过5秒。新手机器人“已读不回”的尴尬场面多半就是这么来的。解决思路后面第5章会细讲。4.3 被动回复与主动发送的区别上面这段代码属于“被动回复”——企业微信发请求过来你在响应里直接塞回消息。这种方式简单但有局限你只能在收到消息之后回不能主动给用户发一条。如果需要“异步回复”——比如收到消息后先回一句“我思考一下”等模型算完再补发结果——就需要用主动发送接口def send_text_message(access_token, agent_id, user_id, content): url https://qyapi.weixin.qq.com/cgi-bin/message/send payload { touser: user_id, msgtype: text, agentid: agent_id, text: {content: content} } headers {Content-Type: application/json} r requests.post( f{url}?access_token{access_token}, jsonpayload, headersheaders, timeout10 ) return r.json()注意这里的access_token需要单独通过企业微信API获取并且有有效期限制正常要写一个带缓存的获取函数不能每次请求都去拉一次。这个先不展开新手先跑通被动回复能收到AI的消息就已经成功一大半了。5. 联调实录第一次跑通的全过程以及我踩过的坑5.1 卡了我两个小时的URL验证第一次联调时我没看官方文档直接就找网上的教程抄了一段代码。抄的时候发现别人的代码里返回的参数名是echoStr大小写和我后台配置的不一致。企业微信的验证要求在取参数时严格区分大小写参数名就是全小写的echostr。这个看起来不起眼的问题让我误以为是IP、端口、防火墙的问题排查了很久。后面我学乖了在Flask的入口加了一行日志打印所有请求参数print(request.args)一打印就明白了请求里带的是echostr而代码读的是echoStr自然拿不到值。所以说联调阶段花十分钟在服务里加几行print日志比瞎猜高效得多。5.2 模型冷启动导致的“首答超时”URL验证通过后我兴冲冲地给应用发了一条“介绍下你自己”等了二十多秒聊天窗口里没有任何回复。一看Flask日志发现请求是收到了但chat_with_lobster还在阻塞中——因为这是当天第一次调用Ollama模型权重要从磁盘加载到显存冷启动特别慢。解决办法也简单启动时预热一次。chat_with_lobster(你好请简短回复。)把这个放在Flask服务启动之后立刻调用一次让模型常驻显存。Ollama默认会在模型不活动约5分钟后卸载它所以如果长时间没消息下一次请求还是会被冷启动拖慢。稳妥的做法是在服务里加个定时任务每两三分钟主动请求一次模型让它别睡过去。等你实际使用后就会发现这个“心跳包”比什么调优都管用。5.3 对话没有记忆它记不住两轮前说过的话第一次收到模型回复时效果还行但很快就发现一个问题我说“我叫王小明”它答了句“很高兴认识你”隔两轮再问“我叫什么”它就答不上来了。因为上面的示例代码每次调用都只把当前这句话发给模型模型没有上下文。要想让它有记忆就得自己维护一个历史消息列表每次把最近N轮对话拼接起来一起发给模型memory {} def build_prompt_with_history(user_id, latest_text): history memory.get(user_id, []) history.append(f用户: {latest_text}) # 只保留最近10条防止对话太长影响速度和消耗 history history[-10:] memory[user_id] history prompt \n.join(history) \n助手: return prompt这样每次请求时prompt里都带着之前的对话记录模型自然能“想起来”。但要注意普通全局字典在并发请求下会互相覆盖如果应用正式对外服务得加锁或用Redis这种独立存储否则两个用户同时在聊天消息历史会串台。我自己是先在本机单人测试用全局字典后来放入口加了个简单的线程锁才避免这个问题。5.4 温度参数调优从“满嘴跑火车”到“安安静静回答”默认温度下模型回消息有时候过于“活泼”问它今天天气它能扯出一段抒情散文。做微信助理这种风格不太合适。我把Ollama请求体里的options加上了温度控制json{ model: MODEL_NAME, prompt: prompt, stream: False, options: { temperature: 0.3 } }温度越低模型输出越稳定、越保守。我把0.3作为默认值如果聊天气氛比较轻松可以适当调回0.7。这个参数对体验的影响比很多人想象中大建议一次性试几种温度找自己最能接受的平衡点。5.5 被动回复超时的终级解法如果你觉得“先回一句再异步补发”更稳妥用一个高并发的思路来做收到消息时立刻返回“收到正在思考中”同时开一个线程去调用模型等模型返回后再用主动发送接口把结果推过去。这样即使模型推理花了30秒用户也不会觉得这条消息“石沉大海”顶多是觉得回复慢一点。import threading def handle_message_async(data): content data.get(Content, ) from_user data.get(FromUserName, ) to_user data.get(ToUserName, ) prompt build_prompt_with_history(from_user, content) reply chat_with_lobster(prompt) # 这里调用 send_text_message 把 reply 发出去 send_text_message(access_token, agent_id, from_user, reply) app.route(/wechat, methods[POST]) def wechat_callback(): data request.get_json() thread threading.Thread(targethandle_message_async, args(data,)) thread.start() return { ToUserName: data.get(FromUserName, ), FromUserName: data.get(ToUserName, ), CreateTime: int(time.time()), MsgType: text, Content: 收到我这就去想稍等一下。 }用这个方案要注意主动发送接口对企业微信的调用频率有限制个人自建应用每天的量级足够用但如果做对外服务还是要做频率控制。6. 上线前必须想明白的三件事6.1 服务跑在哪本地电脑还是云服务器如果你只在测试阶段用frp把本地服务映射到公网就行。但真正常期挂着用我个人建议把中间服务和模型都放到一台云服务器上这么做的好处是稳定不受家里断电、断网、电脑休眠影响。不过本地模型对硬件要求高一台带GPU的云服务器价格不便宜。折中的方案是中间服务放云服务器Ollama模型放在有独立显卡的本地电脑上通过局域网或内网穿透让云服务器能调用到本地模型的API。这样既保证了微信回调稳定又把模型推理成本控制在自家电费里。我目前就是这个架构用了几个月没出过问题。6.2 成本和权限要预判成本主要两块云服务器月租如果走上面的折中方案最低配的就行大概几十块一个月以及本地电脑的长期电费。中端显卡跑量化版模型满载功耗大概一百多瓦一天开24小时的话一个月电费也就几十块。对一个AI助理来说这个成本可以说是零头。权限方面需要注意能力的边界一定要控制。比如有人想把AI接到“自动收款确认”“验证码识别”之类的场景里这种涉及钱和敏感信息的操作AI的判断一旦出错代价很大。我的建议是让龙虾模型只做聊天问答其他的事情最多给个建议不要接任何有实际操作的接口。别高估模型的可靠性这个认知值得反复提醒自己。6.3 接口凭证别泄露整个系统里有两个敏感值企业微信自建应用的Secret回调配置里的Token和EncodingAESKey。任何一条泄露到外网别人都能冒充你的应用收发消息。我自己的习惯是把这些配置放到环境变量而不是写在代码里import os SECRET os.getenv(WECOM_SECRET) TOKEN os.getenv(WECOM_TOKEN) AES_KEY os.getenv(WECOM_AES_KEY)用环境变量还有个额外好处代码可以分享出来而不担心密钥泄露。如果你准备把这个教程分享给朋友看一定记得先检查代码里有没有硬编码的密钥。7. 再往深走一步哪些能力可以扩展跑通文本回复之后这个系统的扩展空间一下就打开了。比如语音消息企业微信支持上传语音文件回调里带了MediaId你可以先用企业微信接口下载语音文件转成文字后再发给模型回复时再用“文本转语音”生成一条语音消息。这样你的AI助理就能“开口说话”。比如定时任务你现在能主动发送消息了完全可以写一个定时脚本每天早上8点给用户推送天气、日程、新闻摘要。龙虾模型在本地跑生成一段简短的播报稿完全不费劲。如果完全不想写代码也不是没有出路。市面上有一些开源项目已经把“企业微信回调 OpenAI兼容接口”整合起来你只需要填一个模型地址和模型名称就能把微信聊天接到一个大模型上。具体项目名我就不说了你可以用“企业微信 机器人 开源”这些关键词去搜。但我的体验是用别人封装好的项目出了问题你很难自己排查一旦遇到回调失败、消息不回复的情况就要重新去读源码。自己亲手搭的这套虽然前期代码多一些但每一步都清楚出问题也能快速定位。到现在为止整条链路已经通了本地龙虾模型负责思考企业微信负责收发消息中间夹着一个几十行的Flask服务。整个过程没有碰任何踩红线的工具全是官方接口和正常部署。最后分享一个我自己的使用小技巧回调服务里把每条消息的接收时间、模型推理耗时、token数量都打进日志。这样聊天过程中如果发现有奇怪的回复翻日志就能复现当时模型看到了什么上下文、花了多久生成的。这种“可追溯”的感觉是用云端API时很难得到的也是我觉得本地模型最值得玩的一个理由。
1. 先想清楚你接入的到底是“微信”还是“微信生态”先说结论这篇想讲的事就是把一个本地跑起来的大语言模型接到微信生态里让它替你回复消息。模型名字我用的“龙虾”——这是社区里对某类开源中文大模型的一个通称别较真你可以理解成“本地部署的开源对话模型”的代号。重点是整条链路怎么打通、怎么合规、怎么让新手不掉进坑里。我最初的想法很简单能不能让我自己的微信收到消息之后自动让AI帮我回于是先搜了一圈。结果发现大部分号称“个人微信接入AI”的方案走的路子都让人很不踏实——要么是模拟网页版微信协议要么是抓客户端数据搞HOOK。这些方案确实能跑看起来也方便但本质是在和微信的安全机制对着干。轻则频繁“操作频繁”验证重则直接封号。我见过有人折腾了半个月号一封前功尽弃。所以各位接AI没问题但接的通道必须是官方允许的这一条不能妥协。那普通人到底能走哪些官方路线说白了微信生态里真正开放了消息回调、能实时收发消息的入口主要就是两个方向方案适合场景门槛风险个人微信自动化模拟协议想直接控制自己微信App低工具现成高容易封号企业微信自建应用个人/小团队做AI助理、客服机器人中要写点代码低官方API公众号/服务号面向粉丝的自动回复较高认证门槛低但接口权限受限我个人实测下来个人想玩得顺、体验又接近微信聊天的就是企业微信自建应用这条路。客户那边看到的是普通微信聊天窗口你这边通过官方API收发消息完全在规则内运行。这也就是标题里“官方合规直连”的真正含义——不是绕过微信而是站在微信生态的官方接口上把AI挂进去。2. “龙虾”模型的本地部署一台普通电脑就能跑2.1 为什么我选本地模型而不是接云端API其实一开始我也动过接云端大模型API的念头注册方便、效果也好。但后来算了笔账每天几百条消息长上下文聊天一个月下来API费用足够吃好几顿小龙虾了。而且消息全要经过第三方服务器虽然大厂不会乱看但心里总归不太踏实。本地模型的好处就出来了模型文件下载到自己电脑或服务器上对话请求走本地地址完成数据不出内网运行过程完全可见——用的是哪个模型文件、每次推理消耗多少token、回复逻辑是什么全都可以查这就是标题里“模型运行清晰”的意思。那为什么选“龙虾”系列因为我需要的是中文对话效果好、体量适中、消费级硬件能跑的模型。现在的开源社区里有很多好选择我用的这个7B规模的量化版就是典型代表单个权重文件大约4~6GB笔记本的显卡就能跑对话质量对个人助理场景完全够用。提示别盲目追求大模型。7B量化版在很多场景下比14B半精度版更实用因为回复速度快微信场景下体验更流畅。2.2 Ollama部署一行命令拉模型如果你完全没接触过模型部署听我说别自己去下载权重再折腾推理脚本直接用Ollama这类一键部署工具就行。它把模型管理、下载、启动、本地API全封装好了装完不用配环境终端里敲命令就能跑。具体步骤很简单到Ollama官网下载对应操作系统Windows/macOS/Linux的安装包双击安装命令行里出现ollama命令就算成功。打开终端输入ollama run lobster:7b-chat-q4_K_M第一次运行会自动下载模型权重下载完成后直接进入对话界面你打一句它回一句。退出对话输入/bye查看已装模型用ollama list。如果你只有CPU没有独立显卡也别灰心选更小的3B/4B蒸馏版内存16GB就能跑速度虽然谈不上飞快但日常回复够用了。我自己是在一台8GB显存的老电脑上跑的量化版模型加载后占用不到6GB显存推理时生成速度大概十几token每秒普通对话完全能接受。2.3 确认本地API已经可用Ollama装好模型之后默认会在本地监听11434端口它同时提供了一个兼容OpenAI格式的HTTP接口。验证方式很简单另开一个终端执行curl http://127.0.0.1:11434/api/generate -d { model: lobster:7b-chat-q4_K_M, prompt: 你好介绍一下你自己, stream: false }如果返回一段JSON里面有response: ...说明本地模型服务已经就绪了。这就是后面微信消息和模型之间的桥梁——你只需要写一个小程序把微信收到的文字转发给这个接口再把接口返回的文字发回微信。这一步跑通之后相当于你在自家电脑里养了一只“龙虾”它随时等你来投喂问题。2.4 给“龙虾”定制一个说话风格直接用的模型回复风格偏“通用助手”放到微信场景里显得太正式。我更希望它像个朋友说话简短、口语化、不端架子。Ollama支持通过Modelfile定制角色设定操作不复杂。新建一个Modelfile文件内容写FROM lobster:7b-chat-q4_K_M SYSTEM 你是我微信上的个人AI助理名字叫小龙虾。 回答要求 1. 简短口语化像朋友聊天不要用“您好”“亲爱的”这类客套词 2. 如果用户问复杂问题可以分点说明但每点不超过两行 3. 不确定的事直接说不知道不要编。然后在终端执行ollama create lobster-assistant -f Modelfile ollama run lobster-assistant这样你本地就有了一个带“人设”的模型实例后续程序调用时把模型名从lobster:7b-chat-q4_K_M改成lobster-assistant就行。3. 企业微信侧配置百分之八十的人卡在这一步3.1 注册企业微信、创建自建应用模型准备好了接下来是微信侧。企业微信个人也是可以注册的不用非得是公司。流程是下载企业微信App并注册一个企业哪怕只有你一个人也算一个企业。登录企业微信管理后台找到“应用管理” - “自建应用” - 创建应用。应用创建完成后你会拿到一个AgentId应用ID和Secret应用密钥这俩是关键凭证先记下来。自建应用在管理后台里有点像“一个小机器人账号”它可以收到成员发给它的消息也能主动向成员发消息还能被添加到微信客户联系人里。我们就是拿它当AI助理的“替身”。3.2 配置接收消息服务器从验证URL开始这是整个接入流程里最容易劝退新手的地方。很多教程在这里直接甩一个加密解密的代码把人看晕。我的建议是开发联调阶段先用明文模式跑通逻辑再考虑加密。在企业微信管理后台的自建应用配置页里找到“接收消息服务器配置”需要填三样东西URL你的服务地址必须是一个公网能访问到的HTTP地址端口建议用80或443。Token自己随便填一个字符串相当于一个简单的口令。EncodingAESKey点随机生成即可。URL验证的逻辑是这样的企业微信用GET请求访问你的URL并且在URL里带上echostr参数。你的服务只需要原样把这个参数返回给企业微信就算验证通过。这就像微信端喊了一声“暗号”你回答一声“暗号收到”双方就算握手成功了。我第一次试的时候URL填的是自己电脑的本地地址结果一直验证失败。后来才明白企业微信服务器在公网上它访问不到我电脑的局域网地址。解决思路有两个一是把服务部署到一台云服务器上二是在本地做内网映射。新手我强烈建议直接上云服务器最便宜的那种1核2G的都够跑这个中间服务一个月成本很低还省去各种公网网关的麻烦。如果非要在本地调试可以用frp这类开源内网穿透工具把本机的服务端口映射到一台有公网IP的机器上但配置起来多一层工作新手别一开始就碰。我用一个极简的Flask服务演示验证过程from flask import Flask, request app Flask(__name__) app.route(/wechat, methods[GET]) def verify_url(): # 企业微信验证URL时会带 echostr 参数原样返回即可 echostr request.args.get(echostr) return echostr or if __name__ __main__: app.run(host0.0.0.0, port80)把这个代码跑在云服务器上URL填http://你的域名或IP/wechat在后台点“保存”。如果后台显示“验证成功”说明第一步通了。注意企业微信要求回调URL必须能公网访问并且参数名必须严格使用echostr。有的老教程写的是echo_str照抄就会验证失败这种细节一旦踩了排查起来很折磨人。3.3 明确“明文模式”的意义在接收消息配置里企业微信支持选择“明文模式”或“加密模式”。明文模式下企业微信推给你的消息是直接可读的JSON你不需要处理AES加解密返回回复时直接返回明文JSON即可。缺点是这样的配置不太适合生产环境消息内容理论上容易被中间人截获而且企业微信官方本身也更建议用加密模式。我的路线是先用明文模式把全流程跑通让AI回复能成功推到聊天窗口再去研究加密。这样一次只面对一个问题排查起来不会一头雾水。等你在明文模式下实现了“发消息-收到回复”的全链路再切换加密模式无非是多写一段加解密工具函数而已。4. 中间服务把微信消息转给“龙虾”再把回复转回来4.1 整体架构一句话讲清楚整个系统的调用关系是这样的微信用户或你自己在聊天窗口给企业微信应用发消息 - 企业微信服务器把这条消息POST到你的回调URL - 你的中间服务Flask提取文本内容 - 把文本发给本地Ollama的“龙虾”模型 - 模型返回回复文本 - 中间服务把回复字符串包装成企业微信要求的JSON格式作为HTTP响应返回 - 企业微信服务器把回复推送到用户的聊天窗口。注意这里说的“微信用户”有两种情况如果你把应用发给你的微信客户那客户用微信就能直接和企业微信应用聊天如果只是自己测试那在企业微信App里给自己的应用发消息也行。4.2 核心代码实现明文模式下接收消息其实就是一个POST请求。企业微信用JSON体把消息推过来文本消息的关键字段是MsgType、Content、FromUserName、ToUserName。把第2章讲过的Ollama调用和第3章的回调服务拼在一起就是一个完整的中间服务from flask import Flask, request import requests import time app Flask(__name__) OLLAMA_URL http://127.0.0.1:11434/api/generate MODEL_NAME lobster-assistant def chat_with_lobster(prompt): r requests.post( OLLAMA_URL, json{ model: MODEL_NAME, prompt: prompt, stream: False }, timeout30 ) data r.json() return data.get(response, 抱歉我刚刚走神了再说一遍) app.route(/wechat, methods[GET, POST]) def wechat_callback(): if request.method GET: # URL验证 return request.args.get(echostr, ) # POST收到消息 data request.get_json() if not data: return error msg_type data.get(MsgType) content data.get(Content, ).strip() from_user data.get(FromUserName, ) to_user data.get(ToUserName, ) if msg_type text and content: reply chat_with_lobster(content) return { ToUserName: from_user, FromUserName: to_user, CreateTime: int(time.time()), MsgType: text, Content: reply } # 非文本消息暂不处理 return ok if __name__ __main__: app.run(host0.0.0.0, port80)跑起来之后再做一次测试在企业微信里给应用发一条“你好”正常情况下几秒后就能收到龙虾模型的回复。这里有个容易忽略的坑被动回复必须要在5秒内响应。Ollama是本地推理如果显卡性能一般或者模型首次加载还没驻留内存生成一个稍微长一点的回答很容易超过5秒。新手机器人“已读不回”的尴尬场面多半就是这么来的。解决思路后面第5章会细讲。4.3 被动回复与主动发送的区别上面这段代码属于“被动回复”——企业微信发请求过来你在响应里直接塞回消息。这种方式简单但有局限你只能在收到消息之后回不能主动给用户发一条。如果需要“异步回复”——比如收到消息后先回一句“我思考一下”等模型算完再补发结果——就需要用主动发送接口def send_text_message(access_token, agent_id, user_id, content): url https://qyapi.weixin.qq.com/cgi-bin/message/send payload { touser: user_id, msgtype: text, agentid: agent_id, text: {content: content} } headers {Content-Type: application/json} r requests.post( f{url}?access_token{access_token}, jsonpayload, headersheaders, timeout10 ) return r.json()注意这里的access_token需要单独通过企业微信API获取并且有有效期限制正常要写一个带缓存的获取函数不能每次请求都去拉一次。这个先不展开新手先跑通被动回复能收到AI的消息就已经成功一大半了。5. 联调实录第一次跑通的全过程以及我踩过的坑5.1 卡了我两个小时的URL验证第一次联调时我没看官方文档直接就找网上的教程抄了一段代码。抄的时候发现别人的代码里返回的参数名是echoStr大小写和我后台配置的不一致。企业微信的验证要求在取参数时严格区分大小写参数名就是全小写的echostr。这个看起来不起眼的问题让我误以为是IP、端口、防火墙的问题排查了很久。后面我学乖了在Flask的入口加了一行日志打印所有请求参数print(request.args)一打印就明白了请求里带的是echostr而代码读的是echoStr自然拿不到值。所以说联调阶段花十分钟在服务里加几行print日志比瞎猜高效得多。5.2 模型冷启动导致的“首答超时”URL验证通过后我兴冲冲地给应用发了一条“介绍下你自己”等了二十多秒聊天窗口里没有任何回复。一看Flask日志发现请求是收到了但chat_with_lobster还在阻塞中——因为这是当天第一次调用Ollama模型权重要从磁盘加载到显存冷启动特别慢。解决办法也简单启动时预热一次。chat_with_lobster(你好请简短回复。)把这个放在Flask服务启动之后立刻调用一次让模型常驻显存。Ollama默认会在模型不活动约5分钟后卸载它所以如果长时间没消息下一次请求还是会被冷启动拖慢。稳妥的做法是在服务里加个定时任务每两三分钟主动请求一次模型让它别睡过去。等你实际使用后就会发现这个“心跳包”比什么调优都管用。5.3 对话没有记忆它记不住两轮前说过的话第一次收到模型回复时效果还行但很快就发现一个问题我说“我叫王小明”它答了句“很高兴认识你”隔两轮再问“我叫什么”它就答不上来了。因为上面的示例代码每次调用都只把当前这句话发给模型模型没有上下文。要想让它有记忆就得自己维护一个历史消息列表每次把最近N轮对话拼接起来一起发给模型memory {} def build_prompt_with_history(user_id, latest_text): history memory.get(user_id, []) history.append(f用户: {latest_text}) # 只保留最近10条防止对话太长影响速度和消耗 history history[-10:] memory[user_id] history prompt \n.join(history) \n助手: return prompt这样每次请求时prompt里都带着之前的对话记录模型自然能“想起来”。但要注意普通全局字典在并发请求下会互相覆盖如果应用正式对外服务得加锁或用Redis这种独立存储否则两个用户同时在聊天消息历史会串台。我自己是先在本机单人测试用全局字典后来放入口加了个简单的线程锁才避免这个问题。5.4 温度参数调优从“满嘴跑火车”到“安安静静回答”默认温度下模型回消息有时候过于“活泼”问它今天天气它能扯出一段抒情散文。做微信助理这种风格不太合适。我把Ollama请求体里的options加上了温度控制json{ model: MODEL_NAME, prompt: prompt, stream: False, options: { temperature: 0.3 } }温度越低模型输出越稳定、越保守。我把0.3作为默认值如果聊天气氛比较轻松可以适当调回0.7。这个参数对体验的影响比很多人想象中大建议一次性试几种温度找自己最能接受的平衡点。5.5 被动回复超时的终级解法如果你觉得“先回一句再异步补发”更稳妥用一个高并发的思路来做收到消息时立刻返回“收到正在思考中”同时开一个线程去调用模型等模型返回后再用主动发送接口把结果推过去。这样即使模型推理花了30秒用户也不会觉得这条消息“石沉大海”顶多是觉得回复慢一点。import threading def handle_message_async(data): content data.get(Content, ) from_user data.get(FromUserName, ) to_user data.get(ToUserName, ) prompt build_prompt_with_history(from_user, content) reply chat_with_lobster(prompt) # 这里调用 send_text_message 把 reply 发出去 send_text_message(access_token, agent_id, from_user, reply) app.route(/wechat, methods[POST]) def wechat_callback(): data request.get_json() thread threading.Thread(targethandle_message_async, args(data,)) thread.start() return { ToUserName: data.get(FromUserName, ), FromUserName: data.get(ToUserName, ), CreateTime: int(time.time()), MsgType: text, Content: 收到我这就去想稍等一下。 }用这个方案要注意主动发送接口对企业微信的调用频率有限制个人自建应用每天的量级足够用但如果做对外服务还是要做频率控制。6. 上线前必须想明白的三件事6.1 服务跑在哪本地电脑还是云服务器如果你只在测试阶段用frp把本地服务映射到公网就行。但真正常期挂着用我个人建议把中间服务和模型都放到一台云服务器上这么做的好处是稳定不受家里断电、断网、电脑休眠影响。不过本地模型对硬件要求高一台带GPU的云服务器价格不便宜。折中的方案是中间服务放云服务器Ollama模型放在有独立显卡的本地电脑上通过局域网或内网穿透让云服务器能调用到本地模型的API。这样既保证了微信回调稳定又把模型推理成本控制在自家电费里。我目前就是这个架构用了几个月没出过问题。6.2 成本和权限要预判成本主要两块云服务器月租如果走上面的折中方案最低配的就行大概几十块一个月以及本地电脑的长期电费。中端显卡跑量化版模型满载功耗大概一百多瓦一天开24小时的话一个月电费也就几十块。对一个AI助理来说这个成本可以说是零头。权限方面需要注意能力的边界一定要控制。比如有人想把AI接到“自动收款确认”“验证码识别”之类的场景里这种涉及钱和敏感信息的操作AI的判断一旦出错代价很大。我的建议是让龙虾模型只做聊天问答其他的事情最多给个建议不要接任何有实际操作的接口。别高估模型的可靠性这个认知值得反复提醒自己。6.3 接口凭证别泄露整个系统里有两个敏感值企业微信自建应用的Secret回调配置里的Token和EncodingAESKey。任何一条泄露到外网别人都能冒充你的应用收发消息。我自己的习惯是把这些配置放到环境变量而不是写在代码里import os SECRET os.getenv(WECOM_SECRET) TOKEN os.getenv(WECOM_TOKEN) AES_KEY os.getenv(WECOM_AES_KEY)用环境变量还有个额外好处代码可以分享出来而不担心密钥泄露。如果你准备把这个教程分享给朋友看一定记得先检查代码里有没有硬编码的密钥。7. 再往深走一步哪些能力可以扩展跑通文本回复之后这个系统的扩展空间一下就打开了。比如语音消息企业微信支持上传语音文件回调里带了MediaId你可以先用企业微信接口下载语音文件转成文字后再发给模型回复时再用“文本转语音”生成一条语音消息。这样你的AI助理就能“开口说话”。比如定时任务你现在能主动发送消息了完全可以写一个定时脚本每天早上8点给用户推送天气、日程、新闻摘要。龙虾模型在本地跑生成一段简短的播报稿完全不费劲。如果完全不想写代码也不是没有出路。市面上有一些开源项目已经把“企业微信回调 OpenAI兼容接口”整合起来你只需要填一个模型地址和模型名称就能把微信聊天接到一个大模型上。具体项目名我就不说了你可以用“企业微信 机器人 开源”这些关键词去搜。但我的体验是用别人封装好的项目出了问题你很难自己排查一旦遇到回调失败、消息不回复的情况就要重新去读源码。自己亲手搭的这套虽然前期代码多一些但每一步都清楚出问题也能快速定位。到现在为止整条链路已经通了本地龙虾模型负责思考企业微信负责收发消息中间夹着一个几十行的Flask服务。整个过程没有碰任何踩红线的工具全是官方接口和正常部署。最后分享一个我自己的使用小技巧回调服务里把每条消息的接收时间、模型推理耗时、token数量都打进日志。这样聊天过程中如果发现有奇怪的回复翻日志就能复现当时模型看到了什么上下文、花了多久生成的。这种“可追溯”的感觉是用云端API时很难得到的也是我觉得本地模型最值得玩的一个理由。
