金融核心系统架构的“第四范式“革命

「Agent 重塑金融技术架构」三部曲 · 第二篇

上一篇讲"我们如何造软件"（研发范式），这一篇讲"软件如何跑 "（运行时架构）。核心命题：当推理时展开的行动序列成为新的能力增长维度，金融核心系统的架构必须重新分层。

摘要（给时间紧张的架构师）

|---|----------------------------------------------------------------------------------|-------------------------------------------|
| # | 结论 | 关键含义 |
| 1 | Scaling Law 有四个范式。前三者扩展能力上限 ，第四范式 Agentic Scaling 扩展能力兑现。 | 金融的痛点从来不是"模型不够聪明"，而是"任务链路太长、跨系统太多、异常分支太密" |
| 2 | Agentic Scaling 的三个变量：Agent 数量 × 迭代深度 × 时间跨度。它不是"更大的模型"，而是"更长的行动序列"。 | 架构要优化的对象从"单次推理"变成"行动序列的可靠性" |
| 3 | 软件形态将分裂为光谱三态：传统软件（稳态）、柔性软件（弹性）、即时软件（即抛）。 | 金融的答案不是"全都改"，而是**"确定性内核 + 柔性外壳"** |
| 4 | 交互入口从 GUI 走向 CUI / Agent Interface。"页面"退化为资源，API 成为主要产品面。 | 权限模型必须从"用户-菜单-按钮"重构为"Agent-工具-范围" |
| 5 | 落地抓手是 Harness Engineering 三件套：Skills 封装、Environment 构建、编排与协调（MCP / A2A）。 | 架构师从"设计软件"转向"设计 Agent 的执行环境" |

一、背景：Scaling Law 的演进与瓶颈

1.1 四个范式，两种性质

过去几年，"能力从哪来"这个问题被反复重新回答。

配图说明：左侧四个范式横向递进，右侧分出两个归因箭头------前三个指向"能力上限"，第四个单独指向"能力兑现"。

1.2 四范式对比：从"更聪明"到"更能扛"

|----------|------------------|-------------------|-------------------|---------------------------|
| 维度 | 范式一 Pre-training | 范式二 Post-training | 范式三 Test-time | 范式四 Agentic |
| 直接变量 | 参数 / 数据规模 | 对齐数据规模与质量 | 推理时思考长度 | Agent 数量 × 迭代深度 × 时间跨度 |
| 能力性质 | 基础涌现 | 可控可用 | 单点难题攻坚 | 端到端任务完成 |
| 成本曲线 | 一次性资本开支，极高 | 中等，需持续标注 | 随思考长度线性增长 | 随行动步数线性增长，但可并行摊薄 |
| 延迟特征 | 与规模无关 | 与规模无关 | 秒到分钟 | 分钟到小时（可异步） |
| 瓶颈 | 数据墙、边际收益递减 | 人类反馈成本、对齐税 | 单线程、无法并行、延迟不可接受 | 可靠性衰减、错误累积、成本失控 |
| 金融适配 | 无直接可操作性 | 决定模型"说不说人话、守不守规矩" | 适合复杂单点推理（如合同审核要点） | 适合跨系统、多步骤、有明确验收标准的业务流 |

核心洞察 ：范式一到三是**"把模型变强"** ，范式四是**"把强者组织起来干活"**。

这对金融行业的意义尤其重大：金融的价值链天生是多步骤、跨系统、强异常 的。一个"企业开户"要穿过 KYC、反洗钱、授信、账户、印鉴、权限六个域；一个"贷款预审"要串起征信、税务、流水、抵押、评分卡。这类任务的瓶颈从来不是"某一步不够聪明"，而是"步骤之间会断"。

1.3 为什么 Agentic Scaling 特别适合金融

