金融监管领域的 Harness 实践：让知识与数据驱动 Agent 稳定运行

在金融监管报送这一对数据准确性要求近乎苛刻的垂直领域中，通用大模型所展现出的"自由发挥"能力反而成为最大的风险来源。 本文整理自中软融鑫总工程师于浩军在 AICon 全球人工智能开发与应用大会 2026 深圳站的分享《金融监管领域的 Harness 实践：让知识与数据驱动 Agent 稳定运行》。他结合过往数年在金融监管领域落地 AI Agent 的实践经验，系统阐述了如何通过知识底座、数据底座、受控状态机与全链路可追溯等机制，将原本发散的 Agent 改造成一个“宁可不答、不能答错”的严格受控系统。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 应用场景：Agent 在金融监管中要解决什么 今天我想聊的，是一个和前面几场分享在技术取向上有所不同的领域——金融监管。上午和下午早些时候各位老师讲的内容覆盖面很广，技术本身的通用性也更强，而我所在的这个方向非常垂直。大的领域叫金融，金融下面还可以细分出监管、风控、营销等多个子领域，我关注的是其中的金融监管，更具体地说，是金融监管报送中与数据准确性密切相关的一类工作。 上午有老师提到，数据准确性做到百分之九十七已经很不错了。但在我所处的这个场景里，九十七只是一个初步的概念，实际要求要比这高得多。也正因为有这样的极高标准，金融监管领域里积累了大量需要谨慎处理的生产实践。来之前我注意到一种声音，认为我们是在给大模型嫁接过多约束、限制了大模型的能力，算不上好的实践。我的看法恰恰相反：在一个极其谨慎的生产环境里，这类约束是不可缺少的。今天我想把过往做的一些工作串联起来，讲清楚我们在这个领域里到底怎么做的，方案是什么，以及它能给其他同样谨慎的行业提供什么参考。 先看应用场景。金融监管的制度背景是：我国所有金融机构——银行、财务公司、小贷公司——都受到强监管要求。监管的核心动作叫“报送”，也就是金融机构把自身经营过程中的关键信息报送给监管机构，由监管机构进行审查。这项工作在小型金融机构里大约占到三分之一的工作量，在大型金融机构也能占到五分之一。它本质上是一类成本型工作，但监管要求非常多。就罚款而言，今年前半年整个行业的罚款规模已经达到数亿级别，单家大型金融机构在去年被罚几个亿，小型机构罚款几百万、几十万的情况也屡见不鲜。在这个环境下，如何把报送工作做得更精准，对金融机构的影响非常直接。 这个场景有四个非常鲜明的特点。第一个特点是口径复杂，解释口径意味着我们获取一个数据时，需要清楚它到底指的是什么。一个贷款信息在金融机构内部，信贷部门、财务部门、统计部门给出的结果可能都不一样。口径不仅复杂，而且在组织内部潜移默化地被人各自理解。第二个特点是频度高。这类数据处理有按月的、按旬的、按周的各种节奏，处理过程相当繁复。第三个特点是最核心的一点——零容错。前面说了，百分之九十七的准确率远远不够，这里要求百分之百，一个数都不能错。我们的原则是宁可不报，也不能报错。第四个特点是强追溯。数据出来之后，如果发现业务出了问题，比如某笔贷款存在违规放贷，这套数据必须能够被完整地追溯回去，定位到究竟是哪个环节造成的。因为我们是数据驱动的，这是四个不容犯错的问题。 我们做金融监管相关的 Agent 工作已经两三年，这期间经历过几个最棘手的痛点。 第一个痛点是口径漂移。前面说到口径很重要，但很多地方的解释并不清楚，也没有统一标准，口径漂移因此成为最严重的问题。举一个小微企业的例子：去年国家提出“五篇大文章”，支持五个重点产业方向。但要统计其中的小微企业到底该按什么口径来算，换一个思路、换一个口径，数据就会出现很大差异。业务口径看起来没变，但数据口径可能截然不同。第二个痛点是幻觉。金融机构处于强监管环境，所有业务规范都来自监管机构的明确发文。这些发文如果直接交给大模型处理，模型往往会根据自己的理解去推理，生成一些实际并不存在的范围，也就是我们前两年常说的“一本正经胡说八道”。这在监管场景里是绝对不能接受的。第三个痛点是不可解释。在 2018、2019 年前后机器学习阶段，不可解释问题基本无解。到了现在这个 AI Agent 阶段，我们每出一个数、每一次计算都需要有合理的归因：这个数到底怎么来的，它的链路是什么，为什么是这个数而不是别的数，这些都需要清晰的回答。 这三个痛点的共同根源在于 Agent 在自由发挥。一方面，我们希望 Agent 去自由发挥，填补我们考虑不到的内容；另一方面，我们又担心它的自由发挥造成“思想的漂移”，让数据处理变得不可控。在监管的要求下，它更多需要的是“照章办事”，而不是过度发挥。监管领域里也有非数字类的工作，比如写一些报告，这些内容相对不敏感，但对于数据处理类的任务，自由发挥是不可接受的。 那么 Agent 在这个需求里具体介入哪些环节？我把它分成四段。第一段是需求侧，涉及对监管要求的理解，再结合银行内部的指标体系，上午有同事分享过指标体系的建设——通过指标、数据资产、知识资产来自动化生成监管要求相关的处理过程。 第二段是报送中的审核与复核，包括数据加工过程的检查、指标计算、指标自动质量检查，以及对异常数据的实时提醒。比如数据比上个月上升了百分之三十或者五十，或者明显不符合监管要求，这些都可以通过 Agent 在过程中实时发现。有人会问，这部分用规则模型不就行了吗？我们的经验是规则模型永远覆盖不了百分之百，不可能一次性拿出几万条规则全量覆盖。所以我们的做法是让 Agent 结合数据特点，针对每一期数据实时生成它认为当下更合适的一批规则，然后执行，这样更有效。 第三段是问题处置。人在处理数据时必然会出错，或者计算结果有问题。这个问题到底是原始数据不对、处理过程出错，还是业务本身就有问题？这三类情况都需要定位、修复、根因分析、追溯和血缘分析。血缘和追溯在数据领域非常重要，但坦白讲，行业里直到今天也没有哪家敢说把追溯和血缘做得非常完美。金融机构一般有原业务系统、中间数据中台、各级集市到业务应用，加起来超过十五层的数据处理链路，要把血缘分析清楚、追溯逻辑搞明白，本身就是极困难的事。这个部分我们现在通过 Agent 来做，取得了很好的效果。 第四段是报送前的复核。数据已经有了，但到底对不对？每家金融机构每期报送前都会花大量人力去检查。这个检核的核心是相互交叉检验：用自己的台账、其他系统、对外暴露的其他侧面数据做相互印证。我们在报送前先通过 Agent 把这些数据联合起来，综合产出一份复核报告，然后让业务员确认这次数据是否能正常报送。报告会告诉业务员，比如百分之九十以上的概率可以报，百分之十可能存在问题的部分，以及每个问题背后的原因是什么。 场景反过来给 Agent 提出了四个强制要求。第一是口径受控，不允许 Agent 去发散口径，不允许它自行理解。口径在监管机构和银行内部都有非常清晰的定义，拿出来用就行，我们只允许它读取已有的口径信息。第二是数据可查、强追溯，每次取数都要走受控通道。金融机构里同一数据往往存在多个系统中，到底从哪个系统取，必须预先定义好路径。第三是逻辑可查，处理过程中调用了哪个能力、引用了哪条规则，都要处于受控状态。第四是能力可复用，监管数据不是一次性的，今天能算出这个数，明天还得用同样的链路算出同样的结果，不能今天一个值、明天另一个值