一家汽车零部件供应商拿到整车厂5亿元应付账款、90天账期,是该去质押应收账款,还是让核心企业做反向保理,或者把订单融资+仓单融资组合用上?供应链金融5种主流方案各有适用场景,但客户经理面对具体客户时往往凭经验选一个。下面这套引擎的做法是:输入四要素,输出方案对比+推荐组合+办理流程,全程零外部依赖。
一、5种方案的边界在哪里
供应链金融(Supply Chain Finance, SCF)的主流方案分为5种,每一种都对应一个特定的"现金流痛点阶段":
| 方案 | 解决的痛点 | 依赖核心企业 | 额度上限 | 利率下限 |
|---|---|---|---|---|
| 应收账款质押融资 | 已开票未到账 | 仅需确认函 | 中 | 中 |
| 订单融资 | 已下单未交付 | 需采购订单 | 中低 | 中高 |
| 核心企业反向保理 | 全链条降本 | 主功臣 | 高 | 低 |
| 供应链票据 | 多级信用穿透 | 票据开立人 | 高 | 低 |
| 仓单融资 | 已备货未开票 | 不依赖 | 低 | 高 |
可以看到,5种方案从"应收账款质押"到"反向保理"再到"仓单融资",覆盖了供应链从下单→发货→开票→到期付款的完整生命周期。但客户经理拿到一个具体客户时,最常遇到的问题是:这家核心企业应付账款5个亿,到底推哪个方案?
financial-ai-skills仓库的supply_chain_finance模块给出的答案不是一个推荐,而是一组规则化对比+一个智能推荐引擎。
二、规模系数scale:一个0.6到1.5的数字如何撬动5种方案
这套引擎最精巧的设计是一个叫scale_factor的函数。它做的事情很简单:根据应付账款规模(万元),返回一个0.6~1.5之间的系数。
def _scale_factor(self, ap: float) -> float:
"""根据应付账款规模确定规模系数"""
if ap >= 100000: # 10亿+
return 1.5
elif ap >= 10000: # 1亿+
return 1.2
elif ap >= 1000: # 1000万+
return 1.0
elif ap >= 100: # 100万+
return 0.8
else:
return 0.6
这个系数看似简单,但它同时影响5种方案的两个关键维度:
第一维:额度放大。每一种方案的额度公式都乘以scale。以反向保理为例:
quota_range=f"{min(ap * 0.8, 150000) * scale:.0f}~{min(ap * 1.0, 200000) * scale:.0f} 万元"
应付账款5亿(50000万元)、scale=1.2时,反向保理额度=48000~60000万元。同样是反向保理,应付账款5000万、scale=0.8时,额度只有3200~4000万元。额度直接放大15倍,比单纯按应付账款比例计算更激进——这正是核心企业规模优势的体现。
第二维:利率微调。利率公式是3.2 + (8 - scale) * 0.2(反向保理):
| scale | 应付规模 | 反向保理利率下限 | 反向保理利率上限 |
|---|---|---|---|
| 1.5 | 10亿+ | 4.50% | 6.10% |
| 1.2 | 1亿~10亿 | 4.56% | 6.16% |
| 1.0 | 1000万~1亿 | 4.60% | 6.20% |
| 0.8 | 100万~1000万 | 4.64% | 6.24% |
| 0.6 | <100万 | 4.68% | 6.28% |
注意一个细节:利率差异只有10~20个BP(基点),但额度差异是数量级的。这不是设计缺陷,而是复刻真实银行授信逻辑:核心不在于"大企业利率低到哪去",而在于"大企业能放大授信额度"。利率断崖式跳变会触发合规审查,scale通过细微利率调整+大幅额度放大的组合,既保留了差异化定价,又规避了利率歧视风险。
5种方案的(8 - scale) * X系数也各有不同:
| 方案 | 利率系数 | scale=1.5→0.6的利率跨度 |
|---|---|---|
| 反向保理 | 0.2 | 4.50%~6.10% / 4.68%~6.28% |
| 供应链票据 | 0.2 | 与反向保理同档 |
| 应收账款质押 | 0.3 | 利率随规模波动更敏感 |
| 订单融资 | 0.3 | 同上 |
| 仓单融资 | 0.3 | 同上 |
反向保理和供应链票据的0.2系数表明:核心企业深度参与的方案,利率对规模更不敏感——因为核心企业信用本身就是定价锚,规模只是放大器。而仓单融资这种不依赖核心企业信用的方案,系数是0.3,利率随规模波动更大,反映了"无核心信用背书时需要更精细的风险定价"。
三、推荐规则:5亿是个分水岭
_build_summary函数的推荐逻辑只有3行,但恰到好处:
if ap >= 50000: # 5亿以上
recommended = ["反向保理", "供应链票据"]
elif ap >= 10000: # 1亿以上
recommended = ["反向保理", "应收账款质押融资", "供应链票据"]
else:
recommended = ["应收账款质押融资", "订单融资", "仓单融资"]
3档分水岭背后的产品逻辑:
5亿+:应付账款体量足够大,核心企业一定有动力做确权(否则资金成本太高),反向保理+供应链票据这对组合覆盖了"信用穿透+标准化结算"两个场景,不需要推应收账款质押——因为质押要多方确认函,操作成本高,5亿+客户用得起反向保理就没必要退而求其次。
1亿~5亿:开始出现"核心企业配合度不确定"的情况。三方案并列:反向保理是首选,应收账款质押是"核心不愿主动确权时"的退路,供应链票据是"已经开过商票想流转"的延续选项。
<1亿:核心企业可能根本不愿意做反向保理的IT投入,直接退回应收账款质押+订单融资+仓单融资三件套,让供应商自己挑。
这套规则最大的价值不在于推荐本身,而在于显式表达"为什么不推荐某方案"。客户经理面对5亿应付账款客户推反向保理,被问"为什么不推应收账款质押",可以引用规则回答:"5亿+档不上应收账款质押,原因是确权成本与方案收益不匹配"。把经验变成可解释的规则,是供应链金融产品数字化的关键一步。
四、parse_input:5套正则搞定自然语言输入
引擎的入口是一个parse_input函数,把自然语言转成SCFProfile结构体。没用任何NLP模型,纯靠5套正则+几条启发式规则,毫秒级响应。
def parse_input(text: str) -> SCFProfile:
# 1. 应付账款规模(支持亿/万/元三单位换算)
ap_match = re.search(r'应付账款\s*([\d.]+)\s*(亿|万|元)', text)
# 2. 账期(默认90天)
term_match = re.search(r'账期\s*(\d+)\s*天', text)
# 3. 供应商类型
supplier_match = re.search(r'供应商类型?\s*[::]?\s*(\S+)', text)
# 4. 核心企业(显式标注优先)
core_match = re.search(r'核心企业\s*[::]?\s*(\S+)', text)
# 5. 兜底:行业关键词触发
if '汽车' in text:
enterprise = "汽车整车厂"
elif '电子' in text:
enterprise = "电子核心企业"
为什么不用LLM?三个原因:
第一,可解释性。客户经理输入"应付账款5亿"被解析成50000万元,过程完全可追溯。用LLM解析就有"为什么是5亿不是50亿"的黑盒争议。
第二,响应速度。正则解析毫秒级,LLM至少500ms以上。客户经理查询高频,每秒延迟都影响体验。
第三,部署成本。正则零依赖,pip install都不需要。LLM要部署模型或买API。供应链金融场景输入结构高度规整(核心企业+供应商类型+应付账款+账期),不值得为这种结构化输入上LLM。
行业识别则用一个8行业关键词词典做兜底:
self._industry_keywords = {
"汽车": ["汽车", "整车", "车企", "车厂", "汽配", "零部件"],
"电子": ["电子", "半导体", "芯片", "面板", "消费电子", "手机"],
"医药": ["医药", "制药", "医疗", "器械", "药店", "医院"],
"家电": ["家电", "电器", "空调", "冰箱", "洗衣机", "彩电"],
"食品": ["食品", "饮料", "乳业", "酒类", "餐饮", "调味品"],
"纺织": ["纺织", "服装", "面料", "印染", "制衣"],
"建材": ["建材", "水泥", "钢材", "木材", "家居"],
"能源": ["能源", "电力", "光伏", "风电", "电池", "储能"],
}
字典不大,但覆盖了供应链金融主力行业的80%以上场景。匹配失败时退回"通用制造",让后续方案依然能跑——容错性比覆盖度更重要。
五、企微卡片:从Markdown报告到一行回复指令
整套引擎还有个容易被忽视但很关键的设计:format_wecom_card输出的是企微markdown卡片,而不是完整报告。
def format_wecom_card(self, result: dict) -> dict:
return {
"msgtype": "markdown",
"markdown": {
"content": (
f"### 🏦 供应链金融方案报告\n\n"
f"**核心企业**:{p['core_enterprise']}\n"
f"**应付账款**:{p['accounts_payable_yi']:.1f}亿 | **账期**:{p['payment_term_days']}天\n"
f"**行业**:{p['detected_industry']} | **供应商**:{p['supplier_type']}\n\n"
f"### ✅ 推荐方案\n\n"
+ "\n".join(f"- **{r}**" for r in summ['recommended_names'])
+ f"\n\n"
f"> 💡 回复【详细】获取完整方案对比及办理流程"
)
}
}
卡片信息密度有限:核心企业+应付账款+账期+行业+推荐方案,最多5个字段。详细方案对比表不直接发,需要客户经理回复"详细"才推送完整Markdown报告。
这个设计源于企微的实际使用场景:客户经理在群里推送方案时,老板第一眼只想看到"推荐了哪几个方案、规模多大",多了一屏刷不完。回复"详细"才触发的二级分发,既保留了完整信息可达性,又控制了消息噪音。如果是直接用format_markdown推完整报告到群里,5种方案的对比表+办理流程表加起来几十行,老板大概率会直接跳过。
这种"卡片摘要+指令触发完整内容"的双形态分发,是金融场景里企微消息设计的标配。比起一股脑塞所有信息,让用户主动索取反而转化率更高。
六、5亿新能源汽车案例完整跑通
输入一句话:
供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天
parse_input解析出的SCFProfile:
SCFProfile(
core_enterprise="某新能源汽车整车厂",
supplier_type="某新能源汽车整车厂", # 兜底逻辑会自动修正
accounts_payable=50000.0, # 万元
payment_term_days=90,
)
_detect_industry扫描关键词"新能源"未命中(字典里没有"新能源",但有"能源"和"汽车")——实际命中"汽车"("整车厂"中包含"车"字)。行业推断为汽车。
_scale_factor(50000):50000 ≥ 10000 且 < 100000,返回 1.2。
_build_summary:50000 ≥ 50000,命中第一档,推荐 反向保理 + 供应链票据。
反向保理实际额度算式:
下限:min(50000 * 0.8, 150000) * 1.2 = 40000 * 1.2 = 48000万元
上限:min(50000 * 1.0, 200000) * 1.2 = 50000 * 1.2 = 60000万元
利率下限:3.2 + (8 - 1.2) * 0.2 = 4.56%
利率上限:4.8 + (8 - 1.2) * 0.2 = 6.16%
供应商拿到的是一份包含5方案对比、办理流程7步、推荐组合+行动建议的完整报告,外加一张企微卡片摘要。整条链路从输入到输出,毫秒级响应,零API调用,零外部依赖。
如果换成应付账款5000万(5000万元,scale=0.8):
| 维度 | 5亿案例 | 5000万案例 | 差异倍数 |
|---|---|---|---|
| 反向保理额度下限 | 48000万 | 3200万 | 15× |
| 反向保理额度上限 | 60000万 | 4000万 | 15× |
| 反向保理利率下限 | 4.56% | 4.64% | -8BP |
| 反向保理利率上限 | 6.16% | 6.24% | -8BP |
| 推荐方案 | 反向保理+供应链票据 | 应收质押+订单+仓单 | 完全不同 |
注意最后一行:5000万应付账款的推荐方案完全切换到了另一组——因为小于1亿档不上反向保理。这就是规则化引擎的价值:同一套逻辑在不同规模下自适应切换,client manager不需要记5种方案什么时候用,规则自动决定。
七、设计启示
scale是个杠杆,不是个开关。0.6~1.5之间连续可变的系数,比"大/中/小"三档离散分类更精准。金融产品定价最忌讳档位跳变,scale用连续函数平滑过渡,规避了合规审查中的利率歧视问题。
推荐规则要显式表达"为什么不推荐"。客户经理需要的不是"推荐反向保理",而是"为什么不推荐应收账款质押"——这种排除式逻辑才是产品规则的真正价值。3档推荐规则背后隐藏着5种方案的两两排除关系,规则化引擎把这种隐性经验变成了显式代码。
双形态输出比单一报告更实战。企微卡片做摘要触发,完整Markdown做详细查询。在消息渠道碎片化的金融场景里,"卡片+指令"的双层分发是消息设计的基本功。
正则解析+词典兜底足够覆盖80%场景。供应链金融的输入结构规整,不值得上LLM。把LLM留给真正非结构化的场景(如客户自然语言咨询),让规则处理规则能处理的事,是工程效能最大化的关键。
快速上手
git clone https://github.com/yuzhaopeng-up/financial-ai-skills.git
cd financial-ai-skills/skills-phase2/supply_chain_finance
python scf_engine.py generate "供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天"
from scf_engine import SCFEngine, parse_input
profile = parse_input("供应链金融 某新能源汽车整车厂 应付账款5亿 账期90天")
engine = SCFEngine()
result = engine.generate(profile)
# 三种输出形态:Markdown报告 / JSON / 企微卡片
print(engine.format_markdown(result)) # 给客户经理看
print(engine.format_json(result)) # 给系统对接
print(engine.format_wecom_card(result)) # 给企微群推送
完整源码不到500行,零外部依赖,copy到任何Python项目都能直接跑。
Agent Skills开源生态
| 仓库 | 定位 | GitHub |
|---|---|---|
| teleagent-skills | 5个通用业务Skill:4-Phase编排+规则参数化 | https://github.com/yuzhaopeng-up/teleagent-skills |
| agent-cluster-comm | 多Agent集群5层通信架构 | https://github.com/yuzhaopeng-up/agent-cluster-comm |
| skill-framework | Skill治理框架:L0-L4分类+YAML模板 | https://github.com/yuzhaopeng-up/skill-framework |
| fintech-h5-demos | 57个零依赖金融H5演示 | https://github.com/yuzhaopeng-up/fintech-h5-demos |
| soe-compliant-office | 17个央国企合规办公Skill | https://github.com/yuzhaopeng-up/soe-compliant-office |
| regulated-rag | 零依赖RAG工具包:BM25+TF-IDF+RRF | https://github.com/yuzhaopeng-up/regulated-rag |
| agent-ops-toolkit | 企业级Agent运维基础设施:降级+告警+工作流 | https://github.com/yuzhaopeng-up/agent-ops-toolkit |
| financial-ai-skills | 金融AI技能库:104个场景纯Python实现(含本文SCF引擎) | https://github.com/yuzhaopeng-up/financial-ai-skills |
如果你在做供应链金融产品,或者想把5种SCF方案的选型逻辑规则化,这500行源码是个直接的起点。比起从零写一个推荐引擎,复用经过实战验证的规则集,能让你的产品早上线两周。
觉得有用?给个 Star 支持一下!你的 Star 是我们持续开源的最大动力。
更多开源 Agent Skills:financial-ai-skills · teleagent-skills · regulated-rag · fintech-h5-demos —— 全部在 github.com/yuzhaopeng-up,欢迎 Star/Fork/PR!