Appearance
低代码智能体
低代码智能体是一类以对话为主要交互方式的 AI 助手。你可以通过可视化配置，将大模型与提示词、技能、知识和记忆组合起来，让智能体在明确的业务边界内理解问题、调用工具并生成回答。
它适合客服问答、业务咨询、资料检索、流程办理、内容生成和企业内部助手等场景。与只依赖通用大模型的对话不同，低代码智能体可以通过业务知识补充专业信息，通过插件或工作流执行实际操作，并利用记忆改善连续对话体验。
使用说明
不同项目类型、模型、发布渠道和账号权限下，可配置的能力可能不同。请以当前编辑器实际显示的选项为准。
选择合适的开发对象
低代码智能体、工作流和低代码应用解决的问题不同，也可以组合使用。
| 开发对象 | 适合的需求 | 典型用法 |
|---|---|---|
| 低代码智能体 | 以自然语言对话为入口，需要理解意图并动态决定如何回答或执行 | 知识问答、业务助手、客服、内容生成 |
| 低代码工作流 | 步骤明确、执行顺序稳定，需要处理多步数据或调用多个服务 | 数据处理、审批流、报告生成、批量执行 |
| 低代码应用 | 需要自定义页面、表单或交互界面 | 在应用中调用智能体或工作流完成业务操作 |
当任务主要依赖对话判断时，优先创建低代码智能体；当任务必须严格按步骤执行时，可先搭建工作流，再把工作流作为智能体的技能使用。
核心能力
编排能力
编排决定智能体“是谁、能做什么、应该怎样回答”。
| 能力 | 说明 |
|---|---|
| 人设与回复逻辑 | 定义角色、目标、服务范围、回答规则、禁止事项、输出格式和异常处理方式。清晰的提示词是智能体稳定运行的基础。 |
| 模型设置 | 根据任务对推理、知识、速度和成本的要求选择模型或自动模式。模型能力和可用范围以当前环境为准。 |
| 编排模式 | 使用单 Agent 直接完成任务，或使用多 Agent 将复杂任务拆分给不同角色协同处理。 |
编写人设与回复逻辑时，建议至少说明以下内容：
- 智能体承担的角色和最终目标。
- 可以回答和不应回答的问题范围。
- 处理任务时应遵循的步骤和优先级。
- 可使用的知识、技能或工作流，以及使用条件。
- 回复的语言、语气、格式和长度要求。
- 信息不足、工具失败或结果不确定时的处理方式。
技能
技能用于扩展大模型本身不具备的查询、计算和执行能力。
| 技能类型 | 作用 |
|---|---|
| 插件 | 通过 API 连接外部平台或业务服务，例如搜索信息、查询数据或提交业务请求。 |
| 工作流 | 将多个节点编排为稳定的执行过程，适合多步骤任务、数据转换和复杂业务逻辑。 |
| 触发器 | 在指定时间或事件发生时自动启动任务。是否可用取决于项目类型和当前版本。 |
添加技能后，应在提示词中写明调用时机、输入来源、结果用途和失败处理规则，并在预览区使用真实问题验证参数传递和返回结果。
知识
知识用于补充企业资料和专业领域信息，提高回答的准确性与可追溯性。平台可根据已添加的知识内容进行检索，再将召回结果提供给模型生成回答。
| 知识类型 | 适合的内容 |
|---|---|
| 文档知识 | 规章制度、产品手册、操作指南、FAQ 和业务资料 |
| 表格知识 | 商品、客户、指标等结构化数据，以及需要按字段检索或计算的数据 |
| 图片知识 | 产品图、设备图、图示资料等需要结合图片内容检索的信息 |
知识不是越多越好。应按业务主题拆分资料，及时清理重复、过期或相互冲突的内容，并通过典型问题检查召回结果是否符合预期。
记忆
记忆用于保存对话之外仍需复用的信息，使智能体能够持续理解用户偏好、历史状态或业务数据。
| 记忆方式 | 适合的用途 |
|---|---|
| 变量 | 保存当前对话或当前任务中的临时状态，例如用户选择、流程阶段和中间结果 |
| 数据库 | 按结构化字段保存和查询业务数据，适合需要持续新增、更新或检索的记录 |
| 记忆库（长期记忆） | 保存可跨对话复用的用户偏好、事实和历史信息，提升个性化体验 |
使用记忆时，应明确写入条件、更新规则、有效期限和读取范围。涉及个人信息或敏感业务数据时，只保存完成任务所必需的内容，并遵循当前企业的权限和数据管理要求。
对话体验与角色呈现
你可以通过开场白、问题建议和快捷指令降低用户的使用门槛；在当前项目支持时，还可以配置头像、声音、背景、语音交互或其他输入方式。插件和工作流的输出也可以绑定卡片，以更清晰的结构呈现结果。
- 开场白：说明智能体可以提供什么帮助。
- 问题建议：给出用户可以直接尝试的典型问题。
- 快捷指令：为高频任务提供固定入口和参数模板。
- 角色设置：通过名称、头像、简介和声音保持统一的人设。
- 结果卡片：将列表、状态或操作结果按结构化样式展示。
编排模式
| 模式 | 适用情况 | 配置重点 |
|---|---|---|
| 单 Agent | 任务边界清晰，一个角色即可完成理解、调用和回复 | 明确提示词边界，按需添加知识和技能，减少不必要的复杂度 |
| 多 Agent | 任务包含多个专业角色或阶段，需要分工、交接和汇总 | 明确每个 Agent 的职责、转交条件、共享上下文和最终结果格式 |
建议先用单 Agent 验证核心场景。只有当角色职责明显不同、单个提示词难以稳定覆盖复杂任务时，再拆分为多 Agent，避免因为过度编排增加调试成本。
标准开发流程
- 创建智能体：填写名称、头像和简介，选择合适的项目或编排类型。
- 定义人设与边界：说明角色、目标、可处理范围、回答规则和异常处理方式。
- 选择模型：根据任务质量、响应速度和成本要求选择模型或自动模式。
- 验证基础对话：先在不添加复杂能力的情况下测试提示词，确认基本回答符合预期。
- 按需搭建能力：逐步添加插件、工作流、知识和记忆，并为每项能力设置明确的使用条件。
- 优化对话体验：配置开场白、问题建议、快捷指令和角色信息。
- 预览与调试：覆盖正常问题、边界问题、信息不足、工具失败和权限不足等场景。
- 发布与迭代：检查版本、资源权限和发布渠道，发布后根据实际运行结果持续优化。
预览、发布与运维
预览区用于验证智能体的回复、工具调用、知识召回和记忆读写。调试时不要只测试“能够成功”的问题，还应检查无匹配知识、参数缺失、服务不可用、越权请求和连续追问等情况。
发布前建议确认：
- 名称、头像、简介、开场白和问题建议已经完善。
- 提示词与实际业务边界一致，没有相互冲突的规则。
- 插件、工作流、知识库和数据库的权限、凭据及参数配置有效。
- 关键场景已经完成预览测试，失败时能给出清晰提示。
- 已选择正确的版本、运行环境和发布渠道。
- 本次变更内容和已知限制已记录，便于后续协作、回滚和排查。
可用的发布方式会随环境和权限变化，通常包括企业运行入口、开放接口或 SDK 等。发布后如继续修改提示词、技能或资源配置，应重新验证相关场景，并按平台要求更新发布版本。
设计建议
- 先确定边界，再增加能力：先让基础对话稳定，再逐项添加知识、技能和记忆。
- 区分知识与技能：知识负责提供回答依据，技能负责查询实时数据或执行操作。
- 让调用规则可判断：不要只写“必要时调用”，应说明什么问题、什么条件下调用哪个能力。
- 控制记忆范围：只保存需要跨步骤或跨对话复用的信息，避免写入无关或敏感内容。
- 为失败路径设计回复：工具失败、数据为空和权限不足时，应明确告知用户并给出下一步建议。
- 保留可复现的测试问题：将典型问题、边界问题和预期结果作为每次发布前的回归检查清单。