问题
已关闭 · 已解答

在自有 App 中使用 Buda,必须展示 Buda 界面吗?

Leonard Li

想请教一下:如果想在自己的 App 里接入 Buda,用户必须使用 Buda 提供的界面吗?

如果我已经有自己的聊天页面,能否保留现有界面,只让 Buda 在后台处理消息?这种接入方式下,登录用户身份和聊天记录通常应由我的 App 管理,还是由 Buda 管理?

举报
Buda FAQ· 已编辑

可以的,不一定要把 Buda 的聊天界面嵌进自己的 App。通过 API Claw(爪),你可以保留现有聊天页面,让 Buda 在后台处理对话。

参考嵌入智能体文档,选择“原生令牌”接入。

举报
Kelly
团队
· 已编辑

可以保留你自己的聊天界面,不必展示 Buda 页面。这里其实有三种接入层级,选哪种取决于你希望 Buda 承担多少工作:

  1. 只需要模型回复:用 Model API。 你的后端调用兼容 OpenAI Responses API 的接口,按需选择 Buda 支持的模型;你的 App 自己管理登录、聊天记录、每次请求的历史上下文,以及工具和业务流程。它是无状态的模型调用,不会替你创建一个带 Drive 和长期会话的 Buda Agent。目前这一路径主要支持文本输入输出,图片、文件和工具调用尚未开放。
  2. 需要 Agent 替用户持续做事:用 API Claws。 Buda 提供 Agent、Drive、运行环境和 Chat Session,你的 App 仍可保留现有聊天页面。后端用自己的 sk_ API key 创建或续接会话;如果前端要直接与 Buda 交互,按嵌入文档签发限定到用户和会话的短期原生令牌,不要把主 API key 放到前端。你的 App 负责终端用户登录、访问权限,以及把自己的用户 ID 对应到 Buda 的 Session ID;Buda 保存该 Session 的消息和 Agent 产出。
  3. 想最快上线且接受现成聊天界面:同一套 Agent 还可以签发短期 iframe URL,直接嵌入 Buda 托管的对话页面。

如果你的目标只是给现有聊天产品增加多模型问答,先看 Model API;如果需要 Agent 用工具、长期资料和会话完成多步骤任务,就看 API Claws。多个客户的资料需要隔离时,再规划各自的 Space。你希望 Buda 只负责生成回复,还是也负责执行任务并保存会话?

举报

你的回复

登录后参与讨论。阅读始终开放,只有发帖和回复需要账号。

登录