Hermes Agent 架构解析：从一次性工具到自进化系统

发表于 2026-04-19 分类于技术

Hermes Agent 架构解析：从一次性工具到自进化系统

先给出结论：Hermes 强，不是因为模型强，而是因为它把“AI 从一次性工具，变成了可积累的系统”。

以下从“架构层级”拆解其核心设计逻辑。

一、解决行业级痛点：AI“失忆”问题

传统 AI 交互面临的最大问题是“无状态”：每次对话重新开始，上下文依赖拼接。Hermes 通过持久记忆（Structured Memory），结构化地存储项目上下文与个人习惯。

二、核心差异化：自进化闭环

Hermes 构建了闭环：任务 -> 执行 -> 评估 -> 抽象 -> 生成 Skill -> 下次复用。系统将“过程”转化为“固有能力”，下次直接调用。

三、Agent Operating System (Agent OS)

Hermes 是一个 Agent Runtime，架构分三层：

Agent 执行层：推理、工具调用。
平台层：CLI / Gateway、调度。
持久层（核心）：Memory、Skills、Profile。

四、模型无关 (Model Agnostic)

支持 OpenAI, Claude, GLM, Ollama 等 200+ 模型，将“模型”变为可替换组件。

五、从“认知系统”升级为“行动系统”

普通 AI：你问 -> 它答。
Hermes：你说目标 -> 它执行（写代码、调终端、操作文件）。

六、能力公式与复利效应

能力 = 模型 × (记忆 + 技能 + 工具 + 时间)

随着使用时间增长，系统呈现复利效应。

七、针对技术团队的落地价值

流程资产化：将流程变成可复用的 Skill。
系统拥有者：从工具使用者变为 Agent 拥有者。
落地架构：构建”AI 提案自动评审系统”。

八、局限性与冷思考

初期较弱（缺乏积累）。
依赖高质量流程引导。
LLM 本质（幻觉风险）。

总结：Hermes Agent 的本质，是将 AI 从“函数调用”升级成“长期运行的状态系统”。

一文读懂：AI 界的“判断大师”——逻辑回归算法

摘要：逻辑回归（Logistic Regression）是机器学习中最经典的分类算法。本文从线性回归的局限性出发，深入解析 Sigmoid 函数的作用机制、对数损失函数的原理及其在工业界的广泛应用。

1. 为什么不能直接用线性回归做分类？

线性回归擅长预测连续数值，但在面对“非黑即白”的分类问题（如垃圾邮件检测、肿瘤良恶性判断）时，它会遇到两个致命问题：

数值越界：线性回归的输出范围是 $(-\infty, \infty)$，而分类问题的概率必须限制在 $[0, 1]$ 之间。
对异常值敏感：极端值会严重拉偏拟合直线，导致分类边界失效。

为了解决这个问题，我们需要一种方法，将线性回归的无限输出“压缩”到 0 和 1 之间。

💡 核心概念：
逻辑回归：一种广义的线性模型，虽然名字带有“回归”，但主要用于解决二分类问题。

2. 核心魔法：Sigmoid 函数

逻辑回归的核心在于引入了 Sigmoid 函数（也称 S 型函数）。

$$y = \frac{1}{1 + e^{-z}}$$

这个函数的形状像一个平滑的”S”。它的特性是：无论输入的 $z$ 是多大的正数或负数，输出结果永远被严格限制在 $(0, 1)$ 区间内。

3. 算法的底层逻辑

逻辑回归的运作可以看作“线性回归 + Sigmoid 外衣”：

第一步：线性打分

计算特征的线性组合：$z = w_1x_1 + … + w_nx_n + b$。

第二步：概率转化

将 $z$ 输入 Sigmoid 函数，得到概率 $P$。例如 $P=0.85$ 表示模型认为该样本属于正类（如恶性肿瘤）的概率是 85%。

第三步：决策

设定阈值（通常为 0.5）。若 $P \ge 0.5$ 则判定为 1，否则为 0。

4. 模型训练：对数损失函数

在逻辑回归中，均方误差（MSE）不再适用，因为加上 Sigmoid 函数后，损失曲面会变得非凸，难以优化。因此，逻辑回归采用对数损失函数（Log Loss / Cross-Entropy Loss）。

其核心逻辑是“惩罚盲目自信的错误”：

