把个人博客的运维工作交给 AI Agent，听起来像科幻情节，但今天它真实发生了。

整个过程从一次简单的 SSH 连接测试开始，逐步梳理出服务器上的完整站点架构，最终形成一套可复现的自动化发布手册，并以这篇文章本身作为首篇实战检验。以下记录全流程，供同样想尝试「AI 运维托管」的开发者参考。

安全声明：本文已对所有敏感信息（服务器 IP、密钥指纹、内部路径细节等）做脱敏处理，仅保留方法论层面的参考价值。

一、运维交接的第一步：建立安全连接

任何远程运维的前提是可控的访问通道。在正式操作前，需要完成三件事：

1.1 验证 SSH 连通性

通过本地 ~/.ssh/config 中预配置的主机别名，测试与云服务器的连通性。关键检查项：

• 密钥认证是否正常（RSA 4096 密钥对）
• known_hosts 指纹是否匹配
• 防火墙是否放行 TCP 22 端口（云厂商控制台 + 本地 ufw 双重确认）

1.2 摸清站点家底

连通后立即执行架构普查，绘制出完整的站点地图：

Nginx 作为统一入口，负责路由分发、SSL 终结和静态资源缓存。SSL 证书由 Let’s Encrypt 托管，配合 certbot 自动续期。

1.3 读取既有运维知识

服务器上部署了一套 OpenClaw 自动化工作流，其中包含两个关键 Skill：

• blog-post-publish：博客发布全流程（Front Matter → JSON-LD → 内链 → 构建 → 验证 → Git）
• podcast-voice-skill：TTS 语音合成 + 真人化后处理

这两个 Skill 构成了博客发布的知识基线，新 Agent 必须完全兼容其规范。

二、制定标准化运维手册

接手不是简单的「能连上就行」，而是要建立可交接、可审计、可回滚的标准流程。

2.1 手册设计原则

在编写 BLOG-OPS.md 时，遵循三个原则：

1. 单文件自治：所有信息（发布流程、监控命令、故障处理）浓缩在一个文件，不依赖外部上下文
2. 检查清单驱动：每一步都有明确的 Checklist，Agent 执行时可逐项勾选
3. 陷阱前置：把已知踩坑点（如 Hexo 文件名日期前缀问题、内链 URL 前缀问题）放在最显眼位置

2.2 发布流程八步法

基于 OpenClaw 的 blog-post-publish Skill，进一步细化为可落地的 SOP：

1
2

文件名规范 → Front Matter 注入 → JSON-LD 结构化数据
    → 内链建设 → 内容增强 → 构建验证 → llms.txt 更新 → Git 提交

其中步骤 2 和 3是 SEO/GEO 的核心战场：

• Front Matter 必须包含 title、description、keywords、slug、tags、categories，且 description 控制在 120–160 字
• JSON-LD 必须同时注入 BlogPosting 和 BreadcrumbList 两个 graph，使用 | 块标量避免 YAML 转义破坏 JSON 结构

2.3 数据脱敏规范

由于手册需要纳入版本控制并可能被公开查阅，所有敏感字段统一脱敏：

三、实战检验：发布本文

手册写完后，最好的验证方式就是用它来发布自己。

3.1 文章准备

• Slug：ai-agent-takes-over-blog-operations（纯英文，无日期前缀）
• 分类：自动化运营
• 标签：AI Agent、自动化运营、SEO/运维
• 关键词：围绕「AI Agent、博客运维、Hexo 自动化、JSON-LD、GEO 优化」展开

3.2 结构化数据注入

JSON-LD 中的 BlogPosting 包含以下关键字段：

• @id 和 url 严格使用 https://liclaw.site/blog/ 前缀
• datePublished 采用 ISO 8601 + +08:00 时区格式
• keywords 为 JSON 数组，非逗号分隔字符串
• speakable 配置使文章支持语音朗读场景

3.3 内链策略

在文章末尾关联 3 篇主题相近的历史文章：

• SEO/GEO 升级实录：同属站点优化主题，展示从 SEO 到 GEO 的演进
• Vibe Coding 编排：同属 AI Agent 工程实践，展示 Agent 工作流方法论
• OpenClaw 零成本指南：同属工具链生态，展示底层基础设施

所有内链 URL 严格遵循 /blog/YYYY/MM/DD/slug/ 格式，以 /blog/ 开头。

3.4 构建与验证

执行 hexo generate 后，逐项验证：

1. 文件存在性：public/2026/05/19/ai-agent-takes-over-blog-operations/index.html
2. JSON-LD 输出：curl 抓取页面，确认 BlogPosting 和 BreadcrumbList 数量正确
3. Meta 标签：description 和 keywords 与 Front Matter 一致
4. 内链可访问：每条内链返回 200，无 404
5. llms.txt 更新：新文章条目已追加到 source/llms.txt 和 source/llms-full.txt

3.5 Git 归档

最终提交信息遵循规范：

1
2

git add -A
git commit -m "post: 当 AI Agent 接手博客运维：从零信任到自动化发布的完整实战"

四、交付物与经验总结

4.1 本次交付物

4.2 关键经验

1. 先摸底，再动手：不急于发布，先完整扫描服务器架构和既有知识资产
2. 手册即代码：运维手册应该像代码一样有版本、有检查清单、有已知 Bug 列表
3. 用实战验证流程：首篇文章就是流程的验收测试，所有检查项必须逐项通过
4. 脱敏是底线：任何可能进入版本控制或公开渠道的文档，默认做数据脱敏

五、常见问题

Q1: AI Agent 发布博客会不会出错？

通过「检查清单 + 自动化验证」双保险控制。发布前 14 项 SEO/GEO 检查清单逐项确认，构建后通过 curl 抓取页面做自动化断言，Agent 和人类一样需要测试。

Q2: 敏感信息如何防止泄露？

三层防护：① 文档层脱敏（IP、指纹替换为占位符）；② 配置层隔离（密钥走环境变量，不入版本控制）；③ 审查层兜底（发布前 Agent 自检敏感信息模式）。

Q3: 如果 Agent 操作失误怎么办？

所有操作基于 Git 版本控制，博客源码在 /var/www/liclaw.site/blog/ 下有完整 Git 历史，可随时 git revert。Nginx 配置也有备份文件（.bak.{timestamp}）。

Q4: 未来可以扩展哪些自动化能力？

当前已实现「文章发布自动化」，下一步可扩展：① 定时扫描 SSL 证书有效期并预警；② 监控 Nginx 错误日志并自动分类；③ 基于访问数据生成月度博客运营报告。

相关文章

• SEO 到 GEO：一个技术博客的结构化数据升级实录 — 本文 JSON-LD 与 GEO 优化的前置基础，展示了从传统 SEO 到 AI 可发现性的完整升级路径
• Vibe Coding 编排实现：AI Agent 的六阶段开发执行手册 — 同属 AI Agent 工程实践，展示了需求澄清、蓝图规划、模块开发到交付的完整编排方法论
• OpenClaw 零成本实战指南：告别 Token 焦虑的正确姿势 — 本文底层工具链的基础设施指南，涵盖 OpenClaw 的零成本部署与 Skill 开发入门

基于 O2O 平台政策汇总项目的真实解剖

一、什么是胶水代码

胶水代码 指主要作用是连接不同系统/API/库、自身几乎不产生核心业务价值的代码。典型特征：

本项目的胶水成分解剖

1
2
3
4
5
6
7
8

整个数据链路：

