OpenClaw - Day 4 从“会聊天”到“能办事”：用 OpenClaw 给 AI 接上网络能力的完整实践
文章目录
- 一、为什么“网络能力”是从玩具到工具的分水岭？
- 二、OpenClaw 的 Skills 体系：给助手“装应用”
- 三、连接 Gmail：把“新邮件提醒”交给 AI 助手
- 四、连接 Google Calendar：用自然语言操作日程
- 五、接入 Web Search：打破模型知识的时间墙
- 六、接入浏览器：让 AI 像真实用户一样“看网页”
- 七、安全：当 AI 能“碰到你的真实数据”时，必须先想清楚的事
- 八、实践建议
- 九、下一步：解锁更大的技能生态
一个只会聊天的 AI，和一个能帮你读邮件、管日历、上网搜信息的 AI，中间差的不是模型智商，而是一整套“触达现实世界的手”。
一、为什么“网络能力”是从玩具到工具的分水岭？
前三天，我们给助手装上了灵魂（SOUL）、设定了性格，建立了和你的关系，但交互本质还是“问答型聊天机器人”。
没有网络能力时，AI 助手有几个明显限制：
- 只能基于上下文和模型内知识回答，无法触达你的真实数据（邮件、日历、网盘）。
- 无法主动帮你完成任务，只能输出“建议”和“步骤”。
- 对世界的认知停留在训练截断时间，连“这周发生了什么事”都答不全。
而当你为它接上四类能力——邮件、日历、搜索、浏览器——局面瞬间改变：
- “帮我看看今天有什么邮件？”→ 真去你的 Gmail 拉取并归类，突出那一两封真正重要的。
- “明天下午有空吗？”→ 查你 Calendar，给出具体时间段，还能做冲突检测。
- “最近 React 19 有什么变化？”→ 联网搜索，多源阅读后给你总结和判断，而不是一堆链接。
- “帮我看下这个竞品的定价页有没有改价格。”→ 打开网址，解析页面结构，对比你之前的记录。
本质上，你是在给一个具备大脑（LLM）的系统，安装上操作外部世界的“手脚”（Skills）。
二、OpenClaw 的 Skills 体系：给助手“装应用”
在 OpenClaw 中，所有外部能力都是通过 Skills（技能） 提供的。你可以把它理解成“给 AI 装插件”或者“给助手手机装 App”。
四个核心技能：
| 技能 | 提供的能力 | 典型使用场景 |
|---|---|---|
| Gmail | 读取、搜索、摘要、（可选）发送邮件 | “今天有什么重要邮件？” |
| Google Calendar | 查询、创建、修改日程 | “帮我下周三下午 3 点约个会。” |
| Web Search | 联网搜索和结果整合 | “OpenClaw 的替代方案有哪些？” |
| Browser | 访问与操作网页（Playwright） | “帮我看看这个网页说了什么 / 截个图。” |
这些技能有几个共性设计要点：
- 统一的配置与调用方式，让 LLM 可以通过结构化工具调用来驱动它们。
- 明确的能力边界，比如 Gmail Skill 会区分“读取邮件”和“发送邮件”的权限。
- 能在对话上下文中暴露可用技能，让模型自己选择何时调用。
其中最值得强调的是 gog ——一个整合了 Gmail、Google Calendar、Google Drive 的 Google Workspace 技能包，你只需要配置一套 OAuth 授权，就能一次性连通多种 Google 服务。
三、连接 Gmail：把“新邮件提醒”交给 AI 助手
邮件是大多数知识工作者的核心信息流入口，也是最容易被信息噪音淹没的地方。OpenClaw 在第 4 天选择从 Gmail 入手，并不是巧合。
3.1 准备 Google Cloud 项目与 API
要让 AI 读你的 Gmail，首先需要在 Google Cloud 上创建一个项目并启用相关 API：
- 打开
console.cloud.google.com，新建一个项目（名称随意，如 “My AI Assistant”）。 - 在“API 和服务 → 库”中搜索并启用：
- Gmail API
- Google Calendar API（为后面日历功能做准备）。
这一步确保你后续生成的 OAuth 凭证具备访问邮件与日历的能力。
3.2 创建 OAuth 客户端并生成 credentials
接下来在同一项目下创建 OAuth 客户端：
- 进入“API 和服务 → 凭证”。
- 点击“创建凭证 → OAuth 客户端 ID”。
- 应用类型选择“桌面应用”。
- 下载生成的 JSON，重命名为
credentials.json。 - 将文件放到 OpenClaw 工作目录，例如
~/clawd/credentials.json（可以直接让助手帮你移动）。
这个 credentials.json 是“拿去换 token 的身份证”，真正的长效访问凭据会写入稍后的 token.json。
3.3 安装 gog 技能：Google Workspace 一键打包
OpenClaw 的技能安装方式非常直接，教程里给出的命令是：
clawdhub install gog gog Skill 下挂载了 Gmail、Google Calendar、Google Drive 等子能力，属于一站式 Google Workspace 适配层。
首次运行时，它会引导你通过浏览器完成 OAuth 授权流程，并生成 token.json——即包含刷新 Token 等信息的长期凭证文件。这个文件一旦生成，助手之后就可以静默代表你访问 Gmail/Calendar，而无需你再手动登录。
3.4 从“列清单”到“帮你决策”的邮件体验
配置完成后，你可以在 Telegram 中直接跟助手说：
帮我看看 Gmail 今天有什么新邮件。
一个理想的返回示例（教程中给出的片段）：
📧 今天共 5 封新邮件：[重要] 合作方回复 —— 关于下周会议时间确认，需要你回复GitHub —— Your repository has been starredHetzner —— Invoice for JulyNewsletter —— This Week in AI广告 —— 已自动忽略。
注意这里的三个关键点：
- AI 帮你做了“重要 / 次要 / 噪音”的初筛。
- 找出“需要你真正行动”的那一封，并加粗标记。
- 对于 Newsletter、广告等噪声流量自动归类，避免打扰。
一个有趣的实践：助手每天固定时间（例如早上 8 点）自动拉取邮件，整理出一份“你真的需要看的摘要”，剩下的全部降权处理。你得到的是“决策前摘要”，而不是“原始信息流”。
四、连接 Google Calendar：用自然语言操作日程
在完成 Gmail 配置后，你会发现 Google Calendar 的接入基本是“零额外成本”：因为同一个 gog 技能和 OAuth 授权已经具备访问 Calendar 的权限，只要你在一开始启用了 Calendar API。
4.1 无需额外配置：直接可用
安装 gog 并授权 Google 账号后，Calendar 功能“直接就能用”，不需要再次生成凭证或改配置文件。你只需要开始跟它对话即可。
比如最基础的一句：
明天有什么安排？
助手给出的结构化回答可能是：
📅 明天（7 月 19 日 周六）的安排：
• 10:00-11:00 产品讨论会（腾讯会议）
• 14:30 牙医预约（提醒：别忘了带医保卡）
• 无其他安排，下午可以 deep work。
可以注意到，它不仅列出事件，还加上了语义化的备注（如“可以 deep work”），这其实是 LLM 基于你日程密度和事件类型做出的二次解读。
4.2 创建事件与冲突检测
更进一步的用法，是用自然语言创建和修改日程。例如：
帮我在下周三下午 3 点创建一个会议，主题是 “SEO 策略讨论”，时长 1 小时。
助手会反馈一个类似的确认结构：
✅ 已创建日历事件：
• 📅 7 月 23 日（周三）15:00-16:00
• 📝 SEO 策略讨论
• 需要添加参会者吗？
如果时间段发生冲突，它会主动提醒你并给出修正建议：
⚠️ 注意：下周三 15:00-16:00 你已经有“客户电话”了。要我改成 16:30 开始吗？
这实际上把“打开日历 App → 找时间 → 建事件 → 调整时间”的完整交互链路，压缩成了一轮对话。
对于开发者而言，价值在于你不需要自己在业务侧重复造 Calendar 操作轮子，而是直接复用 gog 抽象，专注于定义“在什么场景下调用哪个意图”。
五、接入 Web Search：打破模型知识的时间墙
即使有了本地文档和你的个人数据，AI 助手仍然会撞上一堵“时间墙”——模型训练数据的截止时间。要想问“2026 年这几个月 X 领域有什么新进展”，必须接入实时搜索。
5.1 用 Brave Search API 配置联网搜索
OpenClaw 提供多种搜索方式，以 Brave Search API 为例：
配置流程非常简洁：
- 前往
brave.com/search/api注册账号并获取 API Key。 - 按照交互向导提示，填入 Brave Search API Key，系统会自动写入配置文件中。
在 OpenClaw 中执行：
openclaw configure --section web 完成后，你就可以在对话中发起联网搜索请求，例如：
搜索一下 “OpenClaw alternatives 2026”
一个示例化的回答是这样的：
🔍 搜索结果摘要：OpenClaw 的主要替代品包括：AgentGPT —— 浏览器端运行，无需部署AutoGPT —— 老牌 Agent 项目，社区庞大CrewAI —— 多 Agent 协作框架
但这些都侧重“自主执行任务”，而 OpenClaw 更侧重“个人助手”——24/7 在线、聊天交互、技能系统。定位不同，不是直接竞品。
可以看到，助手不是向你丢一串链接，而是完成了三件事：
- 聚合多个搜索结果，做去重与信息对齐。
- 用自然语言总结出一个“决策视角”的对比。
- 给出个人助手 vs 自主 Agent 的产品定位差异。
对于开发者，这提示了一个设计思路：搜索结果应该被视为模型的原材料，而不是终端用户的终点页面。你需要在 Skill 层做好“检索 → 过滤 → 结构化”的接口抽象，让 LLM 有足够信息来做高质量总结。
六、接入浏览器：让 AI 像真实用户一样“看网页”
搜索引擎解决的是“找到页面”的问题，但很多时候你需要的是“在具体网页里做事”：解析动态加载内容、处理需要登录的后台、比对页面改动、抓取非 SEO 友好的页面等。
为此，OpenClaw 内置了一个基于 Playwright 的浏览器技能， 可以直接称为“浏览器能力”。
6.1 浏览器技能能做什么？
这个浏览器能力主要覆盖三类动作：
- 访问任意 URL，并提取页面内容（HTML → 结构化文本 / 片段）。
- 对当前页面进行截图保存，用于回顾或人工审查。
- 执行基本交互：点击、输入、滚动等，模拟真实用户操作。
比如你可以这样问助手：
帮我打开 https://kirkify.net 看看首页现在长什么样。
助手的回答会包含结构化信息和状态概述：
🌐 已访问 kirkify.net：
• 首页标题：“Kirkify — Free Online Tools”
• 主要工具列表：Name Generator，QR Code，Color Palette…
• 页面加载正常，无明显错误 [截图已保存]。
更实战的例子是让 AI 帮你查看竞品定价页、帮助运营查看某个活动落地页有没有上线配置错误等。助手可以做到：
- 打开页面并解析所有价格相关 DOM 节点。
- 与之前保存的快照或结构化数据对比，给出“是否涨价”“是否新增套餐”等结论。
助手第一时间捕捉到竞品悄悄调整定价，并提醒了产品负责人——这就是“AI = 实时监控 + 语义分析 + 主动预警”的一个实际案例。
6.2 浏览器能力的安全边界
浏览器技能本质上是“远程控制浏览器”的一种形式，尤其是通过 Browser Relay / CDP 等技术暴露时，等价于给了远程代码一个“你浏览器中的超级管理员”。
使用建议：
- Browser Relay / CDP 只推荐在
localhost或tailnet（类似 Tailscale 内网）这种受控网络中使用。 - 强烈不建议暴露到公网，以防被第三方恶意利用远程控制能力。
对开发者来说，浏览器技能一定要配合强身份认证 + 授权边界 + 访问控制来使用，最好默认关闭仅在调试或本地环境启用。
七、安全：当 AI 能“碰到你的真实数据”时，必须先想清楚的事
随着 Gmail、Calendar、Web 搜索和浏览器能力接入，你的 AI 助手已经拥有了访问大量敏感数据的潜力。教程在这一章专门提了一个“安全体检”工具：
openclaw security audit openclaw security audit --deep openclaw security audit --fix# 确认无误再用这是一个自动化安全检查命令，用于发现配置错误、端口暴露等问题。使用 --fix 前需要人工确认，避免误改配置。
7.1 API Key 管理：永远不要进 Git
关于 API Key，最佳实践集中在三点：
- 永远不要把 API Key 提交到 Git 仓库，包含私有仓库。
- 使用环境变量或
.env文件进行本地存储和注入。 - 定期轮换密钥，尤其是在迁移、共享、排查问题之后。
对于多环境部署，可以考虑：本地 .env + 线上通过 CI/CD 注入环境变量，不在代码库中保留任何真实 Key。
7.2 OAuth Token：比密码更敏感的文件
token.json 这类文件里保存的是你的 OAuth 访问与刷新 Token，本质上等价于“换取访问权限的长期门票”。强调几个基本安全原则：
- 将文件权限设置为仅当前用户可读写，例如：
chmod 600 token.json。 - 不要将这类文件上传到任何共享空间或公开位置。
- 如果 token 有泄露风险，应立即撤销并重新授权。
在服务端部署时，建议将 token 文件放在特定的私有目录，并在系统级别控制访问权限。
7.3 权限最小化原则
权限最小化是安全设计的核心：
- 只授予助手实际需要的权限。
- 若你只需要读 Gmail，就不勾选“发送邮件”权限。
- 即使 Skill 支持某些危险操作，也可以在配置中关闭或加多重确认。
OpenClaw 默认对一些敏感操作（如发送邮件）要求显式确认，这是一个非常值得在自研系统中借鉴的交互模式。
7.4 网络与主机安全
对服务器侧也给出了一些基本硬安全建议：
- 开启防火墙，仅暴露必要端口。
- SSH 使用密钥认证，禁用密码登录。
- 定期运行
sudo apt update && sudo apt upgrade保持系统更新。
这些看似“老生常谈”，但任何一个环节缺失，在“AI 具备操作浏览器与调用外部 API 能力”的前提下，安全风险都会被放大。
7.5 明确写下“行为边界”
有趣且非常实用的一点，建议你在 SOUL.md 与 AGENTS.md 中写清楚行为边界：
- 哪些操作必须征求用户确认（例如转账、删库、发敏感邮件）。
- 哪些数据永远不能外传（例如他人隐私数据、公司机密文件）。
- 在什么情况下应该拒绝执行用户指令（例如违反法律法规的请求）。
举一个例子：助手被要求去查某个同事的邮件记录，但它依据 SOUL.md 中“只处理主人自己的数据”的规则选择了拒绝，而这一点反而增强了用户对它的信任。
这背后其实是“规则优先级”与“身份角色”的设计哲学——你不只是在写配置，而是在塑造一个有边界感的数字人格。
八、实践建议
今天完成的能力升级：
- 已连接 Gmail —— 助手能读（并可选发）你的邮件。
- 已连接 Google Calendar —— 助手能管理你的日程。
- 已配置搜索引擎 —— 助手能联网找信息。
- 已安装浏览器技能 —— 助手能“看到”和操作网页。
- 已建立基本安全意识 —— 知道如何保护你的数据。
从此，你可以对助手说：
帮我看看今天有什么邮件，明天有什么安排，顺便搜一下最近 AI 领域有什么新闻。
一句话，串联三个不同系统：Gmail、Calendar、Web Search。过去这至少意味着三个 App、十几次点击、十分钟的操作，现在被压缩成十秒的对话。
如果你是开发者，想把这些经验迁移到自己的 Agent 框架或产品中，可以考虑下面几条实践路线：
- 把所有外部集成统一抽象为“技能 / 工具”，而不是散落的 API 调用。
- 在每个技能层中设计清晰的能力边界和权限配置，配合“行为边界文档”。
- 把“联网搜索 + 浏览器操作”视为基础能力，而非附加功能。
- 在任何涉及敏感操作的地方，增加“二次确认”和可审计日志。
九、下一步：解锁更大的技能生态
Day 5 会围绕完整 Skills 生态展开：从 SEO 分析、社交媒体管理，到代码 Review、PDF 解析、数据库查询等，把你的个人助手真正“武装到牙齿”。
如果说今天是给助手接上了“第一双手”，那么接下来，你将开始给它装上“不同专业的手”：运营、研发、分析、自动化……而所有这些，都是站在 Day 4 的网络与安全能力之上继续向外延展的。
