先声明边界:这是一份设计提案,不是已上线功能。面试时讲成”如果给这套数据平台加 AI Agent,我会这么设计”,不是”我做过”。我接手过数据采集和采集需求两个模块,标定模块我只读过没动过手——但这不影响提案的合理性,因为提案的核心是复用我真正改过的那套车云链路基建。讲清楚”哪些是真实的基建、哪些是基于基建的设计”,这正是上一篇方法论讲的诚实边界。
前三篇讲方法论和单点深挖(一、二、三),车云链路那篇讲已有工程实现。这篇是收口——把”加 AI Agent”落到一个具体痛点上,设计一套能在面试里站得住的方案。
一、价值定位:为什么这个提案值钱
面试官见过的 AI 提案太多了,绝大多数长这样:“我们加个 Copilot,用户能对话,接 RAG 查文档,调用工具……”——空泛、什么都能套、看不出和具体业务的关系。
值钱的提案要同时满足四条:
- 落在真实业务痛点上:不是”找个地方用 AI”,是先有一个人工做起来很痛、AI 能省真金白银的点。
- 复用已有基建:不另起炉灶搭一套 agent 框架,而是把 AI 塞进已经跑通的工程基建(消息、锁、调度、车端链路)里——这证明你懂工程,不是只会调 LLM API。
- 全栈闭环:从前端入口到办公 IM 通知,一个请求穿过四环节回来,不是半截子 demo。
- 工程化护栏:白名单、只读、可观测、成本治理——证明你能在 LLM 的不确定性下交付靠谱系统,不是放任 AI 乱来。
这四条合起来,回答的就是面试官那句话:“在 LLM 的不确定性下,你依然能交付一个靠谱的系统。” 这正是第一篇《AI 全栈面试》方法论的落地。
二、选哪个 Agent 最有价值:标定失败归因
不是拍脑袋选的。候选我对比过四个:
| 候选 Agent | 痛点真实度 | 数据是否现成 | 决策可验证 | 误判代价 |
|---|---|---|---|---|
| 标定失败归因(选这个) | 高——每次失败要人查多系统,耗时数小时 | 高——结果库/原始数据/链路状态都在 | 高——归因可对照原始数据复核 | 低——只给建议不改数据 |
| 数据质检 Agent | 中——质检已有漏斗判定 | 高 | 中——质量标准部分主观 | 中——误判影响放行 |
| 标注预标注 Agent | 中——省人工 | 高 | 低——预标注质量难量化 | 中——要人工复核兜底 |
| 采集异常 Agent | 高 | 高 | 中 | 高——误触发车端动作 |
选标定失败归因的理由:痛点真实(标定失败后,工程师要分别去标定结果库、原始数据、车辆链路状态三处查,手动拼原因,一查就是几小时);数据现成(三处数据源都是系统已有的);误判代价低(只给归因建议,不写库、不触发车端动作)——这一点对工程化护栏最关键,Agent 输出错了不会造成生产事故,容许 LLM 的不确定性。
标定是什么:自动驾驶车辆的传感器(雷达、相机、激光雷达)要标定到车身坐标系,标定失败会让这辆车的感知数据不可用、整车数据进不了流程。失败原因很多——场地问题、靶标问题、传感器硬件问题、标定算法参数问题、原始数据质量问题——这正是需要”归因”而非”判定”的场景,适合 LLM 做多源信息汇总推理。
三、全栈四环节闭环
一个归因请求穿过四个环节回来:
工程师提问 ↓① 宿主助手(前端入口) 工程师在宿主应用的助手会话里问:"这次标定为什么失败" 意图校验:是归因意图 → 进编排;否则走通用助手 ↓② 子应用(数据子应用) 归因结果在数据子应用里展示,和点云预览/数据管线联动可视化 工程师能直接点进归因指向的那批原始数据看 ↓③ 后端 agent(归因编排器) 并发查三处数据源 → 汇总 → 调 LLM 归因 → 结构化输出 ↓④ 办公 IM(闭环) 结论推送到办公 IM 群,通知责任人 责任人在群里能直接看到结论 + 数据链接 ↑ 闭环:结论同时回到前端,工程师前端/IM 两处都能看这四环节不是新搭的——①②是已有前端,④是已有办公 IM 机器人,真正要写的只有③后端 agent 编排器。这也是”复用已有基建”的价值:全栈闭环听起来很大,实际增量代码集中在一个环节。
四、复用已有基建(逐项)
这是提案的硬核——每一块基建都是我已经改过或读过的真实工程,不是假设。
1. Kafka 长任务 + 看门狗(复用自车云链路篇)
车云链路那篇讲过:链路版的异步长任务有套状态机(CREATED→SENT→ACKED→RUNNING→SUCCESS)+ 看门狗兜底失联。Agent 调 LLM 也是异步长任务——LLM 慢、可能超时、可能卡。直接复用这套
优点:失联兜底机制现成,不用重写。代价:状态机对短任务有点重,归因通常几十秒,套长任务状态机略 over-engineering——但比起另写一套超时逻辑,复用更安全。
2. Redisson 分布式锁
同一辆车的同一次标定失败,可能被两个工程师同时问、或被定时巡检触发。用 Redisson 锁按”车辆+标定批次”加锁,防并发归因重复调 LLM、重复推送。
优点:防重复 + 省 token。代价:锁粒度要拿捏,太粗(锁整车)会阻塞不同批次,太细起不到防重作用——按”车辆+标定批次”刚好。
3. Hologres 查标定结果 + 原始数据质量
标定结果库和原始数据质量统计本来就在 Hologres 里(车云链路回传的数据进了 Hologres 分析)。Agent 直接查只读视图,不新建数据源、不改表。
优点:数据现成、查询能力强。代价
4. Argo 做 DAG 编排
归因是多步 DAG:并发查三处数据源 → 汇总 → LLM → 推送。Argo Workflows 编排这个 DAG,每步可重试、可观测、有状态。
优点
5. SSH/车端链路(可选)
如果归因要查车端传感器实时状态(比如确认某传感器是否离线),复用车云链路那套 SSH 版或链路版能力。但默认不走这条——链路状态已经有 Kafka 上行快照在云端,查快照就够,不为此主动连车端(降低误触发风险)。
优点:需要时能查到车端真实状态。代价:主动连车端有风险,默认只读快照,SSH 留作兜底。
五、工程化护栏
这是面试时区分”会用 AI”和”能交付靠谱 AI 系统”的分水岭。四道护栏,每道都有为什么 + 代价。
1. 工具白名单
Agent 能调的工具是固定白名单:三个只读查询 + 一个办公 IM 推送,仅此。LLM 不能”决定”调别的——工具集在编排器写死,LLM 只能在白名单里选。
为什么
2. 数据源只读
三个数据源查询全部走只读数据库账号,Agent 拿不到任何写权限。LLM 输出结构化 JSON(归因 + 置信度 + 建议),由编排器决定推送,LLM 不能直接写库或发消息。
为什么:防 LLM 幻觉改数据、防 prompt 注入让 agent 干越权的事。只读是最后兜底。
代价
3. 可观测(trace + token 埋点)
每次 agent 调用复用现有链路追踪(Sleuth),和普通请求同 trace 体系,能从前端 trace ID 一路追到 LLM 调用。token 用量埋点到现有监控。
为什么:出问题能定位是哪步、哪次 LLM 调用抽风。不和业务 trace 体系割裂。
代价
4. 成本治理(token 预算 + 缓存)
单次归因设 token 预算上限,超预算熔断返回”归因超时,请人工”。相同标定失败的归因结论缓存(标定批次号做 key),不重复调 LLM。
为什么:防一个归因请求烧掉大量 token、防重复归因空烧。LLM 调用是按 token 花钱的,不治理会失控。 代价:缓存失效策略要想清楚——标定批次重跑后旧归因失效,要按批次状态失效缓存,否则给过时建议。
六、架构图
点任一环节,看它的职责、复用哪块基建、工程化护栏。绿色虚线是办公 IM 闭环——结论推送到群里并回到前端。
七、面试怎么答这道题
「我会先选一个痛点真实、误判代价低的点——标定失败归因。标定失败后工程师要查标定结果库、原始数据质量、车辆链路状态三处,手动拼原因,一查几小时。这三处数据系统里都有,Agent 并发查完调 LLM 归因,结构化输出结论推办公 IM。
关键是我不另起炉灶搭 agent 框架——Agent 调 LLM 是异步长任务,直接复用我改过的那套车云链路状态机和看门狗兜底超时;并发防重用 Redisson 锁;数据查 Hologres 只读视图;DAG 编排用 Argo。真正要写的只有后端编排器一个环节,前端入口和办公 IM 都是已有的。
护栏四道:工具白名单(零写权限)、数据源只读、复用 Sleuth 做 trace、token 预算 + 缓存治理成本。这样 LLM 出错也不会造成生产事故——它只给建议,不改数据不触发车端。」
三个能加分的追问点
- “为什么不选预标注 Agent?” → 预标注质量难量化、误判要人工复核兜底、且会和已有标注流程耦合;标定归因误判代价低(只给建议不改数据),更适合作为 AI 落地的第一个点。
- “Agent 复用状态机不重吗?” → 对交互式归因确实偏重,所以交互式退化为代码内编排,Argo + 状态机留给定时巡检式归因。这是诚实取舍,不是硬套。
- “缓存归因结论不怕过时吗?” → 按标定批次状态失效缓存——批次重跑后旧归因自动失效。不做全局 TTL,因为”时间过没过”不等于”数据变没变”。
八、这套提案的格局
回到开头的价值定位——这套提案的含金量不在”加了个 AI 功能”,在把 AI 落在真实痛点 + 复用已有基建 + 全栈闭环 + 工程化护栏。面试官要的就是这个:证明你能在 LLM 的不确定性下,依然交付一个靠谱的系统。
这和第一篇方法论、车云链路那篇的工程实现,组成一个完整故事:方法论讲怎么答、车云链路讲已有的工程基建、这篇讲怎么把 AI 落在那套基建上。三篇合起来,就是一个有纵深的全栈工程师画像。