企业官网建设流程全解析

如果把“智能风险评估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.10，Web层用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_k=5) 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项目，后面根本没法谈优化。

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拆开，各司其职。模型层面，定期用人工修订后的报告补充评测集，跑回归并微调提示词，让系统在持续使用中缓慢但稳定地进步。

如果让我重新做一次这个项目，我会在第一天就做两件事：把评测集建好，把日志打全。因为后面所有调优、所有问题排查、所有效果说服，都依赖这两件事。技术上其他内容都可以快速重来，唯独这两样是时间堆出来的，耽误不得。