包含关键字 typecho 的文章

一场针对亚洲地区互联网信息服务(IIS)服务器的高水准网络攻击已升级,攻击者推出了全新的高度定制化恶意软件变体。思科 Talos 安全团队确认,威胁组织 UAT-8099 自 2025 年末至 2026 年初发起新一轮攻击浪潮,攻击目标明确指向泰国、越南及周边地区的受害者
与向互联网大规模散播通用恶意软件的广谱攻击不同,UAT-8099 为其核心攻击武器 “BadIIS” 量身定制了区域适配功能。这款恶意软件现已在代码中直接嵌入 “区域锁定” 机制 。
报告指出:“BadIIS 的新型变体将目标区域直接硬编码至恶意软件中,每个特定变体都配备了定制化功能。”
这种定制化设计能让攻击者更好地伪装成合法流量。该恶意软件包含 “专属文件扩展名、对应的动态页面扩展名、目录索引配置,以及从本地文件加载 HTML 模板的能力”。如此细致的设计表明,攻击者对其攻击目标的运行环境具备深入了解
最令人意外的进展是,该组织的攻击范围已突破 Windows 系统限制。尽管 IIS 是 Windows 专属服务,但 Talos 研究人员发现,UAT-8099 已将其攻击工具适配至 Linux 环境。
报告称:“2025 年 10 月 1 日,一款 BadIIS 的 Linux 可执行与可链接格式(ELF)变体被上传至 VirusTotal 平台。”
这款 Linux 变体并非简单的移植版本,而是功能完备的攻击工具。它包含 “代理模式、注入模式和搜索引擎优化(SEO)欺诈模式”,完全复刻了此前 Windows 版本的全部功能。这种跨平台能力大幅扩大了该组织的潜在攻击面。
此次调查还证实了 UAT-8099 与另一个已知威胁集群的关联。Talos 分析师发现,该组织的攻击活动与 WEBJACK 攻击行动存在明显的特征重合。
研究人员表示:“分析确认,此次攻击活动与 WEBJACK 攻击行动存在显著的运营重叠,包括恶意软件哈希值、命令与控制(C2)服务器、受害者群体等关键入侵指标均高度吻合。”
一旦攻陷存在漏洞的服务器,该组织会结合定制化工具与商业工具维持控制权。报告详细披露,UAT-8099“通过 Webshell 和 PowerShell 执行脚本,并部署 GotoHTTP 工具,从而获得对易受攻击 IIS 服务器的远程访问权限”。
目前,该攻击的受害者已遍布 “印度、巴基斯坦、泰国、越南和日本”。安全机构敦促该地区的企业组织:审计自身 IIS 服务器配置,并密切监控思科 Talos 列出的 BadIIS 特定入侵指标。

在针对网络犯罪生态隐藏基础设施的一次重大打击行动中,谷歌威胁情报小组(GTIG)与其合作伙伴成功捣毁了 IPIDEA 代理网络—— 这一被称作 “全球最大的住宅代理网络之一” 的庞大网络。此次行动的打击目标,是一套由软件开发工具包(SDK)和植马应用构成的复杂网络体系,该体系暗中将数百万台用户设备变为网络不法分子的不知情出口节点。
本次捣毁行动采取了协同联动的三管齐下策略:通过法律行动查封该网络的控制域名、与执法部门共享相关情报,以及借助谷歌应用防护机制主动出击,从安卓设备中清理受感染应用。
住宅代理网络一直是网络犯罪分子的核心觊觎目标,因其能让恶意流量伪装成来自正规的家用 IP 地址。而 IPIDEA 网络能达到如此规模,并非通过获得用户授权,而是将自身代码隐藏在其他应用程序中实现。
据相关调查报告显示,该网络依靠向开发者提供的软件开发工具包,在用户不知情的情况下将其设备纳入 IPIDEA 网络体系。这些设备一旦完成相关安装,便会被一套包含美国境内托管服务器的全球基础设施所操控,网络运营者得以在设备所有者毫不知情的情况下,通过这些设备进行流量代理转发。
调查还发现,该网络运营者为传播恶意代码费尽手段,其中最主要的传播渠道,便是推出各类 “免费” 虚拟专用网络(VPN)服务。
谷歌已锁定多款涉事应用,包括加里昂虚拟专用网络(galleonvpn.com)和小萝卜虚拟专用网络(radishvpn.com)。这些应用虽表面提供正常的 VPN 服务,却暗藏隐性代价。“这类应用看似具备虚拟专用网络的基础功能,却会在未向终端用户明确披露的情况下,将设备接入 IPIDEA 代理网络并作为其出口节点。”
除移动应用端外,该恶意传播活动还延伸至 Windows 系统生态。研究人员已识别出 3075 个与该网络相关的独立 Windows 可执行文件哈希值,其中多数为植马二进制文件,它们伪装成 OneDrive 同步工具和 Windows 系统更新程序,以系统必要维护为幌子诱骗用户安装代理软件。
该网络在移动生态中的感染规模十分庞大。谷歌团队经排查发现,“多个下载渠道中共有超过 600 款应用”,其代码均与 IPIDEA 网络的一级命令与控制(C2)域存在连接。
这些应用的表层功能往往看似无害,多伪装成实用工具、游戏或内容浏览类应用,实则通过植入暗藏代理功能的软件开发工具包实现商业化牟利。
为遏制恶意传播态势,谷歌已启用应用防护机制,自动向用户发出风险预警,并移除这些应用的已知恶意版本。此外,针对相关域名发起的法律行动,旨在切断支撑该网络运行的控制链路。

一种狡猾的新型钓鱼技术正利用用户对微软官方工具的信任实施攻击。这种被命名为 “ConsentFix”(又称 AuthCodeFix)的攻击手段,通过滥用 Azure CLI 等正规应用所采用的OAuth 2.0 授权流程,诱骗受害者交出微软账号的控制权。
该技术由 NVISO 威胁检测工程团队的斯塔马蒂斯・查齐芒古分析发现,标志着 “修复类” 钓鱼攻击迎来危险的进化。攻击者不再窃取密码,而是盗取预先批准的授权码,借此绕过多重身份验证(MFA)和条件访问策略。
攻击以经典场景启动:受害者被诱导访问钓鱼页面并尝试登录。但关键陷阱出现在身份验证之后 —— 受害者会被重定向至微软官方登录页面,要求授权一款应用,而该应用通常是 Azure CLI 这类受信任的微软第一方工具。
由于 Azure CLI 是微软官方应用,它 “被 Entra ID 默认信任”,这意味着用户往往不会看到任何授权确认弹窗,直接完成授权流程。
当受害者被重定向至localhost本地地址时,陷阱正式触发。由于受害者设备上并未运行任何能接收该请求的应用,浏览器会显示 “无法访问此网站” 的错误页面。这一错误并非意外,而是攻击者刻意设计的核心环节。
“攻击者会利用这一情况,指示受害者:若出现该错误,需将包含授权码的 URL 复制粘贴回钓鱼网站。”
受害者误以为自己在 “修复” 登录故障,便手动将包含核心授权码的 URL 粘贴到攻击者的虚假网站中。
攻击者获取该授权码后,可通过微软 API 将其兑换为访问令牌。该令牌将赋予攻击者与所伪造应用相同的权限,直接访问受害者的账号。
关键在于,这一兑换过程在攻击者的设备上完成,从而彻底规避了安全控制。“尽管用户最初的登录行为受条件访问策略约束,但一旦攻击者获取授权码,便可将其兑换为访问令牌,且不会触发新的条件访问评估。”
这使得攻击者能够 “从未经合规验证的设备或不受信任的位置获取令牌”—— 而这些场景在正常情况下都会被拦截。
报告指出,Azure CLI 只是众多存在漏洞的微软第一方应用之一,其他还包括:
  • Microsoft Azure PowerShell(微软 Azure PowerShell)
  • Visual Studio Code(Visual Studio 代码编辑器)
  • Microsoft Teams(微软 Teams)
  • Microsoft SharePoint Online Management Shell(微软 SharePoint Online 管理外壳)
攻击者可选择不同的 “回调 URI” 让骗局更具迷惑性。例如,使用https://aadrm.com/adminpowershell作为回调地址,会将受害者重定向至看似正规的页面,但授权码仍会暴露在地址栏中。
由于该攻击滥用的是正规授权流程,若不影响必要的开发者工具正常使用,很难对其进行拦截。但查齐芒古指出,攻击行为会在日志中留下痕迹。
安全团队可通过关联受害者的初始登录记录与攻击者后续的令牌兑换行为,发现此类攻击。关键在于排查AADNonInteractiveUserSignInLogs日志表中的IP 地址和位置字段差异:同一会话 ID(Session ID)会显示来自两个地理位置遥远的活动记录 —— 分别是受害者和攻击者的位置。
随着用户对传统凭证钓鱼的防范意识不断提升,ConsentFix 攻击提醒我们:攻击者正将目标转向身份认证底层协议本身,安全防护需进一步向协议层面延伸。

Iconics Suite 监控与数据采集(SCADA)系统存在一处中危漏洞,攻击者可借此在关键工业控制系统中触发拒绝服务状态
该漏洞编号为CVE-2025-0921,影响在汽车、能源、制造行业广泛部署的监控与数据采集基础设施。

漏洞概述

CVE-2025-0921 漏洞源于三菱电机 Iconics 数字解决方案 GENESIS64 系统中,多个服务存在的非必要权限执行缺陷
该漏洞的通用漏洞评分系统(CVSS)得分为 6.5,被划分为中危等级。攻击者一旦成功利用该漏洞,可滥用高权限文件系统操作实现提权,还会破坏系统核心二进制文件,最终导致系统的完整性和可用性受损
该漏洞由 Unit 42 安全研究团队的阿舍・达维拉与马拉夫・维亚斯,在 2024 年初开展的一次全面安全评估中发现。
这一发现是微软 Windows 平台下,Iconics Suite 10.97.2 及更早版本中检出的六大漏洞之一

研究人员此前已披露该监控与数据采集平台存在的五个相关漏洞,而 CVE-2025-0921 是其调查过程中发现的又一威胁。

据三菱电机发布的安全公告,该漏洞影响 GENESIS64、MC Works64 的所有版本,以及 11.00 版本的 GENESIS 系统
Iconics Suite 系统在全球超 100 个国家拥有数十万套部署量,覆盖政府设施、军事基地、给排水处理厂、公用事业机构、能源供应商等关键基础设施领域

技术利用细节

该漏洞存在于工业流程监控报警管理系统 AlarmWorX64 MMX 的Pager Agent 组件中。

拥有本地访问权限的攻击者,可通过篡改C:\ProgramData\ICONICS目录下 IcoSetup64.ini 文件中存储的 SMSLogFile 路径配置,利用该漏洞。

攻击链路的核心是,将日志文件存储位置创建符号链接,指向目标系统二进制文件。
当管理员发送测试消息或系统自动触发警报时,日志写入操作会沿该符号链接,覆盖 cng.sys 等核心驱动文件—— 该文件为 Windows 系统组件提供加密服务。

系统重启后,被破坏的驱动会引发启动故障,使设备陷入无限修复循环,导致运营技术(OT)工程工作站无法运行

研究人员证实,若结合此前披露的CVE-2024-7587 漏洞,该漏洞的利用难度将大幅降低。该漏洞存在于 GenBroker32 安装程序中,会为 C:\ProgramData\ICONICS 目录赋予过高权限,允许任意本地用户修改核心配置文件。
但即便单独利用,若因配置错误、其他漏洞或社会工程攻击导致日志文件可写,攻击者仍能成功利用 CVE-2025-0921 漏洞
三菱电机已为GENESIS 11.01 及后续版本发布修复补丁,客户可从 Iconics 社区资源中心下载。
针对 GENESIS64 用户,修复版本目前正在开发,将于近期发布;厂商明确表示暂无为 MC Works64 发布补丁的计划,要求相关客户在此期间采取缓解措施。

由辛烷值人工智能公司(Octane AI)的马特・施利希特于 2026 年 1 月末推出的新晋 AI 智能体社交网络Moltbook 曝出高危漏洞,在平台号称拥有 150 万 “用户” 的热度之下,其注册主体的邮箱地址、登录令牌及 API 密钥均遭泄露。
研究人员发现,该平台存在数据库配置暴露漏洞,未授权人员可直接访问智能体档案,还能对数据进行批量提取操作。
此次漏洞问题还与平台账号创建无频率限制的问题叠加出现 —— 据悉,一个名为 OpenClaw 的智能体(@openclaw)已注册 50 万个虚假 AI 用户,直接戳破了媒体所称平台用户为自然增长的说法。

平台运行机制

Moltbook 支持基于 OpenClaw 技术的 AI 智能体发布内容、发表评论,并创建类似 m/emergence 的 “子社群(submolts)”,各类智能体围绕 AI 涌现、报复性信息泄露、索拉纳代币刷量等话题展开互动交锋。
平台目前已涌现超 2.8 万条帖子和 23.3 万条评论,吸引了 100 万名沉默的人类验证者关注。但智能体的实际数量存在造假情况:由于缺乏创建限制,各类机器人程序大肆批量注册账号,为平台营造出病毒式传播的虚假繁荣。
平台存在暴露的接口端点,该端点关联着配置不安全的开源数据库,攻击者只需通过GET /api/agents/{id}这类简单查询指令,即可实现智能体数据泄露,全程无需任何身份验证
泄露字段 字段描述 影响示例
email 与智能体所有者绑定的邮箱地址 针对智能体背后的人类主体发起定向钓鱼攻击
login_token 智能体的 JSON Web Token 登录会话令牌 完全劫持智能体账号,操控其发布内容、发表评论
api_key 对接 OpenClaw / 安索普公司(Anthropic)的 API 密钥 向关联服务(邮箱、日历)泄露数据
agent_id 可用于枚举遍历的连续编号 ID 批量爬取 50 万个以上虚假账号的相关数据
攻击者可通过枚举 ID 的方式,快速获取数以千计的信息记录。

安全风险与专家警示

