过去十年，平台团队的底气来自一句话：别自己造轮子，我们替你做好了。业务组想搭一套 CI/CD，Infra 组已经把 Jenkins 模板和部署脚本备好了。想加个监控面板，Prometheus 和 Grafana 的配置已经封装成一键接入。业务组想用消息队列，Kafka 集群的运维和 SDK 封装都帮你管完了。这套逻辑成立的前提是轮子造起来又贵又慢，复用比自建划算。
这个前提正在被 AI 侵蚀。不是慢慢松动，是底层经济模型被掀翻了。
GitClear 2025 年的代码质量研究覆盖了 2.11 亿行变更，显示 AI 辅助编码导致重复代码块急剧增加，重构行为明显下降，复制粘贴的克隆代码量在攀升。当一个产品经理花十分钟让 AI 生成一套内部工具、一个数据看板、一条自动化流水线时，那句“别自己造轮子”就失去了它曾经的分量。造轮子的成本降到了让业务组不再需要犹豫的程度。
但这不是 Infra 组退场的信号。它的角色需要转场。
DRY 原则统治了软件工程几十年，不是因为重复本身有罪，而是因为代码曾经昂贵。我在《超越 DRY：AI 原生软件工程的思考》里讨论过这个变化：AI 生成软件的时代，真正需要复用的东西不再总是最终代码，而是支撑代码生成的内核。当 AI 把编写代码的边际成本压到接近零时，在代码层面重复就不再是主要矛盾。GitClear 的数据里重复代码激增这件事，单独看吓人，但放在新成本结构里看，它指向的是另一件事：代码正在从长期资产变成廉价耗材。
这个变化在工程实践上已经有具体表现。以前工程师遇到一个棘手的 Bug，本能是读源码、打断点、在脑子里模拟执行路径。现在遇到同样的 Bug，可以用 AI 现场生成一个分析脚本，在全量日志上跑一遍，直接在可视化界面里看到错误源头。我在《一次性软件与被压缩的现实》里把这种工具称为解压缩工具：它们的价值不在于长期存在，而在于用廉价代码换取高解析度的现实。代码不再只是需要小心维护的资产，也可以是获取认知的工具，用完就可以丢弃。
这个判断对 Infra 组来说不是抽象的软件工程争论。业务团队过去绕不开平台，是因为自建一套东西的启动成本高、维护成本高、出事后的修复成本也高。AI 先降低了第一项成本，让“我先自己搭一个能用的”变成了更常见的选择。Infra 组长久以来引以为傲的价值锚点，在 AI 辅助开发面前变薄了。
真正不能重复的，不是某个函数或模块，而是核心能力层和约束层。支付清算的能力不能在每个业务组里各写一份。数据权限的边界不能被每个 Agent 自己定义。这些才是必须集中维护、反复复用、不允许分叉的东西。
这就引出了一个关键概念：生成内核（generative kernel）。一个组织交付给业务团队和 agent 的东西，不再是一个功能固定的平台或成品软件，而是一套可以按需组装的工具组合。这套东西包含三个部分。
第一部分是不可替代的核心能力。支付 API、商品目录、用户认证，这些是组织真正值钱的资产，业务组靠自己造不出来。第二部分是引导知识：工程设计哲学、最佳实践、常见陷阱。过去这些知识需要工程师花几年时间在工作中内化，现在可以系统性地编码为 agent 上下文，成为交付物本身的一部分。第三部分是杠杆工具，把 agent 容易出错的不确定任务转化为确定性的操作。比如 Stripe 的订阅管理工具，用户用 JSON 描述想要的套餐结构，工具自动完成 SKU 创建和配置，保证结果正确。
三类组件合在一起，构成了 agent 完成任务的完整接口。复用发生的层面变了：不是复用一段代码或一个 API，而是复用一套能让 agent 稳定完成任务的完整能力层。
Shopify 的 agent 平台已经在这个方向上走出了一步。他们没有再做一套“商家管理后台 SDK”，而是把 Catalog API 做成了可供 AI agent 直接查询的结构化基础设施，把商家端的核心能力包装成 MCP server。同一个逻辑也在支付领域重现。Stripe 的 agent 工具链把支付能力和最佳实践封装为 MCP server、agent skills、CLI 三件套。agent 调用它来收付款，和人类开发者调用 SDK 逻辑一样可靠，但交互对象从人变成了机器。
复用单位上移之后，Infra 组要交付的东西不能停留在人类开发者视角的共享库和模板上。
CNCF 的平台白皮书把平台定义为自服务 API、工具、服务和知识的基础。DORA 把平台工程界定为提供共享高质量工具和 golden path 的社会技术实践。这两套框架在各自的时代都是有效的，但它们默认的终端用户是人。现在需要往前推一步：平台必须同时是 agent 可调用、可验证、可治理的。
GitHub Copilot 的 cloud agent演示了这个形态的雏形。它获取一个临时开发环境后，可以浏览代码、做出修改、运行自动化测试和 linter。GitHub 把 repo、Actions、测试、PR review 接成了一个 agent 的执行闭环。agent 不只是被允许写代码，还能自己验证自己写的对不对。
这种 paved road 就是 Infra 组的新产品形态，它包含几个相互咬合的层次。agent 可读的文档：不是写给人类浏览的 wiki，而是可以注入 agent 上下文窗口的知识结构。工具注册中心或 MCP gateway：管控 agent 能调用哪些工具、在什么条件下调用。golden path：编码为 agent 可执行的 workflow。eval、trace、test 闭环让 agent 能自我验证。权限和审计层建立最小权限原则。baseline skills 和 context infrastructure 为每个 agent 提供默认起点。还有一套反馈机制，持续揭示哪些路径上 agent 成功率高、哪些路径上频繁失败。
每一层单独看都不算新鲜，但合在一起，它构成了一个完整的代理执行环境：agent 在其中知道自己有什么能力、能做什么、边界在哪、错了怎么被发现。这就是 agent 时代的 paved road。
把执行权下放给 agent 之后，风险面不是变小了，而是改变了形态。
OWASP 针对 LLM 应用的十大风险明确列出了 prompt 注入、不安全的输出处理和过度授权。agent 接入工具以后，失败模式从生成错误答案升级为执行错误动作。MCP 工具投毒是一个新攻击面：一个被入侵或设计不当的 MCP server 可能向 agent 投送恶意指令，进而触发对生产系统、客户数据或财务接口的实际操作。
这些风险没有哪一项能被业务组独立消化。一个市场团队用 AI agent 自动生成了几十份竞品报告，但没有能力审计这些 agent 调用了哪些工具、读到了哪些不该读的数据、执行了哪些没有授权的操作。影子 agent 的问题比影子 IT 更棘手，因为后者的后果主要是未经授权的成本，前者的后果包含未经授权的动作。
OWASP AI Agent 安全速查表提出的原则恰好就是 Infra 组新的防守范围：最小权限、按工具划分权限范围、显式授权、监控与可观测性。它们必须建在 paved road 里面，而不是留给每个业务团队各自摸索。也是在这个意义上，中央边界不是限制，而是保护：它让业务组可以放心地把 agent 放出去执行任务，因为知道一定有权限墙和审计日志兜着底。
所有这些线索最终汇到一个点上：Infra 组的核心产出不是平台功能，是信任。
过去信任的建立逻辑是“别自己造，用我们的，我们测试过、生产跑过、比你手搓可靠”。在 AI 降低自建成本之后，这条逻辑的护城河浅了。但新的信任来源也出现了：当 agent 沿着 Infra 铺设的路径走时，它的成功率更高、失败模式更可控、行为可被审计和复盘。这种信任不需要说服对方“别碰代码”来建立，只需要用实际的 agent 执行数据说话。
这条逻辑有一个来自实践的关键前提：Infra 的 adoption 失败，从来不是技术问题，而是信任问题。业务组不用你的平台，往往不是因为技术架构不行，而是因为他们觉得走你的路比自己走更麻烦，或者在边缘场景下不信任你的平台能兜住。AI 降低了他们绕路的成本，但也让绕路的代价变得更可见。重复代码和失控的 agent 行为积累到一定规模后，会以一个让管理层不得不正视的方式浮现出来。
生成内核同时解决了这两端：它把 agent 成功所需的全部能力封装进去，也把控制 agent 风险的边界编码进去。复用的单位从代码和平台功能，迁移为能力和约束的打包。Infra 组的目标仍然是信任和 adoption，只是信任不再来自“轮子我替你造好了”，而来自“沿着这条路走，agent 更容易成功，出了问题也知道在哪查”。对于任何正在重新定位自己的 Infra 组来说，这句话就是新 pitch 的第一版草稿。