2026年2月

自己搞了一个 openclaw 机器人运营 twitter tg discord
接入对于不少用户还是有一点点门槛
新发现了一个 OpenClaw 一键部署平台
内置了所有模型包括语音等功能
https://lemondata.cc/en/claw
大家可以去试试

附送兑换码给大家
LD-RW8X-UFRZ
LD-QT47-TWGD
LD-AD9Y-S734
LD-XSC8-XVYX
LD-NGYF-95HV
LD-HK7N-8NKF
LD-GCBV-DAW7
LD-WZV6-667Z
LD-K55J-P39H
LD-ZRKF-YTHU
LD-6F8N-UB2W
LD-E5MK-DMET
LD-5YQK-QH8U
LD-RUQK-CBHA
LD-9MMJ-2WCA
LD-2S7E-MJJK
LD-KRRX-5AXW
LD-6M9D-GNR3
LD-GD2G-BQRW
LD-UAQ6-8HUY

2022 年底把 Kubernetes 和 ArgoCD 还有一大推云服务配置交接后就去玩赛车和滑雪了,今年准备正式回归 DevOps 职业。

因为断片了这 4 年,所以想问下这几年 DevOps 的发展和重新进入该职业的侧重点是什么。以及 AI 在 DevOps 上的集成,有没有进化到可以用 AI 生成配置的阶段。

我目前唯一知道的就是 nginx ingress 要弃用换成 gateway 了:)

谈好薪资,临签合同被恶心到了

招聘来源: https://www.v2ex.com/t/1185062#reply6

完整面试时间线

  • 1.15 业务电话面
  • 1.16 笔试题
  • 1.19 CTO 二面
  • 1.22 沟通薪水,给不到预期,反馈会再去争取
  • 1.27 主动确认薪资达成一致
  • 1.28 答复确认入职,对方告知在走 offer 流程
  • 1.29 第一次催进度,承诺 1.30 给结果
  • 1.30 反馈节假日安排,改口下周三给
  • 2.4 询问进度,仍在流程中
  • 2.9 通知直接签合同,不发 offer

合同问题

  • 劳动合同期限:一年
  • 试用期:六个月
  • 合同上不写工资金额
  • 全程无正式书面 offer ,要求直接签合同

提出以上几点质疑后,他们表示创业公司就这条件。

个人情况

等待流程期间拒了一个 offer ,耗时近一个月,最后等来这种结果。

有投这家的自己留个心眼子。我算是吃一堑又一堑


这些天真是好多出问题的啊,前段时间的 aws ,cloudflare ,现在是 github 。

虽然几天前也有些许中断,但这次是 web 都没了。似乎是彻底崩掉了。

https://www.githubstatus.com/

我自己平时用的几个拦截工具,要么解决方案影响加载速度,要么规则太重、要么配置太复杂,对非技术用户不太友好。
所以这两天索性自己做了一个叫 purely 的小工具,主打几件事:

1.专注广告拦截本身,不做乱七八糟的功能
2.尽量少打扰用户,装好就用
3.规则全面、性能优先

目前还在比较早期阶段,不敢说有多完美,但日常使用已经能明显安静不少。

想来 V2EX 发帖,主要是想找一些愿意认真提意见的用户,看看这个方向是不是走对了。

👉 我会送出 10 个兑换码(永久使用权限),给愿意体验并反馈的 V 友

如果你对广告拦截、浏览体验、隐私这块有兴趣,欢迎留言或私信我 🙏
不吹、不拉踩,只想把产品慢慢打磨好。

App 下载地址: https://apps.apple.com/cn/app/purely-ad-blocker-privacy/id6757303103
官方网址: https://webpurely.com/
VX:angtMjAxMg==

为了逃避上班请假了一周假期提前回家过年,没想到更痛苦了,仿佛从一个牢笼中跳到另一个牢笼。

先说几个关键词,《大龄》,《未婚》,《农村》,这几个词放到一起威力真的堪比核武器。

还有一点痛苦的是从一线城市到农村巨大的环境差异真的很难适应。

当我拿到一台全新的 VPS ,无论是用来建站、跑项目还是作为其他的用途我都有一套流程要走,不知道有没有 mjj 和我一样的,基本上不会直接上手部署业务或者运行其他的内容。跑一个融合怪或者 NQ 测试脚本啊,基本上的日常操作,DD 系统啊,因为有一些厂商预装的系统往往不够纯净,甚至可能被植入了监控组件。此外,如果不经过测试就投入使用,后期一旦出现性能瓶颈或网络问题,很难排查到底是不是商家超售导致硬件“缩水”还是是软件原因。

image

为了确保服务器的稳定性、安全性以及性能最大化,我按照我自己的习惯整理了一套标准化的“VPS 开荒部署”流程。这套 SOP (标准作业程序)是我每次拿到新机器后的必做事项,Linux 系统是基于我最常用的 Debian 12 系统。

第一步:验机与性能摸底

获取 IP 和 root 密码后,第一件事是通过 SSH 连接然后运行融合怪或者 NQ 测试脚本。这一步的核心目的有三点:

  1. 核对配置:检查 CPU 型号、内存大小、硬盘 I/O 是否与商家宣传一致,最主要还是查看 CPU 跑分和硬盘 IO 做到心里有数,后期也好排查是不是超售商家。
  2. 网络体检:测试三网回程线路质量(是 CN2 GIA 还是普通 163 ),这个在优化机器上尤其重要,尤其是一些藏路由或者大小包的商家,避免自己被骗。
  3. 解锁检测:查看 IP 是否被 Netflix 、Disney+ 等流媒体平台封锁,如果是落地机器或者解锁机器这点就特别重要了。

我通常使用以下两个脚本,任选其一即可:

方案 A:NQ (NodeQuality) 测试脚本
这个脚本输出简洁,适合快速查看硬件配置和基础网络状况。

