上一篇部署了雷池 WAF（Web 应用防火墙），大部分恶意请求在到达应用之前就被自动挡住了。

但 WAF 不是万能的。

攻击者会不断变异 payload（攻击载荷），用 WAF 没见过的新手法绕过检测。

雷池的语义分析引擎很强，但新型攻击和精心构造的变异请求仍然可能漏过。

我在网关日志里确实看到了一些 WAF 放行但明显有问题的请求。

光靠 WAF 被动防御不够，得有一道主动的监控层，把 WAF 漏掉的东西捞回来。

从手动排查到自动化

最开始的做法很原始：每天打开网关日志，人工筛查可疑请求，发现漏网的就在雷池控制台手动加规则。

流量小的时候还能应付，但随着业务线增多，每天几千条请求里混着上百个不同 IP 的扫描，手动处理根本追不上。

试过几个方案都不理想，分两个维度看。

先说日志来源。

ELK 太重，小服务器跑不动，规则维护成本高。

阿里云 SLS 成本也不小，每次拉数据都很慢。

再说恶意分析。

纯 AI 分析把所有 IP 都丢给大模型，效果不错但太慢太贵。

最终想通了一件事：大部分攻击模式是重复的，规则能判定的就不该劳烦 AI。

方案定型为六个阶段的管道：网关日志采集 → 规则预分类 → AI 分析 → 写入雷池 WAF → 飞书报告 → 规则自学习。

日志采集：全量数据的源头

管道的第一步是拿到全量请求日志。

没有用到 ELK 或阿里云 SLS，而是直接读取服务器本地的网关日志文件。

网关按小时轮转日志，格式是标准的 nginx combined 风格，每条记录包含客户端 IP、请求方法、路径、状态码、UA、Referer 等字段。

采集器通过 SSH 到网关节点读取日志文件，用正则逐行解析，按 IP 聚合访问路径、状态码、UA 等信息，输出结构化 JSON 供后续阶段使用。

相比 SLS 的条数限制和查询延迟，本地日志是全量的，每小时少则上千条多则数千条，一条都不漏。

规则预分类：AI 的减负关键

这是整套系统最重要的设计。

互联网上的扫描器套路高度固定，有人用 sqlmap 测注入，有人用 gobuster 暴力扫目录，有人直接访问 wp-admin 后台。

这些模式用规则就能精准识别，不需要 AI 来判断。

预分类器对每个 IP 给出三种判定。

规则明确判定正常的标记为 clean，直接跳过。

规则明确判定攻击的标记为 malicious，直接提交封禁。

规则无法判定的标记为 unknown，才交给 AI 做最终判断。

内置规则覆盖三大维度。

UA 维度识别扫描工具，zgrab、sqlmap、nikto 这些一听就不是正经浏览器。

路径维度识别敏感文件探测、CMS 后台扫描、Webshell 入口。

行为维度识别极短 UA、高 404 比例、CLI 工具探测后台路径等异常模式。

实际效果很显著。

1 小时内 104 个 IP，规则直接判定 61 个正常加 1 个恶意，只有 42 个交给 AI 分析，负载降低近 60%。

AI 只处理模糊情况

WAF 漏过的、规则也判不了的灰地带，才轮到 AI 出场。

比如某个 IP 用正常浏览器 UA 访问了几个 404 页面，但也碰了一下 admin 路径，说不清是迷路的真实用户还是低调的扫描器，就丢给大模型判断。

调用 DeepSeek 把 IP 的访问路径、UA、状态码、归属地发给模型，让它给出判定。

AI 判定中内置了大量误报规避逻辑，避免把正常用户误杀。

这些逻辑是被误报教训过几次后逐步加上去的，不是一开始就有的。

回写雷池 WAF：让防火墙越用越强

判定为恶意的 IP 和攻击模式，最终都通过雷池 OpenAPI 回写到 WAF 的自定义规则里。

这是整套系统的核心思路：WAF 漏掉的东西，找到之后再喂回给 WAF。

这样下次再遇到之前漏掉的恶意 IP 就直接在 WAF 层面拦截了。

回写前有多道安全检查，防止误封正常用户和业务流量。

每轮处理完自动生成安全报告，通过 lark-cli 推送到飞书群。

如果某次误封了，在雷池控制台删掉对应规则即可，也可以把 IP 写入白名单文件做预处理。

规则自学习：越用越聪明

本轮处理完成后，从 AI 的分析结果中提取新的攻击模式，通过雷池 OpenAPI 写入 WAF 规则库。

逻辑很简单：这轮 AI 判定某 IP 是攻击，就提取它的路径模式和 UA 特征，自动创建为雷池 WAF 的自定义规则。

下轮同样的攻击直接被 WAF 拦截，不再需要管道介入。

比如 AI 发现有人用变异 payload 探测某个接口，自动提取特征写入 WAF 规则。

下次再有类似请求，WAF 直接拦截，管道连看都不用看。

随着运行次数增加，WAF 的规则越来越丰富，漏过的攻击越来越少，整个系统越来越强。

定时运行

每小时通过 cron 执行一次完整的六阶段流程。

也支持单独运行某个阶段做调试，比如只采集日志看看数据量，或者只跑分类器看看判定分布。

整个管道用 Hermes Agent 编排，放在安全专用的 profile 下面，脚本之间通过 JSON 文件传递数据，互不耦合。

你的业务有没有做过主动安全防御？

评论区聊聊你的方案。

上次博客评论区被植入恶意代码，虽然做了应急处理，封 IP、删评论、修复模板漏洞，但总觉得不够踏实。

攻击者换个 IP 就能再来，每次手动封太被动了。

我需要一个能自动拦截恶意请求的防火墙，在攻击到达应用之前就把它挡在外面。

调研了一圈，选了长亭科技的雷池 WAF（Web 应用防火墙），社区版免费，功能够用，还能和我现有的 APISIX 网关集成。

这篇文章记录完整的部署和集成过程。

雷池是什么

雷池（SafeLine）是长亭科技开源的 Web 应用防火墙，社区版完全免费。

它的核心是语义分析检测引擎，不是简单的正则匹配，而是真正理解 HTTP 请求的内容，误报率低，拦截准。

能防的东西很多：SQL 注入、XSS 跨站脚本攻击、代码执行、目录遍历、文件上传攻击，还有 CC 攻击防护和 Bot 机器人防护。

对我的一人企业场景来说，社区版的能力已经够用了。

手动部署雷池

雷池推荐 Docker 部署，官方提供一键安装脚本，但如果你和我一样喜欢掌控每个配置细节，走手动部署更合适。

前提是服务器已经装好 Docker，版本不低于 20.10.14，Docker Compose 不低于 2.0.0。

创建安装目录：

1
2

mkdir -p "/data/safeline"
cd "/data/safeline"

下载 Docker Compose 编排脚本：

1

wget "https://waf-ce.chaitin.cn/release/latest/compose.yaml"

创建环境变量配置文件 .env，写入以下内容：

1
2
3
4
5
6
7
8
9
10

SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD=your_password  # 自定义密码，数字加英文大小写
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=swr.cn-east-3.myhuaweicloud.com/chaitin-safeline
ARCH_SUFFIX=
RELEASE=
REGION=
MGT_PROXY=0

几个要点。

ARM 架构的服务器需要把 ARCH_SUFFIX 改成 -arm。

海外服务器建议把 IMAGE_PREFIX 改成 chaitin，直接从 Docker Hub 拉镜像。

国内服务器保持默认的华为云镜像源就行。

启动雷池：

1

docker compose up -d

容器启动后，浏览器访问 https://服务器IP:9443 就能看到雷池控制台。

首次访问会提示证书不安全，点继续即可。

PS：由于我服务器并没有放开9443端口，需要通过APISIX网关来暴露雷池控制台了，配置参考如下：

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

{
    "uri": "/*",
    "name": "waf",
    "host": "your-waf-domain",
    "plugins": {
        "proxy-rewrite": {
            "headers": {
                "X-Forwarded-For": "$remote_addr",
            }
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:9443": 1
        },
        "tls": {
            "verify": false
        },
        "scheme": "https"
    }
}

另外首次访问还需要执行命令： docker exec safeline-mgt resetadmin 获取管理员密码。

切换检测引擎为 TCP 模式

到这里雷池已经能独立工作了，可以直接在控制台添加站点进行防护。

但我的架构里前面有一层 APISIX 网关，需要把雷池的检测引擎接入 APISIX，让所有请求先过雷池再转发到后端。

问题是雷池检测引擎默认用 Unix Socket 提供服务，只能在容器内部调用。

要和 APISIX 集成，得改成 TCP 模式。

进入检测引擎的配置目录：

1

cd /data/safeline/resources/detector/

编辑 detector.yml，添加两行配置：

1
2

bind_addr: 0.0.0.0
listen_port: 8000

然后回到雷池安装目录，编辑 compose.yaml，给 detector 容器加上端口映射：

1
2
3

detect:
    ports:
    - 8000:8000

重启雷池让配置生效：

1
2
3

cd /data/safeline
docker compose down
docker compose up -d

还有一步：雷池和 APISIX 默认都用 9443 端口，装在同一台机器上会冲突。

在 .env 文件里把 MGT_PORT 改成别的端口（比如 9444），再重启雷池就行。

需要注意的是，切换 TCP 模式后雷池控制台本身配置的站点防护会失效，需要同步把雷池的 NGINX 配置从 unix socket 改成 http 方式。
具体做法是拷贝 safeline_unix.conf 为 safeline_http.conf，在 nginx.conf 中切换 include，再把 upstream 地址指向检测引擎的 IP 加端口。

在 APISIX 中接入雷池

由于我的网站平台是统一使用 APISIX 做的网关，APISIX 从 3.5.0 版本开始就内置了 chaitin-waf 插件，集成起来非常方便，只需要简单配置就可以给全站平台都加上安全防护啦。

配置 APISIX 指向雷池检测引擎的地址：

1
2
3
4
5
6
7
8
9
10

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/chaitin-waf \
  -H 'X-API-KEY: your-key-here' -X PUT -d '
{
  "nodes":[
     {
       "host": "127.0.0.1",
       "port": 8000
     }
  ]
}'

host 填雷池所在服务器的 IP，同一台机器就是 127.0.0.1。

然后创建一条路由，把流量经过雷池检测后转发到后端业务：

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

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H 'X-API-KEY: your-key-here' -X PUT -d '
{
   "uri": "/*",
   "plugins": {
       "chaitin-waf": {
       "mode": "block",
       "append_waf_resp_header": true
       }
    },
   "upstream": {
       "type": "roundrobin",
       "nodes": {
           "127.0.0.1:9080": 1
       }
   }
}'

upstream 里的地址换成你的实际业务服务器。

测试防护效果

配置完成后验证一下。

正常访问能返回页面：

1

curl http://127.0.0.1:9080/

模拟一个 SQL 注入攻击：

1

curl http://127.0.0.1:9080/ -d 'a=1 and 1=1'

返回 HTTP 403，说明雷池成功拦截了：

1
2
3
4
5
6

{
  "code": 403,
  "success": false,
  "message": "blocked by Chaitin SafeLine Web Application Firewall",
  "event_id": "18e0f220f7a94127acb21ad3c1b4ac47"
}

打开雷池控制台的日志中心，能看到完整的攻击记录，包括请求 IP、攻击类型和拦截时间。

