Ai on GzzhM

[all_in_ai] AI 名词扫盲 FunctionCall

Thu, 06 Aug 2026 00:00:00 +0000

什么是 FunctionCall

我们已经知道一个 Tool 是 函数本体+名称+描述+参数 定义的

有一个关键问题 : 大模型在作出要调用这个工具的决策之后, 它怎么告诉 Agent 去执行

大模型只会说话 , 输出的永远只是文字

Agent 要调用工具,必须知道调哪个工具，传什么参数，格式是什么。这中间的信息交换，靠什么来保证正确

没有 Funcition Call 之前

开发者将全部自然语言写进 system prompt 系统提示词里面

你是一个智能助手，你可以使用以下工具：

工具名：check_weather
功能：查询菜个城市的天气

参数：
- city：城市名，中文，比如"上海"
- date：日期，格式必须是 YYYY-MM-DD，比如"2026-03-19"
- date 是可选的，不填默认查今天


当用户需要查天气时，你要调用这个工具，告诉我工具名和参数。

你让他查 [上海明天的天气] ，可能会返回

散文式回复 :, “好的，我来帮你查询上海明天的天气”
参数顺序颠倒 :

TBD

[all_in_ai] AI 名词扫盲 Tool

Sat, 18 Jul 2026 00:00:00 +0000

如果想让 AI 给你输出一套方案或者是分类规则是非常容易的

但是想让他给你查看今天天气，或者是预定明天机票一般来说都不能很完美的进行

而 Tool 就是为了实现这些内容

Agent 和 Tool

Agent在上一篇文章中指出是负责作出决策和调用工具，所以 Agent主要负责的就是调度和决策

用户 : 提供需求

大模型 LLM : 负责决策，先做什么后做什么

Agent : 负责 Tool 的调度，和 LLM 调度

Tool : 实际处理解决问题的操作

具体来说，当你给 Agent 下一条指令：「帮我读取 C 盘目录下的 hello_world.cpp 文件，移动到 D 盘目录下，最后给我总结一下这个文件的核心内容」，整个执行流程是这样的：

Agent 把需求 + 工具清单打包，发给大模型 ：「用户想做这件事，你有这些工具可以用，第一步该怎么做？」
大模型做决策，返回指令 ：「调用【读取文件】工具，路径是 C://hello_world.cpp」
Agent 执行指令，调用工具 ：真正去磁盘上读文件
Agent 把结果回传给大模型 ：「文件读取成功，内容是……」
大模型根据结果，决定下一步 ：「好，现在调用【移动文件】工具，把它移到 D 盘」
循环执行，直到任务完成 ：所有步骤跑完，大模型生成最终总结
Agent 把结果反馈给你 ：任务完成你看，这整个过程里，「决策」始终在大模型，「执行」始终在工具，而 Agent 就是那个来回传话、推进任务的协调员。

Tool

我们在写 skills 的时候，经常会用到 python 处理脚本

那么 python 代码就是 tool 吗

Tool 的四要素

函数本体

函数本体：真正干活的代码

name (名称) : 大模型的识别标签

description (描述) ：整个工具定义最重要的字段

parameters (参数定义) : 告诉大模型我们应该怎么填参数

函数本体 :

# ===== 第一部分：函数本体（大模型看不到，Agent 负责执行）=====
import requests

def get_weather(city: str, date: str) -> dict:
    """调用天气 API，查询指定城市指定日期的天气"""
    response = requests.get(
        "https://api.weather.com/v1/forecast",
        params={"city": city, "date": date}
    )
    data = response.json()
    return {
        "city": city,
        "date": date,
        "weather": data["condition"],   # 晴/多云/雨
        "temperature": data["temp_c"],  # 摄氏度
        "humidity": data["humidity"]    # 湿度百分比
    }

工具说明书包含 name + description + parameters

// ===== 第二三四部分：工具说明书（大模型看到的部分，靠这个决定要不要调用）=====
{
  "name": "get_weather",
  "description": "查询指定城市在指定日期的天气情况。当用户询问某地天气、出行建议、是否需要带伞等问题时使用此工具，返回天气状况、气温和湿度信息。",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "要查询天气的城市名称，例如：北京、上海、广州"
      },
      "date": {
        "type": "string",
        "description": "查询日期，格式：YYYY-MM-DD，例如：2025-03-21"
      }
    },
    "required": ["city", "date"]
  }
}

[all_in_ai] AI 名词扫盲 agent

Wed, 15 Jul 2026 00:00:00 +0000

