[]
本页面聚焦AI智能体的开发过程，介绍传统开发方案与低代码开发方案的异同点，帮助读者加速AI智能体的技术选型过程。
推荐阅读：有一定软件背景的技术人员，如软件项目经理、技术团队管理者和数字化管理团队等。
在AI智能体的技术架构与解决方案中，我们详细介绍了智能体的核心技术，尤其是“核心中的核心”，智能体引擎。在面向专业开发人员的低代码开发平台中，智能体引擎已经成为了低代码平台的一个重要模块，为开发者提供了可视化的智能体构建体验。图1是活字格低代码开发平台的架构图，AI引擎是与页面渲染引擎、工作流引擎、报表引擎并列的一级模块，这就意味着活字格的开发者能够像构建页面、报表一样去定制开发AI智能体。
（图1 活字格低代码平台架构中的AI引擎）
事实上，AI智能体从本质上讲就是一种特殊的软件，其最大的特点在于该软件与AI大模型进行了深度集成。和主流的企业软件一样，智能体也采用前后端分离的架构：
前端：通常为适配多终端的Web页面。部分智能体的页面设计围绕对话框展开；另一部分智能体为了延续传统体验，降低学习门槛，采用了传统的页面布局
后端：基于HTTP协议的WebAPI，接受来自前端的用户意图，返回加工处理后的AI大模型响应。大多数企业智能体也会提供权限控制、用户与会话保持等功能
理论上，能够开发企业Web应用的低代码平台均可用来构建AI智能体。现实中表现如何？我们用智能体引擎的视角审视低代码平台，如图2所示，可以清晰看到低代码中的智能体引擎是如何工作的。
（图2 智能体引擎中各组件与活字格的对应关系）
AI智能体的主要开发工作集中在后端，以用户的意图为输入，完成必要的处理后，将AI大模型的响应发还给前端。以活字格低代码开发平台为例，AI智能体的后端部分是“服务端命令”。接下来，我们将展示如何使用服务端命令功能，实现AI智能体的后端功能。
首先，AI智能体的开发过程可以分为两个阶段，构建调用单元（LLM Call）和使用执行单元构建工作流（Workflow）。
调用单元是一个独立的元素，给大语言模型输入一定的内容，并将大语言模型返回的信息传递给调用者，如图3所示。
（图3 智能体中的执行单元）
完整大调用单元中，通常还会提供以下能力：
知识引入（Retrieval）：查询与输入内容相关的外部知识，并将其同步提交给大语言模型
能力引入（Tools）：为大语言模型传递可供调用的外部能力，表现为函数或MCP Server
读写记忆（Memory）：将大语言模型的处理结果写入上下文的变量中，以便与其他执行单元写作
最简单的智能体甚至仅包含一个执行单元，所以也可以说一个执行单元本身就是一个微型的智能体。
当我们设计AI智能体时，通常会将复杂的任务拆解为若干子任务，其中一部分是需要调用大语言模型的（即调用单元），另一部分则与传统管理软件类似，如逻辑判断、数值处理、文字处理等等。这些子任务拼接在一起，形似BPM中的工作流，所以也被冠以了“工作流”（Workflow）这个名字。但需要注意的是，智能体的Workflow与BPM的工作流并不是一回事，使用BPM工具来构建智能体也不是一个值得推广的实践。
为了便于您理解Workflow，我们整理了最常见的Workflow类型，共计5种。这些类型的叠加和嵌套，最终就形成了完整的智能体。
提示词链如图4所示，我们将一系列调用单元串联起来，每调用一个单元后，基于前一个单元的输出来判断下一环节该调用哪个单元，实现类似if-else的效果。
（图4 提示词链）
这种类型适合那些可以被清晰拆分并且能够穿行执行的任务，比如：
营销文案编写
公文撰写
路由如图5所示，与提示词链相比，增加了分类路由环节，基于第一个调用单元的返回结果，决定接下来的环节是哪一个调用单元，实现类似switch case的效果。路由可以是基于AI的（即一个承担路由任务的调用单元），也可以是基于预定的规则进行的，类似于一系列的if-else组合。
（图5 路由类型）
该类型适合需要被分拣分类的任务，比如：
智能客服
并行化如图6所示。我们将一个任务拆解成若干个并行的调用单元，全都完成后再进行聚合最终生成最终的结果。
（图6 并行化类型）
企业中该类型的场景较少，Cursor等编程助手中的代码漏洞检查采用了该模式。
该模式如图7所示，顾名思义，是路由模式和并行化模式的结合体。
（图7 路由-并行化）
应用场景与并行模式类似。
如图8所示。工作流中的设计成对出现的两个调用单元，分别担任生成和评估两个角色，前者类似于答卷的考生，后者更像是判卷的老师考生交卷后由老师打分，不及格的话打回给考试重写，直到符合要求。
（图8 生成器-评估器）
该模式适用于有明确评估标准且能够多次迭代改进输出质量的任务，比如：
文学翻译
调用单元是智能体编排的核心，除了该节点外，其他节点均与传统软件开发一致，所以，我们将关注的重点放在调用单元上。
活字格提供【AI助手命令】对应的是上述方法论中的“调用单元”，提供了调用大模型的基础能力。如图9所示。
（图9 调用大模型）
输入为分为三部分：
系统提示词：通常用于定义大模型的“人设”
用户提示词：由用户输入的意图、上下文信息和相关知识构成
用户输入：简化版的“用户提示词”，不包含上下文和知识
用户提示词是本命令的核心，您可以在命令中使用参数组织提示词，如图10所示。这里的参数可以是当前用户上下文、从数据库中实时获取的数据也可以是从外部知识库获取的相关知识。
（图10 服务端命令中AI助手命令的提示词编辑界面）
需要注意的是，提示词与AI大模型的返回效果直接相关。在复杂的企业业务场景中，我们需要频繁调整AI提示词来处理那些大模型处理不如人意的场景，提升其总体效果。此时，我们可以将提示词分为框架和业务两部分，框架提示词中说明任务要求和工作方式，保存在调用单元中；业务提示词则关注具体的业务场景描述，保存在数据库中，如图9的“参数提示词”参数就是从数据库中读取的。这样，您就可以通过修改数据库中的业务提示词来完成调优，而无需重新发布智能体应用了。
在活字格中，您可以通过以下地址获取上述示例：https://gitee.com/low-code-dev-lab/hzg-demo-strict-mode-call
大模型返回的输出将会被存储到变量（与编码开发的概念类似，是内存中的变量）中，成为Workflow上下文的一部分，提供给接下来的环节使用。
外部能力引入主要基于Function Call模式来实现，后期将会扩展至MCP协议。
活字格的【AI助手命令】中，您可以通过“函数定义列表”功能管理该调用单元中用到的外部能力（Tools）。函数的定义界面如图11所示。大模型将会根据您配置的函数名称、描述、参数名称、参数描述、返回值名称、返回值描述等自动选取需要使用的外部能力，并将其应用在大模型的处理过程中。
作为最佳实践，我们建议您将需要复用的外部能力封装为私有的服务端命令，在函数定义列表中，直接调用该命令即可。
（图11 配置函数定义列表）
为了提升调试效率，确保引入的外部能力按照预期被调用，活字格将AI大模型调用的日志与外部能力调用的日志进行合并与对齐，如图12所示，在大模型调用中，使用到了名为“获取折扣政策”的函数（该调用的是get_discount服务端命令）来获取实时的折扣信息，该调用的传入传出参数和执行步骤都在日志中得到展现。这样，您就可以通过查看日志来做持续优化与迭代。
（图12 调试嵌入到AI大模型的外部能力，执行日志）
需要特别注意，FunctionCalling和MCP的原理都是将外部能力提供给AI大模型，由大模型决定是否调用，调用哪些，AI大模型不一定按照你的预期调用这些外部工具，这也是AI幻觉的主要来源之一。
在实际项目中，如果你希望确保大模型调用到特定的外部能力，可以将这部分能力编排在Workflow中，并通过上下文参数与大模型进行交互；再将其他外部能力添加到FunctionCall中即可。这种做法一方面可以平衡整个方案的开发投入、效果与可控性，另一方面还能有效降低FunctionCall带来的大量token消耗，一举多得。
在活字格中，您可以通过以下地址获取上述示例：https://gitee.com/low-code-dev-lab/hzg-demo-ai-chat-with-traditional-ui
活字格将外部知识的引入与上下文信息的补全做了统一化处理，即在服务端命令的Workflow中通过设置非AI节点，如通过【发送HTTP请求】、【设置变量命令】等机制从数据库、WebAPI中获取上下文数据和外部知识，并将其存储到变量中。在【AI助手命令】中使用这些变量来拼接提示词，达到将这些信息同步传递给大模型的效果。
相比于将知识获取和引入的环节紧绑定到调用大模型的RAG模式，这种做法统一性强，更有利于扩展和复用。
活字格内建用户会话管理和RBAC权限控制机制，您可以通过配置服务端命令（AI智能体的后端）所需的角色来实现访问权限控制。此外，您还可以通过%CurrentUser%关键字获取当前会话的用户名，再利用“用户数据视图”补全用户信息。
有了用户信息，我们就可以进行权限控制了。AI智能体的权限控制有两个层次，大部分场景下，我们需要控制的是“谁能使用该智能体”，您可以直接使用活字格【服务端命令】的权限控制机制来完成配置，即声明式的权限控制。
（图13 智能体级别的权限控制，声明式）
但在一些任务型智能体中，我们通常会将多个任务集成到同一个智能体中。为了更精细化的控制用户是否能够让智能体执行特定的任务，可以参考Workflow的路由模式，在让AI大模型实际操作前，追加一个调用单元来实现意图识别，先判定当前用户的请求属于哪种类型的任务，然后再Workflow中追加权限校验的节点，用显式调用的方式进行鉴权，及时拦截没有权限的请求，如图14所示。
（图14 任务级别的权限控制，调用式）
在活字格中，您可以通过以下地址获取上述示例：https://gitee.com/low-code-dev-lab/hzg-demo-strict-mode-call
在会话上下文层面，您可以利用服务端命令中的变量来存储智能体中使用到的会话上下文数据，如外部知识、实时查询的业务数据等。如果需要将其持久化到数据库中，也可以通过【数据表操作】和【设置变量命令】来实现存取操作。
我们继续以活字格低代码开发平台为例，展示如何构建前端界面，并通过与后端功能联动，实现AI智能体的前端功能。
智能体的前端主要有两种体验风格，会话式和传统方式，两者对比如下表所示：
维度 | 会话式创新体验 | 表单式传统体验 |
|---|---|---|
典型特征 | 以对话框为主，人工输入文字、图片或语音等多模态信息，再将AI处理的结果在对话框中以文字、图片或组件、外部链接来呈现 | 类似传统软件，通过表单提交任务，再将AI处理结果以表单、列表或报表等形式来呈现 |
用户观感 | 全新的软件，类似微信 | 传统的企业软件，和之前用过的ERP等类似 |
目标群体 | 追求新体验的年轻用户 | 喜欢传统方式的年长用户 |
技术挑战 | 对多模态输入和输出的处理 | 多轮对话效果 |
推荐场景 | 基于AI技术构建新场景 | 把传统软件中的某个场景中融入AI的处理环节 |
会话式体验是AI智能体的典型表现。
会话式体验是也是大多数C端智能体的选择。该类型前端的核心组件是类似微信的“对话框”，在同一个页面上持续展示多轮次的用户输入信息与AI返回信息，如图15所示。
（图15 对话式AI智能体体验）
在实际的AI智能体中，AI对话框可以分为来自AI的消息和来自用户的消息两种，就像微信聊天中你和好友一样，分列在两侧。
来自用户的消息通常需要支持多种模态：
文字
语音：通常需要自动转换为文字
图片：需要配合能接收图片的大模型
视频：需要配合能接收视频的大模型
来自AI的消息在用户消息的基础上追加了以下几种形态：
候选提示词：AI推断用户下一步可能户提出的问题，用户点击即相当于输入了对应的提示词
小组件：用于结构化呈现数据的可视化组件，类似于一个小型的表单或若干图表的组合。AI推荐的相关问题是典型的小组件，如图14中由蓝色箭头和超链接组成的列表
外部链接：可供点击的超链接，点击后可以跳转到其他页面，或执行特定的前端任务，如弹出对话框、更新页面其他区域的值或样式等
在活字格中，对话框对应的是【AI对话单元格】。【AI对话单元格】支持两种用法，简易设计和前后端分离设计。
简易设计与活字格的数据绑定机制类似，即采用内置的AI智能体运行，无需开发智能体后端。
借助内置的调用单元（LLM Call），开发者可以像服务端命令中一样，在直接配置AI对话单元格的大模型和函数定义列表，可以省掉创建服务端命令这一步操作。但这种模式通常仅适用于不需要引入外部知识的单一调用单元，不支持通过Workflow来解决复杂任务。该用法在企业软件中应用场景相对较少。
这是企业场景下AI智能体开发的主流模式，引入了软件开发中前后端分离的设计理念，前端界面和后端智能体独立设计。
该模式下，仅将【AI对话框】单元格用作前端呈现，通过该单元格的“添加文本消息”（消息类型：user）设置用户的文本消息（需隐藏底边栏，采用独立的文本框或语音识别单元格来获取用户输入，如图15所示），同时将文本消息和聊天记录（通过单元格“获取历史消息”操作来组织）作为参数调用作为智能体后端的服务端命令，如果返回的是文本，可通过单元格的“添加文本消息”（消息类型：assistant）输出到对话框，小组件的话可通过“添加组件消息”（消息类型：assistant）来实现输出。如涉及到候选提示词或外部链接的场景，则需要将其封装为组件后，参照小组件模态来输出，如图16所示。这是企业智能体场景的常规实现。
（图16 在前端调用智能体后端，并将结果以三种形式输出到AI用-对话框组件）
为了便于开发者更快速构建对话框式前端页面，我们还封装了“AI用-对话框组件”、“AI用-链接列表组件”、“AI用-详情页按钮”和“AI用-嵌入式页面组件”4个组件，并配套了演示Demo，可以从以下地址获取： https://gitee.com/low-code-dev-lab/hzg-demo-ai-knowledge-base.git
将AI智能体无缝融入管理软件的“兼容方案”。
该方案可以分为两大类，其中一类是在管理软件页面内部嵌入一个对话框，另一类则是采用表单的形式向AI提交任务，再通过软件界面或流程，在AI返回内容的基础上开展后续工作。
企业场景下，AI返回的内容需要提供更丰富的可视化呈现与交互能力，与上一章节中“会话式创新体验”将软件界面以小组件的形式嵌入对话框中不同，嵌入式对话框则是将对话框和软件界面分离开，AI对话框通过【设置单元格属性】、【设置行列布局】等命令操作软件界面上的其他元素，实现AI与软件界面的联动。效果如图17所示，接收到有效的商品清单后，即自动填充到左侧的订货单。
（图17 传统软件界面与AI对话框的联动）
该功能的实现与“会话式创新体验”章节中的“前后端分离模式”类似，但需要在AI智能体后端中进一步增强对响应内容的约束，如在提示词中明确要求大模型按照指定格式的JSON返回，如图18所示。接下来我们就可以在前端根据返回的JSON做出对应的动作，如本示例中更新页面上的表格等，如图19所示。
（图18 明确指定返回JSON格式的提示词）
（图19 将AI返回的JSON体现在AI对话框以外的软件界面中）
在活字格中，您可以通过以下地址获取上述示例：https://gitee.com/low-code-dev-lab/hzg-demo-ai-chat-with-traditional-ui.git
对于生成型智能体来说，很多场景是没有必要进行多轮交互的。一次性将任务用结构化的方式描述清楚，等待AI的生成结果后进行审核。这种做法下，我们可以简单的将AI智能体视为一个第三方WebAPI，我们提交一个请求，等待返回结果即可。
在活字格中，我们直接在前端使用【调用服务端命令】调用智能体服务端命令，处理其返回的结果，如图20所示。如果需要采用异步的方式调用，还可以配合“服务端通知”（基于WebSocket）向前端实时通知处理进度。这些属于低代码平台的常规功能，在这里不再赘述。
（图20 在前端页面直接调用智能体，并通过服务端通知接受进度反馈）
在活字格中，您可以通过以下地址获取上述示例：https://gitee.com/low-code-dev-lab/hzg-demo-web-api-ai-integration
Q：我该如何在智能体中引入现有的AI知识库？
A：在活字格中，AI知识库的引入采用的是与其他上下文数据一样的“参数机制”（类似于Memory，内存读写能力）。您需要通过【发送HTTP请求】命令，将用户输入的内容作为参数传递给知识库的WebAPI，然后将返回的结果作为“相关知识”拼接到提示词中后再提交给大模型。
Q：如果我调用的大模型不支持Function Calling怎么办？
A：截止2025年4月，deepseek等大模型暂未支持function calling。这个功能并不是智能体开发的必备能力，上文中在外部能力引入章节中详细介绍了如何将外部能力放在Workflow而不是Function中，还配套了演示Demo。如果你坚持希望采用该模式，除了替换成支持该功能的大模型，您可能需要通过提示词工程来模拟function calling。整体思路可参考这篇文章：Deepseek的FunctionCalling功能代码实现完整流程（CSDN）
