atrior notion blog

LLM

LLM（Large Language Module）大语言模型，内部架构为 Transformer。

当用户提出请求时，大语言模型不会立马给出全部响应，而是先给出一部分响应，随后将该响应添加到原用户请求之后，再一并进行分析，随后再返回阶段性响应，直到大模型给出结束标识符，表示一次请求-响应结束。

LLM 的弊端

只会「说」不会「做」

没有「记忆」

不会用「工具」

不会「规划」

Token

大模型处理文本的最「基本单元」。

大模型是一个庞大的数学函数，内部执行着复杂的矩阵运算，输入是数字，输出的也是数字，所以需要一个中间人来在人类自然语言和数字之间进行转换（Tokenizer），负责编解码。

编码：

切分：将原自然语言拆分成一个一个词法单元（Token）。

映射：将 Token 映射成大模型认识的数字（Token ID）。

解码：

映射：将大模型运算出的 Token ID 翻译成文字。

Token 和“词”并不是一对一关系，经验上来讲，一个 Token 大约对应 0.75 个英文单词或 1.5 - 2 个汉字。

Context

大模型每次处理任务时所接收到的信息总和。

在与大模型进行的一次对话时，不仅仅是当前对话的内容，之前对话的历史记录也会被大模型一起加入到会话中，包括大模型正在吐出的 Token 也会加入到 Context 中。

Context = 对话历史 + 用户问题 + 当前输出 + 工具列表 + System Prompt …

Context Window

Context 能容纳的「最大 Token 数量」。

如果用户有一本用户手册，需要让大模型回答问题之前参考用户手册的内容去回答，这样很容易撑爆 Context Window。

引入 RAG 技术，让大模型从“用户手册”中匹配最符合用户提问的片段加入到 Context Window 有效缓解了 Context Window 的压力，成本也会低很多。

Prompt

大模型接收的具体问题和指令。

Prompt 越准确，大模型给出的回复质量就越高，越符合用户预期。

Prompt Engineering 提示词工程，用来解决如何更好的为大模型提供提示词，让大模型更精准的理解用户意图。

Prompt 分类：

User Prompt：用户提示词，用户输入的具体任务（用户输入）。

System Prompt：系统提示词，用来制定大模型的人设和做事规则（后台配置）。

Tool

帮助大模型解决获取外部系统信息的工具（函数、API），即大模型感知外部世界的桥梁。

比如大模型在接收用户输入”今天上海的天气如何？“，流程应该是这样的：

用户 → 平台：发出天气查询请求

平台 → 大模型：不仅携带用户请求，还会携带目前平台已有的 Tools（其中包含天气查询 Tools）

大模型 → 平台：大模型要求平台使用天气查询 Tools 请求天气信息

平台 → 天气查询系统：携带大模型的查询参数发送给天气查询系统请求天气数据

天气查询系统 → 平台：天气查询系统携带天气信息响应给平台

平台 → 大模型：将 Tools 响应发送给大模型进行处理

大模型 → 平台

平台 → 用户

各角色的职责：

大模型：

选择 Tools
总结归纳

Tools：

查询天气

平台：

串联流程

Agent

能够自主规划并且调用 Tools 的系统为 Agent。Agent 就是 LLM 在循环中自主使用工具的系统。

Agent 产品：

Claude Code

CodeX

Gemini CLI

构建模式

ReAct
Plan and Execute

Agent 怎么解决 LLM 的弊端？

针对"只会说不会做"，Agent 引入了工具调用能力，可以调用搜索引擎、数据库、API、代码执行器等各种外部工具来真正执行操作。

针对"没有记忆"，Agent 配备了记忆系统，包括记住当前任务上下文的短期记忆，和存储在外部数据库中、可以跨对话保留的长期记忆。

针对"不会用工具"，业界推出了 MCP 等标准化协议来统一工具接入方式。

针对"不会规划"，Agent 具备了任务拆解和规划能力，能把一个大目标分解成多个小步骤，然后逐步执行。

Agent 的核心组成

第一个是大脑，也就是 LLM，负责理解意图、推理判断、决定下一步行动。

第二个是规划模块，负责把复杂任务拆解成可执行的步骤。

第三个是记忆模块，负责存储和检索信息，让 Agent 能在长时间任务中保持连贯。

第四个是工具模块，是 Agent 的「手和脚」，让它能跟外部世界互动。

Agent 和 Workflow 有什么区别？

Workflow 是指 LLM 和工具通过预定义的代码路径进行编排的系统，而 Agent 是指 LLM 动态主导自身流程与工具调用的系统，由 LLM 自主决定如何完成任务。

