智能体开发入门：先搞懂 Function Calling，再谈别的

经常有刚学 Python 的朋友问我：现在满大街都在说 AI 智能体、Agent，我也想做一个，可是打开教程满屏都是框架、编排、多智能体协作，看得一头雾水，到底该从哪一步开始？

我的答案很简单：先别碰任何框架，把 Function Calling（函数调用）这一个概念搞懂，你就已经摸到智能体的门了。今天这篇文章，就把这一个概念掰开讲清楚，读完你能明白大模型是怎么「自己动手干活」的，还能亲手跑通一个 30 行的最小示例。

一、智能体到底是什么？一句话就够

网上对智能体的定义很多，什么感知、规划、记忆、工具调用，四大能力五大模块，新手看完更晕了。

其实用大白话说：智能体 = 大模型 + 手脚。

• 大模型本身只会聊天。你问它「北京今天多少度」，它只能含糊地说「建议查看天气预报」——因为它没有联网，它只有训练时见过的文字。
• 给大模型装上「手脚」，让它能去查天气接口、能去读写文件、能去调你写的函数，它就从「会说话」变成了「会干活」。

这个「手脚」，就是 Function Calling。

二、Function Calling 是怎么运转的？

这里有一个新手最容易搞错的地方，我先把它说破：

大模型本身不执行任何函数。 它只是「说」要调哪个函数，真正执行函数的是你写的程序。

整个流程像这样（一图看懂五步）：

三、30 行代码，亲手跑一遍

光看流程图还是虚的，我们用一段最小代码跑通它。下面用的是 OpenAI 兼容接口的写法（国内很多模型服务都兼容这个格式），只依赖标准库和一个客户端包：

from openai import OpenAI

client = OpenAI(base_url="你的模型服务地址", api_key="你的密钥")

# 第 1 步：告诉大模型有哪些函数可用
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询某个城市的天气",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"]
        }
    }
}]

# 第 2 步：假装这是你本地的真实函数
def get_weather(city):
    return city + "：晴，25 度"

# 第 3 步：把问题发给大模型
resp = client.chat.completions.create(
    model="你的模型名",
    messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
    tools=tools,
)
call = resp.choices[0].message.tool_calls[0]
print("大模型要求调用：", call.function.name, call.function.arguments)

# 第 4 步：你的代码真正执行，再把结果喂回去
result = get_weather(**eval(call.function.arguments))
print("函数返回：", result)

跑起来你会看到类似这样的输出：

大模型要求调用： get_weather {"city": "北京"}
函数返回： 北京：晴，25 度

就这么点东西。市面上所有智能体框架——不管包装得多花哨——最底层转的都是这个圈：发问题 → 模型点名函数 → 你执行 → 结果回喂 → 模型总结。

（为了示例短，上面用了 eval 解析参数；实际项目请用 json.loads，这是后话。）

四、新手最容易踩的三个坑

概念不难，但自己动手时，几乎每个人都会在同样三个地方摔一跤。我把它们列出来，你撞上的时候就不慌了。

坑一：参数是模型「编」出来的，不一定对。

大模型生成 {"city": "北京"} 靠的是概率，不是查询数据库。你问「北上广天气」，它可能给你拆成三个调用，也可能自作主张只查一个。所以函数返回的结果永远要自己校验一遍，别拿到就用——模型点的菜，端上桌前你要看一眼。

坑二：函数描述写得越含糊，模型错得越离谱。

description 就一行「查天气」，模型经常连参数都填错。把描述写清楚——「查询中国某城市未来 3 天的天气预报，输入城市中文名」——模型的调用准确率会明显上一个台阶。这一行描述，就是你在教模型用工具，值得花时间打磨。

坑三：一次调用往往不够，要多绕几圈。

查完天气，用户可能接着问「那适合穿什么」。这时模型还要再走一遍「点名函数 → 你执行 → 回喂」的圈。很多新手以为一次请求就完事了，结果程序跑一轮就停。正确的做法是把所有消息放进同一个列表里循环发，直到模型不再要求调函数、直接给出最终回答为止。

五、学会这个之后，为什么还是做不出像样的智能体？

到这里你会发现：Function Calling 本身一点都不难，30 行就跑通了。那为什么市面上大部分自学的人，卡在这一步之后就一直做不出像样的东西？

因为从「会调一个函数」到「能交付一个智能体」，中间还隔着好几层，每一层都藏着前面说的那种坑：

• 多步任务的规划：一个「帮我对账」的任务要连续调五六个函数，中间某一步失败怎么办？是重试、跳过还是停下来问人？
• 上下文管理：对话越长，token 消耗越凶，哪些历史该留着、哪些该扔，直接关系到成本和效果。
• 可控性：模型偶尔会「自由发挥」调一个你没预期的函数，生产环境里这就是事故。怎么给它画跑道，是门手艺。

这些东西，看文章能看懂原理，但自己摸的时候，报错了都不知道是环境问题还是代码问题，更不知道做到什么程度算够。就像学游泳，看一百个教学视频，下水还是会呛水——有人带着圈划出来给你看，跟自己扑腾，完全是两种进度。这一行知识密度高、坑也密，系统化的课程存在的意义，就是把前人踩过的坑提前摆到你面前：哪些概念必须先打底、每个阶段该做出什么能跑的东西、报错时往哪个方向排查，都有现成的路径可循，比自己一个个试错要顺不少。

你可以去看看这类的培训机构，比如誉天教育，它的智能体开发课程是按这个思路教的：从工具调用的底层机制起步，一路讲到产品级智能体，课程内容包括工具调用、多智能体协作等进阶内容。感兴趣的可以把纲要要来，对照前面那几条坑看看覆盖了多少。

六、最后

总结一下今天这一篇：

1. 智能体 = 大模型 + 手脚，这个「手脚」就是 Function Calling；
2. 大模型只「点名」函数，真正执行的是你的代码，结果要喂回去才能形成闭环；
3. 三个高频坑：参数靠校验、描述要写细、调用要循环。

为什么你的智能体聊到第十轮就开始胡说八道、费用还翻倍。感兴趣的可以关注一下，我们评论区见。