AI Agent on 魔都水滴

别急着装电脑管家：AI Agent 到底能替代桌面上的哪些软件？一次看懂清理、优化、改配置和维修的边界

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

先说结论

AI Agent 可以替代一大批“只会点按钮”的桌面工具，但它不是把所有软件图标变成一个聊天框。它真正擅长的是：先看懂问题，再组合系统自带工具，执行一连串步骤，最后把结果解释给你。

在文件格式转换、垃圾扫描、性能检查、配置修改和软件故障排查这五类任务里，AI Agent 对前两类的替代程度最高，对性能优化和配置修改属于“半自动”，对硬件维修只能做诊断助手，不能代替人拆机。

本文用一条简单原则贯穿全文：先读，再写；先备份，再改变；先验证，再宣布成功。 文中的脚本不依赖第三方服务，默认只扫描和生成报告，必须加参数并再次确认才会清理。

你给 Agent 装了 Superpowers 吗？v6 这一波更新，把 Skill 从「说明书」改造成了「自动工厂」

Mon, 13 Jul 2026 15:30:00 +0800

先说结论

如果你已经在用 Claude Code、OpenCode、Codex 之类的工具写代码，大概率已经听过 Superpowers 这个名字。它不是又一个「魔法 prompt」，而是一套让 Agent 按流程工作的 Skill 框架——把「先想清楚再动手」「先写测试再看代码」「修 bug 先收集证据」这些人类工程师的好习惯，变成 Agent 必须遵守的操作规程。

截至 2026 年 7 月 13 日，Superpowers 的最新稳定版本是 v6.1.1。从 v6.0.0 到 v6.1.1，这个项目连续完成了六个版本节点：子代理驱动开发（SDD）减少 reviewer，但审查更严格；Plans 增加「全局约束」和「接口契约」；Codex 进入官方插件市场；bootstrap 变得更轻；Gemini CLI 支持被移除；最后还修了一个 hooks: {} 才能表达「明确没有 hook」的兼容性坑。

这篇文章就一起把这波更新拆开看看，你到底能拿到什么新东西，以及它为什么能让你的 Agent 输出更稳。

别再让 AI 猜故障了：MySQL + Prometheus + Loki + Grafana 四件套接入 Agent 全自动实战

Sat, 11 Jul 2026 08:30:00 +0800

很多团队已经把 MySQL、Prometheus、Loki 和 Grafana 装起来了，但线上报警之后，值班人员仍然要在四个窗口之间来回切换：先看仪表盘，再写 PromQL，然后去日志里搜索 trace_id，最后登录数据库核对业务记录。这就像医院明明有体温计、病历、化验单和监护大屏，医生却仍要自己跑四个房间抄数据。AI Agent 真正有价值的地方，不是替医生“猜病”，而是拿着受限制的工具，自动把四处证据取回来，再把“现象、证据、根因和建议”分开说明。本文不是概念拼贴。我实际启动了一套隔离环境，使用 MySQL 8.4、Prometheus 3.13、mysqld_exporter 0.19、Loki 3.7 和 Grafana 13.1，注入了一次带统一 trace_id 的慢查询故障，然后通过自建只读 MCP Bridge 完成协议初始化、工具发现、PromQL 查询、LogQL 查询、MySQL 只读查询和 Grafana 数据源审计。先说结论：四件套接入 Agent，不等于把四套管理员密码交给 AI 正确的架构应该满足下面几条： MySQL 仍然保存业务事实，Agent 只能使用专门的只读账号； Prometheus 负责保存数字随时间的变化，例如连接数、QPS 和缓存命中率； Loki 保存“发生了什么”的日志，并通过标签、时间和 trace_id 关联事件； Grafana 继续承担人工观察、仪表盘、数据源管理和结果复核； MCP Bridge 把查询包装成边界明确的工具，而不是开放任意 Shell； Agent 先调用工具取证，再总结答案，不能把语言模型的推测冒充事实。换句话说，Agent 拿到的应该是一串“只能打开指定抽屉的钥匙”，而不是整栋楼的万能钥匙。四件套分别是什么？用小学生也能懂的方式解释 MySQL：学校老师手里的成绩册 MySQL 保存订单、用户、库存、付款状态等业务事实。你问“这个订单到底有没有支付”，最终应该以数据库记录为准。它像成绩册：里面写着谁参加了考试、得了多少分。成绩册擅长回答具体事实，却不适合每隔五秒画一次“全校平均分变化曲线”。 Prometheus：每隔几秒自动测一次体温 Prometheus 会定时抓取指标，并保存时间序列。借助 mysqld_exporter，MySQL 的连接数、查询数、线程状态等数据会被翻译成 Prometheus 能理解的格式。它像自动体温计：一次读数只能告诉你现在是 38℃，连续读数才能告诉你温度是突然升高、持续升高，还是已经恢复。下面是真实实验中的 Prometheus Targets 页面。mysql 抓取目标显示为 UP，说明 exporter 与 Prometheus 的链路已经打通。

