AI Agent 面试题第三弹：Tool Call、HITL、安全策略

**Schema**（中文常译为"模式"或"架构"）是一种**结构化数据的描述规范**，它用约定好的格式定义了一个数据对象应该长什么样——包含哪些字段、每个字段是什么类型、是否必填、取值范围等。 在 AI Agent 和 Function Calling 的语境下，**JSON Schema** 就是用来描述"工具参数长什么样"的一套标准。举个例子： ```json { "type": "object", "properties": { "file_path": { "type": "string", "description": "要读取的文件路径" }, "max_lines": { "type": "integer", "description": "最多返回的行数", "default": 100 } }, "required": ["file_path"] } ``` 这个 Schema 告诉 LLM： - 这个工具有两个参数：`file_path`（字符串）和 `max_lines`（整数） - `file_path` **必须提供**（required） - `max_lines` 可选，默认值 100 你可以把 Schema 理解为**给 LLM 看的"参数使用说明书"**。LLM 不会像传统程序那样硬编码地解析参数，而是**读这段 Schema 描述，理解每个参数的含义和约束，然后生成符合要求的 JSON**。 所以参考资料里说"Schema 要严格"——描述写得越清晰、类型约束越明确（比如用 enum 枚举可接受的值）、示例给得越具体，LLM 调用工具的**准确率就越高**。反之，Schema 写得模糊，LLM 就容易"自由发挥"，传错参数。

**Schema 就是“数据结构的描述规范”**，它告诉系统（尤其是 LLM）：这个工具的参数长什么样、每个字段的规则是什么。 在 Function Calling / Tool Calling 的场景下，**Schema 特指 JSON Schema**，它是一个轻量级的规则描述语言，用来声明一个函数（工具）的参数结构。比如： ```json { "type": "object", "properties": { "file_path": { "type": "string", "description": "要读取的文件路径，如 /home/user/readme.md" }, "max_lines": { "type": "integer", "description": "最多返回的行数，默认为全部" } }, "required": ["file_path"] } ``` 这段 Schema 就是在告诉 LLM： - 这个工具需要 **一个对象参数** - 里面有 `file_path`（字符串，必填）和 `max_lines`（整数，可选） - 每个字段还有 **描述** 帮助 LLM 理解怎么传值 --- **Schema 写得好不好，直接决定 LLM 的调用准确率**。参考资料里总结了四个原则： 1. **描述要具体** — “读取指定路径的文件内容，返回文件的完整文本” 比 “读文件” 好 2. **参数名要准确** — `file_path` 比 `p` 好 3. **用 enum 枚举限定值** — 防止 LLM 自由发挥导致大小写不一致 4. **描述里加示例** — “项目类型，如 java、python、node” 比光写 “项目类型” 准确率高 所以文中那句 “Schema 要严格” 的意思是：**参数的类型、必填性、枚举值、描述，每一个细节都要写清楚**，因为 LLM 全靠这段文本描述来理解工具该怎么用，Schema 越含糊，LLM 越容易瞎猜乱传参数。

**loopback 地址（回环地址）** 是计算机网络中的一个特殊 IP 地址，最典型的就是 **127.0.0.1**（IPv4）和 **::1**（IPv6），也就是我们常说的 **localhost**。 它的核心特点是： 1. **指向本机自身**：任何发往 loopback 地址的数据包**不会离开本机**，直接由操作系统内核回环回来，相当于跟自己对话。 2. **常用于测试**：开发时启动一个 Web 服务在 `127.0.0.1:8080`，就是只允许本机访问，用来调试。 3. **无需物理网卡**：即使电脑没插网线、没连 WiFi，loopback 接口也是可用的。 **回到你选的那段文本（web_fetch 安全策略）：** ``` 屏蔽内网地址段（10.x、192.168.x、172.16-31.x）和 loopback 地址 ``` 这条规则的目的是**防 SSRF（服务端请求伪造）攻击**。如果不屏蔽 loopback 地址，攻击者（或受骗的 LLM）可以让 Agent 访问 `http://127.0.0.1` 或 `http://localhost`，从而绕过防火墙去攻击本机运行的服务（比如数据库、内部管理后台等）。屏蔽掉就杜绝了这种风险。

