用 React + Ink 在终端里「优雅搜索」：开源 CLI 设计与非交互模式实践

适合：喜欢命令行、想写 Node CLI、或对「终端 UI + 脚本化输出」感兴趣的前端 / Node 开发者。
仓库：bot-cli · npm 包名：search-bot-cli · 全局命令：bot-cli

一、为什么要做这样一个工具

日常开发里，「打开浏览器 → 搜索 → 点开几条结果」路径很短，但在以下场景里，纯终端反而更顺手：

• SSH 到远端、或本机就想少切一次窗口；
• 希望结果列表结构化展示，而不是浏览器里一堆广告与折叠；
• 想把「搜索」接进自己的脚本、CI，甚至 AI Agent 的 tool 调用里。

于是有了 search-bot-cli（命令行里叫 bot-cli）：底层用 DuckDuckGo HTML 结果拉取标题、链接与摘要，无需申请搜索 API Key；上层用 React + Ink 做交互式终端界面，并支持 JSON / 纯文本非交互输出，兼顾「人看」和「机器读」。

二、功能一览

技术栈概览：TypeScript + Node 18+、Commander 14、Ink 7、React 19、Cheerio、clipboardy、open。

三、安装：先认准包名与命令名

npm 上的包名是 search-bot-cli，装好后在终端里执行的是 bot-cli。若误装 npm install -g bot-cli，会装到 npm 上另一个同名包，与本文仓库无关。

npm install -g search-bot-cli

（公司私服、registry 不同步等环境差异，可到仓库 README 查看说明。）

四、使用方式速查

交互搜索（默认进入 Ink 界面）：

bot-cli search "TypeScript"

非交互：只打印 JSON 后退出（脚本 / Agent 友好）：

bot-cli search "Rust 异步" --output json
# 或简写
bot-cli search "关键词" -o plain

查看子命令与参数说明：

bot-cli --help
bot-cli search --help

交互模式下常用指令：1–10 打开对应结果，/save、/save json、/summary、/clear，Ctrl+C 退出。默认 TUI 依赖真实终端；json / plain 模式不渲染 Ink，可无 TTY、可管道重定向。

五、实现思路（精简版）

5.1 CLI 入口：Commander 子命令 + 输出分流

search <keyword> 作为子命令；通过 -o, --output 在三种模式间切换：

• interactive：拉取结果后 render(<SearchApp />)；
• json / plain：格式化写入 stdout 后直接结束进程，不进入 Ink。

这样同一套搜索逻辑既能服务「人类点选」，也能服务「机器解析」。

5.2 搜索层：HTTPS + Cheerio 解析 HTML

对 DuckDuckGo 的 HTML 端点发起请求，用 Cheerio 选择器抽取 title、link、snippet，再截取前 N 条（当前为 10 条）。实现上注意 User-Agent、编码与页面结构变更带来的兼容风险——这是所有「爬 HTML」类工具的共同维护点。

5.3 交互层：Ink 里当 React 写

主界面在 SearchApp 中处理键盘输入、高亮、阶段状态（保存中、摘要生成中等），列表展示拆到 SearchResults；剪贴板、打开链接、写文件、调用兼容 OpenAI 的摘要接口则放在 utils/ 下，保持组件相对干净。

六、CLI 与 MCP：区别是什么，CLI 又好在哪里

Agent 要「动手」时，常见两条路：让模型生成并执行终端命令（CLI），或 通过 MCP（Model Context Protocol）把外部能力注册成结构化工具。二者不是非此即彼，但取舍差异很大；下面把概念对齐，并说明在什么情况下 CLI 往往更划算（也与本文 bot-cli --output json 的设计一致）。

6.1 各自是什么（一句话）

• CLI（命令行接口）：本机或 CI 上的可执行程序，用参数、环境变量、stdin/stdout 交互；输出可以是人类可读文本，也可以是 JSON 等机器可读格式，便于管道（|）和脚本拼接。
• MCP：以 JSON-RPC 为主的协议，在 Host（如 IDE） 与 MCP Server 之间约定资源（Resources）、工具（Tools）、提示（Prompts）等；模型通过协议 发现 工具名与参数 schema，由 Host 代为调用。

MCP 由 Anthropic 在 2024 年提出后，已被多家 IDE / Agent 平台接入，用于把「数据库、文档、内部 API」等以统一形态挂到 AI 侧——这是它的主战场：标准化连接与权限边界。

6.2 核心差异（怎么接、成本从哪来）

社区与厂商文章里常提到：在 Token / 成本 和 可组合性 上，CLI 往往更轻；在 多系统集成、OAuth、企业审计与统一治理 上，MCP 更易做成产品线能力（例如 CircleCI 对 MCP 与 CLI 的对比、Firecrawl 的 Agent 场景选型）。具体倍数因任务与实现而异，不必迷信单一数字，但 「协议 + 全量 schema」带来的上下文压力 是结构性差异。

6.3 CLI 相对 MCP 更「占优」的典型场景

结合日常开发与本文工具特性，CLI 更值得优先的情况包括：

1. 脚本化与管道：搜索、格式化、再喂给下一步（bot-cli … \| jq …），与 Unix 哲学一致；MCP 更偏「IDE 内一站式」，而不是 shell 组合。
2. 调试与可重现：同一命令可脱离 Agent 单独执行，便于定位是模型指令错了还是环境/网络问题（这也是许多团队仍保留「CLI 作为真相来源」的原因）。
3. 非交互、机器可读输出：例如 --output json，Agent 只需约定少量 flag，而不必在上下文里长期挂载一整套 MCP tool 描述。
4. 内循环（inner loop）：个人本机、小团队、原型阶段——上线快、依赖少，不必先搭 MCP Server 与 Host 配置。
5. 模型对「命令」的先验强：训练数据里终端与常见 CLI（git、curl、kubectl 等）密度高，短命令 + 明确 stdout 契约 往往比塞一长段 schema 更省对话轮次与上下文。

业内也有「CLI is the new API」的说法：产品暴露稳定 CLI，比强迫每个集成方都实现 MCP Server 更容易被自动化与 Agent 消费——与本仓库「搜索能力 CLI 化 + JSON 模式」是同一思路。

6.4 MCP 仍然更合适时（避免误读成「否定 MCP」）

在需要 统一鉴权（如 OAuth）、多租户审计、跨应用实时拉取结构化资源、或 IDE 深度集成工具发现 时，MCP 的工程化收益明显。生态上也在缓解 token 压力：例如 按需加载工具、网关聚合、以及「把部分能力仍以子进程 CLI 落地」的混合架构——CLI 与 MCP 叠用 在 Cursor、Claude Code 等产品线里已很常见。

6.5 和本文项目的关系

search-bot-cli 选择 CLI + 可选 JSON 输出，本质是：用最小协议面（argv + stdout）服务人与 Agent，避免为了一次搜索在上下文里常驻大段工具定义；若未来要做「在 IDE 里一键搜 + 带鉴权的私有索引」，再考虑 MCP 或混合方案会更自然。

七、小结

• 终端 + React 并不是噱头：Ink 把状态、输入循环和布局表达得很接近前端日常经验，适合快速做出可用的 TUI。
• --output json 把同一能力开放给自动化与 AI 工具链，和「把能力做成 CLI 给 Agent 调用」的方向一致。
• CLI 与 MCP：简单可组合、低上下文契约的任务，CLI 往往更直接；复杂多源治理与 IDE 级集成，MCP 更对口——可按场景组合，而非二选一。
• 安装时认准：包名 search-bot-cli，命令 bot-cli。

若你对实现细节、DuckDuckGo 解析健壮性等话题感兴趣，欢迎在仓库提 Issue / 交流。

仓库地址： github.com/chenjiaobin…

写在前面

随着ChatGPT、通义千问等大语言模型的兴起，越来越多的开发者希望在自己的应用中集成AI能力，我决定通过实践来学习大模型API的调用方法。

我使用Python作为开发语言，采用阿里云百炼的通义千问模型（qwen3-max）作为基础模型，同时也体验了本地Ollama部署的qwen3:4b模型。

主题：围绕"科技资讯"这个方向，一步步实现文本分类、信息抽取、语义匹配三个常见场景。

1.环境准备

1.1 安装python

www.python.org/downloads/

验证 Python 环境是否安装成功

# 通用命令（推荐，所有系统兼容）
python3 --version
# 补充：Windows系统若已配置PATH，也可执行
python --version

验证 pip3（Python 包管理工具）pip3 是 Python3 默认的包管理工具类似于安装Nodejs中npm包管理工具，用于安装第三方库，验证命令：

# 通用命令
pip3 --version
# Windows补充命令
pip --version

安装成功

2. OpenAI 库的基础使用

Python 库已经成为了调用大模型的"事实标准"。不管是 OpenAI 官方、阿里云 DashScope、还是本地 Ollama，都提供了 OpenAI 兼容的接口。这意味着写一套代码，换个 base_url 就能切换模型。

2.1 安装openai

pip install openai

模型可以使用阿里云百炼，也可以使用 Ollama本地部署模型，先启动 Ollama 并拉取模型：

2.2 第一次调用OpenAI

最简单的调用只需要三步：创建 client → 构造 messages → 发起请求。

from openai import OpenAI

# 1. 创建 client 对象
client = OpenAI(
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
    # api_key="YOUR_API_KEY"  # 如果环境变量没配，这里需要手动传
)

# 2. 调用模型
response = client.chat.completions.create(
    model="qwen3-max",
    messages=[
        {"role": "system", "content": "你是一个科技资讯助手"},
        {"role": "user", "content": "2026年AI领域有哪些重要趋势？"},
    ]
)

# 3. 打印结果
print(response.choices[0].message.content)

api_key可以直接配置到全局环境变量中~./zshrc，就无需在创建client时明文传入了

export OPENAI_API_KEY="your key"
export DASHSCOPE_API_KEY="your key"

关键点拆解：

system 消息就像是给演员的"角色剧本"，告诉模型"你是谁、该怎么做"。assistant 消息可以用作 few-shot 示例，让模型"照着学"。

2.3 流式输出：让用户体验"打字机"效果

非流式调用会等模型全部生成完才返回，用户可能要等十几秒。开启 stream=True 后，模型每生成一段就返回一段，实现类似 ChatGPT 的打字机效果。

from openai import OpenAI

client = OpenAI(
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)

response = client.chat.completions.create(
    model="qwen3-max",
    messages=[
        {"role": "system", "content": "你是一个科技资讯助手，回答问题时请简洁"},
        {"role": "user", "content": "什么是大语言模型？用一句话解释"},
    ],
    stream=True     # 开启流式输出
)

# 流式返回的结果需要遍历 chunk
for chunk in response:
    print(chunk.choices[0].delta.content, end="", flush=True)

流式处理要点：

• chunk.choices[0].delta.content 是每一小段文本，可能是几个字或一个词
• end="" 避免 print 自动换行，flush=True 立即刷新到终端
• 第一个 chunk 的 delta.content 可能为 None，生产环境需要做空值判断

2.4 附带历史消息：让模型"记住"上下文

大模型本身是无状态的，每次调用都是独立的。要实现多轮对话，需要把之前的消息一起发过去。

from openai import OpenAI

client = OpenAI(
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)

# 把之前的对话历史全部带上
response = client.chat.completions.create(
    model="qwen3-max",
    messages=[
        {"role": "system", "content": "你是科技资讯助手，回答简洁"},
        {"role": "user", "content": "英伟达最新一代GPU是什么？"},
        {"role": "assistant", "content": "英伟达最新一代数据中心GPU是Blackwell架构的B200。"},
        {"role": "user", "content": "它比上一代性能提升多少？"},   # 这个问题依赖上文
    ],
    stream=True
)

for chunk in response:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

为什么需要历史消息？ 第二个问题"它比上一代性能提升多少？"中的"它"指代的是前面提到的 B200。如果不带上历史消息，模型就不知道"它"是谁。

3. 提示词优化实战

提示词（Prompt）决定了模型的输出质量。下面通过三个实战案例，展示几种最常用且效果立竿见影的提示词优化技巧。

统一主题：所有案例都围绕"科技资讯处理"场景，包括科技文章分类、关键信息抽取、语义相似度判断。

3.1 案例一：科技文本分类（Few-Shot 提示）

场景：给定一段科技相关的文本，自动判断它属于哪个类别。

核心思路：Few-Shot Learning

直接让模型分类，它可能按自己的理解来。但如果给它几个"输入→输出"的示例，它就能照葫芦画瓢，准确率大幅提升。这就是 Few-Shot Prompting。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1"  # 本地 Ollama
)

# 示例数据：类别 → 文本
examples_data = {
    'AI前沿': 'OpenAI今日发布了GPT-5，该模型在多项基准测试中超越前代，特别是在数学推理和代码生成方面表现突出。',
    '产品发布': '苹果公司在WWDC上正式推出了Vision Pro二代，售价降低至2000美元，新增手势追踪和眼动交互功能。',
    '行业分析': '据IDC最新报告，2025年Q2全球AI芯片市场规模达到180亿美元，同比增长65%，其中GPU占比超过70%。',
    '投融资': 'AI编程助手Cursor完成1亿美元C轮融资，估值达到100亿美元，红杉资本领投。'
}

# 待分类的文本
questions = [
    "今日，华为在开发者大会上发布了HarmonyOS NEXT正式版，全面支持纯血鸿蒙应用生态，不再兼容Android应用。",
    "据市场分析机构Gartner预测，到2026年全球企业级AI软件支出将突破5000亿美元，SaaS和AI Agent是主要增长点。",
    "字节跳动旗下豆包大模型团队宣布开源新一代多模态模型，支持文本、图像和视频的联合理解与生成。",
    "今天天气真不错，适合出去散步。"  # 干扰项，不属于任何科技类别
]

# 构造 messages：system 说明任务 + 示例对话
messages = [
    {
        "role": "system",
        "content": "你是科技资讯专家，请将文本分类为['AI前沿', '产品发布', '行业分析', '投融资']之一，不属于任何类别的回答'不清楚类别'。以下是示例："
    },
]

# 把示例数据转为 user/assistant 对话对
for category, text in examples_data.items():
    messages.append({"role": "user", "content": text})
    messages.append({"role": "assistant", "content": category})

# 批量分类
for q in questions:
    response = client.chat.completions.create(
        model="qwen3:4b",
        messages=messages + [{"role": "user", "content": f"请分类：{q}"}]
    )
    print(f"文本: {q[:30]}... → 类别: {response.choices[0].message.content}")

消息构造示意图：

messages 最终结构：
┌─────────────────────────────────────────────────┐
│ system: 你是科技资讯专家，请分类为[...]            │
│ user:   OpenAI今日发布了GPT-5...                  │
│ assistant: AI前沿                                │
│ user:   苹果公司在WWDC上正式推出...                 │
│ assistant: 产品发布                               │
│ user:   据IDC最新报告...                          │
│ assistant: 行业分析                               │
│ user:   AI编程助手Cursor完成...                    │
│ assistant: 投融资                                 │
│ user:   请分类：今日，华为在开发者大会上...         │  ← 实际要分类的
└─────────────────────────────────────────────────┘

3.2 案例二：科技信息抽取（结构化输出）

场景：从一篇科技新闻中提取关键字段（日期、公司名、产品名、金额等），并以 JSON 格式返回。

核心思路：JSON 结构化输出 + Few-Shot 示例

直接让模型"提取信息"，它可能返回自然语言描述。但如果要求它输出 JSON，并在示例中展示格式，它就能稳定返回结构化数据，方便后续程序处理。

from openai import OpenAI
import json

client = OpenAI(base_url="http://localhost:11434/v1")

# 定义要抽取的字段
schema = ['日期', '公司名称', '产品名称', '融资金额', '投资方']

