企业级 AI 应用不能仅依赖Agent 实时生成

企业级 AI 系统要放在传统软件工程的框架里设计。只依赖 Agent——无论是大语言模型的即时生成，还是对话式的临场决策——覆盖不了复杂业务，也过不了合规这一关。自动驾驶把这件事推到了极端：链路长、容错低、出了事故必须说得清。它因此成为检验企业级 AI 架构是否成立的样本。

本文的判断很具体。Agent 可以执行已经被定义好的任务，不能代替系统本身。感知、规划、控制、审计、发布、回滚，每一层都要有契约、有版本、有责任人。模型是这些层里的一种能力，不是把这些层一次性“说”出来的入口。下文先给出必须同时成立的十项结论，再逐项展开架构、路线和对照。

本文沿着三条线展开

1. 01业务怎么运行：把任务拆成有输入、输出、状态和责任人的过程，明确 Agent 所在的位置。
2. 02行为怎么受控：让权限、数据范围、审批和审计成为调用过程的一部分。
3. 03系统怎么演进：通过测试、版本管理、监控与恢复机制，支撑长期运行和能力升级。

业务与流程

自动驾驶不是一轮对话。它是感知、定位、预测、规划、控制与人机交互叠在一起的流程。每一环都要单独设计、测试和签收。传感器融合、坐标系、时间戳、安全退出，都依赖明确的中间数据，而不是一段可以随时改口的自然语言。单一 Agent 既不是为某一环设计的，也没有内建的物理模型和多传感器约束，拆不开，也验不了。

可追溯与审计

企业 AI 在安全敏感场景里必须留下完整决策链，作用类似飞行记录器：出事之后能回答“为什么是这个动作”。车辆侧已有事件数据记录的监管传统；引入 Agent 之后，要求只增不减。每次调用前后的输入、模型版本、工具、策略判定和输出，都要能按同一次事务回放。IBM 曾以保险场景的多 Agent 法律检索为例，说明效率可以提升，同时每个决策仍然保持可审计。做不到这一点，系统就不可解释，责任也无从归属。

法律、合规与安全

自动驾驶运营要同时满足道路交通、安全生产和道路运输的既有法律，以及网络安全、个人信息保护与数据安全对采集、存储、处理和出境的要求。欧盟《人工智能法案》把车辆安全相关的一类 AI 系统列为高风险，要求可解释、有安全性能、并且避免歧视。ISO 26262、ISO/SAE 21434 与 ISO 42001 则分别把功能安全、网络安全和 AI 治理落成可检查的工程过程。黑箱式地把车况或乘员信息送去第三方模型，过不了数据本地化，也过不了白名单。

可维护、实时与数据

企业系统的寿命长过任何一次演示。模型、训练数据和配置都要进版本库，变更要走 CI/CD，失败要能退回上一个已知安全的版本。实时闭环更苛刻：控制周期在毫秒量级，云端生成的排队、抖动和不确定性不能放进制动与转向。Agent 适合解释、摘要、仿真和离线分析；关键控制必须由确定性逻辑兜底，超时就切换。数据则要先分类、脱敏、授权，再允许进入模型。差分隐私、最小权限和访问日志不是附加项。

组织、成本与风险

架构变了，职责也要变。每个 Agent 和模型登记负责人、场景、权限和风险等级；上线前经过合规与伦理评审，上线后持续监控。成本同样要被治理：公有云按次计费不可预测，网关负责令牌预算、速率和模型路由，核心感知尽量留在车端或私有环境。风险则按可能性和影响分级，高影响且高可能的事项预备停机、隔离和人工接管，而不是等事故之后再写一份说明。

推荐方案

推荐的形态是“传统架构 + Agent 执行层”，中间用 AI 网关把两边接上。员工、业务系统和车端应用都不直接调用模型。网关统一做认证、数据防泄露、上下文记录、路由、限额和审计；网关后面才是云端模型、本地模型、专用视觉模型，以及始终在场的业务规则。模型可以替换，管控框架不跟着推倒。下文把这条路径写成可实施的组件、里程碑和对照表。

