企业官网建设流程全解析

这两年我对 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("fmt""io""net/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

产生 SQL：

SELECTDATE(created_at)ASday,COUNT(*)AStotalFROMusersWHEREcreated_at>=NOW()-INTERVAL7DAYGROUPBYDATE(created_at)ORDERBYday;

数据库返回：

2026-08-16 128 2026-08-17 156 2026-08-18 181 ...

AI 再帮我：

总结趋势 计算环比 找异常 画图

这就比传统 BI 更自然。

十一、但我不会给 AI 无限数据库权限

Tool Calling 最大的问题之一其实不是：

技术做不做得到

而是：

权限

比如给 AI 一个：

execute_sql

Tool。

然后什么 SQL 都允许执行：

DROPDATABASEproduction;

那肯定不行。

所以如果让我设计，我会拆成：

query_database

默认：

Read Only

或者限制：

SELECT

而下面这些操作：

DELETE UPDATE DROP TRUNCATE

需要：

更高权限 + 人工确认

我认为未来 Agent 开发一个很重要的方向就是：

不是 Tool 越多越好，而是权限设计越合理越好。

十二、服务器运维也是非常好的 Tool Calling 场景

这是另一个我自己非常容易用到的地方。

平时维护服务器经常遇到：

504 502 Docker 容器退出 Nginx 配置错误 磁盘满 CPU 高 连接数异常 日志报错

传统排错：

dockerps

dockerlogs

top

df-h

free-h

journalctl

nginx-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 项目 最新发布

这些变化非常快。

十四、我为什么很关注 MCP？

Tool 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 Calling：

AI 再聪明

很多时候也只是：

一个会说话的大脑

有了 Tool：

AI 才真正拥有手和脚。

十九、为什么我越来越关注 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 与开源，持续探索如何把技术做成产品，把产品转化为真实价值。