jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-26 20:33:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
619 Commits 5 Branches 27 Tags
2c810bbbce7e71f4cfba568dd861462098a2c2dd
Commit Graph

14 Commits

Author SHA1 Message Date
JianFeeeee
4d3962a845 feat(csrc): 第二刀 —— 零分配 JSON 扫描/取值层 ha_json_scan（含黄金对照） 
C 化第二刀：为协议编解码层铺 JSON 底座。**本刀只交付库 + 验收，
未改 Go 生产路径**（接线是独立一步，库先验完再换产线）。

为什么是它：SSE 单块解析（parseOpenAICompatibleStreamChunkFull）是每个流式
chunk 都要跑的最热路径，实测 1937ns/13allocs（content 块）、3122ns/21allocs
（toolcall 块），而纯字节扫描理论下限 133ns/1alloc —— 差距 15~23×。
一次 1 万块的会话 = 1~2 万次堆分配，正是 GC 抖动的来源。

为什么不复用 SDK 的 remotedevice/ha_json.c（实测三缺陷，不可直接复用）：
  ① 无 \u 解码：\u4f60\u597d → ?0?d?d?0（非 ASCII 全靠转义时内容直接损坏）
  ② 只有 _get_int 无浮点：temperature:0.7 静默变 0
  ③ null 与「键缺失」不可区分
  外加它是 DOM + malloc，与本层「不 malloc / 零拷贝 / 纯函数」正交。

设计：scan（结构，零分配零解码）+ extract（取值，按需解码）两段分离。
content 可能是很大的多模态数组，而 stringifyContent 只需要 text 字段拼起来；
若 scan 就解码并分配缓冲，等于把成本付给不需要它的调用方。

★ 被测试抓出 7 个真实缺陷（写 C 时同一逻辑我读三遍都认为正确）：
  1 代理对合成成功后未跳过 unconditionally 的 U+FFFD 发射（😀 → 两个 FFFD）
  2 过长编码检查用了只含首字节位的 cp（「你」→ 6 个 FFFD）
  3 members_next 只报值起点不消费值 → 游标停在值前（模糊测试第一轮抓到）
  4 扫描阶段不校验转义字符合法性（{"a":"\q"} C 判合法、json.Valid=false）
  5 扫描阶段不校验 \u 后四位十六进制（同上）
  6 get_int 接受前导零（007 / 00）
  7 cgo 桥接把 C 结构体声明为 Go 局部变量 → 运行时 panic
     （cgo argument has Go pointer to unpinned Go pointer）
  其中 4 个是「静默分叉」——不崩、不报错，生产里表现为「内容少一个字符」
  或「某些块被静默丢弃」，极难归因。这正是黄金对照不可省的理由。

★ 另纠正我自己两次错误的「真值」（比代码 bug 更危险，会变成错误规格）：
  第一版真值表里 content:{} 的花括号少了一层，把「我写错 JSON」误读成
  「Go 对 content 严格」。修正后实测发现一对方向相反的语义：
  content 走 interface{} 宽松（{}→"{}"、true→"true"），
  reasoning_content/usage/finish_reason 强类型严格（123 ⇒ 整块作废）。
  照错误表写 C 会产出「比 Go 更严格」的实现，静默丢弃本该生效的块。

两个由缺陷倒逼的设计决定：
  - members_next 返回**完整值 span** 并内部跳过 ⇒ 「返回 1」蕴含「成员良构」。
    要求调用方自己推进游标的 API 是错的：忘一次就解析到上一个值且不报错。
  - members_complete() 区分「正常扫到 }」与「输入畸形」，否则无法复刻 Go 严格性。

同时修两个基础设施目标对「多源文件/多测试」的适配：
  - csrc-sanitize：每个契约测试各自链接（多个 main 合链会 multiple definition，
    而报错被吞后会被误报成「本机无 sanitizer」——一个假的 SKIP）
  - csrc-cross：多源文件改用 -fsyntax-only 逐文件（gcc 不支持多源单 -o）

实测（全部当场可复现）：
  - C 契约测试 119 项断言全过；黄金对照 5 组全过（语法/成员/解码/整数/随机字节）
  - libFuzzer 4948 万次运行零崩溃（121s）
  - ASan+UBSan PASS（两个契约测试各跑）；gcc+clang 零告警；arm64 交叉编译 0 告警
  - 全量 go test -count=1 ./... 0 FAIL；make build-linux-arm64 → ELF aarch64
  - 纪律检查 SDK 公开接口 diff = 0 行（未触碰 SDK）