把自动驾驶看成一次“请模型开车”的请求，会在第一公里就失败。系统同时处理多路传感器、定位、他车预测、本车轨迹、执行器极限和驾驶员状态。这些不是同一项技能的不同说法，而是不同模块、不同时间尺度、不同失败后果。传统软件工程用模块边界、接口契约和流水线把它们拆开，才能并行开发、独立验证、出了问题只回滚一环。

一条必须被拆开的链路

感知把摄像头、毫米波雷达和激光雷达融成目标与环境表达。输出不是一段描述，而是带时间戳、坐标系和置信度的结构化结果。定位把这幅图锚到可核对的位置。预测估计其他交通参与者的轨迹。规划在交通规则、安全距离和本车动力学约束下生成本车轨迹。控制把轨迹变成转向、制动和驱动指令，并且知道执行器做不到什么。人机交互则在确定的时限内发出接管请求和状态，而不是等一段生成文本慢慢结束。

环与环之间是契约。感知的schema变了，规划的测试就应当失败；控制的接口没变，上层替换模型就不该连带改写执行器。这种中间格式是协作的前提。没有它，就无法把工作分给不同团队，也无法在集成之前知道是哪一层错了。行业里常见的开发节奏——数据采集、训练与验证、软硬件集成——每一段都有里程碑和审核点，原因正是链路太长，不能靠一次端到端的“看起来能开”来签收。

为什么单 Agent 覆盖不了

Agent 不是为其中某一环设计的。它没有内建的多传感器融合，也不携带车辆动力学。让它直接生成驾驶指令，等于跳过契约：没有人能指出这一步的输入是否合法、输出是否落在执行器能力内、失败时该进入哪一个状态。IBM 关于 AI Agent 的论述把边界说得很清楚——智能体可以自主拆解任务，但目标、规则和可用工具仍然要由人事先给定。自主不是免于规格，而是在规格之内行动。

流程里还有状态机，这是对话最不擅长保持的东西。高级驾驶辅助在驾驶员未接管、传感器降级或定位丢失时，必须走到已定义的安全退出，而不是再“想”一个更聪明的回复。状态、守卫条件和超时都是传统架构的长处：它们可以被枚举、被测试、被审查。一个只会继续生成的 Agent，缺少这种“到此必须停”的结构。

安全敏感系统被问责时，问题不是“模型当时觉得怎么样”，而是“从传感数据到执行器指令，中间每一步为何成立”。自动驾驶车辆因此沿用了航空器的思路：事件数据记录器记下制动、转向和关键传感器状态，供事后还原。企业级 Agent 不能比车辆记录器更含糊。它参与过的每一次判断，都要能被放回同一条时间线上。

监管已经把“留得下来”写成要求，而不是最佳实践。UNECE WP.29 框架下的车辆网络安全与软件升级规则，要求事件和变更可以被追溯。国内的智能网联汽车道路测试与示范应用管理规范同样强调关键数据留存，并用于事故认定。记录器如果只覆盖传统电控、不覆盖模型调用，那么新增的 AI 决策就会成为调查里的空洞。

一次调用要留下什么

技术讨论里常把这组控制称为 Prompt、Context、Model、Tool 的追踪。落到架构上，就是一次事务至少绑定这些字段：事务标识、时间、调用方身份、策略判定（放行、脱敏或拒绝）、输入摘要或其不可逆指纹、模型名与版本、工具名与参数摘要、输出摘要、令牌消耗、延迟，以及是否触发了人工断点。决策引擎里的检查点要能和车辆侧的帧号、轨迹号对齐。调查人员不应该在两套对不上的日志之间猜。

IBM 举过一个对照。Dynamiq 为保险场景做的多 Agent 法律检索，效率明显提高，同时每个决策仍保持可审计。这个例子重要的地方不在保险，而在结构：Agent 可以拆分检索、阅读和归纳，但每一次拆分都留在记录里。自动驾驶里的“拆分”更硬——融合、预测、规划不能互相覆盖痕迹。能审计，才谈得上把多 Agent 放进系统。

记在哪里，才算数

