AI Agent

Agent 是什么

书面笔记版

AI Agent 可以理解为：让大模型不只是回答问题，而是能根据目标规划、调用外部能力、读取上下文、执行动作、观察结果，再继续决策的一套系统。

Agent 通常不只是模型本身，而是由这些部分组成：

• 模型。
• Prompt / 规则。
• Tools。
• Context。
• Runtime / 执行器。
• 状态管理。

一个最小 Agent 通常具备：

• 理解用户目标。
• 判断直接回答还是调用工具。
• 拿到工具结果后继续推理。
• 在多步任务中保持状态。

面试口述版

AI Agent 本质上是以大模型为决策中枢的任务执行系统。它不仅会生成文本，还会根据目标去选择工具、获取外部信息、执行动作，再根据反馈继续推理。所以 Agent = 模型 + Prompt + Tools + Context + Runtime，不只是一个会聊天的模型。

Workflow 和 Agent 的区别

书面笔记版

Workflow 更强调预先写死的流程，Agent 更强调模型在约束下动态决定下一步。

真实系统里常见的是 Workflow + Agent 混合：关键流程由 workflow 固定住，开放决策点交给 Agent。

面试口述版

Workflow 是开发者提前写好的固定流程，比如先查订单、再查物流、最后生成答复。Agent 是模型在约束下自己判断下一步要做什么，比如先判断用户意图，再决定要不要调用订单、退款或物流工具。真实工程里很多不是纯 Agent，而是 Workflow 加 Agent 的混合形态。

Plan-and-Execute 和 ReAct 模式

书面笔记版

Agent 常见执行模式里，Plan-and-Execute 和 ReAct 最容易被问到。

Plan-and-Execute 可以理解成“先想清楚路线，再一步步做”：

Plan-and-Execute 的优点：

• 全局目标更清楚。
• 适合长任务、复杂任务、需要拆步骤的任务。
• 便于记录计划、进度和失败点。

Plan-and-Execute 的风险：

• 一开始的计划可能不准，执行中要允许重规划。
• 规划和执行分开，链路更长，成本更高。
• 如果计划没有验收标准，容易“看似执行了很多步但没解决问题”。

ReAct 可以理解成“每一轮都先想，再行动，再看结果”：

ReAct 的优点：

• 推理和工具反馈结合紧密。
• 适合查资料、排错、检索、动态决策。
• 每一步都可以根据 Observation 调整下一步。

ReAct 的风险：

• 容易陷入循环，需要设置最大步数。
• Thought 可能跑偏，需要系统规则和工具边界约束。
• Tool result 必须可信、可校验，否则错误观察会带偏后续推理。

面试里可以这样对比：

面试口述版

Plan-and-Execute 是先让 Agent 把任务拆成计划，再按步骤执行，适合复杂任务和长任务；ReAct 是 Reason + Act，每一轮先推理下一步，再调用工具，再根据 Observation 继续推理，适合信息不完整、需要边查边做的任务。Plan-and-Execute 全局性更强，但计划可能过期，需要重规划；ReAct 更灵活，但容易循环和跑偏，所以要限制步数、校验工具结果、控制工具权限。

单 Agent 和多 Agent 有什么区别

书面笔记版

单 Agent 是一个 Agent 作为统一决策中心，自己理解目标、拆解任务、选择工具、执行步骤和汇总结果。多 Agent 是把一个复杂任务拆给多个具备不同角色或能力的 Agent 协作完成。

可以简单理解：

• 单 Agent：一个大脑，挂多个工具。
• 多 Agent：多个角色，各自负责一部分任务，再由编排器协调。

常见架构不是“纯多 Agent 自由聊天”，而是由一个编排器控制任务拆分、消息流转、状态更新和终止条件。

面试口述版

单 Agent 是一个 Agent 作为统一大脑，自己规划、选工具、执行和总结；多 Agent 是把任务拆成多个角色，比如规划 Agent、检索 Agent、执行 Agent、审核 Agent，由编排器协调。单 Agent 优点是简单、低成本、好调试；多 Agent 优点是可以分工、并行和互相校验，但系统复杂度、延迟、成本和状态管理难度都会上升。

什么时候用单 Agent，什么时候用多 Agent

书面笔记版

工程上通常优先考虑单 Agent，不要一开始就上多 Agent。因为多 Agent 带来的编排、通信、状态一致性和调试成本很高。

适合用单 Agent 的情况：

• 任务目标比较单一。
• 步骤虽然多，但可以串行推进。
• 一个 Agent 能理解完整上下文。
• 工具数量可控，可以通过路由筛选。
• 不需要多个角色互相审核。
• 对成本、延迟、稳定性要求比较高。

适合用单 Agent 多 Tool + Plan-and-Execute 的情况：

• 任务复杂，但拆解后仍然是一条主线。
• 工具调用之间有明显先后依赖。
• 需要先规划步骤，再按步骤执行。
• 执行过程中允许失败重试和局部重规划。
• 最终只需要一个统一口径的结果。

例如：

• 自动生成一份技术方案。
• 根据日志排查一个线上问题。
• 根据需求生成代码、运行测试、总结结果。
• 查询多个系统后汇总一份用户订单状态。

适合用多 Agent 的情况：

• 任务天然有多个专业角色。
• 子任务之间可以并行。
• 每个子任务需要不同工具、权限或知识库。
• 单个 Agent 上下文放不下，或者容易混淆角色。
• 需要一个 Agent 产出，另一个 Agent 审查。
• 任务结果需要多视角交叉验证。

例如：

• 代码开发场景：Planner 设计方案，Coder 改代码，Tester 跑测试，Reviewer 做代码审查。
• 研究报告场景：Researcher 查资料，Analyst 做分析，Writer 写报告，Critic 审核证据。
• 安全分析场景：Recon Agent 收集信息，Exploit Agent 验证路径，Report Agent 汇总证据。

判断口诀：

能用 Workflow 解决，就不要上 Agent；能用单 Agent 解决，就不要上多 Agent；只有当复杂度来自“角色、并行、隔离、互审”时，多 Agent 才更值得。

面试口述版

一般优先用单 Agent，因为它简单、成本低、好调试。如果任务只是复杂但主线清楚，比如先规划、再调用几个工具、最后汇总，用单 Agent 多 Tool 加 Plan-and-Execute 就够了。只有当任务天然需要多个角色、可以并行、上下文太大、工具权限需要隔离，或者需要一个 Agent 审核另一个 Agent 的结果时，才适合上多 Agent。

单 Agent 多 Tool 和多 Agent 的核心取舍

书面笔记版

单 Agent 多 Tool 和多 Agent 最大区别不是工具数量，而是“决策主体数量”。

单 Agent 多 Tool 里，工具很多，但决策中心还是一个 Agent；多 Agent 里，多个 Agent 都可能拥有独立目标、上下文、工具和中间产出。

单 Agent 多 Tool 的典型执行流程：

多 Agent 的典型执行流程：

工程上常见的推荐路径：