# 示例数据
examples_data = [
    {
        "content": "2025年3月15日，AI编程公司Cursor宣布完成1亿美元C轮融资，由红杉资本领投，Andreessen Horowitz跟投。该公司主打产品Cursor AI Editor已成为开发者热门工具。",
        "answers": {
            "日期": "2025年3月15日",
            "公司名称": "Cursor",
            "产品名称": "Cursor AI Editor",
            "融资金额": "1亿美元",
            "投资方": "红杉资本、Andreessen Horowitz"
        }
    },
    {
        "content": "昨日，华为在深圳总部正式发布Mate 70系列手机，搭载全新麒麟9100芯片，起售价5499元。",
        "answers": {
            "日期": "昨日",
            "公司名称": "华为",
            "产品名称": "Mate 70系列",
            "融资金额": "原文未提及",
            "投资方": "原文未提及"
        }
    }
]

# 待抽取的文本
questions = [
    "2025年6月1日，月之暗面科技宣布完成10亿元人民币B轮融资，高榕资本独家领投，公司将用于Kimi智能助手的产品迭代。",
    '特斯拉于上海超级工厂投产了搭载HW5.0芯片的新一代自动驾驶硬件，马斯克称这是"史上最大升级"。'
]

# 构造 messages
messages = [
    {
        "role": "system",
        "content": f"你是信息抽取专家。请从文本中提取 {schema} 这些字段，以JSON格式输出。如果某字段信息不存在，填'原文未提及'。参考以下示例："
    },
]

# 追加示例
for example in examples_data:
    messages.append({"role": "user", "content": example["content"]})
    messages.append({
        "role": "assistant",
        "content": json.dumps(example["answers"], ensure_ascii=False)
    })

# 批量抽取
for q in questions:
    response = client.chat.completions.create(
        model="qwen3:4b",
        messages=messages + [{"role": "user", "content": f"请抽取以下文本的信息：{q}"}]
    )
    result = response.choices[0].message.content
    print(f"原文: {q[:40]}...")
    print(f"抽取结果: {result}\n")

关键技巧：

1. 明确字段列表：在 system 消息中列出要抽取的所有字段
2. JSON 格式约束：要求模型输出 JSON，方便后续 json.loads() 直接解析
3. 缺失值处理：约定"原文未提及"作为默认值，避免模型编造信息
4. 示例中展示完整格式：模型会严格模仿示例的 JSON 结构

实际使用中，拿到结果后建议用 json.loads() 验证一下，确保返回的是合法 JSON：

parsed = json.loads(result)
print(parsed["公司名称"])  # 直接按 key 取值

3.3 案例三：科技文本匹配判断（对比推理）

场景：给定两句话，判断它们描述的是否是同一件事/同一主题。这在资讯去重、推荐系统等场景很常见。

核心思路：正负示例对比 + 格式化输入

让模型判断两句话是否"匹配"，关键是要给它正面示例（匹配）和负面示例（不匹配），让它学会区分。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1")

# 正负示例
examples_data = {
    "是": [   # 这两句说的是同一件事
        ("英伟达发布Blackwell架构B200芯片，性能比H100提升30倍。", "英伟达推出新一代GPU B200，采用Blackwell架构，性能远超H100。"),
        ("字节跳动旗下豆包大模型团队宣布开源新一代多模态模型。", "豆包团队开源了多模态大模型。"),
    ],
    "不是": [  # 两句话各说各的
        ("英伟达股价今日下跌5%。", "苹果宣布Vision Pro二代正式发布。"),
        ("特斯拉上海工厂开始生产HW5.0芯片。", "SpaceX星舰完成第六次试飞。"),
    ]
}

# 待判断的文本对
questions = [
    ("华为发布HarmonyOS NEXT正式版，不再兼容Android。", "纯血鸿蒙系统正式发布，安卓应用将无法运行。"),
    ("AI芯片市场Q2增长65%。", "AI编程助手Cursor完成1亿美元融资。"),
    ("小米SU7交付量突破10万台。", "小米汽车市场表现强劲，累计交付超10万辆SU7。"),
]

# 构造 messages
messages = [
    {
        "role": "system",
        "content": "你帮我完成文本匹配判断。我会给你两个句子，用[]包围，请判断它们是否描述同一件事，只回答'是'或'不是'。参考以下示例："
    },
]

# 追加正负示例
for label, pairs in examples_data.items():
    for s1, s2 in pairs:
        messages.append({"role": "user", "content": f"句子1：[{s1}]，句子2：[{s2}]"})
        messages.append({"role": "assistant", "content": label})

# 批量判断
for s1, s2 in questions:
    response = client.chat.completions.create(
        model="qwen3:4b",
        messages=messages + [{"role": "user", "content": f"句子1：[{s1}]，句子2：[{s2}]"}]
    )
    print(f"句子1: {s1[:35]}...")
    print(f"句子2: {s2[:35]}...")
    print(f"匹配结果: {response.choices[0].message.content}\n")

关键技巧：

1. 用 [] 包裹句子：让模型清楚知道哪里是句子边界，避免混淆
2. 正负示例均衡：匹配和不匹配的例子各给几个，防止模型偏向某一方
3. 约束输出：要求"只回答'是'或'不是'"，避免模型输出多余解释

4. 核心知识点总结

4.1 OpenAI SDK 调用流程

不管什么场景，调用流程都是固定的三步：

# 第一步：创建 client
client = OpenAI(base_url="xxx", api_key="xxx")

# 第二步：构造 messages 并调用模型
response = client.chat.completions.create(
    model="模型名",
    messages=[...],
    stream=True/False
)

# 第三步：处理结果
# 非流式：response.choices[0].message.content
# 流式：遍历 response，每次取 chunk.choices[0].delta.content

4.2 提示词优化的三个实用技巧

4.3 本地 vs 云端模型选择

4.4 JSON 基础回顾

提示词优化案例中频繁用到 JSON 序列化/反序列化，这里简单回顾：

import json

# dict → JSON 字符串
data = {"name": "张三", "age": 25}
json_str = json.dumps(data, ensure_ascii=False)
# '{"name": "张三", "age": 25}'

# JSON 字符串 → dict
parsed = json.loads(json_str)
# {'name': '张三', 'age': 25}

# list → JSON 字符串
items = [{"name": "A"}, {"name": "B"}]
json.dumps(items, ensure_ascii=False)
# '[{"name": "A"}, {"name": "B"}]'

ensure_ascii=False 很重要，否则中文会被转成 \uXXXX 编码，不方便阅读和调试。

写在最后

我们做的，并不只是“调用一个大模型 API”，而是在尝试一种新的开发方式。

过去，我们习惯用代码去精确描述规则，而现在，我们开始用自然语言去“定义能力”。

这两者的区别在于：

• 代码解决的是确定性问题
• 大模型更擅长处理模糊、复杂、难以穷举规则的问题

前言

去年花了半年时间对公司旧业务代码做了不少架构优化，今年开始陆续就要开始业务开发了。

不得不说在 AI 时代背景下，开发范式每天都在变化，prompt engineering -> context engineering -> agent engineering -> harness engineering，一路狂飙，看似每天都有新东西要学习，到最后大多都是 FOMO。

然而在显而易见的不确定性面前，总有一些东西是固定不变的。今天我来分享在 AI 冲击下我的前端 Agent 开发配置，这些内容个人认为属于长期不变的地基。

（本文以 Mac 为例）

基本工具

首先是两个配置工具：

1. cc-switch
2. skills.sh

前者用于接入不同 AI 供应商，例如业内熟知的 Claude、Codex、Gemini、OpenCode 等等；后者用来添加 skills，一些固定的工作流被总结为技能供模型识别和调用。

CC Switch

安装

以 Homebrew（macOS）为例：

brew tap farion1231/ccswitch
brew install --cask cc-switch

# 更新
brew upgrade --cask cc-switch

其他平台也可以在 Release 找到对应的安装包。

更新

APP 的关于页可以检查更新、同时还兼具了本地环境检查：

我觉得特别好的一点就是还提供了一键安装的脚本：

以往我都是要去官方文档上找，这里一键复制更方便。

设置 Skills 存储位置

打开「设置 > 通用」面板，修改如下：

默认情况下，Skills 被存储在 ~/.cc-switch/skills/ 下，换成 ~/.agents/skills/，因为 skills.sh 的脚本安装的 skills 默认也是后者，这遵循了 Agent Skills 开放标准，很多 Agent 都能主动发现此处的 skills。

设置自动故障转移

打开「设置 > 路由」面板，依次打开本地路由、自动故障转移的开关：

回到 APP 首页打开两个开关：

下面可以选择需要加入的服务，按照优先级每次使用 cc 时会先用高优先级的，出现熔断就会退到下一级：

开启用量查询

以 kimi code 为例，点击列表中某项的用量查询：

在预设模板中找到合适的配置：

回到首页可以看到能够自动查询用量了：

点击顶部图标也能看到用量：

Skills 和 MCP

Skills 和 MCP 在右上角：

Skills

Skills 管理面板中，比较常用的是「导入已有」，然后点亮需要加入该 skill 的 Agent 工具：

点击「发现技能」可以搜索开头我们提到的 skills.sh 中的技能，下面以 code-simplifier 为例：

点击安装就能加入 Skills 列表。

这和在 skills.sh 上获取安装指令是一样的：

需要注意的是，使用命令行安装时默认安装到 ~/.agents/skills/ 下，想要同时支持 cc，就要自己勾选：

npx skills add https://github.com/ant-design/ant-design-cli --skill antd

通用的放全局：

安装方式推荐使用 Symlink：

安装完成后，命令行输入 claude 打开 cc，看到如下界面说明 CC Switch 的配置是有效的，一定要选 Yes，否则会让登录官方的账号：

输入 /skills 可以看到 antd skill 确实被安装进来了：

gemini、codex、opencode 也有：

刚刚安装列表中的 kimi 也有：

而未主动选择的 kilo 没有该技能：

在 Skills 管理中可以导入已有技能：

注意：由于 codex、gemini、opencode 都能从 ~/.agents/skills/ 下读取到技能，即便在 CC Switch 中取消引用，还是能搜到；cc 从 ~/.claude/skills/ 下读取技能，关闭了引用就搜不到了。

总结一下，如果按照我说的修改了 Skills 存储位置，那么想要 cc 加入对应 skill 就打开对应 skill 开关，其他剩下几个 Agent 开不开都可以。

MCP

MCP 服务器管理面板没有 Skills 那么复杂，且功能类似，大家可以自己研究下。

（其实是不想写了，哈哈）

Skills、MCP 推荐

Skills、MCP 都装了不少，但是本着如无必要、勿增实体的原则，最低限度推荐以下几个：

Skills：

• vercel-react-best-practices
• antd
• caveman

MCP：

• playwright-mcp
• Figma MCP
• context7

「人红是非多」，Hermes Agent 最近真的火了，一边是 GitHub 积累了超过 8 万星，增长趋势完全是直线上升。

另一边是来自国内开发者的公开指责，说 Hermes Agent 是抄袭了他们的项目 EvoMap，Hermes Agent 的负责人在 X 上回应，表示这是无中生有，从没听说过有 EvoMap 这个项目。

双方都僵持不下，但无论是 EvoMap 所提出的三层记忆系统、主动学习，还是 Hermes Agent 内一样的逻辑架构与核心概念，这种形态的 Agent 或许在此刻都比 OpenClaw 更值得关注。

之前 APPSO 介绍过 Hermes Agent 的基本情况，以及与 OpenClaw 的差别。

它最大的特点就是能自动学习进化，把我们反复用的流程，自动保存为可复用的技能；每一次的任务，都会自动从里面总结经验，是一个用的越多越顺手的 Agent。

目前 MiniMax 已经推出了 MaxHermes，能让我们在云端「无痛养马」，腾讯云也推出了一键部署到其轻量服务器上的 Hermes Agent 应用模板。

Hermes 也从「这东西牛不牛」来到了「这玩意怎么装，装完怎么用」的阶段。这篇文章，APPSO 手把手教大家在自己的电脑上安装 Hermes Agent，并上手用简单的例子来说明它和 OpenClaw 的不同。

这次安卓手机也能养马

和 OpenClaw 不同的是，Hermes Agent 不支持单纯的 Windows 系统。如果我们想要在 Windows 电脑上使用 Hermes Agent 必须先安装 WSL2，WSL 是 Windows Subsystem for Linux 的简称，它允许用户在 Windows 上运行 Linux 操作系统。

苹果表示在这波的本地 AI Agent 大战里，不用下场做大模型做产品，也吃到了 AI 最大红利。

不过，Hermes Agent 支持安卓手机，通过 Termux 应用，一台不需要 root 的闲置安卓手机，直接就能变成一台随身 Linux 服务器。

Termux 是一个运行在 Android 手机上的「终端模拟器 + Linux 环境」，项目在 GitHub 上开源，目前已经获得了 5 万星。

我们可以简单地把它理解成在安卓里开了一个接近 Linux 的命令行世界；不用 root，也能安装很多常见开发工具、能像在服务器上一样敲命令、装软件、跑脚本。

在 Hermes Agent 的官方文档里，有一栏专门用来介绍如何在 Android 系统上使用 Termux 运行，我们只需要在手机上安装好 Termux 应用之后，其他操作和电脑类似，部分的功能像 Docker 隔离、后台常驻、语音能力会受限制。

本地安装之外的选项，云端部署则是和 OpenClaw 一样，目前腾讯云已经宣布率先支持 Hermes Agent 一键部署，通过旗下轻量应用服务器 Lighthouse 内的 Hermes Agent 应用模板。

仿佛过去的记忆在又一次敲打我，接下来大概是各家的云平台，都逐渐推出相关的一键接入服务。

MiniMax 在今天也宣布推出第一个云端沙箱 Hermes，MaxHermes。和 MaxClaw 的体验类似，我们需要订阅 MiniMax 付费计划，同时连接 MiniMax Token Plan，完成两项升级后才能在 MiniMax 上部署 MaxHermes。

从安装到连接飞书/微信/QQ，只要五分钟

打开终端（macOS 用 Terminal，Windows 用 WSL2），粘贴这一行命令。

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

它会自动处理好所有依赖——Python、Node.js、ripgrep、ffmpeg，以及 Hermes 本体。不需要你提前安装任何东西。

等它跑完，再执行，

source ~/.bashrc

这一步是让终端认识新装的 hermes 命令，如果跳过，下一步执行 Hermes，会报错「找不到命令」。整个安装过程大约两到三分钟，取决于网速。

安装完成之后是和 OpenClaw 类似的配置阶段。我们需要配置模型 API，选择对应的模型供应商，并复制粘贴 API。以及选择连接何种即时通讯软件，微信、QQ、企业微信等。

这些配置可以在之后的 Hermes setup 命令下再次进入，这里我们演示一遍按照 Hermes Agent 推荐的流程进行设置。

关于模型，第一项 Nous Portal 是 Hermes Agent 公司所推出的 API 订阅方案。目前小米 MiMo V2 模型可以透过 Nous Portal 连接，免费使用到本月 22 号。

其余的 OpenRouter、OpenAI Codex、Kimi、MiniMax、智谱 Z.ai 等，都可以在对应的模型开放平台，订阅相关的 Token Plan 之后，创建专门用于 Hermes Agent 的 API。

使用 Nous Portal 服务，必须先订阅 Nous Research 计划，才能免费使用小米 MiMo 模型。这里可以选择免费计划，每月 0 元。不过即便是 0 元的订阅计划，也需要使用 Stripe 完成支付，必须有一张 VISA/万事达的信用卡，才能完成订阅。

选择了模型供应商之后，继续选择 Hermes Agent 使用的具体模型。Nous Portal 支持的模型非常多，免费的小米 MiMo V2 Pro 需要滑动到最下面的位置才能看到。

继续设置聊天平台，目前最新的 Hermes Agent 版本已经支持了钉钉、飞书、企业微信、微信、QQ、iMessage，以及 Telegram 等常见聊天平台。

不同的平台配置方式不同，按照 Hermes Agent 推荐的操作执行。如果你选择飞书，它会给我们一段链接，要求在手机飞书，或者飞书网页版内打开，打开后是自动创建机器人的界面，创建完成，选择默认操作，就连接成功了。

