Loop 怎么跑进汽车研发：FDE 驻场，把 AI 做成自主闭环

旧方式：你打开对话框、粘贴一份需求、等它回答。

新方式：凌晨两点没人开对话框——一份新需求文档被同事丢进 Polarion；等你早上到工位，需求分析、冲突清单、一份草稿 Test Run 已经躺在那儿了。因为有一个被我们"驻场配置"过、一直盯着你项目的 Agent。

这篇讲的，就是汽车研发 AI 化真正落地的两个词：FDE（驻场工程师） 和 Loop（自主闭环）——以及它在客户自己的 Polarion 上是怎么跑起来的。

关于平台：Combo Agent 是什么

本文反复出现的"它"，指的是 Combo Agent™——我们的企业级 AI 智能体平台。它的核心理念是"可插拔技能（skill）"：把解析、建模、出图、合规分析、ALM 读写、测试回写等一个个专业能力，封装成标准化、按需调用的技能单元，挂在平台应用层；你用自然语言说清要做什么，平台就在沙箱里自动编排相应技能、跑完全流程并交付结果。

它要解决的事很直接——用 AI 智能体赋能企业现有工作流、降本增效，而不是替换你现有的工具链（DOORS / Polarion / Jama / Jira / CANoe / dSPACE 照旧）。上一篇我们讲了"从设计文档到 ASPICE 合规图"，这一篇换个角度讲怎么落地：不是把工具交给你，而是把工程师"派过去"。

为什么不是"又一个聊天框"：四个落地差异

这两年汽车研发团队被各种 "AI" 轰炸过，大多试用完就回到老路——因为它们不落地。把话说直白，对比一下你大概率试过的几类方案：

一句话：别人给你一个工具，我们给你一个驻场、能写进你系统、还自己盯着干的工程师。下面全是干货——而且文末，我们会当场写一条进你的 Polarion 给你看。

第一个词：FDE——不是卖工具，是"派工程师进场"

FDE（Forward Deployed Engineer，前置/驻场工程师）这个角色最早由 Palantir 提出。Palantir 的产品（Foundry / Gotham）强大但通用——可没有哪个客户能把一个平台"开箱即用"地变成解决自己问题的方案。于是它没有派一支"咨询顾问团"，而是派资深工程师亲自驻场：坐进客户的办公室、参加客户的早会、读懂客户的业务，然后把能跑在生产上的软件直接交付出来，一直待到系统上线、被真正用起来。

关键区别在这里——FDE 不是"给建议的顾问"，也不是"做个 Demo 的售前"：

我们把这套模式搬进了汽车研发。落到我们身上，FDE 意味着每个工程师必须做到两件"非常懂"：

• 非常懂客户的工作流——不是泛泛"了解需求"，而是把客户的研发流程一节一节摸清：需求在 Polarion 里走哪条状态机、用例怎么派生、台架 / HIL 怎么执行、结果回写到哪些字段、追溯线怎么连。再叠加我们咨询工程师对 ASPICE / 功能安全流程的理解，才知道这条链到底该怎么转。
• 非常懂 AI 的边界——同样重要的是知道 AI 不该碰哪里：哪些是机械对齐、跨工具搬运、出草稿，可以放心交给 Agent；哪些是判断、决策、签字，必须留在人手里。边界划错，要么不敢用，要么乱用。

FDE 的价值，正落在"懂流程"和"懂 AI 边界"这两件事的交叉点上：把 Agent 配置成一个懂你项目的同事——而不是丢给你一个通用工具，让你自己摸索。

一句话：我们不卖一份 License 然后走人，而是坐进客户的办公室，把客户的研发流程、Polarion 里的字段与状态机、各域的判定规则，一条条配置进 Agent。交付物不是"一个通用工具"，而是"一个懂你项目、还能自己开工的同事"。

第二个词：Loop——配好的 Agent 自己开工

配置好的 Agent 不再是"一问一答"。它常驻、盯着事件、自己开工。机制很简单：

CronJob：     时间到了 → 往 session 里塞一条消息 → Agent 按提示词决定做什么
EventTrigger：事件来了 → 往 session 里塞一条消息 → Agent 按提示词决定做什么

触发系统不预定义"审核/通知/报告"这些动作——Agent 是逻辑层，你的提示词是配置，触发系统只管投递。你说"有新需求就分析"，它收到事件就分析；你说"有结果就判定回写"，它收到结果就判定回写。

闭环的一天：以 DrivePilot 项目为例

下面用我们自己部署的一套 Polarion（项目 DrivePilot）把闭环串一遍。场景是一个很常见的活：功能测试 + 台架执行——需求来了要分析、要派生用例、上台架跑、结果要判定并回写。传统做法这条链全靠人来回搬运；闭环里它自己转。

下面这些都是从这套 Polarion 真实截下来的——不是 PPT：

左侧栏就是一套完整的研发结构：Requirements / Design / Risks / Planning / Development / Testing / Maintenance。列表里 DP-528、DP-532 这些，正是下文闭环自己写进去的工作项。

