跳到主要内容
AGENT Q&A

Agent 八股文

研发级别的 Agent 架构问答，按技术主题归类，逐题拆成可直接复述的高密度回答。

01

智能体闭环与编排

LangChain vs LangGraph

架构差异与工业落地选型

LangChain 与 LangGraph 的架构差异是什么？工业落地该如何选型？

一句话：LangChain 适合线性、确定性的流水线；LangGraph 面向以状态为核心、可循环执行的智能体编排（State-Centric Multi-Agent Orchestration）。两者不是替代关系，而是按任务的状态复杂度与是否需要回环来选型。

架构对比

LangChain vs LangGraph

执行模型

LangChain

线性、顺序、确定性流水线；本质是无环的 Chain / DAG，数据单向流过各节点。

LangGraph

以状态为核心的可循环执行，DAG with Cycles（带环的有向图），节点可回退、重入与循环。

状态管理

LangChain

状态随链路传递，缺乏一等公民的全局状态；复杂状态迁移与回溯时难以维护。

LangGraph

内建状态持久化（State Persistence）：支持 Checkpointing、暂停/恢复（pause/resume）与时间旅行（time-travel）回放。

控制流

LangChain

适合简单 RAG、提示词工程等固定流程；分支与循环需要外部胶水代码硬拼。

LangGraph

细粒度的智能体流控（fine-grained agentic flow control），条件边与循环是原生能力。

人机协作

LangChain

Human-in-the-Loop 需自行封装，难以在任意节点稳定中断。

LangGraph

原生且健壮的 Human-in-the-Loop 集成，可在任意检查点中断、审批后再恢复。

自治程度

LangChain

偏确定性编排，可预测性强但自主决策弱。

LangGraph

支持非确定性自治（Non-deterministic Autonomy），由状态驱动多智能体自我修正。

工业落地选型

  • 选 LangChain流程固定、单向、可预测：简单 RAG、提示词工程、ETL 式的确定性流水线。维护成本最低。
  • 选 LangGraph复杂多智能体协作、需要回环与回溯、长任务断点续跑、强人机协作：用其 State Persistence 与带环 DAG 承接细粒度流控。
  • 落地经验LangChain 在复杂状态迁移与 backtracking loop 下会变得难维护；一旦出现循环、并发协作或需要中途人审，迁到 LangGraph 的状态机模型更省心。
State-Centric OrchestrationDAG with CyclesState PersistenceHuman-in-the-LoopNon-deterministic Autonomy

Saga Pattern for Agentic Loops

智能体长事务的失败恢复

智能体长链路任务执行到一半失败，如何保证状态一致性与可恢复性？

不要用一把大锁去包整条链路，而是按 Saga 模式把长事务拆成一串可补偿的本地步骤，配合幂等执行与持久化检查点，实现失败回滚与断点续跑。

关键要点

  • Saga 补偿每个原子步骤预先注册对应的补偿动作（Compensating Actions）。任一步失败时按相反顺序逆向回滚已落地的副作用，达成最终一致性；相比 TCC 不长期持有资源锁，更适合长链路异步业务。
  • 幂等执行所有写操作走幂等工具执行（Idempotent Tool Execution），以幂等键去重，确保重试、超时重放或补偿重放时不产生重复副作用。
  • 持久化检查点用 Checkpointing 持久化全局共享状态，链路中断后能从断点恢复，无需从头重跑，并支持 time-travel 回放定位问题。
Saga PatternCompensating ActionsIdempotent ExecutionCheckpointing
字节跳动真题

Ladder Decision-Chains & YAGNI

阶梯式决策链与按需扩展

Agentic workflow 容易过度设计，如何用阶梯式（Ladder）决策链配合 YAGNI 原则做克制的编排？

把 Agent 的决策组织成一条由简到繁的阶梯：能用确定性规则解决就别上模型，能单步就别多智能体。遵循 YAGNI（You Aren't Gonna Need It），只在当前需求真正触达上一层能力边界时才升级，避免为假想需求堆叠复杂度。

关键要点

  • 阶梯升级决策链分层：规则/查表 → 单次 LLM 调用 → 带工具的单 Agent → 多智能体协作。每层都先判定能否在本层闭环，命中再逐级上抬，链路可解释、可回退。
  • YAGNI 克制不为还没出现的场景预埋多智能体、向量库或长记忆。先用最小可用链路上线，靠真实失败样本驱动下一级能力的引入，控制 Token 成本与维护面。
  • 可观测兜底每一级都埋置信度与失败信号，低置信即降级或转人审（Human-in-the-Loop），保证阶梯在不确定时向更安全的下层收敛。
