1. 为什么要在微信里接一个 AI 自动回复先把场景说清楚。我手上有一台常年开着的开发机上面跑着 Claude Code平时用它写脚本、查日志、改配置效率确实高。但问题也很明显人不可能一直坐在电脑前出门在外、开会间隙、甚至只是躺在沙发上想让它帮我跑个命令、查个文件、解释一段报错就得回到终端前面。于是很自然的一个想法冒出来——能不能把微信当成一个入口我在微信里发一句话机器上的 Claude Code 收到、执行、把结果回给我这个方案听起来像是把聊天软件当遥控器但真正动手之后你会发现它牵扯的东西比想象中多消息怎么从微信到本机、本机怎么把结果送回微信、哪些人允许用、怎么防止别人乱发指令、Claude Code 在非交互环境下怎么执行命令、超时了怎么办、长输出怎么截断。这一整套链路才是这个项目真正的价值所在而不是接个 API 就完事。我把它拆成几个核心问题消息链路微信侧怎么收发、白名单谁能用、怎么鉴权、执行层Claude Code 怎么被程序调用、回传与容错结果怎么回去、出错怎么办。这四个问题解决了整个方案就立住了。下面我按实际搭建的顺序把每一步的选择理由、踩过的坑、以及可以直接抄的配置都写出来。注意本文讨论的是个人自用、单机部署的自动化方案重点在链路设计和工程细节不涉及任何账号共享、批量操作或规避平台规则的内容。所有接入方式都基于官方开放的接口能力。2. 消息链路的两条路公众号被动回复 vs 企业微信应用微信侧要接收消息绕不开一个现实普通个人微信号没有官方开放的消息收发接口。所以真正能落地的方案只有两条——微信公众号订阅号/服务号的被动回复或者企业微信的自建应用。这两个我都在不同阶段用过各有取舍。2.1 公众号被动回复门槛低但有 5 秒硬限制公众号的思路是用户在公众号里发消息微信服务器把消息 POST 到你自己配置的服务器 URL你在规定时间内返回一段 XML微信再把这段内容展示给用户。这是最经典的被动回复模式。它的优点是接入简单一个能公网访问的 HTTP 接口就行。但有个致命限制微信要求服务器在 5 秒内返回响应超时就会重试重试三次还没响应就放弃。而 Claude Code 执行一条稍微复杂点的指令动辄十几秒甚至几分钟。5 秒根本不够。所以公众号方案必须改成异步收到消息立刻返回一句收到正在处理然后后台慢慢跑跑完再通过客服消息接口主动推给用户。客服消息接口有 48 小时的时间窗口用户最后一次互动后 48 小时内可以主动推送对个人自用完全够。这里有个容易忽略的点被动回复返回的success空串和返回具体内容行为不一样。如果你返回空串微信不会给用户任何提示用户会以为消息没发出去。所以哪怕只是占位也要返回一句明确的话。2.2 企业微信自建应用更适合遥控器场景后来我换成了企业微信自建应用原因是它更贴近给自己发指令的体验。企业微信可以创建一个只有自己的应用配置好接收消息的 URL 后你在应用会话里发消息企业微信服务器同样 POST 到你的接口。它比公众号舒服的地方在于主动推送的限制更宽松应用消息可以直接推给指定成员不用卡 48 小时窗口而且企业微信的消息结构更规整JSON 为主解析起来比公众号的 XML 省心。代价是配置步骤多一些要建应用、拿 CorpID、Secret、AgentID还要配置可信 IP 和接收消息的 URL。但这些都是一次性的配完就不用管了。对比项公众号被动回复企业微信自建应用接入难度低中响应时间限制5 秒硬限制相对宽松主动推送客服消息48 小时窗口应用消息限制少消息格式XMLJSON适合场景轻量问答指令型遥控我最终选企业微信核心原因就一个它是为内部工具设计的而我要的正好是一个内部工具。公众号更适合对外服务用在自用遥控器上有点别扭。2.3 消息加解密别跳过这一步不管走哪条路微信侧的消息默认都建议开启加密企业微信叫EncodingAESKey。很多人图省事直接明文本地测试没问题但一旦暴露在公网就有风险。加解密本身不复杂官方给了各语言的示例代码核心就是 AES-256-CBC配合签名校验。签名校验的逻辑是把 token、timestamp、nonce、加密消息体拼在一起做字典序排序然后 SHA1。这一步一定要做否则任何人都能伪造请求打你的接口。我见过有人为了调试方便把校验注释掉结果上线忘了改回来接口被人扫到后疯狂触发执行——这是真实会发生的。3. 白名单为什么四元组才是靠谱的鉴权方式标题里提到的白名单需要四元组这是整个方案里最容易被做错、也最值得展开讲的部分。很多人做白名单就是维护一个用户 ID 列表判断发消息的人在不在列表里。这在单入口场景下够用但一旦你的系统有多个入口、多种身份来源就会出问题。3.1 单字段白名单的漏洞在哪假设你只用用户 ID做白名单。问题来了企业微信的 UserID、公众号的 OpenID、你自己系统里的内部 ID这三者是完全不同的命名空间。如果某天你同时接了企业微信和公众号两个来源的用户 ID 可能撞车或者你根本分不清这个 ID 是从哪个渠道来的。更麻烦的是如果接口被伪造攻击者只要猜中一个合法 ID就能绕过校验。单字段校验的本质问题是它只验证了你是谁没验证你从哪来、用什么身份、在什么上下文里。3.2 四元组的具体构成我采用的方案是四元组校验四个维度分别是渠道标识channel这条消息来自企业微信、公众号还是别的入口应用标识agent/app具体是哪个应用企业微信里一个企业可以有多个应用用户标识user发送者的唯一 ID会话标识conversation单聊还是群聊群聊的话群 ID 是什么只有这四个维度全部命中白名单里的一条记录才放行。这样即使某个维度被猜到其他三个维度对不上照样拒绝。# 白名单校验的核心逻辑示意 WHITELIST [ { channel: wecom, agent: 1000002, user: zhangsan, conversation: single, }, # 群聊场景单独列一条 { channel: wecom, agent: 1000002, user: zhangsan, conversation: group:wrOgXXX, }, ] def is_allowed(channel, agent, user, conversation): for item in WHITELIST: if (item[channel] channel and item[agent] agent and item[user] user and item[conversation] conversation): return True return False3.3 为什么不用角色而用四元组有人会问直接给用户打个管理员标签不就行了问题在于权限的粒度应该跟上下文绑定而不是跟人绑定。同一个人在单聊里可以执行任意命令但在一个多人群里你可能只希望他能查状态、不能执行写操作。四元组天然支持这种同人不同场景不同权限的模型而角色模型要做到这点就得引入更复杂的规则引擎。我的实际配置里单聊记录允许执行完整指令群聊记录只允许查询类操作。这样即使群里有其他人也不会因为某个人手滑发了一条危险命令而影响机器。提示白名单一定要写成配置文件或数据库不要硬编码在代码里。我一开始图快写在代码常量里后来加人、改权限都要重新部署非常痛苦。改成读 JSON 文件后改完直接热加载省事太多。4. 执行层Claude Code 在非交互环境下的正确调用姿势链路通了、鉴权过了接下来就是真正干活的部分——让 Claude Code 执行指令。这里有个关键认知Claude Code 默认是交互式的而自动回复场景需要的是非交互式的一次性执行。直接把它当普通命令调用会卡在等待输入上。4.1 非交互模式的关键参数Claude Code 提供了非交互执行的能力核心是用-pprint模式把提示词直接作为参数传入执行完输出结果就退出不会进入交互界面。基本形式是这样claude -p 帮我看看当前目录下有哪些大于 100MB 的文件 --output-format text几个我实测下来必须注意的点--output-format建议用text默认的格式可能带一些结构化包装解析起来麻烦。如果你需要程序化处理用json更规整。工作目录要显式指定。非交互模式下它不会继承你期望的目录最好用cd /your/workspace claude -p ...的方式或者看它是否支持--cwd之类的参数。权限模式要提前想清楚。Claude Code 执行某些操作比如写文件、跑命令会请求确认非交互环境下没法确认所以要提前配置好允许的操作范围否则它会直接拒绝执行。4.2 超时与进程管理这是踩坑最多的地方。Claude Code 执行复杂任务可能跑几分钟而你的消息处理进程不能一直挂着等。我的做法是收到指令后立刻返回已收到正在执行把任务丢进一个后台队列我用的是简单的进程池 任务表后台 worker 调用 Claude Code设置一个合理的超时我设的是 300 秒执行完把结果写回任务表再触发推送超时设置很关键。设太短复杂任务永远跑不完设太长一个卡死的任务会占着 worker 不放。300 秒是我反复调整后的值覆盖了绝大多数日常指令。import subprocess def run_claude(prompt, timeout300): try: result subprocess.run( [claude, -p, prompt, --output-format, text], capture_outputTrue, textTrue, timeouttimeout, cwd/home/me/workspace, ) return result.stdout.strip() or (无输出) except subprocess.TimeoutExpired: return 任务执行超时已终止。 except Exception as e: return f执行出错{e}4.3 输出长度与安全过滤Claude Code 的输出可能很长而微信消息有长度限制企业微信文本消息大约 2048 字节。超长内容必须截断或分段。我的策略是超过 1500 字符就截断并在末尾提示内容过长已截断完整结果已存到 xxx 文件把完整输出落盘用户需要时再去取。另外输出里可能包含一些不适合直接展示的路径、密钥片段。我在回传前加了一层简单的过滤把明显的敏感字段比如形如sk-开头的字符串、绝对路径里的用户名做脱敏。这一步不是必须但养成习惯没坏处。5. 回传与容错让整个链路看起来永远在线链路能跑通只是及格线真正决定体验的是容错。我总结了几个高频故障场景和对应的处理方式这些都是实际跑了一段时间后攒下来的。5.1 消息重复微信的重试机制会坑你前面提过微信在没收到及时响应时会重试。如果你的接口处理慢同一条消息可能被投递两三次。如果不做去重用户发一句话机器执行三遍轻则浪费资源重则重复执行危险操作。去重的做法是用微信消息体里的 MsgId 做幂等键处理前先查这个 ID 有没有处理过处理过就直接返回不再执行。这个 MsgId 在消息体里是唯一的非常适合做幂等。processed set() # 实际用 Redis 或数据库 def handle_message(msg_id, content): if msg_id in processed: return duplicate processed.add(msg_id) # 后续处理...5.2 推送失败要有重试和降级主动推送消息时网络抖动、token 过期都可能导致失败。我的处理是推送失败重试 3 次间隔递增1s、3s、9s如果还是失败把结果存到本地等下次用户发消息时顺带告诉他上次那条任务的结果在这里。token 过期是另一个常见问题。企业微信的 access_token 有效期 7200 秒必须缓存并定期刷新。我见过有人每次请求都重新获取 token结果触发频率限制被封。正确做法是缓存 token快过期时再刷新。5.3 一个完整的故障排查链路有一次用户反馈发了消息没反应。我按这个顺序排查最后定位到问题这个链路值得记下来先看微信侧有没有投递查企业微信后台的消息记录确认消息确实发出去了再看接口有没有收到查我服务器的访问日志看有没有对应的 POST 请求看签名校验有没有过日志里如果全是签名失败说明 token 配错了看任务有没有入队如果接口收到了但没入队说明白名单校验把它拦了看 worker 有没有执行查 worker 日志看 Claude Code 有没有被调用看推送有没有成功查推送接口的返回码那次的问题是第 4 步——白名单里少配了一条群聊记录导致群里的消息全被拦了。如果没有这个排查链路很容易一头雾水。故障现象可能原因排查位置完全没反应接口没收到 / 签名失败服务器访问日志收到但没执行白名单拦截白名单校验日志执行了没回复推送失败 / token 过期推送接口返回码回复重复消息未去重幂等键处理逻辑6. 几个我踩过、但文档里不会写的坑最后这部分是我觉得最有价值的内容都是实际跑起来才会遇到的问题。第一个坑Claude Code 的环境变量不继承。我在 shell 里配好的 API key、代理设置通过 subprocess 调用时不一定能读到。解决办法是在调用时显式传入env参数把需要的环境变量带上。这个坑卡了我半天因为报错信息很含糊只说认证失败。第二个坑并发执行会互相干扰。如果同时来了两条指令两个 Claude Code 进程在同一个工作目录里跑可能互相覆盖文件。我的做法是给每个任务分配独立的工作目录或者干脆串行执行用队列保证同一时间只有一个任务在跑。个人自用场景下串行完全够还省去了并发控制的复杂度。第三个坑长任务的中间状态无法感知。Claude Code 跑一个长任务时你只能等它结束中间没有任何进度反馈。用户体验上就是发完消息干等。我的缓解办法是对于预计会很久的任务先回一句这个任务可能需要几分钟完成后我会通知你让用户心里有数。第四个坑日志里别记敏感内容。调试阶段我图方便把完整的消息内容和 Claude Code 输出都打进日志后来意识到这里面可能有路径、配置片段。现在我只记消息 ID、长度、执行状态具体内容不落日志。这套方案我从最初跑通到现在稳定使用前后大概迭代了三四轮核心的链路设计和四元组白名单一直没变变的主要是容错细节。如果你也想搭一套建议先把消息链路和白名单这两块做扎实执行层反而最简单——Claude Code 的非交互调用本身不复杂难的是让它在一个永远在线、不会乱执行、出错能自愈的系统里稳定工作。