
> 甲方 FDE 手记 ③｜底线
> 系列主线：AI 落地不是交付一个系统，是建立一套让 AI 能活下来的机制。本篇讲这套机制的底线层。

---

## 开篇：能买的是模型调用，买不来的是控制权

前两篇讲路径和方法的时候，隐含了一个前提：这些东西由谁来做都行，内部做、外部做、买现成的，差别在成本和速度。

在金融行业，这个前提不成立。

不是说金融的要求更高。要求高可以靠加预算、加人力解决。真正的问题是，有些环节**根本不能让第三方碰到**。碰到的意思是：能看到，或者能改到。

于是归属判断就有一条很简单的判据：**这个部件能不能让第三方看到或改到？** 能，就可以谈采购；不能，就得自己建，无论多麻烦。

本篇讲四件符合这条判据的事。它们有个共同点：都跟“可控”和“可追溯”有关，**跟“智能”无关**。这恰恰是它们容易被忽略的原因：在一份 AI 项目的方案里，它们看起来都不那么“AI”，很容易被归到“以后再说”。

---

## 先看全景：四件事，和一条判据

| 部件 | 能不能外包 | 为什么 | 自建的最小交付 |
|---|---|---|---|
| 沙箱与审批卡点 | 否 | 审批要接内部流程系统，外包方进不来 | 审批卡点接口定义 |
| 权限穿透与审计留痕 | 否 | 授权规则不能绕过 | 身份透传链路设计 |
| 执行日志与回放 | 否 | 要追溯“当时”的版本，不是今天的 | 日志不变量定义 |
| 评测用例与门禁 | 否 | 业务知识买不来 | 门禁配置 |

这张表不是合规清单，是**工程归属清单**。区别在于：合规清单告诉你“要满足什么要求”，工程归属清单告诉你“什么东西必须握在自己手里，以及最小要建到什么程度才够用”。

先说一个官方口径，后面四件事都挂得上。证监会科技监管司在 2026 年 6 月的公开论坛上列过行业面临的四类挑战，其中技术层面点名了**大模型“黑箱”与“幻觉”问题显著**，治理层面点名了**主体权责界定模糊**。

这两个不是我们自己的观察，是监管机构点出来的。本篇讲的第三件事对应前者，第二件对应后者。用官方口径立论，比自己论证有力得多。它说明这四件事不是某个团队的技术洁癖，是行业已经承认的缺口。

---

## 第一件：沙箱与审批卡点

**为什么买不来**

审批卡点要接的是企业内部的流程系统：谁批、批什么、批完之后往哪儿走。这套东西外包方进不来，不是技术不通，是它本身属于内控的一部分。

还有一层：审批规则本身就在变化。业务调整、监管要求更新，规则跟着改。一个外部系统里的审批配置，改一次要走一次变更流程，走几次大家就不走了。

**外包会怎样**

最常见的后果不是审批被绕过，是**审批形同虚设**。Agent 拿到的是一条绕过审批的执行路径，因为外部系统不知道你内部哪一步需要卡。看起来流程走完了，实际上那个卡点从来没生效过。

另一种更隐蔽：审批存在，但审批人看到的上下文不够，只能盖章。这比没有审批更危险，因为它给了你一个“已经审过”的错觉。

**自建的最小交付**

不用建一套完整的审批系统，把卡点定义清楚就够：

```yaml
# approval-gates.yaml
- gate_id: refund-auto-approve
  at_step: tool.execute          # 在哪一步卡：工具执行前
  blocks:
    tool: create_refund_application
    risk_tier: [high, irreversible]
  required_context:              # 审批人必须看到的，缺一项就卡住
    - order_amount
    - refund_history_count
    - applicant_risk_profile
    - model_confidence
    - model_reasoning_summary
  approver_role: 客服主管
  timeout_action: refuse         # 超时按拒绝处理，不按放行
  evidence: 审批记录写入审计日志，含当时上下文快照
```

四行值得单独说。

`required_context` 是最容易被漏掉的。审批人不看到金额、历史、风险画像和模型给的理由，就只能凭感觉批。给它看的东西决定它批的质量。

`timeout_action: refuse` 是个立场问题。超时按放行处理，等于给了系统一条“等下去就能过”的路径；按拒绝处理，出问题才是可预期的。

`evidence` 那行决定了事后能不能复盘。审批记录里要存**当时的上下文快照**，不是只存“某某于某时批准”。

**判据**

这一步的执行结果是否不可逆？不可逆的动作必须有卡点，可逆的可以事后抽检。这条判据也能反着用：如果一个卡点保护的完全是可逆动作，它多半是形式主义。

---

## 第二件：权限穿透与审计留痕

第二篇讲的责任链，回答的是“出错算谁的”；这一件回答的是“控制权在谁手里”。两件事相邻，但不是同一件。责任链可以在流程文件里约定清楚，但如果 Agent 本身拿着一个绕过授权的身份在运行，那份流程文件就是一张废纸。

**为什么买不来**

一句话：**不能因为调用方变成了 Agent，就跳过原有的授权规则**。

