1.什么是agent，他的组成部分有哪些？

agent是一种能够自主感知环境，自主决策，自主执行动作，并持续迭代优化以完成目标的智能实体，大模型是大脑的话，agent就是带收带记忆有规划能力的完整智能体

agent可以分为5部分

• 感知模块（Perception）

  • 从外部获取信息：用户输入、工具返回结果、环境状态等。
  • 作用：理解当前任务和上下文。

• 决策 / 规划模块（Planning）

  • 根据目标拆解任务、制定执行步骤、判断是否需要调用工具。
  • 常见：ReAct 思维链、任务规划、子任务拆分。

• 执行 / 动作模块（Action）

  • 调用外部工具完成实际操作：搜索、数据库查询、API、代码执行、文件操作等。
  • 对应后端常说的 Function Call / Tool Calling。

• 记忆模块（Memory）

  • 短期记忆：对话上下文、当前任务状态。
  • 长期记忆：历史经验、知识库、向量库检索内容。
  • 作用：避免重复思考，保持任务连贯性。

• 反思 / 迭代模块（Reflection）

  • 执行后判断结果是否满足目标，失败则重试、修正步骤或重新规划。
  • 是 Agent 比单纯大模型对话更 “智能” 的关键。

Agent 搭建完整流程

1. 明确任务场景（顶层设计）

先确定 Agent 要解决什么问题：

• 个人助手？
• 代码助手？
• 企业业务自动化？
• 数据分析？
• 客服机器人？

确定后，你就知道需要哪些：

• 输入输出
• 权限边界
• 可调用工具范围
• 安全限制

---

2. 选择 LLM 并开启 FunctionCall

FunctionCall 是 Agent 的大脑决策机制。

流程：

1. 选一个支持函数调用的模型
   • GPT-3.5/4
   • Claude 3
   • 通义千问、文心一言、GLM 等
2. 给模型传入 tools 描述（JSON Schema）
3. 模型输出结构化调用指令：

   json

   {
     "name": "get_weather",
     "parameters": { "city": "北京" }
   }
   

4. 后端解析并执行

这一步就是：让模型会 “思考要调用什么”。

---

3. 设计并开发 Skill（核心能力封装）

Skill = 面向任务的能力单元。

一个 Skill 标准结构：

• 名称：如 航班查询技能
• 描述：告诉模型这是干嘛的
• 输入参数：出发地、目的地、日期
• 执行逻辑：
  1. 校验参数
  2. 调用航班查询 Tool
  3. 调用比价 Tool
  4. 整理结果返回
• 输出格式

Skill 是 Agent 的 “能力菜单”。

---

4. 开发或接入 Tool（真正执行）

Tool 是原子执行单元，例如：

• HTTP 请求
• 数据库查询
• 文件读写
• 代码执行
• 第三方 API

开发方式：

• 写函数
• 封装 API
• 接入第三方服务

Tool 只负责：接收参数 → 执行 → 返回结果

---

5. 接入 MCP 协议（标准化）

如果你要做可扩展、可插拔、多工具统一管理的 Agent，必须上 MCP。

MCP 做的事：

• Tool 自动注册发现
• 统一调用格式
• 权限控制
• 安全隔离
• 支持本地 / 远程工具

流程：

1. 把每个 Tool 封装成 MCP Server
2. Agent 作为 MCP Client 连接
3. 通过标准协议调用所有工具

这一步让你的 Agent 从玩具变成工程化系统。

---

6. 编排、记忆、调度与测试（Agent 灵魂）

这是 Agent 区别于简单函数调用的关键。

（1）记忆模块

• 短期记忆（对话上下文）
• 长期记忆（向量库 / 数据库）
• 工具调用历史

（2）规划 / 编排

• ReAct 思维链
• 思考 → 行动 → 观察 → 再思考
• 多 Skill 自动调度

（3）循环执行

模型判断：

• 还需要调用工具吗？
• 结果够不够？
• 是否可以回答用户？

（4）测试

