作者：黄呈圣，负责货拉拉小程序前端架构与开发，聚焦业务能力原子化、AI 与前端的工程化融合。
导读：一句话叫一辆货拉拉，背后需要怎样的产品和技术架构？本文完整复盘货拉拉小程序 AI 下单的实战路径：微信 AI 提供的三种模式对比、货拉拉 7 个原子能力如何自由组合、Handoff 机制如何守住交易安全，以及自研 AI 助手与微信 AI 双线并行的架构思考。全文约 6000 字，建议阅读 12 分钟。
漫画：骑行的尽头，是货拉拉
一句话和一张表单
货拉拉提供30多种车型以及多样的服务类型，以前我们把业务流程拆成页面功能让用户学，页面中的表单和选项是为了把复杂业务描述得足够确定。
但对用户来说，叫一次车要走过一串动作：找入口、选业务、填装卸货地、选车型、填货物、选时间、读协议、下单......中间还夹着"整车、零担、跟车、搬运"这些行话和一堆选项。对高频用户，这是闭着眼都能走完的操作；对低频用户，却像要先上一堂培训课。
我们希望用户只说一句话，剩下的交给 AI。例如"把自行车送到上梅林地铁站多少钱"，这个口语化的描述背后是一组明确的业务参数：装货地、卸货地、车型、用车时间、货物，以及查询、估价、取消等动作。AI 要做的，就是把这些参数从自然语言里捞出来，有歧义时才向用户追问，确认支付时再把用户送回小程序页面。
小微是微信 AI 平台提供的智能体载体之一，加个聊天框不难，难的是当这类智能体成为新入口，业务怎么接住需求，又怎么守住原有体验和交易安全？
微信 AI 提供哪些能力
2026 年 6 月，小微开放小程序 AI 能力内测。过去用户进小程序靠搜索、扫码、分享、公众号菜单；现在多了一条路：直接跟智能体说要什么，由它去调对应服务。对货拉拉来说，"叫车"天然适合这种入口：用户一说出"从哪送到哪"，意图明确、参数具体，离交易很近。
但光有入口不够。智能体能否准确调到业务、处理缺失信息、在危险操作前刹住、顺畅回到交易页，才决定它能否接住用户需求。微信官方的接入说明长这样：
微信官方《小程序 AI 开发模式（Beta）》接入指南
GUI 模式：让 AI 代替人点击
最直观的做法，是让 AI 像人一样操作界面：打开小程序、认页面、点按钮、填表单，再读屏取结果。
好处是接入快，不用先改造业务能力。但真跑起货运流程，边界很快就露出来：
- 一个活动弹窗就可能挡住后续点击；
- 地址常要靠地图定位、拖选，还要区分名称相似的地址；
- 车型和价格取决于城市、路线和配置，读页面文字推不出来；
- 一句话往往说不全所有字段，界面自动化也管不住多轮上下文。
让 AI 完成"手指的动作"，和让它理解业务是两回事。页面一变，链路就可能断。实际跑起来是这样：
因为 GUI 模式体验问题太多、显得很「傻」，微信才又推出 MCP 模式，给 AI 加了技能库。
MCP 模式：把能力变成可调用工具
开发模式换了个思路：不让 AI 去猜页面怎么点，改由企业把业务能力封装起来，供小程序 AI 调用。
微信提供了一套智能化的运行环境和开发框架。开发者基于它，把小程序的功能抽象成原子接口和原子组件，再封装成 Skill。
当用户通过小程序 AI 发起对话时，小程序 AI 会通过小程序 MCP 协议分析并选择合适的原子接口和原子组件，完成数据处理和任务执行，最终整合结果给到用户。
所以简单说：MCP 是协议和运行环境，Skill 是业务能力的封装，也就是一份"写给 AI 的业务菜单加操作规程"，能做什么、要收什么、什么不能猜、结果怎么交，都写在里面。
实现上，微信管对话入口与工具调度，货拉拉管地址、车型、估价、订单。价格不由模型生成，订单状态也不靠它猜，关键结果一律来自业务接口，AI 于是从"替用户点屏幕"变成"替用户调服务"。
如图所示：MCP 与 GUI 的差别在于，有了企业服务接入，小微可以直接调企业的接口能力，不用在小程序页面上一步步点、再收集信息。信息收齐后，它把后续下单交给业务方的 Handoff 页面承接，既保住了体验，也降低了小微接更多业务的风险。
Handoff 机制：交回原生页面
AI 擅长理解意图、收集信息，但确认、协议、支付还得交给稳定、明确、可追溯的产品界面。
Handoff 就是这根接力棒。AI 在对话里跑完前半程，把地址、车型、备注、时间和场景交给小程序；小程序接住，用原生确认页跑完后半程。
关键不在"跳转"本身，而在跳过去时有没有带上用户表达的地址、货物和车型，否则前面的 AI 体验就白做了。接力到底怎么接，看这张图：
如图所示：小微把用户表达转化成 Skill 约定的格式，直接组装位置、推测车型和额外需求（比如跟车）；信息收齐后，再把数据交给货拉拉小程序，由它完成接力、回填订单并进入确认页。
我们如何接住微信 AI
小微把一句话交过来之后，货拉拉这边接住的是一组能组合、能追问、也能在该停的时候停住的能力。
功能编排：7 个原子能力
货运下单有很多条路。同城、跨城、搬家、跑腿，页面不同，配置也不同，沉淀了几十种下单流程。用户只会说「把自行车送到上梅林」，对话里讲不完这么多流程。我们从这些流程里抽出 7 个能自由组合的原子能力：
- 查车型： 回答"一辆自行车用什么车"，只返回当前城市真实可用车型。
- 解析地址： 把"送到上梅林地铁站"这类口语地名转成地址和坐标。
- 估价： 基于真实地址、车型和业务配置返回预估价。
- 查订单详情： "去上梅林那单到哪了"唯一命中后，再查询具体订单。
- 查订单列表： 返回近期订单摘要，支持后续筛选。
- 再来一单： 复用历史信息，重新进入估价与确认流程。
- 取消订单： 必须用户明确确认后才执行。
登录不进这 7 个里，交给 Skill 运行时中间件。模型只管业务意图：要登录时提示一声，结束本轮调用。
用户中途改口时，这 7 个能力可以拆开重来。他说「换成依维柯再报一次」，已经确认的地址留着，换个车型重新估价就行。
货拉拉下单 Skill 内部架构： 三份智能体契约约束模型行为，运行时中间件统一处理登录与安全；七个原子 API 只从真实业务系统取数，结果经结构化输出、自动续调或 Handoff 交付。
确认边界：微信管对话，我们管下单
能力拆开之后，先划清微信支持什么、我们要做什么。对话和调度在微信，下单和交易在货拉拉。
完整链路是：
微信 AI 对话 → 调用货拉拉 Skill → 返回真实业务结果与 Handoff 卡片 → 用户点击 → 小程序接住上下文 → 原生确认页重算并支付
微信 AI 从理解到交易的端到端调用链： 微信负责理解和调度，货拉拉负责业务、规则和交易；价格不由模型生成，也不能绕过确认页直接完成支付。
确认页会重新算价，不信对话里那个数。从对话到下单可能隔几分钟，城市配置、车型可用性、估价条件都可能变。宁可多确认一次，也不为「无缝」牺牲一致性。
实现思路：独立分包，不进主流程
边界划完，再落到工程上。这套能力接进现有小程序，但不进主流程。
先看它在整个链路里的位置：微信运行时在最上面，负责对话和调度；Skill 独立分包夹在中间，把业务能力翻译成工具；货拉拉主包和业务 API 在最下面，负责下单和交易。分包只读业务接口，不反向依赖下单页面。
微信提供了把小程序能力抽成 Skill 的开发方法。我们按这个方法开了一条独立分包：技能代码放在 src/skills，有自己的运行时和请求，不依赖主包。AI 代码怎么迭代，都不改原来的下单页面。主包只在用户点开接力卡片时，读一次这次带过来的上下文。
在这套方法上面，又定了业务自己的开发边界。原子接口从现有下单代码里抽，不把确认页整页搬进技能包。模型能承接什么、什么时候追问、什么不能猜，写在 AGENTS.md、SKILL.md 和每个工具的描述里。生成和校验都按这些约束走。
分包内部，登录、签名、安全守卫这些横切逻辑统一收在运行时中间件里，业务代码不碰。约束则落在三份契约上：AGENTS.md 管能力边界，SKILL.md 管编排与规则，mcp.json 管工具契约。
工程组织大致是这样：
技能包和主包之间，只留一条很窄的桥。上一轮认过的地址、报过的价，留在 Skill 自己的缓存里，主包页面看不见。能过桥的只有这一次接力：登录态、地址车型备注和时间，以及确认页能用的那份草稿。确认页收下就清空；用户没进确认页就走了，接力页同样清空。下一句再估价，不会带上上一单的回单和备注。
小程序启动时先收下这次接力；接力页决定要不要进确认页；确认页一读走数据，就把这份临时状态销毁。
独立分包与主包之间的最小数据桥： 隔离的是代码、运行时和发布边界；打通的只有登录态、接力上下文和订单草稿。用完主动清理，避免跨会话污染。
怎么测试：用例、评测、众测
代码抽出来之后，还要看真人会怎么说。演示一条标准话术跑通，离能用还差一截。
真实用户不会照着接口参数说话：有人省车型，有人只报地标，有人中途改地址，还有人张口就是"刚才那单""去前海那趟"。所以测试分三层：
- 微信自动化评测。 开发者工具里可以自动跑评测，看平台运行时下工具有没有调对，Handoff 和边界有没有守住。
- 自测用例。 把口语收成 59 条，按地址、选车、估价、查单、再来一单和取消、拒载分开。
- 产研内部众测。 同事用自己的说法去叫车，看模型会不会补上用户没说的服务、时间和价格。
用例的价值不在数量。写每一条，其实都在回答两个问题：真实用户还可能怎么表达？模型最容易在哪一步自作主张？
有了具体用例，微信会跑一遍评测，顺便验证整条 Skill 流程能不能跑通。评测跑起来是这样：
微信开发者工具：支持自动评测用例
把众测里遇到的问题记下来，再逐个确认：是模型的问题，还是 Skill 的问题。众测记录长这样：
怎么调优：守住边界
众测里冒出来的问题，多半是模型把没发生的事说成已经发生。调优就按用例来：当时怎么表现，原因在哪，最后用哪条约束挡住。
比较典型的场景：用户说床垫、沙发、冰箱该用什么车，模型自行推测，把中货厢长说成 3.8--4.3 米；而接口里原文是 3.9--4.3 米。
原因：模型用常识补了一个接口里没有的数字。
解决方案：加一条约束，说尺寸时只复述接口返回的原文，不加"左右、约、上下"。
这些约束写在 Agent 说明、Skill 和工具描述里，收成四条。
自研 AI 助手
路线：两条并行
奔着"一句话叫车"这个目标，我们没有只押一条路线。
一条是微信 AI。对话在微信的平台智能体里，用户甚至不用先找到货拉拉小程序：小微理解意图后调货拉拉的 Skill，再通过 Handoff 把人接回小程序交易。它更偏渠道能力，用户还没进来，需求已经发生。
另一条是自研 AI 助手。对话就在货拉拉小程序里，模型编排、流式消息、地址卡片、下单、支付都由我们控制，偏产品能力：用户进来后体验能做得更深。
两条路线解的是同一个问题，只是站的位置不一样。我们需要考虑清楚的是底层能力能否复用，渠道差异能否隔开。
架构：五个分层
自研 AI 助手长在小程序里，是个完整的会话产品：前端用流式接口接文本、地址候选、估价卡片和下单动作，服务端由智能体编排服务管模型与工具调度，小程序继续复用真实业务接口完成实名、协议、下单和收银台。
自研 AI 助手的五层架构： 前端不直接调用模型，而是通过统一流式网关与服务端智能体编排协作；对话、状态、业务工具和交易分层演进。
下面的 ✅ / ❌ 只表示当前实现是否具备，不代表平台未来不能支持。
其中，自研助手默认能在 AI 页面里完成协议、实名、下单和收银台，也保留了跳新标准确认页的分支；微信 AI 目前必须回到小程序确认页才能交易。
技术路径不一样，但两条路守着同一条底线：模型负责理解和编排，业务系统负责下单和交易。
交互体验：自研的优势
自研方案的好处，不止是"界面归我们管"。它能把货运场景做成一段真正连续的会话体验：
- 流式展示回答与处理进度，用户随时可以停止生成；
- 地址有歧义时直接给地点候选（POI），也能打开地图重选；
- 估价结果不是一段文字，而是可继续操作的订单卡片；
- 支持拍货选车、图片附件与快捷指令；
- 支持历史会话、会话恢复和"继续上一单"；
- 满足条件时可在 AI 页内完成协议、实名、下单和支付，结果回到对话。
微信 AI 的优势在另一头：用户不用先进货拉拉，平台就守在需求发生的地方，让出部分界面控制权，换来一个更靠前的流量入口。
只看单次交互，自研那边体验更完整；看获客路径，微信 AI 离用户开口更近。自研这边的界面长这样：
行业共性：几条共同做法
把视线从叫车往外拉，会发现服务型 AI 助手慢慢收敛出了几条共同做法。谈不上谁对谁错，滴滴的 AI 叫车就是个例子：把"说一句去哪"接到真实估价与派单上。下面这张图，是这些做法落到架构上的样子：
所以，AI 助手不只是个更聪明的搜索框。它正在变成一层新的服务编排。
总结与思考
流量端：新渠道的机会
过去的增长入口，总要用户先记住品牌、找到小程序才进得了业务。智能体入口把顺序倒过来：用户先说需求，平台再匹配。
对叫车这种强意图场景，这是一次新的需求承接机会。用户说出"帮我送辆自行车去上梅林"的那一刻，需求就成立了。谁能被智能体准确理解、可靠调用，还接得住交易，谁就更可能拿到增量。
当然，渠道红利不只靠"接进去"。智能体在意的是：能力清不清晰、结果可不可信、边界安不安全。企业过去面向人设计页面，往后还得面向 Agent 设计能力。
产品端：不止叫车
今天只从叫车、询价、查单、取消做起。挑这四个，是因为它们有个共同点：一句话能说清，能立刻用真实数据算出来，也能一路走到付款。
这四个场景其实共用同一条链路：用户说人话，AI 拆成结构化需求，去调真实的业务工具，最后回到原生页面成交。链路一旦跑通，换一门业务，模式几乎不用改。
比如：
- 发货：群里说一句"3 箱货，从仓库送到天河门店，下班前到"，AI 把车型和价格算好，订单数据可直接同步到订单确认页。
- 搬家：用户说"一居室，有冰箱和洗衣机，周六搬"，AI 先问清几楼、有没有电梯，再报车型和搬运费。
所以往后扩，靠的是把业务继续拆成一个个边界清楚、结果可信、能组合起来用的小工具。加新场景，就是加几个工具；把所有能力塞进一个大助手，反而更容易失控。
架构：怎么适应渠道变化
渠道一定会变：今天是微信小微，明天可能是别的系统级智能体，自研助手的交互也会一直迭代。要是每个入口都复制一套地址、车型、估价、订单逻辑，口径很容易对不上。
我们的答案是：核心能力复用，渠道适配解耦，交易闭环回归原生。
面向多智能体渠道的演进架构： 这是从两条路线抽象出的演进方向，不代表每个模块都已产品化：上层适配不同 Agent，中层沉淀统一编排与治理，下层复用业务能力和原生交易底座。
- 核心业务层： 复用地址、车型、估价、订单、登录与安全规则，不感知来自哪一个智能体入口。
- 智能体适配层： 复用统一的业务语义和真实数据；微信 Skill、自研流式接口和未来 Agent 各自适配。
- 体验与交易层： 复用确认页、协议、实名、收银台和订单详情；对话 UI 与渠道卡片各自演进。
这套结构能同时做两件看着矛盾的事：积极去接新平台入口，又不把核心业务绑死在任何一个平台上；复用成熟交易能力，又给自研体验留足空间。
回到本文开头的场景：
"小微小微，帮我叫辆货拉拉，把自行车送到上梅林地铁站，我跟车。"
听起来只是少点几次屏幕，背后其实是服务入口、产品形态和技术架构一起在变。对已经骑不动的人来说，它省下的，是实打实的一段路。
文中截图内的价格、时效等信息仅为展示之用，因城市、路线、时间而异；实际金额请以下单时平台内展示为准。