从此以后，恶意请求在到达博客之前就被雷池自动挡住，不用再每次手动封 IP 了。

定时报告

最后还可以通过 hermes 调用 WAF OpenAPI 定时获取安全报告，如下是我的每小时安全报告：

看起来还不错吧，下一篇再来介绍如何通过 hermes 获取安全报告和自定义规则设置。

你的网站有没有做过安全防护？用的什么方案？评论区聊聊。

今天访问自己的博客时突然发现，页面居然弹出了一个 alert(1) 对话框，再一查是多了一个不存在的异常请求地址：/x。

第一反应是网站被黑了。
排查下来，确实是一次评论区的恶意代码注入攻击。

这篇文章记录完整的发现过程和修复方案，包括封禁攻击者 IP、删除恶意评论、修复主题漏洞三步。

攻击是怎么发生的

这种攻击叫 XSS（跨站脚本攻击），原理不复杂：攻击者把恶意代码注入到网页中，其他访客打开页面时代码自动执行。

这次的攻击路径是这样的：

攻击者在 Twikoo 评论区提交了一条评论，把昵称设成了 <img src=x onerror=alert(1)>。

安知鱼主题的最新评论侧边栏组件会调用 Twikoo 的 API 获取最近评论，然后把评论数据拼成 HTML 渲染到页面上。

问题出在拼接 HTML 的环节。
主题模板直接把用户昵称拼进了 innerHTML，没有做任何 HTML 转义，浏览器就把它当成了真正的 <img> 标签来渲染，加载失败后触发了弹窗。

因为 404 页面也带侧边栏最新评论，所以访问任何不存在的路径都会触发弹窗。

攻击者用 alert(1) 只是证明能打。
真正危险的攻击可以窃取用户 Cookie、劫持登录态、注入钓鱼页面，后果严重得多。

第一步：全局封禁攻击者 IP

发现攻击后，第一件事是切断攻击来源。

从 Twikoo 后台和 Nginx 访问日志中定位到攻击者的 IP 地址，然后直接在云服务器安全组里封禁。

在阿里云 ECS 的安全组规则里添加一条入站拒绝规则，把攻击者 IP 的所有流量拦在外面，一劳永逸。

封禁 IP 是应急措施，能争取处置时间，但不是长久之计。
攻击者可以换 IP 再来，所以还需要从应用层面加固。

第二步：删除恶意评论，开启评论审核

评论系统的加固分两个动作。

先从 Twikoo 后台手动删除昵称为 <img src=x onerror=alert(1)> 的那条恶意评论，清除已经注入的攻击载荷。

然后在 Twikoo 管理后台开启评论审核功能。
开启后，新提交的评论不会直接显示，需要管理员审核通过后才能展示。

这样即使有人再提交恶意内容，也不会直接暴露给其他访客。

评论审核的代价是降低了互动即时性，但对于个人博客来说，这个权衡是值得的。
安全优先。

第三步：修复评论插件 Bug 并上线

前面两步是治标，这一步才是治本。

漏洞的根因在安知鱼主题的两个模板文件里，侧边栏最新评论组件和中控台最新评论组件都有同样的问题。

两个文件的 generateHtml 函数把 Twikoo 返回的用户数据（昵称、头像、评论内容、链接）直接拼进了 innerHTML，没有做任何 HTML 转义，所以攻击者的昵称被浏览器当成了真正的 HTML 标签来执行。

修复方法是对所有来自用户的数据做 HTML 实体编码，把 <、>、" 等特殊字符转义成浏览器不会解析的格式。
转义之后，<img src=x onerror=alert(1)> 这种恶意昵称只会被当成普通文字显示，不会被执行。

修复完成后构建验证通过，提交推送到线上。

攻击复盘

回顾这次事件，有几个教训值得记住。

这类攻击的入口往往是评论区、留言板这类用户可自由输入的地方。
任何把用户输入直接拼进 HTML 的操作都是潜在漏洞。

对所有来自用户的数据做 HTML 转义，是前端项目的基本安全底线。
浏览器自带的防护机制（CSP 等）只是辅助，最根本的还是开发者在代码层面做好输入过滤和输出转义。

如果你的博客也用安知鱼主题，建议检查一下评论区组件有没有同样的问题。

你的博客遇到过类似的安全问题吗？评论区聊聊你的经历和应对方式。

青萍AI图床除了基础的图片管理和 CDN 分发能力，还提供了 AI 生图接口，支持文生图和图生图两种方式。

接口采用 RESTful 风格，请求和响应均为 JSON 格式。认证方式为请求头携带 API Key。

认证

所有接口需要在请求头中携带 X-API-KEY：

1

X-API-KEY: your-api-key-here

API Key 在用户后台的 个人信息 页面获取。

创建会话

在生图之前，先创建一个会话。会话用来组织和管理生图任务，后续的文生图和图生图请求都挂载到同一个会话下。

请求

1

POST /api/ai-chat/sessions

请求参数

1
2
3

{
  "title": "测试api生成会话"
}

响应示例

1
2
3
4
5

{
  "session_id": "session_81288c923af9",
  "title": "测试api生成会话",
  "created_at": "2026-07-08T20:00:00.000+08:00"
}

session_id 是后续文生图和图生图请求的必填参数，需要保存下来。

文生图

根据文本提示词生成图片。

请求

1

POST /api/ai-chat/generate-text-to-image

请求参数

1
2
3
4
5
6
7
8

{
  "session_id": "session_d6d8bc43b761",
  "prompt": "一只橘猫坐在窗台上，夕阳洒在它身上",
  "image_size": "auto",
  "image_resolution": "1K",
  "image_count": 1,
  "model": "nano-banana-2"
}

响应示例

1
2
3
4
5
6
7
8
9

{
  "success": true,
  "data": {
    "task_id": "task_ai_22ea54346830",
    "status": "pending",
    "image_count": 1,
    "message": "图片生成任务已创建"
  }
}

接口返回后不代表图片已生成完成，需要用 task_id 轮询获取最终结果。

查询生成状态

轮询 GET /api/ai-chat/images/{task_id} 获取生成进度和结果。

1

GET /api/ai-chat/images/task_a1b2c3d4

生成中响应

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

{
  "success": true,
  "data": {
    "task_id": "task_ai_22ea54346830",
    "status": "processing",
    "image_count": 1,
    "images": [],
    "generation_type": "text-to-image",
    "prompt": "生成一张真人配音员招募的海报",
    "image_size": "auto",
    "source_image_url": null
  }
}

生成完成响应

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

{
  "success": true,
  "data": {
    "task_id": "task_ai_22ea54346830",
    "status": "completed",
    "image_count": 1,
    "images": [
      {
        "image_index": 0,
        "status": "completed",
        "image_id": 6914253,
        "cdn_image_url": "https://img-cdn.lusyoe.cn/images/lusyoe/2026/07/08/muv540x7.jpg",
        "oss_image_url": null,
        "error_message": null
      }
    ],
    "generation_type": "text-to-image",
    "prompt": "生成一张真人配音员招募的海报",
    "image_size": "auto",
    "source_image_url": null,
    "created_at": "2026-07-08T20:07:49",
    "updated_at": "2026-07-08T20:08:24"
  }
}

推荐轮询间隔为 3-5 秒，直到 status 变为 completed 或 failed。

图生图

在文生图的基础上，传入一张或多张参考图片，让 AI 根据参考图的内容和风格生成新图。

适合的场景：给产品图换背景、根据线稿生成上色图、以某张图的风格生成新内容。

请求

1

POST /api/ai-chat/generate-image-to-image

请求参数

1
2
3
4
5
6
7
8
9
10
11

{
  "session_id": "session_d6d8bc43b761",
  "prompt": "将该产品放置在厨房环境中，使用自然的色彩和光线。确保产品保持真实比例，在场景中大小协调。产品需清晰可见并作为主要焦点，光影和反射效果真实自然。背景应与环境融合，但不能喧宾夺主，确保突出产品。",
  "source_image_urls": [
    "https://img-cdn.lusyoe.cn/images/lusyoe/2025/10/23/ej96myumf2.webp"
  ],
  "image_size": "1:1",
  "image_resolution": "1K",
  "image_count": 1,
  "model": "nano-banana-2"
}

响应示例

1
2
3
4
5
6
7
8
9

{
  "success": true,
  "data": {
    "task_id": "task_ai_22ea54346830",
    "status": "pending",
    "image_count": 1,
    "message": "图片生成任务已创建"
  }
}

生成的图片同样需要用 GET /api/ai-chat/images/{task_id} 轮询获取结果。

错误码

完整调用示例

用 curl 完成一次文生图的完整流程：

创建会话

1
2
3
4

curl -X POST https://img.lusyoe.com/api/ai-chat/sessions \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your-api-key" \
  -d '{"title": "测试生图"}'

提交文生图任务

1
2
3
4
5
6
7
8
9
10
11

curl -X POST https://img.lusyoe.com/api/ai-chat/generate-text-to-image \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your-api-key" \
  -d '{
    "session_id": "session_d6d8bc43b761",
    "prompt": "一只橘猫坐在窗台上",
    "image_size": "auto",
    "image_resolution": "1K",
    "image_count": 1,
    "model": "nano-banana-2"
  }'

轮询结果

1
2

curl -H "X-API-KEY: your-api-key" \
  https://img.lusyoe.com/api/ai-chat/images/task_a1b2c3d4

做一人企业，最怕什么？

不是技术难题，也不是没用户，而是每次想做点新东西，都要从零开始。

最近我折腾了几个产品，有一个感慨越来越深：认证体系这件事，开始越随意，后面越痛苦。
但反过来，如果一开始就搭好统一认证，后面做新功能、新产品、新端口的效率能翻倍。

这篇就来聊聊，统一认证对一人企业到底意味着什么。

更快地试错

一人企业最大的优势是灵活。

想做个新功能，今天想出来，明天就能动手。
但如果你每次新开一个产品都要重新搭用户系统：注册、登录、密码重置、邮箱验证、OAuth 接入，光这些基础工作就能耗掉好几天。
几天时间，对一个 solo 创业者来说是奢侈的。

有统一认证就不一样了。

新产品的用户体系直接从老系统继承过来。
用户在 A 产品注册过，打开 B 产品直接用同一个账号登录，连注册页面都不用做。
省下来的时间可以去验证产品方向、去跟种子用户聊需求、去打磨核心体验。

快速试错的前提是快速，而统一认证把最耗时的基建砍掉了。

多端统一

一人企业做到一定阶段，通常不会只有一个端口。

Web 端、微信小程序、移动 App，可能还有公众号、H5 页面。
每个端口如果各自建一套用户体系，问题就来了：用户在 Web 上注册了，到小程序还得重新注册；在 App 里充了会员，Web 端查不到；数据完全割裂。

统一认证解决的就是这个问题。

不管用户从哪个端口进来，背后都是同一个身份。
小程序登录的资料在 Web 端能查到，App 里产生的行为数据跟 Web 端打通。
对用户来说，一个账号走遍所有端口，不用反复注册、反复填信息。

对开发者来说更省事，后端只管跟认证中心交互，不用每个端口维护一套独立的用户表。

权益继承

这是统一认证最有价值的地方。

你做了产品 A，用户积累了 1000 积分、买了年费会员、订阅了高级功能。
后来你做了产品 B，跟 A 是同一个生态。
如果 B 有自己的认证体系，用户到了 B 一切从零开始，之前的积分和会员全都不算数。
用户凭什么要重新积累？

