mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-09-23 10:28:06 +00:00
背景(实测):带条件的记忆召不回来。生产库里明明有 「QQ回复禁用Markdown格式 --规定--> 纯文本不用Markdown」「老大 --偏好--> 同左」, 但输入「QQ回复格式」时命中 148 个实体、规则排第 32,注入只取前 5——规则根本没进去; 输入「在吗」这种零内容词的短消息,向量路反而灌进 17 个毫不相关的实体。 根因:词法/向量召回都建立在「字面或语义相似」上,而条件式记忆(在什么场合该怎么做) 约束的是**场面**不是话题。用户措辞不重合时它天然召不回;措辞太宽("QQ")时又被同形 命中淹没。另一处:自动注入只给实体名索引,而规则本体长在关系上(relation_type + object), 即使命中名字也拿不到「纯文本不用Markdown」这句正文。 改动:把「触发条件」升成一等索引维度。 - schema:新增 scenes(key) + scene_refs(scene_id, kind, ref_id, weight), kind ∈ relation|entity。刻意不建外键:节点可能先于引用被清理, 悬空引用由读取侧 JOIN 过滤,级联删除会把清理变成跨表事务。 - 场景键是分层字符串(`/` 分隔,由宽到窄):chan:qq、chan:qq/peer:group_123、 tool:qq_get_message。NormalizeSceneKey 归一(小写、空白/标点→_、按 `/` 分层), 空白不算层级——否则「老大2026-09-04 12:27 QQ私聊图片」这种来源名会被拆成伪层级。 - 写入即挂场景:Triple 新增 Scene 字段,commit() 在同一事务里把「关系 + 两端实体」 挂到场景上(同事务是必须的:关系进库但引用丢了 = 这条记忆永远无声地召不回来)。 - 召回:RecallByScene 前缀匹配(chan:qq 取回 chan:qq 及所有更窄场景;用 `/` 兜底 防止 chan:qq 吞掉 chan:qq2),按 weight(=写入置信度)降序,返回**关系全文 + 原句**。 - 注入:BuildContextInScene 在词法/向量之外叠加场景路,FormatContext 把场景块排在 最前(规则对行为的约束强于话题相关的实体名),上限 8 条 + 原句截断 60 字; 场景实体不在【记忆索引】里重复占位。BuildContext(input) 保持原语义(无场景)。 - 当前场景推导:payload.scene 显式声明 > 通道(chan:qq)> 工具(tool:qq_get_message), 并列命中不取交集。qq 通道本身 RecallPolicy=none(到达的是中断元文本), 真正召回在 qq_get_message 工具上——现在那一步同时带上 chan:qq 与 tool:qq_get_message。 - 写入侧:memory_commit 新增 scene 参数(逐条 triples[].scene 优先,顶层 scene 作批次默认); docToTriples 按文档来源自动带 chan:<source>(QQ 归档的知识天然属于 QQ 场面)。 不做自动猜测:猜错的场景会把无关记忆钉死,之后每次进入该场面都被注入。 - 存量引导:memgc -tag-scene <键> -entity-glob <GLOB>。用 GLOB 而非 LIKE—— LIKE 对 ASCII 不区分大小写,`%QQ%` 会把对象带 /home/newqqagent 的路径类记忆 (生产数据目录、email-mcp、dify-ops 路径…实测 7 条)一起卷进 QQ 场景。 - 清理对齐:PurgeNoise/PurgeOrphans 之后顺带删悬空场景引用,并提供 PurgeStaleSceneRefs;memgc -scene-stats 看场景规模。 验证:go build/vet 干净,go test -count=1 ./... 全绿。 新增用例:场景键归一(含超长/分层/空白)、写入即挂场景(两端实体进、未标的实体不进)、 前缀语义(含 chan:qq2 反例)、weight 排序与 limit、GLOB 存量引导(dry-run 不写库)、 清理后无悬空引用、场景注入面(关系全文+原句+不在索引重复占位)、 agent 侧 sceneKeysFor 优先级(显式声明 > 通道 > 工具、数组形式、nil 安全)。 生产库实测(先 sqlite3 .backup 到 graph.db.bak-20260915-081043 再写): 把 22 条 QQ 相关关系标进 chan:qq(GLOB *QQ* 19 条 + *qq_* 3 条)。同一批输入前后对比: - 「在吗」:改前注入 17 个无关实体;改后场景块直接给出「QQ回复禁用Markdown格式 --规定--> 纯文本不用Markdown」等规则正文(零字面重合也能召回)。 - 「QQ回复格式」:改前规则排第 32 被截掉;改后排在场景块首位。 - 「帮我发个语音」:场景规则置顶,词法路的 qq通道语音输入 等仍在其后。
121 lines
4.4 KiB
Go
121 lines
4.4 KiB
Go
package core
|
||
|
||
import (
|
||
"log"
|
||
|
||
agentIO "gitcode.com/JianFeeeee/HomeAgent/internal/agent/io"
|
||
"gitcode.com/JianFeeeee/HomeAgent/internal/memory"
|
||
)
|
||
|
||
// sceneKeysFor 推导本轮输入的**当前场景**。
|
||
//
|
||
// 场景是“这场面正在发生”的机器可读描述,用于把带条件的记忆(规则/约定)
|
||
// 取回来。优先级:
|
||
// 1. 注入点显式声明(payload.scene)——插件最清楚自己在什么场面里
|
||
// 2. 通道(evt.Source → chan:qq)
|
||
// 3. 工具(tool:qq_get_message)——工具输出触发的召回只知道这一步
|
||
//
|
||
// 多个场景是**并列命中**(取回任一场景的记忆),不是交集:
|
||
// 「在 QQ 上」与「刚取回消息正文」是两个都能独立成立的触发条件。
|
||
func sceneKeysFor(evt *agentIO.InputEvent, toolName string) []string {
|
||
var keys []string
|
||
seen := make(map[string]bool)
|
||
add := func(k string) {
|
||
// 显式声明的场景键来自插件,大小写/空白/标点都不可控;归一化后再去重,
|
||
// 否则「chan:QQ」与「chan:qq」会变成两个场景,各自只召回一半记忆。
|
||
k = memory.NormalizeSceneKey(k)
|
||
if k == "" || seen[k] {
|
||
return
|
||
}
|
||
seen[k] = true
|
||
keys = append(keys, k)
|
||
}
|
||
|
||
if evt != nil && evt.Payload != nil {
|
||
switch v := evt.Payload["scene"].(type) {
|
||
case string:
|
||
add(v)
|
||
case []string:
|
||
for _, s := range v {
|
||
add(s)
|
||
}
|
||
case []interface{}:
|
||
for _, item := range v {
|
||
if s, ok := item.(string); ok {
|
||
add(s)
|
||
}
|
||
}
|
||
}
|
||
}
|
||
|
||
if evt != nil {
|
||
add(memory.ChannelScene(evt.Source))
|
||
}
|
||
if toolName != "" {
|
||
add(memory.ToolScene(toolName))
|
||
}
|
||
return keys
|
||
}
|
||
|
||
// memoryPassOut 是一次记忆操作(取进来 / 踢出去)的结果。
|
||
type memoryPassOut struct {
|
||
// Archived 是被归档进文档记忆的低相关 L0 事件数(prune 的输出)。
|
||
Archived int
|
||
// RecallText 是可注入 prompt 的记忆索引文本(recall 的输出,空串表示无)。
|
||
RecallText string
|
||
}
|
||
|
||
// memoryPass 是「取进来(召回)」与「踢出去(裁剪)」的**唯一入口**。
|
||
//
|
||
// prune 与 recall 是两根正交的声明轴(默认值刻意相反:裁剪是破坏性的、
|
||
// 默认关;召回是只读增量、默认开),但两者都建立在**同一份清洗后的 query**
|
||
// 之上。调用点只负责解析声明,这里统一做三件各写一遍就会写歪的事:
|
||
//
|
||
// 1. 同一 query:prune 与 recall 用同一个查询向量来源,避免「裁错事件、
|
||
// 召回错记忆」——原始内容里的 ANSI/base64/JSON 噪声会把相关性打分带偏。
|
||
// 2. 同一次预算:召回文本按 token 预算截断只做一次(见 recallText)。
|
||
// 3. 同一条审计:谁(trigger)据什么触发了哪种操作都落一条日志,
|
||
// 否则又是一个「幕后发生、查不出是谁」的机制(对齐 prune 的设计初衷)。
|
||
//
|
||
// 边界:prune 与 recall 目前仍走**各自的相关性空间**(prune 用 L0 事件的
|
||
// 稠密/词向量给已有事件打分,recall 用图 + TF-IDF 实体索引)。真正的
|
||
// 「一次打分」要先统一打分空间(后续步骤);这里统一的是**入口、query、
|
||
// 预算与审计**——这已是「一个过程」的可审计外壳,剩下的差在打分空间。
|
||
func (a *Agent) memoryPass(query, trigger string, prune, recall bool, scenes []string) memoryPassOut {
|
||
var out memoryPassOut
|
||
if a == nil || (!prune && !recall) {
|
||
return out
|
||
}
|
||
if prune {
|
||
out.Archived = a.pruneByQuery(query)
|
||
}
|
||
if recall && query != "" {
|
||
out.RecallText = a.recallTextFor(query, trigger, scenes)
|
||
}
|
||
if out.Archived > 0 || out.RecallText != "" {
|
||
log.Printf("[agent] memory pass (%s): archived=%d recalled=%d chars",
|
||
trigger, out.Archived, len(out.RecallText))
|
||
}
|
||
return out
|
||
}
|
||
|
||
// pruneByQuery 按相关性把低相关 L0 事件归档进文档记忆,返回归档数。
|
||
//
|
||
// **不做声明判定**——声明已由调用方(pruneOnInput / stepToolAfter)解析,
|
||
// 这里只负责执行。放在 memoryPass 内部是为了让裁剪与召回共享入口。
|
||
func (a *Agent) pruneByQuery(query string) int {
|
||
if a == nil || a.context == nil {
|
||
return 0
|
||
}
|
||
// **动态上下文**是父 agent 专属能力:轻量内核(驻留子)用传统上下文,
|
||
// 不做按相关度的裁剪与向 doc 记忆的归档(子也没有 doc 记忆)。
|
||
if a.isLightKernel() {
|
||
return 0
|
||
}
|
||
topK := a.maxContextSize - 1
|
||
if topK < 1 {
|
||
topK = 1
|
||
}
|
||
return a.context.Prune(query, topK, a.docStore)
|
||
}
|