1. 项目概述：为什么要在企业微信里集成Claude？

最近和几个做企业服务的朋友聊天，大家普遍有个痛点：团队内部的技术支持、代码审查、文档查询，甚至一些简单的业务流程咨询，占用了大量人力。工程师们经常被拉进各种群，回答重复性的技术问题；产品经理需要快速查询某个功能的API文档；新员工入职，对着海量的内部Wiki不知从何下手。这些场景，如果有一个能随时响应、知识渊博的“智能同事”在侧，效率会提升不少。

这正是“企业微信集成Anthropic的Claude系列模型”这个项目要解决的核心问题。它不是一个简单的“把聊天机器人搬进企业微信”的玩具，而是一个旨在将Claude强大的自然语言理解、代码生成与分析、安全对话能力，深度嵌入到企业日常协作流中的生产力方案。Claude，特别是Claude Code，在代码理解、生成和安全合规方面口碑不错，很适合企业内部这种对准确性、安全性要求高的场景。

想象一下，在你们公司的技术讨论群里，有人贴了一段报错日志，@一下这个智能助手，它就能分析可能的原因并给出排查步骤；新同事在群里问“报销流程怎么走”，助手能精准调取内部知识库给出指引；甚至开发人员可以直接把一段模糊的需求描述丢给它，让它生成初步的接口定义或伪代码。这一切，都在你们已经高频使用的企业微信里完成，无需切换应用，体验无缝。

这个项目适合有一定技术基础的团队负责人、运维工程师或后端开发者来主导实施。它涉及到企业微信应用开发、API集成、大模型调用以及简单的服务部署。接下来，我会拆解整个实现思路、关键步骤，并分享我在搭建过程中踩过的坑和总结的经验，目标是让你能根据这份指南，复现一个稳定可用的企业内部智能助手。

2. 整体架构设计与核心思路拆解

要把Claude装进企业微信，不是简单做个转发就能搞定。我们需要设计一个稳定、安全、可扩展的架构。核心思路是：企业微信作为交互入口，一个自建的中转服务作为“大脑”，负责处理企业微信的消息、调用Claude API、并管理对话上下文和知识库。

2.1 核心组件与数据流

整个系统可以看作由三个主要部分组成：

1. 企业微信侧（前端入口）：创建一个自定义的企业微信应用（或群机器人）。它负责接收员工发送的消息，并通过企业微信提供的API，将消息推送到我们自建的服务。同时，它也负责将服务返回的回复消息，展示给员工。
2. 自建中转服务（核心逻辑层）：这是项目的核心，一个我们自己部署的Web服务。它需要做几件事：
   • 接收消息：提供一个公网可访问的API端点，用于接收企业微信推送过来的消息事件。
   • 处理与路由：解析消息内容，判断意图（例如，是普通问答，还是需要调用知识库的查询）。
   • 调用Claude API：将处理后的用户问题，结合历史对话上下文，构造符合Claude API格式的请求，发送给Anthropic的服务器。
   • 管理上下文：为了能让Claude记住对话历史（比如用户上文问了什么），需要维护一个简单的会话上下文存储。可以用Redis，或者直接存在服务内存里（适用于单实例部署）。
   • 调用知识库（可选）：如果需要让助手回答公司内部特有的问题，就需要接入知识库。常见的做法是：将内部文档（Wiki、PDF等）进行向量化处理，存入向量数据库（如Chroma、Milvus）。当用户提问时，先根据问题从向量库中检索出最相关的几段文档，然后将这些文档作为“参考信息”和用户问题一起喂给Claude，让它基于这些信息生成答案。这就是RAG（检索增强生成）的基本思想。
   • 返回回复：将Claude返回的文本，通过企业微信API发送回对应的群聊或单人会话。
3. Claude API与知识库（能力与数据层）：
   • Anthropic API：使用官方提供的API（通常是HTTP接口）来调用Claude模型。你需要注册Anthropic账号并创建API Key。
   • 向量数据库（可选）：用于存储和处理企业内部知识的向量化表示。

数据流的完整过程是这样的：员工在企业微信提问->企业微信服务器将消息事件推送到你的公网服务->你的服务处理消息，可能检索知识库->你的服务构造Prompt，调用Claude API->Claude返回生成结果->你的服务将结果通过企业微信API发回->员工在企业微信看到回复。

2.2 技术选型背后的考量

