本系列的第一部分阐述了为何汽车行业的数据基础设施发展速度超过了其智能基础设施，并介绍了“代理循环”（Agentic Loop）——Sonatus提出的用于弥合这一差距的框架：检测 → 收集 → 推理 → 行动 → 学习。在第二部分中，我们将具体说明每个阶段的实际作用，以及为何这一顺序与各个阶段本身同样重要。
DETECT
检测是控制回路的起点，其质量决定了后续所有环节的质量。如果处理不当，会使系统充斥着噪声；如果处理得当，它就能起到精确过滤器的作用——筛选出有意义的信号，同时忽略那些无关紧要的信号。
汽车系统中的传统检测往往基于规则：阈值越界、故障代码触发、二元通过/失败条件等。这些规则是由工程师在某个特定时间点，基于已知的故障模式编写的。从定义上讲，它们是回顾性的——旨在捕捉已经出现的问题，而未将其与问题发生的更广泛的系统背景联系起来。
在基于代理的架构中，故障检测的方式有所不同。它以概率性和情境化的方式运行，同时综合利用多个车辆领域的模式——不仅涉及孤立的动力总成、热管理或车辆网络，还包括它们之间的交叉点。在特定驾驶场景中，与特定网络流量模式同时发生的热事件，其信号意义与孤立出现的同一热事件截然不同。 上下文会改变信号的含义，因此检测必须具备上下文感知能力，才能在恰当的时刻呈现正确的信号。
关键在于，检测是持续进行的——并非作为测试日结束时的批处理过程，而是作为嵌入车辆智能基础设施中的实时层。这正是使该循环具有主动性而非仅仅是分析性的原因。
COLLECT
一旦检测到值得调查的情况，采集阶段就会确定需要捕获哪些数据——同样重要的是，确定哪些数据不被捕获。
这里的转变是从“持续记录”转向“基于事件触发、有针对性的数据采集”。持续记录会产生海量数据，其中绝大多数将永远不会被分析。通过蜂窝网络传输这些数据成本高昂，存储成本高昂，处理成本也高昂。更重要的是，海量日志通常缺乏使其具有可操作性所需的上下文信息：如果不知道是什么触发了数据捕获，原始遥测数据就很难解读。
事件驱动的采集则颠倒了这种关系。当检测层识别出值得调查的信号时，采集阶段会组织一次针对性的捕获：正确的通道、正确的时间窗口、正确的跨域上下文——精准地围绕目标事件进行捕获。工程师收到的不再是数吉字节的连续日志，而是关键数据，其中还附有关于事件发生条件的丰富注释。
正是这一点消除了重新驱动的必要。之前丢失的上下文——即在任何人配置日志记录器之前就已关闭的窗口——会在第一次就被捕获，因为系统当时已经在监听它了。原型无需再次发出请求。工程师们已经获得了他们所需的信息。
理由
推理是智能架构与数据架构之间最明显的区分点。正是这一环节，使循环从“发生了什么”转向了“为什么”。
车辆系统的复杂性使得手动进行根本原因分析变得越来越困难。动力总成、热管理、ADAS 和车辆网络之间的跨领域交互，会产生一些故障模式，这些模式在任何单一数据流中都无法清晰地显现出来。一位经验丰富的工程师可能需要花费数天时间，对 CAN 日志、以太网捕获数据、传感器数据和系统事件跟踪记录中的信号进行关联分析，才能对根本原因形成假设。 而且这种专业知识很难传承：它存在于个人身上，是经过多年诊断工作积累而成的，一旦相关人员考虑其他机会，这种知识就会成为人才流失的风险。
在基于代理的架构中，推理阶段正是针对此类多来源、跨领域数据，应用基于AI 的分析技术。它并非取代工程师的判断，而是缩短了从数据到假设所需的时间。它会列出潜在的根本原因及其支持证据，并以结构化的形式呈现，便于工程师进行审查、验证并采取行动。工程师始终参与其中；这个流程只是运行得更快，且能够处理比任何个人手动操作所能应对的更为复杂的任务。
此外，此事还涉及一个知识保存的层面，而业界往往对此低估。当诊断专长被编码到推理层中——即专家工程师积累的模式识别能力被封装到系统中，而非仅存于他们的脑海中时——它便成为了一项持久的机构资产。它不会“退休”，而是会不断增值。
ACT
正是行动阶段使该循环真正具有能动性，而不仅仅是分析性的。如果没有这一阶段，“能动性循环”不过是一个复杂的报告系统；有了这一阶段，智能便成为一种结果。
这些操作的范围被有意设计得相当广泛。一端是：通过验证工程师现有的任何工具，向其提交结构化的调查结果，其中包含支持证据和潜在根本原因；另一端是：针对特定的车队分组触发 OTA 配置更新，或为特定经销商网点的一辆车标记服务建议。 在这两个极端之间，还存在一系列自动化和半自动化的响应措施，这些措施会根据推理的置信度、决策的重要性以及原始设备制造商（OEM）的组织政策进行调整。
行动层也是该循环产生最显著商业价值的地方。以往需要耗费数天时间进行人工分析，并安排会议才能采取行动的分析结果，如今可以在数小时内浮出水面并得到传播。以往需要等到保修索赔激增才能启动的车队质量干预措施，如今甚至可以在第一起客户投诉出现之前就实施。
学习
学习阶段正是“能动循环”与此前应用于车辆智能领域的所有其他方法的区别所在——而且这也是所有阶段中具有最重要战略意义的阶段。
该循环的每个阶段单独来看都具有价值。但如果没有学习阶段，该循环将处于静止状态：第1,000个周期的检测、收集和推理质量，不会比第一个周期更好。学习阶段从字面意义上闭合了该循环——结果会反馈到检测模型和推理知识库中，并根据已确认的内容、错误的信息以及新出现的模式对它们进行更新。
这意味着该系统会随着时间的推移而显著提升。这种提升并非微乎其微的渐进式改进，而是呈复利增长的——因为每个循环都会为系统的累积智能增添新的内容，从而提升后续每个循环的质量。我们稍后将探讨这一点为何对OEM战略至关重要，因为我们认为这是该架构最重要的启示。
为什么“操作系统”是一个恰当的比喻
让我们对“操作系统”这一比喻进行精准的阐述，因为如果没有正确的依据，它很容易被误解为定位宣传话术。
操作系统并不执行应用程序的功能。它负责管理底层资源——计算、内存、I/O——从而使应用程序能够专注于其设计的功能。它创建了一个稳定的、共享的平台，使各种不同类型的工作都能在此高效运行。
“代理循环”（Agentic Loop）在车辆智能领域也发挥着同样的作用。它管理着车辆数据底层的复杂性——包括检测、采集、推理、执行和学习——从而使基于该循环进行开发的团队能够专注于其核心工作：制定工程决策、提升产品质量、服务客户。它并未取代上述任何一项功能，而是为各项功能创造了条件，使其能够以远高于没有该循环时的速度和质量运行。
就像操作系统一样，在其上运行的功能越多，它的价值就越大。贯穿验证、质量和服务环节的共享智能基础架构，其价值远高于在各自孤立的领域中部署相同能力——因为在验证阶段学到的模式能为现场检测提供参考，而在现场确认的失效模式又能反馈到验证基准中。这一循环不仅在单一职能内部运行，更将各个职能相互连接起来。
“循环”在实践中的应用：SOP前与SOP后
在车辆生命周期内，该循环的架构保持不变。发生变化的只是数据来源以及循环末端的操作性质。
在SOP之前，验证阶段中，该循环针对运行结构化及非结构化测试场景的原型车进行运行。 检测功能可在试驾过程中实时识别异常。定向采集功能会在车辆返回车库、数据窗口关闭之前，当场捕获相关上下文信息。推理功能会在当天（有时甚至更快）为验证团队提供潜在根本原因的候选方案。采取的行动可能包括立即调整测试方案，或将设计发现转交负责的工程团队。学习功能会更新检测和推理模型以备下个测试周期使用，从而使系统在后续测试中能够针对性地关注关键问题。
SOP之后，在实际应用中，该循环会在整个量产车队中大规模运行。检测功能可识别新兴模式——按区域、驾驶循环、软件版本或环境条件聚类的故障模式。针对性数据采集通过来自故障发生车辆的精确、可重现的证据来验证该信号。推理分析则在车队层面诊断根本原因。 应对措施可能包括针对特定软件配置进行 OTA 更新、在故障被客户察觉之前开展主动服务活动，或向零部件供应商发出质量警报。通过学习机制，将新的故障模式纳入检测基准，使下一代平台在开发之初便已内置该知识。
无论是验证车库还是量产车队，系统架构本身并不会发生变化，只有数据来源和最终执行的操作有所不同。不过，这种一致性绝不仅仅是一个设计细节。正是由于这一点，此类系统运行时间越长，其价值就越高——这正是当前整车制造商在思考这一问题时最应重视的论点。
