睡眠:人类每天经历的另一种大脑状态——从睡意、梦境到意识科学前沿

人一生大约有三分之一的时间处于睡眠之中。 这件事因为过于日常,反而很容易被忽视。每天晚上,一个能够观察世界、规划未来、形成语言和维持自我意识的大脑,会主动降低对外界的响应,身体长时间静止,对危险的反应能力下降,然后几个小时以后再次恢复。 从进化角度看,这甚至是一件有些反常的事情。 一个完全不需要睡觉的动物,理论上每天可以多出数小时寻找食物、寻找配偶或者躲避天敌。如果自然选择仍然让睡眠在动物界广泛存在,那么睡眠很可能完成了某些无法轻易替代的生物学任务。 问题在于: 研究睡眠一百多年以后,科学仍然不能完整回答“为什么必须睡觉”。 而过去几年的研究,正在让这个问题变得更加奇怪。 一、睡眠可能并不是“大脑整体关闭” 过去最直观的理解是: 清醒时,大脑工作; 睡眠时,大脑休息。 现代神经科学已经基本否定了这种简单模型。 2026年6月,《Nature Neuroscience》发表了一项非常特别的小鼠实验。研究人员没有让动物进入正常睡眠,而是在动物保持清醒和活动的情况下,通过光遗传学技术,让局部大脑皮层产生类似慢波睡眠的神经活动。 慢波睡眠中,大量神经元并不是持续沉默,而是在数百毫秒尺度上反复经历: ON → OFF → ON → OFF 即神经元群体同步活跃,再同步安静。 研究人员发现,仅仅在清醒状态下人为制造这种局部 ON/OFF 周期,就能够降低该区域之后表现出的睡眠压力,同时降低兴奋性突触强度的分子指标。 更令人意外的是,在睡眠剥夺后,如果在双侧感觉运动皮层制造这种睡眠样活动,部分记忆巩固能力也能够得到恢复。 这意味着一个重要的概念正在形成: 睡眠可能不仅是一种“整个动物进入的状态”,还可能是一种神经网络能够局部执行的计算模式。 换句话说,大脑不一定只有“醒”和“睡”两个档位。 理论上可能存在: 身体仍然醒着,一部分大脑却已经开始进行类似睡眠的维护工作。 鲸类和某些鸟类能够进行单半球睡眠,本来就已经提示了这一点。如今实验室甚至开始人为制造类似的局部睡眠功能。 于是一个原本看似简单的问题——“什么时候算睡着?”——开始变得没有那么容易回答。 二、甚至连“睡意”究竟是什么,科学也才刚刚摸到边缘 每个人都认识睡意。 清醒十几个小时以后,会越来越困;如果整夜没有睡觉,第二天对睡眠的需求会非常强烈。 这种现象被称为睡眠稳态压力。 但这里存在一个长期没有解决的问题: 大脑究竟在计算什么? 是什么东西随着清醒时间不断增加,最后告诉大脑: 必须睡觉了。 2026年,一项《Nature Neuroscience》研究找到了一个非常有意思的候选信号——色胺(tryptamine,TrpA)。 研究人员发现,小鼠和猪脑脊液中的 TrpA 水平能够反映此前的清醒和身体活动历史。清醒活跃的单胺能神经元释放 TrpA,它进一步作用于 GPR139 受体,并通过下丘脑睡眠相关区域促进睡眠。 …

从纳米到宇宙底层:一个问题如何一步步逼近世界的本质

很多关于宇宙终极本质的思考,并不是从宏大的哲学命题开始的。 有时,它只是从一个极其简单的问题开始: 纳米和埃米,究竟差多少? 一、从纳米和埃米开始 纳米的符号是 nm。 埃米,也称 Ångström,符号是 Å。 它们之间的关系非常简单:1 nm=10 A˚1\ \text{nm}=10\ \text{Å} 也就是说:1 A˚=0.1 nm1\ \text{Å}=0.1\ \text{nm} 换成米:1 nm=10−9 m1\ \text{nm}=10^{-9}\ \text{m}1 A˚=10−10 m1\ \text{Å}=10^{-10}\ \text{m} 两者只相差 10 倍。 但进入这个尺度之后,世界已经完全脱离了人类的日常直觉。 原子的典型尺度,大约就在埃米级。 很多原子的直径大致处在:0.1∼0.3 nm0.1\sim0.3\ \text{nm} 也就是:1∼3 A˚1\sim3\ \text{Å} 于是,一个原本只是单位换算的问题,很自然地变成了另一个问题: 原子到底有多大? 二、原子已经很小,但原子核更小 原子的典型尺度大约是:10−10 m10^{-10}\ \text{m} 而原子核的典型尺度只有:10−15 m10^{-15}\ \text{m} 两者相差大约:10510^5 也就是十万倍。 换句话说,如果把一个原子放大到一座大型体育场那么大,那么原子核可能只有中央一个非常小的物体那么大。 原子内部绝大部分空间,并不是由传统意义上的“实体物质”连续填满的。 这已经足够奇妙。 但问题并不会停在这里。 如果原子可以继续拆分,那么原子核里面又是什么? 三、从原子核继续往下 原子核主要由质子和中子组成。 于是结构继续向下展开:原子→原子核→质子和中子\text{原子} \rightarrow \text{原子核} \rightarrow \text{质子和中子} …

