Sync: add identity and trust notes

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 设计文档，暂无已知内容冲突）

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（如自然语言授权描述），则仍存在概率性风险。

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形成领域区隔。

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 的自主性和上下文适应能力。

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
+- 无已知冲突
+