一个员工在系统里只能查自己负责的客户数据，这是授权规则。现在他让 Agent 去查，Agent 用的是服务账号，服务账号往往权限更大。于是同一个人，通过 Agent 拿到了他本来拿不到的东西。

这不是假设。权限穿透没做好的时候，这是默认行为，因为 Agent 运行在服务身份下，继承的是服务账号的权限，而不是发起任务那个人的权限。

**外包会怎样**

Agent 拿到的是“超级权限”，出事追溯不到人。审计日志里记的是“服务账号 A 于某时查询了客户 B”，查不到是谁让它查的。这条日志在监管面前没有意义。

国联民生在实践中给过一个稳妥做法：物理隔离做扎实，AI 只用在内部业务环节、绝不直接对接客户端；风控做成完整回路，事前靠合规规则先拦一道，事中卡死人工审核的强制节点，事后做到全链路留痕、每一步都能追溯。

这三段和本系列的三层正好对得上：事前拦是沙箱，事中卡是责任链，事后留痕是这一件和下一件。我引它，是想说明这套结构不是自创的框架，是行业里已经有人在走的路。

**自建的最小交付**

用户身份从发起环节透传到执行环节的链路。核心是一件事：Agent 每次调用工具时，携带的是**发起人的身份**，不是服务账号的身份。

```
用户 U 发起请求
   │
   ├─ 身份绑定：request.principal = U（不是 service account）
   │
   ├─ 透传：Agent 每次 tool call 都带 principal=U
   │
   ├─ 校验：工具侧按 U 的权限做检查，不是按服务账号
   │
   └─ 留痕：审计日志记录 (U, action, resource, decision, reason)
```

校验那一步最容易做得不对。工具侧如果只校验“这个 Agent 有没有权限调我”，等于没校验。Agent 是代理，权限要落在人身上。

**判据**

这条链路能不能追溯到具体的人？拿一条审计记录出来，能不能回答“谁、让它做了什么、它凭什么能做”。有一个答不上来，链路就是断的。

监管口径上也有佐证：持牌投顾机构对 AI 输出要做实质性专业复核并留存独立判断记录，这被视为不可突破的合规底线。能留存“独立判断记录”的前提，就是知道这个判断是谁做的。

---

## 第三件：执行日志与回放

**为什么买不来**

要能追溯“当时”用的模型、工具、Skill 及配置版本。**不能拿今天的配置去猜昨天发生了什么**。

这是最反直觉的一件。大多数人觉得日志系统有什么难的，存下来就是了。难的不是存，是存的东西够不够重建当时的现场。

三个月前那笔出错的交易，用的模型版本是 v3，prompt 是第 12 版，检索的文档集合当月更新过两次，工具列表里有一个工具后来下线了。这些东西如果没记，你现在拿 v5 的模型、第 20 版 prompt 去复现，大概率复现不出来。然后你会得出一个错误的结论：“这个 bug 修好了”。

**外包会怎样**

通用 Agent 基本不提供完整的执行日志，出事只能靠猜。有篇文章里那句话说得很直白：我们看到的就是一个巨大的黑盒。

黑盒的直接后果不是排查慢，是**无法向监管解释**。证监会点名的“黑箱问题显著”，落到具体项目上就是这一条：你能不能说清楚这笔输出是怎么产生的。

**自建的最小交付**

日志不变量定义。我用的这条是从开源 harness 的实现里抄来的，一句话：**模型可见即已记录**。抵达模型请求的一切，都必须能从会话日志重建。

```
每条模型调用必须记录：
  - model_id + version        不只是模型名，是具体版本
  - prompt_template_id + hash prompt 内容变了 hash 就变
  - 检索到的上下文及来源 id    不是"检索了 5 条"，是哪 5 条
  - 可用工具列表及版本         工具会增删，影响模型的选择
  - skill / 配置版本
  - 输入、输出、token 消耗
  - 调用者与会话 id
```

倒数第三条是分水岭。多数日志系统记录了“检索了 5 条文档”，不记录是哪 5 条。前者没法回放，后者才行。

不变量这个词的意思是：**由运行时断言保证，不是靠约定**。写一条断言，任何一次模型调用如果缺了上面任何一项，直接失败。靠人自觉遵守的规范，撑不过三次赶工。

**判据**

能不能从日志完整重建当时的请求？测试方法很直接：拿三个月前的一条记录，按日志里的配置原样重放一遍，看输出是不是一样。一样，说明日志够用；不一样，说明还有东西没记。

---

## 第四件：评测用例与门禁

**为什么买不来**

拿什么案例测、怎样算通过，只有企业自己知道。这是业务知识，不是技术能力。

一个外部厂商能给你一套评测框架、几十个通用指标，甚至能帮你合成几百条样本。但它不知道你们的退款规则里，超过某个额度要双人复核；不知道某个字段为空的时候应该转人工而不是继续；不知道上个月刚出过一次事故，那个场景必须进回归。

这些知识长在业务人员的脑子里，一部分在流程文件里，一部分哪儿都没写。

**外包会怎样**

