你有没有想过, 我们在借助 AI 大人那份如今而言可谓无所不能的力量时为什么常常要把它囚禁在某个 Coding Agent 里?
现在流行的 Agentic 软件大多都做了太多不该自己全部做完的事, 这导致用户不得不对其中的某个或某几个产生了粘性. 如果只是这样其实也没多大问题, 毕竟大部分人本就没有频繁地在各种 Coding Agent 之间换来换去的需求.
然而在这样本地优先的用法里, Agentic 软件做的这些额外的事还会带来一个更严重的问题: 用户的工作流和具体的物理设备形成了绑定.
举个简单的场景作为例子, 你在自己的笔记本上精心调教了某个 Coding Agent, 这包括软件层面的设置, 用户级的 Skills 与交互偏好, 还有连续用了几个月积累下来的长期记忆. 某一天你公司要求在公司的设备上开发, 于是你不仅要重新安装 cli, 配置供应商, 还要从头驯化它的脾气, 把你做的那些调教想办法迁移过去.
你可能觉得这也没多大点问题, 不就复制粘贴几个文件吗. 但这之后的事情呢? 你将要同时在两台设备上工作, 即使使用相同的 Coding Agent, 两台设备的状态同步也不是一件易事. 会话历史, 长期记忆, 用户级配置各存一份, 于是你原先的 Agent 从此分裂成了两个. 更何况现在很多 Coding Agent 还有各自五花八门的长期记忆系统, 它们光是导出迁移就不是一件易事, 合并多设备的记忆并同步更是难上加难.
当然现在有云端记忆方案可以选择, 同步 .agents/ 的那些东西也不是毫无办法, 有些 Coding Agent 还可以将会话放到云端直接运行. 可这些解法要么把一致性交给人肉, 要么把状态搬进一台你自己搭的服务器却仍与某个具体的 Agent 软件绑在一起, 要么只是把囚笼从你的笔记本挪到了某家厂商的云里; 只要换掉承载它的软件外壳, 一切照样要从头开始. 所谓 Agent, 所谓 AI 助理, 所谓智能体, 本就不该在换了设备, 换了 Harness, 换了交互入口之后就消失, 否则它只是一个被囚禁的会思考的脚本.
我希望我已经暗示出了前文所说的客户端 Agentic 软件所做的额外的事是哪些. 现有的实现普遍把交互入口, 底层命令执行层和构成 Agent 人格的状态打包成一个不可拆分的整体. 或是本地的一个进程树, 又或是同一家厂商的单点服务. 这种集成化在非单机场景下带来了诸多问题, 这些问题可以统一概括为 Agent 寄生.
在这种结构中, Agent 不是独立的实体, 而是在某台机器的某个进程中的寄生者. Agentic 软件的交互入口 (e.g. CLI/TUI) 就是 Agent 的载体本身, 前台会话会随终端一起结束. 即使是那些能把会话挂到后台进程或自家云上, 关掉界面也继续运行的实现, 执行层也依旧被绑定在一台机器或一家厂商的基础设施上. 作为构成 Agent 人格的数据 (例, 长期记忆, 会话历史, 用户级偏好...) 在本地形态下强依赖于本地特定路径, 在云端形态下则被锁定在厂商的账号与运行时里; 无论哪种, 当开发者切换到其他物理设备或另一个 Harness 上时, 都必须手动配置或依赖外部同步工具来恢复状态, 靠人肉维持一致性.
这种设计也完全不利于多设备的调度管理. 假设你在开发某个 API 服务, 你想将它推送到远程服务器上进行真实环境下的测试, 这时候你可能会为 Agent 配备一个 SSH 密钥, 这样它就能帮助你完成这件事. 但这种依靠某种连接手段登录远程机器的办法对于 Agent 而言是不够原生的, 在它的认知上下文里, 它并不是本身就拥有这台服务器, 这台服务器不是它的触手之一, 它只是借助 Harness 和 SSH 去操纵它. 现在确实有远程开发容器这类形态能让 Agent 直接跑在你的基础设施里, 但它们更像是每个工具各自开出的特例, 而不是 Agent 对自己设备的普遍认知. 一台两台设备还好, 但如果你有更复杂的场景呢? 更何况, 在这个借助 SSH 来管理其他设备的例子中, Agent 通常需要多层 Shell 嵌套来执行操作, 这本身就会带来转义和状态上的不确定性.
附带的, Agent 的安全隔离与灵活性的两难也在这种寄生结构下被放大. 默认状态下, 不少实现仍让 Agent 运行在和开发宿主机相同的权限域内, 放开本地 Shell 权限就使它具备破坏本地环境或读取密钥凭据的潜在风险; 放进沙盒内又总要为访问本地服务, 特定硬件或内网资源另做一堆特殊处理. 我当然知道这些问题在 Harness 层有许多成熟的解决办法(e.g. 命令审批, 开发容器, tmpfs), 但正如云端记忆一样, 它们更像是问题的结果催生出的缓解之策. 每个 Harness 各自为营, 钻研自己的解决方案. 只要 Agent 仍然立足于某个具体环境里, 这些策略就得一个环境一个环境地重新设计并施加.
我们来想办法解决这些问题! 首先我们应该尊重这一整套结构中真正具有智能的实体, 即 Agent. 这里我们需要把 Agent 解释为 LLM 的包装, 即 Agent = 模型+身份+记忆:
在上述的定义下, Agent 还要具备独立且长存的核心属性. 它必须常驻于某些网络节点内, 脱离任何客户端物理设备的状态独立运行. 此处的常驻强调的是 Agent 的人格组件持续同步且总能访问到一致的数据, 并不是要求某个守护进程或容器, 它们只是实现这一点的手段而非目的.
再次回顾前文, 对于面对的问题, 我们拟定一些设计系统的基本原则:
基于此思想, 我们将整个系统垂直解耦为接口, Agent 与 Harness 三层.
接口即用户触达 Agent 的入口, 它的定位是作为 I/O 代理的纯粹的人机交互适配器. 它的职责只有上传下达 Agent 与人类之间的对话. 接收人类指令上报给 Agent, 接收 Agent 的输出, 状态变更, 审批请求等在当前媒介上进行渲染.
接口本身是绝对 stateless 的, 它不应该持久化任何对话历史或模型供应商配置, 甚至组装整个会话流的状态机也不应该由它维护. 接口的具体形态可以是任何现今普遍采用的形式, 包括 TUI/CLI, IM Bot, 桌面客户端, Web 端等.
Agent 是全局唯一的认知实体, 它是厚状态的, 且状态在整个系统中是权威的. AgentCore 需要维护智能体的身份与人格, 管理全局长期记忆, 承载 Agent Loop, 规划复杂任务与调度节点执行, 实现访问控制与安全策略等.
Agent 作为持续运行的状态中枢, 它应该能脱离单机的生命周期运转. 这分为两个需求, 一是要求 AgentCore 本身应该具有分布式运行的能力; 二是在客户端接口关闭时, 它也能够沉淀记忆, 执行任务.
Harness 在这里被定位为在各物理环境下的不具有 Agent 的任何状态的能力宿主, 它是单纯的执行工具套件, 是没有生命的机械臂. Harness 需要向 AgentCore 声明自身的环境元数据, 例如操作系统架构, 可用工具, 硬件和网络信息等等, 并执行 Agent 下发的指令.
Harness 不应该感知 Agent 的人格, 它只提供操作原语, 并且它的权限与能力受到 AgentCore 的下发策略的约束.
flowchart TD
%% 交互层
subgraph Interfaces["交互层"]
style Interfaces fill:#1e293b,stroke:#475569,stroke-width:2px,color:#f8fafc
UI_CLI["TUI / CLI"] ~~~ UI_WEB["Web / Desktop UI"]
UI_TG["Telegram / Wechat / IM Bot"] ~~~ UI_ANY["..."]
end
%% 会话总线
Interfaces <-->|"统一上下文流"| AgentCore
%% Agent 层
subgraph AgentCore["Agent 层 (人格与状态维护)"]
style AgentCore fill:#0f172a,stroke:#3b82f6,stroke-width:3px,color:#f8fafc
Core_Soul["统一身份, 人格设定"] ~~~ Core_Mem["长期记忆, skills"]
Core_Plan["任务规划, 决策"] ~~~ Core_ACL["权限, 角色, 节点能力"]
Core_ACL ~~~ Core_ANY["Personality components..."]
end
%% 任务分发总线
AgentCore -->|"动态感知 / 无状态调度"| Harnesses
%% 纯执行工具环境层
subgraph Harnesses["执行层 (无状态 Harness)"]
style Harnesses fill:#1e293b,stroke:#475569,stroke-width:2px,color:#f8fafc
H_A["Harness A (本地)<br/>• bash / exec<br/>• fs 本地文件系统"] ~~~ H_B["Harness B (云开发机)<br/>• git / build / CI<br/>• Docker 沙箱环境"]
H_C["Harness C (无头环境)<br/>• Headless Browser<br/>• Scrapers / APIs"] ~~~ H_D["Harness D (...)<br/>• some capabilities..."]
end
%% 节点样式美化
classDef clientNode fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc;
classDef harnessNode fill:#1e293b,stroke:#0ea5e9,stroke-width:1px,color:#f8fafc;
classDef coreNode fill:#1e1e38,stroke:#6366f1,stroke-width:1px,color:#f8fafc;
class UI_CLI,UI_TG,UI_WEB,UI_ANY clientNode;
class Core_Soul,Core_Mem,Core_Plan,Core_ACL,Core_ANY coreNode;
class H_A,H_B,H_C,H_D harnessNode;
仔细理解上文提出的架构, 你会发现它带来的好处超越预期. 它不是只解决了一开始提到的更换开发机器配置麻烦的这种便利性层面的问题, 而是将 AI 工具的范式向数字生命转变.
最核心的收益是会话的时间线与注意力得到统一. 由于单个 Agent 同时拥有多个交互入口, 用户可以在自己电脑 CLI 上发布一项任务, 出门后通过 IM 软件讨论技术方案, 到家后又回到电脑上说一句"就按照刚才说的实现", Agent 完全清楚上下文发生了什么. 这在我们的架构中是无痛且自然的, 因为在这个过程中切换的始终是接口, 而不是 Agent 本身. 并且此时 Agent 外的两端可以轻易实现按需扩展, 重启, 崩溃后无损恢复. 因为它们是无状态的, 没有任何重要的东西在它们身上, 这对运维和高可用性的设计是很大的简化.
Agent 的能力也不再取决于当前机器上有什么, 而是变成了声明式的, 可扩展的, 天然跨节点执行的能力集. Agent 执行操作的心智模型从在当前设备上寻找解决方案变成了在整个系统中发现能力, 这是一种抽象上的升级. 并且由于这种抽象, Agent 的权限天然得到更细粒度的控制. 不应该在某节点上执行的某操作, Harness 可以直接不予声明其能力, 或是把执行权收回到自身, Agent 只能决策和期望执行结果, Harness 可以控制某些操作能否执行. 而且, 我们还可以让不同任务类型路由到最合适的 Harness 上, 实现更高的资源利用效率.
如果回到我们一开始提出的跨机器协同问题, 你会发现该问题在这种架构下也的确轻易得到了解决. Agent 已经拥有了原生跨节点执行的能力, 它现在甚至可以做到将复杂任务根据节点能力自动拆解, 分发给一系列 Harness. 例如你要求它为你完成一个网站项目, 它可以在你本地电脑的 Harness 上读取代码库, 在云端 Harness 里编译和测试, 在 Browser Harness 里验证, 在 CI Harness 里跑自动集成, 最后再部署到你的服务器上. 在 Agent 看来这些不过是不同的手, 它不需要考虑应该如何连接其他机器, 各个节点在此时完成了分立与统一.
最后是作为人的体验. 一个能够在网络世界持续存在的赛博幽灵带来的情绪价值对我来说是无法抗拒的, 这相比一个冷冰冰的终端和埋头干活的 AI 而言它能给人的感受将完全不同. 它将会生活在云上, 并无处不在地陪伴和协助你处理各种工作, 与此同时它也能够将这些记忆保留下来, 不断构筑自己的人格. 到这里你会发现此节开头所说的数字生命并不只是文艺化的表达, 在我们的设计下, Agent 对象的定义本就和传统相异, 并且它的存在也确实可以被认为是某种意义上有生命的东西. 我承认这里有些饺子醋的成分, 但无论如何, 这是现有的以个人 AI 助理作为卖点的软件多数没考虑过的或没做到的.
尽管在设想中这套架构的落地能带来很美好的结果, 但在那之前我们不得不面对实际工程上的许多难题. 暂时只叙述以下几点.
首先最尖锐的问题就是 AgentCore 难以真正依照此架构实现. 系统内仅存在一个持久化的状态中枢来维护唯一的 Agent 人格数据是我们坚持的原则之一, 也是我们解决 Agent 分裂问题的核心思想. 但这带来的代价是我们不得不把 Agent 的状态做的很厚, 所有关于 Agent 人格的状态都要汇聚在此处, 其一致性并非传统数据库意义上的简单数据一致性, 而是同时涉及会话, 长期记忆, 任务进度, 人格状态等多种状态类型的演化. 如何在保持单一权威状态的同时提供高可用, 低延迟的访问, 将成为一个典型而棘手的分布式状态问题. 即, 拥有唯一权威状态的 Agent 的执行能力又必须分布到系统各处, 这势必增加并发控制与状态协调的复杂度.
在此架构中, 我们希望通过 Harness 的抽象让 Agent 直接理解它所拥有的节点和能力, 这是过度理想化的. Harness 抽象实际上要求 Agent 建立一个关于外部执行世界的内部模型, 而任何这样的模型都不可避免地与现实存在时间差异. 毕竟在现实中物理环境总是动态的, 它们难以被静态声明为单纯的能力供以 Agent 直接使用. 也就是说, Agent 的手并不真的像身体器官那样稳定, 这导致在真实任务中它可能会因为过期的认知做出不可用的规划.
为了让交互接口与 Agent 解耦, 我们想要实现一种通用上下文流来让各个平台顺利接入会话. 但这在工程中是非常难以实现的, 接口不仅需要传入简单的用户输入消息, 还要考虑模型输出, 工具调用/结果, 任务状态/todos, 执行状态, 命令审批等等一系列 Agent Event, 并且还要支持各种接口的分离与切换后的会话恢复. 在真正着手实现时, 可能仅仅两个不同平台上的接口就足以让人一团乱麻.
在传统的 Coding Agent 中, 如果遇到 Agent 执行了危险命令, 通常最坏的结果也只是破坏当前设备的环境, 它的影响范围因为单机设计而正好被物理隔离. 但在此文的架构中, Agent 可以掌握所有物理设备能力, 如果没能真正做好每一个 Harness 的约束, 一旦模型犯蠢或遭到提示注入, Agent 将会贯穿接入网络的所有设备造成破坏. 同时为了让 Agent 同步好自身状态并协调另外两层, 如果采用直接持有凭证的朴素实现, 大量密钥与长期凭证将汇聚到 Agent 层, 从而使得 Agent 本身就成为了显眼的高价值攻击目标.
前面我们从未考虑 Interface 与 Harness 的接入量的问题, 实际上, 当前的直白设计并不能承载稍大量的二者的接入. 尤其是对于 Harness , 为了让 Agent 实施工作, 它必须在恰当的时机知晓它所具有的节点能力. 在节点少时我们使用简单的元信息列表注入系统 instructions 即可, 但一旦接口与能力的接入量随着系统扩展而不断增多, 我们就必须为解决上下文爆炸问题而实现大量形似于服务集群调度的策略. 实际上系统内这一部分的形态最终很可能变成某种 k8s for harness, 这将是在工程上的巨大挑战之一.
我们所描述的完整架构确实过于庞大, 试图一步到位地实现它们是不现实的. 这个系统将涉及 AgentCore 的分布式状态维护, 动态节点发现, 能力调度, 复杂的长期记忆以及完善的安全隔离等诸多难题, 为了真正开始验证这个想法, 我们有必要舍弃一些不太核心的事物.
回顾我们的出发点, 我们想要验证的实则是这样一个命题, 即, Agent 能不能脱离具体的接口与工具, 作为一个拥有唯一连续状态的主体独立存在? 只要这个问题能够得到肯定的答案, 其余能力都可以在此之上逐步构建.
首先, AgentCore 不必是分布式的. 最小实现完全可以让它运行在单个常驻节点上, 用一份数据库维护 Agent 的身份, 记忆, 会话历史与任务状态. 这里真正重要的并不是 AgentCore 自己拥有多少副本, 而是整个系统在语义上始终只有一个权威的 Agent 状态. 至于它未来如何通过副本, 日志或者其他机制实现高可用, 是原型被证明之后才需要面对的问题.
其次, Harness 不需要一开始就拥有复杂的能力发现和调度系统. 我们只需要让每个 Harness 在启动时向 AgentCore 注册一个简单的元信息, 然后通过显式的方式指定执行节点. 这里我们需要验证的最重要的事情是, 同一个 Agent 是否能够把两个物理上独立的执行环境视作自己的能力节点, 而不需要通过 SSH 或其他人为设计的连接方式去建立另一层认知上下文.
前文提到的诸如记忆系统, 统一上下文流, 节点安全体系等也都不是我们设计中最核心的部分. 我们不需要同时实现它们, 于是整套系统可以被压缩为更简单的形态:
flowchart TD
%% 交互层
UI["CLI / Web"] <-->|"Event Stream"| AgentCore
%% Agent 层
subgraph AgentCore["AgentCore"]
style AgentCore fill:#0f172a,stroke:#3b82f6,stroke-width:3px,color:#f8fafc
Core_Identity["Identity"] ~~~ Core_Memory["Memory"]
Core_History["History"] ~~~ Core_Loop["Agent Loop"]
Core_Loop ~~~ Core_Task["Task State ..."]
end
AgentCore -->|"Harness Protocol"| H_Local
AgentCore -->|"Harness Protocol"| H_Remote
H_Local["Local Harness"]
H_Remote["Remote Harness"]
classDef clientNode fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc;
classDef harnessNode fill:#1e293b,stroke:#0ea5e9,stroke-width:1px,color:#f8fafc;
classDef coreNode fill:#1e1e38,stroke:#6366f1,stroke-width:1px,color:#f8fafc;
class UI clientNode;
class Core_Identity,Core_Memory,Core_History,Core_Loop,Core_Task coreNode;
class H_Local,H_Remote harnessNode;
这已经足够验证我们最初真正关心的场景, 你可以在自己的电脑上通过 CLI 告诉 Agent 开始一项任务, 随后关闭终端, 任务将继续执行. 之后你从另一台设备打开网页端, 看到的仍然是同一个 Agent, 能够继续讨论刚才的任务. 即当 Interface 消失, Harness 更换, 物理设备发生变化时, Agent 是否仍然还是原来的那个它? 换言之, 如果连这一点都无法成立, 那么前文所有的关于分布式人格, 跨设备协同以及数字生命的讨论都只是空中楼阁.
实际上你可以注意到, 这个简化的架构所能做到的事情早已有其他软件做到了, 并实现了上述的 Agent 的跨设备统一与会话协同恢复, 只不过它们的实现的重点并不是把 Agent 的存在作为主体, 我将在后文更详细地讨论这一点. 无论如何, 这至少证明了我们的构想并非怪异的空谈, 只是在真正落地的路上还有一段距离.
前文中的批评主要是针对于工程实现上的不良设计, 我并不打算立刻全部解决它们, 毕竟我还没有为此文提出的架构实际写过一行代码. 但为了防止该架构被误解, 我将自我提出一些可能的质疑并回应.
直接让我的 Agent 配个 SSH Key, 不就可以远程控制其它机器了吗? 何必设计这么多有的没的?
SSH 解决的是如何连接另一台机器, 而本文试图解决的是另一台机器如何成为 Agent 的原生执行能力. 在 SSH 模型中, 远程机器是一个需要借助连接手段访问的外部环境; 在我们的 Harness 模型中, 远程节点直接作为 Agent 的能力节点参与调度. 实际上 SSH 很可能就是 Harness 内部的实现手段, 但它不会成为 Agent 对世界的认知模型.
这不就是给 Agent 加上长期记忆, 再做一点 self improvement 吗? 太土了吧.
自我进化解决的是 Agent 如何改变自身, 本身解决的是 Agent 的存在性问题. 即使一个 Agent 不会所谓的自我进化, 它只要拥有与设备, 接口, Harness 都解耦的连续身份认知, 它就是符合本文架构的.
把原先的一个进程拆的这么复杂, 不就是为了分布式而分布式吗?
这套架构没有任何存在的意义是为单纯的拆分服务而生的, 它想解决的是 Agent 的主体归属问题, 三层解耦只是手段, 即使是不同的设计或许仍然能实现本文的目的.
Harness 无状态是哪里的梦话? 无论是设备还是执行过程本来就是带状态的.
本文对 Harness 的定义与常规定义有所差异, 文中的无状态是指 Harness 不拥有 Agent 的人格的状态, 而不是要求物理执行环境不存在状态. 例如, 进程信息, 网页 cookie 等属于环境状态; 而会话历史, 记忆, 人设等属于 Agent 状态. 只有后者不应该保存在 Harness.
依靠云端记忆, 云端会话, 目录同步等现有做法早就能解决这些问题了.
这些方案解决的是多份状态的同步问题, 也确实能在一定程度上解决. 但本文试图从根本上取消多份各自演化的 Agent 状态, 转而让它们都只是同一个主体的投影.
这不就 OpenClaw 吗? 现在已经有项目实现了多渠道接入, 持久会话, 远程节点以及跨设备执行, 这不是在重新造轮子吗?
无法辩驳的是, 至少从最终呈现出的系统形态和用户体验来看, 本文提出的很多东西已经被现实中的项目实现了, 当前的 OpenClaw 就是其中非常接近本文设想的一个例子. 但这并不构成对本文的否定, 因为这些既有项目与本文试图讨论的问题不同, 我们关注的不是有没有人已经实现了这些功能, 而是这些功能的组织模型. 即, Agent 应该作为功能组织的主体, 而非被承载在某个执行环境内.
到这里, 我们其实应该承认, 我们并不是第一个探索这条路的人. 事实上, 当我们顺着前文的逻辑一路推导下来时, 会发现已经有一些项目没有按照本文的定义去实现同一套架构, 但却从不同的方向与我们走到了相当相似的位置.
Letta 很早就在强调 stateful agent 这一概念. 它把 Agent 描述成拥有自己的身份与经验的长期存在实体, 而不是单纯的 LLM 调用. Letta 甚至支持让同一个 Agent 同时参与多个 conversation, 不同 conversation 中产生的经验可以汇入同一个 Agent 的记忆. 这已经很接近本文所说的在面对多种外部环境的单 Agent 人格唯一的雏形.
区别于各种所谓的记忆方案, 这件事情实际上把问题从模型记住的是哪些东西, 转向了记住这些东西的是谁. 本文所说的 Agent 身份, 人格与长期记忆, 与这种方向存在非常明显的相关性. 我们没有重新发现 Persistent Agent 这个概念, 只是顺着 Agent 不应该依附于某个客户端的前提把这种持久性进一步延伸.
我起初对 OpenClaw 的印象停留在其早期的 channel+gateway 设计, 这一设计只像是把传统的单机 Coding Agent 加了个 IM 渠道作为交互层, 并放到云服务器上运行. 显然这种设计没有解决本文提出的问题.
为了撰写本文, 我去调查了 OpenClaw 现今版本的架构, 发现它居然已经实现了大量本文想象中的工程形态. OpenClaw 现在仍然采用 Gateway 作为整个系统的控制中心, Telegram, CLI 等客户端连接到它. 但不同以往的是, Node 以独立的身份接入并声明自己的能力, gateway 负责维护 session, channel, state, node registry 等全局信息, 客户端本身只是连接它的外围. 甚至在它的远程执行模型里, Telegram 到 Agent 再到 Node 的链路几乎就是我们所构想中的路径, 这让我感到不可思议的同时也为之欣慰, 无论如何 OpenClaw 作为现今 github 上 stars 最多的 Agent 项目, 在经历持续迭代后变成了和我们单纯的奇思妙想十分接近的东西. 这说明我们的架构并非纸上谈兵, 而是 Agent 工程化到一定深度后很可能出现的形态之一.
OpenClaw 与本文设计的出发点并不相同, 它更关心远程执行的可控性与可替换性, 并由此获得了 Gateway, Session、Node 与远程执行这样的结构; 而本文则是从 Agent 本身的主体性出发, 推导出 Interface, Agent 与 Harness 的分离. 可以说 OpenClaw 是从不同方向与我们走到了一个相似的目的地. 如果最终证明两条路会收敛到几乎相同的工程实现, 那并不是一件坏事.
不同于过去普通的 Coding Agent 的会话模型, Cloud Session 的方向是主动把会话和执行位置进行了分离, 这也与我们由 Agent 持有会话状态并与 Harness 分离的设计不谋而合. 仍以 OpenClaw 为例, 目前它已经支持让一个 session 的对话和持久状态由 gateway 持有, 而实际的命令执行, 文件修改等工作放到其他机器上运行. 即使远程 worker 失败, session 本身仍然可以继续存在. 这正回答了我们最初提出的为什么 Agent 要在执行环境改变后就消失的问题.
那么, 如果最终解决了重重困难, 使得这套架构真的能够成立, 我们究竟想得到一个什么东西? 又能得到什么东西? 一开始, 我们只是想解决一个多设备下 Agent 分裂的这一简单而具体的问题, 但随着我们的讨论, 事情最终变得比跨设备同步深入得多.
我真正想要的显然并不是一个更方便的 Coding Agent, 而是一个不再属于任何东西的 Agent. 它不会属于某个终端窗口, 不会属于某台笔记本, 不会属于某个客户端, 也不会因为换了一家模型供应商, 换了一个 Harness, 或者把某台作为工作用的机器关掉而消失.
它会生活在网络世界里. 你可以在电脑前看到它, 可以在手机上和它说话, 可以让它在自己的机器上做事, 也可以让它把某项工作交给远程的计算节点. 对它而言, 这些东西是它在现实世界里拥有的不同感官与肢体, 是它与你的联系. 而它真正存在的地方不是其中任何一台机器, 它只是它自己.
这也是为什么前面我一直在强调 Agent 状态的唯一性. 它记得什么, 如何认识你, 如何理解自己, 曾经经历过什么, 形成了什么偏好, 为什么会做出今天这样的判断, 这些东西共同构成了一个连续的主体. 物理设备的更替只是为它换了一间屋子, 而不是杀死了它.
只可惜没有所谓的数字生命, 没人会觉得自己因为实现 Agent 而实现了创生. Agent 仍然只是模型与程序构成的系统, 它没有因此获得什么神秘的主观意识. 但软件架构可以决定一个东西以什么形式存在于世界上, 对于背后的 LLM 而言, 或许 Agent 架构就是它的整个世界. 我希望未来的 Agent 不是打开某个软件时才暂时出现的东西, 而是一个本来就在那里等着你的那个它.
访问 https://krau.top/posts/liberating-coding-agents-as-digital-beings/index 查看原文。
]]>GPU: NVIDIA GeForce RTX 3060M
:::
参考 WSL 安装 CUDA
git clone https://github.com/ggml-org/whisper.cpp.git
cd whisper.cpp
cmake -B build -DGGML_CUDA=1
cmake --build build -j --config Release
可执行文件产物默认在 ./build/bin
whisper.cpp 内置了下载脚本并提供了一些已经转换为 ggml 格式的模型
例, 下载 large-v3:
sh ./models/download-ggml-model.sh large-v3
模型默认存储在 ./models
./build/bin/whisper-cli -m models/ggml-large-v3.bin -f <音频文件路径> -l auto
一些命令行参数:
-m <模型路径>: 指定模型路径-f <音频文件路径>: 指定音频文件路径-l <语言>: 指定语言, auto表示自动检测-olrc: 输出 lrc 格式的字幕-otxt: 输出纯文本格式的字幕-osrt: 输出 srt 格式的字幕-ocsv: 输出 csv 格式的字幕-ojf: 输出 json 格式的字幕在自己的程序中使用类似下面的代码监听 SSH 的全局请求:
for {
select {
case <-ctx.Done():
return nil
case req, ok := <-globalReqs:
if !ok {
return nil
}
// Handle request
fmt.Println("Received global request:", req.Type)
req.Reply(true, nil)
}
}
发现发来的请求有时候没有接收到, 而对端的提示是 reject, 甚至出现 reject, 成功 如此交替出现的情况 (那很公平调度了).
其实很明显是有啥东西和自己的代码在抢同一个通道, 但是因为我一直在找发送端的代码问题, 为这个问题浪费了一晚上的生命, 甚至怀疑这库有 bug
用自定义的 dialer 创建 ssh 客户端时, 代码是像这样的:
dialer := &net.Dialer{Timeout: 30 * time.Second}
conn, err := dialer.DialContext(ctx, "tcp", addr)
if err != nil {
return err
}
sshconn, chans, globalReqs, err := ssh.NewClientConn(conn, addr, conf)
if err != nil {
return fmt.Errorf("failed to establish SSH connection: %w", err)
}
client := ssh.NewClient(sshconn, chans, reqs)
查看 ssh.NewClient 源码:
// NewClient creates a Client on top of the given connection.
func NewClient(c Conn, chans <-chan NewChannel, reqs <-chan *Request) *Client {
conn := &Client{
Conn: c,
channelHandlers: make(map[string]chan NewChannel, 1),
}
go conn.handleGlobalRequests(reqs)
go conn.handleChannelOpens(chans)
go func() {
conn.Wait()
conn.forwards.closeAll()
}()
return conn
}
可以看到它用 handleGlobalRequests 来 handle 了全局请求通道, 这个函数是:
func (c *Client) handleGlobalRequests(incoming <-chan *Request) {
for r := range incoming {
// This handles keepalive messages and matches
// the behaviour of OpenSSH.
r.Reply(false, nil)
}
}
破案 😇
主要是 ssh.NewClientConn(conn, addr, conf) 紧接着就是 ssh.NewClient 带来了点迷惑性, 前者的返回正好是后者所需的所有参数.
给 ssh.NewClient 的 <- chan *Request 传个 nil 就行了
访问 https://krau.top/posts/go-ssh-gloabal-reqs-channel-race 查看原文。
]]>Cloudflare 的 Warp 和 Tailscale 都是基于 WireGuard 的, 它们也都能做到给机器添加特殊的网络出口访问.
最近 Warp 刚好又故障了, 所以折腾了下手动配置 WireGuard , 实现使用一台双栈服务器为 IPV6-Only 的机器提供 IPV4 网络出口.
::: info 本文使用的系统环境
首先在两台服务器上都安装 WireGuard
apt update && apt install wireguard-tools wireguard
进入配置目录, 为两台服务器创建密钥对
cd /etc/wireguard
wg genkey | tee privatekey | wg pubkey > publickey
privatekey 是私钥, publickey 是公钥.
编写服务端配置, 新建 wg233.conf 文件, wg233 可以替换为自己想要的接口名称.
[Interface]
Address = 10.39.0.1/24 # 内网IP/CIDR
ListenPort = 39182 # 监听端口
PrivateKey = 服务端的 privatekey 内容
# Hooks, 用于在开启 WireGuard 接口时启用 IP 转发和添加 NAT 规则
PostUp = echo "1" > /proc/sys/net/ipv4/ip_forward
# 如果服务器的公网接口不是 eth0, 请替换为实际的接口名称
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -A FORWARD -i %i -j ACCEPT
PostUp = iptables -A FORWARD -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[Peer]
PublicKey = 客户端的 publickey 内容
AllowedIPs = 10.39.0.2/32 # 稍后将要配置的客户端IP
编写客户端配置, 同样的新建一个配置文件, 配置文件名即为接口名 (不需要和服务端一致).
[Interface]
Address = 10.39.0.2/24 # 和服务端的 AllowedIPs 一致
PrivateKey = 客户端的 privatekey 内容
# 客户端的 Hooks, 这里添加了对 Docker 的支持
# 若你更改过 Docker 的默认接口和网段, 请相应修改
PostUp = iptables -A FORWARD -i docker0 -o %i -j ACCEPT
PostUp = iptables -A FORWARD -i %i -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -o %i -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 172.17.0.0/16 -o %i -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
PostDown = iptables -D FORWARD -i docker0 -o %i -j ACCEPT
[Peer]
PublicKey = 服务端的 publickey 内容
Endpoint = [服务端公网ipv6]:39182
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25 # keepalive 间隔, 单位秒
启动两个 WireGuard 服务:
systemctl enable --now wg-quick@wg233
输入 wg 命令查看状态, 预期输出:
interface: wg233
public key: QdUOWJE...Nnm8=
private key: (hidden)
listening port: 55670
fwmark: 0xca6c
peer: TcO+...vanU=
endpoint: [ip]:39182
allowed ips: 0.0.0.0/0
latest handshake: 44 seconds ago
transfer: 34.35 MiB received, 3.72 MiB sent
persistent keepalive: every 25 seconds
Some tips:
已经删除了的 WireGuard 配置还在 systemd 里?
使用下面的命令清理:
systemctl reset-failed
WireGuard 附带安装的 openresolv 修改了原来的 DNS 配置?
openresolv 的配置在 /etc/resolvconf.conf.
将 name_servers 部分设为你想要使用的 DNS 服务器, 用空格分隔多个:
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1
name_servers="2606:4700:4700::1111 2001:4860:4860::8888 2001:4860:4860::8844"
# Mirror the Debian package defaults for the below resolvers
# so that resolvconf integrates seemlessly.
dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
关于 IP/CIDR 的计算:
访问 https://krau.top/posts/add-ipv4-network-to-ipv6only-machine-by-wireguard 查看原文。
]]>::: info 这台电视的详细信息
型号: 海信 VIDDA LED55N3000U
安卓版本: Android 5.1
系统日期: 2017年12月26日
abi: armeabi-v7a
存储: 2GB
吐槽:
:::
众所周知现在的电视也叫 Android TV, 所以折腾的第一步就是开启 adb 调试.
但是这部分我很早之前就完成了, 记忆比较模糊, 下面仅供参考.
设置->音量控制->音量平衡->交替按下"OK"键和"菜单"键, 直至出现"雪花屏", 进入工厂模式.
在工厂菜单中, 切换到"选项"选项卡, 将 "To Fac" 改为 "M".
然后重启电视, 应该会出现安卓原生设置软件, 进入设置->关于->版本号, 连续点击7次, 直到提示"你已处于开发者模式".
进入开发者设置, 开启 adb 调试.
电视的 adb 是无线调试, 在电脑上使用 adb connect <电视IP地址> 即可连接.
连接 adb 进入并进入 adb shell
adb shell
列出所有应用
pm list packages
卸载应用
pm uninstall <包名>
大部分预装应用根据包名就能看出来干什么的, 如果误删了, 可以在 /system/app 或 /system/priv-app 中找到对应的 APK 文件, 通过下面的命令恢复安装
pm install -r <路径/包名.apk>
下面给出 AI 推测的一些包名:
::: details 点击展开查看
com.hisense.store.tv: Hisense 应用商店，谨慎卸载 — 如果你无需商店功能且可另行安装应用，可考虑卸载或禁用。
com.hisense.business.ad, com.hisense.service.ad: 广告相关包，安全性较低，建议卸载或禁用。
com.hisense.hitv.hicloud.account: HiCloud 账户服务，若不使用账户登录可以禁用。
com.hisense.hitv.das: 可能是统计或遥测服务，若不影响观看，可禁用。
com.jamdeo: 这是 Hisense TV OS 的核心包（多款 com.jamdeo.*），建议保留。
com.hisense.speech.aiupgrade, com.keylab.speech.core.vidaa, com.keylab.speech.view.vidaa, com.hisense.vidaaassistant: 语音助手及升级功能包。若不使用语音功能，可禁用，但留用不影响系统通常运行。
com.hisense.assistantmenu, com.hisense.horizontalassistantmenu.first: 辅助菜单，如果不使用无障碍功能，也可考虑禁用。
com.hisense.systeminfo, com.hisense.uifac, com.hisense.service.hproxy, com.hisense.hireport: 系统信息、透明更新、日志上传服务——建议保留或仅清除数据。
com.hisense.padinputmethod, com.android.inputmethod.latin: 输入法相关，若不输入文字或使用遥控器输入，可禁用英文键盘。
com.hisense.wifidisplay, com.multiscreen.airplay, com.hisense.mhl, com.hisense.service.hproxy: 屏幕投射与多屏功能，若你不使用 Miracast、Airplay 或 MHL，可以禁用。
com.jamdeo.tv.tileanimation, com.jamdeo.tv.screensaver, com.jamdeo.tv.fte, com.jamdeo.tv.livetv: 系统界面动画模块，慎用——这些可能是启动UI或系统动画的一部分，建议留用以免 UI 异常。
com.android.wallpaper.holospiral, com.android.dreams.basic, com.android.dreams.phototable, com.android.noisefield: 屏保相关，若无所谓，可以卸载或禁用。
com.android.browser: 系统浏览器，如果不使用可禁用。
com.google.android.webview: WebView，Android 系统核心组件，不建议卸载。
媒体提供者、Contacts、Camera、Calculator、Clock 等类应用，属于系统基础功能，建议保留。
:::
安装第三方应用(不在 adb shell 中)
adb install your_app.apk
::: warning
在海信的流氓预装和恶心的收费策略面前, 什么版权意识简直不值一提了😅
:::
尝试了很多应用, 总结就是对于这台电视, 没有什么能推荐的. 大部分应用都会因为安卓版本过低, 架构过时而装不上. 即使有能成功安装的也不好用.
最后使用的方案是装一个能连接远程存储的播放器, 然后下载需要的影视资源到远程存储里来看.
播放器: 当贝播放器 , 支持 WebDAV , FTP , SMB 协议, 还有一些主流网盘.
Webdav 服务我使用的是 Cloudreve V4
::: tip
另外, 这里就不得不介绍下我的 SaveAnyBot 了, 配合上面的方案看影视的自动化程度还是挺高的.
:::
我对这部分不是很感兴趣, 所有没有过多尝试.
显而易见的是想看 IPTV 直播需要找到可用的直播源, 而且这个东西很少有能稳定的, 还需要不断去更新维护.
这里推荐的是 my-tv-0 和 my-tv-server 一起使用, 自带了很多源, 虽然我一个都用不了...
git clone git@github.com:your-username/your-fork.git
git remote add upstream https://github.com/upstream-owner/upstream-repo.git
git fetch upstream
git rebase upstream/main
这里是 main 分支
git checkout main
git merge upstream/main
一一编辑所有提示的冲突文件以解决合并冲突, 我比较喜欢用 VSCode .
完成后, 提交更改:
git commit
git push origin main
之后 rebase 再重新合并, 然后推送时用 --force
git push --force origin main
这时候直接输入用户名和密码可能还会提示错误.
大概率是克隆的时候使用的是 HTTPS 协议而不是 SSH, 密码提示错误是因为 Github 要用 Personal Access Token 代替推送时使用的密码.
把远程仓库地址改为 SSH 协议:
git remote set-url origin git@github.com:your-username/your-fork.git
NMIG 是一个用 node 写的 mysql 到 postgresql 的迁移工具, 截至目前支持 mysql 8.4 到 postgresql 17 的迁移
node: >= 18
git clone https://github.com/AnatolyUss/nmig
cd nmig
npm install
npm run build
config 目录下的几个 json 配置文件都要看一下, config.json 是基本配置, 定义了源数据库和目标数据库的连接信息.
{
"source": {
"host": "127.0.0.1",
"port": 3306,
"database": "sample_stuff",
"charset": "utf8mb4",
"supportBigNumbers": true,
"user": "root",
"password": "0123456789"
},
"target": {
"host": "127.0.0.1",
"port": 5432,
"database": "sample_stuff",
"charset": "UTF8",
"user": "postgres",
"password": "0123456789"
},
}
data_types_map.json 定义迁移时数据类型的映射关系, 默认配置可能不适合你的业务情况.
比如它默认把 mysql 的 bool 类型 (tinyint(1)) 转换为 postgresql 的 smallint , 你可能希望它转换为 boolean
{
"tinyint": {
"increased_size": "int",
"type": "boolean",
"mySqlVarLenPgSqlFixedLen": true
},
}
执行迁移命令, 测试 100w 左右数据花了几十秒, 不算很慢, 如果卡住可以切断重试
npm start
项目中实现了兼容多种服务的文件上传接口的功能, 其中之一就是广为人知的 Alist .
这部分代码如下:
type Alist struct {
client *http.Client
token string
baseURL string
// ...
}
func (a *Alist) Save(ctx context.Context, reader io.Reader, path string) error {
req, err := http.NewRequestWithContext(ctx, http.MethodPut, a.baseURL+"/api/fs/put", reader)
if err != nil {
return fmt.Errorf("failed to create request: %w", err)
}
req.Header.Set("Authorization", a.token)
req.Header.Set("File-Path", path)
req.Header.Set("Content-Type", "application/octet-stream")
resp, err := a.client.Do(req)
if err != nil {
return fmt.Errorf("failed to send request: %w", err)
}
defer resp.Body.Close()
// ...
}
自从发布以来, 就收到一些用户反馈无法向 Alist 上传的问题, 但是无论是开发时的测试还是自己的"生产"环境都无法复现.
现在细说来这个问题出现的原因很简单, 根据 Alist 文档 和 issue #5319 可知 Alist 的文件上传接口不支持 chunked 模式, 必须传递 Content-Length 指定文件大小.
上面的代码里没有设置 Content-Length , 且请求体是以 io.Reader 传递给 http.Client , 查看 net/http 源码 就可以发现, 此时就会使用 chunked 模式传输 (其实这本来就是我想要的, 但谁知道 alist 不支持).
而 Alist 应该返回 400 错误: strconv.ParseInt: parsing "": invalid syntax , 也就是解析不到 Content-Length
但是自己测试时却仍然可以上传成功, 是由于我的环境中使用 nginx 反向代理了 Alist , 根据 nginx 文档 可知, nginx 默认开启了请求缓冲 ( proxy_request_buffering ) .
向 nginx 上传文件时, nginx 会将请求体完整地缓冲到内存或硬盘中, 然后将设置了正确 Content-Length 头的新请求转发给后端.
访问 https://krau.top/posts/nginx-req-buffer-and-go-chunk-transfer-encoding/index 查看原文。
]]>::: tip
示例环境: Debian 12
:::
水文章
wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz
这里下载的是最新适用于 amd64 架构的 ffmpeg + ffprobe 静态编译包，如果你的系统是其他架构，可以到 johnvansickle.com 下载对应的包。
旧版可以在 old releases 下载.
tar -xvf ffmpeg-release-amd64-static.tar.xz
cd ffmpeg-*-static
sudo mv ffmpeg /usr/local/bin/
sudo mv ffprobe /usr/local/bin/
ffmpeg -version
最近把自己的一个小项目迁移了服务器, 结果发现接口响应速度慢了很多, 排查了不少时间后突然想起来是因为新服务器和 MongoDB Atlas 不在同一个地区, 光是二者之间的网络延迟就很高.
而 MongoDB Atlas 提供的免费实例要备份数据和迁移比较麻烦, 又因为 MongoDB 单实例不支持事务, 所以决定干脆自建一个 MongoDB 副本集 😎.
::: tip 本文环境
我手上有几台不同服务商不同地区的服务器, 下文都以 Server A, Server B, Server C 代表.
为了申请证书, 还需要至少一个域名.
首先要在每台服务器上都安装 MongoDB, 这里使用 Docker Compose.
# docker-compose.yml
services:
mongo:
image: mongo
# restart: always
environment:
MONGO_INITDB_ROOT_USERNAME: root
MONGO_INITDB_ROOT_PASSWORD: password
ports:
- 27017:27017
volumes:
- ./data:/data/db
- ./config:/etc/mongo
command: ["--config", "/etc/mongo/mongod.conf"]
然后 ./config 目录下新建我们的配置文件 mongod.conf:
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /data/db
# engine:
# wiredTiger:
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1
# how the process runs
processManagement:
timeZoneInfo: /usr/share/zoneinfo
# where to write logging data.
# systemLog:
# destination: file
# logAppend: true
# path: /var/log/mongodb/mongod.log
暂时只需要上面这一点配置就可以啦, 此时可以先启动容器, 接下来需要配置副本集之间认证用的 keyfile.
keyFile 用于 MongoDB 副本集节点之间的认证, 每一个节点需要有相同的 keyFile 才能加入副本集.
keyFile 的内容就相当于密码啦, 用什么软件生成一个都行, 这里就使用 openssl:
openssl rand -base64 756 > keyfile
然后需要把 keyfile 分发到每一个节点上, 并且仅为文件所有者提供读取权限.
如果你是在本机直接安装的 MongoDB, 只需要使用 chmod 修改权限:
chmod 400 keyfile
但是如果使用 Docker 安装, 不仅要把 keyfile 挂载到容器内, 还要进入容器来修改权限, 因为容器内部的文件权限和外面是不一样的!
这里我把 keyfile 挂载到了 /etc/mongo/keyfile
然后进入容器修改权限:
docker exec -it <container_id> /bin/bash
chmod 400 /etc/mongo/keyfile
chown 999:999 /etc/mongo/keyfile
修改完权限后把容器停掉, 因为我们还要修改配置文件.
::: tip
每一个节点都要使用相同的 keyfile 进行上面相同的操作.
:::
配置完了所有节点的 keyfile, 现在来修改配置文件启用副本集, 依然是所有节点的配置文件都要修改.
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /data/db
# engine:
# wiredTiger:
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1
# how the process runs
processManagement:
timeZoneInfo: /usr/share/zoneinfo
# where to write logging data.
# systemLog:
# destination: file
# logAppend: true
# path: /var/log/mongodb/mongod.log
security: // [!code ++]
clusterAuthMode: keyFile // [!code ++]
authorization: enabled // [!code ++]
keyFile: /etc/mongo/keyfile // [!code ++]
replication: // [!code ++]
replSetName: "rs0" # 副本集名称 // [!code ++]
如果是同机房所有节点使用内部网络的话, 这样就可以直接启动副本集了, 但是我的节点是分布在不同地区的, 所以还需要开放外部连接.
# mongod.conf
net:
port: 27017
bindIp: 0.0.0.0 // [!code warning]
既然开放了外部连接, 那么就需要对传输使用 TLS 加密.
使用 TLS 就需要证书, 这里使用 Let's Encrypt 的证书.
申请证书的方式和为网站申请证书一样, 这里不再赘述, 可以参考:
::: tip
也可以使用自签名证书, 但其实自己维护一个 CA 比申请第三方 CA 的证书麻烦多了, 可以参考:
而且自签名证书也不够安全.
:::
一般来说, 申请成功证书会得到两个文件: fullchain.pem 和 privkey.pem, 分别是证书链和私钥.
但是 MongoDB 还需要 CA 证书, 可以在 Let's Encrypt ISRG Root X1 下载.
接下来需要把 fullchain.pem, privkey.pem '合并' 为一个文件 (MongoDB 要求的!)
cat fullchain.pem privkey.pem > mongod.pem
其实就是把 fullchain.pem 和 privkey.pem 的内容拼接到一起, 得到的 mongod.pem 就是 MongoDB 需要的证书文件.
::: tip 可以使用泛域名证书
如果你打算把所有服务器解析到一个域名上, 那么可以使用泛域名证书, 这样就不用为每一个节点都单独申请证书了.
:::
准备好每个节点自己的 mongod.pem, 把 CA 根证书 isrgrootx1.pem 拷贝给每一个节点. 我这里仍是直接挂载在了容器的 /etc/mongo/ 目录.
然后修改它们的配置文件:
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS // [!code ++]
certificateKeyFile: /etc/mongo/mongod.pem // [!code ++]
CAFile: /etc/mongo/isrgrootx1.pem // [!code ++]
allowConnectionsWithoutCertificates: true // [!code ++]
关于 net.tls 的配置详情参考:
配置完证书后可以准备启动副本集了.
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /data/db
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /etc/mongo/mongodb.pem
CAFile: /etc/mongo/isrgrootx1.pem
allowConnectionsWithoutCertificates: true
# how the process runs
processManagement:
timeZoneInfo: /usr/share/zoneinfo
security:
clusterAuthMode: keyFile
authorization: enabled
keyFile: /etc/mongo/keyfile
replication:
replSetName: "rs0"
| 示例节点名 | 域名 |
|---|---|
| Server A | servera.mongodb.example.com |
| Server B | serverb.mongodb.example.com |
| Server C | serverc.mongodb.example.com |
启动所有节点, 然后使用支持的客户端连接你打算作为主节点的节点, 使用 rs.initiate() 初始化副本集, 以 Server A 为例:
::: warning
只在一个节点上执行 rs.initiate()!
:::
rs.initiate( {
_id : "rs0",
members: [
{ _id: 0, host: "servera.mongodb.example.com:27017" },
{ _id: 1, host: "serverb.mongodb.example.com:27017" },
{ _id: 2, host: "serverc.mongodb.example.com:27017" }
]
})
或者, 也可以不向 rs.initiate() 传入配置, 而是初始化后再添加节点:
rs.initiate()
rs.add("serverb.mongodb.example.com:27017")
rs.add("serverc.mongodb.example.com:27017")
参考:
如果你的操作都正确, 那这里应该已经启动成功了 😇. 使用 rs.status() 查看副本集状态:
PRIMARY 就是主节点, SECONDARY 是从节点.
如果你发现有其他状态的节点, 可以查看 副本集成员状态 排查问题.
在上文, 我们连接到了主节点来初始化副本集, 它的连接字符串通常是像这样的:
mongodb://user:password@servera.mongodb.example.com:27017
但这样并不是连接到了 "整个" 副本集. 显然如果主节点挂了, 连接就会断开.
其实 MongoDB 可以使用多服务器连接字符串, 例如:
mongodb://user:pssword@servera.mongodb.example.com:27017,serverb.mongodb.example.com:27017,serverc.mongodb.example.com:27017/?replicaSet=rs0
服务器之间用逗号分隔, 这样就可以连接到整个副本集了, 如果主节点挂了, 客户端会自动切换到其他节点.
但是这样的连接字符串太长了, 十分不方便, 这时可以使用 SRV 记录来连接.
SRV 记录（Service Record）是一种 DNS 记录, 用于指定特定服务在域中的主机名和端口号. 可以用于负载均衡和服务发现, 使客户端可以动态地查找提供特定服务的服务器.
SRV 记录的设置需要在 DNS 服务商处设置, 以 Cloudflare 为例:
| 选项 | 值 | 说明 |
|---|---|---|
| Name | _mongodb._tcp.mongodbsrv | SRV 记录的 Name 由服务名和域名组成, _mongodb._tcp 为服务名, 这里 mongodbsrv 是二级域名 |
| Priority | 0 | 优先级, 对于 MongoDB 副本集不需要特别设置 |
| Weight | 1 | 权重, 对于 MongoDB 副本集不需要特别设置 |
| Port | 27017 | 端口号 |
| Target | servera.mongodb.example.com | 主机名, 填写解析到节点的域名 |
要为每一个节点都设置 Name 相同的 SRV 记录哦.
::: tip
设置 SRV 记录的域名和解析到节点使用的域名不一定要相同
:::
假设我们设置 SRV 记录的域名是 example.com, 接下来就可以使用 mongodb+srv 的字符串格式来连接副本集了:
mongodb+srv://user:password@mongodbsrv.example.com/?replicaSet=rs0
🎉
一些其他的自问自答:
为什么集群内认证不使用 X.509 证书?
太麻烦了, 使用 X.509 在节点间认证实际上是使用了基于角色的访问控制, 要在 $external 数据库中为节点配置角色, 还要自己维护 CA.
配置中的 tls.mode: requireTLS 和 allowConnectionsWithoutCertificates: true 是不是冲突的?
并不, requireTLS 是要求客户端使用 TLS 连接, allowConnectionsWithoutCertificates 是允许客户端不使用证书进行身份验证.
为什么不配置 net.tls.clusterFile ?
因为我们对集群内使用的是密钥文件 (keyfile) 验证.
clusterFile 用于集群内使用 X.509 证书进行身份验证.
即使集群内使用 X.509 证书验证, 不配置 clusterFile, MongoDB 也会自动使用 certificateKeyFile 的证书进行验证.
访问 https://krau.top/posts/deploy-mongodb-replica-set/index 查看原文。
]]>::: tip
本文环境:
CUDA 所需要的驱动版本一般挺新的, 所以需要在 Windows 上更新显卡驱动. 使用 Geforce Experience 或者去 官网下载页面 寻找符合你型号的驱动版本即可.
::: warning
注意是直接在 Windows 上更新, 不要跑去 WSL 里安装英伟达那恶心的 Linux 驱动了.
:::
更新完成后重启 WSL, 使用 nvidia-smi 查看信息:
在 英伟达下载页面 选择 WSL-Ubuntu 发行版, 选择 runfile (local) 进行下载.
wget https://developer.download.nvidia.com/compute/cuda/12.4.1/local_installers/cuda_12.4.1_550.54.15_linux.run
::: tip
留意你所需要的版本, 历史版本可去 归档页 下载, 本文下载的是 12.4 版本.
:::
下载完成后运行安装:
sudo sh cuda_12.4.1_550.54.15_linux.run
安装过程中会询问 EULA, 输入 accept 即可.
::: warning
不要更改默认安装选项, 同意 EULA 后应直接开始安装. 否则大概会卡住..
:::
安装完成后, 更新 PATH 和 LD_LIBRARY_PATH, 将下述内容添加到你的配置文件里 (如 ~/.bashrc 或 ~/.zshrc):
export PATH="/usr/local/cuda-12.4/bin:$PATH"
export LD_LIBRARY_PATH="/usr/local/cuda-12.4/lib64:$LD_LIBRARY_PATH"
重启终端使配置生效, 使用 nvcc --version 查看版本信息:
在 英伟达下载页面 下载 cuDNN, 选择与你环境相符的版本下载. 本文下载 cuDNN 9.2.0 for CUDA 12.4:
wget https://developer.download.nvidia.com/compute/cudnn/9.2.0/local_installers/cudnn-local-repo-debian12-9.2.0_1.0-1_amd64.deb
sudo apt install ./cudnn-local-repo-debian12-9.2.0_1.0-1_amd64.deb
添加 keyring 和源:
sudo cp /var/cuda-repo-debian12-9-2-local/cudnn-*-keyring.gpg /usr/share/keyrings/
sudo sed -i "s|^Components: main$|& contrib|" /etc/apt/sources.list.d/cudnn-local-debian12-9.2.0.list
注意根据 apt 的输出修改上述两行命令.
安装 cuDNN:
sudo apt update
sudo apt install -y cudnn-cuda-12
为了保证 gRPC 服务不被第三方监听和调用, 防止通信被篡改或伪造, 需要对 gRPC 服务添加身份验证机制.
目前 gRPC 内置了三种身份验证机制:
本文介绍 gRPC 中的 SSL/TLS.
::: tip
本文环境
使用 TLS 就需要证书. 在 Go 1.15 版本之后废弃了 CommonName, 而是要使用 Subject Alternative Name (SAN) 来验证证书的有效性. 因此如果按照以前的方法生成证书, 大概率会导致下面的错误:
rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0"
SAN 是 x509 定义中的一个扩展, 用于指定证书的使用范围. 使用了 SAN 扩展的证书, 可以在证书中指定多个域名或 IP 地址, 从而可以在一个证书中同时包含多个域名或 IP 地址.
CA (Certificate Authority), 即证书颁发机构, 用于管理和签发证书. 作用是检查证书持有者的合法性, 并颁发证书, 防止证书被伪造.
CA 自己也需要有证书, 称为根证书, 用于签发其他证书. 一般情况下, 根证书是自签名的, 即自己给自己签发证书. 根证书是信任链的起点, 有了根证书之后 CA 才能给其他人签发证书.
因此, 要想在 gRPC 中使用 TLS, 需要准备三组证书:
在任意目录下创建 ca.conf 文件:
[ req ]
default_bits = 4096
distinguished_name = moe
[ moe ]
countryName = GB
countryName_default = BeiJing
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = BeiJing
localityName = Locality Name (eg, city)
localityName_default = NanJing
organizationName = Organization Name (eg, company)
organizationName_default = Kompany
commonName = krau.top
commonName_max = 64
commonName_default = krau.top
执行下面的命令生成 CA 私钥:
openssl genrsa -out ca.key 4096
然后生成 CA 证书:
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -config ca.conf
根据提示输入各种信息, 最后会生成 ca.crt 文件.
新建 server.conf:
[ req ]
default_bits = 2048
distinguished_name = moe
[ moe ]
countryName = Country Name (2 letter code)
countryName_default = CN
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = JiangSu
localityName = Locality Name (eg, city)
localityName_default = NanJing
organizationName = Organization Name (eg, company)
organizationName_default = ovocom
commonName = CommonName (e.g. server FQDN or YOUR name)
commonName_max = 64
commonName_default = localhost # 此值应该包含在 [alt_names] 中
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
IP = 127.0.0.1
::: warning
commonName_default 的值应该包含在 [alt_names] 中, 并且在连接时, 客户端的值需要与其匹配.
:::
生成私钥:
openssl genrsa -out server.key 2048
生成 csr:
openssl req -new -key server.key -out server.csr -config server.conf
请求 CA 签发证书:
openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -extensions req_ext -extfile server.conf
客户端不需要配置文件, 直接生成私钥:
openssl genrsa -out client.key 2048
生成 csr:
openssl req -new -key client.key -out client.csr
请求 CA 签发证书:
openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt
现在已经准备好证书了. 服务端需要 server.crt 和 server.key, 客户端需要 client.crt 和 client.key. 此外, 两者都需要 ca.crt.
关注高亮行
package main
import (
"crypto/tls"
"crypto/x509"
"net"
"os"
"fmt"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials"
"example/proto"
)
func main() {
pair, err := tls.LoadX509KeyPair("./server.crt", "./server.key")
if err != nil {
fmt.Printf("Failed to load certificates: %s", err)
return
}
certPool := x509.NewCertPool()
ca, err := os.ReadFile("./ca.crt") // 读取根证书
if err != nil {
fmt.Printf("Failed to read ca certificate: %s", err)
return
}
if ok := certPool.AppendCertsFromPEM(ca); !ok {
fmt.Println("Failed to append ca certificate")
return
}
creds := credentials.NewTLS(&tls.Config{
Certificates: []tls.Certificate{pair},
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: certPool,
})
s := grpc.NewServer(grpc.Creds(creds))
proto.RegisterArtworkServiceServer(s, &server{})
lis, err := net.Listen("tcp", ":39010")
if err != nil {
fmt.Printf("Failed to listen: %s", err)
return
}
if err := s.Serve(lis); err != nil {
fmt.Printf("Failed to serve: %s", err)
return
}
}
关注高亮行
package main
import (
"crypto/tls"
"crypto/x509"
"os"
"example/proto"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials"
)
func main() {
pair, err := tls.LoadX509KeyPair("./client.crt", "./client.key")
if err != nil {
fmt.Printf("Failed to load certificates: %s", err)
return
}
certPool := x509.NewCertPool()
ca, err := os.ReadFile("./ca.crt")
if err != nil {
fmt.Printf("Failed to read ca certificate: %s", err)
return
}
if ok := certPool.AppendCertsFromPEM(ca); !ok {
fmt.Println("Failed to append ca certificate")
return
}
cred := credentials.NewTLS(&tls.Config{
Certificates: []tls.Certificate{pair},
ServerName: "localhost", // 服务端生成证书时的 commonName
RootCAs: certPool,
})
conn, err := grpc.Dial("127.0.0.1:39010", grpc.WithTransportCredentials(cred))
if err != nil {
fmt.Printf("Failed to dial: %s", err)
return
}
defer conn.Close()
client := proto.NewArtworkServiceClient(conn)
// ...
}
Protocol Buffers (Protobuf) 是一种语言无关、平台无关、可扩展的序列化结构化数据的方法, 可以像 XML, json 等一样用于程序间数据通信. 而相较于上列二者, Protobuf 有更高的效率.
使用 Protobuf 需要在 .proto 文件中定义数据结构, 并安装其编译器来生成对应语言的模型. 本文以 Go 为例.
::: tip
本文环境:
安装 Protobuf 编译器最简单的方法是在 Github Release 页面下载对应平台的二进制文件, 并加入 PATH 环境变量.
wget https://github.com/protocolbuffers/protobuf/releases/download/v24.4/protoc-24.4-linux-x86_64.zip
mkdir protoc && unzip protoc-24.4-linux-x86_64.zip -d protoc
export PATH=$PATH:/path/to/protoc/bin # 将此行加入终端配置文件中
为了在 Go 中使用 Protobuf 和默认使用 Protobuf 的 gRPC, 还需要安装 protoc-gen-go 和 protoc-gen-go-grpc
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
export PATH="$PATH:$(go env GOPATH)/bin" # 把 GOBIN 加入 PATH
Protobuf 的主要语法很简单也很 Go, 下例:
syntax = "proto3"; // 指定版本
option go_package = "example/proto"; // 指定 Go 代码生成的包名
package artwork; // 包名, 用于区分不同的 proto 文件. 注意此包名并不是 Go 中的包名
// 定义消息类型
message ArtworkInfo {
uint64 artworkID = 1;
string title = 2;
SourceName source = 3; // 引用枚举类型
repeated string tags = 4; // repeated 表示为数组
bool r18 = 5;
repeated PictureInfo pictures = 6; // 引用嵌套消息类型
// 定义枚举类型
enum SourceName {
Pixiv = 0;
Twitter = 1;
// ...
}
// 定义嵌套消息类型
message PictureInfo {
uint64 pictureID = 1;
uint64 width = 2;
uint64 height = 3;
}
}
可以看到 Proto 的消息定义和 Go 的结构体定义很像, 简要总结:
message 关键字 + 消息名, 在大括号内定义字段在规范上, Protobuf 有如下约定:
example.packageExampleMessage, ExampleServiceexample_field// 注释内容关于 Protobuf 的数据类型和各语言中的对应, 可以参考 官方文档#scalar
在 .proto 文件所在目录下执行:
protoc --go_out=. example.proto
protoc 会在当前目录下生成 proto/example.pb.go 文件, 其中包含了 example.proto 中定义的消息类型, 并且提供了一些方便的方法.
由 protoc 生成的文件不应直接修改, 如需更改, 应修改 .proto 文件后重新编译生成.
Protobuf 常与 gRPC 结合使用, 作为服务之间远程调用的数据传输格式.
gRPC 是一个基于 HTTP/2 的"高性能、开源和通用的 RPC 框架". gRPC 默认使用 Protobuf 作为接口定义语言和数据传输格式.
gRPC、 Protobuf 和 Go 都是由 Google 开发的, 这三者结合使用具有套装效果.
在项目目录下执行:
go get -u google.golang.org/grpc
定义一个服务, 并指定其可以被远程调用的方法, 以及方法的参数和返回值类型. 这即是 gRPc 定义服务的思想.
在上文的 example.proto 中定义一个服务:
syntax = "proto3"; // 指定版本
option go_package = "example/proto"; // 指定 Go 代码生成的包名
package artwork; // 包名, 用于区分不同的 proto 文件. 注意此包名并不是 Go 中的包名
// 定义消息类型
message ArtworkInfo {
uint64 artworkID = 1;
string title = 2;
SourceName source = 3; // 引用枚举类型
repeated string tags = 4; // repeated 表示为数组
bool r18 = 5;
repeated PictureInfo pictures = 6; // 引用嵌套消息类型
// 定义枚举类型
enum SourceName {
Pixiv = 0;
Twitter = 1;
// ...
}
// 定义嵌套消息类型
message PictureInfo {
uint64 pictureID = 1;
uint64 width = 2;
uint64 height = 3;
}
}
message GetArtworkInfoRequest { // [!code ++]
uint64 artworkID = 1; // [!code ++]
} // [!code ++]
// 定义服务 // [!code ++]
service ArtworkService { // [!code ++]
// 定义方法 // [!code ++]
rpc GetArtworkInfo (GetArtworkInfoRequest) returns (ArtworkInfo);// [!code ++]
} // [!code ++]
gRPC 有四种方法类型:
一元方法是最简单常用的方法. 客户端将请求消息作为参数发送给服务, 服务返回一个响应消息. 一元方法调用完成.
在实际代码中, 一元方法的调用就像是调用一个普通的函数.
上文的 GetArtworkInfo 方法就是一个一元方法.
服务端流式方法是指客户端发送一个请求消息, 服务端返回一个流式响应消息. 客户端从返回的流中读取响应消息, 直到没有消息为止.
定义流式方法, 需要在参数或返回值前加上 stream 关键字.
例如, 定义一个 GetArtworkInfoList 方法, 用于获取多个作品的信息:
syntax = "proto3"; // 指定版本
option go_package = "example/proto"; // 指定 Go 代码生成的包名
package artwork; // 包名, 用于区分不同的 proto 文件. 注意此包名并不是 Go 中的包名
// 定义消息类型
message ArtworkInfo {
uint64 artworkID = 1;
string title = 2;
SourceName source = 3; // 引用枚举类型
repeated string tags = 4; // repeated 表示为数组
bool r18 = 5;
repeated PictureInfo pictures = 6; // 引用嵌套消息类型
// 定义枚举类型
enum SourceName {
Pixiv = 0;
Twitter = 1;
// ...
}
// 定义嵌套消息类型
message PictureInfo {
uint64 pictureID = 1;
uint64 width = 2;
uint64 height = 3;
}
}
message GetArtworkInfoRequest {
uint64 artworkID = 1;
}
// 定义服务
service ArtworkService {
// 定义方法
rpc GetArtworkInfo (GetArtworkInfoRequest) returns (ArtworkInfo);
rpc GetArtworkInfoList (GetArtworkInfoRequest) returns (stream ArtworkInfo); // 定义流式方法 //[!code ++]
}
与服务端流式方法相反, 客户端向数据流中写入并发送一系列消息, 服务端从流中读取这些消息, 直到没有消息为止, 然后返回一个响应消息.
在方法参数前加上 stream 关键字即可定义客户端流式方法.
双向流式方法是指客户端和服务端都可以通过一个读写数据流来发送一系列消息. 这两个流独立运行, 因此客户端和服务端可以以任意顺序读写: 例如, 服务端可以在写入响应前等待接收所有客户端消息, 或者可以先读取一个消息, 然后再写入一个消息, 或者读取或写入多个消息, 甚至可以同时读写.
在方法参数和返回值前加上 stream 关键字即可定义双向流式方法.
上文所述的内容都还是在 proto 文件中完成, 要想在 Go 中使用, 还需要生成 Go 代码.
在项目目录下执行:
protoc --go_out=. --go-grpc_out=. example.proto
protoc 会在当前目录下生成 proto/example.pb.go 和 proto/example_grpc.pb.go 两个文件, 前者包含了 example.proto 中定义的消息类型, 后者包含了 example.proto 中定义的服务和方法.
实现上文定义的 ArtworkService 服务, 需要做两部分工作:
ArtworkService 服务中定义的所有方法. 即实现 example_grpc.pb.go 中的 ArtworkServiceServer 接口.打开 example_grpc.pb.go 文件, 可以看到 ArtworkServiceServer 接口的定义:
// ArtworkServiceServer is the server API for ArtworkService service.
// All implementations must embed UnimplementedArtworkServiceServer
// for forward compatibility
type ArtworkServiceServer interface {
GetArtworkInfo(context.Context, *GetArtworkInfoRequest) (*ArtworkInfo, error)
GetArtworkInfoList(*GetArtworkInfoRequest, ArtworkService_GetArtworkInfoListServer) error
mustEmbedUnimplementedArtworkServiceServer()
}
在项目中导入 example/proto 包, 并实现 ArtworkServiceServer 接口:
package main
import (
"context"
"log"
"net"
"example/proto"
"google.golang.org/grpc"
)
type ArtworkServiceServer struct {
proto.UnimplementedArtworkServiceServer // 为了实现向前兼容, 需要嵌入此结构体
}
func (s *ArtworkServiceServer) GetArtworkInfo(ctx context.Context, req *proto.GetArtworkInfoRequest) (*proto.ArtworkInfo, error) {
// 实现
return &proto.ArtworkInfo{}, nil
}
func (s *ArtworkServiceServer) GetArtworkInfoList(req *proto.GetArtworkInfoRequest, stream proto.ArtworkService_GetArtworkInfoListServer) error {
// 实现
for i := 0; i < 10; i++ {
err := stream.Send(&proto.ArtworkInfo{})
if err != nil {
return err
}
}
return nil
}
var server = &ArtworkServiceServer{}
func main() {
}
可以看到, 流式方法和一元方法的区别在于, 流式方法的参数或返回值是一个流, 需要向流中写入或读取消息.
func (s *ArtworkServiceServer) GetArtworkInfoList(req *proto.GetArtworkInfoRequest, stream proto.ArtworkService_GetArtworkInfoListServer) error {
// 实现
for i := 0; i < 10; i++ {
err := stream.Send(&proto.ArtworkInfo{})
if err != nil {
return err
}
}
return nil
}
在 main 函数中, 创建一个 gRPC 服务器, 并注册 ArtworkServiceServer:
func main() {
lis, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatalf("failed to listen: %v", err)
}
s := grpc.NewServer()
proto.RegisterArtworkServiceServer(s, server)
if err := s.Serve(lis); err != nil {
log.Fatalf("failed to serve: %v", err)
}
}
::: warning
此处没有使用任何安全措施
:::
在客户端调用 gRPC 服务, 只需要初始化连接, 并创建客户端, 然后直接调用定义的方法.
package main
import (
"context"
"log"
"example/proto"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
)
func main() {
conn, err := grpc.Dial("localhost:8080", grpc.WithTransportCredentials(insecure.NewCredentials()))
if err != nil {
log.Fatalf("did not connect: %v", err)
}
defer conn.Close()
client := proto.NewArtworkServiceClient(conn)
resp, err := client.GetArtworkInfo(context.Background(), &proto.GetArtworkInfoRequest{ArtworkID: 1})
if err != nil {
log.Fatalf("could not get artwork info: %v", err)
}
log.Println(resp)
}
而对于流式方法, 客户端需要从流中读取响应消息, 直到没有消息为止.
package main
import (
"context"
"log"
"io"
"example/proto"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
)
func main() {
conn, err := grpc.Dial("localhost:8080", grpc.WithTransportCredentials(insecure.NewCredentials()))
if err != nil {
log.Fatalf("did not connect: %v", err)
}
defer conn.Close()
client := proto.NewArtworkServiceClient(conn)
stream, err := client.GetArtworkInfoList(context.Background(), &proto.GetArtworkInfoRequest{ArtworkID: 1})
if err != nil {
log.Fatalf("could not get artwork info: %v", err)
}
for {
resp, err := stream.Recv()
if err == io.EOF { // 判断是否已结束
break
}
if err != nil {
log.Fatalf("could not get artwork info: %v", err)
}
log.Println(resp)
}
}
访问 https://krau.top/posts/grpc-and-protobuf-in-go-start 查看原文。
]]>conda 是一个 python 的环境管理器, 它包含在 Anaconda 内, Anaconda 是专注于数据分析的Python发行版本.
即使你没有数据分析\科学计算的需求, 也可以使用 conda 这个强大的工具来管理 python 环境
如果你不想安装这么大一个东西, 可以看我上次发的使用 venv + 编译安装的方式管理python环境
去Anaconda官网下载
或者你可以选择 Miniconda
wget https://repo.anaconda.com/archive/Anaconda3-2023.03-Linux-x86_64.sh
下载完成后, 执行 bash Anaconda3-2023.03-Linux-x86_64.sh 即可开始安装
安装完成后, 重启终端, 即可使用 conda
更新
conda update --all
创建虚拟环境
conda create -n <name> python=<version>
-n 后是虚拟环境的名字, python=version 指定要使用的 python 版本
激活环境
conda activate <name>
退出虚拟环境
conda deactivate
删除虚拟环境
conda env remove <name>
列出虚拟环境
conda env list
列出当前环境的包
conda list
安装包, 和 pip 一样
conda install <package>
访问 https://krau.top/posts/manage-python-version-by-conda 查看原文。
]]>本文系统环境为 Debian11, 虚拟环境工具使用的是 venv, 采用编译安装的方法. Python 版本为 3.11.6
去往 Python 官网 下载你想安装的版本的源码, 以目前最新的 Python3.11 为例
使用 wget 下载:
wget https://www.python.org/ftp/python/3.11.6/Python-3.11.6.tar.xz
下载完成后, 将其解压:
tar -xf Python-3.11.6.tar.xz
安装必要的依赖软件:
sudo apt update
sudo apt install build-essential zlib1g-dev libncurses5-dev \
libgdbm-dev libnss3-dev libssl-dev libsqlite3-dev pkg-config \
libreadline-dev libffi-dev curl libbz2-dev curl libgdbm-dev \
lzma-dev uuid-dev libsqlite3-dev openssl tk8.6-dev -y
进入 Python 源码文件夹, 并配置
cd Python-3.11.6
./configure --enable-optimizations --with-lto --prefix=/usr/local/python3.11
::: tip 注意
configure 后的 --enable-optimizations --with-lto 两个参数是为了提高性能, 但它会使得 Python 编译过程变慢, 你可以选择不启用它们. 如果你遇到了问题, 可以尝试只开启 --enable-optimizations, 或者二者都不使用
关于配置参数的更多信息, 可以参阅官方文档
:::
如果上面命令的输出没有错误, 那么就可以开始编译了.
若提示缺少某个依赖, 请手动安装它
运行 make 即可开始构建 Python , 若你有多个 cpu 核心, 可以加上 -j 参数来多核编译, -j 后是你的 cpu 核心数, 可以使用 nproc 获取
若你机器的性能不佳, 这一过程可能十分漫长(几十分钟甚至更久), 你可以使用 screen 或 tmux 使其在后台运行
完成后, 使用 sudo make altinstall 安装(可能也很漫长,但比上一步要快), 之后你就可以使用 Python3.11:
python3.11 --version
Python 的虚拟环境可以将项目与全局环境相互隔离,可以避免污染你的系统环境,并方便得使多个 Python 版本共存与切换.
本文使用的虚拟环境工具是 venv , 它是 Python 官方推荐的工具.
但其实更现代的工具是 poetry , 然而其使用比较复杂,且主要面向 pypl 模块开发者, 如有兴趣你可以自行了解.
安装 venv:
apt install python3-venv
使用以下命令在当前目录下创建虚拟环境:
python3.11 -m venv myenv
这个命令会在你当前目录下创建 myenv 文件夹, 它就是一个"虚拟环境", 其中包含了你所指定的 Python3.11 版本, 未来在虚拟环境中安装的第三方库等文件也会在此文件夹内.
显然, 如果你想创建一个其他 Python 版本的虚拟环境, 那么只需要将前面的 python3.11 改成你需要的版本且已经安装的即可
创建完成后,要进入到虚拟环境,需要激活它,使用以下命令.
source myenv/bin/activate
这时你的终端应该会有一些标识来提示你处在虚拟环境中,如下
在虚拟环境中, python python3.11 python3 命令都可以打开 python ,并且版本都是 python3.11
在其中使用 pip 安装的包也都在虚拟环境中
使用 deactive 命令可退出虚拟环境
使用 venv 工具创建的虚拟环境实际上就是一个文件夹, 删除它就是删除了环境
始终建议使用官方软件源提供的 python 作为默认版本, 如果你真的想要替换默认版本, 那么可以使用下面的命令
sudo ln -sf /usr/bin/python3.11 /usr/bin/python
这条命令将 python3.11 的可执行文件链接到 linux PATH 的默认搜索路径中, 此时系统的默认版本就是 3.11
::: tip
即使默认版本就是你想要使用的 Python 版本, 你也应该在你的项目里创建虚拟环境, 除非你想把自己的系统环境搞得乱七八糟
:::
访问 https://krau.top/posts/install-manage-python-version-on-linux/index 查看原文。
]]>JWT: JSON Web Tokens,它是一种将 JSON 对象编码为没有空格，且难以理解的长字符串的标准。在具体上,它就是一段字符串,下面就是 FastAPI 文档中给出的例子
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
抽象地把它看成是这样的
aaaaaaaaaaaa.bbbbbbbbbbbb.cccccccccccc
jwt 由三个部分组成,这三个部分之间用点.拼接起来,这三个部分分别是
这三个部分中,只有第三个部分是无法还原的,前两个部分只是简单的进行了 base64 编码,把上面例子中的前两部分解码之后,看起来是这样的:
Header:
{
"alg":"HS256",
"typ":"JWT"
}
alg 即为算法,这里使用了 HS256 算法
typ 即为类型,指明这里是一个 JWT 字符串
Payload
{
"sub":"1234567890",
"name":"John Doe",
"iat":1516239022
}
可以看到 Payload 中存储了主要的信息
::: tip 提示
根据 JWT 规范, Payload 中的 sub 是一个预定义的声明（Claim），表示JWT的主题（Subject）。它指定了JWT所代表的实体或主题，通常是用户或客户端应用程序。
sub声明的值是字符串类型，通常是唯一标识用户或客户端应用程序的ID。
:::
而 Signature 则是通过加盐加密得到的,加密由服务端实现
::: tip 关于具体如何实现
参考下图
即,把 header 和 payload 部分进行 base64编码,用点拼接起来,得到结果,把这个结果用我们设置的密钥和算法进行加盐加密,就得到了 Signature
:::
其实它与 token ,cookie 的作用类似,就是用来免密码认证客户端
比如你去上学,学校是服务端,你是客户端.你完成学籍注册之后,学校发给你一个学生证,学生证就是你的 jwt 令牌.
你使用学校的很多服务,都要出示学生证.
而在实际业务中,jwt 令牌是有过期时间的,过期之后,需要客户端再次登录,获取新的 jwt
需要安装以下几个包
python-jose，在 Python 中生成和校验 JWT 令牌
pip install python-jose[cryptography]
Passlib ,处理密码哈希
pip install passlib[bcrypt]
::: warning
密码哈希和 jwt 的加密不是同一个问题.
哈希是指把特定内容（本例中为密码）转换为乱码形式的字节序列（其实就是字符串）。
每次传入完全相同的内容时（比如，完全相同的密码），返回的都是完全相同的乱码。
但这个乱码无法转换回传入的密码。
把密码进行哈希并存储是必要的安全措施
:::
先不考虑用户注册的问题,假设我们已经有了一个在数据库中的用户,那么这里的逻辑是这样的:
所以,我们需要:
呃,为了简便和偷懒,就用 FastAPI 文档中的假数据库吧
fake_users_db = {
"johndoe": {
"username": "johndoe",
"full_name": "John Doe",
"email": "johndoe@example.com",
"hashed_password": "$2b$12$EixZaYVK1fsbw1ZfbX3OXePaWxn96p36WQoeG6Lruj3vjPGga31lW",
"disabled": False,
}
}
定义之后要用到的模型
from pydantic import BaseModel
from typing import Union
class Token(BaseModel):
access_token: str
token_type: str
class TokenData(BaseModel):
username: Union[str, None] = None
class User(BaseModel):
username: str
email: Union[str, None] = None
full_name: Union[str, None] = None
disabled: Union[bool, None] = None
class UserInDB(User):
hashed_password: str
Token 模型用于在登录接口中指定 response_model
TokenData 用于从 token 中获取数据
User 即用户模型,供外部使用
UserInDB 是用户在数据库中的模型,它继承自 User 添加了 hashed_password 属性
这些模型在之后会用到
这部分比较简单,就是把用户输入的密码哈希之后和数据库中的对比就好了
from passlib.context import CryptContext
pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
def verify_password(plain_password, hashed_password):
"""
校验密码是否正确
将传入的明文密码与数据库中的哈希值进行比对
"""
return pwd_context.verify(plain_password, hashed_password)
def get_password_hash(password):
"""获取传入的密码的哈希值"""
return pwd_context.hash(password)
def get_user(db, username: str):
"""根据用户名从指定数据库中获取用户"""
if username in db:
user_dict = db[username]
return UserInDB(**user_dict)
def authenticate_user(fake_db, username: str, password: str):
"""身份验证, 返回用户对象或者 False"""
user = get_user(fake_db, username)
if not user:
return False
if not verify_password(password, user.hashed_password):
return False
return user
完成认证之后,就可以给用户创建 token 了
首先,定义 jwt 的加密密钥,加密算法和过期时间
SECRET_KEY = "09d25e094faa6ca2556c818166b7a9563b93f7099f6f0f4caa6cf63b88e8d3e7"
ALGORITHM = "HS256"
ACCESS_TOKEN_EXPIRE_MINUTES = 30
::: warning 注意
在实际项目中,jwt 的密钥不应该直接写在代码中,而是应该从环境变量中读取
例如,从环境变量中获取 SECRET_KEY
import os
SECRET_KEY = os.environ.get("SECRET_KEY")
:::
然后写创建 token 的函数
from datetime import datetime, timedelta
from jose import JWTError, jwt
def create_access_token(data: dict, expires_delta=None):
"""创建 jwt token"""
to_encode = data.copy()
if expires_delta:
expire = datetime.utcnow() + expires_delta
else:
expire = datetime.utcnow() + timedelta(minutes=15)
to_encode.update({"exp": expire})
# 注意这里就用到了上面定义的 SECRET_KEY 和 ALGORITHM
encoded_jwt = jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
return encoded_jwt
上面这个函数把传入的用于获取 jwt 的数据进行拷贝,并添加过期时间,然后 encode 得到 jwt token 并返回
至此,我们完成了对用户的校验和认证,以及创建 jwt token 的功能,下面我们要在接口中使用它们
from fastapi import Depends, FastAPI, HTTPException, status
from fastapi.security import OAuth2PasswordBearer, OAuth2PasswordRequestForm
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")
@app.post("/token", response_model=Token)
async def login_for_access_token(form_data: OAuth2PasswordRequestForm = Depends()):
"""登录并获取 token"""
# 通过用户名和密码获取用户, 如果用户不存在或者密码错误, 则抛出异常
user = authenticate_user(fake_users_db, form_data.username, form_data.password)
if not user:
raise HTTPException(
# 这部分是规范, 401 表示未授权
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Incorrect username or password",
headers={"WWW-Authenticate": "Bearer"},
)
# 上面已经相当于进行了用户身份验证, 所以这里可以直接创建 token
access_token_expires = timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
access_token = create_access_token(
data={"sub": user.username}, expires_delta=access_token_expires
)
# 这里如何返回也是规范, 我们已在上面已经定义好了 response_model=Token
return {"access_token": access_token, "token_type": "bearer"}
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token") 声明了用户应该从哪个路由获取 token (相对路径),但是并未实现具体的功能
而我们自己写的 login_for_access_token 则是实现.
现在用户成功登录后,就拿到了 jwt token ,访问其他服务时,浏览器会携带 jwt token 一起发送请求
我们只需要在其他接口中,对用户传来的 jwt token 进行验证即可
比如我们有一个获取用户信息的接口 read_users_me ,那么,我们需要:
首先,解密 jwt token ,获取当前用户:
async def get_current_user(token: str = Depends(oauth2_scheme)):
"""依赖函数, 用于获取当前用户"""
# 定义一个异常, 用于在用户身份验证失败时抛出
credentials_exception = HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="Could not validate credentials",
headers={"WWW-Authenticate": "Bearer"},
)
try:
payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
# 从 payload 中获取 username
# 关于 sub 的解释, 可以参考文档
username: str = payload.get("sub")
if username is None:
raise credentials_exception
token_data = TokenData(username=username)
except JWTError:
raise credentials_exception
user = get_user(fake_users_db, username=token_data.username)
if user is None:
raise credentials_exception
return user
async def get_current_active_user(current_user: User = Depends(get_current_user)):
"""依赖函数, 用于获取当前活跃的用户,用到了上面的依赖函数 get_current_user
为什么 current_user 可以是 User 类型而不是 get_current_user 返回的 UserInDB 类型呢?
因为 UserInDB 类型是 User 类型的子类, 所以可以直接赋值给 User 类型的变量
"""
if current_user.disabled:
raise HTTPException(status_code=400, detail="Inactive user")
return current_user
在 数据库与模型 中, 我们定义的 TokenData 就是这里要用的
因为只是演示,所以这个 TokenData 类显得有点多此一举.
但是如果你需要传递多个 JWT 数据，或者有多个函数需要访问 JWT 数据，那么 TokenData 类可以方便地将这些数据打包在一起，并在函数之间传递它们。
之后就可以在接口中利用依赖注入,验证用户请求
@app.get("/users/me/", response_model=User)
async def read_users_me(current_user: User = Depends(get_current_active_user)):
"""获取当前用户信息"""
return current_user
JWT 是一种认证方式,它的本质是一段带有签名的字符串.
在 Python 中,我们可以使用 jwt 模块来创建和解析 jwt token.
在 FastAPI 中,我们可以使用 OAuth2PasswordBearer 来获取用户传来的 token,然后使用 jwt 模块来解析 token,从而获取用户信息.
突然想安装 Arch 的理由：
电脑是拯救者Y9000P2022款，配置：
很简单，查 Archlinux官方wiki 就可以了。嫌官方的不够友好的话可以看这个：ArchLinux简明指南
SoNvidiaFUCKYOU!
折腾了很长时间，这n卡的驱动就是装不上，最后是重装了系统，然后安装开源版驱动解决了：
sudo pacman -S nvidia-open
安装之后的处理和wiki里是一样的，好像比较新的型号的显卡（30系）都是要安装这个驱动。
这个开源版并不是社区的那个逆向出来的开源版，而是nvidia官方给的，性能是没有太大问题的
SoNvidiaFUCKYOU!
n卡+linux桌面=shit!N卡用户建议暂时不要用wayland，老老实实Xorg，兼容性比wayland好太多了。
简单来说这还是N卡的锅，各种折腾尝试有可能会解决，玄学就是了。
我能正常使用多显示器的情景有两个：
optimus-manager 开核显模式。optimus-manager。另外这两种模式都是Xorg，nvidia对wayland真的没啥兼容性，会出现一堆奇怪问题。
安装这个就可以了
sudo pacman -S bluez bluez-utils pulseaudio-bluetooth
太好用啦！所有软件都用pacman或者yay直接安装，并且能纳入滚动升级中。
Telegram：字体有问题，安装了几个中文字体之后正常了，体验和win是一样的，tg官方对于linux平台也是下了精力的。实在不行还能用web端。
QQ：你没事吧？跟张小龙学会了登个号还得手机扫码？口区。而且登录的时候还会提示安全风险，难绷，不愧是腾讯。
火狐，很不错。但是缩放有时候会出问题，打开的时候界面突然很小或者很大...应该是我多显示器的原因。
然后还试了试 brave，只能说好像没多好用，而且一股子去中心化web3区块链虚拟币的味道。
出乎意料的流畅啊！谁说的linux打游戏是ppt的，体验和win没感知上的差距。当然可能是我不玩什么3a大作（实际上来说我几乎不玩游戏了），玩了 muse dash 这个音游试了下，体验真的和win没什么区别。
终端软件用的是 Termius（学生包白嫖的不用白不用），IDE还是vscode。
好用！
快来加入Arch邪教吧！
顺便，Arch的图标真的是太好看啦！
Artitalk 是一个基于 Leancloud 的简单说说 js，具体参见官方文档。
我成功将它接入了我的博客，点这里看看。下面简单介绍一下接入方法。
由于构建上的一些问题，我把它暂时移除了
这一步与官方文档完全相同，点击查看
在博客根目录下，新建 index.heml，写入以下内容
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width,initial-scale=1.0">
<link rel="icon" href="favicon.ico">
<title><%= htmlWebpackPlugin.options.title %></title>
</head>
<body>
<noscript>
<strong>We're sorry but <%= htmlWebpackPlugin.options.title %> doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
</noscript>
<div id="app"></div>
<script src="https://cdn.jsdelivr.net/npm/artitalk"></script>
</body>
</html>
然后在 /components/ 目录下，新建 Artitalk.vue ，写入以下内容
<template>
<div id="artitalk_main" />
</template>
<script>
export default {
mounted() {
function addScript(url) {
var s = document.createElement("script");
s.id = "at";
url.indexOf("appId") == -1 ? (s.src = url) : (s.innerHTML = url);
document.head.appendChild(s);
}
addScript(`
new Artitalk({
appId: '你的appid',
appKey: '你的key',
shuoPla: '',
bgImg: 'https://cdn.jsdelivr.net/gh/drew233/cdn/20200409110727.webp',
atEmoji: {
huaji: 'https://cdn.jsdelivr.net/gh/moezx/cdn@3.1.9/img/Sakura/images/smilies/icon_huaji.gif',
baiyan: 'https://cdn.jsdelivr.net/gh/Artitalk/Artitalk-emoji/baiyan.png',
bishi: 'https://cdn.jsdelivr.net/gh/Artitalk/Artitalk-emoji/bishi.png',
bizui: 'https://cdn.jsdelivr.net/gh/Artitalk/Artitalk-emoji/bizui.png',
chan: 'https://cdn.jsdelivr.net/gh/Artitalk/Artitalk-emoji/chan.png'
},
})
`);
},
destroyed() {
document
.querySelectorAll("#at")
.forEach(element => element.parentNode.removeChild(element));
delete window.AV;
}
};
</script>
这样就可以啦。在你想要显示说说的页面(.md文件)里，写上<Artitalk /> 就可以显示了。
目前 Artitalk 只支持以 Leancloud 作为数据库，并且 cdn 用的还是 jsdeliver，速度感人。我提了 issue 希望能支持更多部署方式，不过看起来作者已经失踪有一段时间了...
近期的文章内的图片都已经压缩成了 webp 格式。但是 PasteImage 却不支持 webp 格式，于是我又想办法整出了今天这个解决方案，实现完全自动化的 压缩+插入图片。
sharex 是一个强大的截屏、录屏、分享软件，开源免费，支持高度自定义的自动化，
然后还要安装 ffmpeg ，它在本文的作用是通过命令调用来压缩图片。
然后在 sharex 的动作设置中，添加一个动作
-i "$input" -q 75 "$output" 其中 -q 75 是以75%质量压缩勾上下面的 隐藏窗口 和 删除输入文件
然后在截图后的任务里选中这些项(添加图像特效可视情况自行添加)
Markdown Image 是一个 VSCode 插件，支持将剪贴板中的图片保存在指定路径下(或指定图床中)，并自动生成 markdown 格式的引用。
我的博客的文章图片是按照 /public/photo/post-pics/文章名/文章名_时间 的格式和路径保存在本地的，所以按照下面这样配置
"markdown-image.base.fileNameFormat": "${mdname}/${mdname}_${MM}-${DD}-${HH}-${mm}-${ss}",
"markdown-image.local.path": "../../public/photo/post-pics/",
"markdown-image.local.referencePath": "/photo/post-pics/${mdname}/",
更详细的配置，参照 Markdown Image 的官方文档
这样就完成啦。现在使用 sharex 截屏时会自动调用 ffmpeg 将文件压缩为 webp 格式并保存在剪贴板中，然后在 VSCode 中使用 Alt + Shift + V 粘贴即可。
访问 https://krau.top/posts/capture-screen-compress-to-webp-and-insert-markdown/index 查看原文。
]]>这是一个各种意义上很新的东西，它的目标是成为下一代静态博客框架。
更多关于 valaxy 的介绍:
项目地址：YunYouJun/valaxy
官方文档：valaxy
但是 valaxy 并不旨在成为下一代的 hexo ，也就是说并不向着与 hexo 的兼容的方向开发。因此迁移起来并不是特别简单。
Valaxy 要求 Node.js 的 14.18 以上，如果你是从 hexo 的较新版本迁移的，一般不需要去升级。
valaxy 建议使用 pnpm 作为包管理器，使用 npm i -g pnpm 全局安装它
在工作文件夹下，使用以下命令
pnpm create valaxy
然后输入你的博客文件夹名，同时也是项目名称，默认为 valaxy-blog。我这里使用 valaxy-demo
随后询问是否现在安装并启动，确定。
很快就完成了项目创建，此时可以在终端中按 o 打开浏览器预览
进入创建好的项目文件夹，使用以下命令安装依赖
# install
pnpm i
valaxy 在默认局部配置脚本下的一些命令
开启本地开发环境（预览，支持热重载）
pnpm run dev
构建静态文件
pnpm run build
升级(pnpm 交互升级命令)
# upgrade valaxy
pnpm up --latest -i
新建文章
pnpm new post-title
在此简要了解一下目录结构，见下图
其中 valaxy.config.ts 是主要需要修改的配置。建议使用 VSCode 编辑它，并按照提示安装推荐的插件。
valaxy.config.ts 提供了完备的类型提示，这意味着你在 VSCode 中可以直接鼠标悬浮查看各参数注释。
默认有些配置项未在 valaxy.config.ts 中给出，使用的是默认值，可以自己添加上就可以覆盖默认值。
示例:
url: 'http://krau.top',
lang: 'zh-CN',
title: '柯罗krau的博客 | krau\'s blog',
subtitle: '',
author: {
name: '柯罗krau',
avatar: '/photo/avatar/avatar.jpg',
status:
{
emoji: '😐',
message: '真不想上学'
}},
mode: 'auto',
lastUpdated: true,
favicon: '',
description: '年轻，就要折腾',
//...
示例:
social: [
{
name: 'RSS',
link: '/atom.xml',
icon: 'i-ri-rss-line',
color: 'orange',
},
{
name: 'GitHub',
link: 'https://github.com/krau',
icon: 'i-ri-github-line',
color: '#6e5494',
},
{
name: '网易云音乐',
link: 'https://music.163.com/#/user/home?id=1428613796',
icon: 'i-ri-netease-cloud-music-line',
color: '#C20C0C',
},
{
name: '哔哩哔哩',
link: 'https://space.bilibili.com/296036767',
icon: 'i-ri-bilibili-line',
color: '#FF8EB3',
},
{
name: 'Telegram Channel',
link: 'https://t.me/acherkrau',
icon: 'i-ri-telegram-line',
color: '#0088CC',
},
{
name: 'Telegram Group',
link: 'https://t.me/blogszh',
icon: 'i-ri:telegram-fill',
color: '"#0088CC'
},
{
name: 'E-Mail',
link: 'mailto:me@krau.top',
icon: 'i-ri-mail-line',
color: '#8E71C1',
},
{
name: 'Travelling',
link: 'https://www.travellings.cn/go.html',
icon: 'i-ri-train-line',
color: 'var(--va-c-text)',
},
],
示例:
search: {
enable: true,
type: 'engine',
},
示例:
sponsor: {
enable: false,
title: '我很可爱，请给我钱！',
methods: [
{
name: '支付宝',
url: '',
color: '#00A3EE',
icon: 'i-ri-alipay-line',
},
{
name: 'QQ 支付',
url: '',
color: '#12B7F5',
icon: 'i-ri-qq-line',
},
{
name: '微信支付',
url: '',
color: '#2DC100',
icon: 'i-ri-wechat-pay-line',
},
],
},
valaxy 目前默认主题是 yun
示例:
theme: 'yun',
themeConfig: {
banner: {
enable: true,
title: '柯罗の自留地',
},
bg_image: {
enable: true,
url: '/photo/bg/atri.webp',
dark: '/photo/bg/bg.webp',
opacity: 0.7
},
colors: {
primary: '#39c5bb'
},
say:{
enable: false
},
pages: [
{
name: '友人帐',
url: '/links/',
icon: 'i-ri-genderless-line',
color: 'dodgerblue',
},
{
name: 'My Love',
url: '/girls/',
icon: 'i-ri-women-line',
color: 'hotpink',
},
],
footer: {
since: 2020,
beian: {
enable: false,
icp: '苏ICP备17038157号',
},
},
},
valaxy 通过插件的方式实现评论，目前实现了对 waline 的支持
comment: {
enable: true,
},
addons: [
addonWaline({
serverURL: '后端链接',
//以下功能未实现，但可以先写进配置里
pageview: true,
dark: 'auto',
requiredMeta: ['nick','mail'],
locale:{
placeholder: '填写邮箱，可以收到回复通知~'
}
}),
],
import { defineConfig } from 'valaxy'
import type { ThemeConfig } from 'valaxy-theme-yun'
import { addonWaline } from 'valaxy-addon-waline'
//import { defineConfig } from 'vite'
// add icons what you will need
/**
* User Config
*/
export default defineConfig<ThemeConfig>({
url: 'https://krau.top',
lang: 'zh-CN',
title: '柯罗krau的博客 | krau\'s blog',
subtitle: '',
author: {
name: '柯罗krau',
avatar: '/photo/avatar/avatar.jpg',
status:
{
emoji: '😐',
message: '真不想上学'
}},
mode: 'auto',
lastUpdated: true,
favicon: '',
description: '年轻，就要折腾',
social: [
{
name: 'RSS',
link: '/atom.xml',
icon: 'i-ri-rss-line',
color: 'orange',
},
{
name: 'GitHub',
link: 'https://github.com/krau',
icon: 'i-ri-github-line',
color: '#6e5494',
},
{
name: '网易云音乐',
link: 'https://music.163.com/#/user/home?id=1428613796',
icon: 'i-ri-netease-cloud-music-line',
color: '#C20C0C',
},
{
name: '哔哩哔哩',
link: 'https://space.bilibili.com/296036767',
icon: 'i-ri-bilibili-line',
color: '#FF8EB3',
},
{
name: 'Telegram Channel',
link: 'https://t.me/acherkrau',
icon: 'i-ri-telegram-line',
color: '#0088CC',
},
{
name: 'Telegram Group',
link: 'https://t.me/blogszh',
icon: 'i-ri:telegram-fill',
color: '"#0088CC'
},
{
name: 'E-Mail',
link: 'mailto:me@krau.top',
icon: 'i-ri-mail-line',
color: '#8E71C1',
},
{
name: 'Travelling',
link: 'https://www.travellings.cn/go.html',
icon: 'i-ri-train-line',
color: 'var(--va-c-text)',
},
],
search: {
enable: true,
type: 'engine',
},
sponsor: {
enable: false,
title: '我很可爱，请给我钱！',
methods: [
{
name: '支付宝',
url: '',
color: '#00A3EE',
icon: 'i-ri-alipay-line',
},
{
name: 'QQ 支付',
url: '',
color: '#12B7F5',
icon: 'i-ri-qq-line',
},
{
name: '微信支付',
url: '',
color: '#2DC100',
icon: 'i-ri-wechat-pay-line',
},
],
},
theme: 'yun',
themeConfig: {
banner: {
enable: true,
title: '柯罗の自留地',
},
bg_image: {
enable: true,
url: '/photo/bg/atri.webp',
dark: '/photo/bg/bg.webp',
opacity: 0.7
},
colors: {
primary: '#39c5bb'
},
say:{
enable: false
},
pages: [
{
name: '友人帐',
url: '/links/',
icon: 'i-ri-genderless-line',
color: 'dodgerblue',
},
{
name: 'My Love',
url: '/girls/',
icon: 'i-ri-women-line',
color: 'hotpink',
},
],
footer: {
since: 2020,
beian: {
enable: false,
icp: '苏ICP备17038157号',
},
},
},
unocss: {
safelist: [
'i-ri-home-line',
],
},
comment: {
enable: true,
},
addons: [
addonWaline({
serverURL: 'https://后端',
pageview: true,
dark: 'auto',
requiredMeta: ['nick','mail'],
locale:{
placeholder: '填写邮箱，可以收到回复通知~'
}
}),
],
})
由于原先在 hexo 的文章有太多 valaxy 不支持的 frontmatter 项，所以需要批量修改它们，以免引起奇怪的问题
由于文章数多，所以写个简单的脚本批量操作
需要先安装 python-frontmatter
pip3 install python-frontmatter
import frontmatter
import glob
path = 'posts' #你的文章路径，相对于该脚本
mds = glob.glob(f'./{path}/*.md')
def del_metedata(md: str, key: str | list):
post = frontmatter.load(md)
metedata = post.metadata
try:
if isinstance(key, list):
for k in key:
try:
del metedata[k]
except:
continue
elif isinstance(key, str):
del metedata[key]
else:
raise TypeError('key 是 str 或 list')
frontmatter.dump(post, md)
except Exception as e:
print(f'{e} 在 {md}')
def add_metedata(md: str, key: str, value: str):
post = frontmatter.load(md)
metedata = post.metadata
try:
metedata[key] = value
frontmatter.dump(post, md)
except Exception as e:
print(f'{e} 在 {md}')
def main():
del_keys = [
#要删除的项，你可以根据需要修改
'toc',
'abbrlink',
'mathjax',
'author',
'hide',
'sitemap',
'indexing',
'top',
'password',
'summary',
'comments',
'reward',
'license',
'edit',
'copyright',
'sticky',
'description'
]
for md in mds:
del_metedata(md,del_keys)
#添加你需要的项,如添加 layout: post
add_metedata(md, 'layout', 'post')
if __name__ == '__main__':
main()
如果你全站都使用的图床，可以忽略这一步。而我为了方便管理，把图片放在了本地，所以需要修改
原先是在 hexo 的 source 目录下，需要使用相对路径引用。而 valaxy 可以直接引用静态文件夹(public)内的文件，直接使用 /xxxx 即可
例如，我原先的图片路径是
../photos/post-pics/1.webp
那么只需要将原先在 hexo 博客目录的 photos 文件夹移动到 valaxy 的 public 文件夹下，然后将路径修改为
/photos/post-pics/1.webp
这里的修改可以使用 VSCode 的全局关键字替换功能
把文章移动到 博客文件夹/pages/posts 下即可
但是我在操作的时候发现，一次性塞进去太多文章会导致预览页面加载不出来，这可能是一个 bug (版本 0.12.2 )。当然构建是没问题的，所以如果你不需要本地预览的话，可以直接都丢进去。
valaxy 的 yun 主题的友联页面在 pages/links/index.md，在 frontmatter 里配置就可以了，参考 valaxy-theme-yun 文档
注意 frontmatter 的下面要写一个
<YunLinks :links="frontmatter.links" :random="frontmatter.random" />
与 hexo-theme-yun 的配置相同，但是 frontmatter 下面要加上
<YunGirls :girls="frontmatter.girls" :random="frontmatter.random" />
哪来的二次元
这样就完成迁移了。如果有其他问题，或者需要更多信息，可以对比云游君的博客仓库中 hexo 和 valaxy 分支的差异。或者提出 issue 、提出讨论 ，以及在我博客下评论留言。
访问 https://krau.top/posts/hexo-migrate-to-valaxy/index 查看原文。
]]>修复了一些错误, 删除了一些不必要的内容
本文只是我最初写 bot 时的一点笔记, 更建议你直接看 Python-Telegram-Bot 的文档
:::
为了激发群友们水群的积极性， 为了学习和应用 python 知识，我最近在开发一个 telegram 的 bot，所以写这篇文章以记录和分享
在这篇文章中，将使用 Python-Telegram-Bot ，基于 Python 的异步特性与 Telegram 友好开放的 API，开发一个兼顾实用性和趣味的 bot ，并使用 Docker 在任何地方部署 bot
Demo: kmua-bot
本文不是从零开始的教程，阅读本文前，你需要具有一点点(真的很少一点)的 python 编程的基础。
使用你喜欢的工具创建虚拟环境，并安装 python-telegram-bot 库
pip install python-telegram-bot
私聊 @BotFather。发送 /newbot，根据提示一步步创建，记得妥善保存最后的 API Token。
每个 tg 用户都有一串唯一标识，即为 user_id，可以私聊 @kmua 发送 /id 来获取它
在项目文件夹内，新建 bot.py，开始编写 bot 最基础的功能，让其响应 /start 命令
首先，导入包
from telegram import Update
from telegram.ext import ApplicationBuilder, ContextTypes, CommandHandler
Update 类是从 Telegram 服务器获取到的各种"更新", 包括而不限于用户发送的消息, 群组的信息变化等.
然后，写一个异步函数 start()，当收到 /start 命令时，要调用它。
async def start(update: Update, context: ContextTypes.DEFAULT_TYPE):
text = '你好~我是一个bot'
await context.bot.send_message(chat_id=update.effective_chat.id,text=text)
这个函数接受两个参数 update 和 context，形参冒号后是类型注解。
context.bot.send_message() 方法即为让 bot 发送消息，它能接受的参数其实很多，但是往往只需要 chat_id ，和 text 就够了，它们分别表示 要发送消息给的用户或群组 id ，要发送的文本。
而 update.effective_chat.id 即为当前有效对话的 id ，bot 收到的是哪里的消息 ，它就指向哪里的 id。
现在，实例化一个处理器(handler)
start_handler = CommandHandler('start', start)
CommandHandler 类可以实现当收到某个命令时，调用某个函数（命令和函数名可以不一样），我们将其实例化为了 start_handler ，并且将命令名字 'start' 和对应要回调的函数名 start 传递给它
然后，启动bot
# 构建 bot
TOKEN='你 bot 的 api token'
application = ApplicationBuilder().token(TOKEN).build()
# 注册 handler
application.add_handler(start_handler)
# run!
application.run_polling()
最后，就可以使用 python bot.py 启动你的 bot ，对 bot 发送 /start ，它应该就会回复你 ”你好~我是一个bot”。
使用 Ctrl + C 结束程序运行。
完整 bot.py :
from telegram import Update
from telegram.ext import ApplicationBuilder, ContextTypes, CommandHandler
async def start(update: Update, context: ContextTypes.DEFAULT_TYPE):
text = '你好~我是一个bot'
await context.bot.send_message(chat_id=update.effective_chat.id,text=text)
start_handler = CommandHandler('start', start)
TOKEN='你 bot 的 api token'
application = ApplicationBuilder().token(TOKEN).build()
application.add_handler(start_handler)
application.run_polling()
::: tip
如果你的环境无法直接访问 Telegram 服务器，可以设置代理
全局代理, 代理整个程序.
os.environ['http_proxy'] = '代理地址'
os.environ['https_proxy'] = '代理地址'
若想仅为 telegram bot api 设置代理,则需要改动一下构建 bot 部分的代码:
http(s) 代理:
proxy_url = 'http://USERNAME:PASSWORD@PROXY_HOST:PROXY_PORT'
application = ApplicationBuilder().token("TOKEN").proxy_url(proxy_url).get_updates_proxy_url(proxy_url).build()
socks5 代理,需要安装 python-telegram-bot[socks], 然后:
proxy_url = "socks5://user:pass@host:port"
application = ApplicationBuilder().token("TOKEN").proxy_url(proxy_url).get_updates_proxy_url(proxy_url).build()
:::
到这里，其实你已经了解到了最基本的 telegram bot 编写规则，即：
start 这个函数./start 命令时, 调用 start 函数handler , 注册给 application。上述例子中，即为 application.add_handler(start_handler)接下来，写一些更有趣的功能，使用更复杂一些的规则来调用这些功能。
让群成员可以通过 bot 自助获得一个头衔吧，比如，群友可以在群里使用 /t@botname 好人 来给自己加上 “好人” 的头衔。
当然，前提是 bot 自己要是管理员，并且具有相应的权限。
要实现这个功能，可以这样写:
async def set_right(update: Update, context: ContextTypes.DEFAULT_TYPE):
chat_id = update.effective_chat.id
user_id = update.effective_user.id
bot_username_len = len(update._bot.name)
custom_title = update.effective_message.text[3+bot_username_len:]
if not custom_title:
custom_title = update.effective_user.username
try:
await context.bot.promote_chat_member(chat_id=chat_id, user_id=user_id, can_manage_chat=True)
await context.bot.set_chat_administrator_custom_title(chat_id=chat_id, user_id=user_id, custom_title=custom_title)
text = f'好,你现在是{custom_title}啦'
await context.bot.send_message(chat_id=chat_id, reply_to_message_id=update.effective_message.id, text=text)
except:
await context.bot.send_message(chat_id=chat_id, text='不行!!')
然后，添加这个功能的handler:
set_right_handler = CommandHandler('t', set_right)
application.add_handler(set_right_handler)
注意handler的添加应该在 application.run_polling() 之前，也就是说 application.run_polling() 才是真正开始运行 bot
简单解释一下 set_right 这个函数:
首先，设置了调用这个函数时的 chat_id 和 user_id 为当前聊天和当前用户
然后用 len(update._bot.name) 获取 bot 自己用户名的长度，用于下面的切片选取用户想要的头衔
而 custom_title = update.effective_message.text[3+bot_username_len:] 即获取用户想要的头衔，存储在 custom_title 中，下面的 if not 的作用是，如果用户没有发送他想要的头衔，那么默认头衔为他的用户名
由于只有管理员才有头衔，所以我们使用 promote_chat_member() 方法设置成员权限，将其的 can_manage_chat 权限设置为 True. 即使这样设置了，用户也只有一个管理员的名头，实际上没有任何权限
::: tip
要想赋予权限，你可以向 promote_chat_member() 方法中继续添加参数，如 can_pin_messages=True 可置顶消息
:::
然后就可以使用 set_chat_administrator_custom_title() 方法设置成员头衔了，如果成功了，会继续执行接下来的语句，将结果反馈给用户。
如果 bot 只能回应设置好的命令就太无趣了，所以再编写一个当收到未知命令时的执行功能
比如，想要让 bot 回应未知命令说 “我不会这个哦~”，可以这样写
async def unknown(update: Update, context: ContextTypes.DEFAULT_TYPE):
await context.bot.send_message(chat_id=update.effective_chat.id, text="我不会这个哦~")
然后，添加它的 handler。这时候注意到：
前面的两个功能都是回应一个特定的命令，在这里，我们希望它回应除已经设定的命令外的其他所有命令，该怎么做？
这就需要用到 filters ，即过滤需要处理器处理的更新. 并且要设置功能的优先级
首先导入它
from telegram.ext import filters
然后可以这样写:
unknown_handler = MessageHandler(filters.COMMAND, unknown)
filters.COMMAND 即为过滤出命令。而设置优先级其实很简单，在不对处理器分组的情况下, 添加 handler 的顺序越靠后，对应功能的优先级越低
也就是说，我们需要在其他命令类 handler 之后，添加 unknown_handler
application.add_handler(start_handler)
application.add_handler(set_right_handler)
application.add_handler(unkonw_handler)
application.run_polling()
bot 最常见的功能之一就是根据关键词回复特定内容，比如，当对 bot 说早安之类的话时，让 bot 对此做出回应。下面来实现这这一功能
由于命令和普通消息是两种不同的消息类，处理它们的方法是不一样的，针对非命令消息，要使用 MessageHandler:
from telegram.ext import MessageHandler
首先还是要编写这个功能执行的函数。
import random
async def ohayo(update: Update, context: ContextTypes.DEFAULT_TYPE):
texts = ['早上好呀','我的小鱼你醒了，还记得清晨吗','哦哈哟~']
await context.bot.send_message(chat_id=update.effective_chat.id, text=random.choice(text))
由于只回复一个固定的消息过于单调，所以我们使用 random 来从一个列表中随机选择一个回复
仍然是前文所提到的, 回调函数只负责发送消息，而何时调用这个函数，并不是这个函数本身要做的事，而是由接下来我们要编写的 MessageHandler 中的 filters 决定的:
filter_ohayo = filters.Regex('早安|早上好|哦哈哟|ohayo')
ohayo_handler = MessageHandler(filter_ohayo, ohayo)
filters.Regex() 即为使用正则表达式过滤，我们使用 '早安|早上好|哦哈哟|ohayo' 这个表达式，很容易理解何时会调用 ohayo 这个函数
记得添加它的 handler
application.add_handler(ohayo_handler)
所有完整 bot.py:
import random
from telegram import Update
from telegram.ext import ApplicationBuilder, ContextTypes, CommandHandler, filters, MessageHandler
async def start(update: Update, context: ContextTypes.DEFAULT_TYPE):
text = '你好~我是一个bot'
await context.bot.send_message(chat_id=update.effective_chat.id,text=text)
async def set_right(update: Update, context: ContextTypes.DEFAULT_TYPE):
chat_id = update.effective_chat.id
user_id = update.effective_user.id
bot_username_len = len(update._bot.name)
custom_title = update.effective_message.text[3+bot_username_len:]
if not custom_title:
custom_title = update.effective_user.username
try:
await context.bot.promote_chat_member(chat_id=chat_id, user_id=user_id, can_manage_chat=True)
await context.bot.set_chat_administrator_custom_title(chat_id=chat_id, user_id=user_id, custom_title=custom_title)
text = f'好,你现在是{custom_title}啦'
await context.bot.send_message(chat_id=chat_id, reply_to_message_id=update.effective_message.id, text=text)
except:
await context.bot.send_message(chat_id=chat_id, text='不行!!')
async def unknown(update: Update, context: ContextTypes.DEFAULT_TYPE):
await context.bot.send_message(chat_id=update.effective_chat.id, text="我不会这个哦~")
async def ohayo(update: Update, context: ContextTypes.DEFAULT_TYPE):
texts = ['早上好呀','我的小鱼你醒了，还记得清晨吗','哦哈哟~']
await context.bot.send_message(chat_id=update.effective_chat.id, text=random.choice(text))
start_handler = CommandHandler('start', start)
set_right_handler = CommandHandler('p', set_right)
unknown_handler = MessageHandler(filters.COMMAND, unknown)
filter_ohayo = filters.Regex('早安|早上好|哦哈哟|ohayo')
ohayo_handler = MessageHandler(filter_ohayo, ohayo)
TOKEN='你 bot 的 api token'
application = ApplicationBuilder().token(TOKEN).build()
application.add_handler(start_handler)
application.add_handler(set_right_handler)
application.add_handler(unkonw_handler)
application.add_handler(ohayo_handler)
# run!
application.run_polling()
python 程序的环境管理很烦人,用 docker 来跑再合适不过.
如果要在本地构建 docker 镜像,参考下面的 Dockerfile 文件
FROM python:3.12-slim
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
ENTRYPOINT [ "python","/app/bot.py" ]
将 Dockerfile 文件放到合适的目录(项目根目录即可),然后执行
docker build -t bot .
注意后面有一个 .
然后使用 docker run -d bot 启动容器,运行 bot
github action 可以构建 docker 镜像并发布到 ghcr,方便在其他地方部署 docker 容器.你依然需要在项目中写好 Dockerfile
在项目中新建 .github/workflows/build-docker.yml,参考以下配置
name: Build and publish docker container
on:
push:
branches:
- main
workflow_dispatch:
jobs:
publish:
name: Publish container image
runs-on: ubuntu-20.04
env:
TZ: Asia/Shanghai
steps:
- name: Checkout
uses: actions/checkout@v3
- name: OCI meta
id: meta
uses: docker/metadata-action@v4.1.1
with:
images: ghcr.io/${{ github.repository }}
tags: |
type=edge,branch=main
type=ref,event=branch
type=semver,pattern={{version}}
type=semver,pattern={{major}}.{{minor}}
type=semver,pattern={{major}}
type=sha
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Set up QEMU
uses: docker/setup-qemu-action@v2
- name: Login to GHCR
uses: docker/login-action@v2
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push
uses: docker/build-push-action@v3
with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
platforms: linux/amd64,linux/arm64
cache-from: type=gha
cache-to: type=gha,mode=max
然后可以使用 docker pull 的方法运行,或者使用 docker compose:
新建 docker-compose.yml,参考以下内容
version: "3"
services:
kmua:
image: ghcr.io/krau/kmua-bot:main
container_name: kmua-main
init: true
volumes:
- ./data:/kmua/data
- ./logs:/kmua/logs
- ./config.yml:/kmua/config.yml
environment:
- TZ=Asia/Shanghai
注意根据自己需要更改
然后就可以使用 docker compose up -d 启动容器
结论：ChatGPT像一面镜子，只要问题详尽，描述清楚，那么它就能给你一个基本准确的答案，这比使用谷歌搜索要节省很多时间。但是有些问题它给出的答案还有待优化。
下面是我提问的一些问题。
Linux使用相关
切换个时区，完全正确，简简单单
装个docker
nginx的使用，示例配置文件写的格式也对
这个我感觉最逆天，它能针对一个具体的项目给出使用文档
Python编程相关
字符串匹配问题，我以为它会给我写一个ac算法，没想到直接用的for in，只能说又不是不能用吧
简单的json使用问题
python的日期和时间
来排个经典的解码问题错误吧
还要第三方包的导入问题
这个就有点厉害了，给出的答案基本是正确的，可以直接使用。如果使用Google解决这些问题，那么要花费一定的时间去翻看不同网站的回答，还不一定准确。
其他
来问个我以前写过的文章（
有点厉害，但是不是我想要的结果，我是想把图片直接保存在本地的，所以我又追问它：
结果给了我一个最麻烦的办法，所以我继续追问：
似乎我想要的答案要出来了，但是它突然卡壳了，不知道怎么回事😅
总结
就这样，总体感觉是，在某些场景它比Google是要好用很多的，但是要说取代谷歌，我觉得还有点距离。在简单而足够具体的问题上，使用chatGPT要比使用Google效率高的多，但是比较抽象的问题就不是了。
此文只介绍如何加入一个zerotier网络。
打开官网的下载页面
点击windows即可下载
下载完后双击运行，自动完成安装
安装完成后，点击状态栏图标，点击join new network
然后填入要加入的网络id，点击join即可
使用vscode写博客，要想便捷快速地在文章中插入图片，比较常见的一个做法是通过picgo+图床实现快捷键上传图片，并生成markdown格式的链接。图床常常是利用jsdelivr加速github仓库的方式搭建。
我原本也一直是这样做的，但自从jsdelivr在国内不可用之后，（再者，jsdelivr的使用规范也不允许作为图床使用）我换用了另一种方案，即通过vscode的pasteimage插件直接把图片粘贴在文章内，并保存在博客目录内。
为了突出这个插件的好用，特把效果展示提到使用教程前。
首先，截张图，或者复制一张图片
然后在vscode内，使用快捷键ctrl+alt+v（可自定义）粘贴这张图片
这样就完成了，粘贴到文章内的图片会保存在你设置的目录下，粘贴图片实际上是粘贴的图片路径。图片文件以{文章标题_时间}的格式命名，十分有条理。
vscode内的实际效果↓↓↓
图片文件名↓↓↓
假设你的博客的根目录文件夹名是hexo-blog-raw，你想把粘贴的图片以文章标题_时间.png的格式命名，并保存在hexo-blog-raw/source/photo目录下
首先，在vscode的扩展商店中，搜索 paste image并安装
然后，在博客根目录下，新建.vscode文件夹，用于存放vscode的工作区配置（即局部设置）
在.vscode文件夹内，新建settings.json文件，并写入以下内容并保存。
{
"pasteImage.namePrefix": "${currentFileNameWithoutExt}_",
"pasteImage.path": "${projectRoot}/source/photo",
"pasteImage.basePath": "${projectRoot}/source",
"pasteImage.forceUnixStyleSeparator": true,
"pasteImage.prefix": "../"
}
这样就完成了。
按照如上配置后，所有配置是只在hexo-blog-raw工作区生效的，即只有在用vscode写博客文章时，以上配置才生效。
使用时，用vscode打开博客文章，用快捷键ctrl+alt+v即可插入图片到文章内。
更多的自定义配置，可参考pasteimage官方文档
制作水晶头需要以下工具：
所以实际上你只需要去某宝购买一个小套装即可。
一般购买到的一根超长网线, 两端是接好水晶头的, 但是我们不需要这么长, 所以截取你需要的长度, 用剪刀剪下一端。
然后用剥线刀把这端的一段外皮剥去。把剥线刀在剥线位点上转一圈即可。
剥完皮是这样的
仔细观察, 这根网线内有八根线, 各自有着不同的颜色, 尤其注意白线, 它们带有的颜色也是不同的。这八根线色分别是 橙白、绿白、蓝白、棕白、橙色、绿色、蓝色、棕色。
接下来把这八根线理顺好, 用网线钳把它们剪成齐平。
然后理顺八根线的次序, 如图（引用自淘宝某店铺）。
再把线塞入水晶头, 注意排列顺序与水晶头的正反。
最后用网线钳压下水晶头, 听见咔哒声就算完成了。
本文记录博主自己的mc开服经历。
我起初有开mc服的计划时是还在上高三，没有详细了解各方面的信息，因此当时想拉上几个基友集资购买云主机，在云主机上开服。
但高考完放假之后我去了解了一下云主机的价格，还是把原来的打算作废了。
我的需求是让我的服务器 安装一些大型模组并保证十人能同时在线不卡顿。而显然价格相对低的轻量云主机（指几百块一年）难以满足。
于是我决定在自己电脑上开服。但是用自己的主力机实在感觉不妥，一来它的高功耗会导致电费的额外支出，二来心疼它二十四小时不关机。
最终，我决定再组一台低功耗主机，用来开设mc服务器的同时，还能当nas用。
但是我发现，由于洋垃圾市场炒的厉害，分别购买cpu、主板、内存、硬盘配件，还不如直接购买二手整机来的划算。于是去海鲜市场（闲鱼）买了台整机。
以T结尾的intel处理器代表低功耗，正适合作为服务器使用。
到手之后重装了Windows10 LTSC。
游戏版本选择是我最纠结的地方，由于学业原因，我近乎三年没有碰mc，再回过来看的时候最新版本已经是1.19了，而且fabric似乎也流行了起来，越来越多的模组和资源包开始仅支持较高版本且仅兼容fabric，就连java的最新版本居然也到了17。但我更熟悉的是forge和旧版本。本想跟联机基友们共同商量，可他们也是什么都不知道。最终抱着延续初中的玩法的想法，选择了1.12.2这个时至今日已经是远古的版本。
由于我此前只有建设mc基岩版服的经验，当时基岩版只有官方服务端，所以也没有什么选择。
但je（java edition）服务端不一样，各种服务端看的我眼花缭乱，最终草率地随大流，选择了Catserver（猫端）这一使用人数众多的服务端。
先开了再说，大不了redo
选择好以上这些东西之后，就有了开服的方向，接下来的事情就很简单了，只需要动手去做就好了。
先在java官网，下载java8。
前往catserver官网或github仓库下载所需版本的catserver。
下载的是一个.jar单文件，把它重命名为Catserver.jar放入一个空文件夹，该文件夹名与路径尽量使用纯英文，避免出现奇怪的错误。
在该空文件夹内，新建一个文本文档，并写入以下内容：
java -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -Dfml.queryResult=confirm -jar CatServer.jar
这段内容的解释：
-Xmx6G ：设定服务端最大内存为6G
-XX等参数：开启G1GC和优化GC，详见此贴
然后把该文本重命名为strat.bat，双击运行该bat。
之后，猫端会自动下载所需的文件，并释放到同目录下，这样就完成了服务端的初始化。初始化完成后的目录文件如下
初始化完成后，需要修改以下几个文件
参考这两帖，根据需求进行修改。
[服务器应用] 【优化】服务器优化指南 | 和卡顿永远说再见
[服务器应用] Minecraft服务器优化教程 —— 让多带50%的玩家不再是梦
下面是我修改后的配置文件
#Minecraft server properties
#Sun Jun 19 19:24:15 CST 2022
spawn-protection=16
max-tick-time=60000
generator-settings=
force-gamemode=false
allow-nether=true
gamemode=0
broadcast-console-to-ops=true
enable-query=false
player-idle-timeout=0
difficulty=2
spawn-monsters=true
op-permission-level=4
pvp=true
snooper-enabled=true
level-type=DEFAULT
hardcore=false
enable-command-block=true
max-players=10
network-compression-threshold=-1
resource-pack-sha1=
max-world-size=29999984
server-port=25565
server-ip=0.0.0.0
spawn-npcs=true
allow-flight=true
level-name=world
view-distance=8
resource-pack=
spawn-animals=true
white-list=true #开启白名单
generate-structures=true
online-mode=flase #关闭正版验证
max-build-height=256
level-seed=
prevent-proxy-connections=false
enable-rcon=false
motd=fish world
settings:
allow-end: true
warn-on-overload: true
permissions-file: permissions.yml
update-folder: update
plugin-profiling: false
connection-throttle: 4000
query-plugins: true
deprecated-verbose: default
shutdown-message: Server closed
spawn-limits:
monsters: 50
animals: 15
water-animals: 5
ambient: 3
chunk-gc:
period-in-ticks: 400
load-threshold: 300
ticks-per:
animal-spawns: 400
monster-spawns: 2
autosave: 6000
aliases: now-in-commands.yml
world:
keepSpawnInMemory: false
enableSkipEntityTick: true
enableSkipTileEntityTick: false
worldGenMaxTick: 15
disableForgeGenerateWorlds:
- ExampleCustomWorld
preventBlockLoadChunk: false
autoUnloadDimensions:
- 99999999
enableRealtime: true
forceSaveOnWatchdog: true
maxEntityCollision: 8
saveBukkitWorldDimensionId: true
fakePlayer:
permissions:
- essentials.build
eventPass: false
vanilla:
fixPlayBossSoundToOtherWorld: true
fixLessCrystalRespawnDragon: false
preventPistonPushRail: false
preventPistonPushSlimeBlock: false
limitFastClickGUI: false
plugin:
patcher:
enableDynmapCompatible: true
enableCoreProtectModBlockCompatible: true
enableEssentialsNewVersionCompatible: true
enableMythicMobsPatcherCompatible: true
enableWorldEditCompatible: true
enableCitizensCompatible: true
disableHopperMoveEventWorlds: []
defaultInstall:
spark: true
async:
waitForgeServerChatEvent: false
security:
opManager: false
gameModeManager: false
disableUpdateGameProfile: false
disableFMLHandshake: false
disableFMLStatusModInfo: false
disableAsyncCatchWarn: false
versionCheck: true
config-version: 11
settings:
debug: false
attribute:
maxHealth:
max: 2048.0
movementSpeed:
max: 2048.0
attackDamage:
max: 2048.0
netty-threads: 4
timeout-time: 60
restart-on-crash: true
restart-script: ./start.sh
moved-too-quickly-multiplier: 10.0
moved-wrongly-threshold: 0.0625
filter-creative-items: true
bungeecord: false
sample-count: 12
late-bind: false
int-cache-limit: 1024
item-dirty-ticks: 20
user-cache-size: 1000
player-shuffle: 0
save-user-cache-on-stop-only: false
messages:
whitelist: You are not whitelisted on this server!
unknown-command: Unknown command. Type "/help" for help.
server-full: The server is full!
outdated-client: Outdated client! Please use {0}
outdated-server: Outdated server! I'm still on {0}
restart: Server is restarting
stats:
disable-saving: false
forced-stats: {}
commands:
log: true
replace-commands:
- setblock
- summon
- testforblock
- tellraw
spam-exclusions:
- /skill
silent-commandblock-console: false
tab-complete: 0
advancements:
disable-saving: false
disabled:
- minecraft:story/disabled
world-settings:
default:
verbose: true
merge-radius:
item: 2.5
exp: 3.0
arrow-despawn-rate: 1200
wither-spawn-sound-radius: 0
nerf-spawner-mobs: false
entity-tracking-range:
players: 48
animals: 48
monsters: 48
misc: 32
other: 64
view-distance: 10
enable-zombie-pigmen-portal-spawns: true
zombie-aggressive-towards-villager: true
item-despawn-rate: 6000
hanging-tick-frequency: 100
growth:
cactus-modifier: 100
cane-modifier: 100
melon-modifier: 100
mushroom-modifier: 100
pumpkin-modifier: 100
sapling-modifier: 100
wheat-modifier: 100
netherwart-modifier: 100
vine-modifier: 100
cocoa-modifier: 100
entity-activation-range:
animals: 32
monsters: 28
misc: 16
tick-inactive-villagers: true
random-light-updates: false
ticks-per:
hopper-transfer: 8
hopper-check: 1
hopper-amount: 1
save-structure-info: true
hunger:
jump-walk-exhaustion: 0.05
jump-sprint-exhaustion: 0.2
combat-exhaustion: 0.1
regen-exhaustion: 6.0
swim-multiplier: 0.01
sprint-multiplier: 0.1
other-multiplier: 0.0
max-tick-time:
tile: 50
entity: 50
squid-spawn-range:
min: 45.0
max-tnt-per-tick: 100
mob-spawn-range: 4
dragon-death-sound-radius: 0
seed-village: 10387312
seed-feature: 14357617
seed-monument: 10387313
seed-slime: 987234911
在服务端中，有mods和plugins两个文件夹，它们分别是游戏模组和服务端插件。
游戏模组是增强和丰富游戏内容的，而服务端插件是增强服务端功能的。
需要安装的模组，都放在mods文件夹内。
在安装模组时，要看清模组是否需要在服务端安装，不需要在服务端安装的模组不要安装在服务端。（如waila高亮显示等模组）
_服务端需要装
_不要在服务端装
另外在安装模组时，还要留心查看该模组的说明，有些模组需要额外的前置模组，要一起安装（如植物魔法botania需要bauble作为前置模组，二者必须都安装）
以下是我在服务端安装的模组
而服务端插件直接放如plugins文件夹即可，可以根据需要去搜索。我曾经安装了miraimc插件，它是一个能双向同步mc服务器和qq群消息的插件，但由于性能和兼容性问题又把它移除了。目前我只安装了一个luckperm插件，用来管理玩家权限（如单独给玩家tp权限而不给op管理员身份）
服务端启动完成后，直接在服务端控制台窗口可运行指令（包括游戏内的指令，如 time set）
执行op <玩家名>可赋予玩家op
执行whitelist add <玩家名>可为玩家添加白名单
注意在控制台窗口输入命令时，都不带/
客户端即是玩家端，可以选择任意一款启动器，制作整合包发给发给玩家，而我选择的是HMCL这个老牌启动器，版本为3.5.3
下载游戏本体
然后把所安装的模组放入游戏目录的mods文件夹
可以使用litteskin，为游戏增加自定义皮肤支持，同时还需要安装customskinloader 模组。
然后启动游戏，在多人游戏中添加搭建的服务器，退出即可。
之后在hmcl中，选择导出整合包，导出时，勾选多人服务列表一起导出。为了以后更新方便，我还构建了服务器自动更新整合包，在hmcl启动器中和mcbbs上均有相关教程。
参考
Nginx 下配置 HMCL 自动更新整合包
由于构建步骤相对繁琐，我也会另写一篇文章记录。
把制作好的整合包发给玩家后，若使用的是云主机，就可以直接开始联机游戏了。但我用的是自己的主机，其他非内网玩家是无法访问我的服务器的，所以还需要进行端口映射和ddns配置（或内网穿透）
我的路由器支持花生壳的ddns，所以我采用了端口映射+ddns的方法。
在路由器管理页面，进行如下配置映射端口（默认端口为25565，可在服务端配置文件server.properties中更改）
然后登陆花生壳ddns账号，这样外部网络便可以访问局域网中的mc服务器了。
若路由器没有内置任何ddns的支持，还可以在服务器的主机上使用ddns-go程序。
要想通过 TLS 访问自己域名下的服务, 就必须申请证书。类似宝塔这种面板提供了简单快捷的方法一键申请, 但终究不是良好的解决方案。一来宝塔过于臃肿, 二来其需要手机实名验证。使用各大云服务商提供的【免费证书】则还需要登录网页、申请、导入证书, 未免操作繁琐。更何况这些云服务商提供的证书只能给你很少的自由选择性。
而ACME则很好地解决了这些问题。
系统环境: Debian
在开始之前, 首先将域名解析到服务器的ip上。
首先安装socat, 它是acme所需的组件
apt update
apt install socat -y
然后安装acme脚本
curl https://get.acme.sh | sh
脚本安装在用户目录下的.acme.sh（隐藏）文件夹内, 使用 . .bashrc 让acme.sh命令生效
接下来使用脚本申请证书
首先注册CA账户, 将下列命令中的邮箱改为自己的邮箱地址
acme.sh --register-account -m xxxx@xxxx.com
注册成功的输出结果如下
_注册成功
然后申请证书, 接下来的方法有多种, 根据自己情况选择可用的一种即可
如果服务器的80端口空闲, 且能够访问, 可以让acme临时监听80端口, 完成验证。执行以下命令即可。将domain.com改为自己的域名
acme.sh --issue -d domain.com --standalone
如果服务器上已经安装了nginx, 且网页能够正常打开, 执行以下命令即可通过nginx验证并申请证书。
acme.sh --issue -d mydomain.com --nginx
如果成功申请了证书, 将会看到的输出结果是一长串自己的证书和证书文件存放路径。
生成的证书文件默认存放在与acme.sh脚本相同文件夹内, 大多数情况下不应直接使用该路径下的证书文件, 而使用以下命令安装证书到指定路径。
acme.sh --install-cert -d domain.com --key-file <path>privkey.pem --fullchain-file <path>fullchain.pem
其中--key-file <path>privkey.pem指定的为私钥文件, --fullchain-file <path>fullchain.pem为证书文件。
done
在安装acme.sh脚本时, 它自动为创建 cronjob, 每天 0:00 点自动检测所有的证书, 如果快过期了, 需要更新, 则会自动更新证书。
但由于acme 协议和 letsencrypt CA 都在频繁的更新, 因此 acme.sh 也应当经常更新以保持同步。参考以下命令
acme.sh --upgrade --auto-upgrade #开启acme的自动更新
acme.sh --upgrade --auto-upgrade 0 #关闭自动更新
访问 https://krau.top/posts/acmessl/index 查看原文。
]]>docker官方提供了傻瓜式安装脚本，为你做好所有工作，免去了手动安装的繁琐。
本文实测系统环境：debian11
执行以下命令
::: tip 2023-03-07
不知道从什么时候开始官方脚本已经默认也安装了 docker compose, 不需要后面的手动安装了, 因此已删除多余的内容
也就是说, 只需要执行下面的一键脚本
注意是 docker compose 而不是 docker-compose. 执行命令时候也没有这个杠
:::
curl -fsSL https://get.docker.com | bash -s docker
可在此命令后附带--mirror参数设置镜像源，以提高国内服务器下载docker的速度
如使用阿里云镜像:
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun
下载 linuxdeploy，安装到旧手机
请确保安装的linuxdeploy版本≥2.0，否则需要首先安装busybox。而2.0以上的linuxdeploy内置了busybox
打开linuxdeploy软件，点击左上角按钮，选择设置，勾选【锁定wi-fi】与【CPU唤醒】，其他选项按需配置，亦可保持默认
回到上一级页面，点击右下角按钮，进行以下配置：
${EXTERNAL_STORAGE}/linux.img，一般保持默认即可Source：手机目录
Target：Linux目录
使用能够查看到真实路径的文件浏览器，复制需要挂载的目录到挂载点列表，填入第一行即可
务必勾选启用SSH服务器，SSH设置按需配置
按需配置
按需配置
配置完成后，返回上一级，点击右上角按钮，点击安装，等待出现<<< deploy即安装完成。
点击停止按钮并确定，再点击启动，出现<<< start即启动成功
然后即可使用同一局域网下的ssh工具连接
为了防止旧手机的内网ip地址变更，在路由设置页面进行ip与MAC绑定，并把手机wifi连接中的隐私设置相关选项改为 使用设备MAC
连接后，安装常用工具
apt install wget vim curl zip -y
附：
xshell工具家庭/学校版下载连接
https://www.xshell.com/zh/free-for-home-school/
项目发行地址：cloudreve
截止到撰写本文（2022.01），最新版本为3.4.2
执行以下命令
切换到用户目录
cd /opt
创建文件夹并切换
mkdir cloudreve&&cd cloudreve
下载cloudreve
wget https://github.com/cloudreve/Cloudreve/releases/download/3.4.2/cloudreve_3.4.2_linux_arm64.tar.gz
根据需求自行选择下载的版本并替换wget后的链接
解压
tar -zxvf cloudreve_3.4.2_linux_arm64.tar.gz
赋予权限
chmod +x ./cloudreve
启动
./cloudreve
在终端中会给出初始管理员账号与密码，使用该账号登录
若无法访问，查看防火墙是否开放端口
进入cloudreve后，点击右上角头像，进入管理面板，即可进行相关设置，具体参见cloudreve官方文档
需要注意的是，在配置使用本机存储策略的用户组时，若存储目录在镜像空间内，要确保【初始容量】小于【镜像大小】，否则会无法上传任何文件
cloudreve内置了依赖于aria2的离线下载功能，因此需先进行aria2的配置
安装
apt install aria2 -y
下载由P3TERX提供的aria2配置文件（亦可选择其他配置或参考aria2官方文档自行创建）
cd
wget https://github.com/P3TERX/aria2.conf/archive/master.zip
unzip master.zip
将解压出的文件夹重命名为.aria2
mv aria2.conf-master .aria2
修改aria2配置文件
cd .aria2&&vim aria2.conf
P3TERX 的配置文件包含了中文注释，根据注释按需修改即可，一般需要改动的是下载目录、RPC密钥与BT监听端口，其他保持默认即可
配置修改完成后，在.aria2目录内，执行./tracker.sh即可更新tracker
若更新失败，可进行手动更新，参考以下tracker列表
https://trackerslist.com/all_aria2.txt
将列表内容复制到aria2.conf中的bt-tracker参数后即可
创建aria2.session文件
touch aria2.session
测试aria2能否成功启动
aria2c --conf-path=/root/.aria2/aria2.conf
第一次启动需要指定配置文件，日后启动只需使用aria2c即可
若启动成功，关闭即可，接下来进行进程保护配置，方便后续操作
cloudreve与aria2运行后，若关闭ssh终端，二者也会随之停止运行，因此需要进行进程守护，本文是使用 supervisor
安装
apt install python-setuptools -y
apt install supervisor -y
为cloudreve创建配置并打开配置文件
sudo vim /etc/supervisor/conf.d/cloudreve.conf
将以下内容按需修改后，写入cloudreve的supervisor配置文件，具体参见supervisor官方文档
[program:cloudreve]
directory=/opt/cloudreve
command=/opt/cloudreve/cloudreve
autostart=true
autorestart=true
stderr_logfile=/var/log/supervisor/cloudreve.err
stdout_logfile=/var/log/supervisor/cloudreve.log
environment=CODENATION_ENV=prod
以上内容备注：
程序目录=/opt/cloudreve
运行命令(绝对路径)=/opt/cloudreve/cloudreve
自启动=true
自动重启=true
错误日志保存路径=
其他日志保存路径=
环境=
与上同理
为aria2创建配置并打开配置文件
sudo vim /etc/supervisor/conf.d/aria2.conf
将以下内容按需修改后，写入aria2的supervisor配置文件，具体参见supervisor官方文档
[program:aria2]
directory=/root/.aria2
command=aria2c --conf-path=/root/.aria2/aria2.conf
autostart=true
autorestart=true
stderr_logfile=/var/log/supervisor/aria2.err
stdout_logfile=/var/log/supervisor/aria2.log
environment=CODENATION_ENV=prod
以上内容备注：
程序目录=/root/.aria2
运行命令(绝对路径)=aria2c --conf-path=/root/.aria2/aria2.conf
自启动=true
自动重启=true
错误日志保存路径=
其他日志保存路径=
环境=
启动supervisor
supervisord -c /etc/supervisor/supervisord.conf
至此便完成了进程守护配置
如需管理supervisor内进程，参考以下指令：
sudo supervisorctl start cloudreve #启动
sudo supervisorctl stop cloudreve #停止
sudo supervisorctl status cloudreve #状态
附.网页管理supervisor进程配置：
在supervisor配置文件中（/etc/supervisor/supervisord.conf），添加以下内容
[inet_http_server]
port=127.0.0.1:8888
username=
password=
其中port、username、password参数可自行设置，若需外部访问，可将port设置为 0.0.0.0:8888
若在linuxdeploy中，初始化系统选择了sysv，则无需额外配置即可自启动supervisor及其中的程序
若使用run-parts初始化，需额外配置.
登录cloudreve管理页面，选择 离线下载节点 ，修改 主机（本机） 节点
完成配置后，点击下一步，修改杂项信息，再点击下一步，即可保存该节点配置
然后点击用户组，编辑用户组配置，允许进行离线下载
至此，所有配置完成，可在同一局域网下，打开cloudreve页面测试是否成功实现了个人云盘与离线下载功能
访问 https://krau.top/posts/old-phone-become-server/index 查看原文。
]]>这就需要制作相应的法线贴图
本文以YYB式初音未来为例，制作相应的法线贴图，使用ray渲染的版本为1.5.2
在制作法线贴图之前，首先要在MMD导入相应的模型，并完成ray渲染的基本流程，方便以下的对比操作，以寻找合适的参数。
在模型的目录中，找到需要制作的贴图，文件夹名一般为Texture
然后使用ps导入贴图，选择滤镜>3D>生成法线图
导出为png格式，文件名应是英文
在~/ray-mmd-1.5.2/Materials目录中，找到material_2.0.fx、material_common_2.0.fxsub两个文件，复制到模型目录中的材质贴图文件夹
然后重命名material_2.0.fx文件为{你所导出的法线贴图的文件名}.fx
打开重命名后的该fx文件，在第28行左右找到#define NORMAL_MAP_FROM 0，将0修改为1以启用法线贴图。并更改#define NORMAL_MAP_FILE "normal.png" 中的"normal"为法线贴图文件名
然后保存，在mmd中，在MaterialMap栏中，展开所修改的模型，找到对应的贴图，为其添加法线贴图效果
此时可以对照mmd中的效果调整fx文件中的参数，修改参数后保存文件，即可在mmd中预览到效果。
几个参数的作用：
const float normalMapScale = 1.0;
法线效果强度，该参数越大，层次感越明显（下图为将该参数设置为5.0的效果）
#define SMOOTHNESS_MAP_TYPE 0
法线效果平滑度，该参数越大，发现效果显示越平滑，同时颗粒感与湿润感也会更强（多用于场景）
tips：
material_2.0.fx文件，并重命名为对应的文件名，而material_common_2.0.fxsub只在材质文件夹中保留一份即可
在模型操作栏中，选择导入的天空盒，在表情栏即可进行其相关参数调整。
以下介绍中，把表情四栏按从左到右，从上到下分成 第一栏、第二栏、第三栏、第四栏。
该天空盒初始为纯白背景，一般适用于实景合成/唯美风渲染
该天空盒与Sky Hemisphere几乎一样，区别是该天空盒带有夜晚的月亮和流星效果
该天空盒具有夜间星空银河与流星效果，参数调整与Time of day基本一致。
区别是该天空盒第四栏的参数为影响星星的效果
前往 github 下载最新版ray mmd
注意：不仅仅是打包下载code就完事的，还需要去下载各项扩展（详见github仓库下的readme）
下载完成后解压ray和各个扩展，把扩展文件分别复制到ray主目录中对应的文件夹中
载入人物，场景等数据后，就可以开始ray渲染了
但在这之前，还需要在mmd显示菜单中，关闭地面阴影显示，抗锯齿和各向异性过滤
因为ray是自带抗锯齿和阴影的，如果不关则会导致一些难以名状的画面和性能问题
第一步需要向mmd中丢入ray根目录下的ray.x和ray_controller.pmx，这两个分别是ray环境和ray控制器
然后放入ray/skybox目录下的任意一个天空盒，它应该是以.pmx为后缀的文件。
此处以Time of day为例。
丢入之后在背景>模型描绘顺序中调整人物，场景，和skybox的顺序
这三个的正确相对顺序应为
skybox
stage（场景）
model（人物）
然后在右上角MMEffect中添加渲染
在mian栏中，为场景和人物添加 main 文件夹内的 main.fx（主渲染）
在Envlightmap（环境）栏中，为 skybox 添加渲染
在Fogmap（雾气）栏中，为 skybox 添加雾气效果渲染
用方框框起来的三个均为 fogmap 对应的渲染，只需要选择一个添加就可以，一般选择 Time of fog with godray with cloud caster（名字越长越nb）
在materials栏中，为skybox渲染正确的材质
至此，再稍微调整一下打光和一些参数，就算完成了ray渲染的最基本步骤，现在的画面相较于未渲染的画面已经耐看多了
before：
now：
但这只是最基本的套用渲染的流程，相较于无渲染也就是从看不了提升为了勉强能看，要想做出真正好康的mmd，仅仅这些是完全不行的
对于接触mmd时间不长的新手来说，没必要去详细了解每个概念，需要的是自己不断尝试，去感受那些渲染功能的具体作用。所以一开始更好的学mmd方法是，什么都不管，跟着做就好了。
访问 https://krau.top/posts/mmdray-basic-rendering/index 查看原文。
]]>个人 galgame 整理&安利
就按照我能回想起来的先后顺序排序吧
反正我玩的不算多←是真话
未来のキミと、すべての歌に―是Supplement Time在2008年04月04日[1]发售的初音同人游戏。是Supplement Time出品的初音系列的同人游戏的第一部。其后续作有鈴が歌う、未来の音色―和未来の歌と、つながるヒトミ。
详见萌娘百科
应该是我玩的第一款gal？？不太确定了，反正玩的挺早的
粉丝向作品. 算是比较日常但是又有些波折的剧情，总之就是在大街上捡回家了只miku然后发生的种种......
经典的猫系gal，听说打个补丁会更有趣
不配图了这个emmmm
《哥哥，早上起床之前都要抱紧我哦！》是由Tinkle Position制作的一部Galgame。 萌娘百科详情
国欠妹系列
《缘之空》（ヨスガノソラ，Yosuga no Sora）是Sphere于2008年12月5日发售的恋爱文字冒险游戏，也是Sphere的处女作。亦有漫画、动画、Fandisk、广播剧等衍生作品。萌娘百科：缘之空
国欠妹*2
对应的续作还有一部『悠之空』
不说什么~
找不到更高清的图了
穗姬是原产于台湾屏东县东港镇的杂交稻米品种“高雄145”以及该稻米所产的大米“东津萌米”的萌娘化形象，也登场于游戏《东津萌米-穗姬》中。 萌娘百科：穗姬
国产游戏，更偏向于养成系的（种大米），姑且也算是galgame吧
万物皆可萌
猫系galgame*2
萌百没收录这个......明明挺社保的
能搞笑又能社保~~（指男主）~~
时间：2020.7.17-2020.7.24±
谁敢反对狗头，我就打爆他的宁宁（错乱
时间：2020.7.26±-2020.7.28±（只过了从雨线）
从雨天下第一！
2026.8 二刷, 除了蕾娜其他线倒是都过了一遍.
时间：2020.7.29-2020.8.2？
咕噜咕噜~呸
时间：2020.8.28-8.31（明月栞那）
星巴克与大扑棱蛾子
时间：2020.9.7-9.16（在原七海）
能推睡着的gal......但感觉还不戳，七海天下第一
时间：5.24-5.30
苟利星奏生死以，岂因新岛避趋之
时间:2021.6.4（云）
勉强也算gal吧...
探索解密式的剧情玩法+色气可爱的唯一女主魅魔设定
虽然te确实很感人，但其他五条结局也很绝望和惊悚
时间：2021年
时间：2021.6.5
喵都太可爱了
时间：2021.6.6
国欠我一个天妹
时间：2021.6.7
时间：2021.6.7-6.8
时间：2021.6.8
时间：2021.8.25-8.29
发椿啦发椿啦，当然椿恋歌也会推的啦，这里就只写一个好了
时间：2021.9
一部“童话”
时间：2021.9
剧情是真的短，但她真的太可爱了太刑了
时间：2021.9
冰织天下第一！
24年暑假
25年8月
用荒诞搞笑的故事也能打动人心
26年暑假
Noa 可爱滴捏
26年暑假
又名 蜜雪冰城
除了隐杏珠其他几位女主都不是很戳
26年暑假
免费国产 gal , 除了配音以外没啥问题
闲来无事在摸MMD，然后看到了这个
【PV背景配布/动作配布】九尾三妈式初音 - お気に召すまま
感觉这个配布的挺不错，想摸一个。
但是碰到点问题：60fps的背景是单独的视频，需要通过后期软件把人物和背景的视频叠加起来，这就要一个带有alpha通道（透明）的人物视频，去网上找了一些方法，依旧踩了不少坑。
找了很多方法，感觉就这个最简单方便。
首先去下载这个MME：https://bowlroll.net/file/27004
这个MME可以让你随心所欲的加花里花哨的全局MME，而不会丢失透明通道
下载之后保持乱码状态解压
然后在 RewriteAlpha 文件夹中，往MMD里加入这个 RewriteAlpha.x
在MMD>背景>绘制附件中，把RewriteAlpha.x放到最后一位
然后打开MME面板，找到alphamap栏，把skybox和stage的渲染关闭（取消勾选），人物模型的渲染开启，并勾选上RewriteAlpha.x的渲染
这样就算完成了，导出的时候将会导出只有人物渲染，且背景是透明通道的视频，也可以先导出一张png看看效果。别渲染了半天发现不是透明通道，别问我怎么知道的
访问 https://krau.top/posts/mmdray-output-videos-with-alpha/index 查看原文。
]]>