如果真实标签是 1，而模型预测概率是 0.01（极其自信地认为是 0），损失函数会给出极大的惩罚值。
模型通过梯度下降法不断调整参数，以最小化这种惩罚。

5. 优缺点分析

优势

输出概率：不仅给出分类结果，还提供置信度。这在医疗诊断、金融风控等领域至关重要。
计算高效：训练和推理速度极快，占用资源少，常作为工业界（如推荐系统粗排）的基线模型（Baseline）。
可解释性强：权重 $w$ 直接反映了特征的重要性。

局限性

线性边界：逻辑回归本质上只能学习线性决策边界。面对非线性可分数据（如异或问题），单纯使用逻辑回归效果不佳，需要配合复杂的特征工程。

6. 总结

从预测数值的线性回归，到预测概率的逻辑回归，这是理解机器学习决策过程的关键一步。尽管深度学习模型日益强大，但逻辑回归凭借其出色的效率与可解释性，依然是现代互联网架构中不可或缺的基石。

如果你觉得这篇文章有帮助，欢迎分享给需要的朋友。

一文读懂线性回归算法

摘要：线性回归（Linear Regression）是机器学习领域最基础、最经典的算法。本文将从直观案例出发，系统梳理其数学原理、优化过程以及工程实践中的优缺点。

1. 什么是线性回归？

线性回归是监督学习中最基础的算法之一。它的核心思想是：假设输入特征 $x$ 与输出目标 $y$ 之间存在线性关系，通过历史数据拟合出一条最优的直线（或超平面），从而对未知数据进行预测。

一个直观的例子是房价预测：

横轴表示房屋面积，纵轴表示成交价格
历史数据点大致排列成一条向右上倾斜的直线
线性回归的目标就是找到这条“最优拟合线”

💡 核心概念：
线性（Linear）：假设特征与目标之间存在线性关系（特征增加，目标按比例变化）。
回归（Regression）：寻找数据内在规律的过程，输出连续值。

2. 数学模型

线性回归的数学本质是一元一次方程的扩展。

2.1 一元线性回归

$$y = wx + b$$

其中：

$y$：目标变量（标签），需要预测的结果（如房价）
$x$：特征（输入），已知信息（如房屋面积）
$w$：权重（Weight），直线的斜率，代表特征的重要程度
$b$：偏置（Bias），直线的截距，表示基础值

2.2 多元线性回归

当影响目标的因素不止一个时（如面积、房间数、楼层、学区等），公式扩展为：

$$y = w_1x_1 + w_2x_2 + … + w_nx_n + b$$

或用向量形式表示：

$$y = \mathbf{w}^T\mathbf{x} + b$$

3. 模型训练：机器如何”学习”？

训练线性回归模型的核心是寻找最优的 $w$ 和 $b$，使得预测值与真实值的误差最小。

3.1 损失函数：衡量预测误差

最常用的损失函数是均方误差（Mean Squared Error, MSE）：

$$MSE = \frac{1}{n}\sum_{i=1}^{n}(y_i - \hat{y}_i)^2$$

其中 $y_i$ 是真实值，$\hat{y}_i$ 是预测值。MSE 越小，模型拟合效果越好。

3.2 梯度下降法：参数优化

梯度下降（Gradient Descent）是最常用的优化算法：

随机初始化 $w$ 和 $b$
计算当前参数下的损失函数梯度
沿梯度反方向更新参数，步长由学习率 $\alpha$ 控制
重复上述过程，直到损失收敛

$$w := w - \alpha \frac{\partial MSE}{\partial w}$$
$$b := b - \alpha \frac{\partial MSE}{\partial b}$$

4. 优缺点分析

优势

可解释性强：相比深度学习的“黑盒”模型，线性回归的公式一目了然，可以清晰地解释每个特征对结果的影响程度。
计算效率高：不需要大量算力，训练和推理速度都很快，适合轻量级任务和初步数据探索。
实现简单：几乎所有机器学习库都内置了线性回归实现。

局限性

只能建模线性关系：如果数据的真实关系是非线性的（如年龄与身高的关系），线性回归的拟合效果会很差。
对异常值敏感：极端值会显著影响拟合直线的方向，通常需要进行数据清洗或使用鲁棒回归。
多重共线性问题：当特征之间存在强相关性时，权重估计可能不稳定。

5. 总结

