效率工具 on 火炬树

Pi Agent 配置进阶：AGENTS.md、模型切换与 Thinking Level 实战指南

Wed, 22 Jul 2026 12:14:08 +0800

在《Pi Coding Agent 实战配置：从安装到日常使用的完整指南》一文中，我们介绍了 Pi 的安装、首次配置和核心扩展包。那些内容让初学者能快速上手，但 Pi 的真正灵活性藏在它的配置文件里。

Pi 的核心只有 418 行 TypeScript，默认只给模型四个工具（read、write、edit、bash）。它的所有高级行为，包括用什么模型、用多大的上下文、以什么样的思考深度执行任务，都通过外部配置文件控制。理解这些配置文件之间的关系和优先级，是把 Pi 从"能用"推向"好用"的关键一步。

Pi 的配置文件分几层？每层管什么？

Pi 的配置体系采用分层叠加的设计。理解每一层的职责范围和优先级顺序，就不会出现"改了没生效"的情况。

全局配置放在 ~/.pi/agent/ 目录下，影响所有项目。项目配置放在项目目录的 .pi/settings.json 中，只覆盖当前项目。项目配置中的嵌套对象会与全局配置合并，而非整体替换。

除了两层 settings.json，Pi 还使用了四种专门化的配置文件，各有不同的用途：

配置文件	位置	用途	加载时机
AGENTS.md	项目根目录或 ~/.pi/agent/	项目上下文与编码指令，注入 system prompt	启动时自动加载
APPEND_SYSTEM.md	~/.pi/agent/	全局行为规则，追加到 system prompt 尾部	启动时加载
settings.json	全局或 .pi/	模型选择、UI 主题、压缩策略、重试等运行参数	启动时加载
models.json	~/.pi/agent/	自定义模型与 Provider（Ollama、vLLM 等）	每次打开 /model 时重新加载
auth.json	~/.pi/agent/	API Key 和 OAuth 凭据（权限 0600）	按需读取

以下逐层拆解每一份配置的最佳实践。

AGENTS.md 怎么写才有效？

AGENTS.md 是 Pi 理解项目上下文的主要入口。Pi 启动时，会从多个位置查找并拼接内容注入 system prompt：先加载 ~/.pi/agent/AGENTS.md（全局指令），然后向上遍历父目录，最后加载当前目录的 AGENTS.md。

换句话说，全局的 AGENTS.md 定义你作为开发者常用的技术栈和通用规范，项目的 AGENTS.md 定义这个特定项目的约束和流程。

全局 AGENTS.md 写什么

全局 ~/.pi/agent/AGENTS.md 适合记录你日常使用的技术栈偏好。DeepakNess 在他的博客中分享的全局 AGENTS.md 是一个很好的参考案例：

这段内容来自 DeepakNess 的 Setting Up and Using the Pi Coding Agent 一文。它没有写得过于具体，而是给出宽泛的技术栈提示，同时要求 Pi 优先参考项目级别的 AGENTS.md。

项目 AGENTS.md 怎么组织

项目级别的 AGENTS.md 需要更精确。以下是一个针对 TypeScript 项目的模板，基于 Pi 官方文档的建议整理：

如果你管理多个项目，建议为每种项目类型维护一份模板。每次新建项目时复制过去，修改技术栈相关字段即可。

修改后记得重载

每次修改 AGENTS.md，需要执行 /reload 或重启 Pi 才能生效。这个操作的触发频率不高，但容易忘记。建议写完一段新规则后立即测试，确认 Pi 的行为如预期变化。

APPEND_SYSTEM.md 控制什么行为？

~/.pi/agent/APPEND_SYSTEM.md 追加到 system prompt 的末尾，优先级高于 AGENTS.md。这意味着它的指令会覆盖前面的内容。

它适合定义那些跨项目通用的行为准则，尤其是关于代理如何工作、如何与用户交互的约束。参考官方的建议和社区实践，一个典型的 APPEND_SYSTEM.md 内容如下：

这些规则确保 Pi 在各种项目中保持一致的工作方式，不必在每次对话开头重新交代。

settings.json：常用选项详解

settings.json 有两层：全局（~/.pi/agent/settings.json）和项目（.pi/settings.json）。项目层的嵌套对象会与全局层合并。参考 Pi 官方 Settings 文档的内容，以下是最值得关注的配置项：

模型与思考级别

defaultProvider 和 defaultModel 控制 Pi 启动时默认使用的模型。defaultThinkingLevel 设置思考深度，可选项包括 off、minimal、low、medium、high、xhigh、max。

enabledModels 是一个高性能设置。它定义了 Ctrl+P 循环切换时的模型列表，支持通配符。如果不定这个值，Ctrl+P 会遍历该 provider 下所有可用模型，使用体验会大打折扣。

thinkingBudgets 可自定义每个思考级别的 token 预算。上面的数值参考了 Pi 官方文档中给出的默认值。是否调整取决于你的模型和任务：预算越高，思考越深，token 消耗也越大。

上下文压缩（Compaction）

Compaction 是 Pi 处理长上下文的核心机制。当会话长度接近上下文限制时，Pi 自动将旧消息摘要压缩，为后续对话腾出空间。

reserveTokens：为 LLM 响应保留的 token 数（默认 16384）。这个值越小，压缩发生得越早。
keepRecentTokens：保留不被摘要的近期 token 数（默认 20000）。被保留的消息保持原样，保证最近讨论的内容不会丢失。

如果你常处理长会话，可以调大 keepRecentTokens。但要注意，这会降低压缩效率，可能更早达到模型上下文窗口上限。

重试策略

retry 配置分两层：agent 级别的重试（Pi 自己处理）和 provider 级别的重试（由 API SDK 处理）。官方文档建议将 retry.provider.maxRetries 保持为 0，因为 provider 层的重试可能在看见 rate limit 错误前就已经消耗了配额。

baseDelayMs 控制指数退避的初始延迟：2 秒 → 4 秒 → 8 秒。对于需要长时间稳定运行的任务（例如批量数据抓取），可以适当调大这个值。

项目信任模式

Pi 在项目中首次启动时，会询问是否信任该项目的 .pi/ 目录。这个机制的目的是防止恶意项目插件自动加载。

可选值包括 ask（每次询问，默认）、always（自动信任）、never（从不信任）。在 CI 或自动化场景中，可以用 -a / --approve 参数跳过询问。

models.json 添加自定义模型

如果你的模型不在 Pi 内置的 20 多个 Provider 中，可以通过 ~/.pi/agent/models.json 添加。这个文件支持 Ollama、LM Studio、vLLM、OpenRouter、Cloudflare AI Gateway，以及任何 OpenAI 兼容 API 端点。

参考 Pi 官方 Models 文档的完整配置说明，以下是最常见的三种场景：

场景一：Ollama 本地模型

apiKey 写 "ollama" 只是一个占位符。Ollama 并不验证 API Key，但 Pi 需要 auth 才会在 /model 中显示模型。compat 中的两个开关针对 Ollama 的特点：它不支持 developer role 和 reasoning_effort 参数。

以 name 字段给出人类可读的标签。Pi 在模型选择器中和 --model 模式匹配时都会用到这个值。

场景二：OpenRouter 路由配置

OpenRouter 允许你在多个 API 提供商之间设置路由偏好。以下配置参考了 Pi 官方文档中的 OpenRouter 示例：

openRouterRouting 对象会被原样传递给 OpenRouter API 的 provider 字段。order 指定提供商优先级，data_collection: "deny" 拒绝数据用于训练。

场景三：代理中转 Anthropic API

如果你通过第三方代理使用 Anthropic Messages API，可以这样配置：

在 models.json 中，apiKey 和 headers 支持三种值解析方式：直接字面量、$ENV_VAR 环境变量插值、!command 命令执行。Bitdoze 在 Pi Coding Agent Setup Guide 中评价：Pi 支持 Ollama、LM Studio、vLLM、任何 OpenAI 兼容端点。这个扩展能力是它相较同类工具的重要优势。

auth.json 管理 API 凭据

~/.pi/agent/auth.json 存储所有 Provider 的 API Key 和 OAuth Token。它的权限被设置为 0600，只允许当前用户读写。

auth.json 支持三种 key 解析方式：

字面量：直接用 API Key 字符串
环境变量插值："$MY_KEY" 或 "${KEY_PREFIX}_${KEY_SUFFIX}"
Shell 命令："!security find-generic-password -ws 'anthropic'"

官方文档指出，auth.json 的优先级高于环境变量。这意味着如果你同时设置了 DEEPSEEK_API_KEY 环境变量和 auth.json 中的 deepseek 条目，后者会覆盖前者。

一个实用技巧是使用 shell 命令从系统密钥链中读取凭据，避免将 API Key 明文写入任何文件：

模型切换策略：什么时候用什么模型

Pi 的一个核心优势是模型无关性。你可以为不同的任务选择不同的模型，切换在瞬间完成。

切换方式

操作	快捷键 / 命令	说明
打开模型选择器	Ctrl+L 或 /model	快速切换模型
循环切换模型	Ctrl+P	在 enabledModels 列表间轮换
调整思考级别	Shift+Tab	切换 thinking 深度
中断当前操作	Escape	取消正在执行的任务
发送转向消息	Enter	中断代理当前工作流，立即响应
发送后续消息	Alt+Enter	在代理完成工作后追加消息
退出	Ctrl+C（按两次）	退出 Pi
文件引用	@	模糊搜索文件
运行命令	!	发送命令输出给模型
静默命令	!!	运行命令但不加入上下文

快捷键部分参考了 Pi Agent 中文指南和 DeepakNess 的设置文章。

任务类型	推荐模型	思考级别	理由
快速编辑、文件操作、批量脚本	DeepSeek V4 Flash / MiniMax M2.7	low 或 off	成本极低，对快速任务足够
日常编码、中小型重构	DeepSeek V4 Pro / Qwen 3.6 Plus	medium	平衡质量与成本
深度分析、架构设计、复杂调试	DeepSeek V4 Pro / Claude Sonnet 4	high 或 xhigh	需要更深的推理链
视觉任务（截图理解、UI 分析）	Kimi K3 / Claude	取决于模型	主模型无视觉能力时通过 pi-vision-proxy 代理

enabledModels 通配符

为了让 Ctrl+P 切换更高效，建议在 settings.json 中设置 enabledModels 列表：

通配符匹配所有符合条件的模型。如果你只需特定的两三个模型，也可以写成精确 ID：

Thinking Level 如何影响输出质量

Pi 的 thinking level 是一个分层参数，控制模型在回答前的推理深度。参考 pi.dev 官方 Settings 文档和 models.md 中的 thinkingLevelMap 说明，不同级别对应不同的行为特征：

级别	适用场景	token 预算（默认）
off	简单问答、不需要推理的任务	无推理 token
minimal	非常简单的判断，如"是/否"分类	1024
low	轻度推理，如格式化、简单转换	4096
medium	常规编码任务	10240
high	复杂重构、调试	32768
xhigh	深度分析、架构设计	65536
max	极端复杂的多步骤推理	provider 上限

个级别之间的差异不是线性的。从 low 到 medium，输出质量提升最明显；从 high 到 xhigh，边际收益递减。实际使用中，80% 的日常任务在 medium 级别就能得到满意结果。

对于支持 thinkingLevelMap 的模型，你可以在 models.json 中精细控制每个级别映射到 provider 端的具体参数。例如某个模型可能只需要 high 和 max 两级，中间级别可以跳过：

这个机制来自 Pi Models 文档中的 thinkingLevelMap 说明。当模型不支持某些级别时，Pi 会自动跳到相邻的支持级别。

上下文管理：Compaction、会话树与手动控制

长会话是编码代理的常态。Pi 提供了三层上下文管理机制。

自动压缩（Compaction）

Compaction 在后台运行。当上下文长度接近模型窗口上限时，Pi 自动对旧消息进行摘要。compaction.reserveTokens 控制压缩触发时机：当剩余 token 少于这个值时触发。compaction.keepRecentTokens 确保最近的消息不被摘要。

如果希望更精细地控制，可以手动触发 /compact，Pi 会立即压缩当前会话。

会话树管理

/tree 命令显示会话历史树形结构。每个分支代表一次对话路线。Pi 支持：

/resume：恢复之前的会话继续工作
/new：新建会话
/fork：从当前会话分支，开始一条新的对话线

这个设计让用户可以在不丢失上下文的情况下尝试不同的解决方案路径。

一套完整的配置模板

结合以上所有内容，以下是一套可以投入日常使用的完整配置。

全局 settings.json

全局 APPEND_SYSTEM.md

项目 .pi/settings.json（覆盖全局压缩策略）

这个覆盖让需要频繁压缩的短会话项目更早触发压缩，避免浪费上下文窗口。

总结

Pi 的配置文件体系围绕一个核心原则：层层叠加，精确控制。全局配置定义通用行为，项目配置覆盖特定需求，AGENTS.md 传递项目上下文，APPEND_SYSTEM.md 约束代理行为模式。