在飞书应用内，和机器人发起聊天，机器人会回复一条要求执行 hermes pairing approve feishu XXXXXXX 的消息，将这行命令复制到终端里执行，我们就能在飞书内和 Hermes Agent 聊天。

一切配置完成，在终端里输入 hermes，这匹马就算是牵到了我们电脑里。

询问它能为我们做点什么，可以看到它可以执行的操作，包括终端命令、文件操作、网页交互、代码执行、任务管理、记忆和技能、会话回溯、后台作业、子代理等多个功能。

在最新版本的 Hermes Agent，也提供了可视化、界面友好的控制台，可以让我们不用在终端里，完成一切的操作。在终端里输入 hermes dashboard，会自动打开一个地址为：http://127.0.0.1:9119 的本地网页。

用的越多，越省事

安装很容易，怎么用好 Hermes Agent，才能感受到它和 OpenClaw 最大的差别。

我们现在用 AI 的逻辑，无论是 OpenClaw 还是 ChatGPT，本质上还是我们输入，AI 输出，关掉对话，任务就结束。

Hermes 要改掉的就是这件事，有着和 OpenClaw 同样多的功能，另外还有会自动累积的记忆，会生长的能力。每一次交互，它都在变得更了解我们，偏好、工作方式、我们反复做的那些事。

例如我们简单地在 Hermes 里面告诉它要求设计一个老少皆宜的益智类小游戏，并且在后续的交流中告诉它要多设计一些关卡，有难度的区分，界面要更精美等。

这轮任务结束，我们问 Hermes，要它说说我的用户画像是什么。它很快就从上一个做益智小游戏的项目里，定位到我使用中文交流、表达直接具体、注重细节和精致度等特点。

和大部分 AI Agents 所使用的关键词检索不同，Hermes 使用的是语义相似性的向量查询，它会根据「基于之前的反馈进行迭代改进」，得到我重视反馈循环，并将这一点放进用户画像内。

基于 Hermes 的持久记忆和累积学习，用它来搭建知识库是再合适不过。

我们使用 Hermes 内置的 LLM-Wiki Skill，结合 Obsidian 笔记平台和飞书，在手机上把自己想到的任何事情，发给飞书，Hermes 就会自动帮我们把这些碎片的内容整理成知识库，并在 Obsidian 内以结点的形式呈现。

这里我们告诉它创建一个类似于我的「第二大脑」的知识库，我会把我看到的好文章、有意思的选题、素材统统发给它，Hermes 需要帮助我整理。

当把文章发送给 Hermes 之后，我们在 Obsidian 里面立刻能看到它的处理，把文章的要点总结，同时下载文章全文到 raw 文件夹内的 article 分类下，同时会自动处理不同的概念和主题，彻底贯彻 Wiki 的逻辑。

在 Hermes Agent 里还有许多 Skills，我们在安装时，就已经内置了有 79 个 Skills。官方的 Skills Hub 显示目前提供了 16 个类别，来自 Anthropic、Lobe Hub 等社区公开的 Skills 平台，共计 521 个 Skills。

这些 Skills 涵盖了从日常的生产力工具，到代码审查、PPT、PDF、OCR、YouTube 转写，再到模型微调、vLLM 部署、Stable Diffusion、Whisper、音乐生成，几乎把「数字办公 + 开发 + 创作 + AI 工程」串成了一整套工作流。

例如我们可以直接使用 manim-video.skill，在 Hermes Agent 内就能创建一个简单的视频。

多 Agents 协作也是现在的热门玩法，在 Hermes Agent 内，我们可以用 Profiles（配置文件） 来跑多个独立 Agent。每个 profile 都是一个完全隔离的 Hermes 环境，有自己单独的个性化设置，像是网关、SOUL.md、记忆、SKills 以及环境变量等。

也就是说，我们可以同时有一个写代码的 Agent、一个研究用的 Agent、一个私人助理 Agent，它们互不污染。通过定义的流程，这些 Agents 能在 Hermes 里面形成多 Agent 工作流。

在 Hermes Agent 的官方文档内，有相当多的 Hermes 指令和教程，还有一篇专门教大家如何从 OpenClaw 迁移到 Hermes 的文章。

如果你想从 OpenClaw 转到 Hermes，按照官方教程，三行命令就能快速迁移。

一键卸载指南

装到一半发现不知道怎么继续，或者使用了一段时间觉得不行，想要卸载也很简单。

官方提供了一键卸载命令 hermes uninstall，在终端运行之后，我们会看到保留数据、完全卸载和取消三个选项。

其中保留数据会将 Hermes Agent 的相关配置，像是模型的 API、以及连接到不同第三方通讯工具的 API 保留，只是将整个框架删除。我们可以直接输入 2，表示完全卸载。

如果仍然不放心，回到初始的终端页面，执行下面这三行命令，也会将电脑上所有关于 Hermes Agent 的内容全部删除。

rm -f ~/.local/bin/hermes
rm -rf /path/to/hermes-agent
rm -rf ~/.hermes

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

Claude Code 可以通过 -p 标志、权限绕过、循环模式和终端持久化的组合，实现数小时甚至整夜的无人值守运行。 开发者社区已经形成了一套可靠的操作手册：容器化运行环境、使用 “Ralph Wiggum” 循环模式、安装四个关键 Hook 防止卡死、保持 CLAUDE.md 精简。有开发者记录了 27 小时连续自主会话完成 84 个任务；另一位在睡觉时让 Claude 构建了一个 15,000 行的游戏。但社区也反馈，大约 25% 的过夜产出会被丢弃，而且如果没有适当的防护措施，Claude 曾在至少一位开发者的机器上执行过 rm -rf /。以下是你今晚就能用上的完整设置方案。

一、消除人工干预的三种模式

Claude Code 提供三个级别的自主运行模式，每个级别都在安全性和速度之间做取舍。理解它们是所有过夜方案的基础。

模式 1：-p（print/pipe）标志 —— 所有自动化的核心。 这是非交互式运行模式。接收 prompt，执行到完成，输出到 stdout，然后退出。无需 TTY，512MB 内存的服务器也能跑。

1

claude -p "查找并修复 auth.py 中的 bug" --allowedTools "Read,Edit,Bash"

模式 2：--permission-mode auto —— 更安全的折中方案。 2026 年初推出，使用 Sonnet 4.6 分类器自动批准安全操作，同时阻止高风险操作。分类器分两阶段运作：快速判定（8.5% 误报率），对标记项目进行思维链推理（0.4% 误报率）。如果连续 3 次操作被拒绝或单次会话累计 20 次被拒，系统会升级到人工介入——或者在 headless 模式下直接终止。

1

claude --permission-mode auto -p "重构认证模块"

模式 3：--dangerously-skip-permissions —— 完全绕过权限。 所有操作无需确认直接执行。Anthropic 自己的安全研究员 Nicholas Carlini 也使用这个模式，但有一个关键前提：*”在容器里跑，不要在你的真实机器上。”* 一项调查发现 32% 的开发者使用这个标志时遭遇了意外的文件修改，9% 报告了数据丢失。

1
2

# 仅限 Docker/VM —— 绝对不要在宿主机上运行
claude --dangerously-skip-permissions -p "构建这个功能"

推荐的过夜运行方式是将 -p 与细粒度工具白名单 --allowedTools 结合使用，允许特定命令而非授予全面访问权限：

1
2
3
4

claude -p "修复所有 lint 错误并运行测试" \
 --allowedTools "Read" "Edit" "Bash(npm run lint:*)" "Bash(npm test)" "Bash(git *)" \
 --max-turns 50 \
 --max-budget-usd 10.00

--max-turns 和 --max-budget-usd 是无人值守会话的必备成本控制手段。没有它们，一个失控的循环可以在几分钟内烧光你的 API 预算。

二、Ralph Wiggum 循环：开发者的实际过夜方案

最经过实战验证的长时间自主工作模式是 Ralph Wiggum 循环——以《辛普森一家》中的角色命名，现已成为 Anthropic 官方插件。概念非常简单：一个 bash while 循环持续向 Claude 喂相同的 prompt。每次迭代中，Claude 查看当前文件状态和 git 历史，选择下一个未完成的任务，实现它，然后提交。

1
2
3
4
5

while true; do
 claude --dangerously-skip-permissions \
 -p "$(cat PROMPT.md)" 
 sleep 1
done

那位记录了 27 小时会话 的开发者使用了这个模式，配合一个详细的 prompt 文件，包含架构说明、目标、约束条件和明确的”完成”标准。他的核心发现：*”一句话 prompt 在一两个小时后就没劲了。27 小时的会话能持续下去，是因为 prompt 文件有足够多的上下文。”*

Prompt 文件比循环本身更重要。 一个有效的过夜 PROMPT.md 示例：

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

# 任务：测试并加固认证系统

## 上下文
- 后端：Express + TypeScript，位于 src/api/
- 数据库：PostgreSQL，schema 在 prisma/schema.prisma
- 认证流程：JWT 中间件在 src/middleware/auth.ts

## 目标
- 查看 docs/plan.md，选择下一个未完成的任务
- 实现它，包含完善的错误处理
- 运行测试，修复失败，确认没有回归
- 做通用修复，不要打临时补丁
- 每完成一个任务后用描述性消息提交

## 成功标准
- 每次修改后所有测试通过
- 不会引入之前修复的回归
- 当 plan.md 中所有任务完成后输出 DONE

社区有几个工具扩展了这个基础循环。Ralph CLI 增加了速率限制（100次调用/小时）、熔断器、会话过期（默认24小时）和实时监控仪表板。Nonstop 增加了飞行前风险评估和阻塞决策框架——走之前输入 /nonstop 即可。Continuous-claude 自动化完整 PR 生命周期：创建分支、推送、创建 PR、等待 CI、合并。

三、防止过夜灾难的四个 Hook

开发者 yurukusa 记录了 108 小时无人值守运行，识别出七类过夜事故——包括 Claude 执行 rm -rf ./src/、进入无限错误循环、直接推送到 main 分支，以及产生每小时 8 美元的 API 费用。解决方案：四个关键 Hook，共同预防最常见的故障模式。

10 秒快速安装：

1

npx cc-safe-setup

Hook 1：No-Ask-Human 阻止 AskUserQuestion 工具调用，强制 Claude 自主做出决定，而不是坐在那里等几小时等人回复。这个 Hook 决定了 Claude 是整夜工作还是在晚上 11:15 卡住。在你坐在电脑前时，用 CC_ALLOW_QUESTIONS=1 覆盖。

Hook 2：Context Monitor 将工具调用次数作为上下文使用量的代理指标，在四个阈值（剩余 40%、25%、20%、15%）发出分级警告。在临界水平时，配套的空闲推送脚本会自动向终端注入 /compact 命令——两个进程，共 472 行代码，零人工干预。

Hook 3：Syntax Check 在任何文件编辑后立即运行 python -m py_compile、node --check 或 bash -n，在错误级联成 50 次调试之前就捕获它们。

Hook 4：Decision Warn 在执行前标记破坏性命令（rm -rf、git reset --hard、DROP TABLE、git push --force）。通过 CC_PROTECT_BRANCHES="main:master:production" 配置受保护分支。

在 .claude/settings.json 中配置：

1
2
3
4
5
6

{
 "permissions": {
 "allow": ["Bash(npm run lint:*)", "WebSearch", "Read"],
 "deny": ["Read(.env)", "Bash(rm -rf *)", "Bash(git push * main)"]
 }
}

四、tmux 设置与保持机器不休眠

Claude Code 的交互模式需要 TTY —— 不能用 nohup 或将其作为 systemd 服务运行（大约 15-20 秒后会因 stdin 错误崩溃）。tmux 是会话持久化的必备工具。

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

# 启动命名会话
tmux new -s claude-work

# 在其中启动 Claude
claude --permission-mode auto

# 分离（Claude 继续运行）：Ctrl+B，然后按 D

# 从任何地方重新连接（SSH、手机 Termius 等）
tmux attach -t claude-work

# 不连接就查看进度
tmux capture-pane -t claude-work -p -S -50

对于真正的 7×24 运行，社区推荐 VPS + Tailscale + tmux 方案：便宜的 VPS（Hetzner、Vultr、DigitalOcean）提供永不关机的算力，Tailscale 提供私有网络，mosh 在不稳定网络上保持连接持久性。给 Claude 一个任务，分离，合上笔记本，明天再回来。

macOS 防止休眠：

1
2
3
4
5

# 绑定到 Claude 进程
caffeinate -i -w $(pgrep -f claude) &

# 或者在接通电源时全局禁用休眠
sudo pmset -c sleep 0

管理多个并行会话方面，Amux 是一个约 12,000 行的 Python 文件，提供 Web 仪表板、手机 PWA 监控、自愈看门狗（自动重启崩溃会话）、按会话 token 追踪和 git 冲突检测。Codeman 提供类似的 Web UI，带 xterm.js 终端，支持最多 20 个并行会话。

一个强大的过夜 agent tmux 配置：

1
2
3
4
5
6
7
8
9

#!/bin/bash
tmux new-session -d -s claude-dev
tmux rename-window -t claude-dev:0 'Claude'
tmux new-window -t claude-dev:1 -n 'Tests'
tmux new-window -t claude-dev:2 -n 'Logs'
tmux send-keys -t claude-dev:0 'claude --permission-mode auto' Enter
tmux send-keys -t claude-dev:1 'npm run test:watch' Enter
tmux send-keys -t claude-dev:2 'tail -f logs/app.log' Enter
tmux attach-session -t claude-dev

五、CLAUDE.md 与长时间运行的上下文管理

过夜失败的最大原因是上下文窗口耗尽。Claude Code 的上下文窗口大约 200K token，使用率超过 70% 时性能开始下降。自动压缩在接近阈值时触发，但会丢失信息——仅保留 20-30% 的细节。有开发者报告 Claude 压缩后遗忘了所有内容，重新开始同一个任务，浪费了三个小时。

解决方案是检查点/交接模式，能够在上下文重置后存活：

1
2
3
4
5
6

# 在 CLAUDE.md 中
当上下文变大时，将当前状态写入 tasks/mission.md。
包括：已完成的、下一步的、被阻塞的、未解决的问题。
错误处理：最多重试 3 次。如果没有进展，记录到
pending_for_human.md 然后转到下一个任务。
压缩前，务必保存完整的已修改文件列表。

将 CLAUDE.md 控制在 200 行以内——每个词在每个会话中都消耗 token。从 800 行切换到 100 行的开发者达成社区共识：更短的配置实际上表现更好，因为 Claude 不会忽略被噪音淹没的指令。使用”仅在不可逆时才提问”规则，将提问频率降低约 80%：

1
2
3
4
5
6

# 自主运行的决策规则
- 技术方案不确定 → 选择传统方案
- 两种可行实现 → 选择更简单的那个
- 尝试 3 次后仍有错误 → 记录到 blocked.md，切换任务
- 需求模糊 → 应用最合理的理解，记录假设
- 永远不要提问。做出最佳判断然后继续。

CLAUDE.md 文件是分层的：~/.claude/CLAUDE.md（全局）、./CLAUDE.md（项目级，git 追踪）、.claude/CLAUDE.local.md（个人覆盖，gitignore）。自主运行时，全局文件保持最小，把运行特定指令放在项目文件中。

关键 token 节省技巧：在里程碑后主动使用 /compact，而非等待自动压缩；对独立任务使用子 agent（每个有自己的上下文窗口）；不相关的工作启动新会话；积极使用 .claudeignore 排除无关文件。

六、过夜运行的速率限制处理

速率限制作为三个独立的、重叠的约束运作：每分钟请求数、每分钟输入 token 数、每分钟输出 token 数。一个可见的命令在内部可能产生 8-12 个 API 调用（lint、修复、测试、修复循环）。15 次迭代后，单个请求可能发送 20 万+ 输入 token。

过夜运行速率限制生存策略：

在非高峰时段运行。 Anthropic 确认工作日太平洋时间早 5 点到 11 点限制更严格。过夜运行和周末会话完全避开高峰期限流——恰好就是你在睡觉的时候。