日志如果由模型自己“记得”，就等于没有日志。捕获点要放在 AI 网关或执行层这种调用方绕不开的位置：没有策略审查和记录，请求到不了模型。存储要不可随意改写。一次写入、多次读取的 WORM 介质，或带哈希链接的追加日志，都是为了让事后不能悄悄换掉当时的输入。加密、访问控制和保留期限跟记录本身一样，属于设计，而不是运维时再补的开关。

可解释在这里不是另做一个演示界面。它是能把某一次制动还原成：哪一帧感知、哪一版规划、哪一次模型调用、哪一条规则最终生效。责任归属依赖这条链。链断在任何一截，企业在安全审查和事故调查里都只能重复“模型这么输出的”，而这不是解释。

自动驾驶和企业 AI 同时站在两套规则上。一套管车怎么上路、谁对安全负责；一套管数据怎么采、模型怎么用、人的权利如何被保护。只满足其中一套，系统仍然不能运营。交通运输主管部门对自动驾驶运输的口径一直是依法依规、安全至上：运营许可、保险、测试规范都是硬条件，不是上线之后再补的材料。

车怎么被允许开

• 《安全生产法》要求生产经营单位对安全负责，危险作业和重大风险不能以“系统自动决定”转移义务。
• 《道路交通安全法》仍是车辆通行、驾驶资格和事故责任的基础。自动化等级没有取消这套框架。
• 《道路运输条例》约束的是运营，而不只是单车功能。许可、车辆管理和运输安全义务继续有效。
• 《自动驾驶汽车运输安全服务指南（试行）》把运输场景里的安全服务要求写进了行业指导。
• GB/T 40429-2021《汽车驾驶自动化分级》提供了讨论能力边界的共同语言。分级是描述，不是豁免。

测试和示范同样有留痕义务。智能网联汽车道路测试与示范应用的管理规范要求保存关键数据，使事故能够被复盘。这和上一节的审计链是同一件事的法规侧面：没有记录，就没有示范应用的资格。

数据、模型和人

《网络安全法》《数据安全法》《个人信息保护法》把采集、存储、处理、提供和出境串成一条义务链。个人敏感信息要有明确目的和最小必要；汽车场景里的位置、舱内声音、身份和驾驶习惯都可能落入这个范围。关键信息基础设施还有专门的保护条例，网络数据的处理活动则受到《网络数据安全管理条例》约束。企业不能用“先传到模型看看”代替分类分级。

国际规则把同一件事说得更明确。欧盟《人工智能法案》将作为产品安全组件、用于车辆的一类 AI 列为高风险系统，要求风险管理、数据治理、技术文档、可追溯、人为监督，以及对准确性和稳健性的说明。美国国家标准与技术研究院的 AI 风险管理框架，则提供了一套可执行的治理语言：映射风险、测量、管理，并在整个生命周期里治理。两边都不会接受一个无法复述决策依据的黑箱作为安全功能。

黑箱调用为什么不合规

员工或车端直接把请求送到公有云模型，等于把控制权交到企业看不见的链路里。乘员对话、车辆状态、地图片段都可能离开指定的地域和责任边界。合规实践因此要求白名单：谁可以调用、哪一个模型可以碰哪一级数据、输出要不要再过滤，都在进入模型之前决定。公开的技术治理讨论把这条路径写成固定顺序。

1. 1数据分类：先判断这一跳携带的是哪一级数据，而不是默认全部可进模型。
2. 2敏感信息检测：身份、位置、舱内内容等在离场前被发现并脱敏或阻断。
3. 3模型策略检查：目标模型是否在许可清单内，用途和风险等级是否匹配。
4. 4输出过滤：返回结果再次经过保密、安全和业务规则，而不是原样交给下游。
5. 5审计落盘：上述每一步的判定写入不可改的记录，供事后审查。

关键决策还要能被一个人真正拦住。人工审批门槛和中断点不是不信任自动化，而是法规和功能安全都要求某些后果留在人类决策链上。工程标准把这件事写进了过程：ISO 26262 管功能安全，ISO/SAE 21434 管网络安全，ISO 42001 管 AI 管理体系。三份标准的共同含义是，安全与治理必须被设计、被验证、被留下证据，不能寄托于模型“通常表现不错”。

