企业官网建设流程全解析

1. 企微机器人选型：先搞清楚你要的是哪种“群聊机器人”

动手之前得先泼一盆冷水：很多人一听到“群聊机器人”，下意识就以为企业微信提供了一套万能的对话接口，直接把 Agent 接上去就能在群里聊起来。实际上企业微信对机器人能力的划分比想象中更细，选错方案会让后面的开发路径完全不一样。

企业微信里能“跑”的机器人主要有两类。第一类是群机器人（Webhook 机器人），它本质是一个群聊专用的消息推送入口，你往它配置的 Webhook 地址 POST 一段 JSON，它就把消息发到群里。这类机器人最适合消息通知场景，比如 CI 构建结果、监控告警、日报定时推送。它不能接收群成员的消息，更不可能“聊天”。第二类是自建应用下的智能机器人（也就是企业微信 App 里配置的回调服务），成员在群里 @机器人 或在单聊里直接给应用发消息时，企业微信会把消息内容通过回调推送到你的 HTTP 服务地址上，由你的服务处理后返回应答。这才是真正意义上的“对话机器人”，也是把 Agent 塞进企业微信时最常走的通路。

有些团队会绕开回调方案，直接开发一个外部服务，用“机器人账号”或者中转个人号去模拟收发消息，这类路子稳定性差，而且平台风控严格，一旦被判定为第三方接入很容易封号。合规的做法永远是走企业微信官方提供的回调接口，或者先通过群机器人 Webhook 做单向能力验证，再逐步向双向对话演进。

我的建议是：如果你的 Agent 最终要做成“群里 @它就能干活”的形态，一步到位选中“自建应用 + 回调 URL”方案。如果只是想把 Agent 的产出或通知丢进群里给人看，那就用群 Webhook 机器人，省时省力，连服务端都不用常驻。

为了把两类方案的边界彻底理清，我用一张表做了对比，方便你直接按场景挑。

如果你只是做通知播报，千万别为了追求“智能机器人”而给自己挖坑；如果你做的是多技能 Agent，就别在 Webhook 机器人上浪费时间，因为它根本接不住对话。

2. 第一步先跑通 HTTP 服务：Agent 的“外接大脑”

任何智能体要接入企微，绕不开一个基础动作：先把 Agent 的本体变成一个 HTTP 服务。不夸张地说，这一步是整个项目的地基，地基稳不稳，直接决定后面调试回调接口时你会不会崩溃。

2.1 服务骨架选择与配置

Agent 的 HTTP 服务本质上是一个可以接收外部请求、调用 LLM 和工具、返回结构化结果的 Web 应用。技术栈不用纠结，FastAPI（Python）、Flask（Python）、Express（Node.js）和 Spring Boot（Java）都是社区里验证过无数遍的方案。我自己的项目用的是 FastAPI，理由很简单：异步支持好，LLM 调用天然适合异步 IO；自带 OpenAPI 文档，调试回调时能直接看到接口请求体；类型提示和 Pydantic 的数据校验，在解析企业微信回调 JSON 时省心很多。

服务需要暴露的接口通常就两类：一个是回调接口，用于接收企业微信推送过来的消息；一个是健康检查接口，用于让企业微信和运维平台确认服务存活。下面是最小可用的 FastAPI 骨架。

from fastapi import FastAPI, Request from pydantic import BaseModel app = FastAPI(title="WeCom Agent Gateway") class CallbackBody(BaseModel): msg_signature: str timestamp: str nonce: str echostr: str @app.get("/health") async def health_check(): return {"status": "alive"} @app.post("/wecom/callback") async def wecom_callback(body: CallbackBody, request: Request): # 具体的验签和解密逻辑在下一节展开 return {"code": 0}

有两点需要注意。第一，企业微信的回调接口对响应时间有严格要求，超时会有重试，所以不要在回调请求里同步等待 Agent 的长时间思考，异步任务队列几乎是必须的。第二，回调地址必须是公网可访问的 HTTPS 地址，证书需要是正规机构签发的，自签名证书企业微信不认。

2.2 多技能注册机制：让 Agent 知道自己会什么

Agent 接入企业微信后，真正难的不是“收到消息”，而是“收到消息后怎么干活”。多技能 Agent 的核心在于有一套明确的技能注册表：Agent 能做什么、每个技能怎么触发、每个技能需要哪些参数、技能执行完如何组织回复，这些必须在代码里被显式管理，而不是让 LLM 自己碰运气。

