企业并不缺少 AI 试点，真正困难的是把试点变成可治理、可观测、可持续运行的生产系统。IDC 的 2026 AI in Networking Special Report Survey 指出，阻碍 AI 项目落地的核心问题越来越偏向基础设施：32.6% 的受访者提到安全顾虑，26.8% 提到自动化挑战，24.7% 则受限于人员时间和技能。
Agentic AI 会进一步放大这些问题。一个智能体可能在几秒内访问模型、向量数据库、SaaS API、内部业务服务和其他智能体。调用路径动态变化，组件可能分布在多个云和运行时中。此时，网络不再只是负责“连通”，而是承载身份、策略、审计和端到端信任的基础控制面。
智能体让东西向流量变成动态工作流
传统应用通常拥有相对稳定的服务调用图：前端访问后端，后端访问数据库。Agentic AI 的调用关系更像运行时生成的工作流：
- 智能体读取用户请求并调用模型。
- 模型选择工具，智能体访问内部 API 或外部 SaaS。
- 工具结果进入另一个模型或智能体。
- 流程根据结果继续调用、重试、分支或终止。
这类交互跨越应用、服务、API、工具和数据源，还可能涉及不同的智能体框架、模型提供商、云平台及开源组件。流量增加只是表象，更棘手的是通信对象和数据路径会动态变化。
只在智能体框架中配置工具白名单并不够。框架控制通常只能覆盖自身运行时；如果某个服务绕过框架直接请求外部接口，或者团队部署了未登记的“影子智能体”，应用层策略便可能失效。基础设施层需要提供独立于具体框架的限制和证据，例如：
- 哪个工作负载调用了哪个模型或工具；
- 请求是否携带可信的服务身份；
- 哪些命名空间可以访问敏感数据；
- 数据是否离开了允许的区域或云环境；
- 拒绝、超时和异常重试发生在哪一跳。
因此，网络应被视为平台控制面的一部分。它不替代智能体编排框架，而是在不同运行时和云环境之间提供更一致的策略实施、遥测和审计能力。
把安全策略放到调用路径上
面向生产环境的网络控制至少要覆盖四个层次。
工作负载身份用于回答“谁在调用”。相比依赖 IP 地址，基于服务身份的认证更能适应容器扩缩容和跨集群部署。
最小权限通信用于回答“允许调用什么”。智能体不应因为需要访问一个模型端点，就获得访问整个互联网或全部内部服务的权限。
应用层策略用于回答“可以执行什么操作”。端口级规则只能限制连接；对于高风险工具，还需要根据 HTTP 路径、方法、身份和数据分类实施更细粒度的控制。
统一遥测用于回答“实际发生了什么”。网络日志、分布式追踪、模型调用记录和智能体执行轨迹需要通过共同的请求标识关联，否则故障调查只能依靠多个控制台中的时间戳猜测。
这些能力还要覆盖智能体的非确定性行为。例如，循环调用可能造成成本激增，自动重试可能把短暂故障扩大成流量峰值，而被污染的工具结果可能诱导智能体访问原本不需要的服务。限流、超时、熔断和出口控制因此不仅是可靠性措施，也是治理边界。
可以这样实践：默认拒绝智能体的非必要出口
下面是一个可改造的 Kubernetes 最小示例。假设智能体运行在 agent-system 命名空间，只需要访问同一命名空间中带有 app=model-gateway 标签的模型网关，并通过集群 DNS 解析服务名。
先创建命名空间和策略：
apiVersion: v1
kind: Namespace
metadata:
name: agent-system
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: agent-default-deny-egress
namespace: agent-system
spec:
podSelector:
matchLabels:
role: agent
policyTypes:
- Egress
egress: []
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: agent-allow-dns-and-model-gateway
namespace: agent-system
spec:
podSelector:
matchLabels:
role: agent
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53
- to:
- podSelector:
matchLabels:
app: model-gateway
ports:
- protocol: TCP
port: 8080
将内容保存为 agent-network-policy.yaml 后应用：
kubectl apply -f agent-network-policy.yaml
kubectl get networkpolicy -n agent-system
部署一个带有对应标签的测试客户端：
kubectl run agent-client \
--namespace agent-system \
--image=curlimages/curl:8.12.1 \
--labels=role=agent \
--command -- sleep 3600
kubectl exec -n agent-system agent-client -- \
curl --connect-timeout 3 http://model-gateway:8080/health
kubectl exec -n agent-system agent-client -- \
curl --connect-timeout 3 https://example.com
在支持 NetworkPolicy 的网络插件上，第一个请求应能到达模型网关，第二个外网请求应被阻止。运行前需要修改模型网关的标签、端口和健康检查路径，使其与实际部署一致。
这个示例只解决 Kubernetes 内的三、四层出口限制，并不能识别 HTTP 工具名称、请求参数或敏感数据。生产系统通常还需要出口网关、服务网格、API 网关或其他七层策略组件，用于集中处理 TLS、服务身份、域名白名单、速率限制和审计日志。跨云场景还要确保各环境采用一致的身份和策略语义。
平台与单点工具不是二选一
调查显示，企业对平台方案和最佳单点工具仍存在分歧。在偏好平台的受访者中，32.9% 看重更强的安全性，27.7% 希望降低复杂度，24.2% 则关注更快部署。
平台的价值在于建立共同底座，例如统一身份、连接、策略分发和遥测格式。但封闭平台也可能限制模型提供商、智能体框架和安全工具的选择。单点工具能够快速解决特定问题，却可能带来策略语义不一致、日志割裂和重复运维。
更现实的架构是“稳定底座加可替换能力”：平台负责跨环境的一致控制，专业组件通过标准接口接入。评估平台时，可以检查它是否支持第三方和开源工具、能否插入新的安全与可观测能力，以及更换模型或智能体框架时是否需要重建整套网络架构。
上线前检查这五件事
- 为每个智能体和工具服务分配可验证的工作负载身份。
- 默认拒绝非必要的东西向和出口流量，再按业务调用图逐项放行。
- 将网络遥测与智能体轨迹、模型请求和工具调用关联起来。
- 为外部 API 设置域名限制、超时、重试上限、限流和成本告警。
- 定期发现未登记的智能体、凭证和外部连接，避免形成影子执行路径。
Agentic AI 的生产化问题不能只靠更好的模型解决。智能体越自主、分布越广，企业越需要在基础设施中建立统一的身份、策略、可观测性和治理边界。合适的网络方案不是替应用做决定，而是确保每一次动态决定都发生在可验证、可限制、可追踪的通道内。