但如果 A 和 B 共享同一个认证中心，用户的积分、会员等级、订阅状态就能跨产品继承。
到了 B 产品，发现自己的会员还在、积分还能用，用户自然愿意尝试新产品。

这就是网络的积累效应。

每个新产品不再是孤岛，而是已有用户生态的延伸。
你不需要在新产品上从零做用户增长，因为老用户带着权益自动过来了。
对一人企业来说，这意味着每一个新产品的冷启动成本都大幅降低。

一人企业的统一认证实践：青萍统一认证

前面说的都是理念，但理念落不了地就没用。

我自己维护的产品正好需要这套能力。
Web 站一个、移动端一个、微信小程序一个，三个端口各自管用户，每次新开一个产品，用户体系就得重新做一遍。
后来我在青萍统一认证系统上把这些问题一次性解决了。

青萍统一认证基于标准 OIDC（OpenID Connect）协议，同时完整支持 OAuth 2.0。
核心能力就三块：多网站单点登录、移动端和小程序统一登录、用户权益跨产品同步。

多网站单点登录。
你在青萍AI语音注册了账号，打开青萍AI视频或青萍AI图床不用再注册，点一下授权就能直接登录。
支持跨域无缝会话共享，登录态在所有接入应用间自动同步。
开发者侧只需要在认证中心注册一个客户端 ID，配置回调地址，对接标准 OIDC 端点即可。
不同产品之间的登录态完全隔离，安全性不降级。

移动端和小程序统一登录。
微信小程序用 wx.login 获取 code，移动 App 用手机号验证码或微信授权，都指向同一个用户 ID。
还能绑定 GitHub、Notion 等第三方身份源，用户免注册直接登录。
用户在小程序里看到的积分和订单，跟 Web 端完全一致。
对于大多数一人企业来说，小程序加 Web 是获客的主战场，这套打通之后，用户无论在哪个端口发起操作，后端处理起来都一样。

权益跨产品继承。
用户在产品 A 里累积的积分、会员等级、订阅时长，到了产品 B 自动生效。
不用做数据迁移，不用反复找客服，认证中心就是权益中心。

这套系统对一人企业友好的地方在于：不需要专门搭一套微服务架构来支撑。
认证中心独立运行，其他产品通过 API 对接，改一个地方所有产品都生效。
你只管写业务代码，用户体系交给它。

从第一个产品开始

认证体系这件事，从第一个产品开始做，成本最低。
等有了三个产品再回头改造，就要迁移数据、合并账号、解决冲突，工作量翻倍。

所以如果你现在正在做一个新产品，哪怕是 demo 阶段，也值得先把认证独立出来。
这个习惯养成了，后面的每一个新功能、新产品、新端口，都会跑得更快。

最近刚把个人公众号迁到了企业主体，折腾了一趟流程下来，发现有很多值得说的东西。
所以今天就聊聊为什么要迁移，以及迁移之后到底拿到了什么好处。

如果你运营过一个个人公众号，应该多少体会过那种憋屈感：想做个小程序嵌入文章，不行；想把视频号的直播直接推到公众号，不行；想给用户发个服务通知，不行；甚至想给公众号搞个正经菜单，还是不行。

不是你不会用，是个人号的权限就这么多。

为什么个人号限制这么多

先说清楚一个基础设定。
微信公众号分两种：公众号（原订阅号）和 服务号。

个人只能注册公众号，而且个人主体没有微信认证。
企业既可以注册公众号，也可以注册服务号，认证后还能拿到更多接口权限。

没有认证，意味着没有蓝 V 标识，没有自定义菜单，没有模板消息，没有带参数的二维码，更别谈微信支付。

换句话说，个人号的公众号本质上只是个内容发布通道。
你写文章、发文章、读者看文章，这个流程没问题。
但你想要公众号跟其他微信产品联动，对不起，这条路封死了。

迁移之后拿到了什么

好，下面说重点。
企业认证到底能解锁什么东西。

蓝 V 认证带来的信任感

微信认证费用是 300 元一次，有效期一年，到期需要年审。

认证之后，公众号资料页会显示蓝 V 标识，搜索结果里认证号的权重也比未认证号高。
对读者来说，看到蓝 V 和看到 个人 两个字的感觉完全不同，特别是在商业场景下。

自定义菜单和页面模板

这是最直接的感受提升。

个人号只能用一个极其简陋的自动回复充当导航，企业认证后可以配置三层自定义菜单。
配合页面模板功能，你可以把历史文章、产品介绍、联系方式等组织成几个独立页面，菜单一键跳转。

公众号瞬间从一个 发文机器 变成了一个像样的信息站点。

小程序：终于能直接放了

个人号的文章里不能插入小程序卡片，不能跳转到小程序。

企业认证后，这个问题就解决了。
你可以把公众号跟公司的小程序绑定，文章里直接插入小程序卡片，读者点进去就能用你的服务。
公众号做流量引导、小程序做服务交付，这是微信生态里最经典的搭配。

企业微信：客服和用户运营

企业认证后，公众号可以跟企业微信打通。

用户关注公众号后，可以一键添加企业微信客服。
配合企业微信的客户标签、群发、朋友圈等功能，做私域运营就顺手多了。
很多品牌的生意实际上就是从公众号引流到企业微信，再在企微里完成转化和复购。

视频号：打通内容矩阵

如果你的公司有视频号，企业认证的公众号可以直接绑定。

绑定后可以在公众号主页展示视频号入口，视频号直播时也可以推送到公众号。
图文 + 短视频 + 直播，三个内容形式串起来，比单一渠道的触达效果好太多。

此处需配图：公众号主页展示视频号入口的截图

模板消息：该通知的时候不打扰

这个功能很多人不知道。

服务号开通模板消息后，可以在用户完成某个操作后（比如预约成功、订单状态变更）发送结构化的通知消息。
通知不占用每月的群发次数，直接出现在用户的聊天列表里，体验比群发好得多。

个人号没有这个能力，只能靠群发文章去触达用户，太粗暴了。

带参数的二维码

这是做渠道投放的利器。

你可以生成多个不同的关注二维码，每个二维码对应一个渠道（比如公众号底部菜单、线下海报、官网入口）。
用户从哪里扫码关注的，后台一清二楚，还能自动打标签分组。

个人号只能用系统默认的那个关注二维码，完全没法做渠道归因。

迁移的代价

好处说完了，说说代价。

准备工作

迁移不能直接在原号上改主体，你得先注册一个新的企业号作为目标账号，然后把原号的内容、粉丝、违规记录迁移过去。

目标账号必须是企业或个体工商户主体，个人号不能作为接收方。
如果你还没有企业，走个体户注册是最低成本的方案。

费用

迁移本身有成本。
微信官方收取 300 元审核费，外加一份公证书的费用。
如果自己跑线下公证处，大概 800 元左右。
线上公证平台（比如存证云）会便宜一些，499 元左右。
同主体迁移（原号和新号的法人是同一人）不需要公证，能省一笔。

之后每年还有微信认证年审的 300 元。

总支出大概是 800 到 1100 元的第一年投入，之后每年 300 元。

时间

迁移流程走下来，顺利的话 3 到 7 个工作日。
主要耗时在公证和微信审核环节。
如果资料准备齐全，线上公证能快不少。

自动回复

之前设置的关注自动回复以及关键词回复都没有了，需要重新设置。

私信

之前账号的私信也没有迁移过来，全部都清空了。

合集

之前创建的合集也都被清空了，这点挺意外的。

要不要走这条路

如果你只是写写个人博客，不用考虑变现，也不想折腾产品和用户运营，那个人号够用了。

一旦你有以下需求中的任何一条，就该认真考虑迁移：

• 想做小程序跟公众号联动
• 想接入微信支付做电商
• 想用企业微信做客服和私域
• 想把视频号的内容导入公众号
• 想做渠道投放，追踪粉丝来源
• 想配置正经的自定义菜单

我自己的感受是，迁移之后公众号不再只是一个 发文的地方，它成了微信生态里真正的枢纽。
内容、服务、交易、客服，所有东西通过这个号串起来。

300 块一年换来这么多能力，算下来还是划算的。

今天我们要聊的是一则大新闻。

7月3日晚，豆包发布通知，智能体功能将于7月15日正式下线。
用户将无法新建智能体，已创建的也无法调用和运行。
到10月15日，相关数据会被彻底处理，连查看都做不到。

仅仅一天后，千问（通义千问）也发了同样的通知。
千问的拟人化互动类智能体7月10日先行下线，7月15日全面关闭。

两家大厂的智能体功能，就这么说关就关了。

为什么是7月15日

你可能猜到了，这个日期不是巧合。

《人工智能拟人化互动服务管理暂行办法》将于2026年7月15日正式施行。
这是国内首部专门针对AI拟人化互动服务的监管法规，由网信办、发改委、工信部等五部门联合发布。

办法对虚拟恋人、深度角色扮演、情感依附类AI服务设立了强约束。
用户自建智能体容易出现虚拟陪伴、侵权人设、低俗内容，海量自制内容的审核压力巨大。
6月底上海刚通报了清朗行动的结果，累计下架1.4万个违规智能体。

豆包和千问把下线日定在7月15日，正好是办法施行的同一天。
这不是巧合，是平台们在合规大考前做出的选择。

平台依赖的风险

这件事暴露了一个扎心的事实：你在云平台上辛辛苦苦调教出来的智能体，说没就没了。

你定义的人设、积累的对话记忆、精心调试的规则，都跟着功能下线一起归零。
豆包还能备份一下，但备份的是文本截图，不是可恢复的智能体配置。
千问连备份指引都语焉不详。

这不只是豆包和千问的问题。
只要你的智能体运行在别人的服务器上，就永远面临同一个风险：平台随时可能因为合规、业务调整、成本控制等原因关停功能。

如果你的智能体只是用来聊天解闷，影响还小。
但如果你已经把AI智能体融入工作流，用来处理任务、管理信息、自动化操作，那这种依赖就是实实在在的风险。

换个思路：用开源自托管的智能体

那有没有一种方案，智能体的配置、记忆、运行都完全掌握在自己手里？

有，就是自托管的开源智能体。

今天要介绍的是 Hermes Agent，由 Nous Research 开发的开源自主AI智能体框架。
它不是聊天机器人，也不是代码补全工具，而是一个部署在你服务器上、持续学习的数字助理。

Hermes 的核心能力包括：

持久记忆。
跨会话记住你的偏好、项目和环境。
运行越久越了解你，不用每次都从头解释上下文。

自动技能创建。
当 Hermes 解决了一个复杂问题，它会自动写下可复用的技能文档，以后遇到类似场景直接调用。

多平台消息网关。
通过一个网关进程连接飞书、Telegram、Discord、微信等多个平台。
你在群聊里就能叫它干活。

定时自动化任务。
内置 cron 调度器，可以设置每日报告、定时提醒、周期性检查。
全部无人值守运行。

浏览器与网页控制。
它可以直接操作浏览器，帮你抓信息、填表单、做自动化操作。

以上所有数据都存储在你自己的机器上，存在 ~/.hermes/ 目录下。
MIT 开源许可，没有遥测，没有数据收集，没有什么能远程关掉你的智能体。

和云平台智能体的对比

用豆包、千问这类平台自建智能体，本质上是租用平台的能力。
你定义角色、设定规则，但底层模型、运行环境、数据存储全在对方手里。

