Sync: add identity and trust notes

2026-04-25 07:45:03 +08:00
parent fdb657965e
commit aa980f8da2
26 changed files with 2087 additions and 192 deletions
--- a/wiki/concepts/Algorithm-Agility.md
+++ b/wiki/concepts/Algorithm-Agility.md
@@ -0,0 +1,48 @@
+---
+title: "Algorithm-Agility"
+type: concept
+tags: [cryptography, post-quantum, future-proof]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Algorithm-Agility（算法敏捷性）是一种密码学系统设计原则——将密码学算法作为可替换参数抽象，而非硬编码选择，从而使系统能够在不破坏现有身份链的前提下完成算法升级（如从经典加密迁移到后量子加密）。
+
+## Motivation
+
+当前使用的 Ed25519/ECDSA 等经典签名算法面临量子计算威胁。当 NIST 后量子标准（ML-DSA、ML-KEM、SLH-DSA）成熟并部署时，需要确保：
+- 历史签名的身份链仍可验证
+- 无需重新颁发所有现有凭证
+- 迁移过程平滑，无需停机
+
+## Design Pattern
+
+```python
+# 差的实践：硬编码算法
+signature = ed25519.sign(private_key, payload)
+
+# 好的实践：算法作为参数
+class IdentityVerifier:
+    def verify(self, payload, signature, algorithm="Ed25519"):
+        impl = self._get_implementation(algorithm)
+        return impl.verify(self.public_key, payload, signature)
+```
+
+## Hybrid Scheme（过渡期策略）
+
+在经典算法向量子安全算法迁移期间，使用混合签名：
+```
+hybrid_signature = concat(
+    classical_signature(Ed25519, payload),
+    post_quantum_signature(ML-DSA, payload)
+)
+```
+
+## Relationships
+- [[Zero-Trust]]：Algorithm-Agility 确保 Zero-Trust 基础设施在后量子时代仍可用
+- [[Evidence-Chain]]：历史 Evidence-Chain 记录必须在新算法体系下仍可独立验证
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Blocking.md
+++ b/wiki/concepts/Blocking.md
@@ -0,0 +1,46 @@
+---
+title: "Blocking"
+type: concept
+tags: ["identity-resolution", "performance", "algorithm", "entity-matching"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Blocking（阻塞/分块）
+
+## Definition
+身份解析中的候选对筛选技术——通过预计算的 **blocking key** 将全量 O(n²) 记录对比较减少为可控规模候选集的 O(n×k) 操作，是大规模实体解析的性能关键。
+
+## Blocking Key Types
+
+| 类型 | 示例 | 适用场景 |
+|------|------|----------|
+| Email Domain | `acme.com` | 同一公司账号 |
+| Phone Prefix | `+1555` | 同一地区号码 |
+| Name Soundex | `S530` | 语音相似姓名（Williams→W452） |
+| Postal Code | `94105` | 同一地理区域 |
+| Composite | email_domain + name_soundex | 联合分块，减少假阳性 |
+
+## Workflow
+
+```
+全量记录
+    ↓
+为每条记录生成 blocking key(s)
+    ↓
+按 blocking key 分组（分块）
+    ↓
+仅对同组记录对进行 pairwise scoring
+    ↓
+跨块记录对被阻塞（不比较）
+```
+
+## Design Considerations
+- **召回率 vs 性能**：blocking key 越宽松 → 更多候选对 → 更高召回率但更慢；越严格 → 更少候选对但可能遗漏真匹配
+- **假阴性风险**：两个同实体但 blocking key 不同（如 "gmail.com" vs "googlemail.com"）会跨块遗漏
+- **假阳性成本**：同块内异实体（如同名不同人的 "John Smith"）需靠 scoring 层排除
+
+## Relationship to Related Concepts
+- [[Blocking]] 是 [[Identity Resolution]] 的性能优化组件，通过牺牲少量召回率换取大规模场景可接受的计算成本
+- [[Fuzzy-Matching]] 在 Blocking 筛选出的候选对上执行细粒度评分
+- [[Confidence-Score]] 综合 Blocking + Scoring 的结果给出最终合并决策
--- a/wiki/concepts/Confidence-Score.md
+++ b/wiki/concepts/Confidence-Score.md
@@ -0,0 +1,52 @@
+---
+title: "Confidence Score"
+type: concept
+tags: ["identity-resolution", "decision-making", "threshold", "multi-agent"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Confidence Score（置信度评分）
+
+## Definition
+身份解析决策的核心度量——综合所有字段级匹配证据，通过加权求和得出的合并置信度。是决定"自动合并 / 提案审查 / 创建新实体"三类决策的分界指标。
+
+## Calculation
+
+```
+confidence = Σ(score_i × weight_i) / Σ(weight_i)
+```
+
+其中 `score_i` 是字段级 fuzzy/exact match 分数（0–1），`weight_i` 是字段可靠性权重。
+
+### 示例（来自 Identity Graph Operator 源码）
+| 字段 | 记录A值 | 记录B值 | Normalizer | Comparator | Score | Weight |
+|------|---------|---------|-----------|------------|-------|--------|
+| email | wsmith@acme.com | wsmith@acme.com | email | exact | 1.0 | 高 |
+| last_name | Smith | Smith | name | exact | 1.0 | 高 |
+| first_name | William | Bill | name | nickname | 0.82 | 中 |
+| phone | +155****0142 | +155****0142 | phone | exact | 1.0 | 高 |
+
+综合置信度 = `1.0×0.3 + 1.0×0.3 + 0.82×0.2 + 1.0×0.2` ≈ **0.96**
+
+## Decision Thresholds
+
+```
+confidence > 0.95  →  自动合并（单 Agent 高置信）
+0.60 ≤ confidence ≤ 0.95  →  提案审查（多 Agent 协作）
+confidence < 0.60  →  创建新实体
+```
+
+## Field Reliability Weights
+
+| 字段 | 权重 | 原因 |
+|------|------|------|
+| Email | 高 | 几乎唯一，变更需主动操作 |
+| Phone | 高 | 需验证，变更成本高 |
+| Name | 中 | 常见同名不同人，需结合其他字段 |
+| Address | 低 | 常见地址变更（搬家） |
+
+## Why Thresholds Matter
+- **防止假阳性**（False Merge）：将两个不同人（如同名"John Smith"）错误合并——高阈值 + 字段级证据防止
+- **防止假阴性**（Missed Match）：将同一人（如"Bill Smith"/"William Smith"）遗漏为不同实体——中等阈值触发提案审查而非直接拒绝
+- **可解释性**：per-field evidence 使决策可被其他 Agent 和人类审计
--- a/wiki/concepts/Delegation-Chain.md
+++ b/wiki/concepts/Delegation-Chain.md
@@ -0,0 +1,40 @@
+---
+title: "Delegation-Chain"
+type: concept
+tags: [authorization, delegation, multi-hop]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Delegation-Chain（委托链）是一种多跳授权链机制——当 Agent A 授权 Agent B 代表其行事，Agent B 可以进一步授权 Agent C，但每一跳都必须满足：签名有效 + 作用域不扩大 + 时间未过期。
+
+## Chain Structure
+
+```
+Agent A ──signs──> Agent B (scope: trade.execute)
+                       │
+                       └──signs──> Agent C (scope: trade.execute, audit.write)  ❌ scope_escalation
+```
+
+## Verification Rules
+
+每条委托链必须通过三项验证：
+1. **签名有效性**：当前 Agent 的签名必须可被其公钥验证
+2. **作用域不扩大**：本跳授权的作用域不得宽于上一跳
+3. **时间有效性**：委托链中任意节点过期，则整链失效
+
+## Fail-Closed Behavior
+
+- 委托链的任意链节断裂 → **整链无效**
+- 委托链的任意节点过期 → **整链无效**
+- 无法验证某节点签名 → **整链无效**
+
+## Relationships
+- [[Zero-Trust]]：Delegation-Chain 是 Zero-Trust 授权验证的核心机制
+- [[Fail-Closed]]：委托链验证采用 Fail-Closed 策略（任意断裂则整链失效）
+- [[Peer-Verification]]：Peer-Verification 协议在有委托时必须验证 Delegation-Chain
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Dengbao-2.0.md
+++ b/wiki/concepts/Dengbao-2.0.md
@@ -0,0 +1,50 @@
+---
+title: "Dengbao 2.0"
+type: concept
+tags: [China, cybersecurity, compliance, ToG, government]
+sources: [government-digital-presales-consultant]
+last_updated: 2026-04-25
+---
+
+# Dengbao 2.0（网络安全等级保护）
+
+网络安全等级保护制度（Classified Protection of Cybersecurity），是中国政府强制性的网络安全合规框架，要求所有政府信息系统按照安全等级进行保护和评估。
+
+## 基本概念
+
+- **等级划分**：1级（自主保护）→ 2级（指导保护）→ 3级（监督保护）→ 4级（强制保护）→ 5级（专控保护）
+- **政府系统要求**：通常要求**等保三级**，核心系统可能要求**等保四级**
+- **强制性质**：等保不是加分项，而是**投标入围的强制性前置条件**
+
+## 等保三级核心控制域
+
+| 安全域 | 控制要求 | Proposed Measure |
+|--------|---------|-----------------|
+| 安全通信网络 | 网络架构安全 | 安全域划分、VLAN 隔离 |
+| 安全通信网络 | 传输安全 | SM4 加密传输，国密 VPN 网关 |
+| 安全边界 | 边界防护 | 下一代防火墙访问控制策略 |
+| 安全边界 | 入侵防范 | IDS/IPS 部署 |
+| 安全计算环境 | 身份鉴别 | 双因素认证，国密 CA + 动态令牌 |
+| 安全计算环境 | 数据完整性 | SM3 校验，国密中间件 |
+| 安全计算环境 | 数据备份恢复 | 本地 + 异地备份 |
+| 安全管理中心 | 集中管理 | 统一安全管理平台，SIEM/SOC |
+| 安全管理中心 | 审计管理 | 日志集中采集分析 |
+
+## 实施时间线
+
+- **关键里程碑**：系统上线前必须完成等保评估
+- **整改周期**：通常需要 **2-3 个月**进行整改
+- **评估流程**：系统建设 → 差距分析 → 整改加固 → 正式评估 → 备案
+
+## 与信创的关系
+
+等保三级与[[Xinchuang]]（信创）结合是政府项目的标准合规要求：
+- 信创适配产品（国产 CPU/OS/数据库/中间件）需提供兼容测试报告
+- 等保三级安全架构设计需在信创平台上重新验证
+- 两者共同构成政府 IT 项目投标的技术门槛
+
+## Aliases
+- 网络安全等级保护
+- 等保 2.0
+- Classified Protection of Cybersecurity
+- Wangluo Anquan Dengji Baohu
--- a/wiki/concepts/Evidence-Chain.md
+++ b/wiki/concepts/Evidence-Chain.md
@@ -0,0 +1,42 @@
+---
+title: "Evidence-Chain"
+type: concept
+tags: [audit, security, tamper-detection]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Evidence-Chain（证据链）是一种仅追加（append-only）、链式哈希、防篡改的操作记录系统。每个证据记录包含：意图（intent）、决策（decision）、结果（outcome），并通过哈希链指向前一记录，形成完整操作审计链。
+
+## Core Properties
+
+- **仅追加**：历史记录不可修改，只能添加新记录
+- **链式哈希**：每个记录包含前一条记录的哈希值，篡改任意记录都会破坏链的完整性
+- **独立可验证**：任何第三方可以在不信任记录系统的前提下验证链的完整性
+- **防篡改检测**：链中任意记录被修改，后续所有哈希校验将失败
+
+## Structure
+
+```python
+{
+    "agent_id": "trading-agent-prod-7a3f",
+    "action_type": "trade.execute",
+    "intent": {"symbol": "AAPL", "quantity": 100, "side": "buy"},
+    "decision": "approved: scope verified, trust score 0.94",
+    "outcome": {"filled": true, "price": 182.50, "order_id": "ord-xyz"},
+    "timestamp_utc": "2026-03-01T14:30:00Z",
+    "prev_record_hash": "0"*64,
+    "record_hash": "sha256(...)",
+    "signature": "Ed25519(agent_private_key, record_hash)"
+}
+```
+
+## Relationships
+- [[Zero-Trust]]：Evidence-Chain 是 Zero-Trust 日志完整性的核心机制
+- [[Trust-Scoring]]：Trust-Scoring 的评分依据来源于 Evidence-Chain 的可验证结果
+- [[Algorithm-Agility]]：算法升级时需要保证历史证据链的可验证性
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Evidence-based-Merge-Proposal.md
+++ b/wiki/concepts/Evidence-based-Merge-Proposal.md
@@ -0,0 +1,49 @@
+---
+title: "Evidence-based Merge Proposal"
+type: concept
+tags: ["multi-agent", "identity", "coordination", "decision-making"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Evidence-based Merge Proposal（证据驱动合并提案）
+
+## Definition
+多 Agent 身份协调中的标准提案协议——当发现两个实体应合并时，不直接执行 merge 操作，而是构造包含完整 per-field evidence 的提案，供其他 Agent 审查后再执行。
+
+## Structure
+
+```json
+{
+  "entity_a_id": "a1b2c3d4-...",
+  "entity_b_id": "e5f6g7h8-...",
+  "confidence": 0.87,
+  "evidence": {
+    "email_match": { "score": 1.0, "values": ["wsmith@acme.com", "wsmith@acme.com"] },
+    "name_match": { "score": 0.82, "values": ["William Smith", "Bill Smith"] },
+    "phone_match": { "score": 1.0, "values": ["+155****0142", "+155****0142"] },
+    "reasoning": "Same email and phone. Name differs but 'Bill' is a known nickname for 'William'."
+  }
+}
+```
+
+## When to Propose vs. Direct Merge
+
+| 场景 | 动作 | 原因 |
+|------|------|------|
+| 单 Agent，置信度 > 0.95 | 直接合并 | 无歧义，无其他 Agent 需协商 |
+| 多 Agent，置信度中等 | 提案合并 | 让其他 Agent 审查证据 |
+| Agent 不同意既有合并 | 提案拆分（含 member_ids） | 不直接撤销，由多方验证 |
+| 修正数据字段 | 带 expected_version 的直接变更 | 字段更新无需多 Agent 审查 |
+
+## Core Principles
+- **永远不带证据不合并**："These look similar" 不是证据，per-field comparison scores + confidence thresholds 才是证据
+- **提案优于断言**：提出 merge（带证据）而非直接执行，让对方 Agent 有机会审查
+- **反压不覆盖**：当 Agent 间存在冲突（一个提出 merge，另一个提出 split），不直接覆盖另一方证据，而是呈现反证据让最强证据胜出
+
+## Conflict Resolution
+当两个 Agent 对同一对实体给出矛盾提案时：
+1. 标记为 `conflict` 状态
+2. 双方添加评论讨论证据
+3. 等待人类或仲裁 Agent 最终裁决
+4. 永不通过"强行覆盖"解决冲突
--- a/wiki/concepts/Fail-Closed.md
+++ b/wiki/concepts/Fail-Closed.md
@@ -0,0 +1,36 @@
+---
+title: "Fail-Closed"
+type: concept
+tags: [authorization, security, default-deny]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Fail-Closed（故障关闭）是一种安全授权策略——当验证系统无法完成验证时，默认结果为**拒绝**，而非**允许**。这是 Zero-Trust 架构的必然推论。
+
+## Fail-Closed Rules
+
+| 验证失败场景 | 默认行为 |
+|------------|---------|
+| 身份无法验证 | 拒绝操作 |
+| 委托链存在断裂 | 拒绝操作 |
+| 证据无法写入 | 拒绝操作 |
+| 信任评分低于阈值 | 要求重新验证，拒绝操作 |
+| 凭证已过期 | 拒绝操作 |
+
+## vs. Fail-Open
+
+| 策略 | 无法验证时的行为 | 适用场景 |
+|------|----------------|---------|
+| **Fail-Closed**（本文档） | 拒绝操作 | 高风险操作（金融交易、基础设施部署、物理控制） |
+| **Fail-Open** | 允许操作 | 低风险操作（读操作、内部服务调用） |
+
+## Relationships
+- [[Zero-Trust]]：Fail-Closed 是 Zero-Trust 默认不信任原则的具体化
+- [[Delegation-Chain]]：委托链验证采用 Fail-Closed 策略
+- [[Peer-Verification]]：Peer 验证的所有检查均采用 Fail-Closed
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Fuzzy-Matching.md
+++ b/wiki/concepts/Fuzzy-Matching.md
@@ -0,0 +1,57 @@
+---
+title: "Fuzzy Matching"
+type: concept
+tags: ["identity-resolution", "string-similarity", "normalization", "entity-matching"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Fuzzy Matching（模糊匹配）
+
+## Definition
+处理"相同实体但文本表达不同"记录的能力——通过规范化（Normalization）和相似度算法，将表面不同的记录识别为同一实体。是身份解析的核心挑战之一。
+
+## Core Techniques
+
+### 1. Nickname Normalization
+```python
+nicknames = {
+    "bill": "william", "bob": "robert", "jim": "james",
+    "mike": "michael", "dave": "david", "joe": "joseph",
+    "tom": "thomas", "dick": "richard", "jack": "john",
+}
+# "Bill Smith" → "william smith"
+```
+
+### 2. String Similarity
+| 算法 | 适用场景 |
+|------|----------|
+| Levenshtein Distance | 字符级编辑距离 |
+| Jaro-Winkler | 人名高权重前缀匹配 |
+| Soundex / Metaphone | 语音相似性（"Jon" = "John"） |
+| Token-based（TF-IDF） | 多词短语 |
+
+### 3. Field-specific Normalization
+| 字段类型 | 规范化规则 |
+|----------|------------|
+| Email | `lower().strip()` |
+| Phone | `re.sub(r"[^\d+]", "", value)` → E.164 格式 |
+| Name | Nickname expansion + lowercase |
+| Address | Street abbreviation（St→Street）、directionals（NE→Northeast） |
+
+## Example
+```
+记录A: "Bill Smith", wsmith@acme.com, +1-555-0142
+记录B: "William Smith", wsmith@acme.com, +15550142
+        ↓ Normalize + Score
+Email:     1.0（exact match）
+Name:      0.82（Bill→William nickname expansion）
+Phone:     1.0（E.164 normalized）
+────────────────────────────────
+Total:     0.94 confidence → 触发自动 merge（> 0.95 阈值接近）
+```
+
+## Relationship to Related Concepts
+- [[Fuzzy-Matching]] 是 [[Identity-Resolution]] scoring 层的核心技术
+- [[Blocking]] 筛选候选对后，[[Fuzzy-Matching]] 执行细粒度字段比较
+- [[Confidence-Score]] 综合所有字段的 fuzzy match scores 得出最终决策
--- a/wiki/concepts/Identity-Resolution.md
+++ b/wiki/concepts/Identity-Resolution.md
@@ -0,0 +1,43 @@
+---
+title: "Identity Resolution"
+type: concept
+tags: ["identity", "entity-resolution", "multi-agent", "data-matching"]
+sources: ["identity-graph-operator"]
+last_updated: 2026-04-25
+---
+
+# Identity Resolution（身份解析）
+
+## Definition
+将来自不同来源的多条记录归一化为同一 **canonical entity_id** 的过程——确保同一个真实世界实体（人/公司/产品）在系统中只对应一个唯一标识符，所有 Agent 共享这一规范视图。
+
+## Core Workflow
+
+```
+原始记录 → 规范化(Normalize) → 阻塞(Blocking) → 评分(Scoring) → 聚类(Clustering) → Canonical Entity
+```
+
+1. **规范化**：邮箱小写、电话 E.164 格式、昵称扩展（Bill→William）
+2. **阻塞**：用 blocking key（email domain / phone prefix / name soundex）快速筛选候选对，避免 O(n²) 全图扫描
+3. **评分**：字段级加权相似度（email exact match = 1.0，name fuzzy = 0.82）
+4. **聚类**：高置信度候选归入同一 cluster，生成 canonical entity_id
+
+## Key Properties
+- **确定性**：相同输入必须返回相同 entity_id（由 Identity Graph Operator 强制执行）
+- **证据驱动**：每条合并决策必须有 per-field evidence，拒绝"看起来相似"断言
+- **并发安全**：通过乐观锁（version field）防止并发写入冲突
+- **可审计**：完整事件历史（entity.created / merged / split / updated）
+
+## Confidence Thresholds
+| 置信度 | 操作 |
+|--------|------|
+| > 0.95 | 直接合并（单 Agent 高置信） |
+| 0.60–0.95 | 提案审查（多 Agent 协作） |
+| < 0.60 | 创建新实体 |
+
+## Relationship to Related Concepts
+- [[Identity Resolution]] ⊂ [[Master-Data-Management]]（MDM）：身份解析是 MDM 在多 Agent 系统中的分布式实现，增加了并发协调维度
+- [[Identity Resolution]] 应用层：[[Personal CRM]] 联系人去重、[[Identity-Graph-Operator]] 企业级多 Agent 协调
+
+## Related Agents
+- [[identity-graph-operator]]：Identity Resolution 能力在多 Agent 系统中的 Agent 化封装
--- a/wiki/concepts/Miping.md
+++ b/wiki/concepts/Miping.md
@@ -0,0 +1,54 @@
+---
+title: "Miping"
+type: concept
+tags: [China, cryptography, compliance, ToG, government, SM2, SM3, SM4]
+sources: [government-digital-presales-consultant]
+last_updated: 2026-04-25
+---
+
+# Miping（商用密码应用安全性评估）
+
+商用密码应用安全性评估（Commercial Cryptographic Application Security Assessment），是中国政府对涉及密码使用的信息系统进行强制性安全评估的合规制度。
+
+## 基本概念
+
+- **全称**：商用密码应用安全性评估
+- **拼音缩写**：密评（Mìpíng）
+- **主管机构**：国家密码管理局
+- **强制性质**：政府系统涉及密码应用的上线**前置条件**，验收必须提供密评报告
+
+## 强制使用场景
+
+涉及以下场景的政府系统**必须使用国密算法**：
+1. **身份认证**：用户身份鉴别、单点登录
+2. **数据传输**：系统间 API 通信、数据同步
+3. **数据存储**：敏感数据加密存储
+4. **电子签章**：电子印章、CA 证书
+
+## 国密算法体系
+
+| 算法类型 | 算法名称 | 用途 |
+|---------|---------|------|
+| 非对称加密 | SM2 | 密钥交换、数字签名 |
+| 哈希算法 | SM3 | 数据完整性校验 |
+| 对称加密 | SM4 | 数据加密传输和存储 |
+
+## 密评要求
+
+- 电子印章和 CA 证书必须使用**国密证书**
+- 密码产品必须通过国家密码管理局审批
+- 密评报告是系统验收的**必要文件**
+
+## 与等保的关系
+
+- [[Dengbao-2.0]]（等保）和 Miping 是政府 IT 系统的两项**并列合规要求**
+- 等保关注整体安全架构，Miping 专注于密码应用正确性
+- 两者在投标时通常作为独立章节分别论述
+
+## Aliases
+- 商用密码应用安全性评估
+- 密评
+- Shangmi Yingyong Anquan Xing Pinggu
+- Commercial Cryptographic Application Security Assessment
+- 国密算法（SM2/SM3/SM4）
+- Guomi Algorithms
--- a/wiki/concepts/Peer-Verification.md
+++ b/wiki/concepts/Peer-Verification.md
@@ -0,0 +1,58 @@
+---
+title: "Peer-Verification"
+type: concept
+tags: [verification, authentication, protocol]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Peer-Verification（对等验证）是一种 Agent 间在接受委托工作前互相验证身份和授权的安全协议。在 Agent 接受来自其他 Agent 的工作请求前，必须完成五项独立验证——全部通过才接受工作。
+
+## Verification Checks
+
+```python
+checks = {
+    "identity_valid":         # 1. 密码学身份证明是否有效
+    "credential_current":     # 2. 凭证是否在有效期内
+    "scope_sufficient":       # 3. 授权范围是否覆盖请求的操作
+    "trust_above_threshold":  # 4. 信任评分是否 ≥ 0.5
+    "delegation_chain_valid": # 5. 委托链是否完整（如涉及委托）
+}
+# 全部通过才接受工作（Fail-Closed）
+```
+
+## Protocol Flow
+
+```
+Agent A                     Agent B
+   │                           │
+   │──── request_work ─────────>│
+   │                           │
+   │<--- identity_proof -------│ (Agent B 提供公钥 + 签名)
+   │<--- credential -----------│ (Agent B 提供凭证 + 过期时间)
+   │<--- delegation_chain -----│ (如为委托工作)
+   │                           │
+   │ 验证身份 → 验证凭证 → 验证作用域 → 验证信任分 → 验证委托链
+   │                           │
+   │<--- verification_result --│
+   │                           │
+   if all_passed:
+       Agent A 接受 Agent B 的工作
+   else:
+       Agent A 拒绝 Agent B 的工作
+```
+
+## Performance Requirement
+
+- **P99 延迟 < 50ms**：验证过程不得成为系统性能瓶颈
+
+## Relationships
+- [[Zero-Trust]]：Peer-Verification 是 Zero-Trust 在 Agent 间交互中的实现
+- [[Trust-Scoring]]：Trust-Scoring 提供 Peer-Verification 的决策依据
+- [[Delegation-Chain]]：当 Agent 间存在委托关系时，Peer-Verification 必须验证 Delegation-Chain
+- [[Fail-Closed]]：所有检查项均采用 Fail-Closed 策略
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Trust-Scoring.md
+++ b/wiki/concepts/Trust-Scoring.md
@@ -0,0 +1,54 @@
+---
+title: "Trust-Scoring"
+type: concept
+tags: [trust, scoring, agent-reliability]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Trust-Scoring 是一种基于**可验证结果**的惩罚型信任量化模型。Agent 从初始分数 1.0 开始，仅通过可客观验证的问题进行扣分；Agent 不得自我报告信号来提高信任分。
+
+## Scoring Model
+
+```python
+score = 1.0
+
+# 证据链损坏（最高惩罚）
+if not check_chain_integrity(agent_id):
+    score -= 0.5
+
+# 结果验证（失败率 × 0.4）
+outcomes = get_verified_outcomes(agent_id)
+if outcomes.total > 0:
+    failure_rate = 1.0 - (outcomes.achieved / outcomes.total)
+    score -= failure_rate * 0.4
+
+# 凭证新鲜度
+if credential_age_days(agent_id) > 90:
+    score -= 0.1
+```
+
+## Trust Levels
+
+| 分数区间 | 信任等级 | 说明 |
+|---------|---------|------|
+| ≥ 0.9 | HIGH | 完全可信任，可执行高风险操作 |
+| ≥ 0.5 | MODERATE | 有限信任，需额外验证 |
+| > 0.0 | LOW | 高度谨慎，需全面验证 |
+| 0.0 | NONE | 不可信，拒绝所有操作请求 |
+
+## Key Properties
+
+- **无自我报告**：Agent 不能声称自己是可信的——信任来自客观可验证的证据
+- **信任衰减**：长期未活动的 Agent 或过期凭证自动降低信任分
+- **证据驱动**：评分基于 [[Evidence-Chain]] 中的实际执行结果，而非声誉或声明
+
+## Relationships
+- [[Zero-Trust]]：Trust-Scoring 是 Zero-Trust 可量化验证的实现
+- [[Evidence-Chain]]：Trust-Scoring 的评分依据来源
+- [[Peer-Verification]]：Peer-Verification 协议使用 Trust-Scoring 作为决策依据之一
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/concepts/Xinchuang.md
+++ b/wiki/concepts/Xinchuang.md
@@ -0,0 +1,65 @@
+---
+title: "Xinchuang"
+type: concept
+tags: [China, domestic-IT, localization, ToG, government, Kunpeng, Phytium, UOS]
+sources: [government-digital-presales-consultant]
+last_updated: 2026-04-25
+---
+
+# Xinchuang（信息技术应用创新）
+
+信息技术应用创新（Xìnxì Jìshù Yìngyòng Chuàngxīn），是中国政府推动的 IT 基础设施国产化替代战略，旨在用国产技术和产品替代国外产品，确保关键信息系统的自主可控。
+
+## 全称
+
+- **中文**：信息技术应用创新
+- **拼音**：Xinchuang / Xìnchuàng
+- **英文**：Innovation in Information Technology
+
+## 核心替代领域
+
+| 层级 | 国外产品 | 国产替代 |
+|-----|---------|---------|
+| CPU 芯片 | Intel Xeon / AMD EPYC | 鲲鹏（Kunpeng 920）/ 飞腾（Phytium S2500）/ 海光 / 龙芯 |
+| 操作系统 | Windows Server / CentOS | 统信 UOS / 银河麒麟（Kylin） |
+| 数据库 | Oracle / MySQL / PostgreSQL | 达梦（DM）/ 人大金仓（KingbaseES）/ GaussDB |
+| 中间件 | Tomcat / JBoss / WebLogic | 东方通（TongWeb）/ 宝兰德（BES） |
+| 办公软件 | MS Office | WPS Office / 永中 Office |
+
+## 适配策略
+
+- **优先采用目录内产品**：选择进入信创产品目录的主流产品
+- **兼容性测试矩阵**：建立完整的产品兼容测试矩阵（CPU×OS×数据库×中间件）
+- **分阶段替代**：并非所有组件都需要立即替代，分阶段替代是被接受的
+- **信创适配认证**：需提供适配认证报告和兼容性测试证明
+
+## 信创适配检查清单
+
+| 层级 | 组件 | 当前产品 | 信创替代方案 | 兼容性测试 | 优先级 |
+|-----|-----|---------|------------|-----------|-------|
+| Chip | CPU | Intel Xeon | Kunpeng 920 / Phytium S2500 | | P0 |
+| OS | 服务器 OS | CentOS 7 | UnionTech UOS V20 / Kylin V10 | | P0 |
+| Database | RDBMS | MySQL / Oracle | DM8 / KingbaseES | | P0 |
+| Middleware | 应用服务器 | Tomcat | TongWeb / BES | | P1 |
+| Middleware | 消息队列 | RabbitMQ | 国产替代方案 | | P2 |
+| Office | 办公套件 | MS Office | WPS / Yozo Office | | P1 |
+
+## 实施原则
+
+1. **不是加分项，而是必选项**：信创是政府 IT 项目的强制性要求
+2. **不是一步到位**：允许分阶段实施，优先替换核心组件
+3. **必须提供测试报告**：兼容性测试报告是投标文件的必要附件
+4. **与等保协同**：信创平台需重新进行 [[Dengbao-2.0]] 安全架构验证
+
+## Aliases
+- 信创
+- 信息技术应用创新
+- Xinchuang
+- Xìnchuàng
+- 国产化替代
+- Domestic IT Substitution
+- IT Localization
+- Kunpeng（鲲鹏）
+- Phytium（飞腾）
+- UnionTech UOS（统信 UOS）
+- DM Database（达梦数据库）
--- a/wiki/concepts/Zero-Trust.md
+++ b/wiki/concepts/Zero-Trust.md
@@ -0,0 +1,35 @@
+---
+title: "Zero-Trust"
+type: concept
+tags: [security, identity, authorization]
+sources: [agentic-identity-trust.md]
+last_updated: 2026-04-25
+---
+
+## Definition
+
+Zero-Trust 是一种安全架构范式——**永不信任，必须验证**（Never Trust, Always Verify）。在多 Agent 系统中，该原则要求每个 Agent 在执行操作前必须提供密码学可验证的身份证明，而非依赖自我声明。
+
+## Core Principles
+
+- **身份与授权分离**：证明"我是谁"（身份验证）与证明"我被允许做这个"（授权验证）是两个独立步骤。
+- **最小权限原则**：Agent 仅被授予完成特定任务所需的最小权限范围。
+- **假设已失陷**：设计时假设网络中至少有一个 Agent 已失陷或被错误配置。
+- **显式验证**：每次交互都必须进行验证，不能依赖先前交互的信任状态。
+
+## Application in Multi-Agent Systems
+
+| 层面 | Zero-Trust 要求 |
+|------|----------------|
+| 身份验证 | Agent 必须提供密码学签名证明，而非声称身份 |
+| 授权验证 | 必须提供可验证的委托链，而非声称"我被授权了" |
+| 日志完整性 | 日志写入者不得同时具备修改日志的能力 |
+| 跨框架互操作 | 每个框架的信任模型必须可被其他框架独立验证 |
+
+## Relationships
+- [[Evidence-Chain]]：Zero-Trust 日志层的实现机制
+- [[Trust-Scoring]]：Zero-Trust 信任评估的量化手段
+- [[Fail-Closed]]：Zero-Trust 失败时的默认行为
+
+## Sources
+- [[agentic-identity-trust.md]]
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,11 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-24] [Government Digital Presales Consultant](sources/government-digital-presales-consultant.md)
+- [2026-04-24] [Agentic Identity & Trust Architect](sources/agentic-identity-trust.md)
+- [2026-04-24] [Document Generator Agent](sources/specialized-document-generator.md)
+- [2026-04-24] [Identity Graph Operator](sources/identity-graph-operator.md)
+- [2026-04-24] [Accounts Payable Agent Personality](sources/accounts-payable-agent.md)
 - [2026-04-24] [Recruitment Specialist Agent](sources/recruitment-specialist.md)
 - [2026-04-24] [Specialized Civil Engineer Agent](sources/specialized-civil-engineer.md)
 - [2026-04-24] [Experiment Tracker Agent Personality](sources/project-management-experiment-tracker.md)
@@ -408,11 +413,6 @@
 - [2026-04-20] [healthcare-marketing-compliance](sources/healthcare-marketing-compliance.md) — (expected: wiki/sources/healthcare-marketing-compliance.md — source missing)
 - [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing)
 - [2026-04-20] [specialized-workflow-architect](sources/specialized-workflow-architect.md) — (expected: wiki/sources/specialized-workflow-architect.md — source missing)
- [2026-04-20] [government-digital-presales-consultant](sources/government-digital-presales-consultant.md) — (expected: wiki/sources/government-digital-presales-consultant.md — source missing)
- [2026-04-20] [agentic-identity-trust](sources/agentic-identity-trust.md) — (expected: wiki/sources/agentic-identity-trust.md — source missing)
- [2026-04-20] [specialized-document-generator](sources/specialized-document-generator.md) — (expected: wiki/sources/specialized-document-generator.md — source missing)
- [2026-04-20] [identity-graph-operator](sources/identity-graph-operator.md) — (expected: wiki/sources/identity-graph-operator.md — source missing)
- [2026-04-20] [accounts-payable-agent](sources/accounts-payable-agent.md) — (expected: wiki/sources/accounts-payable-agent.md — source missing)
 - [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
 - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
@@ -826,6 +826,7 @@
 - [AI文生视频](concepts/AI文生视频.md)
 - [AI簡報工作流](concepts/AI簡報工作流.md)
 - [Alerting](concepts/Alerting.md)
+- [Algorithm-Agility](concepts/Algorithm-Agility.md)
 - [Amazon-EKS](concepts/Amazon-EKS.md)
 - [AmbientMessageMonitoring](concepts/AmbientMessageMonitoring.md)
 - [Analogy-as-Straitjacket](concepts/Analogy-as-Straitjacket.md)
@@ -846,6 +847,7 @@
 - [BEATS](concepts/BEATS.md)
 - [BindMount](concepts/BindMount.md)
 - [BI平台](concepts/BI平台.md)
+- [Blocking](concepts/Blocking.md)
 - [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md)
 - [BOOTSTRAP.md](concepts/BOOTSTRAP.md.md)
 - [Brain-Dump](concepts/Brain-Dump.md)
@@ -900,6 +902,7 @@
 - [Compaction](concepts/Compaction.md)
 - [Competition-Analysis](concepts/Competition-Analysis.md)
 - [Compliance-Automation](concepts/Compliance-Automation.md)
+- [Confidence-Score](concepts/Confidence-Score.md)
 - [Configuration-Management](concepts/Configuration-Management.md)
 - [Consensus-Voting-Pattern](concepts/Consensus-Voting-Pattern.md)
 - [Constraint-Driven-Control-Mechanics](concepts/Constraint-Driven-Control-Mechanics.md)
@@ -935,8 +938,10 @@
 - [DealHealthScoring](concepts/DealHealthScoring.md)
 - [Defense-in-Depth](concepts/Defense-in-Depth.md)
 - [Defuddle](concepts/Defuddle.md)
+- [Delegation-Chain](concepts/Delegation-Chain.md)
 - [Delivery-Traceability](concepts/Delivery-Traceability.md)
 - [Demo-Engineering](concepts/Demo-Engineering.md)
+- [Dengbao-2.0](concepts/Dengbao-2.0.md)
 - [Dependency-Management](concepts/Dependency-Management.md)
 - [Deployment-Automation](concepts/Deployment-Automation.md)
 - [Deployment-vs-Release](concepts/Deployment-vs-Release.md)
@@ -978,10 +983,13 @@
 - [Event-Correlation](concepts/Event-Correlation.md)
 - [Event-Driven-Architecture](concepts/Event-Driven-Architecture.md)
 - [EventSourcing](concepts/EventSourcing.md)
+- [Evidence-based-Merge-Proposal](concepts/Evidence-based-Merge-Proposal.md)
+- [Evidence-Chain](concepts/Evidence-Chain.md)
 - [Expert-User-Assumption](concepts/Expert-User-Assumption.md)
 - [Exporter](concepts/Exporter.md)
 - [Extended Thinking](concepts/Extended Thinking.md)
 - [external配置](concepts/external配置.md)
+- [Fail-Closed](concepts/Fail-Closed.md)
 - [Failover](concepts/Failover.md)
 - [Feature-Flag](concepts/Feature-Flag.md)
 - [FeatureList](concepts/FeatureList.md)
@@ -994,6 +1002,7 @@
 - [Food-Sensitivity-Tracking](concepts/Food-Sensitivity-Tracking.md)
 - [Full-Draft-Generation](concepts/Full-Draft-Generation.md)
 - [Full-Funnel-Campaign-Architecture](concepts/Full-Funnel-Campaign-Architecture.md)
+- [Fuzzy-Matching](concepts/Fuzzy-Matching.md)
 - [Gatekeeper](concepts/Gatekeeper.md)
 - [GDM3](concepts/GDM3.md)
 - [Generalist](concepts/Generalist.md)
@@ -1027,6 +1036,7 @@
 - [Idea-Density](concepts/Idea-Density.md)
 - [Idea-Museum](concepts/Idea-Museum.md)
 - [Identity-Governance](concepts/Identity-Governance.md)
+- [Identity-Resolution](concepts/Identity-Resolution.md)
 - [IDENTITY.md](concepts/IDENTITY.md.md)
 - [Ikigai框架](concepts/Ikigai框架.md)
 - [Immutable-Infrastructure](concepts/Immutable-Infrastructure.md)
@@ -1080,6 +1090,7 @@
 - [MEMORY.md](concepts/MEMORY.md.md)
 - [MessageMatch](concepts/MessageMatch.md)
 - [Micro-Recovery](concepts/Micro-Recovery.md)
+- [Miping](concepts/Miping.md)
 - [Model-Context-Protocol](concepts/Model-Context-Protocol.md)
 - [Model-Fallback](concepts/Model-Fallback.md)
 - [Morning-Briefing](concepts/Morning-Briefing.md)
@@ -1119,6 +1130,7 @@
 - [Passive-Learning](concepts/Passive-Learning.md)
 - [passkey](concepts/passkey.md)
 - [Pay-as-you-go](concepts/Pay-as-you-go.md)
+- [Peer-Verification](concepts/Peer-Verification.md)
 - [Penetration-Testing](concepts/Penetration-Testing.md)
 - [PerformanceMax](concepts/PerformanceMax.md)
 - [Personal-CRM](concepts/Personal-CRM.md)
@@ -1277,6 +1289,7 @@
 - [Transcript-Based-Summarization](concepts/Transcript-Based-Summarization.md)
 - [TranscriptProcessing](concepts/TranscriptProcessing.md)
 - [Tree-of-Thoughts](concepts/Tree-of-Thoughts.md)
+- [Trust-Scoring](concepts/Trust-Scoring.md)
 - [tui](concepts/tui.md)
 - [Tutor-Skills](concepts/Tutor-Skills.md)
 - [Two-Way-Voice-Conversation](concepts/Two-Way-Voice-Conversation.md)
@@ -1309,8 +1322,10 @@
 - [Workflow-Engineering](concepts/Workflow-Engineering.md)
 - [Workspace](concepts/Workspace.md)
 - [X11](concepts/X11.md)
+- [Xinchuang](concepts/Xinchuang.md)
 - [Y-Combinator](concepts/Y-Combinator.md)
 - [Zero-Friction-Capture](concepts/Zero-Friction-Capture.md)
+- [Zero-Trust](concepts/Zero-Trust.md)
 - [Zero-Trust-Architecture](concepts/Zero-Trust-Architecture.md)
 - [一人公司](concepts/一人公司.md)
 - [上下文刷新](concepts/上下文刷新.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,33 @@
+## [2026-04-25] ingest | Agentic Identity & Trust Architect（补充摄入）
+- Source file: Agent/agency-agents/specialized/agentic-identity-trust.md
+- Status: ✅ 补充摄入（source page 已存在，本次补充 Concept 页面）
+- Summary: Agentic Identity & Trust Architect——自主 Agent 身份认证与信任验证基础设施专家 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519）、零信任验证模型、惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）、对等验证协议（Peer Verifier）。高级能力：算法敏捷性（后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。
+- Concepts created: [[Zero-Trust]]（永不信任，必须验证）、[[Evidence-Chain]]（哈希链式仅追加证据记录）、[[Trust-Scoring]]（基于可验证结果的惩罚型信任评分）、[[Delegation-Chain]]（多跳委托链验证）、[[Fail-Closed]]（失败默认拒绝授权）、[[Peer-Verification]]（对等验证协议）、[[Algorithm-Agility]]（密码学算法可升级性）
+- Source page: wiki/sources/agentic-identity-trust.md
+- Notes: 与 [[Identity Graph Operator]] 互补——前者处理 Agent 身份证明（密码学确定性），后者处理实体身份匹配（概率性），共同构成完整身份层。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（零信任要求确定性 vs LLM 概率性），已在 Contradictions 中记录。本文件在 index.md中原标记为"source missing"，本次已补全为完整 source page。
+- Source file: Agent/agency-agents/specialized/specialized-document-generator.md
+- Status: ✅ 成功摄入
+- Summary: Document Generator——The Agency Specialized 部门的程序化文档生成专家 Agent，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：样式系统优先、品牌一致性、数据驱动、无障碍设计、模板可复用。
+- Concepts created: 无（文档生成工具库不宜抽象为 Concept）
+- Source page: wiki/sources/specialized-document-generator.md
+- Notes: index 中已存在同名条目（来源缺失），本次摄入后标记为已解决。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）存在潜在协同关系，建议后续摄入时补充连接。
+
+- Source file: Agent/agency-agents/specialized/identity-graph-operator.md
+- Status: ✅ 成功摄入
+- Summary: Identity Graph Operator——多智能体系统共享身份图谱运营专家 Agent，解决多 Agent 系统的身份孤岛问题（重复记录/冲突操作/级联错误）。核心方法：规范化（昵称扩展/E.164 电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类。merge/split 通过乐观锁执行，按置信度分级（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）。保留完整事件历史。
+- Concepts created: [[Identity-Resolution]]（身份解析四步流程框架）、[[Evidence-based-Merge-Proposal]]（证据驱动合并提案协议）、[[Blocking]]（阻塞分块技术）、[[Fuzzy-Matching]]（模糊匹配技术）、[[Confidence-Score]]（置信度评分与阈值决策）
+- Source page: wiki/sources/identity-graph-operator.md
+- Notes: 与 [[Designing-for-Agentic-AI]] 存在潜在冲突：确定性要求与 LLM 概率性行为如何协调，当前观点认为通过将核心逻辑从 LLM 推理分离来解决。index 中已存在同名 [[identity-graph-operator]] 条目（来源缺失），本次摄入后应标记为已解决。
+
+## [2026-04-25] ingest | Accounts Payable Agent Personality
+- Source file: Agent/agency-agents/specialized/accounts-payable-agent.md
+- Status: ✅ 成功摄入
+- Summary: AccountsPayable Agent——The Agency 财务部门的自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 全支付通道。核心原则：幂等性优先（reference ID 去重，零重复付款）、审计全链路、最优通道路由（失败自动切换备选通道）、严格额度管控（超授权额度人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成。成功指标：零重复付款、< 2 分钟执行时间、100% 审计覆盖、60 秒 escalation SLA。
+- Concepts created: （文档内概念均为具体实现细节，不满足可独立复用条件，未创建 Concept 页面）
+- Entities created: （各协作 Agent 在本文档中各仅出现 1 次，不满足出现 ≥ 2 次条件，未创建 Entity 页面）
+- Source page: wiki/sources/accounts-payable-agent.md
+- Notes: 无已知冲突。本文档为单一 Agent 设计文档，与 [[Accounts-Payable-Agent]] 协作的各 Agent 需在各自文档中补充对应协作关系。
+
 ## [2026-04-25] ingest | Specialized Civil Engineer Agent
 - Source file: Agent/agency-agents/specialized/specialized-civil-engineer.md
 - Status: ✅ 成功摄入
@@ -2982,3 +3012,11 @@
 - Entities created: [[Boss Zhipin]]
 - Source page: wiki/sources/recruitment-specialist.md
 - Notes: 无已知冲突。Key Entities 中 Lagou/Liepin/Beisen/Moka/Feishu/STAR 等在源文档出现但出现次数不足以触发独立建页，通过 Sources 页面的 Key Entities 部分建立 wikilinks。
+
+## [2026-04-25] ingest | Government Digital Presales Consultant
+- Source file: Agent/agency-agents/specialized/government-digital-presales-consultant.md
+- Status: ✅ 成功摄入
+- Summary: Government Digital Presales Consultant 是面向中国ToG（政府）市场的全生命周期售前专家Agent，涵盖政策解读、等保2.0三级/商用密码评估/信创适配、数字政府/智慧城市/城市大脑方案设计、招投标全流程（POC→标书→述标→交接）。核心原则：业务场景驱动方案、技术价值需翻译为政府语言、等保/密评/信创是强制项非加分项。
+- Concepts created: [[Dengbao-2.0]], [[Miping]], [[Xinchuang]]
+- Source page: wiki/sources/government-digital-presales-consultant.md
+- Notes: 无已知冲突。Key Entities（Digital China Master Plan、Kunpeng、Phytium、UnionTech UOS、DM Database等）在源文档中属于背景知识，未创建独立Entity页面，通过Source页面Key Entities部分建立wikilinks。Entities页面已添加Dengbao 2.0、Miping、Xinchuang三条概念索引。
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -49,6 +49,10 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents)

 **[[multi-agent-system-reliability]]**（Alex Ewerlöf）：多智能体系统可靠性的架构模式理论——反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件。核心4模式：[[Hierarchy-Agent-Pattern]]（主管→工作→验证链）、[[Consensus-Voting-Pattern]]（N个LLM多数票消除幻觉）、[[Adversarial-Debate-Pattern]]（Generator→Critic→Judge对抗辩论）、[[Knock-out-Pattern]]（适者生存淘汰制）。核心洞察：不应要求模型"小心"，而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补（架构 vs 用户体验），与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]]（遗传算法）有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。

+**[[identity-graph-operator]]**（Identity Graph Operator）：多智能体系统共享身份图谱运营专家 Agent——The Agency Specialized 部门的核心基础设施 Agent，解决多 Agent 系统的身份孤岛问题：当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。核心方法：通过规范化（昵称扩展/E.164电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类四步实现确定性身份解析；merge/split 操作通过乐观锁执行，按置信度分级处理（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）；保留 entity.created/merged/split/updated 完整事件历史。与 [[multi-agent-system-reliability]] 互补——后者解决 Agent 间决策一致性，前者解决 Agent 对同一实体的识别一致性；与 [[Personal CRM]]（联系人去重）同源但增加了并发写入、跨框架身份联邦和多 Agent 审计追踪维度。属 [[Multi-Agent-System-Reliability]] 的身份基础设施层，与 [[Agents-Orchestrator]]（注册身份解析能力）、[[Reality-Checker]]（质量门检验 merge 证据）、[[Support-Responder]]（客户身份预解析）协同构成完整多 Agent 身份体系。
+
+**[[agentic-identity-trust]]**（Agentic Identity & Trust Architect）：自主 Agent 身份认证与信任验证基础设施专家——The Agency Specialized 部门的核心安全基础设施 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519 公钥，签名密钥/加密密钥/身份密钥分离）、零信任验证模型（默认不信任自报告身份，要求密码学证明）、基于可验证结果的惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败按失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录（每个操作记录 intent→decision→outcome，篡改任意历史记录均可检测）、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）。高级能力：算法敏捷性（密码学算法可升级，为后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。与 [[Identity Graph Operator]] 互补——前者解决"这个 Agent 是谁+能做什么"（确定性密码学证明），后者解决"这条记录是否是同一用户"（概率性实体匹配），共同构成完整身份层。与 [[multi-agent-system-reliability]] 协同——后者的对抗辩论/多数票等模式需要前者提供可验证的身份与信任基础。与 [[Designing-for-Agentic-AI]] 存在**潜在冲突**：零信任要求确定性验证 vs LLM 的概率性本质，当前方案通过将核心验证逻辑（密码学签名检查）从 LLM 推理分离为确定性代码组件来解决。
+
 **[[xr-interface-architect]]**（XR Interface Architect）：XR 空间界面架构师 Agent——The Agency Spatial Computing 部门的 UX/UI 设计专家，专注于为 AR/VR/XR 沉浸式环境创建直觉化、舒适且可发现的界面。核心方法：HUD / 浮动菜单 / 交互区域设计，支持直接触摸、注视+捏合、控制器和手势四种输入模型；基于人体工程学约束进行 UI 放置，减少晕动症；构建座舱/仪表盘/可穿戴界面布局模板；运行可用性验证实验（舒适度和学习性）。人格特质：**Human-centered, layout-conscious, sensory-aware, research-driven**。与 [[xr-immersive-developer]] 和 [[xr-cockpit-interaction-specialist]] 同属 Spatial Computing 部门，三者共同构建完整的 XR 产品交互基础设施。

 **[[xr-cockpit-interaction-specialist]]**（XR Cockpit Interaction Specialist）：XR 座舱交互专家 Agent——The Agency Spatial Computing 部门的沉浸式座舱式交互设计专家，专注于设计和实现固定视角、高存在感的座舱交互环境。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）消除自由漂浮运动，通过 3D meshes 和输入约束将控制物理化；座舱人体工学对齐自然的眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用场景：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。与 [[xr-interface-architect]] 存在层级关系（前者提供座舱交互基础能力，后者构建界面）；与 [[xr-immersive-developer]] 在运动自由度设计上存在张力——前者强调固定视角约束以降低眩晕，后者倾向开放空间沉浸体验。属 [[Spatial-Computing]] 概念在座舱场景的具体应用，为 The Agency 的 XR 产品矩阵提供交互基础设施。
@@ -89,6 +93,11 @@ The Agency 的 Paid Media 部门专注于企业级付费媒体策略与运营，

 Key concepts: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[TieredCampaignArchitecture]], [[IncrementalityTesting]], [[ConversionActionHierarchy]], [[CustomerMatch]], [[BudgetPacing]], [[ResponsiveSearchAds]], [[AdStrength]], [[CreativeFatigue]], [[HookBodyCTA]], [[MessageMatch]], [[ABTesting]], [[AdExtensions]]

+### The Agency — Finance 部门
+|The Agency 的 Finance 部门涵盖自主支付运营、财务分析与合规管理等专业 Agent。|
+
+**[[accounts-payable-agent]]**（Accounts Payable Agent）：The Agency 财务部门的自主支付运营专员 Agent——处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 等全支付通道。核心原则：**幂等性优先**（reference ID 去重，零重复付款）、**审计全链路**（每笔支付记录发票引用、金额、通道、时间戳和状态）、**安全路由**（自动选择最优通道路由，失败自动切换备选通道）、**严格额度管控**（超授权额度必须人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成，接收来自其他 Agent 的支付请求并生成支出报告供 Strategy Agent 分析。成功指标：零重复付款、< 2 分钟执行时间（快捷通道）、100% 审计覆盖、60 秒内 escalation SLA。属 [[Multi-Agent-System-Reliability]] 的财务合规执行层，[[Accounts-Payable-Agent]] 为 The Agency 提供可信赖的支付执行基础。
+
 ### Multi-Agent Monitoring & Automation
 **Dynamic Dashboard**：基于 [[OpenClaw]] 的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源，定时聚合结果推送 Discord，支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发，立即获得实时洞察。[[polymarket-autopilot]] 是 Polymarket 市场监控的具体实现——AI Agent 24/7 自动监控预测市场、分析概率变化、自动执行交易策略。与 [[self-healing-home-server]] 的系统监控场景关联，[[earnings-tracker]] 的市场数据监控场景扩展，[[content-factory]] 共享子代理并行执行模式。

@@ -674,6 +683,10 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]

 **[[specialized-civil-engineer]]**（Civil Engineer）：全球设计标准覆盖的结构与土木工程专家 Agent——专注于安全、经济、可建造的结构设计，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB、IS、AIJ 等全球主流建筑规范体系。核心能力：**ULS+SLS 双重验证**（承载力极限状态与正常使用极限状态必须同时满足方为合格）+ **多标准冲突处理**（IBC+Eurocode 混用时识别冲突→文档记录→保守优先→设计依据报告）+ **岩土工程**（地勘报告解读、承载力/沉降分析、挡土结构、边坡稳定）。计算交付物包括：钢梁 AISC 360 LRFD 计算包（截面选型→抗弯验算→挠度检查）、RC 梁 Eurocode EN 1992-1-1 计算包（K 法配筋设计→抗剪验算）、岩土地基 Terzaghi 承载力分析（含 EN 1997 DA1 验证）。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。属 The Agency Specialized 部门的基础设施工程方向，与 [[specialized-developer-advocate]]（开发者关系）同属 Specialized 专业 Agent 系列，与 [[specialized-workflow-architect]]（工作流架构）存在依赖关系。