|------------|----------------|-----------------------------------|
| 金融任务特征 | 单次推理为何失效 | Agentic Scaling 为何有效 |
| 步骤多（10+ 步） | 单次输出必须一次猜对所有步骤 | 分步执行、逐步验证、错误可局部重试 |
| 强异常分支 | 单次生成无法穷举分支 | 每个分支都可调用专门工具实际探查 |
| 需要外部状态 | 模型没有实时数据 | Agent 可调用实时接口获取真值 |
| 需要留痕 | 单次输出无中间过程 | 每一步行动天然可审计（这是金融最看重的副产品） |
| 验收标准明确 | --- | 明确的验收标准 = 清晰的"奖励信号"，让 Agent 能自我纠错 |

一个反直觉结论 ：金融行业"合规要求严"通常被视为 AI 落地的障碍。但从 Agentic Scaling 的视角看，"验收标准明确 + 全程留痕"恰恰是 Agent 最需要的两样东西 。金融行业的强约束，反而是 Agent 能跑得最稳的土壤------只要我们把约束表达成机器可执行的门禁，而不是停留在纸质制度里。

二、架构重塑：从 GUI 到 CUI，从稳态到柔态

2.1 交互变革：前端的"退化"

|------------|-----------------|--------------|-----------------------------------|
| 维度 | GUI（图形界面） | CUI（对话界面） | Agent Interface（Agent 接口） |
| 规划主体 | 人类 | 人类（Agent 辅助） | Agent |
| 执行主体 | 人类 | 人类 + 系统 | Agent |
| 交互单位 | 页面 / 按钮 / 表单 | 对话轮次 | 意图 / 任务 |
| 能力暴露方式 | 菜单树 + 表单字段 | 意图理解 + 技能匹配 | 工具（Tool）/ 技能（Skill）声明 |
| 错误处理 | 提示 + 重试 | 追问澄清 | 自主重试 + 降级 + 上报 |
| 权限模型 | 用户 → 角色 → 菜单/按钮 | 用户 → 意图 → 技能 | Agent → 工具 → 范围（Scope）+ 副作用等级 |
| 关键产物 | 页面 | 会话 | 可审计的行动序列 |
| 测试方式 | UI 自动化 / 人工 | 会话样本评测 | 验收标准回归 + 轨迹评估 |

这个变化对金融架构有四个具体含义：

"页面"退化为资源。 银行 App 里的一百个页面，未来可能只剩"账户总览"和"异常处理"两个真正需要人看；其余都变成 Agent 可调用的能力。

API 成为主要产品面。 产品经理交付的不再是"页面原型"，而是"能力契约"（工具声明 + 语义 + 副作用 + 幂等性 + 错误语义）。

权限模型必须重建。 "用户 → 菜单 → 按钮"的 RBAC 无法覆盖"Agent → 工具 → 范围"。你需要的是意图级授权 + 金额/额度上限 + 可撤销委托。

前端团队的能力重心转移。 从"页面渲染与交互实现"转向"状态可视化与人类干预界面"------即"当 Agent 不确定时，如何让人类高效接管"。

2.2 软件光谱理论：传统、柔性、即时

不是所有软件都该被 Agent 化。金融架构的正确姿势是分层，而非"全量重构"。

配图说明：三层同心结构（内核 → 弹性层 → 即时层），箭头标注三态之间的依赖关系：柔性层"包覆"内核，即时层"按需生成"。

三态详细对照

|----------------|----------------------------------|-------------------------------|--------------------------|
| 维度 | 传统软件 | 柔性软件 | 即时软件 |
| 代表系统 | 核心账务、清算、支付、证券交易、信贷主流程 | 营销活动、智能客服、运营工具、管理报表、风控策略引擎 | 临时数据分析、监管临时报送、一次性尽调、专项测算 |
| 生命周期 | 10--20 年 | 1--3 年（能力持续扩展） | 分钟到周 |
| 变更成本 | 极高（版本窗口 + 回归 + 演练） | 中（配置化 + 技能热插拔） | 近零（生成即用） |
| 确定性要求 | ★★★★★ | ★★★ | ★★ |
| 构建方式 | SDLC 稳态工程 + 严格评审 | 平台 + Skills + Agent 运行时组合 | Agent 即时生成（可含代码） |
| Agent 介入程度 | 外围辅助 （测试、文档、审查），不进核心执行路径 | 深度介入（运行时组合与调用） | 完全由 Agent 驱动 |
| 验证方式 | 全量回归 + 演练 + 双跑比对 | 契约测试 + 灰度 + 熔断 | 抽样校验 + 双人确认 |
| 治理要求 | 最高（双人复核、变更审批、演练） | 中（额度限制、策略审批） | 低（但需留痕与事后抽查） |
| 成本结构 | 人力为主 | 平台 + 推理成本 | 推理成本为主 |