决策关闭（jianf 本轮裁决）：C 实现留主仓 csrc/（它本就是替换内核 Go 实现，
SDK 从未被触碰，跨端复用才需进 SDK 而它们不调用本层）；ha_json.c 不复用；
下一刀即协议编解码层。
 2026-09-26 10:07:27 +08:00
JianFeeeee
8070844fe9 build(csrc): C 基础设施门禁（ABI 版本 / 告警 / sanitizer / 交叉编译 / 模糊测试） 
C 化从「一把刀」推进到「可持续推进」，本轮先把基础设施建起来：
不建它，后续每个 C 切片都在裸奔（无告警门禁、无内存安全检查、
无交叉编译验证、无 ABI 漂移检测）。

新增门禁（make check-csrc / check-csrc-full，已接进 make test）：
- csrc-lint   gcc+clang 双编译器 × -Wall -Wextra -Wpedantic -Wshadow
              -Wconversion，零告警才算过（-Wconversion 是为 cgo 窄化
              准备的：size_t→int 截断在默认档下是静默的）
- csrc-abi    ABI 版本运行期自述 + 荒谬值检查
- csrc-headers 头文件自包含性（每个 .h 能单独编过）
- csrc-sanitize ASan+UBSan 跑 C 契约测试
- csrc-cross  arm64 交叉编译（homed 的真实发布目标）
- csrc-fuzz   libFuzzer：内存安全 + 6 条不变式（可 CI 门禁）

新增 ABI 契约（csrc/include/ha_abi.h）：
- ha_codec.h 声明「签名冻结」，但冻结只写在注释里；现改为
  HA_CODEC_ABI_MAJOR/MINOR + 运行期自述 + Go 侧常量，
  三方交叉断言，版本漂移在测试期判红而非线上表现为行为诡异。
- 门禁当场抓出我自己的两个真 bug：①_Static_assert 是 C11 而项目
  是 -std=c99（-Wpedantic 报的）；②##msg 不能拼接字符串字面量，
  导致两个断言共用一个 typedef 名（clang 报的）。

基础设施当场抓出的三个真实缺陷（都是「本机 gcc 能编过、别处会炸」类）：
- bench 用了 POSIX clock_gettime，而 CMake 刻意 C_EXTENSIONS OFF
  （严格 c99）→ 头文件未声明；补 _POSIX_C_SOURCE（须在任何头之前）
- 头文件缺 include 时只在「恰好被别的头先包含」处静默编过
- Go 不允许在 _test.go 用 cgo ⇒ C 侧 const 桥接只能放非测试文件，
  且 cgo 生成的 *_Cvar_* 不是 Go 常量（「两边一起错成一样」的盲区，
  改用 C 函数返回 + 编译期 _Static_assert 补上）

实测（全部当场可复现）：
- 双编译器 × c99/c11 零告警；ASan+UBSan PASS
- libFuzzer 91s 跑 3329316 次、零崩溃（6 条不变式全过）
- 变异测试：改 C 侧宏 / 让 Go 常量与 C 函数「一起错成一样」，
  均被对应断言抓住（证明门禁不是摆设）
- C 侧纯函数基准（首次把函数体成本与 cgo 边界成本分开测）：
  ascii_1k 121.7ns/8.4GB/s；zh_1k 1434ns；truncate 两者均约 128-134ns
- 全量 go test -count=1 ./...：57 包 0 FAIL
- make build-linux-arm64 → ELF aarch64
- 纪律检查 FAIL=0；SDK 公开接口 diff = 0 行

未动：csrc/ 是内核 C ABI，不属 third_party/homeagent-sdk 公开接口。
 2026-09-26 09:44:17 +08:00
JianFeeeee
7799ca4559 perf(c-core): 完全 C 化 + 消灭初版的 malloc/拷贝开销（C 从「更慢」变「明显更快」） 
上一提交的基准结论是错的："C 比 Go 慢" 不成立 —— 那是我把自己的
malloc/拷贝开销误当成了 cgo 的固有成本。本提交先拆解成本、再逐项消灭。

## 成本拆解（同机、百万次 benchtime）

