当 AI 说＂任务完成＂,为什么银行还是不敢签字?

当 AI 说"任务完成"，为什么银行还是不敢签字？

能力越来越便宜，托付却越来越贵 —— 一个金融行业一线的观察笔记

前几天有同行问我：银行客户现在选 AI 方案，最看重什么指标？我想了想说，不是指标。是他们内部，没人愿意在验收单上签那个字。

这句话我琢磨了很久。我们讨论 AI 的进步，习惯看"能不能做到"；但金融行业真正的门槛，从来是"敢不敢用"。这两件事之间，隔着的不是模型参数，而是一整套工程、制度和责任安排。

BestBlogs 周刊第 112 期的主题是"可托付的智能"（Intelligence You Can Trust to Deliver），读完很有共鸣，也补上了我不少碎片化的感受。下面是我结合一线观察写的一份笔记，观点都在，事实也都标了出处。

一、换个问法：不是"AI 能不能做"，而是"出事谁负责"

互联网团队评估一个 Agent，最关心的是成功率。金融行业不这么看。我们看的是另一句话：如果它错了，谁来兜、能不能发现、能不能退回来。

这两者的差别，不是保守与否，而是失败的性质不同。一个推荐算法推错了商品，代价是转化率；一个流程自动化错了指令，代价可能是客户资金、监管处罚和一家分行的全年考核。所以"能不能做到"和"敢不敢用"之间，差的从来不是最后那 5% 的准确率。

那什么才算"可托付"？周刊里的定义我很认同：它更像一份动态合同 —— 系统知道目标是什么，能访问完成目标所需的事实与工具；行动范围与风险相匹配；结果有独立证据；失败时能停下、恢复或交回给人。最后，有人知道自己为什么接受这个结果，也愿意为后果负责。

看到这段定义的时候我心里一动：这不就是银行内控那套东西吗？职责分离、双人复核、留痕可溯、异常上收 —— 过去二十年，银行用制度解决的核心问题就是"如何托付"。我们现在做的，只是把这套制度翻译成工程语言：复核岗变成独立评估者，"双人复核"变成 rubric 加干净上下文的二次校验，"留痕"变成证据链，"异常上收"变成失败时的停止与交回。

这个视角有个很实际的推论：金融行业做 AI，不需要发明新方法论。把内控的语言系统性地翻译一遍，很多设计问题会立刻有答案。反过来，凡是没法用内控语言解释的 AI 设计，在银行大概率推不动。

而现实中最常见的卡点，恰恰是最后一环 —— 责任。技术上跑通不代表有人敢签字。我在评审会上听过最真实的一句话是："这个结果我认可，但我不能签，因为出了事我不知道是模型的问题还是数据的问题。"归因链断了，责任就没法落地。这也解释了为什么"可观测性"这类看起来很工程师的活，在银行反而是最先被保障预算的。

二、成本账要重算：从"每个 token 多少钱"到"每个合格结果多少钱"

先说一个供给侧的事实。DeepSeek 发布 V4.1 Flash，采用 552B MoE，处理输入时激活 8B 参数，生成输出时激活 16B 参数；新的非对称 Causal-Encoder-Decoder 架构不要求输入与输出承担相同的计算结构。相比上一代，它的 KV Cache 对 HBM 的需求降到 1/4，对 SSD 存储的需求降到 1/8，闲时 API 价格是高峰的一半。

这组数字和 Agent 有什么关系？因为长程任务不是"生成一次答案"，而是反复读取上下文、调用工具、写回观察、继续规划。上下文越长，缓存越大，解析和存储就越容易变成持续成本。所以这次降价的真正含义不是"每个 token 又便宜了一点"，而是长上下文任务的基础设施负担被重算了。

这一点对金融行业特别关键，因为银行的 AI 负载结构和互联网很不一样。互联网的负载大量是短对话、高并发、可容忍偶发错误；银行的负载往往是另一副样子 —— 长文档、大批量、强复核。一份授信材料几十上百页，一次批量任务几千条，每条结果后面还跟着一个人核对。这种负载对"长上下文成本"的敏感度，比 C 端场景高一个量级。