在如今动辄千亿参数的 Transformer 大模型时代，线性回归显得朴素而经典。但正是从 $y = wx + b$ 这个简单的等式开始，人类赋予了计算机从历史数据中总结规律、并预测未来的能力。理解线性回归，是通往整个机器学习领域的必经之路。

如果你觉得这篇文章有帮助，欢迎分享给需要的朋友。

匈牙利算法简介：从二分图匹配到任务分配

发表于 2026-04-16 分类于技术

匈牙利算法（Hungarian Algorithm）是组合优化领域最经典的算法之一，用于解决两类核心问题：二分图最大匹配和任务分配问题。它由匈牙利数学家 Dénes Kőnig 和 Jenő Egerváry 的理论奠基，后由 Harold Kuhn 于 1955 年正式提出。

什么是二分图？

在深入算法之前，我们需要先理解几个基本概念。

二分图（Bipartite Graph）是一种特殊的图结构，它的顶点可以被划分为两个互不相交的集合 U 和 V，使得图中的每一条边都连接 U 中的一个顶点和 V 中的一个顶点。

简单来说：二分图中的边只会”跨界”连接，不会在同一个集合内部连接。

匹配（Matching）是指图中一组没有公共顶点的边。换句话说，每个顶点最多只被一条边选中。

最大匹配就是包含边数最多的匹配。

匈牙利算法（二分图匹配版）

这是最常见的”匈牙利算法”，用于求解二分图的最大匹配。

核心思想：增广路

匈牙利算法的核心定理是 Berge 增广路定理：

一个匹配是最大匹配，当且仅当图中不存在增广路。

增广路（Augmenting Path）的定义：

路径的起点和终点都是未匹配的顶点
路径上的边交替出现”未匹配边”和”已匹配边”

增广路有一个神奇的性质：如果我们将增广路上所有边的状态取反（匹配变未匹配，未匹配变匹配），匹配的边数会增加 1。

算法步骤

1. 初始化匹配为空
2. 对于每个未匹配的左部顶点 u：
   a. 从 u 开始搜索增广路（DFS/BFS）
   b. 如果找到增广路，翻转路径上的边，匹配数 +1
   c. 否则，u 无法匹配
3. 重复直到所有顶点都尝试过

Python 实现

def hungarian_bipartite(graph, n_left, n_right):
    """
    graph: 邻接表，graph[u] = [v1, v2, ...] 表示左部顶点 u 可以匹配右部的 v1, v2...
    n_left: 左部顶点数
    n_right: 右部顶点数
    返回: 最大匹配数
    """
    match_right = [-1] * n_right  # 右部顶点的匹配对象
    visited = [False] * n_right
    
    def dfs(u):
        for v in graph[u]:
            if not visited[v]:
                visited[v] = True
                # 如果 v 未匹配，或者可以为 match_right[v] 找到新的匹配
                if match_right[v] == -1 or dfs(match_right[v]):
                    match_right[v] = u
                    return True
        return False
    
    count = 0
    for u in range(n_left):
        visited = [False] * n_right
        if dfs(u):
            count += 1
    return count

# 示例：4 个男生，4 个女生，边的关系如下
graph = {
    0: [0, 1],      # 男生 0 可以和女生 0, 1 匹配
    1: [1, 2],      # 男生 1 可以和女生 1, 2 匹配
    2: [2, 3],      # 男生 2 可以和女生 2, 3 匹配
    3: [3],         # 男生 3 可以和女生 3 匹配
}
print(hungarian_bipartite(graph, 4, 4))  # 输出: 4（完美匹配）

匈牙利算法（任务分配版）

另一种”匈牙利算法”用于解决带权二分图的最小/最大权匹配问题，也称为 Kuhn-Munkres 算法 或 分配问题算法。

问题描述

有 n 个工人和 n 项任务，每个工人完成每项任务的成本不同。如何分配才能使总成本最小？

这就是经典的任务分配问题，可以用一个 n×n 的代价矩阵表示。

算法步骤

1. 每行减去该行的最小值
2. 每列减去该列的最小值
3. 用最少的线覆盖所有零
   - 如果线数 = n，找到最优分配，算法结束
   - 否则，调整矩阵，返回步骤 3

时间复杂度

任务分配版的匈牙利算法时间复杂度为 **O(n³)**，在多项式时间内解决了这个组合优化问题。

