「AI Agent」Agent 的基本架构由哪些核心组件构成？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 2. Agent 的基本架构由哪些核心组件构成？，用于记录与总结 AI Agent 相关的核心面试知识点。

1 Agent 的四大核心组件（总览）

Agent 的四大核心组件可以概括为：LLM、工具系统、记忆系统、规划模块。

缺了任何一个，Agent 都跑不起来：

  • LLM 是整个系统的大脑，负责理解任务、做出决策——下一步是继续思考、调用工具，还是直接给出最终答案；
  • 工具系统让 Agent 能跟外部世界交互，搜索、执行代码、调 API；
  • 记忆系统让 Agent 在任务执行中保持状态，不会做到一半「失忆」；
  • 规划模块负责把复杂目标拆解成可执行的步骤，让 Agent 能应对复杂任务。

如果把这套系统类比成一家公司，角色分工会非常清晰：LLM 是老板，所有决策都要经过它拍板；工具系统是外包执行团队，老板说「去搜这个」「去发这封邮件」，它们负责真正干活；记忆系统是公司档案室，负责各种信息的存档和调档；规划模块是项目经理，拿到一个大目标后把它拆成一张可执行的任务单。

2 LLM 核心：Agent 的大脑

2.1 LLM 负责什么

LLM 是整个 Agent 的大脑。所有输入——用户的指令、工具返回的结果、记忆里调出来的内容——最终都要经过它来理解和决策。它负责判断：下一步该做什么？ 是继续推理、调用某个工具？还是已经可以给出最终答案？

没有 LLM，其他三个组件就是一堆零件，没有人来统一指挥。

2.2 容易被忽略的 System Prompt

很多人把注意力都放在「模型」上，却忽略了一个同样重要的东西：System Prompt（系统提示词）。

Agent 开始工作之前，System Prompt 就已经定义好了它的 角色、行为边界、输出格式要求 等等。

比如做一个客服 Agent，System Prompt 里会写「你是一个专业的客服助手，只回答产品相关问题，遇到不确定的信息要如实说明，不要编造答案」。这段话看似简单，却直接决定了 Agent 的「人格」和行为准则，写得好不好会直接影响 Agent 的表现。实际工程中，System Prompt 的调优往往占开发时间的相当大一部分，因为它是我们能最直接控制 Agent 行为的抓手。

2.3 模型选型：不是越贵越好

Agent 选哪个模型做大脑，也是一门学问。不同模型之间的差异远比想象中大：

  1. 推理能力：Agent 需要做多步决策，模型的推理能力直接决定了它能不能正确拆解任务、选对工具。像 GPT-4o、Claude Sonnet 这类模型在复杂推理上表现更好，但调用成本也更高。

  2. 推理模型（Reasoning Model）的趋势：专门为推理优化的模型越来越多，比如 OpenAI 的 o1/o3 系列、DeepSeek-R1，它们在做复杂任务拆解和多步决策时表现更佳，特别适合做 Agent 的大脑。但代价是延迟更高、token 消耗更大，不是所有场景都适合用。一个常见的工程做法是：用推理能力强的大模型做核心决策（任务规划、关键判断），用更快更便宜的小模型做简单任务（意图分类、格式提取），按环节搭配。

  3. 工具调用稳定性：有些模型生成的 JSON 格式经常出错、参数乱填，导致工具调用失败，在生产环境里会带来大量重试和 token 浪费。

  4. 上下文窗口大小：Agent 每一步的工具返回结果都要塞进上下文，一个复杂任务跑十几步下来，上下文很容易撑满。窗口太小的话，后面的步骤就「看不到」前面发生了什么。

所以模型选择不是「越贵越好」，而是要根据任务复杂度、延迟要求、成本预算做权衡。

LLM 是 Agent 的核心

Agent 的模型选型

3 工具系统：与外部世界交互的唯一入口

3.1 工具打破 LLM 的三大局限

LLM 本质上是一个「语言处理器」：不能上网、不能读文件、不能执行代码。而工具系统正是 Agent 与外部世界交互的 唯一入口。搜索引擎、数据库查询、代码执行器、发邮件的 API……任何能用函数封装的能力，都可以变成 Agent 的工具。

3.2 工具是怎么定义的

以 OpenAI function calling 格式为例，定义工具其实很简单，只需要告诉模型三件事：工具叫什么名、能做什么事、需要哪些参数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
tools = [
    {
        "type": "function",
        "function": {
            "name": "search_web",
            "description": "搜索互联网上的信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "搜索关键词"
                    }
                },
                "required": ["query"]
            }
        }
    }
]