Ladder Decision-ChainsYAGNIProgressive EscalationHuman-in-the-Loop

MCP Self-Healing Test Agent

自愈式自动化测试智能体

如何利用 MCP（Model Context Protocol）协议构建自愈式的自动化测试智能体？

用 MCP 把 LLM 与本地环境（沙箱、工具、数据库）标准化连接起来，让智能体在「感知报错 → 结合 RAG 决策 → 改码重测」的闭环里自愈，再用 LangGraph 这类状态机框架编排整条流程。

关键要点

  • 协议架构MCP 充当 LLM 与本地环境（沙箱、工具、数据库）的标准化连接层，工具调用统一经协议下放到受控沙箱执行。
  • 感知智能体通过 MCP Tool 触发自动化测试，捕获 Traceback 或系统报错作为闭环触发信号。
  • 决策将错误信息与 RAG 检索到的「测试指南」或「历史修复案例」结合，输入 LLM 生成修复策略。
  • 执行利用 MCP 的文件写入工具修改代码，并重新运行测试验证，未通过则带反馈回到决策。
  • 框架集成可配合 LangGraph 或 AutoGen 定义复杂的状态转移，如「编写 → 测试 → 修复 → 审核」的闭环流程。
MCPSelf-HealingRAGLangGraph / AutoGenSandbox

OpenClaw: Multi-Agent vs Single-Agent

多智能体编排与单体智能体取舍

OpenClaw 这类智能体架构里，多智能体编排（Multi-Agent）相比单体智能体（Single-Agent）该怎么选？

按任务的子域分化程度与上下文压力来选：单体 Agent 上下文连贯、调试简单，适合中小任务；多智能体把角色与上下文窗口分治，适合需要并行、专精分工与长流程的复杂任务，但要为通信与一致性付出协调成本。

架构对比

LangChain vs LangGraph

上下文管理

LangChain

单体：单一上下文窗口，状态连贯、推理无缝，但长任务易超窗、注意力被稀释。

LangGraph

多体：每个子 Agent 持有自己的窗口，按角色分治上下文，缓解超窗，但需共享状态做对齐。

分工与专精

LangChain

单体：一个模型兼任所有角色，提示词臃肿、能力边界模糊。

LangGraph

多体：规划/检索/执行/审查各司其职，可分别选模型与工具，专精度更高。

并行与吞吐

LangChain

单体：本质串行，长流程时延高。

LangGraph

多体：子任务可并行编排，吞吐更好，但需处理汇聚与冲突。

成本与调试

LangChain

单体：链路短、可观测性好、Token 成本可控、易调试。

LangGraph

多体：通信轮次与 Token 成本上升，故障定位更难，需强可观测与状态持久化。

工业落地选型

  • 选单体任务边界清晰、上下文可控、对时延与成本敏感：单 Agent + 工具即可，别过早上多智能体。
  • 选多体任务可自然拆成专精子域、需要并行或长流程协作：用编排框架（如 LangGraph）定义角色与共享状态，按 YAGNI 逐级升级。
  • 工程要点多智能体务必配齐共享状态持久化、消息契约与可观测追踪，否则协调成本会吃掉分工收益。
Multi-Agent OrchestrationSingle-AgentShared StateRole Specialization
02

RAG 与上下文工程

Self-RAG & GraphRAG

压制幻觉与全局多跳检索

RAG 仍然幻觉、跨文档全局问题答不好，进阶检索范式有哪些？

两条进阶路线：Self-RAG 用自反思机制在闭环内决定何时检索、是否采信召回；GraphRAG 用知识图谱 + 社区摘要补齐传统向量检索缺失的全局与多跳推理能力。

关键要点

  • Self-RAG / 反思检索引入 Critique Token 自评估机制，在推理闭环内动态预测检索关联度与生成支持度，自主决定是否触发检索更新或丢弃无效召回，从源头压制 RAG 幻觉。
  • GraphRAG从非结构化文本抽取实体关系构建知识图谱，用社区检测算法（如 Leiden）生成分层全局摘要，解决传统向量 RAG 在跨文档全局关系推断与多跳复杂查询下的召回瓶颈。
  • 混合检索 + 重排底座仍用 Hybrid Search（BM25 + 向量）召回，再以交叉编码 Reranker 精排，把最相关上下文顶到前面，保证生成阶段拿到高质量上下文。
