7.2 KiB
7.2 KiB
title, type, tags, date
| title | type | tags | date | ||||
|---|---|---|---|---|---|---|---|
| Identity Graph Operator | source |
|
2026-04-24 |
Source File
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 的自主性和上下文适应能力。