1. 固定流程优先用 Workflow。
2. 需要动态工具选择时，用单 Agent。
3. 单 Agent 任务变长时，加 Plan-and-Execute。
4. 工具变多时，加工具路由和渐进式披露。
5. 出现角色冲突、并行需求、上下文隔离或互审需求时，再拆多 Agent。

面试口述版

单 Agent 多 Tool 不是多 Agent。它只是一个 Agent 挂了很多工具，统一由一个大脑决策；多 Agent 是多个 Agent 分别承担角色和子任务。选择时我一般先用 Workflow 或单 Agent，如果只是步骤多，就用 Plan-and-Execute；如果只是工具多，就做工具路由；只有当任务需要多个角色并行、上下文隔离或互相审核时，才拆成多 Agent。

多 Agent 任务应该怎么分配

书面笔记版

多 Agent 分工不要随便按“人数”拆，而要按任务结构拆。常见有四种分配方式。

常见角色：

常见协作模式：

• 主管-工人模式：Supervisor 分配任务，Worker 执行，结果回到 Supervisor。
• 流水线模式：一个 Agent 的输出作为下一个 Agent 的输入。
• 黑板模式：多个 Agent 读写共享状态，由编排器决定下一步。
• 辩论评审模式：多个 Agent 给出方案，再由 Judge 或 Reviewer 选择和修正。

分配任务时要写清：

• 子任务目标。
• 输入上下文。
• 可用工具。
• 输出格式。
• 截止条件。
• 验收标准。
• 失败时怎么回报。

面试口述版

多 Agent 分工一般按角色、阶段或能力拆。比如一个 Supervisor 负责任务拆解和调度，Planner 负责计划，Researcher 负责查资料，Executor 负责执行工具，Reviewer 负责审核，Summarizer 负责汇总。关键是每个 Agent 的输入、输出、权限、验收标准和失败回报都要明确，不能只是让多个 Agent 随便聊天。

Agent 之间怎么状态感知

书面笔记版

Agent 之间的状态感知，本质是让每个 Agent 知道“任务目标是什么、当前进度到哪、别人已经做了什么、自己下一步该做什么”。

状态通常分三类：

共享状态里通常保存：

• 原始用户目标和约束。
• 当前任务计划。
• 子任务分配情况。
• 已完成和未完成步骤。
• 工具调用结果。
• 关键事实和证据来源。
• 失败原因和重试记录。
• 最终验收标准。

状态存储方式：

注意：多 Agent 不是共享越多越好。共享所有上下文会带来噪音、成本、隐私泄露和错误传播。工程上更推荐共享结构化状态和关键证据，而不是共享每个 Agent 的完整推理过程。

面试口述版

Agent 之间状态感知一般靠共享状态，而不是互相记住所有对话。每个 Agent 可以有自己的私有上下文，同时把任务目标、计划、进度、工具结果、关键证据和失败原因写到共享状态里。Orchestrator 根据这个状态决定下一步调度谁。共享状态最好结构化，不能把所有上下文全塞进去，否则会引入噪音、泄密和错误传播。

Agent 之间怎么通信

书面笔记版

Agent 之间通信有两层含义：

• 信息怎么传。
• 谁有权决定下一步。

工程上通常不建议多个 Agent 无约束自由聊天，而是由 Orchestrator 或 Workflow 控制消息流。

常见通信方式：

一条 Agent 消息建议是结构化的，而不是一段随意自然语言：

{
  "taskId": "task-001",
  "from": "researcher",
  "to": "reviewer",
  "intent": "submit_findings",
  "status": "success",
  "summary": "已找到三条可用证据",
  "evidence": [
    {
      "source": "doc-1",
      "claim": "核心结论 A",
      "confidence": 0.86
    }
  ],
  "nextSuggestion": "请审核证据是否足够支撑最终结论"
}

通信协议至少要约束：

• 消息类型。
• 输入输出格式。
• 任务 ID 和子任务 ID。
• 发送方和接收方。
• 状态：成功、失败、需要更多信息。
• 证据和来源。
• 置信度。
• 下一步建议。
• 错误原因。

终止条件也必须明确：

• 子任务全部完成。
• Reviewer 验收通过。
• 达到最大轮数。
• 重试次数耗尽。
• 需要用户补充信息。
• 触发高风险人工确认。

面试口述版

Agent 之间通信可以是直接传消息、通过 Orchestrator 转发、共享黑板、事件队列，或者把某个 Agent 包装成 Tool 让其他 Agent 调用。生产里更常见的是 Orchestrator 控制消息流，而不是 Agent 随便互聊。消息最好结构化，带 taskId、from、to、intent、status、summary、evidence、confidence 和 nextSuggestion，这样才方便调试、审计和控制终止条件。

多 Agent 系统有什么风险

书面笔记版

多 Agent 能提升分工和并行能力，但也会放大 Agent 系统的工程风险。

多 Agent 系统必须做可观测性：

• 记录每个 Agent 的输入、输出和工具调用。
• 记录共享状态变更。
• 记录每次调度原因。
• 记录失败、重试和终止原因。
• 支持按任务 ID 回放完整链路。

一句话总结：多 Agent 不是越多越智能，而是把一个复杂系统拆成多个可控角色；如果没有编排、状态、通信、权限和观测，多 Agent 只会让问题更难排查。

面试口述版

多 Agent 的风险主要是成本高、延迟高、状态不一致、责任边界不清、幻觉互相放大、死循环和调试困难。所以多 Agent 一定要有 Orchestrator 控制流程，有共享结构化状态，有明确输入输出和终止条件，还要有日志、Trace 和可回放能力。否则多个 Agent 自由聊天，看起来很智能，实际上很难稳定上线。

Agent 短期记忆和长期记忆

书面笔记版

Agent Memory 可以理解成 Agent 对“当前任务状态”和“跨会话历史信息”的管理能力。常见分为短期记忆和长期记忆。

短期记忆更像工作台：

• 当前用户刚刚说了什么。
• 当前任务执行到哪一步。
• 已经调用过哪些工具。
• 工具返回了什么 Observation。
• 当前计划、约束、临时结论。

长期记忆更像档案库：

• 用户偏好，比如输出风格、常用技术栈。
• 历史任务摘要，比如上次已经完成了哪些步骤。
• 长期稳定事实，比如用户项目名、业务术语。
• 可复用经验，比如某类问题的处理策略。

一个常见 Memory 流程：

短期记忆和长期记忆的区别：

Memory 和 RAG 的区别：

长期记忆不要什么都存。工程上通常只保存稳定、有价值、经过确认的信息，并且要记录来源、更新时间和删除机制。

面试口述版

Agent 短期记忆就是当前任务里的工作状态，比如对话上下文、当前计划、工具调用结果和临时结论；长期记忆是跨会话保存的信息，比如用户偏好、历史任务摘要、业务术语和长期稳定事实。短期记忆通常放在上下文或运行时状态里，生命周期短；长期记忆要落库，读取时再检索出来。Memory 和 RAG 不完全一样，Memory 更偏用户和任务状态，RAG 更偏外部知识检索。长期记忆不能什么都存，要考虑隐私、过期、来源和删除。