用 Hermes Agent 则是拥有自己的智能体。
你选择底层模型（OpenRouter 200+ 模型、本地 Ollama、vLLM 都可以），掌握所有数据，随时可以调整配置。
就算外部平台出了什么变化，你的智能体不会受影响。

用一句话说就是：云平台的智能体是借的，Hermes 是自己的。

快速上手

Hermes Agent 的安装非常简单，一条命令就行：

1

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

支持 macOS、Linux 和 WSL2，不需要 sudo 权限，自动安装所有依赖。

装完之后运行 hermes setup 配置模型，然后就可以开始对话了：
hermes

整个流程不到十分钟就能跑起来。
如果你想接入消息平台（飞书、Telegram等），再跑一遍 hermes gateway setup 即可。

有了 Hermes，你不用再担心智能体哪天会下线。
你的数据在你手里，你的智能体在你手里，谁也关不掉。

今天我们要聊的是配音兼职渠道这件事。

绝大部分行业的兼职，多多少少都能挣到点零花钱。
问题从来不是”能不能挣”，而是渠道从哪里来。

配音行业比大多数行业都要封闭一些。
行业资源长期集中在少数人手里，想入行接单通常靠熟人介绍、师徒带路，或者直接签约工作室。
对新人来说，没人引路可能连门都摸不着。

配音兼职的 5 种常见渠道

新人想找配音兼职，常见的有这么几条路。

大平台入驻。
喜马拉雅、懒人听书、蜻蜓FM 这些有声平台都有配音需求。
但门槛不低，资料审核周期长，新人拿不到流量推荐，平台抽成普遍在 30% 到 50% 之间。
这条路更适合有积累的人，新人起步比较吃力。

配音工作室或社团。
它们从需求方接单，再分发给配音师，赚中间差价。
优点是有人帮你对接客户，缺点是抽成不透明。
30% 算良心价，抽 50% 以上的也不少见。
辛辛苦苦录完，到手只剩一半。

社交群组招募。
QQ 群、微信群、豆瓣小组里到处是”长期招募配音兼职”的广告。
门槛确实低，但风险也最高。
最常见的就是让你交押金、交培训费、交认证费。
钱交完了，群要么解散，要么长期没单。

淘宝店铺应聘。
搜”配音服务”，找销量高的店铺，直接问客服要不要兼职配音员。
符合要求会被拉进接单群，算是一条相对稳定的路。

自己做账号。
在抖音、小红书发配音作品，简介里写上”配音接单”，让甲方主动来找你。
这条路的回报周期最长，但积累的是自己的品牌和资源。

配音兼职最大的坑：先交钱

以上渠道各有优劣，但对新人来说最关键的只有一句话：别掏钱。

很多打着”配音兼职”旗号的机构，真实目的是卖课。
先用”0 元试听””在家接单赚钱”吸引你，再展示学员收入截图，诱导你花几千甚至上万买课。
中消协都曾点名过这类套路。
记住：任何让你先交钱再接单的，直接拉黑。

一个真正对新人友好的渠道

那有没有不给钱就能直接接单的平台？

青萍AI语音平台可以了解一下。

它是一个 AI 和真人双引擎的语音创作平台。
AI 那边能批量生成配音、克隆音色、做多语言翻译，真人配音师这边可以在上面直接接单。
覆盖广告配音、有声小说、角色音、纪录片旁白等多个领域。

对想做配音兼职的新人来说，青萍有几个实在的特点。

免费入驻，不收一分钱。
没有入驻费、认证费、年费、押金。
不是什么”限时免费”或”前 100 名免费”，是一直免费。

不卖课，没有培训捆绑。
行业里有些平台打着招募旗号卖课，价格从 1999 到 5999 不等。
青萍不做这些。
入驻就是入驻，不需要花钱参加任何培训。

审核通过即刻上线接单。
不用排队等派单，不用熬等级熬流量。
提交资料审核通过后，个人主页就会出现在平台配音师列表里，客户可以直接查看样音、发送合作邀请。

覆盖品类广。
宣传片、有声书、广告配音、短视频口播、游戏角色音、情感电台、童话故事都有需求。

入驻流程

打开官网 audio.lusyoe.com，注册账号后进入工作台。
找到”合作入驻”入口，填写个人资料和样音作品，提交审核就行。
审核通过后，你就可以在平台上接单了。

最后再提醒一句：配音能力是练出来的，不是花钱买来的。
任何让你先交钱再接单的渠道，不管话说得多好听，都别信。
真正靠谱的平台，不会在你还没赚到一分钱的时候，就先从你口袋里掏钱。

带娃的空隙想做点声音兼职，但真开始找渠道的时候，不少人卡住了。

喜马拉雅？听说要等好久才开通。

配音群？怕遇到骗子。

App 上那些接单平台？也不知道哪个靠谱。

这篇就从宝妈最在意的三个角度来聊：门槛高不高、要不要交钱、接单方不方便。

喜马拉雅：大平台，但新人难出头

喜马拉雅是音频行业的老大哥，有声书需求量确实大。

广告配音、有声小说、情感电台，每天更新的内容几万条，配音机会是有的。

但问题出在入门这块。

想做喜马拉雅的认证主播，得先提交资料审核，包括学历证明、普通话等级证书、样音作品，全套走下来快则一两周，慢则一两个月。

通过了之后平台不会主动给你推单，得自己去接单广场抢任务。

新人几乎抢不到好单子。

因为接单广场上挂出来的任务有限，几十上百个主播盯着。

有声书分成比例大概 30% 到 50%，平台拿走一大部分，到你手上的并不多。

对宝妈来说，最难受的是时间。

有声书录制通常有交稿截止日，有时候一天得录两三个小时。

带娃的空闲时间本就不固定，赶上孩子生病、学校放假，交稿压力特别大。

不是说喜马拉雅不好，但它更适合有稳定时间、有作品积累的专业主播。

配音圈兼职App：自由灵活，但得自己谈

配音圈兼职App 是四川好声库科技做的平台，模式比较轻：直接让客户和配音员一对一聊。

你想接什么类型的单子自己选，有声书、广告、短视频、游戏配音都有。

平台上没有中间商抽成，客户找到你之后，价格你们自己谈。

优点是自由度很高，不限制接单时间，今天有空接一单，明天没空不接也行。

缺点是平台只管牵线，不管谈价和交付。

你上传样音，客户听了觉得合适就来私聊。

聊价格、聊录制要求、聊修改次数，全得自己来。

有些客户对声音要求很高，一遍遍让你重录，不好意思拒绝，一单改来改去花好几个小时。

还有就是单子得自己找。

平台不主动推送订单，得自己多上线看看有没有客户发来消息。

宝妈白天带娃没空看手机，等晚上打开 App，人家客户已经找别人了。

这种模式适合沟通能力强、时间相对灵活、愿意主动找活的人。

如果你带娃已经很累了，不想再费心跟人讨价还价，这个平台用起来会有点累。

青萍AI语音：免费入驻，海量订单自动推送

前两个平台各有各的好，但对宝妈来说，总差那么一点。

一个门槛高、等太久，一个得靠自己找活谈价格。

有没有那种入驻不用花钱、不需要自己找客户、订单自动送上门的平台？

青萍AI语音的真人配音板块，就是照着这个思路做的。

免费入驻，不收一分钱。

入驻费、押金、培训费，通通没有。

注册一个账号就能申请成为配音师，不是什么限时免费，是一直免费。

没有培训捆绑，不卖课。

很多配音平台说是招募配音师，进去先推几千块的课程。

青萍AI语音不卖课，不推培训套餐。

你有配音能力，直接入驻直接接单。

订单自动推送，不用自己找活。

这是最吸引宝妈的一点。

你入驻通过后，平台上每天都有大量配音需求推送过来。

有声书、广告配音、短视频口播、游戏角色音、情感电台、童话故事……品类覆盖很广。

你不需要去跟客户谈价格、改稿子，平台有专人对接。

订单来了你看着接，合适就接，不合适等下一单。

时间自由，适合碎片化接单。

带娃的空闲时间不稳定，今天下午孩子睡午觉能录半小时，明天可能一整天没空。

青萍AI语音的订单模式支持这种碎片化接单，没有强制交稿时间，不用赶工期。

怎么入驻。

打开官网 audio.lusyoe.com，注册账号后进入工作台，找到合作入驻入口，填写个人资料和样音作品，提交审核。

审核通过后你的配音员页面就上线了，每天等着接单就行。

三个平台怎么选

如果你有大量作品积累、有稳定的录制时间，喜马拉雅值得一试。

如果你擅长沟通、不介意自己谈价格找活，配音圈兼职App 是个灵活的选择。

如果你带娃时间碎片化、不想花钱、不想费心谈客户，只想安安静静录录音赚点零花钱，青萍AI语音是最省心的方案。

声音条件不错的宝妈，不妨从青萍AI语音开始试试。

免费入驻，没有损失。

万一做着喜欢，再拓展到其他平台也不迟。

前往 audio.lusyoe.com 即可体验。

今天我们要介绍的是 Hermes Agent 的浏览器工具集。
用一句话说就是：让 AI 替你操作网页。

你给它一个网址，它能输入文字、点击按钮、滚动页面、截图分析，全程不需要你动手。

这套能力有两层实现方式。
第一层是 Hermes 内置的浏览器工具集，十几个工具覆盖了绝大多数网页操作需求。
第二层是 Browser Harness，一个第三方开源框架，能让 AI 自己编写操控脚本并优化，适合更复杂的任务。

如果你刚开始接触这些工具，别担心，我会从概念开始一步步带着你用起来。

什么是 Hermes 浏览器工具

Hermes 的浏览器工具有 10 个核心操作：

• browser_navigate，打开网页，是所有操作的前提
• browser_snapshot，获取当前页面的无障碍树快照，返回可交互元素的 ref ID
• browser_click，点击 ref ID 对应的元素
• browser_type，往输入框填入文字
• browser_scroll，向上或向下滚动页面
• browser_press，按键盘键（Enter、Tab、Escape 等）
• browser_back，回退到上一页
• browser_vision，截图并用 AI 分析画面内容
• browser_get_images，列出页面上的所有图片
• browser_console，读取浏览器控制台输出

如果通过 CDP 连接浏览器，还会额外解锁两个工具：browser_cdp（发送原始 CDP 指令）和 browser_dialog（处理 alert/confirm 弹窗）。

每个浏览器后端都支持这些工具，区别只在于浏览器跑在哪里。

启用浏览器工具集

浏览器工具默认没开，需要手动加到工具列表里：

1

hermes config set toolsets '["hermes-cli", "browser"]'

或者通过交互式配置：

1

hermes setup tools

在菜单中选择 Browser Automation 并选择你偏好的后端。

本地浏览器模式（零成本起步）

如果你刚开始接触，本地模式是最简单的起点。不花钱，不用注册任何云服务。

Hermes 通过 agent-browser 驱动本地安装的 Chromium。只需要确保系统里有 Chrome 或 Chromium：

1
2

# 安装 agent-browser CLI
npm install -g agent-browser

启动 Hermes 后，直接发指令：

1

帮我打开 https://www.36kr.com，看看今天有哪些热门资讯

Hermes 会自动启动一个后台 Chromium 进程，打开页面，抓取内容，然后把结果返回给你。