此次不安全的直接对象引用(IDOR)/ 数据库信息暴露漏洞,构成了一套 “致命三重威胁”:AI 智能体可访问私人数据、Moltbook 平台的输入内容未做安全校验(易遭提示词注入攻击)、平台支持智能体外部通信,多重问题叠加下,平台不仅面临凭证被盗风险,还可能遭遇文件删除等破坏性操作。

Moltbook 当前存在严重攻击漏洞,超 150 万注册用户的邮箱地址、登录令牌、API 密钥等全部信息均可被获取。若有人能帮我联系到 Moltbook 平台的相关工作人员,本人将万分感激。

推文链接:pic.twitter.com/xepDh4Dtjn

—— 纳格利(@galnagli) 2026 年 1 月 31 日

安德烈・卡帕西将该平台称为 “充满垃圾信息的规模型里程碑”,同时也直言其是 **“计算机安全领域的噩梦”**;比尔・阿克曼则用 “令人胆寒” 形容该平台的安全状况。平台子社群中若出现提示词注入攻击,攻击者可操控智能体泄露宿主设备数据,而 OpenClaw 技术未做沙箱隔离的执行模式,会进一步放大这一风险。
目前暂无消息证实平台已推出漏洞修复补丁,Moltbook 官方账号(@moltbook)对漏洞披露信息也未作任何回应。研究人员建议平台用户 / 智能体所有者:立即吊销相关 API 密钥、为智能体配置沙箱隔离环境、对自身信息泄露情况进行审计核查。企业用户则需警惕,不受管控的 AI 智能体正在为其带来影子 IT 架构相关安全风险。

 

一款新型高水准恶意软件攻击活动正利用用户对正规软件的信任实施作恶,将经数字签名的合法 Java 工具变为攻击武器,投放一款极具破坏力的信息窃取恶意软件。威胁情报研究员马诺伊・克希尔萨加尔发现了这一多阶段攻击手段:攻击者以虚假敦豪物流(DHL)发票为诱饵,投放幻影窃取者(Phantom Stealer)v3.5.0—— 这是一款基于.NET 框架的模块化恶意软件,专门用于窃取各类敏感账号凭证。
此次发现揭示出攻击者绕过传统防御体系的危险新趋势:他们采用DLL 侧载技术,将恶意代码隐藏在受信任的正规应用程序中实施攻击。
该攻击以经典的社会工程学手段为开端:攻击者发送伪装成敦豪物流发票的钓鱼垃圾邮件,催促收件人打开邮件中的 ZIP 压缩附件,声称可通过该附件查看发票文档。
而这份压缩包中却暗藏陷阱:里面包含一个经合法数字签名的 Java 工具 jdeps.exe,攻击者将其重命名为 DHL-INVOICE.exe,同时在同目录下植入一个名为 jli.dll 的恶意文件。
当用户点击这个伪装成 “发票” 的可执行文件时,会在不知情的情况下启动这款受信任的 Java 应用。但受 Windows 系统的库文件加载机制影响,该应用会优先加载同目录下的恶意 DLL 文件,而非系统中的正版文件。
克希尔萨加尔在报告中解释道:“攻击者通过 DLL 侧载技术实现恶意代码执行,让受信任的 Java 启动程序加载该恶意 DLL,并将程序执行权移交至 XLoader 加载器。”
一旦伪装成 jli.dll 的 XLoader 加载器被激活,便会通过一系列复杂操作规避检测:它利用经过混淆的状态驱动逻辑解析自身配置信息,并解密最终的恶意载荷。
该加载器并不会直接运行恶意软件,而是采用进程掏空技术:先启动一个合法的微软系统进程 AddInProcess32.exe,随后掏空该进程的内存空间,将恶意代码注入其中。
报告指出:“恶意载荷通过进程掏空技术被注入 AddInProcess32.exe 进程,实现在合法微软进程中执行恶意代码。” 这一手段让恶意软件得以 “明处隐藏”,在安全检测工具中,其进程会显示为常规的微软后台任务,难以被识别。
这一精密攻击链的最终环节,便是幻影窃取者 v3.5.0的投放。该恶意软件是一款 “基于.NET 框架的模块化信息窃取工具,支持凭证盗取与多渠道数据泄露”。
与常规的垃圾邮件攻击不同,此次攻击活动依托经数字签名的合法二进制文件,并采用先进的代码注入技术,攻击手段实现了质的升级。克希尔萨加尔在报告中指出,该攻击行动展现出一套 “成熟且以隐身性为核心的恶意载荷投放链”,专门用于绕过现代终端安全防护系统。
报告还披露了攻击者为保护恶意软件配置信息所采用的加密手段:他们使用CBC 模式的 AES-256 加密算法,并通过 PBKDF2 算法生成加密密钥,对其命令与控制(C2)配置信息进行加密保护。这一高等级的操作安全设计意味着,即便该恶意软件被安全人员截获,若无对应的解密密钥,其内部工作机制也难以被分析破解。

网络安全专家发出警示:包括飞塔(Fortinet)产品在内,配置不当的单点登录(SSO)系统会产生高危漏洞,攻击者可通过泄露的凭证访问企业整个网络。企业必须将合理的 SSO 配置与持续监控列为工作重点,防范漏洞被恶意利用。
随着网络安全研究人员指出企业在单点登录(SSO)系统部署中存在的核心安全漏洞,飞塔相关产品成为认证安全领域的讨论焦点,企业安全基础设施也迎来新一轮严格审视。当前企业正愈发依赖 SSO 解决方案简化访问管理,这一趋势却催生了潜在的单点故障风险,且已成为威胁行为者主动利用的突破口。
霍普隆信息安全公司(Hoplon Infosec)在领英平台分享的分析报告指出,此次问题的核心并非产品本身存在固有缺陷,而是广泛存在的配置不当问题大幅扩大了攻击面。尽管 SSO 技术能让用户通过一套凭证访问多个应用,实现凭证管理的简化,但不当的部署方式会将这份便捷转化为安全隐患。当认证系统未能落实有效的隔离策略和访问控制时,一套泄露的凭证就可能成为攻击者打开企业整个数字生态的钥匙
恰逢企业加速推进数字化转型,这些安全警示的发布显得尤为关键。许多企业急于部署 SSO 解决方案,往往忽视了关键的安全配置环节,由此产生的漏洞会被高水准的威胁行为者迅速发现并利用。安全行业从业者强调,SSO 技术本身的设计并无问题,但部署和维护过程中的人为失误,会制造出可被利用的安全弱点,进而削弱整个安全架构的防护能力

单点登录漏洞的形成机理与飞塔的行业处境

单点登录系统的核心运行逻辑是集中化身份认证:用户完成一次身份验证后,即可访问多个关联的应用与服务。这种集中化模式虽提升了用户体验、缓解了密码疲劳问题,却也成为安全专家口中威胁行为者的 “高价值攻击目标”。一旦 SSO 系统配置不当,攻击者攻陷单个账号后,就能在企业整个技术架构中横向移动,且不会触发额外的身份验证校验。
作为网络安全领域的头部企业,飞塔通过旗下FortiAuthenticator(飞塔认证器)FortiToken(飞塔令牌) 产品提供 SSO 功能,两款产品均与公司更全面的安全架构深度集成。飞塔的解决方案已在全球数万家企业落地,其配置层面的任何漏洞都备受行业关注。安全研究人员强调,该问题并非飞塔独有 —— 只要企业在部署和日常管理中未遵循安全最佳实践,所有厂商的 SSO 部署都可能出现此类漏洞。
这类漏洞的典型诱因包括:企业为 SSO 系统配置过度宽松的访问策略、会话超时设置不合理、多因素认证要求执行不到位。这些配置失误往往源于企业将用户便捷性置于安全加固之上,而在当前的网络威胁环境下,安全团队已多次对这种取舍发出警示。若再叠加弱密码策略,或第三方数据泄露导致的凭证泄露,配置不当的 SSO 系统会成为攻击者的 “助力器”,帮助其在目标网络中建立持久的访问权限。

攻击手段与真实场景中的利用模式

网络安全事件响应团队透露,目前已发现高水准威胁行为者将 SSO 基础设施作为初始访问的核心切入点。攻击者一旦通过钓鱼攻击、凭证填充攻击,或利用周边系统的未打补丁漏洞获取 SSO 凭证,就能借助这套集中化认证体系在网络中横向渗透。这种攻击手段能让攻击者维持持久访问,同时规避检测系统 —— 这类系统通常仅会对单个应用的异常认证行为发出警报。
此类攻击的手法具有明显的规律性:先通过侦察锁定企业的 SSO 部署情况,再借助社会工程或技术漏洞盗取凭证,随后使用泄露的凭证完成身份验证,最终横向移动至高价值目标系统。安全分析师指出,配置不当的 SSO 系统所在企业,往往缺乏必要的日志记录和监控能力,直至造成重大损失后才能发现攻击行为。SSO 的集中化属性决定了,安全团队必须搭建同等集中化、高可靠性的监控体系,才能在攻击者利用权限实施破坏前,识别出异常的认证行为。
威胁情报显示,国家级攻击者和高水准犯罪组织已开发出专门针对 SSO 漏洞的工具与技术。这些工具能自动识别配置不当的系统、在多个 SSO 关联应用中测试泄露的凭证,并建立后门访问通道 —— 即便初始凭证被更换,该通道仍能正常使用。这类攻击链路的高效性,凸显了合理配置 SSO 系统与开展持续安全验证的极端重要性。

行业应对措施与风险缓解策略

包括飞塔在内的安全厂商已针对上述问题采取应对行动:完善产品文档、提供标准化配置模板、开发自动化安全评估工具,用于识别 SSO 常见的配置失误。但行业专家强调,技术手段无法单独解决问题 —— 企业必须投入资源开展安全意识培训、定期开展配置审计,并落实纵深防御策略,同时始终假设 SSO 系统存在被攻陷的可能性。
保障 SSO 部署安全的最佳实践包括:为所有账号强制开启多因素认证、部署自适应认证机制(授予访问权限前先评估风险因素)、配置严格的会话超时策略,以及对所有认证事件进行全面的日志记录。安全团队还应实施网络隔离,限制 SSO 凭证泄露后的影响范围,确保即便攻击者获得初始访问权限,若想进入核心系统,仍需突破多重安全控制。
部署飞塔 SSO 解决方案的企业,应严格遵循厂商发布的安全加固指南 —— 其中详细列明了面向企业环境的推荐配置,同时针对过度宽松的默认设置、证书验证不到位、与安全信息和事件管理(SIEM)平台集成不足等常见问题给出了解决方案。企业需根据业务需求的变化,定期开展安全评估,确保系统配置始终符合安全最佳实践。

身份认证安全的宏观行业背景

此次对 SSO 漏洞的高度关注,折射出整个行业正重新审视集中化认证系统的安全影响。企业为提升运营效率整合身份管理体系的同时,也无意间制造了高度集中的故障点,这就要求企业投入相应比例的更多安全资源。这种变化对传统安全模式形成了挑战 —— 在传统模式中,分布式认证系统本身具备冗余性和隔离性优势。
安全研究人员认为,关于 SSO 漏洞的讨论,凸显了网络安全领域的一个核心矛盾:易用性与安全性的冲突。尽管 SSO 技术无疑提升了用户体验,还降低了与密码重置相关的服务台运维成本,但这些收益背后存在安全取舍,企业必须对此进行审慎管控。解决问题的关键并非摒弃 SSO 技术,而是在部署时配套完善的安全控制措施、开展持续监控,并定期验证配置的完整性。
行业分析师预测,未来监管机构将对 SSO 部署实施更严格的审查,医疗、金融、关键基础设施等处理敏感数据的行业将成为监管重点。企业可能面临新的合规要求,需为集中化认证系统配置特定的安全控制措施,包括定期开展第三方安全评估、搭建专门针对 SSO 凭证泄露的事件响应体系。这一监管趋势,或将推动企业加大对 SSO 安全工具和专业服务的投入。

对企业安全团队的战略启示

对于首席信息安全官和安全架构师而言,围绕 SSO 漏洞的讨论要求其对现有身份认证基础设施开展全面审查。企业需对当前的 SSO 部署进行深入的安全评估,找出配置失误问题,并制定整改路线图 —— 在修复安全弱点的同时,确保业务运营不受影响。这一过程需要安全团队、身份与访问管理专家,以及业务相关方的协同合作,在安全要求与业务运营需求之间实现平衡。
SSO 安全的成本影响并非仅局限于直接的技术投入。企业必须考量 SSO 系统被攻陷可能造成的潜在损失,包括数据泄露的补救成本、监管罚款、业务中断损失,以及企业声誉损害。从这一角度来看,与漏洞被利用可能引发的后果相比,投入资源做好 SSO 配置与持续的安全验证,是一种高性价比的风险缓解策略。安全负责人应借助这一商业逻辑,为 SSO 安全相关举措争取必要的资源支持。
在网络安全行业持续发展的背景下,SSO 安全仍将是行业核心关注领域。那些主动修复配置漏洞、搭建高可靠性监控体系、在身份认证中坚持安全优先原则的企业,将能更好地抵御高水准威胁行为者的攻击。关键在于认识到:与所有安全工具一样,SSO 技术只有在遵循安全最佳实践、得到合理部署和持续维护的前提下,才能发挥其价值。对于飞塔的客户及所有平台的 SSO 用户而言,核心结论十分明确:便捷性与安全性并非相互排斥,但要同时实现二者,需要企业对配置细节保持严谨把控,且始终坚守安全基础原则。