也正因如此，我判断：模型路由在金融行业不是省钱技巧，而是风险分级手段。周刊里给了几组企业侧的实测数字：Uber 通过开放权重模型、提示词缓存、更便宜的子 Agent 和自动 token 压缩，把单请求成本降了 34%、单会话成本降了 52%；Pinterest 报告开放模型的单次交易成本低于可比闭源模型的 8%；AT&T 在部分任务上节省最高 56%，同时质量下降约 2%。这些数字来自不同公司、不同任务、不同口径，不能横向拉榜，但它们共同指向一件事：企业不再用一个最强模型处理所有问题。

放到银行里，这个"分级"是天然存在的：柜面知识问答、报表口径解释、代码辅助、信贷资料预审、监管报送核对 —— 风险等级完全不同，凭什么用同一个模型、同一套权限？该用便宜模型的地方用便宜模型，不是抠门，是因为"用错模型"本身就是一种风险错配。反过来，需要跨系统协调、模糊判断、高价值决策的环节，省下的那点钱远不够覆盖一次事故。

但这里有个反直觉的结论，值得每个做预算的人记住：更便宜的模型不一定产生更便宜的任务，更强的模型也不一定产生更贵的任务。便宜模型如果反复调用工具、持续重试、最后还要人来修，整个任务的成本反而更高；强模型如果规划更好、轮次更少、一次通过验收，总成本可能更低。所以要优化的从来不是 token 单价，而是"每个合格结果的成本" —— 质量、时延、工具调用、失败重试、人工介入、基础设施，全都得算进去。

还有一个容易被忽略的成本项。Anthropic 的成本优化指南提到，稳定的提示词前缀能显著提高缓存命中，好的应用可以做到 90% 至 99%；一次迁移测试里，prompt-audit 平均降本 14.6%，同时准确率提升 5.3%；缓存、提示词审计、批处理与努力程度调优组合起来，在若干基准上报告了 50% 至 73% 的降本。

这些数字在银行能不能复现？我的判断是：取决于两件事 —— 文档模板统不统一，取数路径稳不稳定。银行在"模板统一"上有天然优势（制度性文件格式极其规范），但在"多系统取数"上是劣势（同一个指标在不同系统里叫不同名字）。所以缓存这件事，在银行的天花板不由模型决定，由数据治理决定。这也是我一贯的看法：AI 项目的成本优化，做到底都是数据治理问题。

三、托付的技术合同：运行时、证据、权限

如果"可托付"是一份合同，那它的技术实现长什么样？周刊里有一篇讲 Harness 的文章把这些层次拆得很清楚：模型记不住历史，于是外部程序装配上下文；模型碰不到世界，于是增加工具；一步做不完，于是形成"模型—动作—环境—观察—模型"的循环；上下文装不下，于是需要压缩与记忆；任务产生副作用，于是出现权限与沙箱；运行时间跨过会话，于是需要持久化事件、恢复状态、协调子 Agent。

这段话我建议每个做方案的人都读两遍。因为它说明了一件事：这些组件不是工程师为了炫技堆出来的，而是每撞上一次真实失败之后留下的答案。反过来说，如果你手上的项目没有这些层次，不是因为你简单，而是因为你还没遇到那些失败 —— 或者更糟，你已经遇到了，只是还没承认。

这直接对应到 POC 的现场。客户在评审时问得最多的问题，其实不是"你能不能做"，而是"你能不能证明你做对了"。而多数演示回答不了后者 —— 因为演示只需要成功一次，真实工作却会遇到过期数据、含糊需求、权限不足、工具失败、环境变化，以及人与人之间从未写下来的约定。演示的默认假设是环境配合，生产的默认假设是环境不配合。

周刊里提到一个我很喜欢的机制。Claude Managed Agents 的创始人圆桌，把期望结果写成 rubric，再由拥有独立上下文的评估者检查。他们举的例子是一家会议产品做会前简报：系统不仅要找到同名的人，还要确认哪份资料属于本次参会者，补回邮件和日历里的历史，再把材料排成有人愿意读的顺序。团队的态度是 —— 认错人会让人带着错误背景走进会议，所以宁可不展示不确定信息，也不提供一个看似完整的错误内容。

这一条对我冲击最大，因为它正好戳中做方案时最容易犯的错。为了演示好看，我们天然倾向于把不确定性藏起来，把一个"看起来完整"的结果摆上台。但在金融场景里，这个习惯是致命的。不确定性被藏起来，不等于它消失了，它只是从演示环节转移到了生产环节 —— 而生产的代价比演示高几个数量级。我现在越来越信一条原则：方案里宁可写清楚"这里我们会停下来问人"，也不要承诺"这里全自动"。