Self-RAGGraphRAGHybrid SearchReranker
字节跳动真题

Long-term Memory: RAG vs Vector DB

智能体长期记忆的持久化设计

智能体的长期记忆，用 RAG 检索还是向量库持久化？两者如何分层配合？

RAG 是「读」的检索范式，向量库是「存」的持久化底座，二者不是二选一：用向量库做长期记忆的持久存储，用 RAG 流程在推理时按需召回，再叠加分层记忆与衰减策略控制上下文聚焦。

关键要点

  • 职责区分向量库（Vector DB）负责长期记忆的持久化存储与近似最近邻检索；RAG 是把召回内容拼进上下文喂给模型的「读」流程。记忆系统通常是「向量库存 + RAG 取」。
  • 分层记忆短期工作记忆用滑动窗口保留当前会话关键变量；长期记忆向量化落库。通过「交互热度」权重对冷数据衰减与摘要化，避免上下文被海量历史稀释。
  • 写入与更新记忆写入要做去重与摘要压缩，并保留可溯源元数据（时间、来源、置信度）；更新走幂等写入，避免重复记忆污染召回。
  • 召回质量用 Hybrid Search + Reranker 提升记忆召回精度，必要时结合 Self-RAG 自评估丢弃低关联记忆，抑制因陈旧记忆引入的幻觉。
Long-term MemoryVector DBRAGHierarchical MemoryReranker
03

微调与推理优化

PagedAttention & KV Cache

长文本推理的显存与吞吐优化

高并发长文本推理时，KV Cache 撑爆显存且吞吐上不去，怎么优化？

核心是把 KV Cache 当作虚拟内存来管：用 PagedAttention 做分页分配消除碎片，再叠加低比特量化压缩缓存体积，从而拉高 batch 与吞吐。

关键要点

  • PagedAttention借鉴操作系统虚拟内存的页表机制，按需把 KV Cache 切成定长物理块动态分配，彻底解决显存碎片化与显存上限瓶颈，让同样显存能容纳更多并发请求。
  • KV Cache 量化对缓存的 Key/Value 做 FP8 / INT4 量化，进一步压低单请求的显存占用，在长上下文场景下显著提升端侧与服务端推理吞吐。
  • 连续批处理配合 Continuous Batching 在 token 粒度动态拼批，让先完成的请求及时让出算力，整体提升 GPU 利用率与有效吞吐。
PagedAttentionKV Cache QuantizationFP8/INT4Continuous Batching
04

安全与合规

Guardrail Middleware & Sandbox

工具自治的安全边界

让 Agent 自主调用工具甚至执行代码，如何守住安全边界？

在 Agent 决策与系统级执行器之间插一层护栏中间件做语义网关与参数校验，再把真正的执行放进轻量沙箱做系统硬隔离，最后对高危动作引入人机在环。

关键要点

  • 护栏中间件在决策与执行之间构建语义网关，用 Pydantic / 规则引擎校验工具调用参数合法性，拦截越权与异常意图，作为统一的强制执行层（含 MCP Host 级 RBAC）。
  • 安全执行沙箱用 gVisor 或 WASM 等轻量沙箱运行工具与生成代码，用用户态内核 / WebAssembly 运行时隔离系统调用与文件、网络访问，确保操作受控可回滚。
  • 人机在环对不可逆或高危动作触发 Human-in-the-Loop 审批，在任意检查点中断、人审通过后再恢复，从协议层杜绝 Prompt Injection 造成的实际危害。
Guardrail MiddlewaregVisor / WASM SandboxRBACHuman-in-the-Loop
百度真题

Autonomous Task Flows & Sandboxing

自主任务流与安全沙箱

Manus 式的自主任务流让 Agent 自行规划并执行多步操作，如何用 gVisor/WASM 沙箱守住安全？

自主任务流的风险在于「模型自己决定做什么并真的去执行」。对策是把规划与执行解耦：规划层产出可审查的步骤计划，执行层只能在 gVisor / WASM 沙箱内、经护栏校验后落地，高危动作走人机在环。

