<!-- title: Token瘦身、记忆图谱与Agent编排：五款HN新利器 -->
<!-- domain: new-tools -->

# Token瘦身、记忆图谱与Agent编排：五款HN新利器

这周Hacker News Show页面上冒出一波针对AI开发者痛点的硬核工具：有能帮你砍掉91.8% LLM token消耗的CLI过滤器，有纯Rust写的本地AI记忆层，还有让AI Agent自动派活给子Agent的MCP编排器。它们解决的都是中国开发者同样面临的问题——**token太贵、Agent没记忆、多Agent协作太复杂**——但国内几乎没人聊。

## 一、Lowfat：一行命令砍掉91.8%的Token消耗

**🔥 HN热度：138分，70条评论（本周最热AI工具帖）**

如果你用Claude Code、Cursor或任何AI编程助手，你的token消耗里有大量"噪音"——`git status`里的提示文字、`git diff`里的上下文标记、`docker ps`里的列头……这些对AI来说毫无价值，但每个字符都在烧你的钱。

**Lowfat**（https://github.com/zdk/lowfat）就是来解决这个问题的。它是一个CLI过滤器，在命令输出喂给AI之前先把噪音剥离掉。

### 压缩效果实测

| 命令 | lite模式 | full模式 | ultra模式 |
|------|---------|---------|----------|
| `git diff` | -16% | -38% | **-96%** |
| `git log` | -53% | -80% | -91% |
| `git status` | -62% | -62% | -74% |
| `docker ps` | -38% | -38% | -85% |
| `docker images` | -48% | -58% | -86% |
| `ls -la` | -2% | -75% | -87% |

举个例子，同样是 `git status`：

**原始输出**（135字符）：
```
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   src/main.rs
```

**Lowfat过滤后**（52字符）：
```
On branch main
Changes not staged for commit:
	modified:   src/main.rs
```

### 安装和使用

```bash
# 方式一：Cargo安装
cargo install lowfat

# 方式二：Homebrew
brew install zdk/tools/lowfat
```

核心设计理念是**UNIX风格管道**——你可以把Lowfat插入任何AI工作流：

```bash
# 在Claude Code中使用
lowfat git diff --level=ultra | pbcopy
# 然后粘贴给Claude

# 或者在自动化脚本中
git log --oneline -20 | lowfat filter git/log-compact --level=full
```

三级压缩策略：
- **lite**：保守压缩，只去掉最明显的冗余
- **full**：中等压缩，去掉提示信息和格式冗余
- **ultra**：激进压缩，只保留核心信号（适合AI理解）

### 为什么值得关注

对Claude Code用户来说，Lowfat直接降低了每次对话的context成本。假设你每天和AI交互50次，每次context包含2次 `git diff` + 1次 `git log` + 1次 `git status`，用 `ultra` 模式保守估计省60%的命令输出token——**一个月下来能省几十美元API费用**。

**国内对比**：目前国内没有类似工具。大多数开发者的做法是手动 `git diff --stat` 然后贴给AI，但这种方式丢失了具体改动内容。

---

## 二、Mnemo：给任何LLM装上本地"记忆大脑"

**🔥 HN热度：59分，28条评论**

LLM最大的缺陷是什么？**没有持久记忆**。每次新对话都从零开始。Claude Code有 `/memory`，但那是简单的文本文件。如果你需要一个结构化的、能跨session自动检索相关记忆的系统呢？

**Mnemo**（https://github.com/zaydmulani09/mnemo）是一个用Rust写的本地AI记忆层，它会把你的对话自动提取成**知识图谱**，存在本地SQLite里，下次对话时自动注入相关上下文。

### 工作原理

```mermaid
flowchart LR
    A[你的应用] -->|POST /ingest| B[Mnemo侧车服务]
    B -->|LLM实体提取| C[知识图谱<br/>SQLite + petgraph]
    C -->|BFS图遍历<br/>+全文搜索<br/>+评分排序| D[POST /retrieve]
    D -->|context_prompt| E[注入LLM系统提示]

    style B fill:#f9f,stroke:#333
    style C fill:#bbf,stroke:#333
```

6阶段检索管线：
1. **全文搜索**：在文本块中搜索关键词
2. **实体名搜索**：匹配人名、工具名、概念名
3. **图扩展（BFS）**：沿知识图谱做多跳遍历
4. **关系过滤**：筛选相关关系类型
5. **评分排序**：直接匹配 > 推断匹配（0.5x权重）
6. **组装输出**：生成 `context_prompt` 字符串

### 与同类工具的核心差异