利用 Ralph 循环的内置重试。 运行 while 循环时，速率限制错误只会导致当前迭代失败，但循环不在乎——它在速率限制窗口重置后的下一次迭代中重试。有开发者警告：*”不要在 API/按用量计费模式下运行——重试会烧光你的预算。”*

运行中切换模型。 Sonnet 能处理 60-70% 的常规任务，每 token 成本比 Opus 低约 1.7 倍。过夜工作设置 --model sonnet，将 Opus 留给复杂推理。也可以设置 --fallback-model sonnet，让 Claude 在主模型过载时自动降级。

Token 消耗的真实数据：20 条消息会话消耗约 105,000 token；30 条消息会话跳到 232,000 token。大约 98.5% 的 token 花在重新读取对话历史——只有 1.5% 用于实际输出。这就是为什么全新会话和积极压缩如此重要。

成本估算：持续运行 Sonnet 大约 $10.42/小时。基于 cron 每 15 分钟运行一次的 agent，预计约 $48/天。使用 --max-budget-usd 作为硬上限。

七、CI/CD 流水线与 Cron 任务集成

对于计划性的自动化工作，Claude Code 可直接与 CI/CD 系统集成。官方 GitHub Action 是 anthropics/claude-code-action@v1：

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

name: Claude Code Review
on:
 pull_request:
 types: [opened, synchronize]
jobs:
 review:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 fetch-depth: 0
 - uses: anthropics/claude-code-action@v1
 with:
 anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
 prompt: "审查这个 PR 的安全和代码质量问题。"
 claude_args: "--max-turns 5 --model claude-sonnet-4-6"

对于基于 cron 的自主 agent，Boucle 模式通过 state.md 文件在运行之间维持状态：

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

#!/bin/bash
# run-agent.sh —— 由 cron 调用
STATE="$HOME/agent/state.md"
LOG="$HOME/agent/logs/$(date +%Y-%m-%d_%H-%M-%S).log"

claude -p "你是一个自主 agent。读取你的状态，决定做什么，
然后用你学到的内容更新 state.md。
$(cat $STATE)" \
 --allowedTools Read,Write,Edit,Bash \
 --max-turns 20 \
 --max-budget-usd 1.00 \
 --bare 2>&1 | tee "$LOG"

1
2

# crontab -e
0 * * * * /path/to/run-agent.sh

200 次迭代后的关键教训：state.md 必须保持在 4KB 以下（它会被注入每个 prompt），使用结构化键值对而非散文，并添加文件锁防止重叠运行。每次迭代后 git commit——git log 就是你最好的调试工具。

CI 环境使用 --bare 模式（跳过 hook、MCP 服务器、OAuth 和 CLAUDE.md 加载，最快最可复现的执行方式）和 --permission-mode dontAsk（拒绝所有未显式允许的操作——自动化环境中最安全的模式）。

八、已知陷阱与可能出错的地方

社区已广泛记录了以下故障模式：

最重要的单一安全措施是容器化。多位经验丰富的开发者独立推荐使用带网络隔离的 Docker：

1
2
3
4
5

docker run -it --rm \
 -v $(pwd):/workspace -w /workspace \
 --network none \
 -e ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \
 claude-code:latest --dangerously-skip-permissions -p "$(cat PROMPT.md)"

正如一位开发者所说：*”用 --dangerously-skip-permissions 运行 Claude Code 就像不做防护措施。所以用个套… 我是说容器。”*

九、今晚的快速启动清单

15 分钟设置过夜自主运行：

1. 创建 git 检查点：git add -A && git commit -m "pre-autonomous checkpoint"
2. 安装四个关键 Hook：npx cc-safe-setup
3. 编写 PROMPT.md，包含架构上下文、任务列表、成功标准，以及每完成一个任务就提交的指令
4. 启动 tmux 会话：tmux new -s overnight
5. 防止休眠（macOS）：caffeinate -s &
6. 启动循环：

1
2
3
4
5
6
7
8

while true; do
 claude -p "$(cat PROMPT.md)" \
 --allowedTools "Read" "Edit" "Bash(npm run *)" "Bash(git *)" \
 --max-turns 30 \
 --max-budget-usd 5.00 \
 --permission-mode acceptEdits
 sleep 2
done

7. 分离 tmux：Ctrl+B，然后按 D
8. 去睡觉

早上起来：tmux attach -t overnight，然后查看 git log（git log --oneline）看 Claude 完成了什么。预计保留大约 75% 的产出，丢弃 25%。这很正常——正如一位开发者说的，*”不是完美，甚至不是最终版，但是在前进。”*

十、总结

先用 plan 模式，把 PRD.md 和 TODO.md 生成好。

• 安装 cc-safe-setup

  1	npx cc-safe-setup

• 安装 format-claude-stream

  1	npm install -g @khanacademy/format-claude-stream

• 编写项目的 CLAUDE.md

  1 2 3

  - 当上下文变大时，将当前状态写入 tasks/mission.md。包括：已完成的、下一步的、被阻塞的、未解决的问题。 - 错误处理：最多重试 3 次。如果没有进展，记录到 pending_for_human.md 然后转到下一个任务。 - 压缩前，务必保存完整的已修改文件列表。

• 编写 PROMPT.md

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

  ## 目标 - 查看 TODO.md，选择一个未完成的任务执行 - 执行的代码必须包含测试用例并测试通过 - 每做完一个任务，及时提交 Git，并在 TODO.md 标记为已完成 - 当所有任务都完成后，在 TODO.md 中顶部注明：“全部任务已完成” ## 要求 - 技术方案不确定 → 选择传统方案 - 两种可行实现 → 选择更简单的那个 - 需求模糊 → 应用最合理的理解，记录假设 - 永远不要提问，做出最佳判断然后继续 ## 环境（如有） # - CLOUDFLARE API 在 key.md 中

• 编写 key.md

  1 2	CLOUDFLARE_API_TOKEN=xxx CLOUDFLARE_ACCOUNT_ID=xxx

• 编写 nostop.sh

  1 2 3 4 5 6 7 8 9

  mkdir -p logs while true; do claude -p "$(cat PROMPT.md)" \ --dangerously-skip-permissions --model opus \ --output-format stream-json --verbose \ tee "logs/$(date +%Y%m%d_%H%M%S).jsonl" \ | format-claude-stream sleep 60 done

在之前那篇讨论 Harness 该怎么翻译的文章，有读者留言说可以叫 Hermes 爱马仕。

本以为是谐音梗，没想到确实有一个 Agent 产品叫 Hermes，而且在 GitHub 的热门榜单上，整个月都排名第一，目前已经累计有 4.8 万个 Stars。

和这段时间以来爆火的 Agent 龙虾不同，一个是支持所有操作系统和平台的专属个人 AI 助手，Hermes 的介绍写着「the agent that grows with you」，与你共同成长的 Agent。

听着就很高级，但这确实是 Hermes Agent 的独特之处。

它有一套内置的学习循环框架，OpenClaw 靠的是修改配置文件，联合多个 Agents 来处理各项复杂的任务，Hermes Agent 是一个单一的 Agent 框架，它的能力会随着实际使用的运行时间增加而不断增强。

它解决的问题是，当所有人都在讨论 agent 能做什么，但没人注意 agent 用完之后什么都不留下，而 Hermes Agent 现在能记住「什么方法有效」。

社交媒体上也不少推荐 Hermes Agent 的帖子，有人说刚刚从 OpenClaw 转移到了 Hermes，是他做过最明智的选择。

还有人分享「爱马仕橙皮书」，表示 Hermes Agent 是一个被严重低估的产品，它算得上目前最强大的开源 AI Agent 框架之一。

Hermes Agent 由 Nous Research 团队研发，查看 GitHub 上的发布记录，从 3 月中旬更新 V0.2.0 版本到昨天发布 V0.8.0，每次更新都有大量代码提交合并，以及实用的功能更新，是一个非常活跃的开源项目。

Karpathy 之前分享的 LLM Wiki 笔记大法，利用大语言模型和 Obsidian 笔记工具，完成对自己知识和研究库的搭建，也被立刻加入到了 Hermes 的内置技能里。

Hermes Agent 不仅支持安装在电脑上，通过 Termux 终端模拟器，还能安装在 Android 手机上。模型和网关的配置与 OpenClaw 类似。

值得一提的是，目前还没有被 Claude「封杀」，我们仍然可以通过登录 Claude 的 Pro 及以上会员直接完成大模型配置。同时，Hermes Agent 也提供了自家的，基于订阅模式的 Nous Portal 登录。

今天，小米大模型也发文正式宣布，「Xiaomi MiMo 已接入全球顶级 Agent 框架 Hermes Agent，并且限免两周。」

Hermes Agent 官网：https://hermes-agent.nousresearch.com

凭什么是 OpenClaw 真正的对手

OpenClaw 的核心是把我们的 AI 从聊天框里彻底拉出来，接入到实际的工作、学习和生活中，真正执行任务。它能连接微信、企微、飞书，能跑终端命令、控制浏览器，帮我们发邮件、管理日程安排等。

但 OpenClaw 有一个缺陷是它无法从我们日复一日的使用中，自动学习进化。

OpenClaw 的记忆是静态的——我们把信息写进配置文件，它读取，会话结束，等下次再读。它不会主动地从执行过程里提炼什么，也不会因为我们纠正过它一次，下次就自动做对。

所有的工作流用过一遍，还是需要我们提醒它，打包成 Skill 或者专门的提示词等。

虽然现在有一些专门的 Skill 被设计用来赋予 OpenClaw 自学习的能力，但是、 Hermes Agent 是从底层架构的学习循环，到记忆系统，和 Agent 执行内部，都把「越用越懂你」作为重点。

Hermes Agent 的特别之处是一个闭合的学习循环 Learning Loop。

每次任务完成后，Hermes 会检查：这次执行值不值得写下来？触发条件很具体，工具调用超过 5 次、中途出过错然后自己修复了、用户做过纠正、或者走了一条不明显但有效的路径。满足任何一条，它就会在 ~/.hermes/skills 目录里生成一个 Skill 文件。

和技能市场上那些被广泛使用的 Skill 一样，这份自动生成的文件是下次可以直接跟着走的操作流程。名称、描述、步骤、涉及的工具调用，全部写清楚。格式遵循 agentskills.io 开放标准，理论上是可以跨兼容 agent，在 OpenClaw、Claude Code、Cursor 等工具内使用。

技能文件不是一次写死。Hermes Agent 在后续执行中发现更好的路径，会直接修改。修改优先用 patch，打补丁的方式，只传入旧字符串和替换内容，而不是整体重写。

这个选择背后有两个考虑：全量覆写容易把原来好用的部分一起破坏掉，而 patch 只碰有问题的地方，更安全，token 消耗也更少。

记忆，是 Agent 最难处理的问题

另一项和 OpenClaw 的差别，是记忆系统。

前几天，《生化危机》女主角 Milla Jovovich 和工程师 Ben Sigman 联合发布了开源 AI 记忆工具 MemPalace，两天内获得超过 23000 个 GitHub stars。

它的设计灵感来自古希腊演讲家的记忆技法，把要记的东西放进一座想象中的建筑的不同房间，需要时走进去取。

整个系统分成五层：Wing（项目或人物）、Hall（记忆类型）、Room（话题）、Closet（压缩摘要）、Tunnel（跨话题引用）。仅靠这个层级结构，MemPalace 称检索准确率就从 60.9% 提升到 94.8%。

MemPalace 的核心判断是：不应该让 AI 来决定什么值得记，AI 的判断不可信，不如全存下来，让检索来决定什么有用。

月初 Claude Code 50 万行代码泄露事件中，另外一种关于记忆的解决方案则是依靠 AI，有网友发现 Claude 会使用做梦的方式，用 Auto Dream 来自动整理我们的记忆文件。

Hermes 的记忆系统也经过专门设计，一共分四层，每层负责不同的事，在不同的时机被调取。

第一层叫常驻提示记忆。两个文件，MEMORY.md 和 USER.md，存放需要在每次会话开始时自动加载的上下文。总字符上限只有 3575 个，这个数字是 Hermes Agent 故意收窄的，目的是强迫我们筛选，而不是什么都往里塞。

第二层是会话归档。每次对话写入 SQLite 数据库，用全文索引检索。Hermes Agent 需要历史上下文时，主动发起查询，把检索结果经过一次 LLM 摘要，只把和当前任务相关的部分注入进来。

第三层是技能文件，也就是上面说的学习循环的产出。默认情况下，系统提示里只加载技能的名称和简短描述，全文按需调入。这个设计的效果是，技能库可以从 40 个增长到 200 个，而上下文成本几乎不变。

第四层叫 Honcho，是可选的用户建模层，被动地在跨会话之间积累你的偏好、沟通风格和领域知识。适合把 Hermes Agent 当成日常个人助理长期使用的场景。

这四层的分工原则也很清楚，如果某件事需要在每次对话里都出现，放第一层；如果只在特定话题出现时有用，留在第二层等检索；如果是可复用的操作流程，让第三层处理；如果是用户的长期画像，交给第四层。

一条消息到达 Hermes Agent，无论来自 Telegram 等第三方网关，还是命令行，进入同一套同步执行引擎：生成任务 ID，从记忆层构建系统提示，优先复用缓存版本，避免重复构建，发送前检查上下文长度是否接近上限，调用模型。

除了在任务执行的过程中会使用学习循环自动更新，Hermes 在每次会话中间还会触发一个叫周期性微调（Periodic Nudge）的机制。

在没有用户输入的情况下，系统会定期自动向 agent 发一条内部提示，要求它回顾最近的操作，判断哪些值得写入记忆。完全不需要用户触发，Hermes Agent 自己决定什么值得保留。

上手 Hermes Agent 需要多少成本

和安装 OpenClaw 一样，Linux、macOS、WSL2 直接一行命令，Android 机上使用 Termux 也支持安装。

Hermes 有提到不支持原生 Windows，我们需要另外安装 WSL2，Windows Subsystem for Linux，简称 WSL，是一个在Windows 上能够运行原生 Linux 二进制可执行文件的兼容层。

安装命令会自动处理大量依赖，包括 Python 3.11、Node.js v22、ripgrep、ffmpeg、虚拟环境、全局命令、LLM 等配置。安装完成之后的界面也 Claude Code 那些终端工具一样，通过一些具体的命令来实现和 Agent 的交互。

在模型配置上，可选推理服务商范围很宽：Nous Portal（订阅制，零配置）、Anthropic（直接用 Claude，可以用 API key 或 Claude Code 授权）、OpenRouter、DeepSeek、Hugging Face、阿里云 DashScope（Qwen 系列）、GitHub Copilot，还有任何 OpenAI 兼容接口，包括 Ollama 本地模型。

还有小米的 Xiaomi MiMo-V2 系列，包括支持百万上下文 Token 的 MiMo-V2-Pro、全模态的理解能力的 MiMo-V2-Omni，以及 Flash 模型。小米还提供了 4.8-4.22 为期两周的限免试用，更新 Hermes Agent 到最新版本，通过 Nous Portal 免费调用小米大模型。

Hermes Agent 还有一个 Auxiliary Models 模块，它是 Hermes 里专门处理「侧任务」的一组轻量模型配置，不负责主对话，但负责很多高频、关键、又不值得占用主模型的工作。

例如像是图像分析、网页提取、Skill 匹配、记忆处理等不同的任务会自动分配不同的模型。在默认情况下，辅助任务会自动检测并优先使用 Gemini Flash，无需手动配置。

这和 Anthropic 今天推出的 advisor 功能类似，都是适合主模型昂贵，但想把边角任务切到便宜模型的机制。Hermes 则是直接把「多模型编排」做成了底层架构。

消息平台方面，支持列表和 Openclaw 类似，Telegram、Discord、Slack 和飞书是功能最完整的几个，语音、图片、文件等各种格式都支持。一套网关进程连接所有平台，会话统一管理。

Hermes Agent 其实很难说是一个花几分钟安装完了，就能快速上手用起来的工具，它更多的是一套我们需要运行和维护的基础设施。

