<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>MacOS on 魔都水滴</title>
    <link>https://blog.margrop.net/tag/macos/</link>
    <description>Recent content in MacOS on 魔都水滴</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Wed, 29 Jul 2026 20:30:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/tag/macos/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>电脑从不“突然坏掉”：看懂日志，十分钟学会像侦探一样排障</title>
      <link>https://blog.margrop.net/post/%E7%9C%8B%E6%97%A5%E5%BF%97-log-reading-art/</link>
      <pubDate>Wed, 29 Jul 2026 20:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/%E7%9C%8B%E6%97%A5%E5%BF%97-log-reading-art/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;电脑很少会“毫无征兆地坏掉”。大多数时候，它早就把线索写进了日志：某个磁盘逐渐变满、某个服务先出现警告、某次 DNS 查询失败、某个进程反复启动又退出。真正的排障，不是看到红色报错就马上重装系统，而是像侦探一样回答五个问题：&lt;strong&gt;什么时候发生？谁发生了？严重程度怎样？前后还发生了什么？修好后能不能验证？&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;这篇文章不把日志讲成只有工程师才懂的黑话，而是把它比作电脑每天写的日记。你会看到 Windows 11、Ubuntu 26.04 和 macOS 26 的真实采集输出，拿到三套不依赖第三方服务的只读脚本，还能把同一套思路交给 Agent 自动执行。即使你是小学生，也应该能看懂其中大部分；如果你是开发者或运维人员，则可以直接把方法带回生产环境。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>重启不是玄学：电脑为什么一关一开，就像治好了 99% 的毛病？</title>
      <link>https://blog.margrop.net/post/why-restart-fixes-99-percent-%E9%87%8D%E5%90%AF/</link>
      <pubDate>Wed, 29 Jul 2026 08:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/why-restart-fixes-99-percent-%E9%87%8D%E5%90%AF/</guid>
      <description>先说结论&#xA;重启不是魔法，也不是把所有故障都修好了。它更像是把一间住了很久、已经乱到找不到东西的房间清空：借出去但没归还的物品被收走，排队的人重新取号，临时便签被撕掉，门锁和电器重新检查。系统因此回到了一个更干净、更容易预测的起点。&#xA;所以，“重启解决了问题”通常意味着：故障藏在易失状态里，而不是硬件已经坏掉、配置一直错误或程序本身存在根因。&#xA;你一定见过这样的场景：浏览器突然打不开新标签页，文件明明存在却提示“正在使用”，远程桌面连不上，风扇像小飞机一样转，内存还剩很多却不停卡顿。你先关一个窗口，再关几个程序，最后抱着“试试看”的心态重启。&#xA;电脑重新亮起来后，刚才那个很难解释的毛病消失了。&#xA;这就是大家常说的“重启能解决 99% 的问题”。它当然不是一个经过严格统计的 99%，而是一种非常生动的工程经验：很多问题不是永久损坏，而是系统在长时间运行中积累了太多没有及时清理的临时状态。&#xA;图 1：重启像把“住乱了”的系统清场复位。原创配图。&#xA;把电脑想成一间一直有人使用的房间 刚搬进去时，房间很整齐。桌上只有一台电脑，柜子里有几份文件，门口有两双鞋。&#xA;但如果这间房连续住三个月，却从来不做大扫除，会发生什么？&#xA;快递盒越来越多，虽然每个盒子都不大，但过道被堵住了。 借出去的剪刀、充电器和钥匙没有归还，东西并没有“消失”，只是没人知道它在哪里。 门口排着很多人，已经离开的客人还占着号码。 桌上贴满旧便签，大家仍然按照过期的便签做决定。 两个人各自拿着一把钥匙，互相等对方先开门，谁都不愿意松手。 系统里的“房间”就是内存、文件句柄、网络连接、线程、锁、缓存、驱动状态和各种服务上下文。它们有一个共同特点：启动时会被建立，运行中会被修改，退出或重启时才有机会统一回收。&#xA;下面这张图把最常见的四种“乱”放在了一起。&#xA;图 2：状态泄漏、内存碎片、连接堆积，以及锁和旧缓存，是重启经常能缓解的四类问题。&#xA;状态泄漏：借出去的东西没有放回原位 “泄漏”不一定是水从水管里流出来。对程序来说，泄漏更像是“借了资源，但忘了归还”。&#xA;程序打开一个文件，系统会给它一个文件描述符；程序创建一个网络连接，系统会保存连接状态；程序申请一块内存，分配器会记住这块空间归谁使用。如果程序退出时没有正确关闭，或者它一直运行、从来不退出，那么这些资源就可能持续占着位置。&#xA;一次泄漏可能小得几乎看不见。比如每处理一千个请求只多留一个句柄，一天之后可能没有任何感觉；几周之后，系统却开始提示“打开文件太多”“无法创建线程”或“连接失败”。&#xA;这就是为什么重启一个服务有时比“再点一次按钮”有效：服务进程结束后，操作系统会回收该进程名下的内存、句柄、线程和连接。房间里那些没有登记归还的物品，会随着住客离开而被物业统一收走。&#xA;macOS 的 vm_stat 会把虚拟内存拆成很多页来观察；Linux 则常见 /proc/meminfo、free 和进程的 RSS。它们不是“电脑健康分数”，而是帮助我们确认房间里到底堆了什么。&#xA;图 3：真实的 macOS vm_stat 输出。数字会随机器和时间变化，重点是观察趋势，不是迷信某个固定值。&#xA;内存碎片：柜子还有缝，却塞不进大箱子 很多人看到“可用内存还有几 GB”，就会问：既然还有空间，为什么程序还是申请失败？&#xA;因为“总空位”不等于“连续的大空位”。&#xA;把内存想成一个有很多格子的柜子。程序先放入一个小盒子，又拿走另一个盒子，再放入一个大箱子。经过很多次申请和释放以后，柜子可能到处都有小缝，但没有一块连续的空位能放下大箱子。&#xA;这就是内存碎片最容易理解的版本。真实系统比这个复杂：用户态分配器、内核页分配器、不同大小的对象、内存映射和缓存都会影响布局。现代操作系统会尽力复用和整理空间，但整理本身也需要时间，并且并非所有内存都能随便移动。&#xA;图 4：蓝色格子表示已占用区域，浅色格子是分散的空位；“还有空位”并不代表能满足连续大块分配。&#xA;Linux 内核文档把 compaction（内存压缩整理）描述为把可移动页搬到一起，从而形成更大的连续空闲区域。这个过程像把衣柜里的小衣物先集中到一侧，让另一侧腾出完整空间，但它不是免费的：搬东西需要 CPU，也受不可移动页、正在使用的页和分配时机影响。&#xA;因此，重启有时会让内存表现“突然变好”，并不是重启凭空创造了内存，而是旧进程、旧映射和旧缓存全部结束后，新的进程在更干净的布局上重新分配。&#xA;图 5：真实的 Ubuntu free -h 与 ss -s 汇总。文章只保留统计项，不展示地址或机器名。&#xA;连接堆积：窗口有限，旧号码却没清掉 网络连接可以想成银行窗口。&#xA;服务器只有有限数量的连接槽位、文件描述符、线程和端口。一个请求来了，系统为它分配资源；请求结束后，资源应当尽快归还。但实际网络里还有重传、超时、半关闭、连接复用和 TIME-WAIT 等状态。某些状态本来就是协议设计的一部分，不是错误；问题在于它们的数量、持续时间和业务流量不匹配。&#xA;RFC 9293 说明了 TCP 状态机中的 TIME-WAIT：主动关闭连接的一方需要在一段时间内保留状态，以避免旧报文干扰后续连接。生活中，这就像快递柜不会在包裹刚取走的一秒钟就立刻把编号交给另一个人，系统要留一点时间确认“旧包裹真的结束了”。</description>
    </item>
    <item>
      <title>别急着装电脑管家：AI Agent 到底能替代桌面上的哪些软件？一次看懂清理、优化、改配置和维修的边界</title>
      <link>https://blog.margrop.net/post/ai-agent-replace-desktop-software/</link>
      <pubDate>Sun, 19 Jul 2026 22:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/ai-agent-replace-desktop-software/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;AI Agent 可以替代一大批“只会点按钮”的桌面工具，但它不是把所有软件图标变成一个聊天框。它真正擅长的是：先看懂问题，再组合系统自带工具，执行一连串步骤，最后把结果解释给你。&lt;/p&gt;&#xA;&lt;p&gt;在文件格式转换、垃圾扫描、性能检查、配置修改和软件故障排查这五类任务里，AI Agent 对前两类的替代程度最高，对性能优化和配置修改属于“半自动”，对硬件维修只能做诊断助手，不能代替人拆机。&lt;/p&gt;&#xA;&lt;p&gt;本文用一条简单原则贯穿全文：&lt;strong&gt;先读，再写；先备份，再改变；先验证，再宣布成功。&lt;/strong&gt; 文中的脚本不依赖第三方服务，默认只扫描和生成报告，必须加参数并再次确认才会清理。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>别再盲目执行 rsync！我用 Dry Run 揪出差异文件，再安全完成增量同步</title>
      <link>https://blog.margrop.net/post/rsync-diff-incremental-sync/</link>
      <pubDate>Sat, 11 Jul 2026 13:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/rsync-diff-incremental-sync/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;code&gt;rsync&lt;/code&gt; 最值得养成的习惯，不是背更多参数，而是把同步拆成两步：&lt;strong&gt;先用 &lt;code&gt;--dry-run&lt;/code&gt; 生成差异计划，确认无误后再执行正式同步&lt;/strong&gt;。如果还会删除目标端文件，则必须把删除能力单独授权，不能让 &lt;code&gt;--delete&lt;/code&gt; 悄悄成为默认动作。&lt;/p&gt;&#xA;&lt;p&gt;文首那段 &lt;code&gt;rsync -n -avz --delete --out-format=&amp;quot;%n&amp;quot;&lt;/code&gt; 确实能看到一部分将变化的路径，但它只输出文件名，后续再靠 &lt;code&gt;grep&lt;/code&gt; 猜“哪些是文件、哪些是删除”并不稳。更可靠的做法是使用 &lt;code&gt;--itemize-changes&lt;/code&gt;，并把 &lt;code&gt;%i&lt;/code&gt; 与 &lt;code&gt;%n&lt;/code&gt; 一起输出，让每一行自己说明是新增、更新、删除还是目录属性变化。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Mac mini 别吃灰：养双 Agent，Windows 随时接管</title>
      <link>https://blog.margrop.net/post/windows-remote-desktop-mac-realvnc/</link>
      <pubDate>Sat, 11 Jul 2026 04:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/windows-remote-desktop-mac-realvnc/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;如果你的日常主力设备都是 Windows，却专门留了一台低功耗 Mac mini 长期开机运行 OpenClaw、HermesAgent 或 macOS 专属自动化任务，那么最省桌面空间的做法，不是再给它配一套显示器和键鼠，而是把它当成一台安静的“Agent 小服务器”。macOS 自带“屏幕共享”，Windows 端安装 RealVNC Viewer 后，需要配置、升级或排障时再远程接管桌面。&lt;/p&gt;&#xA;&lt;p&gt;这种组合特别适合“平时只用 Windows，Mac mini 负责 24 小时养 Agent”的家庭或个人工作室：Mac mini 功耗相对较低、体积小、运行安静，OpenClaw / HermesAgent 可以持续处理消息、自动化和定时任务；Windows 继续承担日常办公，需要查看 Agent 状态时再打开 RealVNC。&lt;/p&gt;&#xA;&lt;p&gt;真正容易踩坑的不是“软件不会装”，而是屏幕共享、用户权限、VNC 兼容密码、网络可达性，以及无人值守 Mac 的睡眠和重启恢复。本文按真实排障顺序讲清楚，并提供 Windows 11、Ubuntu 26.04、macOS 26 三套检查脚本。&lt;/p&gt;&#xA;&lt;p&gt;安全底线也先写在前面：&lt;strong&gt;不要把 VNC 常用的 TCP 5900 端口直接暴露到公网。&lt;/strong&gt; 同一局域网直接连接最简单；跨网络使用时，应先进入自建 VPN、可信内网隧道或其他受控网络，再连接 Mac。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>受够远程控制被限速？我把 RustDesk 服务端搬回自己家：多合一部署、避坑与安全加固</title>
      <link>https://blog.margrop.net/post/rustdesk-all-in-one-server-guide/</link>
      <pubDate>Fri, 10 Jul 2026 22:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/rustdesk-all-in-one-server-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;RustDesk 是一款强调开源与自托管的远程桌面工具。客户端之间能直接连接时，画面和键鼠数据优先点对点传输；直连失败时，才由中继服务转发。把服务端部署在自己控制的机器上，最大的价值不是“完全不要服务器”，而是把设备登记、中继路径、密钥、账号和日志重新放回自己的控制范围。&lt;/p&gt;&#xA;&lt;p&gt;本文使用社区维护的 &lt;code&gt;lejianwen/rustdesk-server-s6&lt;/code&gt; 多合一镜像，把 RustDesk OSS 的 &lt;code&gt;hbbs&lt;/code&gt;、&lt;code&gt;hbbr&lt;/code&gt; 与社区 API、Web 管理功能放进一个容器。它适合家庭、实验室和小团队简化部署，但&lt;strong&gt;不是 RustDesk 官方发行的多合一服务端&lt;/strong&gt;。生产环境仍需自行评估社区镜像、固定版本或镜像摘要、备份数据，并测试升级和回滚。&lt;/p&gt;&#xA;&lt;p&gt;本文所有域名都使用 &lt;code&gt;example.com&lt;/code&gt;，没有展示真实 IP、私有域名、主机名、设备 ID、账号、密钥、Token、Cookie 或镜像仓库地址。公开截图来自项目官方页面或社区仓库公开素材。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>我把 Docker 命令行装进了“驾驶舱”：Portainer 2.39.4 从部署到避坑，一篇就够</title>
      <link>https://blog.margrop.net/post/portainer-ce-docker-deployment-guide/</link>
      <pubDate>Fri, 10 Jul 2026 15:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/portainer-ce-docker-deployment-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Portainer 不是 Docker 的替代品，它更像 Docker 主机的“驾驶舱”：底层发动机仍然是 Docker Engine，Portainer 只是把容器、镜像、网络、卷和 Compose Stack 整理成网页按钮、表格与状态卡片。&lt;/p&gt;&#xA;&lt;p&gt;我用 &lt;code&gt;portainer/portainer-ce:2.39.4&lt;/code&gt; 做了一次隔离部署，完成初始化、接入本机 Docker、查看仪表盘、筛选容器、创建演示 Stack，并记录了真实截图。部署本身只要一条 &lt;code&gt;docker run&lt;/code&gt;，真正需要认真理解的却是三件事：&lt;code&gt;/data&lt;/code&gt; 必须持久化、&lt;code&gt;/var/run/docker.sock&lt;/code&gt; 权限非常高、生产环境不要把管理页面毫无遮挡地暴露到公网。&lt;/p&gt;&#xA;&lt;p&gt;本文没有展示完整 IP 地址、真实主机名、内网域名、管理员密码、Token、Cookie、私有镜像地址或生产容器名称。截图里的实验资源使用专门的演示名称，容器地址已遮盖。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>把「该睡觉了」搬出客厅：让 mac 的 launchd 每天 22:00 自动停用群晖孩子的账号，08:00 再悄悄启用</title>
      <link>https://blog.margrop.net/post/synology-mykid-curfew-launchd/</link>
      <pubDate>Sun, 14 Jun 2026 08:20:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/synology-mykid-curfew-launchd/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;群晖 DSM 控制台里其实有一个&amp;quot;停用账号&amp;quot;按钮，但它不会自动按时执行。借助 mac 自带的 &lt;code&gt;launchd&lt;/code&gt; 加一段 50 行的 &lt;code&gt;bash&lt;/code&gt; 脚本，可以做到：每天 22:00 把孩子的两个本地账号 &lt;code&gt;expired&lt;/code&gt; 标志置位，08:00 再恢复。脚本自带&amp;quot;改前查询 → 改 → 改后查询&amp;quot;的三步校验，任何一步对不上号立刻 &lt;code&gt;exit 1&lt;/code&gt;，launchd 会把执行日志写进 &lt;code&gt;StandardOutPath/StandardErrorPath&lt;/code&gt;。整件事的特别之处是**&amp;ldquo;家长&amp;quot;两个字被从对话里拿掉了**——你不用每天喊&amp;quot;该睡了&amp;rdquo;，机器会准时替你做。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;本文不打算讲一个大而全的家庭 NAS 管理方案，只围绕一件具体的事：让一个原本靠&amp;quot;人记得点&amp;quot;的操作，变成&amp;quot;到了点就自动发生&amp;quot;的纯系统级动作。&lt;/p&gt;&#xA;&lt;p&gt;如果你只想先看图，第二节那张「晚 10 点断电 / 早 8 点复电」的总览图就够了。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;晚 10 点准时&amp;quot;断网&amp;quot;，早 8 点自动&amp;quot;复电&amp;quot;&#34; src=&#34;https://blog.margrop.net/post-images/synology-mykid-curfew-launchd/05-curfew-overview.svg&#34;&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>VPN 连上了，内网域名却死活访问不了？一次 macOS 路由表排查完整复盘</title>
      <link>https://blog.margrop.net/post/macos-routing-table-vpn-troubleshooting/</link>
      <pubDate>Mon, 01 Jun 2026 18:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/macos-routing-table-vpn-troubleshooting/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;一句话总结：&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;macOS 上同时跑了两个 VPN（&lt;code&gt;utun0&lt;/code&gt;、&lt;code&gt;utun15&lt;/code&gt;），其中 &lt;code&gt;utun0&lt;/code&gt; 推送了一条 &lt;code&gt;10.0.0.0/8&lt;/code&gt; 的聚合路由，把目标 &lt;code&gt;10.x.x.x&lt;/code&gt; 全部&amp;quot;吃&amp;quot;掉了——而我真正想走的是 &lt;code&gt;utun15&lt;/code&gt; 对端的内网。DNS 能解析，TCP/ICMP 就是不通。&lt;strong&gt;&lt;code&gt;route -n get&lt;/code&gt; 是定位这类问题的第一把刀&lt;/strong&gt;。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>Mac 应用打不开？别急着删：可能只是 Gatekeeper 不认这个未签名工具</title>
      <link>https://blog.margrop.net/post/macos-gatekeeper-unsigned-app-fix/</link>
      <pubDate>Mon, 01 Jun 2026 07:35:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/macos-gatekeeper-unsigned-app-fix/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;如果一个 macOS 工具下载后双击打不开，提示“无法验证开发者”“已损坏，无法打开”或被系统直接拦住，不要第一时间把它理解成“程序坏了”。很多时候，真正的问题是两个条件叠在一起：这个 &lt;code&gt;.app&lt;/code&gt; 带着浏览器下载留下的 &lt;code&gt;com.apple.quarantine&lt;/code&gt; 隔离属性，同时它没有 Apple 能认可的可用签名。Gatekeeper 在首次打开时看到“来自网络 + 没有可信签名”，自然会把它拦下来。&lt;/p&gt;&#xA;&lt;p&gt;对明确知道来源、只在自己机器上使用的小工具，最小修复通常是：先验证隔离属性和签名状态，再对这个 app 做本地 ad-hoc 签名，最后移除它自己的 quarantine 属性。这里的关键不是“关闭 macOS 安全”，而是只处理一个具体 app，不动全局 Gatekeeper，也不把临时本地修复误认为正式分发签名。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;这篇文章来自一次真实的本地排障，但所有涉及个人机器、内网、下载来源、账号、路径细节的内容都已经脱敏。文中只使用 &lt;code&gt;/Applications/&amp;lt;App&amp;gt;.app&lt;/code&gt;、&lt;code&gt;&amp;lt;App&amp;gt;&lt;/code&gt;、&lt;code&gt;&amp;lt;Vendor&amp;gt;&lt;/code&gt; 这类占位符。重点不是公开某个私有环境，而是把这类 macOS 启动失败的判断路径整理出来，方便以后遇到类似问题时少走弯路。&lt;/p&gt;</description>
    </item>
    <item>
      <title>诡异！Tmux 新 session 里凭空多出一个 http_proxy 环境变量</title>
      <link>https://blog.margrop.net/post/tmux-zsh-http-proxy-mystery/</link>
      <pubDate>Sat, 30 May 2026 16:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/tmux-zsh-http-proxy-mystery/</guid>
      <description>&lt;h1 id=&#34;前言&#34;&gt;前言&lt;/h1&gt;&#xA;&lt;p&gt;今天遇到一个非常诡异的问题：新创建的 tmux session 里，&lt;code&gt;echo $http_proxy&lt;/code&gt; 竟然显示了一个有效的代理地址。但我明明记得自己在 &lt;code&gt;.zshrc&lt;/code&gt; 里只定义了两个 alias：&lt;code&gt;proxy_on&lt;/code&gt; 和 &lt;code&gt;proxy_off&lt;/code&gt;，它们都是手动触发的，不会自动执行。&lt;/p&gt;&#xA;&lt;p&gt;诡异的是，我的主 shell 里 &lt;code&gt;http_proxy&lt;/code&gt;明明是空的，但一进 tmux 就有了。这个问题排查了将近一个小时才找到根因，特此记录。&lt;/p&gt;</description>
    </item>
    <item>
      <title>macOS LaunchAgent 里的 Python 程序连不上外网？一文搞懂 httpx 代理陷阱的完整排查与修复</title>
      <link>https://blog.margrop.net/post/macos-launchagent-python-httpx-proxy-no-route-to-host/</link>
      <pubDate>Sat, 30 May 2026 09:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/macos-launchagent-python-httpx-proxy-no-route-to-host/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论：&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;macOS 的 LaunchAgent 环境下，Python httpx 库会自动读取系统代理设置（&lt;code&gt;scutil --proxy&lt;/code&gt;），但 LaunchAgent 进程可能根本无法访问该代理服务器——于是请求静默失败，报错 &lt;code&gt;All connection attempts failed&lt;/code&gt; 或 &lt;code&gt;No route to host&lt;/code&gt;。&lt;/p&gt;&#xA;&lt;p&gt;解决方案只需要一行：在 LaunchAgent 的 plist 文件中添加 &lt;code&gt;NO_PROXY=*&lt;/code&gt;。&lt;/p&gt;&#xA;&lt;p&gt;这篇文章记录了我从发现 AI Agent 企业微信消息不回复、到逐步排查代理问题、最终定位到 macOS 系统代理与 LaunchAgent 网络隔离的完整过程。涉及 Python httpx 源码分析、macOS 代理机制深度解析、以及 LaunchAgent 运行环境的诸多坑点。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>从零开始的 AI Agent 完整迁移实战：踩坑九九八十一难后的通关攻略</title>
      <link>https://blog.margrop.net/post/ai-agent-complete-migration-guide-from-scratch/</link>
      <pubDate>Sat, 30 May 2026 08:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/ai-agent-complete-migration-guide-from-scratch/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论：&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;从一个 AI Agent 平台迁移到另一个平台，听起来像是「复制粘贴」的事情，实际上却是一场涉及数据迁移、渠道对接、定时任务、自动启动、代理配置、模块兼容性的系统工程。&lt;/p&gt;&#xA;&lt;p&gt;这篇文章记录了我从零开始完成一次 AI Agent 完整迁移的全过程：从安装新平台、迁移记忆和技能、配置消息渠道、排查各种诡异问题，到最终实现全自动运行。涉及 9 个踩坑点和对应的解决方案，希望能帮到有类似需求的朋友。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>MCP 明明没配错，为什么一启动就挂？一次 Codex MCP 故障的完整拆解</title>
      <link>https://blog.margrop.net/post/codex-mcp-startup-swift-runtime-troubleshooting/</link>
      <pubDate>Sat, 23 May 2026 06:10:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/codex-mcp-startup-swift-runtime-troubleshooting/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;这次故障最容易误判的地方，是表面错误写着 “MCP Client 启动失败”“MCP Server 握手失败”，于是人很自然会去怀疑 MCP 配置、插件开关、网络、Token、JSON 格式、stdio 协议，甚至怀疑 Codex 本身挂了。但真正的根因并不在 MCP 协议层：某个 MCP Server 对应的本地二进制在启动瞬间就被 macOS 动态链接器杀掉了，根本没有机会完成 &lt;code&gt;initialize&lt;/code&gt; 握手。Client 看到的只是连接提前关闭，Server 端真正留下的线索是 &lt;code&gt;dyld: Symbol not found&lt;/code&gt;，缺的是 Swift Concurrency runtime 里的一个符号。&lt;/p&gt;&#xA;&lt;p&gt;换句话说：MCP 没有来得及失败，Server 进程先死了。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;这篇文章记录一次很典型、也很容易绕远路的 Agent 工具链故障：Codex 里 MCP Client / MCP Server 启动异常。它不是一个“修改配置就好”的问题，而是一个从应用层错误一路追到本地二进制、动态链接器、Swift runtime 兼容性的排障过程。&lt;/p&gt;&#xA;&lt;p&gt;为了避免泄露任何隐私信息，本文不包含真实内网地址、真实用户名、真实会话 ID、真实本机绝对路径、Token、私有仓库地址或任何业务系统名称。文中路径都使用 &lt;code&gt;~&lt;/code&gt;、&lt;code&gt;&amp;lt;USER_HOME&amp;gt;&lt;/code&gt;、&lt;code&gt;&amp;lt;PLUGIN_DIR&amp;gt;&lt;/code&gt;、&lt;code&gt;&amp;lt;PROJECT&amp;gt;&lt;/code&gt; 等占位符表示；命令输出也只保留与判断根因有关的公开技术字段。&lt;/p&gt;</description>
    </item>
    <item>
      <title>百度网盘别只会拖拽：BaiduPCS-Go CLI 和 Agent 自动化实战</title>
      <link>https://blog.margrop.net/post/baidupcs-go-cli-agent-guide/</link>
      <pubDate>Sat, 16 May 2026 10:06:01 +0800</pubDate>
      <guid>https://blog.margrop.net/post/baidupcs-go-cli-agent-guide/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;如果你只是偶尔从百度网盘下载一两个文件，网页和官方客户端当然够用。但只要你开始批量下载、服务器拉取、自动备份、远程归档、目录巡检，或者希望让 Codex、Claude、OpenClaw、HermesAgent 这类 Agent 帮你处理网盘任务，图形界面很快就会变成阻碍。&lt;code&gt;BaiduPCS-Go&lt;/code&gt; 的价值不是“神奇提速”，而是把百度网盘变成一个可以被脚本、终端和 Agent 调度的文件系统入口。本文会从安装核验、BDUSS/STOKEN 登录、常用命令、配置策略、安全边界，一直讲到怎样把它交给 Agent 使用。&lt;/p&gt;&#xA;&lt;p&gt;本文所有账号、Cookie、路径、任务描述和配置均为脱敏示例，不包含任何真实 BDUSS、STOKEN、Cookie、内网地址、私人目录或业务信息。请不要把自己的登录凭据写进公开仓库、博客、截图、聊天记录或 Agent 提示词正文。&lt;/p&gt;&#xA;&lt;/blockquote&gt;</description>
    </item>
    <item>
      <title>别再远程桌面点点点：让 AI Agent 用 SSH 直接接管 Windows</title>
      <link>https://blog.margrop.net/post/agent-ssh-windows-openssh/</link>
      <pubDate>Wed, 13 May 2026 08:10:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/agent-ssh-windows-openssh/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;先说结论&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;让 AI Agent 从 Linux 或 macOS 管理 Windows，并不一定要走远程桌面、VNC、商业远控软件，也不一定要额外装一套奇怪的 Agent Runtime。对大多数个人工作站、实验机、开发机和内网服务器来说，最简单、最干净、最容易被自动化工具理解的方案，就是在 Windows 上启用系统自带的 &lt;strong&gt;OpenSSH Server&lt;/strong&gt;，然后从 Linux/macOS 直接执行：&lt;code&gt;ssh &amp;lt;user&amp;gt;@&amp;lt;windows-host&amp;gt;&lt;/code&gt;。&lt;/p&gt;&#xA;&lt;p&gt;真正需要做好的只有三件事：第一，Win10 / Win11 正确安装并启动 OpenSSH Server；第二，在 Linux/macOS 生成 SSH key，把公钥放到 Windows 对应位置；第三，如果登录用户属于 Windows 管理员组，要把公钥写入 &lt;code&gt;C:\ProgramData\ssh\administrators_authorized_keys&lt;/code&gt;，并用 &lt;code&gt;icacls&lt;/code&gt; 收紧权限。完成以后，AI Agent 就可以像操作 Linux 一样，用 SSH 在 Windows 上执行 PowerShell、复制脚本、读取日志、安装工具和做自动化运维。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;本文所有命令、截图和主机信息都使用通用占位符，不包含真实内网地址、真实用户名、真实机器名、密钥、Token 或私人路径。你只需要把 &lt;code&gt;&amp;lt;user&amp;gt;&lt;/code&gt;、&lt;code&gt;&amp;lt;windows-host&amp;gt;&lt;/code&gt;、&lt;code&gt;&amp;lt;windows-ip&amp;gt;&lt;/code&gt; 这类占位符替换成自己的环境值即可。&lt;/p&gt;</description>
    </item>
    <item>
      <title>给 macOS 上的 Antigravity 和 Claude 增加 Proxy：用 Wrapper App 安全接管 Electron 出网</title>
      <link>https://blog.margrop.net/post/macos-electron-app-proxy-wrapper-for-antigravity-and-claude/</link>
      <pubDate>Wed, 25 Mar 2026 10:00:00 +0800</pubDate>
      <guid>https://blog.margrop.net/post/macos-electron-app-proxy-wrapper-for-antigravity-and-claude/</guid>
      <description>&lt;blockquote&gt;&#xA;&lt;p&gt;&lt;strong&gt;写在前面&lt;/strong&gt;&#xA;这篇文章记录一种我已经在本机验证过的办法：&lt;strong&gt;不要直接修改原始应用包，也不要把真实代理地址写死到公开文章里，而是给 Electron 应用外面再包一层极小的 wrapper app&lt;/strong&gt;。这样既能给 Antigravity、Claude 这类 macOS 桌面应用注入代理，又不会轻易破坏原始签名、升级链路和回滚路径。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;很多人第一次遇到这个问题时，第一反应都是去改 &lt;code&gt;/Applications/Claude.app&lt;/code&gt; 或 &lt;code&gt;/Applications/Antigravity.app&lt;/code&gt; 里面的内容。短期看似乎可行，但长期通常会带来三个问题：&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;应用签名可能失效，后续启动、权限申请和升级都更脆弱。&lt;/li&gt;&#xA;&lt;li&gt;一旦原应用自动更新，你手工改过的内容很容易被覆盖。&lt;/li&gt;&#xA;&lt;li&gt;真实代理地址、内网 IP、鉴权信息如果直接写进应用包或公开文档，后果通常比“配置没生效”更严重。&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;我最后采用的是一个更稳的方案：&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;保留原始 &lt;code&gt;Claude.app&lt;/code&gt; 和 &lt;code&gt;Antigravity.app&lt;/code&gt; 不动。&lt;/li&gt;&#xA;&lt;li&gt;在 &lt;code&gt;~/Applications&lt;/code&gt; 下创建 &lt;code&gt;Claude (Proxy).app&lt;/code&gt; 和 &lt;code&gt;Antigravity (Proxy).app&lt;/code&gt;。&lt;/li&gt;&#xA;&lt;li&gt;wrapper app 只做三件事：加载本地 &lt;code&gt;proxy.env&lt;/code&gt;、导出大小写代理环境变量、用 &lt;code&gt;--proxy-server&lt;/code&gt; 启动原始 Electron 应用。&lt;/li&gt;&#xA;&lt;li&gt;如果应用内部还用了 Node/undici 的 &lt;code&gt;fetch&lt;/code&gt;，再通过 &lt;code&gt;NODE_OPTIONS=--require=...&lt;/code&gt; 注入一个极小的 bootstrap，把代理继续传到 Node 侧请求链路。&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;本文中的所有代理地址都用占位符表示，例如：&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;http://127.0.0.1:PORT&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;请把它替换成你自己的本地代理入口，&lt;strong&gt;不要把真实代理地址、内网 IP、用户名、密码、Token 或公司域名发布到公开文章、仓库或截图里&lt;/strong&gt;。&lt;/p&gt;</description>
    </item>
    <item>
      <title>2021年的MacOS BigSur系统外接2k显示屏及字体虚化锯齿的解决方案整理</title>
      <link>https://blog.margrop.net/post/2k-monitor-in-macos-hidpi-and-retina-display-menu/</link>
      <pubDate>Tue, 25 Jan 2022 21:45:33 +0800</pubDate>
      <guid>https://blog.margrop.net/post/2k-monitor-in-macos-hidpi-and-retina-display-menu/</guid>
      <description>&lt;h1 id=&#34;1-关闭系统-sip&#34;&gt;1. 关闭系统 SIP&lt;/h1&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://zhuanlan.zhihu.com/p/343151907&#34;&gt;https://zhuanlan.zhihu.com/p/343151907&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;执行命令前需要关闭SIP（系统完整性保护），具体做法是：&#xA;进入恢复模式（开机时按住 command+R 键），在右上角打开系统终端，输入 csrutil disable（禁用）命令，在开启hidpi后可重新使用命令 csrutil enable （开启）。具体可参考，&amp;raquo;传送门&lt;/p&gt;</description>
    </item>
    <item>
      <title>论Mac电脑和TimeMachine的重要性</title>
      <link>https://blog.margrop.net/post/the-important-of-mac-and-timemachine/</link>
      <pubDate>Tue, 14 Sep 2021 16:55:10 +0800</pubDate>
      <guid>https://blog.margrop.net/post/the-important-of-mac-and-timemachine/</guid>
      <description>&lt;p&gt;今天是2021年9月14日。&lt;/p&gt;&#xA;&lt;p&gt;到今天为止，我已经使用 &lt;code&gt;MacOS&lt;/code&gt; 作为主力系统，已经有了2年左右的时间。&lt;/p&gt;&#xA;&lt;p&gt;不得不说，我现在已经深深的爱上了 &lt;code&gt;MacOS&lt;/code&gt;。如果我需要购买下一台笔记本，我一定会购买 &lt;code&gt;MacBookPro&lt;/code&gt;高配。&lt;/p&gt;</description>
    </item>
    <item>
      <title>Java基于 SpringBoot 的 JNI 本地方法库加载器</title>
      <link>https://blog.margrop.net/post/java-spring-boot-jni-java-native-interface-library-loader/</link>
      <pubDate>Sat, 27 Mar 2021 16:37:31 +0800</pubDate>
      <guid>https://blog.margrop.net/post/java-spring-boot-jni-java-native-interface-library-loader/</guid>
      <description>&lt;p&gt;由于Java跨平台需要，自行写了一个跨平台的 JNI 本地方法库加载器。&lt;/p&gt;&#xA;&lt;h1 id=&#34;简单实现逻辑&#34;&gt;简单实现逻辑&lt;/h1&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;根据环境变量&lt;code&gt;os.name&lt;/code&gt;，判断当前系统属于&lt;code&gt;Windows&lt;/code&gt;,&lt;code&gt;Linux&lt;/code&gt;还是&lt;code&gt;MacOS&lt;/code&gt;&lt;/li&gt;&#xA;&lt;li&gt;如果是&lt;code&gt;Linux&lt;/code&gt;，继续判断是&lt;code&gt;CentOS&lt;/code&gt;还是&lt;code&gt;Debian&lt;/code&gt;&lt;/li&gt;&#xA;&lt;li&gt;读取 jar 包中的库文件&lt;/li&gt;&#xA;&lt;li&gt;根据文件名后缀&lt;code&gt;dll&lt;/code&gt;、&lt;code&gt;so&lt;/code&gt;、&lt;code&gt;jnilib&lt;/code&gt;和&lt;code&gt;dylib&lt;/code&gt;，过滤符合当前平台的库文件&lt;/li&gt;&#xA;&lt;li&gt;将当前平台的库文件复制到系统临时目录&lt;code&gt;java.io.tmpdir&lt;/code&gt;&lt;/li&gt;&#xA;&lt;li&gt;使用&lt;code&gt;System.load&lt;/code&gt;加载库文件&lt;/li&gt;&#xA;&lt;/ol&gt;</description>
    </item>
  </channel>
</rss>
