HomeAgent

jianf/HomeAgent

Fork 0

mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-22 18:08:04 +00:00

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	aba1770701	fix(lightkernel): 传统上下文落到实处 —— 子不做策略性裁剪（并修掉裁剪估算的字节/rune 单位混用）用户指出实现不自洽："子 agent 是传统上下文，没有裁剪"。查证属实：子仍走 `formatMergedTimeline` 的预算裁剪、也可能走 `pruneOnInput`（既裁剪又向 doc 记忆归档）。即"动态上下文"（父专属能力）漏进了轻量内核。 ## 三处闸门（按 isLightKernel() 判） 1. 拼装预算：新增 `contextTokenBudget(b)` —— 父用动态上下文的 `ContextTokens`，子用整个窗口 `MaxContext`。两个调用点都改（`stepPrepare`、`rebaseFramePrefix`；漏掉后者时 prepare 之后的重建仍会裁，实测就是这么被抓出来的）。 2. pruneOnInput：轻量内核前置返回 —— 不做按相关度裁剪、不向 doc 记忆归档。 3. doc 记忆 / 整理流水线：早已由 `a.memory == nil` 关闭（N2c）。 ## "不裁"的准确含义不做策略性裁剪（不按相关度挑、不归档），只受"模型能收多少"这个硬上限约束；且在撞到硬上限之前，contextfull（90% 窗口）已按 L4 上报父 agent ⇒ 丢事件的决定权在父（压缩/回收/销毁），不在内核。文档 §16.0.0 记录三处闸门表。 ## 顺带修掉的既有 bug（单位混用） `formatMergedTimeline` 逐事件估算原来是 `len(e.Source)+len(e.Input)+40` 再 ×2 —— `len()` 是字节，而 `EstimateTokens` 是 rune×2 ⇒ 中文事件被高估 3 倍：实测 2384 字的中文事件被估成 14398 token > 8192，于是窗口还有余量也提前 break、把更早的事件整段丢掉。改为统一走 `EstimateTokens`（对父同样生效：中文长会话不再被过早裁剪）。 ## 测试 - 新增 `TestLightKernel_TraditionalContextNoTrimming`：用记录模型实收消息的 provider 断言"更早的事件仍在"（为什么不看 TaskFrame：`prepareInputTask` 只做前半段，消息在 `runTaskSteps`/`stepPrepare` 才拼出来 —— 我第一版断言就打在了空帧上）；填充量取"超过动态份额、但仍在窗口内"，从而能区分父/子两种行为。 - 新增 `TestFullKernel_StillUsesDynamicContext` 作对照（父仍用动态份额）。全量 go test ./... 37 包 ok / 0 FAIL；-race 干净。	2026-09-13 10:36:04 +08:00
JianFeeeee	48cfa8fb6c	feat(lightkernel): N2c —— 轻量内核 profile（窄接口 GraphMemory + nil 即禁用整理面）按用户指出的关键点（a.memory 多数使用点属"主 agent 整理记忆"与"记忆整理流水线"，子不该有那些路径）实现，方案见设计 §16.0。 ## 窄接口：只有 Recall + Commit 新增 `GraphMemory` 接口（memoryface.go）—— 按调用方实测分类后，真正"根与子都要"的只有这两个： - `Recall`：上下文检索 / memory_recall - `Commit`：自动写入路径的图部分 / memory_commit 新增 `Agent.graph`（共同面）与 `Agent.graphMem()` 访问器： - `graph` 显式为 nil 时回落到 `memory` ⇒ 既有"只用 Agent 字面量设 memory"的测试无需改动（原本会出现"必须同时设两个字段"的脚坑，实测踩到后去掉了） - 轻量内核：`graph = memory.LightMemory`，`memory = nil` ## nil 即禁用：整理面自动消失，不需要受限包装子的 `a.memory == nil` ⇒ 既有的 22 处 `if a.memory != nil` 关卡自动禁掉全部整理面： - 记忆整理流水线（distill.go 的 archive/review/merge 循环） - 记忆块 + 媒体桥（graphmedia.go / medialoop.go） - 记忆整理工具（memory_merge / memory_delete_entity / memory_block_merge / memory_purge / memory_edit / memory_introspect）—— 它们本就在 `if a.memory != nil` 块内唯一拆开的一处是自动写入 `commitTriplesWithMedia`：图部分走 `graphMem().Commit`（父落 main、子落 temp），块/媒体部分仍由 `a.memory != nil` 守卫。 `executeMemoryTool` 的读路径改走 `graphMem().Recall`；整理类 case 加 `requireFull()` 闸门，被直调时明确报"本 agent 是轻量内核：记忆整理不可用"，不静默降级。 ## 验收（3 项新测试） - `TestLightProfile_MemoryFaceWiring`：整理面为 nil、写入只落 temp（主库无子痕迹）、读是并集（主库实体 + temp 实体都看得到） - `TestLightProfile_OrganizeToolsAbsentAndRefused`：整理类工具不进工具表*；即便被直调也明确报"轻量内核不支持" - `TestFullProfile_KeepsOrganizeFace`：对照，根 agent 仍保留整理面与整理工具全仓 go test ./... 37 包 ok / 0 FAIL；-race（agent/memory）干净；gofmt 干净。	2026-09-13 10:02:02 +08:00

Author

SHA1

Message

Date

JianFeeeee

