如果把“智能风险评估AI Agent”这个项目名拆开看它其实是在说两件事一是把大语言模型LLM引进金融风控流程二是让它以Agent的形态干活——不是用户问一句它答一句而是它能自主决定先看哪些材料、调哪些数据源、最后产出什么格式的结论。我最近在一个面向中小企业客户的信贷风险评估模拟项目里完整落地了这么一套东西今天把从方案设计到实际踩坑的全过程梳理出来给正在这个方向试水的朋友做参考。这套系统最终交付的是一个文本底稿输入财报文本、舆情摘要、工商登记信息、行业动态和团队内部的风险制度它自动归纳出风险因素、证据来源、不确定性点以及建议人工重点复核的问题生成一份结构化的风险评估初稿。以前人工做这一步单客户至少两三个小时系统跑完一轮大约十几分钟人的工作从“从零阅读”变成了“拿着底稿复核”。听起来很美好实际开发中也有很多细节要处理。这篇文章会写清楚每个关键选择背后的原因也把踩过的坑一并列出来。1. 为什么需要一个能“想”的风控助手1.1 传统风险评估流程的堵点信息过载而非信息缺失做风险评估的人每天面对的并不是信息太少而是信息太多后处理不过来。工商数据在企业信用系统里财务数据藏在报表附注里舆情散落在新闻和社交平台历史类似案例躺在以前的存档报告里。要把这些信息拼成一份逻辑完整的评估底稿靠的是人工逐条阅读再靠经验判断哪些信息相关、哪些只是噪音。这个流程有几个固定痛点。第一阅读长文本非常费时一份几十页的财报附注里可能只有几段话是真正影响判断的第二判断标准不统一同样一条舆情不同评审人解读出的风险程度可能完全不同第三历史知识复用困难去年的案例今年可能没人记得大量经验沉淀在个人脑子里而不是机构资产里第四底稿撰写格式难以保持一致复制粘贴痕迹重格式问题还要花时间调整。这些问题的本质是风险评估的核心动作其实包括“信息收集、语义理解、交叉验证、观点生成”四步其中后三步都高度依赖自然语言处理能力而这恰恰是传统规则系统和评分卡模型很难覆盖的地方。规则系统擅长抓取数字指标比如资产负债率超过多少就预警但它看不懂“应收账款集中度显著上升并且关联方占比较高”这种表述背后隐含的流动性风险。1.2 LLM真正能帮上忙的环节读、比、写LLM的强项刚好落在这些传统方法覆盖不到的环节。它能通读长文本并归纳要点能同时对照多份材料做一致性比对还能基于固定的报告模板生成结构完整的底稿。我在项目中主要让它承担三类任务一是从描述性文本里抽取风险信号二是把多个来源的事实拼在一起判断它们之间是互相印证还是存在矛盾三是按照预先设定的章节结构生成评估报告初稿包括风险因素列表、证据摘要、需要人工复核的问题清单。但有一点必须明确LLM不适合用来做概率测算或精确数值判断也不适合在没有依据的情况下做预测。例如“这个企业未来一年违约概率是百分之几”这种问题模型给出来的数字往往是统计幻觉看起来严谨实际没有可靠依据。所以项目边界从一开始就设为“辅助做语义理解和文书生成”数值建模交给专门的评分模型Agent只负责把相关信息整理成模型和人都能用的格式。1.3 项目边界辅助决策不替代判断为了不让项目失控我明确划定了三条边界。第一Agent只生成初稿不拥有最终决定权所有输出都要经过至少一名有经验的评审人确认。第二Agent的输出必须带证据来源每一个风险因素都要对应到具体的材料片段ID。第三Agent的每一步操作都写入审计日志包括它调了哪个接口、拿到了什么返回值、依据什么生成了哪段结论。这三条规则是整个系统的地基后面所有模块设计都围绕它们展开。这个项目适合谁参考呢如果你正在做企业信贷、供应链金融、投融资尽调这类领域的智能化改造或者你只是对LLM Agent落地感兴趣想看看真实业务场景里会遇到哪些问题这篇文章会对你很有用。2. 整体方案怎么定辅助式Agent而不是自动决策体2.1 Agent形态怎么选先理解三档路线Agent的形态没有标准答案我把它分成了三档。第一档是工具调用型Agent模型看到用户问题后自己决定是否调用检索或API工具用完工具再回答。优点是灵活缺点是路径不确定同一个问题可能每次走的流程都不一样这在金融场景里很难做审计。第二档是固定流程型Agent业务方先把步骤写死比如先查工商再查舆情再读财报Agent只负责填内容好处是稳定、可追溯坏处是遇到预料之外的情况容易卡住。第三档是自主规划型Agent模型完全自我规划可以处理特别复杂的任务但可控性最差现阶段直接用于生产风险太大。我实际选择的是第二档和第三档的结合主流程固定每个流程节点内部允许少量自主调度。用一个贷前筛查case举例流程预定义为“材料解析→工商信息核验→舆情扫描→财务文本分析→风险归纳”。但在“舆情扫描”这个节点内部模型可以自主决定先搜索哪些关键词、调用几次查询接口、对返回结果按什么维度聚类。这样既保留了对核心流程的控制又让Agent有足够灵活性应对不同客户的具体情况。2.2 系统模块划分五个核心组件各自负责什么整个系统分五个核心模块。任务解析器负责把输入的需求拆成可执行步骤比如用户上传一份企业名单它先理解这是要做批量筛查然后拆解成多个独立case。知识检索模块负责从向量化的知识库里召回制度文本、历史案例和行业画像供模型引用。工具执行模块统一封装外部接口调用包括工商信息、公开舆情抓取、企业关联关系等数据源返回结构全部标准化。上下文管理器维护每个case的独立会话状态记录已经完成了哪些子步骤、中间结果是什么避免多轮交互里信息丢失。生成与校验模块负责把中间结果汇总成最终报告并按预设规则检查输出质量。这五个模块的关系有点像一条餐饮流水线任务解析器相当于点单知识检索模块是厨房里的食材库工具执行模块负责从外部现买食材上下文管理器盯着每道菜做到哪一步生成与校验模块负责装盘和检查把关。模块拆得清楚之后单独替换任何一环都不影响其他部分后面迭代才快。2.3 金融场景的硬约束可解释、可追溯、可拦截金融场景的硬约束比技术本身更值得先想清楚。可解释性方面报告里的每个结论都必须能回溯到原始材料不能有模型自创的依据。可追溯性方面每一次模型调用、工具调用、结果变换都要落日志出了问题才能做回放分析。可拦截性方面系统必须设计人工复核节点Agent生成的初稿默认不能直接对外使用必须经过状态流转待复核→已复核→已使用。还有一条特别重要数据边界。外部接口调用时不能把客户敏感字段直接传给第三方服务日志记录里也要做脱敏身份证号、手机号、银行账号这些字段要用掩码处理后再写入存储。这个不是一开始就想得那么细是后来做安全评审时补的建议大家在设计阶段就纳入。一句话总结架构选型原则AI做初稿人来做决定。设计系统的任何时候用这个原则去判断功能取舍都不过时。3. 核心环节实现要点拆解知识库、检索、工具调用与输出控制3.1 知识库构建把制度、案例和行业画像变成可检索资产知识库是整个检索链路的地基。我先整理了四类内容进库。第一类是内部制度文件比如风险评估操作指引、授信审核手册这些决定Agent回答“按公司规定应该怎么办”时引用的口径。第二类是脱敏后的历史案例从过去做过的风险评估底稿里抽取典型段落做成一个个案例条目让模型可以参考类似行业、类似规模企业过去出现过什么问题。第三类是行业风险画像覆盖制造业、贸易、科技、餐饮等常见行业的基本风险特征。第四类是公开规则条目比如一些通用财务指标的解释和判断惯例。文本切分是最容易低估难度的地方。我一开始按固定字数切比如每512个字一段结果很多段落把表格和正文、标题和内容切散了检索的时候召回了半截信息模型引用时张冠李戴。后来改为按文档结构切先解析标题层级识别章节边界再对每个章节内的内容按语义段落切分段落不超过一定长度并且给每个段落保留文档ID和标题路径作为引文来源。嵌入模型的选择直接影响检索质量。我的经验是优先选中文效果好并且上下文窗口足够匹配段落长度的模型不要图省事随便拿一个小模型跑长文本效果差距会在召回质量上直接体现。知识库更新要带上版本号制度文件一旦修订要整体替换对应索引不能新旧混着放否则模型可能引用到已经废止的旧规则。3.2 检索与路由不是每个问题都需要走知识库RAG不是万能的无脑套RAG反而会把简单问题复杂化。我给系统加了一道路由层先判断用户问题属于哪一类型。如果问的是通用问题比如“报告章节目录有什么”直接用大模型回答即可如果问的是制度相关问题比如“单一客户授信余额上限是多少”才走制度知识库检索如果问的是某个企业当前的状态比如“这家公司最近有没有新增诉讼”就要走工具调用去拿外部数据。这相当于先分流每个问题走最短路径省时间也省token。检索本身也不是单一向量召回就够。实际测试下来向量检索对同义改写很有效但遇到专有名词和企业名时经常漏检。我在向量之外同时跑一遍关键词匹配把两种结果按一定权重混合排序能明显提升召回质量。Top-k固定在5左右太多会让模型在信息堆里找不着重点太少又容易漏关键证据。还有一点容易忽略同一问题分散在多个知识条目里可能互相矛盾。所以在检索结果送进大模型之前我会增加一步简单的冲突检测把明显对立的条目标注出来提示模型在报告中单独列出“存在冲突的信息”并交由人工判断。这一步不复杂但对降低幻觉帮助很大。3.3 工具调用通过API给Agent装上“实时眼睛”工具调用的设计质量直接决定了Agent接到的数据是新鲜的还是过期的。我定义了一张工具注册表每个工具包含名称、功能描述、入参格式、出参格式四个字段。模型看到用户需求后根据描述自己决定要不要调用、传什么参数。比如用户想问某企业的舆情情况模型就应该选择“舆情搜索”工具而不是“工商信息查询”工具。描述写得越清楚选择准确率越高。工具返回的数据必须标准化。无论原始接口返回什么格式统一包装成JSON包含状态码、业务数据和错误信息。出参字段名要规范比如财务数据统一用revenue、total_liability不能用不同来源的同义不同名字段否则模型容易混淆。还要设计超时和降级逻辑外部接口偶尔不稳定超时之后重试一次仍然失败就把该数据源标记为“暂缺”明确告诉模型不要猜测缺失数据最后在报告里注明哪些信息未能获取。权限分级也很关键。我把工具分成两类可以自动调用的比如公开舆情、工商公开信息需要人工确认的比如涉及客户敏感数据的查询接口。后者在Agent发起调用时先进入待确认队列由人工点击允许后才执行。这样即便Agent误判也不会越过权限边界。3.4 结构化输出与幻觉控制让结果能被复核、被落库为了让报告能被后续流程解析和存档我要求Agent输出结构化JSON而不是自由文本。结构里包含风险因素列表、风险等级、证据来源、不确定性点、人工复核建议。风险等级枚举只有“高、中、低、未知”四个值出现第五个值就校验失败。关键做法是few-shot演示。给模型两三个完整示例而不是只描述格式要求输出稳定性会大幅提升。同时把输出Schema也放进提示词用JSON格式喂给模型比只用自然语言描述要稳。提示词里我还会明确要求没有依据的项目填“未知”或者“暂无法判断”不强行编造。输出之后还有一道校验。用解析器把模型返回的JSON解析成结构化对象校验枚举值、必填字段、证据编号是否存在。如果出现解析失败或字段缺失可以让模型基于原上下文重新生成一次并附上解析错误信息。为了保证格式稳定温度参数我设得比较低基本在0.2以下。金融场景里稳定优先创造性发挥反而不重要。幻觉控制是这个方向绕不开的话题。我的做法有三层第一层在提示词层面要求“没有证据就承认不知道”允许输出不确定性第二层在检索层保证提供给模型的信息都是真实存在的段落减少编造空间第三层在输出后做证据回查把报告里填的source_id到知识库和工具缓存里逐一确认确认不了的就自动标为“待人工核实”。三层下来能拦住大多数凭空捏造的结论。3.5 Agent工作流编排从“问一句答一句”到“多步骤任务”Agent工作流设计上我采用了一个主循环理解输入→生成计划→执行子步骤→汇总中间结论→生成最终报告。子步骤的类型限定为三种检索知识库、调用外部工具、分析已有材料。模型可以多次执行这三种动作但总步数有限制我设了10步上限超过就强制进入报告生成阶段避免模型陷在某个环节反复打转。上下文管理是我最早忽略、后来吃了亏的地方。每个case的上下文必须隔离不能让A企业的信息串到B企业的报告里。同一case内部中间结果要持久化保存每一轮新动作都能看到之前积累了哪些材料。我用了内存数据结构加日志落盘的方式简单够用。长文本场景下还做了摘要层原始材料全文保留但每份材料先产出一段摘要后续生成报告时优先用摘要需要细节再单独检索原文。4. 实操复盘一天搭出最小可用版本4.1 环境准备一套能跑通的最小技术栈技术栈尽量保持简单。我用的Python 3.10Web层用Flask或FastAPI这类Python框架选一个顺手的就行。向量存储用开源向量库本地跑足够。大模型接口需要支持工具调用和JSON输出商用API或开源模型均可只要能力够。主要依赖就是pydantic做数据结构校验、requests做外部调用、以及向量库的Python SDK。整套东西跑在独立容器里数据访问走内网不直接暴露公网。这里有一个选型建议如果你的部署环境对数据有严格边界要求优先考虑完全私有化部署的模型虽然效果可能要打点折扣但合规底线不能含糊。如果只是做原型验证调用商用API更省事。先把流程跑通再考虑效果优化这是我一贯的做法。4.2 核心代码实现思路两个关键脚本核心代码其实不复杂。我先把输出结构定义清楚。使用pydantic可以同时完成格式约束和自动校验。下面这段是一个简化示意from pydantic import BaseModel, Field from typing import List class RiskFactor(BaseModel): factor: str Field(description风险因素描述) level: str Field(description风险等级高/中/低/未知) evidence: List[str] Field(description支持该风险因素的材料片段列表) source_ids: List[str] Field(description证据来源ID列表) class RiskReport(BaseModel): summary: str Field(description总体风险摘要) risk_factors: List[RiskFactor] Field(description风险因素列表) uncertain_points: List[str] Field(description不确定性点没有证据的推断必须写在这里) manual_review_items: List[str] Field(description需要人工重点复核的问题清单)然后Agent主循环可以抽象成下面这个逻辑。注意这里不绑定任何特定框架接口调用统一用call_llm函数承接。def run_risk_agent(case: dict, retriever, tool_executor, max_steps: int 10): context { materials: case[materials], retrieved: [], tool_results: [], intermediate: [], } for step in range(max_steps): action call_llm_decide_next_action(context) if action[type] finish: break if action[type] retrieve: result retriever.search(action[query], top_k5) context[retrieved].extend(result) elif action[type] tool: result tool_executor.invoke(action[tool_name], action[params]) context[tool_results].append(result) elif action[type] analyze: result call_llm_analyze(context, action[instruction]) context[intermediate].append(result) report call_llm_generate_report(context) parsed RiskReport.model_validate(report[json]) return parsed代码本身没什么玄学关键在于每个动作的结果都被记录进context最终生成报告时模型能看到全部中间产物。这样即使某一步出现问题也可以通过日志回放定位。我还加了一个小技巧在模型选择下一步动作时让它先输出一段简短的理由比如“下一步需要查这家企业的工商信息因为材料里缺少股权结构数据”再输出动作类型。这段理由不参与最终报告但能帮开发和复核人员理解Agent的决策路径。4.3 评测指标设置怎么证明它真的有用没有评测指标系统好不好全凭感觉这在Agent方向是灾难。我建了一个固定评测集收集了三十个历史风险案例每个案例包含原始材料和人工终审报告。系统跑完一遍拿输出和人工版本对照看几个指标风险因素召回率人工报告里列出的关键风险系统是否都有提到报告完整率章节是否齐全、字段是否填全、格式是否合法来源准确率抽查十条证据是否真的来自对应材料平均处理时长从提交到出报告的时间人工修改率复核人员在底稿上实际改动的比例单案例token成本评估一条case花了多少token。这些指标列成一个表格每次改动模型或知识库后都跑一遍回归数字变化一目了然。没有评测集的Agent项目后面根本没法谈优化。指标目标值说明风险因素召回率≥85%与人工终审报告中的关键风险点对比报告完整率≥95%结构化字段是否完整、合法来源准确率≥90%证据回查通过比例平均处理时长≤20分钟单案例运行耗时人工修改率≤30%复核人员实际修改内容的占比单案例成本可视化统计每次优化前后对照4.4 成本与延迟控制算清楚每一笔token成本和延迟我单独拎出来说因为这是生产化最容易被卡住的地方。一次完整case处理大概会发生三到五次大模型调用包括步骤决策、文本分析、报告生成。早期我按最大token预留单case成本偏高后来做了三件事第一同样的检索query走缓存知识库内容不变就不重复计算第二长材料先出摘要后续分析尽量基于摘要需要细节再局部检索原文避免每轮都把全文塞进上下文第三报告生成阶段限定一轮生成不搞多轮自纠大幅省token。延迟方面单case整体能控制在十几分钟主要时间花在长文本分析和报告生成上工具调用本身很快。还有并发控制Agent任务如果同时跑太多大模型API限流和内存开销都会放大。我加了个简单的任务队列同一时间最多跑三个case其余排队。金融场景对时效的容忍度相对较高稳定比快更重要。5. 踩坑记录与排查速查表真实生产环境里的修复实录5.1 高频问题实录五个典型故障和现场修复下面这些坑都是我实际踩过的按频率排个序。头号问题是模型只读了摘要不读原文导致证据引用不精确。比如舆情工具返回了一条包含标题和正文的JSON模型在写证据时只引了标题实际结论可能和正文有出入。解决方法是严格规定所有引用必须落在正文原文片段上标题不能作为依据同时把正文前置摘要放后面。第二个高频问题是Agent在某个动作上反复打转。比如连续三次调用同一个舆情搜索接口只是关键词略有不同浪费token不说还把上下文搞得冗余。我在系统里加了一个已完成动作清单把工具名和参数摘要写进去模型在决策下一步时能看到自己已经做过什么。再配合步数上限基本能解决。第三个问题是知识库切分导致的检索错乱。固定长度切分把表格拆开、把制度条款从所处章节中分离结果模型检索时引用了不完整的上下文。后来改成结构感知切分表格单独解析条款按标题层级归属召回质量明显改善。第四个问题是JSON输出偶发截断。原因通常有两个模型生成长文本到一半撞上输出长度上限或者特殊字符导致解析失败。我在输出完成后先做解析失败就把错误信息回传给模型重新生成一次。重新生成时把返回格式要求压缩得更短成功率高很多。5.2 排查方法论日志、回放和固定案例集排查方法论上我养成了三个习惯。第一所有模型调用和工具调用都要落结构化日志内容包括时间、动作类型、入参、出参摘要、token用量、耗时。没有这些日志出了问题只能靠猜。第二每个case保留一份完整底稿包含输入材料清单、检索结果列表、工具返回记录、中间分析结论、最终报告这份底稿既给人复核用也给开发回溯用。第三评测集固定每次改动后跑一遍回归对比关键指标变化防止修了一个问题又引出另一个问题。遇到诡异问题我的定位方法很简单把一次case的运行日志按时间顺序拉出来看模型每一步看到了什么、做了什么决定、工具返回了什么通常就能定位问题出现在哪一环。是检索没召回到位还是工具数据源出错还是模型决策逻辑不对一目了然。5.3 三条避坑心法通行有效的经验最后说三条避坑心法。第一条初版永远只做最小闭环先跑通一个case的完整链路再谈功能丰富度。如果第一版就想把所有数据源都接上大概率连一个case都跑不顺。第二条在提示词里反复强调“不要猜测”允许模型对缺失信息说不知道这比任何后处理都更能有效防止幻觉。第三条敏感数据保护要前置不要在日志里记录明文身份信息不要将客户数据直接传给外部服务这个修正成本越早越低。这些经验不是从文档上学来的都是实际在项目里被坑出来再总结的。写出来供大家参考少走几个弯路。6. 落地效果评估与下一步扩展空间6.1 实测量产数据从2.5小时到15分钟量化一下效果。在模拟项目的数据集上单案例平均处理时长从人工的约150分钟降到系统跑完约15分钟报告章节完整率保持在95%以上人工在底稿基础上的修改率在可接受区间。这不是说AI能替代风控人员而是说原本花在通读材料和起草文书上的时间大幅压缩后人可以腾出精力去处理真正复杂的部分判断那些没有历史样本的异常情况审阅Agent标出的不确定性点以及和客户做进一步访谈。过程中的一个对比案例让我印象很深一个贸易类企业财报里资产负债率变化并不大但应收账款明细显示前五大客户集中度明显上升且其中一家客户近期有较多法律文书。人工复核前需要把这些信息自己串起来系统在初稿里直接列出了相关证据并标注了这条线索复核人员只需要确认逻辑是否正确。这种“提前帮你把线索串好”的体验才是Agent在这类场景里真正的价值。6.2 可以继续扩展的方向后面可以扩展的方向很多。数据源层面可以接入企业关联关系图谱、发票流水异常检测结果让Agent不只是读文本还能用结构化数据做交叉验证。模态层面财报PDF、合同扫描件这类材料可以OCR之后再进知识库让Agent能处理更复杂的原始凭证。流程层面可以把初审Agent、复核Agent、追踪Agent拆开各司其职。模型层面定期用人工修订后的报告补充评测集跑回归并微调提示词让系统在持续使用中缓慢但稳定地进步。如果让我重新做一次这个项目我会在第一天就做两件事把评测集建好把日志打全。因为后面所有调优、所有问题排查、所有效果说服都依赖这两件事。技术上其他内容都可以快速重来唯独这两样是时间堆出来的耽误不得。