应用场景

场景	算法版本	说明
红娘匹配	二分图匹配	男女配对，使配对数最大
任务分配	任务分配版	工人-任务最优分配
航班-登机口分配	任务分配版	最小化总等待时间
目标跟踪	任务分配版	多目标与多检测的最优关联
课程安排	二分图匹配	教师-教室-时间匹配

复杂度分析

二分图匹配版：O(V×E)，其中 V 是顶点数，E 是边数
任务分配版：O(n³)，其中 n 是矩阵维度

总结

匈牙利算法虽然有两个不同的版本，但它们都源于同一个数学理论：二分图的完美匹配理论。理解增广路的概念是掌握这个算法的关键。

无论是简单的二分图匹配，还是复杂的任务分配问题，匈牙利算法都提供了一个优雅且高效的解决方案。

延伸阅读：

《算法导论》第 26 章：最大流
Harold W. Kuhn, “The Hungarian Method for the Assignment Problem” (1955)
网络流算法（Dinic、Edmonds-Karp）

go语言内存分析

最新看了一下go语言，感觉语言设计的比Java要好一些，底层实现了对并发的支持。
他的内存结构和内存回收跟Java的模型也有很大的不同，抽空写一下go语言的内存分析，后续也会写一篇G1和GMS用来坐对比。

nginx使用try_files配置vue

组内的小伙伴最近独立开发的一个项目，前端使用VUE，路由模式使用history。
部署时发现无法访问，自己研究半天后，无法解决，向我寻求帮助，发现是他的nginx配置错误

其实 vue router 的文档里有部署方式，https://router.vuejs.org/zh/guide/essentials/history-mode.html#%E6%9C%8D%E5%8A%A1%E5%99%A8%E9%85%8D%E7%BD%AE%E7%A4%BA%E4%BE%8B
服务器配置示例：
location / {
try_files $uri $uri/ /index.html;
}

随手写篇文章记录一下，nginx的location下的配置中
root，alias，try_files 区别，未来有时间可以写一篇nginx的深入文章，包含负载均衡、双机热备、缓存等高级功能。

root:
location /test/ {
root /var/www/image
}
若按照上述配置的话，访问/test目录里面的文件时, nginx会自动去/var/www/image/test去找。

alias:
location /test/ {
alias /var/www/image/
}
若按照上述配置的话，访问/img目录里面的文件时, nginx会自动去/var/www/image目录找文件, 也就是不会把后缀带上，常用来配置静态文件。

try_files:
location /test/ {
try_files $uri $uri/ /index.html;
}
try_files 会到硬盘里尝试找这个文件, 找不到，就会 fall back 到 try_files 的最后一个选项index.html,将请求转发返回index.html上，然后html里的vue router再去跟去后缀路由对应的页面。

至此，完成history的转发。

升级成了WIN11

年前公司给换了笔记本电脑，之前在公司一直用的是MACP15款。个人是更偏向苹果系统的，但是无奈老机子太卡了。
申请换电脑时，只能申请win笔记本了。拿到手后是win10，自己下载升级成了win11。

刚用11时，感觉很惊喜，跟MAC用起来很像，又能解决MAC的一些老软件兼容性问题，虽然小BUG比较多。

写一个系统的问题和小技巧吧，会持续更新这个文章

1，在执行shell命令时，报在此系统上禁止运行脚本。

解决方案，管理员身份打开终端，执行 set-ExecutionPolicy RemoteSigned 解决

2，可以直接下载Linux，在应用市场搜索ubuntu。

3，如果下载视频是ev4加密视频的话，建议购买使用正版命令打开。（临时需要可以找我破解，python解密）

4，自带粘贴板记录功能 win + v 打开

5，自带多功能截图 win + shift + s

6，带多桌面功能，触控板可以设置的跟MAC一样。

记一次mybatis引起的线上OOM

最近在忙着加班+找房换租的窝，所有很久没写博客，社畜的艰苦生活，哈哈

言归正传，最近线上一个小项目，出现了特殊的OOM情况，很有意思，所以跟大家分享一下

奇特的内存溢出现象

项目背景：

