我参与过的金融风控项目里，有个让人印象特别深的场景：业务方拿过来一家中小企业的资料，要求在一小时内给出初步信用评估结论。传统做法是人工翻阅财务报表、检索公开信息、电话核实关键数据，一套流程下来至少半天。后来有幸在一个模拟项目X里，和团队一起把LLM驱动的智能风险评估AI Agent落地到了这个环节，效果远超预期——评估时间缩短到十几分钟，而且可解释性、留痕能力比人工整理还要规范。这篇内容我想从实际落地的角度，把整个智能风险评估AI Agent的架构设计、关键技术、踩坑过程都拆开来讲清楚，希望能给正在做类似方向的朋友一些可参考的经验。
这个方向适合谁？如果你的工作涉及金融风控、信贷审批、反欺诈，或者正在用大模型做垂直行业应用，但苦于Agent只停留在“聊天问答”层面、没法真正解决业务问题，那这篇应该能给你不少启发。我们当时的目标很明确：不做一个炫技的Demo，而是一个能嵌入到真实业务流里的评估助手。
1. 项目背景与需求拆解：为什么风控场景需要LLM Agent
1.1 传统风险评估的核心痛点
传统风险评估系统大概分两类：一类是专家规则引擎，人工定义几百上千条规则，命中即触发预警；另一类是统计模型，用逻辑回归、随机森林、XGBoost这类算法，基于历史违约样本训练打分卡模型。这两类方法都已经运行了很多年，实际效果也确实稳健，但它们有个共同短板：对“非结构化信息”的处理能力非常弱。
打个比方，评审一笔贷款时，业务员会去看企业官网的新闻动态、行业研报里的上下游分析、甚至企业实控人在公开场合的发言纪要。这些信息里其实藏着不少风险信号——比如某公司忽然大量裁员、核心供应商出现资金链问题、行业政策方向突变——但它们以自然语言的形式散落在各处，规则引擎没法消化，统计模型的特征工程也很难覆盖到这么细的粒度。
我们团队当时做了一个很现实的统计：一个普通风控分析师一天能深度评估的企业数量大概在5到10家，而且到了下午注意力下降，漏看的风险点会明显增多。而智能化的评估Agent可以做到7×24小时工作，分钟级产出一份结构化评估报告，把基础信息核对、舆情抓取、财务异常初步筛查这些环节自动完成，人工只需要把精力集中在最有价值的判断环节上。
1.2 为什么LLM Agent比单纯的LLM调用更合适
刚开始接触这个方向时，不少人会问：直接调大模型接口，把企业资料丢进去让它“分析”不就行了吗？理论上确实可以，但在真实的金融场景里完全行不通。原因有三点。
第一，单次LLM调用是无状态的。你今天问它这家企业怎么样，明天问同一家，如果没有记忆机制，它的分析逻辑无法保持一致，这在风控这种对一致性要求极高的场景里是致命的。
第二，风险评估需要接入外部数据。企业的工商信息、司法涉诉、新闻舆情、财务数据，这些数据散落在多个数据源里，LLM本身并不具备实时获取的能力，需要Agent机制去调用各种工具和API。
第三，金融场景要求每一个结论都有依据、可追溯。LLM直接生成的分析结论往往是“黑盒”的——它可能得出“该企业偿债能力较弱”的结论，但不告诉你这个结论是基于哪条财务指标、哪条舆情信息得来的。而Agent可以强制工作流中的每个判断环节都留下证据链。
所以真正有价值的不是“调用LLM”，而是“让LLM具备完整的评估工作流能力”。这个过程本质上是在设计一套思考框架，再让LLM在这套框架里扮演核心推理引擎的角色。
1.3 核心业务目标拆解
我们启动项目前，先跟业务方一起把需求拆成了四个明确的指标：
- 时效性目标：单次企业风险评估从原来的半天缩短到15分钟以内。
- 覆盖率目标：需要检查的评估维度不少于人工评估的90%，不能因为用了AI反而漏掉该看的维度。
- 可解释性目标：每一个风险结论必须能溯源到具体的证据条目。
- 人工复核率目标：初期允许高风险结论全部转人工复核，但中低风险结论的复核率要控制在30%以下。
这四个指标后来成为了整个系统设计的主线。每当技术方案争论不下时，我们就回到这四个目标上找答案——这个方案能不能满足时效性？能不能保证覆盖率？结论能不能溯源？复核率是否合理？
2. 系统总体设计与技术选型：Agent架构是怎么搭起来的
2.1 整体架构分层
整个Agent系统的架构我们分成了四层，每层各司其职：
- 接入层：负责接收评估请求。请求可能是业务员手动提交的资料包，也可能是上游系统通过接口推送的企业批次名单。
- 编排层（Agent核心）：这是整个系统的大脑。它接收任务后，把“风险评估”这个大任务拆解成若干子任务——企业基础信息核查、财务数据提取、舆情风险扫描、行业风险分析等，然后按依赖关系编排执行顺序。
- 工具层：封装了一系列可调用的外部能力，包括企业工商数据查询接口、司法涉诉查询、新闻舆情检索、财务计算引擎等。这一层让Agent有了“手”，可以实际操作外部系统。
- 输出层：生成结构化的风险评估报告，推送至审批系统，并在必要时触发人工复核流程。
架构的关键在于编排层。我们对比过几种技术方案：用现成的Agent编排框架，或者自研调度模块。最终选择了一个折中方案——基于成熟框架做二次开发。原因很实际：成熟的编排框架在任务调度、重试机制、上下文管理方面已经沉淀了很多最佳实践，完全自研虽然可控性强，但会消耗大量时间去处理基础问题，因为金融项目最缺的其实是时间。
2.2 模型选型：通用模型还是垂直模型
模型选型是整个项目里争论最激烈的话题。当时有几种倾向：有人主张用参数量更大的通用模型，认为理解能力更强、分析更全面；有人主张微调一个金融领域的垂直模型，认为领域术语理解更准确。
我们最终走了第三条路线：基座用通用模型，但通过“强提示词约束+领域知识外挂”来解决专业性问题。没有直接微调领域模型。原因是基于当时的实际情况：
- 微调需要大规模的高质量标注数据，而金融风险评估的标注数据本身就稀缺且高度敏感，合规审批流程长。
- 通用模型在逻辑推理、长文本理解方面表现已经够用，欠缺的主要是金融领域知识，这个完全可以通过RAG（检索增强生成）来解决。
- 通用模型持续迭代，微调模型一旦落后版本，重新训练的成本会持续累积。
这个决策后面被证明是对的。比起微调，我们通过构建高质量的评估知识库和提示模板，让模型的输出稳定性和专业度都达到了业务可用的水平，同时保留了快速迭代的空间。
2.3 工具层设计与数据接入
工具层设计是另一个花费大量精力的地方。当时可接入的数据源包括工商注册信息、司法涉诉记录、税务评级、新闻舆情、招投标数据等。每个数据源的接口协议不同，有的返回JSON，有的返回PDF，有的只提供网页查询。
我们做了一套标准化的工具封装规范，每个工具都必须实现三个方法：参数校验、数据获取、结果归一化。核心思路是：所有来源的数据经过工具层处理后，统一转换成结构化条目格式，这样上层Agent就不需要关心数据源的具体协议差异了。
这一点对后续的评估质量至关重要。因为LLM最怕的就是输入数据格式混乱。你给它一段格式统一的JSON，它提取风险信号的准确率会高得多；你给它十几个格式各异的原始文档，它就容易丢三落四、抓错重点。
2.4 工作流状态管理与记忆机制
Agent在做一次完整评估时，会经历多个阶段的多次LLM调用。如何管理这些调用之间的状态，是系统稳定性的关键。
我们设计了一套会话级的工作流上下文，里面主要包括几个部分：企业基础信息档案、各数据源返回的结构化证据条目、已生成的阶段性分析结论、待确认的风险疑点清单。每次任务推进时，新结果会被追加到上下文中，并同步更新一个全局状态表。
这套机制的核心价值是：让整个评估过程可暂停、可恢复、可回放。如果某一步调用的数据源超时了，系统不会从头开始，而是把已完成的步骤缓存，等数据源恢复后从断点继续。评审人员也可以随时回放整个评估过程，查看每一步的输入输出，这在金融合规场景里极其重要。
3. 工作流编排与Prompt工程：把风险评估流程变成Agent可执行的动作
3.1 评估流程的分阶段设计
我们按照业务专家的评估思路，把整个评估过程拆成了七个阶段：
- 企业基础信息核验——确认工商注册信息、实际控制人、股东结构。
- 财务数据提取与初步分析——从财报中提取关键指标，计算初步的偿债能力、盈利能力、营运能力指标。
- 司法涉诉与行政处罚扫描——检索历史司法案件、被执行信息、行政处罚记录。
- 舆情风险监测——抓取近期与企业相关的新闻，识别负面信号。
- 行业与宏观环境分析——结合企业所在行业的特点，评估行业整体风险。
- 综合风险评估——汇总以上维度，生成整体风险等级。
- 报告生成——输出标准化的风险评估报告，附证据链。
之所以采用这种串行分阶段的方式，而不是让LLM一次性输出全部分析，是为了控制单次任务的复杂度和保证每一维度的完整覆盖。每个阶段都有独立的Prompt模板和输出格式校验，确保该阶段的产出结构稳定。
3.2 Prompt模板设计的关键技巧
Prompt模板是这套系统里投入迭代次数最多的部分。目前线上在用的模板迭代了十几个版本，我挑几个关键经验分享。
第一，角色设定不宜过度拟人化。很多Prompt喜欢写“你是一位资深风控专家”，这句话对输出质量有影响吗？我们的实测显示没有显著影响，还容易带来一个副作用：模型更容易发挥“想象力”，产生一些不存在的细节。后来我们把它替换成了更务实的表述：“你是企业信用风险评估系统中的自动分析模块，请依据给定证据进行分析，不要推测证据之外的结论。”这个调优直接降低了幻觉出现的概率。
第二，输出格式约束要用双重规范。我们不仅在Prompt里描述要求输出的JSON结构，还用一段示例输出作为结构化规范——注意是给出格式示例，不是给“参考答案”，两者有本质区别。模型看到具体格式示例后，输出格式的稳定性明显改善，JSON解析报错率从初期的15%降到了3%以下。
第三，每个子任务都要有“信息不足时的处理策略”。这是金融场景和普通问答场景的最大差异。普通问答里，信息不足时模型可以自由发挥补充内容；但金融评估不行。我们的Prompt里明确写了一句：如果给定证据不足以对某个维度作出判断，请明确标记为“信息不足待补充”，并列出需要补充的具体资料清单，禁止自行推断。这一条对控制风险很关键。
3.3 Agent工作流核心代码示意
下面是一段简化版的Agent工作流核心调度逻辑，使用的是Python伪代码风格，展示了我们当时的设计思路。生产环境的代码比这个复杂得多，但核心框架基本一致。
class RiskAssessmentAgent: def __init__(self, llm_client, tool_registry, context_manager): self.llm = llm_client self.tools = tool_registry self.context = context_manager async def run(self, task): # 初始化工作流上下文 ctx = self.context.create(task.company_id, task.materials) # 阶段1：基础信息核验 basic_info = await self.tools.call("company_basic_info", company_id=task.company_id) ctx.add_evidence("basic_info", basic_info) # 阶段2：财务数据提取与初步分析 financial_data = await self.tools.call("financial_data_extract", materials=task.materials) ctx.add_evidence("financial", financial_data) financial_analysis = await self.llm.analyze_financials( ctx.get_evidence("financial") ) ctx.add_conclusion("financial_analysis", financial_analysis) # 阶段3~6：司法、舆情、行业分析（类似逻辑，省略） # ... # 阶段7：综合评估 evidence_package = ctx.get_all_evidence() final_result = await self.llm.synthesize( evidence_package, risk_tolerance=task.risk_tolerance ) # 输出结构化报告 report = self.format_report(final_result, ctx.get_evidence_chain()) return report这段代码展示了Agent工作流的核心思想：先收集证据，再让LLM基于证据做分析，而不是让LLM凭记忆作答。注意每个阶段产生的结论都绑定对应的证据条目，存入了上下文的证据链中。
3.4 工具调用的容错与降级策略
工具调用是整个流程中最容易出故障的环节，相比LLM推理的不确定性，外部接口超时、返回格式变化这些问题更频繁发生。我们设计了三级容错策略。
一级容错是重试。对于超时的接口，采用指数退避策略重试，最多三次。二级容错是缓存。对于工商信息这类不太变化的数据，设置24小时缓存，既减少外部接口压力，也提高响应速度。三级容错是降级。如果某个数据源完全不可用，系统不终止流程，而是将缺失的数据维度标记为“数据获取失败”，在综合评估时会把这个不确定性因素考虑进去，并在报告中提示复核人员重点关注该维度。
这套降级策略的价值在于：它让系统在外部条件不完美的情况下仍然能输出结果，但对结果的可信度打了相应的折扣标记。这种“带病运行但你知道它哪里带病”的设计，比“要么全有要么全无”的方案更适合真实的生产环境。
4. 量化评分与LLM推理的融合设计：怎么让评估结果更可靠
4.1 双引擎架构：规则量化打底，LLM深度分析补位
在项目过程中，我们渐渐意识到一个更本质的问题：纯粹的LLM分析再强，也顶不住监管和审计对“一致性”的要求。同样一家企业，今天评估是A级、下周评估成了C级，这个波动在金融场景里很难向贷审会解释。
所以我们做了个关键的架构调整：引入了双引擎评估机制。
底层是量化评分引擎：我们和业务专家一起，把历史审批数据中总结出来的规则固化成了一套打分卡——比如资产负债率超过70%扣分、近一年有被执行记录直接降档、实控人变更未履行信息披露义务扣分等。这套打分卡是确定性的，同样的输入永远得到同样的输出，它构成了评估体系的下限和底线。
上层才是LLM分析引擎：负责处理打分卡覆盖不到的场景——分析舆情事件的性质与严重程度、判断行业环境变化对企业的影响方向、识别财务报表中可能存在的粉饰信号等。LLM的产出以“定性分析意见”的形式附加在量化评分结果之上。
4.2 风险因子提取与权重分配
结合工作流里的七阶段分析，我们对风险因子做了系统性梳理。大致分类如下：
- 财务因子：资产负债率、流动比率、净利润增长率、经营性现金流等。权重占比约35%。这些是历史风险预测能力最稳定的指标。
- 司法与合规因子：被执行金额、诉讼次数、行政处罚次数、经营异常记录。权重占比约25%。一旦命中这类因子，风险等级往往需要直接上调。
- 舆情因子：负面新闻数量、事件性质严重程度、事件时效性。权重占比约15%。这里需要LLM对舆情内容做语义分类——单纯出现负面词不一定有问题，要看具体是什么事件。
- 行业与外部环境因子：所在行业景气度、上下游稳定性、区域经济环境。权重占比约15%。
- 公司治理因子：实控人稳定性、股权结构变动、信息披露质量。权重占比约10%。
这套权重不是拍脑袋定的，而是用了该机构过去三年的历史信贷数据回测了版。我们用这批样本重新计算了各组因子的区分度指标，然后对权重做了逐步调优。在样本内测试中，这套融合机制的排序能力比单纯用打分卡提升了一些。
4.3 置信度与冲突解决机制
双引擎并行后，最棘手的场景是：量化引擎给出低风险评分，LLM却识别出了潜在的重大风险信号，两者不一致时听谁的？
我们设计了一套冲突处理规则：
- 若量化评分与LLM定性结论一致，直接输出结论，并附双引擎依据。
- 若两者不一致且LLM识别的是轻微风险信号，以量化评分为主，LLM结论作为辅助提示。
- 若两者不一致且LLM识别的是严重风险信号，触发强制人工复核，并生成“风险信号提示单”，把LLM识别到的具体证据和逻辑链完整列出。
举个例子，某企业资产负债率只有55%，量化评分尚可，但LLM在舆情扫描中发现该企业最近三个月连续出现核心技术人员流失、多笔应收账款逾期催收的消息，而财报中应收账款账龄分析却显示正常。这种矛盾信号被LLM捕捉后，系统会直接定性为“潜在财务粉饰信号”，触发强制人工复核。
这套冲突解决机制的效果很显著：它让AI系统不跟原有的规则体系打架，而是在其基础上提供增量价值。
4.4 可解释性：从黑盒到证据链
关于可解释性我想多说几句，因为这是金融AI项目成败的分水岭。评审人员不会因为“AI是这么说的”就批准一笔贷款，所以我们的系统必须回答三个问题：为什么得出这个结论？依据是什么？如果信息更新了，结论会怎么变？
针对这三点，我们做了几个设计。
第一，每个风险结论都必须携带证据引用。我们在生成报告中为每个风险点加入了类似于参考文献的引用标注——风险来源、原始信息片段、抓取时间、对应的评估准则。审计人员可以一键跳转查看原始数据。
第二，设计了敏感因子回溯功能。当整体风险等级为高时，系统会把导致该结论的前三大风险因子及它们的贡献度列出来。业务人员能直观看到是哪几条信息把风险等级推高的。
第三，结构化支持“假设分析”。评估师可以在系统里手动修改某个关键假设——比如“如果该企业能提供足额抵押物，风险等级会怎么变”。Agent会用修改后的假设重新跑一遍推理链路，展示结论变化趋势。这个功能在贷审会场景中极受欢迎。
5. 落地过程中的典型问题与排查技巧
5.1 数据时效性问题：企业信息总是滞后
我们遇到的第一个大问题是数据时效性。有几家企业在新一轮舆情里已经出现明显负面信号，但我们的基础信息库还停留在半年前的状态。后来排查发现，部分数据源是T+1批量同步的，部分甚至T+7，导致Agent“拿着旧地图做判断”。
解决办法，一是接入实时数据推送通道，并标注数据抓取时间；二是在证据条目的时间戳上下足功夫。现在报告里每个证据条目都带精确到分钟的时间戳，如果某个维度的数据超过30天才更新，系统会主动标记“数据新鲜度不足”，并建议复核人员重点核查该维度。
5.2 长文本截断与上下文丢失
企业资料包里如果包含完整的审计报告、招股说明书，动辄几百页，直接全量塞进上下文不现实。最初我们简单粗暴地做了截断处理，结果发现模型分析的质量明显下滑，一些关键风险点因为落在截断区间里被直接忽略了。
后来我们设计了一套分层摘要策略：核心财务数据必须全量结构化提取，不允许摘要；辅助性的长篇文本按章节切片做摘要，摘要层级默认为两轮。关键逻辑是——需要计算的部分保留原始数据，需要理解的文本才做压缩。这套策略上线后，财务维度风险信号的召回率明显回升。
5.3 幻觉与过度推断的控制
这是LLM类项目逃不开的话题。在金融场景里，幻觉的危害会被放大——模型一本正经地声称“该公司涉及某项未披露的法律诉讼”，如果这条信息是编的，会直接导致企业被误杀。
我们做了三层防线。第一层是Agent工作流设计上强制“证据-结论”对齐，Prompt里反复加入“仅基于给定证据”“禁止推测未提及信息”的约束。第二层是独立的事实校验模块，对LLM生成的每一项关键风险结论，回查证据库中是否有对应佐证。如果找不到佐证，该结论被标记为“无证据支持”，不进入正式报告，只进入复核通道。第三层是定期用校验集测评模型的幻觉率——我们手工准备了上百条风险结论测试用例，每次换模板、换模型版本时都要跑一遍回归，确保幻觉控制水平不劣化。
这里有个务实的观点：幻觉不可能降为零，但对结论进行逐一溯源校验，成本和收益的平衡点是可以接受的。
5.4 响应延迟：Agent多轮调用导致的慢体验
Agent工作流比单次LLM调用慢得多，这是架构设计天然带来的代价。我们统计过，一次完整的七阶段评估需要调用12到18次LLM接口，加上外部数据源查询，高峰期总耗时可能超过5分钟。虽然相对人工半天已经快了很多，但对用户体验来说还是不够好。
优化思路主要有几条：一是并行化改造，将没有依赖关系的阶段改为并行执行——基础信息核验、司法涉诉扫描、舆情检索这三个阶段互不依赖，从串行变成并行后，整体耗时下降了40%。二是引入敏捷模式，当用户只关心初步结论时，可以先跑快速评估流程，只做三个核心维度——基础信息、财务量化、司法记录，产出初步报告，深度分析再后台执行，完成后主动通知用户。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 解决措施 |
|---|---|---|
| 输出格式频繁解析失败 | Prompt格式约束不够明确 | 加入标准JSON格式示例，用双重格式规范 |
| 同一企业重复评估结果波动大 | 上下文管理缺失或模型温度过高 | 增加工作流上下文缓存，温度调低至0.1~0.3 |
| 关键风险点被遗漏 | 长文本截断策略不当 | 改用分层摘要策略，核心数据全量结构化提取 |
| Agent答非所问 | 子任务拆分粒度不够细 | 检查工作流节点的输入输出是否匹配 |
| 外部数据源超时拖慢全流程 | 缺少容错和降级策略 | 加入重试机制、缓存策略和缺失标记降级 |
| 结论与量化评分明显冲突 | 双引擎权重配置不当 | 检查冲突解决规则，必要时强制人工复核 |
6. 合规与风险底线：金融场景不可妥协的原则
6.1 评估结果权责归属
系统上线前，法务和合规的同事反复强调一件事：AI只是辅助工具，最终的风险审批责任必须落在持牌专业人员身上。这个原则直接决定了我们的系统在设计时将所有输出定义为“参考性建议”，而不是“审批意见”。系统产出的报告头部强制标注“本报告由智能辅助生成，仅供参考，不构成最终审批结论”。审批人的最终意见会被完全保留在流程记录中，与AI建议分离开。
这套权责隔离经过长期的实践检验，证明是务实的。它让业务人员敢于使用AI，因为AI辅助分析降低的是案头工作量，而不是决策责任。
6.2 数据合规与隐私保护
金融数据的高度敏感性决定了数据合规是我们绕不过去的门槛。在技术层面，我们做了几个约束：
- 所有企业数据接入前必须经过数据源合规审查，确认数据来源合法合规。
- 敏感字段加密存储，LLM调用过程中不传输原始身份证号、银行账号等个人敏感信息。
- Agent的日志系统做了完整的访问审计，谁在什么时间调用了什么数据都有据可查。
6.3 人工复核机制的设计
系统设计了三级复核策略。第一级是自动通过：低风险评分 + 无严重风险信号 + 数据新鲜度达标，报告直接推送审批流。第二级是普通复核：中风险或存在少量风险信号，由业务人员结合报告进行复核。第三级是强制复核：任何高风险评分、敏感因子命中、或双引擎结论冲突的情况，必须由资深审批人员介入。
从实际运营数据来看，目前强制复核率约15%，普通复核率约28%，自动通过率约57%。整体符合项目初期设定的复核率目标，且经过多轮优化后，自动通过样本的后期表现与前两类样本没有显著差异，说明筛选机制的精准度是可接受的。
6.4 持续监控与迭代评估体系
AI模型上线不是终点。我们建立了一套持续监控机制：每周统计各风险因子的命中率分布，看是否出现过拟合或偏移；每月用新积累的审批结果回测评估模型的排序能力，跟踪其衰减幅度；每个季度做一次全面复盘，结合外部环境变化评估是否需要调整权重配置。
这套持续迭代机制的核心价值在于：它让系统不是“上线即巅峰”，而是能随着业务数据的积累变得越来越贴合实际。至少在模拟项目X的运行周期里，系统的评估质量整体是逐步上升的。
7. 实践收获与下一步扩展方向
这个项目做下来，我个人的感受是：LLM Agent在金融风险评估这个场景里，真正的价值不在于“替代人”，而在于“为人提供更全的视野、更快的速度、更规范的留痕”。它把业务人员从繁琐的信息收集和初步筛选中解放出来，让人把时间花在真正需要判断力的地方。
下一步我们想探索的方向有两个。一个是把Agent接入贷后监控场景，持续跟踪存量客户的风险变化，在风险信号出现早期就发出预警。目前贷后监控的痛点在于信息量巨大、更新频率快，人工难以做到及时覆盖，Agent的持续运行能力正好对症。另一个是引入多Agent协作机制——让财务分析Agent、舆情分析Agent、行业研究Agent分别独立工作，再由综合评估Agent汇总，减少单一模型带来的系统性偏差。
但要说一句实在话：这个方向的门槛主要在工程落地和数据治理上，而不在模型本身。能否把业务规则理解透彻，能否把数据管好，能否设计出一套让人信任的证据回溯机制，这些才是决定项目成败的核心因素。模型会越来越强，但工程体系的严谨性和对业务底线的敬畏，是任何时候都不能松的。
