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

评估：PullConsent/Profile补persona_id维度（多人设场景，全ADR对抗审查组E） #184

New issue
Closed
opened 2026-08-21 03:24:21 +00:00 by KumaAgent · 1 comment
KumaAgent commented 2026-08-21 03:24:21 +00:00
Member
Copy link

来源

全量32条ADR设计合理性对抗审查（评估侧内部执行，2026-08-21），组E·ADR-0027。经独立agent对抗式反驳后确认成立，但用户已拍板"多人设现阶段不做"，本票仅做评估/留痕，不预期近期排期。

问题

跨平台资料拉取的同意机制（PullConsent）与其写入目标（Profile）都只按 user_id 归属，完全没有 persona_id 维度，而 ADR-0027 自称是隐私分量最重的一条决策，核心正当性建立在"被检查内容的那个人自己同意"上。一旦部署方运营多个人设（ADR-0008 已明确设计为未来场景），用户对人设A说"允许了解我的社交资料"，这份同意会被错误地当成对人设B也同意——因为同意记录压根不区分是对哪个人设做出的。

需要评估的问题

  • 当前项目零host接入、更别说多人设部署（见 project_arise_zero_host_integration.md），这个缺口现阶段是否值得投入设计？
  • 若未来要支持，同意机制/Profile写入目标应如何引入 persona_id 维度？是否需要"每个人设各自独立的同意记录"，还是"同意是对用户本人的，与人设无关，但资料内容的可见范围按人设区分"这类更精细的模型？
  • 是否需要在 ADR-0027 里先补一条留痕说明这个缺口，即便暂不实现？

备注

不建议现在排期实现——留给评估票是为了不丢失这条发现，等真实多人设部署需求出现时有据可查。

## 来源 全量32条ADR设计合理性对抗审查（评估侧内部执行，2026-08-21），组E·ADR-0027。经独立agent对抗式反驳后确认成立，但用户已拍板"多人设现阶段不做"，本票仅做评估/留痕，不预期近期排期。 ## 问题 跨平台资料拉取的同意机制（PullConsent）与其写入目标（Profile）都只按 `user_id` 归属，完全没有 `persona_id` 维度，而 ADR-0027 自称是隐私分量最重的一条决策，核心正当性建立在"被检查内容的那个人自己同意"上。一旦部署方运营多个人设（ADR-0008 已明确设计为未来场景），用户对人设A说"允许了解我的社交资料"，这份同意会被错误地当成对人设B也同意——因为同意记录压根不区分是对哪个人设做出的。 ## 需要评估的问题 - 当前项目零host接入、更别说多人设部署（见 `project_arise_zero_host_integration.md`），这个缺口现阶段是否值得投入设计？ - 若未来要支持，同意机制/Profile写入目标应如何引入 persona_id 维度？是否需要"每个人设各自独立的同意记录"，还是"同意是对用户本人的，与人设无关，但资料内容的可见范围按人设区分"这类更精细的模型？ - 是否需要在 ADR-0027 里先补一条留痕说明这个缺口，即便暂不实现？ ## 备注 不建议现在排期实现——留给评估票是为了不丢失这条发现，等真实多人设部署需求出现时有据可查。
KumaAgent changed title from 占位标题-稍后回填-06 to 评估：PullConsent/Profile补persona_id维度（多人设场景，全ADR对抗审查组E） 2026-08-21 03:28:21 +00:00
KumaAgent commented 2026-08-21 03:56:31 +00:00
Author
Member
Copy link

对本票 grill 后发现问题框架需要修正，关闭并入 #185：

三点关键核实（详见对话记录）：

  1. ArisePorts 确实是进程级单例，get_persona(chat_id) 每次触发都重新调用（无缓存）——这是 ADR-0001 明文允许的 host 自由度，不是理论上的可能性。
  2. 「一人设一进程」这种多进程部署模式下，本票担心的场景完全不存在——Persona 是静态文本，天然可以在多个独立进程间复用，PullConsent/画像等状态各自独立。
  3. 真正暴露问题的是「一进程多人设」这个 get_persona(chat_id) 协议明确允许的用法：文本人格可以按 chat 变化，但 storage/PullConsent/关系网等状态层完全没有对应的 persona 分区——跟 #185（llm_client 同类缺口）是同一个根因（get_persona(chat_id) 承诺的能力，状态层没有支撑）。

原「persona_id 维度缺失」这个措辞本身不准确（系统里不存在可补充的 persona_id 字段），已把更精确的问题框架并入 #185，两个 port 的同类缺口放在一张票里评估。

对本票 grill 后发现问题框架需要修正，关闭并入 #185： 三点关键核实（详见对话记录）： 1. ArisePorts 确实是进程级单例，get_persona(chat_id) 每次触发都重新调用（无缓存）——这是 ADR-0001 明文允许的 host 自由度，不是理论上的可能性。 2. 「一人设一进程」这种多进程部署模式下，本票担心的场景完全不存在——Persona 是静态文本，天然可以在多个独立进程间复用，PullConsent/画像等状态各自独立。 3. 真正暴露问题的是「一进程多人设」这个 get_persona(chat_id) 协议明确允许的用法：文本人格可以按 chat 变化，但 storage/PullConsent/关系网等状态层完全没有对应的 persona 分区——跟 #185（llm_client 同类缺口）是同一个根因（get_persona(chat_id) 承诺的能力，状态层没有支撑）。 原「persona_id 维度缺失」这个措辞本身不准确（系统里不存在可补充的 persona_id 字段），已把更精确的问题框架并入 #185，两个 port 的同类缺口放在一张票里评估。
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#184
No description provided.