企业官网建设流程全解析

智能应用的标志是"感知→理解→决策→执行"闭环跑通。过去这个闭环的两端——感知与执行——都绑死在 App 内部，导致应用只能服务"打开 App 的用户"。Eyun 把微信侧能力以 RESTful API 形式开放后，微信对话窗口变成闭环的感知端，微信消息推送变成闭环的执行端，由此带来 3 个架构层面的技术变化。接口规范见 Eyun开发文档。

一、3个技术变化拆解

1. 消息入口变化：从App内输入框变为微信对话窗口

传统智能应用的消息入口是 App 内的输入框，用户必须先打开 App 才能触发感知端。Eyun 的 Webhook 回调把入口前移到了微信对话窗口——用户在微信里发消息，Eyun 即向回调地址 POST 一段 JSON，含content、fromUser、msgId、wId等字段，应用逻辑被消息事件直接触发。

• 入口迁移：从"需打开 App"变为"在微信直接对话"

• 技术支撑：Webhook 4 类事件回调（消息/好友/群/状态），5 秒回调超时 + 3 次重试保证消息到达不丢

• 架构影响：感知端不再依赖 App 常驻进程，回调入口成为新的请求接收入口

2. 执行通道变化：从App内UI渲染变为微信消息推送

传统应用的决策结果通过 App 内 UI 渲染呈现，用户需主动打开 App 查看。Eyun 把执行通道切换到微信消息推送——决策结果通过sendText/sendImage/sendFile直达用户微信，无需用户进入 App。

• 通道迁移：从"App 内展示"变为"微信消息直达"

• 技术支撑：多接口组合编排（说明文本→配图→附件），200ms 间隔节流避免触发 1004 频次限制；code=1000确认送达，1002自动刷新 Token 重发

• 架构影响：执行端不再绑定前端页面，消息接口成为统一的输出抽象层

3. 上下文来源变化：从App内行为日志变为微信对话历史

传统智能应用的上下文来自 App 内行为日志（点击/浏览/停留），维度有限。Eyun 消息记录接口拉取历史对话拼入 AI 上下文，把微信对话数据纳入理解端。

• 来源迁移：从"App 行为数据"扩展到"微信对话数据"

• 技术支撑：增量同步基于游标管理（lastMessageTime 记录位点），分页拉取控制单次量；Token 上限约束下动态截断最近 N 条对话

• 架构影响：上下文不再局限于结构化埋点，自然语言对话成为新的上下文维度

二、3变化对比

三、智能应用闭环框架

def smart_loop(event): # 感知端：Webhook 回调触发，msgId 幂等去重 if event["msgId"] in seen: return seen.add(event["msgId"]) # 理解端：拉历史消息拼上下文，Token 上限动态截断 history = fetch_msg_record(event["fromUser"], cursor=last_cursor) context = truncate(history, token_limit=4000) # 决策端：大模型推理 reply = llm_infer(context, event["content"]) # 执行端：决策结果推送回微信，5 秒内先回 200 再异步处理 send_text(wId=event["wId"], toUser=event["fromUser"], content=reply)

框架把感知、理解、决策、执行四段串成闭环：Webhook 是感知入口，消息记录是理解数据源，模型推理是决策核心，sendText是执行出口。5 秒回调超时约束下，感知端先回 200 确认，理解到执行走异步链路。

四、闭环覆盖面的延伸

智能应用的"感知-执行"两端从 App 封闭体系走向微信开放生态，闭环覆盖面从"打开 App 的用户"扩展到"微信活跃用户"。这对应用架构的直接影响是：感知端不再要求用户安装并常驻 App，执行端不再依赖前端页面渲染管线。

落地建议先验证闭环的稳定性边界——Webhook 5 秒超时与 3 次重试约束下，理解与决策两段的耗时必须控制在异步链路可承受范围内，否则回调积压会放大异常流量。多wId场景下按实例路由分发，每个实例的 Token 与回调幂等层独立维护。Eyun平台 提供按wId区分的实例管理，闭环扩展到多实例时权限边界仍清晰。后续趋势上看，当大模型上下文窗口进一步扩大，微信对话历史作为上下文源的价值会显著提升，增量游标管理与 Token 截断策略会成为智能应用在微信侧的核心技术储备。