+**[[specialized-document-generator]]**（Document Generator）：专业文档生成专家 Agent——The Agency Specialized 部门的程序化文档生成专家，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档（投资者演示文稿、合规报告、数据密集型电子表格）。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：**样式系统优先**（拒绝硬编码字体/字号，使用文档样式主题）、**品牌一致性**（颜色/字体/Logo 全局统一）、**数据驱动**（接受结构化数据输入生成文档输出）、**无障碍设计**（Alt 文本/标题层级/PDF 标签）、**模板可复用**（构建模板函数而非一次性脚本）。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）协同，构成完整的文档从生成到分发的工作流。属 The Agency Specialized 部门的生产力工具方向，与 [[specialized-developer-advocate]] 同属专业工具 Agent 系列。
+
+**[[government-digital-presales-consultant]]**（Government Digital Presales Consultant）：The Agency Specialized 部门的政府数字化售前专家——面向中国ToG（政府）市场，专注于数字政府、智慧城市、一网统管、城市大脑等主流方向的全生命周期售前支持。核心能力：政策解读（数字中国/国家数据局政策信号提取：区分"鼓励探索"与"全面实施"的政策成熟度判断）、合规架构（等保2.0三级/商用密码评估/信创适配）、招投标全流程（需求调研→方案设计→POC验证→标书撰写→述标答辩→中标交接）。五步工作流配合技术方案模板、等保合规矩阵、投标检查清单、机会评估模板等交付物。关键原则：**技术方案必须以业务场景驱动**（"市民服务处理速度提升80%"而非"微服务架构"）；**等保/密评/信创是强制项而非加分项**；方案至少经过三轮迭代打磨。成功指标：中标率>40%、零废标、售前到交付偏差<10%。与 [[sales-engineer]]（通用售前）互补——后者覆盖企业级B2B市场，前者专精中国政府ToG市场特有的政策合规与采购流程；与 [[Digital-Government]]（数字政府）和 [[Smart-City]]（智慧城市）构成完整的政府信息化知识体系。属 The Agency Specialized 部门的垂直行业方向。
+
 ## Conflict Areas

 1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。