如果我们只是想要一个能在手机上发消息控制的 AI 助理，OpenClaw 会是更简单的路径，写一个 SOUL.md 配置文件，跑起来，接上 Telegram，完成。

Hermes Agent 适合的场景是，我们有一些重复的、会演化的工作流，同时我们愿意让 agent 从使用习惯中积累经验，我们会期待希望三个月后的 agent 和第一天的 agent 不一样。

在社交媒体上，一些网友分享使用 Hermes Agent 的应用实例，包括像是商业自动化，把企业的客户关系管理 CRM 和知识库连接在一起；以及营销管理，将内容生成和社群平台的发布统一自动化；还有经典的代码生成等软件工程项目等。

随着我们在各个真实的业务场景中应用这些技术，一个不争的事实是：Agent 正在加速杀入真正的生产环境。

对于 Hermes，有人说它只是 OpenClaw 的一个「轻量级平替」，也有人说它是单一智能体的一次进化。但无论如何，Agent 的演进路线，绝对不会止步于 OpenClaw 设定的框架。

而不管是 Hermes 还是 OpenClaw，现在所有的开源 agent 方案，都还留着各自的缺口。能让 agent 真正打穿主流、成为普通人日常基础设施的那个形态，大概还没出现。

解决了复杂的记忆系统，还有庞大的 AI 安全问题，给了 AI 手脚又要想着怎么给他上枷锁 Harness，还有安装太复杂，门槛太高，似乎总有各种受限的地方。

只能说，Hermes 这次确实给了 Agent 一个新的方向，它让 Agent 从一个用完归零的工具，变成了能从失败里学到东西、能记住教训的一种搭档关系。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

一个软件工程师每月的人力成本，根据国家统计局的数据粗略估算，在国内是 2 到 3 万元左右。

如果只算他一天 8 小时在岗时间里真正执行任务的部分，折合下来大约是每小时 110 到 170 元。

Anthropic 今天又推出了一项新功能 Claude Managed Agents， 有一项定价写着 $0.08/小时，折合人民币不到 0.6 元。

这个数字本身不是重点，重点是它意味着 Anthropic 开始按小时计费。不不仅收取使用的 Token 费用，还开始计算 Agent 跑了多长时间。

Managed Agents 提供的是一整套现成基础设施，也就是 Anthropic 所说的 agent harness：包括工具调用、记忆系统、权限控制、云端长时运行、Agents 之间互相监控，以及沙箱环境等功能。

举个例子，假设我们要雇一个人帮你干活，会遇到什么麻烦？

招人阶段，要准备办公位（服务器）、要装电脑配系统（开发环境）、要写岗位职责说明书（代码逻辑）。

干活阶段：干到一半断网了，进度全丢（会话中断）、想查他干了啥，没有记录（无法审计）、担心他乱翻公司机密（权限管控）。

而 Claude Managed Agents 在这个过程中的作用，就是把这些麻烦事全包了。Anthropic 表示，别再自己搭那个破烂不堪的草台班子了，把基建交给我，你们只管去想怎么赚钱。

通过在 Claude 官方的 Agent 搭建控制台或者使用 API 的方式，我们直接下达 Agent 需求，Claude Managed Agents 负责给他工位、看着他干活、保证他不乱来。

目前，Claude Managed Agent 正在公测中，任何人、企业都可以快速地构建一个能干活的 真.Agents 数字员工。

几天就能从零开始搭建一个 Agent

过去两年用了无数的 Agents，几乎每天都有开发者推出自己的 Agents 产品。有的面向编程代码，有的面向设计，最后这些 Agents 都被统一到，去年是 Manus 类，今年是 OpenClaw 类的大家族里。

但如果想要自己部署一个更个性化的 Agents，尤其是一个能给其他人用的 Agent。我们需要自己处理对应的服务器，要设置复杂的机制防止它崩溃，要给它接管数据库的安全权限，还要用合理的方式，管理 Agent 的上下文记忆。

Managed Agents 把这些全部承包了。

它的结构围绕四个概念展开。Agent 定义这个员工是谁：用什么模型、遵循什么系统提示、能调用哪些工具。Environment 是一个配置好的云端容器，预装了 Python、Node.js 等运行环境。

Session 是一次具体的任务运行实例，有完整的事件历史，随时可以查。Events 是我们和 agent 之间传递的消息——任务指令、工具结果、状态更新。

过去那种「手搓」Agent 的复杂模式，直接被 Claude Managed Agents 压缩成了全自动的流水线。

如果你是开发者，可以直接调 API 或者用 CLI，几行代码创建 agent、配置运行环境、启动 session、接收实时事件流。整个流程文档写得很清楚，从零到跑起来大概半小时。

如果你不写代码，Claude Console 提供了完整的可视化界面。选模型、写系统提示、接 MCP 工具、挂外部服务，全部点击完成。配置好之后可以直接在界面里测试，看 agent 怎么响应，不满意就调，满意了再让它持续跑着。

Console 的构建页面里有一个「What do you want to build?」的输入框，旁边是模板库，覆盖了研究员、数据分析师、客服助理、事故响应协调员等现成角色，每个都预先接好了 Slack、Notion、Asana、GitHub、Jira 这些工具的连接。选一个模板，改改描述，就能开始。

不过，仅开通了 Claude 会员还不够，目前还是需要有 API 计划，即绑定信用卡有一定 Token 额度，才能使用 Managed Agent。

Managed Agents 在工程上有一个核心决策，和最近一直在讨论的 Harness 工程相关，它决定着这套系统能不能真正用于生产。

Anthropic 在官方的工程博客里用一个特别扎心的比喻，解释了 Managed Agent 的结构设计。

他们认为早期的 Agent 架构，非常像是在「养宠物」。开发者习惯把 Claude（大脑）、执行代码的沙盒（手脚）以及它的记忆（会话日志），一股脑地塞进一个巨大的服务器容器里。

这个容器变得无比娇贵，我们不能让它死。一旦容器卡死或崩溃，AI 的脑子和手脚一起完蛋，用户的任务数据瞬间清零；容器里同时跑着用户凭证和 Claude 生成的代码，一旦有提示词注入攻击，凭证就直接暴露。

Anthropic 的解法是，把「大脑」和「双手」彻底分开，容器变成了随时可以牺牲的「牛马」，即从养宠物变成养牛马。

调度器（大脑）不再住进容器里。它像调用外部工具一样，对容器发号施令。如果容器在执行危险代码时崩溃了？大脑根本不慌，它会记录下一个错误代码，然后毫不犹豫地重新拉起一个新容器继续干活。

使用 Agent 留下的记忆，也不再被塞进某个 AI 或者容器拥挤的脑子里。分开运作后，所有的记忆被单独存放在外部的会话日志中。它就像一个外接硬盘。

大脑通过标准化的调用方式指挥双手，不在乎双手是容器、是外部服务还是别的什么。哪只手出故障了，换一只，大脑继续跑；大脑自己崩了，从对话日志里恢复，接着干。

这个设计带来了性能的大幅提升。解耦之前，每个对话启动都要等容器完整初始化，系统要花很长时间去拉起一个包含了庞大调度逻辑的沉重容器。

现在，首次响应时间降低了超过 90%，安全边界也因此变得清晰——Claude 生成的代码在沙箱里跑，凭证在沙箱外的保险箱里，两者之间有专用 Agents 隔离，agent 永远拿不到原始凭证。

更重要的是，它让 Agent 真正具备了可以长期稳定干活的能力。

Anthropic 提到，Notion 已经在内部使用 Managed Agents 搭建了帮助工程师写代码、帮知识工作者做演示的企业 Agent。

Rakuten 把销售、市场、财务、HR 的 agent 都用 Managed Agents 部署了，每个专项 agent 的上线时间是一周。

Sentry 的调试 agent 在发现 bug 之后，会自动写补丁、开 PR，开发者收到的是一个可以直接 review 的修复方案，整个流程不需要人介入。

可以说，以前的大模型公司提供的是模型 API，即处理我们的每一条消息；Anthropic 做出的改变是将基于消息的 API 包装成可以直接交付工作的 Agent API。

回到那个数字 $0.08/session-hour

这种改变首先体现在 Claude Managed Agents 的定价结构上，根据官方博客，Managed Agents 的计费包括 Token 费用（标准 API 价格，Sonnet 4.6 是 $3/M input，$15/M output），加上 $0.08/session-hour（按实际运行时间计费，idle 时间不算），和 Web search 另计：$10 每 1000 次。

Anthropic 有举例，一个使用 Opus 4.6、跑 50K 输入 + 15K 输出 token 的一小时 coding session，总成本约 $0.70。

和专门请一个员工来处理，现在企业自己就可以通过 Managed Agents 创建一个内部的 Agents。数字员工的概念，又被往前推进一步。

此外，对 Anthropic 来说，这也意味着收入开始和企业的自动化程度直接挂钩，企业跑的 agent 越多，Anthropic 收得越多。这和 AWS 从「卖服务器」变成「卖运行时间」是同一个逻辑，他们打开了一个比卖订阅大得多的市场。

大模型技术发展到现在，单纯比拼参数和跑分的红利期似乎正在消退，毕竟能力真正强的大模型，也被限制不能开放使用。

真正的战场，又回到了「如何让这群聪明的脑子，最稳定、最廉价地在工厂流水线上打工」，Claude Managed Agents 的推出，就是 AI 基础设施走向成熟的一个里程碑。

回头看 Claude 今年的每次更新，无论是模型还是产品，几乎都踩在了我们对 AI 能做什么的痛点上。

一方面在持续提升模型的能力，不被外界生视频、浏览器、生图模型那些方向干扰；另一方面是从 Cowork 开始，到后面疯狂打补丁复制 OpenClaw 的全部功能，再到今天推出一个专门用来开发和部署 Agents 的平台，每一次都是极其敏锐的产品视角。

Anthropic 正在开创一个新的发布模式，即从「我们发布了一个更快更好的工具」，变成「我们为你准备好了构建数字员工的完备基础设施」。

参考链接：
Claude Managed Agents 更新博客：
https://claude.com/blog/claude-managed-agents
Claude Managed Agents 架构设计博客：
https://www.anthropic.com/engineering/managed-agents
在 Claude 控制台开始搭建自己的 Agents：
https://platform.claude.com/workspaces/default/agent-quickstart

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

99 年生的张舒昱，是腾讯电脑管家团队入职不久的产品经理，这在腾讯算不上核心业务线。

今年 1 月 OpenClaw 刚在中国爆火，她着了迷，拉上几个人攒了一个产品原型 QClaw：基于 OpenClaw，一键安装，通过微信直接操控智能体。

项目在腾讯体系里几乎没有存在感，没有立项审批，没有总办资源，几个年轻人凑在一起写代码。

3 月 9 日，QClaw 内测上线。一周之内，数百万用户注册。

然后事情开始失控，惊动了腾讯总办。

高层反应极快，随即调拨数十名员工和计算资源到张舒昱的团队。同日，另一支团队推出了 WorkBuddy，同样兼容 OpenClaw。再隔一天，腾讯港股大涨超过 7%，投资者把涨幅直接归因于这两只虾。

3 月 11 日凌晨 2:06，马化腾发了条朋友圈：「自研龙虾、本地虾、云端虾、企业虾、云桌面虾，安全隔离虾房、云保安、知识库……还有一批产品陆续赶来。」

这对腾讯 11 万员工是一个鲜明的信号，无数员工将其解读为：Pony 支持他们 all in 龙虾。

据 The Information 独家报道，截至本月，腾讯内部同时有 8 个团队在开发基于 OpenClaw 的产品和服务。加上在研和内测项目，总数已超过 10 个。

15 年前，腾讯内部三个团队赛跑移动 IM，张小龙的广州研发部跑出了微信，是腾讯史上赛马最成功的一次。这次换了个物种，叫赛虾。

一个 99 年产品经理做的边缘项目，两周之内变成一家万亿市值公司的战略支点，似乎有点不可思议。

张舒昱对 The Information 说了一句大实话：「我们都在用 AI Agent 做实验。此刻，没有人能说什么是最佳方法。」

翻译一下就是：我们也不知道答案，但先跑起来总比站着强。

全村的希望：腾讯为什么把命押在一只虾身上

要理解腾讯对龙虾的狂热，先要直面鹅厂当下在 AI 竞争中的处境。

过去两年，中国 AI 大模型军备竞赛打得昏天暗地。

阿里砸钱做千问，字节孵出豆包，在用户规模和模型能力上都拉开了身位。腾讯呢？手握游戏和微信广告的丰厚利润，但在 AI 赛道上远不及这两个对手激进。

自研的混元大模型尚且无法与竞争对手匹敌，又拖累了自家 AI 助手「元宝」的进展。

腾讯不是没努力。去年请来前 OpenAI 研究员姚顺雨执掌混元研究，重建了研发基础设施。 4 月即将发布的混元新一代模型，业内普遍视为腾讯模型能力的一次摸底考试。

但远水解不了近渴，在新模型交卷之前，缺乏强大的内部模型，让元宝在与豆包和千问的竞争中暂时落于下风。

所以当 OpenClaw 在中国引爆了 Agent 热潮，腾讯高层几乎是本能地抓住了这根绳子。这只龙虾证明了 AI 的下一个爆发点未必在聊天框里，可能在桌面上，在工具里，在无数个能替你干活的智能体身上。

腾讯高层的判断很清晰： OpenClaw 引发的这一轮 Agent 浪潮，将是 AI 战场重新洗牌的机会。

他们逻辑是这样的，如果腾讯能通过将 OpenClaw 类Agent 能力与微信深度整合，提供配套工具和服务，成为中国最好的 Agent 使用平台，那么即便其内部大模型不是最强大的、AI助手也不是最受欢迎的，腾讯依然有可能在 AI 下半场逆风翻盘。

2020 年，马化腾在腾讯内部将视频号称为「全村的希望」，寄望于它在短视频赛道上扳回一城。如今，「全村的希望」换了物种。

区别在于，视频号好歹是亲生的，龙虾来自一个奥地利独立开发者的 GitHub 。

某种意义上，这更像是 2014 年纳德拉接手微软后做做的事，承认在移动互联网上输了，放下「什么都要自己做」的控制欲，押注一条全新赛道。

纳德拉用了十年，腾讯希望快一点。

八虾夺嫡，腾讯赛虾背后

外界把多团队并行理解为经典赛马机制，腾讯内部更愿意说「多样性」。QClaw 和 WorkBuddy 是最先冒头的两只虾，路线截然不同。

QClaw 是张舒昱从电脑管家边缘团队杀出来的，直接拥抱 OpenClaw 开源生态，做微信一键安装，野蛮生长。设计理念就四个字：打开即用。不需要配置环境，不需要懂终端命令，微信扫一下就能让 AI 接管你的电脑。

WorkBuddy 则走了一条完全不同的路。负责人汪晟杰在接受 APPSO 采访时反复强调一件事：百分百自研，没用过一行 OpenClaw 源码。

它走半自动化路线，避开了 OpenClaw「透传」模式下信息暴露在公网上的风险，采用 bot 推送通知模型，每一步关键操作都需要用户确认。汪晟杰的定义很明确：龙虾是一个概念，不等于 OpenClaw。WorkBuddy 要做的是安全可控的龙虾，企业能放心用的龙虾。

汪晟杰透露了一个时间细节：WorkBuddy 在 1 月 17 号那个周末就已启动，三四个人通宵做出 MVP（最小化可行产品），原计划 3 月 16 日发布。看到龙虾热潮后提前了一周，撞上了 QClaw 同期发布。

也就是说，腾讯并非在 OpenClaw 火了之后才匆忙跟进。多个团队在不同时间点嗅到了同一个机会，OpenClaw 的爆火更像催化剂，把水面下的项目一夜之间推上了前台。

但赛虾机制的矛盾也摆在桌上。

QClaw 和 WorkBuddy 功能高度重叠，都能通过微信操控 AI 智能体，用户该选哪个？8 支团队同时跑，资源会不会内耗？

答案藏在张舒昱那句话里：「此刻没人知道什么是最佳方法。」8 支团队同时下场，与其说是信心爆棚，不如说谁都没有把握。