NASA 与 IBM 开源“月球基础模型”:让人工智能读懂月球

2026 年 9 月,NASA 与 IBM Research 正式发布 NASA-IBM Lunar Foundation Model(NASA-IBM LFM)。这是一个专门面向月球遥感科学设计的多模态、多分辨率人工智能基础模型。模型权重公开托管于 Hugging Face,微调和推理代码则开放在 GitHub,并采用 Apache 2.0 许可证。 它并不是类似 ChatGPT 的语言模型,也不是一个能够模拟整个月球的“数字月球”。更准确地说,它是一套专门学习月球表面遥感数据的视觉基础模型。 从“识别图片”到“理解月球遥感数据” 几十年来,人类已经通过大量探月任务积累了规模庞大的月球观测数据。 其中最重要的数据来源之一,是 NASA 于 2009 年发射的月球勘测轨道飞行器 Lunar Reconnaissance Orbiter,简称 LRO。经过十多年运行,LRO 已经获得覆盖月球大部分表面的高分辨率影像和多种遥感数据。 但数据越来越多之后,一个新的问题逐渐出现: 如何有效分析如此庞大的月球数据? 如果研究人员希望寻找陨石坑、统计地貌、识别特殊火山结构或者分析极区水冰潜力,传统方法往往需要针对每一个研究任务重新建立算法和训练模型。 NASA 和 IBM 希望改变这种模式。 NASA-IBM Lunar Foundation Model 的思路与近年来人工智能领域的“基础模型”类似:先利用海量数据进行大规模预训练,让模型形成一种对月球表面结构的通用表示能力,然后再针对具体科学问题进行微调。 因此,它并不是一个只会“找陨石坑”的模型,而更像一个可以进一步训练成许多不同月球分析工具的基础平台。 近 200 万组月球数据 …

从 System Prompt 到长期知识架构:一套 AI Agent 的演进实践

近年来,AI Agent 的能力正在快速从“会聊天”演变为“能够长期工作”。 它们开始拥有文件系统、Shell、浏览器、代码执行环境、外部 API、远程主机、数据库、记忆、插件、Skill,甚至能够把任务交给其他 Agent。 这带来了一个比“怎么写好 Prompt”更重要的问题: 当一个 AI Agent 真正开始长期运行时,它应该如何组织自己的知识、规则、上下文、记忆和工具? 如果所有内容最终都堆进一个越来越长的 system prompt,系统很快就会遇到三个问题: 一个更成熟的方向,是把 Agent 看成一个长期运行的软件系统,而不是一段特别长的 Prompt。 本文讨论的正是这种演进过程。 一、研究 System Prompt,真正应该学习什么? 收集 OpenAI、Anthropic、Google、Microsoft、Meta、xAI、Perplexity、Cursor、OpenCode 等不同 Agent 产品的 system prompt、CLI Agent 规则和工作流后,一个很容易出现的误区是: 把优秀句子复制出来,然后拼进自己的 system prompt。 这种方法短期看起来很强,长期却很容易失控。 因为不同公司的 Agent: 真正值得借鉴的,不是某一句具体措辞,而是多个独立系统反复出现的共同架构思想。 当这些产品横向放在一起比较时,会发现很多设计已经开始趋同。 例如: 这说明成熟 Agent 的核心已经不再是一个巨大 Prompt,而是一套分层知识系统。 二、第一原则:Bootstrap 是宪法,不是数据库 Agent 启动时会注入一部分固定上下文。 这部分内容非常宝贵。 …

RustDesk Server OSS 设备记录审计、旧设备清理与管理实践

自建 RustDesk Server 运行一段时间后,很容易出现一个实际问题: 服务器已经连接过不少客户端,但究竟登记过多少设备?哪些设备仍在使用?哪些只是已经废弃的历史记录? RustDesk Server OSS 并没有像 Pro 版本那样提供完整的设备管理控制台,因此很多信息需要直接从服务端数据库进行审计。 本文以 Docker 部署的 RustDesk Server OSS 为例,介绍如何安全查看设备记录、理解数据库字段、识别旧设备、删除废弃记录,以及如何建立一个长期可用的系统管理命令。 一、先确认 RustDesk Server 的部署方式 RustDesk Server OSS 主要包含两个服务: 如果采用 Docker 部署,可以先检查: 常见部署会看到两个独立容器: 然后检查数据目录挂载: 典型结果类似: 这意味着 RustDesk 的数据库、服务器密钥等持久化数据实际上都保存在宿主机目录: 二、RustDesk OSS 的设备记录保存在哪里 RustDesk Server OSS 默认使用 SQLite 数据库: 数据目录中通常还能看到: 这里有一个值得注意的细节。 如果存在: 说明 SQLite 正在使用 …