关键要点

  • 规划-执行解耦Agent 先产出离散、可预览的任务计划（plan），每一步是带参数的结构化动作；执行前经护栏中间件校验，避免自由生成不可控操作。
  • gVisor / WASM 沙箱工具调用与生成代码在 gVisor（用户态内核拦截 syscall）或 WASM 运行时中执行，对文件系统、网络与内核做强隔离，限制副作用半径。
  • 权限与人审按最小权限分配会话令牌（RBAC），不可逆/高危动作触发 Human-in-the-Loop 审批；全程留痕审计，从协议层杜绝 Prompt Injection 的实际危害。
  • 可恢复长任务用 Checkpointing 持久化状态，失败按 Saga 模式逆向补偿回滚，保证自主执行可控可回退。
Autonomous Task FlowgVisor / WASM SandboxRBACHuman-in-the-LoopSaga
05

低延迟与边缘计算

Zero-Copy IPC & Speculative Decoding

端侧实时链路的延迟压制

边缘端实时语音 / 感知链路，如何把端到端时延压到极限？

两端发力：数据面用零拷贝共享内存消除跨进程拷贝开销，推理面用投机采样降低自回归解码的首字时延。

关键要点

  • 零拷贝 IPC用 NvMap 等底层驱动在异构架构（如 Xavier NX 的 CPU/GPU/NVDLA）间做单物理地址映射共享，消除系统态与用户态的多余拷贝，把传感到感知的链路延迟压到微秒级。
  • 投机采样用轻量 Draft Model 快速推测 Token 候选流，再由 Target Model 单步并行校验接受，缓解端侧 I/O 访存受限带来的高延迟，显著优化首字响应速度（TTFT）。
  • 解耦与流式把声学 / 感知反馈与业务决策解耦，配合流式分片与并行推理，让指令在用户话音刚落即触发，稳定满足实时性预算。
Zero-Copy IPCSpeculative DecodingTTFTHeterogeneous Compute

Jetson Xavier NX Profiling & Thermal

系统级性能分析与热节流处理

在 Jetson Xavier NX 平台上，如何有效地进行系统级性能 Profiling 并处理 Thermal Throttling 问题？

思路是「先量后调」：用底层工具把 CPU/GPU、显存、功耗与温度看全，定位是算子瓶颈还是热节流，再用频率锁定、热管理与异步流水线把瞬时高功耗削平，最终守住 15ms 级实时性。

关键要点

  • 工具链用 jtop（jetson-stats）做实时硬件监控，或用 tegrastats 获取底层频率与功耗数据；算子级瓶颈再配合 TensorRT Profiler 定位。
  • 性能分析重点关注 CPU/GPU 利用率、显存分配（EMC）以及温度传感器读数，判断是算力打满还是已触发降频。
  • 频率锁定用 jetson_clocks 强制锁定最大频率，避免动态调控（DVFS）引入的抖动，让延迟更稳定可预测。
  • 热管理设置合理的 fan mode；在软件层面通过多线程异步推理（Async Inference Pipeline）平滑负载，减少瞬时高功耗触发的热节流。
  • 延迟控制针对 15ms 级别的实时性要求，优化内存拷贝（尽量用 Zero-Copy 或 Unified Memory），并结合 TensorRT Profiler 找出算子瓶颈。
Jetson Xavier NXtegrastats / jtopjetson_clocksThermal ThrottlingZero-Copy

YOLO PyTorch to TensorRT Pipeline

边缘端部署的完整优化流水线

描述 YOLO 模型在边缘端部署时，从 PyTorch 到 TensorRT 的完整优化流水线及关键技术。

一条主线：PyTorch → ONNX → TensorRT Engine，配合半精度量化、算子融合与多流并行，把 Jetson NX 上的端到端延迟压到 15ms 左右以支撑高频避障。

关键要点

  • 导出与转换PyTorch → ONNX（注意动态维度处理）→ TensorRT Engine，逐级把训练态模型转成可在边缘高效执行的推理引擎。
  • 精度量化采用 FP16 半精度量化获得 2-3 倍推理加速，同时几乎不损失精度；若算力受限可考虑 INT8 量化（需 PTQ 或 QAT 校准）。
  • 算子融合TensorRT 自动融合卷积与激活层，减少访存与 kernel 启动开销。
  • 多流并行利用 CUDA Streams 实现前处理、推理、后处理的流水线并发，提升 GPU 利用率。
  • 性能指标在 Jetson NX 上，优化后的 YOLO 模型端到端延迟应稳定在 15ms 左右，以支持高频避障。