研究原型可以用一次生成交差。企业系统要在人员更换、法规修订、传感器换代之后仍然跑得动。传统架构把代码放进仓库，版本可比较，错误可回滚，发布可重复。AI 没有特权跳过这套纪律。模型权重、训练数据快照、提示与策略配置、网关路由，都是版本化对象。少一个，线上行为就无法再现。

Agent 实时生成的结果天然不易再现。温度、检索到的上下文、工具返回值、上游模型的静默升级，都会让“同一句话”在下周得到另一条指令。再叠加训练数据来自外部、分布随时间漂移，系统就会出现一种安静的失效：没有人改过代码，行为却变了。这就是必须把 Agent 收进 MLOps 和 DevOps 的原因。每个模型或 Agent 打包成带版本的服务，而不是一个随时被改写的对话。

发布要像软件，而不是像聊天

一次升级至少走过这些门。在隔离环境里比较输出质量、安全策略和延迟；用固定的回归集看行为有没有漂；安全测试覆盖提示注入和工具滥用；通过之后才按流量比例灰度。业务或安全侧一旦判定风险，停机开关把流量切回上一个已批准版本，而不是在生产里继续“再试一次提示”。灰度、门禁和回滚都要留下和代码发布同一级别的记录。

ISO 42001 用“可审计的证据包”描述这件事：持续监控不是一块仪表盘，而是日后能拿出来的证据。证据包里应有版本号、审批人、测试结论、发布范围、监控阈值，以及回滚是否演练过。数据层同时保留训练数据的快照和日志，以便审计，也以便在漂移之后重训，而不是只剩一个无法追问的权重文件。

长期运行还会带来性能衰减和标注过时。漂移检测、再标注和再验证要写进运营日历，而不是等指标已经越线。对自动驾驶，这条纪律尤其硬：一套在去年路况上签收的感知模型，不能在今年默默替换，却沿用旧的安全论证。模型即代码，指的就是替换本身必须再次成为一次发布。

车辆控制看的是截止时间，不是平均体验。规划和控制常常要求在毫秒量级内给出确定的结果。云端大模型的延迟由排队、网络抖动、推理时间和供应商侧的拥塞共同决定，分布又长又不稳定。把这种分布放进制动或转向的闭环，等于允许一次无关的网络波动变成安全事件。本地的小模型也受算力约束，不能因为它“在车上”就默认满足硬实时。

所以架构上的分工应当反过来。硬实时环路由边缘侧的确定性算法和传统控制承担。生成式 Agent 做它时间预算允许的事：向操作员解释场景、对日志做离线分析、在仿真里生成工况、为接管之后的复盘写摘要。它不担任主控制模块。这个边界一旦写进架构，后面的超时、降级和容量规划才有对象。

不确定性要有后备

可靠性不只是服务还在不在。生成结果会幻觉、会偏、会在分布外沉默地胡说。传统架构用冗余、隔离和故障域把一个模块的错误关在里面。Agent 把一种新的错误带进来：输出看起来完整，内容却不可用。IBM 的提醒仍然适用——智能体需要特定规则和工具调用来纠正自己的决策。纠正若发生在截止时间之后，对车辆就等于没有纠正。

因此每个 Agent 服务都要有明确的作用边界和后备。超时、低置信、策略拒绝或输出无法通过校验时，预先写好的规则接管，或者把决策交还给人工和其他安全逻辑。切换本身要被测试：后备路径在主路径健康时也要定期演练，否则故障当天才会发现后备没有部署。多级超时、故障切换、边缘与云的分工，是同一套设计的不同刻度。

容量也要在设计时算清楚。模型并行、缓存、负载均衡可以改善吞吐，但改善的是允许使用 Agent 的那些路径，不是把云端生成变成硬实时。令牌限额和模型降级则用来保证过载时系统变慢得可预期：先降到更小的模型或规则，而不是无限排队，直到控制周期被拖垮。

企业 AI 碰到的数据比演示数据危险得多。自动驾驶链路里同时有道路环境、车辆状态、驾驶员与乘员的身份和行为，以及远程升级和客服对话。这些数据的敏感级别不同，允许离开车端的条件也不同。治理要先分类分级，再谈模型效果。没有分类的数据平台，只是一个更快的泄露通道。