# LLM 决定调用工具时，会返回类似这样的结构：
# {"tool_call": {"name": "search_web", "arguments": {"query": "2024年大模型最新进展"}}}
# 真正执行搜索的是我们自己的代码，结果再反馈给 LLM

可以看到，工具定义里没有一行执行逻辑，只有「名字、描述、参数说明」，本质上就是一份说明书。模型读了这份说明书，自己决定该调哪个工具、参数填什么，然后把决策以 JSON 格式返回，由我们的代码真正执行。这个「决策与执行分离」的设计，是理解工具调用最核心的一点——模型负责决定做什么，程序负责真正执行。

3.3 工具描述的质量直接影响表现

还有一个容易被忽略的点：模型是根据 description 来判断「什么时候该用这个工具」的。如果描述写得含糊、有歧义，模型就可能在不该用的时候调用它，或者该用的时候没用它。

举个例子：如果某个查数据库的工具 description 只写了「查询数据」，模型可能在用户问天气时也去查数据库，因为「查询数据」太宽泛了。但如果你写成「查询公司内部销售数据库，支持按日期、产品类别筛选」，模型就能精确判断什么场景该用它。所以在实际开发中，工具描述需要反复调优，其重要性不亚于 prompt 工程。

3.4 MCP：工具世界的「USB-C 接口」

当工具越来越多时，管理和标准化就成了大问题。Anthropic 在 2024 年底提出 MCP（Model Context Protocol，模型上下文协议），底层是一套基于 JSON-RPC 的通信协议，它不只是把「工具」标准化，还定义了三类能力：

  • Tools：会改变外部世界的操作，比如发邮件；
  • Resources：只读的数据源，比如文件内容；
  • Prompts：预定义的提示词模板，比如代码审查模板。

MCP 的架构分三层：最外层是 Host，即用户交互的 AI 应用（如 Claude Desktop、Cursor）；中间是 Client，负责管理与 MCP Server 之间的连接；最里层是 Server，即真正暴露能力的服务端。

工具提供方只要按 MCP 标准实现一个 Server，任何支持 MCP 的 Agent 都能自动发现和调用这些能力，无需额外写适配代码。可以把 MCP 理解成工具世界的「USB-C 接口」——接口标准一致，什么设备都能连上。

Agent 的工具系统

工具描述的质量影响 Agent 表现

4 记忆系统：让 Agent 不失忆

有了工具能「做事」，Agent 还得「记事」。传统 LLM 每次调用都是「失忆」的，而 Agent 系统通常设计 两层记忆。

4.1 短期记忆与长期记忆

  • 短期记忆：当前任务执行过程中的中间状态，存在 context window（上下文窗口） 里，比如第一步搜索到了什么、第二步执行结果是多少。它就像人的「工作记忆」，容量有限，任务一结束就清空了。
  • 长期记忆：跨任务保存的信息，比如用户偏好、历史操作记录，通常用 向量数据库 实现——把重要信息 embedding 之后存起来，需要时做语义检索拿回来。它就像人的「长期记忆」，容量大、可跨天保留，但需要主动「回忆」才能调出来。

4.2 借用认知科学看长期记忆的组织方式

可以借用认知科学对人类长期记忆的分类，来理解 Agent 长期记忆的组织方式（注意这只是便于理解的类比，实际实现通常都是向量检索 + metadata 过滤，不一定分得这么细）：

  • 语义记忆（Semantic Memory）：事实性知识，比如「用户是做金融行业的」「某个 API 的调用频率限制是每分钟 60 次」；
  • 情景记忆（Episodic Memory）：具体的经历，比如「上次用户问退款问题时我们查了订单系统，发现他的订单已过退款期」；
  • 程序性记忆（Procedural Memory）：「怎么做事」的方法论，比如「处理退款问题的标准流程是先查订单状态再核实支付方式」。它不是存某个具体事实，而是把 Agent 做事的方法沉淀下来，下次碰到类似任务时直接套用高效流程，而不是每次都从头摸索。

4.3 记忆工程的三个挑战

  1. 短期记忆的容量问题：复杂任务执行十几步，每步工具返回大量文本，上下文很快撑满。要么做摘要压缩（把前面的步骤浓缩成关键信息），要么做滑动窗口（只保留最近几步的详细内容），但两种方式都会丢失信息。如何在「记住够多」和「不撑爆上下文」之间取舍，是记忆工程最核心的设计问题。

  2. 长期记忆的存储策略：如果什么都往向量数据库塞，检索出来的噪音会很多，反而干扰模型决策；存得太少又失去意义。目前较好的做法是在存入前做一轮重要性评估，只把真正有价值的信息持久化。

  3. 记忆衰减（Memory Decay）：一个客服 Agent 三个月前处理的问题，到今天大概率已不重要。记忆衰减的做法是给每条记忆加一个时间权重，越久远的权重越低，检索时自然排在后面。具体实现上通常用指数衰减公式：记忆相关性分数 = 语义相似度 × 时间衰减因子。衰减速度可按业务场景调整：客服场景衰减可以快一些（对话大多是一次性的），法律合规场景衰减要慢得多（历史记录可能在很久之后仍被引用）。这样 Agent 就不会被过时信息淹没，总是优先关注最近的、最相关的记忆。