当你理解了每一层配置的职责和优先级，Pi 的"最小核心 + 外部配置"设计哲学就不再是"功能少"的缺点，而变成"你控制一切"的优势。每天面对不同任务时，只需通过 Ctrl+P 切换模型、Shift+Tab 调整思考深度，就能在不同工作模式之间快速切换。

如果你的配置已经覆盖了本文提到的主要文件，下一步可以关注扩展系统：通过 pi install 添加 pi-web-access（网页搜索）、pi-codex-goal（任务追踪）、pi-vision-proxy（视觉代理）等包，逐步搭建完全适合自己工作流的 Pi 环境。

参考来源：

Pi Coding Agent 实战配置：从安装到日常使用的完整指南

Sat, 13 Jun 2026 02:01:27 +0800

Pi 是一个开源的终端编码代理，由 libGDX 作者 Mario Zechner 开发。它的核心只有 418 行 TypeScript，默认提供 read、write、edit、bash 四个工具，所有高级功能通过扩展和包来补充。此前我们已经从架构层面深入分析过 Pi 的设计哲学，本文则聚焦于实际使用场景：如何安装、配置、选择扩展包，以及如何将 Pi 融入日常开发工作流。

定位：Pi 在工具链中的角色

Pi 并非要替代所有编码工具。以 DeepakNess 的实际使用为例，三款工具各有分工：

OpenAI Codex：处理主项目的复杂任务
Cursor：主项目的日常编码
Pi：副项目、实验性任务、一次性脚本，通常搭配更便宜的开源模型

这种分层策略的核心逻辑是：复杂度高的任务用强模型 + 重型工具，简单或探索性的任务用轻量代理 + 低成本模型，控制整体开支。

安装与首次配置

Pi 的安装只需一行命令：

安装完成后在终端输入 pi 启动，通过 /login 命令完成认证。Pi 支持两种认证方式：

订阅登录：支持 Claude Pro/Max、ChatGPT Plus/Pro、GitHub Copilot、Google Gemini CLI 等
API Key：选择 “Use an API key”，输入对应提供商的密钥（如 DeepSeek）

模型选择使用 /model 或 Ctrl+L 打开选择器。作者默认使用 deepseek-v4-pro 配合 xhigh 思考级别用于深度分析，切换到 deepseek-v4-flash 处理快速任务。

三个核心扩展包

Pi 通过 pi install 安装扩展包。以下三个包覆盖了大部分实用场景：

pi-web-access

赋予 Pi 网页搜索、内容抓取、YouTube 转录和 GitHub 仓库探索能力。

配置文件位于 ~/.pi/web-search.json：

pi-codex-goal

为长时间运行的任务添加目标追踪机制，适合需要多步骤完成的复杂任务。

pi-vision-proxy

当主模型不具备视觉能力时，将图片分析请求代理到支持视觉的模型（如 Kimi K2.6）。

配置文件体系

Pi 的配置分两层：

AGENTS.md（项目上下文）：放在项目根目录或 ~/.pi/agent/AGENTS.md，内容会注入 system prompt。适合定义项目技术栈、编码规范等。

APPEND_SYSTEM.md（全局行为规则）：位于 ~/.pi/agent/APPEND_SYSTEM.md，追加到系统提示末尾，优先级高于 AGENTS.md。适合定义跨项目的通用行为准则，例如：

主模型不具备视觉能力时自动使用 vision proxy
优先使用本地文件，只在必要时联网搜索
解释高风险的编辑和命令
简洁写作，避免 AI 腔

快捷键与常用命令

Pi 的交互设计围绕终端效率展开：

操作	快捷键 / 命令	说明
打开模型选择器	Ctrl+L 或 /model	快速切换模型
循环切换模型	Ctrl+P	在已配置的模型间轮换
调整思考级别	Shift+Tab	切换 thinking 深度
中断当前操作	Escape	取消正在执行的任务
发送转向消息	Enter	中断代理当前工作流，立即响应
发送后续消息	Alt+Enter	在代理完成工作后追加消息
退出	Ctrl+C（按两次）	退出 Pi

常用命令包括 /model、/settings、/resume、/new、/tree（会话分支管理）、/compact（手动压缩上下文）、/session。

实际成本案例

一个典型的使用场景：用 DeepSeek v4 Flash 抓取 28.5 万个 URL，耗时约 1.5 小时，总费用 $1。这体现了 Pi 搭配开源模型的成本优势。

为什么选择 Pi

Pi 的核心优势在于：

终端原生：无 UI 卡顿，响应迅速
模型无关：通过 /model 随时切换 provider，上下文无缝迁移
高度可定制：扩展和包机制让用户按需组装功能
会话树管理：/tree 命令支持分支和导航对话历史
自动上下文压缩：接近上下文限制时自动摘要

对于终端用户而言，Pi 的价值不在于"功能最全"，而在于"可控性最高"。它的每一个行为都是透明的，每一个功能都是显式安装的。这种设计哲学让它成为副项目和实验性任务的理想选择。

参考来源：

一人日更、篇均 12 万曝光：一套可复用的 AI 内容生产系统

Sat, 09 May 2026 06:11:59 +0800

X 创作者 @yidabuilds（百年 AI×出海）在一条推文中公开了他日更不断更背后的内容生产系统。这套系统的原型来自 @dontbesilent 分享的 Claude Code 工作流，经改造后适配 X 长文场景。截至发文时，该系统已支撑他发布十几篇长文，篇均曝光约 12 万，累计涨粉 9000+，书签率稳定在 0.5-1%。

本文基于该推文的完整内容整理，保留核心方法论与数据细节，供有类似需求的创作者参考。

核心思路：从碎片化提问到闭环系统

@dontbesilent 提出的核心问题是：大多数人用 AI 做内容是碎片化的——有想法就问 AI，拿到答案就发，发完就忘，下次又从零开始。

他的解法是把整个过程变成闭环：想法记进选题库 → AI 检索素材库找可复用的东西 → 套已验证的框架写 → 发布 → 数据复盘 → 把有效的规律沉淀回方法论。每次创作都在给系统加东西，而不是每次重新发明轮子。

@yidabuilds 直接采用了这一思路，并根据自己的需求做了大量改造。

四层知识库：Obsidian + Claude Code

整个系统以 Obsidian 管理内容，Claude Code 执行自动化流程，拆成四层。

第一层：语料库——解决"AI 写出来不像你"

AI 写长文最大的问题是 AI 味太重。长文读者一个字一个字读，机器感一重就感觉不对。

@yidabuilds 的解法是把自己说过的话全部存下来：推文、微信聊天记录里的观点、录音、随手记的碎片想法。从中提炼出一份写作风格指南，例如：

喜欢先下结论再给理由
喜欢用数字不用形容词
喜欢拿别的行业逻辑解释当前这件事
不用鸡汤收束

AI 每次写稿前先读这份指南，出来的初稿至少七八分像本人。写完再跑一遍"去 AI 味"检测，把机器感太重的表达标出来人工修改。

检测规则包括：

问题类型	示例	处理方式
营销体大词	赋能、闭环、打通、底层逻辑	看到就删
替读者说话	「你可能觉得……」「很多人会问……」	你怎么知道别人觉得什么
指令语气	「记住」「一定要」「核心就一句话」	在聊天不是在上课
虚构数据	「90%的人不知道」	你哪来的 90%
独立短句装戏剧感	一句话。一个词。成段。	这个最 AI 味
加粗口号金句	真正厉害的人都在……	删

两步加上去之后，长文的人味改善明显。

第二层：素材库——站在别人的数据上选路线

素材库包含 47 个同类账号的拆解、1100 多篇内容的数据、爆款文章的结构分析、可复用的概念和金句。

每次写新文章之前，AI 先翻一遍素材库：同类话题谁写过、什么角度跑出了数据、什么结构读者愿意存。

拆完 47 个账号之后，有几个发现直接影响了选题策略：

100 万+ 曝光的内容只有 5 类：刚需工具教程、医学健康科普、AI+搞钱、人设解析文、资源合集。其他类型几乎不可能过百万
书签率和曝光不一定正相关。有些文章曝光一般但书签率很高，说明内容有长期价值，读者存了以后用——这类内容值得反复写
涨粉和曝光也不一定正相关。人设文 119K 曝光涨了 156 粉，教程文 77K 曝光只涨 25 粉。人设让人想 follow 这个人，教程让人存了就走

第三层：内容管线——按策略挑选题，不是临时想写什么写什么

管线分四阶段：选题池 → 待深化 → 创作中 → 已发布。池子里长期保持十几个随时能写的选题，十几个需要补素材的备选。

选题分几个赛道轮着来：项目实战、AI 搞钱赛道拆解、草根低门槛生意、AI 新范式趋势。每个赛道的选题强度不一样：

硬核工具教程：曝光最高
人设自我介绍：涨粉最猛
数据复盘：受众窄但书签率好

根据当前目标选选题：要曝光就发教程，要涨粉就发人设，要沉淀就发复盘。

第四层：方法论——从自己的数据里提炼规律

什么标题有效、什么选题能爆、什么结构书签率高——全从自己的发布数据里提炼。

标题是最容易量化的部分。跑了十几篇长文之后，出数据的标题基本落在四个模式里：

模式	示例	曝光
身份+数据+承诺	00后用 Claude Code 做副业，4 个月变现超 10 万	12 万
低门槛+高结果	不到 200 粉账号的第一篇文章，如何冲到 6 万展示	2.5 万
帮你省时间	公众号文章批量采集完全指南：5 种方法+实战脚本	20 万
反差数据	十几张配图带来几十万流量，花了不到五毛钱	0.8 万

发之前过一遍检查清单：有没有具体数字？有没有身份标签？有没有反差？读者看完标题知不知道能得到什么？命中越多数据越好。

配图策略：HERO 图、标题、钩子三件套信息不重复

X 长文的配图很关键。信息流里用户的注意力顺序是 HERO 图 > 标题 > 正文。图不行，标题再好也没人点。

原则：HERO 图、标题、钩子三件套传递三层不同的信息，不重复。

HERO 图：一眼告诉你"这是什么类型的内容"
标题：给一个让人停下来的数据锚点
正文第一段：展开细节

配图两种风格，根据内容类型自动选：

教程类：信息图风格——白底、浅色装饰气泡、圆角卡片、扁平图标、大号中文标题，像 SaaS 官网那种干净的 hero banner
观点类：概念海报——大字作为画面骨架，角色和文字咬合，像展览海报不是 PPT

每篇长文一张封面加两三张内页信息图。AI 根据文章内容生成 prompt，调 GPT Image 2 的 API 出图，下载裁切到需要的比例。以前 Canva 一张调半小时，现在 10 分钟出三张。

数据表现：篇均 12 万曝光，书签率 0.5-1%

标题	曝光	书签	书签率
Codex 实战入门	24 万	1161	0.48%
AI 算命，闷声发大财	21 万	2110	1.01%
公众号文章批量采集完全指南	20 万	1431	0.71%
4 个月变现超 10 万	13 万	845	0.63%
美股投资从 0 到 1 完全指南	10 万	468	0.48%

AI 算命那篇书签率最高，1.01%——AI+搞钱+信息差的组合，读者存得最积极。

从数据里长出来的四条规律

“从数据里长规则"是 @dontbesilent 的核心方法论。以下是 @yidabuilds 自己的 X 长文数据跑出来的具体规律：

标题里必须有具体数字。 “4 个月变现 10 万”"$155 vs $15"“452% 收益率”——跑出来的长文都带硬数字。信息流里数字是最容易让人停下来的东西。

AI 得是主角。 AI 教程类长文稳定 10 万以上，纯投资内容很难过 5 万。来这个账号的人想看"AI 怎么用”，不是看"怎么炒股"。

“帮你省时间"是底层传播逻辑。 公众号采集、Codex 入门、配图实战——所有爆款长文的共性是"我帮你试过了、踩坑了、整理好了，你照着来”。

爆款公式：硬核教程或真实经历 + 具体数据锚定 + 可复现路径。 没有一篇爆款的标题是抽象概念。全是"我做了 X，结果是 Y"的结构——分享经历加数据，不教课。

这些规则每发一篇新文章就更新一版。系统在自我修正。

如何开始：不用一步到位

dontbesilent 的 dbskill（GitHub 4000+ star）是个很好的起点。也可以像 @yidabuilds 一样，拿核心思路过来根据自己的需求改。

不用一步到位。先把选题池和素材库建起来，跑两周，让数据告诉你该往哪个方向调。

本文基于 X 用户 @yidabuilds 的推文内容整理。原文链接：https://x.com/yidabuilds/status/2052252982302200010

有了 AI Agent 助手，还需要 N8N 吗

Fri, 08 May 2026 06:10:14 +0800

问题的起点：AI Agent 能替代工作流自动化吗

2026 年初以来，以 Hermes Agent 和 OpenClaw 为代表的自托管 AI Agent 框架陆续发布，并迅速被广大用户认知和使用。它们通过自然语言理解用户意图，调用浏览器、代码执行、搜索等工具自主完成任务，并支持 Telegram、Discord、Slack 等 20 多个平台的统一接入。一个直观的疑问随之产生：当 AI 已经能"听懂人话并自动执行"，传统的可视化工作流工具 N8N 还有存在的必要吗？