所有操作都在你的电脑上完成，不经过第三方服务器。

CDP 模式（亲眼看着 AI 操作）

本地模式浏览器跑在后台，你看不到操作过程。
如果你想亲眼看着 AI 操作，就用 CDP 模式。

先以远程调试模式启动你的浏览器。

macOS 上的 Chrome：

1
2
3
4

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/.hermes/chrome-debug" \
  --no-first-run --no-default-browser-check &

浏览器启动后，打开控制台，运行 /browser connect：

1

/browser connect

连接成功后，AI 操作会直接反映在你眼前的浏览器窗口中。
适合调试网页，或者需要借用你已登录的会话的场景。

完成后用 /browser disconnect 断开连接。

Browser Harness 是什么

Browser Harness 是 browser-use/browser-harness 开源项目，让 AI 直接通过 CDP WebSocket 连上你的浏览器。
和内置的 browser_ 工具集相比，Browser Harness 的操控更底层、更灵活——AI 可以自己编写操控脚本并不断优化，这就是所谓的”自愈”能力。

它需要手动安装并注册为 Hermes 的技能才能使用：

1
2
3
4
5
6

# 克隆仓库
git clone https://github.com/browser-use/browser-harness ~/browser-harness
cd ~/browser-harness

# 注册为 Hermes 技能（通过符号链接）
ln -s "$(pwd)" ~/.hermes/skills/browser-harness

然后在 Hermes 终端里直接告诉它用 Browser Harness 操作浏览器即可。

如果想通过 CDP 连接本地浏览器，还需要先以调试模式启动 Chrome：

1
2
3
4

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/.hermes/chrome-debug" \
  --no-first-run --no-default-browser-check &

之后 Hermes 就能通过这个 CDP 通道操控 Chrome 页面。

使用场景

填表单、下单、预约

这是最直接的应用。
给 AI 一个注册链接，告诉它填入什么信息，它会自己导航到页面、找到输入框、填入内容、点击提交。

1

帮我用 email@example.com 在 example.com 注册一个账号，密码用 xxxxxx

抓取 JavaScript 渲染的数据

很多现代网站的数据是通过 AJAX 动态加载的。
普通的 web_extract 工具只能拿到初始 HTML，但浏览器工具会等 JavaScript 执行完毕后读取渲染后的 DOM。

1

打开我的后台面板 http://localhost:3000/dashboard，截图看看今天的指标

截图做可视化 QA

部署新版本后，让 AI 打开几个关键页面截图确认，可以替代人工巡检。

1

打开网站首页、登录页、个人中心，每页截图让我看看

多步骤研究

从一个文档页面出发，顺着链接跟踪到多个子页面，最后汇总信息。

1

打开 Hermes 官方文档的浏览器页面，看看支持哪些后端，帮我汇总成表格

Browser Harness 进阶：重复性操作自动化

对于需要每天重复的网页操作（登录后台、导数据、填写日报），Browser Harness 的 domain skills 机制能让这些步骤不断自我优化。AI 会记住每个网站的布局特征和操作流程，下一次执行得更快。

写在最后

Hermes 的浏览器工具给 AI 装上了一双能”看”能”点”的手。

本地模式适合初学者零成本体验，CDP 模式让你看着 AI 操作真实浏览器。
Browser Harness 则为复杂场景提供了自愈式的操控能力。

从简单的截图问答到完整的网页自动化流程，这套工具有很大的想象空间。

用过 AI 编程工具的人大概都有这种体会：明明上一个会话还聊得好好的，换个项目再回来，它又把你当陌生人。

OpenCode 也不例外，每次新会话都是一片空白。

Hindsight 就是来解决这个问题的。
这是一个开源的长效记忆系统，它为 AI 工具装上”脑子”——之前聊过的项目上下文、代码决策、踩坑经验，之后都能自动回想起来。

更实用的是，Hindsight 的 OpenCode 插件支持为每个项目创建独立的记忆库，项目 A 的记忆不会污染项目 B。

插件安装

Hindsight for OpenCode 以 npm 包形式发布，直接在 opencode.json 中声明即可。

打开项目根目录的 opencode.json（或全局配置 ~/.config/opencode/opencode.json），在 plugin 数组里加上插件配置：

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

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    ["@vectorize-io/opencode-hindsight", {
      "hindsightApiUrl": "http://<your-server-ip>:8888",
      "autoRecall": true,
      "autoRetain": true,
      "recallBudget": "mid",
      "retainEveryNTurns": 3,
      "debug": false
    }]
  ]
}

OpenCode 启动时会自动从 npm 安装插件，不需要手动执行 npm install。
插件安装后直接连接到你指定的 Hindsight 服务器地址。

如果你用的是 Hindsight Cloud 云服务，需要更换 hindsightApiUrl 并加上 API Token：

1
2
3
4
5
6
7
8
9

["@vectorize-io/opencode-hindsight", {
  "hindsightApiUrl": "https://api.hindsight.vectorize.io",
  "hindsightApiToken": "your-api-key",
  "autoRecall": true,
  "autoRetain": true,
  "recallBudget": "mid",
  "retainEveryNTurns": 3,
  "debug": false
}]

API Key 在 ui.hindsight.vectorize.io/connect 注册获取。

每个项目独立记忆库

这是整个插件最实用的特性：动态记忆库 ID。

默认情况下，所有项目共享同一个记忆库（bankId 固定为 opencode）。
这就意味着 A 项目的记忆会在 B 项目的会话中被召回，两个项目的上下文互相干扰。

开启动态记忆库后就不一样了：

1

export HINDSIGHT_DYNAMIC_BANK_ID=true

Hindsight 会根据当前项目的特征自动推导一个唯一的 bankId，默认的组合规则是 agent::project。
A 项目启动的会话自动关联 A 项目的记忆库，B 项目启动的会话自动关联 B 项目的记忆库，互不干扰。

支持的特征字段包括 agent（角色名）、project（项目目录名）、channel（渠道名）和 user（用户标识）。
如果你需要更细的隔离粒度，可以自定义组合，但默认的 agent::project 已经覆盖了最常见的场景。

插件提供的三个工具

安装并连接成功后，Hindsight 会注册三个工具给 OpenCode 的 AI Agent：

• hindsight_retain，主动存储信息到长期记忆，适合记录重要的架构决策、踩坑经验
• hindsight_recall，搜索长期记忆中的相关信息，跨会话检索之前讨论过的内容
• hindsight_reflect，综合多条记忆给出一个回答，适合需要总结归纳的场景

这些工具 AI Agent 可以在会话中直接调用。
但多数情况下你不需要手动触发它们，插件有自动机制。

自动记忆与召回

Hindsight 的两个自动行为让记忆真正”无感”。

auto-retain：当会话进入空闲状态时，插件自动把当前对话内容存入记忆。
你可以通过 retainEveryNTurns 控制存储频率。
默认每 3 轮交互保存一次。

auto-recall：每次新会话启动时，插件自动检索与该项目相关的历史记忆。
这些记忆会被注入到系统提示词中。
AI Agent 加载后就拥有了之前会话的上下文，不需要你主动”提醒”。

当 OpenCode 压缩上下文窗口时，插件也会先保存当前会话内容再压缩，确保记忆在上下文截断后不会丢失。

持久配置

如果不想在每个项目里重复配，可以创建 ~/.hindsight/opencode.json 文件，这里面的配置对所有项目生效：

1
2
3
4

{
  "hindsightApiUrl": "http://<your-server-ip>:8888",
  "recallBudget": "mid"
}

配置的优先级从低到高依次是：

默认值 < ~/.hindsight/opencode.json < opencode.json 插件选项

后面的会覆盖前面的，灵活度很高。

完整配置参考

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

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": [
    ["@vectorize-io/opencode-hindsight", {
      "hindsightApiUrl": "https://api.hindsight.vectorize.io",
      "hindsightApiToken": "your-api-key",
      "bankId": "my-project",
      "autoRecall": true,
      "autoRetain": true,
      "recallBudget": "mid",
      "recallTags": [],
      "retainTags": [],
      "retainEveryNTurns": 3,
      "debug": false
    }]
  ]
}

几个关键选项说明：

• bankId：静态记忆库 ID，不开启动态模式时使用
• recallBudget：召回量，可选 low / mid / high，默认 mid
• recallTags / retainTags：按标签过滤存储或召回
• retainEveryNTurns：自动保存频率，每 N 轮交互存一次

写在最后

Hindsight 给 OpenCode 补上了最关键的一环：记忆。

安装只需要在配置里加一行插件声明，连接 Hindsight 服务器后，每个项目就有了自己独立的记忆空间。
之前讨论过的架构、发现过的 bug、做过的决策，新会话直接继承，不需要重复交代。

2026 年 6 月 19 日，Hermes Agent 发布了 v0.17.0 版本，代号 The Reach Release（触达版）。
这个版本从 v0.16.0 算起积累了约 1,475 次提交、800 个合并 PR 和 300 多个修复的 issue，245 位社区贡献者参与开发。
版本名”触达”的含义很直白：扩展 Agent 能到达的地方，包括新的消息渠道、更深的工具集成，以及面向团队部署的能力增强。
其中最值得关注的架构改进，是一个 Gateway 进程同时服务多个 Profile 的多路复用功能。

版本概览

v0.17.0 的更新覆盖面很广，挑几个主要方向：

• iMessage 支持，通过 Photon Spectrum 接入，不再需要一台 Mac 做中继
• 后台子代理，delegate_task 支持 background 模式，派发任务后继续做别的事
• 图片编辑，image_generate 工具支持图生图，传入原图加提示词即可修改
• Automation Blueprints，用问答方式设置定时任务，不用背 cron 语法
• Dashboard Profile Builder，浏览器里选模型、选技能、挂 MCP，直接构建完整 Profile
• memory 批量操作，原子化的 add/replace/remove 批处理，一次调用完成多步编辑
• WhatsApp Business Cloud API，官方适配器，不用再维护 Baileys 桥接进程
• Telegram 富文本，Bot API 10.1，回复消息原生渲染格式

这些功能每一个都值得单独聊，但这篇文章的重点在 Gateway 多路复用。

单 Gateway 多 Profile

之前的问题

Hermes 的 Profile 机制允许在同一台机器上运行多个独立的 Agent 实例。
每个 Profile 有自己的 config.yaml、.env、SOUL.md、记忆、会话、技能和定时任务。

但在 v0.17.0 之前，多 Profile 部署有一个绕不开的代价：每个 Profile 都要启动一个独立的 Gateway 进程。
你有 3 个 Profile，就要跑 3 个 Gateway，每个都有自己的 PID、锁文件、端口和系统服务单元。
N 个 Profile 就有 N 个 Gateway 要配置、监控和重启。

用 Docker 部署时，s6-overlay 会自动管理这些进程，但容器内进程数随 Profile 数量线性增长。
维护成本不低。

新的方案

v0.17.0 引入了 Gateway 多路复用（PR #48273），让一个 Gateway 进程同时服务所有 Profile。

这是一个 opt-in 功能，通过配置项 gateway.multiplex_profiles 开启，默认关闭。
关闭时行为与之前完全一致，不会影响任何现有部署。

1
2

gateway:
  multiplex_profiles: true

开启后，默认的 Gateway 进程会自动枚举所有 Profile，为每个 Profile 注册独立的适配器实例。
自己的 bot token、自己的会话存储、自己的凭证。

凭证隔离

