平台工程需要变得更人性化……同时减少对个人的依赖
内容提要
文章指出，AI代理使非工程师也能开发软件，平台工程需同时服务两类新用户：随意发挥的普通员工与严格按规则行事的AI代理。作者主张将规则写入平台而非依赖个人经验，借鉴Kubernetes的声明式配置、准入控制、资源限额和自动恢复机制，为每个应用和代理分配身份与权限，限制变更速度，提供可读的错误提示，并保留审计与紧急停止手段。
延伸解读
平台规则必须从“人脑”迁移到“系统”
文章指出，过去平台的安全护栏很大程度上依赖工程师的经验和自觉，比如不暴露数据库、不粘贴密钥。但新用户——文案、招聘、财务——没有经历过凌晨两点的故障教训，也不会读文档。因此平台必须把规则写成代码，在每次变更前自动检查，而不是指望用户“知道”。这要求平台从被动工具转变为主动守门人，否则创意爆发会直接变成安全漏洞。
AI代理需要“机器速度”的治理框架
代理与人类新用户相反：它们严格遵循指令，包括错误和未写明的规则，且会高速重试直到找到通路。文章建议为每个代理分配独立身份、限定权限和有效期，设置变更频率与资源配额上限，强制在预览环境工作，并保留审计轨迹和一分钟内可触达的急停开关。核心是把未写明的规则显式化，让代理能读懂拒绝原因并修正请求，而非反复撞墙。
借鉴Kubernetes的四个契约模式
文章将Kubernetes的机制映射到新平台用户：声明式配置让用户表达意图而非步骤；准入控制确保所有变更经过同一套书面规则，没有VIP通道；资源限额为代理和人类设置天花板；自动恢复假设任何变更都可能出错，通过小步发布、监控和回滚让错误变得“无聊”。这些模式原本用于容器编排，现在可用于同时支持人类、工程师和代理三类构建者。
平台需要“更少人性”地执行，但“更人性”地沟通
文章强调平台工程要同时做两件事：执行层面减少对人的依赖，用控制循环替代记忆和人工审查；交互层面则要更人性化，接受意图而非指令，用平实语言解释拒绝原因，例如告诉用户“这会让客户列表公开，这里是保持内部访问的设置”。好的错误提示相当于同事的提醒，让非工程师用户无需变成工程师也能安全地构建。
Q&A
为什么说AI代理让平台工程需要同时服务两类新用户？
AI代理使非工程师也能开发软件，平台工程需同时服务两类新用户：随意发挥的普通员工（如文案、招聘人员、财务主管）和严格按规则行事的AI代理。普通员工会即兴发挥、绕过规则，而AI代理会完美执行规则（包括错误规则），两者都需要平台提供不同的支持。
平台工程如何将规则从个人经验转移到平台中？
平台需要为每个应用和代理分配独立身份与最小权限，在运行时注入密钥而非交给个人，对每次变更进行策略检查（如禁止无理由的公开端点、禁止仪表盘直连生产数据库），并采用小规模部署、监控和自动回滚。错误提示应像好同事一样用平实语言解释原因和修改方法。
AI代理在平台使用中可能带来哪些风险？
AI代理会完美执行指令（包括错误或未写明的规则），遇到阻碍时会快速重试并尝试其他路径，可能以机器速度在多个服务上造成破坏；它们每次会话都无记忆，不会从事故中学习，且总是自信。因此需要为代理设置身份、权限、变更速度上限、预览环境、审计追踪和紧急停止开关。
Kubernetes的哪些机制可以借鉴来管理新型构建者？
Kubernetes的四个机制可借鉴：声明式配置与协调循环（用户声明意图，平台自动实现）、准入控制（所有请求经过同一套书面规则检查）、资源限额（在启动前设定上限，防止失控）、假设失败并自动恢复（健康检查、重启、渐进式发布和回滚）。这些机制可让少量人员支持数千名构建者。
平台工程如何做到“更人性化”又“更少依赖个人”？
“更少依赖个人”体现在执行层面：规则不再只存在于个人记忆中，审查不依赖某人清醒，护栏不靠同事的皱眉，而是变成全天候运行的控制循环。“更人性化”体现在交互层面：平台接受意图而非指令，用平实语言解释“拒绝”的原因，让非工程师无需先成为工程师就能构建真实应用。
对于普通员工（非工程师）使用平台，平台应提供什么样的错误提示？
平台应像好同事一样用平实语言解释“不”的原因，并给出具体修改建议。例如，不说“被策略0042拒绝”，而说“这会让你的客户列表在互联网上公开。这里有一个保持内部访问的设置。”错误提示是这些构建者最接近同事皱眉的体验，因此要写得像同事的提醒。
