Author: Huang Chengsheng, responsible for Huolala Mini Program frontend architecture and development, focusing on business capability atomization and the engineering integration of AI and frontend.

Introduction: What kind of product and technology architecture is needed behind a one-sentence request to call a Huolala truck? This article fully reviews the practical path of Huolala Mini Program AI ordering: comparison of three modes provided by WeChat AI, how Huolala's seven atomic capabilities are freely combined, how the Handoff mechanism protects transaction safety, and the architectural thinking of running a self-developed AI assistant and WeChat AI in parallel. The full text is about 6,000 words, with a recommended reading time of 12 minutes.

Comic: At the end of cycling, there is Huolala

One Sentence and One Form

Huolala provides more than 30 vehicle types and a variety of service types. In the past, we broke down business processes into page functions for users to learn. The forms and options in pages are designed to describe complex business in a sufficiently deterministic way.

But for users, calling a truck used to mean going through a series of actions: find the entrance, choose the business, fill in pickup and drop-off locations, select vehicle type, fill in cargo, choose time, read the agreement, place an order... In between there are jargon like "full truck, LTL, ride-along, moving" and many options. For frequent users, this is an operation they can complete with eyes closed; for low-frequency users, it feels like they need to take a training class first.

We want users to say just one sentence and leave the rest to AI. For example, "How much does it cost to send a bicycle to Shangmeilin Metro Station" - this colloquial description hides a set of clear business parameters: pickup location, drop-off location, vehicle type, use time, cargo, as well as actions such as query, estimate, and cancel. What AI needs to do is extract these parameters from natural language, ask the user for clarification only when there is ambiguity, and send the user back to the Mini Program page when confirming payment.

XiaoWei is one of the agent carriers provided by WeChat AI platform. Adding a chat box is not difficult; the difficulty is when such an agent becomes a new entry point, how does the business catch the demand, and how does it hold on to the original experience and transaction safety?

What Capabilities Does WeChat AI Provide

In June 2026, XiaoWei opened the internal beta of Mini Program AI capability. In the past, users entered a Mini Program through search, QR code, sharing, or official account menu; now there is a new path: directly tell the agent what you want, and it calls the corresponding service. For Huolala, "calling a truck" naturally fits this entry point: as soon as a user says "from where to where", the intent is clear, the parameters are specific, and it is very close to a transaction.

But an entry point alone is not enough. Whether the agent can accurately call the business, handle missing information, stop before dangerous operations, and smoothly return to the transaction page determines whether it can catch the user's demand. WeChat's official integration instructions look like this:

WeChat official "Mini Program AI Development Mode (Beta)" integration guide

GUI Mode: Let AI Click Instead of a Person

The most intuitive approach is to let AI operate the interface like a human: open the Mini Program, recognize pages, click buttons, fill forms, and then read the screen for results.

The advantage is fast integration, without first refactoring business capabilities. But when actually running a freight flow, the boundaries quickly surface:

• An activity popup can block subsequent clicks;
• Addresses often depend on map positioning, drag-select, and distinguishing similarly named addresses;
• Vehicle type and price depend on city, route, and configuration; they cannot be inferred from reading page text;
• One sentence often cannot cover all fields, and UI automation cannot manage multi-turn context.

Letting AI perform "finger actions" is different from letting it understand business. Once the page changes, the chain may break. In practice it looks like this:

Because GUI mode has too many experience issues and looks "stupid", WeChat then launched MCP mode, giving AI a skill library.

MCP Mode: Turn Capabilities into Callable Tools

The development mode shifted direction: instead of letting AI guess how to click pages, enterprises encapsulate business capabilities for Mini Program AI to call.

WeChat provides an intelligent runtime environment and development framework. Based on this, developers abstract Mini Program functions into atomic interfaces and atomic components, and then encapsulate them into Skills.

When a user initiates a conversation through Mini Program AI, Mini Program AI uses the Mini Program MCP protocol to analyze and select appropriate atomic interfaces and atomic components, complete data processing and task execution, and finally integrate results and deliver them to the user.

So in short: MCP is the protocol and runtime environment, and Skill is the encapsulation of business capability, that is, a "business menu plus operating rules written for AI" - what it can do, what inputs it collects, what it cannot guess, and how results are delivered are all written inside.

In implementation, WeChat manages the conversation entry and tool scheduling, while Huolala manages addresses, vehicle types, pricing, and orders. Prices are not generated by the model, and order status is not guessed by it; key results always come from business interfaces. AI thus changes from "clicking the screen for the user" to "calling services for the user".

As shown in the figure: the difference between MCP and GUI is that with enterprise service access, XiaoWei can directly call enterprise interface capabilities, without having to click through Mini Program pages step by step and collect information. Once the information is complete, it hands off the subsequent ordering to the business side's Handoff page, preserving the experience and reducing the risk of XiaoWei taking on more business.