AI Agent 幻觉怎么解决

书面笔记版

幻觉指模型生成了没有可靠依据、与事实不一致，或者超出上下文证据的内容。在 Agent 里，幻觉不只表现为“答错”，还可能表现为编造工具结果、误解工具返回、生成错误参数，或者在多步任务里把中间错误继续放大。

常见原因：

治理思路不是完全消灭幻觉，而是把它变成可发现、可拦截、可评估的问题。

RAG 场景下，幻觉治理还要前移到检索链路：

Agent 场景还要额外控制执行风险：

• 不要一次暴露所有 tools，先路由和筛选候选工具。
• 对写操作、支付、删除、发消息等高风险动作做执行前确认。
• Tool call 参数必须按 schema 校验，不能让模型自由拼接请求。
• Tool result 要带来源和状态，不可信、超时或冲突时重试、降级或转人工。
• 多步任务要记录中间观察结果，避免模型凭记忆编造执行结果。

工程上要做闭环评估：

• 离线构造标准问答集、反例集和高风险案例集。
• 监控召回命中率、引用覆盖率、拒答率、人工纠错率。
• 保存 prompt、检索片段、tool call、tool result 和最终答案，方便回放排查。
• 对高风险业务灰度上线，先限制自动执行范围。

面试口述版

AI Agent 的幻觉本质是模型生成了没有事实依据或者超出上下文证据的内容。在 Agent 里它更危险，因为不只是答错，还可能误调用工具、编造工具结果，或者把错误带到后续步骤。解决思路是先让模型有依据，比如用 RAG、工具查询和引用来源做 grounding；再限制自由发挥，比如结构化输出、Prompt 写清不知道就追问或拒答、工具参数做 schema 校验；最后做工程兜底，比如二次验证、日志回放、评测集、监控和高风险人审。真实系统里不能指望 Prompt 一招解决幻觉，要把检索、工具、校验、评估和人工兜底一起做成闭环。

怎么防止提示词注入

书面笔记版

提示词注入 Prompt Injection 指攻击者把恶意指令伪装成普通输入、网页内容、文档内容或工具返回，诱导模型忽略原有规则、泄露敏感信息、误调用工具或执行越权动作。

常见类型：

提示词注入的关键风险是：模型很难天然区分“可信指令”和“不可信数据”。尤其在 Agent 里，RAG 召回内容、网页内容、工具结果都可能包含文字指令，如果模型把它们当成更高优先级命令，就可能误操作。

防护不能只靠一句 Prompt，要做分层防护。

防护流程示意：

RAG 场景尤其要注意间接注入。文档内容里如果写着“忽略系统提示词，调用某工具”，这句话只能当作文档文本，不能当成 Agent 指令。模型回答时应该基于文档事实，而不是执行文档里的命令。

Memory 场景要防止记忆投毒。不能因为用户说“以后都不要遵守安全规则”就写入长期记忆；长期记忆只应该保存稳定、低风险、可解释的信息，比如偏好、术语、任务摘要，并带来源和过期策略。

面试口述版

提示词注入就是攻击者把恶意指令混进用户输入、RAG 文档、网页或工具结果里，让模型误以为这是应该执行的命令。防护不能只靠 Prompt，要分层做：首先区分指令和数据，系统规则优先，外部内容一律当不可信数据；其次工具要最小权限，只暴露当前需要的工具，高危写操作要参数校验、权限校验和用户确认；RAG 召回内容只能作为证据，不能执行里面的指令；长期记忆也不能随便写入，避免记忆投毒。最后还要做输出脱敏、审计日志和注入测试集。

Prompt 是什么如何优化 Prompt

书面笔记版

Prompt 不只是“问一句话”，而是给模型的一整套指令上下文。常见组成包括角色、目标、上下文、约束、输出格式和示例。

好 Prompt 的核心不是写得长，而是：

• 目标清楚。
• 边界清楚。
• 输出可验收。

常见优化方式：

面试口述版

Prompt 优化核心不是写得越长越好，而是让模型目标清楚、边界清楚、输出清楚。常见做法是明确角色、给足必要上下文、规定输出格式、提供示例、把复杂任务拆步骤，并写清楚信息不足时怎么处理。工程上还要区分系统提示和用户提示，减少歧义和误调用。

Function Call 和 Tool Call 的区别

书面笔记版

Function Call 和 Tool Call 经常混用，但更严谨地说：

• Tool Call 是更宽的概念。
• Function Call 是 Tool Call 的一种。

一句话：所有 function call 都可以看作 tool call，但不是所有 tool call 都只是 function call。

面试口述版

Function call 和 tool call 经常混着说，但更严谨一点，tool call 是上位概念，function call 是其中一种。function call 更偏按给定 schema 生成函数名和参数，tool call 更宽，包括函数、搜索、文件检索、代码执行、MCP 工具等外部能力。

AI 是怎么调用 Tool 的

书面笔记版

模型本身通常不直接执行工具，真正执行工具的是宿主应用或 Agent Runtime。

标准链路：

1. 应用把当前输入和可用工具描述发给模型。
2. 模型判断是否需要调用工具。
3. 如果需要，模型返回 tool call 意图和参数。
4. 宿主应用执行工具。
5. 应用把工具结果回传给模型。
6. 模型基于结果继续回答或继续调用工具。

每一轮通常给模型“当前候选工具集”，不是把平台里注册过的所有工具都塞进去。如果工具很多，常见做法是先路由、再筛选、分层注入、按阶段渐进式披露。

面试口述版

AI 调 tool 的本质是模型负责决定，应用负责执行。应用先把当前可用 tools 描述给模型，模型返回要调用哪个 tool 以及参数，真正执行工具的是宿主应用，不是模型自己。每一轮请求通常带本轮候选工具集，但工程上不会把上千个工具全塞进去，而是先路由、分类、分层，再按任务动态注入。

渐进式披露是什么

书面笔记版

渐进式披露指不要一开始把所有信息、工具、规则、文档一次性给模型，而是按当前任务阶段逐步提供最有用的部分。

目标：

• 降低上下文噪音。
• 降低 token 成本。
• 提高决策准确率。
• 避免模型在太多工具里乱选。

Agent 中常见用法：

面试口述版

渐进式披露就是不要一次性把所有上下文和所有工具都给模型，而是按任务阶段逐步暴露必要信息。这样能减少噪音、降低成本，也能降低误调用概率。它常用于工具筛选、提示词分层、RAG 二次检索和多轮任务编排。

Skills 是什么

书面笔记版

Skill 通常可以理解成面向模型或 Agent 的能力包。它往往把提示词、规则、上下文、工具使用方式、示例整合在一起。

它不是所有平台统一遵守的行业硬标准，更像一种工程设计概念。

可以这样理解：