我习惯把技能定义成一组函数，然后用一个统一的注册器收集起来。每个技能函数带有描述、参数 schema、调用函数三要素，LLM 收到用户问题后先“看”技能描述，再决定调用哪个函数。

import inspect from typing import Callable, Dict, Any # 技能注册表：全局唯一，所有技能注册到这里 SKILL_REGISTRY: Dict[str, Any] = {} def register_skill(name: str, description: str, param_schema: Dict): """ name: 技能名，供 LLM 调度时引用 description: 对 LLM 描述的技能用途，越详细越好 param_schema: 参数 JSON Schema，LLM 按这个结构传参 """ def decorator(func: Callable): SKILL_REGISTRY[name] = { "name": name, "description": description, "param_schema": param_schema, "function": func, "signature": str(inspect.signature(func)), } return func return decorator @register_skill( name="get_weather", description="查询指定城市的实时天气，城市名是必填参数", param_schema={ "type": "object", "properties": { "city": {"type": "string", "description": "城市名，例如北京、上海"} }, "required": ["city"] } ) def get_weather(city: str): # 这里调用真实天气 API 并返回结构化的天气信息 return {"city": city, "temperature": 26, "condition": "晴"};

把技能集中注册之后，Agent 的主循环就变成了“接收消息 -> 拆解意图 -> 匹配技能 -> 执行技能 -> 汇总回复”这样一个清晰的链路。后面接企微回调时，所有的群聊消息最终都会进入这条链路，业务逻辑完全和渠道解耦，你可以同一套 Agent 服务同时接企业微信、飞书、钉钉，只改最外层适配器。

多说一句，技能描述的质量直接决定了 LLM 的调用准确率。我踩过的坑是：描述写得太抽象，比如“查询天气”，LLM 经常不知道该传什么参数；改成“查询指定城市的实时天气，城市名是必填参数，例如杭州、深圳”，准确率立刻提升一大截。技能描述不是写给人看的，是写给模型看的，要明确到参数级别。

3. 企业微信回调接入：从消息到 HTTP 请求的完整链路

服务已经就绪、技能已经注册，接下来这一步是把“企微消息”变成“HTTP 请求”。企业微信的自建应用回调机制不算复杂，但它是一套独立的协议，理解整条链路能让后续调试少走好多弯路。

3.1 回调消息的解密与校验

企业微信在创建自建应用时，可以配置一个“接收消息服务器”，里面填 URL、Token、EncodingAESKey 三个参数。前两个用于验证请求合法性，EncodingAESKey 用于消息体的加解密。官方提供了一套加解密库，但很多语言版本需要自己集成，我第一次接的时候就在这里耽误了一整天。

核心流程是这样的：

1. 企业微信服务器带着msg_signature、timestamp、nonce和消息体请求你的回调 URL。
2. 你先用 Token、timestamp、nonce 做一次签名校验，按官网规定的排序拼接规则生成签名，与msg_signature比对，一致才会继续处理。
3. 校验通过后，对消息体做 AES 解密，得到明文 XML/JSON，里面才是FromUserName、Content、MsgType这些真正的消息字段。
4. 处理完业务后，回复加密 JSON 或原样返回空串。

这个流程里最容易被忽略的点是：验证回调 URL 时，企业微信会 GET 请求你的回调接口，并带上echostr参数，你需要解密echostr成功后才原样返回明文，否则配置无法保存。很多第一次接的人死在这一步，服务没处理 GET 方法，企业微信一直提示“URL 配置失败”。

3.2 群聊消息的三种形态：@、关键词、单聊

代理接入企业微信后，会收到多种不同类型的消息。处理好这些消息是一个合格企业级 Agent 的基本功。用代码把消息解析逻辑沉淀下来，避免每次聊天都走一遍完整链路。

以下是一个精简的群聊消息处理示例：

from typing import Tuple, Optional def parse_chat_message(raw_payload: dict) -> Tuple[Optional[str], Optional[str], Optional[str]]: """ 从企微回调的原始数据中提取会话信息。 返回: (消息类型, 群ID或用户ID, 文本内容) 实际数据经过解密后，字段名这里做了示意。 """ event_type = raw_payload.get("Event", "message") chat_id = raw_payload.get("ChatId") text = "" # 这是一个简化的解析逻辑，真实数据结构会复杂不少 if "content" in raw_payload: text = raw_payload["content"] return event_type, chat_id, text @app.post("/wecom/callback") async def wecom_callback(request: Request): # 前置的验签、解密过程这里省略 raw = await request.json() event_type, chat_id, text = parse_chat_message(raw) # 只处理群聊消息，其他事件根据需要扩展 if event_type == "message" and chat_id: result = await agent_loop(text, context_schema) return {"result": result}

