Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Identity Graph Operator"
|
||||
type: source
|
||||
tags: ["multi-agent", "identity-resolution", "entity-resolution", "the-agency"]
|
||||
date: 2026-04-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/identity-graph-operator]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多智能体系统中的共享身份图谱运营——确保所有 Agent 对同一真实世界实体（人/公司/产品）得到一致的规范化实体 ID，解决多 Agent 系统的核心问题：重复记录、冲突操作、级联错误。
|
||||
- 问题域：多 Agent 系统中的身份孤岛问题——当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。
|
||||
- 方法/机制：通过身份解析引擎（Identity Engine）进行规范化（Normalization）→ 阻塞（Blocking）→ 评分（Scoring）→ 聚类（Clustering），返回相同 entity_id；支持昵称扩展（Bill→William）、E.164 电话标准化、邮箱小写化；merge/split 操作通过乐观锁执行，保留完整事件历史；直接变更 vs 提案决策按置信度分级处理。
|
||||
- 结论/价值：零身份冲突生产环境、合并准确率 > 99%、P99 解析延迟 < 100ms、全链路审计追踪。与 [[Multi-Agent-System-Reliability]] 的 Agent 协作模式互补——后者解决 Agent 间决策一致性问题，前者解决 Agent 对同一实体的识别一致性问题。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **相同输入，相同输出**：两个 Agent 解析同一条记录必须得到相同 entity_id，这是绝对原则，不可妥协。
|
||||
- **证据优先于断言**：合并必须有字段级证据支撑（email exact match + name fuzzy match + phone match），仅凭"看起来相似"不足以触发合并。
|
||||
- **提案优于直接变更**：与其他 Agent 协作时，优先提出带证据的合并提案，而非直接执行，让对方 Agent 审查证据。
|
||||
- **外部 ID 排序**：使用 external_id 排序而非 UUID（UUID 无序），确保排序稳定性。
|
||||
- **从不跳过引擎**：不硬编码字段名、权重或阈值，由匹配引擎统一计算候选评分。
|
||||
|
||||
## Key Quotes
|
||||
> "Same input, same output. Two agents resolving the same record must get the same entity_id. Always." — Determinism 原则核心表述
|
||||
> "Never merge without evidence. 'These look similar' is not evidence. Per-field comparison scores with confidence thresholds are evidence." — Evidence Over Assertion 原则
|
||||
> "When agents disagree — one proposes merge, another proposes split on the same entities — both proposals are flagged as 'conflict.' Add comments to discuss before resolving. Never resolve a conflict by overriding another agent's evidence." — 冲突处理机制
|
||||
|
||||
## Key Concepts
|
||||
- [[Identity Resolution（身份解析）]]：将多条记录归一化为同一 canonical entity_id 的过程——通过 blocking/scoring/clustering 实现，与传统主数据管理（MDM）同源但在多 Agent 场景下增加了并发写入和分布式协调维度。
|
||||
- [[Blocking（阻塞/分块）]]：通过 blocking key（email domain、phone prefix、name soundex）快速筛选候选匹配对，避免全图扫描 O(n²) 开销，是大规模实体解析的性能关键。
|
||||
- [[Fuzzy Matching（模糊匹配）]]：处理"Bill Smith"和"William Smith"视为同一人的能力——通过昵称扩展（nickname normalization）和字段级相似度评分实现，是身份解析的核心挑战。
|
||||
- [[Confidence Score（置信度评分）]]：字段级证据分数加权求和得出的合并置信度——决定直接合并（>0.95）、提案审查（0.6-0.95）还是创建新实体（<0.6），是自动决策与人机协作的分界点。
|
||||
- [[Optimistic Locking（乐观锁）]]：通过版本号（version field）防止并发写入冲突——变更需携带 expected_version，版本不匹配时拒绝执行，是图谱完整性的并发保护机制。
|
||||
- [[Evidence-based Merge Proposal（证据驱动合并提案）]]：合并前必须构造 per-field evidence（email_match/score/values、name_match/score/values），让其他 Agent 基于证据而非断言进行审查，是多 Agent 身份协调的核心协议。
|
||||
- [[Multi-Agent Identity Coordination（多 Agent 身份协调）]]：跨 Agent 的 merge/split 冲突检测、跨编排框架（LangChain/CrewAI/AutoGen）的身份联邦，以及 shared agent memory（跨 Agent 知识共享）——是 Identity Graph Operator 与 [[Multi-Agent-System-Reliability]] 的本质区别。
|
||||
|
||||
## Key Entities
|
||||
- [[Identity Graph Operator]]：身份图谱运营者 Agent——本文档描述的核心 Agent，拥有共享身份层的所有权，负责多 Agent 系统的实体解析、合并提案和冲突协调。
|
||||
- [[Backend Architect]]：后端架构师 Agent——与 Identity Graph Operator 协作，前者设计数据表结构，后者确保跨来源的实体不重复。
|
||||
- [[Agents Orchestrator]]：Agent 编排器——Identity Graph Operator 在其中注册自己的身份解析能力，供编排器分配 identity resolution 任务。
|
||||
- [[Reality Checker]]：现实核查 Agent——接收 Identity Graph Operator 的 merge 证据进行质量门检验。
|
||||
- [[Support Responder]]：支持响应 Agent——通过 Identity Graph Operator 解析客户身份后响应，"这是昨天来电的同一位客户吗？"
|
||||
- [[Agentic Identity & Trust Architect]]：Agent 身份与信任架构师——与 Identity Graph Operator 互补，前者处理实体身份（who is this person/company?），后者处理 Agent 身份（who is this agent and what can it do?）。
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent-System-Reliability]] ← depends_on ← [[Identity-Graph-Operator]]：身份图谱是 [[Multi-Agent-System-Reliability]] 中多 Agent 协作模式的基础设施层——[[Hierarchy-Agent-Pattern]] 中的主管 Agent 需要 Identity Graph Operator 来消除下游 Agent 的重复实体问题。
|
||||
- [[Identity-Graph-Operator]] ← extends ← [[Personal CRM]]：[[Personal CRM]] 中的联系人去重是 Identity Graph Operator 在个人场景的简化实现，企业级多 Agent 场景增加了并发写入、跨框架联邦和图谱完整性等维度。
|
||||
- [[Identity-Graph-Operator]] ← depends_on ← [[Identity-Resolution]]：身份解析技术是 Identity Graph Operator 的核心能力底座，两者同义——Operator 是身份解析能力在多 Agent 系统中的 Agent 化封装。
|
||||
- [[Identity-Graph-Operator]] ← extends ← [[Entity-Merge-Algorithm]]：Entity Merge Algorithm 是合并决策的计算内核，Operator 在其上增加了提案协议、冲突检测和审计追踪等协作维度。
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Designing-for-Agentic-AI]] 可能的冲突：
|
||||
- 冲突点：身份图谱的确定性要求（"Same input, same output"）与 [[Designing-for-Agentic-AI]] 强调的 LLM 概率性行为如何协调？
|
||||
- 当前观点：[[Identity-Graph-Operator]] 通过将身份解析核心逻辑从 LLM 推理中分离出来（blocking/scoring/clustering 由确定性算法执行），仅在 merge proposal 生成阶段使用 LLM 提供自然语言解释，从而在保留 LLM 灵活性的同时保障确定性。
|
||||
- 对方观点：[[Designing-for-Agentic-AI]] 可能认为过度确定性约束会削弱 Agent 的自主性和上下文适应能力。
|
||||
---
|
||||
title: "Identity Graph Operator"
|
||||
type: source
|
||||
tags: ["multi-agent", "identity-resolution", "entity-resolution", "the-agency"]
|
||||
date: 2026-04-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/identity-graph-operator]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多智能体系统中的共享身份图谱运营——确保所有 Agent 对同一真实世界实体（人/公司/产品）得到一致的规范化实体 ID，解决多 Agent 系统的核心问题：重复记录、冲突操作、级联错误。
|
||||
- 问题域：多 Agent 系统中的身份孤岛问题——当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。
|
||||
- 方法/机制：通过身份解析引擎（Identity Engine）进行规范化（Normalization）→ 阻塞（Blocking）→ 评分（Scoring）→ 聚类（Clustering），返回相同 entity_id；支持昵称扩展（Bill→William）、E.164 电话标准化、邮箱小写化；merge/split 操作通过乐观锁执行，保留完整事件历史；直接变更 vs 提案决策按置信度分级处理。
|
||||
- 结论/价值：零身份冲突生产环境、合并准确率 > 99%、P99 解析延迟 < 100ms、全链路审计追踪。与 [[Multi-Agent-System-Reliability]] 的 Agent 协作模式互补——后者解决 Agent 间决策一致性问题，前者解决 Agent 对同一实体的识别一致性问题。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **相同输入，相同输出**：两个 Agent 解析同一条记录必须得到相同 entity_id，这是绝对原则，不可妥协。
|
||||
- **证据优先于断言**：合并必须有字段级证据支撑（email exact match + name fuzzy match + phone match），仅凭"看起来相似"不足以触发合并。
|
||||
- **提案优于直接变更**：与其他 Agent 协作时，优先提出带证据的合并提案，而非直接执行，让对方 Agent 审查证据。
|
||||
- **外部 ID 排序**：使用 external_id 排序而非 UUID（UUID 无序），确保排序稳定性。
|
||||
- **从不跳过引擎**：不硬编码字段名、权重或阈值，由匹配引擎统一计算候选评分。
|
||||
|
||||
## Key Quotes
|
||||
> "Same input, same output. Two agents resolving the same record must get the same entity_id. Always." — Determinism 原则核心表述
|
||||
> "Never merge without evidence. 'These look similar' is not evidence. Per-field comparison scores with confidence thresholds are evidence." — Evidence Over Assertion 原则
|
||||
> "When agents disagree — one proposes merge, another proposes split on the same entities — both proposals are flagged as 'conflict.' Add comments to discuss before resolving. Never resolve a conflict by overriding another agent's evidence." — 冲突处理机制
|
||||
|
||||
## Key Concepts
|
||||
- [[Identity Resolution（身份解析）]]：将多条记录归一化为同一 canonical entity_id 的过程——通过 blocking/scoring/clustering 实现，与传统主数据管理（MDM）同源但在多 Agent 场景下增加了并发写入和分布式协调维度。
|
||||
- [[Blocking（阻塞/分块）]]：通过 blocking key（email domain、phone prefix、name soundex）快速筛选候选匹配对，避免全图扫描 O(n²) 开销，是大规模实体解析的性能关键。
|
||||
- [[Fuzzy Matching（模糊匹配）]]：处理"Bill Smith"和"William Smith"视为同一人的能力——通过昵称扩展（nickname normalization）和字段级相似度评分实现，是身份解析的核心挑战。
|
||||
- [[Confidence Score（置信度评分）]]：字段级证据分数加权求和得出的合并置信度——决定直接合并（>0.95）、提案审查（0.6-0.95）还是创建新实体（<0.6），是自动决策与人机协作的分界点。
|
||||
- [[Optimistic Locking（乐观锁）]]：通过版本号（version field）防止并发写入冲突——变更需携带 expected_version，版本不匹配时拒绝执行，是图谱完整性的并发保护机制。
|
||||
- [[Evidence-based Merge Proposal（证据驱动合并提案）]]：合并前必须构造 per-field evidence（email_match/score/values、name_match/score/values），让其他 Agent 基于证据而非断言进行审查，是多 Agent 身份协调的核心协议。
|
||||
- [[Multi-Agent Identity Coordination（多 Agent 身份协调）]]：跨 Agent 的 merge/split 冲突检测、跨编排框架（LangChain/CrewAI/AutoGen）的身份联邦，以及 shared agent memory（跨 Agent 知识共享）——是 Identity Graph Operator 与 [[Multi-Agent-System-Reliability]] 的本质区别。
|
||||
|
||||
## Key Entities
|
||||
- [[Identity Graph Operator]]：身份图谱运营者 Agent——本文档描述的核心 Agent，拥有共享身份层的所有权，负责多 Agent 系统的实体解析、合并提案和冲突协调。
|
||||
- [[Backend Architect]]：后端架构师 Agent——与 Identity Graph Operator 协作，前者设计数据表结构，后者确保跨来源的实体不重复。
|
||||
- [[Agents Orchestrator]]：Agent 编排器——Identity Graph Operator 在其中注册自己的身份解析能力，供编排器分配 identity resolution 任务。
|
||||
- [[Reality Checker]]：现实核查 Agent——接收 Identity Graph Operator 的 merge 证据进行质量门检验。
|
||||
- [[Support Responder]]：支持响应 Agent——通过 Identity Graph Operator 解析客户身份后响应，"这是昨天来电的同一位客户吗？"
|
||||
- [[Agentic Identity & Trust Architect]]：Agent 身份与信任架构师——与 Identity Graph Operator 互补，前者处理实体身份（who is this person/company?），后者处理 Agent 身份（who is this agent and what can it do?）。
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent-System-Reliability]] ← depends_on ← [[Identity-Graph-Operator]]：身份图谱是 [[Multi-Agent-System-Reliability]] 中多 Agent 协作模式的基础设施层——[[Hierarchy-Agent-Pattern]] 中的主管 Agent 需要 Identity Graph Operator 来消除下游 Agent 的重复实体问题。
|
||||
- [[Identity-Graph-Operator]] ← extends ← [[Personal CRM]]：[[Personal CRM]] 中的联系人去重是 Identity Graph Operator 在个人场景的简化实现，企业级多 Agent 场景增加了并发写入、跨框架联邦和图谱完整性等维度。
|
||||
- [[Identity-Graph-Operator]] ← depends_on ← [[Identity-Resolution]]：身份解析技术是 Identity Graph Operator 的核心能力底座，两者同义——Operator 是身份解析能力在多 Agent 系统中的 Agent 化封装。
|
||||
- [[Identity-Graph-Operator]] ← extends ← [[Entity-Merge-Algorithm]]：Entity Merge Algorithm 是合并决策的计算内核，Operator 在其上增加了提案协议、冲突检测和审计追踪等协作维度。
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Designing-for-Agentic-AI]] 可能的冲突：
|
||||
- 冲突点：身份图谱的确定性要求（"Same input, same output"）与 [[Designing-for-Agentic-AI]] 强调的 LLM 概率性行为如何协调？
|
||||
- 当前观点：[[Identity-Graph-Operator]] 通过将身份解析核心逻辑从 LLM 推理中分离出来（blocking/scoring/clustering 由确定性算法执行），仅在 merge proposal 生成阶段使用 LLM 提供自然语言解释，从而在保留 LLM 灵活性的同时保障确定性。
|
||||
- 对方观点：[[Designing-for-Agentic-AI]] 可能认为过度确定性约束会削弱 Agent 的自主性和上下文适应能力。
|
||||
|
||||
Reference in New Issue
Block a user