大模型 API 是什么

AI 已经渗透到运维的各个环节了——日志分析、告警降噪、故障定位、配置审计、文档生成，都在引入大模型能力。作为运维人员，不需要转行做 AI 算法，但得学会怎么在脚本里调用大模型 API，让它帮着干活。这就是 AIOps 的实践层面：用 AI 能力增强日常运维效率。

好在 Python 调大模型 API 跟调普通接口本质上是一回事：准备输入，带上 key，发请求，拿结果。区别在于普通接口通常返回固定字段——天气接口传城市名返回温度，大模型接口传一段文字和一段要求，返回的可能是总结、JSON、分类结果，或者告诉程序它想查某个工具。

一、一次调用里有什么

调大模型 API 最少会碰到几个东西。

API Key 是身份凭证，不能写死在代码里，通常放到环境变量里，跟数据库密码、平台 token 是一类。

model 选哪个模型。不同模型的速度、价格、上下文长度、推理能力不一样。刚开始先固定一个能跑通的，把请求和返回弄明白。

input 是这次真正要模型处理的内容——一段文章、一份待办清单、一段用户反馈。

instructions 是稳定要求，比如"用中文回答""只返回 JSON""不要编造不存在的字段"。要求放得越清楚，后面脚本越好接。

一个普通接口长这样：

GET /weather?city=beijing

大模型接口更像：

输入:
今天要做三件事:买菜、写周报、回复邮件。

要求:
把这段话整理成待办清单,每项只保留动作。

返回可能是：

- 买菜
- 写周报
- 回复邮件

从脚本角度看，这里已经有几个问题：返回是 Markdown 还是 JSON？如果模型多说一句废话怎么办？如果待办里有日期、优先级、负责人，要不要拆字段？这些后面都会变成代码问题。

二、提示词

Prompt 就是给模型看的任务说明。

写得太短，模型只能猜：

整理一下

这句话基本没法稳定工作——整理成什么？摘要、表格、标题、待办还是分类？模型可能每次都按自己的理解来。

写清楚一点：

把下面这段文字整理成待办清单。
只保留具体动作,不要解释。

文字:
今天下午先买菜,晚上写周报,睡前记得回复小王邮件。

这个就稳定多了。提示词里通常会分两类内容：要求（让模型怎么处理）和材料（让模型处理什么）。这两个最好分开写，后面用 Python 拼字符串时结构清楚，不容易乱。

三、模型只看得到请求里的内容

模型不会自动知道本地文件里有什么，也不会自己翻数据库。Python 没把内容读出来塞进请求，模型就看不到。

比如本地有个 notes.txt，里面写着一堆会议记录。脚本只问"帮我总结 notes.txt"，模型并不会神奇地打开这个文件。正确做法是 Python 先读文件，再把文件内容放进请求里。

这个点容易忽略——平时用聊天页面会觉得模型什么都能答。但写 API 脚本时，模型看到什么完全取决于这次请求给了什么。

四、token 和长度限制

大模型不是按"几个字"算长度，而是按 token——中文、英文、标点、代码都会被拆成 token。输入占 token，输出也占 token。

材料不能无限塞。一本 100 页的文档、一大堆聊天记录、很多篇 FAQ，全放进一次请求里迟早会超限制，费用也会很高。所以 Python 调模型前经常要先做一层整理：只截取相关段落、删除重复内容、把太长的文本切成几段、先检索再把最相关的几段发给模型。

五、返回文本还是 JSON

模型最容易返回的是一段自然语言：

这段文字主要在说三个待办:买菜、写周报、回复邮件。

人看没问题，脚本接着处理就麻烦——脚本想知道有几条待办，要么再解析这句话，要么靠字符串切割硬猜，很不稳。

更适合程序处理的是固定 JSON：

{"items": [{"title": "买菜"}, {"title": "写周报"}, {"title": "回复邮件"}]}

Python 直接 json.loads()，后面写文件、入库、渲染页面都方便。只要结果后面还要交给程序处理，就尽量让模型返回固定结构。

六、工具调用

模型自己不会查文件、查数据库、查网页。工具调用就是让模型告诉 Python："我需要调用这个函数，参数是这些。"

模型做判断，Python 做动作。一个中性工具可以是查联系人：

工具名: find_contact
参数:
  name: 联系人姓名
返回:
  电话、邮箱、备注

用户问"帮我看看张三的邮箱是多少"，模型判断自己缺少联系人数据，于是请求调用 find_contact(name="张三")。Python 执行这个函数，把结果交回去，模型再组织回答。

动作一定要握在 Python 这边，尤其是会修改文件、发消息、调用外部系统的动作。

七、检索

有些资料太长，不能每次都全部塞给模型。Embedding 就是把文本变成一串数字，让程序能按"意思相近"去找内容。

比如有一批 FAQ——"忘记密码怎么办""如何修改邮箱""发票在哪里下载"。用户问"我登录不上了，密码可能忘了"，这句话跟"忘记密码怎么办"意思接近。普通关键词搜索可能搜不到，语义检索就能找到相近的 FAQ。

流程：先把 FAQ 转成向量存索引，用户提问时找相近片段，连同问题一起发给模型。这个思路后来会变成 RAG——检索增强生成，说人话就是：先把相关资料找出来，再让模型带着资料回答。

八、Agent 先按最简单的理解

普通调用是问一次答一次。Agent 是程序允许模型多走几步——输入问题 → 模型判断缺什么资料 → 调工具查资料 → 模型看结果 → 可能再查一次 → 输出结论。

关键多了"下一步要做什么"的判断。Python 这边要记录每一步：模型想调哪个工具，参数是什么，工具返回了什么。

一开始不用框架也能写出最小 Agent。一个 while 循环，加上模型请求、工具函数、历史记录，就能看出基本形态。等工具多了、需要追踪和审批了，再看 Agent 框架才更有意义。

所以这块真正要先想明白的，不是"哪个 Agent 框架最强"，而是一次请求怎么组织：文字从哪来，要求怎么写，返回结果能不能被 Python 解析，模型缺资料时由哪个函数去查。把这几个动作拆开看，后面的工具调用、检索和 Agent 就不再难理解。