一个经验值：群聊里的消息触发 Agent 前，必须做去重。企业微信的群消息会有多端同步的情况，某些场景下同一消息可能回调多次，如果 Agent 是无状态地直接处理，会出现“同一个问题回复两遍”的尴尬。我习惯在消息解析层维护一个 3-5 秒的短时去重窗口，基于消息 ID 或内容哈希做过滤，能挡住很多重复消费的问题。

3.3 被动回复与主动推送的边界

企微回调的响应有严格的健康机制。如果你在回调请求里同步等待 Agent 输出（可能要几秒甚至十几秒），大概率会触发企微的 5 秒超时，然后企微会重试推送，从而造成消息重复。所以成熟的方案都是“异步处理 + 主动推送”：回调接口里只做鉴权和消息入库，立即返回空响应（或明文串）表示接收成功，然后把消息丢到 Redis/队列里，由异步 worker 去跑 Agent，跑完再通过企微的主动发送消息接口把答案推回群里。

主动推送的路径有两种选择：一是用“应用消息”接口，推送文本/图文卡片到指定群聊；二是用“群机器人 Webhook”补充推送纯文本的信息。前者有权限控制，后者更轻量。我在 Agent 场景里主要依赖应用消息接口，因为它能携带 markdown 和图文，交互感强很多。

4. 多技能 Agent 的技能调度策略：别让模型自由发挥

把 HTTP 服务和企微回调接通之后，Agent 服务的核心问题就只剩下一个：群里的用户说了一句话，Agent 怎么才能用对的技能干活。这一节我讲讲我的完整调度策略，包含技术选型的分析和为什么不能只依赖 LLM 自由发挥。

4.1 技能注册表 + 意图路由的配合

前面提到的SKILL_REGISTRY解决了“有什么”的问题，但现在缺一个“怎么选”的机制。有两种主流方案，各有优劣。

方案一是纯提示词调度：把技能列表（名称+描述+参数）塞进 system prompt，让 LLM 自己决定调用哪个技能并输出结构化 JSON。优点是实现简单、扩展性好，适合技能数量少（10 个以内）的场景。缺点是模型可能幻觉出不存在的技能名，或者参数填错。方案二是指令规则预路由：先用正则、关键词匹配把消息分类到具体技能，再让 LLM 在类内填充细节参数，优点是精准、可预测、成本低，缺点是不能处理复杂语义。

我在真实项目中用的是混合策略：先跑一个轻量的分类模型或规则引擎，把消息粗分到技能大类；然后在大类内部，让 LLM 从这一类下挂载的具体技能里选出最合适的一个，并补全参数。这样既保留了 LLM 的泛化能力，又用规则兜底防止它跑偏。技能列表越来越多以后，这个分层设计的优势会非常明显——你不会想让系统提示词里躺着 50 个技能描述白白挤占上下文窗口。

async def agent_loop(user_text: str) -> str: # 第一层：规则/分类器，粗分技能域 skill_domain = route_by_domain(user_text) # 第二层：限定该技能域下的候选技能，交给 LLM 精排 candidates = [s for s in SKILL_REGISTRY.values() if s["domain"] == skill_domain] selected = await llm_select_skill(user_text, candidates) # 第三层：LLM 从 selected.param_schema 生成参数并调用函数 params = await llm_generate_params(user_text, selected) result = selected["function"](**params) return format_reply(selected["name"], result)

这套流程的关键收益是：LLM 每次只需要面对一小撮候选技能，幻觉率大幅降低，响应 token 更短，成本更省。同时因为路由规则是显式可控的，出问题时你能非常快地定位是规则没匹配上，还是 LLM 选错了。

4.2 超时与降级：群聊场景的保命符

群聊机器人有个很特殊的压力：同一时刻可能有多个群多个人同时发消息。虽然你只有一个 Agent，但瞬时请求量可能是并发起伏的。如果不做超时控制和降级策略，一个慢技能（比如某个外部 API 挂了）会拖死整个服务。

