Google Chat App 为何按 Workspace Add-ons 格式解析响应？

2026-11-06数据小陈

结论

错误信息表明，接收响应的一侧正按 Google Workspace Add-ons 的响应结构解析内容。仅凭这些错误，无法判断项目实际配置的是哪种 Chat App，也不能据此认定存在可切换请求路由的隐藏开关。请先核对实际使用的 Cloud 项目、Chat API Configuration 和应用部署类型，再检查 HTTP 处理函数最终返回的响应体。

Google 官方配置文档将通过 HTTP endpoint URL 接收 Chat 事件列为一种交互式 Chat App 连接方式。文档还指出，如果填写了 Apps Script deployment ID，项目就连接着现有的 Google Workspace add-on。Chat API 配置说明

先核对应用配置

打开接收该事件的 Cloud 项目中的 Google Chat API → Configuration，确认项目 ID 与部署 FastAPI 服务、启用 API 时使用的项目一致。
在 Interactive features → Connection settings 中确认选择了 HTTP endpoint URL，并检查 URL 是否指向当前 ngrok 地址。如果配置显示 Apps Script deployment ID，根据官方文档，该项目连接着现有 Workspace add-on。请确认实际测试的应用和部署是预期的 HTTP endpoint 应用。
检查 Workspace Marketplace 或其他部署配置，确认测试时打开的是按该项目配置的 Chat App。错误信息说明解析器期待 add-on 格式，但无法指出是哪项配置启用了这个解析器。
保存配置后，重新向对应的应用发送消息，并确认 FastAPI 日志记录到的请求确实到达当前 endpoint。

gsuiteaddons.googleapis.com 是管理 Workspace Add-ons deployment 的 API 服务地址，与 Chat 交互事件的 HTTP endpoint 是不同概念。启用或停用这个管理 API，不能单独证明哪个应用配置处理了交互事件。Google Workspace Add-ons API

检查 FastAPI 返回值

标准 Chat App 的文本消息响应可以是这样的 JSON 对象：

{"text": "Hello"}

在 FastAPI 中，可以直接返回字典，也可以明确构造 JSON 响应：

from fastapi.responses import JSONResponse

async def handle_event(request):
    return JSONResponse(
        content={"text": "Hello"},
        status_code=200,
    )

请确认服务端实际发出的响应体是 JSON 对象，而不是将正文、状态码和响应头一起序列化成数组。问题中第四次尝试的错误确实显示了类似数组的内容，这表明该次处理链路可能把 HTTP 响应参数当作 JSON 内容。不过，缺少完整的 Functions Framework 路由代码，无法确定是哪一层将内容组装成了数组。

仍出现相同错误时

记录一次请求的目标 URL、HTTP 状态码、Content-Type 和原始响应体，并与 Chat API Configuration 中的 endpoint 逐项核对。如果确认该配置使用当前 HTTP endpoint，且服务端发出的是 {"text":"Hello"}，错误却仍明确要求 RenderActions、DataActions 或 Card，就需要进一步查明实际触发事件的应用部署身份及其配置。单纯改用 cardsV2 或添加 actionResponse，无法解决配置与响应协议不匹配的问题。