架构争论由采购解决不由工程师

CrewAI 创始人讲了一次向大银行推销的经历：对方喜欢平台，但随即追问可观测怎么解决——答案是要另买一家；再问记忆，还是另买。到第三个问题时，客户坐在那里盘算：用你们的东西，我得买五家的产品。这场会议直接终结了他们内部持续数月的争论。 争论的焦点是行业公认的现状：技术栈正在碎裂。数据、模型、编排、可观测、连接、界面，每一层都挤满了想独占一层的公司，每家都把自己的那一环讲成非我不可。工程师在架构图上看到的是分工与专业，可一旦坐到采购那侧，画面就翻转了——没人想要五份合同、五次安全审查、凌晨两点要追五个供应商，客户只想留一个电话号码。 这场对话还暴露了买方评估栈时的真实顺序。银行的三连问——可观测、记忆、治理——没有一个关于模型效果，全部指向出事之后怎么办：能不能追踪、数据存在哪、权限怎么划、审计来了交什么。模型能力反而排在最后一关，因为它在采购流程里最容易被基准分数打包处理掉，而可靠性问题没有统一的分数可抄，只能一家家问。对企业客户，选栈的本质是在选未来几年的运维负担归属。 这位创始人的答案在最后一段：当市场在往两边拉、而买方想要的是聚拢时，就把那些无聊的部分自己做掉——部署、追踪、个人信息处理、权限控制，以及银行坐下来第一个要问的治理能力。平台的边界因此从"最擅长的那一环"挪向"最少合同的那一圈"。 结尾那句值得单独引用：架构争论由采购解决，不由工程师解决。它解释了为什么很多技术选型的结局和博客里的优劣分析对不上——真正拍板的问题从来不是哪家更快，而是几家、几份审查、凌晨找谁。团队内部为技术路线争执不下时，把清单换成合同数与审查次数，争论通常当场收敛。 做产品的可以把部署、追踪、PII、权限、治理列进"无聊但必做"的清单，它们是敲开企业门的门票；选型的团队则可以加一栏整合度——同样的能力，少一份合同就是少一轮安全审查，这笔账在采购桌上比基准分数更硬。