我的做法是给每个技能的执行包一层asyncio.wait_for，给 AI 调用和技能执行各自设定独立的超时时间。执行超时后立即返回“我这边暂时卡住了，稍后再试”之类的兜底话术，而不是让调用者一直干等。同时所有技能函数的耗时统计都打到日志里，定期查哪些技能普遍偏慢，针对性优化。

另一个必须设计的是幂等与重试。企业微信回调本身就自带重试机制，你的 Agent 技能如果对外部系统有写操作，一定要在技能内部设计幂等字段（比如按消息 ID 去重），避免外部系统重复扣款、重复建单这类事故。

4.3 技能上下文：多轮对话里的记忆墙

多技能 Agent 在群聊中要面对的一个麻烦是“多轮上下文”的取舍。谁的 @我 就在这个上下文里追加一条，但群聊是嘈杂的，无关消息过多会把有用的上下文稀释掉。我的策略是设置一个时间窗口，比如近 30 分钟内的、以当前发言人为中心的对话历史才保留；超过时间窗口的消息全部重置。这个既避免了上下文爆炸，也让 Agent 不会被陈旧的对话干扰。

另外，为了控制 prompt 长度，我会在每条历史消息前做一次抽取式摘要，把无关的寒暄压缩掉。你不需要把每句话都喂给模型，保留跟任务相关的信息就够了。这一步做得好不好，直接决定 Agent 在活跃的大群里还能不能保持稳定的响应质量。

5. 完整示例：让 Agent 在企微群里完成天气查询、备忘记录和问答

这一节给出一套可以直接复制改写的完整示例。为了能实际演示“多技能”的效果，我设计了三个技能：天气查询、备忘录增删查、企业知识库问答。这三个技能覆盖了“实时数据获取”“写入与持久化”“基于知识库检索回答”三类典型能力，刚好对应多技能 Agent 最常见的三种形态。

5.1 工程目录与小规模架构

示例工程不会很庞大，但层次清晰，方便你做小步快跑地横向迁移。

wecom-agent-example/ ├── main.py # FastAPI 入口，暴露 /wecom/callback ├── wecom/ │ ├── crypto.py # 企微回调验签与解密 │ └── client.py # 主动发送消息的企微 API 封装 ├── agent/ │ ├── core.py # agent_loop 主链路 │ ├── registry.py # SKILL_REGISTRY 和 register_skill │ ├── skills/ │ │ ├── weather.py # 天气查询技能 │ │ ├── memo.py # 备忘录技能 │ │ └── knowledge.py # 企业知识库问答技能 │ └── memory.py # 上下文窗口管理 ├── schemas/ │ └── wecom.py # 回调请求体 Pydantic 模型 └── requirements.txt

这个结构的妙处在于：企微相关的代码和 Agent 相关的代码完全分开，后面你要接飞书或者钉钉，只需要换掉wecom/这个目录，agent/部分原封不动。

5.2 核心链路代码

先看agent/core.py，它是整个 Agent 的主循环。为了阅读体验，我把日志、异常处理的细节做了裁剪。

# agent/core.py import asyncio from .registry import SKILL_REGISTRY from .memory import ChatMemory memory = ChatMemory(timeline_window_seconds=1800) async def agent_loop(user_text: str, user_id: str, group_id: str) -> str: chat_key = f"{group_id}:{user_id}" history = memory.get_history(chat_key) # 第一步：规则粗分类（基于内置关键词映射） domain = route_by_domain(user_text) # 第二步：在技能域内让 LLM 做技能精排（这里用伪代码代表 LLM 调用） candidates = [s for s in SKILL_REGISTRY.values() if s.get("domain") == domain] if not candidates: return "我还没有掌握这个领域的技能，换个问题试试？" selected = await llm_select_skill(user_text, candidates, history) # 第三步：生成参数并执行 params = await llm_generate_params(user_text, selected) try: result = await asyncio.wait_for(selected["function"](**params), timeout=10) except asyncio.TimeoutError: return "这个操作耗时有点久，我稍后帮你查一下，先看看别的？" except Exception as e: # 统一捕获技能异常，返回友好提示而非堆栈 return f"技能执行失败：{str(e)[:100]}" memory.append(chat_key, user_text, result) return format_reply(selected["name"], result)

route_by_domain在最简单版本里就是一组关键词映射：包含“天气”“温度”“下雨”等词映射到weather_domain；包含“记一下”“待办”“提醒”映射到memo_domain；其他的默认走knowledge_domain。这种朴素实现能覆盖掉很大一部分群聊里的日常调用，而且可以为不同领域设置完全不同的提示词，为 LLM 提供不同的场景预热。