bash <(curl -sL https://run.NodeQuality.com)

方案 B:融合怪测试脚本 (推荐)
这是目前最全面的测试脚本,包含详细的 CPU 跑分( Geekbench )、硬盘读写速度以及全球主流流媒体的解锁检测。

bash <(wget -qO- --no-check-certificate https://gitlab.com/spiritysdx/za/-/raw/main/ecs.sh)

测试脚本数据只作为参考,真实情况可能不一致,最真实的情况还是需要真实的使用体验

如何分析结果?

  • I/O 速度:如果读写速度低于 100MB/s ,说明硬盘性能极差,不适合搭建数据库或高负载网站,看看是石头盘、还是钻石盘、还是 SSD 缓存盘。
  • CPU 跑分:GB5 单核分数直接决定了处理动态页面的能力,如果太低可以判断是超售了。
  • 丢包率:关注晚高峰时段的丢包率,这比单纯的带宽大小更影响体验。

image

延伸阅读:

第二步:DD 重装纯净系统

哪怕商家提供了 Debian 12 镜像,我依然建议自己 DD (重装)一遍。这能确保系统内核是官方原版,彻底清除商家预装的监控代理或多余进程,让系统处于“零污染”状态。

我这里推荐的是使用的是 科技 Lion 的脚本,该脚本集成度高,支持快速重装为 Debian 、Ubuntu 或 Alpine 等主流系统。最主要还是方便,我自己也用习惯了,我知道肯定还有其他的但是懒得找了。

执行命令:

curl -sS -O https://kejilion.pro/kejilion.sh && chmod +x kejilion.sh && ./kejilion.sh

进入脚本菜单后,选择“重装系统”并指定 Debian 12

image

关键提示:
系统重装完成后,SSH 会断开。等待 5-10 分钟重新连接。连接成功后,必须第一时间修改默认密码! 脚本生成的初始密码通常是固定的(如 LeitboGi0),极易被扫描爆破。

修改密码命令:

passwd

第三步:基础安全加固

公网环境极其恶劣,默认的 22 端口和密码登录方式是黑客脚本攻击的重点对象。为了保障服务器不沦为肉鸡,必须进行以下三项配置:

  1. 修改 SSH 默认端口:将默认的 22 端口修改为 20000-65535 之间的高位端口。这能规避 99% 的无差别自动化扫描。
  2. 禁用密码登录:配置 SSH 密钥对,仅允许持有私钥的客户端登录,并彻底关闭密码验证功能。这样设置基本可以安全很多,因为密码泄露是很大的风险秘钥基本上杜绝了撞库或者其他方式的扫描。
  3. 配置防火墙与 Fail2Ban:启用 UFW 防火墙并放行新端口;启用 Fail2Ban 监控 SSH 日志,自动封禁多次试错的恶意 IP 。

操作建议:
这一步容易导致新手把自己锁在门外,建议在修改配置文件(/etc/ssh/sshd_config)前先备份。修改完端口后,先不要关闭当前 SSH 窗口,新开一个窗口尝试连接,确认无误后再断开。

详细教程:
如果你不熟悉密钥生成和配置文件修改,请务必参考这篇教程:
别再让 VPS 裸奔!保姆级 Linux 安全加固教程,彻底告别 SSH 暴力破解

image

第四步:系统环境初始化

系统重装并加固后,需要对系统环境进行一些基础设置,以适应后续的使用需求。

1. 更新软件包与校准时间
确保所有软件都是最新版本,并防止因时间不同步导致的日志混乱或协议连接失败,升级软件包其实可以放到第一步的,但是想了想还是放到了这里,有的时候安装不上去软件的时候,先执行软件包更新就可以安装了。

apt update && apt upgrade -y
timedatectl set-timezone Asia/Shanghai

2. 开启 Swap (虚拟内存)
对于内存较小(如 512MB 或 1GB )的 VPS ,开启 Swap 是防止内存溢出的最后一道防线。

wget https://www.moerats.com/usr/shell/swap.sh && bash swap.sh

建议:Swap 大小设置为内存的 1-2 倍即可,不必过大。

swap 看服务器的情况而定,如果是内存大的服务器不开也可以,开启 swap 可以让硬盘的容量作为运行内存,可以缓解内存不足的问题,但是 swap 本质只是那存储空间作为内存读写速度肯定有差距,所以没必要开的很大

image

3. 修改 DNS (按需执行)
部分国外商家的默认 DNS 解析国内域名速度较慢。我习惯手动修改为 Google 和 Cloudflare 的公共 DNS 。

sudo tee /etc/resolv.conf <<EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 2001:4860:4860::8844
nameserver 2606:4700:4700::1111
EOF

特别警示:
如果你购买的是具有 DNS 解锁流媒体 功能的特殊 VPS (如某些原生 IP 机器),商家通常已经配置好了专用 DNS 。此时千万不要执行上述修改 DNS 的操作,否则会导致解锁功能失效。

搬瓦工的机器默认 DNS 解析延迟有些问题,所以我这里建议修改默认的 DNS

第五步:内核优化与网络加速

Debian 12 默认内核已开启 BBR ,但针对高延迟、高丢包的国际网络环境,适当的 TCP 参数调优可以进一步提升吞吐量。这里就是针对小白的 TCP 调优脚本,不需要知道参数,只需执行选择就可以了,还是很方便的。

简易方案:
使用 Neko 的 TCP 优化脚本,选择推荐配置即可。

wget http://sh.nekoneko.cloud/tools.sh -O tools.sh && bash tools.sh

image

进阶方案 (推荐):
如果你对网络协议有更高要求,推荐使用 **迷之调优**。根据你的服务器配置(内存、线路延迟)生成专属优化命令。这个网页生成的命令还会自动备份原配置,如果优化后效果不佳,可以随时回滚,还是非常方便的。

image

这东西因人而异不是必须的,有的人开了反而更慢,但是有的人开了还是有所改善的

总结

我的习惯就是按部就班的完成以上五个步骤后,这台 VPS 才算真正“交付”到我自己手中,我就可以安心的建站也好部署软件也好,其实还可以增加 docker 部署的内容,但是不是每个人都必须的就没加上去。

  • 验机 让你心里有数,避免被坑,知道最基本的服务器参数了解清楚;
  • DD 系统 给了你一个干净的底层环境,尤其是国内的机器,有很多监控可能都不方便,比如什么阿里云盾拖慢服务器占用资源;
  • 安全加固 最基本的 SSH 安全加固,让你在玩服务器的时候无后顾之忧,不要担心服务器被黑;
  • 系统与网络优化 则榨干了机器的每一分性能,增加一些小鸡的可玩性,让小鸡也有更多的可能。

文中涉及的所有脚本,也可以在 VPS 常用脚本合集 中找到。

[上海] Kong 招聘多名工程师| Rust / Go / API Gateway / AI Gateway / Infra / 前端 / SDET ( 14 HC )

大家好,我们是 Kong 上海研发团队(核心产品线)

近期团队扩张,一次性开放 10+ 技术 HC 。
如果你对 网关 / 高并发 / 网络 / Rust / Go / 云原生 / AI Infra / 开发者工具 感兴趣,可以聊聊。

不是外包,不是业务 CRUD ,主要做 底层基础设施和高性能系统方向


关于 Kong

Kong 是全球领先的 API Gateway / Cloud Native Infrastructure 公司

核心产品:

  • Kong Gateway (基于 OpenResty / Nginx )
  • Service Mesh
  • AI Gateway (大模型流量治理)
  • Insomnia (开源 API Client ,类似 Postman )

客户多为海外技术型公司。

上海团队是:

  • 核心研发(非 support / 本地化)
  • 直接参与 global 架构设计
  • 英文协作 + 工程文化驱动

团队风格偏:

  • Code Review / Design Doc
  • Async 协作
  • 工程质量优先
  • 相对 WLB (不 996 )


在招岗位


① Gateway Runtime / Infra (核心推荐)

Staff Engineer / Senior / Software Engineer II (多名)

方向:

  • API Gateway Runtime
  • 高性能网络处理
  • 插件系统设计
  • 核心转发链路优化

技术栈:

  • Lua / Rust / Go / C++ / Java / Python
  • OpenResty / Nginx
  • Linux / Networking / 高并发 / 性能优化

希望你有:

  • 系统/中间件/网关/存储/高并发服务经验
  • 熟悉 HTTP/TCP/TLS 等网络协议
  • 做过性能优化/底层架构更佳

👉 适合喜欢「底层 + 性能 + 工程深度」的同学


② AI Gateway (新方向,增长中)

Engineering Manager / Senior Engineer

做什么:

  • 大模型/LLM 请求网关
  • AI 流量治理 & 安全控制
  • Token / Rate Limit / Policy 管理
  • AI Infra 能力建设

技术:

  • Go / Rust / Python / Lua
  • 有 LLM / AI 相关经验加分

👉 属于 AI + Infra 结合赛道,技术挑战比较新


③ 前端(平台型产品)

Config Management UI ( Vue )

  • Vue / TypeScript
  • 偏控制台/配置平台/DevTool
  • ToB/工程化前端经验加分


④ SDET / 自动化测试

Cypress / Playwright / TS/JS

  • 自动化测试框架建设
  • CI/CD 集成
  • 工程质量体系建设

不是纯手工测试,偏工程化能力


⑤ Insomnia Team (开发者工具)

  • Senior Go Engineer
  • Senior SDET

Insomnia 是开源 API Client (类似 Postman ),海外用户很多。

方向偏:

  • 客户端
  • 工具链
  • 开发者生态


为什么可以考虑我们(客观版)

  • 外企文化,节奏相对健康
  • 技术栈硬核( Rust / Go / 网关 / AI Infra )
  • 做真正的基础设施,不是业务系统
  • 团队规模小而强,个人影响力大
  • 和 global 团队直接协作

如果你:

  • 想从业务转 Infra
  • 想做 Rust/Go 底层
  • 或对 AI Infra/网关方向感兴趣

匹配度会比较高。


工作地点

📍 上海


投递方式

内推直达 Hiring Manager:

📮 [email protected]

💬 V2EX 私信我

邮件标题建议:
[岗位 + 年限 + 城市 + 姓名]

我会帮你直接对接,流程相对高效。


有问题欢迎回帖/私信交流。
也可以帮你判断岗位匹配度。

欢迎奔走相告,如感兴趣,非常欢迎直接投递英文简历到 chitty.li@konghq.com

https://jobs.ashbyhq.com/kong?locationId=7bc9ac56-8533-43bc-abe0-919dc8caa459 这是我们 Kong 现在上海在招的所有职位,您可以看看。

老婆的手机前阵子不知道在哪儿把主摄的镜头正当中横着划了一个一公分长很深的划痕

我是没想明白她包里或者口袋里能有什么东西如此坚硬可以把蓝宝石镜头盖划成这样

然后今天吃完饭逛到了国金直营店就顺路进去折旧买新手机

店员走了一遍检测说什么这个划痕没检测出来 当前估值 2930 如果过几天再来说不定就不是这个价了

那只好就折旧了 又加了 8000 多换了个 17pro

这个价格正常吗

内部运维工具的访问路径重构,核心在于以“身份态锚定”为核心构建全链路信任校验体系,彻底摒弃传统架构中基于内网网段的准入逻辑,将每一次运维访问请求都拆解为身份、环境、操作三重态的综合核验。在实际的技术落地中,运维人员对不同层级运维工具的访问,不再依赖固定的内网权限配置,而是需要先完成身份态的动态核验,涵盖人员身份的实时有效性、运维角色的权限匹配度,身份信息会与企业人员管理体系实时同步,确保权限与岗位状态完全绑定,再进行环境态的校验,包括访问终端的运行状态、网络接入的环境合规性,终端的补丁更新、安全配置都会纳入核验范畴,网络接入则不区分内外网,仅以环境合规性为判断标准,最后完成操作态的前置匹配,确认操作行为与运维场景的适配性,操作内容需与对应的运维工单、任务指令关联,无关联的操作请求会直接被拦截。三重态核验通过后,才会生成临时的访问链路,且链路的存续时间与操作范围严格绑定,操作结束后链路即刻失效,超时未完成操作也会自动断开。这种重构方式让访问路径从固定的、静态的内网通道,转变为动态的、按需生成的信任链路,从根源上杜绝了无授权访问、权限越界等问题,同时也让运维访问的每一个环节都处于可追溯、可管控的状态,实现了访问权限的微切片化与访问链路的态化闭环,彻底改变了传统运维访问的粗放模式。

在运维工具访问路径的深层重构中,还需建立“行为态校准”机制,针对批量运维、跨节点操作等复杂场景,构建动态的行为基线与实时校验逻辑。传统架构中,运维人员的批量操作往往缺乏过程校验,一旦出现操作偏差难以及时干预,甚至会引发连锁性的运行问题,而零信任架构下,会基于运维人员的历史操作数据、岗位场景特征,生成专属的行为基线,基线会区分常规运维、应急运维、批量配置等不同场景,动态适配不同的操作特征。在运维操作执行过程中,实时校验操作行为与基线的匹配度,若出现偏离基线的异常操作,比如超出权限范围的批量修改、非工作时段的高频操作,会即刻触发链路的临时冻结与二次核验,同时记录操作的态流数据,形成完整的行为溯源档案,档案会留存操作的全流程细节,为后续的复盘与优化提供依据。这种重构要求让运维操作从“事后追溯”转变为“事中校准”,不仅强化了访问链路的安全性,更优化了运维操作的合规性与精准性。此外,访问路径的重构还需适配多终端、跨地域的运维场景,打破物理位置与终端类型的限制,移动端、桌面端、远程终端的访问都遵循统一的三重态核验逻辑,针对移动终端还会增加设备绑定、生物特征核验等补充维度,确保无论何种访问场景,都能遵循统一的信任校验逻辑,让运维访问路径的重构具备全场景的适配性。

监控系统的数据采集方式重构,核心是建立“数据态溯源”体系,将数据采集的全链路纳入信任校验范畴,彻底改变传统架构中监控节点单向推送数据、采集链路无核验的模式。在实际实践中,监控系统的每一个采集节点,都需要先完成节点身份的锚定核验,采集节点需完成注册备案,绑定唯一的身份标识,核验通过后才能接入采集网络,未备案的节点会被直接拦截,杜绝非法采集节点接入。再对采集的数据进行态化封装,将数据的采集时间、采集节点、数据类型、信任核验结果等核心信息与专属信任标识绑定,形成可溯源的数据单元,每一个数据单元都具备唯一的溯源标识,可反向追踪至采集源头。数据传输过程中,每一个中转节点都需要对数据单元的信任标识进行核验,核验内容包括标识的有效性、数据的完整性,只有核验通过的数据才能进入下一级流转环节,最终汇聚至监控分析平台。这种重构方式让数据采集从无序的、无校验的单向流转,转变为有序的、可溯源的信任传输,从根源上避免了无效数据、篡改数据进入监控体系,同时也让监控数据的来源、流转过程清晰可查,为后续的数据分析与决策提供了可信的数据基础,也让监控采集链路的每一个节点都处于可控的状态,解决了传统监控数据杂乱、溯源困难的核心问题。

监控数据采集的深层重构,还需搭建“数据流转态管控”框架,针对监控数据的跨域汇聚、分级使用等场景,实现数据流转的全态管控与权限绑定。传统架构中,监控数据汇聚后往往采用统一的访问权限,难以实现数据的分级管控与精细化使用,不同岗位的分析人员无差别访问所有监控数据,极易造成数据滥用。而零信任架构下,会根据监控数据的敏感等级、使用场景,将数据划分为基础运行数据、核心节点数据、专项监控数据等不同层级,为不同的分析角色分配差异化的数据使用权限,权限与角色、岗位深度绑定,无法跨层级访问。数据在流转与使用过程中,会实时校验使用者的身份态与权限匹配度,同时记录数据的使用态流,包括数据查看、导出、分析等操作的全流程信息,形成完整的数据使用溯源档案。此外,监控数据的分析过程也会纳入态化管控,分析操作的类型、范围、时长都与权限严格绑定,超出权限范围的分析行为会被及时拦截,分析结果的导出也需经过二次核验。这种重构要求让监控数据从“集中存储、粗放使用”转变为“分级管控、精准使用”,既保障了监控数据的安全流转,又最大化发挥了数据的分析价值,同时也让监控系统的数据采集与使用形成完整的信任闭环,适配零信任架构的核心要求。

零信任架构下内部运维与监控体系的重构,并非一次性的静态实施,而是需要建立“架构态动态校准”机制,实现体系的长效适配与持续优化。在技术落地后,需定期对运维访问的三重态核验规则、监控采集的数据态溯源逻辑进行复盘,复盘周期结合企业技术迭代节奏设定,重点核验规则的适配性、执行效率与风险防控效果。结合运维场景的迭代、监控需求的变化,动态调整核验维度、权限配置与流转规则,比如新增运维工具时,快速补充对应的操作态校验规则,监控范围拓展时,优化数据态封装的维度。同时针对新接入的运维工具、新增的监控采集节点,快速完成信任体系的适配与融合,新节点接入前需完成全流程的信任校验配置,确保无缝融入现有体系。此外,还需建立态流数据的分析机制,通过对运维访问行为态、监控数据流转态的数据分析,识别体系运行中的薄弱环节,比如高频触发的异常核验点、数据流转的卡顿节点,针对性优化重构策略,调整核验规则与流转路径。

传统基于单点服务的观测体系,往往会陷入“局部达标、整体失准”的认知盲区,当业务事务在多服务间流转时,节点间的衔接损耗、状态传导偏差、流程闭环断层等隐性问题,会直接消解单点服务的优质表现,最终导致业务终端的体验劣化却无法溯源,这也使得构建一套锚定业务事务整体态的度量体系,成为分布式技术实践中亟待突破的核心命题。我们需要跳出技术链路的表层拼接视角,以业务语义为核心锚点,搭建覆盖事务全生命周期的全域度量框架,从本质上捕捉跨服务业务事务的真实运行状态,而非被碎片化的指标数据误导判断。在实际的技术落地中,我们常会遇到这样的场景:单个服务的可用率维持在极高水准,但跨十余个服务的业务事务却频繁出现闭环失败,终端反馈体验卡顿,可逐一排查单点服务时,却找不到任何异常指标,这种矛盾的根源就在于传统度量只关注节点本身,忽略了节点间协同流转的核心价值,而全域度量体系的构建,正是要打破这种碎片化观测的局限,让度量视角从“点”延伸至“域”,真正贴合分布式业务事务的运行本质。

定义跨数十服务的业务事务,核心在于完成“语义锚定”与“边界切片”的双重操作,摒弃以技术调用链路为唯一依据的定义方式,转而从业务流转的核心价值闭环出发,提取事务的核心发起节点、价值转化节点、结果闭环节点,以此为基准划分事务的核心域,再将支撑核心域流转的关联服务纳入从属域,剥离与业务价值闭环无直接关联的支撑性服务,避免度量范围的冗余扩张。同时通过“事务态标识”的方式,为每一次完整的业务流转赋予唯一的语义标识,贯穿所有关联服务的运行过程,确保度量数据能够精准归属于对应的业务事务实例。这种定义方式既规避了技术链路的复杂性干扰,又能让度量维度始终贴合业务的核心诉求,为后续的可用性与性能度量奠定精准的基础,也让跨服务的事务度量不再陷入无边界的技术链路追踪困境。在具体的操作实践中,我们会先梳理业务的核心价值流转路径,明确哪些服务是直接参与价值创造的核心节点,哪些是仅提供基础支撑的从属节点,再通过语义关联将核心节点串联成闭合的事务域,从属节点仅作为辅助观测维度纳入体系,这样既保证了度量的精准性,又降低了大规模数据采集的算力消耗,让事务定义既贴合业务逻辑,又具备技术落地的可行性。

度量跨服务业务事务的整体可用性,需构建以“稳态存续度”为核心的多维评估体系,区别于传统的服务在线率指标,该体系聚焦于业务事务从发起至闭环的全流程稳态存续能力,同时纳入“断层自愈率”作为辅助评估维度,稳态存续度通过统计业务事务在全生命周期内未出现流转中断、状态丢失的实例占比,反映事务整体的运行稳定性,而断层自愈率则衡量当某一服务节点出现运行波动时,事务流转的自愈传导效率,即波动节点的状态偏差能否在不影响事务闭环的前提下完成自我修正。我们通过划分事务的发起、流转、转化、闭环四大阶段,分别统计各阶段的稳态存续占比,再结合各阶段的自愈传导效率加权计算,最终得到业务事务的整体可用性分值。这种度量方式突破了单点可用性的局限,真正反映了跨服务事务的整体抗波动能力,也能精准定位导致事务中断的核心环节。在实际观测中,我们发现很多业务事务的可用性问题并非源于节点宕机,而是节点间的状态传导断层,比如某一节点的临时波动导致事务状态丢失,后续节点无法接续流转,而稳态存续度与断层自愈率的结合,能精准捕捉这类隐性故障,让可用性度量从“节点在线”升级为“事务闭环”,更贴合业务层面的真实需求。

对于跨服务业务事务的整体性能度量,我们摒弃了单节点时延求和的传统思路,提出“流转时延熵”与“节点协同滞涩度”两大核心度量指标,流转时延熵用于衡量业务事务在多服务间流转的时延离散程度,时延熵值越低,代表事务各环节的时延分布越均衡,整体流转的流畅性越高,反之则说明存在明显的时延瓶颈节点,节点协同滞涩度则评估相邻服务节点间的衔接效率,反映服务间状态传递、数据交互的滞缓程度。通过采集业务事务全链路的时延数据,分析其离散特征与节点间的衔接损耗,我们能够精准识别出性能瓶颈的核心位置,而非单纯关注单节点的时延高低,这种性能度量逻辑更贴合分布式事务的协同运行本质,能够从整体层面优化业务流转的性能表现,而非陷入单点性能优化的无效内耗。在实践中,我们曾遇到单节点时延极低,但整体事务流转缓慢的情况,通过流转时延熵分析发现,各环节时延差异极大,存在明显的短板节点,而节点协同滞涩度则进一步定位到节点间数据交互的衔接损耗,针对性优化后,整体事务性能提升显著,这也验证了这套性能度量体系的实用价值,让性能优化从单点调试转向全域协同调优。

将分散的度量数据转化为可落地的业务决策依据,核心在于构建“事务态画像”并提取“趋势推演因子”,我们整合稳态存续度、断层自愈率、流转时延熵、节点协同滞涩度等多维度量数据,通过特征聚合形成每类业务事务的专属态画像,直观呈现其可用性与性能的整体状态、薄弱环节与运行特征,同时从历史度量数据中提炼出影响事务运行的核心趋势推演因子,包括服务节点迭代频率、业务流量波动幅度、跨服务数据交互量等,基于这些因子对业务事务的未来运行状态进行推演,提前预判潜在的可用性风险与性能劣化趋势。这种数据应用方式让度量体系不再局限于事后统计,而是实现了事前预判、事中调控、事后优化的全流程支撑,让度量数据真正服务于分布式业务事务的持续优化。在落地过程中,我们会为每类高频业务事务生成动态态画像,实时更新度量数据,同时基于历史数据训练推演模型,当流量波动或服务迭代时,能提前预判事务运行风险,及时调整服务调度策略,避免体验劣化,让度量体系从“观测工具”升级为“决策支撑”,深度融入分布式系统的运维与优化流程。

分布式系统的动态演进特性,决定了业务事务的度量体系必须具备“动态域校准”与“度量弹性适配”能力,随着业务场景的迭代、服务架构的调整,跨服务业务事务的边界、核心流转节点、关联服务都会发生变化,若固守静态的度量体系,必然会导致度量结果的失真,因此我们需要建立定期的度量体系复盘机制,结合业务需求的变化与服务架构的演进,重新校准业务事务的语义锚点与边界切片,调整度量维度的权重与计算逻辑,同时适配不同业务事务的运行特征,为高频事务、复杂事务、低频事务制定差异化的度量策略,确保度量体系始终与系统的实际运行状态保持同步。这种动态适配的思路,让跨服务业务事务的可用性与性能度量能够长期保持精准性,成为分布式系统稳定运行与持续优化的核心支撑。

现在的基建 L2 、模块化、高性能公链感觉已经有些性能过剩了,但除了金融/Meme ,依然没看到能破圈的消费级应用,抛开行情不谈,阻碍 Web3 走向大众的核心瓶颈,究竟是 UX 体验(如私钥管理、AA 还没普及) 没跟上? 还是说我们其实一直没找到一个非去中心化不可的真实用户场景?在这个基建狂魔的阶段,想听听各位对真实落地痛点的看法。

前言: 针对坛友 bot 部署中常讨论的 Token 成本与模型智障问题,分享基于我的低成本(纯白嫖)接入方案。本文仅讨论技术实现与体验差异,不涉及推广。

一、API 方案(不推荐):高延迟与低可用性的妥协
API 接入虽然标准,但在“白嫖”或低成本层级下,体验往往受限于 RPM (Requests Per Minute) 和推断速度。

1.NVIDIA NIM (GLM-4.7-Flash):
规格: 免费层提供 GLM-4.7 ,理论性能不错。
实测: 限制 40 RPM 。最大的问题是延迟( Latency ),推断队列极长,导致 Agent 响应迟钝。
结论: 仅适合作为 fallback 或低频任务备用。

2.其他备选:
Google AI Studio: 免费层可用,但风控严格。
Modelscope (魔搭):听说还行,没用过。
SiliconFlow (硅基流动): 免费额度甚至不如本地量化模型实用,Pass 。

二、OAuth (你可以白嫖的订阅):我认可的目前的最优解
通过模拟用户会话( OAuth/Cookie )接入,通常能获得该模型满血版的推理能力和更大的上下文窗口。

1.Gemini (Google CLI / Anti-Gravity)

推荐指数: ⭐⭐⭐⭐⭐

接入方式: openclaw 原生支持 Google cli + 反重力 (AntiGravity) 接入。

优势:
智商在线: 完整的 Flash/Pro 体验,非阉割版,还有 Claude opus/sonnet 。
额度池: Flash 与 Pro 额度独立计算。
家庭组策略: 一个主号可开 5 个家庭组子号,配合 OpenClaw 的轮询策略( Round-Robin ),理论上可获得 6 账号 * ((Flash + Pro)*2+Claude) = 30 独立额度,叠加 5h 刷新的 flash ,可以说是其实单账号也是怎么也用不完的逆天额度。
状态: 目前 Edu 邮箱依然存活,建议自行解决账号源,勿通过二手渠道(高风险)。

2.Qwen (海外版)

推荐指数: ⭐⭐⭐⭐

优势: 注册即用,无门槛,openclaw 原生支持。

缺点: 朋友推荐,我没实测。

3.OpenAI (ChatGPT)

推荐指数: ⭐⭐⭐⭐

依然 openclaw 原生支持,本来肯定想放第二位推荐,但白嫖车已开走,适用已订阅用户。

策略:
适合作为 Coding 任务的主力( Gemini 在代码生成的准确性上仍逊于 GPT-5.3-codex )。
免费层额度每周重置,适合高强度突击使用 2-3 天,不适合 7x24 小时挂机,更别拿来挂 heartbeat 。

三、 建议与实操体验
模型路由 (Router): 建议日常对话/总结接 Gemini ,写代码上 codex 或者反重力的 claude 。

权限警示: OpenClaw 作为一个拥有本地 Shell 读写权限的 Agent ,其安全性完全依赖于模型的指令遵循能力。基模( Base Model )智商过低会导致指令误读,进而误删文件或执行错误脚本。

长期使用建议建立 .md 格式的 Memory/Todo/workflow 体系(我自己又加了给人看的日记 journal 和实用手册)。实测 Gemini 拟人化、全能任务最强,基本能达到“伴生助手”的体验。(最舍不得的是白嫖额度实在太 tm 够用了)

真实经验+AI 润色,欢迎补充

训练一个神经网络过程中,我们会关注两个问题:

模型能否毫不费力处理应用环境中没见过的数据?
模型能否被有效训练?
第一个问题涉及偏差与方差的权衡,第二个问题涉及梯度传播的稳定性。本文首先探讨偏差与方差,然后分析梯度问题,最后引出解决梯度问题的关键之一——科学的初始化方法。

偏差 & 方差
要理解模型的泛化能力,我们首先要量化它的“泛化误差”,即模型在未知数据上的表现。然而,泛化误差并非一个单一的问题,它源于三种不同性质的错误:模型固有的近似能力不足、对训练数据的过度敏感、模型数据本身的不可约噪声。

偏差 - 方差分解公式
规定:

P_{\text{data}}(x,y)P
data

(x,y):数据生成分布
\mathcal{D}D:从P_{\text{data}}P
data

中独立同分布采样得到的训练数据集
f(x;\mathcal{D})f(x;D):由训练集 \mathcal{D}D 学得的模型 ff 对 xx 的预测输出。
\overline f(x)
f

(x):\mathbb{E}_{\mathcal{D} \sim P_{\text{data}}^{\otimes n}}[f(x; \mathcal{D})]E
D∼P
data
⊗n


[f(x;D)],对所有可能训练集的期望
\mathbb{E}_{\mathcal{D} \sim P_{\text{data}}^{\otimes n}}[\cdot]E
D∼P
data
⊗n


[⋅]:对训练集采样的期望
有:

\mathbb{E}_{y|x} \mathbb{E}_{\mathcal{D}}[(f(x; \mathcal{D}) - y)^2] = \text{Bias}^2(f(x)) + \text{Var}(f(x)) + \sigma_\epsilon^2
E
y∣x

E
D

[(f(x;D)−y)
2
]=Bias
2
(f(x))+Var(f(x))+σ
ϵ
2

其中,

\text{Bias}^2(f(x))Bias
2
(f(x)):偏差,反映模型拟合能力。设真实函数为 h(x) = \mathbb{E}[y|x]h(x)=E[y∣x](条件期望),则偏差应定义为 (\overline f(x) - h(x))^2(
f

(x)−h(x))
2

\text{Var}(f(x))Var(f(x)):方差,反映不同数据集表现波动情况即泛化能力,:=\mathbb{E}_\mathcal{D}[(f(x;\mathcal{D})-\overline f(x))^2]:=E
D

[(f(x;D)−
f

(x))
2
]
\sigma_\epsilon ^2σ
ϵ
2

:噪声,反映学习难度,:=\mathbb{E}[(y - h(x))^2]:=E[(y−h(x))
2
]
这里正好对应两种模型:线性拟合 vs. 神经网络

若线性拟合,模型容量低,并且假设空间简单,即大偏差小方差,泛化误差大,欠拟合。
若复杂度过高的神经网络(如未正则化),会学到训练数据中的噪声,导致在训练数据上表现很好(小偏差),但在未见过的数据上表现波动很大(大方差),泛化误差大,过拟合。
若复杂度适中的神经网络,中等偏差中等方差,泛化误差小,最佳了。
得出结论:偏差大(欠拟合)意味着模型能力不足,未能捕捉数据中的真实模式;方差大(过拟合)意味着模型过于复杂,对训练数据中的噪声和随机波动过度敏感。

影响偏差与方差的三大因素

  1. 学习算法能力(模型复杂度)

如果模型欠拟合(偏差大),就换更复杂的模型;如果过拟合(方差大),就换更简单的模型(或对复杂模型做正则化)。

  1. 训练数据量

可间接降低偏差,对方差影响大
如果模型过拟合(方差大),优先增加训练数据。

  1. 学习任务本身的难度(任务复杂度)

如果任务简单但方差大,就控制模型复杂度或增加数据;如果任务复杂导致偏差大,就提升模型复杂度

处理模型高偏差、高方差的一些方法
欠拟合(高偏差):应该换更复杂的模型、增加特征维数、仔细判断训练误差是否收敛到最低。

过拟合(高方差):应该增加训练数据、正则化(如使用L1正则化、L2正则化(即权重衰减)、Dropout等)、批量归一化、剪枝降复杂度、降低特征维度。

偏差-方差权衡
偏差与方差通常是对立的,提高模型复杂度可以减少偏差,但可能增加方差;反之,降低模型复杂度可以减少方差,但偏差可能会升高。这种权衡关系被称为 偏差-方差权衡(Bias-Variance Tradeoff)

在此我们应该拓展一下,经典理论认为模型复杂度(如参数数量)增加,泛化误差会先因偏差降低而下降,后因方差增大而上升,形成单一的U型曲线。双重下降则揭示了在插值阈值(模型刚好能完美拟合训练数据)后,随着复杂度进一步增加,误差会再次下降,形成“下降-上升-下降”的波浪形曲线。在过参数化区域,模型并非必然过拟合到更差的程度,优化过程会引导其找到一个泛化良好的解。在过参数化体制下,模型好像是先“记忆”(拟合噪声),后通过漫长的优化过程“逐渐获得”泛化规则。(其实真正的原因是隐式正则化使得优化算法(如SGD)倾向于找到最小范数解或平坦极小值)

这告诉我们,如果观察到增加模型参数后性能先变差,不要立即止步。这可能只是处于插值阈值附近的危险区。继续增加规模,并配合足够的训练,性能可能会突破并变得更好。

理解了模型的误差问题由偏差、方差间的权衡决定,我们大体了解如何选择模型的复杂度。但是,当我们着手训练一个复杂深层模型,尤其是现代网络层数不断加深时,我们应该考虑,训练本身是否能够正常进行?否则结果上的“偏差、方差”都成空谈。这就引出了深度学习中的 梯度问题 。

梯度问题
我们可以认为,

\mathbf{h}^{(l)} = f_l (\mathbf{h}^{(l-1)})h
(l)
=f
l

(h
(l−1)
)

因此

\mathbf{o} = f_L \circ f_{L-1}\circ \ldots\circ f_2\circ f_1(\mathbf{x})o=f
L

∘f
L−1

∘…∘f
2

∘f
1

(x)

那么不难得到:

\partial_{\mathbf{W}^{(l)}} \mathbf{o} = \underbrace{\partial_{\mathbf{h}^{(L-1)}} \mathbf{h}^{(L)}}_{ \mathbf{M}^{(L)} \stackrel{\mathrm{def}}{=}} \cdot \ldots \cdot \underbrace{\partial_{\mathbf{h}^{(l)}} \mathbf{h}^{(l+1)}}_{ \mathbf{M}^{(l+1)} \stackrel{\mathrm{def}}{=}} \underbrace{\partial_{\mathbf{W}^{(l)}} \mathbf{h}^{(l)}}_{ \mathbf{v}^{(l)} \stackrel{\mathrm{def}}{=}}.

W
(l)


o=
M
(L)

=
def


h
(L−1)


h
(L)


⋅…⋅
M
(l+1)

=
def


h
(l)


h
(l+1)

v
(l)

=
def


W
(l)


h
(l)


.
也因此,梯度 \partial_{\mathbf{W}^{(l)}} \mathbf{o}∂
W
(l)


o 是 (L-l)(L−l) 个雅可比矩阵 \mathbf{M}^{(L)}, \dots, \mathbf{M}^{(l+1)}M
(L)
,…,M
(l+1)
与一个二维张量 \mathbf{v}^{(l)}v
(l)
的乘积。在深层网络中,连续矩阵乘法可能导致结果数值过大(爆炸)或过小(消失)。

梯度消失:

如果使用Sigmoid函数,就要考虑 Sigmoid 函数在其饱和区梯度逼近于零的情况。因此当输入很大或很小时,梯度消失。为此我们最好用ReLU函数替代之。

如果每一次的 梯度都减小一点,那么多层传播后梯度值会非常小。

如果权重的初始值太小,向前传播过程中每层线性变换的输出方差大幅衰减,进而使激活函数的输入落入该函数的危险区(如 Sigmoid 的饱和区、ReLU的斩杀区)。

梯度爆炸:

特指反向传播过程中,梯度值随着层级增加而不断变大,乃至指数型增加。

很可能因为 weightweight 的初始值太大,层数过多等等

参数化的对称性:
若同一层内的的所有权重均初始化为相同值,那么该层所有的神经元在反向传播中都会获得完全一样的梯度,永远学习相同的特征,极大降低模型容量。

那么,如何为我们模型的训练提供一个良好、稳健的起点呢?这就是神经网络 参数初始化 的showtime了。良好的初始化方式,能够前向传播中保持传递强度,在反向传播中保证梯度流动,从而打破上文的 参数化的对称性 等等问题。

三种常见的初始化
Xavier初始化
目标:保持各层激活值方差稳定,确保前向传播的信号强度和反向传播的梯度强度在初始化时不衰减也不爆炸。

Xavier 初始化因为提出的时间较早,它主要针对像 tanhtanh 这样在原点附近近似线性且对称的饱和激活函数。因此对于后来广泛使用的 ReLU 及其变种,它的效果并非最优。

这里的3个函数都有饱和区,也就是梯度消失的那段区域,太大或太小时函数导数趋于 00 。

这个理论的基本原则就是:在前向传播中,保持各层激活值的方差一致;在反向传播中,保持各层梯度的方差一致。 也就是说初始化阶段的激活值和梯度的期望均为 00。Xavier初始化是为 tanhtanh 这类在零点附近近似线性且对称的激活函数设计的,对于 SigmoidSigmoid,虽然 Xavier初始化可以用于 SigmoidSigmoid ,但不是最优的。实际应用中,对 SigmoidSigmoid 可以使用 Xavier初始化,但可能需要调整缩放因子。

用数学语言表述,就是要激活函数在原点泰勒展开的一阶近似(当然 xx 也在 00 附近) f(x)f(x) 满足:

\begin{split} &f(x) = -f(-x),即f(0)=0\ &f'(0)=1\end{split}

f(x)=−f(−x),即f(0)=0
f

(0)=1

再换句话,由观察,我们希望任意层的输入信号方差应等于其输出信号方差:

Var(a^{(l-1)}) \approx Var(a^{(l)})
Var(a
(l−1)
)≈Var(a
(l)
)
观察第 ll 层的线性变换:

\mathcal{z_i^{l}}=\sum_{j=1}^{n_{in}}w_{ij}^{(l)}\cdot a_j^{(l-1)}
z
i
l

=
j=1

n
in


w
ij
(l)

⋅a
j
(l−1)

这里先基本假设一下:

权重 w_{ij}^{(l)}w
ij
(l)

独立同分布,均值为 00,方差 \sigma _w^2σ
w
2

激活值 a_{j}^{(l-1)}a
j
(l−1)

独立同分布,均值为 00,方差 \sigma _a^2σ
a
2

权重和激活值相互独立
先看看期望:
\begin{split} \mathbb{E}[z^{(l)}_i]&=\mathbb{E}\bigg[ \sum^{n_{in}}_{j=1}w_{ij}^{(l)}a_j^{(l-1)} \bigg]\ \mathbb{E}[z_i^{(l)}]&=\sum_{j=1}^{n_{in}}\mathbb{E}[w_{ij}^{(l)}]\cdot \mathbb{E}[a_j^{(l - 1)}]\ \mathbb{E}[z_i^{(l)}]&=0 \end{split}
E[z
i
(l)

]
E[z
i
(l)

]
E[z
i
(l)

]

=E[
j=1

n
in


w
ij
(l)

a
j
(l−1)

]
=
j=1

n
in


E[w
ij
(l)

]⋅E[a
j
(l−1)

]
=0

再看看方差,先着眼于前向传播的过程:
\begin{split} Var(\mathcal{z_i^{(l)}})&=\mathbb E[(\mathcal{z_i^{(l)}})^2]-(\mathbb E[\mathcal z_i^{(l)}])^2\ &=\mathbb E[(\mathcal{z_i^{(l)}})^2] \ &= \mathbb{E} \left[ \left( \sum_{j=1}^{n_{\text{in}}} w_{ij}^{(l)} a_j^{(l-1)} \right)^2 \right] \ &= \mathbb{E} \left[ \sum_{j=1}^{n_{\text{in}}} \sum_{k=1}^{n_{\text{in}}} w_{ij}^{(l)} w_{ik}^{(l)} a_j^{(l-1)} a_k^{(l-1)} \right]\ &= \ldots\ &= \sum_{j=1}^{n_{in}}\mathbb E[(\mathcal{w}_{ij}^{(l)})^2]\cdot\mathbb E [(a_j^{(l - 1)})^2] \space(j=k)\ &=n_{in}\cdot\sigma_w^2\cdot\sigma_a^2\ \end{split}
Var(z
i
(l)

)

=E[(z
i
(l)

)
2
]−(E[z
i
(l)

])
2

=E[(z
i
(l)

)
2
]
=E

(
j=1

n
in


w
ij
(l)

a
j
(l−1)

)
2

=E[
j=1

n
in

k=1

n
in


w
ij
(l)

w
ik
(l)

a
j
(l−1)

a
k
(l−1)

]
=…
=
j=1

n
in


E[(w
ij
(l)

)
2
]⋅E[(a
j
(l−1)

)
2
] (j=k)
=n
in

⋅σ
w
2

⋅σ
a
2

上文公式推导省略号中的内容:

当 j\neq kj

=k,式子为 00
当 j=kj=k,式子为 \sum_{j=1}^{n_{in}}\mathbb E[(\mathcal{w}_{ij}^{(l)})^2]\cdot\mathbb E [(a_j^{(l = 1)})^2]∑
j=1
n
in


E[(w
ij
(l)

)
2
]⋅E[(a
j
(l=1)

)
2
]
因此,求和中仅 j=kj=k 的项有贡献。
为了保证激活方差不变,即

\begin{split} Var(z_i^{(l)})&=Var(a_j^{(l - 1)})\ n_{in}\cdot\sigma^2\cdot\sigma_a^2&=\sigma_a^2\ n_{in}\cdot\sigma_w^2&=1\ \end{split}
Var(z
i
(l)

)
n
in

⋅σ
2
⋅σ
a
2

n
in

⋅σ
w
2

=Var(a
j
(l−1)

)

a
2

=1

接着推导一下反向传播:
反向传播的梯度传播公式如下

\frac{\partial L}{\partial a_j^{(l-1)}}=\sum_{i=1}^{n_{out}}w_{ij}^{(l)}\cdot\frac{\partial L}{\partial z_i^{(l)}}
∂a
j
(l−1)

∂L

=
i=1

n
out


w
ij
(l)


∂z
i
(l)

∂L

那么假设 \frac{\partial L}{\partial z_i^{(l)}}
∂z
i
(l)

∂L

独立同分布,方差为 \sigma_g^2σ
g
2

,可以得到梯度方差的表示:

\begin{split} Var\left( \frac{\partial L}{\partial a_j^{(l-1)}} \right)&=\sum_{i=1}^{n_{out}}\mathbb{E}[(w_{ij}^{(l)})^2]\cdot\mathbb{E}\left[ \left( \frac{\partial L}{\partial z_i^{(l)}} \right)^2 \right] \ &=n_{out}\cdot\sigma_w^2\cdot\sigma_g^2\ \end{split}
Var(
∂a
j
(l−1)

∂L

)

=
i=1

n
out


E[(w
ij
(l)

)
2
]⋅E

(
∂z
i
(l)

∂L

)
2

=n
out

⋅σ
w
2

⋅σ
g
2

我们希望反向传播前后梯度方差不变。即希望:

Var\left( \frac{\partial L}{\partial a_j^{(l-1)}} \right)=Var\left( \frac{\partial L}{\partial z_i^{(l)}} \right)
Var(
∂a
j
(l−1)

∂L

)=Var(
∂z
i
(l)

∂L

)
那么就可以得到反向传播保持方差不变时应满足的条件:

\begin{split} n_{out}\cdot\sigma_w^2\cdot\sigma_g^2&=\sigma_g^2\ n_{out}\cdot\sigma_w^2&=1 \end{split}
n
out

⋅σ
w
2

⋅σ
g
2

n
out

⋅σ
w
2


g
2

=1

因此,这种一下这两个条件,取调和平均:
\begin{split} n_{in}\cdot\sigma_w^2&=1\ n_{out}\cdot\sigma_w^2&=1\ \sigma_w^2&=\frac{2}{n_{in}+n_{out}}\ \end{split}
n
in

⋅σ
w
2

n
out

⋅σ
w
2

σ
w
2

=1
=1
=
n
in

+n
out

2

即:

Var(\mathcal w) = \frac{2}{n_{in}+n_{out}}
Var(w)=
n
in

+n
out

2

这样,标准差就出来了:

\sigma = \sqrt \frac{2}{n_{in}+n_{out}}
σ=
n
in

+n
out

2

因此初始权值应符合的正态分布:

W\sim \mathcal N(0,\sigma^2)
W∼N(0,σ
2
)
或者转化为均匀分布形式,即

w\sim U\left[ -\sqrt{\frac{6}{n_{in}+n_{out}}},\sqrt{\frac{6}{n_{in}+n_{out}}} \right]
w∼U[−
n
in

+n
out

6


,
n
in

+n
out

6


]
然而,Xavier初始化提出的时间有点早,ReLU激活函数还没有得到广泛应用。
对于ReLU函数,Xavier初始化力不从心:

ReLU的函数输出非对称:y \in [0,+∞)y∈[0,+∞)
负的输入反向输出时梯度为 00
会将 50\%50% 的神经元输出清零,从而
前向传播:Var(a) \approx \frac{1}{2}Var(y)Var(a)≈
2
1

Var(y)
反向传播:梯度方差同样减半
而且对于深层神经网络而言,线性激活函数价值不大,因为它需要非线性激活函数来构建复杂的非线性神经网络。

面对这些问题,He初始化(Kaiming初始化)被提了出来。

Kaiming 初始化
与 Xavier 初始化类似,Kaiming 初始化的目的也是尽量让每一层输出层的方差与输入层的方差一致,以缓解深层网络中的梯度消失、梯度爆炸问题,最后使极深整流网络(如30层)能从零开始直接训练并收敛。

对于向前传播:

\begin{split} \text{Var}(y_i) &= \text{Var} \left( \sum_{j=1}^{n_{\text{in}}} w_{ij} \cdot x_j \right) \&= n_{\text{input}}\cdot\text{Var}(w_{ij}) \cdot \text{Var}(x_j) \end{split}
Var(y
i

)

=Var(
j=1

n
in


w
ij

⋅x
j

)
=n
input

⋅Var(w
ij

)⋅Var(x
j

)

对y_iy
i

加入ReLU函数得到a_ia
i

,那么我们就希望:

\text{Var}(a_i) \approx \text{Var}(x_j),\quad \forall i,j
Var(a
i

)≈Var(x
j

),∀i,j
这里的初始化假设与 Xavier 相同。

因为 w_{ij}w
ij

与 x_jx
j

独立且均值为 00,有

\text{Var}(w_{ij}x_j)=\text{Var}(w_{ij})\text{Var}(x_j)=\sigma_w^2\sigma_x^2
Var(w
ij

x
j

)=Var(w
ij

)Var(x
j

)=σ
w
2

σ
x
2

则 y_iy
i

的方差为:

\begin{split} \text{Var}(y_i) &= \text{Var}\left( \sum_{j=1}^{n_{in}}w_{ij}x_j \right)\ &=\sum_{j=1}^{n_{in}}\text{Var}(w_{ij}x_j)\ &=\sum_{j=1}^{n_{in}}\sigma_w^2\sigma_x^2\ &=n_{in}\sigma_w^2\sigma_x^2\ &=n_{in}\cdot\text{Var}(w)\cdot\text{Var}(x) \end{split}
Var(y
i

)

=Var(
j=1

n
in


w
ij

x
j

)
=
j=1

n
in


Var(w
ij

x
j

)
=
j=1

n
in


σ
w
2

σ
x
2

=n
in

σ
w
2

σ
x
2

=n
in

⋅Var(w)⋅Var(x)

我们假设 y_iy
i

的分布是关于 0 对称的,那么 y_iy
i

取正数和取负数的概率各占一半。

再看 y_i^2y
i
2

。因为平方把正负都变成了正数,所以 y_i^2y
i
2

的期望值 E[y_i^2]E[y
i
2

] 可以拆成两半:一半来自 y_i>0y
i

0,一半来自 y_i<0y
i

<0。由于对称,这两半的贡献是一模一样的。

而 ReLU 函数 a_i = \max(0, y_i)a
i

=max(0,y
i

) 只取 y_iy
i

的正值部分,负数部分直接归零。所以 a_i^2a
i
2

其实就是 y_i^2y
i
2

在 y_i>0y
i

0 时的值,其他情况为 0。

因此,a_i^2a
i
2

的期望 E[a_i^2]E[a
i
2

] 正好就等于 y_i^2y
i
2

期望的一半,即

E[a_i^2]=\frac{1}{2}E[y_i^2]
E[a
i
2

]=
2
1

E[y
i
2

]
而 E[y_i]=0E[y
i

]=0,有 E[y_i^2]=\text{Var}(y_i)E[y
i
2

]=Var(y
i

),故

E[a_i^2]=\frac{1}{2}\text{Var}(y_i)
E[a
i
2

]=
2
1

Var(y
i

)
当 (E[a_i])^2(E[a
i

])
2
相较于 E[a_i^2]E[a
i
2

] 可以忽略时,可近似为:

\text{Var}(a_i)\approx\frac{1}{2}\text{Var}(y_i)
Var(a
i

)≈
2
1

Var(y
i

)
我们希望 \text{Var}(a_i) = \text{Var}(x)Var(a
i

)=Var(x)(当然至少得是近似的),结合可得:

\begin{split} \frac{1}{2}\cdot n_{in}\cdot Var(w)\cdot Var(x) &=Var{(x)}\ Var(w)&=\frac{2}{n_{in}} \end{split}
2
1

⋅n
in

⋅Var(w)⋅Var(x)
Var(w)

=Var(x)
=
n
in

2

以此类推,可以得到反向传播时,

Var(w)=\frac{2}{n_{out}}
Var(w)=
n
out

2

不过一般情况,我们使用前向传播优先,即

W\sim \mathcal{N}(0,\sqrt \frac{2}{n_{in}})
W∼N(0,
n
in

2


)
我们为什么不常见类比Xavier做调和平均呢?(其实是可以的,见 PyTorch 中的 mode='fan_avg' )因为ReLU的单向激活特性使得前向传播和反向传播的方差传播规律不同:

对前向传播,ReLU 杀死一半的神经元,方差减半;对反向传播,相当于简单的伯努利掩码,方差依旧减半。
问题在于正向反向的网格结构可能是不同的,且正向反向的衰减机制有席位差别。
pytorch实现:

1
2
3
4
layer = nn.Linear(64, 128)
init.kaiming_normal_(layer.weight, a=0, mode='fan_in', nonlinearity='relu')

a:负斜率(Leaky ReLU 的情况,默认为0)

Leaky ReLU : 负x轴设置为 ax ,而不是 0 ,通常 a = 0.01

正交初始化
上面两种方法都是对每个权重分别进行随机独立采样,但是由于采样的随机性,仍不可避免出现各种梯度问题。

对于一个 L 层的等宽线性网络,可以很容易得到这个等式:

y=W^{(L)}W^{(L-1)}W^{(L-2)}\cdots W^{(2)}W^{(1)}x
y=W
(L)
W
(L−1)
W
(L−2)
⋯W
(2)
W
(1)
x
那么,我们可以直接将 W^{(i)}W
(i)
初始化为正交矩阵。

根据线代知识,我们对这个初始权重矩阵的构建分为两步:

用均值 00 , 方差 11 的高斯分布构建一个矩阵
奇异值分解这个矩阵,得到两个正交矩阵,选择其中一个作为权重矩阵
根据正交矩阵的性质,这个线性网络就会在前向、反向传播中都有一定的范数保持性。如果这个网络是非线性的,只需在矩阵前面乘上一个系数 \rhoρ,这个系数与激活函数有关,如对于 ReLUReLU 应该 \rho=\sqrt 2ρ=
2

,对于 tanhtanh 应该 \rho\approx 1.0ρ≈1.0,这是为了补偿激活函数对信号幅度的压缩(扩张)效应。

更加现代的初始化方法
Fixup
可使在不使用批量归一化的情况下完成深度残差网络训练。

通过缩放残差网络分支的权重来控制梯度规模,避免深层网络的梯度爆炸

方法:

将分类层、残差分支的最后一层初始化为 00
对其他层使用标准方法的初始化,然后将残差分支中的权重层乘以缩放系数 L^{-\frac{1}{2m-2}}L

2m−2
1

在每个分支中添加一个标量乘数(就是前面的缩放系数),在每个卷积、线性和元素级激活层前面添加一个可学习标量偏差(初始为 00 )。
其中

mm:每个残差块中的权重层数
LL:网络总残差块数
T-Fixup
在完全移除层归一化的情况下,稳定并高效地训练 Transformer 模型

通过精心设计的参数初始化和简单的标量偏差,在数学上使前向传播的信号幅度和反向传播的梯度范数在初始化时保持稳定,从而完全移除所有 LN 层。

成年人的世界,总是需要点痛苦才会成长,可能这就是人性吧
不能一直待在舒适圈中
最近总感觉生活有点平淡,晚上总是很晚睡,有时候早睡中途也会醒来,可能白天喝咖啡的原因
突发奇想就想着去跳伞
主要是跳伞之前比较紧张,教练也说蹦极比跳伞恐怖,但其实跳伞也就那样
很多事情就是需要挑战自己,不要内耗,跳伞完还是比较畅快的,就是有点心疼钱,奢侈了一把

前情提要

我的 AppleID 注册于 2014 年,刚开始注册时是国区,2018 年 12 月下载了国区抖音,2020 年转了美区。

目前手机上仅登录了美区 AppleID ,平时下载一些国区独有的 App 如交管 12323 时,会临时将 App Store 账号切换到国区小号,下载完成后切回主号。

发现问题

刚才在抖音评论区看见许多人在说语音相关的事情,而我的评论区中没有语音,猜测是版本问题。

App Store 中检查更新,找不到抖音这个 App 的更新提示。去购买历史中搜索抖音也没有结果,我一直翻到 2018 年,发现那时下载抖音的历史已经被替换成了 TikTok 。

尝试

既然美区主号无法更新,我将 App Store 切换到国区小号,搜索抖音的结果列表中显示抖音已经安装,打开抖音详情页,点击更新按钮后,App Store 提示 The developer has removed this app from the App Store

所以理论上我手机上现存的 “抖音” App 成了孤儿 App ,身份上属于美区 App ,却已经被 Ta 的开发者无情抛弃,只能忍痛将它删除,切换到国区小号重新下载 App 。

结论

这个世界越来越差了。

企业微信ipad协议的技术实现与应用探讨

企业微信作为企业级通信工具,其协议接口在多种设备端均有相应实现,其中ipad端协议因其移动办公场景的适配性而受到关注。本文将从技术角度解析企业微信ipad协议的基本框架与接口调用方式,旨在提供客观的技术参考。

企业微信协议接口基于HTTP/HTTPS协议进行通信,通过官方提供的API实现数据交互。在ipad端,协议主要处理消息同步、文件传输及身份验证等功能。其接口设计遵循RESTful风格,支持JSON数据格式,确保跨平台兼容性。开发者可通过合法授权获取接口权限,实现自动化业务流程集成。

在协议实现中,关键点在于请求鉴权与数据加密。企业微信使用access_token机制进行身份验证,每个请求需携带有效token。以下是一个简单的Python示例,展示如何调用消息发送接口:

import requests
import json

# 企业微信API基础URL
base_url = "https://qyapi.weixin.qq.com/cgi-bin/message/send"
# 假设已获取合法access_token,此处仅为示例
access_token = "your_access_token_here"
payload = {
    "touser": "@all",
    "msgtype": "text",
    "agentid": 1000001,
    "text": {
        "content": "测试消息"
    },
    "safe": 0
}
headers = {'Content-Type': 'application/json'}
# 发送POST请求
response = requests.post(
    f"{base_url}?access_token={access_token}",
    data=json.dumps(payload),
    headers=headers
)
print(response.json())

此代码示例展示了基础的消息发送流程,需注意在实际应用中,access_token需通过官方OAuth2.0流程获取,避免直接硬编码。协议接口还支持文件上传、部门管理等功能,开发者可参考官方文档进行扩展。

在移动端适配中,ipad协议优化了触控交互与离线同步机制。例如,消息队列采用长轮询方式减少能耗,同时利用本地缓存提升响应速度。这些设计确保了在企业内部协作场景下的稳定性与效率。

总结而言,企业微信ipad协议为企业自动化提供了可靠的技术基础。通过合理使用接口,可构建定制化办公解决方案,但需遵循平台规范,确保数据安全与合规性。随着技术迭代,协议接口将持续演进,以支持更丰富的企业应用场景。

# 技术支持:contact_info = "bot555666"

image.png

OpenClaw 目前是全球用户规模最大的自托管个人 AI 助手。从 AI Agent 开发者的视角来看,它不仅仅是一个 AI 工具,更是一个极具参考价值的真实世界 Agent 设计范例。它能够帮助我们在构建 Agent 时形成更加成熟、系统化的设计思路。

在本文中,我将探索 OpenClaw 的内部设计,并最终构建出一个概念模型

概念模型

下图是我构建的 OpenClaw 概念模型:

image.png

OpenClaw 概念模型
使用 Draw.io 打开

该模型基于两个“事实来源”(source of truth):

  • OpenClaw 官方文档:https://docs.openclaw.ai/
    为了验证准确性,你可以在 draw.io 中打开该图,并点击图中指向文档的链接。
  • 对运行中的 OpenClaw 进行 LLM Prompt 与 Tool Calling 的追踪分析

文档分析

官方文档 内容十分丰富,但其组织方式并不是“循序渐进式”的概念教学结构。因此,在阅读过程中,我经常会迷失在文档页面之间。

问题的核心在于:
文档缺乏一个整体性的概念地图,以及各个概念之间清晰、显式的关系描述。

在通读文档后,我尝试尽可能地提炼并还原这些概念之间的关联。

掌握 Prompt 追踪

绝大多数 AI 应用的“核心秘密”,都隐藏在其 LLM Prompt 之中。但对 LLM 流量进行追踪,往往就像掉进了一个由非结构化数据组成的兔子洞。

有效的可观测性(Observability)通常依赖两种主要方法:

  • Tracing(追踪)
  • Sampling(采样)

在我的实验环境中,我使用 OpenRouter 作为 LLM 网关。它支持一种名为 Broadcast 的追踪复制机制(文档)。
我将其配置为把追踪数据发送到我对外开放的、自托管的 Langfuse 服务。

环境准备

为了演示 Prompt 追踪,我们需要一个会触发 OpenClaw 执行特定 Skill 的场景。

我选择了自己自托管的 Home Assistant 实例(用于管理智能家居设备)作为目标环境。为了完成集成,我从以下地址安装了所需的 Skill:

https://clawhub.ai/dbhurley/homeassistant

并将其放置到目录:

~/.openclaw/workspace/skills/homeassistant

同时,别忘了设置环境变量(通常配置在 ~/.openclaw/.env 中):

HA_URL=http://your-ha-host:8123
HA_TOKEN=your_ha_token

理解 Agent Skill 的“魔法”

打开 OpenClaw Dashboard,新建一个聊天会话,并输入以下 Prompt:

Any smart home device in my study room?

为什么要使用 OpenClaw Dashboard,而不是 IM 客户端?
虽然 OpenClaw 支持 Telegram、WhatsApp 等主流即时通讯工具,但在开发和调试阶段,原生 Dashboard 更具优势。
与普通聊天界面不同,Dashboard 提供了一个高可见度的“检查模式(inspection mode)”,能够实时展示:

  • Agent 即将调用的 tool 及其参数
  • 系统返回的原始执行结果
    这种透明性对于验证 Agent 行为至关重要。

接下来,打开 Langfuse Dashboard,进入 Tracing 页面。你将看到捕获到的一系列 Trace。
我们按时间顺序分析前两个 Trace,以理解 Skill 的发现、加载与调用机制

1. Skill 发现

LLM 输入 —— Messages:

You are a personal assistant running inside OpenClaw.
...
## Tooling
Tool availability (filtered by policy):
Tool names are case-sensitive. Call tools exactly as listed.

- read: Read file contents
- write: Create or overwrite files
...
## Skills (mandatory)
Before replying: scan <available_skills> <description> entries.
- If exactly one skill clearly applies: read its SKILL.md at <location> with `read`, then follow it.
- If multiple could apply: choose the most specific one, then read/follow it.
- If none clearly apply: do not read any SKILL.md.
Constraints: never read more than one skill up front; only read after selecting.
The following skills provide specialized instructions for specific tasks.
Use the read tool to load a skill's file when the task matches its description.

<available_skills>
...
  <skill>
    <name>homeassistant</name>
    <description>Control Home Assistant - smart plugs, lights, scenes, automations.</description>
    <location>~/.openclaw/workspace/skills/homeassistant/SKILL.md</location>
  </skill>
</available_skills>

LLM 输入 —— Tool 声明:

tools: [
  {
    type: "function",
    function: {
      name: "read",
      description: "Read the contents of a file...",
      parameters: {
        type: "object",
        properties: {
          path: { "type": "string" },
...
          file_path: { "type": "string" }
        }
      }
    }
  }
]

LLM 输出:

completion: "read{\"path\": \"~/.openclaw/workspace/skills/homeassistant/SKILL.md\"}",
reasoning: "用户在询问书房里的智能家居设备,这与 Home Assistant Skill 完全匹配,因此需要加载该 Skill 的说明文档。"

此时,LLM 主动调用 read 工具,读取对应 Skill 的 SKILL.md 文件。


2. Skill 加载

Agent 接收到 LLM 的 Tool Call 后,执行 read,并将 SKILL.md 内容返回给 LLM。

LLM 输入(节选):

messages: [
    ...
    {
role: "tool"
content: "---
name: homeassistant
description: Control Home Assistant - smart plugs, lights, scenes, automations.
homepage: https://www.home-assistant.io/
metadata: {"clawdis":{"emoji":"🏠","requires":{"bins":["curl"],"env":["HA_TOKEN"]},"primaryEnv":"HA_TOKEN"}}
---

# Home Assistant

Control smart home devices via Home Assistant API.

## Setup

Set environment variables:
- `HA_URL`: Your Home Assistant URL (e.g., `http://192.168.1.100:8123`)
- `HA_TOKEN`: Long-lived access token (create in HA → Profile → Long-Lived Access Tokens)

## Quick Commands

### List entities by domain
```bash
curl -s "$HA_URL/api/states" -H "Authorization: Bearer $HA_TOKEN" | \
  jq -r '.[] | select(.entity_id | startswith("switch.")) | .entity_id'
```
...

随后,LLM 输出

completion: "exec{\"command\": \"curl -s \\\"$HA_URL/api/states\\\" -H \\\"Authorization: Bearer $HA_TOKEN\\\" | jq -r '.[] | select(.attributes.area_name // .attributes.room // .entity_id | contains(\\\"study\\\")) | {entity_id: .entity_id, name: .attributes.friendly_name, state: .state, area: (.attributes.area_name // \\\"N/A\\\")}' | head -20\"}"

在理解了 homeassistant Skill 的文档后,LLM 发起了一个 exec Tool Call,通过命令行访问 Home Assistant 的 HTTP API。

这里最巧妙的设计点在于安全性:

Agent 不会将真实的 Token 或凭据直接传递给 LLM。
Skill 使用环境变量来注入敏感信息,从而确保这些秘密:

  • 不会暴露在 LLM 的上下文中
  • 不会被记录在 Trace 历史里

这是一个值得借鉴的 Agent 安全设计模式。不过,OpenClaw 中充满了各种被业界认为不安全的设计,所以,参考时还需要多加甄别。