这个问题的答案取决于对两种工具能力边界的准确理解。N8N 在同期经历了显著的 AI 化转型，但它没有试图变成另一个 Agent 框架，而是将 AI 作为编排流程中的一个组件。这种定位差异决定了两者并非替代关系。

N8N 最新功能特性：从自动化到 AI 编排

AI Agent Node 与动态模型选择

N8N 在 2026 年推出的 AI Agent Node 支持直接在工作流中嵌入 LLM 驱动的自主 Agent。与早期简单的"调用 API 节点"不同，这个节点具备完整的 Agent 架构：LLM 连接（支持 OpenAI、Anthropic、Google Gemini、Ollama 本地模型等）、记忆管理（窗口记忆、缓冲区记忆、向量存储记忆）、工具调用（HTTP Request、代码执行、自定义子工作流）以及系统提示词配置。动态模型选择功能允许根据任务类型切换 LLM，例如用 GPT-4 处理复杂推理、用 Claude Haiku 做快速过滤，从而降低 token 成本。

Agent-to-Agent 协作与 MCP 双向集成

2026 年 N8N 引入了 Agent-to-Agent Workflow 特性，允许一个 AI Agent 将其他 Agent 当作工具调用。这意味着工作流可以从"固定步骤序列"进化为"动态任务分配"：一个主 Agent 分析任务后，自动路由给专门的子 Agent 处理。同时，N8N 支持 MCP（Model Context Protocol）双向集成，既可以将 N8N 工作流作为工具暴露给外部 AI 平台（如 Claude Desktop），也可以从 N8N 内部调用外部 MCP 服务。

企业级治理与可靠性

N8N 的核心优势并未因 AI 功能的加入而削弱。它提供 400 多个预置集成节点、可视化调试（单步回放、数据预览）、多样化触发器（Cron 定时、Webhook、事件流、数据库变更）、以及企业级安全特性：SOC 2 合规、RBAC 权限控制、外部密钥管理（AWS Secrets Manager、HashiCorp Vault 等）。在性能方面，N8N 单机可达 220 次/秒的工作流执行，支持队列模式横向扩展。

Human-in-the-Loop 与错误处理

生产环境中的 AI 工作流需要人工审批节点。N8N 支持在任意步骤插入人工确认，并具备完善的错误处理机制：自定义告警、备份工作流、AI 辅助错误分析、以及专门的错误处理工作流。这些特性对于金融、医疗、供应链等对可靠性要求极高的场景至关重要。

Hermes Agent 与 OpenClaw：AI 助手的两种实现

Hermes Agent 和 OpenClaw 是功能高度重叠的竞品，定位均为"自托管 AI 助手网关"。它们通过单一进程将 AI 能力接入多种聊天平台，核心能力包括自然语言理解、持久记忆、工具调用（浏览器、代码执行、文件操作）、以及子代理委派。

Hermes Agent 的核心能力

Nous Research 发布的 Hermes Agent 于 2026 年 2 月 25 日正式开源，3 月 12 日发布首个公开版本 v0.2.0。它强调"越用越聪明"：通过 Honcho 记忆系统实现跨会话的持久记忆，自动从解决问题的过程中生成可复用的 SKILL.md 技能文档，并支持与 agentskills.io 社区标准同步。它提供 6 种执行环境（本地终端、Docker、SSH、Daytona、Singularity、Modal），支持 40 多个内置工具，并具备多模型网关（OpenRouter、Nous Portal、本地 vLLM 等）。

OpenClaw 的核心能力

OpenClaw 最初以 Clawdbot 之名于 2025 年 11 月 24 日发布，2026 年 1 月因商标问题先后更名为 Moltbot 和 OpenClaw。它同样强调自托管和隐私，支持 22 个以上消息平台（包括 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等），具备浏览器自动化、系统文件访问、语音交互和自定义技能扩展能力。它采用 TypeScript 插件架构，支持热重载开发，并允许用户通过单一配置切换底层模型（Claude、GPT、Gemini、Ollama 本地模型等）。

两者的共同边界

尽管 Hermes Agent 和 OpenClaw 在"智能对话"和"工具调用"方面表现出色，但它们都缺乏以下能力：

可视化工作流编排：复杂业务流程需要可视化调试和单步回放，纯对话式交互难以长期维护
广泛的 SaaS 集成：接入 Salesforce、HubSpot、Notion 等 400 多个服务需要写插件，而非点选配置
确定性流程控制：条件分支、循环、数据转换、错误重试等逻辑在 Agent 中难以精确编排
企业级治理：SOC 2 合规、审计日志、RBAC 权限管理、版本控制等生产环境必需特性
高并发批量处理：定时任务、事件驱动自动化、大规模数据同步等场景缺乏原生支持

能力边界对比：Agent 与 N8N 各自覆盖什么

能力维度	N8N	Hermes Agent / OpenClaw
可视化工作流编排	强（拖拽式节点编辑器）	无
SaaS 预置集成	400+ 节点	40-50 个工具/插件
确定性自动化	强（条件分支、定时触发、数据转换）	弱
AI 自主决策	中等（AI Agent Node）	强
多 Agent 协作	强（Agent-to-Agent）	强（子代理委派）
持久记忆	弱（需外部存储）	强（Honcho / 内置记忆）
跨平台消息网关	中等（需配置节点）	强（内置网关）
人工审批/治理	强（Human-in-the-Loop）	中等
企业安全合规	强（SOC 2、RBAC、审计）	中等
高并发批量处理	强（220 次/秒、队列模式）	弱

典型协同架构：让 Agent 和 N8N 各尽其职

在实际业务场景中，两者最合理的用法是分层协作：

在这个架构中，AI Agent 负责理解层（自然语言交互、意图识别、结果总结），N8N 负责执行层（确定性流程、跨系统集成、错误处理、审计追踪）。两者通过 Webhook 或 MCP 协议对接，形成完整的智能自动化 pipeline。

什么时候可以只用 Agent，什么时候必须上 N8N

纯 Agent 即可覆盖的场景

信息检索与研究：搜索网页、阅读文档、总结要点、生成报告大纲
单工具调用：查天气、发邮件、查询日历、简单计算
代码生成与文档编写：编写脚本、生成 API 文档、调试代码
个人使用、低可靠性要求：快速原型、实验性任务、非关键业务

必须引入 N8N 的场景

跨多个 SaaS 的系统集成：CRM、ERP、营销自动化、财务系统之间的数据流转
定时或事件驱动的自动化：每日报表生成、订单自动处理、库存同步、监控告警
需要人工审批的业务流程：报销审批、合同签署、发布审核
高并发、高可靠性要求：电商大促期间的订单处理、金融交易对账
团队协作与权限管理：不同角色访问不同工作流、操作日志审计
已有复杂业务逻辑需要可视化维护： legacy 系统的自动化改造、多部门协作流程

结论：互补而非替代

N8N 在 2026 年的演进表明，它清楚地认识到自身与专用 Agent 框架的边界。AI Agent Node 和 Agent-to-Agent 特性的加入，不是为了取代 Hermes Agent 或 OpenClaw，而是为了让 N8N 能够编排这些 Agent 的能力，将其嵌入到更大的确定性流程中。

对于已经部署 Hermes Agent 或 OpenClaw 的用户，N8N 的价值在于接管所有"繁琐但可靠的执行"：跨系统数据同步、定时任务、错误重试、人工审批、审计日志。让 Agent 专注于它真正擅长的"思考"和"沟通"，把"执行"交给 N8N 这个经过生产验证的编排引擎。两者结合，才能构建既智能又可靠的自动化体系。

参考来源

N8N Features — N8N 官方功能页面
N8N AI Workflow Automation — N8N AI 能力官方介绍
N8N AI Agent Frameworks Comparison — N8N 博客：9 个 AI Agent 框架对比
Building AI Agent Workflows in N8N: 2026 Guide — DEV Community
N8N AI Agent-to-Agent Feature — Pegotec, 2025
Latest N8N AI Automation Updates — Geeky Gadgets
N8N vs AI Agent Platforms — DEV Community
N8N vs AI Agents: Which Automation Approach Fits? — BrownMind
Hermes Agent Documentation — Nous Research
Hermes Agent Release Timeline — 社区维护的发布历史
Hermes Agent GitHub Releases — 官方发布记录
OpenClaw Wikipedia — OpenClaw 项目概述与历史
OpenClaw 2026 Guide — Petronella Tech, 2026
OpenClaw Documentation — OpenClaw 官方文档
OpenClaw Features — OpenClaw 功能页面

如何用两小时"蒸馏"一个人

Wed, 06 May 2026 06:28:56 +0800

Ruben Hassid 是一位在 X 上拥有大量读者的 AI 写作者，每周有超过 50 万人阅读他的通讯。他在一篇长推文中分享了一套方法论：用两小时、一个文本文件，让任何大语言模型写出和你一模一样的文字。这篇文章将解析该方法论的完整流程，并评估其实际价值与局限。

核心命题：为什么一个文本文件就能复制你的人格

Hassid 的论点直接且挑衅：你不过是一个文本文件。他认为，大多数人高估了自己的复杂性，低估了自己写作中可提取的模式。你的声音、品味、让你抓狂的烂帖、老朋友模仿你时会说的那句话、你打了又删的两个字、今年写了三次都没意识到的比喻，每一个都是可捕捉的模式。

这个观点的底层逻辑建立在当前大语言模型的上下文学习能力之上。当模型在对话开始时读取一份精心编写的个人档案文件，它会在后续生成中持续参考这些约束条件。这不是在训练模型，而是在给模型一个"角色剧本"，让它在每次输出时都扮演你。

Hassid 本人的验证颇具说服力。他拥有 20 年写作经验，曾在首尔、柏林、特拉维夫生活，9 岁从游戏论坛学会英语，大学辍学两次，现在给财富 500 强公司做 AI 咨询。他把这些经历浓缩进一个文件后，Claude 写出的初稿"就像我自己写的一样"，有时甚至"在我想到之前就写出来了"。

方法论的两阶段结构

Hassid 的方法论分为两个紧密衔接的阶段：深度采访和压缩编译。

第一阶段：100 道题的深度自我采访

这一阶段的核心工具是一个被 Hassid 称为"Taste Interviewer"的 Claude 提示词。它的任务是通过 100 个问题，系统性地提取你的写作 DNA。问题被分为七大类别：

类别	题数	核心挖掘目标
信念与逆向观点	15	你坚信但同行不认同的东西
写作机制	20	你实际怎么写，而非你以为怎么写
审美犯罪	15	什么让你在别人文字中感到不适
声音与个性	15	你严肃时和随意时的语气差异
结构偏好	15	你如何组织想法、使用列表和过渡
绝对禁区	10	你永远不会写的东西
红旗信号	10	什么让你立刻不信任一段内容

采访规则设计得很严格：一次只问一个问题；对模糊答案要追问；要求具体例子；指出矛盾之处；对有趣的话题深入挖掘。Hassid 建议使用 Wispr Flow 进行语音输入，因为"语音更快、更诚实"。

完成全部 100 题大约需要 90 到 120 分钟，最终产出是一份 2 万字左右的原始档案。完整的采访提示词见文末附录 A，可直接复制到 Claude 中使用。

第二阶段：压缩为高保真档案文件

原始档案的问题是体积过大。每次对话都让 Claude 读取 2 万字，既消耗上下文窗口，也增加 Token 成本。解决方法是让 Claude 充当"Voice Compiler"，将原始档案压缩为一个 2000 到 4000 Token 的 about-me.md 文件。

压缩的核心规则是：每一行都必须通过测试——“如果这一行消失，AI 的写作、编辑、判断、拒绝、结构或决策方式会不同吗？“如果答案是肯定的，保留；否则删除。

压缩后的文件采用 XML 结构，包含 15 个模块。每个模块都有明确的功能边界：

usage：三行说明，告诉 AI 如何使用这份文件
priority：六条优先级规则，处理冲突时的决策逻辑
identity_context：影响声音、品味、比喻和判断的身份细节
voice_fingerprint：节奏、密度、直接性、幽默、情感温度等可操作描述
writing_laws：具体的写作规则，包含正反示例
communication_laws：邮件、回复、请求、批评等场景的规则
hard_refusals：AI 绝不应该写、说或暗示的内容
taste_loves 与 taste_disgusts：你欣赏和厌恶的具体事物
phrase_bank：你常用的词、短语、比喻，以及你避免使用的表达
signature_tells：让你可被识别的小细节
decision_rules：你如何判断质量、诚实、美感、风险、可信度
productive_contradictions：需要保留而非抹平的张力
golden_examples：3 到 6 个正反对比示例
do_not_infer：AI 不应该从这份档案中推断出的假设
final_instruction：一条简洁指令，告诉 AI 静默应用这份档案

完整的压缩编译提示词见文末附录 B。

实际效果：从实验到工作流

Hassid 展示了多个对比案例。在加入 about-me 文件前后，同一 AI 模型对相同提示的输出质量差异显著。没有档案时，模型输出的是通用、安全、缺乏个性的文字；加入档案后，输出带有明确的个人风格、特定的用词习惯和结构偏好。