《个人信息保护法》对敏感个人信息规定了严格的处理条件。欧盟 GDPR 要求目的明确、主体权利可行使。国内数据安全法律则要求按重要程度采取相应保护。三套规则的工程含义一致：最小必要、可追溯的授权、加密与脱敏、以及说得清谁在什么目的下读过。把原始舱内录音推进大模型做“更好的体验”，通常已经越界。

进入模型之前

数据防泄露要做在调用侧，而不是做在事后抽查。AI 网关在路由之前执行分类、敏感信息检测、策略检查，返回时再做输出过滤，并把全过程审计下来。车端更靠前：用户交互和远程升级走加密信道，边缘节点先做基本预处理，未授权的字段根本不进入核心控制，也不进入任何生成式服务。最小权限同时约束人和服务账号。一个用于日志摘要的模型，不应该拥有读取原始身份信息的凭据。

日志本身也会变成隐私问题。为了审计而保存的上下文，可能比原始业务库更容易还原一个人。应当事先写明日志里允许出现哪些个人信息，其余用不可逆指纹、截断或匿名化代替。差分隐私适用于需要发布统计或用人群数据改进模型的场合，用来限制单个人被反推出来的可能。它不能代替分类，也不能代替“这条数据本不该采集”。

用途和访问要能被审批。数据中台或同等的治理机制记录每次使用的目的、期限和调用方。合规或数据保护的职能参与审批，而不是在问卷里被通知一声。模型训练和在线推理分开管理：训练集的授权范围，不能被一次线上调试悄悄扩大。

车企和大型研发组织通常已经有研发、测试、法规和运营的协同。缺的往往不是又一个模型小组，而是把 AI 放进既有门禁之后，谁签字、谁值守、谁在事故当天有权停机。引入 Agent 如果不改职责，网关和注册表会变成另一套被绕过的表格。

登记、评审、值守

AI 资产目录是最低限度的组织工具。每一个 Agent 和模型登记负责人、业务场景、输入数据级别、权限、风险评级、依赖的工具和当前版本。没有登记项，就没有生产调用。上线前至少经过合规评审；涉及对人的显著影响时增加伦理评审。部署之后由治理或风险管理职能看监控，而不是由项目组在结项演示里口头保证。

变更管理要多轮，而不是一次审批覆盖所有环境。原型可以在沙箱里失败。进入生产的路径要重新评审，因为数据和权限已经不同。跨部门的 AI 治理小组——可以是委员会，也可以是明确的 AI 风险岗位——负责策略、例外和事件升级。岗位名称不重要，重要的是停机权限和评审否决权写在职责里，而不是写在倡议书里。

人要会用这套门禁

• 工程团队知道如何把审计、测试和回滚写进日常流水线，而不是结项时补文档。
• 管理团队理解模型的失效方式，不为实时生成设定超出架构边界的预期。
• 法务、安全与数据保护参与风险评估和策略，而不是只在合同阶段出现。
• 一线运营知道人机接管的触发条件、话术时限和升级路径。

迭代方式可以借用敏捷，但签收标准不能变成速度。AI 功能以可度量的里程碑进入计划：延迟预算、误报阈值、审计字段是否齐全、回滚是否演练。公司的开发生命周期文档要增加这些检查点，并写明 Agent 的责任人。培训的目的是让门禁被执行，而不是让全员接受一套新口号。

总体拥有成本不只有推理账单。它包括模型调用、为峰值准备的算力、人的值守、审计存储、失败之后的回滚，以及一次合规事件的代价。纯 Agent 方案如果默认走公有云 API，账单会随调用量和上下文长度起伏，业务侧很难做年度预算。传统架构的优势不是更便宜的口号，而是手上有开关：限流、路由、本地部署、降级。

AI 网关是成本控制点，也是安全控制点。按任务把请求送到不同模型：廉价而足够的模型处理摘要，强模型只处理真正需要它的少量调用。令牌预算和速率限制把异常循环——例如 Agent 反复调用工具——挡在账单失控之前。对自动驾驶厂商，障碍检测一类核心推理更合理的位置是车端或私有云，既为了时延，也为了不把每一帧都变成对外计费。