Rocket.Chat 7.x 升级到 8.5.x:一次 Docker 与 MongoDB 联动迁移实践

Rocket.Chat 从 7.x 升级到 8.x,看起来像一次普通的容器镜像升级,但在实际环境中,真正需要处理的不只是 Rocket.Chat 本身。 这次升级同时涉及: 整个过程最重要的并不是“把新镜像跑起来”,而是保证: 任何一个阶段出现问题,都能够明确知道数据是否安全、问题出在哪里,以及能否回退。 一、为什么不能只修改镜像版本然后 docker compose up 旧环境采用的是典型的 Docker Compose 部署: MongoDB 使用的是较早时期常见的第三方容器镜像。 升级到 Rocket.Chat 8.x 后,数据库环境也需要同步调整。新的目标结构变成: 这带来了一个非常重要的问题: 旧 MongoDB 数据目录不能简单地直接挂载到新的 MongoDB 8.2 容器里。 MongoDB 的数据目录内部包含: 跨多个 MongoDB 大版本直接复用底层数据目录,风险远高于普通容器镜像升级。 因此这次采用的不是“原地替换数据库镜像”,而是: 也就是说,迁移的是逻辑数据,而不是直接让 MongoDB 8.2 接管 MongoDB 7 的物理文件。 二、升级前先建立可验证的数据库基线 在修改任何东西之前,先记录数据库当前状态。 例如检查: 这里最重要的不是某一个具体数字,而是建立一个可以在迁移结束后重新比对的基线。 例如: 迁移后重新执行相同统计。 …

木星旁的两个水世界:木卫二与木卫四

提到太阳系中的“水世界”,大多数人首先想到的往往是地球。 毕竟,从太空看,地球是一颗蔚蓝色的行星,约 71% 的表面被海洋覆盖。然而,如果把视线从地球移向木星,会发现一个颇为反直觉的事实: 太阳系中的水,远不止存在于地球。 在木星庞大的卫星系统中,Europa(木卫二)和 Callisto(木卫四)就是两个非常典型的例子。它们的表面都极其寒冷,大量水被冻结成冰,但在厚厚的冰层之下,还可能隐藏着规模惊人的液态海洋。 这两颗卫星也向我们展示了太阳系中两种完全不同的“水世界”。 一、木星的四颗伽利略卫星 1610 年,伽利略用望远镜观察木星时,发现了四颗围绕木星运行的明亮天体。 今天,它们被称为“伽利略卫星”。 按照距离木星由近到远排列,分别是: Io(木卫一) → Europa(木卫二) → Ganymede(木卫三) → Callisto(木卫四) 这四颗卫星本身就像四个截然不同的世界。 木卫一拥有极其猛烈的火山活动;木卫二覆盖着年轻的冰壳;木卫三是太阳系最大的卫星;而最外侧的木卫四,则保存着太阳系早期留下的大量撞击痕迹。 其中,木卫二和木卫四有一个共同特点: 它们都拥有大量的水。 但这些水的分布方式,以及两颗卫星内部的状态,却非常不同。 木卫二:冰层下面隐藏着一片全球海洋 Europa,也就是木卫二,直径大约 3120 千米,比地球的月球稍小。 如果只看照片,它最引人注意的不是陨石坑,而是覆盖整个表面的巨大裂纹。 这些裂纹有的延伸数百甚至上千千米,相互交错,就像一个被冻结后又不断开裂、重新冻结的巨大冰面。 木卫二的表面异常年轻。 与月球、火星和木卫四相比,它表面的撞击坑非常少。这说明在漫长的地质历史中,木卫二的表面曾经不断被重新塑造。 而推动这一切的,很可能就是冰层下面的水。 目前的主流模型认为,木卫二表面覆盖着厚达十几到几十千米的水冰层。 在冰层之下,则可能存在一个覆盖整个卫星的液态咸水海洋。 这片海洋的平均深度可能达到几十甚至上百千米。 作为比较,地球海洋的平均深度只有大约 3.7 千米。 因此,虽然木卫二远远小于地球,它地下海洋所包含的液态水总量,却可能达到: 地球全部海洋水量的大约两倍。 这是一个非常反直觉的事实。 地球看起来像一颗巨大的水球,但实际上,地球的海洋只不过是在巨大岩石球体表面覆盖的一层很薄的水膜。 而木卫二虽然外表冻结,却可能拥有一个真正深达上百千米的全球海洋。 为什么离太阳这么远,还会有液态海洋? 木星距离太阳很远。 木卫二表面的温度极低,按照常理,水应该早已全部冻结。 那么,它内部的液态海洋为什么能够长期存在? 答案来自木星本身: …

