前言

将一个 Agent 从 Demo 推向服务 1.8 亿注册用户的生产环境，核心挑战并非能否实现对话，而是如何将其融入既有的复杂线上架构，并确保端到端时延、召回质量与可观测性达到生产级要求。

神州租车是国内最大的连锁租车企业之一，运营车辆近 20 万辆，服务网络覆盖全国 360 多个城市。2026 年，神州租车启动租车 App 内嵌 AI 助手建设，目标是覆盖用户租车后的全生命周期管理，包括租还网点查询、订单状态跟踪、人工客服跳转、车型推荐、车控指令及售后车辆知识问答。一期功能聚焦车辆控制与用车知识问答，属于典型的 Agent Serving + RAG 场景，Agent 运行时底座采用阿里云函数计算 Agent Sandbox。

本文将围绕整体落地架构、核心诉求与挑战，以及基于 FC Agent Sandbox 的优化实践展开，并介绍项目上线后的实施成效与业务价值。

Agent 典型场景及方案

Agent 从 Demo 走向生产，核心依赖之一是 Runtime。Agent 本体及其工具链最终需要运行在具备弹性伸缩、强隔离和可观测能力的执行环境中。阿里云函数计算云沙箱以 Serverless 形态提供 Agent Runtime，为 Agent 提供云端隔离运行环境，支持按需创建环境、执行命令、运行代码、读写文件及启动临时服务，并在任务结束后自动释放资源，实现运行环境生命周期与任务生命周期对齐。

从负载形态看，Agent 对 Runtime 的诉求可归纳为三类典型场景：

Agent RL / Eval（海量环境池 / 极限压力）：以 SWE Bench、Computer Use、Browser Use 为代表，主要负载包括批量 rollout、reset 和 fork，环境吞吐直接影响训练与评测效率，核心诉求是十万至百万级环境创建、镜像加速与故障隔离。
Agent in Sandbox（Agent 宿主运行 / 长任务环境）：以 Coding Agent、长任务 Agent 为代表，具有生命周期长、状态依赖强、低活跃阶段空闲时间多等特征，核心诉求是会话亲和、休眠恢复与低空闲成本。
Agent use Sandbox（Agent Tools / 外部工具执行层）：以 Code Interpreter、Browser Use、MCP Server 为代表，具有高频突发、生命周期短、调用碎片化和时延敏感等特征，核心诉求是低时延创建、快速销毁与强隔离。

三类场景的负载特征虽有差异，但对 Runtime 的能力要求最终收敛为同一组基线：创建速度、并发容量、镜像分发、状态恢复、隔离强度与单位成本。任一维度存在短板，都可能在企业级 Agent 平台规模化运行时被放大为系统瓶颈。

神州租车的 Agent 属于典型的 Agent in Sandbox 场景，对长会话运行、知识库召回、用户侧端到端响应时延及全链路 Trace 均提出了严格要求。

整体落地方案

整体方案分为两层：一是神州租车现有业务系统接入生产级 Agent 的端到端请求链路；二是用车助手 Agent 的内部实现架构。

端到端接入链路

在神州租车存量业务系统中，Agent 可视为请求链路末端的执行单元，用户请求需经过既有系统链路后到达 Agent。具体来说，设备端及大前端请求首先经域名服务与 CDN 进入阿里云安全防护层，包括云防火墙与 DDoS 防护；随后由 API 网关转发至自研的 zuche proxy 代理，最终路由至 API 层的租车、资产运营、营销、开关锁、二手车等业务模块。本次新增的用车助手以 agentapi 形式接入。

Agent 服务与其他业务 API 复用同一套网关鉴权、限流及 WAF 策略，可直接继承现有安全治理能力。但每接入一个新的 Agent 或工具，仍需在网关侧手动更新路由配置。因此，二期计划引入主子 Agent 架构，由超级 Agent 统一路由和调度子 Agent，并完成 VPC 打通与 API 调用规范化。

用车助手 Agent 方案架构

用户请求通过上述端到端链路接入 Agentic 方案后，将携带 system prompt 并以 HTTP 请求形式发送至模型层。模型层基于 AGUI 协议，通过 SSE 流式返回内容；后端随之对流式输出进行缓存，并调用相应接口渲染多模态响应内容，最终以 AGUI 事件流形式返回前端。

用车助手 Agent 的内部架构主要包括三层：接口层、模型及上下文层、运行时层。Agent 挂载用车教学、车辆控制、车辆推荐等多个 Skills，每个 Skill 下配置相应 Tools，例如获取车型名称、获取车辆参数、调用百炼 RAG 获取用车讲解等。这些 Tools 进一步对接神州租车内部数据服务接口。

