OpenClaw Google Chat 完整性评分细则claw-score 五类评分范围、成熟度档位与仓库证据映射【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw本篇围绕 OpenClaw 成熟度记分卡maturity scorecard中 Google Chat 表面surface的 Completeness 评分细则展开完整解析 google-chat 完整性细则 定义的五大类别评分范围说明每个类别对应的分类学taxonomy特性清单、渠道文档与插件源码证据以及当前仓库已提交的评分结果与验证方式帮助读者理解 OpenClaw 如何对一个消息渠道表面做可复核的完整性打分。1. claw-score 技能与 Completeness 细则的定位OpenClaw 仓库通过 .agents/skills/claw-score/SKILL.md 定义了本地版claw-score工作流它管理成熟度记分卡的四个权威文件taxonomy.yaml手工维护的 source of truth定义 surface表面、级别、QA profile、类别、特性覆盖率 IDcoverageIds、文档引用、LTS 覆盖项与completeness_instructions路径qa/maturity-scores.yaml已提交的 Quality / Completeness / LTS 聚合评分qa/scenarios/index.yamlQA 场景索引生成的公开文档 docs/maturity/scorecard.md 与 docs/maturity/taxonomy.md由pnpm maturity:render生成禁止手工修改生成的 Markdown 来改变评分。在taxonomy.yaml中每个 surface 通过completeness_instructions字段指向一份细则文件Google Chat 表面对应的正是 references/completeness/google-chat.md。该细则的职责是给评分者提供类别范围Category ScopeCompleteness 不按测试广度或实现质量打分而是衡量「预期操作者可见工作流」的完整程度——即从设置setup、正常使用、状态/检查、恢复recovery到重要的平台、渠道、安全与生命周期分支是否齐全。按 SKILL.md 的默认完整性流程评分者需对每个类别回答预期的用户或操作者能否端到端完成该类别工作流taxonomy 中的特性是作为受支持的能力存在还是孤立的实现碎片重要生命周期阶段设置、正常运行、状态检查、恢复、升级/移除是否齐备该表面的重要环境、provider、平台、渠道或安全分支是否都在已知缺口是否使主要用户可见能力分支缺失默认评分档位Bands为档位分数区间含义Clawesome95–100覆盖预期工作流、变体与恢复分支仅余少量打磨缺口Stable80–95预期工作流集合大体齐备仅有限缺失分支Beta70–80主工作流存在但仍有有意义的分支或恢复路径缺失Alpha50–70仅部分能力集存在能完成部分核心任务但非完整工作流Experimental0–50仅暴露预期能力的碎片细则文件同时是评分语义的锚点测试薄不构成降低 Completeness 的理由那是 Coverage实现脆弱同样不算那是 Quality。2. google-chat 表面在 taxonomy 中的定义在 taxonomy.yaml 中google-chat表面声明为- id: google-chat name: Google Chat family: channel level: alpha level_code: M2 rationale: Documented channel, but enterprise/admin setup raises maturity risk. completeness_instructions: references/completeness/google-chat.md其last_score_run记录为2026-05-30、process_version: 3。该表面共划分 5 个类别与细则中的 Category Scope 一一对应Channel Setup and Operations、Access and Identity、Conversation Routing and Delivery、Media and Rich Content、Native Controls and Approvals。下面按细则给出的范围逐类展开并给出每个特性的 taxonomy 描述与仓库证据。3. 类别一Channel Setup and Operations细则为该类别列出的完整范围去重后与 taxonomy 特性清单一致包括Google Cloud project setup、Chat app configuration、Service account setup、Webhook audience and path、Workspace visibility and app status、Guided channel setup、Account resolution、Service account SecretRefs、Env file and inline credentials、Channel status and probes、Directory and mutable-id diagnostics、NPM and ClawHub install、Plugin docs and catalog routing、Channel aliases and labels、Operator status UI、Install/update metadata。taxonomy 将这 15 个特性归为四组语义簇渠道安装与 Google 侧设置前 6 项覆盖 Google Chat 插件安装、Google Cloud 项目与 Chat API 启用、service account JSON / 文件 / 环境变量凭据选择、audienceType与相关的设置鉴权和 workspace app 行为。凭据与账户解析Account resolution 等 5 项覆盖accounts、defaultAccount、顶层与账户级凭据继承、service account SecretRefs以及多账户 secrets 状态与诊断。诊断与探测Channel status and probes、Directory and mutable-id diagnostics。插件分发与运营 UINPM and ClawHub install 等 5 项npm/ClawHub 插件元数据、文档导航、插件引用、官方外部插件目录、插件分发的运营 UI 与文档行为。仓库证据方面docs/channels/googlechat.md 提供了该类别的完整操作手册安装openclaw plugins install openclaw/googlechat本地检出可用openclaw plugins install ./path/to/local/googlechat-pluginGoogle Cloud 侧五步创建 GCP 项目并启用 Google Chat API创建 Service Account名称如openclaw-chat权限留空创建并下载 JSON key建议存于~/.openclaw/googlechat-service-account.json在 Chat 配置页创建 Chat app启用 Interactive features、勾选 Join spaces and group conversations、选择 HTTP endpoint URL、触发器统一指向公网网关地址/googlechat、可见性限定到指定人员将 App status 设为 Live凭据注入环境变量GOOGLE_CHAT_SERVICE_ACCOUNT_FILE/path/to/service-account.json仅默认账户或配置项serviceAccountFile/serviceAccount内联 JSON 字符串、对象或 env/file/exec/store SecretRef多账户用channels.googlechat.accounts.idWebhook 暴露文档给出三种只暴露/googlechat路径的方案——Tailscale Funnel推荐tailscale funnel --bg --set-path /googlechat http://127.0.0.1:18789/googlechat、Caddy 反向代理、Cloudflare Tunnel ingress 规则状态与探测openclaw channels status、openclaw channels status --probe暴露鉴权错误与缺失的 audience 配置、openclaw logs --follow、openclaw doctor --fix405 排障按「channels.googlechat配置缺失 → 插件未启用plugins.entries.googlechat.enabled: true→ 配置变更后未重启网关openclaw gateway restart」三步定位可用openclaw config get channels.googlechat验证配置。源码侧插件实现位于 extensions/googlechat/配置模式见 config-schema.tsdoctor 契约见 doctor.ts 与 doctor-contract.ts凭据 SecretRef 契约见 secret-contract.ts 及其测试。4. 类别二Access and Identity细则范围为DM pairing approval、Sender allowlists、Google Chat identity matching、Direct session routing、Pairing diagnostics、Space allowlists、Mention gating、Sender access groups、Group session isolation、Bot-loop protection、Space diagnostics对应 taxonomy 中两组特性簇DM 侧Google Chat DM、dm.policy、dm.allowFrom、配对挑战pairing challenges及 DM 配对与发送者授权行为Space 侧Google Chat spaces 与群消息、groupPolicy、groups、通配群wildcard groups、space 路由提及与 session 隔离行为。渠道文档给出了可直接操作的默认行为DM 默认 pairing未知发送者收到配对码用openclaw pairing approve googlechat code批准dmPolicy省略时继承渠道根配置根默认为pairingSpace 默认 require-mention提及检测基于 ChatUSER_MENTION注解指向该 app 的判定如需按 app 的 user 资源名识别设置botUser如users/1234567890会话路由Space 获得每 space 独立会话agent:agentId:googlechat:group:spaceId回复进入消息线程DM 默认收敛到 agent 主会话可经session.dmScope改为按对端拆分见 docs/concepts/session.mdBot 消息默认忽略 bot 作者消息allowBots: true时接入共享 bot loop protection配置层级为channels.defaults.botLoopProtection→channels.googlechat.botLoopProtection→channels.googlechat.groups.space.botLoopProtection逐级覆盖。配置示例继承自渠道文档的 Config highlights{ channels: { googlechat: { enabled: true, serviceAccountFile: /path/to/service-account.json, // 或 serviceAccount: { source: file, provider: filemain, id: /channels/googlechat/serviceAccount } audienceType: app-url, audience: https://gateway.example.com/googlechat, appPrincipal: 123456789012345678901, // 仅 add-on 校验数字 OAuth client ID webhookPath: /googlechat, botUser: users/1234567890, // 可选帮助提及检测 allowBots: false, dmPolicy: pairing, allowFrom: [users/1234567890], groupPolicy: allowlist, groups: { spaces/AAAA: { enabled: true, requireMention: true, users: [users/1234567890], systemPrompt: Short answers only., }, }, typingIndicator: message, mediaMaxMb: 20, }, }, }注意群键必须是稳定 space idspaces/spaceId显示名键已弃用并会被记录警告dangerouslyAllowNameMatching是破坏玻璃break-glass兼容模式重新启用可变的邮箱 principal 匹配doctor 会对邮箱条目告警。配套文档引用包括 docs/channels/pairing.md、docs/channels/access-groups.md、docs/channels/channel-routing.md 与 docs/gateway/config-channels.md源码侧群策略判定见 group-policy.ts入口身份处理见 ingress-identity.ts 与 monitor-access.ts。5. 类别三与四Conversation Routing and Delivery、Media and Rich Content细则将这两个类别各列为单一伞形范围umbrella scopetaxonomy 中对应单一coverageIdsgoogle-chat.conversation-routing-and-delivery与google-chat.media-and-rich-content描述统一为「Evidence scope for ...」即该类别以整体证据判定而非逐项特性判定。路由与投递方面渠道文档与源码共同支撑的关键实现是「入站持久化队列」Google Chat POST JSON 到 webhook 路径仅 POST、要求 JSON 内容类型、按 IP 限流请求先鉴权Chat app 事件带Authorization: Bearer tokentoken 在解析完整 body 之前校验Workspace Add-on 事件的 token 位于 body 的authorizationEventObject.systemIdToken在更严格的预鉴权预算16 KB、3 秒内读取并先于校验token 与audienceTypeaudience匹配app-url对应 HTTPS webhook URLproject-number对应 Cloud 项目编号app-url下的 add-on token 还要求appPrincipal为 app 的 21 位数字 OAuth 2.0 client ID否则校验失败并记录警告鉴权通过后OpenClaw 从存储中移除 add-on 授权对象将 Google ChatMESSAGE事件持久化入队后再返回 200持久化失败返回 503让 Google Chat 重试而非确认一个可能丢失的事件。持久化成功的 200 携带x-openclaw-delivery-accepted: durable头非消息 action 的 ack 与错误响应不带该标记反向代理可据此区分「持久接受」与「普通 200」。待处理/可重试消息在网关重启后存活、按 space 串行化用消息资源名抑制重复入队队列到 agent 边界为 at-least-once 投递崩溃期间可能重放一轮。这部分实现的入口可见于 extensions/googlechat/src/monitor-durable.ts、monitor-webhook.ts、monitor-routing.ts、monitor-reply-delivery.ts 及其配套测试。媒体与富内容方面文档明确的边界是入站附件每条消息只下载第一个附件经 Chat API 进入媒体管线受mediaMaxMb限制默认 20 MBGoogle Drive 文件不下载agent 收到「不可用附件、请直接上传」提示多附件消息附带未处理附件的计数提示超限附件保留其尺寸限制提示出站媒体回复与上传受限于服务账号鉴权Google Chat 附件上传与 reaction 端点要求用户鉴权出站文件上传未暴露线程感知回复基于messageReplyOptionREPLY_MESSAGE_FALLBACK_TO_NEW_THREAD与文本分块chunking。相关文档引用含 docs/cli/message.md、docs/nodes/media-understanding.md。6. 类别五Native Controls and Approvals细则范围为 15 项特性Inbound attachments、Outbound media replies、Message upload action、Media source and size controls、Media receipts and thread placement、Text send action、Upload-file action、Reaction actions、Action capability gates、Approval sender matching、Thread-aware replies、Streaming and chunked replies、Typing placeholder lifecycle、Message-tool current-source replies、NO_REPLY cleanup、Markdown/text rendering前 5 项与 Media 类别共享同一组特性描述。taxonomy 将其归为三组附件/文件传输簇入站附件下载、媒体存储交接、出站媒体回复投递、upload-file及附件与文件传输行为消息工具动作簇Google Chat message tool 动作发现、send/upload-file/react及动作能力门控、reaction 与审批鉴权行为线程与回复生命周期簇入站线程资源传播、replyToMode、messageReplyOptionREPLY_MESSAGE_FALLBACK_TO_NEW_THREAD、文本分块、线程回复、流式与 typing 生命周期。该类别的源码证据最为密集目标与身份投递与白名单使用users/userId推荐、spaces/spaceId裸邮箱仅在dangerouslyAllowNameMatching: true时用于白名单匹配users/email形式的弃用写法按 user id 处理googlechat:/google-chat:/gchat:前缀被接受并剥离——实现见 targets.ts 及其测试消息工具动作消息动作仅暴露文本sendreaction 与出站上传因需要用户鉴权而未暴露openclaw doctor --fix会清理不支持的遗留 reaction 配置——见 message-tool-api.ts原生审批卡当 exec 或插件审批从 Google Chat 发起且配置了稳定的users/idapprover 时OpenClaw 在原 space 或线程中投递原生cardsV2审批卡按钮携带不透明回调 token仅在原生投递不可用时才出现手工/approve id decision提示。approver 来自allowFrom或defaultTo且必须是稳定数字users/id。实现分布于 approval-native.ts、approval-card-click.ts、approval-auth.ts 等文件及同名测试Typing 占位typingIndicator: message默认投递_Bot is typing..._占位并编辑进首条回复none禁用reaction需要用户 OAuth在服务账号鉴权下回退为message并记录错误。动作能力矩阵的可验证总结文本send可用upload-file出站、react、自定义 emoji 列表customEmojis.list需要用户鉴权插件仅以chat.botscope 的服务账号鉴权均不可用——这正是评分时该类别能力分支边界的直接依据。7. 当前已提交评分与 LTS 状态qa/maturity-scores.yaml 中google-chat的已提交聚合结果为Quality59AlphaCompleteness66AlphaLTSnone受支持类别 0/5五个类别均supported: false、human_override: false最近评分运行2026-08-02by: codexsource_ref: openclaw9bb7a3c8fd7a60284e2623f70e9f088ec74b3b36process_version: 3。这与 taxonomy 中「Documented channel, but enterprise/admin setup raises maturity risk」的定性一致渠道有文档、有完整插件实现与测试但企业/管理员侧设置GCP 项目、Chat app 配置、audience 绑定带来成熟度风险Completeness 落在 Alpha 段50–70。按 SKILL.md 的规则LTS 状态由 Quality、发布证据 Coverage 与human_lts_override派生不能通过手改生成文档改变主观评分变更应做最小可辩护编辑并在 PR 或任务摘要中保留证据路径。8. 使用与验证该细则的操作流程按 SKILL.md 的评分工作流为 google-chat 表面刷新评分的步骤是读取 taxonomy.yaml 中的google-chatsurface读取本细则 references/completeness/google-chat.md从文档、源码、测试与 QA 场景元数据收集公开仓库证据优先采用 release profile 的qa-evidence.json工件仅凭公开或脱敏工件证据更新 qa/maturity-scores.yaml 中的 Quality、Completeness 与 LTS 评审状态运行 schema 校验在仓库根目录执行node --import tsx --input-typemodule NODE import fs from node:fs; import YAML from yaml; import { readValidatedQaMaturityScoreSources } from ./extensions/qa-lab/src/scorecard-taxonomy.ts; for (const file of [taxonomy.yaml, qa/scenarios/index.yaml]) { YAML.parse(fs.readFileSync(file, utf8)); } readValidatedQaMaturityScoreSources(); NODE改动文档文字时运行pnpm check:docs改动 coverage ID 或 profile 成员时运行pnpm openclaw qa coverage --json做聚焦的 QA 覆盖检查。从源码结构看评分输出经 extensions/qa-lab/src/scorecard-taxonomy.ts 导出的qaMaturityScoresSchema与readValidatedQaMaturityScoreSources工具做校验再由渲染器产出 docs/maturity/scorecard.md 与 docs/maturity/taxonomy.md。9. 小结google-chat.md 细则 本身篇幅不长但它是 google-chat 表面 Completeness 打分的范围契约五类别、四组特性簇设置与运营 15 项、访问与身份 11 项、两个伞形类别、原生控制与审批 15 项与 taxonomy.yaml 的coverageIds严格对齐。结合 docs/channels/googlechat.md 的操作手册、extensions/googlechat/ 的鉴权/持久化队列/审批卡实现以及 qa/maturity-scores.yaml 中已提交的 Quality 59 / Completeness 66均 Alpha结果可以完整还原 OpenClaw「文档 源码证据 → 细则范围 → 分档评分 → 生成文档」的可复核评分链路。维护者在刷新该表面评分时只需沿 SKILL.md 的七步流程走即可在不引入私有证据的前提下保持记分卡的公开可验证性。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考