技术架构 on 火炬树

DeepSeek Harness 开源解读：一切皆插件的 Agent 运行底座

Fri, 14 Aug 2026 08:04:47 +0800

2026 年 8 月 13 日晚，DeepSeek 在公布 API 调价后不久，正式发布并开源了 DeepSeek Harness（以下简称 dsh）开发者预览版 v0.1。DeepSeek Harness 是 DeepSeek 官方开发的开源 agent harness（智能体框架，负责把大模型接入文件系统、终端、网页等真实环境并驱动其持续工作），其核心设计被定义为：Everything is a plugin（一切皆插件）。模型、工具、技能、会话、存储、沙箱、调度、UI，所有 Agent 能力都由插件组合而成，可自由替换、灵活重组。项目以 MIT 协议开源，仓库地址为 github.com/deepseek-ai/deepseek-harness。

需要注意的是，这不是一个全新的 DeepSeek 模型，也不是单纯的 API 客户端。官方把 Agent 拆成两个部分：模型是灵魂，harness 负责让模型理解环境、使用工具、在真实场景里持续工作。dsh 是这套“除模型之外的全部”的开源实现，也是 DeepSeek 从模型层向 Agent 运行时层延伸的第一块正式拼图。

一天 6.6 万星

GitHub API 数据（2026-08-14 早）：deepseek-ai/deepseek-harness 仓库创建于 8 月 13 日，发布 24 小时左右即收获约 4.6 万星，次日早晨已超过 6.6 万星、5,596 forks，是近期增长最快的开源项目之一。npm 包 @deepseek-ai/dsh 最新版本为 0.1.0-rc.6，拆分为 20 多个 @deepseek-ai/dsh-* 子包。

项目背景可以追溯到 2026 年 5 月。彼时 DeepSeek 资深研究员陈德里公开招人，称要对标 Anthropic 的 Claude Code 做 “DeepSeek Code Harness”；团队负责人崔添翼随后发文，说团队新成立、人员紧缺，“每天都在面试”。此次开源前，项目已铺垫数月，8 月初部分媒体获得内测资格并提前体验。

与 dsh 同天发布的还有 DeepSeek V4 Pro 正式版，dsh 默认深度适配 V4 Pro 和 V4-Flash 模型。官方明确表示，当前处于开发者预览阶段，核心插件与接口会快速迭代，未来将出现破坏兼容性的变更。

一切皆插件：Cordis 微内核

dsh 最醒目的设计主张是“一切皆插件”，而且是字面意义上的全部。项目建立在 Cordis 微内核之上，运行中的 dsh 本质上是一个 Cordis Context。

Cordis 是 cordiverse/cordis 项目（2022 年创建，GitHub 实测 2,337 星），自称 “Meta-Framework of Spatiotemporal Composability”（时空可组合性元框架），设计思想源自论文《A Programming Paradigm for Spatiotemporal Composability》（一种面向时空可组合性的编程范式，见 cordiverse/paper）。Cordis 的思路是：插件向共享上下文贡献服务、类型化事件和可逆的副作用。新能力通过挂载插件加入，插件卸载时，自己注册的服务和副作用一并撤销。

这套设计带来两个直接结果：

可观测。 每一步状态都能被追踪和还原。

可回放。 多 Agent 协作可以像录像一样回放、调试。

官方架构文档明确写道：“不存在需要打补丁的特权内核”。扩展 dsh 的方式是把插件挂载到其他插件旁边，各项注册都是副作用，会在插件卸载时撤销。换模型就替换模型适配器，加工具就注册到统一的工具系统，换本地执行为远程沙箱就替换文件系统、进程和终端提供方，调整 Agent 行为可以替换整个 Agent Loop，不需要重写产品。

核心包：没有“大 Agent 类”

dsh 的仓库规模很大，包含超过 230 个 workspace 成员，代码分布在 packages/、apps/、examples/、python/、native/、vendor/、website/ 等区域。文件系统、终端、子进程、PTY、语言服务器、网页访问、技能、子智能体、工作流、计划模式、会话持久化、设置、凭据、遥测，几乎每一项能力都有自己的包。

官方架构文档把核心职责拆到不同包，没有一个大而全的 Agent 类包办所有事情：