两者最核心的区别在于「谁在控制流程」。

Agent 有什么工作模式？

模式一：ReAct（边想边做）

Agent 在思考和行动之间不断交替。具体来说就是一个三步循环，先是思考（Thought），分析当前情况决定下一步做什么；然后是行动（Action），调用一个工具来执行；接着是观察（Observation），查看工具返回的结果。然后回到思考，如此循环，直到任务完成。

ReAct 的优点是透明可审计（每一步思考过程都看得见）、灵活适应（遇到意外能随时调整）、通用性强。

但它的缺点也很明显：token 消耗大，因为每一步都要完整推理一次；有时会陷入循环，反复执行相同动作走不出来。

模式二：Plan-and-Execute（先想好再做）

它把 Agent 的工作分成两个阶段：第一阶段是规划，Agent 先把完整的执行计划想清楚；第二阶段是执行，按计划逐步完成，不用每步都重新思考全局。

这种模式最大的优势是省钱。规划只做一次，执行阶段不用反复推理，token 消耗大约是 ReAct 的五分之一。

但缺点是不够灵活，如果执行到第 3 步发现情况变了，原来的计划可能就不适用了。所以也有这么个做法是在执行过程中加入「重新规划检查点」，每隔几步检查一下计划是否还靠谱。

模式三：Reflection（做完再检查）

反思模式的核心思想是 Agent 完成任务后不急着交付，而是先自我检查一遍，就像你写完文章不会直接发出去，而是再通读一遍、改一改、润色一下。

实现方式通常有两种：

一种是自我反思，同一个 Agent 完成任务后切换到「审查者」角色来审视自己的输出，发现问题就修改，然后再审查，直到满意。

另一种是双 Agent 对话，一个 Agent 负责生成，另一个负责评审，两者来回迭代直到评审方满意，就像代码的 Code Review 过程。这种模式特别适合对质量要求高的场景，比如代码生成、法律文书、学术论文等。

模式四：Multi-Agent（团队协作）

Multi-Agent 模式让多个专业化的 Agent 各司其职，比如一个负责规划、一个负责搜集信息、一个负责写代码、一个负责测试，通过协作来完成复杂任务。

这几种模式不是互斥的，实际中往往是组合使用的。一个多 Agent 系统中，每个 Agent 内部可能用的是 ReAct 模式，整体协作用的是 Multi-Agent 模式，最后还有一个 Reflection 环节来检查质量。

Function Call

函数调用

让 LLM 不仅能生成文字，还能告诉外部程序「我想调用某个函数，参数是这些」。

Function Call 的工作原理

第一步，定义函数。

开发者预先告诉 LLM「你手边有哪些工具可以用」，用 JSON 格式描述每个函数的名字、功能说明和参数。比如你告诉它有一个 get_weather 函数，接收一个城市名参数，返回天气信息。


{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市的实时天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {
              "type": "string",
              "description": "城市名称，比如：上海"
            }
          },
          "required": ["city"]
        }
      }
    }
  ]
}

第二步，模型判断。

用户提问后，LLM 分析用户的意图，自己判断「要回答这个问题，我需要调用哪个函数」。如果用户问「上海今天天气如何」，LLM 会决定调用 get_weather，并生成参数 {"city": "上海"}。


{
  "tool_calls": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\": \"上海\"}"
      }
    }
  ]
}

第三步，执行函数。

注意，这一步非常关键，LLM 自己并不执行函数。它只是输出了「我想调用这个函数，参数是这些」的结构化指令。真正执行函数的是你的应用程序。你的代码拿到 LLM 返回的调用指令后，解析出 city=上海，去实际调用天气 API，拿到结果比如 22度，多云。

第四步，生成回答。

你的代码把拿到的真实温度数据再次发给 LLM。LLM 这次有了客观数据支撑，就会用非常自然的人类语言回复你：今天上海天气是多云，气温大约 22 摄氏度。

为什么 Function Call 这么重要？

Function Call 解决了两个核心问题：

第一个是"什么时候调用"的判断问题，LLM 能根据用户的自然语言意图，自动判断需不需要调用工具、调用哪个工具。你不需要写复杂的条件判断逻辑，LLM 自己会推理。

第二个是"传什么参数"的提取问题，LLM 能从用户的自然语言中提取出结构化的参数。用户说"帮我查一下北京后天的天气"，LLM 能自动提取出 city=北京 和 date=后天。

这两个能力加在一起，就把 LLM 从一个「只会聊天的文本生成器」变成了一个「能理解意图并驱动外部系统的决策引擎」。

大模型基础概念

LLM