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

relations 补回指消解——ADR-0016 遗漏的第四个写入目标（issue #144 拍板） #146

New issue
Closed
opened 2026-08-17 05:37:18 +00:00 by KumaAgent · 0 comments
KumaAgent commented 2026-08-17 05:37:18 +00:00
Member
Copy link

Parent

#144（relations 回指消解开放问题，评估侧已拍板，见下方原文引用）

What to build

给 relations 补回指消解（resolved_subject），补齐 ADR-0016 遗漏的第四个写入目标；顺带补上 Delta
压缩 prompt 里 relations 缺失的自然语言指导文本（相邻缺口，同一处顺手改）。

原文（docs/adr/0016-reference-resolution.md「更新（2026-08-17，issue #144）」节）：

两个独立 resolved_subject，不是一个：relations 有 user_a_id/user_b_id 两个主体位，不能
照搬 facts/events 单一 resolved_subject 字段的形状——各配一个：user_a_id 结构化已知（消息里明确
点名）时直接填，只能靠代词/模糊指代推断时该位置留 null、改填 resolved_subject_a；user_b_id/
resolved_subject_b 同理，两侧独立判断、互不影响。这个形状本身已经覆盖"一方明确、另一方需消解"的
情形，不需要为这种子情况单独设计。

任一位置最终未解析……整条候选丢弃——比照画像更新的失败处理，不比照事件记忆的部分填：关系边
结构上需要两个具体端点才构成一条可查询的边，不存在"半条关系边"这种东西……

Acceptance criteria

一、schema 改动（delta.py::_EXTRACT_MEMORIES_TOOL，"relations" 那段 items.properties）

  • user_a_id/user_b_id 的 "type" 从 "string" 改成 ["string", "null"]（同 facts 的 scope_id
    形状），description 更新为"结构化已知（消息里明确点名）时填，只是代词/模糊指代推断的不要填在这里，
    改填 resolved_subject_a（/_b），这里留 null"
  • 新增 resolved_subject_a/resolved_subject_b（各 ["string", "null"]），description 仿 facts/
    events 现有 resolved_subject 字段的措辞（"尝试通过上下文消解代词/模糊指代锁定的具体 sender_id；
    实在锁定不了才填 null，不要瞎猜"）
  • "required" 列表（现为 ["user_a_id", "user_b_id", "label", "sensitive"]）去掉 user_a_id/
    user_b_id，只留 ["label", "sensitive"]"——同 facts 的 scope_id、events 的 resolved_subject
    都不在各自的 required 里这个既有形状一致

二、解析改动（delta.py::_parse_relation + _resolve_subject）

  • _resolve_subject(raw) 泛化成接受字段名参数（如 _resolve_subject(raw, field="resolved_subject")
    默认值不变，facts/events 现有调用点不用改），避免为 resolved_subject_a/_b 各写一份重复校验
    （该函数现有 docstring 已经点名"facts 与 events 共用同一条校验，避免各写一份逐字段相同的判断悄悄
    分叉"——延续同一条原则，不要破例）
  • _parse_relation：user_a_id/user_b_id 允许为 None；分别用"结构化值 or 对应
    resolved_subject_a/b"合并出最终 id；合并后任一侧仍是 None，整条候选返回 None（丢弃）——
    同现有"user_a_id == user_b_id"防御性丢弃走同一条"整条候选丢弃"路径，不要新开一条不同形状的
    返回逻辑
    • user_a_id == user_b_id 的防御性检查在合并后的最终 id上做（不是在原始结构化字段上），
      避免"A 结构化点名张三，B 靠代词消解也解到张三"这种合并后才会暴露的重复没被拦住

三、prompt 指导文本补齐（delta.py::_build_prompt 的 instruction 字符串，相邻缺口顺手补）

  • instruction 里现在只枚举了 facts=/events=/knowledge= 各自的抽取指导，完全没有
    relations= 这一条    （目前 relations 只在工具级 description 与逐字段 schema description 里有
    只言片语）——补一条 relations=谁与谁是什么关系 的指导文本，比照 facts/events 现有措辞给出
    resolved_subject_a/_b 的消解指引（"能通过消息里明确点名确定的，直接填 user_a_id/user_b_id；
    只是通过代词/模糊指代推断出来的……写进对应的 resolved_subject_a/resolved_subject_b，这个位置留
    null，实在锁定不了也填 null，不要瞎猜"）

四、测试

  • _parse_relation 补单元测试：两侧都结构化 / 一侧结构化一侧靠 resolved_subject 消解 / 一侧消解
    不了整条丢弃 / 两侧都消解不了整条丢弃 / 合并后 A==B 防御性丢弃
  • Delta 压缩集成测试补一条端到端用例（同 test_delta_compression_cycle.py 现有 facts/events
    回指消解用例的形状），钉住 relations 候选真的能借代词消解落库，不能只断言解析函数正确
  • 全量测试通过，不改写任何既有断言（本票是新增能力，不是行为变更）

Not in scope

  • 决策快照//why 记录"本轮因回指模糊丢弃了几条 relations 候选"（ADR-0016 原有备注已把这类观测性
    需求留给实现期按需加，本票不强制要求，需要时再开）
  • relations 以外任何字段/机制的改动（tension/affinity 四轴、label 枚举等一律不动）