核心架构原则：确定性内核 + 柔性外壳

复制代码

┌─────────────────────────────────────────────────────────┐
│  即时软件层   Instant Layer                              │
│  Agent 即时生成 · 即用即抛 · 不进主线 · 全量留痕          │
├─────────────────────────────────────────────────────────┤
│  柔性软件层   Elastic Layer                              │
│  Skills 组合 · 运行时编排 · 额度/策略门禁 · 灰度熔断      │
├─────────────────────────────────────────────────────────┤
│  ── 不可跨越的边界：柔性层不得直接改内核数据 ──            │
├─────────────────────────────────────────────────────────┤
│  确定性内核   Deterministic Core                         │
│  账务/清算/支付/交易 · 幂等 · 事务 · 强一致 · 全量回归    │
└─────────────────────────────────────────────────────────┘

配图说明：四层堆叠，中间用一条醒目的"不可跨越边界"横条分隔内核与柔性层。

这条边界是整篇文章最重要的架构约束 ：柔性层可以调用内核能力（通过明确定义的接口），但不能绕过内核、不能直接操作内核的表。所有柔性创新必须建立在内核提供的能力之上。

2.3 金融业务域 → 软件形态映射

|--------------|-----------|---------------------------|---------|---------|
| 业务域 | 软件形态 | Agent 介入方式 | 治理强度 | 落地优先级 |
| 核心账务 / 清算 | 传统 | 测试生成、文档同步、审查辅助 | R3 极高 | 低（外围先做） |
| 支付路由 | 传统 | 规则审查、异常案例分析 | R3 极高 | 低 |
| 反洗钱 / 风控策略 | 柔性 | Agent 组合规则、生成策略候选、解释命中原因 | R2 高 | 高 |
| 智能客服 | 柔性 | Agent 作为主入口，Skill 组合处理业务 | R1--R2 | 最高 |
| 营销活动 | 柔性 → 即时 | 活动页面即时生成、人群策略动态组合 | R1 | 最高 |
| 运营报表 / 管理驾驶舱 | 柔性 | 自然语言取数 + 动态可视化 | R1 | 高 |
| 监管临时报送 | 即时 | Agent 即时生成取数与校验逻辑 | R1（须留痕） | 高 |
| 投研 / 尽调辅助 | 即时 | 一次性分析工具即时生成 | R1 | 高 |
| 授信审批 | 柔性（内核仍传统） | Agent 做材料核验与要点提取，不做决策 | R2 | 中 |
| 客户资产配置建议 | 柔性 | Agent 生成候选方案，人工/客户确认 | R2--R3 | 中（合规敏感） |

落地次序建议 ：从"柔性层里最靠近客户、且不碰资金与客户核心数据"的场景切入------智能客服、运营报表、营销活动。它们验证快、收益可见、风险可回滚。

三、技术落地：Harness Engineering 在金融架构中的实践

Harness Engineering 的三件套：Skills（能力）→ Environment（环境）→ Orchestration（编排）。

配图说明：三层自下而上（技能 → 环境 → 编排），强调"上层依赖下层，下层约束上层"。

3.1 技能（Skills）封装：把业务能力变成"岗位说明书"

Skill 的四要素模型：

