16 - 业务场景包装：研发团队「AI 知识增强层」#

公司背景#

中型技术公司，研发团队 80-150 人，多产品线并行。内部积累大量技术文档（架构设计文档、API 规范、排障手册、变更记录），分散在 Confluence、飞书文档、本地共享盘。开发者日常在 IDE 里写代码时，查文档需要切换浏览器 → 找 wiki → 翻半天。

核心矛盾#

开发者真正需要知识的时刻是写代码时，而不是坐在浏览器里主动”学习”时。

场景	传统方式	期望方式
调用内部 SDK 忘了参数	切浏览器 → 搜 wiki → 翻文档	IDE 内直接问，秒回带示例
排查线上问题	翻 runbook → 找历史 case → 问老员工	描述现象，Agent 自动关联历史案例+手册
评审别人代码不了解业务背景	找人问 / 翻 PRD	选中代码片段，AI 解释其业务上下文
新人接手模块	读一周代码 + 问三个人	对话式问”这个模块为什么这样设计”

为什么需要 Agentic RAG（而非简单 RAG）#

开发者真实问法	需要的 Agent 能力
”用户鉴权走的哪条链路，和旧版有什么区别”	对比型 → 自动分解子问题 + 多文档检索 + 对比组装
”生产环境 OOM 了怎么排查”	时效型 → 检索排障手册 + Web 搜最新 JVM 建议
”上次谁改过支付回调的超时配置”	记忆型 → 调用 Memory 回溯历史对话
”这个接口的 QPS 限制是多少”	精确型 → 关键词检索直接命中
”帮我梳理下订单模块的核心流程”	复杂型 → 多步检索 + 来源聚合 + 自省验证

简单 RAG 只能处理”精确型”，其余都需要 Agent 动态决策路由。

为什么需要 MCP#

MCP 是让知识库能力从”Web 对话框”走进开发者工具链的标准协议。

┌─────────────────────────────────────────────────┐
│  开发者工具生态                                    │
│                                                   │
│  Cursor / VS Code  ──┐                           │
│  JetBrains IDE     ──┼── MCP Client ──┐         │
│  自研 CLI 工具      ──┘               │         │
│                                        ▼         │
│                              ┌─────────────────┐ │
│                              │  DocMind MCP    │ │
│                              │  Server         │ │
│                              │                 │ │
│                              │  • doc_search   │ │
│                              │  • keyword_search│ │
│                              │  • web_search   │ │
│                              │  • recall_memory│ │
│                              │  • kb_meta      │ │
│                              └────────┬────────┘ │
│                                       │          │
│  Web 对话入口 ────── Agentic RAG ◄────┘          │
└─────────────────────────────────────────────────┘

plaintext

双入口设计#

Web 对话：复杂问题走完整 Agent 链路（路由 → 规划 → 多 Worker 并行 → 重排 → 自省）
MCP 工具调用：IDE 中的 AI 助手直接调用单个工具，轻量快速，外部 Agent 自行编排

内外调用的安全边界#

维度	内部（Web 对话）	外部（MCP 端点）
编排方式	DocMindAgent 全链路编排	外部 AI Agent 自行编排
kbIds 来源	会话上下文锁定，LLM 无法篡改	JWT 鉴权 + kbIds 归属校验
Memory 隔离	userId 从 session 注入	userId 从 auth context 注入，禁止外部指定
适用场景	复杂多步推理问题	IDE 内轻量单工具查询

面试关键表述#

一句话定位#

“我们发现开发者 80% 的知识需求发生在 IDE 里，而不是浏览器。所以除了 Web 端的完整对话体验，我通过 MCP 协议把检索能力标准化暴露，让 Cursor、VS Code Copilot 这类 AI 编程助手可以直接调用我们的内部知识库，把知识送到开发者手边。“

架构决策回答模板#

“内部调用和外部 MCP 调用共享同一套检索引擎，但安全边界不同：内部走 Agent 编排，kbIds 由会话上下文锁定；外部走 MCP 端点，需要 JWT 鉴权 + kbIds 归属校验，防止越权访问。“

为什么不用 LLM Function Calling 做工具选择#

“我们做过 A/B 对比：LLM function calling 在中文短 query 上工具选择准确率只有 78%，且延迟多 800ms。改成规则引擎（RetrievalPlanner）后准确率到 95%+，P99 延迟降到 50ms。Agent 的价值在路由和自省，不在工具选择这种确定性决策上。“

可量化业务成果#

指标	改善
开发者日均切换浏览器查文档次数	↓ 70%
线上问题平均定位时间	30min → 8min
新人首周独立提交代码率	40% → 85%
MCP 工具日均调用量	2000+，覆盖 3 个 IDE 客户端
语义缓存命中率	30%（高频问题免检索）

面试官常见追问 & 应答#

追问	应答要点
”MCP 有什么实际用？“	开发者主战场是 IDE，不把能力暴露出去就触达不到用户；MCP 是 Anthropic 提出的标准协议，Cursor/Claude Code 原生支持
”为什么不直接让 IDE 插件调 HTTP API？“	MCP 提供标准化工具描述（名称、参数 schema、描述），AI 助手无需定制对接代码即可自动发现并调用，降低集成成本
”Agentic 相比普通 RAG 贵多少？“	简单 query 被 MetaIntentDetector Tier-0 规则短路，不进入 Agent 链路（闲聊/寒暄/知识库元查询）；复杂 query 多一次 QueryUnderstanding LLM 调用 + 可选 Self-Reflection，成本增 30-50%，但答案质量提升显著
”Agent 会不会过度设计？“	用数据说话：对比型/时效型/记忆型问题占用户 query 的 45%，这些简单 RAG 根本答不好；剩余 55% 精确型走最短路径，Agent 不增加额外开销
”你一个人怎么做完的？“	核心链路我负责（Agent 编排 + 检索 + MCP），前端 1 人配合；基于 Spring AI 框架 + Milvus/Redis 等成熟组件，不是从零造轮子