运维看什么

Agent 带来新的故障面：依赖的模型供应商、工具接口、提示与策略配置、输入分布。需要有人真正看着这些信号。集中监控可以沿用已经成熟的栈，例如用 Prometheus 与 Grafana 看指标，用 OpenTelemetry 把网关、模型服务和业务日志串成一条追踪。至少收集延迟、错误率、拒绝率、资源占用、输出被规则打回的比例，以及输入分布相对基线的偏移。告警要能触发降级或回滚，而不是只发到一个无人认领的频道。

统一的平台治理能把这些工作从每个项目组里收上来。行业里关于 AI 网关的实践（包括 TrueFoundry 一类平台所描述的路径）反复说明同一点：策略、配额和审计集中之后，运维负担下降，绕过也更难。技术栈尽量选开放、可迁移的格式和运行环境，例如 ONNX 这类模型格式、容器和 Kubernetes、带隔离的 Linux 运行时。可迁移本身就是成本控制，因为它让替换供应商不必重写业务。

• 核心实时推理优先私有或车端，按次计费的模型留给非关键、可延迟的任务。
• 为每个应用设置令牌预算、速率和并发上限，并在网关拒绝超额而不是在月底发现。
• 监控指标进入现有值班体系，和业务告警使用同一套认领与升级。
• 供应商合同写明可用性、数据位置、审计支持和模型变更通知，而不是只写单价。

Agent 驱动的系统要在设计时就有一张风险清单，并且和开发流程同步更新。清单至少覆盖四类：安全与隐私、功能可靠性、合规、业务。每一类都写明如何发现、谁负责、失败时的第一动作。没有负责人的风险矩阵只是一张图。

下面的矩阵是讨论用的示例，不是某一次测评的实测。横轴按可能性与影响粗分成四格，每一格给出第一处置。企业落地时要换成自己的阈值、负责人和检测手段。格里的动作应当能在运行手册里找到对应步骤。

高影响且高可能的格子要有应急预案和紧急停机。低影响且低可能的格子用定期检查即可，但检查必须真的发生。每项风险指定负责人、缓解措施和检测策略。跟踪尽量使用可量化指标，例如平均检测时间，以及安全论证里已经在用的暴露或寿命类指标，而不是用“风险可控”这种无法复测的句子。保险可以作为风险转移，尤其是自动驾驶业务中的专项险种，但它转移的是财务后果，不能代替停机开关和审计。

把前面的约束收成一张结构，就是传统架构加上 Agent 执行层，中间不让任何人直连模型。员工、主应用和车端都通过 AI 网关进入。网关后面同时挂着模型服务和业务规则。规则不是过渡方案，而是高风险路径的主体；Agent 是被调用的工具，并且随时可以被规则替换。

各层做什么

这张结构的可替换性是故意的。底层从一家云模型换成另一家，或从云换成本地权重，业务层和合规框架保持不动，只更新网关配置并重新跑验证。Agent 因此不可能长成一个绕过架构的影子系统。它被调用，被记录，被限额，也被关停。

同一套架构，落地节奏随企业规模变化。下面按小型、中型、大型给出不同的跨度。原则相同：先有分类、审计和网关，再扩大模型面；先有回滚，再放量。图中的综合甘特是一张示例节奏，用来看任务如何重叠，不是某一家公司已经发生的进度。

小型企业，大约一年

初期以云服务为主，用云厂商的 API 网关或同等的托管网关快速立起入口，只映射少量模型。同期完成数据分类标准和基本审计字段的接入。半年内给出最小可用路径：一个业务场景、一套策略、一条能回放的日志。一年内补上网关侧的基本合规策略和多模型路由。这一年不追求私有化全集，但禁止员工直连模型。

中型企业，一到两年

在云之外增加私有推理，并建立可用的注册表，至少覆盖负责人、用途、版本和风险等级。CI/CD 接入 AI 测试脚本，模型评审成为发布门禁而不是会后纪要。设立跨部门的治理小组，按季度审计使用记录。一年半到两年时，开发、发布和监控应当走在同一条流水线上，而不是三套手工表格。