• 边界用例
• 参数错误
• 工具失败重试
• 安全校验

2.为什么要引用工具，单纯的大模型不行吗？

单纯的大模型本质只是语言生成模型，存在知识过时，计算不准，无法操作外部世界等问题，必须要通过调用工具(tool calling/function call)来弥补，大模型负责思考和决策，工具负责执行和落地。

3.工具给大模型扩展了怎么样的能力？

工具本质是给大模型装上感知、执行、计算、记忆、专业能力，让它从纯文本生成，变成能落地真实业务的智能体。例如实时信息获取能力，精准计算与逻辑推理能力，外部操作系统能力，专业领域增强能力，长期记忆与状态管理能力

4.了解tool吗？

Tool是能被模型调用的、具体可执行的外部能力单元

它不负责思考，只负责干活。

• 没有逻辑、没有规划
• 给参数 → 执行 → 返回结果
• 是模型与外部世界交互的手脚

典型例子：

• 联网搜索工具
• 数据库查询工具
• 文件读写工具
• 发送邮件工具
• 调用第三方 API
• 代码执行器
• 计算器

---

Tool 的核心特征

1. 原子性一般只做一件事，不做复杂任务。
2. 结构化必须有明确的入参、出参格式（JSON 结构）。
3. 可被调用模型通过某种机制触发它运行。
4. 无状态用完即走，不记住上下文。

怎么写好一个工具

写好一个工具，关键不在于接口本身多复杂，而在于让大模型能看懂、会调用、不出错。主要抓好三件事：

1. 工具描述（提示词级别的说明）
2. 清晰、简洁、必填明确的入参
3. 结构化、语义明确的出参

1. 工具描述（给大模型看的 “提示词”）非常重要

这是模型判断要不要调用、怎么调用的唯一依据，写不好模型就乱调用或不调用。

书写原则

• 用途明确：一句话说明这个工具是干嘛的
• 场景清晰：什么情况下应该调用
• 边界清晰：不能干什么、不处理什么
• 语言简单：不用专业黑话，模型看不懂
• 避免歧义：不写模糊词汇，比如 “大概”“可能”“相关”

错误示例：

查询用户信息

正确示例：

根据用户 ID 查询该用户的姓名、手机号、注册时间，仅用于身份核验，不返回敏感信息如密码、支付信息。

---

2. 入参设计（决定模型会不会传错）

模型最容易错的就是参数名、参数类型、是否必填。

写好入参的要点

• 参数名语义化：userId、orderId、phone，不要 a1、p2、x
• 类型严格：int、string、bool 明确
• 必填标记清楚：模型必须知道哪些必须传
• 枚举尽量固定：如 status=0/1 要写明含义
• 参数示例：给模型一个示例，它正确率飙升
• 参数约束：长度、格式、范围（手机号 11 位、日期格式 YYYY-MM-DD）

---

3. 出参设计（决定模型能不能理解结果）

返回必须结构化、字段清晰、无冗余，否则模型会理解错误、产生幻觉。

出参原则

• JSON 结构化，不要纯文本
• 字段名简单明确：code、msg、data、success
• 状态码统一：0 成功，非 0 失败
• 失败信息可读：模型能看懂并告诉用户
• 不返回无用字段：减少上下文污染
• 敏感数据过滤：不返回密码、密钥等

5.了解Function call吗？

function call就是函数调用，是大模型厂商提供的一种结构化输出能力，让模型能够判断何时需要调用外部接口，并按照约定格式返回参数，由后端系统真正执行接口，再把结果返回给模型整理输出。

核心流程

1. 定义工具清单：后端把接口信息（接口名、参数、用途）以 JSON 格式告诉大模型。
2. 模型决策：模型判断是否需要调用工具、调用哪个、参数是什么。
3. 结构化返回：模型不直接回答，而是返回固定格式的函数调用指令。
4. 后端执行：Java 解析指令，真实调用接口 / DB / 第三方服务。
5. 结果回传：把执行结果再传给模型，模型自然语言总结后返回用户。