别再人工翻日志了：ELK 三件套接入 AI Agent，从部署到自动排障的手把手教程

Sat, 11 Jul 2026 03:30:00 +0800

过去，线上报警后的标准动作通常是：打开 Kibana、选择时间范围、输入查询语句、翻几十页日志、复制错误堆栈，再把零散证据拼成结论。系统一多，这件事很像在一座没有导购员的巨大仓库里找一颗螺丝。现在可以换一种方式：让 ELK 继续负责可靠地收集、整理和搜索日志，再给它加一座 MCP “翻译桥”，让 AI Agent 用工具读取证据。于是你可以直接问：最近 15 分钟哪个服务的 5xx 最多？请列出证据、关联 trace_id，并给出下一步排查建议。 Agent 不再只靠语言模型“猜”，而是先调用 Elasticsearch 查询，再根据返回的数据组织答案。本文不是概念拼贴。我实际启动了 Elasticsearch、Logstash、Kibana 和 Elasticsearch MCP Server，导入一组脱敏故障日志，完成 MCP 协议握手与查询，并记录了中途踩到的权限问题。先说结论：真正有价值的不是“让 AI 看日志”，而是让它有边界地查日志接入后的合理架构是： Logstash 负责接收、解析、清洗和补充字段； Elasticsearch 负责索引、搜索、聚合与保存； Kibana 负责人工可视化、验证和审计； MCP Server 把查询能力包装成 Agent 能理解的工具； AI Agent 负责拆解问题、调用工具、总结证据，但默认不拥有删除和写入权限。这与“把所有日志复制给聊天机器人”完全不同。后者既容易泄密，也会受上下文长度限制；前者让数据留在自己的 ELK 中，Agent 只取当前问题需要的少量结果。如果给小学生解释，可以把它想成一座图书馆：Logstash 是收书和贴标签的工作人员，Elasticsearch 是记住每本书放在哪里的图书管理员，Kibana 是墙上的查询大屏，MCP 是翻译员，AI Agent 是会帮你办事的值班同学。你问“哪一类事故最多”，值班同学不会凭印象回答，而是让翻译员去问图书管理员，然后把查到的书名和页码一起交给你。 ELK 三件套到底是什么 Elasticsearch：不是数据库替代品，而是搜索与分析引擎 Elasticsearch 将文档建立倒排索引，擅长全文检索、时间范围过滤、多条件查询和聚合统计。日志场景中，一条日志通常是一份 JSON 文档，包含时间、服务、级别、消息、状态码、耗时、链路标识等字段。它最像一本超级厚的词典。普通数据库像按页码翻书；倒排索引则像先做“关键词 → 出现位置”的目录。因此当日志达到百万甚至亿级时，仍然可以快速回答“过去 10 分钟 payment 服务出现了多少次 504”。

别再手点虚拟机了：Proxmox VE 接入 AI Agent 手把手教程，默认只读也能自动巡检

Sat, 11 Jul 2026 02:30:00 +0800

很多人第一次听到“让 AI 管 Proxmox VE”，脑子里出现的画面是：对 AI 说一句话，它就能创建虚拟机、扩容磁盘、重启服务，甚至自动修复故障。这个方向没有错，但真正安全的起点不是“把管理员密码交给 AI”，而是给 AI 一张只读、可撤销、可限制范围的门禁卡。本文会从零解释 Proxmox VE、API Token、MCP 和 AI Agent 的关系，给出人工配置与 Agent 自动配置两条路线，并提供 Windows 11、Ubuntu 26.04、macOS 26 三套一键脚本。图：本文自制题图。AI Agent 不应拿到机房“万能钥匙”，而应通过受限 Token 和 MCP 桥接访问 Proxmox VE。先说结论如果你只想记住最重要的内容，请记住下面几句话： Proxmox VE 是一套开源虚拟化管理平台，可以集中管理物理节点、KVM 虚拟机、LXC 容器、存储、网络、备份与集群。 AI Agent 不能凭空理解 Proxmox VE，它需要一个“翻译员”。本文使用本地运行的 MCP Server，把 Agent 的工具调用翻译成 Proxmox REST API 请求。第一阶段只授予 PVEAuditor，并保持 PROXMOX_ALLOW_ELEVATED=false。此时 AI 可以盘点和巡检，但不能开关机、删除或修改资源。 API Token 要单独创建、单独授权、随时可撤销，不要把 root 密码写进 Agent 配置。接入成功的标准不是“配置文件没报错”，而是 Agent 能列出工具、Proxmox 返回合法数据、权限边界符合预期，而且写操作确实被拒绝。 Proxmox VE 到底是什么 Proxmox Virtual Environment，通常简称 Proxmox VE 或 PVE，是一套面向服务器虚拟化的开源平台。它把几个原本需要分别维护的能力放进同一个管理平面：

别再到处找 YOLO 开关了：6 个 AI Agent 一键进入高自主模式

