话说回来，

Agent不会干活？我给它加了3个工具，从FC到MCP一条线看透工具链进化

昨晚凌晨我跑通了一个能调3种工具的 Agent——查天气、查数据库、读文件。不过，跑通那一刻才真正理解一件事：LLM自己啥也干不了它只会下工单。 你的代码才是干活的人。

新鲜道理，但手敲代码跑通闭环后感受完全不一样。之前看文档觉得 FC 挺简单——定义函数、注册 tool、两轮对话，概念三步就完了。其实，实际写的时候踩了4 个坑还有一个是中文数据库的 charset 问题。排查半小时才定位到根因，

今天把完整过程写出来从 FC 本地调函数到 MCP 协议通信，一条线看透 Agent 工具链是怎么从“一个人干活”进化到“团队协作”。

至于第一个工具，天气 API。跑通 FC 闭环

痛点：很多同学在实现 Function Calling 时只写了“查询天气”几个字的 description，导致 LLM 把所有涉及天气的话都误认为要调接口。

工具链的起点是 Function Calling。原理我之前学过——LLM 不调用函数，它只输出 tool_calls 意图。你的代码拿到意图执行后喂回去，LLM 才生成最终回答。两轮对话，LLM 只决定 “调什么、传什么参数”。

这次我把它跑通了。用 的免费天气 API，写了个 get_wear 函数，注册成 FC tool，让 LLM 决定什么时候调：

tools =
}
}
}]

问 “北京今天天气怎么样”。LLM 输出 get_wear代码执行拿到 “°C 晴 湿度24%”，喂回去，LLM 生成 “北京今天晴，30 度，湿度较低比较干燥”。

问 “帮我写个快排”——LLM 直接回答，不调工具。判断正确，

关键设计点： Description 字段是 LLM 决策的唯一依据。 写清楚比写花哨关键。如果你只写 “查天气” 三个字，LLM 可能把 “帮我查一下明天穿什么” 也理解成要调天气工具。写成 “查询指定城市的当前天气信息”，它就知道什么时候该调什么时候不该调。

说到第二个工具，MySQL 查询。踩了中文 charset 的坑

痛点：

• LLM 生成的 SQL 看似正确，却因为字符集问题返回空结果，让人怀疑模型到底懂不懂中文。其实，
• 在 Docker 环境里插入中文数据时默认 charset 为 latin1。这种隐蔽错误常被忽略，

天气 API 跑通后我让 Agent 查 MySQL 数据库。其实，思路一样——定义 query_database 函数。注册成 tool，LLM 生成 SQL，代码执行返回结果。不过，

Agent 问 “工程部有几个员工？ 平均薪资多少，” LLM 生成的 SQL 完全正确：

SELECT COUNT FROM employees WHERE department = '工程部';

• Docker 内直接使用 mysql 命令行查询，一切正常；Python 连库查询却返回空。
• Docker exec 插入中文数据时 client charset 默认 latin1，导致中文被双重 UTF‑8 编码。
• # 示例 HEX 对比：
  • E5B7A5E7A88BE983A8
  • C3A5C2B7C2A5C3A7C2A8E280B9C3A9C692C2A8

1. 删表重建前执行
2. Pythonn 连接时显式指定 charset：

conn = mysql.connector.connect(
host="localhost"。port=3306,user="root",password="llm_learn_2026",database="llm_learn",charset="utf8mb4" # 必须加，否则中文 WHERE 匹配不到
)

This pitfall is especially sneaky for Agent‑DB projects—SELECT * 能看到所有行，但 WHERE 中文条件永远匹配不到。说起来，如果你在做 Agent + 数据库的项目，请记住："中文数据库必须全程统一使用 utf8mb4".

if not re.match:
return "错误：只允许 SELECT 查询。禁止 INSERT/UPDATE/DELETE/DROP"
sql = sql.split.strip # 截断分号防注入