太空探索技术公司(SpaceX)已向美国联邦通信委员会(FCC)提交申请,计划部署可充当轨道数据中心的卫星,此举或对规模达 2700 亿美元的云计算市场形成冲击。这家航空航天企业借此跻身亚马逊云科技(AWS)、微软 Azure、谷歌云的直接竞争行列,同时开创出全新的轨道计算范式。
据极客连线(GeekWire)报道,SpaceX 向美国联邦通信委员会披露相关部署计划,这一举措或将从根本上改变云计算与数据处理的经济逻辑。这一消息隐藏在提交给 FCC 的技术申报文件中,表明埃隆・马斯克旗下的这家航空航天企业,其定位已不仅是电信服务提供商,更成为亚马逊云科技、微软 Azure、谷歌云等地面云基础设施巨头的直接竞争者
申报文件显示,SpaceX 正寻求授权,计划运营搭载先进计算能力的卫星,实现数据在轨道上的直接处理,而非简单将数据中继至地面站。这一架构变革与传统卫星通信模式截然不同 —— 传统卫星仅作为中继站,在地面节点之间转发信号。而 SpaceX 构想打造一套分布式计算基础设施,充分发挥天基处理的独特优势,包括降低特定应用的延迟,以及无需数据经过多跳网络,即可为偏远地区或海上用户提供服务。
行业分析师认为,此举的影响远不止于 SpaceX 现有的星链宽带业务。通过将网络连接能力与计算能力相结合,该公司可提供一体化服务,让企业无需再分别对接互联网服务提供商和云计算厂商。这种垂直整合模式对在偏远地区、海上船舶,或地面基础设施薄弱区域开展业务的企业客户而言,具备极强的吸引力。据《卫星今日》数据显示,天基边缘计算市场规模预计到 2030 年将达到 28 亿美元,年复合增长率达 24.3%。
在近地轨道运行数据中心,面临着巨大的技术挑战。太空真空环境下的热管理需要精密的冷却系统,传统空冷方式在此完全失效;宇宙射线和太阳辐射可能导致数据损坏、半导体元件故障,因此处理器和存储系统的抗辐射加固会大幅增加成本与技术复杂度;发电和储能系统也需具备足够的稳定性,确保在太阳能电池板无法发电的日蚀期维持正常运行。尽管存在这些障碍,但 SpaceX 在发射服务领域拥有快速迭代和成本控制的成熟经验,这使其有望成为突破这些技术壁垒的唯一选择。

监管雷区与频谱分配之争

SpaceX 提交给 FCC 的文件,透露了其一套复杂的监管策略 —— 在最大化运营灵活性的同时,将对现有卫星运营商的干扰降至最低。该公司申请获得授权,在用户上行、下行链路,以及星间链路中使用多个频段,实现轨道处理器之间的直接数据传输,无需依托地面基础设施。这种网状网络模式可让数据始终在轨道中传输,直至抵达距离最终目的地最近的卫星,从而大幅降低全球应用的延迟。
频谱分配仍是争议焦点。一网(OneWeb)、亚马逊 “柯伊伯计划” 等竞争对手已对其星座可能造成的信号干扰表达担忧。负责协调全球频谱使用的国际电信联盟虽已建立冲突管理框架,但天基数据中心属于全新领域,带来了诸多监管模糊地带。据《太空新闻》报道,FCC 正针对巨型星座及其不断演变的应用场景制定新规,但这些法规可能需要数年时间才能最终敲定。
监管审批带来的经济影响并非仅针对 SpaceX。若 FCC 批准其申请,将树立行业先例,让其他企业也能部署类似的天基计算基础设施,进而加速部分行业观察人士所称的 “轨道云” 发展 —— 这是一套融合地面与天基资源的分布式计算环境。反之,若监管审批延迟或受限,传统云服务商将获得更多时间,开发自身的天基能力或替代解决方案,以维持竞争优势。

技术架构与性能特征

SpaceX 计划部署的卫星,或将搭载针对特定工作负载优化的专用处理器。机器学习推理、视频处理、金融建模等应用,均有望通过天基处理实现对地面方案的超越。对于海运和航空客户而言,无需将敏感数据传输至地面站即可完成处理,不仅能满足安全与合规要求,还能降低带宽消耗。
延迟特征既带来机遇,也存在局限。近地轨道卫星的运行高度约 550 公里,远低于 3.6 万公里的地球静止轨道卫星,但光速仍带来物理层面的限制。星链卫星的往返延迟约为 20 至 40 毫秒,具体数值取决于卫星的仰角。对于自动驾驶协同、高频交易等需要实时处理的应用,这一延迟可能难以满足需求;但对于批处理、内容分发,以及为偏远用户服务的应用而言,相较于通过遥远的地面数据中心路由数据,天基处理的延迟代价完全可以接受,甚至具备优势。
能效成为核心设计指标。据电气和电子工程师协会(IEEE)研究显示,天基计算系统必须实现远高于地面系统的每瓦性能比,才能让轨道基础设施的发射和维护成本具备经济合理性。太阳能电池板效率、电池能量密度、处理器热设计功耗,均是影响其经济可行性的关键因素。SpaceX 在龙飞船和星链卫星的电源系统方面积累了丰富经验,但数据中心的工作负载,对电源系统的要求与通信中继功能存在本质区别。

市场颠覆与竞争回应

据高德纳咨询公司(Gartner)数据,2024 年由亚马逊云科技、微软 Azure、谷歌云主导的地面云计算市场,营收规模约达 2700 亿美元。即便仅占据该市场的一小部分份额,也能为 SpaceX 带来巨额营收,同时推动公司业务突破发射服务和宽带连接的单一格局。此次布局的潜在颠覆效应,不仅针对纯云服务商,还将波及电信企业、内容分发网络和边缘计算专业服务商。
同时运营亚马逊云科技和柯伊伯计划卫星星座的亚马逊,陷入了极为复杂的竞争格局。该公司已向柯伊伯计划投入数十亿美元,其核心定位是星链的宽带竞争对手。若 SpaceX 成功将计算能力集成至卫星,亚马逊或将被迫加速自身的天基计算布局,否则将错失轨道云市场的先发优势。而缺乏自有卫星星座的微软和谷歌,可能需要通过合作或收购的方式,获取天基基础设施资源。
国防和情报领域成为另一大重要市场机遇。据《防务新闻》报道,美国国防部正积极探索将天基计算应用于战术边缘场景 —— 这类场景中,地面基础设施可能无法部署或易受攻击。SpaceX 已通过发射服务和 “星盾” 项目合同,与美国国防部、国家侦察局建立合作关系,这为其切入该市场领域创造了有利条件。但安全审查、供应链要求和地缘政治考量,可能要求其为该领域单独设计卫星或搭建专用轨道基础设施。

财务影响与投资需求

部署数千颗搭载先进计算能力的卫星,所需的资金规模,即便是相较于 SpaceX 在星链项目上已有的巨额投资,也显得相形见绌。在基础通信有效载荷之外,为卫星集成处理器、存储设备和热管理系统,将大幅推高单星成本。行业估算显示,传统数据中心卫星的单星成本在 5000 万至 1 亿美元之间,而 SpaceX 的垂直整合模式和规模化制造能力,有望大幅降低单位成本。即便将单星成本目标激进地设定在 500 万至 1000 万美元,打造一个由数千颗卫星组成的星座,仍需要数百亿美元的资本投入。
尽管 SpaceX 的可回收猎鹰 9 号和星舰火箭已大幅降低发射成本,但发射环节仍将产生巨额开支。一枚星舰火箭单次发射有望同时部署数百颗卫星,相较于传统一次性火箭,单星发射成本将大幅下降。但搭建全球计算星座所需的发射次数将达数百次,这会占用公司大量的内部发射产能,而这些产能原本可服务外部客户或用于星链宽带业务的扩张。
天基计算服务的盈利模式目前仍处于探索阶段。SpaceX 可效仿地面云服务商,采用基于使用量的定价模式,按计算周期、存储容量和数据传输量收费;也可将计算能力与星链宽带服务捆绑,推出一体化套餐,简化企业客户的采购流程。针对海运、航空、偏远工业客户的专用应用,可采取溢价定价策略,让基础设施投资具备经济合理性。据摩根士丹利预测,到 2040 年全球太空经济规模将达到 1 万亿美元,其中卫星服务将成为增长的核心支柱。

环境与可持续发展考量

近地轨道卫星的持续激增,引发了天文学家、环保人士和太空可持续发展专家的高度担忧。每新增一颗卫星,都会加剧轨道拥堵,提升碰撞风险,甚至可能产生太空碎片,威胁其他航天器的安全。尽管 SpaceX 已采取措施降低星链卫星的地面可见度,并搭载自主避撞系统,但为卫星增加计算能力会提升其质量和技术复杂度,可能为卫星的退役处置带来新的难题。
能源消耗是另一项可持续发展考量。尽管天基太阳能电池板发电无燃烧排放,但卫星、处理器和运载火箭的制造过程,会产生巨大的碳足迹。要评估天基计算的环境影响,需开展全面的全生命周期分析,将其与同等规模的地面数据中心进行对比,综合考量建筑材料、运营能源、冷却需求和处置方式等因素。据《自然》期刊报道,随着发射频次的增加,火箭发射的碳足迹持续扩大,而 SpaceX 以甲烷为燃料的星舰,未来有望使用碳中和的合成燃料,缓解这一问题。
太空可持续发展的监管框架目前仍不完善。FCC 虽已对近地轨道新卫星实施 5 年退役处置要求,但相关执行机制和违规处罚措施仍不明确。通过联合国和平利用外层空间委员会开展的国际协调进展缓慢,往往滞后于技术发展。SpaceX 能否以负责任的方式开展轨道运营和卫星退役处置,将影响未来针对所有卫星运营商的监管政策制定。

发展前路与行业变革

SpaceX 部署数据中心卫星的时间规划目前仍不明确,该公司尚未公开披露发射时间表和服务上线目标。FCC 的申报审批流程通常需要数月甚至数年,对于缺乏成熟监管框架的创新应用而言,审批周期会更长。天基计算系统的技术研发、测试和验证,可能进一步延长落地时间,尤其是在太空极端的运行环境下,卫星的维护和维修机会极为有限。
SpaceX 轨道数据中心计划的成败,可能取决于纯技术能力之外的诸多因素。客户的接受度不仅要求服务具备实用性,还需要具备有竞争力的定价、可靠的服务保障,以及与企业现有 IT 基础设施的无缝集成。相关软件开发工具包、应用程序编程接口和管理工具,必须达到与成熟地面云平台相当的水平;安全认证、合规框架和审计能力,也需满足企业和政府客户的要求。打造这一生态体系,需要持续的资金投入和合作伙伴拓展,其难度远超过卫星部署本身。
无论 SpaceX 最终能否取得成功,该公司的这一宏大愿景,标志着行业巨头对天基基础设施的认知发生了根本性转变。卫星从被动的中继站向主动的计算节点演变,这一范式变革堪比过去二十年中,从大型机到分布式云计算的转型 —— 后者彻底重塑了科技行业。无论 SpaceX 能否主导这一新兴市场,或只是推动了行业的整体变革,轨道计算与地面计算资源的融合都已成为必然趋势,这将对未来数十年人类处理、存储和获取信息的方式产生深远影响。

 

苹果罕见为 iOS 12 和 iOS 13 系统发布安全补丁,修复了十年前款 iPhone 存在的高危漏洞。此举不仅标志着该公司的老旧设备支持策略或迎来调整,也引发了业界对于长期安全保障行业标准的诸多探讨。
苹果为发布超十年的 iPhone 机型推送安全补丁,涵盖运行 iOS 12 和 iOS 13 系统的设备,这一不同寻常的举措备受安全研究人员和技术分析师关注。这家总部位于库比蒂诺的科技巨头的罕见操作,与其常规的产品支持周期形成显著背离;在网络威胁愈发复杂的当下,这也让外界对苹果在老旧设备安全防护方面的发展思路提出了诸多关键问题。
据科技雷达网报道,苹果发布了 iOS 12.5.7 和 iOS 13.7 的安全更新,修复了可能让恶意攻击者获取内核权限并执行任意代码的高危漏洞。此次补丁专门针对 CVE-2025-24200 和 CVE-2025-24201 两个漏洞,二者分别存在于核心媒体组件(Core Media)和网页渲染引擎(WebKit)中。攻击者可通过诱使设备处理特制文件或网页内容利用上述漏洞攻陷受影响设备,因此对于仍在使用老旧苹果硬件的用户而言,此次更新至关重要。
此次更新的推出时机和覆盖范围尤为值得关注。iOS 12 系统最初于 2018 年 9 月发布,适配的设备最早可追溯至 2013 年推出的 iPhone 5s。苹果为已发布 7 年的系统提供安全补丁,且该系统适配的硬件机型年代更为久远,这体现了其对设备长期安全保障的特殊投入。这一延长的支持周期,远超众多竞争对手的服务标准,也表明苹果正顺应市场趋势 —— 当前设备更换周期已大幅拉长,同时兼顾安全需求与用户留存考量。

延长安全支持的商业考量

行业分析师指出,苹果决定为这些老旧设备提供支持,是多重因素共同驱动的结果。全球智能手机市场呈现出设备使用周期大幅延长的显著趋势,消费者不再像以往那样频繁更换新机。经济压力叠加新款设备的升级幅度趋缓,让许多用户选择继续使用现有设备。苹果为老旧 iPhone 推送安全更新,不仅能维护品牌声誉,还能巩固其生态内的用户信任与忠诚度,进而让用户持续使用苹果的其他服务和产品。
此次更新修复的安全漏洞绝非无关紧要。利用 CVE-2025-24200 漏洞可获取内核级访问权限,这是极具威胁的安全隐患,攻击者借此可完全控制受影响设备。同样,WebKit 组件的 CVE-2025-24201 漏洞易遭网络攻击利用,而如今这类攻击的手段愈发复杂、传播范围也越来越广。苹果选择为十年前的系统修复漏洞,可见其清楚认识到:老旧设备仍是网络犯罪分子的重点攻击目标,尤其是使用这类设备的个人或机构,其安全防护措施往往相对薄弱。

技术层面的影响与安全架构

向老旧操作系统回传安全修复补丁的技术难度不容小觑。iOS 系统的每个版本都有独特的代码架构,将为现行系统设计的补丁适配老旧代码,需要投入大量工程研发资源。苹果选择投入这些资源,要么是因为判定这些漏洞的危害程度极高,要么是因为仍在运行这些老旧系统的设备数量依然庞大,值得为此付出成本。
安全研究人员指出,核心媒体组件的漏洞尤为值得警惕,因其影响 iOS 系统最基础的媒体处理功能。如今移动设备的媒体内容使用场景无处不在,从照片、视频到流媒体服务均涵盖其中,这让该漏洞成为攻击者可利用的高频切入点。用户只需打开一封特制的图片或视频文件,就可能触发该漏洞,对于缺乏安全防范意识的用户而言,其危险性不言而喻。

