ha-mcp（homeassistant-ai/ha-mcp）：用 87 个工具把 Home Assistant 的配置层交给 AI 智能体

一、导读

智能家居的「最后一公里」从来不是设备连不上，而是配置写不完。一个成熟的 Home Assistant 实例动辄上千个实体、上百个集成：改一条自动化要翻 YAML、查实体 ID、读执行轨迹；而 Home Assistant 官方内置的 MCP Server 建立在 Assist 管线之上，只能读写「已暴露给 Assist」的实体，能开灯关灯，却改不了自动化、建不了仪表盘。

homeassistant-ai/ha-mcp 补的正是这一段。它把 87 个工具挂上 MCP，让 Claude、ChatGPT、Gemini CLI 乃至本地 Ollama 模型直接读写 Home Assistant 的配置层。截至 2026-11-10，仓库 6,577 星、当日涨星 792，一周内连发 v9.1.0、v9.1.1、v9.1.2 三个版本，v9.0.0 刚把「进程内服务器」确立为推荐安装方式。

本文拆解它的四层架构、三道安全闸门（只读模式、逐工具开关、策略审批队列）、搜索式工具发现与跨会话请求队列的取舍，并给出六类可复现场景与真实边界。

二、项目速览

维度	内容
仓库	`homeassistant-ai/ha-mcp`
作者/团队	@julienld（项目创建者与维护者）+ 社区贡献者
主语言	Python（仓库 2,698 个文件，核心源码 316 个 .py）
Star 总数	6,577（2026-11-10，GitHub API）
当日涨星	792（GitHub Trending daily，2026-11-10 抓取）
Fork / Watcher	427 / 23
License	MIT
首次创建	2025-09-14
最新版本	v9.1.2（2026-11-08）；v9.0.0（2026-10-28）为架构里程碑
工具数量	87 个（README 工具表，2026-11-10 读取）

说明：仓库同时维护 dev 通道，2026-11-10 当天发布了 v9.2.0.dev3457 至 dev3463 共 6 个开发构建，主线迭代节奏约为「每周一个正式版」。

三、为什么是它：问题背景与定位

痛点一：官方 MCP 只管「控制」，不管「配置」。 Home Assistant 自带 MCP Server 集成，走 Assist 管线：客户端能读、能控已暴露实体，也能触发 Assist 理解的意图。但它不提供对配置、自动化、仪表盘、实体注册表的直接访问。作者在 2025-10 的社区帖里说得很直白：他试过当时所有可用的 Home Assistant MCP server，「都不太适合和语言模型日常配合」。

痛点二：模糊搜索与工具描述是 LLM 体验的真正瓶颈。 作者点出的第一个缺口是「没有实体模糊搜索」——用户说「客厅那盏灯」，模型不该被要求给出精确的 entity_id。第二个缺口更微妙：他「优化了若干工具描述，去『推』LLM agent 在正确的时机用正确的工具」。这是把提示工程下沉到工具层：工具描述本身就是给模型的接口文档。

痛点三：从「周末项目」长成 87 个工具的产品。 作者自陈这是「周末项目」，不愿投入 Core 开发的学习曲线，因此坚持独立仓库、MIT 许可，并明确「如果 native 成熟了，计划让两者协作：native 托管基础稳定工具，我的专注边缘与高级工具」。这个定位解释了它为什么能覆盖到备份、HACS、设备注册表、Z-Wave 参数读取这些官方 MCP 不会碰的角落。

涨星动因：v9.0.0（2026-10-28）把「进程内服务器」做成推荐路径——服务器直接跑在 Home Assistant 进程里，通过 Home Assistant 自己的 webhook 暴露，不需要额外容器、不需要端口转发，还能顺带把工具集注册成 Home Assistant 的 LLM API 供语音助手使用。安装门槛从「配 Docker + 管 token」降到「在 HACS 里点安装」，这是本轮涨星的直接推手。

四、架构原理

4.1 整体架构

ha-mcp 是一个 FastMCP 服务器（src/ha_mcp/_vendor/fastmcp 内置了一份 vendor 副本），向下用 REST + WebSocket 双通道访问 Home Assistant，向上用 stdio 或 streamable HTTP 对接 MCP 客户端：

