Agent 与应用

功能概述

Agent 是 Clouisle 中最常用的应用形态。
它把模型、系统提示词、知识库、工具、变量和调试能力放在同一个编排页面里，适合快速做出一个可交互的 AI 助手。

适用场景

Agent 常用于：

• 基于文档的问答助手
• 客服、售前或内部支持助手
• 内容生成与总结助手
• 需要自然语言入口的业务助手

前置条件

开始前建议先准备：

• 一句明确的 Agent 目标描述
• 至少一个已接入的平台模型
• 2 到 5 个真实测试问题
• 如果要接知识库或工具，相关资源已经准备好

操作步骤

第 1 步：进入应用列表，确认现有应用结构

先进入工作台的 应用 页面，确认平台里已经有哪些 Agent 和工作流。
这一步的目的不是马上创建，而是先判断：

• 现有应用有没有可以复用的模板
• 当前应用主要是 Agent 还是工作流
• 命名和状态是否已有统一规范

完成这一步后，你应该能明确新 Agent 的命名方式和所属位置。

第 2 步：点击“创建应用”，选择 Agent 类型

点击页面右上角的 创建应用，在弹窗中选择 智能 Agent。
同时填写最基础的名称和描述，先把应用身份确定下来。

建议名称直接体现用途，例如“销售知识助手”“制度问答助手”，不要只写“测试”或“机器人”。

完成这一步后，系统会为你创建一个新的 Agent 草稿。

第 3 步：进入编排页，先完成最小可运行配置

进入 Agent 后，优先完成这几项：

• 模型
• 系统提示词
• 可见性或发布状态

第一次不要同时打开所有增强能力。
目标是先得到一个“仅依赖模型和提示词也能回答”的最小版本。

如果这一步完成顺利，你应该已经能看到完整的编排区、增强能力区和右侧调试区。

第 4 步：编写系统提示词，明确角色和边界

系统提示词建议至少包含 4 类内容：

• 角色定位：它是谁
• 任务范围：它应该处理什么
• 输出规则：回答格式、语气、结构
• 限制条件：不知道时怎么说、不能做什么

如果你的目标是业务落地，不要把提示词写成泛泛的“你是一个乐于助人的助手”。
应直接写成任务导向的说明，例如“你负责根据知识库回答产品操作问题，不得编造不存在的功能”。

完成这一步后，Agent 的回答风格应该已经开始稳定。

第 5 步：按需接入知识库、工具和变量

当基础回答正常后，再逐项补充增强能力：

• 需要基于文档回答时，关联知识库
• 需要调用业务系统时，启用工具
• 需要结构化输入时，配置变量

建议一次只加一种能力，并在加完后立即做验证。
这样后面出现问题时，你能明确判断是提示词问题、知识问题还是工具问题。

第 6 步：在“调试与预览”里做真实问题测试

进入页面下方的 调试与预览 区域，不要只问“你好”。
应直接输入未来用户最常问的真实问题，建议至少覆盖：

• 正常问题
• 信息不足的问题
• 模糊问题
• 需要检索知识或调用工具的问题

如果 Agent 会在调试区里稳定回答，你再进入下一步；如果还不稳定，应回到提示词或增强能力配置继续调整。

第 7 步：确认效果后再保存和发布

只有当下面几类测试都通过后，再考虑点击 保存 或 发布：

• 正常问题回答稳定
• 需要知识时能命中正确内容
• 需要工具时能正确调用
• 不会对未知问题胡乱编造

发布前建议至少保留一份测试问题清单，后续修改 Agent 后可以继续回归验证。

结果验证

一个可用的 Agent，至少应满足下面这些标准：

• 在应用列表中能清楚识别其名称、状态和用途
• 进入编排页后可以看到完整配置，而不是空白草稿
• 调试区提问时能稳定返回结果
• 如果接入了知识库或工具，能够在实际测试中生效

常见问题

为什么 Agent 看起来创建成功了，但回答很差

通常优先检查：

• 模型是否合适
• 提示词是否足够具体
• 是否过早接入过多增强能力

为什么接了知识库却像没接一样

优先去知识库页确认：

• 文档是否处理成功
• 检索是否真的命中
• Agent 当前是否正确关联了目标知识库

为什么调试通过后，上线效果还是不稳定

常见原因是测试样例过少。
建议保留一组真实业务问题，在每次修改 Agent 后都重复测试。

注意事项

• 第一次创建 Agent，先跑通最小版本，再逐步增强
• 每加一项能力就立刻验证一次，不要等全部接完再统一排查
• 发布前一定要使用真实问题测试，不要只做演示式提问