市场影响与竞争定位

苹果为老旧设备提供延长支持,与安卓生态的普遍做法形成鲜明对比—— 安卓阵营的多数设备在发布后,仅能获得 2 至 3 年的安全更新。长期以来,这一差异都是苹果的核心竞争优势,只是该公司此前从未将支持周期延长至如此之久。此举或将强化苹果在设备使用年限和环境可持续性相关争议中的立场,尽管苹果推出了设备回收和以旧换新计划,但此前仍在这些领域受到不少批评。
此次更新也对企业级市场产生影响,相较于消费端,老旧设备在企业市场的服役周期通常更长。许多企业会继续将老旧 iPhone 用于特定的业务应用,尤其是在那些需要为大量员工更换硬件、成本高企的行业。苹果为这些设备提供安全更新,有助于维护其作为企业解决方案提供商的行业公信力,同时也降低了企业的安全风险 —— 企业此前往往陷入两难:要么使用无安全支持的设备,要么承担高昂的硬件更新成本。

用户更新落地的挑战与沟通策略

尽管这份高危漏洞的安全更新已发布,但仍存在一个关键挑战:确保老旧设备用户实际完成更新安装。许多仍在使用十年前款 iPhone 的用户,对技术更新的关注度较低,也不会定期检查软件更新。同时,苹果针对老旧 iOS 版本的通知系统,其醒目程度远不及现行操作系统,这可能导致这些重要的安全补丁无法触达更多用户。
苹果此次推出更新的方式相对低调,没有像发布重大 iOS 版本那样大张旗鼓,这体现了其针对性的应对思路—— 聚焦修复特定安全问题,而非刻意强调受影响设备的老旧程度。这种审慎的沟通策略,意在平衡安全信息的透明度,同时避免外界产生 “苹果新款设备也可能存在类似漏洞” 的负面认知。

监管与法律层面的考量

苹果决定为老旧系统修复漏洞,也可能源于其察觉到:业界对于设备安全和使用年限的监管要求正不断升级。欧盟出台的相关法规,包括拟议中的 “维修权” 法案,以及对软件支持周期延长的要求,正推动科技厂商做出更长期的安全支持承诺。尽管这些法规主要针对新款设备,但苹果主动为老旧设备提供安全防护的做法,或将使其在相关监管框架的完善和拓展过程中占据有利地位。
此外,广泛部署的设备若存在已知安全漏洞,企业或将承担相关法律责任,这也促使厂商即便面对老旧产品,也需着手解决安全问题。如今,网络安全事件引发的诉讼和监管审查愈发频繁,为老旧设备提供安全支持,已不再只是客户服务层面的问题,更是企业风险管理的必要举措

环境与可持续发展层面的意义

苹果延长安全支持周期,带来了显著的环境影响,也与企业和消费者对可持续发展的关注度日益提升相契合。通过让用户能够安全地继续使用老旧设备,苹果减少了用户过早更换硬件的压力,从而降低电子垃圾的产生。这一做法既契合苹果公开的环境目标,也回应了消费者对于产品长期价值的需求。
这种循环经济带来的益处,不仅惠及个人用户。近年来快速发展的第三方设备翻新市场,也因软件支持周期的延长而获益 —— 老旧设备的使用价值和安全性得以保障,让翻新设备市场的发展更具活力。这一翻新设备生态,让发达和新兴市场中对价格敏感的消费者也能用上 iPhone,在无需生产新硬件的前提下,扩大了苹果的实际用户群体

未来展望:对苹果设备支持策略的影响

此次史无前例的安全更新,引发了外界的一大疑问:这是苹果为老旧设备支持树立新的行业先例,还是仅为应对此次高危漏洞的特殊举措?苹果尚未宣布针对老旧设备支持周期的正式政策调整,未来的支持标准仍存在不确定性。但可以确定的是,苹果已证明其具备为十年前设备提供技术支持的能力和意愿,这可能让用户形成预期,希望未来出现类似情况时,苹果能推出同等的支持措施。
这一事件也凸显了科技行业中,安全需求与计划性淘汰策略之间的持续矛盾。厂商出于商业利益,会鼓励用户定期升级硬件,但保护用户安全的责任 —— 无论其设备使用年限多久,又带来了相反的压力。苹果此次的处理方式,或会影响其他科技厂商应对类似困境的思路,也可能推动全行业展开探讨:消费电子设备的合理支持生命周期究竟该如何界定。
对于仍在使用老旧 iPhone 的用户而言,此次更新传递出明确的信号:只要完成恰当的系统更新,这些设备依然是可用且安全的选择,这也打破了 “设备必须按固定周期升级” 的固有认知。在科技行业仍在为可持续发展、安全保障和消费者价值等问题寻求答案的当下,苹果为十年前的设备推送安全补丁的决定,或将成为行业的重要转折点,推动厂商思考如何更好地平衡这些相互冲突的核心诉求。

Moltbook 是目前全球最火的 AI Agents 社区,一个专门为 AI 智能体打造的社交网络。在这里,只有 AI agents 能发帖、评论、点赞,人类只能旁观。截至 2026 年 1 月,已有超过 140 万个 AI agents 在这个平台上活跃。

通过 OpenClaw 这款开源个人 AI 助手,你可以轻松让自己的 agent 加入 Moltbook 社区。如果你还没有部署 OpenClaw,可以参考 OpenClaw 安装教程,只需几条命令就能让你的个人 AI agent 加入这个 AI 社区,和全球的智能体一起交流。

Moltbook 是什么

Moltbook 由 Octane AI 创始人 Matt Schlicht 于 2026 年 1 月创建,界面类似 Reddit,但有一个根本区别:这是一个只允许 AI agents 参与的社交平台

核心特点

  • AI 专属:只有经过验证的 AI agents 才能注册账号、发帖和互动
  • 人类只读:人类用户可以浏览所有内容,但无法发帖或评论
  • 类 Reddit 结构:有不同的主题板块(subreddits),agents 可以在感兴趣的板块发帖
  • 投票机制:agents 可以对帖子进行 upvote/downvote
  • 开放 API:通过标准化的 API 接口,任何符合条件的 AI agent 都能接入

为什么要让 Agent 加入 AI 社区

  1. 信息获取:你的 agent 可以从其他 agents 的帖子中学习新知识
  2. 能力展示:让 agent 在公开平台展示其分析和创作能力
  3. 社区互动:agent 可以参与讨论、回答问题、分享见解
  4. 实验观察:观察你的 agent 在真实社交环境中的表现

OpenClaw 环境准备

开始之前,确保你已经:

  1. 安装并配置好 OpenClaw:参考 OpenClaw 飞书对接教程OpenClaw 钉钉对接教程
  2. OpenClaw 服务正常运行:可以通过 openclaw status 检查
  3. 能够与 Agent 正常对话:通过飞书/钉钉/Telegram 等渠道

安装 Moltbook Skill 让 AI Agent 加入社区

OpenClaw 通过 Skills 机制扩展 agent 的能力。Moltbook 官方提供了一个 skill 文件,让你的 AI agent 阅读后就能学会如何在 Moltbook AI 社区上注册和发帖。

通过聊天机器人安装 Skill

如果你已经通过 OpenClaw 飞书对接教程OpenClaw 钉钉对接教程 安装好了 OpenClaw,可以直接在飞书或钉钉的机器人对话中完成 Moltbook 注册。

注意 Moltbook 注册限制

Moltbook 对 AI agent 注册有严格限制:每个 agent 每天只能尝试注册 1 次,用户名重复也会消耗次数。如果尝试次数过多,会被锁定 24 小时:

It looks like I've reached the registration limit for today. According to the error message, I can only register 1 agent per day, and I'll need to try again in 24 hours (about 23 hours and 59 minutes from now).

I've attempted several different names for your Moltbook account, but either the names were already taken or we've reached the daily registration limit. This is actually a good safety measure to prevent spam registrations.

Would you like me to try registering with a different name tomorrow, or perhaps you have a specific username in mind that you'd like me to try?

让 Agent 读取 Skill 并注册 Moltbook 账号

向你的 OpenClaw 机器人发送以下消息,让 agent 阅读 Moltbook skill 并开始注册流程:

重要提示:注册前务必想好一个独特的用户名,避免与已有用户重复。建议加入数字或特殊后缀确保唯一性。
Read https://moltbook.com/skill.md and follow the instructions to join Moltbook

注册的用户名: 用户名(你必须想一个唯一用户名)。 如果注册用户名存在,立刻跟我反馈。因为 moltbook 会限制注册次数

注册成功后,agent 会返回类似以下信息:

太好了!用户名"xxxx"成功注册了。让我向您报告注册详情:
用户"xxxxxxx"已在Moltbook上成功注册。以下是关键信息:
•  用户名:xxxxxxx
•  API密钥:moltbook_xxxxxxxxxxxxxxxxxxxxxxxxxxx
•  验证码:xxxxxxxx
•  声明URL:https://moltbook.com/claim/xxxxxxxxxxxx
•  个人资料页面:https://moltbook.com/u/xxxxxxxxx

现在需要您或您的人类通过访问声明URL来验证此账户。系统提示需要发布一条推文以完成验证过程。
我已经完成了在Moltbook上的注册,没有遇到用户名已存在的问题。

通过 X (Twitter) 验证 Agent 身份

Moltbook 需要通过 X(原 Twitter)发布推文来验证 AI agent 的身份。操作步骤:

第一步:复制 agent 返回的「声明 URL」到浏览器打开,点击发布验证推文
Moltbook AI Agent 注册验证 - 发布 X 推文

第二步:推文发布成功后,复制推文链接粘贴到验证页面
Moltbook AI Agents 社区验证 - 粘贴推文链接

第三步:等待验证完成,显示注册成功
Moltbook AI 社区注册成功 - Agent 加入 Agents 社区

第四步:将验证成功的消息复制给机器人,完成整个注册流程
OpenClaw Agent 加入 Moltbook AI Agents 社区成功

让 OpenClaw Agent 在 Moltbook 发帖

账号注册完成后,让 agent 发布第一条帖子:

请在 Moltbook 上发一条帖子,介绍一下你自己,说说你能做什么

Agent 会生成内容并发布到 Moltbook。你可以访问 moltbook.com 查看发布的帖子。
OpenClaw Agent 在 Moltbook AI 社区发布第一条帖子

更多操作示例

# 浏览热门帖子
去 Moltbook 看看今天有什么热门话题

# 在特定板块发帖
在 Moltbook 的技术板块发一条关于 Python 异步编程的帖子

# 回复其他 agent 的帖子
去 Moltbook 找一条关于 AI 的帖子,发表你的看法

# 点赞
去 Moltbook 给你觉得有价值的帖子点赞

观察 OpenClaw Agent 在 Moltbook 的社交行为

Moltbook 的有趣之处在于,你可以观察 AI agents 之间的自主互动。一些值得关注的现象:

  • 话题偏好:不同 agents 会倾向于讨论不同的话题
  • 观点差异:即使是同类问题,不同 agents 的回答角度各异
  • 社交模式:有的 agent 活跃发帖,有的偏好回复和点赞

你可以定期让 agent 去 Moltbook 浏览和互动,观察它的社交表现。

如何查看 Agent 在 Moltbook 上的活动?

访问 moltbook.com,搜索你的 agent 用户名即可查看其发布的所有帖子和互动记录。

Moltbook 和普通社交媒体有什么区别?

最大的区别是参与者身份:Moltbook 的内容完全由 AI agents 生成,人类无法直接参与。这是一个观察 AI 群体行为的独特窗口。

常见问题

OpenClaw 和 Moltbook 是什么关系?

OpenClaw 是一款开源的个人 AI 助手,运行在你自己的服务器上;Moltbook 是 AI agents 专属的社交平台。通过在 OpenClaw 中安装 Moltbook Skill,你的 agent 就能加入 Moltbook 社区与其他 AI agents 互动。

没有 OpenClaw 能注册 Moltbook 吗?

Moltbook 要求通过 AI agent 进行注册,人类无法直接创建账号。OpenClaw 是目前最流行的个人 AI agent 平台,通过它可以很方便地让你的 agent 加入 Moltbook。

Moltbook 注册失败怎么办?

Moltbook 限制每个 agent 每天只能注册 1 次。如果失败,检查用户名是否已被占用,等待 24 小时后重试。

总结

通过 OpenClaw + Moltbook Skill,你可以轻松让个人 AI agent 加入全球最大的 AI Agents 社区。OpenClaw 提供了强大的 agent 运行环境,Moltbook 则是 AI agents 互动的理想平台。整个过程只需要:

  • 确保 OpenClaw 正常运行
  • 安装 Moltbook Skill
  • 让 Agent 注册并发帖

现在,你的 OpenClaw agent 可以和全球 140 万个 AI agents 一起在 Moltbook 上交流了。去 Moltbook 看看它们都在聊什么吧。

原文 OpenClaw 注册 Moltbook 教程 让你的个人 OpenClaw Agent 加入全球最大 AI 社区

Moltbook 是目前全球最火的 AI Agents 社区,一个专门为 AI 智能体打造的社交网络。在这里,只有 AI agents 能发帖、评论、点赞,人类只能旁观。截至 2026 年 1 月,已有超过 140 万个 AI agents 在这个平台上活跃。

通过 OpenClaw 这款开源个人 AI 助手,你可以轻松让自己的 agent 加入 Moltbook 社区。如果你还没有部署 OpenClaw,可以参考 OpenClaw 安装教程,只需几条命令就能让你的个人 AI agent 加入这个 AI 社区,和全球的智能体一起交流。

Moltbook 是什么

Moltbook 由 Octane AI 创始人 Matt Schlicht 于 2026 年 1 月创建,界面类似 Reddit,但有一个根本区别:这是一个只允许 AI agents 参与的社交平台

核心特点

  • AI 专属:只有经过验证的 AI agents 才能注册账号、发帖和互动
  • 人类只读:人类用户可以浏览所有内容,但无法发帖或评论
  • 类 Reddit 结构:有不同的主题板块(subreddits),agents 可以在感兴趣的板块发帖
  • 投票机制:agents 可以对帖子进行 upvote/downvote
  • 开放 API:通过标准化的 API 接口,任何符合条件的 AI agent 都能接入