┌──────────────── MCP 客户端 ────────────────┐
│ claude.ai · Claude Code · ChatGPT ·        │
│ Gemini CLI · Cursor · Ollama · HA 语音助手 │
└───────────────┬────────────────────────────┘
                │ stdio / streamable HTTP
                │ （每 URL 固定一种工具目录）
┌───────────────▼──────────────────────────────────────┐
│              ha-mcp 服务器（FastMCP）                 │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────┐  │
│  │ 工具目录层    │  │ 中间件层      │  │ 策略层      │  │
│  │ full / search│  │ 只读 · 队列   │  │ 谓词+审批   │  │
│  └──────┬───────┘  └──────┬───────┘  └─────┬──────┘  │
│         └────────┬────────┴────────┬───────┘         │
│           ┌──────▼──────┐   ┌──────▼──────┐          │
│           │ REST client │   │ WS client   │          │
│           │ 113 KB      │   │ 72 KB       │          │
│           └──────┬──────┘   └──────┬──────┘          │
└──────────────────┼─────────────────┼─────────────────┘
                   │ /api/*          │ /api/websocket
              ┌────▼─────────────────▼────┐
              │      Home Assistant       │
              │  Core · Supervisor · 注册表│
              └───────────────────────────┘

关键点在于双通道分工：REST 负责状态、服务调用、历史；WebSocket 负责 REST 拿不到的配置注册表（实体注册表、设备、区域、标签、Energy 偏好）。这不是可选优化——docs/registry-label-concurrency.md 专门讨论注册表写入的并发问题，说明作者把「注册表是另一套 API 面」当成了架构事实。

4.2 分层模块拆解

传输层：支持 stdio、streamable HTTP、以及 v9.0.0 起的「进程内」模式。进程内模式跑在 Home Assistant 自己的线程上（docs/in-process-server.md 明确写「服务器跑在自己的线程上，慢的工具调用永远不会卡住 Home Assistant 的事件循环」），通过 webhook 暴露；默认端口 9584，与 add-on 的 9583 错开，避免同机冲突。

工具目录层：tool_catalog.py 定义了一个反直觉的设计——工具目录按 URL 固定，而不是按请求协商。理由写在模块 docstring 里：「客户端不会在工具列表变化时刷新它，客户端是靠被给的 URL 来选目录的。」于是同一个实例可以同时服务多种客户端：<path> 跟随 ENABLE_TOOL_SEARCH，<path>/catalog/full 永远给全量目录，<path>/catalog/search 永远给搜索工具，两者都可再跟 /readonly。

中间件层：只读、请求队列、重命名工具、LLM 暴露标记都在这一层。ha_request_queue.py 的 HomeAssistantRequestQueueMiddleware 用信号量限制并发的外层工具调用（取值 1–32，默认 1），等待上限 60 秒、每 15 秒发一次进度心跳；而调用代理（ha_call_read_tool 等）、本地搜索、编排器与审批管理动作绕过外层队列——否则「批准一个被阻塞的请求」这个动作本身会排在同一个被阻塞的工作负载后面，形成死锁。这段注释是整份代码里最能说明「agent 系统为什么难」的地方。

策略层：policy/ 目录约 11 个模块，model.py 定义谓词与规则，approval_queue.py 实现审批队列，middleware.py（35 KB）做拦截。

4.3 核心机制

机制一：搜索式工具发现。 87 个工具的完整 schema 对上下文是笔重账。开启 ENABLE_TOOL_SEARCH=true 后，目录被替换成四个入口加一小撮常驻工具：

工具	作用
`ha_search_tools`	对全部工具做 BM25 英文关键词搜索，返回「名字 + 一行描述 + 一行参数 + 可达代理」
`ha_call_read_tool`	按名执行只读工具（客户端可自动放行）
`ha_call_write_tool`	执行创建/更新类工具
`ha_call_delete_tool`	执行删除类工具

这个「代理三分」不是装饰：它让客户端不解析工具 docstring 就能按类别套用不同权限策略——读自动放行、写弹窗、删二次确认。TOOL_SEARCH_MAX_RESULTS 默认 5（范围 2–10）。README 同时给出反面建议：在 claude.ai、Claude Desktop、Claude Code 这类自带延迟工具加载的客户端里不要开，因为全量目录在那里没有闲置成本。

机制二：只读模式的双重拦截。 read_only.py 的注释把设计讲得很清楚：ReadOnlyToolsTransform 在列表时隐藏写工具，ReadOnlyMiddleware 在调用时再拦一次，返回结构化的 READ_ONLY_MODE 错误。判定用 fail-closed 默认：readOnlyHint 不等于 True 就算写工具。混合读写工具（读面在别处没有纯读副本）走豁免名单，每条带一个参数级谓词，逐次调用判定是读还是写。还有一个细节值得记：错误提示故意不提 /readonly 端点后缀，理由是「不希望一个不可信的模型说服用户去关掉它」。

机制三：策略与审批队列。 策略文件 tool_policy.json 由谓词组成，支持 eq / neq / in / not_in / regex / contains / exists / gt / lt 八种操作；规则效果二选一——require_approval（默认，命中则拦、未命中则放行）或 allow（命中则放行、未命中则拦）。schema 版本 2 引入了 ANY-match 语义：每条 UI 条件各自成规则，规则内谓词 AND。审批队列是进程内内存队列，用 sha256(json.dumps(args, sort_keys=True)) 做参数哈希绑定，支持 remember_minutes 记住决策。最精巧的是 claim()：decide() 会唤醒所有等待者，若不加约束，「一次点击会授权 N 次执行」（issue #2387），因此用一次性 check-and-set 保证恰好一个调用者能消费一个决策。

机制四：技能以 MCP 资源形式内置。 服务器把 homeassistant-ai/skills 的最佳实践技能作为 MCP resource 通过 skill:// URI 暴露；对只支持工具的客户端（claude.ai 等），走 ha_get_skill_guide 工具读取。这个工具被标记为强制存在（不可禁用），理由是「工具型客户端不该看到一个静默消失的技能面」。资源不自动注入上下文，闲置成本只有元数据。

4.4 性能优化与设计取舍

懒加载：server.py 开头写明「设置与 FastMCP 服务器立即创建（快），smart tools 与 device tools 首次访问时懒创建，工具模块启动时发现、首次使用时导入」。
字段投影：六个读密集型工具支持 fields= / attribute_keys= 投影，减少返回体积（贡献者 @SealKan，PR #1225）。
长任务进度：通过 FastMCP 的 Context 发进度（PR #1124），避免客户端误判超时。
取舍：把「目录按 URL 固定」换来多客户端共存，代价是同一 URL 不能动态切换目录；把「审批队列放进程内」换来零依赖，代价是多实例不共享审批状态；把「工具数做到 87」换来覆盖面，代价是小模型必须开搜索模式，否则上下文被 schema 淹没。

为什么并发默认是 1？ ha_request_queue.py 把 max_concurrency 默认设为 1，并在构造时校验取值范围 1–32（0 表示不注册中间件）。这不是保守，而是对 Home Assistant 的尊重：它的状态机与注册表写入并非为高并发设计，docs/registry-label-concurrency.md 专门记录了注册表与标签并发写入的坑。代价是多个客户端共用一个实例时会排队，因此等待超时被设成 60 秒并配 15 秒心跳——超时返回的是结构化错误，而不是静默失败。

编辑前自动备份。 backup_manager.py 有 150 KB，配套还有 backup_entities、backup_dashboards、backup_calendar、backup_todo、backup_zones、backup_integrations 等十余个模块。README 描述了它的严格语义：模板 helper 的编辑备份会捕获持久化选项；恢复一个已存在的 helper 需要一份新的安全备份、会移除快照里没有的可选设置、并校验持久化选项；「捕获拒绝降级的密钥擦洗」——也就是说，如果密钥擦洗机制处于降级状态，备份会直接拒绝执行，而不是存一份带密钥的快照。这个细节说明作者把「备份文件本身不能成为泄露源」当成了硬约束。

4.5 与其他架构路线的差异

三条路线的分野在于「谁定义工具面」：官方内置 MCP Server 由 Assist 管线定义（实体已暴露 + 意图），覆盖面窄但零维护；ha-mcp 由社区按「配置与调试」的需要定义，覆盖面宽但要自己承担安全边界；自建 REST 脚本则连工具描述都要自己写。ha-mcp 的独特之处是把安全边界也做成了产品——只读模式、逐工具开关、策略审批、编辑前自动备份四件套，这在 MCP server 里并不常见。

五、应用场景

场景一：用自然语言建自动化（核心场景）

痛点：一条「日落开玄关灯、有人回家才开、否则不开」的自动化，要选触发器、写条件、挑动作、处理 mode，YAML 写错还不报错，只在运行时不生效。

解决：ha_config_set_automation 直接读写自动化配置，服务器跑在 Home Assistant 自己的校验与存储路径上（v9.1.0 变更：「Run the automation tools on Home Assistant's own validation and storage」），写进去的就是 Core 认的配置。

# 以进程内服务器为例，先在 HACS/Marketplace 装 HA-MCP 集成
# Settings → Devices & Services → Add Integration → HA-MCP → HA-MCP Server
# 复制 Configure 页的 webhook URL，粘进客户端

然后直接说：「建一条自动化，日落时开玄关灯，但如果家里没人就不开。」模型会自己找实体、拼触发器与条件。

收益：第三方实测（Yahoo Tech 记者，2026-11）在 1,700+ 实体、118 个集成的实例上，用自然语言建的自动化「全部按预期工作，YAML 里看不出明显问题」；建仪表盘「几分钟就做出比自己手搓更好的效果」。

边界：模型会犯错。同一篇实测里，作者让 Claude 建世界杯赛程仪表盘，模型开始加入并不存在的国家，最后仍需人工修正。复杂构建建议先让模型输出计划再执行。

场景二：把「体检」交给 agent

痛点：Home Assistant 实例跑久了会积累问题——备份悄悄停了、集成挂了、有几百个没人用的实体。

解决：ha_get_overview + ha_deep_search + ha_get_system_health + ha_get_logs 组合，让模型先做一次全量扫描。

# 客户端里直接说：
# "扫一遍我的系统，找出明显的问题"

收益：同一篇实测中，Claude 扫完 1,700+ 实体与 118 个集成后，发现自动备份已经停了两周——原因是 Proxmox 上 Home Assistant 虚拟机接近存储上限。作者说这是他「完全漏掉、且很可能导致丢失两周成果」的问题。随后它还被用来清理无用实体、集成与自动化。

边界：这类操作需要管理员 token；删实体属于破坏性动作，务必先开只读模式做扫描，再逐条放行删除。

场景三：给语音助手装上「会配置」的手

痛点：Home Assistant 的 Assist 语音管线只能控已暴露实体，说「帮我建个自动化」它做不到。

解决：进程内服务器会把工具集注册成一个名为条目名的 Home Assistant LLM API。任何会话代理（OpenAI、Google、Anthropic、Ollama）都能在「Control Home Assistant」里选它。

1. 添加会话代理集成（全本地可用 Ollama）
2. 在该代理设置里，Control Home Assistant 选 "HA-MCP Server (tool search)"
3. 从 Assist 对话框、手机 App 或语音卫星说话

收益：三种暴露模式可选——Tool search（默认，上下文小，适合本地小模型）、Full catalog（工具选择更准，提示成本约 10 倍）、Both。逐工具可见性在侧栏 HA-MCP 面板里管，对 beta 工具、开发者工具、重启/重载/备份族默认拒绝。

边界（官方明确警告）：工具集以服务器的管理员权限运行，把它挂到某个代理上，就等于把这份权力交给所有能和该代理说话的人，包括语音卫星旁边能听见的人。不要挂到不该挂的管线上。

场景四：给「危险动作」加一道人工闸门

痛点：让 agent 管 Home Assistant，最怕它半夜把门锁开了、把配置删了。

解决：ha_manage_security_policy 写策略规则，命中即进审批队列。

// tool_policy.json 概念示例（谓词 + 规则效果）
{
  "rule_effect": "require_approval",
  "rules": [
    { "tool_name": "ha_call_service",
      "when": [{ "path": "domain", "op": "in", "value": ["lock"] }],
      "remember_minutes": 0 }
  ]
}

收益：审批在 Home Assistant 侧栏的 HA-MCP 面板里点，参数哈希绑定保证「批准的就是那一次调用」；一次性 claim() 保证一次点击只授权一次执行。加上「编辑前自动备份」（backup_manager.py 达 150 KB），误改可回滚。

边界：审批队列是进程内内存队列，重启即丢；多实例不共享审批状态。策略 schema 版本 2 的 ANY-match 语义与旧版不同，升级时会有一次自动迁移。

场景五：让本地小模型也能用

痛点：Ollama 上的小模型上下文窗口小，87 个工具的 schema 一塞就懵。

解决：开 ENABLE_TOOL_SEARCH=true，目录缩到约 10 个工具；同时把本地运行时的上下文窗口调高（README 点名 Ollama 的 num_ctx 默认值太小）。

# add-on / 进程内服务器：在设置面板打开 tool search
# 或环境变量
ENABLE_TOOL_SEARCH=true
TOOL_SEARCH_MAX_RESULTS=5

收益：闲置 token 大幅下降，小模型不再「看不见工具」。README 还点名 GitHub Copilot CLI 这类「无论什么模型都把全部 schema 内联」的客户端同样受益。

边界：搜索模式多一跳（先搜再调），对自带延迟工具加载的客户端是净损失。

场景六：批量整理实体与注册表

痛点：实例用久了会攒下几百个失效实体、重复的区域、没人用的标签，手动清理要在注册表里翻很久。

解决：ha_get_entity / ha_set_entity / ha_remove_entity 与 ha_get_device / ha_set_device 走 WebSocket 注册表通道（REST 拿不到这些数据），配合 ha_config_list_helpers 与 ha_remove_helpers_integrations 做批量清理。

收益：第三方实测里，Claude 在获得授权后一次性清掉了作者不再需要的实体、集成与自动化。区域解析还支持通过父设备归属来推断实体区域（贡献者 @knowald 提交）。

边界：注册表写入是并发敏感的（见 docs/registry-label-concurrency.md），批量操作建议串行；删除实体不可逆，务必先有备份。

适用边界与不建议使用的场景

不要把它当语音控制方案：只想「开灯关灯」，用官方内置 MCP Server 更省事、更安全。
不要暴露到公网而不加认证：none 模式下 webhook URL 就是凭据；公网暴露应选 ha_auth（仅接受管理员账号）。
不要跳过只读模式做首次扫描：先只读、再放行，是成本最低的保险。
不要同时装两种运行方式：README 明确警告，同一客户端里同时配 stdio 与 HTTP 条目是「连接挂起」的已知原因。
stdio 有已知传输问题（issue #1713），官方建议只用于演示。

六、快速上手

# 路径 A（推荐）：进程内服务器
# 1) HACS 或 HA 2026.11+ 的 Marketplace 安装 "HA-MCP"
# 2) 重启 Home Assistant
# 3) Settings → Devices & Services → Add Integration → HA-MCP → HA-MCP Server
#    填入管理员 token（或专为 HA-MCP 建的账号），选择远程/局域网访问方式
# 4) 从 Configure 页复制 webhook URL，粘进 MCP 客户端

# 路径 B：Docker HTTP 服务器
docker run -p 9583:9583 \
  -e HOMEASSISTANT_URL=http://homeassistant.local:8123 \
  -e HOMEASSISTANT_TOKEN=YOUR_LONG_LIVED_TOKEN \
  ghcr.io/homeassistant-ai/ha-mcp

# 路径 C：PyPI / uvx
uvx ha-mcp@latest

# 路径 D：先试再买（连官方 demo 环境，无需自己的 HA）
curl -LsSf https://raw.githubusercontent.com/homeassistant-ai/ha-mcp/master/scripts/install-macos.sh | sh

demo 环境：URL https://ha-mcp-demo-server.qc-h.net，token demo，每周重置。

七、横向对比

维度	ha-mcp	HA 内置 MCP Server	voska/hass-mcp	自建 REST 脚本
工具数	87	约 10（Assist 意图面）	约 15	取决于你
实体范围	全实例	仅暴露给 Assist 的	全实例	全实例
建/改自动化、脚本、场景	是	否	否	需自己写
仪表盘读写	是	否	否	需自己写
执行轨迹/历史/日志	是	否	部分	需自己写
备份、HACS、注册表	是	否	否	否
只读模式	有（列表+调用双重拦截）	无	无	自己实现
策略审批队列	有（谓词 DSL + 参数哈希绑定）	无	无	自己实现
进程内运行	有（v9.0.0+，推荐）	是（本身就是 Core）	否	否
语音助手集成	有（注册为 HA LLM API）	有（Assist 原生）	否	否
维护活跃度	每周正式版 + 每日 dev	随 Core	低	—
License	MIT	Apache-2.0（Core）	MIT	—

四维小结：能力上 ha-mcp 覆盖面最广，但「广」也意味着攻击面大；性能上懒加载 + 字段投影 + 搜索模式三招压上下文，代价是多一跳；生态上它同时支持 15+ 客户端并内置技能资源，是最像「产品」的一个；成本上 MIT 免费，真正的成本是你必须自己决定放行多少权限。

八、局限、风险与社区观察

维护活跃度（正面信号）：2025-09-14 创建，pushed_at 为 2026-11-10，一周内三个正式版（v9.1.0 → v9.1.2），当天另有 6 个 dev 构建。贡献者名单里能看到大量社区 PR（字段投影、事件工具、时区修复、KNX 项目读取等），说明它已从「周末项目」进入社区协作阶段。

License 风险：MIT，商用友好。但注意它 vendor 了一份 FastMCP 副本（src/ha_mcp/_vendor/fastmcp），上游许可与更新节奏需自行跟进。

生产可用性风险：

权限即攻击面：服务器以管理员 token 运行，能删实体、改配置、重启 Home Assistant。README 与文档反复强调「HTTP 模式会把完整控制权暴露到网络上」，并明确要求放在反向代理、VPN 或仅本机绑定之后。
提示注入是独立战场：工具集一旦挂到语音代理上，任何能对代理说话的人都能间接驱动它。官方文档直接写「把它挂到某个代理上，就等于把这份权力交给所有能和该代理说话的人」。
审批队列不跨进程：内存队列、重启即丢、多实例不共享，高可用部署需自行设计。
stdio 传输有已知问题（issue #1713），官方建议只用于演示。
版本节奏快：一周三个正式版意味着接口与工具名会变（v7.3.0 就把 ha_config_set_yaml 移进 beta），生产使用建议锁版本。
模型会犯错：第三方实测中出现了「加入不存在的国家」这类幻觉，破坏性操作必须有人工闸门。

社区观察：讨论集中在两点。一是「社区 MCP vs 官方 MCP」的分工——作者自己的路线图是「native 托管基础稳定工具，我的专注边缘与高级工具」，这个分工在社区里被普遍接受。二是「给 AI 开放智能家居的隐私代价」——第三方实测作者坦言「隐私是 Home Assistant 的核心，把大量家庭信息暴露给 AI 公司远谈不上私密」，他之所以敢试，只是因为本来就打算重建整个实例。这个顾虑不会因为工具变好而消失。

九、小结与行动建议

先只读跑一周：装上后立刻开只读模式，让 agent 先做扫描与体检，确认它「看得懂你的家」再逐步放行写权限。
按客户端选安装方式：Home Assistant OS/Supervised 用进程内服务器或 add-on；Container/Core 用进程内服务器（这是它存在的意义）；只想试水就用 demo 环境。
按模型选工具目录：claude.ai / Claude Code 保持全量目录；Ollama 等小模型开 ENABLE_TOOL_SEARCH 并把 num_ctx 调高。
给危险动作写策略：把锁、门、报警、删除类动作写成 require_approval 规则，remember_minutes 保持 0，让每次执行都要人点一下。
别把它接到语音卫星上：除非你接受「旁边能听见的人也能改你的家」。语音场景优先用官方 Assist。

数据来源与获取日期：GitHub API /repos/homeassistant-ai/ha-mcp、/releases、/git/trees/master?recursive=1（2026-11-10）；GitHub Trending daily 榜（2026-11-10 抓取）；仓库一手文件读取（README.md、CHANGELOG.md、docs/in-process-server.md、docs/FAQ.md、src/ha_mcp/tool_catalog.py、src/ha_mcp/tool_dispatch.py、src/ha_mcp/ha_request_queue.py、src/ha_mcp/read_only.py、src/ha_mcp/policy/model.py、src/ha_mcp/policy/approval_queue.py、src/ha_mcp/llm_exposure.py、src/ha_mcp/server.py，2026-11-10 读取）；Home Assistant 社区论坛帖《Brand New Claude.ai & ChatGPT integration (ha-mcp)》（作者 jld，2025-10-07）；Yahoo Tech《Letting Claude take control of Home Assistant sounded amazing—but it was far from perfect》（2026-11）；PyPI / Docker Hub / Glama / BenchGecko 等第三方目录页。文中标注「第三方实测」「官方口径」处为非一手数据，请谨慎引用。