金融智能体最麻烦的一步，不是读懂一张现金流量表，而是按它的判断真的把钱转出去。
这条界线过去很清楚。模型可以查余额、归类流水、预测头寸、提出换汇建议；到了付款、修改收款人、调拨资金时，系统把操作交回给人。Ant International 在 2026 年 9 月公布全栈 AI-native 金融方案，并提出 Account for Agent（AFA），值得关注的地方正是它试图跨过这条线：给智能体一个受约束、可追踪的交易身份，让它能在授权范围内执行金融动作。
“给 Agent 开户”容易让人联想到新增一种普通账户。实际要解决的远比账户 UI 复杂。金融系统必须回答六个问题：谁在行动，代表谁行动，依据什么授权，可以动哪些资产，单次和累计能动多少，出事后怎样还原决策过程。缺一项，智能体就只能停留在辅助工具；答得含糊，它又会变成权限很大的共享机器人账号。
一、先把 Agent 当成独立执行主体
企业常见的自动化集成有两种身份：共用服务账号，或者借用操作人员的 OAuth Token。两种方式用在确定性脚本上尚可，用在能自主拆解任务、选择工具和调整步骤的 Agent 上风险很大。
共用账号无法区分是哪一个 Agent 实例发起操作，也很难判断动作来自预定流程还是模型临时规划。借用员工身份则把“员工本人操作”和“Agent 代员工操作”混在同一条日志里。员工离职、转岗或 Token 泄漏后，授权关系也容易残留。
AFA 更合理的实现应当是一个独立主体对象，而不是用户名换成“Agent”。这个对象至少关联以下信息：
- 唯一主体 ID，以及创建、停用和版本变更记录；
- 所属企业、业务部门、责任人和技术维护人；
- 被允许使用的模型、工具、工作流版本；
- 可代理的自然人或岗位，以及代理关系的有效期；
- 可访问的账户、币种、法人实体和地域；
- 风险等级、审批策略和紧急停止状态。
一次付款日志中应同时出现四个身份：企业主体、授权人、Agent 主体、实际执行的模型或工作流版本。这样才能区分“财务经理批准了目标”与“Agent 选择了具体路径”。责任不能粗暴地全推给授权人，也不能落在一个无法承担法律责任的模型名称上。
二、权限要描述业务动作，不能只描述 API
传统 IAM 往往授予 read:account、write:payment 一类接口权限。对 Agent 来说，write:payment 太宽。模型可能正确调用接口，却在错误的业务条件下调用它。
金融智能体的权限应拆成“资源、动作、条件、目的”四部分。例如：
允许 Treasury-Rebalance-Agent 在工作日 9:00—17:00，从新加坡法人名下的运营账户向同法人资金池调拨美元；单笔不超过 5 万美元，每日累计不超过 20 万美元；用途仅限流动性再平衡；不得新增收款账户。
这比“允许调用转账 API”多了法人、账户关系、币种、时间窗、额度、用途和收款人约束。执行时由策略引擎做确定性判断，不让大模型自己解释规则。
权限还应按动作风险拆级。查余额和读取历史流水可以自动放行；生成付款草稿可允许较宽范围；提交既有白名单收款人的小额付款可以自动执行；新增收款人、跨法人调拨、大额换汇和修改审批规则则必须转人工。这里没有必要追求一套统一分级，企业应按资金损失、可逆性和监管影响定级。
一个常被忽略的问题是“权限组合”。某个 Agent 单独拥有读邮箱权限看起来低风险，拥有创建收款人草稿也不算高风险；两项合起来，它可能从伪造邮件中抽取账户并创建付款对象。授权评审不能逐个 Connector 看，要检查组合后是否形成完整攻击路径。
三、额度不是一个数字，而是一组动态预算
人类银行卡常用单笔限额和日累计限额。Agent 的执行速度更快，同一故障可以在几分钟内复制到数百笔交易，因此需要更细的风险预算。
第一层是静态硬限制，包括单笔、小时、日、月额度，付款笔数，允许币种及最大敞口。硬限制由账务或支付网关执行，Agent 无权绕过。
第二层是关系限制。首次收款人、近期修改过银行信息的收款人、跨境账户、高风险地区账户应适用更低额度，甚至强制复核。相反，长期稳定的内部资金池可以获得较高自动化额度。
第三层是行为限制。即使每笔都低于上限，如果短时间内付款频率突然升高、金额刻意贴近阈值、交易时间偏离历史习惯，也应暂停执行。异常检测不能只观察单笔，要比较该 Agent、该业务和该收款人的历史基线。
第四层是任务预算。用户下达“把未来三天的美元缺口补齐”时，系统应先生成本次任务的总预算和允许动作，再发放一次性、短时有效的能力凭证。任务结束后凭证失效。这样可以避免一个长期 Token 在目标完成后继续拥有资金权限。
动态额度可以参考账户余额、预测现金流和风险评分，但最终阈值应由确定性服务计算。模型可以提出调整建议，不能自行提高自己的额度。
四、人机复核要放在不可逆动作之前
“所有操作都让人确认”看似安全，实际很快会产生确认疲劳。每天几百次弹窗之后，审批人只会机械点击。有效的 Human-in-the-loop 应该把人放在少数高风险节点，并提供足够上下文。
一条待审批记录至少要说明：Agent 收到的业务目标、拟执行动作、金额和账户、选择该动作的依据、使用的数据时间点、命中的风险规则、替代方案，以及不执行的后果。只显示“是否批准 50,000 美元付款”没有意义。
审批也不应只有批准和拒绝。财务人员需要能够降低金额、缩短有效期、改成分批执行、要求补充凭证，或把收款人加入临时白名单。所有修改都要形成新版本，不能覆盖原始建议。
对于大额或敏感动作，可以采用双人复核，但两名审批人应来自不同职责域。例如业务负责人确认商业目的，财务或风控确认资金和合规条件。Agent 不应能选择审批人，更不能通过发送消息诱导审批流程走捷径。
五、审计日志必须能重放，而不只是“记过一次”
普通应用日志记录请求时间、接口和返回码。金融 Agent 的审计需要回答“为什么会发生”。这要求保存一条从意图到结算结果的证据链：
- 用户或上游系统提交的原始任务，以及身份验证结果；
- 当时有效的授权策略、额度和模型/工作流版本；
- Agent 使用的数据来源、查询时间与数据摘要；
- 规划出的步骤、工具调用参数及每次返回结果；
- 风险引擎命中的规则、人工审批意见和修改；
- 支付网关受理、清算、失败、撤销或退款状态；
- 任务最终结果，以及未完成事项。
考虑到提示词和工具返回值可能包含账户、合同和个人信息，审计系统不能把所有原文无限期保存。更可行的做法是对关键输入生成不可篡改摘要，对敏感字段加密或令牌化，把访问审计日志本身也纳入权限控制。监管或争议处理需要原文时，再走受控解密流程。
“可重放”也不等于重新执行真实付款。平台应提供沙箱重放：使用当时的数据快照、策略版本和模型版本，复现 Agent 的决策轨迹，同时把有副作用的工具替换成模拟器。若模型具有随机性，应保存推理配置和输出，而不是指望事后生成完全相同的内容。
六、把失败方式预先写进系统
金融 Agent 不可能只在模型判断错误时失败。接口超时可能导致重复扣款；汇率报价过期可能使预期收益消失；上游 ERP 数据延迟会造成错误头寸；审批人在 Agent 等待期间可能修改任务；连接器被劫持后还会返回伪造成功状态。
因此每个动作都要有幂等键、超时策略、状态机和补偿方案。付款提交后网络中断，系统应查询原交易状态，而不是再次提交。外汇成交前应重新校验报价有效期和滑点。多步骤资金调拨必须明确哪个阶段可撤销，哪个阶段只能通过反向交易补偿。
紧急停止也要分层。企业需要能暂停一个 Agent、一个工作流、一个 Connector 或某类交易，而不是只能关闭整个系统。停机后，已受理但未结算的交易要进入人工队列；未使用的临时凭证立即吊销；相关责任人收到结构化事件报告。
上线前的测试重点不是让 Agent 回答几组财务问题，而是做破坏性演练：伪造供应商改户邮件、重复回调、部分接口失败、金额拆分规避阈值、跨时区截止日期、权限在任务中途被撤销。红队应尝试诱导 Agent 调用合法工具完成非法组合，而不只测试敏感词拦截。
七、一个可落地的系统分层
企业可以把 AFA 类能力拆成五层。最外层是任务入口，验证发起人身份并把自然语言目标转成结构化任务；第二层是 Agent 编排，只负责规划和调用工具；第三层是策略决策点，依据主体、资源、动作和上下文给出允许、拒绝或需审批；第四层是交易执行网关，落实额度、幂等、签名和状态机；第五层是独立审计与事件响应系统。
这五层里，大模型只应位于编排层。身份判断、策略计算、金额校验、签名和账务状态都应由传统可验证组件完成。一个简单判断标准是：凡是会直接改变资金所有权或授权边界的条件，都不该由自然语言推理单独决定。
Account for Agent 真正有价值的地方，不是让企业多开一种账户，而是迫使金融系统承认 Agent 已经成了新的执行主体。给它独立身份、窄权限、短凭证、分层额度和可重放审计，自动执行才有现实基础。否则所谓“金融 Autopilot”，只是把共享账号、长期密钥和不可解释脚本包装成了聊天界面。