YOLOONNXTensorRTFP16 / INT8CUDA Streams
06

LLMOps 与研发平台

Internal Developer Platform + LLM

内部研发平台与步进式推理自动化

内部研发平台（IDP）如何接入 LLM 做研发自动化，又不失可控性？

把 LLM 当作 IDP 上的一个受约束的自动化执行器：用黄金路径（Golden Path）模板约束动作空间，让模型做步进式推理（step-based reasoning）逐步规划，每一步都走平台既有的鉴权、流水线与审计闭环。

关键要点

  • 黄金路径约束IDP 通过自助模板与 Golden Path 把可执行动作收敛成有限、合规的集合，LLM 只在这个动作空间内编排，避免自由生成不可控的基础设施操作。
  • 步进式推理把「建服务 / 配流水线 / 申资源」拆成可审查的离散步骤，模型逐步规划并在每步产出可预览的 diff，平台校验通过后再执行，失败可逐步回退。
  • 平台护栏复用 IDP 既有的 RBAC、策略即代码（Policy as Code）与审计日志作为护栏，LLM 的每个动作都经平台鉴权与留痕，自动化不绕过治理。
Internal Developer PlatformGolden PathStep-based ReasoningPolicy as Code
华为乾崑真题

Multi-Agent Gaming in World Models

云端世界模型中的多智能体博弈

云端世界模型里为什么要引入多智能体博弈机制？它解决了什么问题？

世界模型负责在云端仿真出可演化的环境，多智能体博弈则让多个策略体在这个仿真世界里对抗与协作，用博弈产生的长尾交互数据反哺策略，覆盖真实路采难以遇到的极端场景。

关键要点

  • 世界模型仿真在云端用世界模型生成高保真、可控、可分支的环境演化，作为策略训练与评测的确定性沙盘，降低对真实路采的依赖。
  • 多智能体博弈让多个智能体在仿真世界中以博弈（gaming）方式交互：对抗体制造危险场景、协作体演练协同，靠博弈自动挖掘长尾 corner case。
  • 数据反哺闭环把博弈产出的高价值交互轨迹回流到训练闭环，形成「仿真 → 博弈 → 反哺」的自进化数据飞轮，提升策略在极端工况下的鲁棒性。
World ModelMulti-Agent GamingCorner Case MiningSelf-evolving Data
07

DevOps 与可观测性

腾讯真题

AI-Driven Observability & RCA

AI 驱动的可观测性与根因定位

如何用 AI 把可观测性从「看图」升级为自动根因定位（RCA Automation）？

把 Metrics / Logs / Traces 三支柱统一成可被模型消费的事件图，让 LLM 结合拓扑与历史故障做关联推理，自动收敛到根因并给出修复建议，把 MTTR 从小时级压到分钟级。

关键要点

  • 数据底座统一采集 Metrics、Logs、Traces 三支柱，关联服务拓扑与变更事件，构成可供模型推理的时序事件图。
  • 异常检测用时序模型做动态基线与异常检测，触发后自动圈定受影响的服务与时间窗，缩小排查范围。
  • 根因推理LLM 沿调用链与依赖拓扑做因果关联（结合近期变更、相似历史故障的 RAG 召回），收敛到最可能根因并产出可解释证据链。
  • 闭环修复给出修复建议或预案，经审批后联动 Runbook / 流水线执行；结果回流形成自进化的故障知识库。
ObservabilityRCA AutomationMetrics/Logs/TracesMTTRRunbook
阿里真题

Ephemeral Environments in GitOps

GitOps 中的临时环境与密钥注入

GitOps 流程里如何为每个 PR 动态拉起临时环境（Ephemeral Environment），并安全地注入密钥？

用声明式 GitOps 把环境定义为代码，按 PR 动态创建、合并即销毁的临时环境做隔离验证；密钥绝不进 Git，而是运行时从外部密钥管理系统按最小权限动态注入。