技能本身则保持纯粹的业务函数，不依赖任何企微协议。比如memo.py的写入部分：

# agent/skills/memo.py import json, time from ..registry import register_skill from ..storage import redis_client @register_skill( name="add_memo", description="记录一条待办事项，需要包含事项内容本身，如果有截止时间也请提取出来", param_schema={ "type": "object", "properties": { "content": {"type": "string", "description": "待办事项内容"}, "deadline": {"type": "string", "description": "截止时间，可选"} }, "required": ["content"] }, domain="memo_domain" ) def add_memo(content: str, deadline: str = ""): key = f"memo:{int(time.time())}" redis_client.set(key, json.dumps({"content": content, "deadline": deadline}, ensure_ascii=False)) return {"success": True, "content": content, "deadline": deadline}

如果你自己写技能，也建议把技能函数保持成这种“只认识参数、不认识消息格式”的样子。这种解耦会让你后续扩展新技能的成本压到最低——只需要在registry.py里发现一个新函数，主链路完全不用动。

5.3 回调到主动推送的组装

main.py里的回调接口在验签解密后，直接做的事是“把消息塞进异步队列，立刻返回”。实际执行和回复放在 worker 里完成。

# main.py（简化版） import asyncio from fastapi import FastAPI, Request from wecom.crypto import decrypt_message from agent.core import agent_loop app = FastAPI() QUEUE = asyncio.Queue() async def worker(): while True: item = await QUEUE.get() try: reply = await agent_loop(item["text"], item["user"], item["group"]) await send_wecom_text(item["group"], reply) except Exception as e: await send_wecom_text(item["group"], f"服务开小差了：{e}") finally: QUEUE.task_done() @app.on_event("startup") async def startup(): asyncio.create_task(worker()) @app.post("/wecom/callback") async def callback(request: Request): payload = await request.json() # 验签、解密后拿到明文消息 plaintext = decrypt_message(payload) await QUEUE.put(plaintext) return "" # 立即响应空串，企微认为接收成功

注意这里的send_wecom_text是通过企业微信“应用消息”接口主动推送文本到群，需要后台配置应用可见范围包含目标群。这个推送动作才是用户真正“看到”Agent 回复的通道，速度取决于 worker 消费队列的速度和 LLM 的响应速度。

6. 部署上线后的真实挑战：频率限制、日志追踪与群聊噪音

把服务和逻辑写完，只是整个项目的上半场。真正让你在深夜被企业微信告警短信吵醒的，往往是那些代码里写不出来的运维细节。我把自己在部署生产环境后踩过的几个坑整理一下，这些内容比任何框架文档都要值钱。

6.1 企业微信的调用频率限制是实实在在的

企业微信接口有比较严格的频率限制，不是靠所谓“防封”手段能绕过的，必须在代码层面主动规避。主动发送消息接口的限制尤其明显，默认每分钟的调用量在一个有些紧张的额度的量级内（不同企业配置略有差异），而群聊场景下你可能同时在好几个群回复。如果你的 Agent 在一分钟内同时向五个群各发两条消息，可能就直接触发限频。

我的对策简单有效：一个接口级令牌桶限流器，控制 Agent 主动推送消息的速度，超出发送配额的消息先进入本地队列慢慢发；同时在代码里统一封装send_wecom_text，每次发送前经过限流器，避免上层业务旁路绕过。重点是不要把“限流”写在业务逻辑里，而是做成基础设施能力，谁发消息都走同一道闸门。

6.2 回调重试的“毒丸”问题

企业微信回调设计了一个很实在的重试机制：如果你的回调接口返回非 2xx 或超时，它会在一定时间窗口内不断重推同一事件。如果你的服务代码在处理消息时有非幂等副作用，重试就会导致严重后果。

比如有一个技能是在用户说“帮我订个会议室”后调用外部会议室系统下单，如果第一次处理时订房 API 成功但回调响应超时了，企微会重推消息，你的服务很可能又调用一次订房 API，导致重复预订。解决这个问题靠两层：第一层，在技能外部对每个消息 ID 做幂等判断，同一消息 ID 的请求一旦成功就把结果缓存，重试时直接返回缓存结果；第二层，对所有外部写操作强行要求接口侧提供幂等键。

6.3 日志追踪：群聊场景的“侦察兵”