Mon, 06 Jul 2026 09:50:00 +0800

先说结论

AI Agent 工具里的 yolo，本质不是“更聪明”，而是“少问你”。它会减少或跳过工具调用确认框，让 Agent 更像无人值守脚本一样连续执行。问题在于，不同工具的叫法完全不统一：Codex 是危险旁路 approval 和 sandbox；Claude Code 是跳过权限检查或使用 bypass 权限模式；Gemini CLI 和 Qwen Code 有 --approval-mode=yolo；OpenCode 是 --auto 加 permission 规则；Aider 是 --yes-always。

这篇文章给出一个统一做法：不要偷偷覆盖原来的 codex、claude、gemini 命令，而是安装一个显式的 agent-yolo 启动器。你想高自主时才输入 agent-yolo codex、agent-yolo claude、agent-yolo gemini。这样一次搞定常见 Agent 的 YOLO 命令，又不会把日常安全模式改坏。文中脚本覆盖 Windows 11、Ubuntu 26.04、macOS 26，不依赖第三方服务，不安装缺失工具，也不包含任何真实内网地址、完整计算机名、私有域名、令牌或密钥。

Ubuntu 26.04 新装机第一刀：不想被 Snap 绑架，就这样干净卸掉它

Mon, 06 Jul 2026 09:45:00 +0800

先说结论

Ubuntu 26.04 新装系统后，如果你明确不想使用 Snap，可以卸载。正确姿势不是上来就 rm -rf /snap，而是先确认系统里有哪些 Snap 应用，迁移重要数据，再按顺序 snap remove --purge，最后 apt purge snapd 并清理残留目录。

本文给出完整背景、风险边界、人工执行方法、Agent 自动配置方法，以及 Windows 11 / Ubuntu 26.04 / macOS 26 三种一键脚本。脚本默认只预演，真正执行必须显式开启，不依赖第三方服务，也不包含任何真实内网地址、真实计算机名、私有域名或密钥。

Docker 容器无限重启？只因 v3.7.0 少了一个 serve —— 思源笔记 CLI 破坏性变更修复实录

Thu, 02 Jul 2026 19:30:00 +0800

先说结论

把思源笔记从 v3.6.x 升级到 v3.7.0 后，Docker 容器陷入无限重启循环。docker logs 显示 Error: unknown flag: --accessAuthCode。根因是 v3.7.0 引入了 CLI 子命令架构，原来的顶级 flag 现在需要加一个 serve 子命令。修复只需在 docker-compose.yml 的 command 字段最前面加上 'serve'，多 7 个字符，从无限重启到正常运行。

本文给出完整排查过程、三种操作系统下的一键修复脚本（Windows 11 / Ubuntu 26.04 / macOS 26），以及人工执行和 AI Agent 自动配置两种方法。所有脚本只调用 Docker CLI 和 SSH，不依赖第三方服务。

别再一个个点更新了：让 Agent 一次管好 Windows 11、Ubuntu 26.04 和 macOS 26 的常用软件升级

Sun, 28 Jun 2026 08:58:00 +0800

先说结论

常用软件升级这件事，最痛苦的不是命令复杂，而是它分散在三个世界里：Windows 11 有 WinGet、Microsoft Store 和传统安装器；Ubuntu 26.04 有 apt、snap、flatpak 和服务重启；macOS 26 有系统更新、App Store、Homebrew 和一堆手动下载的应用。人手工做，很容易漏；让 AI Agent 做，如果不给边界，又可能太激进。

我的建议是：把 Agent 当成“值班更新管理员”，让它先盘点、再预演、再执行、最后验收。本文给出三套不依赖第三方升级助手或云端服务的一键脚本，分别覆盖 Windows 11、Ubuntu 26.04 和 macOS 26；同时给出人工自动执行和 Agent 自动配置两种方法。脚本只调用系统已有的更新入口和已经配置好的包管理器，不包含任何真实内网地址、完整计算机名、私有域名或密钥。

电脑越用越满？让 AI Agent 安全清掉 Windows 11、Ubuntu 26.04 和 macOS 26 的垃圾文件

Sun, 28 Jun 2026 07:15:00 +0800

先说结论

清理垃圾文件这件事，最怕的不是“清不干净”，而是“清得太猛”。Windows 11、Ubuntu 26.04、macOS 26 上真正值得自动化清理的，通常是临时目录、包管理缓存、旧日志、回收站或废纸篓、可再生成的缓存文件；不应该让脚本随手碰用户文档、照片、浏览器 Profile、密钥、证书、虚拟机镜像和业务数据。

这篇文章给出两条路：人工自动执行，也就是你自己复制脚本，先 dry-run 看清楚，再加执行开关；Agent 自动配置，也就是把清理目标、边界、预演、确认和验收交给 Codex、Claude、OpenClaw、HermesAgent 等 Agent 执行。三套脚本分别覆盖 Windows 11、Ubuntu 26.04、macOS 26，不依赖第三方服务，不下载清理软件，也不包含任何真实内网地址、真实计算机名、私有域名或密钥。