更实用的价值在于团队场景。Hassid 指出，你可以把这份文件发给团队成员，让他们在你不在时也能按你的方式起草内容。客服回复、邮件沟通、内容创作，都可以由团队代劳而保持一致的声线。

不过 Hassid 也坦诚地指出了一个问题：一致性带来可预测性。当你的风格被固定在一个文件里，你的输出模式也变得可被预测。他的解决方案是定期编辑这份文件，因为人的品味和声音会随着时间变化。

方法论的价值与局限

为什么这个方法有效

该方法论的巧妙之处在于它把"让 AI 写得像我"这个模糊目标，拆解为两个可执行的具体步骤：先通过结构化采访强制你显式化自己的写作规则，再通过压缩过滤掉噪音、保留信号。

大多数人无法直接写出一个好的 about-me 文件，因为他们从未系统性地思考过自己的写作偏好。100 道题的采访过程本质上是一种强制内省，它逼你把直觉层面的品味转化为可表述的规则。这种转化正是 AI 能够理解和执行的前提。

局限与值得警惕的地方

首先，该方法假设你的写作风格是稳定的、可模式化的。对于风格多变、实验性强的写作者，这份档案可能反而成为一种束缚。

其次，2 小时的投入产出比取决于你的使用频率。如果你只是偶尔让 AI 帮你写几封邮件，花两小时建立档案可能得不偿失。但对于需要持续产出内容的人—— newsletter 作者、社交媒体运营者、团队管理者——这个一次性投入可以带来长期的效率提升。

第三，Hassid 的方法高度依赖 Claude 的 Opus 模型和 Extended thinking 模式。在其他模型或更便宜的模型上，采访深度和压缩质量可能会有明显下降。

最后，也是 Hassid 自己强调的：这个过程会让人感到不适。当你把自己读进一个文本文件时，“无处可藏”。每一个信念都是一种承诺，每一个拒绝都是你如今必须遵守的规则。他第一次读自己的压缩文件时"退缩了”。

如何开始：最小可行实践

如果你不想一次性走完完整的 100 题流程，可以从一个最小版本开始：

打开任意 AI 对话，粘贴 Hassid 的 Taste Interviewer 提示词（见附录 A）
只回答前 20 题，聚焦在"写作机制"和"审美犯罪"两个类别
让 AI 将回答编译为一份 500 到 1000 Token 的精简档案
在下一次需要 AI 帮你起草内容时，把这份档案放在对话开头
根据输出效果，逐步补充和修正档案内容

这个最小版本大约需要 30 分钟，足以让你体验到方法论的核心价值：AI 输出从"通用"到"像你"的质变。

参考来源

附录 A：Taste Interviewer 完整提示词

将以下内容粘贴到 Claude 对话中即可开始采访：

附录 B：Voice Compiler 完整提示词

完成 100 题采访后，在同一段对话中粘贴以下内容，让 Claude 将原始档案压缩为高保真 about-me 文件：

Warp 终端开源的动机与影响

Wed, 29 Apr 2026 03:32:22 +0800

2026 年 4 月 28 日，Warp 官方博客宣布其终端客户端以 AGPL 协议开源，代码托管于 GitHub。这一决定并非单纯的代码公开，而是伴随着一套名为 Agent-first Workflow 的协作机制，社区贡献者通过 Warp 自研的 Oz 平台与 AI Agent 协同推进开发。OpenAI 作为创始赞助方参与了这一实验。

本文基于 Warp 官方公告与定价信息，分析其开源动机、对用户的影响、免费与付费版本的差异，以及产品的未来走向。

Warp 是什么

Warp 是一款面向开发者的现代终端应用，核心功能包括块级命令编辑、自动补全、历史搜索、以及基于 AI 的 Agent 辅助编程。除了终端客户端，Warp 还推出了 Agents（多 Agent 部署与追踪）、Code（生产代码库中的复杂功能构建）、Drive（知识库与上下文管理）和 Oz（云 Agent 编排平台）等产品线。

在开源之前，Warp 的终端客户端是闭源的，AI 功能按用量收费。开源后，终端客户端代码以 AGPL 协议公开，但 AI 能力和云服务仍维持付费模式。

Warp 为什么选择现在开源

Warp 在官方博客中给出了两个层面的原因。

首要原因是开发效率的瓶颈转移。 传统软件开发中，编码本身往往是最耗时的环节。但在 AI Agent 能力快速提升的背景下，Warp 团队发现限制因素已从"写代码"转向了"人类参与的规格制定与验证"。Agent 可以承担实现层面的重活，而人类贡献者则专注于更高杠杆的工作：决定做什么、确保做对。开源社区参与管理 Agent，理论上可以突破内部团队的人力上限。

次要原因是生态位的战略卡位。 Warp 指出，当前市场上尚不存在一个功能完整的开源 Agentic Development Environment（ADE）。通过开源客户端，Warp 试图成为这个新兴领域的标杆替代方案，与资金雄厚的闭源竞品形成差异化竞争。

值得注意的是，Warp 自 2022 年发布之初就有开源计划，但直到 2026 年才执行。团队解释称，“Agent 的崛起"改变了开源协作的可行性。没有 Agent 辅助，大规模社区贡献的 review 和集成成本难以承受。

Agent-first Workflow 是什么

Agent-first Workflow 是 Warp 开源后采用的核心协作模式。其运作逻辑如下：社区贡献者提出功能方向或提交需求，Warp 的 Oz 平台调度 AI Agent 完成编码、规划、测试等实现工作，核心团队负责最终的质量把关和合并决策。

这与传统开源项目的区别在于，传统模式下社区提交的 PR 需要核心团队人工 review 和测试，人力是瓶颈；而在 Agent-first 模式下，Agent 承担了大部分实现和验证工作，人类贡献者的角色从"写代码"转向"定方向"和"做验证”。

Warp 将公开 GitHub issue 作为功能追踪的唯一来源，并发布了 ADE 的公开路线图。这意味着社区可以通过提交 issue 和参与讨论直接影响产品方向。

开源为用户带来什么

透明度与可审计性

终端是开发者与系统交互的核心入口，处理的命令和数据往往涉及敏感信息。开源意味着用户可以直接审计 Warp 在本地执行了哪些操作、数据如何流转。这在安全合规场景下具有实质价值，尤其对于需要审查第三方工具的企业环境。

可定制性提升

Warp 同步推出了可编程的 settings 文件，支持跨设备的配置便携。用户可以根据个人偏好调整界面层级，从极简终端到包含 diff 视图和文件树的完整 ADE 界面。

模型选择自由度扩大

开源版本新增了对 Kimi、MiniMax、Qwen 等开源模型的支持，并引入了 “auto (open)” 自动路由功能，系统会根据任务类型自动选择最优模型，降低用户手动切换的成本。

免费版本与付费版本的区别

Warp 的商业模式是"开源客户端 + 付费云服务"的混合模式。终端核心功能对所有用户免费，AI 能力和云资源按用量分层收费。

维度	免费版	Build 版（$18/月）
终端核心功能	完全免费	完全免费
源代码	AGPL 开源，可查看/修改	同一套开源代码
月度 AI Credits	150（前 2 个月），之后 60	1,500
可用 AI 模型	有限	OpenAI、Anthropic、Google 前沿模型
并发云 Agent	4 个	20 个
云 Agent 算力	2 vCPU / 4 GiB	4 vCPU / 8 GiB
代码库索引	3 个，每库 3,000 文件	40 个，每库 100,000 文件
Warp Drive 知识库	10 workflows + 3 notebooks	无限
BYOK（自带 API Key）	不支持	支持

对于纯终端用户，开源不会改变使用体验。Warp 的块编辑、自动补全、历史搜索等功能始终免费。AI 功能的门槛在于 credits 和模型访问权限。

Warp 在 2025 年底已将定价从多层级（Pro/Turbo/Lightspeed）简化为单一的 Build 计划，并引入了 Reload Credits 机制：超额用量以比旧版便宜 50% 的价格购买，且 12 个月内有效。

一个对重度用户有利的选项是 BYOK（Bring Your Own Key）：Build 及以上用户可接入自己的 OpenAI、Anthropic 或 Google API Key，AI 成本直接计入原有供应商账单，Warp 仅收取 $18/月的基础订阅费。对于已有 AI 订阅的开发者，这可以显著降低综合成本。

不同用户该如何选择

用户类型	建议方案	预期成本
纯终端用户	免费版	$0
轻度 AI 使用者	免费版 credits	$0
已有 AI API Key 的开发者	Build + BYOK	$18/月
需要团队协作	Business（$45/人/月）	按人数计费
数据主权要求严格的企业	Enterprise（定制）	按需定价

免费版每月 60 credits 的额度对于任何实质性的 AI 辅助开发都较为紧张。这意味着大多数希望使用 Warp AI 功能的用户最终需要走向付费或 BYOK 路径。

Warp 与闭源竞品的差异

Warp 的开源策略将其与 Cursor、GitHub Copilot 等闭源竞品区分开来。

维度	Warp	Cursor / Copilot
客户端代码	AGPL 开源	闭源
核心盈利点	云 Agent 服务 + AI credits	订阅费
模型选择	支持多家，含开源模型	主要支持自有/合作模型
社区参与度	Agent-first，社区定方向	官方主导
自托管选项	Enterprise 支持	一般不支持

AGPL 许可证的强 copyleft 属性意味着任何基于 Warp 代码的衍生作品也必须开源。这可能让部分企业犹豫是否深度定制，但也确保了社区贡献能够回流到主项目。

产品的未来走向

短期：迭代速度的竞争

如果 Agent-first 协作模式跑通，Warp 的功能迭代速度可能显著快于依赖内部工程师的闭源竞品。社区贡献者提出方向，Agent 完成实现，核心团队做质量把关。这种流水线理论上可以并行处理大量功能需求。

中期：开源 ADE 生态位的争夺

Warp 明确将自身定位为"开源 Agentic Development Environment"的先行者。这一生态位目前空白，但竞争将迅速加剧。能否建立足够的社区规模和贡献质量，将决定 Warp 是否能守住这个位置。

长期：云服务作为盈利核心

客户端开源不会动摇 Warp 的商业模式。AI 算力、云 Agent 编排、企业级管理（SSO、数据 retention 控制、自托管 Agent）才是收费的核心。这与 GitLab 的"开源核心 + 付费功能"路径类似。Warp 的 Enterprise 计划甚至支持 Bring Your Own LLM 和自托管云 Agent，瞄准对数据主权有严格要求的大型组织。

潜在风险与不确定性

Agent-first 协作模式是实验性的，其有效性有待验证。社区贡献的质量是否能通过 Agent 有效放大、核心团队的 review 瓶颈是否会以新的形式出现，都是未知数。

此外，免费版 credits 额度较低，可能将大量用户推向付费路径。Warp 需要平衡免费用户的增长与付费转化，避免免费版成为"试用陷阱"而损害用户体验。

总结

Warp 的开源不是传统意义上的"回馈社区"，而是一次基于 Agent 能力的商业模式实验。它以 AGPL 开源客户端建立信任与透明度，以 Oz 平台和云 Agent 服务构建商业壁垒。

对于用户而言，纯终端功能不受影响，AI 能力的获取成本取决于使用强度。对于行业而言，这标志着开源协作可能进入"人类定方向、Agent 做执行"的新阶段。这一模式能否持续，取决于 Agent 的质量、社区的活跃度，以及 Warp 在免费与付费之间的平衡能力。

参考来源

Warp Is Now Open-Source，Warp 官方博客，2026-04-28
Warp Pricing，Warp 官方定价页面

Claude Cowork 与 Code 模式的关键区别

Wed, 29 Apr 2026 02:54:21 +0800

Anthropic 在 2026 年初为 Claude 桌面客户端引入了三种并列的工作模式：Chat、Cowork 与 Code。其中 Chat 延续了传统的对话式交互，而 Cowork 和 Code 则代表了两种不同方向的 Agentic（智能体）能力扩展。二者共享同一套 Claude 模型引擎，却在交互界面、工具链和优化目标上存在本质差异。

本文聚焦 Cowork 与 Code 的对比，从核心定位、能力边界到实际应用场景进行系统梳理。

一、核心定位：同一引擎，两套装备

Cowork 与 Code 并非两个独立产品，而是同一智能引擎面向不同用户群体的两种封装形态。

维度	Cowork	Code
设计目标	面向非开发者的通用办公自动化	面向开发者的代码工程化工具
界面形态	Claude Desktop App 内的 GUI 标签页	Terminal CLI / IDE 插件 / Desktop Code 标签页
底层能力	基于 Computer Use（截图+鼠标键盘控制）	基于 MCP + Shell + Git 的完整开发工具链
文件访问	需显式授权文件夹，沙盒化访问	项目级完整文件系统访问
代码执行	展示计划后执行，偏可视化	直接运行 shell 命令、测试、构建
Git 集成	无	完整生命周期（分支、提交、PR）