另一个机制是权限分层。NIST 关于 Agent 工具使用的工作坊总结，给了一把很实用的尺子：权限可以分为只读、受限写入、开放写入，环境可以分为可信与不可信。同样是浏览器，阅读资料和提交订单的风险完全不同；同样是代码执行，在隔离仓库里和接触生产凭据的环境里也完全是两回事。

这解释了一个常被混淆的问题："允许使用工具"从来不是一句充分的授权。它是一个总开关，而真实世界需要的是分层：能读什么、能建议什么、能写什么、哪一步必须人工批准、哪些资源永远不可见。而且权限必须和身份、环境、任务类型、可恢复性一起定义 —— 同一个动作，换个人、换个环境、换个时点，风险等级就变了。

我的判断是：在银行，短期最现实、最容易通过评审的架构是"AI 只读 + 人写入"。不是技术上做不到写，而是责任链还没准备好承接。等到"谁批准、谁复核、谁留痕、谁担责"这一串都能在系统里被完整表达的时候，写入权限才会逐步放开 —— 而且一定是从低风险场景、小额、可逆的动作开始。

最后说一个常被过度解读的数据。METR 的长任务研究用"人类专家完成该任务所需时间"来估计 Agent 达到 50% 或 80% 成功率的时间跨度，同时明确提醒：50% 时间跨度并不表示系统能自动化所有相同时长的工作，任务主要来自软件工程、机器学习和网络安全，而且比真实工作更自包含、更容易自动评分，超过 16 小时的测量当前也不够可靠。

这段提醒非常重要。"偶尔完成一次 8 小时难度的任务"和"每天稳定处理 8 小时关键工作"，是两种完全不同的承诺。前者是能力展示，后者是可靠性工程。金融行业需要的是后者，而后者要的不是漂亮的 best case，而是完整的失败分布：失败率多少、失败长什么样、能不能被发现、漏检的代价有多大。

四、把智能放进旧城：银行的事实散落在哪里

前面聊的都是新系统。但银行里真正的工作量在存量 —— 这一点和互联网公司的 AI 实践差别很大。

周刊里阿里云架构师 Agent 的实践，把存量系统的问题概括得非常准：局部正确，整体错误。字段为什么不能删，历史分支为什么保留，接口曾经向哪个团队承诺过什么，这些信息往往不会同时出现在一份文档里。只让 Agent 搜索相似片段，它可能找到"看起来最相关"的材料，却漏掉作出完整工程判断所必需的那部分知识。

这在银行只会更严重。因为银行的事实源除了代码、文档、配置、数据库，还多出几层：监管口径、制度文件、历史会议口径，以及资深同事脑子里的那些"我们一直这么办"。第四种最难处理 —— 它从来没有被写下来过，也就无法被检索、无法被校验、无法被版本管理。

所以我对"AI 进入存量"这件事有一个可能有点反常识的看法：第一阶段最该被交付的价值，不是写新东西，而是"考古"。阿里云的做法是先按领域建立强结构知识，明确业务、架构、系统、基础设施的阅读路径；运行时再渐进加载当前步骤需要的材料；最后由事实验证层检查方案；涉及业务取舍、跨团队接口承诺和合规等高风险决策时，Agent 应该停止猜测、向人提问。

蚂蚁数科的做法更直白：一个 60 万行的 C++ 存量项目，因为历史文档缺失、事实源不统一，AI 介入后缺陷率一度超过 20%。团队没有立刻去换更强的模型，而是先让 AI 扫描代码和文档的差异、重建唯一事实源，再加入 CI 门禁和多视角 Review。

我特别欣赏这个顺序。先统一事实，再提升智能。因为在一个事实源不统一的系统里，模型越强，可能只是把错误的结论表达得更有说服力。

蚂蚁把 Harness 拆成三层：约束层明确目标、事实来源与文档规范；验证层里，硬门禁检查规则合规，软门禁由不同 Agent 从 Contract、减法与复用角度审查；证据层把测试路径做成可视化报告，用来揭示"100 个测试只覆盖两个状态之间的跳转"这类低质量模式。改造后缺陷率降到个位数。这个结果来自特定组织和项目，不能承诺复制到所有代码库，但机制是可迁移的 —— 验证数量不等于验证质量，覆盖了多少行代码也不等于覆盖了多少关键状态和失败路径。所谓可验收，是让一个不参与生成的人看到证据之后，能够判断目标是否完成、边界是否守住、风险是否仍然存在。

