接个人微信 API 的项目，常见误区是一上来把所有接口全接一遍。实际上多数应用只用到其中一小部分。Eyun API 的接口按能力可以分成 3 个级别，规划阶段先想清楚你的应用需要哪一级，开发量和维护成本能差好几倍。
一、只读级能力：只"看"不"发"
只拉取数据，不发送消息，也不接回调。包含接口就两类：消息记录拉取、联系人同步。
适用应用：数据分析工具、聊天记录备份工具、好友列表管理工具。
大白话：定时调一次 Eyun 的拉取类接口，把历史消息或好友列表拉下来存好，任务就结束了。不用部署 Webhook 服务，也用不到 sendText，是最轻的一种接法。
二、交互级能力：能收能发，构成完整对话
在拉取之外，加上"收"和"发"两条链路：
收：Eyun API 的 Webhook 回调覆盖消息、好友、群、状态 4 类事件，推送到回调地址后需在 5 秒内返回 200，超时会重试 3 次；
发：sendText、sendImage、sendFile 三个发送接口。按照 Eyun 开发文档 的规范，sendText 需要传 wId、toUser、content 三个必填参数，toUser 填目标用户的 wxid。
适用应用：客服系统、智能问答机器人、审批助手。
大白话：用户发消息你能收到，你还能回复回去，一来一回就是完整对话，客服和机器人基本都是这个级别。在 Eyun 平台配置好回调地址，交互级能力就打开了。
三、管理级能力：多实例调度 + 全量接口
这一级是能力的全集：多 wId 实例管理、全部拉取接口、全部发送接口、Webhook 全部 4 类事件。
适用应用：企业级运营平台、多账号管理系统、自动化工作流平台。
大白话："管家"级别——底下管着多个 wId 实例，消息负载要调度，复杂任务要编排，各实例的回调还要统一处理。业务规模大到单实例扛不住时，才需要上这一级。
四、3 级能力对比
能力级别 | 包含接口 | 适用应用 | 技术要求 | 大白话 |
|---|---|---|---|---|
只读级 | 消息记录拉取、联系人同步 | 数据分析、备份、好友列表工具 | 定时任务 + 本地存储 | 只"看"不"发" |
交互级 | sendText/sendImage/sendFile + Webhook 回调 | 客服系统、问答机器人、审批助手 | Webhook 服务 + 5 秒内响应 | 能"聊" |
管理级 | 多 wId 管理 + 全部拉取/发送接口 + 全部事件 | 运营平台、多账号管理、工作流平台 | 多实例调度 + 任务编排 | "管家"，能力全集 |
五、代码：3 级能力规划框架
LEVEL_CAPABILITIES = { "readonly": { # 只读级：定时拉取，不发不收 "apis": ["pull_message_records", "sync_contacts"], "webhook": False, }, "interactive": { # 交互级：Webhook 收 + 三接口发 "apis": ["sendText", "sendImage", "sendFile"], "webhook": True, # 回调需 5 秒内返回 200 }, "manage": { # 管理级：多实例 + 全量接口 "apis": ["multi_wid_manage", "all_pull", "all_send"], "webhook": True, }, } def plan_capabilities(app_type: str) -> dict: """按应用需求选择能力级别，返回接口清单""" if app_type in ("analysis", "backup", "friends_tool"): return LEVEL_CAPABILITIES["readonly"] if app_type in ("customer_service", "bot", "approval"): return LEVEL_CAPABILITIES["interactive"] return LEVEL_CAPABILITIES["manage"]写在最后
3 级能力规划的核心思想是"按需开通"：只读级应用不必部署 Webhook 服务，交互级应用不必操心多 wId 调度，只有管理级才需要全套能力。级别越低实现越简单——只读级 1-2 人天，交互级 3-5 人天，管理级 8-15 人天。
稳妥的实施路径是从只读级起步，先验证接口可用性，再按业务需求往上升级，不要一步到位铺全量。各级能力的接口清单详见 Eyun 开发文档，实例开通在 Eyun 平台 完成。