6.了解skill吗？

Skill = 面向 “任务” 的可复用能力单元

你可以把它理解成：

• LLM 会的一项 “本事”
• 不是单个函数，也不是裸工具
• 是一段逻辑 + 一组工具调用 + 提示词模板的封装

简单类比：

• Tool = 螺丝刀、扳手（单个工具）
• FunctionCall = 拧螺丝这个动作
• Skill = 组装一台电脑（完整任务）

---

Skill 的标准结构

一个完整 Skill 通常包含：

1. 名称与描述告诉 LLM 这个技能是干嘛的
2. 输入参数用户需要提供什么
3. 执行逻辑（Planning）先干嘛、后干嘛、要不要查资料、要不要重试
4. 绑定的 Tools调用哪些底层工具
5. 输出格式返回什么结果给用户

所以：Skill 是 Tool 的上层封装，Tool 是 Skill 的执行依赖。

Skill 核心特性

1. 业务封装性不只是单个接口，而是完整业务能力。例如：“报销审核 Skill”“订单查询 Skill”“简历筛选 Skill”。

2. 可复用性一次编写，多场景、多 Agent、多模型都能复用，避免每个任务重新写提示词和调用逻辑。

3. 流程编排能力内置 SOP（标准作业流程），支持多步骤、多工具串联，比如：查询订单 → 校验状态 → 生成说明 → 发送通知。

4. 自带约束与安全可控可以明确规定：

   • 允许调用哪些工具
   • 禁止哪些操作
   • 权限范围、敏感数据处理规则比裸奔的 Function Call 更安全、更适合企业生产。

5. 触发条件明确有清晰的触发意图：什么用户问题应该启动这个 Skill，避免模型乱调用、乱执行。

6. 自带知识与上下文可以绑定领域知识、文档片段、示例话术，让 Agent 更专业，减少幻觉。

7. 可组合、可扩展Skill 之间可以互相调用、嵌套组合。小 Skill 拼成复杂业务流程，类似微服务架构。

8. 可观测、可迭代执行日志、成功率、失败原因可追踪，能单独优化某个 Skill，不影响整个系统。

7.了解MCP吗，说说MCP的组成？

Model Context Protocol (MCP) 是一个开放标准，用于连接 AI 应用与数据源。就像 USB-C 为设备连接提供了通用接口一样，MCP 为 AI 模型提供了访问外部数据和工具的标准化方式。

MCP 核心组成（C/S 架构，4 大组件）

MCP 采用客户端‑服务器（Client‑Server）架构，核心由 MCP Host、MCP Client、MCP Server、Resources/Tools 四部分组成：

1. MCP Host（主机）

• 角色：运行 LLM 的应用环境，是用户交互入口与任务编排中心。
• 职责：
  • 接收用户请求，管理对话上下文
  • 决策是否调用工具、调用哪个 Server
  • 编排多个 Client，管理整体工作流
• 示例：Claude Desktop、Cursor IDE、Windsurf、VSCode 等。

2. MCP Client（客户端）

• 角色：Host 内置的协议通信模块，与 Server 建立 1:1 连接。
• 职责：
  • 与 MCP Server 建立连接、握手、发现能力
  • 将 Host/LLM 的指令转为 MCP 标准消息
  • 解析 Server 返回结果，回传给 Host
• 定位：Host 与 Server 之间的 “翻译官 / 通信代理”。

3. MCP Server（服务器）

• 角色：封装外部能力的服务端，是 MCP 体系的核心能力提供方。
• 核心能力（三大类）：
  • Tools：可执行的函数 / 接口（如查询数据库、调用 API、执行代码）
  • Resources：可访问的数据 / 内容（如文件、知识库、向量库、Git 仓库）
  • Prompts：可复用的提示词模板 / 工作流
• 职责：监听请求、执行操作、返回结构化结果。
• 示例：GitHub Server、Slack Server、本地文件 Server、MySQL Server 等。

4. Resources & Tools（资源与工具）

