信贷欺诈的形态这几年变化非常快，从早期的伪冒申请、资料造假，发展到有组织的团伙骗贷、中介包装、多头借贷套现。传统风控系统依赖人工沉淀的规则和评分卡模型，面对新型欺诈往往反应滞后，规则越堆越多，误杀率也随之攀升。本文以一个实际的信贷风控反欺诈Agent项目为例，完整拆解这套系统的设计思路、技术架构和落地细节，讲清楚一个Agent驱动的反欺诈体系到底应该如何构建。
传统风控的痛点与Agent化改造的思路
先看传统方案的局限。典型的信贷风控链路是：申请人提交资料后，系统调用征信、运营商、多头借贷等第三方数据源，然后跑一遍规则引擎和评分卡，输出通过、拒绝或转人工。这条链路在应对已知欺诈模式时效率很高，但有几个明显的短板。第一，规则是静态的，欺诈团伙一旦摸清规则边界，就会精心构造刚好卡在阈值之下的申请资料，比如把申请金额控制在规则触发线以下、把设备行为伪装得足够自然。第二，规则之间缺乏语义理解能力，无法识别复杂模式的组合欺诈，比如申请人本人资料完全正常，但紧急联系人、常用收货地址与历史黑名单用户高度重叠，单条规则很难捕捉这种弱关联信号。第三，规则维护成本高，策略分析师需要不断人工挖掘新的欺诈特征，从发现新型攻击到规则上线往往以周计。
Agent化改造的核心思路，是把大模型的推理能力嵌入风控决策链路，让系统从被动执行规则升级为主动分析风险。具体来说，Agent在收到进件事件后，不是机械地跑规则，而是先对申请信息做结构化理解，再自主决定需要调用哪些数据源、执行哪些分析工具，最后综合所有证据链给出风险判断和理由。这带来三个好处：决策过程可解释，Agent会输出完整的推理链；策略迭代更快，新欺诈模式可以通过提示词和工具编排快速响应；长尾风险覆盖更好，Agent对弱信号、多源交叉证据的敏感度远高于静态规则。
当然，Agent不是要替代规则引擎，而是与之协作。高频、明确的规则判断仍然由引擎承担，保证性能和稳定性；Agent负责处理复杂案件、边界案件和新型模式分析。这种分层协作是整个案例的基本设计原则。
反欺诈Agent的整体架构设计
这套系统采用典型的分层架构，自下而上分为数据层、能力层、Agent编排层和决策层。数据层整合了内部业务数据（申请表单、行为埋点、历史借贷记录）和外部数据源（征信报告、运营商数据、多头借贷索引、设备指纹服务）。能力层把这些数据和能力封装成一组标准化工具，供Agent按需调用，包括关系图谱查询、设备风险评分、文本一致性校验、黑白名单检索等。Agent编排层是核心，由一个基于大模型的推理引擎驱动，负责规划分析步骤、调度工具、汇总证据。决策层接收Agent的输出，结合规则引擎的硬性拦截结果，生成最终的审批建议。
下面是能力层工具注册的核心代码示例，展示如何把风控能力封装成Agent可调用的工具：
from agent_sdk import tool, AgentRuntime
@tool(name="graph_relation_query", desc="查询申请人与黑名单、历史欺诈案件的关联路径")
def graph_relation_query(applicant_id: str, max_hops: int = 3):
# 在图数据库中查询关联关系
# 返回格式：路径列表，每条路径包含节点类型、关系类型、风险标签
result = graph_db.traverse(
start_node=applicant_id,
edge_types=["SAME_DEVICE", "SAME_CONTACT", "SAME_ADDRESS"],
max_hops=max_hops,
filter_labels=["fraud_case", "blacklist"]
)
return {"paths": result, "hit_count": len(result)}
@tool(name="device_risk_score", desc="获取设备指纹风险评分及异常行为特征")
def device_risk_score(device_id: str):
features = device_service.get_features(device_id)
# 包括模拟器特征、改机痕迹、传感器异常、批量注册特征等
return device_service.score(features)
@tool(name="info_consistency_check", desc="校验申请资料内部一致性")
def info_consistency_check(app_form: dict):
checks = []
if app_form["work_years"] > 30:
checks.append("工作年限异常")
if app_form["age"] - app_form["work_years"] < 16:
checks.append("年龄与工作年限矛盾")
return {"issues": checks}
runtime = AgentRuntime(tools=[
graph_relation_query,
device_risk_score,
info_consistency_check
])架构设计中有几个关键决策值得展开。首先是工具粒度的划分，粒度太细会导致Agent推理步数过多、延迟不可控，太粗则丧失灵活性。这个案例中我们把工具控制在十几个，每个工具对应一个完整的风控子任务，单次调用耗时可控。其次是延迟预算，反欺诈是准实时场景，整个Agent决策链路要求在秒级完成，因此对工具调用次数做了硬性限制，超过三步未收敛的案件直接降级到规则引擎兜底或转人工。第三是幂等与降级设计，所有外部数据调用都带缓存和超时熔断，大模型服务不可用时系统自动回退到纯规则模式，保证业务连续性。
多源数据关联分析与团伙欺诈识别
团伙欺诈是信贷损失的大头，也是单点规则最难覆盖的场景。欺诈团伙通常用一批真实设备、一批真人或半真人身份，通过中介包装资料批量进件，单个申请看起来都正常，但申请之间隐藏着紧密的关联网络。这个案例中，团伙识别主要依赖图计算能力，把申请人的设备、手机号、紧急联系人、银行卡、IP地址、收货地址等实体统一构建成关系图谱，然后在图谱上做社区发现和风险传播分析。
Agent在这其中的价值在于对图查询结果的语义化解读。传统的图规则只能做简单统计，比如一度关联黑名单直接拒绝，这种粗粒度规则误伤严重。Agent则可以拿到完整的关联路径后进行推理判断：某个申请人通过共用WiFi与三个历史欺诈案件产生关联，但进一步查询发现该WiFi位于城中村出租屋，属于高密度共享网络，这种关联的证据强度就大打折扣；相反，如果两个申请人共用同一台改机设备且紧急联系人互填，即使双方都无不良记录，团伙风险也很高。这种需要结合业务常识的链式推理，正是大模型Agent的强项。
下面是Agent编排层的核心推理循环示例：
class FraudAnalysisAgent:
def __init__(self, runtime, llm):
self.runtime = runtime
self.llm = llm
self.max_steps = 3 # 延迟预算约束
def analyze(self, application: dict):
evidence = []
prompt = self.build_initial_prompt(application)
for step in range(self.max_steps):
plan = self.llm.plan(prompt, self.runtime.tool_schemas)
if plan.action == "finish":
break
tool_result = self.runtime.execute(plan)
evidence.append({
"tool": plan.tool_name,
"result": tool_result,
"reasoning": plan.reasoning
})
prompt = self.update_prompt(prompt, tool_result)
# 汇总证据链，输出结构化风险结论
conclusion = self.llm.summarize(evidence)
return {
"risk_level": conclusion.risk_level,
"fraud_type": conclusion.fraud_type,
"evidence_chain": evidence,
"suggestion": conclusion.suggestion
}在实际运行中，这套机制对团伙案件的识别效果提升明显。项目上线后一个季度内，通过关系图谱加Agent推理的组合策略，识别出多个此前规则完全无法发现的中介包装团伙，其中一个案例涉及上百笔申请，表面资料全部合规，但Agent通过收货地址聚类和申请时间序列的异常集中性，成功将整批案件标记为高风险并推送人工核查，避免了数百万级的潜在损失。
决策链路编排与人机协同机制
反欺诈系统的输出不是简单的二值判断，而是一个分级决策：直接通过、直接拒绝、转人工审核、附加条件通过（比如降低初始额度、要求补充材料）。Agent的输出需要无缝对接这套决策编排体系。这个案例的做法是，Agent输出的风险等级、欺诈类型和证据链作为决策因子之一，与规则引擎结果、模型评分共同进入决策矩阵。规则引擎的硬拦截具有最高优先级，Agent的结论主要用于补充决策依据和提升人工审核效率。
人机协同是落地的关键环节。Agent标记为可疑但证据不够充分的案件，会进入人工审核队列，系统把Agent的推理链完整呈现给审核员，包括它调用了哪些工具、发现了哪些异常、为什么做出这个判断。审核员的最终结论会回流为标注数据，一方面用于评估Agent的准确率，另一方面通过反馈微调提示词策略。这种闭环机制让系统具备持续进化能力，审核员也从事务性工作中解放出来，专注于Agent不确定的灰色案件。
下面是决策编排的核心逻辑：
public DecisionResult decide(Application app, AgentOutput agentOut, RuleOutput ruleOut) {
// 规则引擎硬拦截优先级最高
if (ruleOut.isHardRejected()) {
return DecisionResult.reject("命中硬规则: " + ruleOut.getHitRules());
}
// Agent高置信度高风险直接拒绝
if (agentOut.getRiskLevel() == RiskLevel.HIGH
&& agentOut.getConfidence() > 0.85) {
return DecisionResult.reject("Agent判定: " + agentOut.getFraudType());
}
// 中风险或低置信度案件转人工，附上推理链
if (agentOut.getRiskLevel() == RiskLevel.MEDIUM
|| agentOut.getConfidence() <= 0.85) {
return DecisionResult.toManual(agentOut.getEvidenceChain());
}
// 低风险正常通过
return DecisionResult.approve();
}在效果评估方面，团队建立了三层指标体系：技术层关注Agent决策延迟、工具调用成功率、大模型服务可用性；业务层关注欺诈识别率、误杀率、人工审核量的变化；经济层关注坏账率下降和审核人力成本节约。上线半年后的数据表明，欺诈案件识别率提升约三成，人工审核量下降四成左右，同时误杀率保持在可控范围内。这些数字验证了Agent与规则引擎协作模式的可行性。
最后总结几点落地经验。第一，不要追求全自动化，反欺诈是高风险场景，保留人在回路是必要的保险机制。第二，工具设计比提示词调优更重要，工具封装的质量直接决定Agent能力的上限。第三，延迟和成本预算要从架构设计之初就纳入约束，否则Agent链路很容易在高峰期拖垮整个审批流程。第四，可解释性不是可选项，监管和内部审计都要求每个拒绝决策有据可查，Agent输出的证据链恰好满足了这一要求。对于正在规划智能风控升级的团队，建议从小范围灰度开始，先让Agent承担辅助分析角色，逐步积累信任后再扩大决策权限。