|-----------------|----------------------------|----------------------------|
| 要素 | 作用 | 具体内容 |
| 元数据（岗位说明书） | 让 Agent 知道"这个能力是什么、什么时候该用" | 名称、用途、适用场景、不适用场景、副作用等级、幂等性 |
| SOP（执行流程） | 定义"怎么做"的固定步骤与前置校验 | 前置条件、参数校验、执行步骤、后置校验、异常处理 |
| Tools（工具包） | 实际可调用的原子操作 | API、CLI、SQL（受限）、文件操作 |
| Guard（校验规则） | 定义"什么算做对了 / 什么绝不能做" | 输出结构校验、业务规则校验、红线拦截 |

抽象层级对比（重要）：

配图说明：四级抽象递进，高亮 Skill 为"金融业务与 Agent 之间的正确封装粒度"。

核心判断 ：不要直接把原子 API 暴露给 Agent。 一个裸的 transfer(amount) 是危险品；一个 transfer.precheck Skill（含限额校验、反欺诈查询、黑名单比对、结果预告）才是金融该有的封装粒度。

金融 Skill 定义示例：

复制代码

# skill: transfer.precheck  --- 转账预检（只读，无副作用）
# 设计意图：让 Agent 能做"完整判断"，但不能做"资金动作"
skill:
  id: bank.transfer.precheck
  version: "2.1.0"
  metadata:
    display_name: 转账预检
    purpose: 在不发生实际资金变动的前提下，完整校验一笔转账是否可执行
    when_to_use:
      - 用户表达转账意向，需要确认可行性与费用
      - 需要向用户说明"转账会不会被拦"及原因
    when_not_to_use:
      - 用户已确认且需要实际执行 -> 必须走 bank.transfer.execute（需人工/强认证）
    side_effect: none          # 关键：只读
    idempotent: true
    data_classification: PII_INTERNAL

  inputs:
    - name: payer_account
      type: masked_account_id   # 只接受掩码账号，不接受明文卡号
      required: true
    - name: payee_account
      type: masked_account_id
      required: true
    - name: amount
      type: decimal
      constraints: { min: 0.01, max: 5000000 }
    - name: channel
      type: enum
      values: [REALTIME, BATCH, CROSS_BORDER]

  sop:
    - step: 1
      action: validate_account_status
      tool: core.account.query_status
      on_failure: return_reason
    - step: 2
      action: check_balance
      tool: core.balance.query
    - step: 3
      action: check_limit
      tool: risk.limit.evaluate     # 单笔/日累计/月累计
    - step: 4
      action: check_aml
      tool: aml.screen              # 反洗钱名单
    - step: 5
      action: check_fraud
      tool: risk.fraud.evaluate
    - step: 6
      action: estimate_fee
      tool: fee.calculate

  guards:
    - rule: never_return_raw_account_no     # 输出永不含完整账号
      action: mask
    - rule: reject_if_aml_hit_without_manual_review
      action: return_manual_review_required
    - rule: output_schema_strict
      schema: TransferPrecheckResult

  outputs:
    - name: feasible
      type: boolean
    - name: blockers
      type: list<{code, message, resolution}>
    - name: estimated_fee
      type: money
    - name: required_auth_level
      type: enum
      values: [NONE, OTP, FACE, COUNTER]

  observability:
    audit_fields: [payer_hash, payee_hash, amount, verdict, blocker_codes, latency_ms]
    metrics: [latency_p99, block_rate, manual_review_rate]

这段 YAML 的关键设计点：

side_effect: none ------ 把"只读能力"和"资金动作"在封装层就切开，Agent 拿到预检能力后，可以自由探索，但物理上无法动钱。

when_not_to_use ------ 显式告诉 Agent 边界在哪。这比"写在系统提示词里"可靠得多，因为它随能力一起版本化。

guards 里的 never_return_raw_account_no ------ 红线写在能力定义里，而非依赖 Agent 自觉。

required_auth_level ------ 让能力自己声明认证要求，而不是让编排层去查权限表。这样新增能力时不会漏配权限。