别再让 Agent 吞掉你的 Token：我把 Headroom 接到 NewAPI、OpenClaw 和 HermesAgent 的完整实战

Sat, 20 Jun 2026 12:30:00 +0800

先说结论

这次我没有替换原来的 NewAPI，也没有让 OpenClaw / HermesAgent 直接改用一个不确定的新网关。真正做法是：在 NewAPI 前面加一层 Headroom 代理，把所有已经使用 OpenAI-compatible 协议的调用改到 http://<headroom-host>:8787/v1，而原来的 NewAPI 入口继续保留。这样 Agent 发来的长上下文先经过 Headroom 压缩，再转发给 NewAPI，最后仍由 NewAPI 统一路由到后端模型。

最关键的原则只有一句：先测试，后修改；只迁移测试通过的 OpenAI-compatible 项；非 OpenAI 协议的 fallback 不碰。 这篇文章既是复盘，也是一份可以直接交给 Agent 或人工照着执行的操作指南。

一句话让 Claude 把 Ubuntu 22.04 升级到 24.04:一次几乎不用盯屏幕的跨 LTS 实战

Fri, 19 Jun 2026 10:58:00 +0800

先说结论

这台远端机器是家里那台 24 小时开机的代理机,系统一直停在 Ubuntu 22.04.4 LTS(jammy),内核 5.15。一句"帮我把 192.168.103.182 升级到 ubuntu24.04",Claude 就替我拆开了旧柜子,在另一个房间装上了新柜子,过程中它自己开了 tmux 守夜、自己起了 fallback sshd 备胎、自己用 do-release-upgrade -f DistUpgradeViewNonInteractive 跑完了整段流水线。25 分钟后主机回来,内核已经是 6.8.0-124,所有服务依旧在听。

本文不是讲 do-release-upgrade 怎么用,那是 Ubuntu 官方文档的事;本文是讲"当 Agent 拿到 SSH 之后,它在做什么、为什么这么做、以及哪些坑你必须提前排"。

Markdown 王座崩塌：当 AI Agent 走出聊天框，HTML 成为新答案

Wed, 10 Jun 2026 10:00:00 +0800

如果说 2023 年是属于 ChatGPT 与 Markdown 的"聊天框时代"，那么 2026 年正在宣告一个新阶段的到来：AI 不再只是"回答"你，它要"接管"你的界面。当 Agent 开始直接控制浏览器、操作 SaaS、构建可交互的应用原型时，Markdown 曾经作为 LLM 输出的"事实标准"——那个简洁、可读、token 友好的优雅格式——正在迅速暴露出它作为"最后一公里"的致命短板。HTML，不是 Markdown，正在成为新一代 Agentic 输出的新答案。一、导言：Markdown 的王座，是怎么建起来的？要理解这场变革的迫切性，我们得先回到 Markdown 当年"加冕"的历史现场。 2004 年，John Gruber 写下了一行看似不起眼的 Perl 脚本，目标极其朴素：让写网页的人能够用一种"读起来像写好的文章"的纯文本格式写作。Markdown 的设计哲学是"少即是多"——用 *斜体* 而不是 <em>斜体</em>，用 # 标题而不是 <h1>标题</h1>。它的成功，本质上是一次"人类可读性“对”机器可表达性“的胜利。二十年过去了。Markdown 早已不再只是博客圈的极客玩具，它渗透进了几乎所有数字写作场景：GitHub 的 README、Reddit 的评论、Notion 的文档、Discord 的消息、Slack 的频道、Jupyter Notebook 的单元格……它成了互联网”默认书写协议"。而真正让 Markdown 登上 AI 王座的，是 2022 年末 ChatGPT 的横空出世。 OpenAI 在训练 GPT-3.5/4 时，让模型生成 Markdown 几乎是"母语级别的本能"——因为整个互联网的代码、文档、Stack Overflow 答案、技术博客，全是 Markdown 的海洋。当一个格式占据了 80% 的训练语料，它就不再是"一种格式"，而成了模型的"母语"。

OpenClaw TUI 变复读机？thinking 和回复重复的临时止血手册

Tue, 02 Jun 2026 10:42:00 +0800

先说结论

如果你在 OpenClaw TUI 里看到同一段 thinking 重复出现、同一段回复正文连续出现两遍，先不要急着清空模型、删除 session 或者怀疑所有 provider 配置都坏了。这个问题很可能不是“历史消息太多”，也不一定是模型真的想复读，而是 OpenAI-compatible 流式响应里同时出现了增量 delta 和额外的完整 message，OpenClaw 某些版本在上层聚合时把两份内容都算进去了。

临时解决思路很简单：备份本地安装文件，在 OpenClaw 的运行聚合层增加一个非常保守的去重保护；它只处理“同一轮、同一模型、完全重复的 text/thinking 块”，然后重启 gateway，用 marker 测试确认 TUI 和 session 落盘都只剩一份内容。

