金融Agent如何证明这份报告用了哪版数据？

金融 Agent 最难的问题之一，不是“能不能生成报告”。

而是：

这份报告里的数字
到底来自哪一版数据？

Google Cloud 8 月 25 日发布 Gemini Enterprise for Financial Services 时，把几个能力摆在了模型之外：

50+ foundational skills
MCP连接金融数据源
Existing Entitlements
Confidence Scores
Explicit Methodology
Data Snapshots
Precise Source Citations

其中最值得企业数据团队关注的，不是“50+ Skills”，而是：

Data Snapshot + Citation + Methodology

因为金融研究、KYC、组合监控和信用分析最终都需要回答：

当时查了什么？
用的是哪一版？
为什么得出这个结论？

为什么“当前数据”不能解释历史报告

假设 Agent 8 月 25 日 10:00 生成：

某债券收益率：4.21%

8 月 26 日重新打开数据源：

4.18%

如果系统只保存：

source = market-data

已经没法证明昨天报告里的 4.21% 来自哪里。

所以引用不能只保存：

Provider
Symbol

还要保存：

Snapshot Time
Dataset Version
Query
Entitlement Context

一个最小Data Snapshot

public record DataSnapshot(
        String snapshotId,
        String provider,
        String dataset,
        String datasetVersion,
        Instant asOf,
        String queryHash,
        String payloadHash,
        String entitlementSnapshotId) {
}

这样一条数字可以回到：

哪一个数据快照

而不是“现在再查一次”。

Financial Citation也应该结构化

public record FinancialCitation(
        String snapshotId,
        String sourceId,
        String field,
        String entity,
        String unit,
        Instant asOf,
        String excerptHash) {
}

例如：

{
  "snapshot_id": "snap-9182",
  "source_id": "market-feed-a",
  "field": "yield_to_maturity",
  "entity": "bond/ABC2029",
  "unit": "percent",
  "as_of": "2026-08-25T10:00:00Z"
}

报告里一个数字对应一条可追踪证据。

为什么Entitlement必须一起保存

Google 这次特别强调：

licensed data stays licensed
permissioned data stays permissioned

也就是说，Agent 通过 MCP 访问 Bloomberg 类、市场数据类、内部模型类数据时，权限不能因为 Agent 连接而被拍平。

但审计还要继续回答：

当时这个用户为什么有权看到？

所以 Snapshot 最好绑定：

entitlement_snapshot_id

Entitlement Snapshot

public record EntitlementSnapshot(
        String id,
        String subjectId,
        String provider,
        Set licensedDatasets,
        Set allowedScopes,
        Instant capturedAt) {
}

以后即使用户权限已经变化，也能证明：

报告生成时
权限是什么

Agent不能把“有权读”变成“有权分享”

金融数据授权通常区分：

查看
下载
再分发
外部分享

Agent 读取了 Licensed Data，不代表可以把原始数据复制进任何 Artifact。

所以 Capability 至少拆：

market.read
market.summarize
market.export
market.redistribute

不同动作不同 Policy。

一个典型Egress Policy

licensed_market_data:

  read:
    allowed: true

  internal_summary:
    allowed: true

  raw_export:
    approval: required

  external_share:
    allowed: false

这比只有一个：

market_data_access=true

强很多。

50+ Skills真正需要的是版本治理

Google 公开描述里，Financial Research Agent 自带超过 50 个基础 Skill。

企业自己再叠加：

credit-risk
KYC
portfolio-monitoring
deal-memo

很快就会出现：

Skill版本差异

所以报告必须记录：

skill_id
skill_version

一个Research Methodology Manifest

public record ResearchMethodology(
        String methodologyId,
        String skillId,
        String skillVersion,
        List requiredSources,
        List requiredChecks,
        List forbiddenShortcuts) {
}

例如信用分析：

required_sources:
  - financial_statements
  - debt_schedule
  - market_data

required_checks:
  - liquidity
  - leverage
  - covenant

forbidden_shortcuts:
  - use_unverified_web_source

这才叫“可解释方法论”。

Confidence Score不能变成一个神秘数字

如果 Agent 输出：

Confidence = 0.87

但没人知道怎么算，这个字段基本没有治理价值。

