工具调用
工具调用
Agent 能“做事”，核心靠工具调用。
大语言模型本身不会真的运行命令、读取磁盘、访问网页。它只能根据上下文生成一段文本。工具调用把模型的“想法”接到外部执行环境里：模型决定调用哪个工具，宿主程序负责执行，执行结果再回到模型上下文中。
这一步让 Agent 从“给建议”变成“能验证”。
工具调用的基本链路
工具调用看起来像模型“自己在操作电脑”，但实际上每一步都经过宿主程序。宿主程序可以拒绝危险操作，也可以限制工具能访问的路径、网络和运行时间。
工具由什么组成
一个工具通常有三部分：名称、描述、参数。
{
"name": "read_file",
"description": "Read a text file from the local workspace.",
"parameters": {
"file_path": "string",
"offset": "number",
"limit": "number"
}
}对 Agent 来说，工具描述非常重要。模型不是通过“猜工具源码”来用工具，而是阅读工具说明后决定是否调用。说明写得模糊，Agent 就容易用错；参数设计不清楚，Agent 就容易构造无效调用。
模型、宿主和工具的分工
模型负责理解任务、选择工具、生成参数、阅读返回结果。
它不应该假装工具已经执行，也不应该把未验证的结果当事实。
宿主负责真正执行工具调用，校验权限，控制沙箱，把结果返回给模型。
宿主可以要求用户确认，也可以拒绝越权操作。
工具是具体能力，例如读文件、运行命令、搜索项目、请求网页、启动模拟器。
工具越强，越需要权限边界。
CTF 中常见工具类型
CTF Agent 常用的工具大致分几类。
| 工具类型 | 典型用途 | 风险点 |
|---|---|---|
| 文件读取 | 看题面、源码、输出文件 | 读取无关隐私文件 |
| Shell | 调用 file、strings、checksec、binwalk | 误删文件、长时间运行、外部扫描 |
| Python | 写脚本验证算法或解析数据 | 脚本错误、无限循环 |
| HTTP | 访问题目 Web 服务 | 越过授权范围、请求过量 |
| 搜索 | 在代码和日志里找关键词 | 被大量无关结果干扰 |
| Skill | 加载专业解题路线 | 选错 Skill 导致方向跑偏 |
注意
工具调用不是越多越好。每一次调用都应该服务当前判断。
工具结果如何进入上下文
工具返回的结果会进入模型上下文。比如运行：
file chall返回：
chall: ELF 64-bit LSB executable, x86-64模型才能据此判断：它可能是 Reverse 或 Pwn 题。
如果工具输出太长，宿主可能只返回一部分，或者模型只能看到摘要。因此 CTF 中常用“先小范围查看，再按需深入”的方式，而不是一次把全部日志塞进上下文。
工具调用与幻觉
有工具不代表没有幻觉。
Agent 仍然可能：
- 声称运行了实际没运行的命令
- 误读命令输出
- 忽略错误码
- 把失败脚本当成功
- 只看输出里符合自己猜测的部分
所以工具调用后必须看证据链：命令是什么，输出是什么，结论如何从输出推出。
ctf-skills 如何依赖工具调用
ljagiello/ctf-skills 的 Skill 经常会建议 Agent 使用某类工具。例如 Web 方向可能需要 HTTP 客户端和浏览器观察，Pwn 方向需要二进制分析工具，Forensics 方向需要取证工具。
Skill 不等于工具。Skill 只告诉 Agent “该做什么”；工具负责“真的做”。
可以这样理解：
Skill 给路线，Tool 给手脚，Agent 负责串起来。小结
工具调用让 Agent 可以把推理落到证据上。理解工具调用后，再看 MCP 和 Skill 就会清楚：MCP 解决工具怎么接入，Skill 解决任务怎么执行。