百宝箱怎么用？零代码创建 AI 智能体

百宝箱这类零代码平台，把做一个智能体的门槛降到一段描述：说清它给谁用、解决什么问题、答不上来时怎么办，平台就能生成一个能对话的应用，并发布到支付宝的小程序等入口。门槛降下来之后，决定成败的东西从会不会写代码，变成了会不会把需求说清楚。

零代码省掉的是配置，不是判断

传统开发要写接口、拼提示词、处理异常；零代码平台把这些封装成表单和节点。你省下的是工程时间，没省下的是业务判断：哪些问题该答、答到什么程度、哪些必须转人工。

所以先别急着点创建。拿一张纸写四行：使用者是谁、他带着什么问题来、合格的回答长什么样、超出范围时怎么回应。这四行写不出来，后面配多少知识库都补不回来。

平台的能力边界也要先摸清。有的版本支持知识库和插件，有的还要配工作流；发布入口、审核周期、可用的行业资质，各版本差别不小。以平台当前说明为准，别照着旧教程配。

需求描述写四段就够

角色与对象：你是谁、面向谁说话。任务范围：能处理哪几类问题，每类的处理动作是什么。边界：哪些问题不接、接了怎么转。输出形态：回答多长、要不要分点、要不要给按钮。

其中边界最容易漏。一个没有边界的智能体，遇到你们能便宜点吗、这个能确保有效吗这类问题，会用很自信的语气编一个答案。写清楚不确定时说不确定，并引导到人工，比多写十条业务知识有用。

描述里少用形容词，多用条件和动作。友好专业这种词平台没法执行，先确认订单号、再查物流、查不到就说需要人工核实，这种能执行。把通用模板改成自己的说法，三个改编动作讲的就是这件事。

什么时候需要知识库，什么时候需要工作流

知识库解决答得对：产品参数、政策条款、常见流程。判断标准是内容能不能写成条目、会不会频繁变。会变的要标版本和生效日期，否则模型会把旧条款当现行规则。

工作流解决做得成：查订单、算运费、提交工单。这类动作要调用接口，单靠对话完成不了。判断标准是这一步有没有明确的输入输出和失败处理。

两者都不需要的场景也不少。一个只做入门引导、把用户分流到对应入口的智能体，一段清晰的描述加几个按钮就够了。堆太多能力，反而让对话变长、出错面变大。

如果入口是语音，还要把语音合成接进来，长文本转语音那套参数设置会直接影响听感；如果输出要配图，素材得统一，团队素材库的做法可以借鉴。

测试要按问法矩阵跑

同一件事，用户会用好几种方式问。测试至少覆盖六类：标准问法、口语问法、带错别字、信息不全、越界问题、多轮追问。每类准备三到五条，一共二十条左右，跑完再发。

越界问题最能暴露毛病。问它竞争对手的价格、问它内部政策、问它能不能破例，看它是拒绝、转人工，还是开始编。多轮追问则考验上下文：先说我要退票，再说但是我已经值机了，看它会不会把前一句忘了。

每条测试都记下合格长什么样，不要只记感觉还行。二十条里错了五条，就先改描述和知识，不要指望发布后靠人工兜底。

这张表的用法是横着跑：六类各跑三到五条，把不合格的记在同一张表里，改完再跑一遍。

发布前的五项核对

承诺类：能不能做到、有没有时效、有没有前置条件。价格类：是否与当前政策一致、有没有地区差异。资质类：能不能公示、表述是否准确。隐私类：收集什么信息、存多久、给谁看。兜底话术：答不上来时说什么、转给谁。

五项里任何一项含糊，审核都可能打回。发布后的修改通常要重新走审核，所以宁可先测透。具体审核要求以平台当前规则为准。

上线后按问题聚类改

看真实对话记录，不要逐条改。把问题按意图聚类，找出出现频次高的前几类，逐类补知识或改描述。频率低的长尾问题，交给转人工更划算。

每两周看三个数：一次解决率、转人工率、重复提问率。一次解决率低说明知识不够，转人工率高说明边界太窄，重复提问率说明回答没说到点上。

改动要留版本。同一段时间只改一类问题，才能看出是哪个改动起了作用。全量一起改，效果好坏都说不清。

平台接不住的四类需求

需要精确计算的不行。税费、运费、利息这类，模型算不可靠，必须走接口或规则引擎。

强实时数据的不行。库存、排班、物流轨迹，要靠接口查，不能靠知识库背。

复杂多轮业务不行。涉及身份核验、材料上传、多步审批的流程，对话只是入口，实质要在业务系统里完成。

高责任场景不行。医疗建议、法律意见、投入建议这类，即使平台能生成，也不该由一个零代码智能体独立作答。

还有一层是成本：知识库越大，检索越慢，回答越长，调用成本越高。上线前算一下每次对话的平均消耗，乘以预估日活，看预算能不能撑住。

零代码智能体速查

• 先写四行需求，再点创建
• 描述用条件和动作，不用形容词
• 要答得对配知识库，要做得成配工作流
• 六类问法各跑三到五条，共二十条左右
• 发布前核对承诺、价格、资质、隐私、兜底
• 上线后按意图聚类改，一次只改一类