ProjectKuma/arise
2
0
Fork 0
Code Issues 18 Pull requests 1 Projects Releases Packages Wiki Activity

ADR-0008注入分档恢复+新建lookup_relation工具 #114

New issue
Closed
opened 2026-08-11 03:35:53 +00:00 by KumaAgent · 0 comments
KumaAgent commented 2026-08-11 03:35:53 +00:00
Member
Copy link

Parent

#103 第四批清单：31 条实现类落差 + 9 条待拍板（条目 14；含两条已在评估侧单独拍板的结论，原样落地）

What to build

ADR-0008「保留 dxkuma ADR-0009 全部结构」承诺的"注入分档"（显式边 + 同事件共现自动注入；同群共现按需查询）在 2026-07-13 的一次"修复漏实现"更新中被无意推翻——同群共现也变成了每轮自动（gather_implicit_relations），且这条路径实测是 n 次 + n(n-1)/2 次 DB 往返、跑在前台热路径上。"按需"这一档目前没有机制：lookup_relation 只是个纯函数，没有对应的模型工具。同时"独立封顶"这半在关系注入侧完全没有实现——gather_relationship_edges 无 LIMIT/ORDER BY 拉全历史边，渲染三段全是无条件列表推导。

评估侧已单独拍板：恢复分档 + 新建 lookup_relation 工具。本票按此落地，两半（分档恢复 / 独立封顶）作为两条并列的 AC，不要合并处理——ADR-0009 对画像明文否决硬上限，ADR-0008/0015 对关系/触发注入则明文允许上限，两条规则相反。

Acceptance criteria

一、恢复注入分档

  • 摘掉 runtime_loop.py 两处 gather_implicit_relations(...) 自动调用：_full_frozen_snapshot（被 run() 与 run_callback() 两个入口共用，摘除影响两者）与 _run_event_driven_turn（此处实测已是空转——sender_ids 最多 1 个 id，gather_implicit_relations 开头 len(unique_ids) < 2 即返回，摘掉零行为变化）
  • 摘除后 gather_implicit_relations 若在生产侧无引用，明确处置（删除，或改造为下述新工具的批量路径）
  • 新建 core 原生工具 lookup_relation（不经工具港，同 search_stickers 先例；计入 run_limit，不豁免；不新开成本池，记进调用它的路径已有的池）：tools.py 加常量 + schema + 在 build_tool_schemas 追加，runtime_loop 加 _handle_lookup_relation handler 并接入既有工具分发分支（_handle_search_memory/_handle_search_stickers 那一段），内部复用既有 lookup_relation 纯函数
  • 显式边 + 同事件共现保持自动，gather_relationship_edges 及其渲染路径一行不改
  • ADR-0008 追加更新节，记录 2026-07-13 那次是无意推翻、本次恢复分档
  • tests/test_runtime_loop.py::test_co_occurring_senders_without_an_edge_get_an_implicit_relation_line 改造成针对新工具的测试，不能静默删除；同文件 test_an_explicit_edge_suppresses_the_duplicate_implicit_line 在自动档消失后重新定位

原文（docs/adr/0008-relationship-network.md「背景」节）：

dxkuma ADR-0009 定关系网为两层……注入分档（显式边+同事件自动、同群 lookup_relation 按需）、warmth 加权排序。

原文（docs/adr/0031-on-demand-memory-search.md「拒绝了」节第 2 条——每轮自动正是本次要摘掉的形状）：

每轮自动触发的深度搜索……违红线1前台廉价原则，且没有证据证明冻结快照+触发注入两层不够用到需要每轮兜底——模型主动调用已经是最小必要的介入方式。

二、独立封顶（与上面分档恢复是两件独立的事，不要合写成一条）

  • 新增静态 config 项（如 arise_max_relationship_lines_per_turn），穿 _build_runtime_loop → render_relationship_snapshot，对显式边渲染的行数设上限
  • gather_relationship_edges/render_relationship_snapshot 拉取与渲染逻辑接上这个上限（当前 storage.get_relationship_edges(sender_id) 无 LIMIT/ORDER BY 拉全历史边，axes/edge_lines/implicit_lines 三段渲染全是无条件列表推导）

原文（docs/adr/0008-relationship-network.md「决策」节第 1 条）：

保留 dxkuma ADR-0009 全部结构：两层关系网、不上图（1-hop 主力 + 递归 CTE ≤2 或 lookup_relation）、知情-gate（敏感数据私聊例外 ⇔ current 是某知情者私聊）、注入分档 + 独立封顶。

三、边界（明确不要做的事）

  • 不要把本片与"画像注入无界"那条合并成一个"注入体积治理"票——ADR-0009 对画像的补法是自然遗忘曲线（明文否决硬上限），与本条的独立封顶方向相反，合片容易串用
  • 新工具的入参形状（模型怎么指认要查询的两个用户）需在片内设计并写进 schema，不留待实现期自由发挥

Blocked by

None — can start immediately

