docs: 按 humanizer-zh 规则再改 README 开头

上一版开头四句被指出仍有 AI 味。拆开看问题在：

  · 四句长度接近、每句都是金句，没有一句是普通陈述
  · "说人话："是元话语，AI 特有的"宣布要通俗化"动作
  · "白天聊过的事，晚上还记得" + "三周前说过的偏好，不会因为上下文窗口
    滚动就丢了" —— 严格对仗，一个口语一个技术解释混在一起
  · "插件崩了它不倒，模型换了它不改" —— 两组四字对仗

用 humanizer-zh 的规则过了一遍，命中三条：

1. **§A.1 不是 X，而是 Y** —— "跟直接调 API 的区别在于它把长期当成了
   基本需求，而不是事后加个向量库"，后半句是假想敌。删掉后逻辑没损失。
2. **§A.2 单句收尾** —— "这个仓库从 2026 年 7 月开始开发，现在 1.4.0，
   一千多个提交" 独立成段作收尾。并入上一段。
3. **§A.5 与假想敌辩论** —— 小标题 "它跟别的 Agent 框架哪里不一样"。
   改成 "几个设计决定"。

另外自重写：

- 开头从四句金句改成一句陈述 + 一句具体 + 一段解释。不是排比。
- "## 能力" 从五项 "**类别**：三词·三词·三词" 改成有详有略的散文
  （五项同模板是最密集的 AI 指纹之一）
- "## 几个设计决定" 从五条 "**X，不是 Y。**" 改成一段段长短不一的叙述，
  其中 3 条原本是同一个句式
- 删掉与开头重复的记忆下沉描述

英文版同步，不是直译：`What makes it different` → `Design decisions`，
开头去掉同样的假想敌与收尾句。

## 修掉一处我自己写出来的事实错误

上一版我写了 "微信和 QQ 的文件、语音消息能收发"。核查后：仓库里没有微信
插件，只有 clawhubadapter 注释里提到微信作为通用通道的例子。已删掉微信。

## 验证

- 两版死链检查为空
- 代码块配对（14/14）
- 9 个二级标题中英对齐

README_EN.md

@@ -4,58 +4,56 @@
 
 > **中文**: [README.md](./README.md)
 
-An agent kernel that runs for months and still remembers.
+HologramAgent is an agent kernel that runs on your own hardware. Connect it to QQ, a web UI,
+your shell, your files, a browser, and it works in all of them.
 
-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.
+Memory sinks: the last few turns stay in context, older ones become documents, oldest get
+distilled into triples in a graph database. That is why it can run for months without
+stuffing the entire history into every prompt.
 
 ```bash
 ./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.
+You need a Linux box. API keys go in through the web UI and live in local SQLite.
+Development started July 2026; currently 1.4.0.
 
 ---
 
-## What makes it different
+## Design decisions
 
-**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).
+Plugins run in separate processes. One panics and the kernel stays up; it restarts on its
+own. Drop in a new `plugin.bin` and it's live. The earlier version used C shared libraries,
+where `dlclose` silently no-ops under `DF_1_NODELETE`, cgo timeouts leave threads alive, and
+one plugin panic dragged `homed` down with it. That is why it was rewritten as subprocesses
+plus shared memory.
 
-**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.
+The kernel itself makes no HTTP calls and reads no files. Everything that touches the outside
+world lives in plugins: the web UI, QQ, command execution, web search, the browser. Not for
+tidiness. It means you can swap 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.
+Inside one QQ plugin, a group owner and a random member can hold different permissions.
+Instructions arriving from another agent don't get written into your memory, though they can
+trigger recall. The kernel's security module makes those calls; plugins only declare.
 
-**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
+Memory is partitioned by scene, not by session. Move from work talk to personal talk and it
+splits 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:
+Places it talks: web UI, shell, QQ groups and DMs, other agents over A2A, and an ACP server
+inside your IDE. It can look at images, video, voice, and web pages, and it can drive a real
+Chrome.
 
-- **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
+For getting things done it reads and writes files, runs commands, writes code, and handles
+calendars, notes, RSS, and music. QQ files and voice messages go both ways.
+
+Behind that sit three memory layers plus a graph database plus a knowledge base, recalled by
+scene. When new work arrives mid-task it enters a scheduler; if the user pushes back it can
+jump the queue, and interrupted work saves its state and resumes. Long jobs can be handed to
+sub-agents so they don't block the line you're talking on.
 
 28 built-in plugins, 89 model-callable tools. External plugins live one-per-repo at
 [github.com/HologramAgent](https://github.com/HologramAgent).
@@ -68,16 +66,18 @@ homed  (kernel: LLM orchestration + memory + retrieval)
 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.
+Three channels between kernel and plugins: JSON-RPC over stdio for control, shared memory
+for bulk data, an event ring for notifications. Large objects aren't serialized, so there's
+nothing to copy 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.
+Incoming messages hit a scheduler first, not the model. This exists for the case where work is
+already in flight and a new instruction arrives: queued work and interruptions are separate
+classes, interruptions carry four urgency levels, a higher level preempts a lower one and the
+preempted work saves its state to resume later. Same level waits.
 
-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.
+Below that sits a seven-stage pipeline where the model can call tools in a loop. Multiple tool
+calls in one turn are serial by default unless a tool declares itself concurrency-safe. One
+undeclared tool in a batch drops the whole batch back to serial.
 
 ## Quick Start