翻了下微信 AI 的官方资料，感觉它做“自动模式”这件事，其实挺非共识的。

前段时间很多人都在讲“要给 Agent 做产品”，意思是 Agent 眼里没有 UI，产品应该更 Agent-native，最好是接口、schema、工具调用、结构化状态，别再让 Agent 像人一样点来点去。

这个判断没错。只是它更适合从零开始的产品，或者没有历史包袱的场景。微信不是这个情况。

微信手里不是一张空白画布，而是一个跑了十几年的服务世界。小程序页面、按钮、表单、登录态、地址、优惠券、支付确认，全都已经在那里了。很多业务规则不在某个干净的接口里，而是藏在这些页面和流程之间。

所以微信 AI 的自动模式，其实是在说：既然这套数字基础设施已经为人建好了，那 Agent 先学会像人一样使用它。

它也不是单纯“看截图点坐标”那么土。微信是小程序宿主，自动模式不是外部手机 Agent 硬读屏，而是在平台内部读取源码、分析页面，再让微信 AI 直接操作小程序。走的是 GUI Agent 逻辑，但不是最低配的 GUI Agent。

还有一点我觉得微信可能想得比很多 Agent-native 讨论更清楚：交易场景大概率不是那种能放心扔给 Agent 自己跑完的任务。

点外卖、打车、买票、下单、支付、开发票、改地址、售后，这些事看起来是“执行任务”，但中间其实全是确认、犹豫、纠错、授权和责任边界。价格变了要不要继续？地址是不是对的？优惠券怎么用？支付前要不要再看一眼？出了问题算谁的？

所以商业场景里的 Agent，很难是大家畅想的 fully autonomous。更常见的状态应该是 Human in the loop，而且 loop 还不浅。Agent 可以帮你推进流程、减少点击、聚合信息，但关键节点人还是要看、要确认、要接管。

这会反过来影响产品形态。如果人一直在链路里，那 Agent 和人共用一套交互层就很自然。GUI 不只是给人看的皮肤，它也是人机协作的交接面，是“你确认一下”和“出事算谁的”的边界。

没有包袱的时候，当然可以很潇洒地说：给 Agent 做产品，不需要考虑 UI。

但商业世界没这么干净。交易不是 demo，履约不是函数调用，支付也不是一句 `confirm=true` 就完事。

长期看，Agent-native 当然更优雅。接口清楚，参数明确，状态可控，错误可追踪，也更容易组合。微信官方的开发模式，本质上也在往这个方向走：Skill、原子接口、原子组件、小程序 MCP。

但你不可能要求几百万个小程序开发者明天都重写一套 Agent-native 的服务层。大厂可以，小商家不行；新服务可以，老系统很难；标准流程可以，复杂履约场景更麻烦。

所以自动模式的价值，不是它代表终局，而是它能让服务提供商用最低成本接入 Agent，同时最大化复用已有世界。

微信现在做的其实是迁移路径：先让 Agent 穿上“人的外壳”，使用已经为人建好的小程序基础设施；等高频场景跑出来，再把那些流程拆成原子接口、卡片、半屏页、支付确认和更 Agent-native 的调用。