最近跟不少银行科技部的同事讨论一个很有趣的命题“在内部用Claude Code写辅助代码效果很不错。那能不能把这套模式直接搬到供应商付款审批、或者贷后风控上让一个通用的Agent去跑财务、风控、客服这些业务链路”我的答案是“能跑起来但大概率跑不稳甚至可能跑出风险。”这并不是因为模型不够聪明而是因为代码Agent和业务Agent虽然都叫“Agent”但它们要解决的根本不是同一类问题。一、仓库代码 vs 组织网络在代码仓库里无往不利的Agent一进银行核心业务就“水土不服”代码Agent如Claude Code面对的是一个高度结构化的“静态仓库”。这里有明确的语法规则、可以无限次回滚的版本控制、以及自动化的单元测试。错了没事回退重来成本极低。业务Agent如付款审批面对的是一个正在运转的“动态组织网络”。一笔付款单一旦进入流程它关联着供应商的账期、财务的做账节点、风控的合规校验。不能重来、不能试错、每一步都必须有明确的责任人。这个本质差异决定了两者的工程化路径截然不同。业务Agent 工作环境动态组织网络流程/权限约束不可逆/需留痕人工复核兜底代码Agent 工作环境结构化代码仓库语法/规范约束支持回滚/分支自动化测试验证二、AGENTS.md解读开发者圈最近在热议要不要维护好AGENTS.md这个文件给代码Agent提供了“项目怎么构建”、“哪些文件不能碰”等仓库上下文。这个逻辑放到银行里完全成立只是“资产”变了。银行业务Agent极度依赖流程上下文Process Context付款申请是从ERP进来还是从财资系统进来10万以下走简易流程100万以上是否需要CFO甚至资金调度会签哪些供应商如新成立、或有过风险预警的必须额外触发风控校验节点卡住超过2小时需不需要自动转人工催办核心洞察模型参数里存储的是“通识”但它绝对记不住贵行《供应商付款管理办法》第三条第2款的例外情况。这类知识不在参数里而在制度文件和老员工的经验里。没人替Agent写清楚它就永远是个“不懂规矩”的新人。三、别被Demo骗了银行业务需要“重Loop工程”全球AI圈都在卷“Loop工程”让Agent自己计划、执行、监工、返工而不是简单的“一问一答”。在银行场景下我们不能讲“Loop”这种极客词汇要翻译成业务听得懂的**“业务闭环”。一个真正能进生产的银行业务闭环必须包含以下五步**缺一不可计划Plan解读工单意图拆解成具体任务清单。执行Do调用API查余额、调RPA抓取流水、或生成审核意见。监控Check每一步执行后核对返回结果是否符合预期如额度超限了吗。异常返工Action/Adjust报错或风控拦截时Agent要能自动降级换接口或转人工。复盘Review任务结束后记录日志供后续模型微调或审计追溯。少了任何一步Agent就只是个“更能聊天的机器人”而不是一个“能干活的合规员工”。数据异常/超限符合预期接收付款/风控任务计划阶段拆解意图 调取制度规则执行阶段API调用 / RPA抓数 / 规则匹配监控阶段执行结果校验异常返工自动补偿或转人工介入任务完成 留痕复盘阶段写入审计日志 经验库结束四、架构选型为什么单一“超级Agent”扛不住业务链路在真实的银行信贷审批或付款流程中单一Agent几乎不可能完美扛住一整条链路。比较成熟的落地做法是Supervisor-Worker监督者-工作者分层架构上层Supervisor负责意图识别和任务拆解比如判断这是“加急付款”还是“常规对公”。下层Worker负责调用具体的工具和系统A Worker查风控名单B Worker抓取应付账款账龄C Worker填制支付指令。复杂业务不再靠一个大模型“硬扛”到底而是靠角色分工和流程编排。这一点恰恰是很多银行在技术选型时容易忽略的——他们往往只看“这个模型大不大”而忽略了“这个系统好不好管”。五、银行业务Agent落地的“四条红线”判断涉及资金与数据变更不能只靠推理涉及资金流转、核心系统写入或客户敏感数据变更的场景Agent绝对不能单凭模型推理“拍板”。必须绑定显式的审批链路和操作留痕。在这里出错不是一个Bug而是一次操作风险Operational Risk事件。接口不统一必须“APIRPA”两条腿走路银行有大量存量系统和外包系统甚至只有客户端界面。业务Agent必须同时具备API集成处理标准接口和RPA执行处理“非人类友好”的遗留系统界面能力以及顶层的流程编排能力。选型标准要从“够不够聪明”转向“三可原则”进入强合规生产环境选型标准排序变了动作可不可控不能乱动数据、过程可不可审每一步都有日志、出错能不能退回去原子性回滚。别推倒重来要“长”在现有数字员工资产上很多银行已经有大量RPA机器人数字员工。新的AI Agent更适合作为“大脑”去调度这些现成的“手脚”RPA组件而不是推倒重来做一个通用的聊天入口。六、企业级AI Agent平台怎么选银行必看的6个硬指标真正决定业务Agent能不能上银行生产环境的从来不是会不会写代码而是下面这6项工程化能力序号关键指标银行关注的核心要点1权限继承与治理能不能继承AD/LDAP目录服务和组织架构Agent必须带着“经办人”的身份去干活绝不能成为一个权限过大的超级账号。2流程引擎编排能否图形化拖拽编排多步骤流程支不支持会签、或签、加签、转办等复杂人工节点3可观测性观测能不能提供完整的“链路追踪”Trace让我知道这笔拒绝付款的原因是哪条规则命中了4断点续作与补偿接口超时或系统宕机后Agent能否自动重试或执行逆向补偿冲正操作5数据隔离与合规训练数据和业务数据是否物理/逻辑隔离能否满足等保和监管数据驻留要求6资产复用能力能否无缝调用现有的RPA脚本、Excel宏模板或Python核算脚本七、国内银行流程自动化的三条演进路线企业级业务Agent的建设不会只有一种路线模型平台路线云厂商/大模型厂优势在于基座模型强、工具调用生态好适合搭建全行统一的“AI能力底座”。业务系统路线ERP/核心厂商优势在于贴近财务、人力等既有业务数据适合在系统内部做“智能增强”如智能助手。企业级流程自动化路线RPAAI厂商代表如金智维、来也科技等。它们的优势在于长期处理跨系统操作、流程编排、权限隔离和执行留痕这恰恰补上了大模型落地银行业的“最后一公里”。以金智维为例它更合适作为金融、政务这类强流程、强合规场景的候选方案之一。在这类场景里银行关注的往往不只是“Agent能不能懂业务”还包括“能不能跨系统调度20个RPA机器人”、“出了问题能不能查得到秒级日志”——这类能力正是业务Agent与代码Agent的工程分界线。八、FAQsQ1已经在用Claude Code写辅助代码了还需要单独建业务Agent吗A需要分场景看。代码Agent适合研发效能提升代码审查、测试生成业务Agent适合财务审核、风控处理。两者在银行科技体系内可以并存但绝对不能互相替代——术业有专攻。Q2银行做业务Agent应该先选大场景还是小场景A强烈建议先选高频、规则相对清晰、人工复核容易介入、收益可量化的流程。比如报销单据初审、对账辅助、合同要素核验。第一批场景不一定最大但一定要跑得稳、算得清节省了多少“人日”。Q3怎么判断试点值不值得继续投入A不要看演示效果要看四类硬指标①人工耗时是否下降②处理周期是否缩短③因疏忽导致的错误率是否降低④异常情况如报错能否被完整追踪到具体环节。Q4RPAAI这类厂商到底适合什么样的银行A最适合流程重、系统多、合规要求极高、且已有自动化基础的银行尤其是国有行、股份行。这类银行更关心执行稳定性和权限隔离而不只是模型问答溜不溜。真正决定一个业务Agent能不能上银行生产环境的一定不是模型参数有多大而是它有没有被套进一套看得见、管得住、退得回去的流程铠甲里。
)
