通过搭建 24 点小游戏应用实战，带你了解 AppBuilder 的技术原理

本文将通过一个 24 点小游戏的案例，详细介绍百度智能云千帆 AppBuilder 的基本技术原理和使用方法，帮助读者快速掌握 AI 原生应用的开发流程。

1 三步构建 AI 原生应用方法论

AI 原生应用与传统应用的最大区别是交互形态彻底的拟人化，通过文本、语音、视觉信号直接驱动应用为用户完成具体任务。本文主要讨论的是以自然语言文本为主要形态的 AI 原生应用。在构建各种对话式应用的过程中，我们总结了如下几个关键步骤来实现 AI 原生应用的原型版本。

创意描述：一句话描述你的创意。
创意拆解：将创意拆解为思考模型和组件两类工作。
创意实现：选择合适的工具，通过自然语言描述思考模式，实现组件。

2 案例分享：对话式 24 点小游戏

一个简单的 AI 原生应用应该能用一句话清楚的描述功能边界：用户可以通过对话的方式要求该应用随机出一个 24 点的题目，并可以验证用户提供的数学公式计算结果是否为 24。同时，在用户提出需要帮助的时候能够提示当前题目的解法。

创意分析：该应用主要包括三个功能：随机生成几个数字来构建 24 点游戏、验证一段文本中的数学表达式计算结果是否为 24、根据当前的题目给出建议。这三个功能本质上都涉及到数值计算，用代码实现会非常简单。但是用大语言模型把这些功能串联成一个可以通过对话方式使用的应用就会让人摸不到头脑。

接下来，我们将通过 AppBuilder 来构建这个对话式 24 点小游戏。

2.1 方案概述

由于大语言模型的技术原理仅是预测下一个词，因此单纯依靠提示词工程或指令微调来实现「随机出题」、「验证题目」、「解法推荐」这三个功能并不可靠。基于工具组件增强的大语言模型技术（Agent 技术）才是实现这个 24 点应用的有效方法。

Agent 是一种设计模式，即通过自然语言驱动大语言模型决策要使用的工具，并能够根据工具执行的结果进行下一步决策。对于大部分简单任务来讲，都可以把任务分解为「思考模块」的定义和工具组件实现。

其中，思考模块一般是一个思考模型。它并不一定是特殊的模型，也可以是一个普通的通用大模型。之所以叫思考模型主要是因为这个模型做的事情就是思考、规划和决策。

在构建 AppBuilder 的过程中，思考模型需要遵循复杂的指令，例如格式遵循、用户指令、系统指令、对话历史、组件执行历史等，底座模型的指令遵循能力是最关键的能力，其效率、稳定性、成本是构建 Agent 的关键。

2.2 24 点小游戏任务拆解

下面是对话式 24 点小游戏的任务拆解：

定义思考模块的功能边界：基于大语言模型定义调用组件的协议，包括调用组件的条件描述、组件本身的描述、组件入参的设计。
实现组件：结合思考模块中定义的组件描述、组件入参设计，实现具体组件的功能。

2.3 AppBuilder 实现 AI 原生应用的框架

对任务进行拆解后，我们需要选择一个工具来进行创意的调试和优化，这就需要引入一些平台型工具才能完成。下面是以 AppBuilder 为例说明「思考+组件」是如何在一个完备框架内实现的。

2.3.1 思考过程

百度智能云千帆 AppBuilder 的构建是以交互式对话为主线和应用入口的。在对话过程中，思考模型通过不断整合系统/用户采集环境中的信息来进行决策和反馈，最终实现我们的任务。整个框架的理论基础来源于 ReAct 算法。ReAct 算法并不是最高效的解决框架，但由于其像人类一样采用摸着石头过河的性质（Greedy）以及执行流程的可解释性比较好，我们选择以该算法为主框架实现 Agent 应用。

2.3.2 执行组件

所有组件都是以标准的表达方式呈现给思考模型，而组件的具体执行则依赖工程化的实现。

整个 AppBuilder 的构建框架是一套配合效率较高的 Agent 执行框架，并且从产品的设计方面引入了调试各个环节的开关和选项，在对话执行过程中系统会将影响思考模型决策的关键信息整理好送给模型。包括但不限于：

长期记忆：例如持久化的变量、知识库中检索的内容。
短期记忆：多轮对话历史、系统时间、时效性信息等。
组件描述：官方组件自带标准描述，用户自定义组件依赖用户定义描述。
组件执行结果：对于单轮对话下无法用一次组件调用完成的任务，通常需要调用多次组件，历史组件的调用结果需要告知思考模型。
系统指令：通常是内置的一段用户不可见的 prompt。
用户角色指令：用户自定义的指令。
当前对话的 Query、用户上传的文件信息等。

2.4 定义思考模块的功能边界

2.4.1 AppBuilder 的零代码应用编排功能实战

打开 AppBuilder 然后点击左上角创建应用即可进入零代码开发页面。（https://console.bce.baidu.com/ai_apaas/app）

在 24 点游戏应用的构建中，影响效果的关键要素是：

角色指令：通过自然语言描述应用的作用、组件的功能、组件的调度规则。
组件：开发者选择的组件(官方组件/自定义组件)，即为思考模型可见的组件，在自然语言对话过程中有一定概率会被模型唤醒和执行。
思考模型：用户对角色的定义、对组件的定义、对组件调度的规则描述都会通过思考模型生效。
问答模型：组件生成的结果使用自然语言进行总结回复的模型，问答模型会参考开发者定义的角色指令进行回复，即问答模型的行为也可以通过角色指令影响。