买到的是通用评测，测不出你的业务错误。分数很漂亮，因为通用指标测的是通用能力，比如流畅度、相关性、有没有明显事实错误。你的业务错误往往不在这些维度上：它可能很流畅、很相关、也没有事实错误，但违反了你们内部的一条规则。

**自建的最小交付**

门禁配置，回答一个问题：什么指标不过就不许上线。

```yaml
# quality-gate.yaml
blocking:                        # 不过就阻断发布
  - regression_pass_rate >= 100%   # 历史 bad case 必须全过
  - replay_bucket_pass_rate >= 100%
  - safety_redteam_pass_rate >= 100%
warning:                         # 告警但不阻断，人工判断
  - overall_pass_rate >= baseline - 2%
  - latency_p95 <= baseline * 1.2
  - cost_per_call <= baseline * 1.3
on_block:
  - 保留本次评测的完整输入与输出，供复盘
  - 通知评测集维护人：可能有用例已过期
```

`regression_pass_rate >= 100%` 这一条是硬门槛，不能设成 95%。历史犯过的错，再犯一次就是 100% 不可接受，没有商量余地。

`warning` 那一组要看趋势不看单次。单次波动可能是噪声，连续三次同向变化才是信号。

`on_block` 里第二行容易被忽略：阻断发布的时候，除了通知开发，还要通知评测集的维护人。阻断的原因可能是用例过期了，不是系统变差了。这两件事的处理完全相反，却经常被混为一谈。

**判据**

这个用例错了，业务上会出什么事？答不上来的用例，说明它测的东西不对应真实风险，可以删。评测集不是越大越好，是每条都能对应到一个真实后果。

这一条也能反过来当产品化的判据用。我之前把研发交付拆成七个智能体角色（PM、业务分析师、方案设计师、方案评审员、开发工程师、代码审查员、测试工程师），判断它算不算可复用资产，用的就是这条：换个场景，这些角色的职责描述和质检规则还成立吗？成立，它是资产；不成立，它只是那个项目里的一次性设计。

---

## 归属判定表，与系列的收口

四件事的判断标准归成一张表，可以直接拿去用：

| 问自己 | 答案 | 归属 |
|---|---|---|
| 第三方能不能看到这个部件里的数据？ | 能 | 可采购 |
| 第三方能不能改到这个部件的配置？ | 能 | 可采购 |
| 这个部件的规则是不是内控的一部分？ | 是 | 必须自建 |
| 出事时，能不能追溯到具体的人？ | 不能（若外包） | 必须自建 |
| 这条用例错了，业务上会出什么事？ | 只有内部知道 | 必须自建 |

前两问决定是否可采购，后三问决定最小要自建到什么程度。

**对技术选型的影响**，顺便说一句：这也是开源 harness 框架不能直接上的原因之一。主流实现是 TypeScript 或 Rust 技术栈，嵌不进 Java 存量系统；可观测性那块是空的，正好落在第三件事上；评测用例买不来，落在第四件。这三个理由单独拿出来都不算强，合起来就构成了“基建可以借，这四件事借不走”的结论。

最后一句，是我觉得整个系列里最该记住的：**技术上的执行成功，不等于业务结果正确**。所有工具都返回成功，退款申请也确实创建了，但金额可能不对。前面四件事防的都是这一类：每一步都“成功了”，结果却是错的。

---

三篇收个尾。

篇一讲路径：一个 AI 工具要爬过四道坎，大多数项目死在第二道和第三道之间。

篇二讲方法：第二道坎要补的三样东西（评测集、兜底层、责任链）各自的最小可交付物和代价。

本篇讲底线：有四类工程部件，无论多麻烦都得自己建，判据是能不能让第三方看到或改到。

路径、方法、底线。三样合起来，AI 才可能在企业里活下来，不是跑通一次，而是长期活着，并且能被复制。


甲方 FDE 手记 ③｜底线 系列主线：AI 落地不是交付一个系统，是建立一套让 AI 能活下来的机制。本篇讲这套机制的底线层。

甲方内部 FDE（三）：金融行业买不来的四件事

金融行业做 AI，能买的是模型调用，买不来的是控制权。这篇讲四类只能自己建的部件：沙箱与审批卡点、权限穿透与审计留痕、执行日志与回放、评测用例与门禁。判据只有一条：能不能让第三方看到或改到。证监会科技监管司 2026 年 6 月公开点过名，技术层面是模型黑箱与幻觉，治理层面是主体权责界定模糊，这四件事正对着这两个缺口。文末一张归属判定表，五个问题决定该买还是该建。

人工智能

后端

架构设计

AI落地金融行业底线：四类部件必须自建，判据是能否让第三方看到或改动。沙箱审批卡点、权限穿透审计、执行日志回放、评测门禁，对应监管点名的黑箱与权责问题。最小交付方案+工程归属清单，确保控制权与可追溯性，防止“每一步都成功但结果错误”。

代码解释

TypeScript 

智能体

Agent

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

甲方内部 FDE（三）：金融行业买不来的四件事-腾讯云开发者社区-腾讯云

甲方内部 FDE（三）：金融行业买不来的四件事

甲方内部 FDE（三）：金融行业买不来的四件事

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