为什么选择自建服务，而不是用现成的SaaS工具？核心原因是数据安全与定制化。企业内部的沟通数据、知识文档都非常敏感，通过自建服务，所有数据（用户问题、Claude的回复、知识库）的流转都可以控制在自己的服务器内，只有向Claude API发送的请求会出境（这部分内容也需注意合规）。同时，自建服务可以完全自定义逻辑，比如增加权限校验（只允许特定部门使用）、记录审计日志、对接其他内部系统等。

在编程语言和框架上，Python是首选。因为它有最丰富的大模型生态（OpenAI/Anthropic的SDK、LangChain等框架）和向量数据库客户端。Web框架可以选择轻量级的FastAPI或Flask，它们能快速搭建RESTful接口。对于需要维护对话状态的场景，Redis是一个很好的选择，它读写速度快，适合存储会话上下文。如果知识库文档不多，初期甚至可以用本地文件缓存上下文，但这不是长久之计。

关于Claude模型的选择，Anthropic提供了多个版本。对于通用问答，claude-3-haiku（最快，成本最低）或claude-3-sonnet（平衡型）是不错的选择。如果重点是代码生成与审查，那么claude-3.5-sonnet或专门的claude-code系列能力更强。你需要根据实际需求（响应速度、精度、成本）在后台配置可切换的模型列表。

注意：调用Claude API会产生费用，并且网络请求到海外服务可能存在延迟。在架构设计时，务必考虑增加请求超时、失败重试、以及用量监控和告警机制，避免因为API不稳定或费用超支导致服务不可用。

3. 关键环节实现与实操步骤

理论讲完了，我们进入实战环节。我会以Python + FastAPI + Redis的技术栈为例，分步说明如何搭建这个服务。

3.1 第一步：准备“原料”——账号与配置

工欲善其事，必先利其器。在写代码之前，先把几个必要的账号和配置搞定。

1. 注册Anthropic账号并获取API Key：

   • 访问Anthropic官网，注册账号。通常需要验证邮箱，可能还需要等待审核（特别是新注册）。
   • 在账号控制台，找到创建API Key的地方，生成一个新的Key。这个Key像密码一样重要，务必妥善保存，不要提交到代码仓库。我们后续会把它放在环境变量里。

2. 创建企业微信应用：

   • 登录你的企业微信管理后台。
   • 进入“应用管理” -> “自建应用”，点击“创建应用”。填写应用名称（如“Claude智能助手”）、上传Logo，并选择可见范围（即哪些部门或成员可以使用这个助手）。
   • 创建成功后，记录下三个关键信息：CorpID（企业ID）、AgentId（应用ID）、Secret（应用密钥）。同样，Secret需要保密。
   • 配置“接收消息”：
     • 在应用详情页，找到“接收消息”设置。
     • 你需要提供一个公网可访问的URL，作为企业微信推送消息的入口。在开发阶段，你可以使用内网穿透工具（如ngrok、localtunnel）将本地的服务临时暴露到公网，方便调试。将这个URL填入“接收消息”的API地址栏。
     • 点击“随机生成”获取一个Token和一个EncodingAESKey，并记录下来。这两个参数用于验证消息是否真的来自企业微信服务器，防止他人伪造请求。

3. 准备服务器与环境：

   • 准备一台具有公网IP的云服务器（如阿里云ECS、腾讯云CVM）。操作系统推荐Ubuntu 22.04 LTS。
   • 在服务器上安装Python（建议3.9以上版本）、Redis。可以使用以下命令快速安装：

     # Ubuntu 示例 sudo apt update sudo apt install python3-pip python3-venv redis-server -y sudo systemctl enable redis-server sudo systemctl start redis-server

3.2 第二步：搭建消息中转服务（核心代码解析）

现在我们来编写核心的中转服务。创建一个项目目录，并初始化虚拟环境。

mkdir wecom-claude-bot && cd wecom-claude-bot python3 -m venv venv source venv/bin/activate pip install fastapi uvicorn anthropic redis requests pydantic-settings

接下来，我们创建几个核心文件。

1. 配置文件 (config.py)： 这里我们用pydantic-settings来管理配置，方便从环境变量读取敏感信息。

from pydantic_settings import BaseSettings class Settings(BaseSettings): # Anthropic 配置 anthropic_api_key: str anthropic_base_url: str = "https://api.anthropic.com" claude_model: str = "claude-3-haiku-20240307" # 默认模型，可按需更改 # 企业微信配置 wecom_corp_id: str wecom_agent_id: str wecom_secret: str wecom_token: str wecom_encoding_aes_key: str # Redis配置 (用于存储对话上下文) redis_url: str = "redis://localhost:6379/0" class Config: env_file = ".env" settings = Settings()