至少拆成：

Data Freshness
Source Coverage
Evidence Consistency
Model Confidence

例如：

{
  "overall": 0.87,
  "data_freshness": 0.95,
  "source_coverage": 0.90,
  "evidence_consistency": 0.82
}

这样 Reviewer 知道问题出在哪。

我会把置信度当Review Router

不是：

0.87 = 87%正确

而是：

是否需要人工

例如：

review:
  confidence_ge_0_90: normal
  confidence_0_75_0_90: analyst_review
  confidence_lt_0_75: block

置信度更像风险分流器。

KYC最需要的是Entity Resolution证据

Google 提到 KYC 工作流会处理：

PDF
Excel
SEC filings
Corporate Hierarchy
UBO

最大的风险不是摘要差，而是：

把两个同名公司合并了

所以每次 Entity Resolution 要保存：

Matching Keys
Conflict
Source
Confidence
Human Override

一个Entity Resolution记录

public record EntityMatch(
        String inputEntity,
        String resolvedEntityId,
        double score,
        List matchedOn,
        List conflicts,
        String evidenceSnapshotId) {
}

如果：

score  dataSnapshotIds,
        List citations,
        String modelVersion,
        String contentHash,
        Instant createdAt) {
}

Artifact 不是一段 Markdown。

它是：

正文
+
证据
+
方法
+
版本

数据更新后旧报告不能静默变化

如果 UI 每次打开报告都实时重新取数，历史报告会变。

金融场景应该区分：

Snapshot Report
Live View

Snapshot Report：

当时结论不可变

Live View：

明确显示当前数据

不要混。

可以做Staleness标记

例如：

Market Data:
2h

Financial Statement:
90d

Credit Rating:
30d

如果报告打开时超过阈值：

STALE

但不修改原值。

用户选择：

Refresh

再生成新版本。

Report Versioning

memo-v1
↓
refresh
↓
memo-v2

差异：

哪些数据变了
哪些结论变了

最好自动生成 Diff。

一个数字变化追踪

{
  "metric": "net_debt_ebitda",
  "v1": 3.8,
  "v2": 4.2,
  "reason": "new quarterly filing",
  "source": "filing-snap-91"
}

这类信息比重新生成一份整报告更有价值。

A2A调用也要保留来源链

Google 这次说 Financial Research Agent 可以通过 A2A API 接进其他 Agent Workflow。

一旦：

Agent A
→ Financial Research Agent
→ MCP
→ Market Data

上层报告必须继续保留底层 Citation。

不能只写：

source = financial-agent

否则证据链在 Agent-to-Agent 层断了。

A2A Response应该带Evidence Envelope

{
  "result": {...},
  "evidence": [
    {
      "snapshot_id": "snap-91",
      "citation_id": "cite-17"
    }
  ],
  "methodology": "credit-risk-v8"
}

上游 Agent 原样继承。

我会专门测“Citation完整率”

定义：

有外部事实支撑的Claim
中
有可追踪Citation的比例

例如：

98%

高风险金融报告：

目标100%

还要测“Citation正确率”

有引用不等于引用支持结论。

抽样验证：

Claim
→ Citation
→ Source

是否真正支持。

可以人审 + 自动 Rule 结合。

一个发布Gate

financial_agent_gate:

  licensed_data_violation:
    allowed: 0

  missing_snapshot:
    allowed: 0

  citation_coverage:
    min: 0.99

  unresolved_entity_match:
    max: 0

  stale_critical_data:
    allowed: 0

这比“报告Judge分数85”更贴近真实风险。

金融 Agent 真正进入生产以后，最难证明的不是：

模型会不会写一份漂亮报告

而是：

这份报告当时用了什么数据
用户当时有没有权限
数据是哪一版
方法是哪一版
每个结论能不能回到证据

Google 这次把 Data Snapshot、Methodology、Confidence 和 Source Citation 放进金融 Agent 基础设计里，是一个很重要的方向。

因为在金融场景里，可追溯性本身就是产品能力。

没有数据版本和证据链，再聪明的模型也只能算“生成器”；能把每个结论固定到当时的数据、权限和方法版本，Agent 才开始像真正可审计的研究系统。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/