不止回答问题：让 AI 客服连接 HTTP API

知识库适合回答稳定问题，例如政策、产品说明、安装步骤，以及团队会主动维护的其他内容。但有些客服问题依赖持续变化的数据，不适合复制到文档里，服务状态和实时可用性就是两个简单的例子。

这时 HTTP API 才真正有价值。在 Bubblo 中，Action 可以让组织的无状态 AI Runtime 在对话过程中调用一个已经配置的端点。

知识回答与实时数据的边界

如果答案只应在团队编辑并重新索引内容后变化，就使用知识库；如果答案必须在对话发生时从业务系统获取，就考虑使用 Action。

把这条边界划清楚，客服流程会更容易理解和维护：

“你们的取消政策是什么？”应当来自知识库。
“API 现在是否正常运行？”可以读取状态端点。
“怎样安装聊天挂件？”应当来自知识库。
“这项服务当前是否可用？”可以读取实时可用性端点。

Bubblo Action 当前能做什么

Action 直接属于组织，包含名称、用途描述、HTTP 方法、HTTPS URL 模板、请求与鉴权配置，以及测试和启用状态。AI 会根据名称和描述判断端点是否与当前问题相关；Runtime 只能调用当前组织中已经启用、并且当前配置版本已通过测试的 Action。

Action 当前支持 GET 和 POST。请求配置可以组合动态的字符串、数字或布尔输入与固定值：URL 中 {order_id} 这样的占位符会接收同名 Path 参数，其余 Params 会进入 Query，POST 还可以发送 JSON Body 字段；同时也支持固定 Query、固定 Body 和请求头。

鉴权方式可以选择无鉴权、Bearer Token 或 API Key Header。保存后的密钥会被加密，并且无法再次查看。这些能力可以保护发往业务 API 的请求，但动态输入和已保存凭据本身不能证明某位访客有权访问特定账号；业务端点仍需执行该流程所需的权限校验。

选择一个安全的起点

适合作为第一个 Action 的端点应当满足：

实际效果是只读的。 先获取信息，不要从不可逆操作开始。
URL 中不包含秘密。 凭据应使用加密的 Bearer 或 API Key 字段；不要把秘密或客户数据写进配置 URL。
响应足够快。 每次 Action 请求都有固定的 5 秒硬超时。
返回内容小而明确。 响应上限为 20 KB，最好只返回与客服问题直接相关的简短文本或 JSON。
描述足够清楚。 明确告诉智能体端点会返回什么，以及何时才应调用。

公开的服务状态摘要比退款接口更适合第一次测试。它可以验证实时数据链路，同时不会引入客户身份验证或破坏性副作用。

配置并验证 Action

打开Harness → Actions并新建 Action。名称应当短且具体，例如 check_service_status；然后选择 GET 或 POST、填写 HTTPS URL 模板、说明组织的 AI 应在何时使用它，并按需添加动态输入、固定请求值、请求头或鉴权。

先把 Action 保存为草稿。Bubblo 会在保存时校验配置；新建或修改后的版本保持停用，直到这个配置版本通过测试。填写有代表性的测试值并点击运行测试，系统会向端点发出真实请求。测试成功后，再开启启用此 Action。

接着通过真实挂件验证已经启用的 Action：

提出一个与 Action 描述明确匹配的问题。
检查回答是否使用了端点的最新响应。
打开调用日志，查看状态和耗时。
再问一个无关问题，确认 Action 不会被无谓调用。
如果端点发生变化或返回内容不再可靠，及时停用 Action。

成功和失败的调用都会记录下来，控制台会展示最近的匹配记录。每次请求的超时为 5 秒，最多接受 20 KB 响应数据，并且只有 HTTP 200 会被视为成功。新建 Action 或修改配置后，最多可能需要 60 秒才会出现在新的 AI 对话轮次中。当前字段和限制以 Actions 文档为准。

为例外情况保留人工路径

Action 可以让一小段客服流程更高效，但不能代替人的判断。身份验证失败、特殊账号状态、退款等敏感情况仍应当进入收件箱，由团队成员决定是否接管。

更可信的上线方式是逐步扩展：先连接一个低风险的实时数据源，检查调用日志，了解哪些问题会触发它；只有在 API 契约和安全控制都准备好之后，再增加更复杂的能力。