大型企业，两到三年

混合云上的 AI 与机器学习服务全部纳入统一平台。独立的治理团队、数据职能和安全职能支持完整生命周期。高阶控制包括自动化的偏见检测和可解释性报告，但它们建立在前两年已经可用的审计和门禁之上。里程碑按顺序验收：关键组件上线、对照监管要求的合规验证、全量系统测试。计划里留下余量，用来响应新的政策和标准，而不是把日历排满到没有任何改正空间。

无论规模如何，有四件事不应当倒序。第一，数据分类早于模型接入。第二，审计字段早于对外演示。第三，回滚演练早于灰度放量。第四，注册表里的负责人早于生产权限。倒过来做，会得到一个能演示、不能被问责的系统，而那正是本文要避免的结果。

把“纯 Agent 实时生成”和“传统架构 + Agent 执行层”放在同一张表里，是为了做选择，不是为了否定生成式能力。前者在原型和非关键的文本工作里更快。后者才是安全、合规和数年运维所能接受的形态。自动驾驶，以及所有同等级别的企业场景，落在右列。

右列的优势集中在合规、安全和可维护。左列只在快速原型和非关键应用里显得成本更低，而且这还没有把一次事故或一次数据事件算进去。企业若把“先安全、再创新”当作顺序，就应当默认右列，把 Agent 放进执行层，而不是放在架构的位置上。

下面二十条是本文的操作结论。它们不是愿景清单。每一条都应当能在架构图、发布流程或职责说明里找到对应物。

1. 01企业级 AI 把 Agent 服务建在传统软件框架里。只靠动态生成，不可靠。
2. 02自动驾驶对安全和实时性的要求，决定了必须采用分层、模块化的架构。
3. 03所有 AI 决策都写入可审计日志，做到全程可追溯。
4. 04中国法律、ISO 标准与欧盟人工智能法案，规定了数据和模型的管控义务。
5. 05AI 网关一类中间件，是把技术审计和数据治理做实的核心。
6. 06数据在进入模型之前完成分类、脱敏和策略过滤。
7. 07每个 Agent 和模型在注册表中记录权限、用途、负责人和风险等级。
8. 08用 CI/CD 管理模型版本，并设置自动回滚和停机开关。
9. 09实时关键任务用轻量模型或硬逻辑兜底。Agent 只做辅助决策。
10. 10监控实时跟踪延迟、错误和偏差，并自动告警。
11. 11风险矩阵写明高风险项，例如数据泄露和误判，以及对应的缓解。
12. 12跨部门协同，使 AI 部署符合公司治理和行业准则。
13. 13按企业规模分级实施：示范、迭代、再升级，而不是一次铺满。
14. 14与供应商签订明确的服务水平协议，覆盖可用性和安全审计支持。
15. 15用红队测试、对抗样本和法规评审，定期检验鲁棒性。
16. 16业务与技术共同制定人机接管流程，关键时刻由人介入。
17. 17证据检索和决策跟踪一类可解释手段，同时服务外部审查和使用者信任。
18. 18治理政策必须可执行。停在文件里的原则不算治理。
19. 19目标是让 AI 在可度量的风险和审计条件下可靠运行。
20. 20这些做法已有行业实践支撑。企业在 AI 网关一类平台上的报告表明，集中管控会提高安全性和可控性。

这也是未必然研究院坚持“Agent 只能执行，不能创造”的原因。创造一套可保存、可长期运行的系统，是软件工程、安全论证和公司治理的工作。Agent 在其中执行被允许的步骤，并留下被允许的痕迹。自动驾驶只是把这条纪律显影得最清楚的场景。能源、安全生产和其他不能容忍不可解释失败的业务，适用同一底座。

本文的判断建立在公开的法律、标准、监管文件和行业实践上。不引用未公开的测评数据。架构图是示意，用来说明控制点放在哪里，不代表任何一家厂商的完整产品，也不代替正式的安全论证。

以上材料用于为企业的技术决策和管理决策提供依据：在自动驾驶这类复杂场景里，AI 只有站在可保存的软件架构和可执行的审计上，才谈得上安全与合规。