触发：事件驱动是闭环的发动机

闭环之所以能"自己开工"，靠的是一套与定时任务平行的事件触发基础设施。事件源可以是：

• Polarion 变更——新建工作项、状态流转、Test Run 更新；
• 一个被监视的上传目录 / 网盘——有新需求文档就开扫；
• SCM——PR / push（代码侧，已量产）。

事件到了，触发系统按"来源 + 过滤条件"匹配规则，把它格式化成一条消息投递进目标 session，剩下的交给 Agent。

配置它，就是一句话：

你：以后 DrivePilot 里只要进来新需求文档，就自动做需求分析，
    把冲突点登记成问题单；不用每次叫我。

Agent：✅ 事件触发器「新需求自动分析」已创建。
       以后 DrivePilot 收到 workitem.created（需求类）事件，
       我会在这个会话里自动处理。

几个工程上的"防呆"细节，决定了它在真实项目里不会乱跑：

写进客户的 Polarion：读写 + 自定义字段 + 灵活定义

闭环要落地，关键是能写进客户自己的 Polarion——而每家的 Polarion 都不一样：工作项类型不同、字段是自定义的、状态机和链接规则也是自定义的。我们的做法是把 Polarion 当成一棵"可自定义的树"：

项目 → 文档空间 / LiveDoc → 工作项类型（含自定义类型）→ 字段 / 枚举值 / 工作流状态机 / 链接规则；测试管理（Test Run 字段 / Step 列）是另一枝。

这棵树不写死支持清单。一条命令 discover-schema --deep，就能把整棵真实结构自动拉出来：有哪些类型、每个类型有哪些字段（含自定义）、枚举字段的合法选项、状态机的"动作 → 目标状态 → 前置字段"、链接关系规则……

发现到的结构，会回填进一份客户可复核的 workflow.md：

• 有规范就照着做——客户在 workflow.md 里写了类型/字段/枚举/链接/状态流转，Agent 严格照办，不自作主张；
• 没写就 discover 出来——空白小节自动补全，标注"（AI 自动发现·待确认）"，让客户复核；
• 客户已手写的，一律不改、不覆盖。

写字段时该注意的，工具都替你兜住了：枚举字段填合法选项 id（自动包成 Polarion 要的类型）、状态流转自动带上前置字段（比如先填 resolution 再流转），否则 Polarion 会拒绝。不同客户对同一概念的命名差异（DOORS 叫 Safety、Polarion 叫 safety、禅道叫 customSafety），用一份 per-客户的映射 yaml 做一次"原生名 ↔ 规范名"翻译，业务代码只认规范名。

看真实的一条：缺陷 DP-528 就是闭环自己写进 DrivePilot 的——类型、严重度、状态、优先级、版本这些字段一栏不缺；描述区里原样带着 Test Run、Test Case、8 步测试步骤，以及那句判定："HIL: torque 14.2Nm exceeds 10Nm limit"。

信号与规则：汽车特有的两层功夫

需求和测试之外，汽车还有一层别人没有的活。这里其实是两件事叠在一起——一件是把数据解出来，另一件是知道"解出来的值到底合不合格"。

第一件：信号分析——把总线与标定的运行时数据还原成能判定的物理量。

第二件：知识库（KB）——把信号解出来只是前半场；"这个值合不合格"要靠 KB。KB 里沉淀的，是这家客户对两类东西的解析，落成可执行的判定规则：

• 需求 / 期望值解析——把客户测试需求里的期望值、阈值、容差，归一成可精确查询的库（E2E / DTC / CCDB、通信矩阵……）；判定时按"现象 → 用例 → 需求"下钻取值。
• 法规 / 协议解析——把行业标准和诊断协议的硬性约束写成规则。以 UDS 诊断（ISO 14229） 为例，这类规则非常具体：
  • 正响应格式：如 0x22 ReadDataByIdentifier 的正响应必须是 0x62 + 回显原 DID + 数据记录，长度与分帧（ISO-TP）要合规；
  • 时序：服务要在 P2_server 内响应，需要更久就得用 0x78（responsePending）合法延时，超出 P2* 即判不符合；
  • 负响应码（NRC）：该拒绝时要回对的码——0x13 长度非法、0x31 超出范围、0x33 安全访问拒绝；该放过的不能乱拒。

最关键的一条设计原则：规则不写死在技能里。期望值、阈值、UDS / 法规判定，全部是 KB 条目，按客户 / 车型 / 法规版本配置、可随时覆盖；加一个测试域 = 加一个文件（网络测试已落地，UDS / 诊断、DTC / OCC 按需求清单往下扩），主框架不动。

把上面这些拼起来，就是一条由事件驱动、跑在客户 Polarion 上的技能流水线：

回写闭环：HIL 结果怎么变成 Polarion 里的判定 + 缺陷 + 追溯

判定出来了，怎么"落"进 Polarion？这一步是闭环真正的收口，规则全在业务层，可按客户配置覆盖。

第一步：判定词归一。台架/分析工具的原始判定五花八门，先映射成 Polarion 的标准结果枚举：