然后在项目根目录创建一个.env文件，填入你的真实配置（切记将此文件加入.gitignore）：

ANTHROPIC_API_KEY=你的Anthropic_API_Key WECOM_CORP_ID=你的企业ID WECOM_AGENT_ID=你的应用ID WECOM_SECRET=你的应用Secret WECOM_TOKEN=企业微信后台生成的Token WECOM_ENCODING_AES_KEY=企业微信后台生成的EncodingAESKey

2. 企业微信消息加解密与验证模块 (wecom_crypto.py)： 企业微信服务器推送的消息是加密的，我们需要根据官方提供的算法进行解密和回复加密。这里简化处理，你可以直接使用企业微信官方提供的Python示例代码中的WXBizMsgCrypt类。由于代码较长，此处概述其作用：它利用Token,EncodingAESKey,CorpID来验证消息签名、解密消息体、以及加密回复消息。

3. 主服务应用 (main.py)： 这是FastAPI应用的核心。

from fastapi import FastAPI, Request, HTTPException from fastapi.responses import PlainTextResponse import xml.etree.ElementTree as ET import hashlib import time from typing import Optional import redis import anthropic from config import settings # 假设我们已经将企业微信的加解密类导入为 WXBizMsgCrypt from wecom_crypto import WXBizMsgCrypt app = FastAPI() wxcpt = WXBizMsgCrypt(settings.wecom_token, settings.wecom_encoding_aes_key, settings.wecom_corp_id) redis_client = redis.from_url(settings.redis_url) anthropic_client = anthropic.Anthropic(api_key=settings.anthropic_api_key, base_url=settings.anthropic_base_url) def get_conversation_history(session_id: str) -> list: """从Redis获取指定会话的历史消息""" history_json = redis_client.get(f"conversation:{session_id}") if history_json: return json.loads(history_json) return [] def save_conversation_history(session_id: str, history: list, max_length: int = 10): """保存会话历史到Redis，并控制最大长度""" # 只保留最近 max_length 轮对话 if len(history) > max_length * 2: # 每轮包含用户消息和助手消息 history = history[-(max_length * 2):] redis_client.setex(f"conversation:{session_id}", 3600, json.dumps(history)) # 设置1小时过期 @app.get("/wecom") async def verify_url(request: Request): """企业微信验证回调地址（GET请求）""" query_params = dict(request.query_params) msg_signature = query_params.get("msg_signature", "") timestamp = query_params.get("timestamp", "") nonce = query_params.get("nonce", "") echostr = query_params.get("echostr", "") ret, sEchoStr = wxcpt.VerifyURL(msg_signature, timestamp, nonce, echostr) if ret != 0: raise HTTPException(status_code=403, detail="验证失败") return PlainTextResponse(content=sEchoStr) @app.post("/wecom") async def handle_wecom_message(request: Request): """处理企业微信推送的消息（POST请求）""" query_params = dict(request.query_params) msg_signature = query_params.get("msg_signature", "") timestamp = query_params.get("timestamp", "") nonce = query_params.get("nonce", "") # 读取加密的请求体 body = await request.body() post_data = body.decode('utf-8') # 解密消息 ret, decryp_msg = wxcpt.DecryptMsg(post_data, msg_signature, timestamp, nonce) if ret != 0: raise HTTPException(status_code=403, detail="解密失败") # 解析XML消息 xml_tree = ET.fromstring(decryp_msg) msg_type = xml_tree.find("MsgType").text from_user = xml_tree.find("FromUserName").text content = xml_tree.find("Content").text.strip() if xml_tree.find("Content") is not None else "" # 只处理文本消息 if msg_type != "text": return PlainTextResponse("success") # 构建会话ID（这里用“应用ID_用户ID”简单标识） session_id = f"{settings.wecom_agent_id}_{from_user}" # 获取历史对话 history = get_conversation_history(session_id) # 构建发送给Claude的消息列表 messages = [] for h in history: role = "user" if h["type"] == "user" else "assistant" messages.append({"role": role, "content": h["content"]}) # 加入当前用户消息 messages.append({"role": "user", "content": content}) try: # 调用Claude API response = anthropic_client.messages.create( model=settings.claude_model, max_tokens=1024, messages=messages ) reply_content = response.content[0].text except Exception as e: reply_content = f"调用AI服务时出错：{str(e)}" # 更新对话历史 history.append({"type": "user", "content": content}) history.append({"type": "assistant", "content": reply_content}) save_conversation_history(session_id, history) # 加密并回复消息 resp_xml = f"""<xml> <ToUserName><![CDATA[{from_user}]]></ToUserName> <FromUserName><![CDATA[{settings.wecom_agent_id}]]></FromUserName> <CreateTime>{int(time.time())}</CreateTime> <MsgType><![CDATA[text]]></MsgType> <Content><![CDATA[{reply_content}]]></Content> </xml>""" ret, encrypt_msg = wxcpt.EncryptMsg(resp_xml, nonce) return PlainTextResponse(content=encrypt_msg)