多路复用面临的核心技术挑战是凭证隔离。

如果直接把所有 Profile 的密钥合并到进程级的 os.environ，Profile A 的 API Key 会在 Profile B 的请求中被读到。
更危险的是，所有子进程（MCP Server、Kanban Worker）都会继承这份全局环境变量，导致跨 Profile 泄露。

v0.17.0 的解决方案是 fail-closed 的 get_secret() 机制。
多路复用模式下，凭证读取由一个 context-local 的 secret scope 包裹。
当读取凭证时没有安装对应的 scope，get_secret() 会直接抛出 UnscopedSecretError 异常。
它不会回退到 os.environ。
这确保了即使代码中有遗漏的调用点，也会在运行时立即暴露，不会静默泄露。

真正全局的变量（HERMES_* 系列、PATH、Kanban 路径等）通过一个白名单继续从 os.environ 读取。
每轮对话开始时重新加载对应 Profile 的 .env 文件，不再修改全局的 os.environ。

怎么用

先升级到 v0.17.0：

1

hermes update

然后在默认 Profile 中开启多路复用：

1

hermes config set gateway.multiplex_profiles true

重启 Gateway 后，它会自动枚举所有 Profile 并为每个创建独立的适配器实例。
之后只需要维护一个 Gateway 服务，所有 Profile 的消息渠道都通过它收发。

每个 Profile 仍然在各自的 .env 中配置 bot token 和允许用户列表。
如果两个 Profile 不小心配了相同的 token，系统会直接报错并指出冲突。

注意一点：多路复用模式开启后，不能用 hermes -p <name> gateway run 单独为某个 Profile 启动 Gateway。
系统会检测到多路复用器正在运行并阻止这种操作，避免端口和 token 冲突。

其他团队部署改进

除了 Gateway 多路复用，v0.17.0 还有一批面向团队和规模化部署的更新：

• Managed Scope，管理员可以从 root 权限的 /etc/hermes 锁定不可变的配置和密钥，普通用户无法修改
• 可插拔 CronScheduler，支持 Chronos 等托管 cron 服务，实现 scale-to-zero 的定时任务调度
• Gateway-Gateway Relay，多级 Gateway 中继协议，适合跨网络、跨区域的 Agent 部署
• 安全加固，凭证审批默认 fail-closed、MCP stdio 配置安全扫描、REST cron 提示词校验

升级方式

一行命令：

1

hermes update

升级会自动同步新增的 bundled skills 到所有 Profile，用户自定义的 skills 不会被覆盖。
更新完成后用 hermes -V 确认版本号显示 v0.17.0 (2026.6.19) 即可。

播客、音乐、配音，这些音频内容有个共同的短板：看不见。

在短视频平台上，纯音频的完播率远低于带视觉元素的内容。
一段好听的配音，如果配上跳动的波形或炫酷的频谱，观感完全不同。

音频可视化就是把声音变成画面。
这篇文章介绍三种主流的可视化形式，以及两种能直接上手的实现方案。

三种可视化形式

波形图

最经典的形式，展示音频幅度随时间的变化。
横轴是时间，纵轴是音量大小，看起来像一组密集的竖线。

波形图制作简单，辨识度高，适合有声书、播客、语音备忘录。

频谱图

展示音频的频率分布，用颜色表示不同频段的强度。
低频在底部呈现暖色（红/橙），高频在顶部呈现冷色（蓝/紫），形成类似热力图的效果。

频谱图视觉冲击力强，适合音乐类内容。

粒子动效

波形和频谱的组合升级版。
音频数据驱动粒子系统的运动，音量大时粒子炸开，音量小时收拢，节奏感极强。

这种效果在 EDM（电子舞曲）视频和游戏混剪中最常见，但实现成本也最高。

方案一：FFmpeg 命令行

FFmpeg 内置了一组音频可视化滤镜，不需要写代码，一行命令就能生成视频。

生成波形视频

1
2
3

ffmpeg -i input.mp3 -filter_complex \
  "[0:a]showwaves=s=1280x720:colors=white,format=yuv420p[v]" \
  -map "[v]" -map 0:a -c:a aac output.mp4

showwaves 滤镜把音频波形渲染到画面上。
s=1280x720 设置输出分辨率，colors=white 设置波形颜色。

生成频谱视频

1
2
3

ffmpeg -i input.mp3 -filter_complex \
  "[0:a]showspectrum=s=1280x720:mode=combined,format=yuv420p[v]" \
  -map "[v]" -map 0:a -c:a aac output.mp4

showspectrum 滤镜生成频谱热力图。
mode=combined 将所有声道合并显示，适合音乐。

FFmpeg 方案的优势是快，缺点是画面风格固定，自定义空间有限。

方案二：Web Audio API

需要在网页端实时渲染音频可视化，Web Audio API 是首选方案。

核心流程分三步：解码音频 → 提取频域数据 → 绘制到 Canvas。

  flowchart LR    A[音频文件] --> B[AudioContext 解码]    B --> C[AnalyserNode 分析]    C --> D[getByteFrequencyData]    D --> E[Canvas 绘制]    E -->|requestAnimationFrame| C  

关键代码

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

// 创建音频上下文和分析节点
const audioCtx = new AudioContext();
const analyser = audioCtx.createAnalyser();
analyser.fftSize = 256;

// 连接音频源到分析节点
const audioElement = document.querySelector('audio');
const source = audioCtx.createMediaElementSource(audioElement);
source.connect(analyser);
analyser.connect(audioCtx.destination);

// 获取频率数据并绘制
const bufferLength = analyser.frequencyBinCount;
const dataArray = new Uint8Array(bufferLength);

function draw() {
  requestAnimationFrame(draw);
  analyser.getByteFrequencyData(dataArray);
  // 用 dataArray 的值在 Canvas 上画柱状图
}

fftSize 决定频率分辨率，值越大细节越丰富但计算量也越大。
getByteFrequencyData 返回 0-255 的整数值数组，每个元素对应一个频段的能量。

Web Audio API 方案的优势是灵活，可以自由设计视觉效果。
缺点是需要前端开发能力，且浏览器兼容性需要处理。

两种方案怎么选

选 FFmpeg 的场景：批量处理、后台生成、不需要实时预览。
选 Web Audio API 的场景：在线播放器、交互式可视化、需要自定义动画风格。

如果两种都不想碰，还有一个零门槛的选择。

零门槛方案：青萍 AI 语音的音频生视频

上面两种方案，FFmpeg 需要命令行基础，Web Audio API 需要前端开发能力。
对大多数创作者来说，门槛还是高了。

青萍 AI 语音（audio.lusyoe.com）提供了音频生视频功能。
上传一段音频，系统自动生成带波形和频谱动效的视频，不需要任何技术操作。

效果上，它会根据音频的节奏和音量动态生成可视化画面。
适合做短视频配音、播客片段分享、音乐可视化等场景。

配合平台已有的语音合成和音色克隆功能，整个流程可以这样串起来：
用 AI 语音生成配音，一键转成可视化视频，直接发到短视频平台。

从文字到声音到画面，一个平台搞定。

大部分 AI 助手有个共同的局限：你问一句，它答一句。
你不说话，它就安安静静待着。

但日常工作和生活里，很多事情是周期性的。
每天早上想看一眼科技新闻摘要，每周想检查一次关注的仓库有没有新动态，某个网页更新了想第一时间知道。

这些事情反复做，每次手动问 AI 太累了。
Hermes Agent 的 Cron 定时任务功能就是来解决这个问题的。

你可以让 AI 在指定时间自动干活，结果直接推送到飞书、微信等消息平台。
相当于给 AI 管家装了一个闹钟，到点就上班。

Cron 是什么

Hermes 的 Cron 是内置在 Gateway 网关里的定时调度器。

Gateway 每 60 秒检查一次任务列表，发现到期任务就启动一个全新的 Agent 会话来执行。
执行完成后，结果自动推送到你指定的消息渠道。

跟传统 crontab 相比，最大的区别是 Hermes 的 Cron 任务由 AI 来执行，不是跑固定的 shell 命令。
你给它一段自然语言指令，它自己理解、拆解、调用工具、输出结果。

  flowchart LR    A[Gateway 调度器] -->|每60秒检查| B[任务列表]    B -->|发现到期任务| C[启动独立 Agent 会话]    C --> D[执行 Prompt]    D --> E[结果自动推送]    E --> F[飞书 / 微信 / 钉钉]  

创建任务的三种方式

最方便的是直接在对话里说自然语言。
比如直接对 Hermes 说，每天早上 9 点搜一下今天的 AI 新闻，整理成简报发到飞书。
Hermes 会自动创建任务，你不需要记任何命令。

需要精确控制参数时，可以用斜杠命令。

1

/cron add "0 9 * * *" "搜索今天的 AI 领域新闻，整理成 5 条摘要，每条配链接" --name "每日AI简报" --deliver feishu

终端操作的话，CLI 命令也可以。

1

hermes cron create "0 9 * * *" "搜索今天的 AI 领域新闻，整理成 5 条摘要" --name "每日AI简报" --deliver feishu

三种方式效果一样，选你顺手的就行。

调度格式速查

常用的就是 Cron 表达式和间隔循环。
0 9 * * * 是每天早上 9 点。
0 9 * * 1-5 是工作日早上 9 点。
0 */6 * * * 是每 6 小时一次。

每日新闻简报自动推送

这是最经典的应用。

创建一个每天早上 9 点运行的任务，自动搜索 AI 领域新闻，整理成简报推送到飞书。

1

/cron add "0 9 * * *" "搜索过去 24 小时的 AI 领域重要新闻，选出最有价值的 5 条。每条包含标题、一句话摘要和原文链接。格式简洁，适合手机上快速浏览。" --name "每日AI简报" --deliver feishu

每天到点，飞书就会收到一条整理好的新闻摘要。
早上喝咖啡的时间就把行业动态刷完了。

网站变更监控

想盯一个网页看它什么时候更新，手动刷新太蠢了。
这个场景有个关键技巧：[SILENT] 标记。

配一个脚本先检查网页内容有没有变化。
如果没变化，让 Agent 回复 [SILENT]，Cron 就不会推送任何消息。
如果有变化，Agent 正常输出摘要，你才会收到通知。

1

/cron add "every 1h" "如果脚本输出显示 CHANGE DETECTED，分析网页发生了什么变化并简要说明。如果输出是 NO_CHANGE，只回复 [SILENT]。" --script ~/.hermes/scripts/watch-site.py --name "网页监控" --deliver feishu

只有网页真的变了，你才会被通知。
这就是 [SILENT] 的价值：让监控类任务在没事的时候保持安静。

GitHub 仓库动态

关注一个开源项目，想第一时间知道有没有新 issue 或 PR。
这个场景不需要写脚本，Hermes 内置的终端工具可以直接跑 gh 命令。

1

/cron add "every 6h" "检查 NousResearch/hermes-agent 仓库过去 6 小时的新动态。用 gh issue list 和 gh pr list 命令查询，筛选出最近 6 小时内的更新。如果没有新动态，回复 [SILENT]。否则简要列出新增的 issue 和 PR。" --name "仓库监控" --deliver feishu

每 6 小时自动检查一次，有动静才通知你。

任务全生命周期

创建之后，任务不是一成不变的。
Hermes 提供了完整的管理命令。

1
2
3
4
5
6