• 角色：被 MCP Server 封装的真实外部能力与数据。
• 范围：数据库、API、文件系统、代码仓库、第三方服务、企业内部系统等。

MCP 核心流程

1. 能力发现：Client 向 Server 发起握手，获取其提供的 Tools/Resources/Prompts 列表
2. 请求发起：Host 决定调用，Client 按 MCP 格式发送结构化请求
3. 执行与返回：Server 执行对应工具 / 资源操作，返回标准结果
4. 结果处理：Client 解析结果，回传给 Host，LLM 整理后输出给用户

怎么开发一个mcp服务

开发 MCP 服务，先选框架（优先 FastMCP），再定义 Tools/Resources/Prompts，用 stdio/SSE 传输，接入 Claude/Cursor 等客户端，最后做安全、权限、监控。

8.tool，function call，skill，mcp对比

tool就是工具，是大模型调用工具的最原子执行单位，是外部能力的具体实现，只负责执行，而function call就是告诉大模型怎么去调用执行tool，许多特定的function call加一些规则约束提示词组成了可以完成一项特定任务的skill（例如扣子工作流），而mcp就是大模型调用工具这个过程中要遵守的协议

标准化:Tool 是模型可调用的外部能力单元，Function Call 是模型以结构化形式触发 Tool 的机制；多个 Tool 调用和推理流程可以封装为 Skill，而 MCP 则是规范模型如何发现、描述和调用这些工具的协议标准。

维度	Tool（工具）	Function Call	Skill（技能）	MCP（协议）
本质	实际可执行的外部能力	模型输出的结构化调用格式	面向业务的能力封装单元	模型与外部的标准化连接协议
通俗理解	螺丝刀、接口、API	拧螺丝的一次指令	完整组装流程 + 工具包	通用插座 / USB 规范
核心作用	提供具体功能：查、算、写、操作	让模型告诉后端：调谁、传什么参数	完成一整项业务任务	统一连接所有工具 / 模型，解决碎片化
粒度	原子级：单接口、单功能	单次调用：一次函数执行	业务级：多步骤、多工具、SOP	全链路级：发现 + 连接 + 调用 + 权限
由谁定义	后端开发	大模型厂商（OpenAI 等）	Agent 开发者 / 业务方	行业标准（Anthropic 主导）
是否带业务逻辑	❌ 纯功能，无流程	❌ 仅调用，无逻辑	✅ 自带 SOP、规则、约束	❌ 纯协议，无业务
是否需要上下文	不需要	少量（参数描述）	非常大（提示词 + 示例 + 流程）	很小（协议结构）
通用性	业务内部使用	模型私有，不跨模型	平台内可复用	✅ 跨模型、跨客户端通用
能力发现	无	无	内部可管理	✅ 支持自动发现工具 / 资源
与 LLM 关系	被调用方	LLM 负责输出调用指令	LLM 负责决策与执行 Skill	LLM 应用通过 MCP 统一接入
典型形态	接口、函数、第三方 API	JSON 结构（name/parameters）	Skill 文件、配置、流程编排	Server + Client + JSON-RPC
失败处理	后端抛异常	模型重新生成参数	Skill 内部重试、反思、降级	协议层错误码、重连、超时
适用场景	单一功能调用	简单单次工具调用	复杂业务：订票、报销、代码开发	企业级多模型、多工具统一接入
后端类比	Controller/Service 接口	API 入参格式	微服务 / 业务模块	RPC/HTTP 通信协议

9.mcp和skill哪个上下文占用比较大

1）MCP 上下文很小

MCP 做的事情：

• 定义通信格式：请求、响应、错误码
• 能力发现：有哪些工具、资源
• 传输结构化数据，不带业务逻辑

它更像HTTP 协议，只规定怎么传，不传业务文档。→ 给 LLM 的提示词里只需要塞极简协议格式，token 占用极低。

---

2）Skill 上下文非常大

Skill 本质是完整业务逻辑，必须塞进上下文：