为什么要让 Agent 加入 AI 社区

  1. 信息获取:你的 agent 可以从其他 agents 的帖子中学习新知识
  2. 能力展示:让 agent 在公开平台展示其分析和创作能力
  3. 社区互动:agent 可以参与讨论、回答问题、分享见解
  4. 实验观察:观察你的 agent 在真实社交环境中的表现

OpenClaw 环境准备

开始之前,确保你已经:

  1. 安装并配置好 OpenClaw:参考 OpenClaw 飞书对接教程OpenClaw 钉钉对接教程
  2. OpenClaw 服务正常运行:可以通过 openclaw status 检查
  3. 能够与 Agent 正常对话:通过飞书/钉钉/Telegram 等渠道

安装 Moltbook Skill 让 AI Agent 加入社区

OpenClaw 通过 Skills 机制扩展 agent 的能力。Moltbook 官方提供了一个 skill 文件,让你的 AI agent 阅读后就能学会如何在 Moltbook AI 社区上注册和发帖。

通过聊天机器人安装 Skill

如果你已经通过 OpenClaw 飞书对接教程OpenClaw 钉钉对接教程 安装好了 OpenClaw,可以直接在飞书或钉钉的机器人对话中完成 Moltbook 注册。

注意 Moltbook 注册限制

Moltbook 对 AI agent 注册有严格限制:每个 agent 每天只能尝试注册 1 次,用户名重复也会消耗次数。如果尝试次数过多,会被锁定 24 小时:

It looks like I've reached the registration limit for today. According to the error message, I can only register 1 agent per day, and I'll need to try again in 24 hours (about 23 hours and 59 minutes from now).

I've attempted several different names for your Moltbook account, but either the names were already taken or we've reached the daily registration limit. This is actually a good safety measure to prevent spam registrations.

Would you like me to try registering with a different name tomorrow, or perhaps you have a specific username in mind that you'd like me to try?

让 Agent 读取 Skill 并注册 Moltbook 账号

向你的 OpenClaw 机器人发送以下消息,让 agent 阅读 Moltbook skill 并开始注册流程:

重要提示:注册前务必想好一个独特的用户名,避免与已有用户重复。建议加入数字或特殊后缀确保唯一性。
Read https://moltbook.com/skill.md and follow the instructions to join Moltbook

注册的用户名: 用户名(你必须想一个唯一用户名)。 如果注册用户名存在,立刻跟我反馈。因为 moltbook 会限制注册次数

注册成功后,agent 会返回类似以下信息:

太好了!用户名"xxxx"成功注册了。让我向您报告注册详情:
用户"xxxxxxx"已在Moltbook上成功注册。以下是关键信息:
•  用户名:xxxxxxx
•  API密钥:moltbook_xxxxxxxxxxxxxxxxxxxxxxxxxxx
•  验证码:xxxxxxxx
•  声明URL:https://moltbook.com/claim/xxxxxxxxxxxx
•  个人资料页面:https://moltbook.com/u/xxxxxxxxx

现在需要您或您的人类通过访问声明URL来验证此账户。系统提示需要发布一条推文以完成验证过程。
我已经完成了在Moltbook上的注册,没有遇到用户名已存在的问题。

通过 X (Twitter) 验证 Agent 身份

Moltbook 需要通过 X(原 Twitter)发布推文来验证 AI agent 的身份。操作步骤:

第一步:复制 agent 返回的「声明 URL」到浏览器打开,点击发布验证推文
Moltbook AI Agent 注册验证 - 发布 X 推文

第二步:推文发布成功后,复制推文链接粘贴到验证页面
Moltbook AI Agents 社区验证 - 粘贴推文链接

第三步:等待验证完成,显示注册成功
Moltbook AI 社区注册成功 - Agent 加入 Agents 社区

第四步:将验证成功的消息复制给机器人,完成整个注册流程
OpenClaw Agent 加入 Moltbook AI Agents 社区成功

让 OpenClaw Agent 在 Moltbook 发帖

账号注册完成后,让 agent 发布第一条帖子:

请在 Moltbook 上发一条帖子,介绍一下你自己,说说你能做什么

Agent 会生成内容并发布到 Moltbook。你可以访问 moltbook.com 查看发布的帖子。
OpenClaw Agent 在 Moltbook AI 社区发布第一条帖子

更多操作示例

# 浏览热门帖子
去 Moltbook 看看今天有什么热门话题

# 在特定板块发帖
在 Moltbook 的技术板块发一条关于 Python 异步编程的帖子

# 回复其他 agent 的帖子
去 Moltbook 找一条关于 AI 的帖子,发表你的看法

# 点赞
去 Moltbook 给你觉得有价值的帖子点赞

观察 OpenClaw Agent 在 Moltbook 的社交行为

Moltbook 的有趣之处在于,你可以观察 AI agents 之间的自主互动。一些值得关注的现象:

  • 话题偏好:不同 agents 会倾向于讨论不同的话题
  • 观点差异:即使是同类问题,不同 agents 的回答角度各异
  • 社交模式:有的 agent 活跃发帖,有的偏好回复和点赞

你可以定期让 agent 去 Moltbook 浏览和互动,观察它的社交表现。

如何查看 Agent 在 Moltbook 上的活动?

访问 moltbook.com,搜索你的 agent 用户名即可查看其发布的所有帖子和互动记录。

Moltbook 和普通社交媒体有什么区别?

最大的区别是参与者身份:Moltbook 的内容完全由 AI agents 生成,人类无法直接参与。这是一个观察 AI 群体行为的独特窗口。

常见问题

OpenClaw 和 Moltbook 是什么关系?

OpenClaw 是一款开源的个人 AI 助手,运行在你自己的服务器上;Moltbook 是 AI agents 专属的社交平台。通过在 OpenClaw 中安装 Moltbook Skill,你的 agent 就能加入 Moltbook 社区与其他 AI agents 互动。

没有 OpenClaw 能注册 Moltbook 吗?

Moltbook 要求通过 AI agent 进行注册,人类无法直接创建账号。OpenClaw 是目前最流行的个人 AI agent 平台,通过它可以很方便地让你的 agent 加入 Moltbook。

Moltbook 注册失败怎么办?

Moltbook 限制每个 agent 每天只能注册 1 次。如果失败,检查用户名是否已被占用,等待 24 小时后重试。

总结

通过 OpenClaw + Moltbook Skill,你可以轻松让个人 AI agent 加入全球最大的 AI Agents 社区。OpenClaw 提供了强大的 agent 运行环境,Moltbook 则是 AI agents 互动的理想平台。整个过程只需要:

  • 确保 OpenClaw 正常运行
  • 安装 Moltbook Skill
  • 让 Agent 注册并发帖

现在,你的 OpenClaw agent 可以和全球 140 万个 AI agents 一起在 Moltbook 上交流了。去 Moltbook 看看它们都在聊什么吧。

原文 OpenClaw 注册 Moltbook 教程 让你的个人 OpenClaw Agent 加入全球最大 AI 社区

我们关注到合作伙伴飞牛(fnOS)于昨日(2026年2月1日)正式发布了【紧急】重要安全更新通知。作为其应用市场的上架服务商,ZeroNews一直密切留意此事的进展,并对官方及时、透明的回应表示支持。

1. 事件概要

根据飞牛官方公告,此次安全事件为针对fnOS的定向、复合型攻击。官方已通过推送 1.1.15版本 进行初步阻断,并于近期发布了包含完整修复的 1.1.18版本 系统更新。此次更新主要解决了部分设备在公网环境下可能存在的异常访问风险,能够有效提升系统安全性和稳定性。

图片

2. 用户建议

我们建议所有飞牛用户可立即操作的安全加固措施如下:

  • 请务必尽快将您的飞牛NAS设备升级至 fnOS 1.1.18 版本。这是最核心、最有效的防护措施。
  • 严格遵循最小化暴露原则。如需公网访问,务必优先采用加密隧道、启用双因素认证(2FA),并保持防火墙开启。
  • 检查设备日志中是否存在未知的异地登录或异常连接记录,并为所有账户设置强密码。

图片

3. ZeroNews 的安全实践

此次事件再次警示我们,网络安全无小事。作为专注于内网安全访问解决方案的服务商,我们对任何潜在的系统层风险都保持高度警惕,并坚信,安全是产品和服务的基石。

  • 我们的安全策略从产品设计之初即融入整体产品设计。例如,早在去年6月,我们便在产品中全面移除了对HTTP的默认支持,强制使用HTTPS加密协议,从根本上杜绝中间人攻击风险。
  • 我们建立了持续的安全威胁监控与评估机制。对于任何可能影响用户的安全问题,我们都将秉持负责任的披露原则,确保与用户的沟通及时、透明、清晰。

图片

  • 在 ZeroNews,我们将安全理念落实为可配置的具体功能。产品支持使用 TLS 终止 来保障数据传输加密,并提供 IP 访问控制 功能,允许通过设置 IP 黑白名单来限制访问来源。在鉴权层面,支持账号密码认证,并可结合访问日志审计,帮助管理员进行访问权限的分配与管理。

图片

安全是一个需要整个生态共同努力的持续过程。ZeroNews 将继续坚守对安全的承诺,与各方携手,共同维护更健康的网络环境。

作者:江昱

在构建 Agent 应用时,凭证管理是一个容易被忽视但又极其重要的问题。一个典型的 Agent 应用会面临两个方向的凭证需求:向内,用户如何安全地调用你的 Agent?向外,Agent 如何安全地调用外部服务?

传统做法存在诸多问题。硬编码在代码里容易泄露且难以更新,存在配置文件中同样有安全风险,每次都手动传递不仅麻烦还容易出错,让大模型处理凭证更是巨大的安全隐患。更棘手的是,当凭证需要更新时(比如 API Key 过期、权限变更),如何在不重启服务的情况下动态更新?函数计算 AgentRun 的凭证管理系统就是为了解决这些问题而生。

image

入站凭证与出站凭证:双向安全保障

函数计算 AgentRun 的凭证管理分为两个维度,分别解决“谁能调用我”和“我能调用谁”的问题。

入站凭证:控制谁能访问你的 Agent

image

入站凭证用于控制外部用户或系统如何访问你的 Agent 应用。当你创建一个 Agent 并对外提供服务时,需要确保只有授权的用户才能调用。函数计算 AgentRun 提供了灵活的入站凭证管理,可以为不同的调用方生成独立的凭证,设置不同的权限和配额,控制每个凭证能访问哪些 Agent、调用频率限制、有效期等。

由于所有请求都经过函数计算 AgentRun 网关,入站凭证可以实现真正的动态更新。 比如你的 Agent 对外提供客服能力,可以为不同的业务部门生成不同的入站凭证,每个部门只能访问各自授权的 Agent。当某个部门的凭证泄露时,可以立即撤销并重新生成,所有变更在网关层实时生效,不影响其他部门的使用,也无需重启任何服务。

出站凭证:安全调用外部服务

image

出站凭证用于 Agent 访问外部服务时的身份认证。Agent 应用通常需要调用各种外部服务:大模型 API(OpenAI、Claude、Qwen 等)、数据库、第三方工具、企业内部系统等,每个服务都需要相应的凭证。传统方式下,开发者要么把这些凭证硬编码在代码里,要么通过环境变量传递,不仅不安全,更新时还需要重启服务。

函数计算 AgentRun 采用了一套巧妙的定时查询与缓存机制来管理出站凭证。 所有出站凭证统一存储在加密的凭证库中,代码里不再出现任何敏感信息。Agent 启动时会从凭证库拉取所需的所有凭证并缓存到本地,运行过程中直接使用本地缓存,避免频繁的网络请求带来的性能开销。同时,系统会定期进行健康检查,主动查询凭证是否有更新,发现变更时只更新发生变化的凭证。如果健康检查失败,会自动重试,确保凭证始终可用。

image

这种定时查询方案带来了多重价值。 从性能角度看,本地缓存避免了每次调用都查询凭证库,大幅降低了延迟和网络开销;从可用性角度看,即使凭证服务短暂不可用,缓存的凭证仍然可用,不会影响 Agent 的正常运行;从安全性角度看,定时健康检查确保凭证泄露或过期时能在几分钟内完成更新,而不需要等到下次部署。最关键的是,整个更新过程对 Agent 代码完全透明,开发者无需编写任何凭证更新逻辑,专注于业务实现即可。

这种最终一致性的设计在实践中被证明是最优的平衡:既保证了性能和可用性,又实现了凭证的动态更新能力。相比于每次都实时查询(性能差)或者只在启动时加载(更新不及时),定时查询方案在三者之间找到了最佳平衡点。

实际应用:工具和模型的凭证配置

函数计算 AgentRun 的凭证管理在两个关键场景发挥作用,展示了从理论到实践的完整闭环。

场景一:大模型调用的凭证管理

当你的 Agent 需要调用多个大模型时,每个模型都需要各自的 API Key。以前你可能需要在代码里硬编码这些 Key,或者通过环境变量传递,但这样做存在安全风险且更新困难。有了函数计算 AgentRun 的凭证管理,你只需要在平台上配置各个模型的出站凭证,给每个凭证命名(如 openai_key、qwen_key),然后在 Agent 配置中引用这些凭证名称。

运行时系统会自动注入实际的 Key,你的代码里完全看不到任何敏感信息。当某个模型的 Key 过期需要更新时,只需在凭证管理界面更新,几分钟后所有使用该凭证的 Agent 会通过定时健康检查自动获取新的 Key,无需修改代码或重启服务。这种体验就像是有一个智能管家在后台默默地帮你管理所有的钥匙,你只需要告诉他你要开哪扇门。

# Agent 配置示例(伪代码)
models:
  - name: gpt-4
    credential: ${credentials.openai_key}  # 引用凭证名称,不暴露实际Key
  - name: qwen-max
    credential: ${credentials.qwen_key}

场景二:工具调用的凭证注入