这个main.py做了几件关键事：

• 提供了/wecom端点，同时处理企业微信的验证（GET）和消息推送（POST）。
• 收到加密消息后，使用官方库解密，并解析出用户ID和问题内容。
• 以“应用ID+用户ID”为键，从Redis中获取该用户的过往对话历史，形成一个连贯的上下文。
• 将历史对话和当前问题组合，调用Claude API。
• 将Claude的回复和当前对话更新到Redis，并设置过期时间（这里设了1小时，避免无限增长）。
• 最后，将回复内容加密，返回给企业微信服务器。

4. 运行与测试： 在本地启动服务：

uvicorn main:app --reload --host 0.0.0.0 --port 8000

使用ngrok将本地的8000端口暴露到公网：

ngrok http 8000

ngrok会生成一个https://xxxx.ngrok.io的地址。将这个地址（后面加上/wecom）填入企业微信应用后台的“接收消息”URL中。 在企业微信里向这个应用发送消息，你应该就能收到Claude的回复了。

3.3 第三步：进阶功能——集成内部知识库（RAG）

基础问答实现了，但如果想让助手回答“公司今年的年假政策是什么？”这类内部问题，就需要连接知识库。这里简述RAG的集成思路：

1. 文档预处理与向量化：

   • 收集内部文档（Markdown、PDF、Word等），使用文本分割器（如LangChain的RecursiveCharacterTextSplitter）将长文档切成语义相关的小片段。
   • 使用嵌入模型（Embedding Model，如OpenAI的text-embedding-3-small，或开源的sentence-transformers模型）将每个文本片段转换为一个高维向量（一堆数字）。
   • 将这些向量及其对应的原始文本片段，存储到向量数据库（如Chroma）中。

2. 在服务中集成检索逻辑：

   • 当用户提问时，先用同样的嵌入模型将问题转换为向量。
   • 用这个向量去向量数据库中搜索，找出最相似的几个文本片段（即top_k个结果）。
   • 将这些片段作为“参考依据”，和用户问题一起构造一个更丰富的Prompt给Claude，例如：“请根据以下信息回答问题：[检索到的文本片段1][片段2]... 问题：[用户原问题]”。
   • Claude会根据你提供的参考信息生成答案，准确性和针对性会大大提升。

这部分代码量会增加不少，涉及到异步处理、向量数据库操作等。一个简单的伪代码示例，展示在主服务中如何加入检索步骤：

# 假设我们已经初始化了向量数据库客户端 vector_db 和嵌入模型 embedding_model from your_rag_module import retrieve_relevant_docs @app.post("/wecom") async def handle_wecom_message(request: Request): # ... [前面的解密、解析代码不变] ... user_question = content # 检索相关文档 relevant_docs = retrieve_relevant_docs(user_question, top_k=3) # 构建包含上下文的Prompt context_prompt = "" if relevant_docs: context_prompt = "请参考以下信息：\n" + "\n---\n".join(relevant_docs) + "\n\n" final_question = context_prompt + "问题：" + user_question # 将 final_question 放入 messages 中，代替原来的 content # ... [后续调用Claude和回复的代码不变] ...

实操心得：知识库的构建质量直接决定RAG的效果。文本分割的大小、嵌入模型的选择、检索策略（是否使用元数据过滤）都需要仔细调优。初期建议从一个小的、结构清晰的文档集（如产品API文档）开始，快速验证流程，再逐步扩大范围。

4. 部署上线与性能调优

本地测试通过后，就要考虑如何让服务7x24小时稳定运行。

4.1 生产环境部署

