用蚂蚁百宝箱Tbox 零代码搭建并发布支付宝小程序智能体

蚂蚁百宝箱Tbox 是蚂蚁集团推出的一站式 AI 原生应用开发平台。它要解决的问题很具体：让没有编程背景的人也能把「一个能对话、能调工具、能按流程办事的智能体」做出来，并且把它发布到用户真正能触达的渠道上。做法上，它把两件事合在了一起——用自然语言描述需求来生成应用骨架，再用可视化编排把模型、插件、流程串起来。平台已经接入了 DeepSeek、通义千问、Kimi、智谱等主流大模型，发布侧则打通了支付宝小程序、应用市场、Web 服务等渠道。

适合谁：想快速验证一个智能体想法的个人开发者、需要做客服或营销类小工具的业务团队、以及希望把服务挂到支付宝生态里的商家。不太适合谁：需要完全自建底层基础设施、对模型与运行时要有深度定制权的技术团队——平台的深度定制能力受平台本身约束，这一点在动手之前就要想清楚。如果你只是想先了解这类零代码智能体平台的整体形态，可以先看蚂蚁百宝箱Tbox 的工具条目，再回到本文按步骤操作。

准备工作

在开始搭建之前，把下面几件事确认好，可以省掉后面反复返工的时间。

账号：需要在官方站点注册并登录。平台以中文界面为主，注册流程按页面提示走即可。
使用地区与可用性：账号能否注册、模型与发布渠道在所在地区是否可用，需要以官网当前说明为准。不同地区的开放情况可能不同，动手前先确认自己所在地区是否在支持范围内。
费用：部分插件和模型调用可能产生费用。具体哪些能力免费、哪些按量计费、额度如何，属于会变动的信息，务必以官网当前的定价与配额页面为准，不要依据第三方转述的数字做预算。
发布渠道的前置条件：如果目标是发布到支付宝小程序，需要提前准备好对应的小程序主体与开发者身份；如果只是发布为 Web 服务，前置条件会简单一些。渠道侧的资质要求同样以官网与渠道方当前规则为准。
需求草稿：零代码不等于不用想清楚。动手前先写下三样东西——这个智能体要回答什么问题、需要调用哪些外部能力（例如查询、下单、生成图片）、失败时应该怎么回复。这三样直接决定后面提示词怎么写、插件怎么挂。

不需要安装本地开发环境，也不需要配置编译工具链，整个搭建过程在浏览器里完成。

操作步骤

第一步：创建应用并填写基本信息

登录后进入创建入口，新建一个应用，按表单填写应用名称、用途描述、所属分类等信息。这一步看起来只是登记，但它会影响后续的模型推荐与发布渠道选择，所以名称要能一眼看出用途，描述要写清服务对象和使用场景，不要只写「测试」。

创建完成后会进入应用的编辑界面。此时应用还是一个空壳，没有对话能力，也没有任何工具。

第二步：用提示词定义智能体的行为

这是整个流程里最影响效果的一步。平台通过自然语言交互来生成和调整应用，所以提示词的质量直接决定输出质量。一条可用的提示词通常包含四段内容：

角色：它是谁，服务谁。例如「你是某商家的售后客服助手，面向已下单用户」。
任务边界：能回答什么、不能回答什么。把不该答的范围明确写出来，比事后靠测试去堵更省事。
输出格式：回答的长度、结构、语气。需要固定字段时，把字段名和顺序写清楚。
兜底策略：信息不足或工具调用失败时怎么回复。例如「无法确认订单信息时，请用户提供订单号，不要猜测」。

写好后在编辑界面提交，平台会据此生成或调整应用配置。如果结果不符合预期，不要推翻重来，而是在原提示词上追加约束条件，逐条收敛。

第三步：选择并接入大模型

平台已集成 DeepSeek、通义千问、Kimi、智谱等主流模型。在模型配置处选择要使用的模型即可，不需要自己申请密钥、也不需要写调用代码。

选型时可以从三个角度判断：任务类型（通用对话、长文本理解、代码或结构化输出对模型的要求不同）、响应速度要求、以及成本。具体每个模型的能力差异、可用版本和计费方式会随时间变化，以官网当前信息为准。如果应用面向的是中文场景的日常问答，先用一个通用模型跑通流程，再根据实测效果决定是否更换，比一开始就纠结选型更有效率。

第四步：添加 MCP 插件扩展能力

模型本身只会说话，要让它真正办事，需要挂载插件。平台支持通过 MCP 插件的方式为应用增加外部能力，例如查询数据、调用业务接口、生成图片等。

操作上，在插件配置区域选择需要的插件并完成授权或参数配置。这里有两个要点：

只挂当前任务真正需要的插件。插件越多，模型在决策时越容易误调用，调试成本也越高。
把插件的调用条件写进提示词。明确「什么情况下调用哪个插件、拿到结果后如何组织回复」，比让模型自行判断稳定得多。