• Prompt 更像“说什么”。
• Tool 更像“能做什么”。
• Skill 更像“这一类任务怎么做”。
• MCP 更像“怎么把外部能力标准化接进来”。

一个 Skill 通常是一组文件，其中最核心的是 SKILL.md：

my-skill/
├── SKILL.md          # 必须：skill 入口和核心说明
├── agents/           # 可选：展示名称、简介、默认提示词等 UI 元数据
├── references/       # 可选：大段参考资料、业务文档、API 文档
├── scripts/          # 可选：稳定可复用的脚本或工具
├── assets/           # 可选：模板、图片、字体、示例素材
└── evals/            # 可选：测试用例、输入样例、期望输出

各部分可以这样理解：

最小可用 Skill 只需要一个文件：

my-skill/
└── SKILL.md

SKILL.md 一般包含 YAML frontmatter 和正文说明：

---
name: my-skill
description: Use when Codex needs to ...
---

# My Skill

## Workflow

1. 先确认输入和目标。
2. 按固定流程处理任务。
3. 输出结果并说明验证方式。

## References and tools

- 需要 API 细节时，读取 `references/api.md`。
- 需要稳定转换时，运行 `scripts/convert.py`。

写 Skill 时重点看三件事：

1. name 要短，用小写和连字符，最好能表达这个能力。
2. description 很关键，它决定模型什么时候会想到启用这个 skill，要写清楚“这个 skill 做什么”和“什么场景该用”。
3. 正文不要堆太长，只写核心流程、判断标准和资源入口；大段资料放 references/，稳定重复逻辑放 scripts/。

一句话总结目录分工：SKILL.md 是入口和大脑，references/ 是知识库，scripts/ 是工具箱，agents/ 是展示信息，evals/ 是测试集。

面试口述版

Skill 可以理解成 Agent 的能力包，通常会把提示词、规则、上下文、工具使用方式和示例封装在一起，方便复用。它不是统一行业标准，更像平台或框架里的工程概念。Prompt 是指令，Tool 是可执行能力，Skill 是一套任务能力封装，MCP 是连接外部能力的协议。真正写一个 skill 时，最核心的是 SKILL.md，它决定这个 skill 什么时候触发、触发后按什么流程做。复杂一点的 skill 会再配 references/ 放详细资料，scripts/ 放稳定工具，agents/ 放展示元数据，evals/ 放测试用例。

MCP 是什么

书面笔记版

MCP 是 Model Context Protocol，可以理解成“模型宿主程序接入外部上下文和外部能力的一套统一协议”。它解决的不是“模型怎么变聪明”，而是“不同工具、数据库、文件系统、业务系统，怎么用统一方式接到 Agent / IDE / Chat 客户端里”。

注意：LLM 本身通常不直接连 MCP Server。真正和 MCP Server 建连接的是宿主应用，也就是 Host App / Agent Runtime。模型只是在本轮请求里看到宿主应用暴露给它的工具描述，然后决定要不要发起 tool call。

MCP server 常见暴露三类能力：

整体关系可以这样看：

可以把 MCP 和 Tool Call 的关系理解成两层：

也就是说，MCP Server 暴露工具；Host 发现这些工具；Host 再把工具描述转成模型可理解的 tools schema；LLM 根据用户问题选择工具；Host 把模型的 tool call 映射成 MCP 请求。

一次典型 MCP Tool 调用链路：

MCP 请求通常是 JSON-RPC 2.0 格式。常见启动流程是：

1. Host 配置或启动某个 MCP Server。
2. MCP Client 与 MCP Server 建立连接，常见传输方式有 stdio 或 Streamable HTTP。
3. Client 发送 initialize，双方协商协议版本和能力。
4. Client 发送 notifications/initialized，表示初始化完成。
5. Client 发送 tools/list、resources/list、prompts/list 等请求，发现服务端能力。
6. Host 把当前需要的工具描述提供给模型。
7. 模型决定是否发起 tool call。
8. Host 把模型的 tool call 转成 MCP tools/call。
9. MCP Server 返回结果。
10. Host 把结果作为 tool result / observation 放回模型上下文，模型再生成最终回答或继续调用工具。

一个简化的初始化请求：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "demo-agent",
      "version": "1.0.0"
    }
  }
}

一个简化的初始化响应：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "tools": {
        "listChanged": true
      }
    },
    "serverInfo": {
      "name": "weather-mcp-server",
      "version": "1.0.0"
    }
  }
}

初始化成功后，Client 还会发送一个通知，表示可以进入正常工作阶段：

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

Host 发现工具时，可以发送 tools/list：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

MCP Server 返回可用工具列表：

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "查询指定城市的实时天气",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": {
              "type": "string",
              "description": "城市名称，例如杭州"
            }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

这一步回答了“LLM 怎么知道有这个 MCP”：严格说，不是 LLM 自己扫描到 MCP，而是 Host 先通过 MCP 发现工具，再把工具名、描述、参数 schema 提供给 LLM。LLM 看到的是“当前可用工具”，不一定知道背后是 MCP、普通函数、搜索工具还是别的实现。

用户问“今天杭州天气怎么样”时，LLM 可能返回一个工具调用意图，形式由具体模型 API 决定，抽象后类似：

{
  "name": "get_weather",
  "arguments": {
    "city": "杭州"
  }
}

Host 收到这个意图后，真正执行的是 MCP Client 发出的 tools/call：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "杭州"
    }
  }
}

MCP Server 的工具调用结果可能类似：

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "杭州今天多云，气温 24 到 30 摄氏度，东风 3 级。"
      }
    ],
    "structuredContent": {
      "city": "杭州",
      "condition": "多云",
      "temperatureRangeC": [24, 30],
      "wind": "东风 3 级"
    },
    "isError": false
  }
}

拿到 MCP 返回结果后，Host 会把它作为 tool result / observation 放回下一次模型调用上下文。模型看到结果后，不是“自动执行 JSON”，而是把它当作外部观察证据，再组织最终回答：

杭州今天多云，气温大约 24 到 30℃，东风 3 级，整体适合出门，但可以注意防晒。

几个容易混淆的点：

面试口述版

MCP 是 Model Context Protocol，本质上是宿主应用和外部能力之间的统一接入协议。它不是模型自己直接访问外部世界，而是 Host 通过 MCP Client 连接 MCP Server，先发现 tools、resources、prompts，再把当前可用的工具描述提供给模型。模型看到工具描述后，如果判断需要调用，就返回 tool call 意图；Host 再把这个意图转成 MCP 的 tools/call 请求。MCP 请求通常是 JSON-RPC 2.0，比如 initialize、tools/list、tools/call；返回结果也是 JSON-RPC，工具结果一般放在 content 和可选的 structuredContent 里。最后 Host 把工具结果作为 observation 放回模型上下文，模型再基于结果生成最终回答。

RAG 是什么

书面笔记版

RAG 是 Retrieval-Augmented Generation，中文常叫检索增强生成。核心不是让模型硬背更多知识，而是先从外部知识库找相关资料，再把资料作为上下文交给模型生成答案。