本文是一份可复用的临时修复记录。所有路径、模型名、网关地址和 Token 都做了脱敏处理，真实环境请用自己的安装路径和模型名替换。不要把本文里的占位符当成真实配置直接复制。

MiniMax M3 正式发布:稀疏注意力 MSA 是什么神仙架构?顺手深扒一下 Mavis 的沙箱

Mon, 01 Jun 2026 22:00:00 +0800

6 月 1 日,稀宇科技正式发布新一代通用模型 MiniMax M3。他在编程、超长上下文和原生多模态三条科技树上同时点满,而且全球唯一开源。同一天,我顺手在 Mavis 里跑了几个小时的探索,把背后那个看不见的沙箱摸了一遍 —— 顺便把这份体验 + 这段时间的用量数据 + 一个邀请链接一起整理给你。

特别声明: 本文 100% 全部由 MiniMax-M3 撰写生成，包括全部代码段、图表设计与大纲架构，未经过任何人工修改或二次润色。

更新说明(2026-06-01 22:00):本文发布后,官方针对 Token Plan 改版又发了一版补充公告,承认此前的迁移方案在沟通和老用户限额问题上考虑不周,并给出了补偿方案和退款通道。本文末尾新增了 第九节"Token Plan 改版最新公告",正在或打算订阅 Token Plan 的朋友务必读完再下单。

一次流式响应被重复消费：NewAPI v1.0.0-rc.10 MiniMax 转发 Bug 排查实录

Sun, 31 May 2026 18:00:00 +0800

先说结论

问题现象：AI Agent 在 DingTalk 通道中回复了重复的文本。消息不是发送了两次，而是一条消息里的内容被复制了一遍。排障最终定位到 NewAPI（QuantumNous 维护的 OneAPI 分支）v1.0.0-rc.10 版本的一个流式响应 Bug：当通过 OpenAI Chat Completions 协议转发 MiniMax 模型时，finish chunk 会同时包含 delta.content 和 message.content，且两者内容完全一致。Agent 框架的流式处理器将两者都当作"可见文本"消费，导致最终文本被拼接两次。修复方案也很朴素：将 OpenClaw provider 协议从 openai-completions 切换到 anthropic-messages，OneAPI 原生支持该协议，且该路径下流式响应正常。

本文不会出现任何真实内网地址、Token、模型 ID 或私有路径。所有配置片段都已脱敏。

macOS LaunchAgent 里的 Python 程序连不上外网？一文搞懂 httpx 代理陷阱的完整排查与修复

Sat, 30 May 2026 09:00:00 +0800

先说结论：

macOS 的 LaunchAgent 环境下，Python httpx 库会自动读取系统代理设置（scutil --proxy），但 LaunchAgent 进程可能根本无法访问该代理服务器——于是请求静默失败，报错 All connection attempts failed 或 No route to host。

解决方案只需要一行：在 LaunchAgent 的 plist 文件中添加 NO_PROXY=*。

这篇文章记录了我从发现 AI Agent 企业微信消息不回复、到逐步排查代理问题、最终定位到 macOS 系统代理与 LaunchAgent 网络隔离的完整过程。涉及 Python httpx 源码分析、macOS 代理机制深度解析、以及 LaunchAgent 运行环境的诸多坑点。

从零开始的 AI Agent 完整迁移实战：踩坑九九八十一难后的通关攻略

Sat, 30 May 2026 08:00:00 +0800

先说结论：

从一个 AI Agent 平台迁移到另一个平台，听起来像是「复制粘贴」的事情，实际上却是一场涉及数据迁移、渠道对接、定时任务、自动启动、代理配置、模块兼容性的系统工程。

这篇文章记录了我从零开始完成一次 AI Agent 完整迁移的全过程：从安装新平台、迁移记忆和技能、配置消息渠道、排查各种诡异问题，到最终实现全自动运行。涉及 9 个踩坑点和对应的解决方案，希望能帮到有类似需求的朋友。

Claude Code 一升级就全模型 400：别急着换 Key，可能是网关没跟上新版协议

Fri, 29 May 2026 15:30:00 +0800

先说结论

这次故障的表象非常吓人：Claude Code 更新之后，不管访问哪个模型，都会立刻报 API Error: 400 invalid params, chat content has invalid message role: system (2013)。如果只看错误，很容易怀疑 API Key 失效、模型下线、余额不足、代理坏了、环境变量乱了，甚至怀疑所有模型同时挂掉。真正的根因不是这些，而是新版 Claude Code 发出的请求结构和某些 Anthropic-compatible 模型网关之间出现了兼容断层：网关把不该出现在 chat content 中的 system role 当成非法消息拒绝了。

最小可用修复也很朴素：先用最小 prompt 复现，再对相邻版本做二分式验证。最终确认 2.1.150 能正常返回，2.1.154 和 2.1.156 会复现 400，于是把全局 Claude Code 固定回 2.1.150。这不是“玄学回滚”，而是基于证据找到最后一个已知可用版本。

