研发全链路智能体：三层架构与制品追溯链
最近在做一个方案：把智能体铺到汽车座舱软件研发的全流程里，从需求到运营。写这篇不是讲方案细节，是讲画架构图时想明白的几件事。
先定阶段，再定智能体
一开始画的草图是按”数字员工”分组的：需求组、开发组、测试组、运营组，每组下面挂智能体。画完发现对不上研发流程——需求评审明明是需求阶段的事，却挂在开发组下面。
改成先定七个阶段（需求洞察、产品规划、架构设计、敏捷开发、持续集成、智能验证、发布运营），每个阶段一个数字员工，数字员工下面挂该阶段的智能体。分组依据从”谁来做”改成”哪个阶段”，图立刻顺了。
三层
解决方案层 工作台 · 七个阶段的数字员工 · 各阶段智能体
编排与能力层 多智能体编排（顺序 / 并行 / 循环）· 能力单元
基础层 模型网关 · 知识与数据 · 规范 · 合规 · 协同 · 治理三个概念划清楚：
- 数字员工是阶段级的编排单元，决定该阶段内智能体的顺序和循环条件。
- 智能体是单一职责的执行单元，不跨阶段。
- 能力单元是已有系统（文档解析、预审、用例生成……），按标准协议接入，自身不含编排逻辑。
第三条最重要：已有系统不改造，包一层协议就能被任意智能体调。公司这几年做的七八个系统，这样全部复用进来了。
制品追溯链
画到一半发现草图里只有控制流（谁调谁），没有数据流（什么东西从哪流到哪）。汽车软件研发有过程要求，核心是双向追溯：从需求能查到验证它的用例和结果，从缺陷能回溯到需求。
补了一张图：
需求条目 → 特性 → 架构元素 → 代码提交 → 构建产物 → 测试用例 → 测试结果 → 发布版本 → 运营反馈
▲ │
└──────────────────────── 派生新需求编号 ──────────────────────────────────────────┘每件制品带唯一编号，记录上游编号。追溯关系集中存在治理层，不依赖任何一个阶段的系统——因为阶段的系统会换，追溯数据不能跟着丢。
这张图画出来之后，整个方案的重心变了：智能体是手段，追溯链才是客户真正要的东西。
三态标注
方案里的东西，有的已经在跑，有的有底座正在定制，有的只是规划。对外材料如果混在一起写，客户问到就穿。
所以每个框标三种状态：已有、在建、规划。图上用实线、虚线、点线区分。对内文档全标，对外版本按目标态画但另附一张现状表。这条纪律是之前做产品介绍时吃过亏学来的。
引用的东西要核
方案早期引用了几个”可以作为底座”的项目。逐个看了代码之后：一个是代码评审工具不是需求评审，一个是测试平台但不含任何模型调用，一个只是论文索引仓根本没代码。都改了口径。
架构文档里引用的每个东西，要么自己看过代码，要么标”待核实”。这条也是纪律。
一句话
给一个流程铺智能体，先想清楚流程的制品和追溯，再想智能体。智能体是替换的，制品链是留下的。