天猫技术那边的经验，补上了"人多了以后怎么办"这一环。团队总结了从超级个体、加人提速、高速迭代到全员赋能的四个阶段：早期个人凭经验就能快速推进，人员和 Agent 数量一多，上下文不一致、冲突和质量劣化就会成为新瓶颈。他们用一份不超过 120 行的 AGENTS.md 只做导航，把规格、变更记录、架构、运行手册交给 6 个 Skill 管理，用 Git commit 作为统一关卡；还通过 MCP 提供只读通道，把仓库之外的事实（配置、任务状态、线上数据）拉回 Agent 的视野。

这套东西对金融行业的启发是"治理先行"。银行的上下文比代码仓库复杂得多 —— OA、知识库、制度系统、监管报送平台，还有大量非结构化的会议纪要。如果一家银行要真正把 AI 用起来，最先需要建设的可能不是模型平台，而是一个能被授权的、有版本的、知道谁能读什么的"事实入口"。这话说出来不性感，但我觉得它比讲一百个 Agent 场景更有用。

五、任务经济：当采购单位从"坐席"变成"结果"

前面讲的是"能不能托付"。接下来这个问题更商业：如果 AI 真的能托付了，行业怎么给它定价？

腾讯研究院用一个很好记的说法描述了正在发生的变化：单 token 通缩、单任务通胀。每个 token 的价格在持续下降，但 Agent 承担的任务越来越长 —— 规划、读文件、调工具、自我校验、失败重试，会把一次任务的消耗从数百 token 推到数十万。效率提高之后，人们反而愿意交出更多工作，所以总账单未必同步下降。

这个框架解释了一个很有意思的现象：为什么"模型越来越便宜"和"AI 支出越来越高"会同时成立。它也能解释为什么低价模型和成本治理会在同一周同时成为热点。

更值得琢磨的是商业单位的变化。互联网过去的商业单位常常是曝光、点击和坐席；平台分发信息的边际成本很低，用户旅程越长，可以放广告的位置越多。而 Agent 接受的是任务 —— 它要理解目标、选择工具、读取数据、执行动作、校验结果。用户可能不再打开十个页面去比较，而是直接说"帮我筛三家供应商、比一下报价、约个沟通"。

于是关键问题变成了：谁掌握任务入口，谁就掌握了排序权。而排序权在金融行业是个敏感词。银行对"不透明的商业推荐"是零容忍的 —— 一个替用户作判断的系统，如果在不透明的情况下被商业利益影响，它作为"受托者"的资格当场就没了。所以做 Agent 入口的人要记住：在金融场景里，可解释的排序逻辑不是加分项，是准入项。

周刊还推演了 SaaS 的分化：一部分会变成保存客户、订单、财务、库存等核心数据的 System of Record，另一部分会变成代表用户调用系统、完成任务的 System of Action；界面型软件可能退到后台，收费方式从卖坐席转向卖结果。

这对我这样的从业者意味着什么？我的判断是：银行的采购计价方式会滞后，但一定会跟着变。现在大家买的是"平台 + 授权 + 人天"，未来大概率会加入另一套计量 —— 完成率、准确率、可追溯性、人工接管率。这对厂商是双向的：交付责任变重了，但能把"结果"讲清楚的人，溢价空间也变大了。反过来，只会卖授权和参数表的方案，会越来越难。

六、人的位置：不是"机器做不到什么"，而是"目标本来就需要主体"

聊到这儿，通常会有人问：那人的位置在哪里？

我比较认同周刊里引用的一个说法 —— 未来很多职能会被重组成一层层相互连接的循环，每个循环围绕可衡量的目标持续执行；遇到阻塞时，人补上缺失的上下文、洞察或方向；循环恢复后，人的注意力移到下一处。人真正的工作，是"选择下一座山"。因为自动化系统擅长在已经定义好的方向上逼近局部最优，而新的战略目标、异常情况和分布外判断，仍然需要人来定。