• 技能用途、触发条件
• 详细 SOP 步骤
• 输入输出规则
• 约束、禁忌、权限
• 示例对话、示例调用
• 领域知识、注意事项

一个稍微复杂的 Skill，可能几百～几千 token，多加载几个 Skill，模型上下文直接吃满。

10 怎么写好提示词

提示词工程，就是用清晰、结构化、有约束的自然语言，把人的意图精准翻译给大模型，让它像可靠服务接口一样稳定输出。

1. 明确角色先告诉模型它是谁：专家、助手、代码审查员、面试官、Agent 决策者。
2. 明确任务清晰告诉它要做什么，不要模糊、不要多任务混杂。
3. 明确约束限制输出格式、长度、风格、禁忌、敏感信息过滤。
4. 提供上下文给足背景、历史、数据、文档片段，减少模型瞎猜。
5. 给出示例（Few-shot）给 1～3 个输入输出示例，效果提升巨大。
6. 指定输出格式强制 JSON、列表、分段、步骤，方便后端解析。
7. 要求思考过程让模型先思考再输出，减少幻觉（ReAct 思想）。

11 什么是上下文工程

上下文工程，就是对传入大模型的所有上下文信息做结构化、精简、优先级排序、持久化与召回管理，在有限 token 限制下，保证模型推理准确、稳定、不溢出。

它解决几个核心痛点：

1. 上下文窗口有限，不能无限塞历史
2. 信息杂乱会导致模型混乱、幻觉
3. 长对话、多轮 Agent 必须记住关键状态
4. 外部知识库不能全塞进去，要精准召回

上下文工程核心做哪些事？

1. 上下文裁剪 / 压缩

   • 只保留关键信息，删除冗余对话
   • 对旧信息做摘要，而不是全量保留

2. 结构化管理记忆

   • 短期记忆：最近几轮对话
   • 长期记忆：摘要、关键实体、任务状态
   • 外部记忆：向量库检索的知识片段

3. 优先级调度

   • 最新信息 > 重要任务信息 > 旧闲聊
   • 保证关键数据一定在窗口内

4. 防溢出控制

   • 实时 token 估算
   • 自动截断、滑动窗口、滚动上下文

5. 外部知识召回（RAG 核心）

   • 不把全量文档塞进去
   • 只召回最相关的几条知识注入上下文

6. 状态与变量提取

   • 把用户姓名、订单号、任务目标抽成结构化字段
   • 避免模型在长对话中 “失忆”

上下文过长怎么办?

上下文过长，核心就三件事：裁剪、压缩、召回，再配合窗口控制，保证不爆 token、不丢关键信息。

---

1. 滑动窗口（最常用、最简单）

• 只保留最近 N 轮对话，旧的直接丢掉
• 实现简单、性能好
• 缺点：很早的关键信息会丢失

2. 摘要压缩（最通用）

• 把早期对话丢给 LLM 生成精简摘要
• 只保留摘要 + 最新几轮完整对话
• 适合长对话、多轮 Agent 任务

3. 结构化抽取（效果最稳）

不从文本层面删，而是提取关键信息：

• 用户 ID、订单号、任务目标、关键决策
• 转成 KV 结构或极简列表
• you：用户=小明，查询订单=123456，问题=物流状态
• 大幅降 token，信息几乎不丢

4. 向量库召回（RAG 思路）

• 把历史对话向量化存入向量库
• 每次只检索和当前问题相关的历史
• 不相关的历史完全不进上下文
• 适合超长对话、跨天记忆

5. 分层记忆（企业级标准方案）

• 短期记忆：最近几轮完整对话
• 中期记忆：摘要 + 关键事实
• 长期记忆：向量库存储
• 只把必要层塞进模型上下文

6. Token 估算 + 动态截断

• 实时计算 token 数
• 达到阈值自动触发压缩 / 摘要
• 防止直接触发模型 “上下文超限” 报错

7. 清理冗余信息

• 删除问候、客套、重复语句
• 去掉工具调用的冗余返回字段
• 只保留业务有效内容