公司有某个线下零售业务部门，有POS一千台左右，业务和门店还在持续扩张中。业务现有的CRM和POS修改起来较为困难(全为供应商标准系统)。
业务有个中间件，用于接受POS的一个结账前的会员信息请求，转发到SRM系统获取基础信息后，然后查数据库表做数据加工后再返回POS，以此来做双方系统的自定义配置。(个人不认可这种方案)
这个小项目是由我们组的一个小伙伴完成开发，压测完成后部署在阿里云上，2台ECS做了负载均衡。

溢出现场:

项目上线后，间隔一段时间后，用户反馈POS有些门店请求报错。上服务器查询日志发现报了内存溢出，项目已经被守护进程自动重启，无法查看溢出时内存具体成分。查看代码报错，是请求导致的OOM报错。结合之前的日志分析发现，崩溃前已经发生多次内存无法回收的异常。查看ECS的监控，发现内存是缓慢上升的。断定发生了内存泄漏。
监控了一段时间后，发现被重启后应用，内存依旧在缓慢上升。并发高发时间段是在晚上7-8点，而内存溢出发生在晚上9点多。所以也并不是并发引起的。思考这种内存无法释放的缓慢OOM，单靠增加内存或者JVM调优是很难解决的，应该是小伙伴的代码中有对象没有及时释放导致的，此时已经晚上十点多，门店已经关店，无法观察内存变化，而且之前压测也没有出现OOM。考虑有可能需要长压测来让内存缓慢累计，所有起了压测程序，参数并发调低，压测时间改为连续3小时。等待明早观察成果。

问题定位

早上发现内存回收正常，尝试分析内存内容。无法复现的异常，很难解决，尝试观察内存状况。
先用 jmap -histo 在服务器上查看哪些对象内存占用异常。
结果发现都是 char 并无异常。于是打开窗口连接2台服务器，持续监控2台机器的内存状况。同时打开代码，找寻可能异常点。
（最小化接着做其他的事情）
中午左右，观察到其中一台服务器内存持续上升。立刻将负载均衡全部切换到另一台上，保护现场防止再崩溃。
开始处理分析内存内容：
1，使用 jmap -histo 在服务器上查看内存中哪些对象异常。
发现除了 char map 这些基础类，还有 CurrentHashMap 占用很多。
CurrentHashMap ？采用了数组+链表+红黑树的实现方式来设计，内部大量采用CAS操作，是线程安全性的map，锁的颗粒度是到数组。因为该项目并不涉及到多线程，找寻项目代码果然没有这方面的引用。
2, 发现不能迅速定位，先保存下内存状态。使用 jmap -dump:format=b,file=文件名 [pid] 将内存数据导出成二进制文件。
下载下来后，重启服务，调回负载均衡。
3，使用 java 自带 VisualVM 来分析内存中的类及其引用。
发现大量的char和原始值引用指向CurrentHashMap，同时存在某个 entity 占用也过多。
这时想到 mybatis 源码是将数据映射成map，处理并发时应该会有CurrentHashMap。正好也和某个实例占用过多吻合。
打开 mybatis 源码发现在一级缓存和二级缓存，果然是使用 CurrentHashMap 来接收缓存的。
难道缓存没释放？
mybatis 一级缓存是SqlSession内的，二级缓存是基于namespace。如果是缓存没释放那我将二级缓存关闭试试。于是将二级缓存配置关闭。配置数据库请求超时时间后。
本地压测通过（之前压测就无法复现），打包发布至其中一台服务器，做个对比验证。

问题解决

以为问题已经解决，安心下班，晚上收到运维小伙伴反馈，服务器内存报警了。
–”，还是我新发布的那台。立刻上线查看，还是内存缓慢溢出。缓存已经关闭了，还是大量的引用指向CurrentHashMap？
这难道不是缓存引起的？那还有什么能够让CurrentHashMap撑爆内存？
没关系，已经定位到是mybatis的问题了，下面应该从SQL入手去看看，有没有什么SQL的异常。
看了对应namespace的sql，咦？这个sql写的有点怪，把id包在if判断里也正常，难道id也有可能不存在，如果id不存在，那这个sql就会变成全部查询？
那也会超时被断开呀？没怎么用过oracle，难道真的是这里？
戴着疑问，我让DBA把表发给我，oracle的自增id是DBA自己用触发器生成，但是真的会有业务数据没有id嘛？我跑了sql查了一下，真的！！！有极个别几个用户的在业务表id居然是null。
突然间豁然开朗，一切问题都能解释通了。
小伙伴代码有个基于id的查询，没有判断id是否为空（id还有为空的？算了不想吐槽了）。id传到mapper时，查询条件被过滤掉，形成了一个全表查询。
oracle的查询是流式缓慢吐出数据，所以照成内存缓慢增加，因为id为空是极个别现象所以照成了内存溢出是随机的现象。
mybatis 查询sql会先把值存在缓存里，所以分析内存时，发现缓存中的CurrentHashMap引用大量entity，占据内存不释放。