aba1770701

fix(lightkernel): 传统上下文落到实处 —— 子不做策略性裁剪（并修掉裁剪估算的字节/rune 单位混用）

用户指出实现不自洽："子 agent 是传统上下文，没有裁剪"。查证属实：子仍走
`formatMergedTimeline` 的预算裁剪、也可能走 `pruneOnInput`（既裁剪又向 doc 记忆归档）。
即"动态上下文"（父专属能力）漏进了轻量内核。

## 三处闸门（按 isLightKernel() 判）

1. **拼装预算**：新增 `contextTokenBudget(b)` —— 父用动态上下文的 `ContextTokens`，
   子用**整个窗口** `MaxContext`。两个调用点都改（`stepPrepare`、`rebaseFramePrefix`；
   漏掉后者时 prepare 之后的重建仍会裁，实测就是这么被抓出来的）。
2. **pruneOnInput**：轻量内核前置返回 —— 不做按相关度裁剪、不向 doc 记忆归档。
3. doc 记忆 / 整理流水线：早已由 `a.memory == nil` 关闭（N2c）。

## "不裁"的准确含义

不做**策略性**裁剪（不按相关度挑、不归档），只受"模型能收多少"这个硬上限约束；
且在撞到硬上限之前，contextfull（90% 窗口）已按 L4 上报父 agent ⇒
**丢事件的决定权在父**（压缩/回收/销毁），不在内核。文档 §16.0.0 记录三处闸门表。

## 顺带修掉的既有 bug（单位混用）

`formatMergedTimeline` 逐事件估算原来是 `len(e.Source)+len(e.Input)+40` 再 ×2 ——
`len()` 是**字节**，而 `EstimateTokens` 是 rune×2 ⇒ 中文事件被高估 3 倍：
实测 2384 字的中文事件被估成 14398 token > 8192，于是窗口还有余量也提前 break、
把更早的事件整段丢掉。改为统一走 `EstimateTokens`（对父同样生效：中文长会话不再被过早裁剪）。

## 测试

- 新增 `TestLightKernel_TraditionalContextNoTrimming`：用**记录模型实收消息**的 provider
  断言"更早的事件仍在"（为什么不看 TaskFrame：`prepareInputTask` 只做前半段，
  消息在 `runTaskSteps`/`stepPrepare` 才拼出来 —— 我第一版断言就打在了空帧上）；
  填充量取"超过动态份额、但仍在窗口内"，从而能区分父/子两种行为。
- 新增 `TestFullKernel_StillUsesDynamicContext` 作对照（父仍用动态份额）。

全量 go test ./... 37 包 ok / 0 FAIL；-race 干净。

2026-09-13 10:36:04 +08:00

JianFeeeee

48cfa8fb6c

feat(lightkernel): N2c —— 轻量内核 profile（窄接口 GraphMemory + nil 即禁用整理面）

按用户指出的关键点（a.memory 多数使用点属"主 agent 整理记忆"与"记忆整理流水线"，
子不该有那些路径）实现，方案见设计 §16.0。

## 窄接口：只有 Recall + Commit

新增 `GraphMemory` 接口（memoryface.go）—— 按调用方实测分类后，真正"根与子都要"的只有这两个：
- `Recall`：上下文检索 / memory_recall
- `Commit`：自动写入路径的图部分 / memory_commit

新增 `Agent.graph`（共同面）与 `Agent.graphMem()` 访问器：
- `graph` 显式为 nil 时**回落**到 `memory` ⇒ 既有"只用 Agent 字面量设 memory"的测试无需改动
  （原本会出现"必须同时设两个字段"的脚坑，实测踩到后去掉了）
- 轻量内核：`graph = *memory.LightMemory`，`memory = nil`

## nil 即禁用：整理面自动消失，不需要受限包装

子的 `a.memory == nil` ⇒ 既有的 22 处 `if a.memory != nil` 关卡自动禁掉全部整理面：
- 记忆整理流水线（distill.go 的 archive/review/merge 循环）
- 记忆块 + 媒体桥（graphmedia.go / medialoop.go）
- 记忆整理工具（memory_merge / memory_delete_entity / memory_block_merge /
  memory_purge / memory_edit / memory_introspect）—— 它们本就在 `if a.memory != nil` 块内

唯一拆开的一处是自动写入 `commitTriplesWithMedia`：
图部分走 `graphMem().Commit`（父落 main、子落 temp），块/媒体部分仍由 `a.memory != nil` 守卫。
`executeMemoryTool` 的读路径改走 `graphMem().Recall`；整理类 case 加 `requireFull()` 闸门，
被直调时明确报"本 agent 是轻量内核：记忆整理不可用"，不静默降级。

## 验收（3 项新测试）

- `TestLightProfile_MemoryFaceWiring`：整理面为 nil、写入只落 temp（主库无子痕迹）、
  读是并集（主库实体 + temp 实体都看得到）
- `TestLightProfile_OrganizeToolsAbsentAndRefused`：整理类工具**不进工具表**；
  即便被直调也明确报"轻量内核不支持"
- `TestFullProfile_KeepsOrganizeFace`：对照，根 agent 仍保留整理面与整理工具

全仓 go test ./... 37 包 ok / 0 FAIL；-race（agent/memory）干净；gofmt 干净。

2026-09-13 10:02:02 +08:00

2 Commits