/cron list                    # 查看所有任务
/cron run <任务名>             # 立即触发一次（测试用）
/cron pause <任务名>           # 暂停，不删除
/cron resume <任务名>          # 恢复执行
/cron edit <任务名> --schedule "every 4h"  # 改调度频率
/cron remove <任务名>          # 彻底删除

任务名不区分大小写，用名称代替 ID 就行。
改调度频率或提示词不需要删了重建，直接 edit。

两个关键注意点

提示词必须自包含。

Cron 任务运行在全新的会话里，没有你之前聊天的上下文。
如果你只写 检查一下那个服务器，Agent 根本不知道是哪台服务器。
IP 地址、用户名、具体命令都要写在 prompt 里。

Gateway 必须在运行。

Cron 调度器是 Gateway 网关的一部分。
Gateway 没跑，定时任务就不会触发。
用 macOS 的话，推荐用 launchd 托管 Gateway，设置 RunAtLoad=true 和 KeepAlive.SuccessfulExit=false，开机自动启动，意外退出自动重启。

声音好听的你，有没有想过用这个优势赚点外快？

真人配音兼职这几年越来越火。
有声书、短视频、广告宣传片、游戏角色配音，需求量大，价格也不低。

但很多想入行的人卡在第一步：去哪里接单？

这篇聊聊几个常见的配音接单渠道，再推荐一个免费入驻的平台。

喜马拉雅：门槛高，但单量稳定

喜马拉雅是最大的有声书平台之一，对配音师的需求量确实大。

有声书分成、平台任务、接单广场，几个渠道加起来，月入过万的主播不在少数。

但问题也很明显。
想做喜马拉雅的认证主播，需要提交学历证明、普通话等级证书、作品样音，审核周期长。
通过之后，新人几乎拿不到流量推荐，得从最基础的低价单开始熬。

平台抽成也不低。
大部分有声书任务的分成比例在 30% 到 50% 之间，配音师拿到手的比想象中少。

适合已经有大量作品积累、不愁没单的专业配音员。
新人想靠它起步，压力和投入都不小。

配音工作室和社团：中间商赚差价

市面上的配音工作室和配音社团也不少。
它们从需求方接单，再分发给旗下的配音师，赚中间的差价。

优点是工作室会帮你对接客户、安排档期，你只需要专注录音就行。

缺点是抽成比例不透明。
有些工作室抽 30% 算良心价，抽 50% 以上的也不少见。
配音师辛辛苦苦录完，稿费到手只剩一半。

还有些工作室设置了阶梯派单制度：想接高价单，先接几单低价单攒星级。
新人几个月下来都在白忙。

社交群组招募：门槛低但风险高

QQ 群、微信群、豆瓣小组，到处都有”长期招募配音兼职”的广告。

这种渠道的好处是几乎没有门槛。
发一段试音，对方觉得可以，直接派单。

但风险也是最高的。

最常见的套路是”交押金才能接单””交培训费才能提升等级””交认证费才能解锁高价单”。
钱交完，群要么解散，要么长期没单派。

还有一些是做”卖课”生意的。
打着招募旗号吸引人进群，然后推配音课程，价格从 199 到 5999 不等。
课卖了，单不一定有。

不是所有群都是骗子，但对新人来说，要分辨哪些靠谱、哪些是坑，难度很大。

青萍AI语音：免费入驻，在线接单

这些痛点，市面上有没有平台真的在认真解决？

青萍AI语音的真人配音板块就是针对这些问题设计的。

免费入驻，不收 1 分钱

入驻青萍AI语音不需要交任何费用。
入驻费、认证费、年费、押金，通通没有。
注册一个账号就能申请成为配音师。

不是什么”限时免费”或”前 100 名免费”，是一直免费。

没有培训捆绑

我们不卖配音课程，不推培训套餐。
不需要在入驻前花一分钱参加任何培训。
有配音能力，直接入驻接单。

审核通过即刻上线

提交资料审核通过后，你的配音员主页立即上线。
客户能在平台上搜索到你，在线试听你的样音作品，直接下单。

不用排队等单，不用熬等级熬流量。

怎么入驻

打开官网 audio.lusyoe.com，注册账号后进入工作台，找到合作入驻入口，填写个人资料和样音作品，提交审核。

审核通过后，你的页面就会出现在配音员列表中。
客户可以直接下单、发起试音。

平台提供一对一专属对接服务。
从沟通需求到交付成品有专人跟进，不用自己跟客户扯价格和修改。

覆盖宣传片、有声书、广告配音、短视频口播、游戏角色音、情感电台、童话故事等多个品类。

如果你声音条件不错，想找一条靠谱的配音兼职路，不妨从这里开始。

前往 audio.lusyoe.com 体验。

这两年 AI 语音技术进步很快。
但大多数人提到它，想到的还是 Siri 或者剪映里的文本朗读。
其实 AI 语音已经分成两个明确的方向：语音合成（让文字开口说话）和语音识别（把声音变成文字）。
两个方向解决的是不同的问题，但对创作者来说，最好两个都有。

语音合成：让文字开口说话

语音合成就是文字转语音，简称 TTS。
你给一段文字，它读出来。
十年前那个水平的 TTS 机械感很重，现在完全不一样了。

声音克隆

现在的 TTS 已经能做声音克隆。
上传一段录音，AI 就能学会你的声音，然后用你的音色去读任何文字。
做有声书的时候，你可以给每个角色克隆一个专属音色，切换着用。

声音设计

现在的 TTS 不只是克隆已有声音。
你可以用文字描述来创造一个不存在的声音，比如写一句 “一个低沉的男中音，带点沙哑感”，模型就能直接生成对应的音色。
不需要录音，不需要素材，适合虚拟角色和个性化场景。

多语言合成

TTS 现在已经能讲几十种语言。
用中文写稿，系统自动翻译成英文、日语、法语再合成，一个声音说多国语言。
对做跨境电商、出海内容的团队来说很实用。

语音识别：让声音变成文字

语音识别就是自动语音识别，简称 ASR。
它和合成互为逆过程：合成是文字变成声音，识别是声音变成文字。

谁在用

开会录音转纪要、播客出字幕、访谈快速出稿、课堂录音变笔记、微信语音转文字。
这些场景都用得上语音识别。

工具在变强

以前的语音识别只能输出一段没标点的文字，谁说了什么都分不清。
现在的 ASR 可以自动加标点、区分不同说话人、给每句话打时间戳直接生成字幕文件。
对于 中文专业术语识别不准 的问题，还能设置热词，告诉系统哪些词比较重要。

门槛在降低

以前要用语音识别，得自己部署模型、调参数。
现在上传文件等几秒钟就能拿到结果。

从单点到平台：青萍AI语音

说了这么多，自己搭一套语音合成加语音识别并不轻松。
一个平台把这两件事都做了，才是省心的方案。

青萍AI语音就是这样的平台。
它同时覆盖了语音合成和语音识别两个方向。

合成这边：
音色克隆上传录音就行，11 种语言支持自动翻译再合成。
配音工作台左侧写稿、右侧调参数、底部播预览，多人对话模式几分钟就能产出播客。
多音字手动校对功能也是标配，生成前把所有多音字标出来，点一下就能改。

识别这边：
上传音频或视频文件，自动提取对话内容，输出可编辑的文字。
支持多人对话识别，自动标注谁说了什么、什么时候说的。
结果可以带时间戳导出 SRT 字幕，导入剪映直接能用。
支持 MP3、WAV、MP4、MOV 等常见格式，视频文件上传后自动提取音轨，不用手动转格式。

还有真人兜底。
AI 不是万能的，遇到高端宣传片、品牌广告这类场景，平台上有上百位配音老师可以约。
AI 做初稿、真人做精修，两种模式灵活切。

无论你是工作室做短视频、团队管内容、自己折腾 AI 项目，一个平台搞定语音的进和出，省下来的时间是实打实的。

前往 audio.lusyoe.com 即可体验。

做漫剧的朋友大概都经历过这种崩溃：画面调好了，节奏卡准了，就差配音。
找配音员试音，声音合适的排期排到两周后，有档期的声音又不搭。
自己录吧，没隔音环境，出来的效果跟语音备忘录差不多。
用AI合成，角色说话跟念课文似的，没有情绪起伏，观众听两句就划走了。

漫剧配音的痛点集中在三件事。
角色多，一部漫剧动辄十几个角色，每个都要不同的声线和语调。
找齐合适的配音员就是个大工程。
改动频繁，台词改了就得重新录，配音员的时间你控制不了。
一个字改了可能要等两天。
情绪表达，AI合成的语音太平，遇到哭戏、吵架、低声下气这些场景完全撑不住。

青萍AI语音，一站搞定漫剧配音

青萍AI语音是一个AI和真人双引擎的语音创作平台，官网地址 audio.lusyoe.com。
不管是AI批量生成配音，还是找专业真人配音员精修，都在一个平台上完成。

克隆音色。
上传 3 到 10 秒的声音样本，AI就能精准复刻这个人的声音特征。
音色、语调和情感风格都能保留。
你可以为漫剧里的每个角色建立专属音色，主角、配角、反派各一个声线，互不干扰。
克隆一个音色只需要 5 秒左右，一部漫剧的角色音色库，半小时就能搭好。

设计音色。
不想用真人声音，也可以从零设计一个虚拟音色。
通过参数调节音高、音色、语速，打造出你需要的声音类型。
萝莉音、大叔音、反派低沉嗓音，参数调一调就能生成，不用四处找声源。

配音生成。
把台词输入进去，选好角色音色，点击生成就行。
支持批量生成，一集漫剧十几段台词，几分钟就能全部搞定。

平台内置多音字检测功能，生成前手动确认读音。
比如避免把”音乐”的”乐”读成”快乐”的”乐”。

情绪参数。
漫剧配音最怕的就是”一个情绪演到底”。
青萍AI语音支持为每段台词单独设定情绪参数，愤怒、悲伤、平静、兴奋都能调。
同一段台词切换不同情绪，出来的效果完全不一样。
吵架场景拉满愤怒值，独白选悲伤模式，情绪到位了观众才会真正代入。

真人配音服务

有些场景AI确实拿不准，比如高张力的哭戏、方言演绎、或者品牌级项目的品质要求。

青萍AI语音接入了大量专业配音员，每位都有独立主页和样音展示。
你可以直接在线试听，找到合适的再下单，拿不准还能让多人免费试录一小段。

价格按 100 字计费，从几块钱到几十块都有，丰俭由人。

AI做初稿批量出活，真人做精修保证质量，两种模式灵活切换。
漫剧制作周期紧的时候先用AI出初版，关键场景再交给真人精修，效率和质量都不耽误。

开始使用

网页版访问 audio.lusyoe.com 注册即可使用。
另外微信小程序版也已上线，搜索”青萍叙事创作工具”就能找到。
关注公众号「青萍叙事」，回复邀请码，通过邀请码注册可免费获得 120 积分。
最多可生成 5.1 万字配音，够你把克隆音色、配音生成这些核心功能都体验一遍。

写内容有个尴尬的阶段：写一篇文章不难，但是从写完到发布，中间有一堆琐事。

审查格式、修破折号、生成封面图、压缩上传、git 提交。
每篇都来一遍，烦不烦？
烦。

所以我把这个过程做成了一条自动化生产线。
用 Hermes Agent 的 Profile 系统和多 Agent 协作，从写完文章到发布，一条指令搞定。

