Files
HomeAgent/README_EN.md
JianFeeeee 7f43a6bfc7 docs: 重写 README,中英文对齐,历史移入 CHANGELOG
## 问题:README 像架构文档,不像 README

原文 420 行,开头第一句是「以核心域与应用域分离为设计原则的 Agent 框架」。
读者点进来想知道「这东西能给我干什么」,得到的是一句需要三分钟才能理解的定义。

量化一下 AI 味的几个典型指纹:

| 指标 | 改前 | 改后 |
|---|---|---|
| 加粗标记 | **230** 处 | 56 处 |
| 破折号插入语 | **17** 处 | 0 |
| 行数 | 420 | 204 |
| 「项目状态」占比 | 86 行(21%) | 移出 |

几乎每条 bullet 都是同一个模板:粗体术语开头 + 三行解释 + 收尾总结。
结构过度对称、每段都自我收尾,是 AI 写作最明显的痕迹。

## 改法:先说人话,再讲设计

开头四句:

> 一个能自己跑几个月、还记得住事的 Agent 内核。
> 说人话:你给它接上 QQ、WebUI、命令行、文件、浏览器,它就能在这些地方替你干活。
> 白天聊过的事,晚上还记得。三周前说过的偏好,不会因为上下文窗口滚动就丢了。
> 插件崩了它不倒,模型换了它不改。

然后把 `## 设计要点` 改成 `## 它跟别的 Agent 框架哪里不一样` ——从「我们有什么设计」
改成「你和别人有什么不同」。每条都给了**为什么这么选**,不是**我们做得多好**:

- 插件是独立进程 → 因为 `.so` 那套踩过 `dlclose` 空操作、cgo 超时杀不掉线程
- 内核不碰 IO → 好处不是干净,是能换掉整个交互层而不改内核
- 记忆会下沉 → 所以能跑几个月而不把历史全塞进 prompt

`## 能力` 不列 API,列「你能让它干什么」:说话的地方 / 看和听 / 动手 / 记住 / 调度。

## 删掉 227 行重复与历史

- **`## 架构图`(142 行)**:`ARCHITECTURE.md` 里已有完整的「消息处理流程」「7 阶段
  钩子」「三层记忆」,README 里这套是**逐字重复**。README 留一张 8 行流程图 +
  三段话讲清机制,细节指向架构文档。
- **`## 项目状态`(85 行)**:这是更新日志,不是 README。移入新建的
  `CHANGELOG.md` / `CHANGELOG_EN.md`。

## 中英文同步

`README_EN.md` 之前停在旧版式(439 行,含 `Architecture Diagrams` /
`Project Status`),与中文版结构完全不同 —— 不是这次才不同步,是**一直是两份不同的文档**。

本次按节 1:1 对齐(9 节完全一致),英文不是逐字直译,按英文习惯重写:

```
## 它跟别的 Agent 框架哪里不一样   →  ## What makes it different
## 能力                          →  ## What it can do
## 怎么工作的                    →  ## How it works
## 快速体验                       →  ## Quick Start
## 代码结构                       →  ## Code Structure
...
```

补上英文版一直**缺失**的 `## Quick Start` 整节(中文有、英文没有)。

## 顺带修正的事实错误