名词扫盲

Agent

对于 llm 和 prompt 他都只能进行 ask 操作，并不能干，只是能输出

什么是 Agent

Agent (智能体) : 能够自主感知环境，作出决策，调用工具，完成多步骤任务的程序

自主（Autonomously）：不需要人在每一步发指令。你给它一个目标，它自己判断下一步做什么
多步骤（Multi-step）：一个任务可能要走 5 步、10 步，Agent 自己把这些步骤串起来
工具调用（Tool use）：调用真实的函数，查数据库、搜网页、发通知、写文件，不只是"说说"，而是真的去做

一句话总结： Agent = 大模型（大脑）+ 工具（双手）+ 执行循环（思考-行动-观察-再思考）

为什么需要 Agent

之前我们说过大模型的三大短板：

没有执行能力：只能生成文字，不能操作外部系统
知识有截止日期：不知道最新数据，看不到你的私有系统
没有持久记忆：每次调用对它都是全新的，不能积累任务中间状态

Agent 的核心组成

大模型（LLM），大脑

负责理解任务、分析当前状态、决定下一步做什么。所有的"推理"都在这里发生，该查什么、查完之后怎么解读、下一步往哪走，全是大模型来判断。

工具（Tools），双手

一个个可以被调用的真实函数：查数据库、调用搜索引擎、读写文件、发通知、调用 API…… 大模型告诉 Agent “调用这个工具、传这些参数”，代码层面真正去执行。工具的结果会返回给大模型，供它继续推理。大模型不"直接"操作外部系统，它通过工具来"动手"。

记忆（Memory），记事本

短期记忆：当前任务里的对话历史 + 每次工具调用的结果，存在 context window 里。Agent 执行第 5 步时，“记得"第 1 步查到了什么，靠的就是这个
长期记忆：跨会话需要记住的信息，存在外部数据库，需要时检索出来注入 context

为什么需要记忆？多步骤任务里，每一步的结果都是下一步判断的依据。没有记忆，每步都是"从零开始”，Agent 根本没法串联多步骤任务。

执行循环（Loop），节拍器

Agent 的"引擎"。不断重复"思考 → 行动 → 观察"这个循环，直到任务完成。没有这个循环，Agent 只是一次性的问答，无法串联多步骤。这个循环是 Agent 和普通大模型调用之间最根本的区别。

Agent 是怎么工作的. ReAct 循环

目前主流的 Agent 工作范式叫做 ReAct 即 Reasoing+Acting 即推理 + 行动 + 观察 + 在推理 ..

用户：帮我调查今晚 23:00 的数据库报警

[第 1 轮]
Think：需要先拿到具体的报警详情
Act：调用 get_alarm_details(time="23:00")
Observe：返回"连接数突增，连接池耗尽，持续 8 分钟后自动恢复"

[第 2 轮]
Think：连接数突增，需要看是哪些查询造成的
Act：调用 query_slow_log(timerange="22:50-23:10")
Observe：发现 3 条全表扫描的慢查询，来自同一个用户 ID

[第 3 轮]
Think：根因已经清楚，生成分析报告
Act：输出最终分析结论（Final Answer）

几个关键机制：

结果回流：每一轮的工具调用结果都会追加到 context window 里，大模型下一轮能"看到"所有历史。所以它能基于已有发现继续推理，而不是每次都从零开始。这就是为什么前面"记忆"那个组件如此重要。
动态决策：每一步该怎么走，是大模型实时推理出来的，不是你提前写好的。发现是慢查询，它就去查慢查询日志；如果发现是网络问题，它就会去查网络相关的工具。路径是活的，不是死的。
何时停止：大模型判断任务已完成时输出"最终答案"，或者达到预设的最大轮数上限。两个条件任意满足一个，循环结束。这就是"自主"的含义，你给任务目标，它自己决定怎么走到终点。

Agent 的另一个工作模式 Plan and Execute

ReAct 很好用，但有一个先天的弱点。

ReAct 是「边想边做」，每一步只看眼前，这一步的结果决定下一步的方向。对于 2-3 步能解决的短任务，这完全没问题。但如果任务很复杂、步骤很多呢？

问题一：长任务容易「迷路」

ReAct 跑了 8 轮之后，context window 里已经堆满了历史操作记录。大模型要在这一大堆信息里同时维持「当前在第几步」「最终目标是什么」「还缺哪些信息」，注意力越来越稀释，越往后越容易偏离最初的目标。

问题二：容易绕弯路