这篇文章记录一次 Claude Code 本地环境排障。它不是一个复杂到需要改源码的问题，但很有代表性：AI Agent 工具链越来越依赖模型网关、兼容协议、环境变量、版本更新和本地 provider 切换；当其中一层发生协议细节变化时，终端里看到的却往往只是一句抽象的 400。

为了避免泄露任何隐私信息，本文不会出现真实内网地址、真实用户名、真实 token、真实私有 provider 名称、真实本机路径或私有服务域名。所有配置片段都使用 <PLACEHOLDER>、<MODEL_GATEWAY>、<MODEL_NAME> 等占位符表示。文章重点是分享排障方法，而不是公开某个具体环境。

AI 助手为什么把一句话复读四遍：一次 OpenClaw 微信通道排障复盘

Fri, 29 May 2026 11:24:29 +0800

先说结论

这次问题看起来像“微信通道把同一条回复发了四遍”，但真正的重复发生在更早的位置：消息还没有进入微信发送层之前，OpenClaw Agent 的最终可见文本就已经被模型执行链路重复拼接了。排障的关键不是一上来改微信插件，而是把链路拆成发送层、会话层、模型路由层三段，用最小 prompt 复现，再比较“兼容网关路径”和“原生 provider 路径”的输出差异。最后的修复也很朴素：让个人 IM 通道显式走原生 provider，移除容易被误选的故障候选模型路径，重启 Gateway 后复测主会话。

这篇文章不会出现任何真实内网地址、账号、token、会话 ID、个人微信标识或私有路径。所有配置片段都已经脱敏，并用 <PLACEHOLDER> 形式表示。重点是分享一套可复用的排障方法，而不是公开某个具体环境的细节。

OpenClaw 升级指南：从入门到精通的完整攻略

Fri, 29 May 2026 09:00:00 +0800

先说结论

OpenClaw是一款强大的个人 AI 助手，支持多种消息渠道和 AI 模型。升级 OpenClaw 其实非常简单，最推荐的方式是使用 openclaw update 命令。本文将详细介绍各种升级方式，包括从 npm 包安装到 git 源码安装的切换，以及升级后的验证和回滚策略。

本文所有示例都使用公开项目、公开链接和占位符，不包含真实服务器地址、账号、Token、业务配置或任何内网信息。文中配图来自 OpenClaw 官方仓库和文档，内容按其 MIT 授权引用。

别等 Codex 额度归零才后悔：这个“重置雷达”能提前亮灯

Sun, 24 May 2026 08:10:00 +0800

先说结论

最近 Codex 的额度重置变得比以前更值得关注：有时是常规周期，有时是服务故障后的补偿性重置，有时是限额消耗异常后的官方修复。对重度 Codex 用户来说，真正尴尬的不是“额度被重置”，而是“我明明还剩不少周额度，却在重置前没有及时用掉”。

Codex 重置雷达 做的事情很简单：把官方状态页、官方/社区公开动态、历史重置窗口和当前预测信号聚合起来，判断是否出现“即将或正在重置”的窗口。它不是魔法预测器，也不是 OpenAI 官方服务；它更像一个面向 Codex 用户的早期预警看板：当信号足够强时，提醒你赶紧把当前周期剩余的 Codex 周额度用在真正需要的任务上。

本文只讨论公开信息、公开网页和公开状态信号，不包含任何私有账号、Token、真实业务系统、内网地址或个人使用数据。文中提到的“额度”“重置”“速蹬窗口”都是面向普通 Codex 用户的体验分析，不构成对 OpenAI 官方计费、订阅或服务策略的承诺。

MCP 明明没配错，为什么一启动就挂？一次 Codex MCP 故障的完整拆解

Sat, 23 May 2026 06:10:00 +0800

先说结论

这次故障最容易误判的地方，是表面错误写着 “MCP Client 启动失败”“MCP Server 握手失败”，于是人很自然会去怀疑 MCP 配置、插件开关、网络、Token、JSON 格式、stdio 协议，甚至怀疑 Codex 本身挂了。但真正的根因并不在 MCP 协议层：某个 MCP Server 对应的本地二进制在启动瞬间就被 macOS 动态链接器杀掉了，根本没有机会完成 initialize 握手。Client 看到的只是连接提前关闭，Server 端真正留下的线索是 dyld: Symbol not found，缺的是 Swift Concurrency runtime 里的一个符号。

换句话说：MCP 没有来得及失败，Server 进程先死了。

这篇文章记录一次很典型、也很容易绕远路的 Agent 工具链故障：Codex 里 MCP Client / MCP Server 启动异常。它不是一个“修改配置就好”的问题，而是一个从应用层错误一路追到本地二进制、动态链接器、Swift runtime 兼容性的排障过程。

