320 lines
14 KiB
Markdown
320 lines
14 KiB
Markdown
# 百瑞互联 AI 智能体建设方案
|
||
|
||
> 面向：深圳百瑞互联技术有限公司管理层
|
||
> 目的：基于公司现有研发知识库问答能力，提出下一阶段「智能体（Agent）」建设方向、优先场景与推进路径，供内部决策参考。
|
||
> 说明：本文为方案建议，不涉及商务报价；具体范围、节奏与投入需结合贵司确认后细化。
|
||
|
||
---
|
||
|
||
## 一、背景与判断
|
||
|
||
百瑞互联是短距离无线通信领域的芯片、模组、协议栈与方案提供商，业务覆盖物联网、音频、汽车电子等场景，并深度参与蓝牙技术生态。日常工作高度依赖芯片手册、协议规范、认证材料、应用笔记与历史项目经验。
|
||
|
||
贵司已建设并投入使用 **研发知识库 AI 问答系统**。该系统解决的是第一层问题：
|
||
|
||
- 资料能问、答案有出处、可按权限隔离；
|
||
- 支持内部文档与外部蓝牙权威知识源（如 Amber）统一入口；
|
||
- 具备企业管理、密级授权、审计与可运营能力。
|
||
|
||
下一阶段引入「智能体」，不是再做一个聊天窗口，而是把现有知识能力 **按岗位、按流程做深**：从「能问答」升级为「能协助办事」。
|
||
|
||
**核心判断：**
|
||
|
||
1. 百瑞最适合的不是全员一个万能助手，而是围绕研发与交付链路的 **垂直智能体**。
|
||
2. 芯片、协议、认证类回答必须 **可核对、可追溯、人在回路**，不宜让智能体对外自动承诺技术参数或商务条件。
|
||
3. 现有知识库是最好的底座。优先复用、扩展岗位场景，再逐步连接工单、测试、CRM 等系统。
|
||
|
||
---
|
||
|
||
## 二、建设目标
|
||
|
||
建议将智能体建设目标定义为三句话：
|
||
|
||
1. **让一线少被打断**：研发、FAE、认证人员把重复问答、材料整理、初判工作交给助手。
|
||
2. **让答案可进业务**：不仅能查资料，还能生成排查清单、回复草稿、齐套检查结果，经人工确认后使用。
|
||
3. **让知识持续沉淀**：把客户问题、项目经验、认证与测试结论回流进知识库，形成越用越准的闭环。
|
||
|
||
建议用 6–12 个月看到可量化结果，而不是一次性铺开所有部门。
|
||
|
||
| 周期 | 建议目标 |
|
||
|---|---|
|
||
| 近 3 个月 | 在 2–3 个高价值岗位上线垂直助手，形成可演示、可统计的使用闭环 |
|
||
| 3–6 个月 | 覆盖认证/测试与售前选型，补齐「人审后发出」的流程能力 |
|
||
| 6–12 个月 | 按需对接工单/CRM/测试系统，形成流程型与分析型智能体 |
|
||
|
||
---
|
||
|
||
## 三、总体原则
|
||
|
||
1. **窄而深，不求全能**
|
||
先做 FAE、研发、认证等高频场景，不做「什么都能聊」的通用机器人。
|
||
|
||
2. **有出处，才进业务**
|
||
涉及电气参数、协议条款、认证结论，必须带来源；找不到就明确说找不到。
|
||
|
||
3. **人在回路，先辅助后自动**
|
||
第一阶段只做检索、起草、检查、推荐；不自动对客发送、不自动改代码合入、不自动承诺交期与价格。
|
||
|
||
4. **权限与保密先行**
|
||
沿用现有密级、目录授权、出站脱敏与审计能力；智能体不得突破员工本人可见范围。
|
||
|
||
5. **一个底座，多岗位入口**
|
||
共用知识库、模型与权限体系；按岗位配置知识范围、提示词、工具权限与审核强度。
|
||
|
||
---
|
||
|
||
## 四、适合建设智能体的部门与岗位
|
||
|
||
### 4.1 优先建设（P0）
|
||
|
||
#### （1）FAE / 应用工程 / 技术支持
|
||
|
||
这是芯片公司最典型的「人肉知识路由器」。客户与内部同事高频询问选型、引脚、功耗、连接异常、认证注意点、示例工程用法，大量答案已在文档和历史案例中，但查找成本高。
|
||
|
||
**建议能力：**
|
||
- 基于手册、应用笔记、FAQ、历史案例进行带出处问答；
|
||
- 按故障现象给出排查清单（连接失败、功耗偏高、音频断续等）；
|
||
- 生成对内/对客回复草稿，由工程师确认后发出；
|
||
- 召回相似历史问题及解决路径。
|
||
|
||
**预期价值：** 缩短一线响应时间，减少资深工程师被重复打断。
|
||
|
||
#### （2）研发（芯片 / 固件 / 协议栈 / 驱动 / SDK）
|
||
|
||
研发资料专业、更新快、图表多，新人上手慢，老人重复答问多。现有知识库能力与该岗位最贴合。
|
||
|
||
**建议能力：**
|
||
- 规格书、寄存器、协议、errata、SDK 示例的高精度问答；
|
||
- 版本变更与已知问题影响面提示（必须附出处）；
|
||
- 设计/自测检查清单辅助（不替代评审拍板）；
|
||
- 根据需求或规格生成测试用例大纲草稿。
|
||
|
||
**预期价值：** 提升研发自助查询效率，降低跨组反复请教成本。
|
||
|
||
### 4.2 第二批建设（P1）
|
||
|
||
#### （3）认证 / 测试 / 质量
|
||
|
||
蓝牙认证、一致性测试、问题复盘材料多、检查项多、流程长，非常适合「清单型 + 对照型」智能体。
|
||
|
||
**建议能力：**
|
||
- 认证材料齐套检查与缺件提示；
|
||
- 功能/问题与规范条款对照；
|
||
- 测试失败日志的常见根因初分；
|
||
- 质量问题报告（如复盘/8D）结构草稿；
|
||
- 变更后的回归测试范围建议。
|
||
|
||
**预期价值：** 压缩认证与质量闭环中的文书和检索时间。
|
||
|
||
#### （4）售前 / 产品 / 解决方案
|
||
|
||
选型、方案拼装、标书应答高度依赖产品能力矩阵和历史项目经验。
|
||
|
||
**建议能力：**
|
||
- 按应用场景（音频、车载、物联网、Mesh 等）给出候选芯片/模组及依据；
|
||
- 生成方案说明、参数对比表、应答材料草稿（基于已过审内容）；
|
||
- 对「该需求能否支持」做初判，并列出限制条件。
|
||
|
||
**边界：** 对外承诺、定制可行性结论、价格与交期必须人工确认。
|
||
|
||
### 4.3 后续扩展（P2）
|
||
|
||
| 部门 | 可做场景 | 不宜一上来就做 |
|
||
|---|---|---|
|
||
| 销售 | 会议纪要提炼、跟进邮件草稿、内部查询某客户历史料号与已知问题 | 无人值守报价、自动商务承诺 |
|
||
| 市场 / 开发者运营 | Release Note、迁移指南、FAQ、技术内容初稿 | 未审核参数直接对外发布 |
|
||
| 计划 / 供应链 / 制造协同 | PCN 影响说明草稿、异常经验检索 | 在主数据不完整时做自动排产/承诺交期 |
|
||
| HR / 行政 | 制度、入职、培训材料问答 | 作为公司 AI 建设的第一优先级 |
|
||
|
||
### 4.4 明确不建议由智能体自动执行的事项
|
||
|
||
- 对外自动答复并承诺芯片参数、认证结论、交期、价格；
|
||
- 自动修改并合入生产固件 / 协议栈代码；
|
||
- 替代架构评审与技术拍板；
|
||
- 突破密级与目录权限去检索或汇总高敏感资料。
|
||
|
||
---
|
||
|
||
## 五、推荐的智能体形态
|
||
|
||
建议采用「一个平台底座 + 若干岗位智能体」，而不是为每个部门单独做一套系统。
|
||
|
||
```text
|
||
┌─────────────┐
|
||
│ 员工入口 │
|
||
│ 问答 / 企微 │
|
||
└──────┬──────┘
|
||
│
|
||
┌────────────────┼────────────────┐
|
||
▼ ▼ ▼
|
||
FAE 助手 研发助手 认证/测试助手
|
||
售前助手 （后续）销售/市场/供应链助手
|
||
│ │ │
|
||
└────────────────┼────────────────┘
|
||
▼
|
||
统一底座：知识库 + 权限密级 + 模型 + 审计
|
||
│
|
||
逐步连接：工单 / CRM / 测试平台 / 物料主数据
|
||
```
|
||
|
||
按能力成熟度分三层推进：
|
||
|
||
| 层级 | 形态 | 说明 | 阶段 |
|
||
|---|---|---|---|
|
||
| L1 知识型 | 岗位问答助手 | 带出处检索与回答，复用现有知识库 | 立即启动 |
|
||
| L2 助手型 | 起草与检查 | 回复草稿、排查清单、材料齐套、纪要待办 | 3 个月内 |
|
||
| L3 流程型 | 系统协同 | 创建/更新工单、拉取测试结果、同步客户项目信息 | 数据接口具备后 |
|
||
|
||
对管理层而言：先把 L1/L2 做扎实，比急着上「全自动流程机器人」更安全、也更快见效。
|
||
|
||
---
|
||
|
||
## 六、P0 场景建议（可直接作为试点范围）
|
||
|
||
以下 6 个场景建议作为第一期试点，均满足「高频、可核对、能统计、风险可控」。
|
||
|
||
### 场景 1：研发知识问答（内部自助）
|
||
|
||
- **使用人：** 芯片、固件、协议栈、SDK 工程师
|
||
- **输入：** 自然语言问题（型号、寄存器、协议条款、配置项等）
|
||
- **输出：** 带文档名/页码/原文片段的回答
|
||
- **人工：** 关键参数引用前由工程师自行核对
|
||
- **成功标准：** 自助解决率提升，跨组重复答问下降
|
||
|
||
### 场景 2：FAE 一线应答助手
|
||
|
||
- **使用人：** FAE / 技术支持
|
||
- **输入：** 客户问题、现象描述、型号信息
|
||
- **输出：** 可能原因、资料出处、回复草稿、是否需升级研发
|
||
- **人工：** 对外发送前必须确认
|
||
- **成功标准：** 首响时间缩短，草稿采用率可统计
|
||
|
||
### 场景 3：故障排查清单
|
||
|
||
- **使用人：** FAE、测试、部分研发
|
||
- **输入：** 故障现象 + 产品型号/应用场景
|
||
- **输出：** 分步排查项、所需日志/仪器、常见误区
|
||
- **人工：** 按清单执行，结果可回写知识库
|
||
- **成功标准：** 同类问题平均处理时长下降
|
||
|
||
### 场景 4：历史案例召回
|
||
|
||
- **使用人：** FAE、质量、研发
|
||
- **输入：** 当前问题描述
|
||
- **输出：** 相似历史案例、处理结论、关联文档
|
||
- **人工：** 判断是否复用，避免错误迁移
|
||
- **成功标准：** 「重复踩坑」明显减少
|
||
|
||
### 场景 5：认证材料齐套与条款对照
|
||
|
||
- **使用人：** 认证、质量、项目经理
|
||
- **输入：** 产品/项目、目标认证项
|
||
- **输出：** 材料清单、缺件、对应规范条款
|
||
- **人工：** 认证负责人确认后执行补件
|
||
- **成功标准：** 因材料缺失导致的延误减少
|
||
|
||
### 场景 6：售前选型初判（内部）
|
||
|
||
- **使用人：** 售前、产品、资深销售
|
||
- **输入：** 客户场景与关键约束（功耗、接口、音频、车规等）
|
||
- **输出：** 候选料号、依据、限制条件、需 FAE 确认的问题
|
||
- **人工：** 对外方案必须审核
|
||
- **成功标准：** 内部选型准备时间缩短，明显错选减少
|
||
|
||
---
|
||
|
||
## 七、实施路径
|
||
|
||
### 第一阶段（0–3 个月）：岗位助手试点
|
||
|
||
- 明确 2 个试点部门：建议 **FAE + 研发**；
|
||
- 梳理并补齐对应知识：手册、应用笔记、FAQ、errata、高频案例；
|
||
- 配置岗位助手（知识范围、拒答边界、必须出示出处）；
|
||
- 建立使用规范：对外内容一律人审；
|
||
- 统计：提问量、有来源回答占比、草稿采用率、未覆盖问题清单。
|
||
|
||
**阶段成果：** 领导可看到真实岗位在用，而不是一次性演示。
|
||
|
||
### 第二阶段（3–6 个月）：认证/售前扩展 + 助手型能力
|
||
|
||
- 上线认证齐套、条款对照、测试失败初分；
|
||
- 上线售前选型助手（仅内部）；
|
||
- 增加回复草稿、排查清单、会议纪要待办等 L2 能力；
|
||
- 把高频未覆盖问题转化为标准知识条目。
|
||
|
||
**阶段成果：** 从「会查」扩展到「会协助准备材料与回复」。
|
||
|
||
### 第三阶段（6–12 个月）：有选择地连接业务系统
|
||
|
||
- 评估工单、CRM、测试平台、物料/PCN 等系统接口；
|
||
- 上线「创建工单草稿、回写处理结论、拉取测试摘要」等流程能力；
|
||
- 视成熟度决定是否对内开放更多岗位（销售、市场、供应链）。
|
||
|
||
**阶段成果：** 智能体开始进入业务流程，而不仅停留在对话。
|
||
|
||
---
|
||
|
||
## 八、组织与运行机制建议
|
||
|
||
智能体要持续有效，不能只上线一个入口，建议明确三类角色：
|
||
|
||
| 角色 | 建议承担部门 | 职责 |
|
||
|---|---|---|
|
||
| 业务负责人 | 各试点部门主管 | 确定场景、验收是否真能减负 |
|
||
| 知识运营 | 研发支持 / FAE 骨干 / 质量文档接口人 | 补文档、标密级、回收高频问题 |
|
||
| 平台运营 | 信息化 / 现有系统实施团队 | 权限、模型、审计、效果统计 |
|
||
|
||
建议每月一次简短运营会，只看四件事：
|
||
|
||
1. 哪些问题反复出现但知识库没有；
|
||
2. 哪些回答被一线判定不准；
|
||
3. 哪些草稿真正被采用；
|
||
4. 下个月补哪些资料、关哪些高风险能力。
|
||
|
||
---
|
||
|
||
## 九、风险控制
|
||
|
||
| 风险 | 控制方式 |
|
||
|---|---|
|
||
| 技术参数幻觉 | 强制出示出处；无依据不给结论；关键对外答复人审 |
|
||
| 越权泄露 | 沿用现有密级 + 目录授权；智能体检索范围不超过用户权限 |
|
||
| 敏感信息出站 | 对外部大模型启用脱敏；核心场景可评估专有/内网模型 |
|
||
| 员工不会用 / 不愿用 | 嵌入现有问答与企微入口；先解决最痛的重复问题 |
|
||
| 期望过高 | 对外明确：智能体是助手，不是自动决策系统和自动客服总机 |
|
||
|
||
---
|
||
|
||
## 十、资源与配套（供评估，非报价）
|
||
|
||
第一期通常需要同时具备三类投入，缺一不可：
|
||
|
||
1. **知识准备：** 试点岗位的文档整理、目录与密级、FAQ/案例入库；
|
||
2. **平台能力：** 在现有问答系统上增加岗位配置、草稿/清单类输出、使用统计；
|
||
3. **业务时间：** FAE/研发骨干每周固定时间做验收与纠错，否则无法变准。
|
||
|
||
其中，**知识质量与一线纠错** 往往比模型本身更决定效果。
|
||
|
||
---
|
||
|
||
## 十一、建议决策事项
|
||
|
||
请领导层重点拍板以下事项：
|
||
|
||
1. **是否同意** 以现有研发知识库为底座推进智能体，而不是另起一套通用聊天系统；
|
||
2. **是否同意** 第一期只做 FAE + 研发两个岗位试点（认证/售前放第二期）；
|
||
3. **是否明确** 对外技术答复、商务承诺、代码合入必须人审，不允许全自动；
|
||
4. **指定** 一名业务负责人与一名知识运营接口人，保证试点有人用、有人改；
|
||
5. **确认** 3 个月后的验收口径：使用量、有来源占比、一线减负感受、未覆盖问题闭环。
|
||
|
||
---
|
||
|
||
## 十二、结语
|
||
|
||
百瑞引入智能体，最有价值的方向不是「让 AI 什么都会」，而是：
|
||
|
||
> 让芯片、协议、认证和客户支持链条上的专业人员，把重复查找、起草和初判交给助手，自己把时间留在判断、调试与对客户负责上。
|
||
|
||
现有知识库已经解决了「能问、有出处、可管控」。下一步按岗位做深，是投入产出比最高、风险最可控的路径。
|
||
|
||
如需进入立项，建议下一步仅做两件事：确定试点部门，梳理这批岗位最高频的 20 个真实问题作为验收集。 |