- 「内置 13 个插件」→ 实际 18 个插件目录(`webui`/`cli`/`files`/`cmd`/`mcp`/`kbtree`/`seq`/`skillmgr` …)
- 「参考 `example/` 目录下的 Go 和 Lua 示例」→ 26 个插件已迁到
  [github.com/HologramAgent](https://github.com/HologramAgent),`example/` 只剩 2 个

## 验证

- 两版死链检查:`README.md` / `README_EN.md` 内部链接全部有效
- 9 个二级标题逐一对齐
- 破折号插入语归零(英文剩余 4 处全是列表分隔符)
2026-10-31 11:08:12 +08:00

11 KiB

⚠️ AI-Assisted Programming Notice: Parts of this project's code, documentation, and commit history were generated or modified with AI assistance. Key changes have been human-reviewed, but please evaluate and verify before use.

HologramAgent

中文: README.md

An agent kernel that runs for months and still remembers.

In plain terms: connect it to QQ, a web UI, your shell, your files, a browser, and it gets work done in all of them. What you discussed this morning, it still knows tonight. A preference you mentioned three weeks ago doesn't vanish when the context window scrolls. A plugin crashes and it keeps running. Swap the model and nothing else changes.

./build/homed -data /tmp/ha      # start the kernel
./build/waiter                    # talk to it

All you need is a Linux box. API keys go in through the web UI and live in local SQLite.


What makes it different

Plugins are separate processes, not shared libraries. A plugin panic can't take the kernel down, and it restarts on its own. Drop in a new plugin.bin and it's live. No rebuild, no restart. This isn't architectural purity for its own sake: the .so approach burned us badly enough to justify the rewrite (dlclose silently no-ops under DF_1_NODELETE, cgo timeouts leave threads alive, one plugin panic dragged the whole homed process down with it).

The kernel touches no IO. No HTTP calls, no file reads, no reach into the world outside its database. Web UI, QQ, command execution, web search are all plugins. The payoff isn't tidiness; it's that you can replace the entire interaction layer without touching the kernel.

Memory sinks as it ages; it doesn't pile up in the context window. Recent turns stay in the window, older ones settle into a document layer, oldest get distilled into a graph. That's why it can run for months without stuffing the whole history into every prompt.

It remembers scenes, not sessions. Move from work talk to personal talk and it splits the context by channel, conversation partner, tools used, and time of day. When a scene recurs, last time's conclusions come back, including the ones it got wrong.

Security is a wall, not a line each tool remembers to check. Everything leaving the kernel and everything flowing back from plugins passes through it. Secrets never enter the prompt (they're substituted at execution time), tool allow/deny lists, sensitive-word alerts, per-principal authorization (the same QQ plugin can grant an owner and a random group member different powers).

What it can do

No API listings. What you can point it at:

  • Where it talks: web UI, CLI/TUI, QQ groups and DMs, other agents (A2A), ACP in your IDE
  • What it sees: images, video, voice, screenshots, web pages
  • What it does: read and write files, run commands, write code, drive a real Chrome, calendar, notes, RSS, music
  • What it remembers: three-layer memory plus graph memory plus a knowledge base, recallable by scene
  • How it schedules: chat with a human while long jobs run in parallel sub-agents; jump the queue when the user pushes back; resume interrupted work where it stopped

28 built-in plugins, 89 model-callable tools. External plugins live one-per-repo at github.com/HologramAgent.

How it works

homed  (kernel: LLM orchestration + memory + retrieval)
   ↑ PluginSDK
plugins  (web UI / QQ / CLI / files / network / all IO)

Three channels between kernel and plugins: stdio JSON-RPC for control, shared memory for bulk data, an event ring for notifications. Large objects aren't serialized and copied twice.

Incoming messages hit a scheduler first, not the model. Queued work and interruptions are separate classes; interruptions come in four levels ("how badly can this wait"), and a higher level preempts a lower one while saving its state. Same level waits its turn.

Then seven pipeline stages, and the model can call tools in a loop. Multiple tool calls in one turn are serial by default; to run them in parallel a tool must declare itself safe. One undeclared tool in a batch drops the whole batch back to serial.

Quick Start

make build build-cli
./build/homed -data /tmp/ha
# Interactive mode
./build/waiter

# Or a single message
echo "Hi, remember I like coffee" | ./build/waiter

Daemon mode

waiter can also run resident, holding a persistent connection to homed and waiting for a TUI instance to attach. Useful when the agent needs to reach you proactively or keep a device bridge alive.

# Resident (connects to ~/.homeagent/cli.sock by default)
./build/waiter --daemon

# Custom socket
./build/waiter --socket /path/to/cli.sock --daemon

# Any TUI or one-shot instance then attaches to the running daemon instead of homed directly
./build/waiter

The daemon listens on ~/.homeagent/waiter.sock, replays the last 256 lines of conversation to new clients, survives disconnects, reconnects to homed on its own, and keeps the device bridge alive when device_gateway / device_token are configured.

Set API keys in the web UI at http://localhost:8080; they persist in SQLite.

Code Structure

cmd/homed/          Daemon entry, assembles all subsystems
cmd/waiter/         CLI client (Unix socket)
internal/
├── agent/core/     Agent core: input scheduler (2 classes + 4 levels), event loop, LLM tool loop, 7-stage pipeline, residents
├── agent/api/      LLM Provider (Lua adapter layer: provider.go drives the vm)
├── memory/         Three-layer memory: Graph(SQLite) / Document(JSON+TF-IDF) / Text(JSONL) + StaticEmbedder(pretrained word embedding/TF-IDF fallback) + CleanTemplateText(de-template)
├── knowledge/      Knowledge base (filesystem + TF-IDF)
├── plugin/         Plugin registry + subprocess loader (stdio RPC + shared memory segment + event ring)
├── plugins/        built-in plugins (webui / cli / files / cmd / mcp / kbtree / seq / skillmgr …)
├── sdk/            PluginSDK (Tool/Stage/Event three channels)
├── config/         SQLite config center
├── events/         Event bus
└── internal/lua/adapters/   10 LLM protocol adapter scripts
External plugin development: see the [hologramagentsdk](https://github.com/JianFeeeee/hologramagentsdk)
repo with the `hmapdev` toolchain. Each plugin has its own repo under
[github.com/HologramAgent](https://github.com/HologramAgent).

Documentation

Online docs:

In-repo docs (versioned with the code):

Downloads

Releases ship three variants:

Variant Contents For
full homed + waiter + desktop GUI + systemd unit Single-machine, everything
server homed + waiter + systemd unit Servers (no desktop environment)
client waiter + desktop GUI Connecting to a remote HologramAgent
  • Linux: .deb (amd64/arm64), .rpm (x86_64), .tar.gz
  • Windows: HologramAgent_v1.2.0_{Full,Server,Client}_win64.exe (NSIS installer, includes the AGPL license page). Since v1.2.0 homed no longer supports native Windows (it relies on fd inheritance and in-segment offset dereferencing), so the installer bootstraps WSL2 and installs the Linux packages inside the distribution the same way a Linux host would.
  • Portable: homeagent-bin-<os>_<arch>.tar.gz (homed/waiter/initconfig)
  • Verification: SHA256SUMS

The macOS homed requires a native macOS build (CGO + sqlite3), so release packages ship only waiter/initconfig.

Build

make build build-cli    # Build daemon + CLI
make test               # go test ./...
make install            # Install to system

Dependencies: Go 1.25+, CGo (go-sqlite3), Linux.

homed requires Linux (it relies on fd inheritance and intra-segment offset dereferencing of the shared memory region; see cmd/homed/platform_windows.go). On Windows only waiter.exe is built and homed runs under WSL2 (see Downloads). macOS can build waiter/initconfig; homed must be built on native macOS.

License

This project is released under the GNU Affero General Public License, version 3 (AGPL-3.0-only) — see LICENSE.

This is the strongest copyleft in the GPL family: besides shipping the complete corresponding source when you distribute the software, you must also offer the source to users who interact with it over a network (§13, Remote Network Interaction). Anyone running a modified HologramAgent as a network service therefore has to make the modified source available to that service's users.

Plugins are statically linked against this project through the public hologramagentsdk (the SDK source ends up inside the plugin binary), but that repository is released under MIT. That is a permissive license, so code received under it does not inherit this project's AGPL. External plugins are therefore not derivative works of this project: authors pick their own license (closed-source, commercial or private included), with no same-license obligation and no §13 network clause. The safety and vitality of the third-party plugin ecosystem rest on this.

The boundary is clean: AGPL covers the kernel and the bundled plugins (homed, internal/, the 13 built-in plugins under internal/plugins/); MIT covers the public SDK (sdk/, whose go.mod has zero external dependencies and imports only the Go standard library, never any kernel code). Process isolation is beside the point here. What decides the license is the linked SDK code itself, and that code is MIT.

Third-party components shipped with the packages

Component License Location
Chinese-CLIP ViT-B/16 (ONNX artifacts) Apache-2.0 /usr/lib/hologram/models/chinese-clip-vit-b16-onnx/
ONNX Runtime (libonnxruntime.so) MIT /usr/lib/hologram/onnxruntime/
jieba dictionary (embedded in the binary) MIT internal/memory/jiebadict/
Go dependencies (go-sqlite3, gojieba, bubbletea, …) MIT / BSD-3 / Apache-2.0 permissive, AGPL-3.0-compatible

These components keep their own licenses and are not relicensed by this project. Full texts are shipped in /usr/share/doc/hologramagent/licenses/, and the package metadata declares this package as AGPL-3.0-only.