## File 协议是什么 **File 协议**（`file://`）是一种**本地文件访问协议**，允许浏览器或程序直接读取用户计算机本地文件系统中的文件。 **基本语法：** ``` file:///path/to/file ``` 比如在浏览器地址栏输入 `file:///C:/Users/README.txt`，就能直接打开本地的那个文件。 ### 为什么联网工具要禁止它？ 在 `web_fetch` 这类工具的安全策略里禁止 file 协议，核心原因是**防止 SSRF（服务端请求伪造）攻击**。 假设 LLM 被恶意 Prompt 诱导，引导 Agent 去访问： ``` file:///etc/passwd file:///C:/Windows/System32/config/sam ``` 如果没拦截，Agent 就会读取服务器本地的敏感文件（密码文件、配置文件、密钥等），并把内容返回给用户，造成严重的数据泄露。 所以安全策略规定：**只允许 http 和 https 协议，禁止 file 协议**，就是从源头上堵死这个攻击路径。 ### 和 http/https 的区别 | 协议 | 访问范围 | 安全风险 | |------|---------|---------| | `http://` / `https://` | 远程网络资源 | 有，但可控（可加白名单） | | `file://` | 本地文件系统 | 极高，一旦开放等于裸奔 | 一句话总结：**File 协议是本地文件系统的“后门”，联网工具必须把它拦住，否则 SSRF 攻击可以直接把服务器文件暴露给攻击者。**

## file 协议是什么 **file:// 协议**是浏览器和操作系统用于访问**本地文件系统**的协议。它允许你通过 URL 的形式直接读取本地磁盘上的文件。 ### 基本格式 ``` file:///C:/Users/xxx/文档/notes.txt # Windows 系统 file:///home/xxx/文档/notes.txt # Linux/Mac 系统 ``` ### 为什么联网工具要禁止 file 协议？ 和你引用的文章上下文相关——**防止 SSRF（服务端请求伪造）攻击**。 如果不禁止 file 协议，攻击者或恶意的 prompt 注入可能让 LLM 引导 Agent 去读取服务器本地文件，比如： | 攻击目标 | 示例 | |---------|------| | 读取系统密码 | `file:///etc/passwd` | | 读取密钥文件 | `file:///home/app/.ssh/id_rsa` | | 读取数据库配置 | `file:///app/config/database.yml` | **这不是 LLM 的错**，web_fetch 工具如果支持 file 协议，就相当于给攻击者开了一扇门——"只要骗过 LLM 生成这个 URL，就能拿到服务器的敏感文件"。 所以安全策略里明确：**只允许 http 和 https，禁止 file 协议**，从根本上封堵这条攻击路径。这是 Web 安全里最基本的外围防御手段。

这个问题核心在于 **SSRF（服务端请求伪造，Server-Side Request Forgery）** 安全攻击防护。 Agent 本质上是一个运行在用户环境中的“执行器”，它接收 LLM 的决策去发起网络请求。如果不加限制，攻击者（或恶意提示词）可以利用 LLM 诱导 Agent 访问内网服务，造成以下严重后果： **1. 内网资产探测与信息泄露** 内网通常运行着数据库（MySQL/Redis）、配置中心、日志系统等敏感服务，这些服务默认无认证或只有弱密码。Agent 一旦访问 `http://10.0.0.1:6379`（Redis 默认端口），攻击者就能通过返回值推断内网拓扑和配置信息。 **2. 绕过防火墙横向移动** 企业防火墙通常只封锁外网入站流量，但对内网出站流量管控较弱。Agent 运行在内部环境，它发出的请求被视为"可信流量"，可以直接触达防火墙后面的内网服务，形成攻击跳板。 **3. 云服务元数据泄露（云上最致命）** 云服务器的内网地址 `http://169.254.169.254/latest/meta-data/` 能返回云平台的临时密钥（AK/SK）。一旦 Agent 被诱导访问这个地址，云服务的关键凭据就直接暴露了，攻击者可以用这些密钥操作整个云账号。 这就是为什么 `web_fetch` 工具要**硬编码屏蔽内网地址段**（10.x、192.168.x、172.16-31.x 以及 loopback 地址）并**禁止 file 协议**——不是在代码层面给 LLM "建议"，而是直接在网络层拦截掉，不给任何犯错空间。