在二期架构演进中，当请求或任务复杂度提升，需要进行任务编排与拆解，且用户无需关注子任务的中间过程时，系统将引入超级 Agent 的主子调用架构。

落地过程中用户核心诉求及挑战

神州租车用车助手项目需要将 Agent 嵌入一套服务 1.8 亿注册用户的存量系统，并直接面向 C 端用户灰度上线，其生产级诉求主要集中在以下四个方面：

低代码快速构建 Agent

神州租车开发团队希望通过白屏化方式完成 Agent 的搭建与部署，降低开发和维护成本。核心挑战在于，基于模板快速创建的 Agent 仍需充分适配业务需求：模型、系统提示词、Skills、工具、记忆库、知识库、权限及网络策略等能力均应支持配置与调试，否则一旦超出框架能力边界，仍需通过二次编码完成定制开发。

端到端时延控制在 3 秒以内

端到端响应时延覆盖 FC 冷启动、知识库检索及模型推理等全链路耗时。在利用 Serverless 计算资源实现实例快速拉起的基础上，还需进一步优化 Agent 框架自身的启动与调用链路，确保整体响应达到预期。

基于车型 Metadata 的精准召回

按照业务预期，用车助手 Agent 需先调用车型接口获取用户实际租用的车型信息，再据此动态设置 metadata 过滤条件并检索百炼知识库。核心挑战包括：统一过滤标签的数据格式、实现过滤逻辑与模型选型解耦，以及持续优化文档切分策略和评测集。这些因素共同影响知识召回效果及后续优化效率。

短期会话记忆与全链路可观测

同一用户需在单个 Session 内保持 30 分钟的上下文信息，记忆连续性依赖实例与 Session 生命周期的绑定。同时，可观测链路需下钻至每个调用环节，并清晰透出 FC、LLM 与知识库侧关联的 requestId，否则线上问题的人工排查成本将显著增加。

基于 FC Agent Sandbox 的优化与最佳实践

端到端时延优化

本项目的端到端时延链路如下：

用户请求 → 客户端 App 及中台 → 调用 agentapi 进入 Agent 层 → 底层 FC 实例冷启动 → 通过 MCP 连接知识库并完成召回检索 → 调用百炼模型完成推理并返回 TTFF。

上线前压测发现，部分请求的端到端时延一度接近 20 秒，与业务预期存在较大差距。根因分析表明，时延主要来自 Agent 自身较重的启动逻辑：一方面，基于 LangChain 框架快速创建的 Agent 会在启动时同步拉起可观测探针，产生约 10 秒的启动时延；另一方面，Agent 启动时需与工具建立连接。由于知识库通过 MCP tool call 方式接入，底层 MCP 部署函数存在冷启动，耗时约 10～15 秒。

采用 MCP 方式接入知识库的原因将在知识库链路优化部分进一步说明。针对上述典型高时延问题，项目主要从以下方面进行优化：

FC 实例预留及函数会话亲和

函数计算实例生命周期与会话（Session）强绑定。通过会话亲和，可确保同一 Session 的请求始终路由至同一实例处理；同时，单个实例可承载多个 Session。结合预留函数实例，可最大限度规避冷启动。相较于按并发请求分别拉起活跃实例，单实例承载多 Session 也具有更低的资源成本优势。

该方案仍存在后续演进空间，也是多数 Agent Serving 场景在 Runtime 层面面临的共性问题：一是按用户维度实现鉴权与隔离；二是建立跨实例的同 Session 数据保留兜底机制。

神州租车用车助手属于多租户场景，需要确保不同用户调用 Agent 时的权限判定与请求数据相互隔离。同时，业务要求同一 Session 的请求数据保留 30 分钟。虽然可通过上下文与短期记忆方案满足该诉求，但在后台实例因平台原因自动轮转等极端情况下，如何保证用户上下文不丢失，仍需进一步探索。

MCP 直连知识库工具 Go 语言重写

如前所述，项目通过 MCP 形式接入用户知识库，相关 MCP 知识库工具部署在函数计算上，原有代码采用 Python 实现。排查发现，Python 应用初始化占用了较多时间：Python 代码包需要携带解释器及相关依赖，包体较大，初始化效率相对较低，是冷启动较慢的主要原因。

Go 版本采用单个静态二进制的编译形态，可将代码包由 Python 版本的 155 MB 压缩至 3 MB，显著提升拉取与启动速度，使冷启动时延由十余秒降低至百毫秒级。因此，用户侧无需再通过预留实例规避该环节的冷启动问题。