没有全局规划，每步只看眼前，就像在迷宫里随机探索，走了 5 步之后才发现方向不对，只能回头重来，白白消耗了好几轮 LLM 调用。

问题三：token 消耗滚雪球

ReAct 每一轮都要把完整的对话历史带上。步骤越多，每轮的 context 越长，后期每次 LLM 调用的 token 消耗都很高，成本直线上升。

这三个问题催生了另一种工作模式： Plan and Execute（规划-执行模式） 。

核心思路用一句话说清楚： 先让大模型把整个任务规划成一份清单，再逐步按清单执行，而不是走一步看一步。

Plan and Execute 的两个阶段

第一阶段：Planner（规划阶段）

大模型拿到任务，先不调任何工具，专注做一件事：把任务完整拆解成一份有序的子任务清单。

用户：「帮我调查今晚 23:00 的数据库报警，写一份完整的故障分析报告」

Planner 输出的计划：
  步骤 1：获取 23:00 报警的详细信息（报警类型、持续时间、影响范围）
  步骤 2：查询报警时间段内的慢查询日志，定位异常 SQL
  步骤 3：查询报警时间段内的数据库连接数、CPU、内存指标
  步骤 4：关联步骤 2 和步骤 3 的结果，分析根因
  步骤 5：生成完整的故障分析报告，包含时间线、根因和改进建议

第二阶段：Executor（执行阶段）

执行步骤 1：
  → 调用 get_alarm_details(time="23:00")
  ← 返回「连接数突增，连接池耗尽，持续 8 分钟后自动恢复」

执行步骤 2：
  → 调用 query_slow_log(timerange="22:50-23:10")
  ← 发现 3 条全表扫描的慢查询，来自同一个用户 ID

执行步骤 3：
  → 调用 get_db_metrics(timerange="22:50-23:10")
  ← CPU 正常，连接数峰值达到上限 500，内存无异常

执行步骤 4：
  → 大模型综合步骤 2、3 结果进行分析
  ← 结论：慢查询导致连接长时间占用，连接池耗尽触发报警

执行步骤 5：
  → 生成故障分析报告
  ← 完整报告输出，任务完成

Re-planning （重新规划）

执行中途如果遇到了计划没预料到的情况，比如步骤 2 查不到慢查询，但发现了大量锁等待，Executor 可以把这个新信息反馈给 Planner，重新生成后续步骤的计划，而不是一条路走到黑。

用户任务
  ↓
[Planner]  大模型一次性生成完整计划
  ↓
执行计划 = [步骤1, 步骤2, 步骤3, 步骤4, 步骤5]
  ↓
[Executor] 按顺序执行每个步骤
  步骤1 → 调工具 → 结果
  步骤2 → 调工具 → 结果      ← 遇到意外？触发 Re-planning，重新调整后续计划
  步骤3 → 调工具 → 结果
  ...
  ↓
最终结果汇总 → 输出给用户

ReAct vs Plan and Execute：怎么选？

对比维度	ReAct	Plan and Execute
决策时机	每一步实时决策	开始前一次性规划
全局视野	弱（只看当前这步）	强（提前看到全貌）
灵活性	强（随时根据结果调整）	弱（计划一旦生成，调整成本高）
适合任务步骤	少（3 步以内）	多（5 步以上的复杂任务）
token 消耗	随步数线性增长，后期很贵	规划阶段集中消耗，执行阶段可控
实现难度	低（结构简单）	中（需要管理计划状态和 Re-planning 逻辑）

简单记忆：

任务步骤少、目标模糊、需要随机应变 → 用 ReAct
任务步骤多、目标明确、需要全局把控 → 用 Plan and Execute
系统复杂、两者都需要 → Plan and Execute 做外层框架，每个子任务内部跑 ReAct

最后这种「外层 Plan and Execute + 内层 ReAct」的搭配，在实际生产系统里最常见，用规划保证大方向不跑偏，用 ReAct 保证每个子任务执行时足够灵活。

Agent vs Workflow

Workflow（工作流）是你提前写好所有步骤和分支逻辑的流程：先做 A，再做 B，如果 B 的结果是 X 就走流程 C，否则走流程 D。大模型只是其中某个步骤里被调用一次，整体流程是硬编码的。

Agent 是你只给任务目标，大模型自己实时决定每一步做什么、调用什么工具、根据结果决定下一步。执行路径是动态的，每次运行可能走不同的路径。