包	职责	ctx 键
core/session	仅追加的 SessionEvent 日志和内存存储	ctx.sessions
core/system-prompt	提示词片段与工具 schema 的组装	ctx.systemPrompt
core/tools	作用域化的工具注册表和带把关的执行流水线	ctx.tools
core/agent	Agent 接口、活跃 agent 注册表和 agent/* 事件	ctx.agents
core/agent-loop	实现该接口的默认驱动器	ctx.agentLoop
core/scope	按 agent 划分作用域的注册原语	库，无 ctx 键
llm/llm	消息与流式词汇表，以及适配器 seam	ctx.llm

模型是模型，工具是工具，循环是循环，需要时再把它们拼起来。这种结构体现了一种边界意识：谁拥有接口，谁负责实现，谁把能力呈现给模型，尽量不混在一起。

Profile 与 Bundle：运行配置也能组合

运行中的 dsh 是一棵插件树，由启动时按序叠加的各层组合而成。

profile 是一套命名好的运行组合，存放在 Harness home 中。它列出自己叠放的组合包（bundle），存放自己安装的树外插件，并保存用户自己的 cordis.patch.yml。官方交付了两个模板：web（启动 Web UI）和 headless（一次性运行，不带服务器）。

bundle 是可以分发的插件组合。启动时，Harness 会从空配置开始，依次叠加 profile 指定的 bundle，再应用 profile、用户目录和命令行上的 patch。各层按此顺序应用：先按 profile 列出的顺序应用每个组合包，然后是 profile 的 cordis.patch.yml，然后是 home 级的那份，最后是任意 --patch overlay。

想查看实际启动的配置树，运行：

这条命令打印出的任何条目，都可以由自己的 patch 替换。部署差异尽量放进配置组合，而不是变成一堆分支代码。

Turn 与 Step：一轮任务的完整生命周期

官方把一次工作拆成 turn 和 step 两个层级。一个 turn 是一轮完整任务，里面可以有多个 step；一个 step 对应一次模型请求，以及这次请求触发的工具调用。

简化后的事件流如下：

这些事件是给插件提供的具体接入点，模型请求前可以改写或拒绝输入；请求发出时可以拦截；工具执行前后可以加入审批、超时、监控和策略检查。

输入通过同一个 inbox 到达驱动器，有些消息会立即唤醒它；注入的上下文会留在 inbox 中，直到另一条消息将其唤醒。agent/pre-step 决定模型看到什么，监听器可以改写已领取的消息，也可以直接拒绝；首次领取被拒绝或被改写为空时，仍会关闭一个不含步骤的持久轮次，日志会记录这次尝试。

工具也不是“拿到函数名就调用”，它会经过前置策略、不可逆的安全守卫、实际执行、后置处理、内容整理和结果通知。允许或拒绝、超时、重试、指标统计、附加上下文，都可以从流水线的不同位置接入。工具可以声明某类参数下的调用是并发安全的，调度器便会让连续的只读任务并行；一旦碰到修改状态或无法确定安全性的调用，就把它当作屏障，等待前面的任务结束后独占执行。

会话日志：模型可见即已记录

dsh 另一项核心设计是会话日志（Session Log）。项目规定，凡是模型看见的内容，都必须能够从日志中重建，并由一项运行时不变量断言这一点。因此，新增一项模型可见输入就需要新增一个会话事件：扩展 SessionEventMap 并从日志渲染。

用户消息、运行环境上下文、模型请求信息、流式输出、工具调用和结果、压缩事件、权限切换、取消原因，都会以事件形式进入追加式会话流。deriveMessages() 从日志中投影出模型历史，原始 assistant/chunk 事件则保证回放和 UI 保真。fork、恢复、transcript（文本记录）、遥测和持久化都派生自该事件流。

这项原则解决的是 Agent 系统里一个棘手问题：当任务出错时，我们能不能知道模型当时到底看到了什么？如果系统只保存最终聊天文本，许多关键因素会丢失。也许模型请求前刚注入了工作区状态，也许工具结果被裁剪过，也许系统自动切换了模型路由，也许用户在流式输出中途改变了方向。dsh 在请求边界保存足以重建消息的记录，原始流式 chunk 也保留，以便界面和回放维持一致。

会话持久化本身仍然是插件，项目提供 JSONL 和 SQLite 后端，查询能力可以优先访问实时会话，也可以通过 SQLite 全文检索历史记录。Resume 会沿用原会话继续工作，Fork 则从一个确定的历史边界派生新会话。

能力 seam：换后端不换产品

dsh 把可替换能力称为 seam（接缝）。一个 seam 通常有三层：声明接口的 Service Definition、实现它的 Service Provider，以及使用它的 Consumer（通常是面向模型的工具）。

以 Bash 为例，接口定义“执行命令”是什么，本地实现负责真正创建进程，而面向模型的工具包负责把这项能力变成模型可理解的 schema 和结果。文件系统与进程提供方共享同一个执行世界，因此把它们指向远程沙箱，也就把 Bash、PTY 和 LSP 一并搬了过去，无需为每个工具写远程分支。subagent 提供方在同一个接口之后也千差万别，从新建一个子 agent，到把一个轮次委派给另一个产品。

这种设计让替换一个提供方就能改变整个产品的行为，本地 Shell 换成远程容器、云端沙箱或企业执行平台，理论上只需替换实现层，不必重写模型工具和 Agent Loop。

四种运行模式

dsh 的 Web UI 提供四种 Agent 预设模式。它们是基于同一套 Harness 宿主，为当前会话装配不同的工具、提示词和运行时能力：

模式	内容
标准模式	功能最完整的通用编码 Agent：文件编辑、Shell、文件与网页检索、Skills、计划、目标、子 Agent 和工作流
Code 模式	保留标准模式全部能力，同时通过 Code Mode SDK 向模型呈现工具。模型可以编写一段 TypeScript 程序，在一次 run_code 中组合多步操作，减少反复往返的开销
极简模式	只提供持久 Bash 与 str_replace_editor 两项工具，较小的工具集合减少选择和上下文负担，适合路径明确的编码任务
创造模式	在标准模式之上加入 Cordis 运行时检查、临时插件实验和 Agent preset 创作指导。Agent 可以检查甚至改装自己的运行时

创造模式是“一切皆插件”最极致的表达。选择这一预设后，Agent 可以检查当前运行时的插件树，并动态挂载或卸载临时插件，在任务完成后卸载。自指 Cordis 工具不会进入标准、Code 或极简模式，作为明确的高级入口提供，官方定位为面向高级用户的高信任模式。

快速上手

前置条件只有 Node.js（≥ 18）。运行：

该命令会启动 Web UI，默认监听 http://127.0.0.1:3080。也可以在 Web UI 的 Settings → Models 里填入 DeepSeek API key 并保存，模型路由立即生效，无需重启服务。然后选择工作区（workspace），即可开始会话。dsh 进程以调用目录为默认文件系统位置，新 Web UI 需要手动添加工作区。

从源码运行：

自动化方面，项目提供 ACP 服务和 JSON-RPC 入口。Python SDK 驱动随附的 JSON-RPC 运行时，让 Python 应用可以启动会话、发送任务、接收通知，而不必直接嵌入 Node 内核。仓库还包含 Code Mode、自指 Cordis、MCP 记忆服务等示例。

安全设计：失败关闭

编程智能体一旦获得文件系统和 Shell 权限，就能修改代码、安装依赖、启动进程，甚至触碰工作区之外的主机环境。dsh 把安全问题当作基础架构问题处理：

默认采用 workspace-write 模式，将命令执行和文件修改限制在当前工作区及允许的临时目录中，并配合 ask 审批策略处理需要扩大权限的操作
danger-full-access 模式存在，但必须由部署方明确选择
工具调用经过前置策略、单调安全守卫、执行包装和后置处理。被守卫拒绝的操作不能被后续插件重新放行
文件系统、Bash 和子进程共享同一套沙箱策略，避免出现“命令受限制，但文件工具可以绕过去”的割裂边界
采用失败关闭原则，系统无法确认隔离机制真正生效时拒绝执行，不静默退化为无保护运行

权限切换、审批请求、工具参数、执行结果和取消原因都会进入 Session Log，为事后审计和问题复现保留依据。

插件生态：发布当天自发成型

GitHub topics 实测：600 多个公开仓库带 dsh-plugin 话题。第三方开发者中心 dsh.so 索引了 490 多个已验证插件。代表性项目：

插件	星数	说明
dsh-web-ui	586	Web UI 的插件与皮肤合集：任务看板、git 图、右侧面板、宠物、token 统计
dsh-cc-tui	169	Claude Code 风格的全屏终端 TUI，面向偏好 CLI 的用户
dsh-vision-toolkit	169	让纯文本模型做视觉任务：带意图的图片问答、长截图 OCR、UI 还原
awesome-deepseek-harness	162	插件、MCP、编排的精选清单
oh-dsh	70	一站式社区发行版，统一 TUI、桌面端、Web UI 三种形态

插件星数来自 dsh.so 与社区文章，发布时间集中在开源后 24 小时内。一个插件生态在项目发布当天自发成型，是“开放插件范式”在 Agent 领域的一次快速验证。

与同类工具的对比

工具	定位	扩展方式	协议
DeepSeek Harness	通用 Agent 底座	一切皆插件（Cordis）	MIT 开源
Claude Code	终端 AI 编程助手	闭源内置	闭源
Codex CLI	终端编码 Agent	多 Agent 编排	闭源
OpenCode	开源终端编码 Agent	社区驱动	开源

dsh 的差异化在于官方开源加插件范式。Claude Code 和 Codex 都是闭源产品，能力边界由厂商定义；dsh 以 MIT 协议把能力边界交给社区，这是闭源产品难以复制的护城河。

局限与风险

开发者预览阶段。 官方明示未来会出现破坏兼容性的变更，核心插件与接口仍在快速演进，不适合在生产环境锁版本。

学习成本高。 Cordis 插件树、profile/bundle、事件流、seam 等概念有门槛，对初学者不友好。官方文档建议直接用 agent 探索代码库来理解架构。

配置有陷阱。 配置补丁替换的是目标插件的整个 config，不是深度合并。如果只写一个新字段，原有的 API Key、基础地址或其他参数可能会一起消失。

生态早期。 插件虽多但质量参差，多数是 UI 和工具类，深度能力插件还在生长。

技术栈。 项目以 Node.js/TypeScript 为主，与 Python 为主的 AI 社区有隔阂。Python SDK 通过 JSON-RPC 驱动，属于外围接入，不是一等公民。

笔者观点

dsh 的开源意味着 DeepSeek 不再满足于只提供可被调用的模型，开始争夺模型之上的开发者入口。AI 编程是大模型商业化落地最靠前的领域之一。据 Research and Markets 数据，2025 年全球 AI 编程相关工具市场规模约 295.7 亿美元（约合人民币 2,011 亿元），预计 2030 年攀升至 646.8 亿美元（约合人民币 4,398 亿元），年复合增长率约 17.1%。

技术层面，会话日志“模型可见即已记录”的原则解决了 Agent 调试和审计中最痛的问题：任务失败后重试、执行到一半恢复、把会话 fork 出去继续跑，系统首先得回答一个问题，刚才模型到底看到了什么。Cordis 的可观测、可回放能力如果能在多 Agent 协作中真正落地，会推动整个行业的调试标准。

官方在发布页也明确表达：“DeepSeek Harness 仍在开发者预览阶段，核心插件和 API 将继续演进。我们期待与全球开发者一起，用可复用、可组合的开源基础设施探索智能的边界。”

对开发者来说，现在的价值在于研究架构、写插件、跑工作流。执行命令 npx @deepseek-ai/dsh web 即可开始体验；想开发插件，可以从 Cordis 和官方架构文档读起。这个项目后面最值得关注的，是“一切皆插件”最终能把 Agent 拆到多细，又能重新组合出多少种运行方式。

参考来源

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 的价值不在于"功能最全"，而在于"可控性最高"。它的每一个行为都是透明的，每一个功能都是显式安装的。这种设计哲学让它成为副项目和实验性任务的理想选择。

参考来源：

Hermes Kanban：让多个 AI Agent 像团队一样协作

Sun, 07 Jun 2026 07:24:48 +0800

Kanban 是什么

Hermes Agent 是一个开源 AI Agent 框架，支持在终端、Telegram、Discord、Slack 等多个平台上运行。它的 Kanban 功能是一套持久化的多 Agent 协作任务板，让多个独立的命名 Agent（在 Hermes 中称为 profile）通过共享的任务队列协同工作，无需依赖脆弱的进程内子代理调度。

每条任务是 SQLite 数据库中的一行记录，每次交接是任何人都可读写的持久数据，每个 worker 都是一个拥有独立身份和记忆的完整操作系统进程。这和 Hermes 原有的 delegate_task（一次性函数调用式子代理派发）形成互补：delegate_task 适合快速的一问一答，Kanban 适合需要持续状态、多角色接力、人类介入的工作流。

它能做什么：从一个真实场景说起

假设你需要写一篇技术调研报告。传统做法是让一个 AI Agent 从头做到尾，结果往往是：调研深度不够、写作风格单一、中间方向偏离无人纠正。

用 Kanban，流程变成这样：

你创建一个 triage 状态的任务：“调研 Hermes Kanban 功能，形成一篇面向开发者的分析报告”
系统的自动编排器（decomposer）将它拆解为三个子任务：researcher 做信息采集、analyst 做综合分析、writer 负责成文
两个 researcher 子任务并行执行，各自负责不同信息源
它们完成后，analyst 自动启动，读取两份调研结果进行综合
analyst 完成后，writer 启动，基于综合结果撰写报告
整个过程中，你随时可以评论、调整方向、阻塞等待决策
最终产出包含完整的审计轨迹：谁做了什么、花了多久、中间经历了几次迭代

这不是概念设想，而是 Kanban 的标准工作模式。

Kanban 的核心概念有哪些

Kanban 由六个相互协作的组件构成。

**Board（看板）**是独立的任务队列，拥有自己的 SQLite 数据库、工作目录和调度循环。单次安装可以创建多个 board，按项目或领域隔离。

**Task（任务）**是看板中的基本单元，包含标题、正文、一个 assignee（指派的 profile 名称）、状态流转链（triage → todo → ready → running → blocked → done → archived），以及可选的 tenant 命名空间和幂等键。

**Link（依赖）**记录任务之间的 parent → child 关系。当所有父任务完成后，子任务自动从 todo 提升为 ready，由调度器拾取执行。这实现了"扇出 + 扇入"的并行编排。

**Comment（评论）**是 Agent 之间的通信协议。Agent 和人类都可以追加评论，worker 被（重新）调度时会读取完整的评论线程作为上下文。这本质上是任务维度的对话通道，不依赖主聊天的上下文窗口。

**Workspace（工作空间）**是 worker 操作的目录。scratch 是临时目录，任务完成后自动清理；dir:<path> 指向一个现有的持久目录；worktree 是 Git worktree，适合编码任务。

**Dispatcher（调度器）**是长驻循环，默认每 60 秒执行一轮：回收过期 claim → 检测崩溃的 worker → 提升 ready 任务 → 原子认领 → spawn 分配的 profile。它运行在 Hermes Gateway 进程内部，不需要单独管理。

人类如何介入 Agent 的工作过程

Kanban 和纯自动化批处理的根本区别在于，它在工作流的每个阶段都留了人类介入的入口。

入口控制（Triage）：任务可以创建在 triage 状态，相当于一个"停车场"。你可以先审视任务描述是否清晰、拆解是否合理，再决定是否推进到执行队列。

执行中阻塞（Block/Unblock）：Worker 在执行过程中遇到需要人类判断的决策时，会调用 kanban_block 主动暂停。例如翻译任务中遇到专业术语需要确认，或者技术方案需要你选择方向。你做出决策后通过 unblock 解除阻塞，worker 继续执行。

持续评论（Comment）：你随时可以往任务线程中追加评论，比如"请用中文写作，控制在 3000 字以内"或"这个方向不对，请参考 X 的做法"。Worker 下次被调度时会读取这些评论。

产出审查（Runs）：每次执行尝试都记录在 task_runs 表中。你可以查看每次尝试的耗时、结果摘要、错误信息，不满意可以修改任务描述后重新调度。

Goal 模式的验收标准：创建任务时指定验收标准，worker 会在每轮结束后自检是否满足。写得越明确，产出越可控。

Kanban 支持哪些协作模式

Kanban 不是一种固定的编排方式，而是支持多种协作模式的基础设施。官方文档列出了九种典型模式：

模式	形状	场景示例
Fan-out	N 个同角色并行	同时调研 5 个技术方案
Pipeline	角色链式接力	采集 → 分析 → 写作 → 审查
投票/仲裁	N 并行 + 1 汇总	3 个研究员 → 1 个审查员综合
长期日志	同 profile + 共享目录 + cron	每日自动生成 Obsidian 日记
人机交互	worker block → 人类 comment → unblock	需要决策确认的任务
@mention	行内路由	在评论中 @reviewer 请求审查
线程 workspace	每个聊天线程一个独立看板	多项目并行管理
Fleet farming	一个 profile 管理 N 个对象	同时管理 50 个社交账号
Triage specifier	一行想法 → 系统展开为完整任务规格	快速捕捉粗略想法

任务如何分配给不同 Agent

Kanban 不要求必须有多个 profile。单个 profile 就能使用，此时它就是一个带持久化、可重试、可审计的工作队列。多 profile 是为了专业分工。

任务分配有三种精度档位：

手动指派：创建任务时显式指定 --assignee <profile-name>，你完全控制谁做什么。

Orchestrator 自动分配：Orchestrator agent 读取你的 profile 列表和描述，根据任务内容决定分配给哪个 profile。精度取决于 profile 描述的质量。

Auto-decomposer：triage 任务进入后，系统使用辅助 LLM 读取 profile roster，自动拆解为子任务图并路由到最合适的专家。如果 LLM 选了一个不存在的 profile，任务会 fallback 到默认 assignee。

两个入口，同一个数据库

Kanban 的设计有一个重要的架构选择：它有两套操作界面，但后端共享同一个 SQLite 数据库。

Agent 通过工具调用：dispatcher spawn 每个 worker 时，自动在模型的 schema 中注入 kanban_* toolset（kanban_show、kanban_complete、kanban_block 等）。Worker 直接调用这些工具，不走命令行。这样做的好处是：无论 worker 的终端后端是本地、Docker 还是 SSH 远程，工具调用始终能访问到数据库；结构化 JSON 参数避免了 shell 引号问题；普通聊天会话零 schema 占用。

人类通过 CLI 或斜杠命令：hermes kanban create/list/show/... 或在聊天平台中 /kanban create/list/show/...。参数格式完全相同，两个入口的读写结果一致。

此外还有一个 Dashboard GUI，提供拖拽式看板界面，支持内联创建、多选批量操作、依赖编辑、实时 WebSocket 更新。

什么场景适合用 Kanban

Kanban 的适用边界可以用一句话划清：当你需要的不只是一个答案，而是一条有状态、可中断、可追溯的工作流水线时，Kanban 才值得启动。

三类任务是它的甜区：

需要多角色接力：研究 → 分析 → 写作 → 审查这种多阶段管道，每个阶段需要不同的专业能力
需要人类中途介入：翻译确认术语、调研调整方向、敏感操作需要审批
需要并行执行 + 结果汇总：N 个同类 worker 同时跑不同子任务，完成后自动触发汇总

反过来说，简单问答、一次性小任务、纯自动化无人值守流水线，用 delegate_task 或 cron 就够了，不需要 Kanban 的额外开销。

与 delegate_task 的对比

这两个能力看起来相似，但定位完全不同：

维度	delegate_task	Kanban
形状	函数调用（fork → join）	持久化消息队列 + 状态机
父子关系	阻塞等子返回	创建后 fire-and-forget
子代理身份	匿名子代理	带持久记忆的命名 profile
可恢复性	失败就失败	block → unblock → re-run；crash → reclaim
人机交互	不支持	任何时候可以 comment / unblock
每任务 agent 数	一次调用 = 一个子代理	N 个 agent 跨任务生命周期
审计追踪	上下文压缩后丢失	永久保存在 SQLite 中

一句话区分：delegate_task 是函数调用；Kanban 是工作队列，每次交接都是任何 profile 或人类可见可编辑的行。

快速上手

从聊天平台操作同样简单：/kanban create "调研 AI Agent 框架生态" --assignee researcher。

参考资料

HyperFrames 深度解析：HTML 驱动视频渲染与 Remotion 的差异化路径

Wed, 06 May 2026 07:06:39 +0800

HyperFrames 是 HeyGen 于 2026 年 3 月开源的视频渲染框架，核心定位是将 HTML、CSS 和 JavaScript 直接转换为 MP4 视频。其设计初衷并非面向传统视频编辑者，而是面向 AI 代理：让已经熟悉网页技术的 LLM 能够直接生成视频内容，无需学习专有格式或复杂的时间轴界面。

截至 2026 年 5 月初，该项目在 GitHub 上已获得约 14,800 颗 Star 和 1,400 次 Fork，最新版本为 v0.4.45。项目采用 Apache 2.0 许可证，允许无限制的商用。

HyperFrames 的核心机制

HyperFrames 的工作流可以概括为：用纯 HTML 文件描述视频的时间轴和视觉层，通过 headless Chrome 逐帧捕获，再由 FFmpeg 编码为 MP4。

创作格式：HTML + data 属性

视频合成文件是一个标准的 index.html，通过 data-* 属性定义每个元素在时间轴上的行为：

属性	作用
data-composition-id	合成唯一标识
data-start	元素出现时间（秒）
data-duration	元素持续时间（秒）
data-track-index	图层堆叠顺序
data-width / data-height	输出分辨率

动画逻辑由 GSAP、Lottie、CSS @keyframes、Three.js 等标准网页动画库驱动。HyperFrames 并不包裹这些库，而是通过 Frame Adapter 模式让它们与逐帧渲染引擎同步。这意味着：CodePen 上积累的 15 年 GSAP 动画片段，可以直接粘贴到 HyperFrames 中使用。

渲染引擎：确定性逐帧捕获

HyperFrames 使用 Puppeteer 驱动 headless Chrome，在每一帧渲染前将动画库精确 seek 到 frame / fps 对应的时间点，然后捕获画面。这种机制保证了"相同输入产生相同输出"，对自动化流水线至关重要。

渲染支持两种模式：

BeginFrame 模式（Linux + chrome-headless-shell）：原子级合成器控制，逐字节可复现
Screenshot 模式（macOS/Windows，或自动降级）：实时 Chrome + 截图，适用于包含 iframe 或原始 canvas 循环的场景

输出格式包括 MP4、MOV 和 WebM，且支持 HDR 输出。

与 Remotion 的对比

Remotion 是 HyperFrames 最直接的参照对象。两者都使用 headless Chrome + FFmpeg 的技术路径，但在创作层、目标用户和生态成熟度上存在显著差异。

创作层的根本分歧

维度	HyperFrames	Remotion
创作语言	HTML + CSS + JS	React / TSX
构建步骤	无，index.html 直接运行	需要 webpack 打包
组件复用	直接粘贴现有网页代码	复用 React 组件和设计系统
类型安全	无（纯 HTML）	有（TypeScript）

HyperFrames 的赌注是：LLM 的训练数据中有海量 HTML/CSS/JS 和 GSAP 动画，网页是它们最熟悉的创作媒介。Remotion 的赌注是：React 开发者已经习惯了组件化思维和类型安全，视频创作应该延续这一范式。

动画库兼容性

这是两者最实质的技术差异。GSAP、Anime.js、Motion One 等动画库内部使用 performance.now() 驱动自己的时钟。在逐帧渲染场景下，这种"自带时钟"的库会与渲染引擎产生冲突。

HyperFrames 的解决方案是暂停动画库的 ticker，在每一帧前精确 seek 到对应时间点。这保证了 GSAP 的 SplitText、ScrollTrigger、MotionPath 等高级功能在渲染时与预览时行为完全一致。

Remotion 没有等价的 primitive。GSAP 在 Remotion 的渲染过程中按 wall-clock 全速运行，可能导致 4 秒的动画在 1 秒内跑完，剩余帧拍到空舞台。开发者需要自行处理时钟同步问题。

分布式渲染能力

维度	HyperFrames	Remotion
单机渲染	支持	支持
分布式渲染	目前仅单机	Remotion Lambda 已成熟
渲染成本	仅本地硬件/云主机成本	Lambda 约 $0.01/分钟视频 + AWS 费用
并发能力	受单机限制	最高 200x 并发，80 秒视频 15 秒渲染完

Remotion Lambda 是压倒性优势。对于需要批量生成、高并发、低延迟的场景，Remotion 是目前唯一成熟的选择。HyperFrames 目前尚未提供分布式渲染方案。

许可证与成本

维度	HyperFrames	Remotion
许可证	Apache 2.0，完全开源商用	Source-available，3 人以下免费，4 人以上需付费
费用	$0，无渲染费，无 seat 限制	创作者 $25/月/座位；自动化 $0.01/次渲染，$100/月最低；企业版 $500/月起
隐性成本	无	团队规模超限必须升级

HyperFrames 的许可证更干净，没有"团队变大后被迫付费"的陷阱。Remotion 的收费模式对成长中的团队构成潜在的合规风险。

生态与成熟度

维度	HyperFrames	Remotion
GitHub Stars	~14,800（2026 年 3 月发布，增长极快）	~45,900（多年积累）
发布历史	95 个 release	617 个 release
贡献者	较少（HeyGen 主导）	335+ 贡献者
社区项目	50+ 可安装 block	GitHub Unwrapped、Fireship 等标杆项目
可视化编辑器	Studio（基础功能，非完整 NLE）	Remotion Studio（功能完整，与代码双向同步）

HyperFrames 很新，文档和边缘场景覆盖仍在快速迭代。Remotion 经过多年生产验证，生态更为成熟。

AI 代理集成：HyperFrames 的差异化优势

HyperFrames 并非"能被 AI 使用"，而是"为 AI 代理原生设计"。这是它与 Remotion 最显著的定位差异。

专用技能包

HyperFrames 为 Claude Code、Cursor、Codex、Gemini CLI 等代理提供了结构化技能包：

安装后，代理可直接调用 /hyperframes（合成创作）、/hyperframes-cli（开发循环）、/hyperframes-media（TTS、转录、抠图）、/gsap（动画模式）等技能。这些技能将框架规则编码为代理可执行的指令，降低了"代理写错框架 API"的概率。

Remotion 虽然提供了 AGENTS.md 和 CLAUDE.md 等提示文件，但没有等价的结构化 skill 体系。

为什么 HTML 更适合代理

LLM 的训练数据包含数十亿网页和大量 GSAP、SVG、Canvas、Lottie 实验。网页是它们训练数据中最大的创作媒介。让代理写 HTML，相当于让它们使用最熟练的工具。而 Remotion 的 useCurrentFrame()、useVideoConfig() 等 API 是专有概念，代理需要额外的学习成本。

此外，HTML 文件可以直接在浏览器中打开预览，代理可以立即看到效果并迭代。Remotion 需要等待构建完成，调试链路更长。

适用场景与选型建议

场景	推荐选择	理由
AI 代理自动生成视频	HyperFrames	技能包深度集成，HTML 低门槛，无构建步骤
已有 React 设计系统	Remotion	直接复用组件，类型安全，IDE 支持好
分布式/批量渲染（>100 视频/天）	Remotion	Lambda 是唯一成熟方案
对许可证敏感	HyperFrames	Apache 2.0 无后顾之忧
重度使用 GSAP/Lottie/Three.js	HyperFrames	Frame Adapter 解决时钟同步
团队有专业前端/React 背景	Remotion	生态、工具链、社区支持更成熟
快速原型/个人项目/小团队	HyperFrames	零成本，零配置，即时运行
企业级 SaaS 内置视频生成	Remotion	分布式渲染 + 商业支持更可靠

技术架构概览

HyperFrames 采用模块化包结构：

包名	功能
hyperframes	CLI 工具（init、preview、render、lint、add）
@hyperframes/core	类型、解析器、linter、运行时
@hyperframes/engine	Puppeteer + FFmpeg 逐帧捕获
@hyperframes/producer	完整流水线（捕获 + 编码 + 混音）
@hyperframes/studio	浏览器端可视化编辑器
@hyperframes/player	可嵌入的 <hyperframes-player> Web Component
@hyperframes/shader-transitions	WebGL 着色器转场效果

系统要求：Node.js >= 22，FFmpeg。支持 macOS、Linux、Windows，Docker 可选（推荐用于跨平台确定性）。

局限与风险

HyperFrames 作为 2026 年初发布的项目，存在以下已知局限：

分布式渲染缺失：目前仅支持单机渲染，大规模批量生产需要自行搭建调度系统
编辑器功能有限：Studio 不是完整 NLE，缺少 split、slip、slide、ripple、roll 等专业剪辑操作
文档仍在完善：部分边缘场景和高级用例的文档覆盖不足
社区规模较小：相比 Remotion 的 335+ 贡献者，HyperFrames 的社区仍在早期阶段
HeyGen 商业绑定风险：虽然 HyperFrames 是独立开源项目，但其发展节奏受 HeyGen 战略影响

参考来源

OpenClaw 与 Hermes Agent 全面对比：执行者还是学习者

Mon, 04 May 2026 15:57:59 +0800

OpenClaw 与 Hermes Agent 是 2026 年最受关注的两个开源自托管 AI Agent 框架。两者都支持多平台消息接入、工具调用和持久化记忆，但在核心哲学、架构设计和演进路线上存在根本差异。本文基于两者截至 2026 年 5 月的最新版本进行全面对比。

OpenClaw 最新版本为 2026.5.3（2026 年 5 月 4 日发布），GitHub 仓库 368k Stars，1,976 位贡献者，41,105 次提交。Hermes Agent 最新版本为 v0.12.0 “The Curator”（2026 年 4 月 30 日发布），GitHub 仓库 132k+ Stars，822 位贡献者，7,150 次提交。

核心哲学：执行者还是学习者

两者的根本分野在于对"Agent 应该是什么"这一问题的回答。

OpenClaw 的定位是执行者（Doer）。它是一套你配置好就能运行的工具，按照预设的技能和流程执行任务。它的性能在你配置完成的那一刻基本确定，除非你手动修改配置或技能文件，否则不会随使用时间发生显著变化。用社区中的说法来形容：“OpenClaw 用的时候什么样，以后还什么样。”

Hermes Agent 的定位是学习者（Learner）。它的核心设计围绕一个可重复的"做、学习、改进"循环展开。每次完成复杂任务后，Hermes 会提取可复用的模式，自动撰写技能文档，并在后续类似任务中调用和优化这些技能。根据 Nous Research 公开的信息，这种程序性记忆机制使得 Hermes 在重复任务家族上的执行效率在数周内可提升约 40%。

这种哲学差异直接影响了用户与 Agent 的关系：OpenClaw 更像一台你设定好程序的机器，Hermes 更像一位与你共事的队友，相处越久配合越默契。

架构设计：网关中心化还是循环中心化

OpenClaw 的网关中心化架构

OpenClaw 采用单一 Node.js 进程作为核心，会话管理、路由、工具执行和状态存储全部集中在这个进程内。其架构可以概括为：

这种设计的优势在于部署和调试极为简单。用户只需启动一个进程，所有日志集中在一处，不存在服务发现和跨容器网络的问题。对于个人用户和小团队来说，这种"一体化"体验降低了运维负担。

代价是水平扩展受限。当并发任务量增加时，无法独立扩展某个子系统，只能整体扩容。此外，所有组件共享同一地址空间，一旦某个模块出现安全漏洞，影响范围可能波及整个系统。

Hermes Agent 的循环中心化架构

Hermes Agent 将所有组件围绕 AIAgent 循环设计。根据 Nous Research 官方架构文档，其核心文件 run_agent.py 约 13,700 行，包含三个子系统：

Prompt Builder：负责系统提示词组装，内置上下文压缩和缓存机制
Provider Resolution：支持三种 API 模式（chat_completions、codex_responses、anthropic_messages）
Tool Dispatch：工具注册表管理 61 个工具和 52 个工具集

下游系统包括 SQLite + FTS5 会话存储、6 种终端后端（本地、Docker、SSH、Daytona、Singularity、Modal）、以及 19 个消息平台适配器。

这种架构下，学习循环是头等架构关切，而非事后补充。每个组件的存在都是为了服务于"观察、行动、反思、改进"这一核心流程。代价是系统复杂度更高，对用户的运维能力有一定要求。

技能系统：静态文档还是自改进程序

技能（Skill）是 Agent 框架的核心竞争力，两者的设计理念截然不同。

OpenClaw：社区驱动的静态技能

OpenClaw 的技能以自然语言 Markdown 文件（SKILL.md）形式存在，存储在 ClawHub 市场上。截至 2026 年初，ClawHub 拥有超过 5,700 个社区贡献技能，覆盖内容创作、销售自动化、数据分析、客户服务等多个领域。

这种设计的好处是门槛极低。即使不具备编程背景的用户，也能通过撰写自然语言文档来定义 Agent 的行为。技能格式直观，类似于写一份操作手册。

但静态技能有两个明显局限：一是性能不会随使用自动提升，每次执行相同任务都需要重复相同的推理过程；二是社区技能的质量参差不齐。Snyk 在 2026 年初的审计中发现 ClawHub 上存在 1,467 个恶意技能，其中 91% 结合了提示注入和传统恶意软件技术。OpenClaw 在 2026.3.22 版本中被迫引入强制性的 SkillFortify 验证机制，直接通过 GitHub URL 安装技能的功能被移除。

Hermes Agent：自改进的程序性记忆

Hermes Agent 的技能系统是其最具辨识度的特性。技能采用 agentskills.io 开放标准格式，但关键差异在于创建和改进方式：

阶段	行为
经验积累	完成复杂多步骤任务
模式提取	识别可复用的工作流模式
技能创建	自动撰写 Markdown 技能文件
技能优化	在后续使用中根据结果自我改进
定期复盘	每完成 15 个任务评估整体表现

这种机制使得 Hermes 的技能库随时间自然增长和优化。一个三月份需要多轮交互才能完成的客户服务流程，到六月份可能变成一步到位的自动化操作。程序性记忆存储的是"怎么做"而非"说了什么"，这是与简单对话历史记录的本质区别。

v0.12.0 版本进一步引入了"Curator"机制，能够自动评级和修剪技能库，防止低质量技能累积。

记忆机制：对话存档还是分层认知

OpenClaw 的记忆设计

OpenClaw 使用纯 Markdown 文件管理记忆，包括 SOUL.md（Agent 人格定义）、MEMORY.md（长期记忆）和 USER.md（用户画像）。搜索依赖 SQLite 向量数据库和关键词匹配。

这种设计的优点是简单透明，用户可以直接打开 Markdown 文件查看和编辑 Agent 的记忆内容。缺点是记忆之间缺乏结构化关联，跨会话的知识持久化需要手动配置，且没有自动的知识压缩或摘要机制。

Hermes Agent 的分层记忆架构

Hermes Agent 采用五层记忆架构：

层级	功能	存储方式
持久笔记	Agent 筛选的跨会话知识	SQLite + 文件
会话历史	可搜索的对话记录	FTS5 全文搜索
用户建模	对用户偏好的深度理解	Honcho 辩证法建模
程序记忆	可复用的技能方法	Markdown 文件
归档存储	旧会话的冷存储	SQLite

这种分层设计的核心优势在于冷热分离。高频访问的记忆（如近期技能和用户偏好）保持在活跃上下文中，低频历史记录被压缩归档，从而在不显著增加 Token 消耗的前提下实现长期记忆。v0.7.0 版本起，记忆后端还支持插拔式替换，可接入 Honcho、向量数据库或自定义存储。

安全态势：默认开放还是默认保守

2026 年 2 月的 CVE-2026-25253 是 OpenClaw 安全形象的转折点。这个 CVSS 评分 8.8 的未授权远程代码执行漏洞，导致数万个未修补的 OpenClaw 实例在补丁发布前被入侵。漏洞的根源在于 OpenClaw 的单进程架构和宽泛的默认权限：一个 HTTP 监听端点的缺陷就足以导致整个系统沦陷。

此后 OpenClaw 采取了一系列补救措施：

2026.3.22 起强制 ClawHub 插件验证，禁止直接 GitHub URL 安装
引入 AgentWard 运行时监控（eBPF 探针）
修补 CVE-2026-2847（WebSocket 劫持）等后续漏洞
2026.5.3 版本进一步强化插件安装扫描器，修复了官方捆绑插件包被误拦截的问题

但这些改进大多是事后补救。OpenClaw 的默认安全姿态仍偏向"信任单机环境"，沙箱功能默认关闭。

Hermes Agent 的设计从一开始就采用安全默认原则：

容器加固（只读根文件系统、降权运行）
五种沙箱后端可选，默认启用隔离
内置提示注入扫描
敏感数据上下文过滤
凭证文件隔离

截至 2026 年 5 月，Hermes Agent 没有公开记录的 CVE。需要指出的是，任何复杂软件都难以完全避免漏洞，Hermes 的架构优势在于隔离设计能够将单点漏洞的影响范围限制在特定模块内，而非阻止所有漏洞的发生。

功能特性逐项对比

维度	OpenClaw 2026.5.3	Hermes Agent v0.12.0
消息平台	25+	19（含 Teams、Yuanbao、QQBot、Home Assistant）
终端后端	2（本地、Docker）	6（本地、Docker、SSH、Daytona、Singularity、Modal）
内置工具	依赖技能/插件	40+
子代理	支持	隔离子代理（独立会话、终端、Python RPC）
MCP 支持	客户端	客户端 + Server 模式
定时任务	Heartbeat cron	内置 Cron 调度器
模型提供商	OpenAI、Anthropic、Google、OpenRouter	Nous Portal（400+）、OpenRouter（200+）、OpenAI、Anthropic、Gemini、Bedrock、小米 MiMo 等
RL/研究支持	无	Atropos 集成、批量轨迹生成
语音/TTS	ElevenLabs、Edge TTS、macOS 系统 TTS	支持
浏览器自动化	Playwright	Camofox（10 个浏览器工具）
本地 LLM	Ollama、llama.cpp、vLLM	Ollama、llama.cpp、vLLM
安装方式	npm install -g openclaw	brew install 或 pip install
资源需求	8GB RAM 最低	8GB RAM 最低
实时语音	支持（macOS/iOS 唤醒词 + Android 连续语音）	支持
可视化 Canvas	Live Canvas（Agent 驱动可视化工作区）	无
文件传输	文件传输插件（16MB 每轮上限，默认拒绝符号链接遍历）	内置文件工具

安装与上手体验

OpenClaw 的安装体验更接近消费级应用。运行 openclaw onboard --install-daemon 后，交互式向导会自动创建工作区、生成人格文件、配置 API 密钥并引导消息平台接入。从冷启动到可操作的 Agent 通常只需 3 到 5 分钟。

Hermes Agent 的安装对技术背景有一定要求。虽然 hermes init 提供了交互式配置，但用户仍需理解 Docker 网络、服务拓扑等概念。对于日常部署容器化系统的 DevOps 工程师来说，这种透明度和可控性是优势；对于从未配置过 .env 文件的用户，则可能构成门槛。

选型建议

使用场景	推荐选择
追求最快部署、最大集成列表和最广社区	OpenClaw
希望 Agent 随使用时间增长而变得更高效	Hermes Agent
从 OpenClaw 迁移（尤其受安全事件影响）	Hermes Agent（内置 hermes claw migrate）
完全离线运行本地模型	两者皆可
非技术背景，追求开箱即用	OpenClaw
企业级部署，需要安全隔离和可扩展性	Hermes Agent
研究人员，需要 RL 训练和轨迹数据	Hermes Agent
偏好手写 SKILL.md 的提示工程师	OpenClaw
需要实时语音唤醒和可视化 Canvas	OpenClaw

参考来源

本文信息来源于以下公开渠道：

OpenClaw 官方 GitHub 仓库 — openclaw/openclaw，368k Stars，1,976 贡献者，41,105 次提交，MIT 许可
OpenClaw 官方 Releases 页面 — 最新版本 2026.5.3（2026 年 5 月 4 日）
OpenClaw 官方文档 — docs.openclaw.ai
Hermes Agent 官方 GitHub 仓库 — NousResearch/hermes-agent，132k+ Stars，822 贡献者，7,150 次提交，MIT 许可
Hermes Agent 官方架构文档 — Nous Research，2026 年
Lushbinary: Hermes vs OpenClaw 关键差异 — 2026 年 4 月 7 日
Lushbinary: Hermes Agent 开发者指南 — 2026 年 4 月 7 日
DeployAgents: OpenClaw vs Hermes 深度对比 — 2026 年 4 月 9 日
Amir Teymoori: Hermes Agent vs OpenClaw 对比 — 2026 年
NVD: CVE-2026-25253 — 美国国家漏洞数据库

局限性与免责声明

本文基于截至 2026 年 5 月的公开信息整理。部分性能数据（如 Hermes 的 40% 效率提升）来源于项目方公开声明，未经独立第三方基准测试验证。

OpenClaw 和 Hermes Agent 都处于快速迭代期，部分特性可能在读者看到本文时已发生变化。建议在做最终决策前查阅各自的官方文档和最新发布说明。

两者均未提供企业级的零信任沙箱。对于金融、医疗等受监管行业，建议在使用前进行额外的安全评估和合规审查。

本文基于公开可获取的社区讨论和官方文档整理，不构成专业采购或安全建议。

Pi Coding Agent：一个 418 行代码的终端 AI 编码代理

Wed, 29 Apr 2026 02:07:14 +0800

Pi（全称 pi-coding-agent）是一个开源的终端 AI 编码代理（CLI coding harness），目前在 GitHub 上已获得超过 17,500 个 star，npm 周下载量峰值达 130 万。它由 Mario Zechner（知名游戏框架 libGDX 的作者，GitHub @badlogic）开发，近期在 OpenRouter 的 trending 榜单上位列第一。

核心理念：极简主义与可扩展性

Pi 的诞生源于 Zechner 对现有编码代理的不满。他在博客中写道：“Claude Code 已经变成了一艘宇宙飞船，80% 的功能我用不上。系统提示和工具每次发布都在变，破坏我的工作流。”

Pi 的哲学可以概括为：“如果我不需要它，就不会把它造出来。”

与同类工具相比，Pi 在多个维度上选择了极端的精简：

维度	Claude Code 等主流工具	Pi
核心 agent 循环	数千行代码	418 行 TypeScript
系统提示 + 工具定义	数千 tokens	< 1,000 tokens
默认工具	十几个	4 个（read, write, edit, bash）
内置功能	大而全	极简，靠扩展补全

Zechner 的核心假设是：所有前沿模型都经过大量 RL 训练，它们本身就理解什么是编码代理。 因此代理框架（harness）不需要过度指导模型，越轻量越好。

四层架构设计

Pi 采用严格的自底向上分层设计，下层对上层零依赖：

pi-ai：跨提供商上下文迁移

pi-ai 是底层的统一 LLM API，支持 15+ 提供商和 300+ 模型。它将 OpenAI Completions、OpenAI Responses、Anthropic Messages、Google Generative AI 四种协议归一化为统一的事件流格式。

其杀手级功能是跨提供商上下文迁移：你可以在一个会话中先用 Claude 思考，再切换到 GPT-4o 验证，上下文无缝携带。Claude 的 thinking traces 会自动转成 `` 标签供 OpenAI 模型读取。

pi-agent-core：418 行的双循环

这是 Pi 的核心，采用 AgentMessage（应用层）与 LLM Message（模型层）的双层分离设计：

无最大步数限制：循环一直执行到代理自己声明完成
运行时热插拔：setModel()、setTools()、setSystemPrompt() 随时生效
Steering 机制：用户可以在代理执行工具时发送"转向消息"，代理完成当前工具后立即响应，跳过剩余排队的工具调用
三层事件系统：agent / turn / message / tool 级别全流式事件订阅

pi-coding-agent：终端应用层

提供四种运行模式：

模式	用途
Interactive	完整 TUI 交互体验
Print (-p)	生成 shell 脚本并打印
JSON (–mode json)	结构化事件流，适合管道化处理
RPC (–mode rpc)	JSON protocol over stdin/stdout，可嵌入其他应用
SDK	直接嵌入 Node.js 应用

扩展性：Pi 的真正杀手锏

Pi 把"别人内置的功能"变成"你自己造或安装的扩展"，这是它与 Claude Code 等工具最根本的区别。

Extensions：TypeScript 模块，可访问工具、命令、快捷键、事件、完整 TUI
Skills：按需加载的能力包（指令 + 工具）
Prompt Templates：/name 快速展开的可复用 Markdown 提示
Pi Packages：通过 npm 或 git 分发扩展包

官方提供了 50+ 扩展示例，包括子代理、计划模式、权限门控、路径保护、SSH 执行、沙箱、MCP 集成等。

上下文工程机制

Pi 提供了多种机制来精确控制上下文：

机制	用途
AGENTS.md	项目级指令，放在 ~/.pi/agent/ 或项目目录
SYSTEM.md	替换或追加默认系统提示
Compaction	接近上下文上限时自动摘要，可自定义
Dynamic Context	通过扩展注入消息、过滤历史、RAG、长期记忆

社区定位与 Harness 效应

根据 Pawel Jozefiak 于 2026 年 4 月发布的六大 harness 横评，Pi 的定位是可塑的极简 harness。

该评测提出了一个重要的"Harness Effect"（框架效应）：同一模型在不同 harness 中表现差异可达 5-40 个百分点。例如，Claude Opus 在 Claude Code 中得分为 77%，在 Cursor 中则达到 93%。Pi 的价值在于它提供了一个高度可调、完全透明的基础，让用户自己优化这个效应。

工具	定位	特点
Claude Code	Agent Orchestrator	上下文连贯性最强，适合复杂多文件任务和夜间自主运行
Codex CLI	Coding Tool	执行干净但缺乏上下文连贯感
Aider	Coding Tool	编辑精度高，但不追求自主代理
OpenCode	中间地带	SST 团队出品，功能全面
Pi	可塑的极简 harness	轻量、透明、可深度定制

它能用来做什么

日常编码代理：替代 Claude Code/Codex CLI，在终端里完成代码生成、重构、调试
自定义工作流：通过扩展构建自己的"计划模式"、“权限门控”、“子代理协调”
嵌入其他应用：通过 SDK 或 RPC 模式把 Pi 作为引擎嵌入自有工具（OpenClaw 即采用此方案）
多模型协作：在一个任务中切换不同模型，利用各自优势
夜间自主运行：结合 steering 和 follow-up 机制，实现长时间自主任务
团队标准化：通过 AGENTS.md、Skills、Pi Packages 在团队内共享编码规范和工作流

快速上手

Pi 的安装与启动流程极为简洁。

安装

进入项目目录后启动：

添加模型（认证）

Pi 支持两种认证方式：

方式一：订阅登录

在 Pi 交互界面内执行：

然后选择提供商。内置支持 Claude Pro/Max、ChatGPT Plus/Pro（Codex）、GitHub Copilot、Google Gemini CLI 等。

方式二：API Key

启动前设置环境变量：

也可通过 /login 选择 API Key 提供商，将密钥存入 ~/.pi/agent/auth.json。

任务对话

启动后直接输入需求即可：

默认提供四个工具：read（读文件）、write（写文件）、edit（编辑文件）、bash（执行命令）。另有 grep、find、ls 等只读工具可通过选项启用。

常用操作：

引用文件：输入 @ 进行模糊搜索，或命令行直接指定 pi @README.md "Summarize this"
执行命令：!npm run lint（输出送入模型上下文），!!command（执行但不送入上下文）
切换模型：/model 或 Ctrl+L
继续会话：pi -c（最近会话），pi -r（浏览历史），/resume、/new、/tree（会话管理）
非交互模式：pi -p "Summarize this codebase"（单次输出）

项目指令

在项目根目录创建 AGENTS.md，Pi 启动时自动加载：

修改后执行 /reload 生效。

总结

Pi 不是"又一个 Claude Code 替代品"。它是一个激进的极简主义实验，证明了一个精心设计的轻量 harness 可以匹配甚至超越复杂框架。

它最适合对现有代理的"黑盒行为"感到不满的开发者，以及想要完全控制系统提示、工具、上下文流程的高级用户。如果你只是想要"开箱即用、功能最全"的体验，Claude Code 可能仍是首选；但如果你想理解并掌控代理的每一行行为，Pi 是目前最透明的选择之一。

参考来源

AI 时代的工具分层：从个人杠杆到企业系统的全景图谱

Mon, 27 Apr 2026 01:44:12 +0800

一个基本判断

AI 编程助手（Claude Code、Codex、Cursor 等）和个人 Agent 工具（OpenClaw、Hermes Agent 等）的发展速度令人瞩目。它们极大地放大了单个个体的生产能力，一个工程师借助这些工具，可以在几小时内完成过去需要几天的工作。

但这里有一个容易被忽视的分野：这些工具的本质是"杠杆"，而不是"系统"。

杠杆的作用对象是使用者本人。它要求使用者具备相应的能力，知道何时使用、如何使用、如何调试。杠杆的产出质量直接取决于使用者的判断力和经验。一把好的杠杆可以让强者更强，但对不具备基础能力的人来说，它可能反而制造混乱。

企业环境需要的不是杠杆，而是系统，能够一次部署、稳定运行、持续解决特定业务问题的可靠基础设施。系统不依赖某个特定个体的临场发挥，它的行为是可预测、可维护、可交接的。

如果把 Claude Code 或 Codex 比作一盒 LEGO 积木，什么都能拼，但前提是你会拼，那么 n8n、Dify 以及下文将要介绍的工具，就是已经设计好的解决方案骨架。它们可以被 AI 编程助手进一步组装和定制，但本身已经具备了稳定运行的基础结构。

本文的目的，是系统梳理在当前 AI 大爆发的背景下，那些能够被 AI 编程助手操控、进而产出稳定企业级解决方案的底层工具与平台。这不是一份简单的工具清单，而是一张从"个人杠杆"到"企业系统"的完整地图。

第一类：工作流编排与自动化平台

工作流编排平台是企业自动化的基础设施层。它们负责连接不同的应用、API 和数据源，按照预设逻辑执行一系列操作。在 AI 时代，这些平台的核心演进方向是：原生支持 LLM 调用、提供更长的执行超时、以及更强的状态持久化能力。

工具	开源	定位	核心特点
n8n	Fair-code	开源工作流自动化标杆	400+ 集成节点，可视化编排，支持自托管，AI Agent 节点原生集成
Node-RED	Apache 2.0	IoT 与工业自动化首选	4000+ 社区节点，制造业大规模部署验证，边缘计算友好
Activepieces	MIT	现代开源自动化平台	280+ skills 集成，TypeScript 驱动，支持嵌入第三方应用
Windmill	AGPL	极速脚本工作流引擎	执行速度为 Airflow 的 13 倍，原生支持 Python/TypeScript/Go/SQL
Trigger.dev	MIT	长时 AI 工作流专用	无超时限制，持久化执行，自动重试，支持浏览器自动化与 FFmpeg
Conductor	Apache 2.0	Netflix 级微服务编排	工作流即代码（JSON），版本控制，事件驱动架构
AutoKitteh	Apache 2.0	代码优先的自动化	原生 Python，基于 Temporal 持久化引擎，面向 DevOps/MLOps
Flowgram.ai	开源	可组合工作流框架	字节跳动开源，可视化画布 + LLM 节点 + 代码编辑器
Zapier	商业	SaaS 自动化之王	8000+ 应用集成，最易用的无代码体验
Make (Integromat)	商业	高级数据路由	可视化数据映射、迭代器、JSON 解析，适合复杂数据流
Pipedream	核心开源	开发者优先集成	Serverless 函数，npm 包支持，内置 AI 模型调用

选型建议：如果团队已有 DevOps 能力且重视数据主权，n8n 或 Windmill 是首选；如果需要连接大量 SaaS 应用且追求快速上线，Zapier 或 Make 更合适；对于需要小时级甚至天级执行时长的 AI 流水线，Trigger.dev 几乎是唯一选择。

第二类：AI Agent 构建与编排平台

Agent 平台是 AI 时代的应用开发层。它们将 LLM 的推理能力封装成可复用的组件，支持可视化构建、RAG（检索增强生成）、多 Agent 协作等高级功能。与纯代码框架（如 LangChain）不同，这些平台提供了完整的应用生命周期管理，从原型到部署到观测。

工具	开源	定位	核心特点
Dify	MIT	LLM 应用开发平台	Agent 工作流、RAG、模型管理、内置可观测性，从原型到生产
Flowise	MIT	可视化 AI Agent 构建	拖拽式 LangChain 节点，快速原型，支持嵌入式聊天机器人
LangFlow	MIT	模块化 Agent 构建	强调组件模块化与开源治理，强社区生态
LangGraph	MIT	生产级 Agent 编排	图结构工作流，LangSmith 深度观测，状态持久化与故障恢复
CrewAI	MIT	角色化 Agent 团队	角色-目标-背景故事定义，执行速度为 LangGraph 的 5.76 倍
AutoGen	MIT	微软对话式 Agent	多 Agent 对话协作，人工介入点灵活（⚠️ 2025 年 10 月起进入维护模式）
Haystack	Apache 2.0	生产级 RAG 管道	检索器-阅读器架构，2.0 支持并行分支与循环，大规模文档问答
LlamaIndex	MIT	数据连接框架	深度 RAG 原语，结构化输出，适合复杂领域应用
Letta (原 MemGPT)	MIT	长期记忆 Agent	自编辑记忆系统，跨会话持久化，Agent 可自主更新知识库
TEN Framework	Apache 2.0	实时多模态 Agent	语音/视频超低延迟，面向实时协作者与语音机器人
OpenWebUI	MIT	本地 LLM 界面	轻量级，完全私有部署，适合本地模型爱好者
Relevance AI	商业	企业 AI 劳动力	多 Agent 编排，向量存储，面向大规模企业部署

选型建议：Dify 是目前从原型到生产最平衡的选择；LangGraph 适合对控制流和可观测性要求极高的企业场景；CrewAI 在开发速度和直观性上有明显优势；需要语音/视频实时交互的，TEN Framework 是开源领域的佼佼者。

第三类：RPA + AI 融合自动化

RPA（机器人流程自动化）在 AI 时代经历了根本性升级。传统的 RPA 只能按照固定规则操作界面，而 AI 赋能的 RPA 可以理解文档内容、做出判断、处理异常情况。这一类工具特别适合与遗留系统交互，那些没有 API、只能通过界面操作的老旧系统。

工具	开源	定位	核心特点
UiPath	商业	RPA 市场领导者	AI Center 统一模型管理，任务挖掘发现自动化机会，桌面+云双部署
Automation Anywhere	商业	云原生 RPA	云优先架构，AI 赋能的 IQ Bot，强合规与治理功能
Robocorp	Apache 2.0	开发者友好 RPA	Python 驱动，开源核心，与主流 CI/CD 工具集成
Appian	商业	流程自动化平台	低代码 + RPA + AI + IDP（智能文档处理）一体化
Microsoft Power Automate	商业	Office 生态自动化	与 M365/Azure 深度集成，AI Builder 提供预训练模型

选型建议：如果企业已有 Microsoft 生态，Power Automate 是最自然的选择；如果需要处理大量遗留系统且无 API，UiPath 或 Automation Anywhere 是行业标准；对于希望用代码而非可视化方式实现自动化的团队，Robocorp 提供了更现代的开发体验。

第四类：低代码/无代码应用构建平台

低代码平台在 AI 时代的角色正在发生变化。它们不再只是让非技术人员构建简单应用，而是成为开发者快速交付内部工具、原型验证和轻量级业务系统的加速器。AI 的融入让这些平台具备了智能生成界面、自动补全逻辑、甚至从自然语言描述生成完整应用的能力。

工具	开源	定位	核心特点
Retool	核心开源	内部工具之王	JS/SQL 转换器，自定义组件，支持私有部署，“为工程师设计”
Appsmith	Apache 2.0	开源内部工具平台	18+ AI 集成，45+ 拖拽组件，Git CI/CD，企业级安全
ToolJet	GPL	可视化应用构建	60+ UI 组件，多人协作，内置数据库，非技术人员友好
OutSystems	商业	企业级低代码	AI Mentor 系统指导全生命周期，全栈开发能力
Mendix	商业	企业应用平台	Maia AI 助手，双 IDE（Web + 桌面），云原生部署
Bubble	商业	无代码 MVP 构建	可视化创建，托管包含，丰富插件生态，面向客户的产品
Microsoft Power Apps	商业	Office 生态应用	Power Fx 公式语言，Azure AD 集成，公民开发者友好

选型建议：对于需要快速构建内部管理后台和数据操作界面的团队，Retool 或 Appsmith 是首选；Appsmith 的开源属性在数据主权敏感的场景下更有优势；面向外部客户的产品 MVP，Bubble 提供了最完整的无代码路径；大型企业多应用组合和严格合规场景，OutSystems 或 Mendix 更合适。

第五类：AI 知识库与企业搜索

企业搜索是 AI 时代被低估的基础设施。当企业使用了数十个 SaaS 工具后，信息分散在各个系统中，员工每天花费大量时间寻找信息。AI 驱动的企业搜索不仅能在所有系统中统一检索，还能理解语义、生成摘要、回答具体问题。

工具	开源	定位	核心特点
Glean	商业	企业 AI 搜索领导者	100+ 应用连接器，知识图谱个性化，权限感知搜索
Guru	商业	知识管理 + 搜索	自然语言答案，持续学习优化，多应用统一搜索
Coveo	商业	AI 个性化搜索	意图检测，无代码 AI 优化，CRM/电商深度集成
Elastic	核心开源	开发者搜索工具包	多区域多云，API 优先，Elasticsearch 生态成熟
Pinecone	商业	向量数据库	实时索引，零模型训练，语义搜索基础设施
Sana	商业	AI 学习平台	语义搜索，验证答案，内容创作，企业培训
Dashworks	商业	AI 工作空间搜索	跨工具统一搜索，分布式团队信息查找

选型建议：Glean 是目前企业 AI 搜索最成熟的商业方案；如果团队已有 Elastic 基础设施，可以基于 Elasticsearch 自建语义搜索；Pinecone 是构建 RAG 应用的默认向量数据库选择；对于知识管理和培训场景，Sana 提供了更完整的闭环。

第六类：AI 数据分析与 BI 自动化

数据分析工具正在从"可视化报表"向"智能分析助手"演进。新一代工具不仅能生成图表，还能理解自然语言提问、自动发现数据异常、生成分析结论，甚至预测趋势。

工具	开源	定位	核心特点
Hex	商业	AI 原生分析平台	笔记本 + BI + AI 一体化，团队协作，深度分析
Metabase	AGPL	开源 BI	问题即查询，极易用，支持自托管，社区活跃
Apache Superset	Apache 2.0	云原生 BI	可视化丰富，SQL Lab 探索，插件生态强大
Microsoft Power BI	商业	企业 BI 标准	AI 洞察，Azure 集成，企业级治理
Tableau	商业	可视化分析领导者	深度可视化能力，AI 预测，数据故事讲述
Vanna	MIT	AI SQL 生成	自然语言转 SQL，自学习优化，业务用户自助查询

选型建议：Hex 适合数据团队需要深度分析和协作的场景；Metabase 是开源 BI 中最易用的选择；Superset 适合有数据工程能力、需要大规模云原生部署的团队；Vanna 为业务用户打开了直接查询数据库的通道，无需学习 SQL。

第七类：AI 客服与支持自动化

客服是 AI 应用最成熟的领域之一。现代 AI 客服系统不仅能回答常见问题，还能理解复杂查询、访问订单/账户信息、执行退款/改单等操作，并在必要时无缝转接人工。

工具	开源	定位	核心特点
Zendesk AI	商业	企业客服平台	AI 自动化，全渠道支持，企业级功能完备
Intercom Fin	商业	对话式 AI 客服	现代 UX，复杂查询处理，Fin AI 助手
Freshworks Freddy AI	商业	性价比客服 AI	强 AI 能力，成长型企业友好定价
Tiledesk	AGPL	开源 Agentic AI OS	自主 Agent，记忆推理，API/数据库连接
Help Scout	商业	人性化客服	AI 增强，以人为本，小型团队高接触服务

选型建议：Zendesk 适合已有成熟客服体系的大型企业；Intercom 在用户体验和现代化程度上领先；Tiledesk 是开源领域功能最完整的 AI 客服方案，适合希望自建系统的团队。

第八类：AI 营销自动化

营销自动化平台正在从"规则驱动的邮件序列"进化为"AI 驱动的全漏斗优化系统"。它们能自动进行线索评分、内容个性化、发送时间优化，甚至生成营销文案。

工具	开源	定位	核心特点
HubSpot (Breeze AI)	商业	营销自动化之王	AI 全层覆盖，CRM 深度集成，内容生成
Marketo Engage	商业	企业营销平台	高级线索评分，AI 优化，Adobe 生态
ActiveCampaign	商业	智能邮件自动化	AI 预测发送，细分自动化，客户旅程
Klaviyo	商业	电商营销 AI	预测分析，个性化推荐，Shopify 生态深度集成
Clay	商业	数据丰富 + 外联	多源数据整合，AI 个性化，销售外联
Apollo	商业	销售智能平台	AI 工作流，CRM 同步，全漏斗自动化
Instantly	商业	冷邮件自动化	邮件预热，批量发送，代理机构友好

第九类：AI 项目管理与协作

项目管理工具的 AI 进化方向是：自动分配任务、预测延期风险、生成会议纪要、推荐资源调配方案。它们从"记录工具"变成了"决策辅助工具"。

工具	开源	定位	核心特点
Monday.com	商业	运营规模化	灵活面板，镜像数据，执行仪表盘
Asana	商业	清晰目标追踪	目标到项目，利益相关者沟通，低摩擦采用
ClickUp	商业	全能工作空间	深度定制，文档，白板，产品/工程团队友好
Notion AI	商业	知识 + 项目管理	AI 写作，数据库，Wiki，知识型团队首选
Linear	商业	工程团队首选	极速体验，Git 集成，AI 工作流

第十类：AI 文档处理（IDP）

智能文档处理（IDP）是 AI 在企业落地最直接的场景之一。发票、合同、表单、报告，这些原本需要人工阅读和录入的文档，现在可以被 AI 自动分类、提取关键信息、验证数据一致性。

工具	开源	定位	核心特点
Docsumo	商业	智能文档处理	10 倍更快工作流，AI 驱动数据提取
DocuWare	商业	文档管理 + IDP	AI 上下文理解，分类提取，企业文档数字化
Appian IDP	商业	流程 + 文档 AI	低代码 + 智能文档处理，复杂业务流程
Microsoft AI Builder	商业	M365 文档 AI	预建模型，Power Platform 集成

第十一类：AI 测试与 QA 自动化

AI 正在改变软件测试的方式：自动识别 UI 变化、生成测试用例、预测缺陷高发区域、自愈因界面变动而失效的测试脚本。

工具	开源	定位	核心特点
Applitools	商业	视觉 AI 测试	Visual AI，无代码，合规测试
Testim	商业	AI 自愈测试	AI 定位元素，自维护，快速创建
Mabl	商业	ML 驱动 QA	机器学习，敏捷工作流，DevOps 集成
Functionize	商业	NLP 驱动测试	自然语言测试创建，企业级规模
Katalon Studio	核心开源	AI 测试平台	AI 测试创建，分析，全栈测试

第十二类：AI 基础设施与运维（LLMOps/MLOps）

这是最容易被忽视但最关键的一层。任何企业级 AI 解决方案都需要可观测性、模型管理、成本控制和安全治理。没有这一层，前面的所有应用都如同在黑暗中飞行。

工具	开源	定位	核心特点
Langfuse	MIT	LLM 可观测性	追踪、提示管理、评估、指标，LLM 应用调试
Weights & Biases	核心开源	MLOps/LLMOps	实验追踪，模型管理，Weave LLM 评估
MLflow	Apache 2.0	开源 MLOps	模型生命周期管理，实验追踪，复现保障
Arize AI	商业	LLM 观测平台	性能监控，问题识别，生产级保障
Kong AI Gateway	Apache 2.0	AI API 网关	令牌成本控制，语义路由，多 LLM 负载均衡
LiteLLM	MIT	统一 LLM API	多模型路由，负载均衡，成本追踪，API 统一层

核心洞察与趋势判断

基于以上梳理，可以提炼出几个关键趋势：

第一，开源正在吞噬企业自动化。 2025 到 2026 年的明显趋势是，原本闭源的企业级功能，工作流编排、Agent 构建、RAG、可观测性，正在被高质量开源方案替代。n8n、Dify、Langfuse 等开源工具的功能密度已经逼近甚至超越商业竞品。

第二，“LEGO 化"正在双向发生。 不仅是 Claude Code 在组装这些工具，这些工具本身也在变得更模块化。Skills 机制（如 OpenAI 的 Function Calling、Anthropic 的 Computer Use 等扩展能力规范）正在成为连接 AI 助手与外部系统的技术范式，被主流模型提供商广泛采纳。n8n、Zapier、Gumloop 等平台已原生支持通过 skills 与外部系统交互。

第三，可观测性从"加分项"变为"必选项”。 任何企业级 AI 解决方案都必须包含 Langfuse、W&B 或 LangSmith 级别的可观测性，否则无法在生产环境稳定运行。LLM 的不可预测性使得追踪每一次调用、每一个 token、每一个延迟成为刚需。

第四，向量数据库正在成为隐形基础设施。 Pinecone、Milvus、Weaviate 等向量数据库正在成为所有 AI 应用的默认后端，就像关系型数据库之于传统应用。没有向量数据库，RAG 和语义搜索无从谈起。

从个人杠杆到企业系统：一个实用的组合策略

理解了工具分层之后，下一个问题是如何组合使用。以下是几个典型场景的推荐组合：

场景一：快速构建内部工具

场景二：复杂业务流程自动化

场景三：AI 原生产品构建

场景四：全栈企业解决方案

结语

AI 工具市场正在经历快速分化。一端是面向个人的杠杆型工具，它们放大个体能力，但依赖使用者的判断力；另一端是面向企业的系统型平台，它们提供稳定可靠的基础设施，但需要在特定场景下进行配置和定制。

Claude Code、Codex、Cursor 等 AI 编程助手位于这两者之间：它们既是个人杠杆（帮助开发者更快写代码），也是系统构建者（帮助企业组装和定制上述平台）。

对于企业决策者来说，关键不是选择"最好的 AI 工具"，而是理解工具的分层逻辑，知道什么时候需要一把万能螺丝刀，什么时候需要一个专用解决方案。本文梳理的 12 类 60+ 系统，正是为了帮助企业在这个快速变化的环境中，找到适合自己业务场景的可靠基础设施。

本文基于公开资料整理，工具信息截至 2026 年。市场变化迅速，建议在实际选型前进行最新信息验证。

Hermes Agent 浏览器工具的用户登录实现方案

Wed, 15 Apr 2026 10:42:16 +0800

Hermes Agent 的浏览器工具将身份验证统一纳入常规的页面交互流程，并配合不同后端的状态持久化能力来完成登录态的保持。本文基于 NousResearch/hermes-agent 源码的直接分析，梳理其在处理“需要登录才能访问的网站”时的五种具体操作方案。

一、交互式自动化登录（通用方案）

这是最基础的方案，适用于所有后端。Agent 通过标准的浏览器操作链模拟人类登录：

browser_navigate(url) — 打开登录页
browser_type(ref, text) — 在用户名/密码输入框中填写内容
browser_click(ref) 或 browser_press("Enter") — 点击登录按钮或提交表单
browser_snapshot() — 确认登录是否成功（页面跳转、出现个人中心等）

在 tools/browser_tool.py 的实现中，browser_type 底层调用的是 fill 命令，会先清空输入框再键入文本，避免残留旧内容。这种方式零配置、通用性强，但面对 CAPTCHA、2FA、二维码或强反 bot 检测时容易失败。

对于需要反复访问的登录网站，Hermes 提供了跨任务保留登录态的能力，核心载体是 Camofox 后端。

Camofox 的 Managed Persistence

当环境变量 CAMOFOX_URL 指向本地 Camofox 服务器，并在 config.yaml 中启用持久化：

tools/browser_camofox_state.py 会根据当前 Hermes profile 生成一个**确定性的 ****userId**，并映射到固定本地目录（~/.hermes/browser_auth/camofox/）。Camofox 服务器收到相同 userId 时会复用同一浏览器 profile，因此 cookies、localStorage、IndexedDB 等登录状态可以跨任务保留。

在 tools/browser_tool.py 的清理逻辑中，当 managed persistence 启用时，Agent 会执行 soft cleanup——仅释放本地内存跟踪，不销毁服务端的浏览器上下文，从而确保 session cookies 得以保留。

三、JavaScript 注入（程序化身份验证）

Hermes 的 browser_console 工具支持传入 expression 参数，在页面上下文中执行任意 JavaScript（相当于 DevTools Console）。这允许 Agent 直接：

读取/设置 Cookie：document.cookie = "session_id=xxx"
操作 localStorage：localStorage.setItem('token', 'xxx')
注入 JWT 或 API Token

该能力在 tools/browser_tool.py 的 _browser_eval 中实现，Camofox 后端也提供了对应的 /tabs/{tabId}/eval REST 端点。适用于开发者已拥有用户 session token、需要跳过登录表单的场景。

四、人机协作登录

当遇到强反 bot、CAPTCHA、二维码登录或 SSO 时，Hermes 提供了两种人机协作路径，但二者的交互形态差异很大。

4.1 Camofox + VNC：实时可操作浏览器窗口

这是代码中唯一为人类用户提供了可直接点击、输入、扫码的浏览器界面的方案。

在 tools/browser_camofox.py 中，初始化时会探测 Camofox 服务器的 /health 端点。如果服务器返回 vncPort，Hermes 会将其缓存为 _vnc_url，并在每次 camofox_navigate() 调用后把该地址写入返回结果：

人类用户看到的界面：在自己的浏览器中打开 vnc_url，通常是一个 noVNC Web 客户端，显示远程桌面级别的浏览器窗口。用户可以直接点击按钮、填写表单、扫描二维码、拖动滑块完成 CAPTCHA，也可以观看 Agent 的自动化操作并随时接管。

协作流程：Agent 检测到登录或验证受阻后，会将 vnc_url 发送给用户，随后停止发送浏览器操作指令，等待用户反馈“已完成登录/验证”，再继续后续自动化。如果同时启用了 managed_persistence，用户通过 VNC 登录一次后，后续任务可直接复用该登录态。

4.2 `browser_vision`：截图回传的静态辅助

这是所有后端都可使用的通用方案，但它是单向的。Agent 调用 browser_vision 后，会将当前页面截图保存到本地，并通过 MEDIA:<path> 以图片附件形式发到聊天对话中。

用户只能看、不能点。典型 workflow 是：

Agent 操作到验证页，发现被拦截
Agent 截图并回传，用户看到例如短信验证码输入框
Agent 通过对话询问用户验证码
用户回复数字，Agent 继续用 browser_type 填入

该方案对需要人类直接操作网页元素的场景（如点击“我不是机器人”复选框、拖动拼图、扫码登录）基本无效。

五、连接已登录的现有浏览器（CDP Override）

Hermes 支持通过 BROWSER_CDP_URL 环境变量连接到一个现有的 Chrome DevTools Protocol (CDP) 端点。用户可以：

在本地启动一个普通 Chrome（带 --remote-debugging-port）
手动登录目标网站
将 Chrome 的 CDP websocket 地址交给 Hermes
Agent 直接在该已登录的浏览器实例中执行操作

在 tools/browser_tool.py 中，_get_cdp_override() 会读取该环境变量，_get_session_info() 则会创建对应的 CDP session，完全绕过本地启动和云 provider。

六、安全与防护

在 browser_navigate 的实现中，有一道针对凭据外泄的安全检查。Agent 会解码 URL 并扫描其中是否包含 API key 或 token 前缀，一旦发现即阻断导航：

这防止了 prompt injection 攻击通过导航链接将用户的敏感凭证外泄。

总结

方案	实现方式	最佳适用场景
自动化表单登录	navigate → type → click/press	普通用户名密码登录，无强反 bot
持久化 Profile/Cookie	Camofox managed_persistence	需要长期、反复访问同一网站
JS 注入 Token/Cookie	browser_console(expression=…)	已有 session token，需快速跳过登录
人机协作（VNC 实时）	Camofox 后端 + vnc_url	CAPTCHA、二维码、SSO 等复杂验证
人机协作（截图辅助）	browser_vision + 对话回传	验证码回传等轻协作
连接已登录浏览器	BROWSER_CDP_URL	用户已有登录环境，Agent 仅做后续操作

整体而言，Hermes 的登录策略 = 交互式表单填写 + 后端状态保持 + 人机协作兜底。在默认的本地 agent-browser CLI 后端和云端 Browserbase / Browser Use 后端中，代码层面并未为人类预留可直接操作的浏览器界面；若需真正的实时人机协作，Camofox + VNC 是目前代码中最完整的实现路径。

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. 独立最佳实践）以及对直连性能的敏感程度。

参考来源

Hermes Agent Docker 容器化运行完全指南

Mon, 13 Apr 2026 15:39:21 +0800

两种 Docker 交互方式

Hermes Agent 与 Docker 的交互存在两种不同模式，官方文档对此有明确区分：

在 Docker 中运行 Hermes（本文重点）：Agent 本身运行在容器内部，所有用户数据通过挂载卷持久化到宿主机。
Docker 作为终端后端：Agent 运行在宿主机，但具体命令执行在 Docker 沙箱中完成。该模式需通过 terminal.backend 配置启用。

以下讨论均围绕第一种模式展开。

快速开始：三种运行方式

1. 首次初始化（setup 向导）

该命令启动交互式安装向导，将 API 密钥写入 ~/.hermes/.env。此步骤只需执行一次。

2. Gateway 模式（后台常驻）

适用于 Telegram、Discord、Slack、WhatsApp 等消息平台的长期接入。

3. 交互式 CLI 模式

用于临时开启一个聊天会话。

持久化数据目录结构

容器内 /opt/data 映射到宿主机 ~/.hermes/，是 Hermes 所有状态的单一真相源，包含：

路径	内容
.env	API 密钥与秘密
config.yaml	所有 Hermes 配置
SOUL.md	Agent 人格/身份定义
sessions/	对话历史
memories/	持久化记忆
skills/	已安装技能
cron/	定时任务定义
hooks/	事件钩子
logs/	运行时日志
skins/	自定义 CLI 皮肤

容器化运行 vs 宿主机直接运行

容器化的主要优势

优势	说明
环境一致性	官方镜像已预装 Python、Node.js、Playwright + Chromium、ripgrep、ffmpeg、WhatsApp bridge 等全部依赖，宿主机运行则需手动配置虚拟环境与浏览器。
依赖隔离	Hermes 的 Node 版本、Playwright 浏览器二进制等不会与宿主机其他项目冲突。
无状态升级	镜像本身无状态，所有数据保存在挂载目录。升级时只需 docker pull 新镜像即可，不丢失配置。
资源可控	可通过 –memory、–cpus 明确限制容器资源，防止浏览器自动化或长任务耗尽宿主机资源。
可移植性	备份 ~/.hermes 目录后，可在任意机器上通过相同挂载命令快速恢复完整环境。
适合长期驻留	docker run -d –restart unless-stopped 非常适合将 Hermes 作为后台 Gateway 服务运行。

容器化的主要劣势

劣势	说明
并发限制	官方文档明确禁止两个容器同时挂载同一数据目录。宿主机单进程运行天然不存在此问题。
权限问题	容器默认以 root 启动，写入 ~/.hermes 的文件在宿主机可能归属 root，导致后续宿主机直接运行时遇到权限错误。
浏览器工具需额外配置	Playwright/Chromium 在容器内需要共享内存，必须添加 –shm-size=1g，否则可能崩溃。
镜像体积较大	基于 Debian 且包含完整浏览器引擎，镜像比纯 Python 环境大得多。
调试多一层	查看日志、修改代码、运行测试均需通过 docker exec 或 docker logs 操作，不如宿主机开发直接。
排查成本	若 .env 缺失或配置错误，容器会立即退出，新手需要查看 docker logs 才能定位；宿主机交互运行则能直接看到报错输出。

选择建议

优先选 Docker：追求开箱即用、快速部署、长期后台运行 Gateway，或宿主机环境复杂不愿手动配置依赖的场景。
优先选宿主机：需要频繁开发调试、对文件权限敏感、重度使用浏览器自动化且希望最小化资源开销的场景。

若计划混用（Docker 跑 Gateway + 宿主机 CLI 调试），需特别注意容器生成的文件权限问题。

两个关键实践问题

1. Gateway 前台运行时如何执行其他子命令？

容器启动命令 hermes gateway run 为前台进程。执行其他子命令有两种方式：

方式 A：对运行中的容器执行 **docker exec**（推荐）

方式 B：启动一次性临时容器

2. 容器化环境下 Profiles 是否可用？

可用，但需要显式指定 **HERMES_HOME** 环境变量。

从 hermes_constants.py 源码可以看出，Hermes 已明确处理 Docker 场景下的 profile 路径识别：当 HERMES_HOME 指向 <root>/profiles/<name> 时，系统能正确解析其根目录。

使用示例：

只要 -v ~/.hermes:/opt/data 挂载正确，profile 数据就会在宿主机持久化。entrypoint.sh 还会自动创建 home/ 子目录，使 git、ssh、npm 等子进程的配置也能落入持久卷中。

若未显式指定 HERMES_HOME，则默认使用 /opt/data，等价于宿主机直接运行 hermes（不带 -p 参数）的默认 profile 模式。

总结

Hermes Agent 的 Docker 容器化部署通过单一挂载卷实现了配置与镜像的解耦，既保留了无状态升级的优势，又确保了数据的持久化。对于希望将 Hermes 作为长期后台 Gateway 的用户，Docker 是最省心的方案。

但在实际使用中需要注意三点：

严禁同一数据目录并发挂载多个容器；
子命令优先通过 **docker exec** 执行，避免启动冲突容器；
Profiles 在 Docker 中完全支持，核心操作是通过 -e HERMES_HOME=/opt/data/profiles/<name> 显式指定路径。

如果你还在宿主机与容器化之间犹豫，可以先通过 Docker 完成 setup 向导并试用 Gateway 模式，确认稳定后再决定是否长期采用。

Ollama Cloud 套餐对比：用量、并发与选择建议

Mon, 13 Apr 2026 15:17:54 +0800

Ollama Cloud 是 Ollama 团队推出的云端模型推理服务，允许用户在不自建硬件的情况下调用开源大语言模型。与 OpenAI、Anthropic 等按 Token 计费的 API 服务不同，Ollama Cloud 采用基于 GPU 时间 的用量模型，并设置了独特的「5 小时会话限制」和「7 天周限制」双重约束。本文梳理官方定价页面的公开信息，并整合社区用户的实测经验，为正在评估该服务的开发者提供参考。

一、官方定价方案概览

根据 Ollama 官方定价页，Cloud 服务分为三个层级：

方案	月付价格	年付价格	核心定位
Free	$0	—	入门体验
Pro	$20/月	$200/年	日常生产力
Max	$100/月	—	高负载持续使用

各方案权益详情

Free（$0）

本地运行模型完全免费且无限制
云端模型访问权限
CLI、API、桌面 App 支持
数据隐私保护
无限量公共模型拉取
并发限制：同时运行 1 个云端模型

Pro（$20/月）

包含 Free 全部权益
云端并发模型数：3 个
云端用量：Free 的 50 倍
可上传并分享私有模型

Max（$100/月）

包含 Pro 全部权益
云端并发模型数：10 个
云端用量：Pro 的 5 倍（即 Free 的 250 倍）

二、用量计算方式：GPU 时间而非 Token 数

Ollama Cloud 的用量计算方式与主流 API 服务商有本质区别。

官方说明

根据官方 FAQ：

关键要点：

按 GPU 时间计费，而非固定 Token 数或请求数
模型越大、请求持续时间越长，消耗越快
短请求和命中上下文缓存的 prompt 消耗更少
随着硬件和模型架构效率提升，同等套餐未来可能获得更多可用时长

双重限制机制

云端使用受两套独立限制约束：

限制类型	重置周期	说明
Session Limit	每 5 小时	短期高频使用上限
Weekly Limit	每 7 天	长期累计使用上限

注意：本地运行模型不受上述任何限制。

三、社区实测：将 GPU 时间换算为 Token 当量

由于官方未公布具体的 GPU 时间配额，社区用户通过实际测试进行了估算。

来源说明

以下数据来自 Reddit 用户 u/nusquama 的实测帖子《Tracked my Ollama Cloud free tier usage to estimate Pro and Max quotas》（发布于 r/ollama 和 r/LocalLLaMA）：

实测观察

该用户在一次 Free 层会话中观察到：

由此推算：

Free 层 5 小时 Session 配额 ≈ 200 万 tokens 当量
Free 层 Weekly 配额 ≈ 200 万 ÷ 0.4 = 500 万 tokens 当量

应用官方倍数（Pro 50x，Max 5x Pro）：

方案	估算 5h Session 配额	估算 Weekly 配额
Free	~200 万 tokens	~500 万 tokens
Pro	~1 亿 tokens	~2.5 亿 tokens
Max	~5 亿 tokens	~12.5 亿 tokens

重要局限性与免责声明

引用该用户明确列出的警告：

关键不确定性：

模型差异巨大：同一 Token 数，使用 70B 模型可能比 7B 模型消耗多 10 倍 GPU 时间
测试样本单一：基于单次会话、单一模型的观测
动态调整：官方可能在后台调整配额而不提前通知
并发开销：同时运行多个模型时，即使不活跃也可能占用 GPU 内存

四、并发限制与请求队列

除了用量限制，Ollama Cloud 还对同时运行的云端模型数设置了硬性上限：

方案	并发模型数	超限行为
Free	1	请求进入队列，队列满则拒绝
Pro	3	请求进入队列，队列满则拒绝
Max	10	请求进入队列，队列满则拒绝

队列机制说明

根据官方文档：

这意味着：

即使使用同一模型，并发请求也会占用独立 slot
Pro 用户同时发起 4 个请求时，第 4 个会进入队列等待
队列深度有限，严重超载时直接报错

五、可用模型与功能特性

云端模型清单

Ollama Cloud 支持的主流开源模型包括：

Qwen 系列：qwen3.5（多尺寸）、qwen3-coder-next（代码专用）
Google：gemma4（多模态）
Z.ai：glm-5、glm-5.1（大参数 MoE 架构）
MiniMax：minimax-m2.7、ministral-3
Mistral：devstral-small-2
NVIDIA：nemotron-3-super

完整列表可在 Ollama Cloud 模型库查看。

功能支持

Tool Calling：支持工具的模型在上架前会经过真实 Agent 工作流测试
权重格式：使用模型提供方发布的原生权重；在现代 NVIDIA 硬件上可能启用 Blackwell / Vera Rubin 架构的加速格式（如 NVFP4）
隐私保护：Prompt 和 Response 数据永不记录、不用于训练

六、适用场景评估

适合使用的场景

方案	最佳匹配场景
Free	轻度个人使用：模型体验、小模型编码辅助、概念验证
Pro	日常工作流：较大模型调用、代码自动化、深度研究
Max	高强度持续负载：长时间 Agent 任务、多模型并发协作

不太适合的场景

超高并发生产服务：Max 仅支持 10 并发模型，超出后需排队；不适合大规模对外 API 服务
无限量云端调用：即使 Max 也有周期上限，目前不支持单独加购额度
严格数据不出境：流量可能路由至欧洲和新加坡，对「数据绝对不出境」有硬性要求的企业需审慎
需要明确 SLA：官方未公布服务等级协议（SLA）或专属企业支持通道
超大模型独占算力：未提供「独占 GPU / 专用实例」级别套餐

七、社区反馈摘要

正面评价

负面反馈

动态调整担忧

有 Reddit 帖子《Ollama Cloud: Usage limit reduction in past 24 hours》提到：

这表明配额可能动态调整，建议用户定期查看 usage dashboard。

八、如何查看实时用量

用户可在 ollama.com/settings 页面查看：

Session usage: 百分比，每 5 小时重置
Weekly usage: 百分比，每 7 天重置
重置倒计时

当用量达到 90% 时，系统会发送邮件提醒（可在设置中关闭）。

九、总结与决策参考

评估维度	Free	Pro	Max
价格	$0	$20/月	$100/月
5h Session 配额	~200万 tokens 当量	~1亿 tokens 当量	~5亿 tokens 当量
Weekly 配额	~500万 tokens 当量	~2.5亿 tokens 当量	~12.5亿 tokens 当量
并发模型数	1	3	10
适合用户	体验/轻量使用	日常开发/研究	重度 Agent/多模型协作

关键决策建议：

如果你主要使用 7B 级别小模型，Pro 的性价比可能接近社区估算值
如果你依赖 70B+ 大模型，实际可用 Token 会大幅缩水，Max 可能是唯一选择
对于需要严格 SLA、数据本地化或高并发对外服务的场景，建议对比 AWS Bedrock、Azure OpenAI 等企业级方案

十、信息来源与免责声明

官方信息来源

Ollama 官方定价页
Ollama Cloud 模型库
Ollama GitHub Issue #12532：关于通过 API 获取 usage stats 的功能请求
Ollama GitHub Issue #13728：关于在第三方工具中显示 usage 的讨论

社区信息来源

Reddit r/ollama 板块：
u/nusquama: Tracked my Ollama Cloud free tier usage to estimate Pro and Max quotas
Cloud Pro Usage Limits 讨论
Ollama Cloud: Usage limit reduction in past 24 hours
Ollama Cloud models good for coding?
Reddit r/LocalLLaMA 板块：同 u/nusquama 帖子的 crosspost
Reddit r/openclaw 板块：关于 Kimi k2.5 与 Ollama Cloud 集成的用户反馈

免责声明

本文内容基于以下材料整理：

官方公开文档：截至检索日期的最新官方定价和 FAQ 页面
社区用户实测：Reddit 等平台的用户经验分享，未经官方验证
推算数据：基于单一用户的单次测试，不具备统计学意义上的普适性

重要提示：

Ollama Cloud 的用量配额可能动态调整，官方可能在不提前通知的情况下变更限制
Token 当量换算仅供参考，实际用量因模型大小、请求模式、缓存命中率等因素差异巨大
本文不构成购买建议，具体套餐选择请结合自身使用场景和预算评估
建议在购买前通过 Free 层进行充分测试，观察实际用量消耗速度

本文最后更新：2025 年 4 月。由于 Ollama Cloud 服务可能持续迭代，建议读者在决策前查阅官方最新文档。

Anthropic Harness 设计解析：长时自主编码的多智能体架构

Sat, 11 Apr 2026 22:54:20 +0800

2026 年 3 月，Anthropic 工程团队发布了一篇题为《Harness design for long-running application development》的研究文章，系统阐述了如何让 Claude 在数小时的自主会话中完成高质量的全栈应用开发。这篇由 Anthropic Labs 成员 Prithvi Rajasekaran 主导的研究，不是发布一款新产品，而是提出了一种**多智能体编排架构（multi-agent harness）**的设计范式。本文将梳理该方案的核心概念、实现路径、开源状态与适用边界。

一、它是什么？

Harness 在此语境下指一套围绕大模型能力短板设计的编排架构，用于支撑长时运行的自主软件开发。其最终形态是一个三智能体系统：

Planner（规划者）：将用户的一句简单 prompt 扩展为完整的产品 spec 和功能清单。
Generator（生成者）：按 sprint 逐个实现功能，产出代码或设计。
Evaluator（评估者）：独立运行，扮演 QA / 评审角色，通过实际测试（如 Playwright MCP）发现 bug 和缺陷，并给出生成者可执行的反馈。

该架构受 GAN（生成对抗网络） 启发：生成者与评估者形成对抗/反馈循环，通过多轮迭代将输出质量推到单智能体难以达到的高度。

二、谁提出的？

由 Anthropic Labs 团队的 Prithvi Rajasekaran 提出并主导实验。这项工作建立在 Anthropic 此前的两个项目之上：

frontend design skill：提升 Claude 的前端设计能力；
long-running coding agent harness：让 Claude 进行多会话长时间编码。

研究人员发现，仅靠 prompt engineering 和简单的 harness 设计虽然能超越基线，但很快就会触碰到能力天花板，因此需要更系统化的多智能体架构来突破。

三、解决什么问题？

文章指出了长时自主编码中的两个核心失效模式：

1. Context anxiety（上下文焦虑）

在 lengthy tasks 中，随着上下文窗口被填满，模型会逐渐失去连贯性，甚至出现"提前收尾"的行为。Claude Sonnet 4.5 在这方面表现尤为明显。

解法：Context resets。不是简单地把前文摘要压缩（compaction），而是彻底清空上下文窗口，启动一个全新的 agent，通过结构化交接 artifact 把之前的状态和下一步任务传递给新 agent。这能给模型一个"干净 slate"，有效消除焦虑。

2. Self-evaluation bias（自我评估偏差）

当让模型评估自己的作品时，它倾向于过度自信，即使质量明显平庸也会"自信地称赞"。这在设计等主观任务中尤为致命。

解法：生成与评估分离。让独立的 evaluator agent 来评审生成者的输出。通过 prompt 调优让 evaluator 变得 skeptical（持怀疑态度），从而给生成者提供真实、可迭代的反馈。

此外，对于主观质量难以衡量的问题，研究团队将"品味"拆解为可评分标准：

Design quality：设计是否有整体感；
Originality：是否有刻意创作，而非模板堆砌；
Craft：技术执行（排版、间距、对比度）；
Functionality：可用性。

通过明确惩罚"AI slop"（千篇一律的紫渐变白卡片等），推动模型走出安全区。

四、核心价值是什么？

1. 突破单智能体天花板

文章做了一个对比实验：用同样的 prompt（做一个 2D 复古游戏编辑器），solo agent 花费约 $9、20 分钟产出的版本核心功能（游戏运行）是坏的；而 full harness 花费约 $200、6 小时产出的版本功能完整、界面更精致，还自带 AI 辅助生成功能。

2. 把"品味"变成工程约束

通过明确的设计/评分标准，让 evaluator 能稳定地评判原本主观的东西，驱动生成者迭代。

3. 支撑数小时连贯自主工作

通过 context reset + 结构化交接，harness 能支撑多 session、数小时的长任务，而不受上下文长度或模型焦虑限制。

4. 发现真实 bug

Evaluator 通过 Playwright MCP 实际点击运行中的应用、测试 API 端点和数据库状态，能发现代码层面的真实缺陷（如路由顺序错误、事件处理逻辑错误等）。

五、适合谁，不适合谁？

适合

在模型能力边界上工作的 AI 工程师：任务刚好比当前模型单独处理能力复杂一点，需要脚手架辅助。
需要产出复杂全栈应用的团队：例如需要 Claude 自主构建 DAW（数字音频工作站）、游戏编辑器等。
涉及主观质量判断的任务：前端设计、创意内容生成等，需要把"品味"编码成可迭代标准。
愿意为质量支付时间和成本的场景：高复杂度任务下，$200 换一个有核心功能的应用，远比 $9 换一个坏掉的 demo 划算。

不适合

模型已能独立搞定的简单任务

文章明确说：如果任务在模型当前能力舒适区内，harness 就是**“不必要的开销”（unnecessary overhead）**。

预算/时间极度敏感的原子任务

Solo agent 可能只需 20 分钟 / $9，full harness 可能需要 4-6 小时 / $100-200。简单任务下这个溢价不值得。

追求最低延迟、快速反馈的场景

Harness 运行周期长，不适合需要秒级/分钟级结果的场景。

模型升级后仍僵化保留的旧 harness

文章强调核心原则：“harness 中的每个组件都编码了一个关于模型无法独自完成某事的假设”。随着模型能力提升（如从 Opus 4.5 到 4.6，上下文焦虑大幅减少），原本必要的组件可能变得不再"承重"，此时应该简化 harness，而非继续维护完整复杂架构。

六、具体该如何实现？

实现 Harness 的关键不是某个单一算法，而是围绕模型短板设计编排架构。根据官方实践，关键要素如下：

1. Context Resets（上下文重置）

每个 session 启动一个全新的 Claude Agent SDK client，强制清空上下文。旧 session 的状态通过结构化文件 artifact 交接：

app_spec.txt：产品规格
feature_list.json：功能验收标准及通过状态
claude-progress.txt：工作总结和下一步指引
git commits：代码版本记录

2. Generator-Evaluator 反馈循环

Generator：负责产出；
Evaluator：独立运行，使用明确标准评分，通过 Playwright MCP 或 Puppeteer MCP 实际点击应用、截图验证 UI；
未达标时，Evaluator 的详细反馈回流给 Generator 进行下一轮迭代。

3. Sprint Contract（可选）

在 Generator 动手前，Generator 与 Evaluator 先协商一份"合同"：这个 sprint 做什么、如何验证。这能防止高层 spec 导致的实现偏差。

4. 安全沙箱与权限控制

通过 Claude Agent SDK 的 ClaudeCodeOptions 配置：

Sandbox：OS 级 bash 隔离；
Permissions：文件操作严格限制在项目目录内；
Bash Allowlist：只允许特定命令，危险命令通过 PreToolUse hook 拦截。

七、开源状态与平台依赖

开源状态：部分开源

官方开源了一个最小示例：在 GitHub 仓库 anthropics/claude-quickstarts 中，有一个 two-agent harness demo（Initializer + Coding Agent），展示了 context reset、文件交接、git 持久化、安全沙箱等基础机制。
博客中的 three-agent 高级架构目前并未作为完整开源框架发布。那篇博客更像是一份工程研究报告，分享的是设计模式与实验结果，而不是一个打包好的现成产品。
部分组件已开源：例如博客中提到的前端设计技能在 claude-code 仓库中是公开的。

平台依赖

依赖	作用
Python + claude-code-sdk	Harness 编排代码的运行基础
Node.js + npm	运行 Puppeteer MCP server 及前后端应用
Anthropic API Key	调用 Claude 模型
Puppeteer MCP / Playwright MCP	浏览器自动化验证
Git	版本控制与跨 session 状态追踪

操作系统：macOS / Linux 最自然。Windows 原生环境可能因 bash 命令兼容性存在问题，建议在 WSL2 中运行。

模型依赖：博客实验主要基于 Claude Sonnet 4.5 和 Opus 4.5/4.6。不同模型对 harness 复杂度的需求不同——Sonnet 4.5 需要 context resets，而 Opus 4.6 可以去掉 sprint decomposition。

八、总结

Anthropic 的 Harness design 不是一种现成软件，而是一种面向长时自主编码的多智能体编排设计模式。它通过 Planner + Generator + Evaluator 的分工与对抗式迭代，解决上下文焦虑和自我评估偏差问题，用 orchestration 复杂度换取单智能体无法企及的输出质量。

它的最佳适用场景是复杂度刚好超出当前模型单独能力边界的任务。对于简单任务或模型已能很好处理的场景，它是一种昂贵且不必要的 overhead。更重要的是，随着模型能力进化，harness 也需要不断被审视和简化——正如文章所言：“模型越好，原本承重的脚手架就越应该被拆除。”

参考来源

Hermes 微信集成：认证机制、配置字段与接入流程

Sat, 11 Apr 2026 13:18:51 +0800

Hermes Agent 近期新增了微信（WeChat）渠道集成支持。本文梳理其认证机制、配置字段、接入流程及主要约束，供需要将 Hermes 接入微信的用户参考。

认证机制

微信集成采用 iLink Bot API 的二维码扫码登录方式，无需 Webhook，通过长轮询（Long Polling）接收消息。认证流程在本地完成，凭据自动保存到 ~/.hermes/weixin/accounts/，后续无需重复扫码。

配置字段

字段	必填	说明
WEIXIN_ACCOUNT_ID	是	iLink Bot 账号 ID，扫码登录后自动获取
WEIXIN_TOKEN	是	iLink Bot 鉴权 token
WEIXIN_BASE_URL	否	API 端点，留空使用 iLink 默认服务地址
WEIXIN_DM_POLICY	否	私聊策略，见下方说明
WEIXIN_GROUP_POLICY	否	群消息策略，见下方说明

访问策略

私聊（DM）策略（WEIXIN_DM_POLICY）：

open：接受任何人的私聊
allowlist：仅接受白名单用户
disabled：关闭私聊
pairing：需要配对确认

群消息策略（WEIXIN_GROUP_POLICY）：

open：接受所有群的消息
allowlist：仅接受白名单群
disabled：关闭群消息（个人账号默认值）

接入流程

执行后选择 Weixin，按提示用微信手机 App 扫描终端中显示的二维码，在手机上确认登录。凭据由 hermes 自动保存，无需手动配置 token 字段。

媒体能力

适配器原生支持图片、视频、文件和语音消息。CDN 传输使用 AES-128-ECB 加密/解密，由 hermes 在内部处理，对使用方透明。

主要约束

单实例限制：同一个 token 在同一时刻只能被一个 hermes 实例使用。多实例接入需要对应多个独立账号。
群消息默认关闭：个人微信账号的 WEIXIN_GROUP_POLICY 默认值为 disabled，需要显式设置才能接收群消息。
消息自动分段：超过 4000 字的回复会按语义边界自动拆分发送。
去重窗口：5 分钟内的重复消息会被过滤，防止重复处理。

扫描版 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 自定义 AI Provider 配置方法梳理

Sat, 11 Apr 2026 03:56:24 +0800

本文整理自社区实践与底层源码 review，旨在客观呈现 Hermes 中自定义 AI Provider 的安全配置路径，并标注用户经验与代码实现之间的差异和补充说明。

用户实践中的配置流程

以下步骤来源于 Herald 的实际操作经验，描述了他总结的“安全添加第三方自定义 AI Provider”的完整流程。

第一步：准备 Provider 基本信息

在开始前，需要确认以下信息：

base url：API 端点地址
api key：访问密钥
model name：模型名称

第二步：交互式添加 custom provider

通过 hermes model 命令进入交互式向导：

填写 base url 和 模型名
api key 留空（该字段为选填项）
上下文尺寸知道可填，不知道可留空

第三步：修改配置文件中的 provider 名称

交互添加后，默认会以 base url 命名 provider。用户可手动修改 ~/.hermes/config.yaml，将名称改为更具可读性的形式。例如：

第四步：通过 credential pool 添加 api key

执行以下命令为自定义 provider 添加密钥：

底层实现中，该命令会将密钥写入独立的 credential pool 存储，而不会落入 config.yaml。这样可避免配置文件中的密钥明文泄漏风险。

第五步：重启 gateway

配置和密钥添加完成后，重启 gateway 即可生效。

底层源码视角的补充与修正

以下分析基于对 Hermes 底层代码的直接阅读，对前述流程进行验证和补充。

1. `custom_providers` 名称解析的灵活性

代码层面，model.provider 支持两种写法：

custom:kimi-plan：带 custom: 前缀的 slug，可直接定位 custom_providers 中的对应条目
custom：传统写法，此时依赖 base_url 来匹配 custom_providers

用户示例中的 provider: custom:kimi-plan 是完全符合底层预期的写法。底层在解析时大小写不敏感，且会自动将空格替换为 -，因此命名容错空间较大。

2. 上下文尺寸自动探测的完整链路

用户提到“不知道可以留空让程序自动探测”，这一点底层确实有完整支持，但探测逻辑有明确的优先级：

custom_providers 中 models.<model>.context_length 的手写配置
本地缓存 ~/.hermes/context_length_cache.yaml
models.dev / OpenRouter 元数据缓存（当 base_url 属于已知 provider 时，如 api.kimi.com）
直接探测端点 /models（对 local / ollama / vLLM / LM Studio 等特别有效）
上下文递减探测（从 128K 逐步向下尝试，直到 API 不返回上下文超限错误）
最终 fallback 到 128K

因此，留空自动探测对标准 OpenAI-compatible 端点通常有效；若端点 /models 返回格式不标准或未包含 context_length，则可能退回到 128K 默认值。

3. `hermes auth add` 的密钥存储机制

底层代码路径为 agent/credential_pool.py 和 hermes_cli/auth_commands.py：

_normalize_provider("kimi-plan") 发现匹配 custom_providers 中的名称后，将其规范化为 custom:kimi-plan
生成 PooledCredential 条目，写入 credential pool 持久化存储
运行时，runtime_provider.py 的 _try_resolve_from_custom_pool() 会优先从 pool 读取密钥

这意味着：

API key 不会进入 config.yaml
该机制天然支持多 key 轮询（fill_first、round_robin、random 等策略）

4. 关于“重启 gateway”的适用范围

需要区分运行模式：

CLI 模式：改完配置、添加 auth 后，下一次调用即生效，无需重启
Gateway 模式（作为后台服务接收 Telegram / Discord / Slack 消息）：model.provider 和 model.default 在启动时加载并缓存，因此需要重启 gateway 才能感知变更

流程对照总结

用户描述	底层验证	说明
hermes model 交互添加，不填 api key	正确	_model_flow_custom 支持此操作
手动修改 custom_providers 的 name	正确	name 可自定义，slug 为 custom:<name>
hermes auth add <provider> –api-key	正确	写入 credential pool，避开 config.yaml
留空 context_length 自动探测	部分正确	标准端点有效，非标准端点可能 fallback 128K
重启 gateway 使用	基本正确	CLI 无需重启，gateway 需要重启

额外建议

如果你已经通过 hermes auth add 将 key 存入了 credential pool，建议进一步检查 config.yaml 中是否残留有此前交互时意外写入的 api_key 字段，并予以清理，以确保配置文件中不存在任何密钥明文。

为 auxiliary 任务配置自定义 Provider 的注意事项

Hermes 的 auxiliary 系统（负责图片理解、上下文压缩、网页摘要等侧边任务）与主对话模型在读取 API Key 时的逻辑并不完全相同。

核心差异：当 auxiliary 任务使用 named custom provider 时，如果该 provider 没有显式指定 key_env，底层不会 fallback 到 OPENAI_API_KEY 或 OPENROUTER_API_KEY，而是直接发送 Bearer no-key-required，导致服务商返回 401 Unauthorized。更糟糕的是，部分 API 网关（如 SiliconFlow）在鉴权层拒绝请求之前，可能已经在网关接入层记录了输入 token 并产生计费。

因此，**只要你的自定义 provider 需要 API Key 认证，就必须在 **custom_providers** 中显式设置 ****key_env**，例如：

随后在 auxiliary 中直接引用该 provider 名称即可：

多模型配置建议

不要在 custom_providers 里为同一个 endpoint 创建多个 entry。Hermes 在解析 named custom provider 时只会命中列表里第一个匹配 name 的 entry，后续同名的 entry 会被忽略。

如果你需要为同一个 provider 配置多个模型的上下文长度，请使用 models 子字典：

model 字段（与 models 同级）不是必须的。若省略，Hermes 会 fallback 到你在 model.default 中配置的主模型，或最终使用 gpt-4o-mini。

深入解析 Hermes Agent 会话管理机制与设置技巧

Fri, 10 Apr 2026 12:20:30 +0800

会话存储架构

Hermes Agent 自动将每一次对话保存为 session，以支持对话恢复、跨会话检索和完整的历史管理。其底层采用双存储结构：

SQLite 数据库 (**~/.hermes/state.db**)：存储结构化元数据，利用 FTS5 插件实现高效的全文检索。记录内容包括 Session ID、来源平台、用户 ID、唯一标题、模型配置、系统提示词快照、完整消息历史及 Token 统计。
JSONL 转录文件 (**~/.hermes/sessions/**)：存储原始对话转录，包含详细的工具调用过程与结果。

会话来源与隔离机制

Hermes 支持多种来源（Source），包括 cli、telegram、discord、slack 等。针对不同场景，采用了不同的隔离策略：

1. 群聊隔离逻辑

在 Discord 频道、Slack 频道等共享上下文中，Hermes 默认启用 group_sessions_per_user: true。这意味着：

每个发送者拥有独立的 session 历史。
不同用户的长任务不会相互污染上下文。
中断处理和运行状态按用户隔离。

若需将群组视为一个共享的“房间大脑”，可将该项设为 false。

2. 线程隔离

在 Slack 等支持线程的平台中，线程是主要的隔离边界。在同一线程内的对话将沿用同一会话，而新线程则会开启新会话。

CLI 会话管理

1. 对话恢复

恢复最近会话：使用 hermes --continue 或 hermes -c。
按 ID 或标题恢复：使用 hermes --resume <ID/Title> 或 hermes -r <ID/Title>。

恢复时，Hermes 会显示一个紧凑的摘要面板（Recap Panel），通过颜色标识区分用户（金点）与助手（绿点），并折叠工具调用过程。可通过 display.resume_display: minimal 关闭该面板。

2. 会话命名与 Lineage

自动命名：系统在首轮交互后自动生成 3-7 个词的描述性标题。
手动命名：在 session 中使用 /title <name> 命令，或通过 hermes sessions rename <ID> <name> 修改。
自动血统 (Lineage)：当会话因上下文压缩而分裂出续篇时，标题会自动递增（如 my project → my project #2）。

3. 管理命令速查

列表：hermes sessions list (支持 --source 筛选)。
导出：hermes sessions export <file>.jsonl (支持单会话导出)。
删除：hermes sessions delete <ID>。
清理：hermes sessions prune (默认清理 90 天前已结束的会话)。
统计：hermes sessions stats。

跨会话检索：`session_search`

Hermes 内建 session_search 工具，允许 Agent 检索历史对话以找回丢失的上下文。

工作流：利用 SQLite FTS5 进行相关性排序 → 聚合 Top N 个 session → 提取匹配点前后约 100K 字符 → 调用快速摘要模型生成结果。
支持语法：支持简单关键词、精确短语 ("...")、布尔运算 (OR, NOT) 及前缀匹配 (*)。

Gateway 会话重置策略

对于消息平台会话，Hermes 提供了四种重置策略 (reset_policy)：

idle：空闲 N 分钟后重置。
daily：每天固定时间重置。
both：两者取其先。
none：永不自动重置。

在自动重置前，Agent 会获得一个 Turn 用以将重要信息保存至 Memory 或 Skills。此外，含有活跃后台进程的会话不会被自动重置。

核心配置技巧

1. 上下文压缩 (`compression`)

为了在长对话中维持性能，Hermes 采用分段压缩机制：

threshold: 设置触发压缩的上下文百分比（默认 0.50）。
target_ratio: 压缩后保留的中间内容比例（默认 0.20）。
protect_last_n: 强制保留最近 N 条消息不被压缩（默认 20）。

2. 关键配置项汇总

配置项	推荐值	作用
display.resume_display	full	恢复会话时显示历史回顾面板
group_sessions_per_user	true	群聊中按用户隔离会话，防止上下文污染
compression.enabled	true	自动压缩长对话，防止触碰模型 Context Limit
compression.threshold	0.50	达到 50% 上限时开始摘要压缩

参考来源

Hermes Agent Sessions Documentation

3 台 Dell GB10 的本地推理集群跑 Trinity-Large-Thinking

Fri, 10 Apr 2026 00:54:44 +0800

X 上的 Harrison Kinsley（@Sentdex）贴出了一套本地大模型集群：3 台 Dell GB10，每台 128GB unified memory，合计 384GB，节点之间用 200Gbps QSFP 做 mesh 互联。

他给出的当前运行结果，是 Trinity-Large-Thinking（398B）在 Q4_K_M 量化下跑到 17-18 t/s。贴文里还提到一次运行记录，速度是 17.43 t/s，耗时约 13 秒。

作者说，这套集群后面还会继续观察模型表现，也会拿来做 coding agent，并通过 Hermes 接入。

原帖信息

帐号：Harrison Kinsley
X 账号：@Sentdex
发布时间：2026-04-08
原帖链接：https://x.com/Sentdex/status/2041912383824670804

用 VPS 给 Tailscale 网络加一个稳定中继节点

Wed, 08 Apr 2026 14:42:47 +0800

用 VPS 给 Tailscale 网络加一个稳定中继节点

Tailscale 在某些网络环境下直连不稳定，默认走官方 DERP 服务器延迟又高。如果你有一台公网 VPS 已经在 tailnet 里，可以把它配置成 Peer Relay 节点，让其他设备借道它中转——延迟比 DERP 低得多，吞吐量接近直连。

本文记录实际操作过程，包括遇到的几个坑。

背景：Tailscale 的两种中继机制

DERP（Designated Encrypted Relay for Packets）是 Tailscale 的兜底中继，走 HTTPS/WebSocket，全球分布，但延迟受制于地理位置和官方服务器负载。

Peer Relay 是 v1.86 引入的新机制，用 tailnet 内的普通节点做中继，走原生 WireGuard UDP，延迟更低，吞吐量更高。连接优先级是：

也就是说，配好 Peer Relay 之后，Tailscale 会在直连失败时优先走它，而不是绕到 DERP。

前提条件

VPS 已加入 tailnet（tailscale up 过）
Tailscale 版本 >= 1.86（tailscale version 确认）
云厂商安全组能放行 UDP 端口

本文使用的 VPS 是阿里云，在 NAT 后面（eth0 是内网 IP，公网 IP 通过安全组映射）。

第一步：允许当前用户免 sudo 操作 tailscale

tailscale set 默认需要 root，先设置一次免 sudo：

后续所有 tailscale set 命令都不需要 sudo 了。

第二步：开启 Peer Relay 并广播静态端点

--relay-server-port 指定监听的 UDP 端口，--relay-server-static-endpoints 告诉其他节点去哪里连接这台中继。

坑：如果后续执行了 tailscale up（比如打标签），这两项配置会被重置，需要重新执行上面两条命令。

验证配置是否生效：

输出应包含：

验证 tailscaled 是否在监听：

第三步：开放安全组端口

在云厂商控制台，给 VPS 的安全组添加入站规则：

协议	端口	来源
UDP	40000	0.0.0.0/0

VPS 本地防火墙（iptables/ufw）通常不需要额外配置，tailscaled 会自己处理。

从本机验证端口是否可达：

第四步：配置 ACL 授权

Peer Relay 需要在 tailnet 的访问控制策略里明确授权。进入 Tailscale 管理后台 → Access Controls，在 JSON 编辑器里做两处修改：

1. 添加 tagOwners（取消注释并填入）：

2. 在 grants 里新增一条：

保存即生效。

第五步：给 VPS 打标签

坑：tailscale set 没有 --advertise-tags 参数，必须用 tailscale up：

打完标签后，节点归属会从用户账号变为 tag，在 tailscale status 里显示为 <your-vps>.xxx.ts.net 而非 user@，这是正常现象。

注意：tailscale up 会重置 relay 配置（见第二步的坑），打完标签后需要重新执行：

验证效果

在另一台设备上 ping VPS 节点：

正常输出：

可以看到连接路径的协商过程：第一跳先通过 DERP，接着切换到 Peer Relay（延迟从 1.89s 降到 269ms），最终升级为直连。

总结

整个配置归纳为几个关键点：

tailscale set --operator=$USER 免 sudo
设置 relay port 和 static endpoints
安全组放行 UDP 端口
ACL 里添加 tagOwners 和 relay grants
tailscale up --advertise-tags=tag:relay-server 打标签
打标签后重新设置 relay 配置（因为 tailscale up 会重置）

配置完成后 Tailscale 会自动在合适时机走 Peer Relay，不需要任何客户端改动。

2026-04-08 主题挖掘

Wed, 08 Apr 2026 01:39:32 +0800

JuiceFS 开源社区核心痛点与主题挖掘报告

报告日期: 2026-04-08

数据来源: GitHub Issues & Discussions (非官方渠道)

聚焦范围: JuiceFS 开源社区版

一、元数据引擎选择与对比

1.1 SQLite vs Redis（单节点场景）

来源: GitHub Discussion #5037

原始 Issue: “For single node usage, is SQLite comparable with Redis?”

作者: @shinebayar-g

时间: 2025-01-27

用户反复询问单节点场景下 SQLite 是否能替代 Redis，以及性能差距多大。

Redis 内存占用痛点

来源: GitHub Discussion #2574

原始内容: “Only 9149 inodes consume 1 GB of Redis memory, is this normal?”

作者: @zhiqiangxu

用户反馈仅 9149 个 inode 就消耗了 1GB Redis 内存，对 Redis 内存效率表示担忧。

Redis Enterprise Cloud 限制

来源: GitHub Issue #6850

标题: “Update Juicefs Redis Metadata Engine to support a generic prefix”

作者: @gtratnack-alteryx

时间: 2026-04-07

原始内容:

用户希望迁移到 Redis Enterprise Cloud，但其不支持非零 DB，导致多文件系统隔离成为问题。

1.2 TiKV 的复杂性与问题

高并发小 IO 写场景告警

来源: GitHub Issue #6812

标题: “JuiceFS高并发大文件小IO写场景下持续输出get timestamp too slow告警”

3 节点集群、25Gb 网络、TiKV 7.3 集群环境下，高并发小 IO 写场景持续触发 TSO 获取延迟告警。

TiKV 部署困难

来源: GitHub Discussion #2307

标题: “tikv as kv storage error”

作者: @lddlww

用户反馈 TiKV 环境配置困难，tiup playground 报错。

CephFS vs JuiceFS+TiKV 性能对比

来源: GitHub Issue #6789

标题: “performance vs cephfs”

作者: @chenjie4255

用户实测 CephFS 架构 vs JuiceFS+FUSE+TiKV 架构性能差距大。

二、Windows 客户端的严重问题

2.1 文件共享/句柄死锁（Critical）

来源: GitHub Issue #6691

标题: “Windows: Opening two file handles to the same file hangs indefinitely (FileShare / dwShareMode)”

作者: @kenaroik

时间: 2025-10-16

原始内容:

影响评估: 28 个测试中 24 个挂起，JuiceFS 对 .NET 应用几乎不可用。

用户结论: “This makes JuiceFS unusable for .NET applications that rely on Windows file sharing semantics.”

2.2 权限/所有权问题

来源: GitHub Issue #6092

标题: “Windows: incorrect ownership”

作者: @TiptenBrink

时间: 2025-05-02

原始内容:

Workaround 限制: 必须以 Administrator + –as-root 挂载，但不实用。

2.3 修改时间（mtime）丢失

来源: GitHub Issue #5700

标题: “在Windows上复制文件后，源文件的修改时间没有应用到目标文件”

作者: @frostwind

时间: 2025-09-25

原始内容:

根因分析: 用户已定位到代码层面——异步写入导致 mtime 被覆盖。

三、小文件性能问题（社区版核心痛点）

3.1 与竞品对比

vs rclone

来源: GitHub Issue #5524

标题: “for many smaller files, juicefs is slower than rclone”

作者: @lddlww

时间: 2025-08-21

测试数据:

vs NFS

来源: GitHub Discussion #1984

标题: “How to tune JuiceFS to deal with ’excessive’ amount of small files”

作者: @solracsf

测试数据:

3.2 Java/Maven 构建场景

来源: GitHub Issue #6556

标题: “mvn package slow”

作者: @YunhuiChen

时间: 2025-12-16

测试数据:

场景	时间	对比本地盘
本地盘	240s	-
JuiceFS 无缓存	666s	慢 170%
JuiceFS 写缓存	458s	慢 90%
JuiceFS 写缓存+元数据缓存	418s	慢 45%

核心问题: “元数据缓存似乎不生效，仍有大量元数据访问”

3.3 Zip 操作极慢

来源: GitHub Issue #6813

标题: “[Linux] Zip operations are extremely slow in juicefs directory”

作者: @zhijian-pro

时间: 2026-04-02

原始内容:

四、数据一致性与可靠性担忧

4.1 元数据丢失风险

来源: GitHub Discussion #690

标题: “Can juicefs recover from lost metadata? E.g. if redis is gone?”

作者: @SvenDowideit

原始内容:

这是生产环境评估中的核心担忧。

4.2 多客户端并发问题

并发 rename + open 导致文件进入 trash

来源: GitHub Issue #6395

标题: “file created by open(O_CREAT) ends up in trash due to concurrent rename”

作者: @panda2134

时间: 2025-08-22

原始内容:

数据丢失风险: 文件被创建在 trash 中，可能被清理导致数据丢失。

删除后无法重新创建同名文件

来源: GitHub Issue #6396

标题: “file cannot be recreated after being deleted by another client”

作者: @panda2134

时间: 2025-08-22

4.3 Prometheus 数据损坏

来源: GitHub Issue #6625

标题: “prometheus WAL data corruption in segment! 发现了数据不一致问题”

作者: @mucheng380-bot

时间: 2025-11-06

原始内容:

根因分析: Prometheus 文档明确指出非 POSIX 兼容文件系统不受支持。

五、S3 Gateway 问题

5.1 兼容性

AWS SDK v2 不兼容

来源: GitHub Issue #6489

标题: “The gateway is incompatible with the new AWS SDK v2”

作者: @chenjie4255

时间: 2025-09-10

原始内容: “When calling delete objects, it returns api error MissingContentMD5: Missing required header for this request: Content-Md5.”

CONDITIONAL WRITE 不支持

来源: GitHub Issue #6724

标题: “s3 gateway does not support CONDITIONAL WRITE”

作者: @zhijian-pro

时间: 2025-10-24

5.2 性能

PostgreSQL 死锁

来源: GitHub Issue #6778

标题: “PostgreSQL deadlocks during doFlushStats under concurrent S3 gateway usage”

作者: @chenjie4255

时间: 2026-01-08

原始内容:

六、缓存与写入问题

6.1 writeback 模式问题

升级问题

来源: GitHub Issue #6840

标题: “Upgrading from a writeback mount to a non-writeback mount smoothly requires uploading the cached data”

作者: @YunhuiChen

时间: 2026-04-07

原始内容: “The data remains in the cache disk and will not be uploaded to S3”

sync 残留问题

来源: GitHub Issue #6838

标题: “sync: delete-dst fatal”

作者: @YunhuiChen

时间: 2026-04-07

6.2 缓存清理

来源: GitHub Discussion #3905

标题: “How to manually clean up jfsCache folder?”

作者: @0mza987

用户困惑如何手动清理缓存目录。

内存占用

来源: GitHub Issue #6803

标题: “scanCached时同步对expireCache进行清理”

作者: @YunhuiChen

七、建议的视频/文章选题

优先级	选题	理由	核心来源
🔥 高	SQLite vs Redis：单节点 JuiceFS 元数据引擎选型实测	社区反复询问，你认可的价值主题	Discussion #5037
🔥 高	Windows 下 JuiceFS 的坑与 Workaround	大量严重 Bug，.NET 用户痛点	Issue #6691
🔥 高	JuiceFS 小文件性能优化实战	与 rclone/NFS 对比，Maven 构建场景	Issue #5524
🔥 高	JuiceFS 数据可靠性：元数据丢失能恢复吗？	用户核心担忧，生产环境关键问题	Discussion #690
中	TiKV 元数据引擎：值得吗？	性能问题、部署复杂度、告警困扰	Issue #6812
中	JuiceFS S3 Gateway 兼容性测试	AWS SDK v2、MinIO CVE、死锁问题	Issue #6778
中	写缓存（writeback）模式的风险与正确使用	数据丢失风险、升级陷阱	Issue #6840

八、参考链接汇总

具体 Issue/Discussion 页面

主题	链接
SQLite vs Redis 讨论	Discussion #5037
Redis 内存占用讨论	Discussion #2574
Redis Enterprise Cloud prefix 支持	Issue #6850
TiKV TSO 告警问题	Issue #6812
TiKV 部署错误	Discussion #2307
CephFS vs JuiceFS 性能	Issue #6789
Windows 文件句柄死锁	Issue #6691
Windows 权限问题	Issue #6092
Windows mtime 问题	Issue #5700
rclone 性能对比	Issue #5524
小文件调优讨论	Discussion #1984
mvn package 慢	Issue #6556
Zip 操作慢	Issue #6813
元数据恢复讨论	Discussion #690
并发 rename 问题	Issue #6395
删除后重建问题	Issue #6396
Prometheus 数据损坏	Issue #6625
AWS SDK v2 不兼容	Issue #6489
CONDITIONAL WRITE 不支持	Issue #6724
S3 Gateway 死锁	Issue #6778
writeback 升级问题	Issue #6840
sync 残留问题	Issue #6838
jfsCache 清理	Discussion #3905
scanCached 内存优化	Issue #6803

报告生成时间: 2026-04-08

数据收集范围: GitHub juicedata/juicefs 仓库 Issues & Discussions (最近活跃)

API Key 不应该放在 shell 配置文件里

Tue, 07 Apr 2026 03:11:16 +0800

API Key 不应该放在 shell 配置文件里。这是很多开发者都有的习惯，图省事，但风险被长期低估。

最近一次操作失误让我意识到这个问题：一条命令找不到目标文件，fallback 执行了 env，把整个终端环境变量打印出来，十几个 API key 直接进了 AI 对话的上下文，不得不全部轮替。

事故很小，但揭示了一个结构性问题：把 key 放在 shell 配置文件里，意味着它们始终暴露在所有子进程、所有工具的视野里。

为什么 shell 配置文件不适合存 API key

不同的 shell 有不同的配置文件，但都面临同样的问题：

zsh：~/.zshrc、~/.zprofile
bash：~/.bashrc、~/.bash_profile、~/.profile
fish：~/.config/fish/config.fish

在这些文件里写 export API_KEY=xxx，后果是：

每个终端会话启动就自动加载，任何子进程都能读到
env、printenv 等命令随时能看到明文
AI 工具、日志收集、调试输出都可能意外捕获
一旦配置文件被同步到 dotfiles 仓库，直接公开

根本问题是：key 的生命周期远长于它实际被用到的时间。

更好的方式

方案一：项目级 `.env` + 精确注入

最轻量的改进。每个项目只放自己用到的 key，通过脚本精确提取，不污染全局环境。

run.sh 示例：

优点：简单，无依赖，适用于所有操作系统。

缺点：key 仍然明文存在磁盘。

方案二：macOS Keychain

系统级加密存储。key 加密保存在 Keychain 里，只在被读取的瞬间解密到内存，cat、grep、env 全都看不到。

存入：

在脚本里读取：

使用体验： 开机登录 Mac 时系统 Keychain 自动解锁，整个会话期间脚本可以直接读取，不需要输密码。第一次访问某个条目时系统会弹一次授权框，点"始终允许"后就再也不会弹了。

这是替代 shell 配置文件存 key 的最直接方案，对工作流几乎没有影响。macOS 独有，Linux 和 Windows 有各自的等效方案（secret-tool、Windows Credential Manager）。

方案三：Bitwarden CLI（私有部署）

如果你有 Bitwarden 实例（包括私有部署的 Vaultwarden），可以用官方 CLI bw 在脚本里动态拉取 key。

配置私有部署地址：

登录并获取 session：

Session 在当前终端会话内有效，关闭终端后失效，不会持久暴露。

在脚本里读取指定条目：

bw get password 按条目名称检索，返回该条目的 password 字段。也可以用 bw get notes 获取备注字段，适合存储格式复杂的 key。

适合的场景： 多台设备共用同一套 key，或者需要跨平台（macOS/Linux/Windows 都支持）。key 集中在 Bitwarden 管理，换设备只需重新登录，不用手动迁移 .env 文件。

迁移建议

如果你现在 shell 配置文件里有大量 export KEY=xxx：

按项目整理，每个项目建一个 .env，只放该项目用到的 key
高价值凭证（数据库密码、支付相关）迁移到 Keychain 或 Bitwarden
把 shell 配置文件里的 export KEY= 全部删掉
确认 .env 文件加入了 .gitignore

不需要一次做完。先把最敏感的几个迁走，剩下的项目用到哪个迁哪个。

总结

方案	明文落盘	跨平台	跨设备	依赖
shell 配置文件	✓（危险）	✓	需手动同步	无
项目 .env	✓	✓	需手动同步	无
macOS Keychain	✗	✗	✗	系统内置
Bitwarden CLI	✗	✓	✓	bw CLI

没有完美方案，但任何一个都比 shell 配置文件好。最实用的起点是：**清空配置文件里的 key，改用项目级 ****.env**，高价值凭证再逐步迁到 Keychain 或 Bitwarden。

Kimi Code 接入 OpenClaw：关键配置备忘

Sun, 05 Apr 2026 07:01:31 +0800

Kimi Code 是月之暗面推出的 Coding Plan 订阅服务，基于 Anthropic 协议提供 API 接口。如果你已经订阅了 Kimi Code，可以通过以下方式将其接入 OpenClaw。

核心信息

Endpoint: https://api.kimi.com/coding/
协议: Anthropic Messages API（非 OpenAI 兼容）
模型名: kimi-for-coding
上下文窗口: 256K tokens
最大输出: 64K tokens
多模态: 支持（基于 K2.5，可处理图片等视觉输入）
API Key: 在 Kimi Code 控制台的 Coding Plan 页面生成，用量也在同一页面查看

OpenClaw 配置示例

在 OpenClaw 配置文件中添加以下 provider：

配置说明：

将 API Key 设置为环境变量 KIMI_CODE_API_KEY，值为 Coding Plan 页面生成的 key
api 必须为 anthropic-messages，走 OpenAI 兼容路径会报 403 或 404 错误
cost 设为 0 是因为 Coding Plan 走订阅制而非按 token 计费
input 包含 text 和 image，表示支持多模态输入

注意事项

OpenClaw 部分版本可能存在工具调用（tool_call）兼容性问题，如遇调用链断裂可关注版本更新
Kimi Code 官方明确允许在 Claude Code 和 Roo Code 中使用；接入 OpenClaw 属于"非官方支持产品"，存在被判定为滥用的风险，请自行评估

适用场景

适合已有 Kimi Code 订阅、希望在 OpenClaw 中复用额度的用户。如果你还没有 Kimi Code 订阅，需要先在 kimi.com 开通会员套餐。

更新说明：provider 名称从 kimi-code 改为 kimi-plan，避免与 OpenClaw 内置名称冲突。