来自网络，侵删   

先完成，再完美  某东，某节

1.LLM 为什么有幻觉，如何减少 LLM 幻觉？

1.1

• 概率生成机制：LLM 本质是基于统计概率预测下一个 token，而非检索事实数据库。当训练数据中缺乏确切信息或模式模糊时，模型会“脑补”最可能的序列，导致事实性错误。

• 训练目标偏差：预训练和微调阶段通常奖励“流畅且看似合理”的回答，惩罚“我不知道”，迫使模型在不确定时强行生成内容。

• 上下文窗口限制：长文本中关键信息可能被遗忘或注意力分散，导致模型基于不完整信息推理。
• 数据噪声：训练数据本身包含的错误、矛盾或虚构内容被模型学习并内化。

1.2检索增强生成 (RAG)、思维链 (CoT）、负提示 (Negative Prompting) 与约束解码：在提示词中明确禁止编造，或在解码阶段限制输出空间（如仅允许从给定选项中选择）

2.模型效果怎么评估

• 自动化指标 (Automated Metrics)：

  • 传统 NLP 指标：BLEU, ROUGE (用于翻译/摘要)，Perplexity (困惑度，衡量语言建模能力)。

  • 语义相似度：BERTScore, Embedding Cosine Similarity。

  • 特定任务基准：MMLU (综合知识), GSM8K (数学推理), HumanEval (代码生成), HELM (综合评测)。

  • 幻觉检测指标：Factuality Score (如 Vectara HHEM), Self-Consistency Rate。

  • Agent 能力指标：任务成功率 (Success Rate), 步骤效率 (Step Efficiency)。

• 人工评估 (Human Evaluation)：

  • 维度：准确性 (Accuracy)、相关性 (Relevance)、流畅度 (Fluency)、安全性 (Safety)、有用性 (Helpfulness)。

  • 方法：Likert 量表打分、成对比较 (A/B Testing)、红队测试 (Red Teaming，专门寻找漏洞和有害输出)。

  • LLM-as-a-Judge：使用更强的模型（如 GPT-4/Claude 3）作为裁判来评估弱模型的输出，需校准偏差。

3.MCP底层协议是什么

MCP 的底层通信协议主要基于 JSON-RPC 2.0。

• 传输层 (Transport)：支持多种传输方式，最常见的是 Stdio (标准输入输出，用于本地进程间通信) 和 SSE (Server-Sent Events，用于远程 HTTP 流式通信)。

• 数据层 (Data Layer)：

  • 遵循 JSON-RPC 2.0 规范，定义了 request, response, notification 三种消息类型。

  • 核心原语：定义了 Tools (工具调用), Resources (资源读取), Prompts (预设提示词) 的标准 Schema。

  • 生命周期管理：包含初始化 (initialize)、能力协商、以及会话终止流程。

• 特点：无状态设计（依赖上下文传递）、双向通信（服务器可主动推送通知）、强调权限分离和用户确认机制。

4.skill本质

在 AI Agent 语境下，Skills (技能) 的本质是 结构化、可调用的功能单元 (Structured, Callable Functional Units)。

• 封装性：它将复杂的底层操作（如 API 调用、代码执行、数据库查询、工具使用）封装成一个模型可理解的接口（通常包含名称、描述、参数 Schema）。

• 映射桥梁：它是 LLM 的“意图”与现实世界“行动”之间的桥梁。LLM 输出自然语言指令，通过 Function Calling 机制映射到具体的 Skill 执行。

• 动态扩展：Skills 使得模型能力不再局限于训练数据，而是可以通过加载新的 Skill 插件无限扩展（即“模型即操作系统，Skill 即应用”）。

• 标准化协议：在 MCP 等协议中，Skill 对应于 Tool 原语，遵循统一的发现 (list) 和调用 (call) 规范。

5.如何设计一个AI IDE（结合MCP ACP）

1. 架构分层：

   • UI 层：提供沉浸式对话、行内建议 (Ghost Text)、可视化依赖图。

   • 编排层 (Orchestrator)：负责任务拆解、路由（决定调用哪个 Skill/MCP Server）、并发控制。

   • 协议层：

     • 集成 MCP Client：统一连接各类工具（调试器、终端、外部 API、知识库）。

     • 实现 ACP (Agent Communication Protocol) 或类似标准：处理多 Agent 间的协作与状态同步（如果涉及多智能体）。

   • 上下文引擎：维护代码库的向量索引 + 符号表 (Symbol Table)，实现毫秒级检索。

2. 核心工作流：

   • 用户指令 -> 意图识别 -> 锁定当前代码快照 -> 检索相关上下文 -> 调用 MCP Tools (如运行测试、查阅文档) -> 生成代码 Plan -> 二次校验文件状态 -> 应用 Diff -> 自动运行 Linter/Test -> 反馈结果。

3. 安全与信任：

   • 所有高危操作（如删除文件、执行 Shell）必须经过用户显式确认（MCP 的用户监督机制）。

   • 提供“撤销栈”和“时间旅行”功能，随时回滚到 AI 介入前的状态。

3.agent的编排是怎么做的，运用到了什么样的模式呢，如何调度的？

核心模式：

• 中心化编排 (Centralized Orchestrator)：一个“主脑”Agent（Planner/Manager）负责拆解任务、分配子任务给专用 Agent（如 coder, tester, researcher），并汇总结果。适合复杂、多步骤任务。

  • 代表框架：AutoGen (Group Chat), LangGraph (State Graph)。

• 去中心化协作 (Decentralized/Swarm)：多个 Agent 基于共享状态或消息总线自主交互，通过预设规则或协商机制完成任务，无单一控制点。适合动态、开放环境。

  • 代表概念：Swarm Intelligence, Peer-to-Peer Agent Networks。

• 工作流引擎 (Workflow Engine)：将任务定义为有向无环图 (DAG)，节点是 Agent 或工具，边是数据流。执行引擎按拓扑顺序调度。适合确定性高、流程固定的场景。

  • 代表技术：LangChain Expression Language (LCEL), Prefect/Airflow for AI。

调度策略：

• 基于意图路由 (Intent-based Routing)：根据用户请求的语义，动态选择最合适的 Agent 或工具链。

• 基于能力注册 (Capability Registry)：维护一个所有可用 Agent/Tool 的能力描述库，编排器根据任务需求查询并调用。

• 动态优先级队列：根据任务紧急度、依赖关系和资源占用情况，动态调整执行顺序。

• 反馈闭环调度：子 Agent 执行失败或返回不确定结果时，触发重试、切换策略或上报主 Agent 决策。

4.你说的混合记忆架构，短期记忆，长期记忆记忆槽位是如何做的呢？里面用的什么数据结构，存的具体是什么数据。

• 短期记忆 (Short-Term Memory, STM)：

  • 实现：通常直接利用 LLM 的 Context Window。

  • 数据结构：线性列表或滑动窗口，存储最近 N 轮对话的 [{role: "user", content: "..."}, {role: "assistant", content: "..."}]。

  • 内容：当前会话的即时上下文、临时变量、未完成的思维链。

  • 优化：使用 摘要压缩 (Summarization) 或 关键信息提取 来延长有效上下文。

• 长期记忆 (Long-Term Memory, LTM)：

  • 实现：外部存储系统（向量数据库 + 关系型/图数据库）。

  • 数据结构：

    • 向量索引 (Vector Index)：用于语义检索（如 FAISS, Milvus, Pinecone）。存储 Embedding 向量。

    • 键值对/文档存储 (Key-Value/Document Store)：用于精确查找（如 Redis, MongoDB）。存储结构化事实。

    • 图结构 (Graph Structure)：用于存储实体关系（如 Neo4j）。

  • 内容：用户偏好、历史任务总结、领域知识库、代码库符号表、过往错误日志。

• 记忆槽位 (Memory Slots)：

  • 本质：一种结构化的记忆单元，类似编程中的“变量”或“对象属性”。

  • 实现：在 LTM 中定义特定的 Schema（如 UserPreference, ProjectStatus, SkillProfile）。

  • 操作：支持 Read Slot, Write Slot, Update Slot, Delete Slot。Agent 可以显式地更新某个槽位（例如：Slot["current_language"] = "Python"），以便在后续对话中快速读取，无需重新推理。

5.那数据库存储和rag是咋做的？

• 向量库：存 Embedding 和原始文本块（用于 RAG）。

• 关系型/NoSQL 库：存结构化数据（用户信息、任务状态、配置、记忆槽位）。

• 图数据库：存实体关系（用于复杂推理和多跳检索）。

• 缓存层 (Redis)：存高频访问的检索结果、会话状态、API 响应，减少延迟和 Token 消耗。

6.项目有什么问题么，遇到过比较难的问题？

(注：此处基于通用 AI 工程实践总结常见难点)

• 幻觉与事实一致性：即使有 RAG，模型仍可能忽略检索内容或过度推断。难点：如何在保持回答流畅性的同时，强制模型严格遵循检索事实？

• 长上下文的“迷失中间” (Lost in the Middle)：当上下文极长时，模型对中间信息的注意力下降。难点：如何设计更高效的上下文压缩和摘要策略？

• 工具调用的准确性：模型可能选错工具、参数构造错误或无法处理复杂依赖。难点：如何通过 Few-shot 示例、Schema 约束或验证循环提高准确率？

• 状态管理与并发：多 Agent 协作时，共享状态易冲突，任务执行顺序难以协调。难点：设计鲁棒的锁机制和事务模型。

• 评估困难：自动化指标难以全面反映 Agent 的真实能力（尤其是复杂任务的成功率）。难点：构建高质量的基准测试集和自动化评估流水线。

6.1.讲到token消耗，和mcp类似的上下文协议占用token的问题，以及如何减少这样的消耗呢？

• 按需加载 (On-Demand Loading)：不一次性加载所有 Tools/Resources。仅在用户意图明确或 Agent 规划到某一步时，动态加载相关子集。

• 渐进式披露 (Progressive Disclosure)：先提供工具的简要描述（名称 + 一句话功能），当 Agent 决定调用时，再获取详细参数 Schema。

• 摘要与缓存 (Summarization & Caching)：

  • 对长对话历史进行定期摘要，只保留核心事实和结论。

  • 缓存常用工具的 Embedding 和描述，避免重复传输。

  • 使用 差分更新 (Diff Update)：仅传输上下文的变化部分，而非全量重传。

• 小模型路由：用低成本小模型做意图识别和上下文筛选，只有复杂任务才调用大模型并携带完整上下文。

6.2.子agent在动态分配的过程当中如何做呢，通过什么技术来实现一种调度和分配，如何提高子agent的执行任务和工具调用的准确率。

动态分配技术：

• 基于能力的路由表 (Capability Routing Table)：维护一个 {Task_Type: [Agent_List]} 的映射，根据任务标签动态选择。
• 强化学习 (RL) 调度器：训练一个轻量级 RL 模型，根据历史成功率、延迟、成本等指标，学习最优的 Agent 分配策略。
• 竞价机制 (Auction Mechanism)：子 Agent 根据自身负载和能力对任务进行“投标”，主 Agent 选择最优者。

7.图数据库引入解决了什么样的问题？给我讲讲。

• 多跳推理 (Multi-hop Reasoning)：传统向量检索擅长找“相似”，但不擅长找“关系”。图数据库能轻松处理“A 的朋友的同事是谁？”这类多步关联查询。

• 结构化知识表示：将非结构化文本中的实体（人、地点、代码类、函数）及其关系（继承、调用、依赖）显式建模，形成知识图谱。

• 消除歧义与上下文增强：通过实体链接 (Entity Linking)，区分同名不同义的实体（如“Apple”是公司还是水果），提供更精准的上下文给 LLM。

• 可解释性：推理路径可视化。用户可以清楚看到 AI 是基于哪条关系链得出的结论，便于调试和信任建立。

• 动态更新与一致性：当代码库或知识库变更时，只需更新图中的节点和边，无需重新向量化整个文档，保证知识的实时性和一致性。