1. 服务器部署：将代码上传到你的云服务器。建议使用Git进行版本管理。
2. 使用进程管理器：不要直接用uvicorn main:app在后台运行。使用systemd或supervisor来管理进程，实现开机自启、崩溃重启。下面是一个简单的systemd服务文件示例（/etc/systemd/system/wecom-claude.service）：

   [Unit] Description=WeCom Claude Bot Service After=network.target redis.service [Service] Type=simple User=www-data Group=www-data WorkingDirectory=/path/to/your/wecom-claude-bot Environment="PATH=/path/to/your/wecom-claude-bot/venv/bin" ExecStart=/path/to/your/wecom-claude-bot/venv/bin/uvicorn main:app --host 0.0.0.0 --port 8000 --workers 2 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

   启用并启动服务：

   sudo systemctl daemon-reload sudo systemctl enable wecom-claude sudo systemctl start wecom-claude sudo systemctl status wecom-claude # 检查状态

3. 配置反向代理与SSL：使用Nginx或Caddy作为反向代理，将80/443端口的请求转发到本地的8000端口。更重要的是，配置SSL证书（可以使用Let‘s Encrypt免费证书），将你的服务域名升级为HTTPS。企业微信要求接收消息的服务器地址必须是HTTPS。

   # Nginx 配置示例 (部分) server { listen 443 ssl; server_name your-bot-domain.com; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

4. 更新企业微信配置：将企业微信后台“接收消息”的URL，从ngrok地址改为你自己的域名（例如https://your-bot-domain.com/wecom）。

4.2 性能、安全与成本优化

服务跑起来只是第一步，要让它稳定、安全、不烧钱，还得做不少优化。

1. 异步处理与队列：直接在主请求流程中调用Claude API可能会阻塞，如果API响应慢，会导致企业微信服务器重试。一个更好的方案是引入消息队列（如Redis List或Celery）。当收到用户消息后，立即返回“success”给企业微信，然后将任务放入队列，由后台Worker异步调用Claude API并发送回复。这能显著提高接口的响应速度和可靠性。

2. 限流与降级：为了防止恶意调用或意外流量导致API费用暴涨，必须实施限流。可以在服务入口处（或Nginx层）对每个用户/会话进行频率限制。同时，设置一个预算监控，当当月API调用费用接近预算时，自动切换到一个更便宜的模型（如从Sonnet降到Haiku），或者直接返回“服务繁忙”的提示，实现降级。

3. 上下文管理的优化：我们之前用Redis存储了完整的对话历史。对于长对话，这会导致每次请求的Prompt非常长，增加API调用成本和延迟。可以优化为只存储最近几轮的对话，或者使用Claude API本身支持的“系统提示词”（System Prompt）来设定助手的角色和背景，减少对历史上下文的依赖。对于超长对话，可以考虑自动总结之前的对话内容，将总结作为新的上下文，而不是传递全部历史。

4. 安全加固：

   • IP白名单：在企业微信应用后台，可以配置“接收消息”的服务器IP白名单。将你的服务器公网IP填进去，这样只有来自企业微信官方IP的请求才会被处理。
   • Token验证：我们代码中已经通过WXBizMsgCrypt进行了签名验证，这是必须的。
   • 日志与审计：记录所有用户请求和AI回复的日志（注意脱敏），便于事后审计和问题排查。但日志要妥善保管，避免泄露敏感信息。
   • 内容过滤：可以在调用Claude API前，对用户输入进行一层简单的内容安全过滤，拦截明显违规或恶意的提问。也可以在Claude的回复返回后，再做一次过滤，确保输出内容符合企业规范。

5. 常见问题排查与实战经验

在实际搭建和运维过程中，你肯定会遇到各种问题。我把一些典型问题和解决方法整理如下，希望能帮你少走弯路。

5.1 企业微信集成相关

问题1：企业微信验证回调URL失败，提示“签名错误”或“解密失败”。

• 排查步骤：
  1. 检查URL和Token：确认你在企业微信后台填写的URL、Token、EncodingAESKey与代码中使用的完全一致，注意不要有空格或换行。
  2. 检查加解密库：确保你使用的WXBizMsgCrypt类与企业微信官方提供的版本一致，且Python环境兼容。不同语言版本的加解密库不能混用。
  3. 检查时间戳：企业微信服务器会对时间戳进行校验，如果服务器时间不同步可能导致失败。确保你的服务器时间（NTP同步）是准确的。
  4. 检查网络：使用curl或Postman模拟企业微信的验证请求，看你的服务是否能正确响应。确认你的服务端口（8000）和反向代理配置正确，且防火墙已放行。