Handoff Mechanism: Pass Back to Native Pages

AI is good at understanding intent and collecting information, but confirmation, agreements, and payment still need to be handled by a stable, clear, and traceable product interface.

Handoff is this baton. AI runs the first half in the conversation, passing addresses, vehicle type, remarks, time, and scenario to the Mini Program; the Mini Program catches it and runs the second half using a native confirmation page.

The key is not the "jump" itself, but whether the addresses, cargo, and vehicle type expressed by the user are carried over when jumping. Otherwise the previous AI experience is wasted. How the handoff works is shown in this figure:

As shown: XiaoWei converts user expression into the format agreed by the Skill, directly assembling location, inferring vehicle type, and additional needs (such as ride-along); after collecting the information, it hands the data to the Huolala Mini Program, which completes the handoff, refills the order, and enters the confirmation page.

How We Catch the WeChat AI

After XiaoWei hands over one sentence, what Huolala catches is a set of capabilities that can be combined, ask for clarification, and also know when to stop.

Function Orchestration: 7 Atomic Capabilities

Freight ordering has many paths. Same-city, cross-city, moving, errands - different pages, different configurations, and dozens of ordering flows have been accumulated. Users will only say "send the bicycle to Shangmeilin", and the conversation cannot cover all these flows. We extracted 7 atomic capabilities that can be freely combined from these flows:

• Query vehicle type: Answer "What vehicle is used for a bicycle", only returning real vehicle types available in the current city.
• Parse address: Convert colloquial place names like "to Shangmeilin Metro Station" into addresses and coordinates.
• Estimate price: Return an estimated price based on real addresses, vehicle type, and business configuration.
• Query order details: After uniquely matching "where is the order to Shangmeilin", query the specific order.
• Query order list: Return a summary of recent orders, supporting subsequent filtering.
• Order again: Reuse historical information and re-enter the estimate and confirmation process.
• Cancel order: Only executed after explicit confirmation by the user.

Login is not among these 7; it is handled by the Skill runtime middleware. The model only handles business intent: when login is needed, it prompts once and ends the current round of calls.

When the user changes their mind mid-way, these 7 capabilities can be broken apart and restarted. If he says "change to Iveco and quote again", the already confirmed address is kept, just change the vehicle type and re-estimate.

Huolala ordering Skill internal architecture: Three agent contracts constrain model behavior, runtime middleware handles login and security uniformly; seven atomic APIs only fetch data from real business systems, and results are delivered through structured output, automatic continuation, or Handoff.

Confirming Boundaries: WeChat Manages Conversation, We Manage Ordering

After splitting the capabilities, first clarify what WeChat supports and what we need to do. Conversation and scheduling are in WeChat, ordering and transactions are in Huolala.

The full chain is:

WeChat AI conversation -> call Huolala Skill -> return real business results and Handoff card -> user clicks -> Mini Program catches context -> native confirmation page recalculates and pays

End-to-end call chain of WeChat AI from understanding to transaction: WeChat handles understanding and scheduling, Huolala handles business, rules, and transactions; price is not generated by the model, and payment cannot be completed bypassing the confirmation page.

The confirmation page recalculates the price, not trusting the number from the conversation. From conversation to ordering may take a few minutes, city configurations, vehicle availability, and pricing conditions may all change. Better to confirm one more time than to sacrifice consistency for "seamlessness".

Implementation Approach: Independent Subpackage, Not into Main Flow

After setting the boundaries, we move to engineering. This capability is integrated into the existing Mini Program, but it does not enter the main flow.

First look at its position in the whole chain: WeChat runtime is at the top, handling conversation and scheduling; the Skill independent subpackage sits in the middle, translating business capabilities into tools; the Huolala main package and business APIs are at the bottom, handling ordering and transactions. The subpackage only reads business interfaces and does not reversely depend on the ordering page.

WeChat provides a development method to extract Mini Program capabilities into Skills. We used this method to create an independent subpackage: the skill code is placed in src/skills, with its own runtime and requests, and does not depend on the main package. No matter how AI code iterates, the original ordering page is not changed. The main package only reads the context carried over when the user clicks the handoff card.

On top of this method, we set our own business development boundaries. Atomic interfaces are extracted from existing ordering code, and the confirmation page is not moved wholesale into the skill package. What the model can handle, when to ask questions, and what cannot be guessed are written in AGENTS.md, SKILL.md, and each tool's description. Generation and validation follow these constraints.