此外，知识库工具在每次召回时均需校验用户配置参数。针对这一链路，项目进一步完成参数缓存及 SDK 优化，用户可通过环境变量开启参数缓存能力，从而继续降低知识库调用时延。

知识库调用链路优化

知识库集成至 Agent 框架业界通常有两种主流方式：

第一种是上下文接入。Agent 在每次生成回复前获取用户输入，主动调用知识库检索接口，并将检索结果拼接至上下文后传递给模型。该方式可确保每轮调用均执行 RAG，但知识库检索在代码中仅表现为一次不在探针埋点范围内的普通调用，Trace 数据中无法呈现独立的检索 Span，存在可观测性缺失的问题。

第二种是工具接入。知识库以工具形式挂载至 Agent，大模型根据工具描述理解知识库的名称与用途，并自主判断是否调用。该方式的优势在于可观测性：工具调用遵循 Agent 框架标准路径，可被探针自动捕获为独立的检索 Span，相关入参、返回结果、耗时与 requestId 均可在 Trace 中追溯。

神州租车采用 MCP 工具方式接入知识库，主要基于两方面考虑：一是保障知识库调用链路的可观测性；二是用户问答场景并非每次模型输出都需要经过 RAG，由模型判断是否发起知识库检索可保留更高的调用灵活性。

神州租车用车助手的完整知识库检索链路如下：

以用户提问“空调怎么开”为例，模型不会直接调用知识库检索工具，而是先调用内部车型数据接口，获取该用户实际租用的车型，再基于车型信息发起检索，以避免将比亚迪秦的车辆手册内容返回给租用别克 GL8 的用户。

车型信息透传至百炼知识库并完成 metadata filter 后，系统以 agentic 模式进行多轮迭代检索，最终由模型基于精准召回的内容生成回答。项目同时设计了基础 fallback 机制：当百炼知识库未检索到与用户问题相关的知识时，模型将调用用户自有的联网搜索服务工具，进一步补充模型上下文。

整体链路可归纳为车型信息获取、metadata filter、RAG 检索，以及 fallback 场景下的外部工具调用。针对上述链路，项目完成了以下实现与优化。

基于车型信息的metadata filtering

如上文提到，这一步链路主要是为了应对用户询问A车问题确返还B车问题的badcase，实现方式简单来说是知识库文档在入库时按车型打上 metadata 标签，检索时带上标签过滤，把召回范围先收敛到本车型后再进行向量排序。

该链路主要用于解决用户询问 A 车型问题却返回 B 车型内容的 badcase。实现方式是：知识库文档入库时按车型添加 metadata 标签；检索时通过标签进行过滤，先将召回范围收敛至对应车型，再执行向量排序。

“过滤”主要有两种实现方式：

第一种是 Agent 全局过滤。Agent 每次调用知识库工具时均携带统一的过滤条件，相关配置在 Agent 侧全局生效，例如直接配置知识库召回过滤条件，或通过环境变量配置并由模型强制调用。该方式实现简单，但扩展性有限，维护成本较高。随着知识库文档类别与数量增加，例如不同车型的文档持续入库，用户要么需要为同一个 Agent 挂载与车型数量相同的知识库工具，分别配置过滤条件并指向同一个后端知识库；要么需要创建多个 Agent，并通过不同环境变量分别承载各车型的问答。两种方式均不适用于神州租车的业务场景。

第二种是请求级过滤。Agent 根据用户请求，或调用车型数据接口获取结果后，动态填写知识库过滤参数，并在调用请求中将该参数传入百炼知识库，在召回前完成数据过滤。动态生成的过滤参数最终作为知识库 MCP 工具的入参之一，即 metadata_filter。项目对 MCP 工具进行了相应改造，使其支持该参数。

以符合 AGUI 协议规范的 HTTP 调用为例，支持 metadata filtering 的请求格式如下：

curl https://xxx.fc-data.cn-beijing.aliyuncs.com/.../invocations/ag-ui/agent -XPOST \
  -H "content-type: application/json" \
  -H "x-fc-session-id: dxxx5c21-..." \
  -H "X-API-Key: ak_xxx" \
  -d '{
        "messages": [{"role": "user", "content": "空调怎么开"}],
        "stream": true,
        "metadata_filter": [{"tags": ["2024款_秦PLUS_荣耀版_DM-i_120KM领先型"]}]
      }'

该实现有两个关键设计点：

一是将 metadata_filter 放置于请求 body，而非 header。一方面，body 的 JSON 格式更适合承载用于过滤的结构化数组；另一方面，从语义上看，车型 filter 属于业务查询参数，而非元信息、鉴权信息或传输控制类 header。