金融业务能力 → Skill 封装清单（部分示例）：

|-----|-------------------------------|-----------|-----------|------------------------|
| 业务域 | Skill 示例 | 副作用 | 认证要求 | 封装粒度说明 |
| 账户 | account.query_balance | none | OTP | 只读，可让 Agent 自由调用 |
| 账户 | account.statement.export | low（生成文件） | OTP | 需限频，防批量导出 |
| 转账 | transfer.precheck | none | NONE | 见上文 |
| 转账 | transfer.execute | high | FACE | 必须强认证，不开放给自主 Agent |
| 理财 | wealth.product.search | none | NONE | 只读 |
| 理财 | wealth.suitability.evaluate | none | NONE | 适当性评估（合规必需） |
| 理财 | wealth.order.submit | high | FACE + 录音 | 需人工/强认证 |
| 风控 | risk.limit.evaluate | none | NONE | 只读 |
| 风控 | risk.rule.simulate | none | NONE | 沙箱内模拟，不落生产 |
| 授信 | credit.material.extract | none | NONE | 材料要点提取，不做决策 |
| 运营 | ops.report.generate | low | NONE | 动态生成报表 |
| 客服 | cs.knowledge.answer | none | NONE | RAG 问答 |

注意这张表里的规律 ：所有"读"类能力几乎都可以放开给 Agent，所有"写资金/写客户"类能力都必须强认证。 这条规律可以大幅简化权限设计------先按"读/写"切一刀，再按"敏感度"细分。

3.2 环境（Environment）构建：恰如其分的权限

"恰如其分（Just-enough）"是金融环境设计的关键词------给得少一点比给得多一点安全，但给得太少 Agent 就动不了。

沙箱环境的设计要素：

|----------|--------------------|----------------------------|
| 要素 | 设计要点 | 金融特有考量 |
| 数据隔离 | 沙箱内仅能用脱敏/合成数据 | 生产数据永不进沙箱；合成数据需保持统计特征但不可反推 |
| 网络隔离 | 出站白名单，默认拒绝 | 防数据外泄；出站流量全量审计 |
| 凭证管理 | 短期令牌、最小 scope、自动过期 | 绝不下发长期凭证；凭证不落 Agent 上下文 |
| 资源配额 | Token、调用次数、并发、时长上限 | 防成本失控；超限自动挂起而非静默失败 |
| 状态管理 | 幂等键 + 事务边界 + 回滚方案 | 每步操作必须可重放；写操作必须幂等 |
| 可观测 | 全轨迹记录（含上下文引用 hash） | 满足审计要求；轨迹可回放用于复盘 |
| 故障隔离 | 熔断、降级、爆炸半径限制 | 单个 Agent 异常不得影响其他任务 |

环境策略配置示例：

复制代码

# agent-runtime-env.yaml --- Agent 运行时环境（示意）
environment:
  name: elastic-layer-sandbox
  tier: elastic                 # traditional | elastic | instant
  isolation:
    data: masked_only           # 严禁生产数据
    network:
      egress: whitelist         # 默认拒绝
      allow: ["internal-api-gw.svc", "knowledge-svc.svc"]
    filesystem: ephemeral       # 任务结束即销毁

authority:                      # 恰如其分的权限
  model: just_enough
  token:
    ttl_seconds: 900
    scope: ["account:read", "risk:read", "report:write"]
  escalation:
    on_need_high_risk: request_human_approval   # 提权必须人工
  prohibited:
    - prod.write
    - core_schema.ddl
    - pii.raw_read
    - secret.read

budget:
  max_tokens_per_task: 300000
  max_tool_calls_per_task: 120
  max_wall_clock_seconds: 900
  on_exceed: suspend_and_notify    # 不是静默截断

reliability:
  idempotency_key: "${task_id}:${step_id}"
  max_iterations: 25               # 防无限循环
  max_retries_per_step: 3
  circuit_breaker:
    error_rate_threshold: 0.5
    window: 60s
    action: open_and_alert

