
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>TechLog</title>
      <link>https://joker1point.github.io/techlog/blog</link>
      <description>AI Agent 工程化实践复盘：架构设计、容错与可靠性、上下文工程与成本治理。</description>
      <language>zh-cn</language>
      <managingEditor>birenwenmou@qq.com (眠月)</managingEditor>
      <webMaster>birenwenmou@qq.com (眠月)</webMaster>
      <lastBuildDate>Fri, 16 Oct 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://joker1point.github.io/techlog/tags/windows/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://joker1point.github.io/techlog/blog/exetrace-native-rewrite</guid>
    <title>20.4 MB → 1.72 MB：把一个 Windows 工具从 tkinter 重写成 Win32 原生控件</title>
    <link>https://joker1point.github.io/techlog/blog/exetrace-native-rewrite</link>
    <description>一个记录&quot;你打开过哪些应用&quot;的桌面小工具，Python 版功能最全但体积 20.4 MB、常驻 5-8 MB。这一轮用 Rust + Windows 公共控件重写了一个原生版：exe 1.72 MB、托盘常驻约 4.5 MB。重写不是翻译——列表虚拟化与&quot;运行中自动隐藏&quot;、图标的三种形态、项目管理扫描、以及把工具变成&quot;可以被 Agent 调用的接口&quot;，每一步都是跟平台重新谈条件。</description>
    <pubDate>Fri, 16 Oct 2026 00:00:00 GMT</pubDate>
    <author>birenwenmou@qq.com (眠月)</author>
    <category>engineering</category><category>windows</category><category>rust</category><category>performance</category><category>desktop</category>
  </item>

  <item>
    <guid>https://joker1point.github.io/techlog/blog/flowwatch-alert-rules</guid>
    <title>从&quot;事后看&quot;到&quot;事中拦&quot;：给流量观测工具装上告警规则引擎</title>
    <link>https://joker1point.github.io/techlog/blog/flowwatch-alert-rules</link>
    <description>一个自维护的本机流量观测工具，被三次真实事故各推着长出一个能力：20 小时静默停摆催生看门狗，单日 124GB 上行催生代理哨兵，一次 207GB 事故催生&quot;本机连接&quot;面板。最新一轮把写死阈值的哨兵泛化成告警规则引擎：任意进程 × 可组合条件 × Web 配置。本文记录这条演进路径与三个设计决策：为什么只告警不处置、为什么规则要能解释、以及为什么出口必须能兜底。</description>
    <pubDate>Fri, 16 Oct 2026 00:00:00 GMT</pubDate>
    <author>birenwenmou@qq.com (眠月)</author>
    <category>engineering</category><category>observability</category><category>windows</category><category>network</category><category>system-design</category>
  </item>

  <item>
    <guid>https://joker1point.github.io/techlog/blog/memory-guard-demote-tier</guid>
    <title>不杀，先让路：内存守护的降级档是怎么长出来的</title>
    <link>https://joker1point.github.io/techlog/blog/memory-guard-demote-tier</link>
    <description>一台 32GB 的开发机长期在 10% 可用内存附近徘徊——&quot;临界才杀进程&quot;意味着天天在悬崖边保持不动。这一轮改版给守护脚本加了降级档：警告线以下不杀，先把最大的非前台进程降优先级、交还工作集；再加&quot;你正在看的应用全家豁免&quot;、和一次真实搁浅事故修出来的状态落盘。三个决策都不是设计阶段想出来的，而是上线后逐次事故长出来的。</description>
    <pubDate>Fri, 16 Oct 2026 00:00:00 GMT</pubDate>
    <author>birenwenmou@qq.com (眠月)</author>
    <category>engineering</category><category>reliability</category><category>windows</category><category>system-design</category>
  </item>

  <item>
    <guid>https://joker1point.github.io/techlog/blog/memory-guard-last-line-of-defense</guid>
    <title>最后一道内存防线：内存守护脚本的设计取舍与真实战报</title>
    <link>https://joker1point.github.io/techlog/blog/memory-guard-last-line-of-defense</link>
    <description>32GB 开发机被 Electron 全家桶吃干、一天在 3% 可用内存附近挣扎之后，我写了一个只做一件事的守护脚本：内存临界前杀掉占用最大的进程。难点不在杀谁，而在什么时候动手、谁不能杀、守护者自己死了怎么办。附真实战报与一次杀-重生循环的根因复盘。</description>
    <pubDate>Tue, 22 Sep 2026 00:00:00 GMT</pubDate>
    <author>birenwenmou@qq.com (眠月)</author>
    <category>engineering</category><category>reliability</category><category>system-design</category><category>windows</category>
  </item>

    </channel>
  </rss>