| 特性 | Mnemo | 大多数替代品 |
|------|-------|------------|
| 运行时 | 单个Rust二进制 | Python守护进程 |
| 存储 | SQLite（持久化） | 内存或云端 |
| 图谱层 | petgraph多跳遍历 | 无 |
| 云依赖 | 零 | 必需或可选 |
| LLM后端 | 任何OpenAI兼容 | 通常锁定一个 |
| 检索质量 | 评分+排序+图谱扩展 | 朴素上下文dump |

### 快速上手

```bash
# 方式一：Docker + Ollama（完全免费）
git clone https://github.com/zaydmulani09/mnemo
cd mnemo
docker compose up -d

# 方式二：Cargo安装
cargo install mnemo-core
```

API非常简洁：

```python
import requests

# 注入对话记忆
requests.post("http://localhost:8080/ingest", json={
    "text": "用户张三是前端工程师，偏好React，项目使用TypeScript"
})

# 检索相关记忆
resp = requests.post("http://localhost:8080/retrieve", json={
    "query": "张三的技术栈是什么？"
})
context = resp.json()["context_prompt"]
# 把context注入你的LLM系统提示
```

### 为什么值得关注

HN上有评论指出："多数AI记忆工具的问题在于，把一堆记忆塞进context反而降低性能。" Mnemo的图谱+评分方案试图解决这个精确检索问题。**对于构建自定义Agent pipeline的开发者**，这是一个比MemGPT、Zep更轻量的选择。

---

## 三、Sub-Agent MCP：让AI Agent自动"派活"的编排器

**工具地址**：https://github.com/stormaref/Sub-Agent-MCP

如果你用Cursor、Claude Code或任何支持MCP的工具，Sub-Agent MCP让你可以定义多个专职子Agent，父Agent通过MCP协议自动把任务委派给它们。

### 架构设计

```mermaid
sequenceDiagram
    participant P as 父LLM<br/>(如Cursor Agent)
    participant S as Sub-Agent MCP<br/>(MCP Server)
    participant R as researcher子Agent
    participant C as coder子Agent
    participant L as OpenAI/Ollama

    P->>S: 调用 researcher(prompt)
    S->>R: 构建Agent + 注入下游工具
    R->>L: 推理循环
    R-->>S: 返回研究结果
    S-->>P: {"response": "..."}
    
    P->>S: 调用 coder(prompt)
    S->>C: 构建Agent + 注入代码工具
    C->>L: 推理循环
    C-->>S: 返回代码方案
    S-->>P: {"response": "..."}
```

### YAML配置示例

```yaml
# agents.yaml
agents:
  - id: researcher
    model: gpt-4o-mini
    system_prompt: "你是一个研究助手，擅长搜索和分析技术文档。"
    mcp_servers:
      - name: web-search
        transport: streamable-http
        url: http://localhost:3001/mcp
    tool_allowlist:
      - web_search
      - fetch_url

  - id: coder
    model: claude-sonnet-4-6
    system_prompt: "你是一个高级编程助手。"
    mcp_servers:
      - name: filesystem
        transport: streamable-http
        url: http://localhost:3002/mcp
    tool_allowlist:
      - read_file
      - write_file
```

### 核心优势

- **避免context膨胀**：父Agent不需要加载所有子Agent的工具schema
- **按角色配置**：不同子Agent可以用不同模型、不同prompt、不同工具
- **生产就绪**：Pydantic验证、结构化日志、Docker健康检查、CI流水线
- **OpenAI兼容**：支持OpenAI、Azure、Ollama、LM Studio等任何兼容API

### 国内对比

国内类似方案主要是Coze、Dify的工作流编排，但它们是SaaS形式，不够灵活。Sub-Agent MCP是纯本地部署、YAML配置、MCP标准协议——**对注重数据隐私的企业开发者更友好**。

---

## 四、Nanocode-CLI：200KB的终端AI编程助手

**工具地址**：https://github.com/hit9/nanocode

Claude Code很好，但它很重——每次启动要加载大量context，token消耗也不低。如果你只是想快速让AI帮你改个bug、加个函数呢？

**Nanocode**是一个极简的终端AI编程助手，用Python写的，安装只要一行：

```bash
uv tool install nanocode-cli
```

### 与Claude Code / Aider的关键差异

| 特性 | Nanocode | Claude Code | Aider |
|------|----------|-------------|-------|
| 安装大小 | ~200KB | ~50MB | ~10MB |
| 依赖 | Python + API Key | Node.js | Python + Git |
| 上下文策略 | 文件状态大脑 | 全项目扫描 | Git-aware |
| 实时交互 | ✅ 可中途追加输入 | ✅ | ❌ |
| 编辑保护 | line:hash锚点 | 全文件diff | Git diff |
| 缓存优化 | ✅ 稳定区段前置 | ✅ | ❌ |