二是在系统提示词中显式约定 metadata_filter 的示例格式，即 [{"tags": ["具体车型的标签值"]}]。该格式符合百炼知识库的入参要求，但不同模型生成结构化参数的习惯并不一致：部分模型会直接生成 JSON 数组，部分模型则倾向于输出完整的 JSON 字符串。一旦模型生成的参数格式与入参 schema 声明不一致，即会触发参数校验错误。因此，项目通过提示词约束尽可能规避此类问题。

同时，项目提供了完整的可选车型标签值，例如 2024款_秦PLUS_荣耀版_DM-i_120KM领先型、2025款_问界M9_增程_Ultra版_52kWh_6座版 等，并配置相应规则约束，包括必须调用 MCP 工具查询知识库、不得直接基于模型自身知识作答；用户未明确车型时，必须先追问或调用订单接口，不得默认车型；文末需标注引用的 chunk，便于结果回溯。

fallback机制设计及其他后续优化

当百炼知识库未检索到对应结果时，模型侧将触发 fallback，调用联网搜索工具后再生成回复。联网搜索由客户自有外部服务提供，并已基于 function call 协议封装为 Tool。由于调用外部服务时需在请求 header 中携带鉴权及身份信息，项目进一步将 header 透传沉淀为产品化能力。当模型通过 function call、remote MCP 或 OpenAPI 调用外部工具时，可将客户请求中的 header 信息传递至服务端，为完整 fallback 链路提供鉴权支持。

此外，针对 RAG 链路中收集到的用户侧 bad case，前线团队持续推动百炼知识库文档切分策略优化，并与用户共创沉淀定制化评测数据，为模型效果评估建立清晰、直观的 benchmark。相关内容本文不再展开。

Agent 全生命周期的可观测

可观测性是 Agent 上线前后不可或缺的生产能力。本项目采用 AgentLoop 构建完整的观测与优化闭环。神州租车用车助手 Agent 全程运行在函数计算云函数提供的全托管环境中，由 ARMS Python 探针自动埋点，数据统一汇聚至云监控 2.0，观测与优化共用同一套链路数据。

在观测层面，首先需要将 Agent 的每次请求拆分为足够细粒度的 Span，覆盖调用链各个环节，帮助用户准确定位异常耗时所在节点。其次，每个 Span 均需携带足以支持问题定位的信息，例如 requestId。当出现 Agent 回复耗时过长或结果不符合预期的 bad case 时，需要通过对应 requestId 联动模型侧或知识库侧日志，定位问题原因并制定优化策略。为此，项目通过升级 SDK 与 ARMS 探针，并补充百炼 API 数据埋点，确保模型与知识库两侧的 requestId 均可清晰透出至用户侧。

观测沉淀的链路数据同时构成持续优化的基础。神州租车已使用 AgentLoop 的评测能力，将线上 Trace 数据沉淀为评测集，支持基于清晰、直观的 benchmark 开展模型选型。观测使问题可见，优化推动问题收敛，二者共同形成 AgentLoop 闭环。

上线成效与业务价值

一期功能已完成灰度上线，并在工程指标、研发效率与规模化承载能力等方面取得可量化成效。

研发效率提升，基于云端能力快速创建 Agent

精简团队无需自建基础设施，模型、提示词、Skills、工具、记忆库与知识库均支持白屏化配置和即时调试，使研发资源能够聚焦业务逻辑，而非底层设施运维。

C 端体验达标，端到端时延稳定在 3 秒以内

通过预留实例与会话亲和，单实例可承载多个 Session，使实例数量与并发会话数解耦；同时，通过 MCP 知识库工具 Go 语言重写及召回参数缓存，将上线前实测约 20 秒的端到端时延优化至 3 秒以内，达到 C 端实时交互要求。用户无需额外预留过多实例，也可兼顾成本控制。

优化知识库检索链路，实现基于车型信息的精准召回

通过请求级 metadata filter，系统可先将召回范围收敛至用户实际租用的车型，无需按车型堆叠知识库工具或复制多个 Agent。当知识库未返回结果时，模型可自动 fallback 至客户自有联网搜索工具，并结合产品化的 header 透传能力完成鉴权，使回答覆盖范围不受知识库边界限制。

复用存量网关治理体系，沉淀可复制的接入模板

Agent 服务以与租车、营销等业务 API 平级的 agentapi 形态接入，沿用同一套网关鉴权、限流与 WAF 策略，无需为 AI 服务单独建设安全与治理体系。二期车机助手及后续功能可直接复用一期用车助手的整体架构，进一步降低增量功能的上线成本。