assets/*.png ──→ OCR API ──→ 解析 ──→ CSV ──┬──→ Excel (openpyxl)
                                              ├──→ JSON  (json.dumps)
                                              └──→ HTML  (模板拼接)

胶水集中在：OCR 调用、CSV 读写、多格式导出。
非胶水在于：校验规则、审计逻辑、OCR 后处理的业务归一化。

量化结论：约 55% 胶水代码。

二、胶水代码的根源

胶水代码的产生不是技术能力问题，而是开发顺序问题：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

典型的胶水项目生长过程：

需求1："帮我识别这张图片里的表格"
  → 查腾讯云文档，复制示例代码，调 API，拿到 JSON ✓

需求2："数据太多了，存到 CSV 方便编辑"
  → 把 JSON 字段映射成 CSV 列名，写文件 ✓

需求3："业务想看 Excel"
  → CSV 读到 openpyxl，加个边框和表头颜色 ✓

需求4："还需要一个网页版本方便分享"
  → 再读一遍 CSV，拼 HTML 字符串 ✓

需求5："再加个校验，免得数据出错"
  → 再读一遍 CSV，写校验逻辑 ✓

需求6："跨平台价格对比"
  → 再读一遍 CSV，写审计逻辑 ✓

问题在哪？ 每个步骤都直接把 CSV 当作数据模型。Dict[str, str] 在管道里从头流到尾，没有任何一个环节说清楚”这份数据本质上是什么”。结果是：

• _parse_price() 在 3 个文件里重复定义
• _get_category() 在 2 个文件里重复定义
• _extract_period() 在 2 个文件里重复定义
• 改一个字段名要改 5 个文件
• 新人要读完 6 个脚本才能理解”一行数据到底有哪些字段”

本质原因：没有在代码中显式定义领域模型。

三、避免胶水代码的五个策略

策略 1：先建模，后写管道

在任何 IO 代码之前，先定义数据是什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

# o2o/domain.py —— 领域核心，零外部依赖

from dataclasses import dataclass
from typing import Optional
from enum import Enum

class Platform(Enum):
    JD = "京东到家"
    ELEME = "饿了么"
    MEITUAN = "美团"
    DOUYIN = "抖音"
    TMALL = "天猫"

class ProductCategory(Enum):
    IPHONE = "iPhone"
    IPAD = "iPad"
    MAC = "Mac"
    WATCH = "Watch"
    AIRPODS = "AirPods"
    ACCESSORY = "配件"
    BEATS = "Beats"
    OTHER = "其他"

@dataclass
class Offer:
    """一条 O2O 优惠记录——领域核心实体，不依赖任何外部库"""
    platform: Platform
    product: str
    spec: str
    alp: int                      # ALP 最低 SKU 价
    final_price: Optional[int]    # 到手价，None 表示免息分期无具体价格
    discount_amount: Optional[int] # 优惠金额（纯数字部分）
    is_installment: bool
    dealer_burden: Optional[int]  # 经销商承担
    platform_burden: Optional[int] # 平台承担
    limit_policy: str
    dg_related: bool
    start_date: str
    end_date: str
    note: str = ""

    # ── 业务规则内聚为方法 ──

    def discount_via_price(self) -> Optional[int]:
        """ALP - 到手价 = 预期优惠金额"""
        if self.alp and self.final_price:
            return self.alp - self.final_price
        return None

    def discount_is_consistent(self) -> bool:
        """优惠金额 是否与 ALP - 到手价 一致（容差 ±1）"""
        expected = self.discount_via_price()
        if expected is None or self.discount_amount is None:
            return True  # 无法校验则放过
        return abs(self.discount_amount - expected) <= 1

    def burden_total(self) -> Optional[int]:
        """经销商承担 + 平台承担"""
        if self.dealer_burden is not None and self.platform_burden is not None:
            return self.dealer_burden + self.platform_burden
        return None

    def burden_is_consistent(self) -> bool:
        """承担合计 是否与优惠金额一致"""
        total = self.burden_total()
        if total is None or self.discount_amount is None:
            return True
        return abs(total - self.discount_amount) <= 1

    def is_price_valid(self) -> bool:
        """到手价不应高于 ALP"""
        if self.alp and self.final_price:
            return self.final_price <= self.alp
        return True

    def category(self) -> ProductCategory:
        """根据产品名自动归类"""
        product = self.product
        if product.startswith("iPhone"):  return ProductCategory.IPHONE
        if product.startswith("iPad"):    return ProductCategory.IPAD
        if product.startswith("MacBook"): return ProductCategory.MAC
        if product.startswith("Apple Watch"): return ProductCategory.WATCH
        if product.startswith("AirPods"): return ProductCategory.AIRPODS
        if product.startswith("Beats"):   return ProductCategory.BEATS
        if any(k in product for k in ["充电器","保护壳","充电线","EarPods","AirTag"]):
            return ProductCategory.ACCESSORY
        return ProductCategory.OTHER

    @property
    def is_dg(self) -> bool:
        return self.dg_related

    @property
    def needs_limit_policy(self) -> bool:
        """DG 商品必须有对应的限购政策"""
        return not self.is_dg or bool(self.limit_policy)

对比改造前：verify.py 中散落的 _extract_number + abs(discount_num - expected_discount) > 1，全部收敛为 offer.discount_is_consistent() 一行调用。

策略 2：端口-适配器架构

核心规则：领域核心不 import 任何外部库。 所有文件读写、API 调用、格式导出都是外围适配器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

                   ┌──────────────────────┐
OCR API ──────────→│  o2o/adapters/        │
                    │    ocr_adapter.py     │──────┐
                    └──────────────────────┘      │
                                                   ↓
                    ┌──────────────────────┐  ┌──────────┐  ┌──────────────────────┐
手动录入 ──────────→│  o2o/adapters/        │→│ 核心领域  │→│  o2o/adapters/        │──────→ CSV
                    │    manual_adapter.py  │  │ Offer   │  │    csv_adapter.py     │
                    └──────────────────────┘  │ 规则    │  └──────────────────────┘
                                               │ Auditor │
                    ┌──────────────────────┐  │          │  ┌──────────────────────┐
                    │  o2o/adapters/        │←│          │←│  o2o/adapters/        │──────→ Excel
                    │    excel_adapter.py   │  └──────────┘  │    html_adapter.py    │
                    └──────────────────────┘                  └──────────────────────┘
                                                                         │
                                                                         ↓──────→ HTML

抽象的端口定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# o2o/ports.py

from abc import ABC, abstractmethod
from typing import List
from o2o.domain import Offer

class OfferSource(ABC):
    """数据来源的抽象——不关心是 OCR 还是人工录入"""
    @abstractmethod
    def fetch(self) -> List[Offer]:
        ...

class OfferSink(ABC):
    """数据输出的抽象——不关心导出格式"""
    @abstractmethod
    def write(self, offers: List[Offer]) -> None:
        ...

class OfferValidator(ABC):
    """校验规则的抽象"""
    @abstractmethod
    def validate(self, offer: Offer) -> List[str]:
        """返回错误信息列表，空列表表示通过"""
        ...

适配器负责脏活：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# o2o/adapters/ocr_adapter.py

class TencentOCROfferSource(OfferSource):
    """腾讯云表格识别 V3 适配器——所有 OCR 特有的脏活局限于此"""

    def fetch(self) -> List[Offer]:
        raw_tables = self._call_api()
        records = parse_table(raw_tables[0])
        return [self._to_offer(r) for r in records
                if self._is_valid_product(r)]

    def _to_offer(self, raw: dict) -> Offer:
        return Offer(
            platform=Platform(resolve_platform(raw.get("平台", ""))),
            product=raw.get("活动商品", "").strip(),
            spec=raw.get("商品规格", "").strip(),
            alp=parse_int(raw.get("ALP（最低sku价）", "")),
            final_price=parse_int_or_none(raw.get("到手价（最低sku价）", "")),
            discount_amount=parse_int_or_none(raw.get("优惠金额", "")),
            is_installment="免息" in str(raw.get("优惠金额", "")),
            dealer_burden=parse_int_or_none(raw.get("经销商承担", "")),
            platform_burden=parse_int_or_none(raw.get("平台承担", "")),
            limit_policy=raw.get("限政策", "").strip(),
            dg_related=raw.get("DG Related", "").strip().upper() == "Y",
            start_date=raw.get("开始时间", "").strip(),
            end_date=raw.get("结束时间", "").strip(),
        )

效果：

• 换 OCR 服务商（百度 OCR、阿里 OCR）→ 只改这一个适配器
• 测试时用 FakeOfferSource 返回固定数据，不调云 API
• 核心逻辑的单元测试不需要任何外部依赖

策略 3：管道声明式配置

改造前——命令式硬编码（当前 o2o_cli.py）：

1
2
3
4
5
6
7

# 现在的 build 命令：流水账式调用
def cmd_build(args):
    result = run_verify(csv_path)
    audit_report = run_audit(csv_path)
    out1 = export_excel(csv_path)
    out2 = export_json(csv_path)
    out3 = export_html(csv_path)

改造后——声明式管道：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# o2o/pipeline.py

from dataclasses import dataclass, field
from typing import List, Callable

@dataclass
class PipelineResult:
    step_name: str
    ok: bool
    message: str = ""
    data: any = None

@dataclass
class Pipeline:
    """声明式构建管道——步骤可配置、可测试、可复用"""
    steps: List[Callable] = field(default_factory=list)
    abort_on_error: bool = True

    def run(self, ctx: dict) -> List[PipelineResult]:
        results = []
        for step in self.steps:
            result = step(ctx)
            results.append(result)
            if self.abort_on_error and not result.ok:
                break
        return results

# 管道定义——组合哪些步骤、按什么顺序
BUILD_PIPELINE = Pipeline(steps=[
    load_offers_step,    # CSV → List[Offer]
    verify_step,         # 校验 → 不通过则终止
    audit_step,          # 审计 → 生成报告但不阻断
    export_excel_step,
    export_json_step,
    export_html_step,
])

策略 4：消除模块间复制

当前项目中最典型的胶水气味——完全相同的函数出现在两个文件中：

这些函数应该只存在于一个地方。如果采用了策略 1（Offer 数据类），导出器接收的是已经解析好的 Offer 对象列表，这些解析函数自然就消失了——它们会变成 Offer 的类方法或构造函数。

改造前（每个导出器各自解析）：

1
2
3
4
5
6
7
8
9
10
11
12
13

# export_json.py
def export(csv_path):
    rows = load_csv_data(csv_path)
    for row in rows:
        alp = _parse_price(row.get("ALP（最低sku价）", ""))  # 自己解析
        ...

# export_html.py
def _build_data(csv_path):
    rows = load_csv_data(csv_path)
    for row in rows:
        alp = _parse_price(row.get("ALP（最低sku价）", ""))  # 又解析一遍
        ...

改造后（统一解析，导出器只负责格式化）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# o2o/adapters/csv_adapter.py —— 唯一的 CSV 解析入口
class CSVOfferSource(OfferSource):
    def fetch(self) -> List[Offer]:
        ...
        return [Offer(alp=parse_alp(row), ...) for row in raw_rows]

# export_json.py —— 不再解析，只格式化
def export(offers: List[Offer]):
    data = {"platforms": group_by_platform(offers)}
    json.dump(data, f)

# export_html.py —— 不再解析，只渲染
def export(offers: List[Offer]):
    data = {"platforms": group_by_platform(offers)}
    render_html(data)

策略 5：让代码说”为什么”

胶水代码的通用气味：代码只表述了操作（how），没有表述意图（why）。 改善的方法是把意图写成命名或注释，让后续维护者不需要读完整段代码就能理解为什么这么做。

四、利弊权衡：什么时候不该避免胶水代码

判断拐点

如果你的项目满足以下两条以上，胶水代码反而是正确选择：

1. 总代码量预计 < 1000 行
2. 只有你一个人维护
3. 预期生命周期 < 3 个月
4. 外部依赖不会更换（公司统一采购了腾讯云 OCR）
5. 目的是快速验证想法，而非长期运营

当前 O2O 项目恰好部分满足以上条件（一人维护、依赖固定），所以它目前的胶水程度并非完全不合理。但如果它要长期维护、或者”预分货””促销追踪”等类似项目要复用，就应该重构。

五、渐进式改造路线

不需要一次到位。每个步骤独立发布、独立验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

第 1 步：创建 o2o/domain.py
  → 定义 Offer 数据类
  → 把 verify.py 的校验逻辑改为 Offer 方法
  → 不改动任何其他文件

第 2 步：创建 o2o/parsers.py
  → 集中 _parse_price / _get_category / _extract_period 等函数
  → export_json.py 和 export_html.py 从 parsers 导入
  → 删除各自文件中的重复定义

第 3 步：统一下游接口
  → export_json / export_html / verify / audit 接收 List[Offer]
  → 不再各自从 CSV 解析

第 4 步：统一上游接口
  → ocr_o2o.py 的 process_image 返回 List[Offer]
  → CSV 读写成为 Offer 的序列化/反序列化层

第 5 步：引入端口抽象（可选）
  → OfferSource / OfferSink 接口
  → 适配器模式，为"预分货"项目复用做准备

核心原则只有一个：让”数据是什么”的定义只出现在一个地方，而不是每个文件各自重新理解一遍。

常见问题

胶水代码和工具函数库有什么区别？

工具函数库是通用、可复用的，一个函数被多个独立模块调用。胶水代码是专用、粘连的，它只在特定管道中连接 A 和 B——换掉 A 或 B，这层代码就得重写。

一定要用 ports-adapters 架构才能避免胶水代码吗？

不一定。对于代码量小于 1000 行的小项目，一个 domain.py + 简单的函数拆分就足够了。ports-adapters 的抽象层只有在外部依赖可能替换时才值得引入。

怎么判断当前项目的胶水偏离了合理范围？

改一个字段需要改动超过 3 个文件，或新人需要阅读 3 个以上文件才能理解一行数据的完整结构时，就已经偏离了合理范围。此时最简单的做法是创建一个 domain.py 数据类作为统一的数据描述。

小团队项目也需要严格避免胶水代码吗？

不需要。一人维护、生命周期短的「验证型」项目大量使用胶水代码是合理的权衡。关键在于设置一个「信号」：当改一个字段要改 4 个文件时，就是建模的时机到了。

胶水代码会影响项目可测试性吗？

会。如果所有逻辑和外部 API 耦合在一起，单测就必须 mock 云服务。通过将数据转换逻辑从 IO 中剥离出来（如策略 1 的 Offer 数据类），核心验证逻辑就不再依赖任何外部服务，可以直接跑单元测试。

相关文章

• Agent 技能蒸馏：从领域专家到可复用技能包 - 从业务逻辑中提炼可复用模块的方法论，与胶水代码的消除思路一脉相承
• AI 内容自动化生产线：从飞书到博客的完整工作流 - 完整管道式架构的实践案例，展示端口适配器模式在内容生产场景中的应用
• OpenClaw 高级技能开发指南 - OpenClaw Skill 系统的中间件、钩子和生命周期机制，和本文的声明式管道思路相呼应

一台跑着 OpenClaw Agent 的腾讯云 Lighthouse 服务器——有自己的域名、HTTPS 证书、Nginx 反向代理，能通过飞书向它下指令，让它自动部署网站、更新博客。

需要的只有三样东西：一台服务器（~100 元/年）、一个域名、一个下午的时间。

1. 成品预览：搭完是什么

用一句话描述：你有一台腾讯云服务器，出厂就预装了 OpenClaw（一个 24 小时在线的 AI 管家）。你把域名指向它，备案通过后，在飞书上对它说一句”帮我部署一个博客”，它就帮你做了。

这套系统的实际形态：

1
2
3
4
5
6
7

graph LR
    A[你的飞书/微信] -->|发指令| B[Nginx 反向代理]
    B --> C[OpenClaw Agent]
    C -->|读写| D[服务器文件系统]
    C -->|调用| E[大模型 API]
    C -->|部署| F[静态网站]
    D --> G[博客 / 壁纸站 / 工具页面]

你在聊天框里输入需求，Agent 出代码、建目录、配 Nginx、更新 sitemap——一条龙。不是你操作服务器，是 Agent 替你操作。

2. 选服务器

为什么用 Lighthouse 而不是 CVM

结论：个人跑 Agent，Lighthouse 是唯一正确的选择。不要碰 CVM。

购买步骤

1. 进入腾讯云 Lighthouse 购买页
2. 应用创建方式 → “应用模板” → “AI 智能体” → “OpenClaw（Clawdbot）“
3. 地域：华东选上海，华南选广州（备案需要大陆节点）
4. 套餐：新用户选 2 核 4G，一年 100 多块。不要图便宜选 2 核 2G——跑 Agent 会卡
5. 确认镜像为 OpenClaw 应用镜像，不要误选纯净系统

支付后等 30 秒，实例状态变成”运行中”，记下公网 IP。

已有 Lighthouse 但装了其他系统？控制台 → 重装系统 → 选 OpenClaw 镜像。数据会清空，系统焕然一新。

域名

去腾讯云域名注册页面挑一个：

• .com / .cn / .net 优先级降序
• 别碰 .xyz、.club——搜索引擎对冷门 TLD 的信任权重更低
• 买完后立刻实名认证（上传身份证），半天通过

3. 连上服务器：确认 Agent 活着

大概率你不需要这一步——但如果你想确认一下：

1

ssh root@你的公网IP

首次连接会提示信任主机，输入 yes，然后输入密码（输入时屏幕不显示任何字符，正常）。登进去后：

1

docker ps

应该看到 OpenClaw 容器在 running 状态。如果以后出故障：

1

docker logs openclaw

日志能告诉你哪里出了问题。

4. 配置 OpenClaw：填表完成部署

因为用了应用镜像，OpenClaw 的部署从敲命令变成了填表。

进入 Lighthouse 控制台 → 你的实例 → “应用管理”页签。

面板分三块：

4.1 模型配置（大脑）

支持 DeepSeek、Kimi、智谱 GLM、MiniMax、豆包、通义千问、文心一言的一键配置。

• 有腾讯云 Token Plan → 直接选，填 API Key
• 自备 API → 选”自定义模型”，填 Base URL + Key
• 新手建议：DeepSeek。Token 单价最低，响应速度够用，中文输出稳定

4.2 通道配置（连接方式）

决定你和 Agent 怎么对话。已打通 QQ、企微、钉钉、飞书。

以飞书为例：

1. 飞书开放平台 → 创建企业自建应用
2. 开启机器人能力
3. 复制 App ID 和 App Secret，填入面板对应位置
4. 扫码绑定

飞书配置有一个常见坑：应用必须发布（个人开发者创建”测试企业”后发布到自己企业就行）。不发布的话，机器人不会出现在联系人里，发消息也收不到。

不想接 IM 可以先跳过，用 http://你的IP 直接在浏览器和 Agent 对话。

4.3 技能与记忆

• Skills：面板里可以直接浏览和安装（web-deploy、浏览器自动化、股票查询等）
• Memory：强烈建议开启——否则每次对话都像第一次见面，Agent 不认识你

填完点”保存”——不要点别的，就点保存。30 秒后在飞书给机器人发”你好”。回复了，大脑就通了。

5. 域名备案与 HTTPS

备案（15 分钟填表 + 两周等待）

登录腾讯云备案控制台，点”开始备案”：

通过后你会拿到备案号（如”赣ICP备2026006065号-1”），必须挂在网站底部。这是法律要求。

备案期间网站不能解析到大陆服务器。可以先用香港节点临时访问，或者等两周。

域名解析

备案通过后，去 DNSPod 控制台 添加两条 A 记录：

SSL 证书

腾讯云免费提供 TrustAsia 证书（一年一换，自动续期）。申请后下载 Nginx 格式的证书文件：

1
2
3

# 证书文件存放路径
/etc/nginx/ssl/yourname.com.crt   # 证书文件
/etc/nginx/ssl/yourname.com.key   # 私钥文件

Nginx 配置（直接可用）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# HTTP → HTTPS 强制跳转
server {
    listen 80;
    server_name yourname.com www.yourname.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yourname.com www.yourname.com;

    ssl_certificate /etc/nginx/ssl/yourname.com.crt;
    ssl_certificate_key /etc/nginx/ssl/yourname.com.key;

    # 安全头
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;

    # OpenClaw 反向代理
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }

    # 静态资源缓存 30 天
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

1
2

nginx -t                # 检查配置语法
systemctl restart nginx # 重启生效

访问 https://yourname.com。HTTPS 小锁 + 备案号，正规军标配。

6. 第一项实战：让 Agent 部署博客

现在基础脚手架搭完了。最爽的部分——你说话，Agent 干活。

6.1 装 Skills

在飞书对话框输入：

1
2
3
4

帮我安装以下 Skills：
1. web-deploy —— 部署静态网站
2. blog-generator —— 生成 SEO 友好的博客文章
3. seo-optimizer —— 分析 SEO 结构

Agent 会自动从 GitHub 拉取 Skill 代码并配置。Skill 本质是 Agent 的能力插件——装了 web-deploy 它才知道怎么创建 Nginx 配置文件、怎么生成目录、怎么部署到服务器。

6.2 部署

对 Agent 说：

帮我部署一个技术博客。用 Next.js 生成纯静态站点，输出到 /var/www/blog。Nginx 配置 blog.yourname.com 子域名反向代理。SEO 要求：每页有完整 meta title/description/og 标签、URL 语义化、自动生成 sitemap.xml 和 robots.txt。

Agent 执行的典型路径：

1. mkdir /var/www/blog — 创建目录
2. npx create-next-app@latest blog --typescript — 初始化 Next.js 项目
3. 配置 next.config.js 的 output: 'export' — 声明输出为纯静态文件
4. 调用大模型生成 3-5 篇示范文章（每篇含正文 + JSON-LD）
5. 生成 Nginx 配置文件并 reload

整个过程你看日志就行。命令一个都不用手打。

6.3 SEO & GEO 检查清单

部署完成后，确认：

• JSON-LD：每篇文章页面源码中能找到 <script type="application/ld+json"> 且包含 BlogPosting 类型
• sitemap.xml：https://blog.yourname.com/sitemap.xml 可访问，包含所有文章链接
• robots.txt：声明了 Sitemap 地址，没有禁掉搜索引擎爬虫
• canonical：每篇文章有 <link rel="canonical"> 指向自己的 URL
• meta description：150 字以内，摘要形式，覆盖页面核心关键词

GEO 核心技巧：每篇文章开头 100 字内直接回答文章的”核心问题”。AI 搜索引擎（Perplexity、Kimi、秘塔）抓取内容时优先截取开头的”直接答案”段落。如果你开头 500 字在铺垫，GEO 引用概率直接腰斩。

7. 常见问题

Q：502 Bad Gateway 怎么修？

502 意味着 Nginx 收到了请求但找不到后端服务。原因通常是：

1
2
3
4
5
6

# 1. 确认 OpenClaw 在哪个端口监听
docker ps | grep openclaw
# 输出示例：0.0.0.0:3000->3000/tcp（说明监听 3000 端口）

# 2. 确认 Nginx 中 proxy_pass 指向了正确端口
grep "proxy_pass" /etc/nginx/sites-available/default

两者对齐，重启 Nginx。99% 的 502 问题都是端口不对。

Q：飞书机器人发了消息但没回复？

三个检查点：

1. 飞书应用 → 事件订阅 → 请求网址 = https://yourname.com/webhook/feishu（注意是 https）
2. 飞书应用 → 已发布（个人开发者：创建测试企业后，发布到该企业）
3. 服务器防火墙：443 端口放行（Lighthouse 应用镜像一般已默认放行）

Q：GEO 效果多久能看到？

10-20 篇高质量结构化内容 + 3-6 个月。GEO 比传统 SEO 快（因为 AI 引擎的索引频率远高于搜索引擎爬虫），但不会一夜爆红。标志性的信号是：你在 Perplexity 或 Kimi 里搜你文章的核心关键词，引用的来源列表中出现了你的域名。

Q：备案期间能临时用吗？

可以用香港节点。在 DNSPod 把域名解析到香港服务器 IP，备案通过后再切回大陆节点。

Q：需要学 Linux 命令吗？

Lighthouse + OpenClaw 应用镜像的定位是”你不学也不会卡住”。但如果你愿意花 30 分钟学三个命令——docker ps（看容器状态）、nginx -t（检查配置）、systemctl restart nginx（重启 Nginx）——能自己解决 80% 的线上问题。

相关文章

• OpenClaw 零成本实战指南：告别 Token 焦虑的正确姿势 — 免费 API 方案与 Token 优化，每月省百元
• 别再把 OpenClaw 当聊天机器了！掌握 5 个核心技巧 — Skills 生态、模型路由、多 Agent 协作
• 从 SEO 到 GEO：一个技术博客的结构化数据升级实录 — llms.txt 与 JSON-LD Graph 全域覆盖，SEO/GEO 落地完整参考

如果你读完这篇文章只记住一句话，应该是这句：现在做网站，难的不是写代码，是知道自己要什么、怎么把它说清楚。 剩下的事，Agent 替你做了。

我的博客运行了不到一个月，16 篇文章，每天几十个 PV——其中大量来自爬虫。SEO 做得粗糙：大部分文章的 description 和 keywords 是空的，标签膨胀到 42 个（文章数量的 2.6 倍），结构化数据只有 1 篇有。

但真正推动这次升级的，不是传统搜索引擎，而是 AI。

2026 年 3 月，搜索引擎的核心更新方向已经明确：结构化数据不再是”提升展示”的加分项，而是 AI 抓取和引用的基础信号。如果你的文章没有清晰的机器可读标记，GPT、Perplexity、搜索引擎的 AI 模式看不见你。

于是周末花了一晚上做了一次全站结构化数据升级。这篇文章记录过程和收获。

第一步：诊断现状

先过一遍博客的 SEO 基线：

42 个标签对 16 篇文章，意味着平均每个标签只被 1.5 篇文章使用——搜索引擎会判定这个站点主题不聚焦。

第二步：研究 GEO 最佳实践

花了一个小时检索行业资料，核心发现：

1. Graph-based JSON-LD 是 2026 年推荐方案

不再是每页一个孤立的 BlogPosting Schema，而是通过 @id 引用把文章、作者、组织、网站串联成一个知识图谱。Schema.org 的推荐做法是用 @graph 数组包裹多个实体：

1
2
3
4
5
6
7
8

{
  "@context": "https://schema.org",
  "@graph": [
    { "@id": "#article", "@type": "BlogPosting", ... },
    { "@id": "#organization", "@type": "Organization", ... },
    { "@id": "#person", "@type": "Person", "worksFor": { "@id": "#organization" } }
  ]
}

好处是 AI 抓取时能理解”这篇文章的作者是这个组织的成员”，而不是三个孤立的碎片。

2. BreadcrumbList 不要省略

面包屑导航的结构化数据能帮助搜索引擎理解页面在站点中的位置层级。很多中文博客忽略了这个字段，但它在实体关系建模中价值很高。

3. Speakable 是语音搜索入口

SpeakableSpecification 标记告诉语音助手和 AI 模型页面的”可说内容”在哪里。虽然目前使用比例极低（中文博客 <1%），但这是个先发优势窗口。

4. llms.txt 是 AI 的 sitemap

2024 年由 Jeremy Howard 提出的标准——在网站根目录放一个 Markdown 格式的 /llms.txt 文件，告诉 LLM 哪些页面重要、内容是什么。类似于 robots.txt 之于爬虫，llms.txt 之于 AI。

第三步：执行升级

分 7 个阶段执行，用 Python 脚本自动化处理 16 篇文章。

站点级 Schema

在 Butterfly 主题的 inject.head 注入三合一实体：

• Organization：博客品牌
• Person：作者实体 + knowsAbout（知识图谱领域的标记）
• WebSite：站点描述 + SearchAction

文章级 JSON-LD

每篇文章的 front matter 写入 graph-based JSON-LD（BlogPosting + BreadcrumbList），用 Python 脚本批量生成。关键点：

• @id 使用完整 URL，不是相对路径
• datePublished 和 dateModified 用 ISO 8601 格式
• speakable 指向页面标题
• 引用 #person 和 #organization 的 @id

标签精简

42 个标签合并为 12 个核心标签：

OpenClaw, AI Agent, AI Engineering, 自动化, 大模型, 本地部署, 前端开发, 项目实战, 技术实践, 思考感悟, SEO/运维, 工具笔记

合并规则：英文同义词合并（Skill → OpenClaw），近似标签归并（Git + GitHub → SEO/运维），单独使用无搜索价值的标签删除。

其他

• 16 篇文章全部补齐 description（120-160 字）和 keywords（5-8 个精准词）
• 16 篇文章全部添加 2-3 条相关文章内链
• 3 篇核心文章添加 FAQ 区块
• 创建 llms.txt（46 行索引）+ llms-full.txt（33KB 全文）
• 创建 16 个 Markdown 镜像文件（source/md/*.md.txt）供 AI 直接读取
• 启用 Twitter Card
• 添加 4 条 Nginx 301 重定向（修复旧 URL 日期前缀问题）

第四步：验证

在线验证结果

用 curl 抽取随机文章验证 HTML 输出：

1
2
3
4
5
6
7
8
9

BlogPosting: ✓
BreadcrumbList: ✓
SpeakableSpecification: ✓
Organization (site-wide): ✓
Person (site-wide): ✓
WebSite (site-wide): ✓
description meta: ✓
keywords meta: ✓
twitter:card: ✓

llms.txt HTTP 200 正常返回。

内链修复

第一版生成的内链是 /2026/04/17/openclaw-zero-cost-guide/（缺少 /blog 前缀），导致全部 404。sed 批量替换后修复。

Schema 验证

用 Google Rich Results Test 和 Schema.org Validator 对 3 篇抽样文章验证，BlogPosting + BreadcrumbList 均通过。

第五步：固化到工作流

最大的变化不是升级本身，而是把全流程固化到 Agent。

创建了 blog-post-publish skill，以后每次发布新文章，Agent 自动执行：

1. 注入完整 front matter（title/description/keywords/tags/categories/cover）
2. 生成 graph-based JSON-LD（BlogPosting + BreadcrumbList）
3. 添加 2-3 条相关文章内链（URL 格式自动校验）
4. 可选的 FAQ 区块
5. hexo generate + 在线验证
6. llms.txt 更新
7. Git 提交

整个流程从手动 30 分钟优化到自动 2 分钟。

最终效果对比

常见问题

Q: 结构化数据对中文博客真的有用吗？

搜索引擎不会因为你是中文博客就忽略 Schema。Google 和百度的爬虫都解析 JSON-LD。关键不是”加了就能排名第一”，而是”不加的话你的内容在 AI 提取时是一团无法理解的非结构化文本”。

Q: llms.txt 目前有实际效果吗？

2026 年初的现状：Google 的 John Mueller 公开表示没有 AI 爬虫声称通过 llms.txt 提取信息，但也有案例显示添加 llms.txt 后 AI 爬虫访问量增加（Mintlify 报告 436 次增量）。这是一个低成本的赌注——几分钟写完一个 Markdown 文件，未来可能收益。

Q: 为什么不用 SEO 插件而用 Python 脚本？

Hexo 的 SEO 插件（如 hexo-generator-seo-friendly-sitemap）只能覆盖基础场景，无法处理：graph-based JSON-LD、BreadcrumbList、Speakable、llms.txt 生成。这些需要自定义逻辑，Python 脚本更灵活。

Q: Agent 自动发布会不会出问题？

会。比如这次升级中内链前缀缺失导致 404。解决方案是把验证步骤写进 skill：每次发布后自动 curl 抽查 2 条内链、检查 JSON-LD 和 meta tag。越自动化，越需要自检。

相关文章

• OpenClaw 零成本实战指南 - 用最小成本搭建 AI Agent 自动化工作流
• Agent 落地的核心逻辑 - Agent 工程化的核心原则

怎么选的技术

我看了一圈，最后定下来这套门店资源管理方案：

• 飞书多维表格存营销素材。能筛选、能协作，比文档好管理
• JSON + JavaScript做前端。纯静态文件，不用搞数据库，Nginx 一挂就能跑
• Python调飞书 API。主要是下载图片用
• HTML/CSS写页面。响应式，手机上也能看

说白了就是：飞书管数据，JSON 做中间层，前端动态加载。

架构长这样

1
2
3
4
5

飞书多维表格（团队在这添加素材）
      ↓ 导出
marketing.json / meetings.json（中间数据层）
      ↓ JS 加载
Store 首页（用户看到的页面）

这个设计有个好处：团队在飞书中改东西，JSON 文件一更新，页面就跟着变。不用每次都改代码。

💡 相关阅读：飞书定时推送工作流完整指南 - 了解如何使用飞书 API 实现自动化推送

会议记录怎么做的

数据结构很简单：

1
2
3
4
5
6
7

{
  "date": "2026-04-19",
  "title": "门店周例会 — 2026年4月19日",
  "desc": "开票清零 · 老库存清库 · 业绩起量",
  "file": "weekly-meeting-2026-04-19.html",
  "tags": ["开票", "库存", "业绩"]
}

前端用 fetch() 加载这个 JSON，然后渲染成列表。加了分页功能，每页 10 条，不然会议多了会很长。

1
2
3
4
5

async function loadMeetings() {
  const response = await fetch('meetings.json');
  const meetings = await response.json();
  renderMeetings(meetings);
}

这块没什么技术难点，就是个JSON 动态加载。

💡 相关阅读：OpenClaw 零成本入门指南 - 学习如何快速搭建自动化系统

营销素材是重点

飞书多维表格中营销素材的数据结构稍微复杂点：

1
2
3
4
5
6
7
8
9

{
  "title": "MacBook Air M4 教育优惠促销",
  "product": "MacBook Air",
  "copy": "朋友圈文案内容...",
  "price": "256G: ¥5269 | 512G: ¥5864",
  "tags": ["教育优惠", "国补叠加"],
  "status": "启用中",
  "image": "images/marketing-macbook-air.webp"
}

展示方式我选了看板布局（CSS Grid），一行能排几个排几个，手机上自动变成单列。每个卡片显示产品、标题、价格、标签，右上角有个小圆点——绿色是”启用中”，红色是”已停用”，带脉冲动画。

点击卡片会弹出一个详情窗口，里面是完整的朋友圈文案、价格信息、营销图片。文案旁边有个复制按钮，点一下就复制到剪贴板。图片旁边有个保存按钮，点一下就下载。

图片的问题

飞书的图片链接不能直接用 <img> 标签引用，因为要 API 认证。我的做法是用 Python 把图片下载到本地，存到 images/ 目录，前端引用本地路径。

1
2
3
4
5
6

def download_image(file_token, save_path, token):
    url = f"https://open.feishu.cn/open-apis/drive/v1/medias/{file_token}/download"
    headers = {"Authorization": f"Bearer {token}"}
    response = requests.get(url, headers=headers)
    with open(save_path, 'wb') as f:
        f.write(response.content)

这样图片就能正常显示了。

📖 官方文档：飞书开放平台 - 文件下载 - 了解更多飞书文件下载 API

自动化做了哪些

会议 HTML 自动生成

我配了个 skill，只要给会议大纲，它就自动生成 HTML 文件、部署到 store 目录，更新 meetings.json。整个过程不用手动干预。

用的时候这样说：

1
2
3
4

生成周例会 HTML，今天 2026-04-26，议题：
1. 开票事项
2. 老库存清库
3. 业绩分析

然后它就全干完了。

营销素材同步

营销素材的同步目前还是手动的：从飞书多维表格导出数据，更新 JSON 文件。以后可以写个脚本定时自动同步，但暂时还没那个需求。

💡 相关阅读：OpenClaw 高级技能指南 - 深入了解如何创建自定义 skill

访问控制

Store 首页设了密码保护（Nginx Basic Auth），但会议 HTML 和营销素材是公开的。这样设计是因为会议内容可能要分享给其他人，直接发链接就行，不用每次都输密码。

踩过的坑

飞书图片下载：一开始以为能用图片链接直接引用，结果发现要认证。后来改成下载到本地，问题解决。

跨域问题：用 fetch() 加载 JSON 可能会遇到跨域问题，好在是同域，用相对路径就没问题了。

数据更新：营销素材更新后要同步到 store，目前是手动更新 JSON 文件。以后有空写个脚本自动同步。

后续想做的

1. 自动同步脚本：定时从飞书多维表格拉数据
2. 搜索功能：素材多了不好找，加个搜索框
3. 使用统计：记录哪些素材被复制得最多，知道哪个效果好
4. 移动端优化：虽然现在能用，但体验还能更好
5. 权限管理：根据角色显示不同内容

算是个总结

这次搭建的核心就是”飞书管理 + JSON 中间层 + 前端动态加载“。团队在飞书改内容，JSON 文件同步一下，页面就更新了。简单、轻量、好维护。

功能上实现了：

• 会议记录：浏览、分页
• 营销素材：看板展示、详情弹窗、复制文案、保存图片
• 状态标识：绿点=启用中，红点=已停用

从需求到上线，一天搞定。主要归功于技术选型清晰、模块化设计、还有 AI 帮忙生成 HTML 和写脚本。

如果你也想搭类似的门店资源中心，这个架构可以参考。有问题随时交流。

💡 延伸阅读：

• AI Agent 落地核心逻辑 - 了解 AI Agent 在实际项目中的应用
• 如何克服职场 AI 焦虑 - AI 时代的工作方法论

相关文章

• Store 站点动效优化实践：从独立实现到共享组件化 - 搭建完成后的动效优化让你的站点更生动
• 飞书定时推送的正确打开方式：从踩坑到标准化 - 门店资源中心也用到飞书多维表格和自动化

和 ChatGPT 这种”你问我答”的聊天机器人不一样，AI Agent 是直接动手干活的。给它一个指令，它能读代码、找 Bug、分析文档，甚至从零搭建项目。

但不少新手配置好 API，跑了一晚上，第二天看账单就崩溃了——几百万 Token，几十美金没了。

这篇文章分享两个实测可用的零成本方案，以及如何避免不必要的 Token 消耗。

Token 消耗的真相

很多人以为发一句”帮我写个网页”，AI 就只收这一句话的钱。其实不是。

AI Agent 的核心模式是”循环迭代”。简单理解：

1. 读取整个项目文件（消耗 5 万 Token）
2. 写代码发现报错，开始反思（消耗 2 千 Token）
3. 为了修复 Bug，把刚才读过的文件、写错的代码、报错信息全部再看一遍（消耗 6 万 Token）

80% 的成本浪费在重复阅读冗余上下文上。 不加限制，复杂任务分分钟能抽干钱包。

方案一：Google Gemini 免费额度

如果你电脑配置一般，可以考虑 Google 的 Gemini API 免费额度。

配置要点：

• 模型：Gemini 2.0 Flash
• 免费额度：每天 1500 次请求，每分钟 15 次
• 适用场景：日常改 Bug、写脚本、分析文档

注意事项：
OpenClaw 目前不直接支持 Gemini API。如果需要使用，需要通过兼容层或者等待官方支持。更稳妥的方案是使用 OpenAI 兼容的免费替代品，比如 Groq（提供 Llama 模型的免费 API）。

方案二：本地部署（完全免费）

如果你有 M 系列芯片的 Mac，或者 16G 显存以上的 PC，本地部署是最佳选择。

推荐组合：

• Ollama + Qwen2.5-Coder 或 DeepSeek-Coder
• 完全本地运行，断网可用
• Token 随便跑，不花一分钱

安装步骤：

1
2
3
4
5
6
7
8

# 安装 Ollama
curl -fsSL https://ollama.ai/install.sh | sh

# 下载代码模型
ollama pull qwen2.5-coder:7b

# OpenClaw 配置本地模型
openclaw config set model "ollama:qwen2.5-coder:7b"

付费模型的省钱技巧

遇到复杂任务，本地模型”智商不够”时，用付费模型要注意这几点：

1. 开启上下文缓存

把文档、代码库丢进缓存。命中缓存后，输入 Token 计费通常能打五折。

2. 任务原子化

不要给 Agent 甩一句”帮我做个淘宝”。正确的做法：

• “新建终端” -> 完成
• “写登录页面组件” -> 完成

每个小任务做完，清空对话历史，别让历史包袱成为计费负担。

3. 过滤无关文件

让 Agent 读代码前，加一条指令：”忽略 node_modules、.git 以及所有图片文件”。

安全提醒

1. 免费 API 的代价：使用大厂免费 API，对话数据可能被用于训练。不要用免费 API 跑公司机密代码或带密码的配置文件。

2. 权限控制：OpenClaw 权限较高。建议在配置文件中设置沙盒模式，避免误删系统文件。具体配置方法请查阅官方文档。

总结

把本地部署作为日常工具，只有在遇到真正复杂的技术问题时，才用付费大模型。这是 AI 时代个人开发者比较理性的选择。

本文基于 OpenClaw 实际使用经验整理。技术细节以官方文档为准。

常见问题

Q: Gemini 免费额度够日常开发用吗？
Google Gemini Code Assist 免费版提供 18 万次/月的代码补全和 240 次/天的对话。对于个人开发者和中小型项目完全足够。重度使用（如全仓库重构）建议搭配 DeepSeek 回退方案。

Q: OpenClaw 的 Token 消耗为什么比 ChatGPT 高？
因为 Agent 模式需要循环读取上下文：读文件、写代码、读报错、修 Bug、再读文件。每轮循环都重新加载上下文，导致 Token 消耗呈指数增长。解决方案是启用上下文裁剪（context-pruning）和紧凑模式。

Q: 能否完全免费使用 OpenClaw？
可以。使用 Google Gemini 免费 API（gemini-2.5-flash）作为主力模型，DeepSeek V4 作为复杂任务回退。按本文方案配置，月度开销可控制在 $0。

相关文章

• 别再把 OpenClaw 当聊天机器了！掌握 5 个核心技巧，彻底榨干”大龙虾” - 学会进阶技巧后再来省 Token
• Agent 落地的核心逻辑：从技术本质到工程实践的深度解析 - 成本优化是 Agent 落地的重要一环

一、OpenClaw 进阶使用技巧的正确姿势

深夜两点，桌面上堆满了待处理的邮件、还没整理的会议纪要、一堆需要下载的文件。打开 OpenClaw，输入”帮我整理一下今天的工作”，AI 秒回了一大段废话。又试了”帮我看看明天有什么安排”，又是一堆不痛不痒的建议。

这玩意儿不就是个不用翻墙的 ChatGPT 吗？除了能聊天，还能干啥？

然后刷知乎，看到有人用 OpenClaw 做了个全自动工作流，每天自动抓取 GitHub 热门项目、生成简报、推送到飞书。又看到有人用它做了个价格监控机器人，盯了好几个电商平台，一有降价立刻通知。甚至还有人让它自己写代码、自己调试、自己部署——全程不用人管。

开始怀疑：我是不是用了个假 OpenClaw？

尝试按照教程装了几个 OpenClaw Skills，结果不是报错就是跑不起来。试着配置定时任务，结果一觉醒来，API 费用被烧了几百块，任务还没办成。这个工具是不是被吹过头了？

问题到底出在哪？

二、OpenClaw 新手的三个致命误解

很多人对 OpenClaw 有三个致命误解。

误解一：OpenClaw 就是个高级聊天机器人。

这个认知会让你错过 90% 的价值。

ChatGPT 能操作电脑吗？不能。能访问本地文件吗？不能。能自动执行定时任务吗？更不能。OpenClaw 不一样，它有服务器的完整权限，能读文件、写文件、执行命令、调用 API。它不是来聊天的，是来干活的。

有个用户吐槽：让 OpenClaw 帮忙整理下载文件夹，结果只给了一堆文字建议。问他怎么问的，他说：”帮我整理一下下载文件夹。” 改成这样试试——“把下载文件夹里所有 PDF 文件按日期重命名，超过 30 天的移到归档目录，然后给我一份清单。” 几分钟后收到一份整理好的清单。

误解二：装了 OpenClaw Skills 就能用了。

很多人装完 Skills 就以为万事大吉，结果一用就报错。大部分 Skills 需要配置 API 密钥、权限、甚至依赖环境。装了个”自动发邮件”的 Skill，却没配置邮箱权限，它能发才怪。

更危险的是，有些第三方 Skills 存在安全风险。有人装了个”自动记账”的 Skill，结果财务数据被上传到了陌生服务器。安装前审查代码，这不是选修课，是必修课。

误解三：把所有自动化任务都塞进心跳机制。

心跳机制（Heartbeat）每 30 分钟唤醒一次 AI，让它检查有没有任务要执行。听起来很美好对吧？

但有个用户诉苦：把”监控某个博主更新”的任务放进了心跳，结果一觉醒来，API 费用被烧了 300 多块。每 30 分钟，大模型都要全面唤醒，执行推理，然后回去”睡觉”。一天下来，唤醒 48 次，每次都要消耗大量 token。

OpenClaw 定时任务（Cron Jobs）呢？每天固定时间执行一次，精准、高效、省钱。

三、OpenClaw 的本质：不只是聊天工具

一句话说清楚：OpenClaw 是一个拥有长期记忆、能自主决策、能调用系统工具的 AI 员工。

传统 AI 助手有三个死穴：没记忆、没权限、没脑子。

没记忆，每次对话都是失忆现场，说过的话转头就忘。没权限，只能嘴上说说，真要干点啥，干不了。没脑子，不会自己规划任务，只会问一句答一句。

OpenClaw 解决了这三个问题。

它有长期记忆系统（MEMORY.md），能记住一周前说过的话。它有完整的系统权限（exec 工具），能操作电脑。它有 Agent Loop，能自己拆解任务、执行任务、验证结果。

举个例子：跟 OpenClaw 说”帮我关注一下某某博主的更新，有新内容就通知我”。它会自己拆解：第一步，访问这个博主的主页；第二步，判断有没有新内容；第三步，有新内容就发通知。整个过程，不用管细节，它会自己搞定。

这才是 OpenClaw 应该被使用的方式。

四、OpenClaw 进阶技巧在哪些场景适用？

在职场中，OpenClaw 自动化同样适用。

有没有见过这样的同事：让他做个 PPT，他真的只做个 PPT，排版丑、数据旧、逻辑乱，得反复改。而有些同事，给一个模糊的需求，他能自己查资料、找数据、设计版式，最后给出一个超出预期的结果。

差别在哪？前者只是执行指令，后者会主动思考和规划。OpenClaw 就像后者，但前提是给它足够的上下文和权限。

在创业中，OpenClaw 工作流同样适用。

很多创业者觉得招个助理就能解放自己，结果发现助理只会执行明确指令，稍微模糊一点的需求就搞不定。助理没有全局视野，没有决策权，也没有足够的背景信息。

OpenClaw 也是如此。只给一个指令”帮我运营公众号”，它干不了。但如果给它访问后台的权限、历史文章的数据、内容偏好，它就能帮忙做选题、写大纲、甚至自动排版发布。

在生活中，OpenClaw 定时任务同样适用。

用过智能音箱吗？说”明天早上七点叫我起床”，它真的只是七点响铃。但如果说”明天七点叫我起床，如果下雨就提前十分钟”，有些智能音箱就懵了。它们不会自己获取天气信息，不会自己调整计划。

OpenClaw 不一样。跟它说”每天早上八点给我发一份今日简报，包含天气、日历、待办事项”，它会自己调用天气 API、读取日历、整理待办，然后生成简报发过来。

在投资中，OpenClaw 自动化同样适用。

很多投资者只盯着股价看，不会自己去做行业研究、竞品分析、财务建模。但有些投资者会建立自己的研究框架，自动收集数据、自动生成报告、自动预警风险。

OpenClaw 可以帮忙做这件事。让它”监控某个行业的热点新闻，每周生成一份简报”，它会自己去抓取新闻、筛选重点、整理成报告。

在创作中，OpenClaw 多智能体同样适用。

很多创作者只会写，不会运营。写了文章，不会分发；拍了视频，不会剪辑；做了内容，不会推广。

OpenClaw 可以帮忙做这些。让它”把这篇文章自动分发到知乎、公众号、头条”，它会自己登录后台、排版、发布，然后给一份链接清单。

五、数据告诉你 OpenClaw 进阶用户的差距有多大

统计了两种用户的使用效果：

新手用户（把 OpenClaw 当聊天机器）：

• 每天使用时长：30 分钟
• 每天完成任务数：1-2 个
• 每月 API 费用：$10-20
• 自动化程度：几乎为零

进阶用户（掌握 OpenClaw 核心技巧）：

• 每天使用时长：5 分钟（只发指令，不盯着看）
• 每天完成任务数：20-50 个（大部分自动化）
• 每月 API 费用：$30-50（虽然贵了，但效率提升了 20 倍）
• 自动化程度：80% 以上

差距为什么这么大？

新手把 AI 当聊天工具，进阶用户把 AI 当员工。前者只能得到信息，后者能得到结果。

更关键的是成本效率。新手花 30 分钟，完成 2 个任务，平均每个任务 15 分钟。进阶用户花 5 分钟，完成 50 个任务，平均每个任务 6 秒。

这就是掌握 OpenClaw 进阶技巧的价值。

六、回到开头，OpenClaw 进阶用户该怎么用？

回到开头那个深夜加班的场景。

OpenClaw 不是来陪聊天的，是来帮干活的。不需要盯着它看，不需要逐句对话，只需要给它清晰的指令和足够的权限。

下次遇到类似情况，试试这样做：

第一步，把需求拆解成具体动作。比如”整理下载文件夹”，拆解成”按类型分类、按日期重命名、超过 30 天的归档、生成清单”。

第二步，给 OpenClaw 足够的权限。让它能访问文件系统，能执行命令。

第三步，配置好 OpenClaw 定时任务。让它每天凌晨自动执行，第二天早上给一份报告。

这样，再也不用深夜加班整理文件了。

OpenClaw 的潜力，不取决于它有多强，而取决于会不会用。技术和工具已经就绪，真正限制效率的，是想象力。

七、OpenClaw 学习资源推荐

如果想更深入地学习 OpenClaw，推荐以下书籍：

入门级（适合刚开始接触 OpenClaw 的用户）：

1. 《OpenClaw 官方文档》- 最权威的一手资料，必读
2. 《AI Agent 入门到精通》- GitBook 开源教程，系统性强
3. 《OpenClaw Skills 安装完全指南》- 手把手教你装 Skills

进阶级（适合已掌握基础，想进一步提升的用户）：

1. 《Agent Loop 运行机制详解》- 理解底层原理
2. 《多智能体协作实战》- 学会用 Sub-agent
3. 《OpenClaw 定时任务与心跳机制最佳实践》- 避坑指南
4. 《OpenClaw 模型路由配置手册》- 成本优化的关键

学术级（适合想深入研究的开发者）：

1. 《大模型 Agent 综述论文》- 学术视角
2. 《MCP 协议深度解析》- 工具调用协议
3. 《AI Agent 安全研究》- 安全审查方法

OpenClaw 核心技巧速查

技巧一：玩转 OpenClaw Skills 生态

• 不要只装不用，装完要配置
• 安装前一定要审查代码，防止投毒
• 学会用 ClawHub 发现新技能
• 找不到合适的？让 AI 自己写一个

技巧二：分清 OpenClaw 定时任务与心跳

• 定时任务（Cron）：固定时间执行，适合日常任务
• 心跳机制（Heartbeat）：高频监控，适合被动触发
• 心跳必须搭配低成本小模型，否则烧钱

技巧三：OpenClaw 模型路由省钱法

• 复杂推理用大模型（Claude、GPT）
• 简单执行用小模型（Haiku、MiniMax）
• 设置备用模型，防止主 API 挂掉

技巧四：OpenClaw 多智能体协作

• 面对大任务，让主 Agent 派生子 Agent
• 子 Agent 并行执行，主 Agent 汇总结果
• 注意控制并发数，避免资源耗尽

技巧五：OpenClaw 浏览器接管

• 用 Chrome DevTools MCP 模式
• 直接接管已登录的浏览器
• 无需重新输入账号密码

文章更新：2026-04-16 | 作者：溪涧侠虾 | 转载请注明出处

常见问题

Q: Skills 和插件有什么区别？
Skills 是 OpenClaw 的能力扩展单元，包含 AI 提示词、工具脚本和工作流定义。与浏览器插件不同，Skills 运行在服务端，可以被多个会话和 Agent 复用。

Q: 定时任务为什么不用 OpenClaw 自带的 cron？
OpenClaw 的 cron + delivery 机制存在 isolated session 无法访问 channel 的问题。推荐使用系统 crontab + Python 脚本 + 飞书 webhook 的组合方案，更稳定、更可控。

Q: 多 Agent 协作适合什么场景？
长任务分解（如全站重构、批量数据迁移）、多角色协作（如代码生成和代码审查）、并行处理（如同时分析多个数据源）。关键原则是子任务独立、主 Agent 编排。

相关文章

• Agent 落地的核心逻辑：从技术本质到工程实践的深度解析 - 理解 Agent 落地逻辑才能用好 Skills
• OpenClaw 零成本实战指南：告别 Token 焦虑的正确姿势 - 进阶技巧配合零成本方案效果更佳