ALM 平台对接

方案定位

汽车研发的需求往往"卡"在 ALM 工具里——看得见但用不出来。这个方案让 combo agent 直接读懂 ALM 工具里的需求、架构、测试资产，完成需求理解 / 追溯建立 / 变更广播 / 覆盖审计的全链路自动化，不做数据迁移、不改变客户既有工作流。

支持矩阵

ALM 平台	协议	能力覆盖
IBM DOORS Next (DNG)	OSLC RM 2.0 + Reportable REST	✅ 完整（主推荐）
IBM DOORS 9 (Classic)	DXL + Excel/ReqIF 中间件	✅ 读写
Polarion ALM	REST API	✅ 读写
Jama Connect	REST API	✅ 读为主
codeBeamer	REST API	✅ 读写
Jira (+ Xray / R4J)	REST API	✅ 需求 / 任务
Redmine	REST API	✅ 需求 / 任务
自研 / 内网 ALM	Base Adapter 适配	⚠️ 按需开发

DOORS Next 深度能力（主推荐）

围绕 OSLC RM 2.0 构建的完整能力：

能力	说明
模块发现	遍历 project → folder → module，支持万级节点高效分页
基线管理	读取 / 创建 / 对比 Baseline，支持 A↔B 差分
ReqIF 导入导出	与 OEM / Tier1 之间交换需求的标准格式
报表导出	通过 Reportable REST 导出任意视图为 XML/CSV
追溯链接批量操作	Link Type 发现 + 批量创建 / 更新 / 删除
版本历史	单条需求的完整修订流水
文件夹管理	创建 / 移动 / 重命名 folder

对接拓扑

Rendering diagram…

典型工作流

Rendering diagram…

凭据与安全

支持 OAuth 2.0 / API Key / Basic Auth，由平台 Credential 层统一管理
凭据不写入 prompt / 日志 / ledger，审计日志只记录引用 ID
按租户隔离：不同客户、同一个客户下不同项目组，凭据完全隔离
最小权限原则：平台只需要目标 project/module 的读写权限，不要求全局管理员

私有化 vs SaaS 对接

场景	对接方式
客户 ALM 部署在内网	私有化部署 combo agent，同内网直连
客户 ALM 有公网入口	SaaS combo agent，白名单 IP
跨境数据敏感	混合部署：combo agent 本地化，只把脱敏元数据上云

常见场景

场景 1：需求基线差分

"上周冻结的基线 B23_01 和今天的 B23_02 之间有什么不同？哪些下游文档需要更新？"

Agent 自动：读取两个 baseline → 逐条差分 → 沿追溯链广播到下游 → 生成变更清单。

场景 2：追溯关系修复

"评估前一周发现有 300+ 条需求没有对应的架构链接。"

Agent 自动：批量扫描断链 → 按模块优先级排序 → 对每条提供候选链接建议 → 人工确认后批量回写。

场景 3：与 ReqIF 互通

"Tier1 要一份 ReqIF，把这个 module 导出来。"

Agent 自动：调用 ReqIF 导出工具 → 按目标 Tier1 的属性映射表转换 → 输出标准 ReqIF 文件。

操作步骤

快速对照表

平台	主要协议	支持范围	操作入口
IBM DOORS Next (DNG)	OSLC RM 2.0 + Reportable REST	完整	👇 配置 DOORS Next
IBM DOORS 9 (Classic)	DXL + Excel/ReqIF	读写	👇 配置 DOORS 9
Siemens Polarion	REST	读写	👇 配置 Polarion
Jama Connect	REST	读为主	👇 配置 Jama
codeBeamer	REST	读写	按需
Jira（+ Xray / R4J）	REST	需求 / 任务	👇 配置 Jira
自研 / 内网	Base Adapter	按需定制	联系支持

凭据管理原则（通用）

所有凭据由平台 Credential 层集中管理，不写入 prompt / 日志 / ledger
按租户隔离，同一租户下按项目可再分组
支持 OAuth 2.0 / API Key / Basic Auth / 客户自定义 Header
凭据通过 Agent 会话内的 alm_bind_credential 工具按提示词激活；详见代码托管平台集成同款思路

配置 DOORS Next

1. 准备工作

让 DOORS 管理员开通 OSLC 访问 scope（read、write）
准备凭据：OAuth 2.0 或 Basic Auth 账号
记录：服务器 URL、project area 名、component 名

2. 在会话里激活

在专用会话中给出提示词，例：

帮我绑定 DOORS Next 凭据：
- URL: https://dng.example.com
- Project Area: ABZ-Lightcontrol
- Component: Functional Requirements
- 鉴权: Basic Auth

Agent 会通过 ask_user 工具收集账号 / Token，提交到 Credential 层加密存储，并执行连接测试，成功后显示"模块数 / 条目数"预览。

3. 日常操作（聊天触发）

拉取模块：

从 DNG-Production 把 `Functional Requirements` 模块同步过来。

基线对比：

把模块 A 的基线 B23_01 和 B23_02 对比一下。

批量回写链接：

这份追溯矩阵确认，把链接回写到 DOORS。先给 Dry-run。

ReqIF 导出：

把 `Functional Requirements` 模块导出 ReqIF，给 Tier1。

配置 DOORS 9

DOORS 9 没有原生 REST，走 DXL 脚本 + 中间件：

部署平台提供的 DXL 中间件到 DOORS 服务器（官方脚本包）
开放指定端口（默认 8443）给 combo agent 所在内网
在会话里以提示词激活 DOORS 9 Classic 连接

能力上与 DOORS Next 基本等价，但不支持实时增量 webhook，需要定时拉取。

配置 Polarion

1. 准备 REST Token

在 Polarion 里生成 Personal Access Token，scope 至少 project.read、workitem.write。

2. 激活

在会话里给出 URL + Token + Project，Agent 自动完成绑定。

3. 日常操作

与 DOORS Next 类似，指令如："从 Polarion 项目 ABZ_Control 同步所有 WorkItem"。

配置 Jama

Jama 主要支持读能力（批量读 Items / Relationships），写能力按接口可用性按需支持。

连接方式：OAuth 2.0 或 Basic Auth。

配置 Jira

适用场景

Jira 同时作为 需求管理（Story / Epic） + 任务追踪 + 缺陷管理。常见用法：

把 Story / Epic 作为"轻量级需求"导入，与代码 PR 做追溯
把代码审查 / 测试失败的缺陷单自动写回 Jira

激活

在会话内给出 URL + API Token + Project Key，Agent 完成绑定。

如果用 Xray 或 R4J 做需求管理，在提示词里注明插件类型，Agent 会调用对应专用 API。

常见问题

Q：同步一次万级需求模块要多久？ A：首次 10–30 分钟；之后走增量，变更几分钟内反映。

Q：凭据会被 Agent 发给 LLM 吗？ A：不会。凭据只在执行工具调用时由 Credential 层注入，prompt 里只引用 ID。

Q：OSLC 链接类型（Link Type）客户有自定义的，支持吗？ A：支持。在连接配置里映射"平台内部语义" ↔ "客户 Link Type"。