Inside the subpackage, cross-cutting concerns like login, signing, and security guards are collected in the runtime middleware, and business code does not touch them. Constraints are placed on three contracts: AGENTS.md manages capability boundaries, SKILL.md manages orchestration and rules, and mcp.json manages tool contracts.

The engineering organization is roughly like this:

Between the skill package and the main package, only a very narrow bridge is left. The addresses and prices confirmed in the previous round stay in the Skill's own cache, invisible to the main package pages. Only one handoff can cross the bridge: login state, address, vehicle type, remarks, and time, plus the order draft usable by the confirmation page. The confirmation page clears it upon receipt; if the user does not enter the confirmation page and leaves, the handoff page also clears it. The next estimate will not carry the previous order's receipt or remarks.

When the Mini Program starts, it first accepts this handoff; the handoff page decides whether to enter the confirmation page; once the confirmation page reads the data, it destroys this temporary state.

Minimal data bridge between independent subpackage and main package: Isolated are code, runtime, and release boundaries; the only things opened are login state, handoff context, and order draft. Proactive cleanup after use avoids cross-session pollution.

How to Test: Cases, Evaluation, Crowd Testing

After extracting the code, we still need to see how real people speak. Running through a standard phrase does not mean it is usable.

Real users do not speak according to interface parameters: some omit vehicle type, some only report landmarks, some change the address mid-way, and some say "the last order" or "that trip to Qianhai". So testing is divided into three layers:

1. WeChat automated evaluation. In the developer tools, evaluation can be run automatically to check whether tools are correctly called under the platform runtime, and whether Handoff and boundaries are held.
2. Self-test cases. Collect colloquial phrases into 59 items, separated by address, vehicle selection, estimate, order query, order again and cancel, and refusal.
3. Internal product and R&D crowd testing. Colleagues call a truck using their own wording, and see if the model fills in services, time, and price the user did not mention.

The value of cases is not in quantity. Writing each one actually answers two questions: how else might real users express this, and where is the model most likely to act on its own?

With specific cases, WeChat runs an evaluation and verifies that the entire Skill flow can run. The evaluation looks like this:

WeChat developer tools: supports automated evaluation of test cases

Record problems found in crowd testing, then confirm each one: is it a model problem or a Skill problem. Crowd testing records look like this:

How to Tune: Guard the Boundaries

The problems that surface in crowd testing are mostly the model saying something that has not happened as if it has. Tuning is done according to cases: how it behaved at the time, why, and which constraint finally blocks it.

A typical scenario: the user asks what vehicle is suitable for a mattress, sofa, or refrigerator, and the model makes a guess, saying the medium cargo van's length is 3.8-4.3 meters; but the interface says 3.9-4.3 meters.

Reason: the model used common sense to fill in a number not present in the interface.

Solution: add a constraint that when stating dimensions, only repeat the original text from the interface, without adding "about, approximately, around".

These constraints are written in the Agent description, Skill, and tool description, condensed into four rules.

Self-Developed AI Assistant

Route: Two Parallel Tracks

Aiming at "one-sentence truck call", we did not bet on just one route.

One is WeChat AI. The conversation is in WeChat's platform agent; users do not even need to find the Huolala Mini Program first: XiaoWei understands intent, calls Huolala's Skill, and then uses Handoff to bring the user back to the Mini Program for transactions. It is more of a channel capability; the demand has already happened before the user enters.

The other is a self-developed AI assistant. The conversation is inside the Huolala Mini Program; model orchestration, streaming messages, address cards, ordering, and payment are all controlled by us. It is more of a product capability: after users enter, the experience can be made deeper.

The two routes solve the same problem, just from different positions. We need to think clearly whether the underlying capabilities can be reused and whether channel differences can be isolated.

Architecture: Five Layers

The self-developed AI assistant grows inside the Mini Program and is a complete conversation product: the frontend uses streaming interfaces to receive text, address candidates, estimate cards, and ordering actions; the server side uses an agent orchestration service to manage model and tool scheduling; the Mini Program continues to reuse real business interfaces for real-name verification, agreements, ordering, and checkout.

Five-layer architecture of the self-developed AI assistant: The frontend does not directly call the model; instead, it collaborates with the server-side agent orchestration through a unified streaming gateway; conversation, state, business tools, and transactions are layered and evolve separately.

The following ✅/❌ only indicates whether the current implementation has it, not that the platform cannot support it in the future.

Among them, the self-developed assistant by default can complete agreements, real-name verification, ordering, and checkout in the AI page, and also keeps a branch for jumping to a new standard confirmation page; WeChat AI currently must return to the Mini Program confirmation page to transact.

The technical paths differ, but both routes hold the same bottom line: the model is responsible for understanding and orchestration, and the business system is responsible for ordering and transactions.

Interaction Experience: Advantages of Self-Development

