1. 项目概述当AI Agent遇上企业级挑战最近和几个做企业服务的朋友聊天大家不约而同地都在讨论同一个话题AI Agent。这玩意儿听起来很酷对吧一个能自主理解、规划、执行任务的智能体仿佛给每个业务都配了个不知疲倦的“数字员工”。从自动生成周报、智能客服到复杂的供应链预测和代码审查AI Agent的想象空间巨大。但聊到具体落地尤其是想在企业内部大规模、稳定地跑起来朋友们脸上的兴奋劲儿很快就变成了苦笑。问题出在哪总结下来就三句话“跑不动、稳不住、管不住”。“跑不动”说的是算力。一个大点的模型动辄需要几十GB显存推理延迟要求毫秒级现有的CPU服务器或者老旧的单卡GPU根本扛不住训练一次模型等得黄花菜都凉了。“稳不住”指的是可靠性。今天Agent还能流畅对话明天可能就因为内存泄漏或者资源争用直接“躺平”生产环境谁敢用“管不住”则是安全和合规。Agent接触的都是企业核心数据和业务流程权限怎么控制行为如何审计模型会不会“胡说八道”泄露机密这“三重门”几乎卡死了绝大多数企业AI Agent从Demo走向生产的路。而今天要聊的TCE在我看来就是针对这三大痛点给出的一份相当扎实的“企业级答卷”。它不是一个单一的软件或框架而是一套围绕智算基础设施构建的完整技术栈与运维体系核心目标就是让AI Agent在企业里不仅能“跑起来”更能“跑得好”、“跑得安心”。接下来我就结合自己的观察和实践拆解一下TCE是如何从GPU算力、DPU数据加速、到全生命周期管控这三个维度来回应挑战的。2. 核心需求解析企业AI Agent落地的“三重门”在深入技术细节之前我们必须先搞清楚企业级场景对AI Agent的要求到底和个人开发者、小型团队有什么本质不同。这决定了所有技术选型和架构设计的出发点。2.1 第一重性能之槛——“跑得动”这里的“跑得动”绝非指能在你本地电脑上弹出个对话框那么简单。它意味着在满足业务SLA服务等级协议的前提下能够承载预期的并发请求量。高吞吐与低延迟的平衡一个客服Agent可能需要同时服务上千个对话每个对话的响应时间必须在秒级甚至毫秒级比如语音交互。这对模型的推理速度提出了极致要求。大模型与大数据量企业Agent往往需要基于私有知识库进行检索增强生成RAG或者对多模态信息如图片、表格进行处理。这要求基础设施不仅能快速运行大参数量的LLM还要能高效处理并行的数据加载与预处理流水线。资源利用率与成本GPU是昂贵的资源。如何让一块GPU同时服务多个Agent任务多实例推理或者在不同时间段灵活调度资源给训练和推理任务直接关系到ROI投资回报率。常见的torch.cuda.empty_cache()手动清理显存只是杯水车薪需要系统级的资源池化和调度。从网络热词如gpu burnGPU压力测试、高密度gpu服务器、gpu集群运维就能看出大家对算力的焦虑是普遍且深入的。2.2 第二重稳定之基——“稳得住”稳定性是生产系统的生命线。AI Agent的“不稳”可能来源于多个层面硬件与驱动层nvrm: gpu ... failed这类错误信息是运维的噩梦。GPU驱动兼容性、散热问题、显存错误纠正ECC是否开启都会影响长期运行的稳定性。软件与依赖层PyTorch、CUDA版本冲突pytorch安装教程gpu是个永恒的热门话题深度学习框架内存管理缺陷都可能导致服务内存缓慢增长直至OOM内存溢出崩溃。服务与架构层单个Agent服务挂了如何无缝切换如何实现滚动更新而不中断业务如何监控GPU利用率、显存占用、推理延迟等关键指标并设置预警“稳得住”要求基础设施具备高可用、容错、可观测和自动化恢复的能力。2.3 第三重治理之维——“管得住”这是企业级应用独有的、也是最复杂的挑战。它关乎安全、合规与可控。数据安全与隐私Agent在回答问题时会不会把训练数据里包含的敏感客户信息“回忆”并泄露出去如何确保知识库检索和模型推理的全链路数据都在安全域内权限与访问控制不同部门如财务、HR、研发的Agent能访问的数据和能执行的操作必须严格隔离。这需要精细到API级别的权限体系。行为审计与可解释性Agent做出的关键决策如是否批准一笔贷款必须有迹可循。需要记录其思考过程Chain-of-Thought、调用的工具Tool Calling以及最终输出的依据以满足内部审计和外部监管要求。模型风险管理如何防止Agent被恶意提示词Prompt注入攻击如何设定输出过滤器Output Filter防止生成有害或不恰当内容“管得住”的本质是将AI Agent纳入企业现有的IT治理框架使其成为一个可信、可控、可审计的业务组件而非一个难以驾驭的“黑盒”。3. TCE的三重答卷技术架构深度拆解面对上述需求TCE提供了一套分层的解决方案。我们可以将其想象成建造一栋高楼GPU是钢筋水泥提供了最基础的承重算力DPU是高速电梯和管线保障了材料运输的效率数据流而管控平台则是整个建筑的设计图、物业管理和安防系统调度与治理。3.1 第一重答卷弹性高效的智算底座——“跑得动”的基石TCE通过构建云化的GPU算力池来解决“跑得动”的问题其核心思想是资源解耦与弹性调度。3.1.1 异构算力统一纳管企业内部的GPU资源往往是异构的既有用于训练的计算卡如NVIDIA A100/H100也有用于推理的卡如T4、L4甚至还有国产化芯片如昇腾系列。TCE通过设备插件Device Plugin和自定义调度器Scheduler将这些异构算力统一抽象为“算力单元”向上层应用提供一致的申请接口。开发者不再需要关心具体卡型只需声明“需要多少带显存的GPU”系统会自动匹配。实操心得在资源池规划时建议根据业务特性划分资源组。例如将高带宽显存如HBM的卡划分给训练和大模型推理任务将能效比高的卡如T4划分给高并发的轻量级推理任务。通过给节点打标签label来实现例如gpu-type: a100-80g和gpu-type: t4。3.1.2 细粒度资源切分与共享一块80GB显存的A100如果只跑一个简单的分类Agent无疑是巨大的浪费。TCE支持多种细粒度共享方案时间片共享基于Kubernetes的扩展资源实现多个PodAgent服务实例分时复用同一块物理GPU。适用于离线训练或低优先级批量任务。空间显存隔离利用NVIDIA MIGMulti-Instance GPU技术将一块物理GPU划分为多个具备独立显存、计算核心和带宽的实例。每个实例如1个7G的MIG实例可以独立分配给一个Agent服务实现硬隔离避免相互干扰。这对于多租户环境至关重要。虚拟化切分通过vGPU或类似技术将单卡虚拟化为多个带有部分显存的小卡。这种方式灵活性高但开销相对MIG略大。3.1.3 高性能容器与镜像优化“跑得动”也离不开软件栈的优化。TCE会提供针对不同AI框架和CUDA版本优化的基础镜像。# 一个典型的TCE优化镜像可能基于以下构建 FROM nvidia/cuda:12.1.1-cudnn8-runtime-ubuntu22.04 # 预安装特定版本的PyTorch并针对该CUDA版本编译最大化性能 RUN pip install torch2.2.0 torchvision0.17.0 torchaudio2.2.0 --index-url https://download.pytorch.org/whl/cu121 # 安装优化的通信库如UCX和监控工具如DCGM RUN apt-get install -y datacenter-gpu-manager同时TCE会集成镜像缓存预热功能。当调度器决定在某个节点启动一个包含大镜像几个GB的Agent服务时可以提前将镜像拉取到该节点避免因镜像下载导致的任务启动延迟。3.2 第二重答卷DPU加速的数据平面——“稳得住”的引擎如果说GPU是负责“思考”的大脑那么数据训练数据、请求输入、模型参数就是需要高速流动的“血液”。传统CPU处理网络、存储协议栈的开销在AI密集IO场景下成为巨大瓶颈。这就是DPU数据处理单元登场的意义。3.2.1 计算与数据卸载DPU是一张专为数据中心设计的智能网卡它可以将原本由CPU负责的网络TCP/IP、存储NVMe over Fabric、安全加密解密等任务卸载到专用硬件上执行。网络加速在分布式训练中Worker节点间需要频繁同步梯度All-Reduce操作。通过DPU的RDMA远程直接内存访问能力数据可以直接从一个GPU的显存传输到另一个节点的GPU显存完全绕过CPU和操作系统内核延迟极低吞吐量极高。这对于大规模模型训练至关重要。存储加速当Agent需要从远端存储如Ceph、S3加载巨大的模型文件几十GB或海量知识库数据时DPU可以直接处理存储协议将数据直接DMA到GPU显存或主机内存极大减轻CPU负载提升数据加载速度。3.2.2 提升稳定性和隔离性DPU的卸载能力直接提升了系统的稳定性。降低CPU负载CPU从繁重的IO任务中解放出来可以更专注于业务逻辑和调度减少因CPU资源竞争导致的服务抖动。故障隔离网络、存储的故障处理逻辑在DPU上运行即使出现问题也较难影响到主机上运行的AI Agent服务实现了故障域的隔离。可观测性增强DPU通常提供更精细的流量监控和性能指标如RDMA报文速率、延迟为诊断网络性能问题提供了新的视角。3.2.3 与GPU的协同在TCE的架构中DPU和GPU不是孤立的。通过NVIDIA的BlueField DPU和Spectrum交换机的配合可以实现端到端的加速。例如在AI训练集群中构建一个基于RoCERDMA over Converged Ethernet的高速无损网络DPU负责提供可靠的RDMA服务GPU则专注于计算从而构建出一个“稳得住”的高性能计算环境。3.3 第三重答卷全生命周期的智能管控——“管得住”的大脑有了强大的“身体”GPUDPU还需要一个聪明的“大脑”来指挥和约束。TCE的管控平台覆盖了AI Agent从开发、部署、运行到下线的全生命周期。3.3.1 开发与编排层这一层解决“如何定义和组装Agent”的问题。TCE可能会提供一个低代码/DSL领域特定语言的编排界面。可视化编排通过拖拽组件LLM、知识库检索器、工具函数、条件判断的方式构建Agent的工作流Workflow。这降低了AI应用开发门槛让业务专家也能参与。模版与市场提供常用的Agent模版如“智能客服”、“会议纪要生成”、“代码审查助手”支持一键部署。同时也支持用户分享和订阅模版。3.3.2 部署与运维层这是管控的核心确保Agent服务的高可用和可观测。智能调度调度器不仅考虑GPU资源还会综合考量节点负载、网络拓扑利用DPU加速的节点优先、亲和性将需要频繁通信的服务调度到同一台物理机等因素做出最优的调度决策。弹性伸缩基于自定义指标如每秒请求数、平均响应延迟、GPU利用率实现Agent服务的自动水平伸缩HPA。例如当客服对话请求队列超过阈值时自动扩容出新的Agent实例。全链路监控与告警集成Prometheus、Grafana等生态采集从基础设施GPU温度、显存、DPU流量到应用层Agent请求量、Token消耗、工具调用成功率的全方位指标。并设置智能告警如“显存使用率连续5分钟超过95%”或“知识库检索超时率上升”。3.3.3 安全与治理层这是实现“管得住”的最后一道也是最关键的一道防线。身份与访问管理IAM与企业的统一身份认证如LDAP/AD集成。每个Agent服务都有一个服务账户其权限被严格限定。例如一个HR招聘Agent只能访问简历数据库相关的API。数据与模型安全静态加密模型文件、知识库向量存储在磁盘上是加密的。动态加密利用DPU的硬件加密引擎对节点间传输的梯度、数据进行加密。隐私计算对于特别敏感的数据支持联邦学习等隐私计算框架让模型在不交换原始数据的情况下进行训练。审计与合规操作审计记录所有对Agent的创建、更新、删除、扩缩容操作。行为审计关键Agent的每一次推理过程其输入Prompt、中间思考链Chain-of-Thought、调用的工具、最终输出都可以选择性地被记录到安全的日志中心供事后审计和分析。这需要与Agent框架深度集成。内容安全过滤在Agent的输出层部署内容安全过滤器防止生成违法、违规或不符合企业价值观的内容。4. 实操指南基于TCE理念构建你的AI Agent基础设施理解了TCE的架构思想后我们如何将其落地虽然你可能无法直接获得完整的TCE产品但其设计理念和选型思路完全可以借鉴。下面是一个基于主流开源技术栈的简化实现方案。4.1 环境准备与硬件选型4.1.1 硬件规划计算节点选择支持PCIe 4.0及以上、具备足够PCIe槽位和供电的主板。根据业务需求混合配置GPU训练/大模型推理节点配备NVIDIA A100/H100或类似高性能卡建议使用NVLink互联的多卡配置。高并发推理节点配备多张NVIDIA T4或L4这类卡能效比高适合部署大量轻量级Agent实例。DPU节点选择配备NVIDIA BlueField-2/3 DPU或类似智能网卡的服务器。DPU节点可以作为计算节点的网络和存储网关也可以独立部署为存储或网络加速节点。网络至少需要25GbE以上的以太网环境推荐100GbE或更高并启用RoCEv2以支持RDMA。交换机组网建议采用Spine-Leaf架构避免带宽瓶颈。4.1.2 基础软件栈安装操作系统Ubuntu 22.04 LTS或RHEL/CentOS 8内核版本建议5.15以获得更好的硬件支持。GPU驱动与CUDA从NVIDIA官网下载并安装与GPU型号匹配的最新稳定版驱动和CUDA Toolkit如12.1。# 示例安装CUDA 12.1 wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-ubuntu2204.pin sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600 sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/3bf863cc.pub sudo add-apt-repository deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ / sudo apt-get update sudo apt-get -y install cuda-12-1容器运行时安装Docker并配置NVIDIA Container Toolkit使容器能够使用GPU。# 安装NVIDIA Container Toolkit distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/libnvidia-container.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart dockerKubernetes集群使用kubeadm、k3s或RKE2等工具部署一个K8s集群。至少包含一个控制平面节点和多个计算节点。GPU设备插件在K8s集群中部署NVIDIA GPU设备插件将GPU资源暴露给K8s调度器。kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.1/nvidia-device-plugin.yml4.2 核心组件部署与配置4.2.1 部署Kubernetes GPU调度增强组件单纯的设备插件只能让Pod“看到”GPU但无法实现细粒度调度。我们需要更强大的调度器。NVIDIA GPU Operator这是目前社区的主流选择。它通过Operator模式自动化管理集群中所有与GPU相关的软件组件驱动、容器运行时、设备插件、监控等并支持MIG、时间片等高级功能。helm install --wait --generate-name \ -n gpu-operator --create-namespace \ nvidia/gpu-operator \ --set driver.enabledfalse \ # 如果节点已预装驱动则禁用 --set mig.strategysingle # 配置MIG策略自定义调度器对于复杂的调度策略如基于GPU型号标签调度、拓扑感知调度可以考虑使用Kubernetes Scheduling Framework编写自定义调度器插件或者使用Volcano、Kueue等批调度器来管理AI训练任务队列。4.2.2 部署DPU加速组件NVIDIA Network Operator用于在K8s集群中管理和配置BlueField DPU包括启用RDMA、创建VF虚拟功能等。部署RDMA CNI插件如whereabouts或rdma-shared-dp让Pod能够直接使用宿主机的RDMA设备。配置存储加速如果使用Ceph可以部署nvme-oftarget在DPU上为计算节点提供高速块存储。4.2.3 部署监控与日志系统GPU监控部署DCGM Exporter将GPU指标利用率、温度、显存、功耗暴露给Prometheus。应用监控在Agent应用代码中集成Prometheus客户端库暴露业务指标请求延迟、Token数、工具调用次数。日志收集部署Fluentd或Fluent Bit作为日志收集代理将容器日志统一收集到Elasticsearch或Loki中。4.3 AI Agent的打包与部署示例假设我们有一个基于LangChain开发的客服Agent它使用Qwen-7B-Chat模型并连接了一个内部知识库。4.3.1 编写Dockerfile与优化# 使用轻量级且兼容性好的基础镜像 FROM python:3.10-slim # 安装系统依赖 RUN apt-get update apt-get install -y --no-install-recommends \ gcc g git curl \ rm -rf /var/lib/apt/lists/* # 使用清华PyPI镜像加速并安装PyTorch根据CUDA版本选择 RUN pip install torch torchvision torchaudio --index-url https://pypi.tuna.tsinghua.edu.cn/simple # 复制依赖文件并安装 COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple # 复制应用代码 COPY . /app WORKDIR /app # 暴露端口 EXPOSE 8000 # 启动命令使用Gunicorn管理进程 CMD [gunicorn, -w, 4, -k, uvicorn.workers.UvicornWorker, --bind, 0.0.0.0:8000, main:app]注意事项-w 4指定了4个worker进程。这个数字需要根据GPU的并行处理能力和模型大小来调整。对于7B模型单个进程可能就能占满一张卡的算力此时多worker可能反而导致竞争。最佳实践是通过压力测试来确定。4.3.2 编写Kubernetes部署文件apiVersion: apps/v1 kind: Deployment metadata: name: customer-service-agent spec: replicas: 2 # 两个副本实现高可用 selector: matchLabels: app: customer-service-agent template: metadata: labels: app: customer-service-agent spec: containers: - name: agent image: your-registry/customer-agent:latest resources: limits: nvidia.com/gpu: 1 # 申请1个GPU memory: 8Gi cpu: 2 requests: nvidia.com/gpu: 1 memory: 8Gi cpu: 1 ports: - containerPort: 8000 env: - name: MODEL_PATH value: /models/qwen-7b-chat - name: KNOWLEDGE_BASE_ENDPOINT value: http://knowledge-base-service:8080 volumeMounts: - name: model-storage mountPath: /models volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc # 预置的PVC存储模型文件 nodeSelector: gpu-type: t4 # 调度到标有gpu-typet4的节点上 --- apiVersion: v1 kind: Service metadata: name: customer-service-agent spec: selector: app: customer-service-agent ports: - port: 80 targetPort: 8000 type: ClusterIP实操心得在resources.limits中明确设置GPU请求这是保证服务质量的关键。nodeSelector可以用于将不同类型的Agent调度到不同规格的GPU节点池实现资源分区管理。4.3.3 配置HPA自动伸缩apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: customer-agent-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: customer-service-agent minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Pods pods: metric: name: gpu_utilization # 需要DCGM Exporter提供此自定义指标 target: type: AverageValue averageValue: 70 # GPU利用率达到70%时触发扩容这个HPA配置了基于CPU利用率和GPU利用率两个指标进行伸缩更全面地反映了Pod的实际负载。5. 常见问题与排查技巧实录在实际运维中一定会遇到各种问题。下面记录几个典型场景和排查思路。5.1 GPU相关问题问题1Pod启动失败报错nvidia-container-cli: requirement error: unsatisfied condition: cuda12.1排查这通常是因为容器内所需的CUDA版本与宿主机NVIDIA驱动支持的CUDA版本不兼容。使用nvidia-smi命令查看宿主机驱动版本及支持的CUDA最高版本。解决确保基础镜像中的CUDA版本不高于驱动支持的版本。或者在安装GPU Operator时让其统一管理驱动和容器运行时保证一致性。问题2服务运行一段时间后响应变慢最终OOM被杀掉。排查首先检查Pod的监控图表观察显存占用是否随时间缓慢增长。进入Pod执行nvidia-smi确认显存泄漏。检查应用日志看是否有异常提示。常见于未正确释放的CUDA张量或缓存。解决在代码中确保在不再需要时将张量移回CPU.cpu()或直接删除del tensor。定期调用torch.cuda.empty_cache()但注意这会影响性能不宜频繁调用。考虑使用支持显存池化的推理框架如TensorRT-LLM或vLLM它们能更高效地管理显存。问题3多GPU卡负载不均只有一张卡在忙。排查检查部署配置。如果是单Pod多卡nvidia.com/gpu: 2需要确认AI框架如PyTorch是否正确地使用了torch.nn.DataParallel或torch.nn.parallel.DistributedDataParallel进行并行。解决对于推理服务更推荐使用多副本单卡的模式。即创建多个Pod每个Pod只申请1个GPU然后通过Service负载均衡。这样更简单也更容易实现弹性伸缩。可以使用K8s的Deployment直接设置replicas并配合HPA。5.2 网络与DPU问题问题1分布式训练速度远低于预期网络带宽成为瓶颈。排查使用ethtool检查网卡速率和状态。使用ibstat或ibstatus检查InfiniBand/RoCE状态。在训练代码中增加通信时间的日志或使用NCCL的调试环境变量NCCL_DEBUGINFO来观察All-Reduce等集合通信操作耗时。解决确认物理网络交换机、网线支持所需的带宽如100GbE。在K8s Pod配置中使用支持RDMA的CNI并正确挂载/dev/infiniband设备到容器。调整NCCL参数例如NCCL_IB_HCA指定使用的网卡NCCL_SOCKET_IFNAME指定使用的网络接口。问题2Pod无法通过RDMA通信。排查检查Pod是否成功挂载了RDMA设备。进入Pod执行ibv_devices看是否有设备列表。解决确保部署了正确的RDMA CNI插件并且节点上的MOFED驱动等已正确安装。检查Pod的securityContext是否包含了必要的权限如capabilities。5.3 管控与运维问题问题1如何快速定位是哪个Agent实例出了问题技巧为每个Pod注入一个唯一标识符作为环境变量如POD_NAME可通过Downward API获取并在应用日志和导出指标中带上这个标识。这样在查看集中式日志或监控仪表盘时就能快速过滤出问题实例。env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name问题2模型文件很大每次启动Pod拉取镜像或挂载模型都很慢。技巧镜像分层将稳定的基础环境OS、CUDA、PyTorch做成一层将经常变动的应用代码做成最上层。这样每次更新代码只需要拉取最上层的小镜像。使用Init Container预加载模型创建一个Init Container其唯一任务就是将模型文件从对象存储如S3下载到共享的EmptyDir或PVC中。主容器启动时模型已经就绪。使用有状态副本集StatefulSet配合持久化卷对于特别大的模型可以将其存储在持久化卷PV中。当Pod在节点间迁移时PV可以跟随挂载避免重复下载。问题3想对Agent的输入输出进行审计和内容安全过滤如何集成方案采用Sidecar模式。在Agent的Pod中除了主业务容器再部署一个Sidecar容器如一个轻量级的Python服务。这个Sidecar容器负责拦截主容器的HTTP请求/响应可以通过共享网络命名空间或配置流量转发实现。对请求的Prompt进行安全检查如敏感词过滤、提示词注入检测。对响应内容进行过滤和脱敏。将审计日志脱敏后发送到安全的日志后端。 这种方式实现了安全逻辑与业务逻辑的解耦便于统一管理和升级安全策略。构建一个能“跑得动、稳得住、管得住”的企业级AI Agent平台绝非一蹴而就。它需要从硬件选型、系统软件、容器编排、应用框架到安全治理的全栈考量。TCE所代表的技术方向为我们提供了一个清晰的蓝图以云原生和智算基础设施为基石通过GPU的弹性算力解决性能问题通过DPU的数据加速解决效率与稳定问题最后通过全生命周期的智能管控解决安全与合规问题。这套组合拳正是将AI Agent从炫酷的演示转变为驱动企业核心业务发展的可靠生产力的关键。在实际操作中从小规模试点开始逐步迭代架构持续积累监控数据和运维经验才是最终成功的路径。