腾讯选择用数量对冲不确定性，多条路线同时跑，押中一条就够了。

赛马机制的精髓从来都是：靠数量提高命中概率。15 年前微信就是这么跑出来的。

马化腾的养虾哲学

赛虾的前提是有虾可赛，但这只虾不归腾讯管。

3 月 12 日，OpenClaw 创始人 Peter Steinberger 在 X 上公开批评腾讯，矛头直指腾讯的 SkillHub 服务复制了社区 Skills 却没有做出任何贡献。

两天后，腾讯通过 GitHub 捐款，随后被列为特色赞助商，与 OpenAI 并列。在上周英伟达 GTC 大会上，腾讯云 CEO 汤道生当面约见 Steinberger，提出由腾讯云贡献服务器和安全服务，并探讨与 OpenClaw 基金会更深层的合作。

中国市值最高的互联网公司之一的高级副总裁，飞到圣何塞跟一个开源项目创始人坐下来谈合作。在腾讯历史上几乎没有先例。当你需要别人的东西比别人需要你的东西更急迫时，身段自然就放下来了。

同一周的财报发布会上，腾讯总裁刘炽平宣布 2026 年将 AI 新产品的投资至少翻倍，从去年的 180 亿元起步。而在阐述钱花到哪里时，他只点了三个名字：混元、元宝、以及最新的 Claw 产品。

一个月前还是边缘项目的龙虾，一跃与腾讯自研大模型和旗舰 AI 应用并列。龙虾从「大家自己玩玩」正式升格为「公司战略」。

马化腾最近在财报会议上的发言，进一步回答了一个更本质的问题：腾讯想用龙虾做什么？

他的切入角度直接跳过了产品层面，落在生态上。

马化腾认为龙虾类应用有记忆和个性，更像助理，带有「活人感」，能让 AI 落地到办公、终端、小程序等各种场景中，不再全部挤在 chatbot 这条独木桥上。

但真正耐人寻味的是他关于「去中心化」的论述。微信本身是中心化的 App，但微信生态是去中心化的，数十万小程序商家构成了开放平台。马化腾认为 AI Agent 天然具有去中心化特征，可以融入微信生态。有一句话特别关键：

所有服务商的心态都是怕被 AI 智能体「短路化」「渠道化」。

意思是，他不想让 AI Agent 变成一个新的中间商，把微信里的服务商变成纯粹的后端 API。他想让小程序保留独立性，同时具备 AI 能力。「每一个小程序都可以智能化和龙虾化。」

这个思考比「我们也做龙虾」高出一个维度。马化腾看到的是一种范式转移的可能：AI 的价值分配方式，从「一个超级 chatbot 统治一切」变成「无数分布式智能体各显神通」。

如果这个判断成立，拥有全球最大通讯生态和最活跃小程序平台的微信，天然就是 Agent 时代最肥沃的土壤。

刘炽平在财报会上把这套逻辑做了明确的总结：「Claw 提出了一种去中心化的模型……有段时间，似乎每个人都在争夺成为 AI 智能体唯一的入口和垄断者。但现实并非如此。」

一句话概括腾腾讯的押注逻辑：模型之争输了一局，但生态之争的牌还没摊开。

当然，这套叙事也可以被翻译成另一句话：我们模型不够强，所以告诉你们模型没那么重要。

自洽和自欺之间，有时候只隔一层窗户纸。但关键在于，这一次腾讯确实有牌可打。微信不需要成为最强大模型的容器，只需要成为最好用的 Agent 运行环境。

这和纳德拉的 Azure 逻辑如出一辙，你不需要自己做出最好的 AI，你只需要让最好的 AI 都跑在你的云上。

养虾产品全景图，腾讯到底下了多少注

腾讯的「养虾」远不止做几个 C 端产品那么简单。腾讯周五公布了「养虾产品全景图」，这套从底层到应用层的完整龙虾矩阵，密度超出外界预期。

消费级产品打头阵。QClaw 主打微信一键安装，面向普通用户；WorkBuddy 走桌面端自研路线，强调安全可控；微信 ClawBot 负责让用户在微信聊天界面直接操控龙虾。

三个产品覆盖了「小白用户一键上手」「桌面深度使用」「微信生态无缝接入」三个核心场景。光是消费级这一层，腾讯就同时铺了三条路。

企业级产品紧随其后。ClawPro 面向企业和政务客户，主打安全隔离和精细权限管控，企业微信独占通道，账号权限分级，内置技能审核机制，代码生成类操作要过审，网页搜索走安全网关。

汤道生在腾讯云峰会上重点推介了 ADP（智能体开发平台），定位是企业构建定制化 Agent 的工具箱。配合 Claw Runtime 提供安全沙箱运行环境，Lighthouse 做安全管理。

整套企业方案的逻辑很清晰：OpenClaw 太野了，我帮你把它关进笼子里。

开发者生态也没落下。CodeBuddy 是去年下半年就上线的 AI 编程助手，现在被纳入龙虾矩阵成为开发者入口；SkillHub 是 AI 技能社区，做了本土化适配，也正是因为这个产品被 Steinberger 点名批评后才有了后面那笔捐款。TokenHub 则是模型服务市场，不光接混元，也接 DeepSeek、MiniMax、Kimi 等第三方模型，统一计费。

腾讯连「卖铲子」的生意都想好了。

从这张全景图可以看出，腾讯不想只在产品上做单点突破，要做一整条龙虾产业链——从安装到运行，从个人到企业，从消费到开发，每个环节都有人盯着。

这正是汤道生反复强调的「Harness 工程」思路：Agent 时代的胜负手不在模型本身，在于脚手架。工具调用、上下文工程、长期记忆管理、工作流设计，这些看起来不性感的苦活，才是决定 Agent 好不好用的关键变量。

汤道生在腾讯云上海峰会上表示：「AI 落地不只是算法题，Harness 工程能力是关键变量。不同的脚手架设计，会显著影响实际使用效果和 token 成本。」

翻译成人话就是：模型是发动机，但没有底盘和方向盘，跑不了多远。腾讯模型暂时跑不过别人，但如果能把底盘和方向盘做到最好，照样能赢。

虾潮退去之后

把所有线索串起来，这个故事可以被浓缩成一句话：腾讯用一家大公司能调动的所有资源，去拥抱了一个自己无法控制的开源项目。

这是一个充满张力的姿态。

OpenClaw 的更新节奏是每周两三个版本，API 说改就改，Breaking Changes 说来就来。Peter 点一下 merge，深圳大厦里好几支产品团队可能就要通宵救火。腾讯把战略命脉系于别人的 GitHub 仓库上，这需要的不只是勇气，还有一种前所未有的谦逊。

但换个角度想，腾讯可能也没有更好的选择了。

如果继续只在模型和 chatbot 赛道上硬碰硬，不是陪跑就是陷入同质化厮杀。但 Agent 浪潮撕开了一条新缝隙：谁能把 AI 变成最好用的工具，谁就能重新定义入口。

微信有 14 亿月活，有小程序生态，有支付，有社交关系链。这些东西造不出最强模型，但能造出最好的 Agent 使用环境，这是腾讯手里唯一一张别人没有的牌。

问题在于，这张牌的有效期有多长。

OpenClaw 仍在快速迭代，生态远未定型。今天的龙虾热，会不会像去年的 Manus 一样来得快去得也快？8 支团队赛虾，会跑出下一个微信，还是跑出 8 个半成品？马化腾的「去中心化 Agent 生态」蓝图很美，但从蓝图到现实之间，还有需要经历多少次「技术事故」？

不过，有一件事是确定的。

当一家公司的 CEO 凌晨两点发朋友圈，总裁在财报会上把龙虾和自研模型并列，高级副总裁飞到美国去约见开源项目创始人，8 支团队同时下场赛虾，AI 投资直接翻倍，它就已经不是在追热点了，它在押注这家公司的未来。

赌的不是这只虾能活多久。赌的是在 AI 重构一切的十年里，腾讯还能不能坐在牌桌上，以及坐在什么位置。

视频号当年也被叫做「全村的希望」。五年过去了，它还没打败抖音，但在微信生态内长出了自己的活法。龙虾能不能也走出第三条路？答案还早。

不过，当一个巨头被逼到墙角，终于想清楚自己要什么，把资源砸向同一个方向的时候，你永远不能低估它。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

过去两年，我们每天都在做同一件事：学习和进修「提示词工程」这门玄学。

找 AI 干活，总要像个碎碎念的甲方一样，交代八百字背景，像是在哄一个智商奇高、但每天都会间歇性失忆的实习生。

这让我想起在游戏里，施展出必杀技之前，总是会有一个类似「前摇」或者「吟唱」的过程。某种程度上，写提示词，提供上下文，上传各种文件等等……就是使用 AI 的「前摇」。

不是说用户每次都要做到极致，只是如果你能给足这些前置条件的话，AI 会做的更好。

不过，前段时间 APPSO 在中关村的一场线下聚会看到了一个还在测试中的 AI 办公产品——它很大程度上摒弃了对「前摇」的依赖。

产品名字叫 Floatboat。

Floatboat 的联合创始人兼 CEO 少卿走到台上，打开 Floatboat，选中一个文件夹，里有一个 CSV 表格，是一份参加本次活动的嘉宾名单。他在旁边的 AI 对话框里说了一句：生成邀请函。

过了一会，每位嘉宾的邀请函都出现了。

到这里为止都还好，把表格丢给 ChatGPT、Claude、WorkBuddy、悟空………任何一个今天的 AI，写一句指令，大概率也能做到差不多的事情——但接下来发生的，让我愣了一下。

有一位新嘉宾确认出席了，少卿说，「在表里更新一下」。

CSV 更新了；紧接着，一封新的邀请函也自动生成了。

我坐在那里花了两秒钟，试图理解刚刚发生了什么：

Floatboat 它知道这份表格和邀请函之间，知道「更新表格」和「生成邀请函」两个动作之间，是有关系的。所以少卿只说了前半句，后半句没说出来，它自己悟出来了。

AI 不再是等待指令的工具，变得越来越积极、主动，会动脑子，像一个一直给你打下手的小朋友，你说「更新一下」，他知道你的意思。

这个瞬间让我开始认真看这个产品。

简单，但又无法简单定义的产品

Floatboat 是什么？我试着给它一个定义，发现很困难。

它有一个长得像 macOS Finder 的文件管理器，你可以浏览本地文件、打开 iCloud Drive；文件格式支持得很全，Markdown、CSV、Excel、Word、图片、视频，都能直接预览，甚至编辑；

它有一个内置浏览器，可以打开任何网页，甚至可以让 Agent 去操作这些网页；

它有一个 AI 对话界面，底层可以接 Gemini 或其他模型。这么看来它有点像 Claude 的桌面端，但又比 Cowork 多一些更直观的操作逻辑。

这三个东西，文件、浏览器、对话，以面板的形式并排在一起，可以随意拖拽组合，最多四栏并排。

你在浏览器里看到一张有用的图，可以直接拖到本地文件夹里保存；你让 AI 生成了一份报告，报告会直接写入本地文件，以 .md 或 .docx 格式保存，并且你可以直接编辑这些文件，不需要 cmd-c 再 cmd-v 到另一个地方。

信息从各个方向流进这个环境里，加工过的内容也能流出去，不会被锁死在某一个面板里。

所以 Floatboat 到底是什么？是文件管理器？是浏览器？是 AI 聊天工具？是氛围编程环境？

它都是，又不完全是。

在 Floatboat 出现之前，我们其实一直在做不同软件之间的「人肉 API」，每天按几百次复制粘贴，打开不同的软件或浏览器窗口、编辑不同的文件。

在 AI 世代在线办公的我们，成了在窗口与窗口之间疲于奔命的赛博搬运工。

而 Floatboat 打破了软件之间的墙，让所有的窗口都能共享同一份上下文。

开发团队给产品的定义是「工作环境」而非「AI 助手」。助手是你要求它才动的，工作环境是一直在那里的，你在里面做事，它一边帮你做事一边观察和学习。

在沟通会上，有人问少卿：一句话形容你们的产品？

少卿反问：你能一句话形容 ChatGPT 吗？

大家会心一笑。我觉得他说的有道理。有些东西确实不是一句话能装下的，除非你做的是一个非常垂直的工具。Floatboat 显然不打算做垂直。

做科技记者这些年，我经历过好几代这样的产品。最早是电子邮件加 Office 套件的时代，后来是各种 OA 系统，再后来钉钉来了、飞书来了、Slack 来了。

每一代都有一个产品，或者一类产品，它们有着同一句潜台词，对你发出强有力的暗示或者明示：上班，用我就够了。

而在 AI 时代，Floatboat 想要成为这个角色。

这么说不是在拔高它。恰恰相反，这个位置历史上从来没有人真正坐稳过。飞书解决了团队协同，但文档操作仍然需要 Office 套件。钉钉把审批这个工作做到了极致，但打工人私下用微信聊工作的习惯从来没变过。

「一统江湖」这件事，每一代都有产品在尝试，但从来没人真的实现过。

原因是结构性的：这类产品想要成功，需要整个组织一起换过来。而组织的惯性，是所有惯性里面最大的。你一个人觉得飞书好没用，你的团队、你的客户、你的供应商都得觉得好才行。

Floatboat 的策略有一个不同：它不面向组织，它面向个人。

这个产品的目标人群，也正是时下最流行的概念：OPC，全称 One Person Company/一人公司。

过去一年 AI 能力的跃进，让 OPC 这个前两年的口号，逐渐变得越来越现实和可行。一个人，加上三五个 agent， 几乎可以对等一个小的草创阶段的业务和支持团队。无论是自媒体内容创作者，从选题到写稿到排版到分发，还是电商业务，从选品到上架到客服到投流，都已经够用了。

Floatboat 希望能够打动这群人。在 APPSO 的体验中，我们测试了包括内容创作、数据科学等场景，也测试了外部工具接入（例如 Slackbot）等多种场景。对于内容、营销、数据分析、客服等类型的工作，Floatboat 都达到了我们的期待。

现在 AI 产品有两种设计哲学。一种是「你放手，我来」，把用户推到后座上去，Agent 全权接管，跑完了给你看结果。另一种是「你干活，我在旁边」，成为用户的副驾，在适当的时候递工具、提建议。

Floatboat 更接近后者，但又不全是。用 Floatboat 工作，我的体验是：跟 AI 在主驾副驾之间来回切换，畅快自如。

用了一段时间之后，我觉得 Floatboat 的主张是行得通的。至少在现在这个阶段，大多数人对 AI 的信任还没到「你尽管干，我不用看」的程度。你让一个打工人把整份方案交给 AI 自己跑，他会焦虑的睡不着觉……

但如果 AI 是在他的屏幕上、在他的文件夹旁边干活，他看得见过程，能随时纠正，那他会比较安心。

这也是为什么 Floatboat 的界面设计那么像一台传统电脑的桌面，把文件管理器、对话框、浏览器/编辑器都拉出来让你一览无遗：已经认识的东西，能够降低用户对一个新事物的戒备心，提高接受度。

一边工作、一边蒸馏工作

然后再说 Floatboat 做的一个叫 Combo 的功能。

Combo 可以是一个复杂的 skill，也可以是多个 skill 的组合。而在工作的逻辑里，就是把一套工作流打包成一个可复用的操作。

Floatboat 内置了从工作成果中「蒸馏」 combo 的能力——这其实很像 Anthropic 官方的 skill-creator（本身也是一个 skill）。

比如你每周都要做一件事：从网上抓几篇行业报告，提炼摘要，整理成 Markdown 文档，然后推送到 Notion。你第一次在 Floatboat 里手动跟 Agent 对话完成了这套流程之后，对话框下方会出现一个按钮，问你要不要把这轮操作存成一个 Combo。

或者你也可以主动跟 Floatboat 说，「把我们目前的工作里面的方式、思考、逻辑，整理为一个 skill」。

当下次遇到类似任务的时候，Floatboat 会自动把这个 Combo 推荐给你，一键启动。