The benefit of the self-developed approach is not just that "the interface is ours". It can turn the freight scenario into a truly continuous conversation experience:

• Stream answers and processing progress, and users can stop generation at any time;
• When an address is ambiguous, directly give location candidates (POI), and also allow opening a map to re-select;
• The estimate result is not a piece of text but an order card that can be further operated;
• Supports photo-to-vehicle selection, image attachments, and quick commands;
• Supports history sessions, session recovery, and "continue the last order";
• When conditions are met, agreements, real-name verification, ordering, and payment can be completed in the AI page, and results return to the conversation.

The advantage of WeChat AI is on the other side: users do not need to enter Huolala first; the platform is guarding where demand occurs, giving up some interface control in exchange for an earlier traffic entrance.

Looking at a single interaction, the self-developed side has a more complete experience; looking at the acquisition path, WeChat AI is closer to when the user speaks. The self-developed interface looks like this:

Industry Commonalities: Several Common Practices

Moving the view outward from truck calling, it is noticeable that service-oriented AI assistants are converging on several common practices. It is not about who is right or wrong; Didi's AI taxi calling is an example: connecting the phrase "tell me where to go" to real estimate and dispatch. The figure below shows how these practices land on the architecture:

So, an AI assistant is not just a smarter search box. It is becoming a new layer of service orchestration.

Summary and Thinking

Traffic Side: Opportunities of New Channels

In the past, growth entrances always required users to remember the brand and find the Mini Program before entering the business. Agent entrances reverse the order: users first state their demand, and the platform then matches.

For a strong-intent scenario like calling a truck, this is a new opportunity to catch demand. The moment a user says "help me send a bicycle to Shangmeilin", the demand is established. Whoever is accurately understood by the agent, reliably called, and also able to catch the transaction, is more likely to get incremental growth.

Of course, channel dividends are not only about "getting connected". Agents care about: whether capabilities are clear, whether results are trustworthy, and whether boundaries are safe. Enterprises used to design pages for people; in the future, they also need to design capabilities for agents.

Product Side: More Than Truck Calling

Today we only start with truck calling, price inquiry, order inquiry, and cancellation. We chose these four because they share a common trait: they can be explained in one sentence, can be immediately calculated with real data, and can go all the way to payment.

These four scenarios actually share the same chain: users speak human language, AI splits it into structured requirements, calls real business tools, and finally returns to native pages to close the deal. Once the chain is established, switching to another business barely requires changing the pattern.

For example:

• Shipping: say in a group "3 boxes of goods, from warehouse to Tianhe store, arrive before off work", AI calculates the vehicle type and price, and the order data can be directly synced to the order confirmation page.
• Moving: user says "one-bedroom, has refrigerator and washing machine, move on Saturday", AI first asks how many floors and whether there is an elevator, then quotes vehicle type and moving fee.

So for future expansion, it relies on continuing to break down the business into small tools with clear boundaries, trustworthy results, and combinable usage. Adding a new scenario means adding a few tools; stuffing all capabilities into one large assistant is more likely to get out of control.

Architecture: How to Adapt to Channel Changes

Channels will definitely change: today it is WeChat XiaoWei, tomorrow it may be another system-level agent, and the self-developed assistant's interaction will keep iterating. If each entrance copies a set of address, vehicle type, estimate, and order logic, the counting rules are easily out of sync.

Our answer is: core capabilities are reused, channel adaptation is decoupled, and the transaction loop returns to native.

Evolving architecture for multi-agent channels: This is an evolution direction abstracted from the two routes and does not mean every module is already productized: the upper layer adapts different Agents, the middle layer accumulates unified orchestration and governance, and the lower layer reuses business capabilities and the native transaction base.

• Core business layer: Reuse addresses, vehicle types, estimates, orders, login and security rules, without being aware of which agent entrance it comes from.
• Agent adaptation layer: Reuse unified business semantics and real data; WeChat Skill, self-developed streaming interfaces, and future Agents each adapt.
• Experience and transaction layer: Reuse the confirmation page, agreements, real-name verification, checkout, and order details; conversation UI and channel cards evolve separately.

This structure can simultaneously do two seemingly contradictory things: actively connect to new platform entrances without binding core business to any one platform; reuse mature transaction capabilities while leaving room for self-developed experience.

---

Back to the opening scenario:

"XiaoWei, XiaoWei, help me call a Huolala, send the bicycle to Shangmeilin Metro Station, I'll ride along."

It seems like just a few fewer screen taps, but behind it are changes in service entrance, product form, and technology architecture all at once. For those who can no longer ride, what it saves is a real distance.

Prices, times, and other information in the screenshots in this article are for display only and vary by city, route, and time; actual amounts are subject to what is shown in the platform at the time of ordering.