| 场景 | ns/op |
|---|---:|
| cgo 边界（零拷贝传指针 + 空函数体）| 31.9  ← cgo 真实固有成本 |
| + 一次 C.CString + C 侧 strlen | 105-111（多出 ~75ns）|
| 初版 ModelContextWindow（另加 lower_dup malloc + 16×strstr）| 175 |

即 82% 开销是自找的。而初版还违反了自己写在设计文档 §四 的原则第 1 条
「C 接口只吃 const char* + 长度」——它没传长度，让 C 侧 strlen 再扫一遍。

## 逐项修复

1. C.CString（malloc+整串拷贝）→ unsafe.StringData 传指针+长度，零拷贝
2. C 侧 strlen 再扫一遍 → 长度由调用方传入，不扫
3. truncate 的 malloc 输出缓冲 + GoStringN 拷回 → C 只返回**字节数**
   （结果必然是输入前缀），Go 侧 s[:n] 完成切片，全程零分配
4. lower_dup 每次 malloc 模型名 → 栈缓冲折叠，超长走零分配回退
5. 逐字节 utf8_next 函数调用 → 字级（8 字节）ASCII 检测
6. truncate 扫完整串才判断 → 数满 keep 个 rune 立即返回（提前短路）
7. 纯 Go 侧 len([]rune(s))/[]rune(s)（1KB 分配 4KB）→
   utf8.RuneCountInString / DecodeRuneInString 游走，零分配

## 结果

| 基准 | 初版 C | 优化后 C | 纯 Go | 提升 |
|---|---:|---:|---:|---:|
| ModelContextWindow | 175 | 76.5 | 46.8 | 2.3× |
| EstimateTokens / 1KB ASCII | 2318 | 80.8 | 326 | 28.7× |
| TruncateByTokens / 1KB ASCII | 2594 | 71.7 | 411 | 36× |
| TruncateByTokens / 1KB 中文 | 3923 | 70.1 | 3097 | 56× |

## 完全 C 化（jianf 裁定）

撤掉我一度加的「短串 <32B 走回 Go」按长度分派：那会同时存在两份语义
可能分叉的实现。C 是唯一实现。

代价如实记录：EstimateTokens("qq") 这类极短串上 C 约 47ns（几乎全是
31ns 边界成本）vs 纯 Go 约 3ns，慢约一个数量级；绝对值纳秒级
（0.000047ms），单次请求尺度可忽略。若某循环对极短串高频调用，
正确应对是**把该循环 C 化（批量传一次）**，而不是按长度分派回 Go。

## 顺带补的正确性缺口（初版是真错的）

初版 C 的 UTF-8 解码只按首字节推断长度、**不校验后续字节**，
因此对畸形序列会与 Go 分叉：例 "\xE4\x41\x41"，Go 判 3 rune，
初版判 1 rune ⇒ rune 计数偏差 ⇒ token 预算与截断点偏移。
这类偏差**只影响计数、不会崩**，不测发现不了。

现在 C 侧做与 utf8.DecodeRuneInString 等价的完整校验（含过长编码、
代理对、超 U+10FFFF、截断序列），语义边界逐条注释。
代价：中文密集输入比初版慢（1467 vs 840）—— 这是刻意的正确性代价，
且仍比纯 Go 快 2×。

新增测试：
- TestGolden_InvalidUTF8：3000 组**任意字节**（含畸形序列）对拍，
  覆盖初版会分叉的输入类别
- TestGolden_TruncateAlwaysPrefix：截断结果必为原串前缀且不超长
- C 契约测试从 21 项扩到 40 项（含非 NUL 结尾、超长名、畸形 UTF-8）

## 包现在要求 cgo 才能编译

删除 codec_nocgo.go：CGO_ENABLED=0 下整包构建失败（错误直指缺失符号）。
不保留回退的理由：只验证过一条路，就不该存在第二条。
实测这不影响任何构建 —— go list -deps 证明只有 cmd/homed 依赖本包，
而 waiter/initconfig/memgc/mock-server 均不依赖（逐个验过），
且 homed 本就强制 cgo（sqlite3 + gojieba）。仓库无 CI。

Makefile 把「不许有第二条路」变成可执行断言：check-codec-cgo-only
（断言 cgo 下全绿 **且** CGO_ENABLED=0 下必须失败）。

## 验证

- C 契约测试 40/40（gcc -Wall -Wextra 零警告）
- 黄金对照 6 个测试全绿（含 2000 组随机 + 3000 组畸形字节对拍）
- 变异测试：改 C 侧返回值后 go test 立即 FAIL（确认真的走 C）
- make check-codec-cgo-only 两项断言通过
- go vet ./... 干净；全量 go test -count=1 ./... → 38 ok / 0 FAIL