对比维度	Workflow	Agent
决策者	你（写死的代码逻辑）	大模型（实时推理）
执行路径	固定	动态
适合场景	步骤明确、重复性高	任务开放、情况多变
可预测性	高	低
成本	低	高（多轮 LLM 调用）

两者没有高下之分，适合不同的场景：

流程能写清楚、步骤是固定的 → 优先用 Workflow ，更稳、更省钱、更可预期
任务是开放式的、需要根据中间结果动态决策 → 用 Agent
最常见的实际架构： Workflow 做骨架，Agent 负责其中需要判断的环节，两者结合，不是非此即彼

一个真是的 agent

def run_agent(user_message):
    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user",   "content": user_message},
    ]

    while True:
        # 1. 调用大模型，让它思考下一步
        response = llm.call(messages)

        # 2. 如果大模型说"我完成了"，退出循环
        if response.is_final_answer:
            return response.content

        # 3. 否则，执行大模型指定的工具
        tool_result = execute_tool(response.tool_name, response.tool_args)

        # 4. 把工具结果追加到 messages，供下一轮参考
        messages.append({"role": "tool", "content": tool_result})

总结

整理一下这一章的核心认知：

Agent 是什么 ：以大模型为大脑，能自主调用工具、完成多步骤任务的程序。让大模型从"只能说"变成"能干"。

核心组成 ：大模型（大脑）+ 工具（双手）+ 记忆（记事本）+ 执行循环（节拍器）

核心机制：Think → Act → Observe 循环，每轮工具结果都回流给大模型，直到完成

和 Workflow 的本质区别 ：决策者不同，Workflow 是你提前写好的代码逻辑，Agent 是大模型实时推理。两者不是竞争关系，实际系统里经常结合使用

[all_in_ai] AI 名词扫盲 prompt

Wed, 15 Jul 2026 00:00:00 +0000

名词扫盲

Prompt

Prompts (提示词) ; 对于同一个 LLM , 不同的人用结果天差地别，而 prompt 就是为了统一。

可以是 :

具体的指令
具体的问题
具体的背景
具体的格式要求

messages = [
  { role: "system",  content: "你是一个 OnCall 助理，回答必须简洁" },
  { role: "user",    content: "昨晚数据库报警是什么原因？" },
]

system和user 都是 prompt 的一部分

为什么 prompt 很重要

llm 本质上是一个 next-token 的预测及其。对于模糊的上下文，他往哪里走的方向就越多，输出的就越随机

但是给的上下文越精确，它搜索的范围就越窄

user prompts

大部分 Ai 对话都是 user protmps

好的 User prompts 的三要素 :

目标明确 ：要做什么？分析、总结、改写、生成代码，得明说。“帮我看看这个日志"不是目标，“帮我分析这段日志里的报错原因并给出排查方向"才是。
背景充足 ：大模型不知道你的业务、你的系统架构、你的团队惯例，它只能靠你给的信息推断。背景给得越充分，它越不需要乱猜，幻觉越少。
输出要求 ：格式、长度、风格，不说，它随心所欲。你想要 Markdown 列表？想要 JSON？想要 3 条以内？一定要在 Prompt 里讲清楚。

场景对比 :

❌ 简单版：「数据库怎么了？」大模型不知道你说的是哪个数据库、什么时间发生的、有什么报警信息、你想要什么样的答案。

✅ 完整版：

以下是今天凌晨 2 点的数据库报警日志：

[日志内容]

请分析可能的根本原因，并给出 3 条排查建议，以 Markdown 列表格式输出。

System Prompt

用户层面看不到 system prompt 这是开发提前写进去的一个底层指令

system prompts 的三个核心用途 :

身份设定 ：给模型一个具体的角色

1
2

你是一个 OnCall 助理，专门帮助工程师排查和分析系统故障。
你只处理与系统稳定性、报警分析、故障排查相关的问题。

行为规则：定义模型"能做什么、不能做什么”

不允许回答与系统故障无关的话题。
如果你不确定某个判断，必须说明"我不确定，建议进一步验证"。

不要自行假设任何背景信息，只根据用户提供的内容作答。

输出格式约束 ：让模型每次都按固定格式输出

你的回答必须是 JSON 格式，包含以下字段：
summary：对问题的一句话概括
root_cause：可能的根本原因列表
action_items：建议的排查步骤列表

如何写好一个 pormpts

给模型"角色”
正向约束 > 负向约束

❌不要太啰嗦
✅回答控制在3句话以内

喂足够的信息
指定输出格式
Few-shot . 给几个参考例子
让模型先思考再回答