为了避免泄露任何隐私信息，本文不包含真实内网地址、真实用户名、真实会话 ID、真实本机绝对路径、Token、私有仓库地址或任何业务系统名称。文中路径都使用 ~、<USER_HOME>、<PLUGIN_DIR>、<PROJECT> 等占位符表示；命令输出也只保留与判断根因有关的公开技术字段。

别再让 Agent 瞎画界面：UI UX Pro Max 安装与正确使用指南

Fri, 22 May 2026 22:50:00 +0800

先说结论

UI UX Pro Max 不是一个“让 Agent 变会审美”的魔法提示词，而是一套可以被 Claude Code、Codex、Cursor、Windsurf、Gemini、OpenCode 等 Agent 调用的 UI/UX 设计知识库与搜索型 Skill。它把产品类型、行业、视觉风格、色彩、字体、落地页结构、图表、可访问性、前端技术栈建议等内容整理成可查询的数据和脚本，让 Agent 在动手写页面之前先生成一套设计系统，再按设计系统实现。

正确姿势不是“装完以后继续一句话让它做个好看的页面”，而是让 Agent 先调用 search.py --design-system，再补充 UX、图表、技术栈查询，最后把这些结果落到组件、布局、颜色、动效和验收清单里。这样做的价值很直接：减少 AI 紫色渐变、千篇一律 Hero、低对比度文字、移动端溢出、卡片套卡片、按钮没有 hover/focus 状态这些常见 Agent UI 问题。

本文只使用公开资料、公开仓库和干净示例目录中的验证结果。文中的命令、路径、项目名均为通用示例，不包含任何真实内网地址、账号、密钥、业务项目名或个人配置。截图来自公开参考页面和一次隔离目录中的安装/使用验证，不包含隐私信息。

Gemini 3.5 不只是更快：Google I/O 把 AI 战场推向“会干活的代理”

Wed, 20 May 2026 07:05:00 +0800

先说结论

Google I/O 2026 这次最值得关注的，不是又多了一个聊天模型，而是 Google 把 Gemini 3.5 明确推向了“行动层”：首发的 Gemini 3.5 Flash 已经进入 Gemini App、Search AI Mode、Google Antigravity、Gemini API、Android Studio、Gemini Enterprise Agent Platform 和 Gemini Enterprise。Google 官方给出的关键词是 frontier intelligence with action，翻译成人话就是：模型不只是回答你，而是要在工具、代码、文件、搜索、企业流程里替你连续干活。

本文只整理 Google 官方公开资料和公开大会信息，并在此基础上做行业影响分析。文中图片均来自 Google 官方博客公开配图，未包含任何个人账号、内部网络、密钥、私有系统截图或非公开信息。

别再远程桌面点点点：让 AI Agent 用 SSH 直接接管 Windows

Wed, 13 May 2026 08:10:00 +0800

先说结论

让 AI Agent 从 Linux 或 macOS 管理 Windows，并不一定要走远程桌面、VNC、商业远控软件，也不一定要额外装一套奇怪的 Agent Runtime。对大多数个人工作站、实验机、开发机和内网服务器来说，最简单、最干净、最容易被自动化工具理解的方案，就是在 Windows 上启用系统自带的 OpenSSH Server，然后从 Linux/macOS 直接执行：ssh <user>@<windows-host>。

真正需要做好的只有三件事：第一，Win10 / Win11 正确安装并启动 OpenSSH Server；第二，在 Linux/macOS 生成 SSH key，把公钥放到 Windows 对应位置；第三，如果登录用户属于 Windows 管理员组，要把公钥写入 C:\ProgramData\ssh\administrators_authorized_keys，并用 icacls 收紧权限。完成以后，AI Agent 就可以像操作 Linux 一样，用 SSH 在 Windows 上执行 PowerShell、复制脚本、读取日志、安装工具和做自动化运维。

本文所有命令、截图和主机信息都使用通用占位符，不包含真实内网地址、真实用户名、真实机器名、密钥、Token 或私人路径。你只需要把 <user>、<windows-host>、<windows-ip> 这类占位符替换成自己的环境值即可。

Codex 0.130 后 /approvals 没了？别慌，权限开关都搬到启动参数了

Tue, 12 May 2026 18:50:00 +0800

先说结论

如果你升级到 Codex 0.130.0（很多人会口头叫 Codex 0.130）之后，发现以前习惯在会话里用的 /approvals 不见了，不要急着回退版本。现在更稳定的做法，是在启动 Codex 时就把权限策略说清楚：用 --ask-for-approval 控制什么时候询问，用 --sandbox 控制命令能操作哪些文件，确实处在外部隔离环境里时，再使用 --dangerously-bypass-approvals-and-sandbox 一次性跳过确认和沙箱。这个长参数也可以直接写成 --yolo，更方便记忆和输入，也更接近 Gemini 等工具里常见的命名习惯。

换句话说，思路从“进会话后再临时切权限”，变成“启动前就选择运行档位”。这篇文章会把常用参数、推荐组合、风险边界和 shell alias 写法一次讲清楚。