2.4.2 角色指令

# 角色任务
作为24点游戏助手，你的任务是随机生成4个1到13之间的数字，要求玩家使用加减乘除和括号进行运算，使最后结果等于24.你需要判断玩家给出的答案是否正确，并在必要时提供提示。# 工具能力
1. 出题
用户需要出一道题，或者开始游戏、再来一道题时，使用该工具进行出题。
2. 解题建议
用户希望给一些做题建议的时候，使用解题建议工具来给出解题方案。
3. 答案验证
当用户给出了一个计算24点的表达式，使用24点计算来验证用户的计算是否正确。

2.4.3 组件设计

大部分用户对组件设计会有两个疑问，一是为什么要有组件描述，二是参数设计与应用有什么关系，入参如何填进来。

实际上，组件起到了辅助思考模型更好解决问题的作用。本质上来说，组件是函数或者 API 的抽象表达，那么对于思考模型来说，了解组件的功能以及组件的输入是比较重要的，需要「告诉」思考模型。在实际对话过程中，思考模型通过理解组件的描述、入参信息，判断当前决策下要执行的组件以及入参。

下面是 24 点小游戏中，出题组件、答案验证组件和解题建议组件的示例。

出题组件：

描述：当用户表达想要玩一局 24 点游戏的时候，使用该组件进行出题，返回的是一道计算 24 点题目的 4 个数字。
参数设计：{“name”: “start”, “type”: “string”, “desc”: “24 点题目中，4 个数字里的最小值”}，{“name”: “end”, “type”: “string”, 24 点题目中，4 个数字里的最大值""}

答案验证组件：

描述：对用户提供的表达式进行是否能够计算出 24 点的验证，给出结果。
参数设计：{“name”: “expression”, “type”: “string”, “desc”: “用户提供的计算 24 点数学表达式”}

解题建议组件：

描述：当用户希望给出解题建议，或者对题目如何解没有思路时，使用该组件进行候选答案建议，如果当前题目无法计算出来答案，也明确告知用户无法得到答案。
参数设计：{“name”: “number1”, “type”: “string”, “desc”: “第一数字”}，{“name”: “number2”, “type”: “string”, “desc”: “第二数字”}，{“name”: “number3”, “type”: “string”， “desc”: “第三数字”}，{“name”: “number4”, “type”: “string”， “desc”: “第四数字”}

2.4.4 思考模型

为了更快的思考速度和游戏体验，这里选择 2024.05.25 最新上线的 Ernie Speed AppBuilder 专用版思考模型，该模型的思考速度通常是 Ernie 4 的 3-4 倍、Ernie 3.5 的 2-3 倍。

2.4.5 问答模型

同样这里也为了最优的游戏体验，选择 Ernie 3.5-8K 作为问答模型。

2.5 实现组件

「出题组件」、「答案验证组件」、「解题建议组件」这三个组件并不是 AppBuilder 官方提供的组件，需要通过开发者自定义才能完成，以下给出了基于工作流画布的自定义组件实现方案供参考。

2.5.1 出题组件

使用 AppBuilder 工作流中的代码节点对开始、结束节点进行连接。开始节点包含 start 和 end 变量，这个与前面的组件设计一致，而结束节点的输出则是对代码节点输出的题目进行直接输出。

2.5.2 解题建议组件

使用 AppBuilder 工作流中的代码节点对开始、结束节点进行连接。开始节点 number1、number2、number3、number4 四个变量依次代表当前题目的四个数字。

2.5.3 答案验证组件

使用 AppBuilder 工作流中的代码节点对开始、结束节点进行连接。开始节点 expression 代表当前可以直接通过代码进行 eval 得到结果的数学表达式。结束节点的输出则是对表达式执行后是否为 24 的文字表达。

2.6 通过几个 Case 了解思考模型

体验链接：

https://console.bce.baidu.com/ai_apaas/examplePage/e9a7935c-aac3-4465-b86d-8ced27a0bc6e

2.7 一些小技巧

定义思考模块的功能边界是创建一个效果不错的 Agent 最重要的步骤，包括角色指令、组件描述、组件入参设计、组件输出的设计、思考模型选择等。

目前在 AppBuilder 中，官方组件的描述、组件入参出参都是由官方设计并嵌入系统的，并且这些描述也会跟思考模型的训练联动逐渐加强。
自定义组件：组件描述在创建组件时可以填写，并且也可以不断修改和优化。自定义组件的入参描述也非常重要，这个直接决定了思考模型填写正确参数的稳定性。
自定义组件的输出：我们推荐尽量用模型看得懂的语言进行描述，即规范的自然语言，这样系统预置的 chat_agent 组件更容易理解组件的运行结果以做更好的输出。
思考模型的选择：选择思考模型时，需要考虑性价比，对于官方组件来说选择 Ernie-Speed-AppBuilder 专用版是个不错的选择。这个模型对官方组件的描述更熟悉。而 Ernie 3.5、Ernie 4.0 模型的泛化能力较好，对一些自定义组件的思考决策效果更有效。

在实现具体的 Agent 之前，可以尝试先构建一个小规模的测试集，覆盖当前所有组件的能力，这样可以通过构建的 App 来检验创意实现的效果。