我特别想把这个说法带回项目现场。我见过太多 AI 项目推进不下去，原因不是技术，而是"那座山不是业务选的"。IT 部门拿着一个很好的工具，去找业务部门说"你看这个能帮你省多少人力"，业务部门礼貌地点头，然后不用。而真正跑起来的项目，往往起点是一句很朴素的话：这个环节我确实想解决，而且我知道"解决了"是什么样子。

周刊里还有一个我很有共鸣的例子。一位创业者在讨论 AI 与内容时，追问的不是"AI 能不能生成更多角色和世界"，而是"用户进去以后到底体验什么"。她给的答案是"命运" —— 用户的选择会影响内容与 AI 共同编织的剧情。判断很干脆：能生成更多，只代表供给增加；用户愿不愿意进入、停留和付费，取决于体验有没有情感重量、选择有没有后果、作品有没有品味。

这段话放到 B 端同样成立。AI 能做的更多，只代表供给增加；业务方愿不愿意真的用它，取决于这件事有没有解决他的真实痛点、结果有没有可验证的后果。供给过剩的时代，稀缺的从来不是能力。

她还讲了一件让我印象很深的事：团队曾主动清理流量导向的内容，短期数据掉了 30%，多年以后 IP 衍生收入占比过半。这个决定背后的逻辑，是把"长期价值"放在"当期指标"之前。我觉得这恰好是 AI 时代最难、也最需要人的一类判断 —— 系统可以帮你优化指标，但不能替你决定"为了什么愿意承受短期的难看"。

所以我的结论是：人的位置不只来自"机器暂时做不到什么"。目标、价值、责任这些东西，本来就需要一个主体来承担。而且模型越强，这个判断越重要，不是越不重要 —— 工程师和业务方在目标澄清、边界识别、架构判断、结果验收上的要求，反而更高。

七、一份可以马上用的自检清单

前面都是观察，最后给点能直接用的。如果你正在推一个 AI 项目，尤其是金融这类强监管场景，我建议先回答这六个问题：

l能不能用一句话写清"合格结果"？写不出来就别启动。写出来了，它就能变成 rubric，就能被独立校验。

l这个任务失败一次，最坏后果是什么？可逆吗？不可逆的环节，默认不交给 AI 全自动。

l系统需要的"最小权限"是什么？默认从只读开始，写入权限按副作用分层，逐步放开。

l谁来独立验收？他能不能不看生成过程的推理、只看证据就下判断？如果不能，说明证据链还不完整。

l出错时怎么停、怎么退、怎么把上下文交回人？没有恢复机制的长程任务是负债，不是资产。

l你算的是 token 单价，还是合格结果的成本？把重试、人工介入、修复成本都算进去再下结论。

这六个问题听起来简单，但我见过太多项目在第三个和第四个上翻车 —— 不是能力不够，是设计之初就没打算回答。

写在最后

回到开头那句"没人愿意签字"。我现在的理解是：这不是保守，这是理性。在一套责任体系里，没人会为一个自己无法解释的结果负责。而"可托付"这三个字要做的，就是把"无法解释"变成"可以解释" —— 把目标写清楚，把边界划出来，把证据留完整，把失败设计好，把责任接住。

模型能力会继续变便宜，这一点几乎没有悬念。但"敢不敢用"不会因为模型变强而自动解决。它需要有人去做那些看起来不性感的工作：统一事实源、定义合格标准、设计权限分层、建立验收机制。这些活不产生演示效果，但决定了 AI 到底能不能进生产。

技术供给的丰裕，不会替我们回答"什么值得做"。这件事，一直都需要人。而我觉得，这恰恰是我们在行业里跑的人，最该花时间的地方。

— — — — —

参考来源：本文事实与案例来自 BestBlogs.dev 周刊第 112 期「可托付的智能」及其收录内容（DeepSeek V4.1 Flash、面壁智能 MiniCPM5-2B、ChatGPT Images 2.5、Anthropic 成本优化指南、Spotify Portal 实践、OpenAI Agents API、Claude Managed Agents 创始人圆桌、NIST Agent 工具使用工作坊总结、METR 长任务研究、阿里云架构师 Agent 实践、蚂蚁数科 Harness 工程、天猫技术研发协同实践、Shopify 原生开发迁移、腾讯研究院任务经济分析等）。

原文链接：https://www.bestblogs.dev/newsletter/issue112/read

本文为基于上述公开内容的原创解读，观点与判断由本文作者持有，不代表任何机构立场。