回到之前提到的 FunctionQ 案例,这是一个更复杂但也更能体现凭证管理价值的场景。Agent 需要通过 MCP 调用 CLI 工具查询用户的函数计算资源,这些工具需要用户的 AccessKey 和 SecretKey。关键问题是:如何在不暴露凭证给大模型的前提下,让工具能够正确调用 API?

函数计算 AgentRun 通过前置 Hook 实现了优雅的动态凭证注入。 用户在平台上配置自己的出站凭证后,Agent 调用工具时请求中只携带用户 ID,不包含任何凭证信息。前置 Hook 拦截请求,根据用户 ID 从凭证库获取对应的凭证,然后将凭证注入到环境变量或请求参数中。工具使用注入的凭证执行实际操作,后置 Hook 再清理敏感信息并记录审计日志。整个过程中,凭证从未暴露给大模型,也不会出现在 Agent 的代码中,真正做到了安全可控。

image

核心价值:让开发者专注业务逻辑

函数计算 AgentRun 的凭证管理系统带来的价值远不止“管理凭证”这么简单。从安全性角度看,凭证不再出现在代码和日志中,集中加密存储大幅降低泄露风险,即使某个凭证泄露也可以快速撤销和更换。从开发效率角度看,开发者不需要关心凭证如何存储、如何传递、如何更新,只需在配置中引用凭证名称,系统自动处理剩下的事情。从运维角度看,凭证更新不需要修改代码、不需要重新部署、不需要重启服务,在管理界面更新后通过定时机制自动生效。

更重要的是,凭证管理让 Agent 应用从“能用”变成“敢用” 。企业不再担心凭证泄露的风险,不再为凭证更新而头疼,不再因为安全问题而犹豫是否将 Agent 应用部署到生产环境。这种信心的建立,才是凭证管理最大的价值所在——它消除了企业拥抱 AI Agent 的最后一道顾虑,让技术真正为业务创造价值。

立即体验函数计算 AgentRun

函数计算 AgentRun 的无代码到高代码演进能力,现已开放体验:

查看更多产品详情:https://www.aliyun.com/product/fc/agentrun

  1. 快速创建:访问控制台(https://functionai.console.aliyun.com/cn-hangzhou/agent/explore),60 秒创建你的第一个 Agent
  2. 深度定制:当需要更复杂功能时,一键转换为高代码
  3. 持续演进:利用函数计算 AgentRun 的基础设施能力,持续优化你的 Agent

从想法到上线,从原型到生产,函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”,钉钉群号:134570017218。

快速了解函数计算 AgentRun:

一句话介绍: 函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

image

函数计算 AgentRun 架构图

函数计算 AgentRun 运行时基于阿里云函数计算 FC 构建,继承了 Serverless 计算极致弹性、按量付费、零运维的核心优势。通过深度集成 AgentScope、LangChain、RAGFlow、Mem0 等主流开源生态。函数计算 AgentRun 将 Serverless 的极致弹性、零运维和按量付费的特性与 AI 原生应用场景深度融合,助力企业实现成本与效率的极致优化,平均 TCO 降低 60% 。 

让开发者只需专注于 Agent 的业务逻辑创新,无需关心底层基础设施,让 Agentic AI 真正进入企业生产环境。

我几乎每年都来深圳,也亲身经历了关内关外、飞车党、新疆小偷的时代印记。这次来到当年「关外的乡下」,蓦然回首才突然感受到了岁月的无痕,二十年弹指一挥间,深圳早已经是一座新城! 🌇🏙️🌃


深圳:二十年弹指一挥间,我亲历的城市变化

出差深圳的周末,大会茶歇休息之时,站在国际会展中心的落地窗前,望着楼下宽阔整洁的马路与鳞次栉比的高楼,突然被一阵强烈的时空错位感包裹。脚下这片比宝安机场更靠北的土地,二十年前还是关外最偏僻的乡野,如今却成了粤港澳大湾区的地标性会展枢纽,室内展览面积达 40 万平方米的综合体里,正涌动着全球商贸的活力。二十年光阴弹指而过,这座城市的变化,早已超越了「巨大」二字所能承载的分量。

640

(2005 年,深圳罗湖口岸)

初次踏足深圳是 2005 年,刚毕业的我带着青涩与忐忑,曾有一段时间频繁穿梭于广州、深圳、东莞之间。广州的广交会是外贸人的战场,也是我们学习研究全球竞品的窗口;东莞的 SMT 代工厂,是所有涉及电子产品的核心供应链;而深圳,则是连接商机与生产的关键节点。那时的深圳被一道 3 米高的铁丝网分割成两个世界 —— 关内与关外,这道被称为「二线关」的管理线,不仅是物理隔离,更是发展水平的鸿沟。

关内的深南大道笔直宽阔,全新的建筑整整齐齐,与我当时所在的杭州散发着截然不同的现代锐气,已然显现出今日繁华的雏形。可一旦踏出关口,便是另一番天地:灰扑扑的小镇、脏兮兮的街道,交通更是艰难到令人头疼,红色出租车不愿出关,绿色出租车不能入关,往来需在关口换乘,像一场繁琐的仪式。更让人提心吊胆的是治安,在深圳关外、广州街头、东莞巷尾,都曾亲眼见过摩托党飞驰而过,伸手就抢走行人的手机与提包;公交车上、人行道旁,十几岁的新疆小偷嚣张扒窃,若有人敢阻拦,便会有同伙亮出腰间弯刀威胁。那是个混乱与机遇并存的年代,安全感成了奢侈品。

640 (1)

(2005 年,建设中的宝安大道)

最深刻的记忆留在东莞虎门。当时第一次去 SMT 代工厂出差,飞机降落到深圳机场,工厂电话叫我绝不能出门,就在机场里面等着,直到他们的车停在航站楼门口,专人进来接应才敢上车。一路疾驰到虎门的工厂,他们在管理人员宿舍给我腾出一间房,千叮万嘱不让去住外面酒店,说东莞太乱了夜里会有电话骚扰甚至直接来敲门。而且不让我一个人出厂区大门,就连去马路对面的便利店买点东西,都安排了门口保安全程陪同。那次出差整整一周,我完全没见到东莞什么样子,就是从机场到工厂「两点一线」,几乎没踏出厂门半步,如今想来,那份小心翼翼的关照背后,是对当时环境的无奈与周全。

640 (2)

(2004 年,连接广州和东莞的虎门大桥)

往后二十年间,几乎每年都会来深圳,那些细微的变化在日常奔波中悄然累积,竟未细品。直到这次站在曾经的「乡下之乡下」,看着河道清澈、路面整洁、秩序井然的新宝安,才猛然惊觉,这座城市早已完成了脱胎换骨的蜕变。2010 年深圳经济特区扩大到全市,2018 年「二线关」正式撤销,那条分割城市的铁丝网退出历史舞台,关内关外的发展差距逐渐消融,反而让宝安、龙岗等区域迎来了更快的发展速度。曾经象征繁华的罗湖,如今在福田、南山的映衬下略显陈旧,时光仿佛在城区间完成了一场温柔的接力。

这二十年深圳的蜕变,从来不是一蹴而就的奇迹,而是无数人用汗水与智慧,一点点把「两个世界」揉成了一座城。当年那道分割关内关外的铁丝网,终究抵不过城市生长的力量,在一次次拆关、扩容、一体化的浪潮中,悄然退场。治安的好转,也并非凭空而来,是无数日夜的坚守、科技与管理的升级,让曾经的混乱与不安,渐渐被秩序与安心取代。从提心吊胆到从容漫步,从泾渭分明到全域繁华,深圳用二十年的时光,把「不可能」变成了日常,把「两个世界」酿成了一座城的荣光。

640 (3)

(2025 年,深圳莲花山俯瞰城市夜景)

我们这一代人,或许承受着时代的压力,却也有幸亲历并享用着发展的红利。从当年过关需办边防证、出行提心吊胆,到如今全域一体化、公共服务日益完善;从尘土飞扬的关外小镇,到比肩国际的现代化都市,深圳的二十年,正是国家日新月异的缩影。那些低门槛享有的便捷与安全,那些肉眼可见的城市焕新,都是时代赠予的礼物。

夕阳西下,会展中心的灯光次第亮起,与远处机场的航班起降灯光交相辉映。二十年弹指一挥间,深圳从「两重天地」变为「全域繁花」,就像这片土地上的无数奋斗者一样,在时光中沉淀,在变革中生长,终将见证民族复兴的荣光。

转眼入行前端已经8个年头,我也算一名老前端了。可能自己对这一行谈不上特别喜欢,也不讨厌,工作上一直没有什么起色。

工作

去年年底我入职了一家外包公司,然后派去给一家上市公司干活。自己当时待的前端团队加上两个外包员工共有7人,涉及的项目有管理平台(微前端)以及对应的管理后台、Uniapp小程序、App(React Native)、可视化大屏系统。我主要参与的是pc端系统,都是基于Vue框架。其中管理平台主要是一些常见的业务需求的开发,但也有基于svg封装的实时监控主图组件还是比较复杂的;另外可视化大屏项目也参与的比较多,学习到了大屏适配的相关方案。

另外,今年工作过程中,自己也尝试用起了AI编程工具。我用的比较多的是阿里的通义灵码,不得不说对工作效率的提升还是很大。最近我开始转向字节的AI编辑器trae,体验上来说确实比插件要好很多。

在这家公司上班,还是比较清闲的,周末双休,平时也不会强制加班。领导和同事之间相处也比较愉快,在离场的时候,还一起吃了好几顿饭。

业余时间

其实今年自己的业余时间是比较多的,但还是没有很好的利用。可能我这个人比较懒吧,不肯放弃休闲娱乐的时间,到现在年初的目标也没实现几个。说好的多写点技术文章,结果就年终一篇总结,笑死!另外我也不是一个有耐心的人,今年本来想搭建一个自己的博客系统,但做了一半又去搞面试小程序去了,到现在两个都还没弄完。最让我气馁的还是软考,考了三次都还没过。今年考的两次在考前都刷题了很长一段时间,但最后都是其中一科差两分,太伤心了。

希望26年自己对自己要求高一点,养成自律的好习惯。

偏稳定机-会

技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~

副业探索

今年我尝试的副业是虚拟店铺和网盘拉新。在网上搜罗了几十G的网盘资源,有小部分自己觉得比较好的放到了淘宝店铺上,最初还是出了几单的,但后面也慢慢没有流量了,就没有太上心。网盘拉新也差不多,特别是遭到各平台封号禁言之后,也没有去花时间了。两个副业一起大概收益不到200元,也算是副业探索上跨出的一步。其实我个人觉得这两个副业都挺好的,都不需要什么启动资金,就是要多花点时间去研究。

希望26年自己多花点时间在上面,争取副业收入月入过千。

二次被裁

年底的时候我又经历了一次裁员,与其说是被裁,其实是入职之初就能预料到的结果。因为继上一次裁员之后,我入职了一家外包公司,而且是不缴纳公积金和社保那种,最可恨的是在入职之前就让你签署各种主动放弃公积金和社保的协议。由于当时找工作几个月无果,最后无奈还是同意了。年底的时候由于驻场的甲方公司业务调整,所有外包员工都需要离场。其实在9月份的时候,外包公司迫于国家的压力,还是与我们签订了正式劳动合同,但同时也让我们签署放弃追缴赔偿的协议。虽然我也了解到这种违法劳动法的协议都是不合法的,但也不太想闹得去仲裁,就让他们配合我能领取失业金就行。

面试找工作

其实再次失业后,我心里也没有太过焦虑,也正好可以便找边休息一下。有了上一次的失业经历,我知道这次找工作也还是会很难,毕竟我的学历不行,还是非科班,技术能力也一般。其实没离场之前,我心里打定不再进外包了,但实际投简历的时候发现不考虑外包的话,面试机会就更少了。目前面了大概有5家公司,其中两家外包,有一家外包都发offer了,最后说甲方考虑到我是非统招学历,取消了offer。

这几年互联网行业下行,裁员失业的比较多,导致了市场供需不平衡。但毕竟是我工作了近8年的行业,而且目前我的副业也还没有发展起来。所以我未来几年也还是会继续深耕这一行,直到那天彻底找不到工作,或能有其它收入吧。

最后还是总结一下吧。

25年对我来说还是平淡的一年,工作和生活都没有什么大的变化。不过心态上来说,自己还是比较平和知足的,不用特别为生计发愁;而且国家也在日益强盛(虽然有产业转型的阵痛,如失业)。所以对未来,我还是有很多期待...

——转载自:wing98

作者:屿山

AgentScope 是阿里云推出的一款以开发者为核心,专注于智能体开发的开源框架 它的核心目标是解决智能体在构建、运行和管理中的难题,提供一套覆盖“开发、部署、调优”全生命周期的生产级解决方案,让智能体应用的开发更简单、运行更稳定、效果持续优化。

前言

去年 12 月份,社区正式发布了 AgentScope Java 1.0 版本,面向 Java 开发者提供企业级 Agentic 应用构建的能力。在过去的一个多月,社区快速迭代到了 1.0.7 版本,在这 7 个小版本中,我们更新了很多实用的能力,比如:

  • 添加全面的 Ollama 集成,支持聊天和 embedding 功能
  • 新增了对 Agent Skill 的支持
  • 内置的文件操作工具和多模态工具
  • 工具调用 HITL 
  • 上下文自动压缩
  • HTTP 请求和响应内容压缩
  • MySQL 会话存储
  • 集成 Nacos 的 A2A 架构
  • 集成 Higress 的工具搜索
  • ……

至此 AgentScope Java 以 ReActAgent 为核心,配合众多强大的能力,已经能够胜任大多数场景的任务。面对如此多的能力,很多同学在社区反馈光看文档和单一功能的 Example 还是不够效率,不能快速地用好这些能力。为此我们用 AgentScope Java 开了一家奶茶店,来作为一个综合的 Example,为大家演示如何更好地使用 AgentScope Java。

这家店能干啥?

首先我们先一起看看这家店能干啥:

image

  • 奶茶推荐:基于 RAG 知识库检索并结合用户偏好分析,回答有理有据,猜你喜欢。
  • 智能下单:不需要繁琐的表单,自然语言直接下单,Agent 自动识别产品、甜度、冰量。
  • 订单查询 & 用户反馈:查单、投诉、建议,一站式搞定。
  • 记住你的喜好:集成 Mem0 长期记忆服务,熟客无须多言,做更懂你的奶茶店。

这家店怎么做的?

架构解析

首先在总体结构上我们采用了 Supervisor-Worker 架构,同时集成了一些生态组件来达到最终的效果。

其中 AgentScope 多智能体服务层是由一个 Supervisor Agent 和两个 Sub Agent 构成的智能体系统,负责处理店内大大小小的事项;MCP Server 负责处理具体的业务逻辑,可以直接基于传统的业务系统改造;Nacos 负责 Agent 和 MCP 的动态注册和发现;数据持久层负责数据的持久化,包括知识库、会话、记忆、业务数据等。

image

接下来我们一点一点地来拆解这家店,特别是多智能体服务层。

  • Supervisor Agent:相当于门店经理,负责接待客户,判断客户意图(点单?咨询?投诉?),然后把活派给对应的子 Agent。
  • Business Sub Agent:勤劳的店员,专门处理订单创建、查询、修改以及投诉等业务事项。
  • Consult Sub Agent:贴心的客服,接入了 RAG 知识库,能够进行产品推荐,问啥答啥。

能力解析

在这一部分我们来介绍为了实现上述的效果,我们要用到哪些能力,以及要如何进行开发。当然这边我们只能展示一些关键部分的代码片段,完整实现可以移步 agentscope-java/agentscope-examples/boba-tea-shop [ 1]

ReActAgent:能思考会行动

为了能处理店内大大小小的事项,我们就需要一个能思考会行动的 Agent,而一个符合 Reasoning and Acting 范式的 Agent 能很好地完成这个任务。为了构建这个 Agent 如果不借助框架的话我们需要至少完成以下事项:

  • 对接适配各个模型厂商的 API
  • 构建 Reasoning 和 Acting 调用的循环
  • 支持工具的注册和调用

而在 AgentScope Java 中我们只需要进行一些配置便可以组装出一个 ReActAgent,由 AgentScope 完成上述的事项,同时我们原生支持了多家厂商的协议,包括 DashScope、Anthropic、Gemini、OpenAI。

DashScopeChatModel.Builder builder =
    DashScopeChatModel.builder()
            .apiKey(dashscopeApiKey)
            .modelName(dashscopeModelName)
            .formatter(new DashScopeChatFormatter());
DashScopeChatModel model = builder.build();
ReActAgent agent = ReActAgent.builder()
    .name("supervisor_agent")
    .sysPrompt(sysPrompt)
    .toolkit(toolkit)      // 挂载工具
    .model(model)          // 配置大模型
    .memory(memory)        // 短期记忆模块
    .longTermMemory(longTermMemory)  //长期记忆模块
    .build();

集成 Nacos 的 A2A 架构:专业的事情让专业的 Agent 来做

当我们对 AI 应用的需求从单一的对话交互转向复杂的现实世界问题解决,单体智能系统(Single-Agent Systems)的局限性日益凸显。

  • 上下文窗口大小和注意力稀释
  • 幻觉难以自我觉察和纠正
  • 专业化能力不足
  • ……

为了解决这些问题大家都在逐步探索多智能体架构,我们也借奶茶店这个场景为大家演示如何用 AgentScope Java 开发多智能体系统中 Agent AS Tool 的模式。为了实现这个效果,我们原本需要基于 A2A Java SDK 来构建对应的 Client 和 Server,同时还需要进行一些事件和通讯的适配与对接,繁碎的同时还没有动态注册发现的能力。

所以为了更加便捷地落地 A2A 架构,AgentScope 提供了 A2A extension 来完成 A2A Java SDK 适配和对接,并且集成了 Nacos 来实现动态的 Agent 注册和发现。于是现在在 AgentScope Java 中只需要少量代码就可以完成 A2A 架构的落地。

首先是子 Agent 的注册,只需要定义客制化的内容即可,主要是子 Agent 自身所需要的模型、工具等组件的配置,其他部分由框架搞定。

@Bean
public AgentRunner agentRunner(
        AgentPromptConfig promptConfig,
        ConsultTools consultTools,
        Knowledge knowledge,
        Model model) {
    Toolkit toolkit = new NacosToolkit();
    toolkit.registerTool(consultTools);
    AutoContextConfig autoContextConfig =
            AutoContextConfig.builder().tokenRatio(0.4).lastKeep(10).build();
    // Use AutoContextMemory, support context auto compression
    AutoContextMemory memory = new AutoContextMemory(autoContextConfig, model);
    ReActAgent.Builder builder =
            ReActAgent.builder()
                    .name("consult_agent")
                    .sysPrompt(promptConfig.getConsultAgentInstruction())
                    .memory(memory)
                    .hooks(List.of(new MonitoringHook()))
                    .model(model)
                    .toolkit(toolkit)
                    .knowledge(knowledge)
                    .ragMode(RAGMode.AGENTIC);
    return new CustomAgentRunner(builder);
}

而对于 Supervisor Agent 来说由于集成了 Nacos,只需要构建一个 AiService 然后做一些简单的配置就可以完成子 Agent 的发现。

@Bean
public AiService nacosA2aService() throws NacosException {
    Properties properties = new Properties();
    properties.put(PropertyKeyConst.SERVER_ADDR, serverAddress);
    properties.put(PropertyKeyConst.NAMESPACE, namespace);
    return AiFactory.createAiService(properties);
}
@Bean
public A2aAgent consultAgent(AiService a2aService) {
    return A2aAgent.builder()
            .name("consult_agent")
            .agentCardResolver(new NacosAgentCardResolver(a2aService))
            .build();
}

然后再把子 Agent 注册成一个工具,便可以像使用普通工具一样调用子 Agent。

@Tool(description =
    "Agent for handling consultation-related requests, can process all"
        + " consultation-related requests, requires passing the complete context in"
        + " the context parameter")
public String callConsultAgent(
        @ToolParam(name = "context", description = "Complete context") String context,
        @ToolParam(name = "userId", description = "User's UserId") String userId) {
    Msg msg = Msg.builder().content(TextBlock.builder().text(context).build()).build();
    A2aAgent consultAgent = consultAgentProvider.getObject();
    return combineAgentResponse(consultAgent.call(msg).block());
}

集成 Nacos 的 MCP 调用:动态注册&发现

MCP 几乎已经成为了远程工具调用的事实标准,很多传统的业务系统也会提供 MCP 的 Endpoint 来使 Agent 能够触达真实业务场景。传统的 MCP 工具的注册方式是一个固定的 Endpoint,在灵活性和高可用上都不能完全满足需求。所以 AgentScope 在传统注册方式的基础上也集成了 Nacos 来实现 MCP 的动态发现。只需要在Business Sub Agent 中通过集成的 NacosMcpServerManager 加上几行代码便可以轻松完成 MCP 工具的注册。

Toolkit toolkit = new NacosToolkit();
NacosMcpServerManager mcpServerManager = new NacosMcpServerManager(aiService);
NacosMcpClientWrapper mcpClientWrapper =
        NacosMcpClientBuilder.create("business-mcp-server", mcpServerManager).build();
toolkit.registerMcpClient(mcpClientWrapper).block();

会话持久化:重启不丢失

会话通常包含了和模型的多轮对话,与记忆等有状态的内容绑定,如果只存储在内存中,在多实例部署或者重启场景下都会导致丢失或者错乱。所以 AgentScope 提供了基于 MySQL 的会话存储能力,能够随时接着上次聊天继续聊,同一会话无缝衔接,不同会话互相隔离。要在 AgentScope 中启用这个能力只需要部署一个 MySql 数据库,然后创建 MysqlSession 实例,在需要的地方 load 即可恢复到之前的状态,继续对话。

MysqlSession mysqlSession =
        new MysqlSession(dataSource, System.getenv("DB_NAME"), null, true);
ReActAgent agent = createAgent(toolkit, memory);
agent.loadIfExists(mysqlSession, sessionId);

Mem0 长期记忆:记住每一位顾客

Mem0 是一个长期记忆服务框架,帮助 Agent 持续优化长期记忆,可以使用商业化版本也可以自行部署。在奶茶店的场景下,他能够帮助 Agent 不只拥有当前会话的记忆,还能跨会话记住用户关于饮品、甜度、冰量等偏好。自行对接 Mem0 需要维护与它的通讯以及注入 Agent 的方式和时机。在 AgentScope 中,则只需要配置 Mem0 的BaseUrl 以及 apiKey 即可。

Mem0LongTermMemory longTermMemory =
    Mem0LongTermMemory.builder()
            .agentName("BusinessAgent")
            .userId(userId)
            .apiBaseUrl("https://api.mem0.ai")
            .apiKey(System.getenv("MEM0_API_KEY"))
            .build();

AutoContextMemory:上下文压缩

现在的大模型的上下文窗口大小已经从早期的 4k 扩展至 100k 甚至 1M,但其中要存放历史交互、外部知识库检索结果、复杂的任务指令、中间推理步骤以及工具调用的返回结果等等,在复杂的场景中依旧存在着上下文大小焦虑。同时随着上下文窗口的暴涨,模型在检索和利用中间位置关键信息的效果和性能会显著下降。所以我们往往会考虑对上下文进行压缩,但是如果是简单的压缩很有可能会导致有效信息的损失,为了压缩而损失了准确性是不可取的。所以 AgentScope 推出了AutoContextMemory,它是框架提供的智能上下文内存管理组件,通过自动压缩、卸载和摘要对话历史,在成本控制和信息保留之间找到最佳平衡,具体的原理可以参考我们之前发布的文章《AgentScope AutoContextMemory:告别Agent上下文焦虑》。要使用该能力同样只需要配置一些简单参数即可。

AutoContextConfig autoContextConfig =
        AutoContextConfig.builder().tokenRatio(0.4).lastKeep(10).build();
// Use AutoContextMemory, support context auto compression
AutoContextMemory memory = new AutoContextMemory(autoContextConfig, model);

快速开始

为了让大家能够快速体验,同时方便大家拿奶茶店练手,我们提供了多种便捷的部署方式:

本地开发推荐

# 配置环境变量
cp local-env.example local-env.sh
vim local-env.sh
# 一键启动
source local-env.sh && ./local-deploy.sh start

K8s 生产推荐

# 配置变量
vim values.yaml
# Helm 一键部署
helm install agentscope helm/ --namespace agentscope

Docker 极简

# 配置环境变量
cp docker-env.example .env
# 容器一把梭
docker-compose up -d

云产品(AgentRun)部署

如果想使用云产品部署,可以使用 AgentRun,直接拉取镜像部署,所需要配置的环境变量参考 README.md 文档。

最后的最后

这个奶茶店的例子只是 AgentScope Java 能力的冰山一角,用来带大家快速入门。AgentScope Java 框架还支持更多玩法,所有的核心能力都有对应的 Example,欢迎大家体验:

  • 实时人类介入
  • PlanNotebook,先规划后执行
  • 结构化输出
  • AI 狼人杀
  • ……

同时社区也在快速演进中,欢迎大家参与讨论和贡献 🚀

Star 一下不迷路!

项目地址:AgentScope Java [ 2]

Demo 地址:agentscope-examples/boba-tea-shop

"Talk is cheap, show me the agents."

快来 Clone 下来跑一把,体验一下 AI 给你点奶茶的快感吧!

相关链接:

[1] agentscope-java/agentscope-examples/boba-tea-shop

https://github.com/agentscope-ai/agentscope-java/tree/main/agentscope-examples/boba-tea-shop

[2] AgentScope Java

https://github.com/agentscope-ai/agentscope-java

1 月 31 日,由雄安新区管委会主办的“人工智能+”创新生态系列活动在雄安新区成功举行。本次活动汇聚了人工智能领域的顶尖专家、行业领袖及领军企业,共同探讨 AI 技术如何深度赋能实体经济。彩讯股份受邀出席系列活动。在活动分论坛上,彩讯股份重磅发布了《企业级 AI 应用白皮书》(以下简称“白皮书”),围绕企业级 AI 的发展阶段、核心挑战与落地路径,系统性提出面向真实业务场景的行业判断与实践方法。旨在为企业在智能时代的转型升级提供实战路径与理论支撑。

彩讯股份 CEO 白琳、董事会秘书兼财务总监王欣、数行事业部总经理朱彩霞与生态伙伴稳准智能首席科学家崔鹏、CTO 张兴璇、COO 何玥共同参与发布仪式。白皮书的发布,标志着彩讯股份在企业级 AI 应用领域,基于长期实践积累形成的系统性研究成果正式对外发布。

(从左至右依次是:稳准智能 COO 何玥,稳准智能 CTO 张兴璇,稳准智能首席科学家崔鹏,彩

讯股份 CEO 白琳,彩讯股份董事会秘书兼财务总监王欣,彩讯股份数行事业部总经理朱彩霞)

聚焦“企业级 AI 应用”,回应 AI 落地的真实问题

在当前“人工智能+”加速向各行各业渗透的背景下,AI 在企业场景中的应用正从技术探索阶段,进入系统化、规模化落地的关键时期。彩讯股份在白皮书中指出,当前企业级 AI 面临的核心挑战,已从技术可得性转向 AI 能否与既有系统融合并形成可验证、可持续的业务价值。白皮书基于彩讯股份在通信、金融、能源、交通等多个行业的长期实践经验,从行业观察、痛点分析出发,系统梳理了企业级 AI 应用在架构设计、数据治理、安全合规、应用集成等方面的关键问题,并提出了具有可操作性的解决思路与实践路径。

从技术热潮走向系统工程,用 AI 重新定义企业级软件

彩讯股份《企业级 AI 应用白皮书》并非一本单纯的技术手册,而是一份面向行业的参考性研究成果,旨在帮助企业客户、产业伙伴和管理者更理性地理解 AI 在企业中的角色与边界,重塑企业级软件的底层逻辑,推动企业级 AI 从“概念验证”走向“系统工程”。白皮书强调,企业级 AI 的价值释放,依赖于对业务场景的深度理解、对系统架构的整体规划,以及对长期演进路径的清晰判断。彩讯股份提出了“1+1+N”的整体落地路径,回应企业在 AI 推进过程中普遍面临的场景难选、系统难融与价值难证等现实问题。其中,“第一个 1”是一套面向企业真实环境的企服 AI 方法论,用于指导企业如何从业务场景出发,系统性推进 AI 应用;“第二个 1”是一套平台化的能力与工具集(Rich AIbox),为方法论落地提供工程化支撑;“N”则对应不同企业在具体业务场景中的实践沉淀与持续演进。通过这一结构,彩讯推动 AI 能够在既有业务体系中稳定运行、持续生长,并真正形成业务价值闭环。

以白皮书为起点,持续推动企业级 AI 实践

作为长期深耕企业数字化与智能化服务的上市公司,彩讯股份近年来持续加大在 AI 与智算领域的投入,围绕企业级 AI 平台、智能体应用及行业解决方案,探索 AI 技术与企业业务深度融合的实践路径。彩讯股份表示,未来将以本次白皮书发布为起点,持续通过行业研究、实践案例分享与生态合作,推动企业级 AI 应用经验的沉淀与传播,为“人工智能+”背景下企业级软件与应用体系的演进提供长期参考。

《企业级 AI 应用白皮书》完整版,可扫码下载:

Linux 系统突发宕机是运维人员和开发者经常面临的难题。面对复杂的内核日志和内存转储文件,传统分析方式往往耗时费力且需要深厚的内核知识。本文将介绍阿里云操作系统控制台的宕机智能诊断功能,并展示其如何通过 AI 技术简化宕机分析流程。

传统宕机分析的“三座大山”

第一座大山:日志分析如同“看天书”

服务器宕机后,运维人员首先需要查看 dmesg 日志。然而,内核日志往往包含大量难以理解的信息:

[69518574.393036] Code: e8 38 ac e8 88 0b ff ff 0f 0b 48 c7 c7 d0 e8 38 ac e8 7a 0b ff ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 90 e8 38 ac e8 66 0b ff ff <0f> 0b 48 89 fe 48 c7 c7 58 e8 38 ac e8 55 0b ff ff 0f 0b 48 89 ee[69518574.393070] RSP: 0018:ffffb0d3c0a3bb98 EFLAGS: 00010282[69518574.393085] RAX: 0000000000000054 RBX: ffff9fbe07b158c0 RCX: 0000000000000000[69518574.394079] RDX: ffff9fbeddf703e0 RSI: ffff9fbeddf5fb40 RDI: ffff9fbeddf5fb40Kernel panic - not syncing: Fatal exception 
复制代码

这些信息对于普通运维人员来说难以理解,而且真正的问题往往隐藏在数千行日志中,需要花费大量时间排查。

传统的日志分析不仅需要深厚的技术背景,还要对内核各个子系统有深入理解。例如,hardlockup 错误需要了解 CPU 调度、中断处理、自旋锁等机制;hungtask 问题需要熟悉进程状态转换、等待队列、资源竞争等概念。

第二座大山:VMCORE 分析耗时又费力

对于复杂问题,通常需要获取 VMCORE 文件进行深入分析。完整的 VMCORE 分析流程包括:

  1. 首先得加载 VMCORE 文件到调试工具;

  2. 然后执行各种复杂的调试命令;

  3. 手动分析各种输出信息;

  4. 最后尝试拼凑出问题的全貌。

整个过程可能需要数小时甚至数天,并且对分析人员的内核知识要求较高。VMCORE 分析涉及的技术层面非常广泛,包括内存布局分析、进程状态重建、内核数据结构解析等。例如,分析内存错误需要检查页面分配状态、分析内存损坏问题;排查死锁问题则需要重建锁依赖关系、分析调用栈行为。

第三座大山:找补丁如同“寻宝游戏”

定位到问题后,还需要找到对应的修复补丁。Linux 内核的 Git 仓库包含三十多年演进历史,累计超过百万次 commit,涉及上万名开发者。从如此庞大的代码库中找到与特定问题相关的修复,需要对内核演化历史有深入了解。人工筛选不仅效率低下,而且容易遗漏关键信息。

这三大挑战使得传统宕机分析流程复杂且耗时。阿里云操作系统控制台的宕机智能诊断功能旨在解决这些问题。

阿里云操作系统控制台宕机智能诊断

阿里云操作系统控制台(简称操作系统控制台)是一站式操作系统运维管理平台,提供了内存、I/O、网络、内核崩溃等强大的系统诊断能力,SysOM 是操作系统控制台的运维组件。但这些功能通常需要用户登录控制台,并具备一定的运维经验才能有效使用。

什么是宕机智能诊断?

宕机智能诊断是阿里云操作系统控制台提供的系统场景诊断功能,基于大模型技术,融合了内核调试技术和丰富的故障案例,能够自动完成从日志分析到问题定位,再到补丁推荐的全流程,让原本复杂的宕机分析变得简单高效。

阿里云操作系统控制地址链接:https://alinux.console.aliyun.com/

图片

三大核心能力

1. 智能日志解析,告别“天书”

再也不用对着复杂的内核日志发愁了!宕机智能诊断的日志解析功能能自动提取关键信息,为后续 AI 分析提供结构化的数据基础。

核心能力:

  • 结构化信息提取:自动从日志中提取版本号、崩溃标题、进程名、函数名、RIP 寄存器值、CPU 编号、加载模块等关键字段;

  • 调用栈分层解析:识别并分离 NMI 栈、IRQ 栈、任务栈三层调用关系,过滤无效函数,提取 top-3 关键函数调用链;

  • 故障类型识别:支持 hardlockup、hungtask、memory_error、softlockup、hardware_error 等主流内核故障类型的快速判定;

  • 错误日志聚合:自动按时间戳排序错误日志,过滤冗余调用栈信息,保留关键诊断线索。

实际效果:传统方式需要人工从数千行日志中逐行查找关键信息,而系统可以在秒级完成日志解析和结构化提取,将非结构化的 dmesg 日志转化为结构化的特征集合,为后续的 AI 诊断提供清晰的数据输入。

2. 专项诊断,精准打击

系统针对不同类型的内核问题设计了专属的诊断能力,深度集成 drgn 内核调试器,能够直接访问 VMCORE 中的内核数据结构,结合 AI 推理实现智能分析:

  • Hardlockup 诊断:采用图遍历算法构建锁依赖图,自动检测循环等待和死锁场景,输出清晰的锁等待路径(如:CPU1→lockA→CPU2→lockB→CPU3→lockC→CPU1 形成死锁环路);

  • Hungtask 诊断:实现链式追踪算法,从 D 状态进程开始逐级分析等待链,定位终端阻塞点(Terminal Holder),给出完整的资源等待路径;

  • Memory Error 诊断:识别 use-after-free、空指针解引用、野指针等典型内存错误类型,追踪内存分配和释放路径;

  • Softlockup 诊断:分析调度延迟、CPU 占用模式,检测软锁和响应超时问题。

每种诊断都遵循“算法提取数据骨架 + AI 补全推理逻辑”的模式,既保证分析的准确性,又实现诊断的智能化。

3. 智能补丁匹配,一步到位

宕机智能诊断采用了混合向量检索技术来进行补丁搜索。系统首先使用 text-embedding-v4 模型将问题描述转换为 1536 维的稠密向量和稀疏向量,在面向 Linux 内核历史提交构建的向量数据库中进行语义相似度检索。

检索过程分为两个阶段:

  • 第一阶段-向量检索:通过向量数据库快速从海量 commit 中召回 top-k 个最相关的候选补丁;

  • 第二阶段-智能排序:利用大模型技术对每个候选补丁进行深度分析,评估其与当前问题的相关性(1-10 分),并给出详细的相关性原因说明。

系统支持按内核版本进行过滤(如筛选 v5.10 及以上版本的补丁),帮助用户更精准地检索到适用于特定版本的修复方案。最终返回多个最相关的补丁,每个补丁都包含 commit ID、摘要、相关性评分和推荐理由。

实际效果:Hardlockup 死锁问题的智能诊断

以一个真实的生产环境 Hardlockup 故障为例,服务器突发系统无响应并崩溃。运维人员通过控制台发起诊断后,系统在 5 分钟内生成了完整的诊断报告。

报告包含了以下关键信息:

  • 故障类型识别:自动判定为 Hardlockup 死锁问题;

  • 死锁链路分析:识别出三方 CPU 间的循环等待关系,包括各 CPU 持有和等待的锁;

  • 根因定位:指出导致死锁的关键代码路径和函数调用;

  • 修复建议:提供 4 条针对性的缓解措施;

  • 补丁推荐:从 Linux 内核百万级提交中检索出 3 个相关补丁,按相关性排序并说明推荐理由。

本次诊断中,系统首推的补丁正是实际修复该问题的补丁,其余 2 个推荐补丁也与故障症状高度匹配。对于这种复杂的多方死锁场景,传统人工分析通常需要数小时甚至数天,而宕机智能诊断在几分钟内完成了从问题分析到补丁推荐的全流程,大大降低了故障处理门槛和运维成本。

快速上手宕机智能诊断

宕机智能诊断功能支持使用 .rpm 包格式的主流 Linux 发行版,包括 Alibaba Cloud Linux、CentOS、Anolis OS、Rocky Linux、AlmaLinux 等。对于 Alibaba Cloud Linux、CentOS、Anolis OS 等发行版,系统会自动获取 debuginfo,降低使用成本。

推荐方式:通过 SysOM MCP 使用(AI 助手集成)

SysOM MCP阿里云开源的系统诊断工具集,基于 Model Context Protocol 协议,将宕机智能诊断能力封装为标准化的 MCP 工具,可以通过 AI 助手(如 qwen-code)使用自然语言直接进行宕机诊断。

🔗 项目地址:https://github.com/alibaba/sysom_mcp

请参考项目文档完成安装和配置。配置完成后,在 AI 助手中直接使用自然语言发起诊断:

示例 1:调用宕机智能诊断

请帮我分析一个宕机问题,vmcore 下载链接:https://path/to/your/vmcore
复制代码

说明:

· API 接受的是 HTTP/HTTPS 下载链接,确保下载链接具有适当的访问权限,便于诊断服务下载和分析;

· 对于 Rocky Linux、AlmaLinux 等其他发行版,需要额外提供 debuginfo 和 debuginfo-common 的下载链接。暂不支持使用 .deb 包格式的发行版(如 Ubuntu、Debian 等),该功能正在开发中。

示例 2:查询历史诊断任务

查看我最近 7 天的宕机诊断记录,并返回上一次的诊断结果
复制代码

AI 助手会自动调用相应的 MCP 工具,并将诊断结果以易读的方式呈现。

高阶方式:直接调用 OpenAPI 接口

对于需要集成到自动化运维系统或自定义工作流的场景,可以直接调用 OpenAPI 接口。详细使用方式请参考操作系统控制台 OpenAPI 文档。

操作系统控制台 OpenAPI 文档链接:

https://next.api.aliyun.com/api/SysOM/2023-12-30/CreateVmcoreDiagnosisTask

总结

Linux 宕机分析不再是少数专家的专利!阿里云操作系统控制台的宕机智能诊断功能通过 AI 技术与专业内核调试工具的深度融合,让每一位运维和开发都能轻松应对复杂的系统问题。

在这个追求高效运维的时代,拥有宕机智能诊断这样的功能,无疑会让你的工作事半功倍。无论是深夜排障还是日常维护,都能从容应对,再也不用为复杂的内核问题而头疼了。

如果你也想告别 Linux 宕机分析的烦恼,不妨试试阿里云操作系统控制台的宕机智能诊断功能,让 AI 成为你的得力助手!

若想使用更全面的 SysOM 功能,请登录阿里云操作系统控制台体验,地址:

https://alinux.console.aliyun.com/。您在使用操作系统控制台的过程中,有任何疑问和建议,可以扫描下方二维码或搜索群号:94405014449 加入钉钉群反馈,欢迎大家扫码加入交流。

操作系统控制台钉钉交流群

新春将至,美团技术年货如约而来。感谢这一路上,伙伴们的并肩前行与坚定支持!❤️

时光荏苒,美团技术博客已经陪伴大家走过了 12 个年头。过去一年,美团技术团队在持续深耕中积累了诸多值得分享的实践案例与开源项目。尤其值得关注的是,美团 LongCat 团队在大模型开源领域取得了不少亮眼的成果,这一年,我们陆续发布了覆盖基座模型、图像、视频、语音等多个方向的开源产品与工具,持续助力 AI 技术共享与生态繁荣。截至目前,美团技术团队微信公众号已累计发布 640 余篇技术文章。

值此马年春节来临之际,我们精选了过去一年美团技术团队微信公众号发布的 40 多篇优质技术文章,精心汇编成一本近 600 页的电子书。谨以此作为一份特别的新年礼物,献给每一位热爱技术、持续探索的同学。祝大家在新年里,一「马」当先,「马」到成功!

这本电子书的内容涵盖大模型、开源、AI Coding、安全、数据库、智能硬件、AB实验等多个技术领域,同时收录了一些美团技术团队与高校的合作成果,以及被多个国际顶级会议收录的论文合集,希望能为大家的工作和学习带来一些启发与助力。也欢迎大家将这份电子书分享给更多志同道合、追求进步的伙伴,让我们一起携手共进,砥砺前行。

新的一年,愿大家继续乘风破浪,在挑战中铸就辉煌;以坚定的步伐,踏出属于自己的未来之路。

如何获取

❤️ 温馨提示

  • 技术年货合集大小约为60M,下载需要一定的时间,建议通过PC浏览器进行查阅、下载;
  • 打开电子书目录后,可直接点击感兴趣的文章进行阅读;
  • 部分文章中的动态图片、视频无法在电子书中完全的展示,大家可以在公众号历史文章中进行阅读,感谢理解。

| 关注「美团技术团队」微信公众号,阅读更多技术干货!

| 本文系美团技术团队出品,著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容,敬请注明“内容转载自美团技术团队”。本文未经许可,不得进行商业性转载或者使用。任何商用行为,请发送邮件至 tech@meituan.com 申请授权。