是个少女EDI协议选型，是在选你未来十年的供应链网络拓扑
去年冬天半夜两点，我被手机震醒。不是闹钟，是监控告警：和某国际零售巨头对接的AS2通道连续投递失败，对方仓库系统里积压了整整六小时没进来的订单，再拖到早上，罚款单比订单量还壮观。
我爬起来查证书有效期，检查网络，确认对端HTTP响应码，一通操作之后问题解决，但躺在床头再也睡不着。那天我在想：如果当初不是AS2而是OFTP2，如果当时走的是VAN而不是直连，这个半夜的“定时炸弹”还会不会存在？
做企业间电子数据交换（EDI）这些年，我几乎每年都会被问同一个问题：AS2、OFTP2、VAN，到底该选哪个？有时候提问者还会把“STTP”这个词混进来——这通常是Concept Drift，大家口口相传把某个内部传输组件叫成了标准协议，实际上它并不属于国际主流EDI传输标准。真正需要认真对待的，是AS2、OFTP2和VAN这三驾马车，以及它们在今天企业集成架构中各自的生态位。
这篇不是要给你一份“标准答案”，因为根本没有标准答案。我要做的是把每一种协议背后的设计逻辑、适用场景、真实成本结构全部摊开，再结合我在零售、汽车、供应链物流项目里的实际踩坑经验，帮你做一套能落地的选型决策框架。
1. 内容整体设计与思路拆解：先搞懂协议在解决什么问题
1.1 传输层只是起点，业务语义才是终点
很多人一谈EDI选型，就直接跳到“哪个协议快”“哪个协议安全”，这是一种误区。实际上，EDI整体架构分为两层：业务语义层和传输层。语义层解决的是“数据长什么样”，比如ANSI X12、UN/EDIFACT、EANCOM，它们定义了采购订单（Purchase Order，即EDI 850报文）、发票（EDI 810）、发货通知（EDI 856）这些单据的字段结构和业务规则。传输层解决的是“数据怎么送到对方手里”，这正是AS2、OFTP2、VAN这些协议的地盘。
理解这个分层是选型的前提。因为传输层的选择，往往受到业务语义层需求的制约。你做的是零售快消，对方用的是AS2接收EDI 850和EDI 856，那你即便觉得OFTP2的断点续传更香，也得优先匹配对方的AS2端点；你如果处在欧洲汽车产业带，大众或者博世要求你用OFTP2连接他们的ODETTE网络，那VAN反而成了多余的一层。
我见过太多企业老板拿着采购买来的“最佳实践”文档来找我，说“我们就要上AS2，因为先进“。但一深问，他们的主要交易伙伴都在欧洲，且传输大文件（比如CAD图纸、质量检测报告）需求频繁。这种场景下AS2就未必是首选，OFTP2既支持大文件压缩又有丢包重传机制，明显更贴近实际。
1.2 协议选型背后是三种网络拓扑的博弈
从网络拓扑角度看，这几种方案代表了不同的哲学：
AS2是一种点对点直连模式。它跑在HTTP/S之上，每个企业都有自己的AS2端点（Endpoint），相当于在互联网上开了一个专用的收件窗口。消息通过S/MIME加密和数字签名保证机密性与不可否认性，认证靠X.509数字证书完成。拓扑简单直接：你连我，我连你，不经过任何人。这种模式的代价是双方必须各自维护一套AS2服务器或者购买一个托管AS2服务，证书到期了没人提醒就等着半夜被电话吵醒。
OFTP2同样可以点对点，但它的血脉里流着欧洲汽车工业的“标准强迫症”。ODETTE组织设计它的时候，不止考虑了传输，还考虑了断点续传、压缩、数字签名、以及基于ODETTE ID的地址路由。它还支持“会话内多文件传输”，一个连接里可以连续传多个业务文件，效率极高。更准确的描述是，它是一种在传输层和会话层之间做了大量精细设计的协议。
VAN则完全是另一个思路：我不和你直连，我们大家连到同一个“邮局”，你把文件丢给邮局，邮局根据收件人地址（比如DUNS编号或VAN分配的ID）投递到对方的信箱。VAN的核心价值是提供中立第三方的可靠投递、格式转换（Translation）、通信记录审计，以及对中小企业极其友好的接入门槛。代价则是按字符或按千字符计费，交易量上去之后，成本曲线陡峭得吓人。
搞清楚了这三种拓扑，你再看市面上那些方案建议书，一眼就能看穿供应商在推荐什么逻辑：卖软件的可能推AS2直连，卖流量的可能推VAN，做汽车行业整合的会说你得上OFTP2。不是他们错，而是各自的商业立场决定了技术立场。你自己的立场，必须由你的业务网络图谱和运营能力来决定。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。