这里面我觉得最有意思的一点是：你不需要事先「设计」工作流，只需要正常干活就行了。一边干着，一边 Floatboat 就会自己把你的工作习惯、操作方法等「蒸馏」出来，沉淀出一份指导思想。

少卿告诉 APPSO，Combo 能力的设计，是为了实现今天的绝大部分用户对于 agent 产品的那个核心期待：自进化。

「当 agent 能够感知你 80% 的操作的时候，它就有自进化的能力了」，Combo 的自动沉淀机制就是在做这件事的第一步。

兜售「提示词」的时代，快要结束了。你不再需要像个魔法师一样去背诵枯燥的咒语，把提示词保存在一个专门的文件夹或者 AI 工具的后台。通过 Combo，Floatboat 可以让用户把他们每天最经常做的固定动作，提炼成独属于自己的「手艺」和数字资产。

当然，Floatboat 也做了一个 Combo 市场，你做的好用的 Combo 可以上传，别人做的也可以下载。官方也提供了一些现成的。

但这个 Combo 体系仍有不足。

任何一个号称能够一统江湖的办公软件，号称「越用越懂你」的 AI 系统，都仍然存在冷启动的障碍：就好比 Google Docs 的初始简历模板虽然很全很好，但仍然需要每一个求职者去调整修改以适合自己。

Combo 的自动沉淀机制，逻辑上是说得通的：你用得越多，它学得越好，推荐的工作流越贴合你。但这有一个前提：你需要先投入时间从零教它，而大多数人没有这个耐心，他们希望拿来就能用。

作为一位媒体编辑，我的日常工作是阅读大量资料、跟作者沟通选题、改稿子、偶尔自己写长文。这些工作的颗粒度很细，上下文很碎，跟官方预设的那些模板（更偏向标准化的报告生成、数据整理之类）对不上。

在我的具体使用中，我将几种不同的内容生产路径保存成了不同的 Combo：针对外部新闻的快速反应是一种，基于采访 Q&A 提纲的撰写是一种，针对复杂课题的调研、资料的编排、然后进行原创写作，又是另一种。

当然，这不是 Combo 本身的问题。对于绝大多数人，无论他们的工作是文档写作、报表处理、ppt 写作，还是数据整理、行政工作，甚至更加复杂的「一人开发者+marketer+客服」，无论是自己生产 Combo，还是在 Floatboat 的官方 combo 基础上做微调，都足够好用。

AI 工具不是一切工作的万灵药——一个工具把自己宣传得再美好，今天的用户也应该有这样的觉悟。对于 Floatboat，正如前面所说的，它是「工作环境」，它的能力足以强化人，但它的工作效果仍然取决于人。

然后再说说用 Floatboat 和其他「类 Cowork」产品的区别：最大的明显感受，是 Floatboat 的工作流程很快。以文件操作、内容生成为例，在 Gemini 3.1 Pro 模型驱动下的 Floatboat，对文件进行操作（批量重命名/修改格式、填充 markdown 等）的用时，是我平时用 Cowork/Claude Code CLI 的三分之一左右。

Gemini 在「讨好用户」上也是老演员了，所以最近 Floatboat 也加入了 Claude 两个最新版模型，Sonnet 和 Opus 4.6 的支持。

Gemini 对于 Floatboat 主打的大多数办公场景（文案生成、表格处理、信息整理）来说够用，写作效果也还算不错；如果不符合你偏好的话，切到 Claude 模型也没问题。如果你注意到 Floatboat 的迎合意图太强，可以在工作过程中时不时强调一下，不要一味迎合，要对生成的结果，甚至用户的输入做批判性的思考。

以及，你也可以充分利用 Combo 生成的功能，将这些技巧写进 Floatboat 的核心指导思想。

另外一个小设计值得提一句：Floatboat 可以集成到飞书和 Telegram 里，你不打开它的客户端，直接在聊天工具里给它发消息，它就在后台帮你执行任务——这个功能叫 Claw 模式，相信足够你顾名思义了。

除了产品本身，Floatboat 团队还在做一件更远的事。

他们开源了一个协议叫 Selfware，核心理念用一句话说就是：A file is an app。

这是什么意思？现在你用 AI 辛辛苦苦做了一份调研报告，发给同事，他收到的是一个 Word 文档或者 .md 文件。文件里有最终结果，但你当时调用了哪些资料、AI 跑了什么逻辑、中间修改了几次、为什么改，这些对于工作最关键的经验，并没有被保存下来。

Selfware 想解决的就是这件事。一个 .self 格式的文件，里面不只有数据，还携带逻辑和结构。你的同事收到之后，可以直接打开、继续编辑、让 Agent 沿着你的思路往下跑。文件自带了工作环境。

这个想法，和目前 AI 开发圈里对 CLAUDE/SKILL.md、cursor rules 这类文件的热情， 属于同一个潮流。大家都在发现，文本文件可以用来「编程」AI 的行为，一个 .md 文件可以定义一个 Agent 的人格、工作方式、输出风格。

但 Selfware 往前又多走了一步：那些 .md 文件是指令，你告诉 Agent 怎么做；Selfware 想做执行单元，文件本身就能运行，而且不依赖于特定平台。

这其实有点像 Jupyter Notebook，把代码、数据、输出打包在一起了；也类似于 Docker，把运行环境做成了可分发的单元——Selfware 把场景换成了 Agent 协作。它不是从零发明的概念，但在 Agent 时代重新提出，确实切中了一个真实的痛点。

不过，协议这种东西，最终看的是采用率。现在 Selfware 主要在 Floatboat 自己的生态里运转。「A file is an app」是个有趣的理念，但从理念到被广泛采用的标准，中间路还很远。

另外值得提一句的是 IACT (Inline Action-Clicked Text)，Floatboat 开源的另一个协议。它做的事情更小但很实际：在 Markdown 语法的基础上，直接在 AI 对话生成结果加上可点击的行内 (in-line) 链接/按钮。生成结果中的「可行动内容」将会自动套上这个按钮，用户直接点击就行了。

这个交互改进看着不起眼，用起来确实减少了摩擦。最早做类似体验的应该是 Claude，但 Claude 的很多「好东西」都是闭源的。Floatboat 把 IACT 开源，让其它产品也可以充分利用。

现在一些同类产品比如 WorkBuddy 也在做类似的东西了，但据我了解 Floatboat 是最先提出这个概念并把它协议化的。

工作起来，开心最重要

Floatboat 的名字来自一句英语俗语，whatever floats your boat，大概的意思是「你开心就好」。

少卿说，他们希望产品给人一种在 AI 时代悬浮起来的感觉，不被裹挟着走。

这个愿景挺好的。但 Floatboat 能不能成为这个时代的那个「用我就够了」的产品？老实讲，APPSO 仍然没法给出一个明确的判断。

毕竟大家都看到了：每一代尝试做这件事的办公产品，到了最后，多半成为了工具箱里的工具之一，而非唯一。

但今天下判断，也为时尚早。

一个产品不需要统一所有人的工作方式才算成功。如果它能让一部分人——那些一个人干五个人的活、每天在软件之间当搬运工的「OPC」们，每天省出一个小时来做真正需要动脑子的事，那它就已经值得存在了。

对大多数普通人来说，一家公司的活如果全都一个人干，确实挺累的。

但 Floatboat 让人兴奋的地方在于，它给了一个人也可以是一家公司的从容和底气。

不是所有人都能 OPC，你至少首先需要台好「PC」。而 Floatboat 赌的，就是自己会成为那台 PC。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

一、背景

事情是这样的，之前对 AI 编程一直是观望态度，但是部门最近在做 AI 辅助编程 POC，有幸成为 POC 用户，用上了自己舍不得买的高级编程模型 （感谢公司）。尽管我自认为是一个在代码上很挑剔的人，但是试了下感觉居然还可以 （Go、React）！只能说还得是谷歌，调整重心略微发力，Gemini 3 表现确实很不错。既然尝到甜头了，觉得自己是时候好好地琢磨琢磨，研究研究，沉淀一套自己的工作流、方法论，解放自己的生产力，顺应潮流努力成为 AI 时代的受益者，而不是被淘汰的人！

新的开发范式需要搭建新的开发环境和匹配自己开发习惯的工作流，这就像刚学编程那会，需要挑一个自己喜欢的 IDE、熟悉 IDE 快捷键和优化 IDE 设置一样。过程中间肯定有阵痛，Java 开发者们回忆一下多年之前从 Eclipse 转 IDEA 那会的阵痛吧，但是磨刀不误砍柴工，阵痛之后一定是生产力提升。借本文分享下我摸索后的方案，供大家参考。

二、工具选型

目前 AI 辅助编程领域热火朝天，各种 GUI 工具、TUI 工具如雨后春笋让人目不暇接，这对于花心的强迫症选手（比如我）来说选型很困难。但是我觉得有两个基础认知可以帮助我们更好地做决定：

（一）AI 辅助编程工具由脑和手两部分组成。脑是外接的大模型 API，手是各个产品调教的提示词和内部工作流。按我理解，【脑】决定了工具的上限，【手】决定了工具的下限。在这个场景里，大模型就像是汽车里的发动机，而且所有型号的汽车支持的【发动机】规格都是通用的、统一的、标准化的。有了这个基础，我们可以随便选一个趁手的工具，然后自行按场景选配【合适】的【发动机】。

（二）AI 辅助编程当前是一个【千帆竞发】的热门领域，而且单纯就【工具】来说，这个领域【没有技术壁垒】。A 产品抛出的杀手级特性，不出半个月一定会有 B 产品跟进。毕竟现在软件迭代的速度借助 AI 提升了很多，A 产品验证过的想法，B 产品可以很快地跟进和实现。Claude Code CLI 的开发者就使用 Claude Code CLI 迭代 Claude Code CLI，有点绕口，大概就是【工具自举】的意思吧。

Claude Code CLI

综上，其实没啥纠结的，我们照着这两点来选型就好：1. 这个工具一定得便捷地支持模型插拔，就是我随时可以根据场景换一个更适合的、更便宜的、表现更好的大模型。而且这种插拔一定要简单。 2. 这个工具一定要有积极的维护者，不断地迭代、优化它的工作流、提示词。最好是一个商业化产品，因为商业化产品出于其商业目标，一定会投入资源积极进行迭代。 

当前满足这两个条件的，我想也就是 Claude Code CLI 了： 1. Claude Code CLI 是一个商业化产品，有专门的技术团队在不停地更新、迭代。 2. Claude Code CLI 可以非常便捷地支持大模型插拔，我可以随时根据成本、效率、体验来切换合适的大模型。因此，这个环节我选 【Claude Code CLI】。

后文以CC代指Claude Code CLI。

快速切换模型

我通过自定义 Shell 函数来实现便捷的模型切换，不同的场景、不同的任务使用不同的模型。基本原理就是，CC 支持环境变量注入 LLM 配置信息，因此我只需要按场景注入【行内临时环境变量】即可。

详见：Bash - 行内环境变量，Bash 是标准的 Shell 实现，其他 Shell 如 Zsh 都兼容其行为。

Shell配置

我到处弄了一堆免费的、收费的模型用，然后给他们取了我记得住的别名：

使用效果

为了兼容，设置了一个 claude 别名：

这样输入claude 时，默认使用智谱 GLM 模型。

脚本源码

Shell 脚本大概这样，可以修改后配置到自己的 ~/.zshrc 中。如果不熟悉 Shell，嫌麻烦也可以试试这个开源工具：farion1231/cc-switch。

# claude 默认
alias claude='zcc'
# Kimi
function kcc(){
    echo Kimi Claude Code...
    local model="kimi-k2.5"
    ANTHROPIC_BASE_URL="https://api.moonshot.cn/anthropic" \
    ANTHROPIC_AUTH_TOKEN="sk-xxxxxxxxx" \
    ANTHROPIC_SMALL_FAST_MODEL="$model" \
    ANTHROPIC_DEFAULT_OPUS_MODEL="$model" \
    ANTHROPIC_DEFAULT_SONNET_MODEL="$model" \
    ANTHROPIC_DEFAULT_HAIKU_MODEL="$model" \
    CLAUDE_CODE_SUBAGENT_MODEL="$model" \
    launch_claude_code $@
}
# 智谱GLM
function zcc(){
    echo GLM Claude Code...
    ANTHROPIC_BASE_URL="https://open.bigmodel.cn/api/anthropic" \
    ANTHROPIC_AUTH_TOKEN="sk-xxxxxxxxx" \
    launch_claude_code $@
}
# 七牛
function qcc(){
    echo QiNiu Claude Code...
    local model="minimax/minimax-m2.1"
    ANTHROPIC_BASE_URL="https://api.qnaigc.com" \
    ANTHROPIC_AUTH_TOKEN="sk-xxxxxxxxx" \
    ANTHROPIC_SMALL_FAST_MODEL="$model" \
    ANTHROPIC_DEFAULT_OPUS_MODEL="$model" \
    ANTHROPIC_DEFAULT_SONNET_MODEL="$model" \
    ANTHROPIC_DEFAULT_HAIKU_MODEL="$model" \
    CLAUDE_CODE_SUBAGENT_MODEL="$model" \
    launch_claude_code $@
}
function launch_claude_code(){
    CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
#    clear
    command claude $@
}

三、开发环境

在当前的气氛下，我想我算是一个【古板】的开发者，我做不到【fire and forget】，或者说完全靠黑盒的自然语言对话来完成代码开发。

我还是只将 AI 当助手，还是想要白盒的掌控 AI 写的代码，还是希望最终交付的代码有我的风格、我的审美、我的品味。毕竟 AI 也只能帮我写代码，并不能帮我背锅。尽管我选择了 TUI 工具 Claude Code CLI，但是我还做不到全程只在终端操作，我还是习惯 JetBrains 特色的双栏 diff。

因此，当前我开发流程的起点还是传统的 IDE，比如我最喜欢的 JetBrains。每天上班第一件事是接水，第二件事就是打开 IDE。所以我需要想办法来将 GUI 工具和 TUI 工具流畅的衔接起来，减少代码开发时的频繁切换产生的割裂感！

多屏协作

如上图，我有 3 个显示器，我的构想是这样的：

1. MacBook 内置显示器 —— 常驻两个空间：一个用来打开浏览器，还有 VPN、网易云音乐、Finder 软件，用来承接各种临时的操作。一个用来打开飞书，用来沟通、协作。

2. 中间主屏 —— 常驻两个空间：一个用来打开浏览器，用来做各种【输出】。一个用来打开 IDE，专注于写代码、看代码，用标签页打开多个 Project。

3. 左边竖屏 —— 常驻两个空间：一个用来打开浏览器，用于看文档、查资料等各种【输入】。一个用来打开 TUI 工具，进行辅助编程！

GUI/TUI衔接

现在问题来了，我希望我的开发工作的【主轴】是 IDE，流程的起点是 IDE。但是我的 IDE 在中间屏幕，终端在左边屏幕，它俩是独立软件，没法协作、自动跟随切换 Project 的工作目录。我希望有个【自动化流程】，当我在 IDE 里切换项目的时候，CC 自动跟随切换！

衔接流程

我期待的流程是这样的：

因为某个原因，我在 IDE 里打开了一个项目 A → 准备写代码了，点击 IDE 里的某个【按钮】，左边屏幕自动【新建】一个项目 A 的 CC 会话终端并激活到前台显示  → 我跟左边的 CC 对话，让他干活 → 我在中间的 IDE 里评审、调试、诊断 → 因为某些原因我又要在 IDE 打开一个别的项目 B → 我再次点击那个【按钮】，左边屏幕自动【新建】一个项目 B 的 CC 会话终端并激活到前台显示 → 我在 IDE 里又切回了项目 A，我又点击了那个【按钮】，左边屏幕自动【切换】到 A 的 CC 会话终端并激活到前台显示。

好的想法已经有了，AI 时代就怕你没有想法，有想法就一定有办法实现！

代码实现