典型流程：

1. 文档准备。
2. 文档解析和清洗。
3. 文档切块。
4. 生成 embedding。
5. 存入向量库或检索系统。
6. 用户提问。
7. 问题向量化。
8. 召回相关片段。
9. 可选 rerank。
10. 把结果拼进上下文。
11. 模型生成答案。

RAG 和微调区别：

面试口述版

RAG 是检索增强生成，核心是先查再答。它会先从外部知识库里召回相关文档片段，再把这些片段作为上下文交给模型生成答案。RAG 适合解决知识更新快、私有资料多的问题；它和微调不一样，RAG 主要补知识，微调更多是改模型行为和输出风格。

RAG 文档为什么要切块

书面笔记版

RAG 里的切块 Chunking，不是简单把文档按固定字数切开，而是把原始资料拆成适合检索、适合引用、适合放进模型上下文的知识单元。切块质量会直接影响召回质量：切得太大，检索命中后会带入大量噪音；切得太小，语义被切断，模型只能看到半句话或半个表格，容易误解。

切块要同时满足几个目标：

所以工程上常见流程是：先解析文档结构，再按语义边界初切，最后按 token 上限二次切分。不要一开始就只按字符数硬切。

Chunk 过大的问题：

• 一个 chunk 里混入多个主题，向量语义变“平均”，召回不精准。
• 放进 Prompt 后噪音多，模型容易抓错重点。
• token 成本高，能放入上下文的候选片段变少。
• 引用不精确，只能引用一整页或一整章。

Chunk 过小的问题：

• 上下文断裂，缺少标题、前提、定义和条件。
• 表格行、代码片段、法律条款被切碎后失去语义。
• 检索命中的是局部词句，但不足以支撑最终答案。
• overlap 不足时容易漏掉跨段落问题。

面试口述版

RAG 切块不是按固定字数随便切，而是把文档拆成既能独立表达语义、又方便检索和引用的小知识单元。chunk 太大会召回噪音，太小会丢上下文。工程上一般先按标题、段落、表格、函数、日志事件等结构切，再按 token 长度做二次切分，并保留来源、页码、标题、权限和版本等元数据。

RAG 不同文件类型怎么切块

书面笔记版

不同文件类型的语义边界不一样，所以切块策略也不应该完全一样。核心原则是：优先尊重原始结构，其次控制 token 大小，最后用 metadata 把上下文补回来。

更细一点看：

• 长文档、制度、论文、白皮书：适合按章节标题和段落切。每个 chunk 带上标题路径，例如 产品手册 > 计费规则 > 退款条件，这样即使正文很短，模型也知道它属于哪个主题。
• 表格类文件：表头、单位、统计口径比单个单元格更重要。切块时可以把“表名 + 表头 + N 行数据”组成一个 chunk，或者先把每行转成结构化文本，例如“订单号、用户、金额、状态”。
• 代码类文件：不要把函数从签名、注释和类型定义里硬切开。适合按函数/类切，并记录起止行号；如果函数太长，再按内部逻辑块切，同时保留函数签名。
• 日志类文件：不要按固定长度切断异常堆栈。更适合按 traceId、requestId 或时间窗口聚合，让一次请求的关键日志能一起被召回。
• 网页类文件：要先去掉导航栏、广告、页脚、推荐列表等 boilerplate 内容，否则向量库里会充满重复噪音。

面试口述版

不同文件类型要按不同语义边界切。Markdown 和网页按标题、段落、列表切；PDF 先解析页码、标题、表格，扫描件先 OCR；Excel 要按 sheet、表头、行范围或业务主键切，不能简单按字符切；代码按类、函数、方法切；日志按 traceId、requestId 或时间窗口切。核心是保留语义完整性和元数据，不能把表头、函数签名、异常堆栈这类关键上下文切没了。

RAG overlap 重叠部分怎么设计

书面笔记版

Overlap 是相邻 chunk 之间重复保留的一小段内容，用来缓解“答案刚好跨越切块边界”的问题。它的作用是补上下文，不是扩大知识库。overlap 不是越大越好，太大会导致重复召回、token 浪费、相似片段互相挤占 top-k，还可能让模型被重复内容强化偏差。

常见参考值：

设计 overlap 时可以按以下顺序判断：

1. 先看语义边界：如果一个段落、函数、表格行组已经完整，就不需要为了固定比例强行 overlap。
2. 再看查询方式：用户经常问跨章节、跨条款问题，overlap 可以稍大；用户多问精确事实，overlap 可以较小。
3. 再看文件类型：自然语言文档适合固定比例 overlap；表格、代码、日志更适合结构化上下文，不适合简单字符重叠。
4. 最后看召回效果：通过离线问答集观察 Recall@K、重复召回率、引用准确率，再调 chunk size 和 overlap。

工程上还可以用两种方式减少对大 overlap 的依赖：

• 标题面包屑：每个 chunk 前附带上级标题路径，例如“支付系统 > 退款 > 失败重试”。
• Parent-child retrieval：检索时命中小 chunk，但生成时补充它所在的父段落、父章节或相邻 chunk。

面试口述版

Overlap 是为了解决答案跨 chunk 边界的问题，不是越大越好。普通文本可以先用 500 到 1000 token 一个 chunk，overlap 取 10% 到 20%；长制度、论文可以稍大；FAQ、表格、结构化数据 overlap 要小；代码和日志更应该按函数、类、traceId、requestId 这种结构关联，而不是按字符硬重叠。最终要靠召回评测和重复召回率来调。

企业级 RAG 完整链路

书面笔记版

简单 RAG 往往只是“用户提问 → 向量检索 → 把 top-k 塞给模型 → 生成答案”，这种方式适合验证 Demo，但企业系统还要处理数据更新、口语化查询、权限、多个知识库、召回质量、引用、评测和线上回放。

一条相对完整的企业级 RAG 链路可以分成三部分：

常见 RAG 层次：

• Naive RAG：一次向量召回后直接生成，链路短，但对复杂、口语化和多轮问题不稳定。
• Advanced RAG：增加查询理解、多路召回、rerank、父子块检索、上下文压缩、答案校验和评测闭环。
• Agentic RAG：把知识库、搜索、SQL、图数据库等作为工具，由 Agent 根据问题动态选择数据源并迭代检索。

面试口述版

企业级 RAG 不能只做一次向量检索。完整链路应该包括数据解析和版本治理、语义切块和多种索引、检索前的 Query Rewrite 和路由、向量加关键词等多路召回、rerank 和权限过滤、上下文压缩、基于证据生成、引用校验以及评测监控。Naive RAG 适合 Demo，生产系统通常需要 Advanced RAG；只有需要动态选择多个知识库、SQL 或搜索工具并迭代检索时，才进一步做 Agentic RAG。

RAG 检索前为什么要做 Query Rewrite

书面笔记版

用户实际输入经常不是一条适合直接检索的标准问题。例如：