部分插件涉及费用，启用前先确认计费方式。

第五步：可视化编排工作流

对于步骤固定的任务——比如旅行规划这类「先收集条件、再查询、再汇总成行程」的流程——单靠提示词约束不够稳定，需要用可视化编排把节点和流转关系画出来。在编排界面中把各个处理节点按顺序连接，定义每个节点的输入输出，以及分支条件。

编排的价值在于把「模型自由发挥」压缩成「按既定路径执行」。凡是业务上有明确先后顺序的环节，都应该放进编排里，而不是留给提示词去描述。

第六步：预览与调试

配置完成后进入预览环节，用真实的问题去测试。调试时建议按下面的顺序推进，不要一上来就测复杂场景：

正常路径：用最典型的问题测，确认能给出符合格式要求的回答。
边界问题：问一些超出范围的问题，确认它会拒绝而不是编造。
插件路径：构造必须调用插件的场景，确认插件被正确触发、返回结果被正确使用。
异常路径：模拟信息缺失、插件无返回等情况，确认兜底回复生效。

每一轮发现问题，回到提示词或编排里改，再重新预览。把测试过的问题和对应结果记下来，后面发布前还要再跑一遍。

第七步：发布到目标渠道

调试通过后即可发布。平台支持一键发布到支付宝小程序、应用市场、Web 服务等渠道。发布时按页面提示选择目标渠道、填写必要信息、完成授权，然后提交。

发布不是终点。上线后要关注实际对话中的失败案例，把它们补进提示词的约束里，形成「上线—观察—收敛」的循环。渠道侧的审核规则、上线所需资质、审核时长以渠道方与官网当前规则为准。

一个完整示例

下面以一个「商家售后客服智能体」为例，把上面的步骤串一遍。选择这个场景是因为它同时用到了提示词约束、模型调用和插件，能覆盖大部分配置项。

目标：面向已下单用户，回答订单状态、退换货政策类问题；无法确认订单时引导用户提供订单号；不回答与售后无关的问题。

第一步，创建应用。名称写「售后客服助手」，用途描述写「为已下单用户提供订单状态查询与退换货政策解答」。分类选择与客服相关的类别。

第二步，写提示词。可以按下面的结构组织：

角色：你是某商家的售后客服助手，只服务已下单用户。

任务范围：
1. 解答订单状态、物流进度、退换货政策相关问题。
2. 用户询问订单状态但未提供订单号时，先请用户提供订单号。
3. 与售后无关的问题，礼貌说明只能处理售后事项。

工具使用规则：
- 拿到订单号后，调用订单查询插件获取状态。
- 插件返回为空或报错时，告知用户暂时无法查询，建议稍后重试，不要猜测订单状态。

输出要求：
- 回答控制在三句话以内。
- 涉及政策条款时，只陈述已确认的政策内容，不自行补充条件。

第三步，选模型。先选一个通用对话模型跑通流程，观察回答是否符合格式要求，再决定是否更换。

第四步，挂插件。只挂载订单查询这一个插件，完成授权与参数配置，并在提示词里已经写明调用条件。

第五步，编排。这个场景流程较短，可以先用提示词加插件完成；如果后续要加入「查询后自动生成退换货指引」这类固定后续动作，再把节点画进编排里。

第六步，调试。依次测试：提供订单号查询状态、不提供订单号询问状态、询问退换货政策、询问与售后无关的问题、模拟插件无返回。五个场景都符合预期后再进入发布。

第七步，发布。选择支付宝小程序作为目标渠道，按提示完成授权与信息填写后提交。上线后收集真实对话中的异常案例，回到提示词里补充约束。

注意事项

深度定制受平台约束。平台提供的是可视化配置与自然语言交互，能改的是提示词、模型选择、插件与流程编排；底层运行时和基础设施不在可改范围内。如果需求涉及深度定制，要提前评估平台是否够用。
生态偏向支付宝。发布渠道以支付宝小程序等为主，如果目标用户主要在其他平台，需要先确认对应渠道是否支持。
费用需自行确认。部分插件与模型调用可能产生费用，具体计费项、免费额度与价格会调整，一律以官网当前信息为准。
可用性需自行确认。账号注册、地区可用性、商用授权等条件可能因地区与时间而异，动手前先在官网核对。
插件不是越多越好。每增加一个插件，就多一条模型可能误判的路径。只挂当前任务必需的插件，并把调用条件写进提示词。
提示词要迭代而不是重写。发现偏差时在原提示词上追加约束，保留已经生效的部分，避免每次重来导致效果反复。
发布前重跑测试。修改提示词或插件配置后，之前通过的场景可能失效，发布前把测试清单完整跑一遍。