关键要点

  • 声明式拉起环境即代码：PR 打开时由 GitOps 控制器（如 Argo CD）按声明式清单动态创建命名空间级隔离环境，PR 合并或关闭即自动回收，避免环境漂移与资源泄漏。
  • 密钥注入密钥不入库：用 External Secrets / Vault 在运行时把密钥注入到工作负载，配合 SOPS / Sealed Secrets 加密引用，按环境与角色做最小权限隔离。
  • 数据与种子临时环境用合成数据或脱敏快照做种子，保证可重复、不触碰生产数据。
  • 成本与回收为临时环境设 TTL 与自动回收策略，结合按需调度控制成本，避免大量 PR 环境长期空转。
Ephemeral EnvironmentsGitOpsArgo CDExternal Secrets / VaultTTL
08

智驾与 VLA

华为乾崑真题

Vision-Language-Action (VLA) for ADAS

面向智驾的 VLA 与 WEWA 2.0 架构

面向智驾的 Vision-Language-Action（VLA）模型相比传统感知-规控分段式有什么优势？WEWA 2.0 这类架构怎么落地？

VLA 把视觉感知、语言推理与驾驶动作统一进一个模型，用语言作为可解释的中间表征，端到端地从场景理解直达驾驶决策，缓解传统「感知-预测-规控」分段误差累积与长尾场景泛化差的问题。

关键要点

  • Vision-Language-Action视觉编码场景、语言模块做常识推理与意图表达、动作头输出轨迹/控制量；语言中间层让决策可解释、可对齐人类驾驶常识，对未见长尾场景泛化更好。
  • WEWA 2.0 协同以云端世界模型（World Engine）训练与蒸馏、车端 VLA Agent（World Action）实时执行的云-车协同架构：云端做世界仿真与策略进化，车端做低时延的驱动型 Agent 推理。
  • 安全交付VLA 决策经护栏中间件与系统级执行器之间的语义校验，高危动作走确定性兜底与冗余控制，确保物理世界的确定性安全交付。
Vision-Language-ActionWEWA 2.0End-to-End DrivingCloud-Vehicle Co-training
特斯拉 / 行业真题

Occupancy Networks for Long-Tail Obstacles

占用网络应对静态长尾障碍物

OccNet（占用网络）为什么能更好地处理静态障碍物的长尾检测问题？

传统 3D 框检测依赖预定义类别，遇到没见过的异形 / 静态障碍物会漏检。占用网络（Occupancy Network）把场景表示成与类别无关的体素占用栅格，只判断「这块空间是否被占据」，从而覆盖长尾异形障碍。

关键要点

  • 类别无关表征OccNet 输出 3D 体素的占用概率（occupied / free），不依赖预定义类别框，天然覆盖掉落物、异形护栏、施工设施等长尾静态障碍。
  • 多视角融合用环视相机做 BEV / 体素特征提升与时序融合，补全单帧遮挡，提升静态结构的几何一致性与稳定性。
  • 规控友好占用栅格直接给规控提供可行驶空间（free space）与障碍体积，避免「先分类再决策」的误差累积，对未知障碍也能安全绕行。
  • 部署考量体素推理算力开销大，车端需做分辨率分级、稀疏化与 TensorRT 加速，平衡精度与实时性。
Occupancy NetworkBEVLong-Tail DetectionFree SpaceVoxel
华为 / 大疆真题

End-to-End World Models in Urban NOA

城区 NOA 的端到端世界模型与 VLA

城区 NOA（领航辅助）里，端到端世界模型与 VLA 模型相比分段式方案有什么价值？

城区路况长尾极多，分段式「感知-预测-规控」误差累积、规则难穷举。端到端世界模型让模型在内部学到环境演化规律并直接输出决策，VLA 再用语言中间层引入常识推理与可解释性，提升城区长尾泛化。

关键要点

  • 世界模型模型内部学习场景的时空演化（预测周车与环境如何变化），把预测与规划耦合进统一表征，缓解分段误差累积。
  • VLA 决策Vision-Language-Action 把视觉感知、语言常识推理与驾驶动作统一，语言中间层让城区复杂博弈（让行、汇入）决策可解释、可对齐人类常识。
  • 云车协同云端用世界模型做仿真、数据挖掘与策略蒸馏，车端跑轻量 VLA 实时推理，形成「仿真进化 + 车端执行」的闭环。
  • 安全冗余端到端决策外挂规则护栏与确定性兜底，高危场景退回保守策略，保证物理安全交付。
End-to-EndWorld ModelVision-Language-ActionUrban NOACloud-Vehicle