如何构建可信的 Agentic AI：系统优先的方法

随着 Agentic AI 从辅助工具逐步走向流程中的执行角色，“信任”成为无法回避的问题。此类系统能够跨多领域进行推理、调用工程工具，并在满足严格安全、性能和验证要求的复杂系统中不断迭代。当 AI 同时承担规划、执行与迭代职责时，即便单个输出看似正确，在整体系统中也可能引发意外行为——这是由于系统组件之间的交互会带来新的失效模式。

在软件定义产品中，这类风险并非源自 AI 的自主行为，而更多源于工程流程缺乏可执行的系统级行为表达。目前，软件相关问题已占汽车召回的五分之一以上，类似的集成问题在其他软件定义系统中同样普遍存在。例如，一个通过单元测试的时序调整，在集成到依赖原始行为的控制回路后仍可能导致系统异常。这些问题的根本原因在于，系统级行为在演进过程中未能持续、一致地进行评估。

系统模型将需求、设计、虚拟化与代码连接起来，实现贯穿整个开发流程的执行能力

为什么系统上下文对 Agentic AI 至关重要

工程团队通过采用“系统优先工程”来构建对 Agentic AI 的信任。这一理念强调在开发早期就关注系统级行为，并以基于模型设计（Model-Based Design）为基础。通过使用可执行系统模型作为共通载体，取代基于假设的信息传递，工程师与 Agentic AI 能够共享统一的系统级参考。这些模型贯穿机械、电气与软件领域，提供一致的行为基准，使 AI 不仅依赖抽象需求，而是扎根于成熟的工程流程中，从而在团队扩展与功能迭代过程中保持行为一致性的理解。

系统优先工程为 Agentic AI 提供了结构化的运行环境，同时降低了意外风险。领先团队通常在硬件实现之前就对系统进行虚拟化，并通过自动化流程持续评估系统模型，这些流程通常依托 CI/CD 管道和闭环仿真实现。Agentic AI 通过协调并主动执行模型、测试与验证活动，加速整个开发流程。它通过调用基于模型设计中可自动化的部分，遵循既定流程模型来完成各项工程步骤。在这一环境中，能够在早期就针对系统行为对由智能代理驱动的变更进行评估，从而避免在后期集成阶段暴露问题。工程师依然负责监督代理过程与结果，并承担最终验证与确认（V&V）的审核职责，确保 AI 执行过程始终以系统级证据为依据，而非孤立输出。

确定性验证构建信任基础

对 Agentic AI 的信任源于可重复性，其核心在于确定性验证，即能够提供一致、可审计的证据，用于追溯与安全评审。系统优先工程团队以可执行规范取代易产生理解偏差的文档，这些规范贯穿系统架构与设计、代码生成到测试全过程，确保每一项由代理驱动的变更都能依据同一系统行为进行评估。

在软件可以日更迭代、而硬件开发周期以周甚至月计的背景下，依赖硬件进行验证已不可行。团队通过持续仿真已建立的系统模型，减少对昂贵硬件测试的依赖。所有软件、架构及控制逻辑的变更，都在完整系统表示下进行确定性验证。这使团队能够在问题进入硬件阶段之前，就发现系统级故障，例如时序未达标或内存占用异常。基于这种可重复的验证证据，团队能够在任务复杂度不断提升的情况下，对 Agentic AI 的输出进行审查与认证。

系统优先工作流连接模型、代码与验证，实现从设计到部署的持续执行

Agentic AI 在可验证系统中的执行

在通过确定性验证建立信任之后，下一步要解决的是 Agentic AI 如何在该环境中运行。在工程流程中，Agentic AI 主要作用于系统模型、组件模型、测试用例及场景变体等工程资产，其中部分内容可能由生成式 AI 生成。虽然 Agentic AI 也可以参与这些资产的生成，但其核心价值在于在工作流中对这些资产进行操作，并通过独立验证来确保其正确性。例如，一个代理可能调整了某个通过测试的时序参数，但却导致下游控制器误读原本按既定频率接收的信号。

为避免此类问题，Agentic AI 必须运行在明确区分“生成”与“执行”的工程流程中。它本质上是在既有基于模型设计流程中的自动化程度提升，这些流程涵盖仿真、代码生成、分析与测试，并可通过如 Simulink® Agentic Toolkit 等工具实现。系统优先工程定义了哪些内容可执行、可验证；而 Agentic AI 则决定在何时以及如何执行这些自动化步骤。

System-First Engineering 奠定基础

基于系统优先工程引入 Agentic AI 是一个渐进过程。工程团队通常从单一功能和小规模团队入手，通过自动化仿真与测试流程验证系统模型，再逐步推广至相关团队。Agentic AI 负责生成并评估变更，而验证流程确保每一项变更在推进前都经过测试。许多团队会构建统一的初始环境，使各团队共享相同的 CI 流程与验证约束，从而避免碎片化应用，例如某些模型仅存在于单一团队且缺乏持续集成或跨学科应用。

这一统一环境也确保 Agentic AI 从一开始就运行在一致的系统级上下文中，而非孤立引入。其结果是在不割裂工作流程的前提下实现可靠扩展，并为建立对 AI 驱动执行的信任奠定基础。

当团队将单一领域误当作“系统”的全部时，软件定义产品开发的规模化便会失败。Agentic AI 的信任同样在这种情况下崩塌。构建可靠产品始终依赖一系列不可妥协的原则，而这些原则同样适用于 Agentic AI：

• 如果不是可执行模型，那只是观点。代码可以定义单个组件的行为，而可执行系统模型则提供组件在系统层面如何交互的统一参照。
• 如果某项变更在完整系统中验证失败，就不能交付。局部测试通过的改动，依然可能在系统其他部分引入退化问题。
• 如果行为未通过真实工况仿真验证，那只是猜测。故障模式将被推迟到硬件测试或实际部署阶段才被发现，代价高昂。
• 如果需求没有与模型、测试和数据建立关联，就会与系统实现脱节。这使得难以追溯哪些模型或测试验证了特定需求，从而导致实现偏离最初设计意图。
• 如果代理驱动的变更无法通过可执行模型、确定性分析以及人工审查验证，就必须被拒绝。缺乏这些验证，团队无法在审查与审批过程中说明变更内容、变更原因以及其是否满足系统级要求。

工程师始终掌控代理驱动的变更，通过审查结果并基于系统级证据进行最终确认。一旦出现问题，将其视为常规工程问题，通过模型与测试进行追溯、诊断并修正，然后再继续推进。

具备合适工具、流程与方法来构建系统的团队，能够交付可靠的软件定义产品，并在不丢失系统级信心的前提下引入 Agentic AI。而缺乏这些基础的团队，则将在系统集成、认证或召回阶段遭遇 Agentic AI 能力的限制。

作者：朱天一，MathWorks 高级产品经理