这两年我对 AI 的使用方式发生了一个非常明显的变化。最开始我把 ChatGPT、Claude、DeepSeek 这些大模型当成一个更聪明的搜索引擎 一个随时可以问问题的人后来开始用 AI 写代码它变成了程序员的 Copilot而现在我越来越少把 AI 当成一个单纯的聊天机器人。我更愿意把它理解成一个可以调度各种工具替我完成任务的执行者。这里面有一个非常重要的能力Tool Calling如果你正在研究 AI Agent、MCP、Codex、Claude Code或者各种自动化工作流那么 Tool Calling 基本上是一个绕不过去的概念。今天这篇文章我不准备只讲 Tool Calling 的理论。我想结合自己目前真正使用 AI 的方式聊聊王仕宇是怎么使用 AI Tool Calling 的。一、以前我怎么使用 AI最早的时候使用 AI 基本都是这种模式我 ↓ 输入问题 ↓ ChatGPT ↓ 输出一段文字比如帮我写一个 Go 的 HTTP Client。AI 返回代码packagemainimport(fmtionet/http)funcmain(){resp,err:http.Get(https://example.com)iferr!nil{panic(err)}deferresp.Body.Close()body,err:io.ReadAll(resp.Body)iferr!nil{panic(err)}fmt.Println(string(body))}然后接下来还是我自己复制代码 ↓ 打开 IDE ↓ 创建文件 ↓ 粘贴进去 ↓ 运行 ↓ 发现报错 ↓ 复制错误 ↓ 重新问 AI本质上 AI 做的是生成答案而不是完成任务这两个看起来很像实际上完全不是一回事。二、Tool Calling 改变了什么现在我可能直接对 AI 说帮我看看这个 Go 项目为什么启动失败。如果只是普通 ChatGPT它只能说请把报错贴给我。但一个拥有 Tool Calling 能力的 AI可以自己查看项目文件 ↓ 读取 go.mod ↓ 查看配置文件 ↓ 执行 go run ↓ 读取错误日志 ↓ 搜索错误位置 ↓ 修改代码 ↓ 再次运行 ↓ 确认问题是否解决这时候 AI 就已经不是Chat而更接近Agent这里真正关键的地方就是模型拥有了一批Tools例如read_file write_file search_file run_command git_diff web_search browser database generate_image generate_video模型根据当前任务决定什么时候调用工具 调用什么工具 传入什么参数 根据结果下一步怎么办这就是我现在使用 AI 的核心方式。三、我现在越来越少“让 AI 给我代码”这是我的一个非常明显的变化。以前我经常问帮我写一个 Docker Compose。然后 AI 给我services:mysql:image:mysql:8.0environment:MYSQL_ROOT_PASSWORD:passwordports:-3306:3306接下来还是自己复制。而现在我更希望 AI直接查看当前项目 ↓ 判断项目需要什么 ↓ 创建 docker-compose.yml ↓ 检查已有端口 ↓ 运行 Docker Compose ↓ 检查容器日志 ↓ 发现问题以后继续修改也就是说我越来越喜欢给 AI目标而不是某一小段代码要求比如以前给我写一个 Nginx 配置。现在把这个项目部署到服务器 域名使用 xxx.com 服务运行在 3000 端口 配置 HTTPS 和 SSE 然后检查配置有没有问题。区别非常大。第一个是生成文本第二个是完成一个任务四、我在 AI 编程里大量使用 Tool Calling这是我现在 Tool Calling 使用最多的地方。我日常会接触Go Python Node.js Vue Docker Nginx MySQL Redis MongoDB Cloudflare以前遇到项目问题大概是我自己定位 ↓ 找到文件 ↓ 复制代码 ↓ 发给 AI ↓ AI 给修改建议 ↓ 自己修改现在有 Codex、Claude Code 这类 Agent 工具以后我更倾向于AI 自己读取仓库例如我说帮我给这个项目增加 MongoDB 支持。Agent 可以先list_files发现config/ internal/ model/ repository/ service/ go.mod接着读取go.mod config.yaml repository/user.go main.go然后判断项目结构。接下来可能自动添加 Mongo Driver ↓ 增加 MongoDB 配置 ↓ 写初始化代码 ↓ 创建 Repository ↓ 更新依赖 ↓ 运行 go test这些步骤每一步实际上都在调用工具。五、一个 AI 编程 Agent 背后可能有哪些 Tool简单模拟一下。一个编码 Agent 可能拥有{tools:[{name:read_file},{name:write_file},{name:list_directory},{name:search},{name:run_command},{name:git_diff}]}当我说帮我修一下登录接口的 Bug。模型可能先调用{name:search,arguments:{query:Login}}然后找到internal/handler/login.go internal/service/login.go再{name:read_file,arguments:{path:internal/service/login.go}}然后执行{name:run_command,arguments:{command:go test ./...}}发现panic: invalid memory address修改{name:write_file,arguments:{path:internal/service/login.go,content:...}}最后go test ./...通过。你会发现模型本身其实并没有“神奇地控制电脑”。真正让它能够操作项目的就是这些 Tool。六、我也在用 Tool Calling 做图片生成除了编程我现在做内容时也大量用 AI 图片。比如我要写一篇Go Context解决协程泄漏与超时控制以前我的流程是写文章 ↓ 想封面 ↓ 打开生图网站 ↓ 写 Prompt ↓ 生成 ↓ 下载 ↓ 放入文章现在我的理想流程变成文章生成完成 ↓ AI 分析文章核心知识点 ↓ 调用图片 Tool ↓ 生成知识总结图 ↓ 自动得到图片比如我只需要说根据这篇文章画一张总结图。模型先理解文章。然后调用generate_image把标题 知识结构 视觉风格 尺寸 个人信息全部转换成图片生成参数。所以我现在越来越喜欢把生图也做成 Agent Tool。七、图片 Skill 本质上也是 Tool Calling我之前也在做自己的 AI 生图 Skill。从最终体验来看我希望它是这样的用户 帮我给这篇文章配一张图Agent读取文章 ↓ 判断适合什么图 ↓ 生成 Prompt ↓ 调用图片 API ↓ 拿到图片 URL ↓ 下载图片 ↓ 返回本地文件真正执行生图的还是图片模型 API但是大模型决定了该不该生成 生成什么 用哪个模型 如何组织 Prompt这就是LLM Tool八、视频生成也是同样的逻辑AI 视频也是我现在比较关注的一类工具。比如帮我生成一个 4 秒钟的动物世界视频一只猎豹在草原追逐羚羊。大模型负责理解主体 场景 镜头 动作 光影 视频长度 画面风格然后调用generate_video真正的视频可能由Kling 即梦 Grok Imagine MiniMax 其他视频模型完成。流程自然语言 ↓ LLM ↓ Prompt 编排 ↓ Video Tool ↓ Video API ↓ 任务 ID ↓ 查询任务状态 ↓ 获取视频 ↓ 下载注意这里已经不是只调用一次 Tool 了。而是create_video ↓ get_video_status ↓ download_video多个 Tool Calling 串联。这就是一个很典型的 Agent 工作流。九、我特别看好“AI API”我自己本身做后端比较多。所以在我看来任何已有 API 的系统理论上都非常适合接入 AI。比如一个传统后台里已经存在GET /users GET /orders POST /orders POST /refund GET /statistics过去这些 API 是给Web App 小程序使用。未来完全可以包装成Tools比如get_user get_order create_order refund_order get_statistics于是管理员可以直接问 AI今天退款金额超过 500 元的订单有多少AI调用 get_statistics ↓ 拿到订单 ↓ 筛选 ↓ 汇总 ↓ 回答接着你说把金额最大的 10 个订单列出来。Agent 再调用 Tool。甚至给这 10 个订单的负责人分别发消息确认。又继续调用send_message这就是我认为 Tool Calling 特别有价值的一点它可以直接复用我们已经存在的大量后台能力。十、数据库是我很看好的一个 Tool我自己做项目经常使用MySQL Redis MongoDB SQL Server过去要查业务数据登录服务器 ↓ 进入数据库 ↓ 写 SQL ↓ 复制结果 ↓ 分析以后完全可能变成帮我查一下最近 7 天每天新增用户数量。AI 调用query_database产生 SQLSELECTDATE(created_at)ASday,COUNT(*)AStotalFROMusersWHEREcreated_atNOW()-INTERVAL7DAYGROUPBYDATE(created_at)ORDERBYday;数据库返回2026-08-16 128 2026-08-17 156 2026-08-18 181 ...AI 再帮我总结趋势 计算环比 找异常 画图这就比传统 BI 更自然。十一、但我不会给 AI 无限数据库权限Tool Calling 最大的问题之一其实不是技术做不做得到而是权限比如给 AI 一个execute_sqlTool。然后什么 SQL 都允许执行DROPDATABASEproduction;那肯定不行。所以如果让我设计我会拆成query_database默认Read Only或者限制SELECT而下面这些操作DELETE UPDATE DROP TRUNCATE需要更高权限 人工确认我认为未来 Agent 开发一个很重要的方向就是不是 Tool 越多越好而是权限设计越合理越好。十二、服务器运维也是非常好的 Tool Calling 场景这是另一个我自己非常容易用到的地方。平时维护服务器经常遇到504 502 Docker 容器退出 Nginx 配置错误 磁盘满 CPU 高 连接数异常 日志报错传统排错dockerpsdockerlogstopdf-hfree-hjournalctlnginx-t以后完全可以定义get_server_status get_docker_status get_logs restart_container test_nginx reload_nginx然后直接说帮我看看 api 服务为什么 502。AI 自己检查 Nginx ↓ 检查 upstream ↓ 检查 Docker ↓ 查看日志 ↓ 发现 3000 端口没启动 ↓ 检查对应容器如果权限允许重启容器 ↓ 再次 curl ↓ 确认恢复这就是一个真正能干活的运维 Agent。十三、Web Search 也是一种 Tool很多人没有意识到联网搜索本身也是 Tool Calling。比如我问MongoDB 8.3 最近更新了什么模型训练数据不一定包含最新资料。它就应该search_web ↓ 打开 MongoDB 官方文档 ↓ 读取 Release Notes ↓ 总结而不是依靠模型参数里的旧知识我现在做技术内容一个非常明显的变化就是越来越多内容必须“模型 搜索”而不是只靠模型。特别是模型版本 软件版本 价格 API 新功能 GitHub 项目 最新发布这些变化非常快。十四、我为什么很关注 MCPTool Calling 解决的是AI 怎么调用工具但还有另一个问题这么多工具到底怎么接到不同的 AI 上比如我自己写了MongoDB Tool 图片 Tool 视频 Tool GitHub Tool 数据库 Tool如果Codex Claude Code Cursor OpenCode ChatGPT全部使用不同协议。那每个都重新开发一遍很麻烦。所以 MCP 出现以后我觉得它非常值得关注。我的理解很简单Tool Calling AI 使用工具的能力 MCP AI 连接工具的一种标准未来我更希望我的服务 ↓ MCP Server ↓ 暴露 Tools ↓ 不同 Agent 都可以使用而不是每个平台单独做一套插件十五、我理想中的 AI 使用方式我认为 AI 最终不应该变成一个越来越大的聊天框而应该越来越像一个任务调度中心比如我未来希望直接说写一篇 MongoDB 的文章然后给它生成一张总结图检查里面的 MongoDB 命令是否有明显问题最后整理成适合发布的版本。这句话背后可能发生读取已有内容风格 ↓ 搜索 MongoDB 官方资料 ↓ 生成文章 ↓ 校验关键命令 ↓ 生成图片 ↓ 处理图片 ↓ 生成最终 Markdown这里面可能连续调用Memory Tool Web Search Image Tool File Tool Code Tool但是对我来说我只需要提供目标这才是我真正期待的 Agent。十六、Tool Calling 以后人最重要的能力是什么我认为不是记住更多命令也不是学会更多软件按钮而是知道自己想要什么因为以前使用软件你需要知道第一步点哪里 第二步点哪里 第三步输什么 第四步怎么保存未来使用 Agent告诉它目标Agent 自己调 Tool。所以人的角色逐渐变成目标制定 ↓ 结果判断 ↓ 风险判断 ↓ 最终决策这也是为什么我一直认为AI 越强判断力反而越重要。十七、但我并不认为 Agent 可以完全放任我现在比较认同的一套方式是低风险任务 AI 自动执行 中风险任务 AI 执行 日志 高风险任务 AI 提方案 人确认比如可以自动执行读取文件 搜索代码 查询数据库 搜索网页 生成图片 生成草稿 运行测试可以执行但需要记录修改代码 部署测试环境 创建文件 修改配置最好人工确认删除生产数据 退款 转账 删除服务器 修改 DNS 发布生产环境 批量发送消息真正成熟的 Agent不应该只是能调用 Tool而应该知道什么时候不能直接调用 Tool十八、我现在怎么理解 AI Agent如果用一个比较简单的公式我会写成AI Agent LLM Tool Calling Memory Planning Environment其中LLM负责理解和推理。Tool Calling负责做事情。Memory负责记住过去。Planning负责拆任务。Environment可能是电脑 浏览器 服务器 代码仓库 数据库 企业系统 互联网如果没有 Tool CallingAI 再聪明很多时候也只是一个会说话的大脑有了 ToolAI 才真正拥有手和脚。十九、为什么我越来越关注 Harness最近我也越来越关注一个词Harness可以简单理解为给大模型提供一套运行环境和工具系统。同一个模型DeepSeek Claude GPT Gemini如果只是放进聊天框能力是一种表现如果放进Codex Claude Code OpenCode 其他 Agent Harness表现可能完全不同。为什么因为 Harness 给模型增加了文件 Shell 代码执行 Git 搜索 Memory Tool Calling所以我现在越来越觉得未来比拼的不只是“谁的模型参数更多”还包括“谁给模型配的工具更好”。二十、我的 Tool Calling 使用方式正在发生一个变化我目前明显在从使用别人做好的 AI 工具逐渐走向给 AI 做自己的 Tool比如图片生成 视频生成 API 代码操作 服务器管理 数据库查询 内容生产以前我调用 API以后AI 帮我决定什么时候调用 API这中间只多了一层LLM但是整个交互方式发生了非常大的变化。二十一、一个非常值得程序员关注的机会我认为 Tool Calling 对程序员特别重要。为什么因为过去我们写了大量API SDK CLI 后台系统 微服务 数据库接口这些东西其实天然就可以变成AI Tools过去是程序调用程序现在变成人说一句话 ↓ AI 理解 ↓ AI 调用程序所以很多旧系统不需要推倒重做。你完全可以在上面加一层AI Agent让现有能力通过自然语言暴露出去。我觉得这会带来大量新的产品机会。二十二、如果让我重新学习 AI我会怎么学如果现在让我重新开始我不会只学Prompt而会按照下面的顺序LLM API ↓ Structured Output ↓ Tool Calling ↓ MCP ↓ Memory ↓ RAG ↓ Agent ↓ Multi-Agent其中我会特别重视Tool Calling因为从这里开始大模型第一次真正从“会回答”跨到了“会行动”二十三、最后过去我们评价一个 AI最常问的是这个模型聪不聪明以后我觉得还要增加一个问题这个 AI 能用什么工具因为一个模型再聪明如果它只能输出文字很多任务最终还是得你自己完成。而一个拥有文件工具 浏览器 搜索 Shell Git 数据库 图片 视频 支付 企业 API的大模型即使模型本身没有发生变化它的实际价值也可能完全不同。所以我现在使用 AI越来越少关注“让 AI 给我一个答案。”而越来越关注“怎么让 AI 把这件事情做完。”这也是我理解 Tool Calling 最简单的一句话Tool Calling就是让大模型从会说话开始真正拥有做事的能力。模型负责理解 判断 推理 决策Tool 负责搜索 读取 执行 修改 查询 生成 操作二者结合才逐渐形成我们今天所说的AI Agent我认为未来真正有价值的 AI 应用很可能并不是再做一个聊天框。而是把真实世界里那些已有的 API、软件、数据和工作流全部变成 AI 可以调用的 Tool。到了那个时候我们和软件之间的交互方式也许真的会从学习软件怎么用逐渐变成告诉 AI 我想做什么。现在是最好的时代。中国有全世界最高性价比的制造业有发达的网络和全球物流。只要你愿意你几乎可以买到这个世界上任何地方生产的、任何你想要的商品。你可以用很低的成本撬动全球的资源为你服务。不过真正稀缺的从来不是商品而是注意力、判断力以及把事情做成的能力。所以这是最好的时代也是最坏的时代。我是王仕宇关注 AI、Web3 与开源持续探索如何把技术做成产品把产品转化为真实价值。