Agent 的记忆机制

长期记忆的分类

记忆衰减

5 规划模块：把大目标拆成小步骤

5.1 规划的本质

简单任务一步就能搞定，但如果你让 Agent「帮我写一份竞品分析报告」，它需要先把目标拆解成：搜索竞品资料 → 整理关键数据 → 对比分析 → 撰写报告。规划模块就是负责做这件事的，它决定了 Agent 能不能应对复杂任务。

规划模块的底层依赖 LLM 的推理能力，而提升推理能力主要有两种技术手段：

  • CoT（Chain of Thought，思维链）：让模型「把思考过程写出来」，而不是直接输出最终答案。你可以在 prompt 里加一句「Let’s think step by step」，模型就会一步步展开推理。为什么一句话就能提升效果？因为 LLM 的 token 生成是逐步进行的，每一步的输出都会成为下一步的输入，把中间步骤写出来，等于给了模型更多「思考空间」。
  • ToT（Tree of Thoughts，思维树）：不是走一条线性的推理链，而是在每个推理节点展开多个可能的分支，评估每个分支的质量，选出最优路径继续往下走。可以这样理解：CoT 是一条路走到底，ToT 是走到岔路口先看看几条路，选最好的那条再往前。ToT 在需要创造性思考或复杂决策的场景下效果更好，但计算成本也更高，因为它要同时评估多条路径。

5.2 两种主流的规划执行模式

有了推理技术打底，规划模块在实际运作中有两种主流模式：

  • Plan-and-Execute（先规划后执行）：先让 LLM 输出一个完整的步骤列表，再按顺序逐步执行。好处是整体结构清晰，能在执行前就看到完整计划，方便人工审核；缺点是如果中间某一步的结果与预期不符，原计划可能就不合适了，需要重新调整。
  • ReAct（边执行边规划）：每走一步就根据当前结果重新思考下一步做什么，不提前制定完整计划。好处是灵活性极高，能根据实际情况随时调整；缺点是容易「走偏」，因为每一步都是局部最优决策，有时会忽略整体目标。

实际工程里，很多团队会把两种模式结合起来：先做一个粗略的计划确定大方向，执行过程中再根据反馈动态微调。

Plan-and-Execute 与 ReAct 模式对比

6 四者如何协作：Agent 运行主循环

了解了四个组件各自的作用，最后看它们是如何串起来运行的。用一段伪代码还原整个流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Agent 运行的核心 loop（伪代码）
def agent_run(user_goal: str):
    # 第一步：规划模块上场，把目标拆成步骤列表
    plan = llm.plan(user_goal)

    memory = []  # 短期记忆，存放每一步的中间结果

    for step in plan:
        # 第二步：LLM 核心做决策，这一步该怎么做？
        action = llm.decide(
            step=step,
            history=memory,                    # 传入短期记忆，让它知道之前做了什么
            long_term=vector_db.search(step)   # 从长期记忆里捞出相关历史
        )

        if action.type == "tool_call":
            # 第三步：工具系统负责真正执行
            result = tools.execute(action.tool_name, action.args)
            memory.append({"step": step, "result": result})  # 执行结果存入短期记忆

        elif action.type == "final_answer":
            return action.content  # LLM 判断任务完成，返回最终答案

看完这段伪代码，Agent 的核心节奏其实很简单：规划 → 决策 → 执行 → 结果存入记忆 → 再决策，循环往复，直到任务完成。在这个闭环里，LLM 始终是那个做决策的角色，工具系统是执行者，记忆系统让它不会「失忆」，规划模块帮它把大目标拆成小步骤。

这也是为什么 LangChain、LlamaIndex、AutoGen 这些主流框架，本质上都是围绕这四个组件来设计的——只是封装方式和侧重点各有不同。

Agent 的运行主循环

参考

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。

追逐繁星 > AI Agent
#AI #Agent #大模型 #LLM
「AI Agent」Agent 的基本架构由哪些核心组件构成？
https://marisamagic.github.io/2026/08/06/20260806_Agent的基本架构/
作者
MarisaMagic
发布于
2026年8月6日
许可协议