群聊机器人调试最大的痛点是：一条消息从用户发出到你看到结果，中间隔了“企微回调 -> 验签解密 -> 队列 -> worker -> LLM -> 技能 -> 推送回复”这么多环节，任何一个环节出错都很难快速定位。因此日志链路追踪必须从一开始就设计好。

我的日志规范是使用请求 ID（或消息 ID）做全局链路标记，每进入一个环节就把相关信息带进日志，同时打印一条结构化 JSON 日志，包含时间、消息ID、用户ID、群ID、当前步骤、耗时、状态码。这样调试的时候用消息 ID 一搜，整条链路的每一跳耗时和错误信息都清清楚楚。不要指望靠 print 碰运气发现问题，结构化日志是降低你排查痛苦的最重要工具。

另外强烈建议接一套独立的错误告警通道（比如给运维群推消息或者走 email 告警），但注意监控信息的发送消息接口和业务发送的接口做好分离，别让告警挤占业务推送的限流配额。

6.4 群聊噪音：机器人也要学会“选择性反应”

最后列一个最容易被忽略的问题：在活跃大群里，你的 Agent 如果对任何 @它 的内容都回复，体验会极其糟糕。真实的群聊充斥着闲聊、图片、“哈哈哈哈”，如果 Agent 每一次 @ 都调用 LLM 生成一次回答，既消费昂贵 token，也容易给出无关内容。

我的策略是分层降噪。第一层：语义预判，在进入技能路由前，用一个轻量规则判断这条消息是不是真的需要干活——比如纯表情、纯语气词、少于 3 个字的内容，直接忽略回复。第二层：任务完成度判断，Agent 如果在技能执行结果里发现没有置信度较高的技能被匹配到，就复用“我暂时不太明白你的意思，你可以换个说法或者直接问天气、备忘录、知识库等能力”这样的固定话术，而不是硬编一段回复。第三层：配置群聊安静时段，比如深夜只看不回，避免打扰。

这套降噪机制上线后，用户对 Agent 的“打扰感”评价直线上升，后端成本也明显下降，属于性价比极高的改造。

7. 从示例到生产：下一步还能怎么扩展

如果你已经跑通了上面这套“HTTP 服务 + 企微回调 + 多技能 Agent”的链路，那其实已经具备了把 Agent 落地到真实业务环境的完整能力。下一步的扩展方向，我建议从这几个维度来挑。

第一个方向是把技能做成插件化热装载。当前SKILL_REGISTRY还是写死在代码里的，企业内部很多团队想自己加点自定义技能（比如查订单、查排班、跑报表），你不希望每次加技能都改主程序重新发布。可以做成技能目录扫描 + 动态 import + 配置管理，通过管理后台让运维在一个界面上启停技能、调整技能参数，这是企业级 Agent 平台的基本形态。

第二个方向是引入多轮对话的澄清机制。现在的问题如果缺参数，Agent 会直接尝试用默认值或报错。更优雅的做法是反问用户：“你说要查天气，但没说要查哪个城市，告诉我城市名就行。”这个可以用一个简单的“缺参追问”状态机来实现，LLM 负责判断参数缺什么，状态机负责控制轮次和终止条件，避免无限追问。

第三个方向是多 Agent 并行调度。当群里同时有多个不同技能域的请求时，与其让一个 Agent 串行处理，不如把不同域的消息分发到不同的 Agent 实例或者不同模型配置的 worker 池里。我这个示例的路由已经适配了这个方向，只要把route_by_domain的结果映射到不同的队列/消费者即可。

最后一个建议是关于模型选型的。群聊场景里，用户往往期待的是“快”，而不是“深”。在能被规则和技能解决的范围里，尽量用快模型处理；只有在技能无法覆盖、必须靠开放语义理解兜底时，才上强推理的大模型。一套良好的技能路由，实际上也是在帮你省钱——因为你不用每秒都拿最强模型去消化群里那堆“哈哈哈哈”和表情包。

我的实际体会是，把 Agent 接入企微这件事的难点从来不是“接入”，而是“在消息洪流中保持清醒”。企业微信只是消息的搬运工，真正决定产品价值的，是你有没有一个结构清晰、技能可扩展、降噪合理的 Agent 核心。按照这个思路一步步打磨，即使一开始只接了三五个技能，随着业务侧的反馈越来越多，这个系统也会自然生长，从一个“会聊天的机器人”慢慢变成一个真正能替人干活的数字同事。