智能应用的标志是感知→理解→决策→执行闭环跑通。过去这个闭环的两端——感知与执行——都绑死在 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 频次限制code1000确认送达1002自动刷新 Token 重发架构影响执行端不再绑定前端页面消息接口成为统一的输出抽象层3. 上下文来源变化从App内行为日志变为微信对话历史传统智能应用的上下文来自 App 内行为日志点击/浏览/停留维度有限。Eyun 消息记录接口拉取历史对话拼入 AI 上下文把微信对话数据纳入理解端。来源迁移从App 行为数据扩展到微信对话数据技术支撑增量同步基于游标管理lastMessageTime 记录位点分页拉取控制单次量Token 上限约束下动态截断最近 N 条对话架构影响上下文不再局限于结构化埋点自然语言对话成为新的上下文维度二、3变化对比变化维度传统方式Eyun方式技术接口架构影响消息入口App内输入框微信对话窗口Webhook回调感知端前移到微信执行通道App内UI渲染微信消息推送sendText/sendImage/sendFile输出抽象为消息接口上下文来源App行为日志微信对话历史消息记录增量同步上下文纳入自然语言维度三、智能应用闭环框架def smart_loop(event): # 感知端Webhook 回调触发msgId 幂等去重 if event[msgId] in seen: return seen.add(event[msgId]) # 理解端拉历史消息拼上下文Token 上限动态截断 history fetch_msg_record(event[fromUser], cursorlast_cursor) context truncate(history, token_limit4000) # 决策端大模型推理 reply llm_infer(context, event[content]) # 执行端决策结果推送回微信5 秒内先回 200 再异步处理 send_text(wIdevent[wId], toUserevent[fromUser], contentreply)框架把感知、理解、决策、执行四段串成闭环Webhook 是感知入口消息记录是理解数据源模型推理是决策核心sendText是执行出口。5 秒回调超时约束下感知端先回 200 确认理解到执行走异步链路。四、闭环覆盖面的延伸智能应用的感知-执行两端从 App 封闭体系走向微信开放生态闭环覆盖面从打开 App 的用户扩展到微信活跃用户。这对应用架构的直接影响是感知端不再要求用户安装并常驻 App执行端不再依赖前端页面渲染管线。落地建议先验证闭环的稳定性边界——Webhook 5 秒超时与 3 次重试约束下理解与决策两段的耗时必须控制在异步链路可承受范围内否则回调积压会放大异常流量。多wId场景下按实例路由分发每个实例的 Token 与回调幂等层独立维护。Eyun平台 提供按wId区分的实例管理闭环扩展到多实例时权限边界仍清晰。后续趋势上看当大模型上下文窗口进一步扩大微信对话历史作为上下文源的价值会显著提升增量游标管理与 Token 截断策略会成为智能应用在微信侧的核心技术储备。 智能应用的标志是感知→理解→决策→执行闭环跑通。过去这个闭环的两端——感知与执行——都绑死在 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 频次限制code1000确认送达1002自动刷新 Token 重发架构影响执行端不再绑定前端页面消息接口成为统一的输出抽象层3. 上下文来源变化从App内行为日志变为微信对话历史传统智能应用的上下文来自 App 内行为日志点击/浏览/停留维度有限。Eyun 消息记录接口拉取历史对话拼入 AI 上下文把微信对话数据纳入理解端。来源迁移从App 行为数据扩展到微信对话数据技术支撑增量同步基于游标管理lastMessageTime 记录位点分页拉取控制单次量Token 上限约束下动态截断最近 N 条对话架构影响上下文不再局限于结构化埋点自然语言对话成为新的上下文维度二、3变化对比变化维度传统方式Eyun方式技术接口架构影响消息入口App内输入框微信对话窗口Webhook回调感知端前移到微信执行通道App内UI渲染微信消息推送sendText/sendImage/sendFile输出抽象为消息接口上下文来源App行为日志微信对话历史消息记录增量同步上下文纳入自然语言维度三、智能应用闭环框架def smart_loop(event): # 感知端Webhook 回调触发msgId 幂等去重 if event[msgId] in seen: return seen.add(event[msgId]) # 理解端拉历史消息拼上下文Token 上限动态截断 history fetch_msg_record(event[fromUser], cursorlast_cursor) context truncate(history, token_limit4000) # 决策端大模型推理 reply llm_infer(context, event[content]) # 执行端决策结果推送回微信5 秒内先回 200 再异步处理 send_text(wIdevent[wId], toUserevent[fromUser], contentreply)框架把感知、理解、决策、执行四段串成闭环Webhook 是感知入口消息记录是理解数据源模型推理是决策核心sendText是执行出口。5 秒回调超时约束下感知端先回 200 确认理解到执行走异步链路。四、闭环覆盖面的延伸智能应用的感知-执行两端从 App 封闭体系走向微信开放生态闭环覆盖面从打开 App 的用户扩展到微信活跃用户。这对应用架构的直接影响是感知端不再要求用户安装并常驻 App执行端不再依赖前端页面渲染管线。落地建议先验证闭环的稳定性边界——Webhook 5 秒超时与 3 次重试约束下理解与决策两段的耗时必须控制在异步链路可承受范围内否则回调积压会放大异常流量。多wId场景下按实例路由分发每个实例的 Token 与回调幂等层独立维护。Eyun平台 提供按wId区分的实例管理闭环扩展到多实例时权限边界仍清晰。后续趋势上看当大模型上下文窗口进一步扩大微信对话历史作为上下文源的价值会显著提升增量游标管理与 Token 截断策略会成为智能应用在微信侧的核心技术储备。 
