Hi

一次对公开户材料预审，看起来很适合交给AI。

材料多、规则细、重复核对占用人力，模型可以识别证照、抽取字段，也能指出缺项。可当结果要写入业务系统，甚至进入正式审核环节，项目面对的就不再只是识别准不准。

谁有权发起任务？智能体可以读取哪些材料？哪些规则版本有效？哪一步需要客户经理确认？判断依据和操作记录能否还原？这些问题答不清，AI很容易停在演示环境里。

金融监管总局2026年6月发布的银行业保险业人工智能安全开发应用指导意见，要求金融机构建立覆盖需求分析、数据准备、训练开发、部署运行、维护迭代、评估退出的全生命周期管理体系，并加强应用场景和业务流程管理
对银行科技团队来说，AI项目的衡量标准正在增加：除了模型效果，还要看它能否在组织制度和业务系统内被管理。
“会回答”和“能办事”之间，隔着四个运行条件

仍以开户材料预审为例。
识别营业执照、抽取企业名称、核对字段、提示缺失材料、生成补充清单、写入开户系统，看似是一条流程，风险等级并不相同。
识别和整理通常属于辅助动作；写入系统、发起流程、对外发送则会改变业务状态。银行需要按动作划分权限，明确只读、生成草稿、等待确认、正式提交等层级。智能体使用的权限也应对应任务需要，不宜直接继承员工的全部权限。
中央网信办发布的智能体规范应用意见提出，要厘清仅限用户本人决策、需用户授权决策和智能体自主决策的边界，且智能体执行操作不得超出用户授权范围。该意见为业务设计提供了一个朴素原则：先确定动作等级，再决定AI能走到哪一步。
业务规则要成为受管理的能力资产
银行场景很少只靠一段提示词运行，开户材料清单会调整，信贷审查口径有版本，客户经营规则还涉及适当性、名单和渠道约束。规则若散落在个人提示词、临时脚本或各自维护的知识库里，业务部门很难确认当前使用的是哪一版。
更适合组织使用的方式，是把SOP、字段规则、核验步骤封装成可复用的Skills，由指定人员维护、审核和发布。规则变更时留下版本记录；试运行没有达到预期时，可以停止分发或回到已确认版本。
这样做的价值不在于多建一个“技能市场”，而在于把业务经验从个人用法转成机构可管理的能力。客户经理、运营人员和审查人员调用的是同一套已审核规则，技术团队也能知道某项业务能力依赖哪些接口、知识和模型。
高风险节点要保留人工确认
银行业务中，模型给出意见和系统提交结果不是一回事。
开户材料缺项提示可以由AI生成，是否接受补充材料，需要业务人员判断。资产配置可以整理客户信息和生成分析草稿；面向客户的正式意见，还要经过适当性与内部流程。信贷合同可以标记疑似风险条款，最终审查结论仍应由有权人员确认。
人工确认不是自动化不足的表现，它把责任边界嵌入流程，也给员工保留核对依据的机会。
日志要能回答业务和审计问题
智能体进入业务流程后，一条“任务成功”的记录远远不够。
银行需要还原：谁在什么时间发起任务，智能体使用了哪个角色和哪一版Skill，读取了哪些授权数据，调用了什么工具，在哪一步等待人工确认，结果是否写入系统，异常发生后如何终止或回退。
全国网安标委2026年7月发布的智能体部署使用安全指引，将风险防范覆盖到评估、准备、部署、使用和停用阶段。
因此，日志不仅服务于事后追责，也用于日常运营。业务团队可据此发现规则缺口，安全团队可以复查越权和异常调用，科技团队则能评估资源消耗、失败环节和版本影响。
FinClaw在银行方案中承担什么角色

FinClaw的定位是企业级自主Agent中台，放到银行场景里，更适合承接智能体的组织、能力和运行治理，避免每个部门各自搭建一套难以维护的工具。
企业Skills Hub可把SOP、专家经验和行业规则整理为受管理的技能，配置审核、灰度发布、版本迭代和回退。
FinFlow、MCP Server与MCP-UI用于连接已经授权的接口、表单和流程，让员工在对话中查看结果、修改信息并完成确认。多租户、组织身份、工具策略、执行日志和模型用量管理，则为不同部门、角色和任务提供统一的管理入口。
这些能力如何组合，需要结合银行现有的身份权限体系、核心及外围系统、数据分级制度和项目目标确定。具体接入范围、运行环境、安全策略和验收指标，应以当前产品版本及试点验证为准。
先选一个边界清楚的场景
银行不必一开始就把营销、信贷、运营和运维全部纳入同一项目，选择一个高频、结果可复核、系统影响范围清楚的任务更为稳妥。
对公开户材料预审、内部对账差异整理、经营日报生成、运维告警归因，都可以用来验证四件事：动作能否分级，规则能否管理，人工确认点是否合理，过程能否完整留痕。
当这四项在真实环境里跑通，银行再讨论扩大数据范围、开放更多工具或增加自动执行比例，会有更可靠的依据。
若贵行正在评估智能体场景，凡泰极客可围绕“业务动作—数据权限—人工确认—审计证据”协助梳理试点边界，再据此核对FinClaw的产品与交付范围。