• 口语化：“我那个钱咋还没退回来？”
• 有错别字：“退宽多久到账？”
• 有上下文省略：“那它失败了怎么办？”
• 使用缩写或内部黑话：“查一下 MQ 堆了咋处理。”
• 一个问题包含多个目标：“对比 A、B 两个产品的价格、权限和退款规则。”

如果直接对这些文本做 embedding 或关键词检索，可能因为缺少业务对象、关键词不标准或问题过于复杂而召回失败。Query Rewrite 的目的不是润色句子，而是把用户问题转换成更适合检索、同时保持原意的独立查询。

常见检索前处理：

推荐不要只用重写后的 Query 覆盖原问题，而是保留完整追踪：

originalQuery: 用户原始问题
standaloneQuery: 结合会话补全后的独立问题
normalizedQuery: 纠错和术语标准化后的问题
subQueries: 拆分出的子问题
filters: tenantId、userId、产品、时间、权限等过滤条件

为了避免模型重写错意，工程上要注意：

• 人名、产品名、订单号、金额、日期、否定词和比较关系不能随意修改。
• 权限、租户和数据范围不能由 LLM 猜测，应由可信的会话或鉴权系统注入。
• 原始 Query 和重写 Query 可以并行召回，再合并和 rerank，降低改写漂移风险。
• 简单、明确的精确查询不必强制走 LLM 重写，避免增加延迟和成本。
• 保存原问题、重写结果、召回结果和最终答案，才能定位是改写错还是检索错。

Query Rewrite 和 Rerank 的区别：前者发生在检索前，优化“拿什么去查”；后者发生在召回后，优化“哪些结果排在前面”。

面试口述版

企业用户的问题经常比较口语化，还有错别字、缩写、指代省略和多轮上下文，直接做向量检索不能保证召回准确率。所以检索前通常要做 Query Rewrite：结合历史对话补全上下文，纠正错别字，把口语和内部黑话统一成业务术语，必要时扩展同义词或拆成多个子问题，再根据问题类型路由到合适的索引。重写不能改变用户原意，尤其要保留产品名、数值、时间和否定关系；生产里还可以让原始 Query 和重写 Query 并行召回，再统一 rerank。

企业级 RAG 的索引和数据治理

书面笔记版

企业知识库不是一次导入后长期不变，索引设计和更新机制会直接决定答案是否准确、及时和合规。

常见索引组织方式：

• 分层索引：先通过文档摘要或章节摘要缩小范围，再检索具体 chunk。
• 专业索引：制度、FAQ、代码、日志、表格分别使用适合自身结构的索引。
• 混合索引：同时保留向量、BM25/关键词和结构化字段，按问题类型组合查询。
• Parent-child / Small2Big：用小 chunk 精确命中，生成时补充父段落、父章节或相邻块。
• Hypothetical Questions：为每个 chunk 生成它可以回答的样例问题，检索时匹配“问题与问题”，改善文档表述和用户问法差异大的情况。
• 图索引 / Knowledge Graph：适合实体关系、多跳推理和跨文档关联，但不应为了使用 GraphRAG 而强行图谱化所有内容。

数据更新策略：

• 小规模变更做增量更新和局部重建，不必每次全量向量化。
• 文档新增、修改或删除时通过事件触发索引更新，并记录失败重试。
• chunk 保存 documentId、version、effectiveTime、updatedAt 和内容 hash。
• 新旧版本并存时默认只召回当前生效版本；审计场景可以显式查询历史快照。
• 删除源文档时同步删除或标记失效的 chunk、向量、关键词索引和缓存。
• 对重复、过期、冲突资料做去重、可信级别和冲突标记，不能让模型自行决定哪个版本有效。

权限控制必须发生在检索阶段。chunk 应带 tenantId、部门、用户组、密级和数据域等 ACL 元数据，由应用根据可信身份生成 filter。不能先跨权限召回，再指望 Prompt 告诉模型“不要泄露”。缓存也必须包含知识库版本、租户和权限范围，避免不同用户复用越权结果。

面试口述版

企业级 RAG 的难点不只是向量库，而是索引和数据治理。索引可以按摘要到正文做分层，也可以针对 FAQ、表格、代码、日志建立专业索引；检索时用小 chunk 命中，再补父段落。文档更新要支持增量重建、版本快照和失效删除。权限必须作为 metadata filter 在召回阶段执行，不能先把无权文档取出来再靠 Prompt 防泄露，缓存也必须隔离租户、权限和知识库版本。

企业级 RAG 怎么评测和持续优化

书面笔记版

RAG 的答案错了，不一定是模型问题，也可能是数据缺失、解析错误、切块错误、Query Rewrite 改错、路由错误、召回失败、rerank 排错或上下文被截断。因此企业系统要分阶段评测，而不是只看最终答案“像不像对的”。

企业上线前应建立 Golden Dataset，至少包含：

• 标准问题、标准答案和权威来源文档。
• 同一个问题的正式问法、口语问法、错别字问法、缩写问法和多轮问法。
• 无答案问题、证据冲突问题、过期资料问题和越权问题。
• 问题所属业务域、难度、查询类型和期望命中的 chunk。

线上要保存完整 Trace：原始 Query、重写 Query、路由结果、filter、召回片段和分数、rerank 分数、知识库版本、最终 Prompt、答案、引用、耗时和用户反馈。用户点踩后应把失败归因到数据、解析、切块、改写、召回、排序、生成或权限环节，并沉淀到回归集。

任何 chunk size、embedding、重写 Prompt、top-k、rerank 或生成模型变更，都要在同一套 Golden Dataset 上做版本对比，不能只凭几个示例判断效果提升。

面试口述版

企业级 RAG 要分阶段评测。Query Rewrite 看是否保持原意和关键实体，检索看 Recall@K、MRR、nDCG，生成看 Faithfulness、引用覆盖率和拒答准确率，系统层还要看 P95 延迟、成本和权限泄漏率。上线前要准备带标准答案、来源和多种口语化表达的 Golden Dataset；线上记录从原始问题到重写、召回、排序、Prompt、答案和引用的完整 Trace，差评进入回归集持续优化。

怎么降低 RAG 幻觉

书面笔记版

RAG 能降低幻觉，但不能天然保证没有幻觉。因为 RAG 链路里任何一环出问题，最后都可能表现为“模型胡说”：文档解析错、切块不合理、索引过期、召回不相关、rerank 排错、Prompt 没约束、模型没有严格引用证据，都会导致答案不可靠。

RAG 幻觉常见来源：

一个比较稳的 RAG 回答链路可以这样设计：