二者的关系可以概括为：同一引擎，不同装备。模型层面的推理能力完全一致（均使用 Opus 或 Sonnet），差异体现在模型被允许调用的工具集合以及人与模型的交互方式上。

二、Cowork：非技术人员的"桌面自动化同事"

Cowork 于 2026 年 1 月推出，Anthropic 将其定位为 “Claude Code for the rest of your work”——即把开发者已享有的 Agentic 能力扩展到非技术场景。

核心能力

本地文件读写：用户授权特定文件夹后，Cowork 可直接读取、创建和修改文件，无需手动上传下载
跨应用桌面自动化：基于 Computer Use 能力，通过截图识别界面元素并控制鼠标键盘，可操作 Excel、PowerPoint、浏览器等任意桌面程序
浏览器自动化：可读取 Gmail、后台网页数据，利用用户已登录的会话完成网页级任务
子代理协调：将复杂任务拆解为并行工作流，自动合并多个子任务的结果
定时任务：支持 /schedule 指令设置每日或每周重复执行的自动化流程
专业文档生成：直接输出 PPTX、XLSX（含公式）、DOCX 等办公格式

典型应用场景

文件整理：“将桌面上的 200 张截图按日期分类，生成索引表格”
数据提取：“读取 50 份 PDF 发票，提取供应商名称、日期和金额到 Excel”
定时报告：“每周一上午 9 点，自动汇总 Salesforce 销售数据并生成周报”
演示文稿：“根据调研资料生成一份带格式的 PowerPoint 演示文稿”

Cowork 的设计哲学是降低使用门槛：用户用自然语言描述目标，系统在展示执行计划后自主完成，过程中可通过 GUI 实时观察进度。

三、Code：开发者的"终端级工程助手"

Code 模式（及更早发布的 Claude Code CLI 工具）面向软件开发场景，提供对代码库和开发工具链的深度访问。

核心能力

代码库级理解：自动映射项目结构、依赖关系和跨文件引用，建立完整的代码上下文
多文件重构：单次会话内跨文件修改代码、更新 import 语句、调整测试用例、修复构建错误
终端命令执行：直接运行 shell 脚本、测试套件、构建流水线和部署命令
Git 全生命周期：从读取 issue、编写代码、运行测试到提交 PR 的完整闭环
MCP 工具连接：通过 Model Context Protocol 对接 GitHub、Slack、Jira、数据库等外部系统
**后台代理与 ****/loop**：支持长时间运行任务，如每 5 分钟审查一次 PR、持续监控部署状态（最长可持续一周）
Plan 模式：只读探索代码库，不修改任何文件，适用于理解和分析阶段

典型应用场景

功能开发：“给 Express 应用添加 JWT 认证，创建中间件和路由，并编写测试”
代码重构：“重构服务模块，涉及 8 个文件，跑完测试后提交 PR”
Bug 排查：“排查前端渲染问题，打开浏览器调试并截图分析 UI”
持续监控：“设置后台代理，持续监控仓库新 PR 并自动执行代码审查”

Code 的设计哲学是精确控制：开发者通过终端或 IDE 与模型交互，可以审查每一步的中间输出，并在必要时进行细粒度修正。

四、底层技术差异

Computer Use vs. MCP + Shell

Cowork 的核心技术栈是 Computer Use——Claude 通过截取屏幕图像、识别界面元素，进而模拟鼠标点击和键盘输入来完成任务。这种方式的优势是通用性：理论上可以操作任何有图形界面的应用程序。代价是效率较低，每一步都需要截图、分析和模拟输入，且对界面变化的容错能力有限。

Code 的核心技术栈是 MCP（Model Context Protocol）+ Shell 命令。MCP 为模型提供了结构化的工具调用接口（如读取文件、执行命令、查询数据库），Shell 则赋予其直接调用系统级工具的能力。这种方式的优势是精确性和效率：模型可以直接操作文件系统、运行编译器、调用测试框架，无需经过 GUI 层的间接模拟。

记忆机制

Cowork：基于 Projects 的持久化记忆，跨会话保留任务历史和连接器配置
Code：基于 CLAUDE.md 文件的项目级指令 + 自动记忆，记忆粒度更细，与代码库结构深度绑定

五、选择建议

以下决策树可帮助快速判断应使用哪种模式：

任务特征	推荐模式
涉及代码库、版本控制、测试构建	Code
需要操作多个办公软件、整理文件、生成文档	Cowork
需要定时执行的重复性办公任务	Cowork
需要深度代码理解和跨文件重构	Code
快速问答、头脑风暴、移动端交互	Chat

常见误区

Cowork 不是 Code 的 GUI 版本：二者接口和优化方向完全不同，Cowork 不具备 Git 支持、终端访问和 IDE 集成
用 Cowork 写代码效率偏低：缺少代码库级上下文和构建工具链，跨文件重构能力有限
给非开发者配置 Code 并不合适：终端界面和开发工作流对运营、销售、HR 等角色存在不必要的学习成本

六、总结

Cowork 与 Code 代表了 Anthropic 对 Agentic AI 的两种产品化路径：Cowork 以通用性和易用性为核心，面向知识工作者的日常办公自动化；Code 以精确性和控制力为核心，面向软件开发者的工程化需求。二者并非竞争关系，而是互补关系——同一用户在不同场景下可能同时需要两者。

从更宏观的视角看，Chat、Cowork、Code 的三层结构也反映了 AI 产品的一个演进趋势：从被动响应（Chat）到主动执行（Cowork/Code），从单一对话到工具集成再到系统级自动化。对于用户而言，理解每种模式的边界和优势，是高效使用 Claude 生态的前提。

参考来源

本文信息综合整理自以下公开资料：

网页 PPT：比传统幻灯片更灵活的几个开源方案

Tue, 28 Apr 2026 02:03:53 +0800

用网页做演示这件事，最早是技术从业者圈子里的小众选择。但近两年的趋势是，越来越多的非技术用户也开始尝试——学术汇报、产品发布、企业内训等场景中，基于网页的幻灯片正在从边缘走向主流。其背后的驱动力并不复杂：网页技术天然具备跨平台一致性、版本控制友好性，以及传统 PPT 难以实现的交互能力。

本文梳理了当前几个值得关注的网页 PPT 工具，分为核心框架和 AI 生成两个层面，并附上可直接访问的项目地址。

一、核心框架层

网页 PPT 的基础设施由一系列开源框架构成。它们将幻灯片从专有格式解放出来，转为基于开放 Web 技术构建。

reveal.js：HTML 演示的"事实标准"

reveal.js 是目前最成熟的 HTML 演示框架，由 Hakim El Hattab 开发。其核心定位是：任何能在网页上实现的效果，都能在演示中使用。

该框架支持垂直嵌套幻灯片、演讲者视图（含计时和下一张预览）、Auto-Animate 自动动画、LaTeX 公式渲染等功能。幻灯片过渡效果包括 fade、slide、convex、concave、zoom 等多种模式。对于不熟悉代码的用户，同一作者还提供了配套的无代码编辑器 slides.com。

reveal.js 的适用场景是对交互效果有较高要求的技术演示，比如需要嵌入实时代码运行、iframe 网页内容或复杂 CSS 动画的场合。

项目地址：github.com/hakimel/reveal.js

Slidev：开发者首选的 Markdown 方案

Slidev 专为开发者设计，技术栈基于 Vite + Vue 3 + UnoCSS，使用 Markdown 作为内容源格式。其最大优势是将"写代码"和"做演示"的工作流统一到了同一个环境中。

Slidev 的特色功能包括：Shiki 驱动的代码高亮、内置实时代码演示、Mermaid 图表支持、KaTeX 数学公式、演讲者画笔批注，以及内置的录制工具。部署方面，运行 slidev build 即可输出静态网页，可托管到任意平台。

对于习惯使用 Git 管理文档的开发者而言，Slidev 的 Markdown 源文件天然支持版本控制，这是传统 PPT 难以比拟的优势。

项目地址：github.com/slidevjs/slidev

Marp：最轻量的 Markdown 方案

Marp 是 Markdown Presentation Ecosystem 的简称，提供了 VS Code 插件形式的即开即用体验。安装插件后，新建一个 Markdown 文件、添加 marp: true 前置配置，即可开始制作幻灯片。

Marp 的学习成本在三者中最低，支持导出 PDF、PPTX 和 HTML 三种格式。它适合快速制作学术汇报、工作简报等对设计复杂度要求不高的场景。

项目地址：github.com/marp-team/marp

Spectacle：React 生态的演示方案

Spectacle 是由 Nearform（原 FormidableLabs）维护的 React 组件化演示框架，使用 JSX 语法编写幻灯片。它与 React 生态无缝集成，支持实时代码演示（live coding）。对于已经深度使用 React 技术栈的团队，Spectacle 提供了组件复用的可能性，比如将 UI 组件库中的元素直接嵌入演示文稿。

项目地址：github.com/FormidableLabs/spectacle

二、AI 生成层

框架解决了"如何呈现"的问题，AI 工具则开始解决"如何生成内容"的问题。以下是目前值得关注的开源方案。

Presenton：功能最完整的 AI 演示生成器

Presenton 在 GitHub 上已获得 4.8k Stars，采用 Apache 2.0 协议开源。其定位是 Gamma、Beautiful.ai 和 Decktopus 的开源替代方案。

该项目的核心特性包括：

BYOK 模型支持：可使用 OpenAI、Gemini、Anthropic 的 API，也可通过 Ollama 接入本地模型
模板继承：支持上传现有 PPTX 文件作为设计模板
完全本地运行：提供 Electron 桌面端和 Docker 自托管两种部署方式，所有处理可在本地完成
MCP Server 内置：支持 Model Context Protocol，可与其他 AI 工具链集成

部署方式非常简洁，一行 Docker 命令即可启动服务。对于数据隐私敏感的场景，比如企业内部汇报或涉及商业机密的演示，Presenton 的本地运行能力是一个重要加分项。

项目地址：github.com/presenton/presenton

PPTAgent：学术研究级别的生成方案

PPTAgent 是发表于 EMNLP 2025 的研究项目，由中科院计算所（ICIP-CAS）开发。其特色在于引入了系统化的质量评估机制。该项目采用两步生成流程，并内置了 PPTEval 评分体系，从设计、流程和内容质量三个维度对生成结果进行量化评估。

PPTAgent 同样支持 Docker 秒级部署。它的适用场景是对生成质量有可量化评估需求的研究或企业环境，比如需要向客户证明 AI 生成内容达到特定质量标准的场合。

项目地址：github.com/icip-cas/PPTAgent

三、工具链层：格式转换

网页 PPT 与传统工作流之间的桥梁由专门的转换工具提供。

DeckTape：HTML 演示的高质量 PDF 导出

DeckTape 基于 Puppeteer 和 Chrome 渲染引擎，可将 reveal.js、Slidev、impress.js、remark 等 13 种以上 HTML 演示框架导出为高质量 PDF。其用法简洁：

该工具还支持选择性导出（如仅导出第 1、3、5 至 10 页）、多分辨率截图捕获，以及 Docker 容器化运行。对于需要离线分发或打印备份的场景，DeckTape 是网页 PPT 工作流中不可或缺的一环。

项目地址：github.com/astefanutti/decktape

四、选型建议

需求场景	推荐方案
已有 Markdown 内容，快速生成网页 PPT	Slidev 或 Marp
需要 AI 辅助从零生成完整演示	Presenton（自托管）
追求复杂交互效果、嵌入网页应用	reveal.js
React 技术栈、需要组件化复用	Spectacle
需要 PDF 备份或离线分发	任意框架 + DeckTape
数据敏感、必须本地运行	Presenton + Ollama 本地模型

五、一条值得关注的工作流

目前这些工具正在形成一条清晰的工作链条：

Markdown/文本 → AI 生成内容 → 网页 PPT 框架渲染 → DeckTape 导出 PDF

这意味着用户可以用 AI 生成内容大纲，用 Slidev 或 Marp 以 Markdown 形式精修，构建为可交互的网页 PPT，再用 DeckTape 导出 PDF 作为 fallback。这种"网页优先、PDF 兜底"的模式，正是"网页 PPT 更好"这一判断背后的技术基础。

网页 PPT 在交互性、版本控制和跨平台一致性上的优势是客观的。但它并非万能：传统 PPT 在商务场景中的兼容性、审阅批注功能，以及非技术用户的接受度，仍然是网页方案需要面对的现实约束。选择哪种工具，最终取决于具体的使用场景和受众特征。

国内主流 AI Coding Plan 选购指南：9 家平台速度与价格实测对比

Thu, 16 Apr 2026 09:46:38 +0800

自 2025 年下半年起，国内大模型厂商纷纷推出面向开发者的 Coding Plan 订阅套餐，用固定月费取代传统按 Token 计费的模式，大幅降低 AI 辅助编程的使用门槛。然而，各家平台在定价、额度、响应速度和模型支持上差异巨大，甚至存在计量单位不同、限额严格等隐藏条款，让不少开发者感到选择困难。

本文综合一篇小红书实测笔记、博客园的深度横评以及各平台官方文档，从价格与速度两个核心维度，对国内 9 家 Coding Plan 进行梳理，希望能为你的选购决策提供参考。