L​LM 生成的 SQL 并非基本可信；没有这层校验，一句 DROP TABLE 就可能毁库。话说回来，这是 Agent 安全的第一道防线——**工具函数自己做输入校验。不指望 LLM 自觉**。怎么说呢，

从第三个工具来看，MCP Server，自描述才是真进化

Pain point：

• MCP 看起来高大上。却不知道如何让 Server 自动暴露能力，让 Client 无需硬编码 tool 列表。
• MCP 的自描述机制如果不使用合适装饰器，会 陷入“每换一个功能必须改代码”的死循环。

、返回格式怎样，无需硬编码。

I 用 Python 的 FastMCP 库实现了一个文件程序 Server，两项功能：list_files和 read_file。Server 代码极简：

from mcp.server.fastmcp import FastMCP
mcp = FastMCP
@mcp.tool
def list_files -> str:
"""列出指定目录下的所有文件和子目录名称"""
# 实现省略
@mcp.tool
def read_file -> str:
"""读取指定文件的文本内容，限制返回前500行"""
# 实现省略
mcp.run

@mcp.tool 注解自动把函数名、参数、docstring 打包成 MCP 的 tool schema。 代表着 Agent 通过标准输入输出管道与 Server 通信，不需要打开 HTTP 端口。

The log after client connects:

Server 暴露了以下工具：
- list_files: 列出指定目录下的所有文件和子目录名称
- read_file: 读取指定文件的文本内容。限制返回前500行

能力，只要连上就能发现并调用。

MCP 调用方式与 FC 不同：

• FC：`tool_map` —— 本地函数调用，同进程内硬编码映射。
• MCP：`client -> stdio pipe -> server` —— 基于协议通信。可独立部署在不同机器上，实现热加载新工具而无需改动 Client 代码。说起来，

文件”和“读取 wear_agent.py 内容”。LLM 自动选择调用 list_files 或 read_file，并传递正确参数。整个闭环仍然是两轮对话，但工具发现与调用方式彻底不同，更加解耦、更易

FC 到 MCP：一条进化线

安全性Tool 函数自行校验Server 可统一做权限校验&审计  团队协作个人脚本式服务化 + 多 Agent 协作

维度	FC 本地调用	MCP 协议通信
工具发现	硬编码 tool 定义	Server 自描述
调用方式	本地函数调用	STDIO / SSE 协议
性	加新工具要改代码	Server 热加载，新 Tool 就可以使用
部署形态	同进程	独立进程 / 跨机器

从概念映射示例来看。

• FC ≈ Spring @RequestMapping
• MCP ≈ 微服务 RPC

更远一步 — 四层演进路线:

层级	名称	特征	类比
1	Function Calling	本地硬编码	Spring MVC
2	Multi‑Channel Protocol	Server 自描述+协议交互	微服务 RPC
3	Skills	可复用·可热加载·可分享	Spring Boot Starter
4	Agent‑to‑Agent	多 Agent 协作·消息队列·自治	Kafka / Service Mesh

四个踩坑

PITFALL	根因	解决办法
"中文WHERE匹配不到"	"Docker exec 插入时 charset=latin1 双重 UTF‑8 编码"	"SET NAMES utf8mb4；Python connector 加 charset=utf8mb4"
"第二轮未传 tools 参数"	"create 请求忘记带 tools 参数"	"第二轮 create 时一样传 tools=tools"
"Tool description 太模糊"	"LLM 无法区分何时应调何时不应调"	"description 写成完整业务意图与参数说明"
"Docker exec 插中文数据损坏"	"容器默认字符集不一致"	"统一使用 utf8mb4，从插入到查询全程保持"

Agent 工具链主要原则

• Description 要精确: LLM 完全依赖 description 决策何时调用哪项能力。
• S安全要自校验: Tool 本身必须防注入、防越权，不指望 LLM 主动遵守。
• S协议要解耦: MCP 的自描述机制让 Client 与 Server 完全脱钩，可独立演进。

下一篇预告这方面，Agent 安全与容错策略 🚀

---