rollback:
  strategy: compensating_action    # 补偿式回滚，非事务回滚
  auto_rollback_on:
    - guard_violation
    - downstream_5xx
  manual_confirm_on:
    - financial_impact

observability:
  trace: full                      # 完整轨迹
  capture_context_refs: true       # 记录上下文引用的 hash，而非原文
  redact_patterns: ["*id_card*", "*bank_card*", "*phone*"]

两个容易踩的坑：

on_exceed: suspend_and_notify 而不是静默截断。 静默截断会让 Agent 拿到一个"看起来成功实际不完整"的结果，进而做出错误决策------这在金融场景比直接失败更危险。

回滚用"补偿式"而非"事务式"。 跨系统、跨服务的 Agent 行动链路不可能有分布式事务。唯一现实的做法是每步设计补偿动作，并把"是否需要人工确认回滚"按资金影响分级。

危险操作分级 → 权限策略对照：

|------------|--------------------|----------------------|-----------|
| 危险等级 | 操作特征 | 允许的自动化程度 | 回滚要求 |
| D0 无害 | 只读查询、知识检索 | 完全自动 | 无需 |
| D1 可逆 | 生成报告、写沙箱、提交 PR | 完全自动 + 事后抽查 | 自动补偿 |
| D2 有影响可逆 | 写测试环境、发营销短信、调额（小额） | 自动 + 额度限制 | 自动补偿 + 告警 |
| D3 有影响难逆 | 发正式通知、改客户风险等级 | 人工确认后执行 | 人工介入回滚 |
| D4 资金/合规相关 | 转账、下单、授信决策、报送监管 | 人工执行，Agent 仅提供方案 | 人工流程 |

一票否决原则 ：D4 永不开放给自主 Agent。这条线一旦松动，整个 Agent 体系在金融场景的信任基础就会崩塌。

3.3 编排与协调：MCP 与 A2A

当 Agent 从"一个"变成"一群"，集成复杂度会爆炸式增长。

复制代码

没有标准协议时：
N 个 Agent × M 个系统 = N × M 个定制集成     ← 不可维护
┌────┐ ┌────┐ ┌────┐
│ A1 │ │ A2 │ │ A3 │
└─┬──┘ └─┬──┘ └─┬──┘
  │╲   ╱ │ ╲   ╱│
  │ ╲ ╱  │  ╲ ╱ │
  │  ╳   │   ╳  │
  │ ╱ ╲  │  ╱ ╲ │
  ▼╱   ╲ ▼ ╱   ╲▼
┌────┐┌────┐┌────┐┌────┐
│S1  ││S2  ││S3  ││S4  │
└────┘└────┘└────┘└────┘

有 MCP 之后：
N + M 个标准实现                              ← 线性可维护
┌────┐ ┌────┐ ┌────┐
│ A1 │ │ A2 │ │ A3 │
└─┬──┘ └─┬──┘ └─┬──┘
  └──────┼──────┘
         ▼
   ┌─────────────┐
   │  MCP 层     │  ← 标准化工具/资源发现与调用
   └──┬───┬───┬──┘
      ▼   ▼   ▼
    S1   S2   S3

配图说明：左右对比图，左侧 N×M 网状耦合，右侧通过 MCP 层降为 N+M 星型。

MCP 与 A2A 的分工：

|--------------|----------------------------------|----------------------------------------|---------------------------|
| 维度 | MCP（Model Context Protocol） | A2A（Agent to Agent） | 传统 ESB / SOA |
| 解决的问题 | Agent ↔ 工具/资源 的标准化接入 | Agent ↔ Agent 的发现、委托与协商 | 系统 ↔ 系统的集成与路由 |
| 交互隐喻 | "我能调用什么" | "谁可以帮我，怎么托付" | "消息怎么路由" |
| 关键概念 | Server、Tool、Resource、Prompt | Agent Card、Task、Message | Endpoint、Service、Contract |
| 金融价值 | 统一对外能力暴露，成为开放银行面向 Agent 的标准面 | 跨机构、跨部门 Agent 协作（如银行 Agent ↔ 券商 Agent） | 已有能力，但对"语义"和"意图"无感知 |
| 与现有体系的关系 | 建议叠加在现有 API 网关之上，不替代网关 | 增量建设 | 保留（负责底层治理、限流、鉴权） |