1. macOS 上的原生软件，大部分支持 AppleScript 自动化，也就是说我们可以写脚本驱动软件的行为、模拟人机交互，比如打开软件、新建 tab、点击按钮等。

2. JetBrains IDE 支持集成外部命令，也就是说：可以在 IDE 里点击一个按钮，自动执行一个 Shell 脚本或者别的可执行文件。

产品需求清晰了，接下来开始让 AI 干活！一顿沟通和调试之后，我们有了一个【自动化】创建 iTerm2 新标签的可执行脚本！

这是给大模型的需求提示词，大家可以按需选用，做个性化的调整：

## 📌 工具功能说明
请帮我创建一个 macOS 上的 iTerm2 自动化工具,主要功能包括:
### 核心需求
1. **智能窗口管理**:自动使用或创建 iTerm2 窗口
2. **项目标签管理**:为每个项目目录维护独立的标签页,支持标签复用
3. **三面板布局**:自动创建固定的三面板布局(上方一个全宽面板,下方两个并排面板)
4. **命令自动执行**:在每个面板中自动切换到项目目录并执行预定义的命令
### 使用场景
```bash
# 基本用法:在当前目录打开
./open-claude-in-iterm.sh
# 指定项目目录
./open-claude-in-iterm.sh /path/to/project
```
---
## 🎯 技术架构要求
### 技术栈
- **Shell 脚本** (open-claude-in-iterm.sh):参数处理、路径规范化、日志管理
- **AppleScript** (open-claude-in-iterm.applescript):iTerm2 自动化核心逻辑
- **依赖**:macOS、iTerm2、Bash
---
## 📋 详细功能规格
### 1. Shell 脚本 (open-claude-in-iterm.sh)
#### 参数处理
- **参数1**:项目目录(可选,默认当前目录)
- **自动处理**:相对路径转绝对路径
#### 面板命令配置
```bash
PAN1_CMD="claude"     # 上方面板命令
PAN2_CMD="claude"     # 左下面板命令
PAN3_CMD="claude"     # 右下面板命令
```
### 2. AppleScript (open-claude-in-iterm.applescript)
#### 主要流程
**步骤1:窗口管理**
- 检查 iTerm2 是否运行(未运行则自动启动)
- 使用当前激活的 iTerm2 窗口,如果没有则创建新窗口
**步骤2:标签管理(关键逻辑)**
- 在找到的窗口中,查找 `session.path` 变量等于项目目录的标签
- **复用逻辑**:如果找到现有标签 且 窗口不是新创建的 → 直接切换标签并返回
- **创建逻辑**:如果未找到标签 或 窗口是新创建的 → 创建新标签和布局
**步骤3:三面板布局创建**
```
布局示意图:
┌─────────────────────────┐
│   上方面板 (全宽)         │
│   执行: PAN1_CMD         │
├──────────────┬──────────┤
│  左下面板    │  右下面板 │
│  PAN2_CMD   │  PAN3_CMD │
└──────────────┴──────────┘
```
**分割顺序(重要)**:
1. 初始状态:一个全屏 session(上方面板)
2. 第一次分割:对上方 session 执行**水平分割**,创建下方面板
3. 第二次分割:对下方 session 执行**垂直分割**,创建右下面板
**步骤4:命令执行**
在每个面板中依次执行:
1. 切换到项目目录:`cd "/path/to/project"`
2. 清屏:`clear`
3. 等待 0.3 秒(确保目录切换完成)
4. 执行命令:`PAN_CMD`
5. 等待 0.5 秒(确保命令启动)
## ⚠️ 常见错误
- ❌ 符号链接未处理,导致找不到 AppleScript 文件
- ❌ 分割顺序错误,导致布局不正确
- ❌ 缺少 delay,导致命令执行失败或在错误目录执行
- ❌ 新窗口处理错误,导致多余空白标签
- ❌ 标签复用逻辑错误,导致同一项目创建多个标签
- ❌ 路径未引用,导致包含空格的路径失败

IDE配置

创建外部工具

添加到工具栏

使用效果

点击工具栏按钮后，自动在全屏的 iTerm2 窗口新建或激活项目目录下的 CC 会话，下图里就是 3 个项目。

四、多Agent协作

会的越多，让你干的就越多。既然 AI 那么牛，一个 CC 会话已经满足不了我膨胀的想法和需求了。我希望我可以同时支配多个 AI 开发工程师，而我变成 PM！所以参考酒米的思路，我给每个项目的终端，自动化的划分了 3 个子窗口，每个子窗口都是一个 CC 会话。效果大概这样：

主从架构

每个项目自动打开 3 个常驻的 AI 会话，我设想的工作流是这样的：

【架构师】上面的大屏，用贵的模型！专门用来跟我聊需求、对方案、产出任务列表。

【开发者】下面的两个小屏，用领域特定的模型，专门用来落地大屏架构师产出的方案和任务。比如前端需求用前端效果好的模型，后端需求用后端效果好的模型。

知人善用才是好 PM！这个模式也很匹配现实中的组织架构和成本取舍，现实中每个需求一般也都是由一个架构师和多个中高级开发者来协作完成！感谢热心市民无声雨，给我们小组共享了自己采购的纯血 Claude 模型，所以目前我用 Claude 模型来对方案，用 GLM 或者 MiniMax 来实施方案！

规范驱动开发(SDD)

主从智能体的协作很重要，我跟【架构师】聊了半天确定的方案和设计，需要有一个清晰的、对大模型友好的方案和任务文档作为【开发者】的输入。这就很巧，刚好最近在流行 SDD，规范驱动开发。大致就是模拟现实中的软件开发流程将开发生命周期拆分为 3 个阶段：

• 【proposal】需求对齐、方案设计、【任务细化】；
• 【apply】开发任务实施；
• 【archive】功能验收、文档沉淀

围绕这个流程，开源社区设计和研发了一系列对大模型非常友好的工具和提示词（比如 OpenSpec），【阶段 1】和【阶段 2】中间通过格式设计良好的【设计文档和任务文档】来进行上下文交接。

也就是说，我可以在上述的 3 窗口环境中，按照 SDD 流程来：【proposal】跟【架构师】交互，对齐需求、设计和任务 A → 【apply】让【开发者 1】着手完成任务 A → 【proposal】继续跟【架构师】交互，对齐需求、设计和任务 B → 【apply】让【开发者 2】着手完成任务 B → 【proposal】继续跟【架构师】交互，对齐需求、设计和任务 C → 【apply】让【开发者 1】着手完成任务 C → ……

五、CC拓展

CC 当然很厉害，但它本质上也就是一个朴素的 ReAct 模式智能体。

ReAct 这么火，大家肯定也都耳熟能详了，我们也就不说太多。当然 CC 团队围绕编程这个课题做了很多细致的提示词调优和内置工作流设计，这个我们黑盒的用就好了，也没必要关注太多。我们最需要关注的，是 CC 提供给我们使用者的【拓展点】，那些允许我们个性化设置的东西。

命令(command)

命令的本质就是预定义的提示词模板。目的是为了省事，不用每次都重复的输入类似的提示词。比如想让 CC 帮我提交代码，每次我们可能都要交代一大堆字，比如：

请调用 git diff --cached 获取当前暂存区的代码变动。
忽略所有的 node_modules 或二进制文件。
基于变动内容，判断这是一个 feat (新功能), fix (修复) 还是 chore (杂务)。
生成一个不超过 50 字符的标题，并在正文详细列出影响的文件。
由我确认后执行 git commit。”

就像写代码的时候将重复代码提取为一个独立方法一样，我们可以把这些可以复用的提示词固定成一个【命令】，后续使用的时候，直接输入命令名字就好。斜杠命令是一段提示词的快捷方式。

技能(skill)

技能和命令最大的差别就是：命令是用户主动提交的提示词，而技能是 Agent 自己决策后自动导入的提示词。当然技能包里除了提示词，一般还会携带一些配套的工具、脚本、命令或者文档。

比如，我安装了一个【html 转 pdf 的技能包】，这只能提示 CC 可以使用这个技能，但是具体用不用、什么时候用、怎么用都是 CC 自己规划、决策的。

子代理(subAgent)

SubAgents 是可以并行处理任务的独立 AI 代理，每个子代理拥有独立的上下文窗口，可以分配不同任务以提高效率。【主代理】的上下文窗口中包含有【子代理】的【简短】描述信息，可以基于这个描述信息规划、决策使用哪个子代理。

{
  "agents":{
    "code-reviewer":{
      "description":"专门负责代码审查的子代理",
      "model":"claude-opus-4-5",
      "instructions":"你是一个专业的代码审查专家,专注于检查代码质量、安全漏洞和性能问题。",
      "tools":["read","search","git"],
      "permissions":{
        "allowWrite":false
      }
    },
    "test-writer":{
      "description":"专门负责编写测试的子代理",
      "model":"claude-sonnet-4-5",
      "instructions":"你是一个测试工程师,专注于编写全面的单元测试和集成测试。",
      "tools":["read","write","bash"]
    },
    "doc-generator":{
      "description":"专门负责生成文档的子代理",
      "model":"claude-sonnet-4-5",
      "instructions":"你是一个技术文档专家,专注于生成清晰、准确的技术文档。",
      "tools":["read","write"]
    }
  }
}

独立上下文窗口的好处是：避免上下文污染和占用。比如我要在代码里找一个接口的所有实现类，这个就很适合子代理来做。主代理只需要交代给子代理接口名，然后就等子代理返回实现类列表。

这样在主代理的上下文窗口里，只会有子代理的输入和输出（几个类文件路径），而子代理在搜索过程中遍历文件、目录、读取文件内容产生的临时 token，不会对主代理产生影响。我目前认为 SubAgent 和 Skill 差不太多。不过我不确认 Skill 是不是在独立的上下文中执行。

MCP

MCP 和技能一样，都是由 CC 自主规划、决策使用的。差别有两个：

1. MCP 工具的说明信息占用的上下文太多了！不管是否被使用，每次都需要一口气提交所有工具的完整元信息（使用说明 + 出入参 Schema）供大模型规划、决策，占用大量上下文。而【技能】选择了【渐进式披露】，先向大模型提供少量关键信息，只有在大模型选择了使用技能时，才告诉大模型更多关于技能的补充说明信息，让大模型进一步推理、决策。

2. MCP 工具更多的偏向【远程 RPC】，基于网络来实现原子化的远程能力调用。而【技能】更多的偏向【本地 IPC】，具体能力更多通过【编排】本地脚本、本地命令来实现，有点像 stdio 模式下的 MCP。

钩子(hook)

hook 是在特定事件触发时自动执行的脚本，用于自定义工作流、拦截危险操作、自动格式化代码等。就类似 Linux NetFilter，CC 在很多地方植入了流程执行的劫持点，将流程上下文交给用户开发的脚本或者命令。

插件(plugin)

plugin 就是上述各种拓展打包、分发、安装的一种格式。你可以把它想象成 npm 包、pip 包、apk 包等我们比较熟悉的概念。然后我们可以按流程和格式建设插件市场，类似 pip-index、npm-index 等。

我没有细看流程和格式，但是大概也就是一个特定文件布局的 zip 文件包，里面有插件描述信息和各类拓展，比如可以包含：

• 5 个 Skills；
• 10 个斜杠命令；
• 3 个 MCP 服务器配置；
• 2 个 SubAgent 定义；
• 若干 Hooks。

六、CC技巧

飞书MCP

飞书官方提供了 MCP，我主要用它来读写飞书文档，蛮好用的，大家可以试试。比如我每周都要在固定目录下创建固定标题格式的【系统巡检文档】，所以我借助飞书 MCP 整了个自定义 Command 帮我自动创建这些文档去除重复劳动，感觉真香！之前每次都要手动建 3 个文档、选目录、改名字！

@模糊搜索

有时候我们需要精确的告诉 CC，哪个文件需要读或者改，其实不用从 IDE 里复制文件路径，直接在终端里模糊搜索就好了。

WebFetch

CC 默认集成了 WebFetch 命令，就是指定 URL 读取网页内容，这个理论上就是一个本地执行的 curl 命令，没有云端成本，不需要云端协作。但是有个问题：（一）CC 在访问地址之前，会先调用 anthropic.com 的一个风控接口，判断这个网络地址是否有安全风险。（二）政策原因，anthropic.com 会拒绝所有来自中国大陆、香港的请求，风控接口返回 404 或者其他。（三）风控不通过，WebFetch 失败。

在 ~/.claude/settings.json 中添加如下配置，禁用 WebFetch 工具前置的风控检查就好了。

{
  "skipWebFetchPreflight":true,
}

详见：linux.do/t/topic/114…

WebSearch

WebSearch 是需要云端协作的，需要有个搜索引擎服务提供能力。因为我们没有用官方的付费订阅，所以默认的 WebSearch 工具我们用不了，调用 WebSearch 工具得到的结果都是 0。

办法是去找一个免费或者收费的 MCP 服务。免费的我看大家都推荐 Brave<brave.com>，大家也可以找找别的。收费的也有很多，我看智谱的套餐里限量提供了 <联网搜索 MCP - 智谱 AI 开放文档>。也有很多按量付费的，大概几分钱一次，有需要的可以找找。

添加了 MCP 搜索工具后，建议禁用 CC 自带的 WebSearch 工具，不然每次跟大模型交互时，工具信息还会带给大模型，产生额外的 token 开销和推理误判。在 ~/.claude/settings.json 中添加如下配置：

{
  "permissions":{
    "deny":[
      "WebSearch"
    ]
  }
}

iTerm2通知

终端上的任务需要我们输入的时候，可以配置下，让 iTerm2 发出声音和通知。这样我们就不会因为忘记确认操作而阻塞进度。

详见：Optimize your terminal setup - Claude Code Docs

清空上下文

因为我们每个项目都复用一屏内的 3 个子窗口，一般不会重开。为了避免上下文溢出或者之前对话对新任务产生干扰，当我们完成一个任务时，需要及时的执行 /clear 命令，清空上下文，从 0 开始新对话。

如果任务没有完成，但是又不得不 clear，那么可以维护一个自定义命令，在 clear 后提示大模型根据 git status 看到的文件变更快速找回上下文。把 git 状态当作 AI 的 “短期记忆快照”，/clear 只清上下文，不清工作进度。

# Context Catch-up
当前对话已被 `/clear`，请通过 git 状态恢复上下文。
使用方式：
1. 阅读 `git status`（必要时结合 `git diff`）
2. 仅基于文件变更推断正在进行的任务
3. 延续现有实现思路，不要假设额外背景
4. 在未收到明确指令前，先给出你对当前上下文的判断
目标：
- 快速找回任务状态
- 避免旧对话或错误假设干扰新任务

注意力哨兵

在记忆文件里要求大模型扮演一个特别的角色，如果聊着聊着角色行为丢失了，说明大模型注意力失焦了，已经丢掉了你最开始的要求。这时候就该 clear 一下重开会话了。

拓展市场

为了便于相关个性化拓展物料的分发、便于大家搜索、安装，市面上已经有了相关的分发平台和便捷安装命令了。

1. skills.sh

2. www.aitmpl.com

状态行个性化

状态行显示在 Claude Code 会话界面底部，可以自定义显示的内容，比如git分支名、目录名、模型名等。推荐使github开源项目：claude-code-statusline-pro-aicodeditor，效果如下：

详见：github.com/HorizonWing…

七、总结

差生文具多，尽管我暂时还没有使用 CC 产出啥说得上来的东西，但是确实花了很多时间琢磨怎么让它用起来更顺手。一些不成熟的想法，希望可以给到大家启发。

参考：

1. www.ginonotes.com/posts/how-i…
2. www.cnblogs.com/knqiufan/p/…

往期回顾

1.AI编程能力边界探索：基于 Claude Code 的 Spec Coding 项目实战｜得物技术

2.搜索 C++ 引擎回归能力建设：从自测到工程化准出｜得物技术 

3.得物社区搜推公式融合调参框架-加乘树3.0实战

4.深入剖析Spark UI界面：参数与界面详解|得物技术

5.Sentinel Java客户端限流原理解析｜得物技术

文 /羊羽

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。