安全 on 魔都水滴

AI 怎么学会“用手”的？从只会聊天到会查、会写、会操作

Sun, 19 Jul 2026 22:00:00 +0800

先说结论

AI 并不是突然长出了手。它只是学会了一个非常关键的动作：先判断自己需要什么工具，再用结构化参数请求工具，等工具返回真实结果，最后把结果翻译成人话。

这套机制通常叫 Tool Calling（工具调用）；在不同平台上也会看到 Function Calling、Tools API 等名字。MCP（Model Context Protocol，模型上下文协议）则像一套“统一插座”，让不同的 AI 应用可以用相似的方式发现和调用文件、数据库、搜索、工单、浏览器等能力。

本文不把 AI 神化成“会自己做事的数字员工”，而是把一次调用拆开给你看：模型到底做了什么、真正执行动作的是谁、为什么 MCP 会火、权限应该放在哪里，以及为什么“能调用工具”不等于“可以随便给它钥匙”。文中截图来自 OpenAI 与 MCP 官方页面，命令输出图为本文根据真实调用流程制作的示意证据；文章不包含任何真实内网地址或主机名。

青龙面板还能公网裸奔吗？几个月前那次致命漏洞后，我更建议你看白虎面板

Thu, 09 Jul 2026 10:00:00 +0800

先说结论

青龙面板曾经是很多人自托管定时任务的默认选择：跑脚本、管环境变量、看日志、定时同步仓库都很方便。但 2026 年初公开爆出的青龙面板致命漏洞，把一个老问题重新摆到台面上：定时任务面板不是普通网页，它往往握着脚本、变量、通知密钥和执行权限。一旦认证被绕过，攻击者看到的不是一个登录页，而是一台可以被调度的机器。

如果你只是新装一个轻量任务面板，我现在更建议优先评估白虎面板。白虎面板采用 Go + Vue3，主打轻量、高性能、低系统开销，并且官方 README 已经明确支持 Docker / Docker Compose 部署、Mise 运行时管理、仓库任务同步、执行日志和多渠道通知。它不是“青龙的一比一复制品”，但对很多个人脚本托管场景已经够用。

如果你因为兼容旧脚本、历史任务或迁移成本，必须临时继续用青龙面板：不要把它直接暴露在公网。 至少在前面加 VPN、零信任访问、反向代理二次认证、IP allowlist、WAF 或其它访问控制。本文给出 Windows 11、Ubuntu 26.04、macOS 26 三套一键脚本，默认部署白虎；只有显式指定时才部署青龙，并且都会把面板放到 Basic Auth 保护后面。

Mac 应用打不开？别急着删：可能只是 Gatekeeper 不认这个未签名工具

Mon, 01 Jun 2026 07:35:00 +0800

先说结论

如果一个 macOS 工具下载后双击打不开，提示“无法验证开发者”“已损坏，无法打开”或被系统直接拦住，不要第一时间把它理解成“程序坏了”。很多时候，真正的问题是两个条件叠在一起：这个 .app 带着浏览器下载留下的 com.apple.quarantine 隔离属性，同时它没有 Apple 能认可的可用签名。Gatekeeper 在首次打开时看到“来自网络 + 没有可信签名”，自然会把它拦下来。

对明确知道来源、只在自己机器上使用的小工具，最小修复通常是：先验证隔离属性和签名状态，再对这个 app 做本地 ad-hoc 签名，最后移除它自己的 quarantine 属性。这里的关键不是“关闭 macOS 安全”，而是只处理一个具体 app，不动全局 Gatekeeper，也不把临时本地修复误认为正式分发签名。

这篇文章来自一次真实的本地排障，但所有涉及个人机器、内网、下载来源、账号、路径细节的内容都已经脱敏。文中只使用 /Applications/<App>.app、<App>、<Vendor> 这类占位符。重点不是公开某个私有环境，而是把这类 macOS 启动失败的判断路径整理出来，方便以后遇到类似问题时少走弯路。

你能 SSH 出去，却 SSH 不回来：一次被 Fail2Ban 误伤的反向访问排障实录

Sat, 30 May 2026 15:45:00 +0800

先说结论

这次问题的表象很简单：本机可以主动 SSH 到远端内网机器，但远端机器反过来 SSH 回本机时，连接直接被拒绝。sshd 明明在监听，路由也没断，最后却卡在“反向访问”这一步。

真正的根因不是 sshd 挂了，而是 Fail2Ban 把承载反向连接的 VPN 网关地址 封掉了。对本机来说，来自远端的连接并不是以“远端机器本身”的地址出现，而是以网关地址出现。于是，错误的封禁对象把整条回程链路一并打断了。

SSH 密钥算法 Ed25519 与 RSA 的前世今生，以及今天该怎么用

Mon, 02 Mar 2026 09:00:00 +0800

很多人第一次接触 SSH，都是从一行命令开始的：

ssh-keygen -t rsa

这条命令并没有错，但它背后有一个经常被忽略的问题：我们讨论的到底是“RSA 这种密钥类型”，还是 ssh-rsa 这种“签名算法”？

这两个概念在很多旧教程里被混用，导致不少人一边以为自己“还在用老旧不安全方案”，一边又不知道怎么迁移，甚至在新系统和老设备之间反复踩坑。

这篇文章就把这件事讲清楚：

RSA 和 Ed25519 在 SSH 世界里是怎么一路走来的。
为什么今天大家都在推荐 Ed25519。
如果你线上还有一堆老机器，应该怎么稳妥迁移。
2026 年这个时间点，个人和团队应该采用什么默认策略。