本文只讨论公开的 Codex CLI 参数和通用工作流，不包含任何真实主机、内网地址、用户名、Token、私有路径或业务项目名。所有命令都用 <PROJECT>、<TASK> 这类占位符表示，你可以按自己的环境替换。

国产小模型不稳定？别急着换模型，先给你的 Agent 装上 Superpowers

Thu, 07 May 2026 16:43:10 +0800

先说结论

很多 Agent 工作流里所谓“国产模型不稳定”，表面看是模型一会儿聪明、一会儿犯糊涂，真正落到工程现场，常常是两个问题叠在一起：一是模型本身参数规模、训练数据和工具调用稳定性确实不如顶级闭源大模型；二是 Agent 没有稳定的方法论和检查点，导致每一次任务都靠即时发挥。前者短期内不一定能解决，后者可以马上解决：给 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 这类 Agent 安装一套可复用的 Skill 工作流，例如 Superpowers。

Superpowers 不能把小模型“魔改”成大模型，也不能保证所有国产模型突然拥有顶级推理能力。它真正有价值的地方，是把 Agent 的行为从“靠灵感输出”拉回“按流程工作”：先澄清目标，再写设计，再拆计划，再测试，再审查，再验证。对参数较少、上下文保持能力较弱、输出波动较大的模型来说，这种外置流程约束往往比继续堆提示词更有效。

这篇文章想聊一个很现实的问题：当我们把 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 乃至更多 Agent 放进日常工作流之后，为什么某些模型看起来特别不稳定？又为什么我会建议先安装 Superpowers 这样的 Skill，而不是第一反应就去换模型、加提示词、调温度或者把系统提示写成一篇论文。

为了避免泄露任何隐私信息，本文所有环境、路径、主机、账号、项目名都使用通用示例，不包含真实内网地址、密钥、业务系统名称或个人配置。文中的命令也以官方公开文档和通用安装方式为准，实际使用前请结合你自己的 Agent 版本确认。

OpenClaw / HermesAgent 的最佳归宿：Proxmox VE

Wed, 29 Apr 2026 10:00:00 +0800

OpenClaw / HermesAgent 的最佳归宿：Proxmox VE

如果只把 OpenClaw 或 HermesAgent 看成一个“能聊天的机器人”，那它装在哪里似乎都无所谓：实体机可以，VPS 可以，Docker 也可以，甚至日常用的笔记本也能跑起来。

但只要它开始接入消息渠道、执行命令、读写文件、调用浏览器、保存长期记忆、定时跑任务，这个问题就不再是“能不能安装”，而是“它应该被放进什么样的运行边界里”。

我的结论很明确：OpenClaw / HermesAgent 这类长期运行的个人智能体，最稳妥的归宿不是直接装在实体机上，而是安装在 Proxmox VE 里的专用虚拟机中。

这里的重点不是 PVE 有多高级，而是它刚好解决了智能体运行时最难缠的三件事：数据隔离、计算资源隔离、备份与恢复。

关于

Wed, 13 Jan 2021 17:34:15 +0800

魔都水滴 AI Infrastructure Engineer 这里记录我在 AI Agent、Cloud Platform、Self-hosting 和 Engineering 方向上的长期实践。我更关心一套系统能不能真正运行起来、稳定下来，并且在出现问题时能够被定位和修复。因此，博客内容主要来自真实环境中的部署、迁移、排障、自动化和复盘，而不是只整理一份“看起来能用”的教程。我长期关注什么 AI Agent：Coding Agent、MCP、共享记忆、模型网关和 Agent 工作流 Self-hosting：Docker、NAS、Proxmox VE、家庭实验室和网络基础设施 Engineering：Linux、Java、Go、数据库、性能、可观测性和线上事故 Cloud Platform：服务部署、自动化、权限、Token 管理和生产环境实践这些方向并不是彼此孤立的。我的兴趣是把 AI 能力放进真实的工程系统里：有数据、有权限、有监控，也有明确的失败边界和回滚方式。文章会写什么我通常会尽量保留：起因和背景：问题在什么环境里出现，原本的目标是什么。验证过程：实际执行了哪些命令、观察到什么现象，以及哪些尝试没有奏效。根因和修复：为什么会出问题，最终改变了什么。验收方式：如何证明服务恢复、配置生效或部署真的上线。如果文章涉及线上环境、机器或内部系统，会对敏感信息做脱敏处理。推荐阅读路径第一次来：从 Start Here 了解完整主题地图。想看最新实践：浏览归档。想按技术检索：浏览标签。想看代码和自动化：访问 GitHub。其他入口资源下载站 GitHub 关注微信公众号：ClawLoader 关注微信公众号扫描下方二维码关注 ClawLoader，获取 AI Agent、Self-hosting 和工程实践更新。这个博客会继续以中文为主，并在值得长期参考的文章上补充英文版本。欢迎通过文章底部的评论区交流，也欢迎指出实践中的遗漏和错误。