云原生时代的平台工程，最初解决的是 Kubernetes、微服务、GitOps 和分布式架构带来的交付复杂度。随着 AI Agent 进入企业应用，平台面对的对象不再只有容器、数据库和流水线，还包括模型、提示词、工具权限、知识源与运行时策略。平台工程正在从“提供基础设施自助服务”演变为“管理应用、资源和智能体的统一控制面”。
平台管理对象正在扩张
传统内部开发者平台通常围绕几类资源展开：代码仓库、构建流水线、Kubernetes 工作负载、数据库、消息队列、密钥和可观测性配置。开发团队通过服务目录或模板申请资源，平台团队负责把组织规范固化到自动化流程中。
Agent 引入了新的依赖关系。一个业务智能体可能同时需要：
- 一个或多个模型，以及明确的版本、区域和成本限制；
- 可调用的内部 API、数据库查询工具或工单系统；
- 提示词、评测数据集和知识库索引；
- 身份凭证、审批规则和最小权限策略；
- 对输入、工具调用、模型输出和费用的追踪能力。
这意味着 Agent 不能只被当作部署在 Pod 中的一段普通代码。容器状态正常，并不代表智能体的回答可靠；接口返回 200，也不代表它调用工具时遵守了业务权限。平台需要同时管理确定性的基础设施状态与带有概率性的模型行为。
把 Agent 纳入平台控制面
一个可落地的方向，是为 Agent 定义声明式契约。开发者描述智能体需要什么模型、工具和运行策略，平台控制器再负责创建底层 Deployment、ServiceAccount、Secret 引用、网络策略与观测配置。
下面是一个可以改造的示例。这里的 Agent 是示意性自定义资源，并非来源摘要声明的标准 API；实际使用前需要由平台团队实现对应 CRD 和控制器。
apiVersion: platform.example.com/v1alpha1
kind: Agent
metadata:
name: incident-assistant
namespace: operations
spec:
image: registry.example.com/agents/incident-assistant:1.4.2
model:
provider: approved-model-gateway
name: reasoning-medium
maxTokens: 2048
monthlyBudgetUSD: 500
tools:
- name: read-metrics
permission: read-only
- name: create-ticket
permission: require-approval
knowledge:
indexes:
- operations-runbooks
runtime:
replicas: 2
serviceAccountName: incident-assistant
policy:
redactSecrets: true
retainTracesDays: 14
allowedNamespaces:
- operations
保存为 agent.yaml 后，可以这样提交并检查状态：
kubectl apply -f agent.yaml
kubectl get agent incident-assistant -n operations
kubectl describe agent incident-assistant -n operations
一个成熟的控制器还应把业务状态写入 status.conditions，例如 ModelReady、ToolsAuthorized、EvaluationPassed 和 DeploymentAvailable。这样，GitOps 系统看到的不只是 YAML 已经同步，还能判断 Agent 是否真正具备上线条件。
平台护栏必须覆盖模型行为
对普通应用，平台护栏通常集中在镜像签名、资源限额、网络边界和发布审批。Agent 还需要增加三层控制。
工具边界：每个工具应有独立身份和权限，读取指标与修改生产配置不能共享同一凭证。高风险操作应进入审批流程，而不是依赖提示词中的一句“执行前请确认”。
模型与数据边界：平台应限制可用模型、数据驻留区域和允许进入提示词的数据类型。日志与追踪系统需要脱敏，避免把密钥、客户数据或完整对话直接写入普通应用日志。
质量与成本边界：延迟、令牌消耗和调用费用只是运行指标，回答正确率、工具选择准确率和拒答表现同样需要评测。由于模型行为可能随模型版本、提示词和知识库内容变化，评测应进入发布流程。
可以这样实践一个最小发布门禁。下面的命令假设仓库中已有可执行的评测脚本，并要求关键场景通过率不低于 90%：
python -m agent_eval \
--agent incident-assistant \
--dataset tests/incidents.jsonl \
--min-pass-rate 0.90 \
--report build/evaluation.json
kubectl apply -f agent.yaml
kubectl rollout status deployment/incident-assistant -n operations --timeout=180s
评测数据集应覆盖正常请求、越权诱导、提示词注入、工具故障和知识缺失，而不能只准备几条理想问答。涉及生产变更的 Agent，还应保留人工审批和快速停用开关。
平台团队如何开始
不必立即建设一个包揽所有模型和框架的庞大平台。更稳妥的顺序是先选择一个业务边界清晰的 Agent，把模型网关、身份、工具授权、追踪和评测串成一条可重复的交付路径，再抽取服务模板和策略。
落地时可以检查以下事项：
- 应用、基础设施资源和 Agent 是否进入同一服务目录，并有明确负责人；
- 模型、提示词、工具定义和评测集是否能够版本化与回滚；
- Agent 是否使用最小权限身份，高风险工具是否要求审批；
- 平台是否同时观察基础设施指标、模型质量、工具调用与成本；
- GitOps 同步成功之外，是否还有评测通过和策略合规等就绪条件；
- 是否定义停用 Agent、撤销凭证和回滚模型版本的应急流程。
面向智能体企业的平台工程，重点不是给现有平台简单增加一个“AI”入口，而是把 Agent 变成可声明、可审计、可评测、可回滚的受管对象。只有应用、云资源和模型行为共享一致的交付与治理机制，企业才能在扩大 Agent 使用范围时控制权限、成本和生产风险。