架构建议 ：MCP 不是网关的替代品，而是网关之上的"语义层"。 底层仍然由成熟的 API 网关负责限流、鉴权、路由、防重放；MCP 层负责让 Agent 能"理解并发现"这些能力。把这两件事混在一起做，是常见的架构失误。

多 Agent 编排时序图（以"企业开户预审"为例）：

配图说明 ：突出三个设计点------(1) 并行/串行混编；(2) 每个 Agent 的产出都附带"依据引用" ；(3) 最终动作（正式开户）必须人工执行，Agent 只做到"预审结论"。

编排层的四个工程要点：

|--------------|----------------------|---------------------------|
| 要点 | 说明 | 失败模式 |
| 任务分解与依赖图 | 显式建模步骤依赖，识别可并行分支 | 全串行 → 延迟不可接受；全并行 → 依赖错乱 |
| 状态机与幂等 | 每步有明确状态，每步可重放 | 重试导致重复执行（双扣款、重复报送） |
| 错误传播与降级 | 区分"可重试 / 可跳过 / 必须终止" | 一刀切重试 → 成本爆炸；一刀切终止 → 可用性差 |
| 上下文传递策略 | 不传全量上下文，只传结构化结论 | 上下文爆炸 → 成本与幻觉同时上升 |

上下文传递的关键原则 ：Agent 之间不要传自然语言的原始对话 ，要传结构化的中间结论 + 依据引用。前者会随协作轮数指数膨胀，且把上游的幻觉传染给下游。

四、结语：架构师的思维转型

4.1 三个转变

|--------------------|-------------------------|---------------------------------------------------------|
| 从 | 到 | 为什么 |
| Prompt Engineering | Context Engineering | Prompt 决定"怎么说"，上下文决定"依据什么判断"。金融场景下，后者才是决定输出质量的关键 |
| 接口设计 | 工具链与能力封装设计 | 接口是给程序员看的；Tool / Skill 是给 Agent"理解并决策"用的，需要语义、副作用、幂等性声明 |
| 功能实现 | 门禁、可观测与回滚设计 | Agent 系统的可靠性不来自"写得对"，而来自"错了能被拦住、被看见、被回滚" |

4.2 一句话总结

架构师不再设计"软件的结构"，而是设计"Agent 的执行环境"------ 定义它能做什么、不能做什么、做错了怎么办。

4.3 落地行动清单

第 1 步：画一条边界线（1 周）

把现有系统按"确定性内核 / 柔性层 / 即时层"三态分类

明确宣布：柔性层不得绕过内核直接改数据

识别 3--5 个"柔性层高价值场景"作为试点

第 2 步：把能力封装成 Skill（2--4 周）

从最靠近客户的场景开始（智能客服、运营报表）

每个 Skill 必须写清四要素：元数据、SOP、Tools、Guard

只读能力优先放开，写能力一律强认证

第 3 步：建环境，不建应用（4--8 周）

沙箱 + 脱敏数据 + 短期令牌 + 配额 + 熔断 + 全轨迹审计

D4 类操作永不开放这条线写进代码，而不是写进文档

第 4 步：叠加 MCP，不要替换网关（持续）

在现有 API 网关上叠加 MCP 语义层

让"能被 Agent 理解并调用"成为新服务上线的验收项之一

系列下一篇

《重构金融互联网：从"流量逻辑"到"行动网络"的范式转移》 ------当 Agent 成为用户的第一入口，银行 App 会变成什么？开放银行需要开放什么？

标签：Agentic Scaling Scaling Law 金融架构 Harness Engineering MCP A2A 柔性软件