映射表客户可覆盖；遇到不认识的判定词宁可报错也不乱写——把错的结果写进 Polarion 比报错更危险。

第二步：按顺序收口（每条用例独立处理，一条出错不中断整批）：

1. 写用例结果（set_test_result）、写步骤级结果；
2. 先判定、后传证据——证据附件在结果写好之后才上传（Polarion 不接受未执行记录的附件）；
3. 失败项自动建缺陷，把判定详情（失败信号、阈值、实测值等）一起带上；客户若在 Polarion 自定义了 DTC / 信号 / OCC 等字段，可直接按字段写入；
4. 给缺陷连追溯线：缺陷 ↔ 用例、缺陷 ↔ 需求（链接类型按客户命名翻译）。

还是真实截图。这条 Test Run 跑完，饼图是 1 通过 / 1 失败；下面 "Problems Reported" 直接把失败用例 DP-224 和它自动生成的缺陷 DP-528 摆在一起——判定、建缺陷、连线，一步没落：

反过来从用例 DP-224 看，"Test Records" 记着这次 Failed、对应的 Test Run 和缺陷 DP-528；"Linked Work Items" 里追溯线一条条连着——缺陷 ↔ 用例 ↔ 需求，断链在这条流水线上不存在：

眼见为实：让 skill 当场写一条给你看

截图也许还不够——你可能会想："这会不会是手动建的？" 那就让 skill 当场跑给你看。

写这篇文章时，我们把 skill 的 Polarion 适配器（PolarionAdapter，走 python-polarion 的 SOAP/WSDL）直接连上这套 Polarion：admin 登录 → 先读 DP-224 / DP-528（证明读得到）→ 新建一条缺陷 → 写字段 → 加评论 → 传附件 → 连追溯线。全程没有人点鼠标，都是代码干的。下面是这次运行的日志节选：

INFO  tools.adapters.polarion_adapter: Polarion login OK: admin@http://<客户 Polarion>/polarion
[login]    -> True
[health]   hasService(Tracker) -> True
[read]     DP-224: type='systemtestcase' status='active'
[read]     DP-528: type='issue'          status='open'
[read]     test runs in drivepilot: 16
[create]   defect  -> DP-544
[comment]  DP-544  -> True
[attach]   DP-544  <- hil_evidence_20260613-133804.log -> True
[link]     DP-544  --relates_to--> DP-224 -> True
[verify]   read back DP-544: status='open' severity='major' priority='70.0'
[verify]   links: [('relates_to', 'DP-224')]
>>> PROOF DONE. New defect DP-544

几秒后回到 Polarion，这条 DP-544 就在那儿——而且它自己"招了"：描述和评论都写着"由 Combo Agent alm-integration skill 写入"；附件 hil_evidence_20260613-133804.log 挂着；Linked Work Items 里 relates to → DP-224 也连上了。一次运行，把回写闭环要的「结果 / 字段 / 评论 / 附件 / 追溯」全落了地：

边界：它不替代工程师

闭环再自动，判断权始终在工程师手里。Agent 做的是机械对齐和出草稿，工程师做的是决策和签字。

加上私有化部署、客户数据租户级隔离、不出域、不做跨客户基准训练——"你的数据养你的 Agent"。

方向性收益（参考值，非承诺）

具体值要结合项目规模、Polarion 历史质量、团队工程纪律评估。

客户常问

Q：我们的 Polarion 字段很特殊，自定义了一堆，能用吗？ A：能。这正是设计出发点——discover-schema 把你的真实结构（含自定义类型/字段/枚举/状态机）读出来，写进 workflow.md 给你复核，之后直通读写，不要求你改任何字段。

Q：事件触发会不会乱跑、重复跑、把工程师刷屏？ A：有 debounce（同一条多次改只触发一次）、conflict_policy（会话忙时排队）、分布式锁（多 worker 不重复），可控。

Q：我们不想全自动，想在关键节点人工确认。 A：可以。把"判定有争议 / 置信度低于阈值"的条目留给人确认，其余自动；阈值项目初期可调低（多让 Agent 建议），成熟后调高（少打扰）。

Q：跨多个 ALM 工具能搞吗？ A：能。DOORS / Polarion / Jama / Jira / 飞书项目都有适配器，不要求客户换工具。

Q：数据安全？出不出域？ A：私有化部署、内网可跑、租户级物理隔离、不做跨客户基准训练。

想看它在你的项目里跑起来？

最快的验证方式：给我们一份脱敏的需求文档，或一段 Polarion schema（也可以直接开一个只读账号），我们用你的数据跑一遍闭环，让你亲眼看到：

• 需求分析 + 冲突 / 歧义清单长什么样；
• 从需求自动派生出的功能测试用例；
• 一条结果真的写进你的 Polarion——结果 / 缺陷 / 附件 / 追溯，就像本文里那条 DP-544。

私有化部署、数据不出域、不做跨客户训练。先看效果，再谈上不上线。

联系我们：info@nox-lumen.com