智能体 AI 带来的变化不只是模型更强，而是软件开始自主调用 API、操作数据并持续执行多步任务。CNCF 发布的技术分析提出了一个务实判断：支撑这类系统的关键能力，不必从零发明；现代分布式应用已经使用的云原生生态，可以继续承担调度、隔离、可观测性、安全策略和故障恢复等职责。
智能体仍然是分布式工作负载
一个生产级智能体通常包含模型推理、工具调用、状态存储、任务队列和外部服务访问。它看起来是一个能够规划和行动的整体，落到基础设施层却仍是一组需要治理的分布式工作负载。
智能体还放大了几个传统问题：
- 一次用户请求可能派生多个步骤，运行时间和资源消耗难以提前确定。
- 工具调用会跨越数据库、内部 API 和第三方服务，权限边界容易扩散。
- 模型输出具有不确定性，同一输入未必产生完全相同的执行路径。
- 失败可能发生在推理、网络、工具或状态提交阶段，需要区分可重试与不可重试错误。
这些问题与云原生系统长期处理的弹性伸缩、服务身份、策略控制、链路追踪和任务编排高度重合。Kubernetes、容器、服务网格、OpenTelemetry、策略引擎和工作流系统因此可以成为智能体平台的组成部分，而不是只负责部署一个模型 API。
“可信”必须落实到每一次行动
智能体的风险不只在回答是否准确，更在于它是否真的执行了操作。一个生成错误文本的助手可能需要纠正；一个误删数据、错误退款或泄露凭证的智能体会直接造成业务事故。
可信运行环境至少需要建立四层控制：
- 身份：每个智能体及其工具拥有独立的工作负载身份，避免共享长期凭证。
- 最小权限：网络、API 和数据权限按任务收敛，默认拒绝未声明的访问。
- 可观测性：记录任务 ID、模型调用、工具参数、耗时和结果，但对密钥与个人数据做脱敏。
- 执行约束：高风险动作增加审批、幂等键、额度限制和超时，不能只依赖提示词要求模型“谨慎操作”。
这里有一条重要边界：云原生基础设施可以控制智能体在哪里运行、能访问什么以及如何审计，却不能自动保证模型推理正确。输出验证、事实核查、评测集和人工审批仍属于应用层责任。
可以这样实践：把智能体当作受限服务部署
下面是一个可改造的 Kubernetes 示例。它不依赖某个特定智能体框架，假设镜像 ghcr.io/example/agent-api:1.0.0 在 8080 端口提供 HTTP 服务，并通过 Kubernetes Secret 获取模型 API 密钥。运行前请替换镜像地址和域名；示例中的 NetworkPolicy 还要求集群安装支持该能力的 CNI 插件。
apiVersion: v1
kind: ServiceAccount
metadata:
name: agent-api
namespace: agents
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: agent-api
namespace: agents
spec:
replicas: 2
selector:
matchLabels:
app: agent-api
template:
metadata:
labels:
app: agent-api
spec:
serviceAccountName: agent-api
automountServiceAccountToken: false
containers:
- name: agent-api
image: ghcr.io/example/agent-api:1.0.0
ports:
- containerPort: 8080
env:
- name: MODEL_API_KEY
valueFrom:
secretKeyRef:
name: model-credentials
key: api-key
- name: OTEL_EXPORTER_OTLP_ENDPOINT
value: http://otel-collector.observability:4318
- name: TOOL_TIMEOUT_SECONDS
value: "15"
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: "1"
memory: 1Gi
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: 8080
periodSeconds: 10
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
capabilities:
drop: ["ALL"]
---
apiVersion: v1
kind: Service
metadata:
name: agent-api
namespace: agents
spec:
selector:
app: agent-api
ports:
- port: 80
targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: agent-api-default-deny
namespace: agents
spec:
podSelector:
matchLabels:
app: agent-api
policyTypes: ["Ingress", "Egress"]
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: gateway
ports:
- protocol: TCP
port: 8080
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: observability
ports:
- protocol: TCP
port: 4318
创建命名空间和凭证后即可应用配置：
kubectl create namespace agents
kubectl -n agents create secret generic model-credentials \
--from-literal=api-key='REPLACE_WITH_REAL_KEY'
kubectl apply -f agent-api.yaml
kubectl -n agents rollout status deployment/agent-api
kubectl -n agents get pods,networkpolicy
这个配置刻意关闭了 ServiceAccount Token 自动挂载，并采用非 root、只读文件系统和默认受限网络。实际接入模型服务时，还需要为 DNS 和指定的模型 API 出口增加精确的 egress 规则。不要为了快速连通而永久开放 0.0.0.0/0，否则 NetworkPolicy 很快会失去治理价值。
从单个部署走向平台能力
团队不应一开始就建设庞大的“智能体操作系统”。更稳妥的路径，是从现有平台逐步补齐智能体特有的控制面：
- 使用统一入口验证用户身份，并把调用者身份传递到工具层。
- 为工具建立显式注册表，描述参数、权限、超时、幂等性和数据敏感级别。
- 用 OpenTelemetry 关联一次任务中的模型请求、工具调用和队列消息。
- 将高风险工具拆成独立服务，通过策略引擎或人工审批控制调用。
- 对推理成本、任务时长、失败重试和工具调用次数设置预算。
- 把提示词、模型版本、工具定义和策略配置纳入版本管理与发布审计。
采用云原生底座也有成本。Kubernetes 和服务网格会增加运维复杂度，短任务未必适合长期驻留的 Deployment，GPU 调度也需要额外的容量规划。规模较小的团队可以先使用托管容器与托管队列，只保留身份、审计和权限隔离等关键原则；当任务量、合规要求或多团队协作增长后，再引入更完整的平台能力。
真正值得复用的不是某个产品名称，而是云原生已经验证过的工程方法：声明式配置、最小权限、故障隔离、全链路观测和自动恢复。智能体改变了应用如何做决策，却没有取消分布式系统的基本规律。