<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>System-Design on All about Raspberry Pi</title><link>https://hugozhu.site/tags/system-design/</link><description>Recent content in System-Design on All about Raspberry Pi</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 18 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hugozhu.site/tags/system-design/index.xml" rel="self" type="application/rss+xml"/><item><title>Agent 的 Skill 自进化机制：它是如何自己长记性的</title><link>https://hugozhu.site/post/2026/183-agent-skill-self-evolution/</link><pubDate>Sat, 18 Apr 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/183-agent-skill-self-evolution/</guid><description>&lt;p&gt;昨天我用 Agent 处理一个棘手的部署任务。它第一次跑的时候踩了个坑——少了一步 &lt;code&gt;docker login&lt;/code&gt;，推送镜像时报错了。Agent 发现问题，自己补上登录步骤，重试后跑通了。&lt;/p&gt;
&lt;p&gt;但最让我惊讶的不是它跑通了，而是它&lt;strong&gt;默默更新了自己的操作手册&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;下一次我再让它做同样的任务时，它直接带上了 &lt;code&gt;docker login&lt;/code&gt;，一步到位。&lt;/p&gt;
&lt;p&gt;它自己&amp;quot;长记性&amp;quot;了。&lt;/p&gt;
&lt;p&gt;这不是魔法，是 Hermes Agent 的 &lt;strong&gt;Skill 自进化机制&lt;/strong&gt;。它把一次性的试错经验，固化成了可复用的程序化记忆。&lt;/p&gt;</description></item><item><title>LLM Agent 上下文压缩算法</title><link>https://hugozhu.site/post/2026/182-llm-agent-context-compression-evolution/</link><pubDate>Sat, 18 Apr 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/182-llm-agent-context-compression-evolution/</guid><description>&lt;p&gt;跑了一个长对话 session，agent 帮我重构了一个模块，修了三个 bug，又加了一组测试——最后触发了 context compression，屏幕上显示：&amp;ldquo;Compressed: 347 -&amp;gt; 18 messages (~89,000 tokens saved, 74%)&amp;quot;。&lt;/p&gt;
&lt;p&gt;我好奇它是怎么做到的：压缩了 89K tokens 后，agent 继续干活，居然还记得之前改过的文件路径、失败的测试用例、我说过&amp;quot;不要用 &lt;code&gt;==&lt;/code&gt; 要用 &lt;code&gt;is&lt;/code&gt; 比较 None&amp;quot;这种细节。&lt;/p&gt;
&lt;p&gt;这不是魔术，是一个经过大量 bug 修复迭代出来的上下文压缩算法。我花了两个小时读了 Hermes Agent 的 &lt;code&gt;context_compressor.py&lt;/code&gt;，1163 行代码，每一步都有对应的失败案例和修复注释。&lt;/p&gt;</description></item><item><title>OpenCLI vs AutoCLI：把网站变成 CLI 的技术革命</title><link>https://hugozhu.site/post/2026/181-opencli-vs-autocli-web-cli-revolution/</link><pubDate>Sat, 18 Apr 2026 00:00:00 +0000</pubDate><guid>https://hugozhu.site/post/2026/181-opencli-vs-autocli-web-cli-revolution/</guid><description>&lt;p&gt;上周给 DingTalk 的一个内部项目做技术调研，需要从知乎、B站、小红书几个平台拉热榜数据做竞品分析。同事的第一反应是写爬虫——打开 Playwright，找 CSS 选择器，处理登录态，和 Cloudflare 斗智斗勇，折腾了两小时还没跑通。我看了看他的代码，说：&amp;ldquo;换个思路，试试 OpenCLI，&lt;code&gt;opencli zhihu hot&lt;/code&gt; 一行命令就完了。&amp;rdquo;&lt;/p&gt;
&lt;p&gt;一查这个项目——GitHub 上 16K stars。再看 AutoCLI（OpenCLI 的 Rust 重写版）的性能数据：&lt;code&gt;bilibili hot&lt;/code&gt; 命令，OpenCLI 要 20 秒，AutoCLI 只要 1.66 秒，&lt;strong&gt;12 倍加速&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;更令人震惊的不是性能数字，而是这两个项目背后的&lt;strong&gt;技术范式转变&lt;/strong&gt;——它们不是在&amp;quot;做更好的爬虫&amp;quot;，而是在&lt;strong&gt;重新定义怎么从网站获取数据&lt;/strong&gt;。&lt;/p&gt;</description></item></channel></rss>