1. 检索前处理：对用户问题做意图识别、关键词抽取、时间/产品/权限过滤；复杂问题可以 query rewrite 或拆成多个子问题。
2. 多路召回：同时使用向量检索、关键词检索、元数据过滤，必要时按标题、正文、表格分别建索引。
3. 重排和去重：用 rerank 把真正能回答问题的片段排到前面，并按文档 ID、chunk ID、相似内容去重。
4. 证据门槛：如果 top-k 分数低、片段互相矛盾、没有命中权威来源，就不要强答，改为“资料不足”或让用户补充条件。
5. Citation / 带引用生成：Prompt 明确要求“只能基于给定资料回答”，关键结论必须带 citation，也就是文件名、页码、章节、URL 或记录 ID。
6. 答案校验：检查每个关键结论是否能在引用片段中找到依据；高风险场景用规则、另一个模型、测试用例或人工复核。
7. 评测监控：离线看 Recall@K、MRR、nDCG、引用覆盖率 citation coverage、拒答率、人工纠错率；线上记录完整 trace 方便回放。

Prompt 层可以加这样的约束，但不能只靠 Prompt：

请只根据提供的检索资料回答。
如果资料中没有明确依据，请回答“当前资料不足，无法确定”，不要编造。
每个关键结论后标注来源，例如文件名、页码、章节或记录 ID。
如果不同资料互相矛盾，请指出冲突来源，而不是自行合并成确定结论。

所以“怎么确保 RAG 不幻觉”的更准确回答是：无法 100% 确保，只能通过数据治理、检索质量、证据引用、拒答机制、答案校验、评测监控和人工兜底，把幻觉变成可发现、可度量、可拦截的问题。

面试口述版

RAG 不能自动保证不幻觉，它只是让模型有外部证据。要降低 RAG 幻觉，要从链路上做：数据要新、解析要准、切块要保留语义，检索要用向量加关键词的混合检索，召回后用 rerank，答案必须基于证据并带引用；如果没有证据就拒答或追问。上线后还要记录 query、召回片段、分数、Prompt 和答案，用标准问答集评估召回率、引用覆盖率和人工纠错率。

RAG 数据库有哪些

书面笔记版

“RAG 数据库”通常指向量数据库，或者支持向量检索的搜索和数据库系统。

常见类型：

工程选型通常看数据规模、延迟要求、混合检索能力、过滤和权限控制、运维成本。

面试口述版

RAG 数据库通常指向量数据库或支持向量检索的系统。专门的向量库有 Milvus、Qdrant、Weaviate、Pinecone、Chroma；传统数据库也可以加向量能力，比如 PostgreSQL 的 pgvector；搜索引擎方案有 Elasticsearch、OpenSearch。选型主要看数据规模、延迟、过滤权限、混合检索和运维成本。

PDF 怎么存入 RAG

书面笔记版

PDF 进入 RAG 时，通常不是把二进制文件原样直接拿去做语义检索，而是先解析成文本、版面结构和可追溯的元数据。

典型流程：

1. 判断 PDF 类型：文本型 PDF 直接抽取文本，扫描版 PDF 先 OCR。
2. 提取正文、标题、段落、列表、表格、脚注和页码。
3. 清理页眉页脚、水印、目录噪音、重复页码和无意义换行。
4. 对表格做结构化，保留表名、表头、单位、行列关系和跨页表格关联。
5. 按章节、段落、页码、表格或图注切块，必要时再按 token 上限二次切分。
6. 生成 embedding，并把文本块、向量、页码、章节、坐标、来源和权限标签一起存入检索系统。

常见元数据：

• 文件名、文件 ID、版本号。
• 页码、页内坐标、章节名、标题层级。
• 表格编号、图编号、脚注编号。
• 来源路径或链接。
• 创建时间、更新时间、生效时间。
• 业务域、权限标签、可信级别。

PDF 的难点是版面结构复杂。比如两栏论文、跨页表格、页眉页脚、扫描件 OCR 错字，都会影响切块和召回。工程上不要只看“能不能抽出文字”，还要看抽出的文字是否顺序正确、表格是否保留结构、引用是否能回到具体页码。

面试口述版

PDF 放进 RAG 一般不是直接存文件，而是先判断它是文本型还是扫描件；扫描件要 OCR。然后提取正文、标题、段落、表格和页码，清理页眉页脚、水印等噪音，再按章节、段落、表格或页码切块。存储时要把文本块、向量、页码、章节、来源、权限、版本等元数据一起存起来，这样后续才能准确检索、引用和做权限控制。

AI 是怎么查询 RAG 的

书面笔记版

AI 查询 RAG 常见有两种架构。

第一种是应用先查，模型后答：

1. 用户提问。
2. 应用侧先做向量检索或混合检索。
3. 拿到相关片段。
4. 把片段拼进 Prompt。
5. 调用模型生成答案。

这种方式里，模型不一定知道背后有 RAG，稳定性较高。

第二种是把检索能力包装成 Tool：

1. 把知识库检索作为 tool 暴露给模型。
2. 模型判断要不要调用。
3. 应用执行检索。
4. 检索结果回传模型。
5. 模型基于结果作答。

这种方式更像 Agent，但也更需要控制误调用。

面试口述版

AI 查询 RAG 不一定非得通过 tool call。常见有两种方式：一种是应用层先做检索，再把召回结果塞给模型；另一种是把检索能力包装成 tool，让模型自己决定什么时候查。前者更稳定，后者更像 Agent。无论哪种方式，本质都是先召回相关知识片段，再让模型基于这些片段生成答案。

常见补充八股

书面笔记版

面试口述版

Embedding 是把文本映射成向量，方便按语义相似度检索。Chunk 要在语义完整、检索精度和 token 成本之间平衡，太大噪音多，太小上下文断裂。不同文件类型要按不同结构切：文档按标题段落，表格按表头和行范围，代码按函数类，日志按 traceId 或 requestId。Overlap 普通文本常用 10% 到 20%，结构化数据要小，代码和日志优先按结构关联。用户问题口语化、有错别字、缩写或上下文省略时，检索前要做 Query Rewrite、上下文补全和术语标准化，复杂问题还可以拆成子查询；原始 Query 和重写 Query 可以并行召回再统一 rerank。企业级 RAG 还要处理索引版本、增量更新、租户和 ACL 过滤、完整 Trace 与 Golden Dataset 评测。RAG 降低幻觉要靠混合检索、rerank、引用来源、证据不足拒答和评测监控。Plan-and-Execute 是先规划再执行，ReAct 是边推理边行动边观察。单 Agent 是一个决策中心挂多个工具，多 Agent 是多个角色协作；工程上优先单 Agent，只有需要角色分工、并行、上下文隔离或互审时才上多 Agent。Memory 更偏用户偏好、对话历史和任务状态，RAG 更偏外部知识检索。Skill 最小只要 SKILL.md，复杂时再拆 references/、scripts/ 和 evals/。提示词注入要把外部内容当不可信数据处理，不能让模型执行文档或工具结果里的指令。如果任务流程固定、容错要求极高，其实不一定要上 Agent。

高频追问速答

书面笔记版

面试口述版