## 已知既有 flaky（与本改动无关，单独记录）

internal/plugins 在全量并发下偶发一次 SIGSEGV，栈在
internal/plugin/proc/{unified.go:234,arena.go:197}（arena 的 getU32）。
该两文件最后修改于 09-10，本提交 0 处触及；随后连跑 5 次单包 +
2 次全量均通过。初步判断是 arena/shared-region 的既有竞态，需单独排查。
 2026-09-25 15:40:20 +08:00
JianFeeeee
7351c6ca2e feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链 
第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），
价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并
建立可复现的对照范式，后面每扩一个函数都复用它。

## 为什么是这三个

按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。

## 关键设计：包内符号链接，不链接静态库、不 include 包外源

三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」：

1. ❌ 链接 `csrc/build/libha_codec.a`（原方案）
   - .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），
     而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，
     实测报 `cannot find .../libha_codec.a`
   - 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a
     被链进目标产物，实测报 `file in wrong format`

2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含）
   ★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测：包外源把返回值
   7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内
   文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
   （包内 shim `#include` 包外源同样漏跟踪，已实测排除。）

3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
   文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，
   也不需要「同步 C 源」的 make 目标。

## 不需要额外 build tag

ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；
而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。

## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖）

- Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报
  `gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
  （deploy/packaging/build.sh:49 一直是对的，Makefile 漏了）
- Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/*.syso 是 Windows
  COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows
  平台报 `file format not recognized`（build.sh 有 hide_syso_for_target）

## 验证（每条可复现）

- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB）
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB）
- 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建
- 变异 C 源（131072→777）后**同一缓存**下 go test 立即 FAIL（改前：仍报 ok）
- `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100%
- 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL

新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。

## 文档

- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因
  「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述）
- plan.md 的 P0-1 标记为已修复，附实测证据
 2026-09-25 14:45:08 +08:00
JianFeeeee
065732f42e chore(version): 客户端版本与内核对齐（唯一事实源 internal/meta.Version） 
此前三份版本号互不相干：内核 1.4.0、GUI 1.0.0、鸿蒙 1.1.1。手工各改各的
必然漂移，所以把「对齐」做成机械动作而不是约定：

- deploy/scripts/sync-client-versions.sh：从 internal/meta.Version 读版本，
  同步 cmd/gui/package.json 与鸿蒙 AppScope/app.json5（versionName +
  versionCode=X*1e6+Y*1e3+Z）；--check 给 CI/Makefile 做漂移门禁。
- Makefile 新增 sync-client-versions / check-client-versions；build-cli 也注入
  LDFLAGS，waiter 与 homed 同版本。
- 鸿蒙：新增 common/AppVersion.ets，从 bundleManager 读安装包 versionName，
  BridgeProtocol/BridgeCaps 里两处硬编码 '1.1.1' 改为读它——版本只剩
  app.json5 一份，杜绝第二真相。
- waiter：`-version` 打印版本，启动横幅与设备桥 hello 的 version 字段
  直接引用 internal/meta，与内核天然同源。

对齐后：GUI 1.4.0 / 鸿蒙 1.4.0(1004000) / waiter 1.4.0 / 内核 1.4.0。
 2026-09-15 11:03:26 +08:00
JianFeeeee
9d45cd0277 fix(rel): 场景贯穿流水线到块层 + 编辑不再丢置信度/场景 + 构建默认带 onnxruntime 
三件事，前两件是上一轮热部署暴露/遗留的真缺陷。

1) 热部署差点静默降级（已修）
   `make build` 之前**不带任何 tags**，而发行构建（deploy/packaging/build.sh）
   默认 HOMED_TAGS=onnxruntime，package-linux.sh 还会直接拒收非 onnxruntime 二进制。
   实测差异：33MB vs 84MB；启动日志里
   「multimodal space active: provider=chineseclip dim=512」整行消失、
   少加载一个插件（chinese-clip/qwen3vl provider 降级）、
   静态词向量退回 fallback。即「随手 make build」与「发行构建」不是同一个东西，
   而部署时无从察觉。
   修：Makefile 的 build 默认 HOMED_TAGS ?= onnxruntime（与打包脚本一致），
   构建后自动校验二进制里有没有 onnxruntime，缺了就打 WARN。
   生产已按此重新构建部署（v1.4.0+hotfix.d98bf51，已核实 provider 行回归）。