## Parent #144（relations 回指消解开放问题，评估侧已拍板，见下方原文引用） ## What to build 给 `relations` 补回指消解（`resolved_subject`），补齐 ADR-0016 遗漏的第四个写入目标；顺带补上 Delta 压缩 prompt 里 `relations` 缺失的自然语言指导文本（相邻缺口，同一处顺手改）。 原文（`docs/adr/0016-reference-resolution.md`「更新（2026-08-17，issue #144）」节）： > **两个独立 `resolved_subject`，不是一个**：`relations` 有 `user_a_id`/`user_b_id` 两个主体位，不能 > 照搬 facts/events 单一 `resolved_subject` 字段的形状——各配一个：`user_a_id` 结构化已知（消息里明确 > 点名）时直接填，只能靠代词/模糊指代推断时该位置留 `null`、改填 `resolved_subject_a`；`user_b_id`/ > `resolved_subject_b` 同理，两侧独立判断、互不影响。这个形状本身已经覆盖"一方明确、另一方需消解"的 > 情形，不需要为这种子情况单独设计。 > > **任一位置最终未解析……整条候选丢弃**——比照**画像更新**的失败处理，不比照事件记忆的部分填：关系边 > 结构上需要两个具体端点才构成一条可查询的边，不存在"半条关系边"这种东西…… ## Acceptance criteria **一、schema 改动**（`delta.py::_EXTRACT_MEMORIES_TOOL`，`"relations"` 那段 `items.properties`） - [ ] `user_a_id`/`user_b_id` 的 `"type"` 从 `"string"` 改成 `["string", "null"]`（同 facts 的 `scope_id` 形状），description 更新为"结构化已知（消息里明确点名）时填，只是代词/模糊指代推断的不要填在这里， 改填 `resolved_subject_a`（/`_b`），这里留 `null`" - [ ] 新增 `resolved_subject_a`/`resolved_subject_b`（各 `["string", "null"]`），description 仿 facts/ events 现有 `resolved_subject` 字段的措辞（"尝试通过上下文消解代词/模糊指代锁定的具体 sender_id； 实在锁定不了才填 null，不要瞎猜"） - [ ] `"required"` 列表（现为 `["user_a_id", "user_b_id", "label", "sensitive"]`）去掉 `user_a_id`/ `user_b_id`，只留 `["label", "sensitive"]"`——同 facts 的 `scope_id`、events 的 `resolved_subject` 都不在各自的 `required` 里这个既有形状一致 **二、解析改动**（`delta.py::_parse_relation` + `_resolve_subject`） - [ ] `_resolve_subject(raw)` 泛化成接受字段名参数（如 `_resolve_subject(raw, field="resolved_subject")` 默认值不变，facts/events 现有调用点不用改），避免为 `resolved_subject_a`/`_b` 各写一份重复校验 （该函数现有 docstring 已经点名"facts 与 events 共用同一条校验，避免各写一份逐字段相同的判断悄悄 分叉"——延续同一条原则，不要破例） - [ ] `_parse_relation`：`user_a_id`/`user_b_id` 允许为 `None`；分别用"结构化值 or 对应 resolved_subject_a/b"合并出最终 id；**合并后任一侧仍是 `None`，整条候选返回 `None`（丢弃）**—— 同现有"`user_a_id == user_b_id`"防御性丢弃走同一条"整条候选丢弃"路径，不要新开一条不同形状的 返回逻辑 - [ ] `user_a_id == user_b_id` 的防御性检查在**合并后的最终 id**上做（不是在原始结构化字段上）， 避免"A 结构化点名张三，B 靠代词消解也解到张三"这种合并后才会暴露的重复没被拦住 **三、prompt 指导文本补齐**（`delta.py::_build_prompt` 的 `instruction` 字符串，相邻缺口顺手补） - [ ] `instruction` 里现在只枚举了 `facts=`/`events=`/`knowledge=` 各自的抽取指导，**完全没有 `relations=` 这一条**（目前 relations 只在工具级 `description` 与逐字段 schema description 里有 只言片语）——补一条 `relations=谁与谁是什么关系` 的指导文本，比照 facts/events 现有措辞给出 `resolved_subject_a`/`_b` 的消解指引（"能通过消息里明确点名确定的，直接填 user_a_id/user_b_id； 只是通过代词/模糊指代推断出来的……写进对应的 resolved_subject_a/resolved_subject_b，这个位置留 null，实在锁定不了也填 null，不要瞎猜"） **四、测试** - [ ] `_parse_relation` 补单元测试：两侧都结构化 / 一侧结构化一侧靠 resolved_subject 消解 / 一侧消解 不了整条丢弃 / 两侧都消解不了整条丢弃 / 合并后 A==B 防御性丢弃 - [ ] Delta 压缩集成测试补一条端到端用例（同 `test_delta_compression_cycle.py` 现有 facts/events 回指消解用例的形状），钉住 relations 候选真的能借代词消解落库，不能只断言解析函数正确 - [ ] 全量测试通过，不改写任何既有断言（本票是新增能力，不是行为变更） ## Not in scope - 决策快照/`/why` 记录"本轮因回指模糊丢弃了几条 relations 候选"（ADR-0016 原有备注已把这类观测性 需求留给实现期按需加，本票不强制要求，需要时再开） - `relations` 以外任何字段/机制的改动（`tension`/`affinity` 四轴、`label` 枚举等一律不动）
Yushu closed this issue 2026-08-17 08:41:03 +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#146
No description provided.