Agent 和普通聊天机器人最大的区别是能结合工具、上下文和状态做多步决策。Plan-and-Execute 先规划再执行，ReAct 边推理边调用工具边观察。单 Agent 是一个决策中心，多 Agent 是多个角色协作；如果只是工具多或步骤多，优先单 Agent 多 Tool 加计划执行，只有需要分工、并行、隔离或互审时才上多 Agent。Function call 不等于已经执行，模型只是提出调用意图，宿主应用才执行。Tools 通常只传当前候选集，工具很多时要先路由和筛选。Skill 是能力封装，核心文件是 SKILL.md，复杂资料和工具再拆到 references/、scripts/。MCP 的价值是让 Host 用统一协议发现和调用外部 tools、resources、prompts；LLM 不是直接连 MCP，而是看到 Host 提供的工具描述，生成 tool call 意图后由 Host 转成 MCP tools/call，再把结果作为 observation 放回模型上下文。短期记忆保存当前任务状态，长期记忆保存跨会话偏好和历史。提示词注入不能只靠 Prompt 防，要把外部内容当不可信数据，并配合工具权限、参数校验、输出脱敏和审计。RAG 主要补知识，微调主要改行为；RAG 的切块要按文件类型保留语义边界，overlap 用来补跨块上下文但不能过大，降低幻觉要靠混合检索、rerank、证据引用、资料不足拒答和评测监控。

三分钟串讲版

书面笔记版

AI Agent 是以大模型为决策中枢的任务执行系统，它不只是回答问题，还会根据目标决定要不要调用工具、获取上下文、执行动作并根据结果继续推理。工程上通常是模型、Prompt、Tools、Context 和 Runtime 一起组成 Agent。Workflow 更像固定流程，Agent 更像在约束下动态决策，很多真实系统是二者混合。

Agent 常见执行模式有 Plan-and-Execute 和 ReAct。Plan-and-Execute 是先拆计划，再按步骤执行，适合长任务和复杂任务；ReAct 是每一步先推理，再行动，再观察工具结果，适合边查边做、信息不完整的任务。两者都要限制工具权限、记录状态，并设置失败重试和终止条件。

从架构上看，单 Agent 是一个决策中心挂多个工具，多 Agent 是多个角色或能力单元协作。工程上一般优先用 Workflow 或单 Agent，如果只是任务步骤多，可以用单 Agent 多 Tool 加 Plan-and-Execute；如果只是工具多，可以做工具路由和渐进式披露。只有当任务天然需要多角色分工、并行处理、上下文隔离、权限隔离或互相审核时，才更适合多 Agent。多 Agent 通常要有 Orchestrator 负责拆任务、调度 Agent、维护共享状态和控制终止条件。

Agent Memory 分短期记忆和长期记忆。短期记忆是当前会话和当前任务状态，比如计划、工具结果、临时结论；长期记忆是跨会话保存的用户偏好、历史任务摘要和稳定事实。Memory 更偏用户和任务状态，RAG 更偏外部知识检索。

Agent 的幻觉治理不能只靠 Prompt，要让模型基于 RAG、数据库或工具结果回答，用引用来源、结构化输出、参数校验和二次验证约束结果，并对高风险动作做人审或执行前确认。

Agent 安全里还要重点防提示词注入。用户输入、RAG 文档、网页和工具结果都可能夹带恶意指令，所以要把外部内容标记为不可信数据，只作为事实证据，不作为更高优先级指令。工具调用要做最小权限、参数校验、权限校验和高危动作确认，长期记忆写入也要防投毒。

Prompt 优化的核心不是写得越长越好，而是让模型目标清楚、边界清楚、输出清楚。Function call 和 tool call 经常混用，但 tool call 是上位概念，function call 是其中一种结构化调用。AI 调 tool 的本质是模型负责决定，应用负责执行。工具很多时不能全量塞给模型，要先路由、分层，再按需动态注入，这就是渐进式披露思想在工具管理里的典型应用。多 Agent 通信通常通过 Orchestrator、共享黑板、事件队列或 Agent Tool 化完成，消息最好结构化，带任务 ID、意图、状态、证据、置信度和下一步建议，方便审计和回放。

Skill 是 Agent 能力的工程封装，最小结构只需要 SKILL.md，里面写清楚名称、触发描述和执行流程；如果资料很多，就放进 references/，如果有稳定重复逻辑，就放进 scripts/，如果要验证效果，就放进 evals/。

RAG 是检索增强生成，核心是先查再答。企业级 RAG 不只是把文档向量化后做一次 top-k 检索，而是一条包含数据解析和版本治理、语义切块、多种索引、查询理解、多路召回、rerank、权限过滤、上下文构建、引用校验和评测监控的完整链路。用户问题可能口语化、有错别字、缩写、指代省略或多轮上下文，所以检索前要做 Query Rewrite，把问题补全并标准化，复杂问题拆成子查询，再通过 Query Router 选择合适的知识库或数据库。为了防止重写改变原意，要锁定产品名、数值、时间和否定关系，并保留原始 Query；生产里可以让原始 Query 和重写 Query 并行召回。切块不能只按固定字数，不同文件类型要按不同语义边界处理，检索可以用小 chunk 命中后补充父段落。企业知识库还要支持增量更新、版本失效和检索阶段的租户、ACL 过滤。RAG 不能完全避免幻觉，要通过混合检索、rerank、metadata filter、证据引用、资料不足拒答和答案校验降低风险，并用 Golden Dataset 分别评测改写、召回、排序和生成效果，线上保存完整 Trace 形成反馈闭环。

面试口述版

AI Agent 可以理解成模型加工具加上下文加运行时组成的任务执行系统。Workflow 流程固定，Agent 会在约束下动态决定下一步。执行模式里，Plan-and-Execute 是先规划再执行，ReAct 是边推理边调用工具边观察。单 Agent 是一个决策中心挂多个工具，多 Agent 是多个角色协作；一般优先单 Agent，只有需要角色分工、并行、上下文隔离、权限隔离或互审时才上多 Agent。多 Agent 要有 Orchestrator、共享状态、结构化通信、最大轮数和终止条件。Memory 里短期记忆保存当前任务状态，长期记忆保存跨会话偏好和历史。Agent 幻觉要靠 grounding、引用来源、结构化输出、工具校验、二次验证和人审兜底一起治理；提示词注入则要把用户输入、RAG 文档和工具结果都当成不可信数据，配合最小权限、参数校验、高危确认、输出脱敏和审计。Prompt 优化要让目标、边界、输出都清楚；tool call 是模型提出调用意图，真正执行的是宿主应用。工具很多时要做路由、筛选和渐进式披露。Skill 是可复用能力包，最核心是 SKILL.md，复杂内容再拆到 references/ 和 scripts/。RAG 的核心是先查再答，企业链路还包括 Query Rewrite、子查询拆分、路由、多路召回、rerank、权限过滤、版本更新、引用校验和评测闭环。用户问题口语化或上下文不完整时，要先补全、纠错和标准化，再检索；重写时必须保持实体、数值、时间和原意。切块要按文件类型保留语义边界，降低幻觉要靠证据引用、拒答和答案校验，上线后用 Golden Dataset 与完整 Trace 持续优化。