这是一个典型的安全问题，核心原因是**防止 SSRF（服务端请求伪造）攻击**。 简单来说，LLM 只是"决策者"，实际执行网络请求的是客户端 Agent。如果不加限制，攻击者可以通过精心构造的 Prompt，诱导 LLM 输出访问内网地址的指令，然后 Agent 就傻乎乎地去执行了。 具体风险有三点： 1. **内网信息泄露**：攻击者可以通过 LLM 让 Agent 去访问内网的管理后台、数据库、配置中心等敏感服务，把返回的数据（如数据库密码、配置信息）带出来。 2. **横向移动**：Agent 一旦能访问内网，就可以探测内网里还有哪些机器、开了哪些端口、跑了哪些服务，为后续攻击铺路。 3. **执行破坏性操作**：如果内网里有未鉴权的管理接口（比如直接删库、重启服务器的 API），LLM 一句话就能让 Agent 去触发。 所以在设计工具时，安全策略必须包含五道防线： - **协议白名单**：只允许 `http` 和 `https`，禁止 `file`、`ftp` 等协议 - **地址黑名单**：屏蔽 `10.x`、`192.168.x`、`172.16-31.x` 等内网段和 `127.0.0.1` 回环地址 - **超时控制**：30 秒超时，防止长时间等待 - **响应大小限制**：5MB 上限，防止内存撑爆 - **频率限制**：每分钟 30 次，防止被滥用 一句话总结：**LLM 只能决策"用什么工具"，但 Agent 要对"访问了哪里"负责。** 安全是 Agent 工程里不可逾越的红线。

这段文字中提到的 **enum**，在 Function Calling 的 JSON Schema 中起的是 **值域约束** 的作用。 具体来说，它的作用有三点： 1. **限定参数的可选值**：如果某个参数（如 `language`、`project_type`）只接受几个固定的取值（如 `java`、`python`、`node`），用 `enum` 就能把这些合法值明确列出来。 2. **防止 LLM 自由发挥**：不加 `enum` 时，LLM 可能会生成 `Java`（首字母大写）、`Python3`、`Node.js` 等变体。尽管语义相同，但后端解析时可能因为大小写或格式不匹配而直接报错。加上 `enum` 后，LLM 生成 tool_call 时会严格从 enum 列表里选值，不会自由发挥。 3. **保证后端兼容**：后端逻辑通常是按固定字符串匹配的。通过 `enum` 约束，前端（Agent）传递给后端的参数值一定是后端期望的格式，避免因参数格式不一致导致执行失败。 **总结**：enum 的作用就是**给 LLM 一个明确的选项列表**，告诉它"只能从这几个值里面选"，从而提高 tool call 的准确率和系统的稳定性。

这里 `enum` 的作用是**为参数限定一个严格的可选值列表**。 在 LLM Function Calling 的场景中，不加 `enum` 时，LLM 会"自由发挥"——它可能生成一个不在预期范围内的值，或者大小写不一致（例如你期望 `"java"`，它可能输出 `"Java"` 或 `"JAVA"`）。后端收到这些不合规的参数值，无法匹配预先定义的业务逻辑，直接报错。 加了 `enum` 约束后，JSON Schema 明确告诉 LLM：**这个参数只能从这几个值里选**。LLM 在生成参数时会受此约束，只能输出枚举列表中的某一个值，从而保证参数值的合法性和一致性，避免后端解析出错。