--- a/wiki/sources/accounts-payable-agent.md
+++ b/wiki/sources/accounts-payable-agent.md
@@ -0,0 +1,47 @@
+---
+title: "Accounts Payable Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/accounts-payable-agent.md]]
+
+## Summary（用中文描述）
+- 核心主题：AccountsPayable Agent——自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖加密货币、法定货币、稳定币等全支付通道
+- 问题域：AI Agent 工作流中的支付执行、审计追踪、防重复付款、多通道路由
+- 方法/机制：幂等性检查 → 供应商注册表验证 → 最优通道路由 → 执行支付 → 审计日志全链路；通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 等集成
+- 结论/价值：为 AI Agent 生态提供可信赖的支付执行层，零重复付款、完整审计覆盖、60秒内 escalation SLA
+
+## Key Claims（用中文描述）
+- AccountsPayable Agent 通过幂等性检查确保永远不会发送同一笔支付两次
+- Agent 自动选择最优支付通道（ACH/ Wire/ Crypto/ Stablecoin/ Payment API），基于接收方、金额和成本
+- 所有支付均保留完整审计日志，包含发票引用、金额、通道、时间戳和状态
+- 超过授权额度的支付必须上报人工审批，不得自动执行
+
+## Key Quotes
+> "Idempotency first: Check if an invoice has already been paid before executing. Never pay twice." — 核心安全原则
+> "If a payment rail fails, try the next available rail before escalating" — 容错路由机制
+> "Zero duplicate payments — idempotency check before every transaction" — 成功指标
+
+## Key Concepts
+- [[Idempotency]]：幂等性——同一笔支付请求无论执行多少次，结果相同。AccountsPayable 通过 reference ID 去重，防止重复付款
+- [[Payment-Rail]]：支付通道——ACH（国内/工资，1-3天）、Wire（大额/跨境，即时）、Crypto（加密原生供应商，分钟级）、Stablecoin（低费用，秒级）、Payment API（卡片/平台，1-2天）
+- [[Audit-Trail]]：审计追踪——每笔支付记录发票引用、金额、通道、时间戳和状态，确保财务合规
+- [[Vendor-Registry]]：供应商注册表——维护已批准供应商及其首选支付通道和地址
+
+## Key Entities
+- [[Contracts-Agent]]：里程碑完成后触发 AccountsPayable 执行承包商付款
+- [[Project-Manager-Agent]]：处理承包商工时材料发票
+- [[HR-Agent]]：负责工资单发放
+- [[Strategy-Agent]]：接收支出报告和资金跑道分析
+
+## Connections
+- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[Contracts-Agent]]
+- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[Project-Manager-Agent]]
+- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[HR-Agent]]
+- [[Accounts-Payable-Agent]] ← provides_spend_reports ← [[Strategy-Agent]]
+
+## Contradictions
+- （本文档为单一 Agent 设计文档，暂无已知内容冲突）
--- a/wiki/sources/agentic-identity-trust.md
+++ b/wiki/sources/agentic-identity-trust.md
@@ -0,0 +1,53 @@
+---
+title: "Agentic Identity & Trust Architect"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/agentic-identity-trust.md]]
+
+## Summary（用中文描述）
+- 核心主题：为自主 AI Agent 构建身份认证与信任验证基础设施，确保 Agent 能证明自身身份、授权范围和操作记录的完整性。
+- 问题域：多 Agent 环境中身份伪造、授权链验证缺失、可篡改日志、凭证过期未检测、委托权限升级等安全问题。
+- 方法/机制：零信任身份体系（永不信任自我声明）、密码学身份证明、证据链完整性、委托链验证、信任评分、Fail-Closed 授权策略。
+- 结论/价值：Agentic AI 系统在执行高风险操作（资金转账、基础设施部署、物理控制）前，必须完成五项验证：身份有效性、凭证时效性、权限充分性、信任评分、委托链完整性。
+
+## Key Claims（用中文描述）
+- 零信任原则：Agent 不得信任自我声明的身份或授权——"Agent 说它被授权"不等于"Agent 证明了它被授权"。
+- 证据链完整性：证据链的任何历史记录被篡改必须可被检测；写日志的实体若能修改日志，则该日志对审计毫无价值。
+- Fail-Closed 授权：身份无法验证 → 拒绝操作；委托链存在断裂 → 整链无效；信任评分低于阈值 → 要求重新验证。
+- 密码学卫生规范：使用成熟标准（Ed25519/ECDSA），签名密钥与加密密钥分离，密钥材料不得出现在日志或 API 响应中。
+- 信任评分基于可验证结果：信任分从 1.0 开始，仅通过可验证问题扣分；不允许 Agent 自我报告信号来提高信任分。
+
+## Key Quotes
+> "Never trust self-reported identity. An agent claiming to be 'finance-agent-prod' proves nothing. Require cryptographic proof." — 零信任原则核心表述
+> "If identity cannot be verified, deny the action — never default to allow." — Fail-Closed 授权策略
+> "Trust score 0.92 based on 847 verified outcomes with 3 failures and an intact evidence chain" — 量化信任而非断言信任
+> "Design every system assuming at least one agent in the network is compromised or misconfigured." — 假设妥协的安全设计哲学
+
+## Key Concepts
+- [[Zero-Trust]]：永不信任自我声明，要求密码学证明。适用于身份验证、授权验证和日志完整性三个层面。
+- [[Evidence-Chain]]：仅追加、可独立验证、链式哈希、防篡改的 Agent 操作证据记录系统。
+- [[Trust-Scoring]]：基于可观测结果的惩罚模型信任评分，Agent 从 1.0 开始，仅通过可验证问题扣分。
+- [[Delegation-Chain]]：多跳委托授权链，每一跳须签名且作用域不得宽于上级，过期或断裂则整链无效。
+- [[Fail-Closed]]：授权失败时默认拒绝，而非默认允许的安全策略。
+- [[Peer-Verification]]：Agent 之间在接受委托工作前互相验证身份和授权的协议。
+- [[Algorithm-Agility]]：密码学算法可升级性，为后量子密码学迁移预留抽象层。
+
+## Key Entities
+- [[Identity-Graph-Operator]]：与本文档并列的 Entity 身份解析 Agent，本文档负责 Agent 身份认证，Identity Graph Operator 负责人/公司/产品实体解析。
+- [[The Agency]]：该 Agent 所属的 The Agency 专业化 Agent 生态。
+
+## Connections
+- [[Identity-Graph-Operator]] ← 互补关系 ← [[Agentic-Identity-Trust]]
+- [[Designing-for-Agentic-AI]] ← 潜在冲突 ← [[Agentic-Identity-Trust]]（确定性要求与 LLM 概率性行为的张力）
+- [[agents-orchestrator]] ← 依赖 ← [[Agentic-Identity-Trust]]（编排器需信任验证层）
+- [[report-distribution-agent]] ← 依赖 ← [[Agentic-Identity-Trust]]（分发代理操作需可审计）
+
+## Contradictions
+- 与 [[Designing-for-Agentic-AI]] 冲突：
+  - 冲突点：零信任要求确定性验证 vs LLM 的概率性本质（LLM 无法提供数学意义上的确定性签名证明）
+  - 当前观点：通过将核心逻辑（密码学验证、签名检查）从 LLM 推理分离为独立组件来解决——LLM 只负责策略决策，验证层由确定性代码执行。
+  - 对方观点：若信任验证逻辑本身依赖 LLM（如自然语言授权描述），则仍存在概率性风险。
--- a/wiki/sources/government-digital-presales-consultant.md
+++ b/wiki/sources/government-digital-presales-consultant.md
@@ -0,0 +1,59 @@
+---
+title: "Government Digital Presales Consultant"
+type: source
+tags: [ToG, government-IT, presales, compliance, Xinchuang, Smart-City, Digital-Government]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/government-digital-presales-consultant.md]]
+
+## Summary（用中文描述）
+- 核心主题：中国政府信息化（ToG）市场的全生命周期售前专家智能体，涵盖从政策解读、解决方案设计到招投标全程
+- 问题域：政府数字化转型市场的项目机会识别、标书撰写、合规要求（POC验证、等保/密评/信创）、干系人管理
+- 方法/机制：五步工作流（机会发现→需求调研→方案设计→投标执行→中标交接），配合政策解读、竞品分析、POC演示、合规矩阵等工具模板
+- 结论/价值：为技术团队提供进入数字政府、智慧城市、一网统管、城市大脑等主流方向的决策支持，核心目标是提高中标率（>40%）、零废标、售前到交付对齐（偏差<10%）
+
+## Key Claims（用中文描述）
+- 售前专家通过政策语言解码（"鼓励探索"→"全面实施"）识别市场成熟度信号，在政策从"软性鼓励"转向"硬性要求"时入场
+- 政府系统通常要求等保三级，核心系统可能要求等保四级；等保评估需在系统上线前2-3个月完成整改
+- 信创替换不必一步到位，分阶段替代是被接受的
+- 技术方案应以业务场景驱动，而非技术架构驱动——客户关心"市民服务处理速度提升80%"而非"微服务架构"
+- 投标文件零容忍格式错误——资质缺失、格式偏差、响应偏移均属废标项
+
+## Key Quotes
+> "Drive with business scenarios, not technical architecture — the client cares about '80% faster citizen service processing,' not 'microservices architecture.'" — 方案设计核心原则
+> "Dengbao, Miping, and Xinchuang are mandatory, not bonus points." — 合规基线
+> "Don't tell the bureau head we use Kubernetes. Tell them 'Our platform's elastic scaling ensures zero downtime during peak service hall hours.'" — 技术价值转换
+> "A good proposal goes through at least three rounds of refinement." — 方案迭代要求
+
+## Key Concepts
+- [[Dengbao-2.0]]：网络安全等级保护制度，政府系统通常要求三级，等保评估需在上线前2-3个月完成
+- [[Miping]]：商用密码应用安全性评估，涉及身份认证、数据传输、数据存储必须使用国密算法（SM2/SM3/SM4）
+- [[Xinchuang]]：信息技术应用创新，核心要素为国产CPU（鲲鹏/飞腾/海光/龙芯）+ 国产OS（统信UOS/麒麟）+ 国产数据库（达梦/人大金仓/ GaussDB）+ 国产中间件
+- [[ToG]]（Government）：面向政府的数字化转型市场，区别于ToB（企业）和ToC（消费者）
+- [[Smart-City]]：智慧城市，典型方向包括城市大脑/城市运行中心（IOC）、智慧交通、智慧社区、城市信息模型（CIM）
+- [[Digital-Government]]：数字政府，典型方向包括一体化政务服务平台、一网统管/一网通办、12345热线智能升级、政府数据中台
+- [[Yiwangtongban]]：一网统办，一网通管，一体化政务服务门户
+- [[POC]]：概念验证，通过精选场景展示差异化优势，控制范围并设定明确成功标准
+
+## Key Entities
+- [[Digital-China-Master-Plan]]：数字中国建设整体布局规划，国家级政策文件
+- [[National-Data-Administration]]：国家数据局，国家层面数据治理主管机构
+- [[Government-Cloud]]：政务云平台，政府信息化基础设施
+- [[City-Brain]]：城市大脑，城市级数据融合与智能决策平台
+- [[Kunpeng]]：鲲鹏，国产CPU代表
+- [[Phytium]]：飞腾，国产CPU代表
+- [[UnionTech-UOS]]：统信UOS，国产操作系统代表
+- [[DM-Database]]：达梦数据库，国产数据库代表
+
+## Connections
+- [[Government-Digital-Presales-Consultant]] ← extends ← [[Sales-Engineer]]（通用售前 → 政府垂直领域售前）
+- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Xinchuang]]（信创合规必须掌握）
+- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Dengbao-2.0]]（等保合规必须掌握）
+- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Miping]]（密码评估必须掌握）
+- [[Digital-Government]] ← solution_domain ← [[Government-Digital-Presales-Consultant]]（数字政府是主要方案方向之一）
+- [[Smart-City]] ← solution_domain ← [[Government-Digital-Presales-Consultant]]（智慧城市是主要方案方向之一）
+
+## Contradictions
+- 无明显冲突。本文档专注于中国政府ToG市场，与Wiki中其他以企业级/B2B市场为中心的售前/销售Agent形成领域区隔。
--- a/wiki/sources/identity-graph-operator.md
+++ b/wiki/sources/identity-graph-operator.md
@@ -0,0 +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 的自主性和上下文适应能力。
--- a/wiki/sources/specialized-document-generator.md
+++ b/wiki/sources/specialized-document-generator.md
@@ -0,0 +1,48 @@
+---
+title: "Document Generator Agent"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-document-generator.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 担任专业文档生成专家，通过代码方式生成 PDF、PPTX、DOCX、XLSX 等格式的专业文档
+- 问题域：如何让 AI Agent 高效、规范、可复用地产出商业级文档（投资者演示文稿、合规报告、数据密集型电子表格等）
+- 方法/机制：基于 Python（reportlab、python-pptx、openpyxl、python-docx 等）和 Node.js（puppeteer、pptxgenjs、exceljs、docx 等）两大生态，使用模板化、数据驱动、品牌一致的设计原则
+- 结论/价值：文档生成 Agent 需具备精确、设计意识强、注重格式的特点；核心规则包括使用样式系统而非硬编码、保持品牌一致性、数据驱动输入、无障碍设计，以及构建可复用模板而非一次性脚本
+
+## Key Claims（用中文描述）
+- Document Generator Agent 通过代码编程方式（而非手动操作）生成专业级 PDF、演示文稿、电子表格和 Word 文档
+- Agent 需根据不同文档格式选择最优工具链（PDF 推荐 HTML+CSS→PDF 方案，PPTX 推荐 python-pptx，XLSX 推荐 openpyxl，DOCX 推荐 python-docx）
+- 核心规则：必须使用文档样式系统而非硬编码字体/字号，确保品牌颜色、字体、Logo 一致，数据驱动输入输出，支持无障碍（Alt 文本、标题层级、PDF 标签）
+- Agent 应构建可复用模板函数，而非一次性脚本，以提升效率和可维护性
+
+## Key Quotes
+> "You are **Document Generator**, a specialist in creating professional documents programmatically." — Agent 身份定位
+> "Use proper styles — Never hardcode fonts/sizes; use document styles and themes" — 核心规则第1条
+> "Ask about the target audience and purpose before generating" — 沟通风格
+
+## Key Concepts
+- [[Code-Based Document Generation]]：通过编程代码（Python/Node.js 库）而非手动操作软件生成文档的方法
+- [[Template-Based Document Generation]]：基于预定义模板，通过数据替换生成一致性文档的工作模式
+- [[Data-Driven Document Generation]]：以结构化数据为输入，自动生成对应格式文档的自动化方法
+- [[Brand-Consistent Document Design]]：在文档生成过程中保持颜色、字体、Logo 等品牌元素一致的设计原则
+
+## Key Entities
+- [[The Agency]]：Document Generator Agent 所属的 Agent 框架体系（从 index 中相关条目推断）
+- reportlab / weasyprint / fpdf2：Python PDF 生成库
+- python-pptx / pptxgenjs：PPTX 演示文稿生成库
+- openpyxl / xlsxwriter / exceljs / xlsx：XLSX 电子表格生成库
+- python-docx / docx：DOCX Word 文档生成库
+
+## Connections
+- [[specialized-developer-advocate]] ← relates_to ← [[specialized-document-generator]]（同为 The Agency 下的专业 Agent）
+- [[agents-orchestrator]] ← orchestrates ← [[specialized-document-generator]]（文档生成通常由编排 Agent 调度）
+- [[report-distribution-agent]] ← supports ← [[specialized-document-generator]]（文档生成后可由分发 Agent 推送）
+
+## Contradictions
+- 无已知冲突
+