请先逐步分析，再给出最终结论

[all_in_ai] AI 名词扫盲大模型

Wed, 15 Jul 2026 00:00:00 +0000

名词扫盲

大模型

什么是大模型

LLM (large language Model) 大语言模型。平时说的 [AI 对话] [AI 助手] 都是大模型

大的体现 :

参数量大 : 模型内部有数千亿个参数
训练数据大

根据给的上下文，预测接下来最合理的文字是什么

大模型读文字的基本方式

Token 是大模型处理文本的基本单位。LLM 会把一句话拆分成多个 token 进行读取

对于一句话 hello world ，通常会被切分为 ["hello", "world"] ，大约一个单词对应一个token

Token :

决定模型能处理的文本长度上限 : 最常见的就是 200k
决定 API 调用花费

上下文窗口

上下文窗口，限制了 token 的量。跟达模型聊的越久，越容易忘记前面发生的事

GPT-4 有 128K token 窗口，大约 10w个汉字
Claude 3.5 有 200k 的 token 窗口

不过上下文窗口并不只是包含你询问的数据，它包含 你发出去的所有消息+模型的所有回复+调用工具的结果

大模型是无状态的

LLM 本身没有任何记忆，每次调用 APi 对他来说都是第一次见面

为什么我们在网页端 Gemini 和 Gpt 上面聊天都能记住前面的话，是因为在应用层，代码已经处理了记忆

每次我们发送消息，他都会把历史对话打包成为一个列表传给大模型

这就引入了两件事 :

为什么上下文窗口会写满 : 历史对话越多，上下文窗口会更快的被占满
为什么 Agent 需要管理记忆 : Agent 在执行长任务时，必须主动决定把哪些历史传进去，不然窗口很快就会塞满

对话的角色结构 : system,user,assistant

既然多轮对话是靠 传历史列表实现的，那么列表长什么样

调用大模型 API 时，你传入的不是一段裸文字，而是一个有结构的消息列表，每条消息都有一个角色（role）：

system ：系统提示，给模型的"身份设定和行为规则"。比如「你是一个 OnCall 助理，只能回答和系统故障相关的问题，回答必须简洁」。这部分用户看不见，但模型会严格遵守
user ：用户的输入，就是你说的话
assistant ：模型之前的回复，多轮对话时，把历史回复也打包进来，模型才知道"之前说了什么" 用伪代码表示，大概长这样：

messages = [
  { role: "system",    content: "你是一个 OnCall 助理，回答必须简洁" },
  { role: "user",      content: "昨晚数据库报警是什么原因？" },
  { role: "assistant", content: "是慢查询导致的连接池耗尽。" },
  { role: "user",      content: "怎么预防？" },   // 当前问题
]

https://cloud.tencent.com/developer/article/2643849

大模型能帮我们做什么

使用自然语言，分析意图
会进行逻辑思考，拆解任务和做决策
生成符合要求的内容
看懂规则并且执行

大模型做不到什么

没有执行能力, 只能通过 agent+tool的方式进行调用
知识有保质期，容易瞎编
上下文窗口有限，记不住太长的内容

开发场景

在理解完上面的概念之后，我们可以知道 agent 开发 就是给 llm 增加 Tool 调用,funciton call ,MCP 并且加上 RAG (知识库) 进行应用开发

Ai on GzzhM

[all_in_ai] AI 名词扫盲 FunctionCall

什么是 FunctionCall

没有 Funcition Call 之前

[all_in_ai] AI 名词扫盲 Tool

Agent 和 Tool

Tool

Tool 的四要素

函数本体

[all_in_ai] AI 名词扫盲 agent

Agent

什么是 Agent

为什么需要 Agent

Agent 的核心组成

Agent 是怎么工作的. ReAct 循环

Agent 的另一个工作模式 Plan and Execute

Plan and Execute 的两个阶段

Re-planning （重新规划）

ReAct vs Plan and Execute：怎么选？

Agent vs Workflow

一个真是的 agent

总结

[all_in_ai] AI 名词扫盲 prompt

Prompt

为什么 prompt 很重要

user prompts

System Prompt

如何写好一个 pormpts

[all_in_ai] AI 名词扫盲 大模型

大模型

什么是大模型

大模型读文字的基本方式

上下文窗口

大模型是无状态的

对话的角色结构 : system,user,assistant

大模型能帮我们做什么

大模型做不到什么

开发场景

[all_in_ai] AI 名词扫盲大模型