问题2：能收到消息，但无法回复，或用户收不到回复。

• 排查步骤：
  1. 检查日志：查看服务日志，确认是否成功调用了Claude API以及是否成功执行了回复的加密步骤。
  2. 检查企业微信应用权限：登录企业微信管理后台，确保该应用有“发送消息”的权限。
  3. 检查回复XML格式：企业微信对回复消息的XML格式要求严格。确保ToUserName和FromUserName的值是正确的（分别是接收者用户ID和你的应用ID），并且整个XML结构完整。可以使用在线XML格式化工具检查你生成的resp_xml字符串。
  4. 检查异步处理：如果你使用了消息队列异步回复，请确认Worker进程正常运行，并且有权限调用企业微信的发送消息API（需要Access Token）。

5.2 Claude API调用相关

问题3：调用Claude API超时或返回错误。

• 可能原因与解决：
  • 网络问题：到Anthropic服务器的网络不稳定。考虑在服务端部署网络代理（需确保合规），或者使用云服务商提供的海外加速服务。
  • 额度不足：检查Anthropic控制台，确认API Key的额度或余额是否充足。
  • 速率限制：Anthropic API有调用频率限制（RPM/TPM）。如果请求太频繁，会被限流。需要在代码中实现指数退避的重试机制，并控制单个Key的调用频率。
  • 模型不可用：偶尔目标模型可能暂时不可用。可以在代码中实现模型降级策略，比如首选claude-3.5-sonnet，失败后尝试claude-3-sonnet。

问题4：Claude的回复内容不符合预期，比如胡言乱语或拒绝回答。

• 优化方向：
  • 优化Prompt：Claude对Prompt非常敏感。在系统提示词（System Prompt）中清晰地定义助手的角色、职责和边界。例如：“你是一个企业内部助手，负责回答技术问题和流程咨询。如果问题涉及公司未公开信息，请回答‘我无法回答这个问题’。请用中文回复。”
  • 控制上下文长度：过长的上下文可能导致模型注意力分散。定期清理或总结旧的对话历史。
  • 调整参数：尝试调整API调用时的temperature（创造性，越低越确定）和max_tokens（最大生成长度）参数。对于企业应用，通常设置较低的temperature（如0.2）以获得更稳定、可靠的输出。

5.3 服务运维相关

问题5：服务运行一段时间后，响应变慢或内存占用高。

• 排查与解决：
  • 检查Redis：如果使用了Redis存储上下文，检查Redis内存使用情况。为Redis设置合理的最大内存限制和淘汰策略（maxmemory-policy），如allkeys-lru。
  • 检查Python进程：使用htop或ps命令查看UVicorn worker进程的内存和CPU占用。如果持续增长，可能存在内存泄漏。检查代码中是否有全局变量无限增长，或者没有正确关闭的连接（如数据库、HTTP客户端）。
  • 引入监控：使用Prometheus+Grafana监控服务的请求量、响应时间、错误率以及Claude API的调用延迟和费用。设置告警，在指标异常时及时通知。

问题6：如何控制成本？

• 成本控制策略：
  • 用量监控：在Anthropic控制台设置预算和用量告警。在自建服务中，也记录每个用户、每个会话的Token消耗情况。
  • 模型分级：根据问题的复杂程度选择模型。例如，简单的问候和查询用Haiku，复杂的代码分析和生成用Sonnet。可以在用户提问时做一个简单的意图识别，或者让用户通过指令选择模型（如“@助手 /code 帮我写一个Python函数”）。
  • 上下文优化：如前所述，优化上下文管理是降低Token消耗最有效的方法之一。
  • 设置对话轮次上限：强制在对话达到一定轮次后清空历史，或提示用户开始新话题，防止无限长的对话消耗大量Token。

最后，分享一个我踩过的“坑”：初期没有做消息队列，当Claude API偶尔响应慢到10秒以上时，企业微信服务器会因收不到及时响应而多次重试，导致同一个问题被处理了多次，不仅浪费API调用次数，还给用户发送了重复的回复。所以，对于任何可能耗时的外部API调用，异步化+消息队列是生产环境必须考虑的方案。另一个小技巧是，在企业微信应用的自定义菜单里，可以加一个“清空上下文”的按钮，点击后调用一个后端接口清除该用户的Redis记录，这对于用户遇到助手“胡言乱语”时自助解决问题非常有用。