最近在为集团内部做一些 AI 中台工具，其中有一件事让我反复思考：我们到底还应该怎样做中台？
我们要做的是一个服务于 Agent 的评测平台。集团内部有很多业务线，每个业务都在尝试做自己的 Agent。只要做 Agent，就绑不开评测。一个 Agent 能不能上线，能不能稳定迭代，能不能被业务信任，本质上都要回到评测。评测不是一个附属模块，而是 Agent 产品化过程里的核心基础设施。
从今年年初开始，我们已经搭建了一个 Agent 评测平台，包含评测集录入、评测任务管理，以及一些可以自由配置的评估器。最开始做这个平台时，我们沿用的仍然是传统企业中台的思路：做一个类 SaaS 的统一平台，把公共能力沉淀下来，让各个业务线都来使用。
这套思路在过去很自然。因为业务要自己做一个平台，成本很高。中台的价值很大程度上来自替业务把重复的东西做掉。业务不用再搭页面、写流程、做权限、搞数据表、配任务调度，只需要接入中台，使用中台，就能把很多事情跑起来。
但最近我明显感觉到，这个前提正在变化。
AI Coding 流行之后，开发平台类工具的门槛被显著降低了。对没有开发能力的同学来说，用 AI 做一些简单页面、表单、后台工具，已经变得越来越常见。对有开发能力的业务团队来说，在 AI 的配合下，开发过去由中台提供的工具和平台，成本也大幅下降。
这在以往很难想象。过去一个业务团队如果说要自己做评测平台，大概率会被认为是重复建设，是资源浪费，是不划算的。但现在，他们真的可以做，而且可能做得很快。更重要的是，他们离自己的业务场景更近，知道自己的 Agent 要解决什么问题，知道什么样的评测结果才有意义，也知道哪些页面、流程和指标最符合自己的使用习惯。
于是中台遇到了一个很现实的问题：如果业务团队自己也能快速搭平台，中台还应该做什么？
我现在越来越倾向于认为，AI Coding 不是简单提升了研发效率，而是改变了中台的经济学基础。
过去，中台存在的一个核心理由是：应用层工具的建设成本高，所以集中建设更划算。今天，当 AI 把应用层工具的建设成本打下来之后，统一做一个操作平台这件事本身的价值就会下降。中台如果仍然执着于做统一页面、统一入口、统一操作后台，就会发现自己很难跑赢业务。
不是因为中台团队能力不够，而是因为这个位置天然变得不占优。
业务团队离问题更近，反馈链路更短，变化速度更快。当业务每天都在调整 Agent 的策略、任务、prompt、知识库和交互方式时，一个统一 SaaS 化平台很容易变成瓶颈。它看起来统一，实际上可能是把不同业务的差异强行塞进同一个产品形态里。最后要么平台越来越复杂，要么业务绕开平台自己做。
这不是中台该不该努力的问题，而是中台应该站在哪一层的问题。
中台要退到哪里
我现在的判断是：AI Coding 时代，中台确实要更靠后。但这里的靠后，不是简单退到更底层的技术组件，也不是把自己变成一组冷冰冰的 API。中台真正应该后退到的位置，是业务自建系统无法自然形成一致性的地方。
换句话说，中台不应该再把重点放在替业务做一个统一工具，而应该放在让业务各自做工具时，仍然运行在同一套公共契约之下。
以 Agent 评测为例，业务完全可以自己做评测页面，自己设计任务流程，自己管理实验，甚至自己开发评估器。这些东西高度贴近业务，中台未必应该强行统一。但有一些东西不能完全放任各业务各做各的。
比如，什么叫一次评测？评测任务的输入输出应该如何定义？评测集应该如何版本化？评估器的结果应该如何表达？不同业务的评测指标能不能横向比较？一次 Agent 变更之后，如何知道是模型能力提升了，还是评测集被污染了？评测结果的置信度、稳定性、可复现性，应该怎么被记录？哪些评估器是人工规则，哪些是 LLM-as-a-Judge，哪些又需要人工抽检兜底？
这些问题不是一个页面能解决的。它们是契约问题，是标准问题，也是基础设施问题。
过去中台喜欢做一栋大楼：所有人都进入同一栋楼，走同一个门，使用同一套设施。AI Coding 之后，业务可能会自己快速搭出很多小楼。中台再去阻止这件事，既不现实，也未必正确。更好的方式也许是：中台不再坚持所有人必须住进同一栋楼，而是去定义道路、电网、水管、消防标准和验收规则。
业务可以自己装修，甚至可以自己盖楼，但这栋楼必须接入同一套基础设施，必须满足同一套安全和质量标准，必须能被集团层面看见、理解和治理。
所以，中台要后退，但不是退到无关紧要的位置，而是退到更关键的位置。它从操作界面的提供者，变成公共契约的定义者。从平台功能的建设者，变成组织协同成本的管理者。从替业务做事，变成让业务做出来的东西可以被连接、比较、复用和治理。
统一不再发生在 UI 层
这也意味着，中台的交付形态要变化。
过去我们交付一个 SaaS 平台，业务进入平台使用。现在我们可能需要交付的是一套评测协议、一套数据 schema、一套 evaluator SDK、一套任务执行引擎、一套指标注册机制、一套结果追踪和审计能力，以及一套可以被业务系统调用的 API。业务前台可以不同，但底层的评测记录、指标口径、评估器标准、实验追踪和权限审计应该是统一的。
在这个意义上，统一不再发生在 UI 层，而是发生在协议层、数据层、方法层和治理层。
这其实是一个很大的变化。因为做 SaaS 平台时，中台团队容易把自己理解成产品团队：我要设计功能、设计页面、设计用户路径，让业务来用。做契约和基础设施时，中台团队更像是在设计一种组织内部的语言。
这套语言要足够稳定，让不同业务可以对齐；又要足够开放，让业务可以扩展；还要足够可执行，不只是文档，而是能通过 SDK、API、校验器、指标系统和运行时机制真正落地。
中台也要向前走
但这并不意味着中台只能往后退。
我反而觉得，中台还有一个往前走的方向，只是这个往前不再是往应用层抢位置，而是往问题定义层走。
在 Agent 评测这件事上，真正困难的往往不是做一个评测页面，而是判断什么是好的评测。业务团队可以很快做出一个平台，但未必能系统性地想清楚评测方法。比如评测集如何构造，如何避免只测常见问题，如何覆盖长尾风险，如何设计对抗样本，如何区分能力问题和产品策略问题，如何用离线评测预测线上表现，如何判断一次 prompt 修改是提升还是过拟合。
这些不是纯工程问题，而是方法论问题。它们介于产品、算法、数据和业务之间。中台如果只做工具，很容易被 AI Coding 替代；但如果能沉淀方法，定义标准，提供最佳实践和参考实现，它就会重新获得位置。
所以我觉得，中台往前走的方式，不是做一个更大的统一平台，而是成为业务构建系统时的默认方法提供者。
比如，中台可以提供一套 Agent 评测的参考框架：不同类型 Agent 应该怎么分层评测，任务完成率、事实准确性、工具调用正确性、稳定性、成本和安全性之间如何权衡，哪些指标适合自动化评测，哪些必须引入人工抽检，什么时候应该做回归测试，什么时候应该做线上 A/B，什么时候离线评测已经不足以支撑判断。
中台也可以提供一套参考实现。不是要求业务必须使用某个统一平台，而是给业务一个高质量的样板间。业务可以直接使用，也可以拿去改造。但只要它沿用中台定义的契约，它就能接入集团统一的评测底座，能复用公共评估器，能沉淀公共 benchmark，能让评测结果被横向理解。
这可能是一个更适合 AI Coding 时代的中台形态：不是中心化控制所有应用，而是通过标准、协议、SDK、模板和参考实现，影响业务系统的生长方向。
重复造轮子不一定总是坏事
这里有一个不太符合传统中台直觉的判断：业务重复造轮子，不一定总是坏事。
在过去，重复建设通常意味着浪费。但在 AI Coding 时代，造一个轮子的成本变低了，而且业务自己造的轮子可能更适合自己的路况。中台真正需要避免的，不是所有重复建设，而是不可连接、不可比较、不可治理的重复建设。
如果业务自己做了一个评测平台，但它的评测任务、评估器、指标、结果和日志都符合统一契约，那么它未必是坏事。它可能是业务前台的快速创新。相反，如果所有业务都被迫使用一个统一平台，但各自通过各种 workaround 绕过系统，最后数据口径不一致、指标不可解释、评测不可复现，那看似统一，实际并不统一。
真正的统一，不是大家都用同一个界面，而是大家在关键问题上使用同一种语言。
这也是我对中台更靠后的阶段性答案：中台要后退到业务差异的后面，站在公共语言、公共协议、公共数据和公共治理的位置上。它不必规定业务每天怎么操作，但要规定什么东西可以被称为一次评测，什么结果可以被信任，什么指标可以被比较，什么能力可以被复用。
与此同时，中台也要向前走，走到方法论和问题定义层。它要帮助业务理解，什么样的 Agent 值得评，怎么评才有效，哪些指标会误导团队，哪些实验结论不可靠，什么样的评测体系能支撑真实的产品迭代。
一个可能的判断是：AI Coding 会让应用层工具越来越便宜，但会让判断力、标准化能力和组织协同能力越来越贵。
过去中台的价值，是把东西做出来。以后中台的价值，可能是让大家做出来的东西不互相割裂、不各说各话、不在关键问题上失去共识。
中台能力的重新定义
这对中台团队的能力要求也会变化。
我们不能只问这个功能业务要不要用，还要问这个能力能否成为业务自建系统的底层依赖。不能只问平台页面是否完整，还要问业务如果不用我们的页面，是否仍然愿意使用我们的协议、SDK、指标体系和评测方法。不能只问我们有没有统一入口，还要问集团是否有统一的质量语言。
我还没有完全想清楚最终答案。尤其是在实际落地时，边界会很复杂。中台退得太后，可能变成纯基础设施，离业务越来越远，最后失去影响力。中台走得太前，又可能重新变成一个大一统平台，压不住业务变化，也跑不赢业务速度。
也许更合理的形态不是二选一，而是分层。
最上层允许业务高度自由，自己做页面、流程和场景化工具。中间层提供可复用的参考实现和模板，让业务不用从零开始。更底层则沉淀统一的契约、数据、评估器、任务引擎、追踪审计和指标体系。中台不再试图占据所有层，而是明确哪些层必须统一，哪些层应该开放，哪些层只提供默认选项。
这可能也是 AI 时代中台最重要的克制：不要因为过去做过统一平台，就默认未来仍然应该做统一平台。
当业务拥有更强的自建能力时，中台真正要守住的不是入口，而是秩序。不是页面，而是契约。不是所有工具的所有权，而是公共能力的定义权。
对我来说，这次做 Agent 评测平台最大的启发也在这里：AI Coding 让很多东西变得更容易被做出来，但也让组织内部更容易出现大量局部最优的系统。中台的价值不再是阻止这些系统出现，而是让这些系统在快速生长时，仍然能共享一套底层语言。
也许未来好的中台，不是那个让所有人都登录同一个平台的中台，而是那个即使业务各自拥有自己的平台，仍然能让整个组织在关键问题上保持一致的中台。