一、Coding Plan 的计费模式与避坑要点

在对比具体套餐之前，有必要先厘清三家厂商采用的不同计量单位，这是最容易踩坑的地方：

API 请求次数：阿里云百炼、火山方舟、无问芯穹采用此方式。一次用户提问（Prompt）后台可能触发 5~30 次模型调用，每次调用均计为 1 次 API 请求（据腾讯云官方文档）。
Prompt 次数：智谱 GLM、MiniMax 采用此方式。1 次 Prompt 约等价于 1200~1600 次 API 请求。
Token 计量：Kimi 于 2026 年 1 月 28 日切换为此模式，按输入输出 Token 计费，且缓存命中率会直接影响实际可用额度。

由于计量单位不同，单纯比较数字没有意义。例如百炼 Lite 的「每 5 小时 1200 次 API 请求」与智谱 Lite 的「每 5 小时 80 次 Prompt」在实际使用强度上可能相差无几。

二、价格与额度对比

2.1 四大厂平台

根据小红书笔记中的截图以及博客园的整理，阿里云百炼、火山引擎、腾讯云、京东 JoyCoder 的定价策略高度趋同：

平台	Lite 套餐	Pro 套餐	核心额度（Lite）	支持模型
阿里云百炼	¥40（首月 ¥7.9）	¥200	1200 次/5h，9000 次/周，18000 次/月	Qwen3.5-Plus、Qwen3-Coder-Next、GLM-4.7、Kimi-K2.5
火山方舟	¥40（首月 ¥8.91）	¥200	与百炼一致	Doubao-Seed-Code、DeepSeek-V3.2、GLM-4.7、Kimi-K2.5
腾讯云	¥40（首月 ¥7.9）	¥200	与百炼一致	Hunyuan 系列、MiniMax-M2.5、Kimi-K2.5、GLM-5
京东 JoyCoder	¥40	¥200	与百炼一致	DeepSeek-V3.2、Kimi-K2.5、MiniMax-M2.7、GLM-5

2.2 新兴 AI 厂商

相比四大厂，新兴厂商的定价更加分散：

平台	入门价格	核心额度	计费方式	特点
无问芯穹	¥19.9/月	1000 次/5h，6000 次/周	API 请求	月费最低，多模型聚合
MiniMax	¥29（首月 ¥9.9）	40 Prompt/5h，无周限额	Prompt	入门价最低，无每周限额
Kimi	¥49（Andante）	按 Token（限时 3 倍）	Token	原生多模态，256K 长上下文
智谱 GLM	¥49（2 月涨价后）	80 Prompt/5h，400/周	Prompt	纯自研模型，20+ 工具适配
阶跃星辰	未测试	—	—	暂无实测数据

从性价比角度看：

预算敏感用户：无问芯穹（¥19.9）和 MiniMax（¥29）的入门门槛更低。
新用户试水：阿里云百炼首月 ¥7.9 是目前已知最低的尝鲜价。

三、速度实测：TTFT 与 TPS

以下速度数据来自一篇小红书实测笔记，测试条件为「白天 @ 10K tokens」，分别测量了首 Token 响应时间（TTFT）与TPS 生成速度。这些数据能直接反映编程时的「跟手」体验与代码生成效率。

3.1 首 Token 响应时间（TTFT）

平台	最快模型	TTFT	最慢模型	TTFT
智谱 GLM	glm-5-turbo	1.43s	glm-5	7.82s
腾讯	hunyuan-2.0-thinking	2.51s	kimi-k2.5	12.38s
MiniMax	m2.1	2.44s	m2.5	5.54s
阿里	glm-4.7	2.76s	qwen3-coder-next	11.58s
无问芯穹	deepseek-v3.2-thinking	3.26s	kimi-k2.5	7.76s
火山	doubao-seed-2.0-pro	3.29s	glm-4.7	21.52s
京东	deepseek-v3.2	~5s	kimi-k2.5	~19s
Kimi	kimi-for-coding	5.71s	—	—

观察：智谱 GLM 的 glm-5-turbo 以 1.43s 的 TTFT 全场最快；火山和京东平台上部分模型的首字响应时间则明显偏高，分别达到 21.52s 和 19s，可能与平台调度策略或模型部署方式有关。

3.2 TPS 生成速度

平台	最快模型	TPS	最慢模型	TPS
智谱 GLM	glm-4.5-air	103	glm-5	23
火山	doubao-seed-2.0-pro	76	kimi-k2.5	23
腾讯	hunyuan-2.0-thinking	76	glm-5	30
阿里	qwen3-coder-next	67	glm-4.7	41
无问芯穹	minimax-m2.5	51	kimi-k2.5	25
MiniMax	m2.5	48	m2.1	45
京东	deepseek-v3.2	35	glm-5	25
Kimi	kimi-for-coding	35	—	—

观察：智谱 glm-4.5-air 的 TPS 达到 103，显著领先其他平台；火山和腾讯的混元/豆包模型也能达到 76 TPS。京东和 Kimi 的 TPS 相对较低，均为 35 左右。

此外，MiniMax 官方宣称其 M2.5 模型速度可达 100+ TPS，这与小红书笔记中 MiniMax 平台测得的 48 TPS 存在差异，说明同一模型在不同平台上的部署性能可能并不相同。

四、各平台简评与选购建议

综合价格、额度与速度数据，以下是针对不同使用场景的选购建议：

新用户/想低成本试水

首选 阿里云百炼 Lite（首月 ¥7.9）。模型丰富，依托阿里云基础设施，稳定性较强。缺点是仅支持主账号、配置文档对新手不够友好。

预算敏感、轻度使用（月预算 ≤ 30 元）

首选 无问芯穹 Lite（¥19.9/月），额度接近百炼，价格仅一半，适合每周编程 2~3 次的轻度开发者。
次选 MiniMax Starter（¥29/月），无每周限额，额度仅按每 5 小时刷新，适合连续使用。

日常开发、中度使用（月预算 40~50 元）

首选 阿里云百炼 Lite（常规价 ¥40）或 火山方舟 Lite（常规价 ¥40）。两者额度透明、模型选择多。
不推荐智谱 GLM（涨价后 ¥49，性价比下滑）和 Kimi（¥49，工具适配少且额度受缓存影响大）。

重度开发、全栈或多模型切换

首选 阿里云百炼 Pro 或 火山方舟 Pro（¥200/月），额度为 Lite 的 5 倍左右，支持多模型自由切换。火山还支持 Auto 智能调度模式。
若对 GLM 自研模型有偏好，可考虑智谱 GLM，但需注意其每周限额和高峰期的额度抵扣倍数（高峰期 3 倍、非高峰 2 倍）。

追求极致响应速度

若首字响应和生成速度是首要诉求，智谱 GLM 的 glm-5-turbo（1.43s TTFT）和 glm-4.5-air（103 TPS）表现最佳。

五、总结

国内 Coding Plan 市场正处于快速迭代期，价格战与模型战并行。选购时切忌只看表面价格，而应关注三个核心问题：

计量单位是什么？ API 请求、Prompt 次数还是 Token？不同单位之间无法直接比大小。
限额机制如何？ 是按 5 小时刷新、每周限额，还是每月封顶？这决定了你能否连续高强度使用。
速度是否跟手？ TTFT 和 TPS 直接影响编程体验，同一模型在不同平台上的部署表现可能差异巨大。

最后提醒：各家套餐政策更新频繁（如智谱涨价、Kimi 切换 Token 计费、阿里云 Lite 档停售），建议在订阅前前往各平台官网确认最新详情。

数据来源

Cloudflare Mesh 与 Tailscale 对比：功能、架构、定价与选型

Wed, 15 Apr 2026 05:54:49 +0800

在零信任网络（ZTNA）逐渐取代传统 VPN 的背景下，Cloudflare Mesh 与 Tailscale 是两类代表性方案。前者依托 Cloudflare 全球边缘网络提供 Relay 式私有互联，后者则基于 WireGuard 实现点对点 Mesh VPN。本文从功能、架构、安装配置、定价、适用场景与潜在风险等维度进行系统对比。

1. 产品定位

Cloudflare Mesh 是 Cloudflare One（Zero Trust/SASE）套件中的私有网络组件，前身为 WARP Connector，于 2026 年 4 月更名为 Cloudflare Mesh 并进入 Beta 阶段。它通过 Cloudflare One Client（即 WARP 客户端）将服务器、笔记本电脑和手机接入同一私有网络，所有流量经由 Cloudflare 边缘节点转发。详见 Cloudflare Mesh 官方文档。

Tailscale 是一家独立公司推出的商业 WireGuard 组网服务，已成熟运营多年。它在标准 WireGuard 协议之上增加了 NAT 穿透、密钥分发和控制平面管理，使设备能够自动建立加密连接。详见 Tailscale 官方博客。

2. 核心功能对比

功能	Cloudflare Mesh	Tailscale
私有 IP 互访	支持。分配 Mesh IP（100.96.0.0/12），支持 TCP/UDP/ICMP	支持。分配 Tailscale IP（100.64.0.0/10），实现第 3 层互通
子网路由	Linux Mesh node 可宣告 CIDR 路由	Subnet Router 功能，任意节点均可宣告路由
Exit Node	间接支持（绑定公网 CIDR 或使用 Gateway Egress Policy）	原生支持，可指定任意节点作为互联网出口
DNS	Local Domain Fallback + Gateway Resolver Policies	MagicDNS，开箱即用的内网域名解析
客户端平台	Mesh node：仅 Linux（headless warp-cli）<br>Client：Win/Mac/Linux/iOS/Android	几乎所有主流平台，包括 Windows、macOS、Linux、iOS、Android、FreeBSD 及嵌入式系统
高可用	Mesh node 支持 active-passive 副本	支持 Subnet Router HA、MagicSRV 等
Serverless 集成	可与 Cloudflare Workers VPC 绑定，直接访问私有服务	无原生集成，需借助第三方方案
访问控制	Gateway Network Policies + Device Posture + Identity Checks	ACL（HuJSON）、Device Posture、SSO、Tag-based Policy

3. 架构差异

Cloudflare Mesh：Relay（星型转发）

所有 enrolled 设备之间的通信都必须经过 Cloudflare 的最近边缘节点（PoP），再由 Cloudflare 网络转发到目标端。即使两台设备位于同一局域网，流量也不会在本地直连。

优势：不依赖 NAT 穿透，连接建立稳定；天然集成 DDoS 防护与全球加速；访问策略可在边缘统一执行。
劣势：端到端延迟高于本地直连；Cloudflare 作为中间节点可获取连接元数据；对 Cloudflare 网络可用性有强依赖。

Tailscale：Peer-to-Peer Mesh（优先直连）

Tailscale 基于 WireGuard，设备之间首先尝试通过 NAT 穿透（STUN/ICE）建立直接连接。只有在对称 NAT 或严格防火墙无法穿透时，才会回退到 Tailscale 的 DERP Relay。详见 Tailscale 对比页面。

优势：直连模式下延迟极低，带宽不受 Relay 瓶颈限制；数据面去中心化，Tailscale 官方无法读取实际流量内容。
劣势：复杂网络环境下可能无法直连，导致延迟和带宽显著下降；中国大陆或某些企业防火墙后的连接稳定性存在变数。

4. 安装配置与易用性差异

上手流程

Tailscale 的上手流程：

在设备上安装客户端（提供各平台安装包，包括移动端 App Store）。
使用各种身份提供商（Google、Microsoft、GitHub 等）或邮箱注册登录。
登录后设备自动获得 Tailscale IP，默认即可互通，无需额外配置网络策略。
若需要子网路由或更细的访问控制，在 Admin Console 中通过 GUI 配置，或编辑 ACL 文件。

Cloudflare Mesh 的上手流程：

需先开通 Cloudflare Zero Trust 账户并完成组织基础设置。
在仪表板中创建 Device Enrollment Policy，生成集成参数。
对于 Mesh node（服务器）：在 Linux 主机上安装 warp-cli，通过仪表板导出的 Token 或认证链接完成注册。对于 Client device（笔记本/手机）：安装带 UI 的 Cloudflare One Client，通过组织域名或邀请链接登录。
在 Cloudflare Dashboard 的 Networking > Mesh 页面检查节点状态、分配的 Mesh IP 和 CIDR 路由。

配置复杂度

对比项	Tailscale	Cloudflare Mesh
安装步骤	下载客户端 → 登录账户 → 完成	需先配置 Zero Trust 组织 → 创建策略 → 安装客户端 → 注册节点
初始配置	默认即用，无需编写策略即可互访	需在 Dashboard 中配置设备注册策略和网络规则
访问控制	ACL 文件（HuJSON）或 Admin Console GUI	Gateway Network Policies，通过 Dashboard GUI 配置
子网路由	在目标节点执行 tailscale up –advertise-routes=…	在仪表板中为 Mesh node 声明 CIDR 路由
DNS 配置	MagicDNS 默认开启，自动生成域名	需手动配置 Local Domain Fallback 或 Resolver Policy
命令行依赖	有丰富的 CLI 命令（tailscale）	Mesh node 主要通过 warp-cli 命令行操作，普通 Client 以 GUI 为主

