\n\n本文探讨了 AI 时代平台工程师的角色转变。面对开发者自主构建智能体带来的管理挑战，平台工程师应提供标准化的基础组件与治理框架，打造更具吸引力的开发者平台。
译自：How AI transforms your role as a platform engineer
作者：Zohar Einy
平台工程的目标一直是使工程师在不牺牲标准的情况下更加自力更生。
实现这一目标的最佳方式是通过你所控制的平台提供自服务。当开发人员需要一项新服务时，他们点击一个按钮，就能获得一个仓库、一条 CI 流水线、监控和一个 Dockerfile。你可以让他们这样做，是因为你内置了工程标准。这种自服务与标准的结合对你和你的开发人员来说是双赢的。他们获得了速度，你获得了控制权。
随着 AI 的出现，开发人员变成了智能体工作流的构建者。通过构建智能体（Agent），他们可以自动化大部分工作。他们正在构建 SRE 智能体、发布智能体、技能等。他们已经拥有使用所有这些 AI 工具的权限，因此他们开始将各种东西缝合在一起。
“随着 AI 的出现，开发人员变成了智能体工作流的构建者。通过构建智能体，他们可以自动化大部分工作。”
这导致了在没有人工监督的情况下，执行破坏性操作的智能体缺乏治理和可见性。
我们称之为智能体蔓延（agent sprawl）。
那么，这对于作为平台工程师的你意味着什么呢？
你应该如何思考你与开发人员之间的关系？
在 AI 世界中作为平台工程师，你当然希望开发人员更多地使用 AI。但每当技术采用率上升时，对你负责的所有事情（如成本和治理）的需求也会随之上升。
被你本应赋能的人绕过，也会让人感到有些不适。你以通过自己的帮助使开发人员更有能力而感到自豪，但现在他们自己在构建智能体。
AI 赋予了开发人员构建任何自动化工具的能力，例如 SRE 智能体、部署智能体，甚至是帮助其智能体工作的基本目录。
为了让他们的智能体更强大，他们希望为其提供真实的动作和对真实数据的访问。为此，他们仍然必须经过你。但即使没有你提供的动作和上下文湖（context lake），他们仍然可以创造出强大到足以产生危险的东西。
假设一个工程团队在没有经过你的情况下为自己构建了一个 SRE 智能体。我们甚至可以更进一步说，它在分类问题方面表现非常好，为团队每次事故节省了数小时。
- 但这个智能体可能没做什么？
- 它可能没有留下审计踪迹。
- 它可能没有尊重个人身份信息（PII）。
- 它可能没有使用适当的凭据。
清单还可以列很长。
该团队肯定没有从一开始就按照公司预期的标准来构建智能体。
他们为什么要这样做呢？他们有真实的、迫切的需求，而 AI 让解决问题变得容易。他们还感受到来自工程领导层的压力，要求产出更多成果。
开发人员不应该等待（而且他们也不会等待）
有了这种新工具和新的紧迫感，他们只是在以一种新的方式完成工作，主要做两件事：
- 他们正在使用 MCP 查询数据并获取洞察，以帮助他们或其智能体工作。
- 他们正在构建像 SRE 智能体这样的智能体，这些智能体正变得更有能力，并在整个 SDLC 中承担更多责任。
开发人员（和智能体）获取所需数据的问题，可以通过提供丰富的上下文湖以可扩展的方式解决。
但是，当所有工程师都开始构建智能体时，你如何以可扩展的方式促进这一进程？
平台工程的产品管理属性
考虑到我们都生活在新的现实中，平台团队有三个选择。
你可以无所作为，让开发人员随心所欲地构建智能体。反正智能体蔓延已经存在了，为什么要反抗呢？问题在于，最终你会失去可见性、失去标准，并且在出现问题时（一定会出问题）无法干预。
你可以强制要求所有 AI 开发都必须流经平台团队。如果你选择这条路线，你可能会面临反抗，因为工具已经在开发人员手中了。Cursor 在本地运行。Claude Code 在本地运行。这是减慢工程速度而非加速的好方法。
最后，这是唯一行之有效的方案：让平台足够引人入胜，让开发人员主动选择在其上构建智能体。
那么，你如何让它更具吸引力呢？
这就是我喜欢称之为平台工程的产品管理属性。你首先需要了解开发人员实际想做什么，然后移除最困难的部分。
我会让你在你的组织中开展工作，与开发人员交谈，找出他们在构建智能体时认为困难的地方。
但我也会让你看看我所看到的一些共性，因为构建智能体的开发人员每次都会遇到同样的障碍。数据分散、杂乱的集成连接、缺乏审批关卡（或过多）、或对关键系统的访问权限过大，等等。
我看到这些问题在所有处于“试用”阶段的智能体中不断重复。但如果你成功消除了其中的一些摩擦，或者至少将其最小化，那么开发人员创建的智能体最终不撞南墙的可能性就会大大增加。
还有一点。构建了有用东西的开发人员希望其他人能从中受益，就像在开源中一样。如果有一个地方可以分享他们团队构建的事故分类技能，他们就会把它放在那里。如果有一个注册表，其他人可以在那里找到并扩展它，它就会随着时间的推移变得更好。平台成为了优秀成果积累的地方。
这就是平台引人入胜的原因。当开发人员觉得他们正在使用专为他们（及其智能体）设计的体验时。
如何为你的工程团队创造引人入胜的智能体构建体验？
既然你的开发人员已经是智能体构建者，你的工作之一就是让这种体验尽可能无缝和愉快。他们是来创造新事物的。这是一种创作者体验，需要一种不同的思维方式。这就是开发者体验 2.0。
以下是我认为在为构建者设计时最重要的几点：
- 他们需要在开始之前知道什么是可用的。一个准备构建发布管理智能体的开发人员不应该到处打听才能发现他们可以访问哪些数据、存在哪些集成或可以执行哪些操作。这种探索必须是无缝的。
- 他们需要早期收获。让开发人员投入到你的平台的最快方法是让他们快速做出一些能运行的东西。启动模板、示例工作流和预构建技能都是他们开始 fork 的绝佳场所。一个能在小时内运行出成果的开发人员，比一个花了一整天研究如何身份验证的人，更有可能在你的平台上构建真实的东西。
“一个能在小时内运行出成果的开发人员，比一个花了一整天研究如何身份验证的人，更有可能在你的平台上构建真实的东西。”
他们需要看到别人构建了什么。这是开发人员热爱的开源的一面。构建了有用东西的开发人员想要分享，而从零开始的开发人员想要看看已经存在了什么。技能注册表或智能体目录会让平台感觉充满活力。当开发人员可以浏览同事构建的内容并对其进行扩展时，平台就不再感觉像基础设施，而开始感觉像一个社区。
让我们展开谈谈如何帮助你的团队在开始构建智能体之前发现可用资源。
你应该给他们提供哪些智能体需要的构建块？
我之前写过关于“智能体工程隐藏的技术债”的文章，其中我详细阐述了每个演示智能体都会产生的 7 个技术债区块。
可靠的上下文湖。 智能体需要实时了解情况，并且这些信息必须准确：谁拥有这项服务、上次部署更改了什么、这项服务依赖于什么，以及现在谁在值班。
如果没有这个，构建自己智能体的团队会把更多时间花在数据管道上，而不是实际逻辑上，并获取他们本不该拥有的数据访问权限。平台团队将其整合到一个地方，保持更新，并通过 API 或 MCP 暴露出来，供任何智能体查询。
预先审核的集成。 智能体需要与系统对话：GitHub、PagerDuty、Datadog、Jira 以及你的云服务商。获得这些系统的访问权限是一个过程。自行构建智能体的开发人员可能会独立完成该过程。通过集中管理，平台团队只需审核一次集成，每个智能体都能使用它们。
受治理的批准动作清单。 智能体不仅仅是阅读。它们还会做事：触发回滚、开启 PR、重启 pod、关闭事故。自行构建智能体的团队要么完全避免执行动作（因此智能体只是告诉你该做什么），要么在没有防护栏的情况下连接它们。平台团队将哪些动作作为工具可用进行了定义，因此问题永远不是“这个智能体能做这个吗？”，而是“我们是否明确允许它这样做？”
确定性策略。 一个建议生产回滚的智能体没问题。一个在凌晨 2 点触发回滚而不唤醒任何人的智能体则不行。你不能通过像“在生产环境做任何事之前请询问”这样的提示词或技能来处理这个问题。策略必须编码为关卡：测试环境自动批准，生产环境在工作时间外需要人工签核。它们要么通过，要么不通过，并且需要是确定性的。
审计踪迹。 当凌晨 3 点出现问题时，你需要知道智能体做了什么、访问了什么数据、是什么触发了它以及结果是什么。自行构建智能体的团队几乎从不预先添加日志。起初这感觉像是额外负担。平台团队需要将审计日志内置到工作流引擎中，使其自动化。无论是否有人想起要查询，每项操作都记录在案。审计踪迹的额外好处是，它还可以作为决策追踪，帮助智能体随着时间的推移而改进。
评审流程。 将智能体从演示转为生产，需要平台人员检查权限、测试边缘情况并定义什么是真正的“生产就绪”。平台团队必须拥有该生命周期：从实验、到评审、到信任、再到完全自主。
审批或人在回路（human-in-the-loop）层。 在某些时候，每个智能体都需要停下来询问人类。自行构建审批逻辑的团队会在不同方面犯错。有的硬编码 Slack 消息，有的完全跳过。由于没有人共享模型，当智能体需要跨团队工作时，审批逻辑就会在衔接处断裂。平台提供一个标准：这些动作自动批准，这些需要人工，这是通知对象。基于平台构建的团队无需考虑这些。
这些本身都不复杂。但当每个工程师都在构建自己的智能体时，问题就会迅速累积。
责任范围扩大了
形势正在发生变化，而你原来的工作并没有消失。服务目录仍需维护。黄金路径仍需更新。CI/CD 集成仍会中断。
现在，在所有这些之上，组织中运行着你没有构建的智能体，访问着你配置的系统，做着你无法完全看到的事情。从未写过基础设施代码的开发人员正在从头开始构建内部工具。你负责的领域扩大了，但没有人从你的盘子里拿走任何东西来腾出空间。
一些平台团队正在关注这一局面的展开，并感觉他们正在失去对自己花费数年精心构建的东西的控制。在某种程度上，确实如此。每个基础设施决策都流经平台团队的时代已经结束了。
“每个基础设施决策都流经平台团队的时代已经结束了。”
仅仅因为你不再拥有垄断地位，并不意味着你不再重要。实际上，你将变得比以往任何时候都更加重要。 因为开发人员不会等待，智能体的数量正在爆炸式增长。而在你组织中的智能体数量还足够少、可以提前布局的窗口期还在。
我们讨论了平台工程师和开发人员的双赢。在使用 AI 的同时，两个团队仍然可以实现双赢。
Port 是为步入这一新角色的平台工程师而构建的，他们希望建立双赢的体验。它为你的团队提供了基础，让开发人员在他们的新构建者角色中获得所需的构建块：受治理的数据、预先审核的集成、批准的动作、审批关卡等。现在每个工程师都是构建者。是时候在保持控制的同时，为他们构建一个平台了。全 工智能