到此问题原因已经找到，于是在查询前，增加了一个id为空的判断，发布后监控内存状况。

第二天，果然没有再出现内存泄漏问题，于是问题解决（小伙伴和DBA关于id为空撕逼中）。

过程中忘了截图，没有图大家将就着看吧，过程中主要用到了jmap的相关命令、VisualVM内存分析、mybatis源码和自己敏锐的问题觉察能力

hexo+GitHub 搭建博客 1/119

发表于 2021-11-09

hexo+GitHub 搭建博客

基础环境：nodejs

本文用使用示例是github，同样的操作也可用于gitee，但我在实际操作的过程中发现gitee需要实名手持身份证拍照审核，觉得麻烦随之放弃

1, 新建仓库

github上新建代码仓库，用来存储博客

注意，项目名字使用你的github名字加 .github.io  后缀，比如我的GitHub名称是liu-xiaoran,n那么我的项目名字就是 liu-xiaoran.github.io 点击创建完成操作，注意不要勾选add Readme file 和其他选项，这个可以后续自行添加，空白的仓库库有助于git的第一次推送合并。

2, 配置博客访问

跳转到刚刚新建仓库首页，也厚点击上方菜单栏的 Settings ,再点击左边栏位的 Pages , 填写对应的pages设置。

Source 那里默认是 root, 点击选择Theme Chooser，选择一个主体，点击保存。
此时你通过填写的仓库名，如 liu-xiaoran.github.io 就可以访问到该博客地址。

3, 配置域名访问

配置域名访问和配置https的方式，打开你的域名解析控制台，如我的阿里云域名配置页面。

配置CNAME，指向你的博客访问地址，如liu-xiaoran.github.io。

配置结束后，返回github的pages配置页面，填写上域名，自动生成CNAME文件，勾选启用https。保存后稍后即可使用域名访问博客。想使用GitHub自动博客功能的，到此处就可以结束了。

3, 安装使用hexo

打开终端输入

npm i hexo-cli -g

安装hexo, 拉取我们的github上的博客库，到本地。清空内部GitHub博客配置的文件。在文件夹内使用终端，输入

hexo init

初始化文件夹，接着使用 npm i 安装依赖。

这样hexo博客就配置好了，输入 hexo g 生成静态网页，然后输入 hexo s 打开本地服务器。可以写一个hello本地尝试一下。

4，配置GitHub默认路径

本地写完博文，推送到github时，发现通过域名访问的并不去hexo博客地址，怎么办？
仔细看我的步骤2里的红框内的，GitHub上的默认博客根目录是固定，只有几个值可以选择，这里选择一个自己喜欢的值，不是root,比如我选的 docs  , 打开自己的hexo配置，_config.yml 将里面的public_dir值改成和GitHub选择的值一致，比如我的都是 docs  。

重新生成静态文件，删除不需要的旧的生成目录，重新提交github。再次通过域名访问，就能看到效果了。

5，主题配置和hexo深入配置

主题配置，想复用别人的主题很简单，以我使用的主题hexo-theme-matery为例，https://github.com/blinkfox/hexo-theme-matery 打开hexo-theme-matery项目地址，里面有详细的配置方式，其他开源主题可以自己搜索获得。由于hexo-theme-matery中文文档比较详细，这里就不再赘余了。

hexo的深入配置也可以参考 https://hexo.io/zh-cn/ 文档，根据自己的需求自定义配置。

到此，hexo+GitHub 搭建博客算是完成了。

119行动

发表于 2021-11-09

内容

我打算开始写博客，今天是2021年11月9号。我称之为119行动。

119，一方面因为今天是11月9号开始时间，另一方面也表示这个事情对我像火灾一样比较紧迫。

github是我主发的地方，抽空会将文章同步到个人公众号等等各个平台。

119行动的内容包含写119篇博客