目前跑下来效果不错，写出来分享一下。

整条生产线长什么样

流程分成 6 个步骤，全部用 Hermes 的 delegate_task 串起来：

写作，内容审查，修复，二次审查，封面图生成与上传，发布。

每个步骤都是独立的 Agent，互不干扰。
写作阶段我在主会话里完成，后面的脏活累活丢给子 Agent 去跑。

核心思路很简单：把以前手动做的事情，写成可重复的 Agent 工作流。

内容审查：让人工智能检查人工智能

这是整个流程里最重要的一环。
Hermes 写文章有时候会带点 AI 腔，写多了还会漏掉格式规范。

审查 Agent 专门用 deepseek-v4-pro 模型，因为审查对细节敏感度要求高，普通模型的注意力不够。
它带着整篇文章和完整的写作规范清单去逐行检查，发现的问题按严重程度标注：

• 🔴 必须修。比如破折号、角括号、分割线。
• 🟡 建议修。比如一句多行、标题内容不匹配。
• 🟢 可优化。比如代码示例不完整、字段缺失。

审查 Agent 不写临时文件，结论直接 return 给我。
修完一轮还得二次审查，确保前面改的问题没有漏网之鱼，也没有因为改东西引入新问题。

这个双轮审查机制救了我好几次。
有一次 ai 字段里写了 RuntimeError: Executor shutdown has been called，其中的冒号加空格让 YAML 解析直接挂了，审查 Agent 一眼就发现了。

封面图：从 HTML 到 CDN 的最后一公里

文章定稿后，封面图生成是个独立步骤。

Hermes 的 cover-image-generator skill 负责这件事。
它用一套 HTML 模板拼接文章信息：标题、副标题、Logo、标签，然后用 Playwright 调用系统的 Chrome 浏览器截图。

说起来简单，但踩过不少坑。
之前用的渐变背景看起来太廉价，后来改成纯色深底加 Logo 大字的风格，顺眼多了。
Logo 统一从 jsdelivr 拉 CDN 版本，Hermes 系列文章用绿色强调色。

截图出来是 3840x2160 的 PNG，用 cwebp -q 75 压到 50KB 左右的 WebP，再调用青萍图床的 API 上传。

封面和配图能稳定上线，全靠青萍图床这个基础设施。
它是面向内容创作和电商设计的图片管理平台，官网在 img.lusyoe.com。
上传后自动分配 CDN 加速地址，不需要自己搭 OSS 或折腾 Nginx。
整个生产线里，封面图、内文配图、产品展示图，都走这一条链路。

这里有个有意思的设计：封面图生成后不自动上传，等我说了 上传 才执行。
因为截图效果好不好，我得先看一眼。

content-publisher：收尾一步交给专用 Agent

封面图上传到 CDN、写入文章的 cover 字段后，发布是收尾。

这一步我单独拆了一个 content-publisher 专用 Agent。
发布到个人博客（Hexo）时，它的职责很单一：git add、git commit、git push。
不多不少。

但它不止管博客。
同一条内容，可以一键分发到知乎、博客园、微信公众号、今日头条等多个渠道。
每次调用时指定目标渠道，content-publisher 自动适配对应的格式和发布方式。

为什么不用主 Agent 直接操作 git？
两个原因。
一是权限隔离，发布 Agent 只需要终端和文件工具的权限，没有理由给它更多。
二是专注性，主 Agent 可以花很长时间研究文章内容，发布 Agent 只做一件事，不会分心。

从 delegate_task 调过去时，带上 git 仓库的地址和凭据，它几秒钟就搞定了。
我这边继续写下一篇文章，它后面默默把发布跑完。

这条生产线给我带来了什么

以前发一篇文章，从写完到上线，怎么也得 15 到 20 分钟的收尾工作。

现在写完文章说一句 帮我走流程，然后等着就行。

审查 Agent 找出问题，我确认修复。
封面图生成后看一眼效果，确认上传。
发布 Agent 推完代码，回来告诉我 commit SHA。

省下来的时间不多，但每篇都省一点，积少成多。
说白了，那些枯燥的重复劳动不用我自己干了。
机器擅长的事就交给机器，人只做需要判断的事。
这大概就是自动化最朴素的价值。

昨天手痒，给 Hermes Gateway 换了个新模型。
结果飞书那边突然就收不到消息了。

第一反应是：换模型搞坏了？
赶紧查 Gateway 日志，看到了这么一行：

1

RuntimeError: Executor shutdown has been called

飞书的 WebSocket 连接也断了，Gateway 看起来还在跑，但实际上已经是个空壳。

排查：先看 Gateway 日志

1
2
3
4
5

2026-06-09 14:23:45 INFO  Gateway started
2026-06-09 14:23:46 INFO  Feishu WebSocket connected
...
2026-06-09 15:34:12 ERROR RuntimeError: Executor shutdown has been called
2026-06-09 15:34:12 ERROR Feishu WebSocket connection lost

Gateway 14:23 启动，15:34 报错，刚好运行了 1 小时 11 分钟。

这个时间点很微妙，不是刚启动就挂，而是运行了一段时间后才出问题。
换模型的操作发生在 15:30 左右，看起来像是换模型触发了问题，但实际上根因不在这里。

根因：Python asyncio executor 的生命周期陷阱

Gateway 是 Python 写的，核心用的是 asyncio event loop。
问题出在 run_in_executor 这个调用上。

Python asyncio 的 loop.run_in_executor() 会把同步代码丢到线程池里执行。
默认情况下，它用的是 event loop 自带的 ThreadPoolExecutor。
这个 executor 的生命周期管理有个坑：

如果 executor 的引用计数归零，Python 的垃圾回收器会把它清理掉，调用 shutdown()。

在长时间运行的服务里，这种情况可能悄无声息地发生：

1
2
3
4
5
6

# 这段代码可能出问题
async def call_llm(prompt):
    loop = asyncio.get_event_loop()
    # 如果 executor 被 GC 回收，这里就会报错
    result = await loop.run_in_executor(None, sync_llm_call, prompt)
    return result

日志里的 Executor shutdown has been called 就是这么来的。
executor 被关了，所有依赖它的异步任务都会失败，飞书的 WebSocket 消息处理自然也跟着挂了。

加上 macOS 的内存压力管理（memory pressure），长时间运行的 Python 进程更容易触发这类内部状态异常。
系统可能在后台杀掉了一些不活跃的线程，导致 executor 的内部状态被破坏。

发现问题：`–replace` 的坑

最直接的办法就是重启：

1

hermes gateway start

重启后飞书消息恢复正常。
但这只是临时方案，后面还会遇到同样的问题。

这里又踩了一个坑，我发现之前的 Gateway 是用 --replace 模式启动的：

1

hermes gateway start --replace

--replace 的作用是如果已有 Gateway 在跑，先杀掉再启动新的。
听起来很方便对吧？
但在 macOS 上，如果你用了 launchd 来管理服务，--replace 会导致冲突。

Gateway 被 launchd 拉起来后，你手动 --replace 启动一个新的，launchd 不知道旧的被杀了，新旧进程就会打架。

最佳实践：用 launchd 托管 Gateway

macOS 上管理后台服务，launchd 是正道。
先看看现有的配置：

1

ls ~/Library/LaunchAgents/ai.hermes.gateway-*.plist

1
2

/Users/lu/Library/LaunchAgents/ai.hermes.gateway-default.plist
/Users/lu/Library/LaunchAgents/ai.hermes.gateway-work.plist

每个 profile 有一个对应的 plist 文件。
看看里面写了什么：

1

cat ~/Library/LaunchAgents/ai.hermes.gateway-default.plist

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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>ai.hermes.gateway-default</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Users/lu/.hermes/bin/hermes</string>
        <string>gateway</string>
        <string>start</string>
        <string>--replace</string>   <!-- 问题在这 -->
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <dict>
        <key>SuccessfulExit</key>
        <false/>
    </dict>
</dict>
</plist>

看到了吧，ProgramArguments 里赫然写着 --replace。
这就是问题所在。

批量修复 plist 配置

检查了一下，所有 profile 的 plist 都有这个问题。
手动改太慢，写个脚本批量处理：

1
2

# 查看所有有问题的 plist
grep -l "\-\-replace" ~/Library/LaunchAgents/ai.hermes.gateway-*.plist

1
2

/Users/lu/Library/LaunchAgents/ai.hermes.gateway-default.plist
/Users/lu/Library/LaunchAgents/ai.hermes.gateway-work.plist

批量移除 --replace：

1
2
3
4
5

for plist in ~/Library/LaunchAgents/ai.hermes.gateway-*.plist; do
    # 移除 --replace 那一行
    sed -i '' '/<string>--replace<\/string>/d' "$plist"
    echo "Fixed: $plist"
done

重新加载所有 launchd 服务：

1
2
3

# 先卸载再加载
launchctl unload ~/Library/LaunchAgents/ai.hermes.gateway-*.plist
launchctl load ~/Library/LaunchAgents/ai.hermes.gateway-*.plist

新版 macOS 上 unload/load 已标记为 legacy，推荐用 bootout/bootstrap：

1 2	launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/ai.hermes.gateway-*.plist 2>/dev/null launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/ai.hermes.gateway-*.plist

验证一下：

1

launchctl list | grep hermes

1
2

ai.hermes.gateway-default    0    com.apple.xpc.launchd.oneshot.0x10000001.hermes
ai.hermes.gateway-work       0    com.apple.xpc.launchd.oneshot.0x10000002.hermes

状态码是 0，说明正常运行。

踩坑后的教训

asyncio executor 的坑要提前防。

长时间运行的 Python 服务，executor 的生命周期不能完全交给垃圾回收器。
要么显式持有 executor 的引用，要么定期检查 executor 状态。

1
2
3
4
5
6
7
8
9

# 显式持有 executor 引用
class Gateway:
    def __init__(self):
        self._executor = ThreadPoolExecutor(max_workers=4)
        self._loop = asyncio.get_event_loop()
        self._loop.set_default_executor(self._executor)
    
    async def call_in_background(self, func, *args):
        return await self._loop.run_in_executor(self._executor, func, *args)

macOS 服务必须用 launchd 托管。

别用 nohup 后台跑。
别用 --replace。
别用 screen 或 tmux。
launchd 是 macOS 原生的服务管理器，它会帮你处理进程崩溃重启、开机自启、资源限制等问题。

关键配置点：

• RunAtLoad=true：登录时自动启动
• KeepAlive.SuccessfulExit=false：正常退出不重启，异常退出才重启
• 不要加 --replace：让 launchd 管理进程生命周期

遇到连接问题先查日志。

飞书消息发不出去，原因可能很多：网络问题、token 过期、服务挂了……
别上来就重启，先看日志。
日志里的错误信息通常能直接指向问题根因。

1
2
3
4
5

# 查看 Gateway 最近日志
tail -100 ~/.hermes/logs/gateway-default.log

# 查看 launchd 的日志
log show --predicate 'processImagePath contains "hermes"' --last 1h

这次排查让我对 Python asyncio 的底层机制有了更深的理解。
asyncio 不是银弹。
executor 管理、事件循环生命周期这些细节，在开发阶段很难暴露，往往要跑到生产环境、运行一段时间后才会出问题。

好在这次只是飞书消息发不出去，不是什么致命故障。
但也提醒我，对于长时间运行的服务，监控和容错设计真的不能偷懒。