一、Agent 项目背景与价值

1. 为什么做 Agent 项目？

回答脚本：

我们做 Agent 项目，核心是为了突破大模型 “单次问答” 的局限，让 AI 能像人一样自主完成复杂、多步骤的任务。

从技术角度看，大模型的推理能力加上工具调用（MCP/Function Calling）的成熟，让 Agent 具备了 “感知 - 思考 - 执行 - 反思” 的闭环能力。

从业务价值看，在企业内部知识管理、研发提效、智能客服等场景中，Agent 可以深度替代人力，比如自动生成并调试代码、处理跨系统的审批流程，从而降低成本、提升效率。

同时，Agent 也是未来 AI 应用的核心形态，能让我们的产品从 “辅助工具” 升级为 “解决方案载体”。

2. Agent 项目背景

回答脚本：

一方面是技术成熟度的提升，GPT-4、Claude 3 等大模型的推理能力大幅增强，加上 MCP、Function Calling 等工具调用协议的完善，让 Agent 具备了落地的技术基础。

另一方面是企业需求的升级，过去的大模型应用多是 “问答式” 的，无法处理需要多步决策、工具协作的复杂任务，比如 “从企业知识库中检索数据并生成分析报告”，而 Agent 正是为了解决这类场景而生。

此外，行业内像 AutoGPT、DevIn 等 Agent 产品的涌现，也验证了这一方向的可行性，推动我们启动相关项目。

---

二、行业认知与竞品

3. 了解过市面上有哪些智能体 agent 吗？

回答脚本：

市面上的 Agent 主要分为几类：

1. 通用开源框架：LangChain Agents 是最常用的，支持多模型和工具链；AutoGen 主打多 Agent 协作；Semantic Kernel 是微软推出的企业级框架。
2. 垂直领域产品：DevIn 是 AI 程序员，能完成从需求到代码调试的全流程；Character.AI 专注于角色化对话 Agent。
3. 云厂商产品：阿里云的通义千问 Agent、腾讯的混元 Agent，都提供了企业级的 Agent 开发平台。
4. 实验性项目：AutoGPT 是早期自主任务规划的代表，展示了 Agent 的潜力，但落地性稍弱。

4. 了解其他的 Agent 范式吗？

回答脚本：

常见的 Agent 范式有这些：

1. ReAct：核心是 “思考 + 行动”，让 Agent 先推理下一步该做什么，再调用工具执行，通过闭环迭代逼近目标。
2. Plan-and-Execute：先把复杂任务拆解成子步骤，再依次执行，适合需要明确规划的场景，比如写代码、做项目方案。
3. Reflexion：增加了自我反思能力，Agent 会复盘之前的执行结果，修正错误，比如代码调试后发现问题，会重新生成代码。
4. Hierarchical Agent：分层协作模式，比如一个 “总 Agent” 负责拆解任务，多个 “子 Agent” 负责执行具体子任务，适合大型复杂场景。

---

三、Agent 技术架构与开发

5. Agent 项目开发的框架

回答脚本：

我们主要用 LangChain 作为核心框架，它的生态很完善，支持多模型接入、工具链管理和记忆系统。

整个架构分为这几层：

1. 大模型调用层：对接 GPT-4、Claude 3 或开源模型，负责核心推理。

2. 工具调度层：基于 MCP/Function Calling 管理外部工具（比如代码生成、数据库查询），处理调用逻辑和结果校验。

3. 记忆层：短期记忆用对话上下文拼接，长期记忆用向量数据库存储历史对话摘要，支持检索召回。

4. 规划与监控层：负责任务拆解、步骤规划，以及执行过程中的错误追踪和重试。

   另外，我们也会结合 LlamaIndex 做知识增强，用 Prometheus 做监控。

6. Agent 推理模式

回答脚本：

我们主要用 ReAct 模式，这是最成熟的方案。

比如处理 “生成并调试接口” 的任务时，Agent 会先思考 “需要先生成接口代码，再启动服务测试，最后根据错误日志修复问题”，然后依次调用代码生成工具、本地运行工具和代码修复工具，每一步都会根据结果调整后续动作。

对于更复杂的任务，我们会叠加 Plan-and-Execute 模式，先把任务拆解成子步骤，再用 ReAct 执行每个子步骤，确保逻辑清晰。

7. 多轮对话的实现方案

回答脚本：

核心是记忆管理，我们分短期和长期记忆来处理：

1. 短期记忆：直接拼接对话上下文，但会做摘要压缩，比如用大模型总结前几轮的核心信息，避免上下文过长导致模型输入超限。

2. 长期记忆：把历史对话的关键信息（比如用户的业务背景、之前的决策结果）向量化后存入向量库，当新问题进来时，先检索相似的历史信息，再拼接上下文，让 Agent 记得之前的对话内容。

   另外，我们会用 对话状态机 管理多轮流程，比如在客服场景中，跟踪用户当前处于 “问题咨询” 还是 “故障排查” 阶段，确保对话连贯。

---

四、大模型与 MCP/Function Calling

9. MCP 和 Function Calling

回答脚本：