一次 OpenClaw × Nextcloud Talk 故障排查与完整审计:从 Webhook 401 到迁移残留清理

前言 在一套长期运行的自建 AI Agent 环境中,OpenClaw 通过 Nextcloud Talk 接收消息,并借助 FRP、反向代理和 Webhook 与外部服务通信。 某次系统维护之后,Nextcloud Talk 中的机器人突然停止回复。与此同时,OpenClaw 此前还经历过一次失败的版本升级,因此最初很容易怀疑:是否升级失败破坏了插件、数据库或 Gateway 状态? 最终调查表明: Talk 故障与失败升级没有直接关系。真正原因是 Nextcloud 公网域名迁移后,OpenClaw Talk Channel 中的 baseUrl 仍指向旧地址,导致 Webhook Backend 校验失败并返回 HTTP 401。 在修复 Talk 后,又对整个 OpenClaw 安装实例进行了完整的只读审计,清理了迁移残留、失败升级 candidate 和旧 SQLite snapshot cache,并验证 SQLite、插件、Gateway、FRP、Agent 数据库等核心组件均处于正常状态。 这次排查很适合作为一个复杂自托管系统的故障分析案例: 不要看到异常就立即修复,而应先确定故障边界,建立证据链,最后只修改真正错误的部分。 一、系统架构 为避免暴露真实基础设施信息,本文统一使用占位符。 典型架构如下: …

从 /nextcloud/ 迁移到独立子域名:一次完整的 Nextcloud URL 架构重构

很多早期部署的 Nextcloud 都采用子目录模式。 例如: 这种部署方式简单,而且可以和其他服务共用同一个主域名。 但随着 Nextcloud 和现代浏览器安全机制不断演进,子目录架构会逐渐暴露一些限制。 这次迁移最终把正式地址从: 迁移为: 也就是独立子域名根路径部署。 整个过程涉及: 并不是简单地修改一个域名字符串。 一、为什么要从子目录迁移到子域名 最直接的原因之一是: 现代浏览器支持: Cookie 前缀。 它要求: 而如果 Nextcloud 长期运行在: 路径下,就很难完全满足: 这一要求。 安全扫描因此一直存在一个: 相关提示。 这意味着即使 HTTPS、HSTS、Content-Security-Policy 等其他配置全部正常,子路径本身仍然会限制部分 Cookie Hardening。 因此最终决定把 Nextcloud 放到独立子域名根目录。 二、DNS:先创建新的正式入口 首先创建: 对应 DNS A 记录: TTL 采用普通值,例如: 在真正修改 Web Server 之前,先确认: 这样后续 TLS 和反向代理才能正常验证。 三、TLS:把新域名加入现有多域名证书 …

从多个大版本一路升级到 Nextcloud 34:数据目录分离、App 兼容性、数据库索引与完整性修复

长期运行的 Nextcloud 实例,升级通常不是简单地执行一次: 就可以结束。 随着运行时间增加,实例会逐渐积累: 因此,一次跨越多个主要版本的升级,本质上更像是一次系统整理。 这次升级最终依次完成: 最终版本为: 一、没有跨主要版本跳跃 整个升级过程采用官方支持的逐版本路线。 例如: 这样做的主要原因不是保守,而是每一个主要版本都可能包含自己的: 如果跳过中间版本,就可能绕过原本应该执行的升级阶段。 二、数据目录分离显著改变了 updater 的行为 在早期升级过程中,一个非常明显的瓶颈出现在: 某次升级中,这一步曾经持续: 后来数据目录从应用程序目录中彻底分离。 原来的结构类似: 调整后变成: Nextcloud 配置中的: 也同步修改。 而且没有通过符号链接伪装旧数据目录。 之后再次进行: 升级时, 几乎变成瞬时完成。 这说明此前 updater 很大一部分时间很可能消耗在庞大的数据目录树检查上。 应用代码和数据目录分离后,更新器只需要处理真正属于程序的文件。 三、升级使用 updater.phar,并明确关闭 updater 自己的备份 其中一次升级命令类似: 这里使用: 并不是表示系统不需要备份。 而是因为该实例已经有独立的备份策略,不需要 updater 再额外生成一份完整程序备份。 更新完成后,继续执行: 最终状态为: 四、第三方 App 是升级中最需要单独处理的部分 Nextcloud Core 与第三方 …