在金融监管报送这一对数据准确性要求近乎苛刻的垂直领域中，通用大模型所展现出的"自由发挥"能力反而成为最大的风险来源。
本文整理自中软融鑫总工程师于浩军在 AICon 全球人工智能开发与应用大会 2026 深圳站的分享《金融监管领域的 Harness 实践：让知识与数据驱动 Agent 稳定运行》。他结合过往数年在金融监管领域落地 AI Agent 的实践经验，系统阐述了如何通过知识底座、数据底座、受控状态机与全链路可追溯等机制，将原本发散的 Agent 改造成一个“宁可不答、不能答错”的严格受控系统。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
应用场景：Agent 在金融监管中要解决什么
今天我想聊的，是一个和前面几场分享在技术取向上有所不同的领域——金融监管。上午和下午早些时候各位老师讲的内容覆盖面很广，技术本身的通用性也更强，而我所在的这个方向非常垂直。大的领域叫金融，金融下面还可以细分出监管、风控、营销等多个子领域，我关注的是其中的金融监管，更具体地说，是金融监管报送中与数据准确性密切相关的一类工作。
上午有老师提到，数据准确性做到百分之九十七已经很不错了。但在我所处的这个场景里，九十七只是一个初步的概念，实际要求要比这高得多。也正因为有这样的极高标准，金融监管领域里积累了大量需要谨慎处理的生产实践。来之前我注意到一种声音，认为我们是在给大模型嫁接过多约束、限制了大模型的能力，算不上好的实践。我的看法恰恰相反：在一个极其谨慎的生产环境里，这类约束是不可缺少的。今天我想把过往做的一些工作串联起来，讲清楚我们在这个领域里到底怎么做的，方案是什么，以及它能给其他同样谨慎的行业提供什么参考。
先看应用场景。金融监管的制度背景是：我国所有金融机构——银行、财务公司、小贷公司——都受到强监管要求。监管的核心动作叫“报送”，也就是金融机构把自身经营过程中的关键信息报送给监管机构，由监管机构进行审查。这项工作在小型金融机构里大约占到三分之一的工作量，在大型金融机构也能占到五分之一。它本质上是一类成本型工作，但监管要求非常多。就罚款而言，今年前半年整个行业的罚款规模已经达到数亿级别，单家大型金融机构在去年被罚几个亿，小型机构罚款几百万、几十万的情况也屡见不鲜。在这个环境下，如何把报送工作做得更精准，对金融机构的影响非常直接。
这个场景有四个非常鲜明的特点。第一个特点是口径复杂，解释口径意味着我们获取一个数据时，需要清楚它到底指的是什么。一个贷款信息在金融机构内部，信贷部门、财务部门、统计部门给出的结果可能都不一样。口径不仅复杂，而且在组织内部潜移默化地被人各自理解。第二个特点是频度高。这类数据处理有按月的、按旬的、按周的各种节奏，处理过程相当繁复。第三个特点是最核心的一点——零容错。前面说了，百分之九十七的准确率远远不够，这里要求百分之百，一个数都不能错。我们的原则是宁可不报，也不能报错。第四个特点是强追溯。数据出来之后，如果发现业务出了问题，比如某笔贷款存在违规放贷，这套数据必须能够被完整地追溯回去，定位到究竟是哪个环节造成的。因为我们是数据驱动的，这是四个不容犯错的问题。
我们做金融监管相关的 Agent 工作已经两三年，这期间经历过几个最棘手的痛点。
第一个痛点是口径漂移。前面说到口径很重要，但很多地方的解释并不清楚，也没有统一标准，口径漂移因此成为最严重的问题。举一个小微企业的例子：去年国家提出“五篇大文章”，支持五个重点产业方向。但要统计其中的小微企业到底该按什么口径来算，换一个思路、换一个口径，数据就会出现很大差异。业务口径看起来没变，但数据口径可能截然不同。第二个痛点是幻觉。金融机构处于强监管环境，所有业务规范都来自监管机构的明确发文。这些发文如果直接交给大模型处理，模型往往会根据自己的理解去推理，生成一些实际并不存在的范围，也就是我们前两年常说的“一本正经胡说八道”。这在监管场景里是绝对不能接受的。第三个痛点是不可解释。在 2018、2019 年前后机器学习阶段，不可解释问题基本无解。到了现在这个 AI Agent 阶段，我们每出一个数、每一次计算都需要有合理的归因：这个数到底怎么来的，它的链路是什么，为什么是这个数而不是别的数，这些都需要清晰的回答。
这三个痛点的共同根源在于 Agent 在自由发挥。一方面，我们希望 Agent 去自由发挥，填补我们考虑不到的内容；另一方面，我们又担心它的自由发挥造成“思想的漂移”，让数据处理变得不可控。在监管的要求下，它更多需要的是“照章办事”，而不是过度发挥。监管领域里也有非数字类的工作，比如写一些报告，这些内容相对不敏感，但对于数据处理类的任务，自由发挥是不可接受的。
那么 Agent 在这个需求里具体介入哪些环节？我把它分成四段。第一段是需求侧，涉及对监管要求的理解，再结合银行内部的指标体系，上午有同事分享过指标体系的建设——通过指标、数据资产、知识资产来自动化生成监管要求相关的处理过程。
第二段是报送中的审核与复核，包括数据加工过程的检查、指标计算、指标自动质量检查，以及对异常数据的实时提醒。比如数据比上个月上升了百分之三十或者五十，或者明显不符合监管要求，这些都可以通过 Agent 在过程中实时发现。有人会问，这部分用规则模型不就行了吗？我们的经验是规则模型永远覆盖不了百分之百，不可能一次性拿出几万条规则全量覆盖。所以我们的做法是让 Agent 结合数据特点，针对每一期数据实时生成它认为当下更合适的一批规则，然后执行，这样更有效。
第三段是问题处置。人在处理数据时必然会出错，或者计算结果有问题。这个问题到底是原始数据不对、处理过程出错，还是业务本身就有问题？这三类情况都需要定位、修复、根因分析、追溯和血缘分析。血缘和追溯在数据领域非常重要，但坦白讲，行业里直到今天也没有哪家敢说把追溯和血缘做得非常完美。金融机构一般有原业务系统、中间数据中台、各级集市到业务应用，加起来超过十五层的数据处理链路，要把血缘分析清楚、追溯逻辑搞明白，本身就是极困难的事。这个部分我们现在通过 Agent 来做，取得了很好的效果。
第四段是报送前的复核。数据已经有了，但到底对不对？每家金融机构每期报送前都会花大量人力去检查。这个检核的核心是相互交叉检验：用自己的台账、其他系统、对外暴露的其他侧面数据做相互印证。我们在报送前先通过 Agent 把这些数据联合起来，综合产出一份复核报告，然后让业务员确认这次数据是否能正常报送。报告会告诉业务员，比如百分之九十以上的概率可以报，百分之十可能存在问题的部分，以及每个问题背后的原因是什么。
场景反过来给 Agent 提出了四个强制要求。第一是口径受控，不允许 Agent 去发散口径，不允许它自行理解。口径在监管机构和银行内部都有非常清晰的定义，拿出来用就行，我们只允许它读取已有的口径信息。第二是数据可查、强追溯，每次取数都要走受控通道。金融机构里同一数据往往存在多个系统中，到底从哪个系统取，必须预先定义好路径。第三是逻辑可查，处理过程中调用了哪个能力、引用了哪条规则，都要处于受控状态。第四是能力可复用，监管数据不是一次性的，今天能算出这个数，明天还得用同样的链路算出同样的结果，不能今天一个值、明天另一个值。所以我们要做的不是一个“更聪明的 Agent”，这其实是一个悖论——我们希望 AI 越来越聪明，但在这个场景下，我们要的是一个受到严格约束的 Agent。它仍然是 Agent，但里面加上了各种控制，让它始终走在正确的路上。
解决方案：Harness 体系如何支撑场景落地
为了实现前面说的百分之百准确，我们构建了一套自研的 Harness 架构。这个架构有两个重要的基础：知识底座和数据底座。
先看知识底座。我们将监管机构发布的各类发文、制度作为知识来源。这类内容的特点是相对标准、规范，都经过国家正式发布或行业内部加密发布。另外一部分是银行内部的业务知识和流程，也统一作为知识体系放入系统。这里我想特别说明一个问题：今天一整天的分享里我一直没怎么提向量。到现在这个阶段，大家对向量层的讨论已经不那么热衷了，因为向量的能力确实存在一些不足。我们现在采用的方式是把向量、精确数据处理和图库结合起来，把几种在知识领域能起作用的技术综合运用。对 Agent 来说，知识的切片策略非常重要。如果拿一个非常大的知识库丢给 Agent 去用，它基本就废了，知识过多会造成幻觉。正确做法是针对特定 Agent，比如专做贷款相关任务的，与相关知识切片相结合。
第二个是数据底座。根据我们对行业的理解，数据底座里包括明细数据、指标数据、报表数据，以及非结构化和半结构化数据。在这个底座上，元数据、数据标准和安全分级分类构成了支撑层。数据查询时，查询者应该能查什么，不能因为是 Agent 就可以什么都看。所以我们通过数据标准、安全分级和分类与企业用户结合，让它只查它权限范围内的数据。此外，数据质量治理和责任归属也是数据底座的重要组成部分。
在双底座之上是执行层：Agent 的任务编排与判断、Skill 的能力固化、MCP 的受控连接，以及全过程的可追溯。最上面一层对应前面说的四方面需求场景。侧面则是治理和工具的保障。
具体来讲，监管要求或者机构分析数据的口径是变化的，最少每年一变，变动幅度在百分之三十左右。因此我们必须在整个知识和数据体系里对知识版本、数据版本进行非常清晰的管理。同时需要测评和编排机制，让 Agent 每个月运行之后都能做一次测评，回归到基线，并能完成回归处理，在测试、准生产、生产几个环境之间来回穿插。权限与审计方面，我们在数据分级分类和报表指标权限划分的基础上，通过控制和规则限制 Agent 的访问范围与权属范围。最后是可观测性，每一个 Agent 运行一段时间或每一批运行之后，都需要由独立的审计 Agent 对其执行日志进行单独审计，发现是否存在不可控因素，再回归去做调整。只有在测试环境或准生产环境连续三四轮没有发现问题后，才会上生产。
我们如何把自由的 Agent 循环改造成受约束的状态机制呢？正常情况下，Agent 收到任务后会自动推理、自行调用它认为合适的工具、执行并返回结果，这是一个相对不受控的过程。要实现受控机制，我们在 Agent 构建过程中做了五个方面的工作。
第一是计划环节，Agent 在执行过程中只能从我们已经注册的 Agent 可获取范围内去取 Skill。我们需要把 Skill 的基础信息写得很清晰，让它不至于偏离或漂移到别的 Skill 上，产出结构化的执行计划。第二是保护环节，我们设置动作白名单，明确它能干什么、不能干什么，比如能否连接核心数据、能否修改数据、能操作哪些数据。同时做 Schema 校验，对越界的状态或操作直接拒绝。第三是执行环节，对于 Skill 和 Tool 的执行，我们会把确定性的处理过程下推，不让 Agent 直接执行。虽然大模型也能算一加一等于二，也能算出一些数学或经济算法的结果，但我们现在把常用算法固化到 Python、Java 程序里，大模型 Agent 只需直接调用对应的 Tool 或过程，这样计算过程和结果都相对可控。第四是检核环节，对 Agent 的输出做契约检核和一致性校验，不通过就不能走下一步。第五是过程维度检查，如果执行过程中四个大维度里缺了任何一个，整个状态就被判定为失败。
总体来看，动作空间是封闭的，未注册的 Skill 或 Tool 不可调用。之前的经验里，Agent 有时会自动创建一些 Skill 和 Tool 来完成任务，我们现在把这些行为都加以限制。部署和预算也要设上限。现在 Token 使用量很大，我个人一个月大概会用到三四万人民币的 Token 量。预算和部署上限的设定原则是：如果预计十五步就能完成的任务超过了三十步，说明出现了问题，我们就要停掉它；Token 超过一定范围也一样。我们没精力去检查每一步里是否真的需要这么多 Token，但设置一个上限后，达到上限就认为过程异常，直接终止。中间还要设置审批中断点，比如口径确认、数据补全、最后签发，都需要人工介入，虽然只是确认，但这一步不能少。最后是失败即停，五个环节里任何一步出问题，整个任务就停下来，执行相关工作，绝不把错误结果交给客户。讲来讲去目标只有一个：可以没有结果，但不能错。
报送场景中的 Agent 执行全流程
Agent 在报送场景里到底怎么跑呢？第一步是接单，读取报送任务并拆解。一个报送任务可能涉及一百个、两百个甚至五百个指标，我们按单个指标逐个拆解。如果把五百个指标一次性丢给 Agent，让它全算出来，大概率做不成；但如果让它算其中某一个，成功概率就高很多。所以接单之后我们拆解报表项和指标清单。第二步是通过 MCP 知识库获取口径信息，知识底座本身是分布的，比如这个报送任务针对资产负债表，就调用资产负债表对应的知识库，获取指标或数据项的精准口径。第三步是取数，通过 MCP 或连数据库的方式，根据口径描述生成对应的取数逻辑，获取相关数据。第四步是勾稽校验，取到的数据往往是相互关联的，比如一个数应该小于或大于另一个数，或者与某个数的差异不能超过百分之三十。通过这些检核要求，我们可以判断数据准确度的高低。
第五步是异常处理。当勾稽校验发现问题时，就要通过数据库、Agent 和图库相结合的方式，获取血缘处理逻辑或取整个 Track 库的路线，在链路每个节点上做检核校验，然后给出建议和处置意见。这个意见可能指向原始业务环节，比如整个数据处理架构是对的、计算也准确，但结果不对，那可能是原始业务发生时填错了材料，需要回到源头修改。第六步是复核报告出具。我们做了一个专门的 Skill，Agent 在异常处理完成后会出具复核报告。比如针对这批报表的一百个指标生成结果，报告会说有些数据超过了百分之三十的变化，原因是你上个月给某个企业多贷了一千万，导致幅度大幅变化，诸如此类的详细解释说明。有异常的给出异常说明，正常的也有对应的计算链路。通过留痕机制，让整个链路上的 Agent 只做编排和判断，不做取数和定义，从而达成受控目标。也就是说，无论计算数据还是取数据口径，都不让 Agent 做过多的联想，拿到的数据必须是我们已经定义好的数据。当然，定义数据本身的口径工作是在知识库建设过程中用 Agent 来完成的，但在后续运行过程中不允许再发散。
接着讲一个完整 Skill 的规格。对于口径信息，我们不再用一句话来描述，比如“各项贷款包括什么什么”，这种描述非常模糊，每一句话都可能被模型做不同理解。我们对 Skill 的定义采用非常严格的结构化要求，语义版本之类的信息硬绑定，同时指向具体的知识条目，比如这个口径对应知识库里的哪个条目。输出方面，口径是什么、来源是什么，都有非常清晰的定义。还要记录本次执行的血缘关系，以及对应的数据计算引擎是什么，是 Python 代码、Java 代码还是 SQL。对于版本要求，我们有非常详细的定义。在这些定义约束下，Skill 无法超越定义去做更多工作，只能在可控范围内执行。
具体来说，口径引用是必填字段；数据计算前面说过不经过模型；输入输出采用契约化，明确规定类型和枚举类型，不让模型发散出它理解的东西。比如币种，一般我们只用到五种，它发散出十五六种放进来，这种情况就要通过契约化方式来约束。发布前还要准备回归用例，一个 Case 要跑五六遍，全部通过才可能到准生产环境，再上生产。整个生产和上线过程都保持这种严谨性。
对口径来说，受控执行意味着只允许使用，不允许理解。对特别热衷大模型的人来说，这可能显得不可理喻，觉得限制了大模型的能力。但它是一个安全可控的做法。具体实现上，我们把口径沉淀在数据治理的成果里。在金融机构做 AI，一般都会被问有没有做数据治理，做了才能继续推进。我们对指标的计算逻辑、指标范围、过滤条件都做了明确界定，Agent 只能引用，不能改写，也不能推测口径相关内容。如果根据口径完全取不到数据，那可能是口径写错了或过时了，这时它想自己理解一下改对了再用——也不可以，必须保持在严格定义的限制之内。
对于高频动作，我们将指标计算固化为 Skill。金融行业的指标计算种类其实不多，大多数也用不到非常复杂的经济算法，固化起来相对容易。同样的输入输出还可以做回归测试，把一个 Skill 做到相对完善。同时 Skill 要有版本管理，因为监管要求和口径每年都会变化。比如今年要报明年做去年的数据，就要用去年的 Skill 版本，上个月用上个月的 Skill 版本，版本概念贯穿始终。
对于口径缺失的情况，明确要让模型回答“不知道”。如果某些数据或逻辑它不理解，大模型的结果就是“不知道”，不能自己拼一个。它提建议时可以说不知道然后提出建议，但建议的结果必须经过人工确认才能继续往下做。大模型该不知道的时候就要让它不知道，不能让它假装知道。我们做第一批金融机构项目时，确实出现了大量“不知道”，用户会觉得很不合理：你怎么有这么多不知道？但经过一轮口径治理的调整，不知道越来越少，系统就达到了可控或可上生产的状态。
我们把哪些监管标准 Skill 固化下来了？第一类是口径类，包括口径解释和结构化、版本对比、口径适应性判定。这部分工作手工做不现实，必须通过 Skill 完成，这些 Skill 为真正执行的 Skill 创造条件。第二类是计算类，包括指标计算、报表数据项的汇总计算，以及期初期末、同期、同比、环比数据的推导。这些看似简单，实际上同期计算按月、按季、按天的算法都不一样，相对繁杂。第三类是校验类，涉及表内表外的勾稽关系。金融数据从不同维度、不同角度看，很多数据可以相互印证，所以有表内表外检核、跨表一致性检核，以及值域、非空等检核，都固化成 Skill。这些检核相对稳定，因为金融机构核心数据体系建成后不会三五年就变，差不多能用十年。第四类是追溯类，关于数据处理过程中血缘路径的查询和分析。原来做数据的人要解析 Excel、解析处理逻辑来生成血缘，现在我们通过数据加工链路自动完善血缘关系，同时做变更影响分析。前面说过，监管体系每年有百分之三十的变化，每次变化后对后续的影响是什么，需要通过 Skill 和 Agent 结合来处理。第五类是取数过程回放。一期数据完成后，可以回放整个链路的影响。输出方面，质量分析报告、复核报告、审核建议都固化为 Skill。
那么大模型在链路里到底负责什么、不让他干什么？允许它做的是意图识别和任务分解、槽位抽取（只抽取不做分析）、Skill 路由和参数填充、异常判定和文本识别。不允许它做的是数据计算、汇总、口径判别表生成、弱化校验，以及生成引用，也就是处理逻辑引用了什么内容，不让他们直接去取知识体系。数据受控链接是数据和知识的唯一接口，通过 MCP 方式连接监管知识库、血缘库、图库。
全链路可追溯方面，调用哪个 Skill、引用哪条链接、取了哪张表、出了哪条血缘，都要有详细链路留存。留痕后的样子包括执行 ID、调用的 Skill、引用路径、数据来源、血缘路径、勾稽关系、耗时、结果以及校验和复核过程。人为操作也放入链路，比如生成报表后谁做了复核，整个过程记录下来。
对 Agent 来说，知识资产和数据资产是唯一能够被调用的内容，不允许发散。知识资产包括口径、表、字段含义等；数据资产包括明细数据、指标数据、报表数据，也涵盖结构化和非结构化数据。两者之间有内在关系，比如数据资产中的元数据（数据定义本身）也作为知识资产的一部分处理。
图库里到底做了什么？举一个例子：借据里合同表的一个余额，来源于某个明细表，再汇合成某个汇总值，最终加工成一个指标值，这是一个完整链路。下面还有勾稽关系，加工出来的指标值应该与其他指标值保持什么关系，都存在图里。数据资产的产生涉及数据治理：监管文件、填报说明等都放进去，最终形成版本化的有效口径，再供 Agent 引用或回流到 Agent 里。
向量的部分需要多说一点。举小微企业贷款划型、普惠型小微企业的例子。用向量检索时经常出现歧义，召回率时高时低，不够精确。我们的做法是引入语义本体，用同义词或易混淆内容做处理，同时把版本和生效条件做前置处理。这样就避免只是把文档丢进去，而是把结构化数据放到图库或知识库中相互协作、相互配合，形成高召回率的能力。现在也有把文件和结构结合起来看的做法，召回率可能更高。
检索路由方面，向量检索第一部分是组件检索，该精确获取的必须精确获取。对于不能精确获取的内容，最终通过图的约束来检验，也就是在版本体系和图体系里校验所挂节点的准确性、完整性和一致性。这样能保证检索路径上出来的结果基本可用、是最新的、也是所需路径。
知识库本身有五个健康度指标。一是覆盖率，因为要出数，覆盖率应该是百分之百。二是鲜度，涉及引用版本是否为最新。三是冲突，不经意的操作可能导致系统里有两个或多个同时处于激活状态的条文。四是过期项目，从来没被用过的要及时清理。五是引用命中率。对这些内容要持续处理，自动登记知识缺口，对未命中原因做分析，最后形成改进方案。
数据资产治理是一边加工一边沉淀成知识的过程。原系统部分做接入登记和确认；明细层做元数据登记、目标映射、标准化、数据分类分级；指标层做口径和计算逻辑、质量匹配；报表层做口径、频度、范围和确权。知识与数据的 Agent 关系是正向循环：Agent 调用知识资产和数据资产，同时知识资产和数据资产的不完整之处也通过 Agent 去补充完善，完善过程需要人工确认，最终形成有效的知识资产。
上生产之前有三个做法。第一个是红线机制，口径歧义、跨表勾稽关系错误、极值、空值等问题，任意一条出现都不能上线。第二个是回归机制，每个 Skill 要用历史报送实际情况跑五期和十期的测试。第三个是灰度双轨机制，做技术的人都知道，应用发布要有灰度发布，同时并行跑三五个月观察。我们做的一个实际演练，从需求报送到整个异常处理过程，一共五步，涵盖需求侧、报送侧、异常拦截、血缘分析和复核报告出具，形成完整流程。
最后回到一个根本概念：治理和智能是相互为前提的。不能光说治理好再做智能化，而是一边治理一边做智能化。过去有人会说，我们还没治理好所以不能做后面的工作。现在我们的方法是，用 AI 的方式提高数据治理能力，通过数据治理的提升来增强 Agent 的稳定性、准确性和最终可用性，两者相互协作。下一步我们计划把 Skill 做成资产化，把整个数据处理过程从影响清单到自动化改造做起来。最后要做的是可信的度量和评估，这个部分我们现在做得还不够，尤其是中间过程的度量和评估还有欠缺。后面会继续加强。
会议推荐
QCon 全球软件开发大会·2026（上海站）将于 10 月 22 日—24 日举办。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型 等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。查看更多详情可扫码或联系票务经理 18514549229 进行咨询。