2) memory_edit 每跑一次就静默降级一次（新）
   memory_edit 是「按包含匹配 Purge + 写新三元组」，中间那一步把旧关系的
   置信度、原句、**场景引用**全丢了：置信度被重置成默认 1.0，场景钉死的记忆
   被打散成无场景。而关系复审心跳（reviewLoop）走的正是这条路——每轮复审都
   在无声地削记忆质量。
   修：编辑前用 FindRelations 精确取回旧关系，把置信度/原句/场景带到新三元组；
   新增 ScenesOfRelation。Purge（hard/soft）与 PurgeNoise/PurgeOrphans 之后
   统一清理悬空 scene_refs，SceneStats 不再说谎。

3) 场景贯穿流水线到块层（按「rel 应贯穿整条流水线」的设计）
   此前场景只到 relation/entity：块（L0/L3 一等记忆块）没有场景，于是
   「那场 QQ 对话里发过来的那张图」在场面重现时永远取不回来。
   - MemoryBlock.Scene + memory_blocks.scene 列（幂等 ALTER 迁移）。
   - scene_refs 增加 ref_text 承载字符串主键（块/文档 id 不是数值）。
     **不能只 ALTER ADD COLUMN**：唯一约束要从 (scene_id,kind,ref_id) 变成
     含 ref_text 的四元组，而 ALTER 改不了约束——旧约束会让「同场景第 2 个块」
     直接冲突（只在多块场景暴露）。改为按列探测后整表重建并搬运旧数据。
   - PutMemoryBlocks 同事务挂 scene_refs(kind='block')；无场景重写不覆盖已有场景
     （否则一次无场景重写就静默抹掉挂载）。
   - RecallByScene 返回块；FormatContext 增「场景素材」段（模态 + 文本/短 digest），
     上限 3 条。
   - 生产者接线：attachBlocksToSentence 让块继承承载它的三元组的场景；
     linkBlocksToDocument 让文档的块继承文档来源场景（QQ 归档的图挂 chan:qq）。

验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景块（取回/同场景多块/无场景重写不抹场景/悬空引用清理）、
**旧表结构迁移**（降级成旧 scene_refs 后重开，旧数据保留且多块可写）、
场景素材注入、FindRelations+ScenesOfRelation 编辑搬运闭环。

生产：已重建（-tags onnxruntime）并原子替换 /usr/local/bin/homed + 重启，
35 插件全加载、panic/fatal=0、chineseclip 空间 active。
 2026-09-15 09:03:36 +08:00
HomeAgent Agent
a15e7c2dc1 chore(lint): 加 .golangci.yml（funlen/gocyclo/lll/dupl，warn-only）+ make lint-full 
main 上曾有 4 个 >=300 行函数、12 个 >=200 行函数；没有复杂度 linter 是它们
长期存活的直接原因。先以 warn-only（issues.exit-code:0）立阈值、只出清单，
历史债下降后再收成硬门禁。测试与 testdata/third_party 排除长度类规则。
 2026-09-13 21:59:10 +08:00
root
3a5a16c916 bump version to v0.8.0 2026-07-29 15:45:24 +08:00
JianFeeeee
2c5f9ff262 v0.7.2: 根目录清理 + Agent 心跳重构 + 内嵌 ONNX 模型 
- 根目录清理: branding/docs/knowledge -> assets/, package/tools/deploy -> deploy/
- meta.go: Version 0.7.2, SDKCompatibleVersion 语义改为最高兼容
- Makefile: 版本回退 0.7.2
- registry.go: 系统提示词改用 meta.Version 格式化
- Agent 心跳: reorgGraph 拆分为三个独立循环(archive/merge/review)，各自可配间隔
- GraphDB: 新增 sentences 表 + 关系句子溯源 + ClearSentenceID + CleanupOrphanedSentences
- Knowledge: 支持词嵌入向量化器
- NLP 四阶段流水线: Parse -> Extract -> Verify -> Fuse + SentenceRef
- 移除远程 HTTP 解析器(remote_parser.go)
- 新增内嵌 ONNX 模型(vocab + dep_parser.onnx):
  +build onnxruntime: 全量 ONNX Runtime 推理
  !build onnxruntime: 内嵌词表规则式降级解析器