两者都是大模型调用外部工具的协议，但定位不同：

1. Function Calling：是大模型的原生能力，比如 GPT-4 自带的，核心是让模型能生成结构化的 JSON 来调用工具，但它是无状态的单步调用，只能单次触发工具，无法处理多轮工具协作。

2. MCP（Model Context Protocol）：是对 Function Calling 的扩展，它支持多轮工具调用、状态保持、错误重试和工具动态选择，更适合 Agent 场景。

   比如在 “生成报表” 的任务中，Function Calling 只能调用一次数据库查询工具，而 MCP 可以先调用查询工具获取数据，再调用可视化工具生成图表，还能根据图表结果调整查询条件，实现闭环。

10. MCP 协议的核心内容

回答脚本：

MCP 的核心是解决 “大模型如何连贯地使用工具完成复杂任务” 的问题，核心内容包括：

1. 会话状态管理：维护多轮工具调用的上下文，比如记录之前调用的工具、参数和结果，让模型能基于历史信息做决策。
2. 多工具协作：支持并行调用多个工具，比如同时调用数据库和知识库检索，再整合结果。
3. 错误处理与重试：工具调用失败时，自动重试或切换工具，比如数据库查询超时后，切换到缓存查询。
4. 权限与安全控制：对工具调用做权限校验，比如敏感数据查询需要用户授权。
5. 标准化通信：基于 HTTP/JSON 或 WebSocket 实现，确保不同模型和工具之间的兼容性。

---

五、RAG 系统

13. RAG 系统流程

回答脚本：

RAG 分为构建阶段和查询阶段：

1. 构建阶段：先采集企业内部文档、知识库等数据，做清洗和格式转换，然后用嵌入模型（比如 text-embedding-3-large）将文本向量化，最后存入向量数据库（比如 Pinecone、Milvus）。

2. 查询阶段：用户提问后，先对问题做向量化，在向量库中检索最相似的知识片段，然后把这些知识和原始问题拼接成 Prompt，再调用大模型生成回答。

   我们还会在查询阶段增加重排序步骤，用 Cross-Encoder 对检索结果做精排，提升相关性。

14. RAG 检索优化策略

回答脚本：

我们主要从这几个方面优化：

1. 多路召回：同时用向量检索和关键词检索，比如用 Elasticsearch 做全文检索，再和向量结果合并，提升召回率。
2. Query 改写：用大模型把用户的模糊提问改写为更精准的查询，比如把 “怎么调接口” 改成 “Spring Boot 接口调试步骤和常见问题”。
3. 分层检索：先做粗排（用向量库快速召回 top 100），再做精排（用 Cross-Encoder 排序 top 10），平衡速度和精度。
4. 知识摘要：对长文档做分段摘要，避免检索到的知识片段过长，影响大模型生成质量。

---

六、Prompt 工程

17. 如何写好的 prompt

回答脚本：

我总结了几个核心原则：

1. 明确目标：用 “给定 X，生成 Y，满足 Z 条件” 的句式，比如 “给定用户的报错日志，生成 3 个可能的根因和排查步骤”。
2. 设定角色：让模型代入特定角色，比如 “你是资深 Java 开发工程师”，这样回答会更专业。
3. 提供示例：复杂任务用 Few-shot 示例，比如给 1-2 个正确的回答范例，引导模型输出符合要求的结果。
4. 约束格式：要求输出结构化内容，比如 JSON、列表，方便后续处理。
5. 增加事实校验：在 Prompt 中加入 “基于给定信息回答，不要虚构内容” 的约束，减少幻觉。

18. Prompt 设计示例

回答脚本：

比如针对 “Spring Boot 接口报错” 的场景，我会这样写：

plaintext

你是一位资深的 Java 开发工程师，请分析以下错误日志并给出解决方案：
1.  先提取日志中的关键异常信息；
2.  列出3-5个可能的根因；
3.  针对每个根因给出具体的排查步骤和修复方案。
错误日志：
java.lang.NullPointerException: Cannot invoke "com.example.service.UserService.getUserById(Long)" because "this.userService" is null

这样的 Prompt 目标明确、步骤清晰，模型能输出非常精准的结果。

---

七、其他高频问题

20. LLM 产生幻觉的原因及解决方案

回答脚本：

幻觉的原因主要有：

1. 训练数据问题：数据中有噪声、过时信息或矛盾内容，模型学习后会生成错误信息。
2. 推理逻辑跳跃：模型为了生成流畅的回答，会在信息不足时 “脑补” 内容，导致虚构。
3. 输入信息模糊：用户提问不明确时，模型会过度生成内容。

我们的解决方案包括：

1. RAG 增强：引入真实的企业知识库，让模型基于给定信息回答，减少虚构。
2. 事实校验：增加工具调用步骤，比如生成回答后，调用知识库或搜索引擎验证关键信息。
3. Prompt 约束：在 Prompt 中明确要求 “仅基于给定信息回答，不确定时说明”。
4. 小模型校验：用轻量模型（比如 Llama 3 7B）对大模型的输出做事实核查，过滤错误内容。