goplaces 让 OpenClaw 通过独立 CLI 查询 Google Places。第一次可以做一个明确的小任务：确认一个完整地址，再查询相关地点并读懂返回的 JSON。下面以已有 Homebrew 的 macOS 或 Linux 为例；实际执行环境需要能访问 Google API，并有已启用结算和 Places API (New) 的 Google Cloud 项目及 API key。
先确认 Skill 与命令运行在哪
在运行目标 OpenClaw Agent 的主机上打开终端，把 YOUR_AGENT_ID 换成实际 Agent ID：
openclaw skills info goplaces --agent YOUR_AGENT_ID
openclaw skills check --agent YOUR_AGENT_ID
这两个检查读取所选 Gateway 的 Skill 库存。确认 goplaces 是否存在、是否可见，以及缺的是二进制还是环境变量；如果配置了远程 Gateway，检查结果属于那台 Gateway。本机有命令不代表远程 Agent 也有。
只有目标 Agent 确实缺少这份 Skill，才在其工作区所在主机安装 ClawHub 的 v1.0.0：
openclaw skills install @steipete/goplaces --version 1.0.0 --agent YOUR_AGENT_ID
已有内置版时直接补依赖。Skill 是使用说明，独立的 goplaces CLI 和 Google API key 还需要分别准备。
准备 CLI 和 API key
当前官方仓库已迁到 openclaw/goplaces，Homebrew 采用 Formula。按当前 README 安装：
brew install openclaw/tap/goplaces
goplaces --version
若已安装旧 Cask，先按当前 README 的迁移说明处理。以下参数和 JSON 按 CLI v0.4.11 说明；它与 ClawHub Skill 的 v1.0.0 是两个版本号。仓库主分支中的后续修复不能代替本机发行版检查。
在 Google Cloud 中选择自己的项目，启用结算和 Places API (New)，创建并限制 API key 的 API 范围，再按用途设置配额。首次地点查询不需要 Routes API；只有后续使用 route 或 directions 才需另外启用。
为当前终端配置密钥，用自己的值替换占位符：
export GOOGLE_PLACES_API_KEY="YOUR_API_KEY"
让 OpenClaw 调用时，还需把同一变量提供给真正执行命令的环境。例如可在 Gateway 的私有 openclaw.json 中，把以下片段合并到已有配置：
{
skills: {
entries: {
goplaces: {
env: { GOOGLE_PLACES_API_KEY: "YOUR_API_KEY" }
}
}
}
}
不要把密钥发到聊天里。另一终端中的 export 不会自动改变已运行 Gateway 的环境。skills.entries 的注入作用于宿主 Agent；沙盒还必须单独具备 CLI、密钥和网络访问。补依赖后重新检查，并在新会话里调用。
查询按所请求的字段计费，--limit 5 不是免费额度。此版搜索会请求评分、营业时间等字段；费用不能只根据返回五条结果估算。只读任务限定的是这一轮操作范围；密钥实际权限仍由 Google Cloud 的限制设置决定。
先确定地址，再选择查询方式
把下面的地址占位符换成完整地址，保留城市和国家，避免同名街道或地区：
goplaces resolve "YOUR_FULL_ADDRESS, CITY, COUNTRY" --limit 3 --json
resolve --json 返回候选数组。比较每项的 name、address 与 location.lat / location.lng，确认所选候选确实在目标城市；有多个可能地址时先选择，不能直接把第一项当成已确认位置。
如果只是按名称或类别查相关地点，可以这样查询：
goplaces search "cafe near YOUR_FULL_ADDRESS, CITY, COUNTRY" --limit 5 --json
需要偏向一组已确认坐标时，可给 search 同时提供 --lat、--lng、--radius-m。它们是位置偏好（locationBias），允许返回圈外结果；若查询文字指定另一个城市，Google 还可能忽略这个偏好。没有提供位置时，服务器 IP 也可能影响结果。
若任务要求“只找指定坐标 1.5 公里内的咖啡店”，使用 CLI 的 nearby。将 LAT_FROM_RESOLVE、LNG_FROM_RESOLVE 换成刚确认的数值：
goplaces nearby --lat LAT_FROM_RESOLVE --lng LNG_FROM_RESOLVE --radius-m 1500 --type cafe --limit 5 --json
nearby 发送的是位置范围限制（locationRestriction）。它没有 search 的 --open-now 或 --min-rating 参数；要判断开放状态和评分，读返回字段，必要时查询详情。
读懂 JSON，完成首次查询
search 和 nearby 返回含 results 的对象，字段使用 CLI 的命名，并非 Google 原始响应里的 places / id。检查这些字段：
| 字段 | 怎样判断 |
|---|---|
place_id | 作为下一步详情查询的 ID，保留原值。 |
name、address、location | 核对地点、城市和坐标是否符合任务。 |
rating、user_rating_count | 一起看评分和评价数量；缺失时保留未知。 |
open_now | true / false 是返回的开放状态；字段缺失不能解释为已关闭。 |
business_status | 与开放状态分开看；只在 Google 返回时出现。 |
next_page_token | 文字搜索存在后续页的线索，不是全城地点总数。 |
需要进一步核对一个地点时，把占位符换成刚返回的 place_id：
goplaces details "PLACE_ID_FROM_RESULTS" --json
这次返回的是单个地点对象，可检查 hours、phone、website 等实际提供的字段。只有需要评论或照片时再添加 --reviews、--photos；缺字段不由模型补齐。
对于文字搜索，可以用同一查询和返回的 next_page_token 继续一页：
goplaces search "cafe near YOUR_FULL_ADDRESS, CITY, COUNTRY" --limit 5 --page-token "TOKEN_FROM_PREVIOUS_SEARCH" --json
翻页时保持上一请求的查询文字、位置和筛选参数一致；如上一页使用了 --lat、--lng、--radius-m、--type 等，下一页也带上相同参数。上面的示例查询没有这些额外参数。
每次请求都可能产生 API 使用量。五条候选、分页结束或空 results 都不能证明已经覆盖当地所有商家。首次任务完成的标志是：确认了正确地址，能读出符合查询的候选，且明确哪些状态未知、位置是偏好还是硬范围。
再交给 OpenClaw
终端查询有可核对的结果后，在 OpenClaw 中可以这样输入；先替换地址和范围：
请使用 goplaces Skill，查询地址 [完整地址、城市、国家] 附近的咖啡店。
先确认地址候选，地址有歧义时让我选择。
这一轮最多做一次 resolve 和一次地点查询，返回最多五条候选。
我的范围要求是 [偏向附近 / 必须在已确认坐标1500米内]；硬范围请使用 CLI nearby。
列出 place_id、名称、地址、坐标、评分及评价数、open_now、business_status。
缺失字段保留未知，并注明结果来自 Google Maps。
先展示候选；需要详情或下一页时，说明要增加的查询再继续。
不要预订、联系商家或把这份结果称为当地完整名单。
若 Agent 与终端结果不一致，先核对其实际命令、查询文字、坐标和执行环境。command not found 要检查那个环境的 PATH；缺密钥要检查 Gateway 或沙盒配置；API 权限、配额或网络报错按原始诊断处理，不改写成“附近没有地点”。v0.4.11 之后已有针对响应验证和 CLI 输出的主分支修复；不要仅凭正常退出就下完整性结论，也不要把 --limit 0 当作不发送查询。
需要把结果用于网页、地图、长期存储或公开再利用时，再按 Google Places 的展示、署名与存储要求设计；JSON 输出本身不取消这些要求。