- config: core.agent.onnx_model_path 替代 dep_parser_url
 2026-07-28 09:56:26 +08:00
root
951d31cca0 feat: align GUI and CLI with WebUI - move GUI to cmd/gui/, add REPL+mgmt to waiter, enhance GUI features 2026-07-16 20:28:56 +08:00
root
1f1233b823 refactor: P0-P3 fixes, C1 cleanup, architecture diagrams, go.work upgrade 
- P0-1: ProviderError type + ReportStatus for precise 401/403 detection
- P0-2: Remove -config flag from deploy/homeagent.service
- P2-1: 5s debounce on context.go Save()
- P2-2→C1: Delete output_set_channel entirely
- P2-3: Extract mediaDataURL/mediaChat helpers
- P2-4: Dedup defaultSources var
- P3: Delete dead packages (embed/tokenizer/container/snapshot)
- P3: Delete dead functions (messagesToMap, RunStageAll)
- CL: Update .gitignore, docs, Makefile, gojieba removal
- Config: Delete config/config.yaml, update docs
- Arch: Remove EmitOutputTo from emitResponse
- CL-1: go.work 1.19→1.21
- Docs: Add Mermaid architecture diagrams to README
- Docs: Add kernel-rebuild requires plugin-rebuild note to PLUGIN_DEV.md
 2026-07-12 11:42:56 +08:00
root
c3816dc699 IO 抽象层增强：非文本输入支持 + waiter CLI 重写 
PluginSDK:
- 添加 InjectInput / InjectInputSync / InjectInterrupt 泛型接口
- 插件现在可注入 image/audio/file 等任意类型输入

Provider:
- 添加 ContentBlock / ImageURL / AudioURL 类型
- Message 增加 Blocks 字段，Content 在非空 Blocks 时序列化为数组（多模态格式）

Agent:
- handleInput 新增 image/audio 类型分发 → processMediaInput
- processMediaInput 将媒体数据附着到对话上下文，LLM 自主决策处理策略
- 新增内置工具：describe_image / transcribe_audio / ocr_image（pendingMedia 驱动）
- 工具仅当有未处理媒体数据时注册，通过 Provider 直接调用多模态模型

Config:
- 新增 InputProcessingConfig（image/audio 处理配置）
- 含 fallback_provider / describe_prompt / ocr_enabled 等选项

Waiter CLI 重写:
- 配置文件 ~/.config/homeagent/cli.yaml（自动发现 socket）
- 原始终端行编辑 + 命令历史持久化 + 彩色输出
- 内置命令：/help /reconnect /connect /remote /local /prompt
- 断线自动重连
 2026-07-04 15:01:35 +08:00
root
2d314b3e9c 重构: 插件自注册 + .so 动态加载 + 中断打断机制 
- 所有内置插件 init() 自注册 (plugin.RegisterFactory), 移除 main.go 硬编码
- 新增 .so 动态加载器 (internal/plugin/dynamic.go), 插件可编译为 plugin.so
- 新增 plugin.json 元数据 (internal/plugin/manifest.go)
- 新增 interceptLoop 独立 goroutine:
  (a) cancelLLM() 取消进行中的 HTTP 请求
  (b) interceptCh → drainInterrupt() 注入 [打断消息] 到 LLM 上下文
  (c) InjectInput 空闲时触发新处理循环
- 新增 internal/plugins/all.go 空白导入触发所有内置插件 init()
- internal/sdk/ 作为 PluginSDK 正式 Go API
- internal/api/ → internal/plugins/webui/ 迁移
- 删除旧 cmd/cli/, 使用 cmd/waiter/ 替代
- 更新 PLAN.md / ARCHITECTURE.md / README.md 文档
 2026-07-03 16:53:34 +08:00
root
bc26850b50 feat: complete HomeAgent architecture v2 
- IO abstraction layer with OutputChannel routing and capability validation
- Three-layer memory (Context-Document-Graph) with TF-IDF relevance pruning
- OneBot V11 QQ protocol plugin with Reverse WebSocket client
- Plugin system with hot-reload (SKILL.md + native factories)
- Knowledge system with TF-IDF vector indexing
- Personality system (personal.md)
- Text memory (JSONL with rotation)
- Change tracker (overlayfs) with rollback
- Lua adapter VM
- Design document (DESIGN.md)

Module: gitcode.com/JianFeeeee/HomeAgent
 2026-07-02 12:04:36 +08:00