最近在为集团内部做 AI 中台的能力建设，今年年初我们就搭起了一套 Agent 评测平台——评测机、评测任务、可自由配置的评估器，标准的"中台型基础设施"思路。
直到上个月一次跨部门同步，三件事撞到了一起。
第一件事，另一个业务线的同学在群里发了一张截图，是他用 Claude Code 半天写出来的 Agent 评测页面。逻辑不复杂，但把"我们家业务对的样子"翻译成可执行 grader 这件事，比我们中台模板里能配出的更贴。
第二件事，审 Q3 资源时有人提了一个问题。既然每个业务都在自己搭 Agent 评测的局部能力，为什么还要中台一统？
第三件事，那一周我刚读完 Anthropic 的工程博客《Demystifying evals for AI agents》。他们在公司层面给出了一份术语字典——task、trial、grader、transcript、outcome、harness——但全文没有推荐任何一家商业 Eval 平台。
这三件事让我重新想，传统中台思路在 AI 时代的失效，可能比我以为的更深。不是策略要调一调，是形态层级要换一层。
"中台已死"这个口号，要先放一放
过去两年很容易就滑到一个论断：中台死了。证据看起来扎实——阿里 2023 年「1+6+N」、字节 2021 年拆中台改 BU、京东 2023 年品类经营单元化，三家做同一个动作很难只是巧合。
但读一手材料的时候我发现另一面。张勇本人 2021 年在阿里果汁会上说的原话是这样的：
反过来不是说不要中台了，是对中台要求更高，在一个整体架构里面的可扩展性。
阿里官方的口径从来就是"做薄、下沉"，从未说过"废中台"。2024 年吴泳铭主政后，部分中台能力还回归到了集团层。所以衰落派看到的"拆"和演化派看到的"做薄"，不是同一件事的两种解读，是两件事。
更准确的判断应该这样讲：作为组织建制的"大中台事业群"已经系统性退场。几千人编制、独立 KPI、向 CTO 汇报的中央军模式，不再适合多元业务集团。但作为能力复用形态的中台并没有死，反而在 AI 时代有了新需求。它只是不能再长成一个 SaaS 操作平台。
把这两件事分开，你就不会被"中台已死"这种营销标题带偏。更值得警惕的反而是国内当下另一种叙事——AI 中台。火山 HiAgent、智谱 BiSheng、迈富时、Dify、纷享销客，全在用"AI 中台"包装 Agent 平台。叫法借壳，但形态有没有跟着变？如果答案是"没有"，那就是穿了 LLM 马甲的旧大中台，会重蹈 2015-2023 年那一轮的覆辙。
西方踩过的坑，国内中台一个没少
这部分是我看完一篇叫《Platform Engineering Paradox》的文章之后最受冲击的发现。
简单数据：Gartner 预测 2026 年 80% 大型软件组织会建平台团队，基线 2022 年是 45%。这个数字被反复转引，看起来 Platform Engineering 已经赢了。
但采用率不等于成功率。那篇文章引用了 2026 年 4 月一份 Medium 案例研究：一个 18 个月、$4.2M 投入的内部开发者平台，第一份开发者满意度调查回来——64% 的工程师还在绕开它，直接用原生 kubectl 部署。综合多份 2026 调研的更悲观数字是：60-70% 平台项目"未交付可衡量影响"，约一半平台团队 18 个月内被解散或重组。
读到这里我停下来想了想。这些英文术语换成中文，几乎就是国内中台失败的复盘。
The DevOps Rename——原来的运维团队改名叫平台团队，预算和 backlog 都没变，没产品经理，结果继续被工单淹没。
The Backstage Maintenance Trap——自托管 Backstage 看起来是免费开源，实际上维护一个生产级开发者门户本身就是一个完整软件产品，平台团队所有产能都被吞掉了。
The Mandate Without Migration——领导宣布"新平台是唯一被认可的部署方式"，但旧路径没拆，工程团队各自找 workaround。
这三条对应到国内中台失败的典型表现：业务部门各自又搭一个中台、平台投入巨大但开发体验糟糕、强令推行结果上有政策下有对策。曹春晖那篇《中台的末路》里描述的成本中心化、KPI 错位、订单页面 8 个月排期，本质上就是这同一座山。
platformengineering.org 自己造了一个更刺眼的词，叫 Golden Cage Syndrome。原文大意是这样的：
"我们给他们盖了座宫殿，他们为什么还住在泥地里？" 答案很简单——你建的不是宫殿，是金笼子。当一个内部开发者平台是为控制而设计、不是为消费而设计的时候，结局就是这样。
为控制而设计的平台、不是为消费而设计的平台。这一句把传统中台思维的病灶钉死了。控制是中台部门的生存方式，但消费才是业务部门的生存方式。两者错位的时候，业务一定会绕。
Agent Eval 这个具体场景，给中台范式判了死刑
如果说 Platform Engineering 的失败是宏观证据，那 Agent Eval 就是显微镜下的活体证据。
我把这个领域翻了一遍。LangSmith、Braintrust、Latitude、Maxim、Galileo、Langfuse、Phoenix、DeepEval、Promptfoo 八九家主要玩家，全部分布在 observability、SDK、SaaS、OSS 几条平行赛道。没有一家成功做"覆盖所有 Agent 业务的统一中台"。
为什么？
我读 Anthropic 那篇《Demystifying evals for AI agents》的时候意识到一个关键事实——他们把 Eval 字典公开发布了，但不卖任何 Eval 平台。task、trial、grader、transcript、outcome、harness 六个核心抽象，是一份开放契约。文章里讲 Claude Code 的 eval 是怎么演化的，完全是 in-house 自建，由产品工程团队自己写。
不是只有 Anthropic 这样。Stripe 自建了 SI-Bench，Shopify 自建了 ROAST（开源、500 DAU、25 万 RPS），Bitrise 自建了 Go-based eval framework。Stripe Minions 现在每周 ship 1000+ unattended PR，全部用自己写的 eval gate 把关。这些公司完全有能力采购任何商业 Eval SaaS，但他们都选择自建。
我后来想明白原因了。Eval 的核心价值是"我家业务对的样子"。这件事不可能被中台抽象掉。中台只能给数据底座——trace、dataset、runner——但 grader 必须业务自己写。
这是中台思维的根本失败。你以为业务团队需要一个"什么都能做的评测平台"，他们其实需要的是一套契约、一个数据底座、一组 SDK，让他们自己定义"对"的样子。
类比一下就更清楚。把 Agent Eval 类比为单元测试。如果有一家公司宣布要做"统一单元测试中台"，集团所有业务团队登录 Web 界面跑测试，所有人都会觉得疯了。单元测试天然属于业务代码仓的一部分，跟着 PR 走。Eval 在 AI 时代要走的也是同一条路：eval-as-code、跟代码同步迭代、CI gate 把关。中台只能提供 SDK、trace 底座、grader 的运行时，但不能拥有业务对错的定义权。
我自己做集团 AI 中台的时候也意识到这件事——评估器模块支持业务自己开发或配置自己的评估器。但当时的设计前提还是"中台是入口、SaaS 是形态"。现在回头看，入口和形态都得让出来。
AI Coding 把"业务自建"从特例变成默认
这一节讲的是中台的另一边。为什么业务团队现在能自己干。
数据先放着。Cursor 18 个月做到 $2B+ ARR，企业收入占比从 2024 年第四季度的 25% 涨到 2026 年 3 月的 60%。Anthropic 总 ARR 从 2025 年底的 $9B 涨到 2026 年第一季度的 $30B，4 个月翻 3 倍。Claude Code 单产品 6 个月做到 $1B ARR。字节 Trae 内部覆盖 70% 开发者。Google CEO Pichai 公开说 25% 新代码由 AI 生成。Retool 2026 调查 800+ 企业，35% 已用自建替代至少一个 SaaS、78% 计划继续。
这些数字加在一起说明一件事：业务团队自建工具不再是特例，是默认行为。
但这一节我必须加一段批判，因为乐观叙事在我看完素材之后觉得太过头。
Wired 在 2025 年 11 月报道过一件事。安全研究公司 RedAccess 扫描了 5000 多个用 Lovable、Replit、Base44 这类 vibe coding 平台部署的应用，发现绝大多数完全没有任何鉴权。其中 40% 的应用泄露了敏感数据——包括医疗信息、财务数据、企业战略文档。研究员说这是"史上最大规模之一的企业敏感数据公开暴露事件"。
另一个反例。CodeRabbit 2025 年 12 月的研究显示，AI 代码 bug 率是人类代码的 1.7 倍。Forbes 引用 Veracode 的扫描结果——AI 代码安全漏洞率是人类的 2.74 倍。Lovable 自家系统在 2026 年 4 月也被攻破过。
还有 MIT Sloan Review 那篇文章里的判断：在 brownfield（既有遗留系统）上用 AI 自建，会复利地放大已有技术债。AI 让坏的环境更坏，不会让坏的环境变好。
把这三组反例拼起来，结论很清楚：AI Coding 让业务自建的速度暴涨，但治理能力成熟得远远不够。这不是要否定业务自建，是要重新定义中台职责。
业务团队应该自己写业务逻辑，那是他们离用户最近的部分。业务团队不应该自己解决鉴权、暴露面、审计、限流、合规、敏感数据隔离，那些是基础设施的事。
新中台应该往哪去：契约 + 运行时基础设施
把上面几节的判断合起来，我的结论是这样的。中台的形态从"工具/平台/SaaS"，应当转向"契约 + 运行时基础设施"。
具体到三个动作。
第一个动作，确立行业级开放契约。参考 Anthropic 的 task、trial、grader、transcript、outcome、harness 六词字典。这不是"我们中台有这些功能"，而是"我们和你约定，AI 评测系统有这些抽象，你的实现细节自己定，但接口要遵守"。CNCF Score Spec 是另一个范式——业务团队写一份 score.yaml 描述 workload 的运行时需求，平台团队负责把它翻译成具体的 K8s/Nomad/ECS 实现。这种"开发者签 YAML 契约、平台兑现"的关系，比"中台搞个统一管理界面让业务来填表"健康得多。
第二个动作，把运行时和应用分开。Augment Code 那份 2026 平台 Leader Job Spec 里写得很清楚——AI 平台团队该独占的是 agent orchestration 层、模型网关、guardrails、audit trail。这些东西 80% 的业务都需要、但每个业务自建都不划算。而每个业务自己的 prompt、grader、eval dataset、agent 编排逻辑、UI/UX、领域知识库——都应当下放。这些东西做得好不好取决于业务团队对自己业务的理解深度，中台再"专业"也替代不了。
第三个动作最反直觉，对中台团队的同事最难接受——放弃"操作界面"对外的执念。过去做中台的成就感来自"我们的平台被多少业务方用"。但 AI 时代这套打法不再奏效。业务方用 Claude Code 半天能撸出他们要的界面，比中台模板里配出来的更贴他们业务。中台对外的接口应该是 SDK、CLI、API、契约规范文档，不应该是 SaaS 操作页面。
CNCF Platforms White Paper 里把这个原则总结成一句话：
Platforms are the thinnest reasonable layer that provides consistency.
最薄、足够一致、剩下的留给业务自由。这才是 AI 时代中台的样子。
跟读者有什么关系
我知道你不一定关心阿里和字节怎么拆中台。所以最后一节讲讲这事跟"在公司里做平台、中台、基础架构"的人有什么关系。
如果你在中台团队，这两年最危险的不是技术选型错，是叙事保守。一个本能反应是：业务团队自建工具会冲击中台存在感，所以要把更多业务流程"中台化"挡住。这个反应是错的。Wired 那 5000 个裸奔应用证明了一点——业务自建是堵不住的，治理空洞才是真正的风险。中台团队的存在价值不会因为下放业务定义权而变弱，反而因为承担了"运行时治理 + 暴露面治理"这种业务搞不定的脏活，价值更刚性。
如果你在业务团队，要学会读"中台输出物"的形态变化。如果你的中台团队还在给你做 Web 操作界面、让你登录他们平台填表，问问他们能不能给你一份 SDK 或者一份契约文档让你跟代码集成。如果他们给不了，那个中台短期内还能用，长期会被你绕开。这不是中台团队人不行，是范式不匹配。
如果你在做行业级中台标准，包括 Eval 标准、Agent 标准、模型治理标准，形态比"有没有"更重要。Anthropic 那篇文章给整个行业做了一件功德无量的事——发布了一份开放词典，没卖任何东西。我们国内做行业标准的常见路径是"先建一个大平台，再在平台里定义标准"，结果业务方因为不想被绑在这个平台里就不来用。倒过来的做法是先发标准、平台变成可选实现之一。这才是契约思维。
回到那次内部讨论
那个用 Claude Code 半天搭出来的 Agent 评测页面，比我们中台模板里能配出的更贴业务。这件事本身不能解读为"中台失败了"。它说明的是另一件事——中台和业务争"操作界面"和"业务流程定义"这一层，已经不再有意义。AI Coding 让业务团队自己干这层的成本崩塌了。
但这不等于中台没用。Wired 5000 个应用裸奔的反例同样真实。治理、运行时、契约这一层，业务团队反而更搞不定，更需要中台。
所以我的判断是：中台不会消失，但你认知里的中台会。需要做减法的，是认知里那个"集中决策、统一界面、SaaS 操作、业务方来用"的中台形象。需要做加法的，是"提供契约、提供运行时、提供模板、把判断权下放、把治理权收紧"的新中台形态。
Anthropic 那六个词的字典让我反复琢磨——task、trial、grader、transcript、outcome、harness。这不是一份产品规格，是一份让所有 Agent 系统都能互相对话的开放协议。这种东西如果是中国某家大厂率先发布的，影响力远比再多一个"国产 Agent 中台"大得多。
而能不能做出这种东西，不取决于你有多少工程师、多少预算，取决于你愿不愿意把判断权让出去、把契约定下来、把执行权交回业务。
这是 AI 时代中台团队最该练的功课。