<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BigOrangeQWQ Blog</title><link>https://blog.orangeqwq.top/zh/</link><description>Recent content on BigOrangeQWQ Blog</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Tue, 14 Apr 2026 00:08:01 +0800</lastBuildDate><atom:link href="https://blog.orangeqwq.top/zh/index.xml" rel="self" type="application/rss+xml"/><item><title>Prefix‑Cache 友好的 SubAgent 派生：一种 fork() 式设计</title><link>https://blog.orangeqwq.top/zh/posts/2026-04-14-my-site/</link><pubDate>Tue, 14 Apr 2026 00:08:01 +0800</pubDate><guid>https://blog.orangeqwq.top/zh/posts/2026-04-14-my-site/</guid><description>这里记录着我个人对 LLM Agent 的 Ideas
最近的工作 最近，我自己编写了一个给自己用的 CLI 工具 (OMG CLI)
设计这个 CLI 的时候大范围借鉴了 kimi-cli
而关于 CLI 的设计上来说，业界也会有诸多的人如我一般，都会思考两件事
上下文如何节省 注意力如何不分散 于是我们今天就来聊一聊，我对这两件事的不同看法和实践
我们首先必须得知道的一个前提是上下文很昂贵
这个昂贵有两层含义，一个是经济上的，一个是对于 Agent 来说的
前者不必提，后者其实就是当上下文接近 80% 的时候 AI 就会被记忆给拖累以至于无法再有新产出
基于这个前提，我们自然会有许多手段来防止上下文溢出
先说三个业界内比较普遍的手段。
1. 上下文压缩 让 LLM 自己把整个上下文压缩，去掉冗余信息 kimi-cli 在这点上做的非常顶，它们的 COMPACT.md 非常棒。
2. 动态裁剪 上次跟朋友讨论这个的时候，朋友分享了一个 OpenCode 的插件
就是把一些不必要的 ToolCall 和 ToolResult 让 LLM 自己压缩起来
这种方案缺点是会导致模型提供商围绕请求做的缓存失效。
3. 子代理 (SubAgent) 当前的 SubAgent 的方案其实就是多花 Token 外包某项任务给其它 Agent，而后 Main Agent 就可以通过 SubAgent 的汇报来保证自己注意力和上下文不分散，其实就是砸钱。
4. 我个人的方案 (Fork) 我个人的方案是操作系统那个异常经典且令人拍案叫绝的 fork() 函数</description></item><item><title>浅说 ST表</title><link>https://blog.orangeqwq.top/zh/posts/2024-09-28-st-tabel/</link><pubDate>Sat, 28 Sep 2024 23:46:38 +0800</pubDate><guid>https://blog.orangeqwq.top/zh/posts/2024-09-28-st-tabel/</guid><description>ST 表 ST 表是利用倍增思想做预处理的一种数据结构，而预处理所指的算法自然就是动态规划。
这是一个二维的的动态规划，它的状态如下：
设 $f(i,j)$ 代表第 $i$ 个数到第 $i + 2^j - 1$ 个数的最大值，即为：$f(i, j) = \max(i,i + 2^j - 1)$
这里需要画下重点，请劳烦读者再观察一次该式，后面的推导全部基于此
$$f(i, j) = \max(i,i + 2^j - 1)$$
可以发现 $f(i, j)$ 所管辖的区间取决于 $[i, i + 2^{j - 1} - 1] , [i + 2^{j - 1},i + 2^j - 1]$ 这两个区间。
得转移公式：$f(i, j) = \max(f(i, j - 1), f(i + 2^{j - 1}, j - 1))$</description></item><item><title>个人的收藏网站</title><link>https://blog.orangeqwq.top/zh/posts/2024-08-30-my-site/</link><pubDate>Fri, 30 Aug 2024 00:08:01 +0800</pubDate><guid>https://blog.orangeqwq.top/zh/posts/2024-08-30-my-site/</guid><description> CS Course Rust 官网 Rust 期刊 Rust TRPL Rust 圣经,不推荐入门 RISC-V 官网 Lua 官网 Lua 手册 License 选择自己喜欢的开源许可证吧！ Python 文档 Python Cookbook 绘制流程图 画图 字节码/汇编 每日资讯 有向图/无向图编辑器</description></item><item><title>浅谈 Docker in Docker 的两种方法</title><link>https://blog.orangeqwq.top/zh/posts/2024-08-29-docker-in-docker/</link><pubDate>Thu, 29 Aug 2024 20:55:24 +0800</pubDate><guid>https://blog.orangeqwq.top/zh/posts/2024-08-29-docker-in-docker/</guid><description>DinD (Docker in Docker) 简介 在运行某一个容器时，该容器若存在运行其它容器的需求时，需要在需要运行其它容器的容器安装一个 Docker 环境
但是我们会发现安装一个 Docker 环境来启动其它容器的代价是巨大的，这样的容器会十分笨重且难以管理
于是可以自然的想到一个很重要的点，需要在容器里面复用容器外的 Docker 环境，这样既能启动容器，也很轻便快捷。
怎么复用呢？有什么方法能够支持复用？
当我们每次启动 Docker 容器时，是不是可以提供或者同步什么东西过去？环境变量，挂载文件还是网络呢？
是不是可以通过网络的形式做通信？藉此来连接到外部的 Docker 环境，我们是不是只需要一个 Client 而不需要启动一个 Docker 了。
有两种技术可言，一个是 DinD 容器，启动一个 DinD 容器，让其它容器通过 Network 形式连接到该容器后来创建新的容器，但这种方式因为要使用到 &amp;ndash;privilege 选项而容易有安全风险问题。
第二个 DooD(Docker outside of Docker) 使用套接字(Socket)的解决方案，我们只需要将 /var/run/docker.sock 文件挂载到容器内部即可：
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
只需要在需要启动其它的容器内安装 Docker Cli 或者是其它能连接的 Client 即可解决此事。</description></item></channel></rss>