## Parent #103 第四批清单：31 条实现类落差 + 9 条待拍板（条目 14；含两条已在评估侧单独拍板的结论，原样落地） ## What to build ADR-0008「保留 dxkuma ADR-0009 全部结构」承诺的"注入分档"（显式边 + 同事件共现自动注入；同群共现按需查询）在 2026-07-13 的一次"修复漏实现"更新中被无意推翻——同群共现也变成了每轮自动（`gather_implicit_relations`），且这条路径实测是 n 次 + n(n-1)/2 次 DB 往返、跑在前台热路径上。"按需"这一档目前没有机制：`lookup_relation` 只是个纯函数，没有对应的模型工具。同时"独立封顶"这半在关系注入侧完全没有实现——`gather_relationship_edges` 无 LIMIT/ORDER BY 拉全历史边，渲染三段全是无条件列表推导。 **评估侧已单独拍板**：恢复分档 + 新建 `lookup_relation` 工具。本票按此落地，两半（分档恢复 / 独立封顶）作为两条并列的 AC，不要合并处理——ADR-0009 对**画像**明文否决硬上限，ADR-0008/0015 对**关系/触发注入**则明文允许上限，两条规则相反。 ## Acceptance criteria **一、恢复注入分档** - [ ] 摘掉 `runtime_loop.py` 两处 `gather_implicit_relations(...)` 自动调用：`_full_frozen_snapshot`（被 `run()` 与 `run_callback()` 两个入口共用，摘除影响两者）与 `_run_event_driven_turn`（此处实测已是空转——`sender_ids` 最多 1 个 id，`gather_implicit_relations` 开头 `len(unique_ids) < 2` 即返回，摘掉零行为变化） - [ ] 摘除后 `gather_implicit_relations` 若在生产侧无引用，明确处置（删除，或改造为下述新工具的批量路径） - [ ] 新建 core 原生工具 `lookup_relation`（不经工具港，同 `search_stickers` 先例；计入 `run_limit`，不豁免；不新开成本池，记进调用它的路径已有的池）：`tools.py` 加常量 + schema + 在 `build_tool_schemas` 追加，`runtime_loop` 加 `_handle_lookup_relation` handler 并接入既有工具分发分支（`_handle_search_memory`/`_handle_search_stickers` 那一段），内部复用既有 `lookup_relation` 纯函数 - [ ] 显式边 + 同事件共现保持自动，`gather_relationship_edges` 及其渲染路径一行不改 - [ ] ADR-0008 追加更新节，记录 2026-07-13 那次是无意推翻、本次恢复分档 - [ ] `tests/test_runtime_loop.py::test_co_occurring_senders_without_an_edge_get_an_implicit_relation_line` 改造成针对新工具的测试，不能静默删除；同文件 `test_an_explicit_edge_suppresses_the_duplicate_implicit_line` 在自动档消失后重新定位 原文（docs/adr/0008-relationship-network.md「背景」节）： > dxkuma ADR-0009 定关系网为两层……注入分档（显式边+同事件自动、同群 `lookup_relation` 按需）、warmth 加权排序。 原文（docs/adr/0031-on-demand-memory-search.md「拒绝了」节第 2 条——每轮自动正是本次要摘掉的形状）： > **每轮自动触发的深度搜索**……违红线1前台廉价原则，且没有证据证明冻结快照+触发注入两层不够用到需要每轮兜底——模型主动调用已经是最小必要的介入方式。 **二、独立封顶（与上面分档恢复是两件独立的事，不要合写成一条）** - [ ] 新增静态 config 项（如 `arise_max_relationship_lines_per_turn`），穿 `_build_runtime_loop` → `render_relationship_snapshot`，对显式边渲染的行数设上限 - [ ] `gather_relationship_edges`/`render_relationship_snapshot` 拉取与渲染逻辑接上这个上限（当前 `storage.get_relationship_edges(sender_id)` 无 LIMIT/ORDER BY 拉全历史边，axes/edge_lines/implicit_lines 三段渲染全是无条件列表推导） 原文（docs/adr/0008-relationship-network.md「决策」节第 1 条）： > **保留 dxkuma ADR-0009 全部结构**：两层关系网、不上图（1-hop 主力 + 递归 CTE ≤2 或 `lookup_relation`）、知情-gate（敏感数据私聊例外 ⇔ current 是某知情者私聊）、**注入分档 + 独立封顶**。 **三、边界（明确不要做的事）** - [ ] 不要把本片与"画像注入无界"那条合并成一个"注入体积治理"票——ADR-0009 对画像的补法是自然遗忘曲线（明文否决硬上限），与本条的独立封顶方向相反，合片容易串用 - [ ] 新工具的入参形状（模型怎么指认要查询的两个用户）需在片内设计并写进 schema，不留待实现期自由发挥 ## Blocked by None — can start immediately
Yushu closed this issue 2026-08-12 03:23:38 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/189-delegate-task-cancellation-shield
No results found.
Labels
Clear labels   
状态：人类就绪
Requires human implementation

  
状态：待拆片
Issue is too large or underspecified — needs to be broken down into smaller child tickets before work can start

  
状态：待评估
Maintainer needs to evaluate this issue

  
状态：忽视
Will not be actioned

  
状态：智能体就绪
Fully specified, ready for an AFK agent

  
状态：等待信息
Waiting on reporter for more information

No labels
状态：人类就绪
状态：待拆片
状态：待评估
状态：忽视
状态：智能体就绪
状态：等待信息
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ProjectKuma/arise#114
No description provided.