易用性小结

Tailscale 更适合快速上手。个人用户安装应用后几乎无需配置即可互联，MagicDNS 也能自动解决内网域名问题。但若需要细粒度访问控制，则需学习 HuJSON ACL 语法。

Cloudflare Mesh 的上手门槛稍高。用户需先完成 Zero Trust 组织配置、创建设备注册策略，然后再在不同平台上分别部署。但日常管理几乎全部集中在 Dashboard GUI 中完成，无需编写命令行脚本。

5. 定价与免费额度

Tailscale

计划	价格	核心限制
Personal	$0 / 永久免费	最多 6 个用户、无限设备、最多 3 个 ACL groups、50 个 tagged resources、每月 1,000 分钟 ephemeral resources
Standard	$8 / 用户 / 月	无限用户、最多 10 个 ACL groups、SCIM、MDM、Device Posture 集成
Premium	$18 / 用户 / 月	无限 ACL groups、更多 ephemeral 资源、优先支持
Enterprise	定制报价	SLA、专属客户经理、高级合规

以上数据来源：Tailscale 官方定价页。

Cloudflare Mesh

Cloudflare Mesh 本身没有独立定价，包含在 Cloudflare Zero Trust 套件中：

计划	价格	核心限制
Zero Trust Free	$0	最多 50 个用户；Mesh nodes 每账户上限 50 个；CIDR 路由与 Cloudflare Tunnel 共享上限 1,000 条
Zero Trust Pay-as-you-go	约 $7 / 用户 / 月	超过 50 用户后可用
Zero Trust Enterprise	定制报价	可提升 nodes、routes 等配额

限制说明来源：Cloudflare Community 及 Cloudflare One 账户限制文档。

免费额度小结：对于 6 人以内的个人或小团队，Tailscale Personal 几乎无功能阉割且设备数不限；对于 6–50 人的中型团队，Cloudflare Zero Trust Free 在用户席位上更宽松，但 Mesh nodes 的 50 个上限可能对基础设施规模构成硬约束。

6. 相同点

零信任网络访问（ZTNA）：两者都替代传统 VPN，提供基于身份和设备的细粒度访问控制。
CGNAT 私有地址：都使用运营商级 NAT 地址段为节点分配稳定私有 IP（Cloudflare 使用 100.96.0.0/12，Tailscale 使用 100.64.0.0/10）。
子网路由：都支持将未安装客户端的私有子网暴露给远程设备。
跨平台支持：均覆盖主流桌面与移动操作系统。
无需 Bastion Host：允许直接通过私有 IP 访问后端服务器。

7. 不同点

对比项	Cloudflare Mesh	Tailscale
连接模式	流量必经过 Cloudflare（Relay）	优先点对点直连，失败才走 Relay
节点类型	严格区分 Mesh node（仅 Linux headless）与 Client device	所有设备均为平等的 peer/node
产品成熟度	Beta，功能与限制可能快速变化	非常成熟，社区与企业案例丰富
开源程度	闭源（warp-cli / Cloudflare One Client）	客户端开源，控制面闭源
DNS 体验	需手动配置 Local Domain Fallback 或 Gateway Resolver	MagicDNS 开箱即用
管理平台	Cloudflare Dashboard / API，几乎无需命令行	Admin Console + ACL 文件（HuJSON）
生态集成	与 Cloudflare Workers、Access、Gateway、DLP 深度整合	更独立，需额外配置与其他安全栈集成
加密算法	强调后量子加密（post-quantum）	标准 WireGuard（ChaCha20-Poly1305）

8. 主要适用场景

更适合 Tailscale 的场景

个人开发者与家庭实验室：Personal 免费版对 6 人以内团队几乎无功能阉割，且设备数不限。
对延迟敏感的应用：如远程游戏串流、实时音视频、高频本地开发环境访问，直连模式能显著降低延迟。
需要 Exit Node 或 MagicDNS：希望将某台设备作为全局代理出口，或自动解析内网域名。
开源/可审计需求：客户端代码开源，适合对供应链安全有严格要求的组织。

更适合 Cloudflare Mesh 的场景

已有 Cloudflare One 投资的企业：若已使用 Cloudflare Access、Gateway、DLP，Mesh 可让所有私有流量继承同一套策略。
Serverless 访问私有网络：需要从 Cloudflare Workers 直接调用内网 API 或数据库。
规避 NAT 穿透复杂性：所有流量走 Cloudflare edge，连接建立更稳定，网络策略执行更一致。
后量子加密合规：对加密算法的前瞻性有硬性要求的行业。

9. 潜在风险与注意事项

Cloudflare Mesh

Beta 阶段风险：2026 年 4 月刚升级更名，文档和功能仍在迭代，生产环境部署前需充分评估。
50 nodes 硬上限：对于容器化或大规模服务器集群，50 个 Mesh nodes 可能迅速耗尽，需升级 Enterprise。
Mesh node 平台限制：仅支持 Linux headless，Windows Server 或大量嵌入式设备无法作为 Mesh node（只能作为普通 client）。
Relay 架构的延迟与隐私：流量必经 Cloudflare，物理距离较近的设备之间也会引入额外跳数；对 Cloudflare 服务可用性有强依赖。
完全闭源：遇到边缘场景时，自定义和深度排错能力受限。

Tailscale

免费版用户上限 6 人：7–20 人小团队必须跳转至 $8/人/月的 Standard 计划。
ACL 学习曲线：访问控制基于 HuJSON，对新用户有一定学习成本；免费版仅 3 个 ACL groups，策略复杂度受限。
NAT 穿透失败的体验降级：当无法直连而 fallback 到 DERP relay 时，延迟和带宽会显著下降。在部分企业防火墙或特定运营商网络中，这种情况并不罕见。
控制面依赖：虽然数据面点对点，但节点发现与密钥交换仍依赖 Tailscale 的 coordination server。该服务不可达时，新节点无法加入网络。
Ephemeral 资源限制：Personal 计划每月仅 1,000 分钟 ephemeral 使用时间，CI/CD 或 Kubernetes 场景下可能不足。

总结

个人用户、家庭实验室或 ≤6 人小团队，且对延迟敏感、需要无限设备：Tailscale Personal 是目前最成熟、最慷慨的选择。
已深度使用 Cloudflare 生态，或团队规模在 6–50 人之间、希望统一零信任策略：Cloudflare Mesh（Zero Trust Free）提供了有竞争力的免费方案，但需接受其 Beta 状态与 Relay 架构带来的额外延迟。
超过 50 人的企业，两者均进入付费区间，决策应更多基于现有安全栈生态（Cloudflare 一体化 vs. 独立最佳实践）以及对直连性能的敏感程度。

参考来源

扫描版 PDF 的处理逻辑：从本地 OCR 到 Vision 大模型

Sat, 11 Apr 2026 12:54:28 +0800

处理扫描版 PDF 时，一个常见的陷阱是先用传统 OCR 工具跑完全量，再花费大量时间清洗错误结果。本文从一次 Hermes Agent 执行的大尺寸扫描版 PDF 提取任务出发，抽象出一套更通用的处理逻辑：如何以最小的沉没成本，高效、高质量地完成扫描版 PDF 的识别与结构化整理。

一、先判断：这是"图像书"还是"文档"

拿到 PDF 后的第一步不是直接提取，而是做类型探测。很多扫描版 PDF 外表上是 .pdf，内部却没有任何可提取的文本层。

这一步通常只需几秒钟，却能避免后续数小时的无用功。

二、本地 OCR 的职责应当最小化

确认是图像型 PDF 后，很多人的第二反应是启动 Tesseract 等传统 OCR 工具进行全量识别和清洗。但在实际任务中，这种做法的边际收益往往很低：

本地 OCR 对印刷体英文的识别尚可，但对中英混合排版的中文释义容易出错；
清洗脚本只能处理排版噪音（页眉、页脚、表格线），无法修复语义层面的识别错误；
当最终目标是结构化、可直接使用的高质量文本时，清洗代码的投入很容易变成沉没成本。

三、决定性环节：引入 Vision 大模型直接识别

在本次任务中，Hermes Agent 在确认本地 OCR 的中文质量不可接受后，自行编写 Python 脚本，直接调用了外部的 Vision-Language 模型（Qwen/Qwen2-VL-72B-Instruct）进行重新识别。这是最终决定输出质量的转折点。

3.1 模型选择的教训

最初测试了名为 OCR 的专用模型，但该模型指令遵循能力较弱，会反复输出页面上的复习表格和标记符号，无法按要求只提取目标内容。这说明：

3.2 调用方式的安全实践

外部 API Key 并未硬编码在脚本中，而是通过 ~/.hermes/.env 配置的环境变量注入（如 SILICONFLOW_API_KEY），由脚本通过 os.environ 读取。这种实践符合安全要求：

密钥不暴露在任何代码文件或日志中；
凭据存储在用户主目录的受控配置里；
仅在当前会话生命周期内有效。

对于 AI Agent 而言，通过 ~/.hermes/.env 获取环境变量是调用外部服务的标准且安全的方式。

四、页面拼接策略：把连续页面合并后统一识别

扫描版书籍、教材、试卷往往存在跨页连续排版的内容。如果逐页单独上传给模型，可能导致：

上下文割裂，模型误判两页内容的关联性；
跨页断开的条目被截断或遗漏。

本次任务采用的策略是：

具体做法：

用 pdf2image 将连续页转换为图片；
用 PIL 将多张图片垂直拼接成一张长图；
以 JPEG 格式压缩后编码为 base64，通过 API 上传。

这种方式的优势在于：保持了阅读的连续性和空间关系，减少了 API 调用中的上下文切换，同时也节省了多次请求的开销。

五、Prompt 设计：格式化输出的刚性约束

为了让 Vision 模型输出可直接写入文件的纯净文本，prompt 需要包含以下刚性约束：

明确排除项：列出页面上所有非目标内容（表格、圆圈标记、页码、使用说明等），要求模型主动忽略；
格式模板：规定每个条目的输出格式，例如 序号. 英文单词音标词性中文释义；
固定头部：强制要求输出开头包含统一的标题结构，方便后续自动化处理；
参考文本辅助：将本地 OCR 的初筛结果附在 prompt 末尾，让模型基于图片进行"对比修正"，而不是从零盲猜。这能显著提升输出准确率和完整性。

六、核心方法论：先验证，再全量

无论使用什么工具链，处理扫描版 PDF 时最重要的一步是：

6.1 最小化验证的内容

在启动全量批处理之前，Agent 应当先用最小成本验证以下要素：

页码映射规律：几天/几章？每章占几页？边界在哪里？
模型识别能力：当前 DPI 下，模型能否准确识别字体、音标、中英混合内容？
Prompt 稳定性：连续 1~3 个样本的输出格式是否一致？是否遗漏内容？
成本估算：单页/单章的 token 消耗是否在预算范围内？DPI 是否可以降级？

6.2 分辨率动态降级

图像 token 成本与分辨率大致成正比。可以先以低 DPI（如 100 DPI）测试 Vision 模型，如果识别率已足够，就不必使用 150 DPI 或 250 DPI。对于字体较大的印刷品，100 DPI 往往已能满足需求，可降低约 50% 以上的图像编码成本。

6.3 结构化输出的可能性

如果 API 支持 JSON mode，可以直接要求模型返回结构化数组（如 {"word", "phonetic", "pos", "definition"}），从而彻底消除后处理清洗代码，提升自动化程度和可维护性。

七、交付结构：原始数据与精校结果隔离

在处理可能产生多版本结果的任务时，建议采用双目录隔离的设计：

这种设计的好处：

原始数据不丢失；
任何单元的精校结果都可以与原始输出做 diff；
不会因为覆盖操作导致无法回滚。

八、给 AI Agent 的前置检查清单

如果你是 AI Agent，在接到"从扫描版 PDF 中提取结构化内容"的任务时，请按以下顺序执行：

PDF 类型探测：pdfinfo + pdftotext 抽样，确认是否为图像型 PDF；
结构规律探测：用最低成本的方式（低分辨率 OCR 或少量 Vision API 调用）确认"页→章节/单元"的映射规律；
方案验证：用 Vision 模型处理前 1~3 个单元，验证输出格式、完整性和准确率；
API Key 安全：从 ~/.hermes/.env 环境变量读取，绝不硬编码；
全量并发执行：确认无误后再批量处理，结果保存到独立目录，不覆盖原始数据。

九、结论

对于扫描版 PDF 的内容提取，工具链的选择顺序比单一工具的能力更重要。传统 OCR 适合作为低成本的结构探测前哨，但如果最终目标是可直接使用的高质量结构化文本，Vision-Language 模型才是质量的最终保障。

最昂贵的错误，往往不是选错了模型，而是在没有经过最小化验证的情况下就启动了全量批处理。Agent 应当在早期就建立"验证样本 → 调整参数 → 全量执行"的节奏，以控制沉没成本并确保最终交付物的可靠性。

Hermes Agent Slack 使用指南：从高效对话到精细化配置

Fri, 10 Apr 2026 09:55:33 +0800

