8.0
热点
AI SCORE
技术实践2026-10-12 12:39
金融 Agent 的授权边界该如何设计
dev.to · AI#Agent#金融科技#权限控制
Editor brief · 编辑速览
文章在金融执行链路中加入策略与授权层，强调模型推理不能成为最终授权依据。以限额代缴账单为例，将自然语言要求转成包含支付类型、账单对象、金额上限和币种的结构化意图。
AI-native FinTech 改变的不只是用户界面。
它还改变了我们思考权限、执行和财务事实的方式。
传统支付流程相对直接：
User
↓
Mobile App
↓
API
↓
Financial Service
↓
Payment Rail
引入自主 Agent 后，流程中就多了一层决策：
Customer Intent
↓
Agent Reasoning
↓
Policy / Authorization
↓
Financial Services
↓
Payment Rail
架构上的关键问题不再仅仅是：
代表客户行事的软件，究竟被允许做什么？
AI Agent 可以理解含糊的指令、收集信息、选择工具、重试操作，并协调多个服务。
这种灵活性很有用。
但金融系统不能让概率性的推理成为最终的权限依据。
来看这样一条客户指令：
如果宽带账单每月都低于 ₹1,500，就帮我支付。
这并不是一条直接的支付命令。
它包含多个约束，需要先转化为结构化的金融意图：
{
"intentType": "PAY_BILL",
"billerId": "ISP_291",
"maximumAmountMinor": 150000,
"currency": "INR"
}
Agent 可以帮助理解这条指令。
但支付系统应该执行的是结构化契约，而不是原始的自然语言句子。
这条边界带来了一条实用的架构原则：
推理可以是概率性的，金融执行应当保持确定性。
客户可能已经成功完成身份认证，但这并不意味着 Agent 应当自动获得客户拥有的全部权限。
平台可以创建一份有明确边界的委托授权，而不是把宽泛的账户权限交给 Agent：
action: PAY_BILL
biller: ISP_291
maxAmount: 150000
expiresAt: ...
具体实现可以采用 scopes、服务端授权记录、capability tokens、mandates，或其他授权模型。
原则都是一样的：
只授予 Agent 完成特定任务所必需的权限。
Agent 可能拥有一项已经获批的能力，例如：
executePayment()
这并不意味着每次调用都应该执行。
某个具体请求仍然可能违反：
Agent 能否请求这类操作？
策略层仍然必须回答：
这一次具体操作，现在能否执行？
假设 Agent 提交了一笔支付。
支付处理机构收到了请求，并完成了支付，但网络响应丢失了。
TimeoutException
一种合理的软件处理思路可能是：
No response != No payment
如果重试会创建一笔新交易，那么一次普通的分布式系统超时，就会变成重复支付问题。
更安全的做法是创建一个稳定的操作 ID，并查询已有支付的状态。
P7123
PROCESSING
↓
UNKNOWN
↓
RECONCILED
↓
SUCCEEDED / FAILED
保留不确定状态，比错误地宣告失败更好。
我已经支付了你的宽带账单。
这句话属于对话状态。
它不是会计凭证。
权威结果应当来自金融平台：
Agent requests payment
↓
Payment service creates operation
↓
Processor invoked
↓
Provider result / event received
↓
Authoritative transaction state advances
↓
Agent reads final state
这个方向很重要。
财务状态为 Agent 提供事实依据。
Agent 不应仅仅因为模型相信某件事已经发生，就告诉金融系统它已经发生了。
一个实用的 AI-native FinTech 技术栈，可以通过几道边界划分职责：
Mobile / Web Client
↓
Identity + Device Signals
↓
Intent Service
↓
Agent Runtime
↓
Policy & Authorization Engine
↓
Capability Gateway
↓
Financial Domain Services
↓
Payment Orchestrator
↓
Ledger / Authoritative State
↓
Banks / Networks / Payment Rails
有几条原则尤其重要。
在执行金融操作之前，将自然语言请求转换为结构化意图。
将必须强制执行的金融规则放在 prompt 之外。
授予 Agent 范围明确且有限的能力，而不是不受限制的服务访问权限。
在执行会产生实质影响的操作之前，立即重新验证授权。
对于重试敏感的状态变更操作，使用稳定的操作标识符和幂等机制。
明确表示待处理和结果不确定的状态。
将对话状态与权威财务状态分开。
将对账设计为支付流程的一部分，而不是事后补上的环节。
关联客户、设备、Agent、策略和支付的身份标识，以支持审计追溯。
AI 工作流不应成为整个金融平台的同步机制。
许多重要的支付结果都是异步产生的：
因此，支付平台可能产生以下事件：
PaymentRequested
PaymentAuthorized
PaymentSubmitted
PaymentSucceeded
PaymentFailed
PaymentReversed
SettlementCompleted
但异步架构也会引入自身的故障模式。
消息可能被投递多次。
消费者可能崩溃并重试。
数据库写入可能成功，而事件发布失败。
消息顺序可能与预期不同。
transactional outbox 等模式可以帮助协调本地状态变更与事件发布，但消费者仍然应该能够容忍重复投递。
涉及资金时，假设消息能够恰好处理一次是危险的。
再来看客户的这条指令：
如果宽带账单每月都保持在 ₹1,500 以下，就帮我支付。
平台保存一份有明确边界的委托授权。
之后，一张金额为 ₹1,249 的账单到达。
Agent 准备支付。
执行之前，确定性系统会验证：
支付编排器创建支付操作 P7123。
支付服务提供方处理了交易，但响应超时。
薄弱的实现会创建另一笔支付。
更可靠的实现会询问：
What is the state of P7123?
交易仍处于 PROCESSING 状态。
之后，支付服务提供方报告成功。
权威财务状态转为 SUCCEEDED。
只有到这时，Agent 才会告诉客户支付已经完成。
Agent 并没有自行判定资金已经转移。
它观察到了支付平台产生的财务状态。
这个区别至关重要。
AI Agent 可以减少金融工作流中的操作阻力。
它们可以理解意图、协调服务、提供个性化体验，并自动完成过去需要切换多个页面、执行多次手动操作才能做出的决策。
但更高的自主性，需要底层更强的基础设施：
架构不应变成：
Mobile App
↓
AI Agent
↓
Payment API
更安全的方向是：
Customer Intent
↓
Bounded Delegation
↓
Agent Reasoning
↓
Deterministic Policy
↓
Controlled Capability
↓
Financial State Machine
↓
Authoritative Financial State
界面可以变成对话式。
编排可以变得智能。
客户可以减少需要明确执行的操作。
但软件越接近自主完成资金转移，平台就越需要精确定义：推理在哪里结束，金融权限从哪里开始。
想进一步了解架构拆解、实现考量、故障场景，以及完整的推导过程吗？
在 Medium 阅读完整文章
#FinTechArchitecture #AgenticAI #PaymentSystems #SoftwareArchitecture
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。