随着Agentic AI不再局限于辅助角色，而是开始直接参与工程工作流中的执行环节，“可信”正成为绕不过去的核心问题。与传统自动化工具不同，Agentic AI系统不仅需要跨领域推理、调用工程工具、完成跨域重复性任务，还必须运行在对安全、性能和验证有严格要求的环境中。一旦AI开始主导规划、执行和迭代，即使单个结果看似正确，也可能因组件间交互而在系统层面引发非预期行为。

在软件定义产品的开发中，这类风险的根源并不只是AI具备更强自主性，而在于现有工程工作流往往难以把系统级行为转化为可执行、可验证的表达方式。

这一问题在现实中已有体现。当前汽车召回案例中，超过五分之一涉及软件相关修复，类似的集成失效在其他软件定义系统中也并不少见。比如，一项时序调整即便通过了单元测试，只要被集成进依赖原有行为的更大控制回路，仍可能触发问题。其根本原因在于，随着系统持续演进，系统级行为并未被持续、统一地评估。

文章认为，要建立对Agentic AI的信任，工程团队需要引入“系统优先工程”（System-First Engineering）。这一方法的核心，是在开发早期就把系统级行为置于优先位置，并通过基于模型的设计（Model-Based Design）加以落实。

与其依赖基于假设的交接，不如以可执行的系统模型作为统一基准。这样的模型既能覆盖机械、电气、软件等不同领域，也能成为工程师与Agentic AI共同引用的系统行为依据，使AI沿着可验证的工程流程推进工作，而不是停留在抽象需求层面。即便开发规模扩大到更多团队和职能，系统行为也能获得一致解读。

系统优先工程一方面为Agentic AI提供结构化运行边界，另一方面也有助于降低非预期风险。领先团队通常会在硬件尚未就绪前完成系统虚拟化，并借助自动化工作流持续评估系统模型，这类实践通常依托CI/CD流水线和闭环仿真完成。

在这一框架下，Agentic AI可以通过协调并直接执行建模、测试和验证任务，进一步加快开发流程。它能够调用基于模型的设计中可自动化的环节，并按照预定义流程模型执行各项步骤。这样一来，由代理发起的变更可以在进入后期集成阶段之前，先依据系统行为基准完成早期评估。工程师则负责监督Agentic流程及其输出，并对最终的验证与确认（V&V，Verification and Validation）承担审批责任，从而确保AI驱动的执行建立在系统级证据基础之上。

确定性验证是建立信任的基础

对Agentic AI的信任，最终来自可重复性。要实现可重复，就必须依赖确定性验证（deterministic verification），提供一致、可审计的证据，以支持可追溯性和安全审查。采用系统优先工程的团队，会以“可执行规范”替代容易产生歧义的文档，将系统架构和设计一路贯通到代码生成与测试，并据此用同一套系统行为基准评估代理发起的所有变更。

软件可以按天迭代，但硬件开发周期往往长达数周甚至数月。在这种情况下，把验证建立在硬件测试之上并不现实。团队可以通过仿真持续运行既有系统模型，减少对高成本硬件测试的依赖。无论变更发生在软件、架构还是控制逻辑层面，都应基于系统整体模型开展确定性验证，在进入硬件阶段之前发现系统级错误，例如时序目标未达成或内存占用过高。依托可重复的验证证据，即使系统复杂度持续上升，团队仍能对Agentic AI带来的变更进行审查和认证。

Agentic AI应运行在已验证的系统内

当确定性验证成为信任基础后，接下来的关键问题是：Agentic AI应如何在这一环境中运行。它需要处理系统模型、组件模型、测试用例、场景变体等工程产物，其中相当一部分本身就可以由生成式AI生成。Agentic AI同样可以参与这些产物的生成，但更关键的角色，是将其纳入“变更可验证”的工作流中统一处理。

例如，若代理调整了时序参数，即便该变更本身通过测试，下游控制器仍可能因为原先按既定速度接收信号而误判输入。为了避免这类失效，Agentic AI必须运行在“生成”与“执行”相分离的工作流中。在既有基于模型的设计流程之上，它可以进一步提升仿真、代码生成、分析和测试等环节的自动化水平。

这类工作流可以借助Simulink Agentic Toolkit等工具实现：系统优先工程负责界定哪些内容可执行、可验证，Agentic AI则负责判断自动化步骤应在何时、以何种方式被调用。

将系统优先工程与Agentic AI引入工程工作流，通常是一个渐进推进的过程。实践中，往往先从单一功能、单一团队起步，在通过自动化仿真和测试工作流验证系统模型后，再逐步扩展到相邻团队。Agentic AI负责生成和评估变更，而验证机制则在进入下一阶段前确认相关变更已经完成测试。许多团队还会搭建统一环境，为不同团队提供一致的CI流水线和验证护栏，避免模型仅在少数团队内部运行，形成缺乏CI支持和跨领域复用能力的碎片化部署。

统一环境的意义在于，Agentic AI从一开始就不是以“孤立工具”的方式被引入，而是在一致的系统级上下文中运行。这样，团队既能在不割裂工作流的前提下稳步扩展，也能为建立对AI执行结果的信任打下基础。

文章指出，软件定义产品的大规模开发之所以失败，很多时候正是因为团队只把单一领域视为“系统”，却没有把整个工程体系作为系统来管理。对Agentic AI的信任，也会在同样的条件下失效。打造可靠产品所需要坚持的原则，如今同样适用于Agentic AI。

换句话说，如果没有可执行模型，很多判断就仍停留在经验和意见层面。代码可以定义单个组件的行为，但只有可执行的系统模型，才能为系统层面的组件交互提供共同基准。如果某项变更无法在整体系统模型中通过验证，就不应投入应用。即便它在本地测试中表现正常，也仍可能在系统其他部分引发回归问题。

同样，如果相关行为没有经过能够反映真实运行条件的仿真验证，那么结论本质上仍只是推测。其结果是，潜在故障模式往往要到硬件测试甚至现场运行阶段才被发现，而此时返工成本已经大幅上升。

如果需求没有与模型、测试和数据建立关联，系统实现与需求之间的一致性也会被削弱：团队将难以追踪究竟是哪些模型或测试在验证某项需求，已经实现的行为也可能逐渐偏离初衷。对于代理主导的变更，如果无法通过可执行模型、确定性分析和人工审查完成验证，就不应被接受。否则，在后续审查和审批过程中，将难以说明“改了什么、为什么改”，以及相关变更是否满足系统级需求。

因此，工程师必须始终掌握对代理主导变更的控制权，基于系统级证据审查结果，并作出最终批准。一旦出现问题，也应像处理其他工程问题一样，通过模型和测试进行追踪、诊断与修复，再进入下一阶段。具备合适工具、流程和实践体系，并以系统方法推进工程的团队，才能在保持系统级确定性的前提下引入Agentic AI，并交付可信的软件定义产品；否则，就可能在集成、认证或召回阶段暴露Agentic行为的边界。