### 亮点功能

**1. 实时追加输入**：AI还在工作时，你可以在 `+>` 提示符追加指令，不会打断当前工具调用流程。

**2. 文件状态大脑**：不是暴力读取所有文件，而是跟踪你当前编辑的文件，维护一个行号精确的视图。

**3. 过时编辑保护**：用 `line:hash` 锚点验证目标代码是否已变化——如果AI想编辑的那行代码已经被你改了，操作会被拒绝，避免冲突。

**4. 缓存感知上下文**：稳定的代码段放在prompt前面（命中缓存），频繁变化的工作状态放在后面——**提高prompt缓存命中率，降低成本**。

### 适用场景

- 快速修bug、加函数，不想等Claude Code启动
- 在SSH远程服务器上用AI写代码（轻量级）
- 作为Claude Code的"快餐版"替代

---

## 五、TextSnap：一行命令把截图变文字，纯CPU、纯本地

**工具地址**：https://github.com/kouhxp/textsnap

OCR工具遍地都是，但大多数要么依赖云端API（隐私问题），要么需要GPU（部署门槛高）。TextSnap与众不同：

- **纯CPU运行**：用PaddleOCR-VL-1.5量化模型（q4 ONNX），0.9B参数，普通笔记本就能跑
- **完全离线**：首次下载约890MB模型，之后永不联网
- **单文件工具**：整个工具就一个Python模块
- **支持多种输入**：截图文件、剪贴板、URL、网页

```bash
pip install textsnap

# 截图OCR
textsnap screenshot.png

# 从剪贴板读取（不用传参数）
textsnap
# 结果自动回到剪贴板，直接粘贴

# 网页截图OCR
textsnap https://example.com/article --plaintext

# URL图片OCR
textsnap https://example.com/image.png
```

### 为什么它比其他OCR工具强

| 特性 | TextSnap | Tesseract | 云端OCR API |
|------|----------|-----------|------------|
| 精度 | 高（VLM） | 中 | 高 |
| GPU需求 | 不需要 | 不需要 | 不适用 |
| 隐私 | 本地 | 本地 | ❌ 上传云端 |
| 复杂排版 | ✅ Markdown输出 | ❌ 纯文本 | ✅ |
| 安装复杂度 | pip install | 系统包管理 | 注册+API Key |
| 中文支持 | ✅ PaddleOCR原生 | 需额外包 | 视服务商 |

**对AI工作流的价值**：把截图/文档OCR成Markdown后喂给LLM，比直接贴图片的token消耗低一个数量级。

---

## 信息差总结

| 你知道的 | 你不知道的（本篇信息差） |
|---------|----------------------|
| Claude Code token消耗高 | **Lowfat**能在命令输出环节砍掉60-96%的token |
| LLM没有持久记忆 | **Mnemo**用Rust+知识图谱实现了50ms检索的记忆层 |
| 多Agent协作靠Coze/Dify | **Sub-Agent MCP**用MCP协议做本地Agent编排 |
| AI编程助手只有Claude Code/Aider | **Nanocode**只有200KB，有缓存优化和编辑保护 |
| OCR要么云端要么GPU | **TextSnap**用CPU跑VLM，输出Markdown，完全离线 |

## 行动指南

**立刻可以做的**：

1. **安装Lowfat**（5分钟）：`brew install zdk/tools/lowfat`，在你的AI工作流中加入 `lowfat git diff --level=full` 过滤。这是投入产出比最高的一个。

2. **试用TextSnap**（3分钟）：`pip install textsnap`，把平时截图贴给AI的习惯改成先OCR再贴文本，省token且更精确。

3. **配置Sub-Agent MCP**（30分钟）：如果你用Cursor，在 `.cursor/mcp.json` 中加入Sub-Agent MCP配置，把research和coding任务分给不同子Agent。

4. **关注Mnemo**（观望）：如果你在构建自定义Agent pipeline，可以把Mnemo作为记忆层集成进去。目前项目还比较新（59星），但架构设计很清晰。

## 参考来源

- [Lowfat - GitHub](https://github.com/zdk/lowfat) — HN 138pts, 70条评论
- [Mnemo - GitHub](https://github.com/zaydmulani09/mnemo) — HN 59pts, 本地AI记忆层
- [Sub-Agent MCP - GitHub](https://github.com/stormaref/Sub-Agent-MCP) — Agent编排MCP Server
- [Nanocode-CLI - GitHub](https://github.com/hit9/nanocode) — 轻量终端AI编程助手
- [TextSnap - GitHub](https://github.com/kouhxp/textsnap) — CPU本地OCR工具
- [Hacker News Show页](https://news.ycombinator.com/show) — 本周Show HN原始列表

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护。
> 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)