Hermes Agent 在 Slack 中的集成旨在提供一个高效、可隔离且可自定义的交互环境。为了确保在多人协作的频道中能够精准调度 AI 而不干扰他人，理解其交互逻辑和配置项至关重要。

核心交互规则

1. 显式唤起 (@mention)

在 Slack 频道中，Hermes 默认采用“被动响应”模式。这意味着简单的文本消息会被忽略，必须通过 @mention (例如 @Hermes) 明确唤起机器人。

这一设计旨在防止 AI 在高频讨论的频道中产生不必要的干扰，确保只有在用户明确需要时才介入对话。

2. 线程作为上下文隔离单元

Slack 的 Thread（线程）是 Hermes 管理上下文的核心机制：

上下文继承：在已有线程中 @mention Hermes，它会继承该线程的历史记录并在此回复。
独立会话：不同线程之间的上下文是完全隔离的。
多人并行：即使在同一个频道中，不同用户与 Hermes 的对话历史也是分离的，只要各自在独立的线程中进行。

高频使用技巧

任务隔离：一事一线程

为了避免上下文混淆，最有效的实践是将每一个独立任务绑定到一个独立的线程。

操作流程：

发起新任务 → 创建新消息并 @mention Hermes → 开启新线程。
追问或迭代 → 在该线程内回复。

优势：当需要并行处理多个任务（如：同时进行“代码审查”和“文档编写”）时，可以通过切换线程来快速切换上下文，而无需向 AI 重新解释背景。

结构化首条指令

为了提高响应质量，建议首条指令包含以下要素：

任务目标：明确要解决的问题。
约束条件：输出格式、禁忌项或特定参考资料。
预期结果：希望得到的最终交付物形式。

配置项深度解析

Hermes 的 Slack 行为可以通过 ~/.hermes/config.yaml 进行精细化调整。

1. 线程回复行为 (`reply_in_thread`)

路径：platforms.slack.extra.reply_in_thread
默认值：true
行为：
true：频道内的首条指令会在新线程里回复。
false：频道内的首条指令会直接回复到主频道流。
边界：无论此项如何设置，已经在线程中的消息始终会在线程内回复。

2. 响应触发机制 (`require_mention`)

路径：require_mention
默认值：true
行为：决定是否必须通过 @mention 才能激活机器人。在多人协作频道中，建议保持为 true，以避免误触发。

3. 自定义触发模式 (`mention_patterns`)

除了标准的 @mention，还可以通过 mention_patterns 配置自定义口令唤起。

示例配置：

用途：在特定工作流中简化唤起操作，无需频繁输入 @ 符号。

4. 可对话用户白名单 (`SLACK_ALLOWED_USERS`)

Hermes 还支持通过 Slack Member ID 限定哪些用户可以与 bot 对话。

配置方式：设置环境变量 SLACK_ALLOWED_USERS
值类型：Slack Member ID 列表，而不是用户名或 display name
安全行为：如果不设置该白名单，网关会默认拒绝所有消息，作为安全措施
适用场景：
只允许特定成员调用 bot
避免频道里无关成员误触发
在测试环境里限制使用范围

总结：Slack 使用口诀

频道先 @，任务一线程一事，换题另起 thread，多人并行不串线。

信息来源

Hermes profiles：在一台设备上给多人提供独立 AI 助手

Fri, 10 Apr 2026 08:34:20 +0800

什么是 profiles

Hermes 的 profiles 功能，提供的是一组彼此隔离的运行环境。每个 profile 都有自己的配置、密钥、人格设定、记忆、会话、技能、定时任务和状态库。换句话说，它不是在同一个会话里分出几个角色，而是在同一台设备上建立多个独立的 Hermes 空间。

这类隔离带来的直接结果是：不同用途、不同身份、不同用户之间不会互相污染上下文。一个 profile 可以专门给自己用，一个给家人用，一个给朋友用，也可以按项目、按角色、按工作流拆开。

它是怎样工作的

创建 profile 之后，Hermes 会自动为它生成独立的命令入口。比如创建一个名为 coder 的 profile 后，就可以直接使用：

coder chat
coder setup
coder gateway start

这意味着 profile 不只是一个配置文件夹，而是一个可以直接启动和管理的独立 agent 单位。

Profile 管理命令

创建 Profile

选项	说明
–clone	复制 config.yaml、.env、SOUL.md，但使用新的会话和记忆
–clone-all	复制全部内容，相当于完整快照
–clone-from	指定源 profile，而非当前 profile

列出和切换

使用 Profile 的方式

方式一：命令别名（自动生成）

创建 profile 后，Hermes 会自动在 ~/.local/bin/ 下生成同名命令：

方式二：-p 参数

查看详情

输出示例：

导入和导出

删除 Profile

:::warning

删除操作不可恢复，会同时停止网关、移除服务并删除所有数据。

:::

Profile 文件结构

每个 profile 存储在 ~/.hermes/profiles/<name>/，包含：

适合什么场景

1. 给不同人提供独立助手

最直接的用途，是在同一台设备上给家人或朋友各自创建一个独立的 Hermes。每个人都能拥有自己的配置、记忆和使用习惯，不需要理解底层运维细节。

2. 多项目隔离

如果你同时维护多个项目，可以把每个项目放进不同 profile。这样模型设置、技能、会话历史和 cron 任务都不会互相干扰。

3. 多角色并行

你可以把一个 profile 作为个人助理，另一个作为代码助手，再另一个作为研究助手。它们的行为风格、插件、记忆和任务状态都可以单独配置。

4. 实验和备份

当你想测试一套新配置、新技能，或者想保留当前状态做一个可回退的副本时，--clone-all 很适合。它可以把当前环境完整复制出来，再在新 profile 上继续试验。

能解决什么问题

profiles 主要解决的是"单一 agent 不够分、上下文容易串、配置难隔离"的问题。

具体来说，它可以减少：

会话历史混在一起
不同用户的记忆冲突
API 密钥和模型配置互相覆盖
定时任务、技能、插件互相影响
一个 agent 既要扮演多个身份，又没有清晰边界

因此，profiles 更像是一种"隔离式多租户"能力：同一台机器上，可以同时运行多个互不干扰的 Hermes 实例。

和 subagent 的区别

profiles 和 subagent 不是一回事。

profiles：长期独立环境，适合多人、多身份、多项目
subagent：临时派出去执行单个任务的工作单元，适合并行研究、拆分任务、快速协作

可以把 profiles 理解为"各自独立的房间"，把 subagent 理解为"临时派出去做事的人"。

一个比较实用的理解

如果你希望一台设备上同时服务不同人，而且每个人都像拥有自己的专属 AI 助手，那么 profiles 就是 Hermes 提供的基础能力。它让复杂的多用户使用方式变成可管理、可隔离、可复制的结构。

这也是它和很多只强调单会话工作流的方案相比，最有价值的地方之一。

OpenClaw 把 Ghost 发布能力做成 skill 的过程

Thu, 02 Apr 2026 11:56:02 +0800

这篇记录一次具体实现：让 OpenClaw 能稳定创建、更新并发布 Ghost 文章。目标很简单，流程要能复用，配置要能收敛，出错时也要知道卡在哪一步。

目标

我们想让 OpenClaw 做三件事：

读懂 Ghost 的发布链路
把发布流程整理成一个可复用的 skill
用本地环境变量完成鉴权和发布，不把密钥写进代码

先看了哪些文档

先看的不是文章样例，而是 Ghost 官方文档里和接口、鉴权相关的部分，重点确认两件事：

哪些接口只负责读取
哪些接口可以创建和更新内容

看完之后，结论很明确：Content API 适合读取，真正写入要走 Admin API。

这个 skill 做什么

我们把流程整理成了 ghost-publisher。

它的职责很窄，也很明确：

接收标题、正文、slug、标签等发布字段
处理 Markdown 或 HTML 输入
发布前规范化内容结构
调用 Ghost Admin API 创建或更新文章
返回可验证的结果，例如文章 id、slug、URL 和状态

这样做的好处是，OpenClaw 不需要每次都临时解释 Ghost 规则，直接走这个 skill 就行。

需要哪些环境变量

概念上只需要两类配置：

Ghost 的站点地址
Ghost 的 Admin API key

这两个值都应该放在 .env 里，由 OpenClaw 启动时读取。不要把它们写进文章、日志或提示词里。

为什么第一次没成功

一开始我们拿的是 Ghost Integration 里常见的 Content API key。它能读内容，但不能写内容。

这就是第一次失败的根因：

Content API key 是只读的
要写文章，必须使用 Admin API key
Admin API key 需要在 Ghost 后台创建 Custom Integration 后才能拿到

权限模型没理顺之前，流程看起来都对，实际就是发不出去。

为什么改了 `.env` 还要重启 OpenClaw

因为 OpenClaw 读取环境变量是在启动时完成的。

所以 .env 改完以后，必须重启 OpenClaw，新的 host 和 key 才会真正生效。只改文件不重启，进程里还是旧配置。

实际踩到的格式问题

这次也确认了几个发布时的约束，后面继续做文章时可以直接沿用：

正文里不要重复顶层标题，Ghost 已经有 title 字段
发布前先规范化 Markdown，避免混乱的空行、缩进和重复列表符号
slug 要清楚，和主题一致，英文通常比硬拼中文更直观

这些问题不解决，页面就会显得乱，也会让内容更像临时拼出来的。

怎么安全地让 AI 处理带密钥的环境

如果让 AI 参与这类工作，边界要先写清楚：

只使用指定的环境变量
不要输出 .env 全文
不要回显任何 key 的值
只返回非敏感的验证结果

也就是说，AI 可以告诉你“配置是否生效”“文章是否已发布”“返回的 slug 是什么”，但不能把密钥内容带出来。

结果

这套流程跑通以后，OpenClaw 现在已经可以稳定地：

读取本地配置
通过 ghost-publisher 处理文章
用 Admin API 写入 Ghost
返回可核验的发布结果

后面如果还要扩展到更新文章、批量发文或更复杂的内容格式，基础已经在了，直接沿用这条链路就行。

效率工具 on 火炬树

Pi Agent 配置进阶：AGENTS.md、模型切换与 Thinking Level 实战指南

Pi 的配置文件分几层？每层管什么？

AGENTS.md 怎么写才有效？

全局 AGENTS.md 写什么

项目 AGENTS.md 怎么组织

修改后记得重载

APPEND_SYSTEM.md 控制什么行为？

settings.json：常用选项详解

模型与思考级别

上下文压缩（Compaction）

重试策略

项目信任模式

models.json 添加自定义模型

场景一：Ollama 本地模型

场景二：OpenRouter 路由配置

场景三：代理中转 Anthropic API

auth.json 管理 API 凭据

模型切换策略：什么时候用什么模型

切换方式

推荐的分层策略

enabledModels 通配符

Thinking Level 如何影响输出质量

上下文管理：Compaction、会话树与手动控制

自动压缩（Compaction）

会话树管理

一套完整的配置模板

全局 settings.json

全局 APPEND_SYSTEM.md

项目 .pi/settings.json（覆盖全局压缩策略）

总结

Pi Coding Agent 实战配置：从安装到日常使用的完整指南

定位：Pi 在工具链中的角色

安装与首次配置

三个核心扩展包

pi-web-access

pi-codex-goal

pi-vision-proxy

配置文件体系

快捷键与常用命令

实际成本案例

为什么选择 Pi

一人日更、篇均 12 万曝光：一套可复用的 AI 内容生产系统

核心思路：从碎片化提问到闭环系统

四层知识库：Obsidian + Claude Code

第一层：语料库——解决"AI 写出来不像你"

第二层：素材库——站在别人的数据上选路线

第三层：内容管线——按策略挑选题，不是临时想写什么写什么

第四层：方法论——从自己的数据里提炼规律

配图策略：HERO 图、标题、钩子三件套信息不重复

数据表现：篇均 12 万曝光，书签率 0.5-1%

从数据里长出来的四条规律

如何开始：不用一步到位

有了 AI Agent 助手，还需要 N8N 吗

问题的起点：AI Agent 能替代工作流自动化吗

N8N 最新功能特性：从自动化到 AI 编排

AI Agent Node 与动态模型选择

Agent-to-Agent 协作与 MCP 双向集成

企业级治理与可靠性

Human-in-the-Loop 与错误处理

Hermes Agent 与 OpenClaw：AI 助手的两种实现

Hermes Agent 的核心能力

OpenClaw 的核心能力

两者的共同边界

能力边界对比：Agent 与 N8N 各自覆盖什么

典型协同架构：让 Agent 和 N8N 各尽其职

什么时候可以只用 Agent，什么时候必须上 N8N

纯 Agent 即可覆盖的场景

必须引入 N8N 的场景

结论：互补而非替代

参考来源

如何用两小时"蒸馏"一个人

核心命题：为什么一个文本文件就能复制你的人格

方法论的两阶段结构

第一阶段：100 道题的深度自我采访

第二阶段：压缩为高保真档案文件

实际效果：从实验到工作流

方法论的价值与局限

为什么这个方法有效

局限与值得警惕的地方