原生大模型为什么做不了智能 Agent

1. 引言

以 GPT-4、Llama 3 为代表的原生大模型在文本理解与生成上表现出色，能回答复杂问题、编写代码、撰写报告。然而，当我们需要它们完成需要环境交互、工具调用和多步规划的智能 Agent 任务时，模型的局限性立即暴露：它无法主动查询天气、不能调用数据库、不会记住多轮对话中的中间状态。本文从能力缺失的本质出发，分析原生大模型的局限，介绍 Function Call、MCP 协议等工程弥补方案，并给出构建简单 Agent 的实战指引。

读完本文，你将清楚原生大模型与智能 Agent 的分界线，理解 Agent 核心能力（感知、决策、执行）为何缺失，学会如何借助外部架构让大模型初步具备 Agent 行为。

2. 原生大模型的能力边界 —— 它擅长什么，缺什么

原生大模型的核心能力建立在海量静态文本语料的统计学习之上，其行为模式可概括为 “基于上下文的模式续写”。这决定了它擅长哪些任务，又天然缺失哪些能力。

2.1 它擅长什么

能力类别	典型场景	表现水平
语言理解与生成	翻译、摘要、改写、对话	优秀，媲美人类中上水平
静态知识问答	历史事件、科学常识、代码语法	良好，但存在时效性限制
模式识别与推断	阅读理解、逻辑推理、情感分析	在常见模式下表现出色
指令遵循能力	按给定格式输出、遵守约束条件	可通过提示工程引导

2.2 它缺什么

Agent 需要的能力	原生大模型现状	缺失原因
实时环境感知	无法获取当前时间、天气、系统状态	训练数据是静态的，模型无传感器
工具调用与执行	只能输出文本，不能直接调用 API 或执行函数	缺乏执行引擎；模型输出本质是“建议”而非“操作”
自主决策与目标分解	无法主动设定子目标、选择策略	推理是条件式的，无内部动机或奖励信号
多步规划与错误恢复	中途出错的输出会偏离正确方向	无反馈闭环，无法感知“操作是否成功”
持久记忆	上下文窗口有限（通常 4K-128K tokens），无法长期保存状态	无写入外部存储的机制
安全边界判断	可能被诱导执行危险操作	缺乏可撤销的执行权限控制

核心结论：原生大模型的功能可以类比为一个拥有海量知识但四肢瘫痪的学者 —— 它能回答问题、提出方案，但无法动手操作、无法感知环境变化、也无法在执行过程中调整行为。这正是“原生大模型无法做 Agent”的根本原因：大模型缺乏自主决策能力与执行闭环。

3. Agent 所需的核心能力 —— 对照 LLM 的缺失项

要理解为什么原生大模型无法做 Agent，需要拆解一个典型智能 Agent 的四个核心能力支柱，并逐一对照 LLM 的缺失。

3.1 环境感知

Agent 必须能获取实时环境信息：系统时间、用户位置、API 返回状态、传感器数据等。原生大模型对此完全无感知 —— 它不知道今天是几号，不知道用户当前在哪个城市，不知道数据库里有几条记录。即便模型通过训练语料记住了某些高频事实（例如“北京是中国的首都”），但面对“北京今天空气质量如何”这类实时问题，它只能承认无法回答。

为什么缺失：训练过程是离线的文本预测任务，模型从未被暴露在需要读取外部数据源的场景中。没有输入接口，就不可能有感知能力。

3.2 工具调用

Agent 通过调用外部工具（API、数据库、文件系统、计算器）来执行具体动作。原生大模型的输出仅限于文本，无法真正触发任何系统调用。即使模型在回答中写出 SELECT * FROM users WHERE id = 1，这段 SQL 也不会被实际执行 —— 它只是一个文本输出。

关键区别：一些人可能会认为“Function Call 机制让大模型能调用工具了”。但要注意，Function Call 本质上是大模型的一种原生能力机制，其关注点在 LLM 如何识别用户意图并生成工具调用指令，作用层级是在大模型推理层面。模型本身并不具备执行能力，它只是输出一个结构化的 JSON 调用指令，真正执行的是外围编排代码。

这个区别至关重要：大模型调用工具实现 Agent 依赖于外部工程系统，而非模型内生能力。

3.3 自主决策

Agent 需要自主决定接下来做什么 —— 在多个可选动作中选择，根据中间结果调整策略，在信息不足时主动询问。原生大模型的输出逻辑取决于输入上下文，本质上是被动响应的。如果用户不提供新的上下文，模型不会主动发起“下一步应该做什么”的自我提问。

实例对比：

原生大模型：用户问“北京天气怎么样？” → 模型回答“我无法获取实时数据。”
Agent 流程：用户问“北京天气怎么样？” → Agent 感知到需要工具 → 调用天气 API → 获取结果 → 判断是否需要额外动作（如提醒带伞）→ 输出最终回答。

Agent 的决策链条是由外围编排代码驱动的，模型在其中只扮演“意图理解”和“参数提取”的角色。真正的决策逻辑在编排层。

3.4 记忆与规划

Agent 需要记忆历史交互（之前调用过什么工具、获得什么中间结果），并能基于当前状态规划后续动作。原生大模型的“记忆”仅限于上下文窗口内的内容。一旦对话超过窗口长度，早期信息被截断，Agent 就“失忆”了。更关键的是，模型天然不具备规划能力 —— 它不会主动写出“我需要先查天气，然后判断是否需要提醒带伞，接着提醒用户”这样的计划，除非在外层提示词中显式要求。

工程实践提示：在构建 Agent 时，规划部分通常由提示工程或专门的规划模块（如 ReAct 框架）实现，而不是依赖模型自主规划。

4. 从 LLM 到 Agent 的桥梁：Function Call 与 MCP 协议

既然原生大模型缺失上述能力，业界自然发展出了多个层次的补充方案。其中 Function Call 和 MCP 协议是最具代表性的两个，但它们服务于不同层级。

4.1 Function Call —— 大模型的工具指令生成器

Function Call 是 OpenAI、Google、Anthropic 等主流大模型厂商提供的 API 特性。它允许开发者在请求参数中声明一组可用的工具函数（名称、描述、参数结构），然后模型在回复时可以选择性地返回 tool_calls 字段，其中包含标准 JSON 格式的调用指令。

工作原理：

开发者在 API 请求中定义工具（例如 get_weather，要求参数 city、date）。
模型根据用户输入判断是否应该调用哪个工具，输出类似：{"function": "get_weather", "arguments": {"city": "北京", "date": "2025-01-15"}}。
外部代码解析此 JSON，实际执行函数，将结果作为新的系统消息追加到对话中。
模型基于工具返回结果生成最终回答。

本质：Function Call 让大模型具备了“生成调用指令”的能力，但没有赋予其“执行”或“决策”能力。模型输出的是“建议”而非“动作”。这可以类比为一个工程师在图纸上标注了“此处需安装螺栓 M8×20”，但本人不去拧螺栓。执行必须由外围系统完成。

4.2 MCP 协议 —— 智能体的执行框架

MCP（Meta-Command Protocol）是一个更高层级的概念，它本质上是一个 AI Agent 的架构框架。MCP 不仅解决工具调用问题，还涵盖了状态管理、错误恢复、安全约束、多步编排等更完整的能力。

MCP 的关键组成部分：

调度层：决定调用顺序、超时策略、重试逻辑，而不是让模型自己决定下一步。
状态层：维护上下文中实时更新的状态变量（如“当前用户是否已验证”），弥合上下文窗口限制。
工具层：注册可用工具列表，并包含安全校验（权限检查、参数校验、结果审查）。
恢复层：当工具调用失败或返回异常时，执行预设的 fallback 逻辑，而不是让模型自行应对。

Function Call vs MCP 对比：

维度	Function Call	MCP 协议
抽象层级	单次调用机制	完整执行框架
决策主体	模型（通过 API 输出）	外围编排系统
错误处理	无，需要开发者手动实现	内置重试、降级、报警
状态管理	依赖开发者手动维护上下文	提供状态层自动管理
适用范围	单个工具调用场景	多工具、多步骤、长流程

值得注意的是，MCP 本质上是一个 AI Agent 协议，它关注的是如何将 LLM 的“理解”能力转化为可执行的系统行为。Function Call 是 MCP 体系中用于“模型与工具通信”的一个组件，但不是全部。

4.3 为什么不能直接依赖 Function Call 做 Agent

实践中，一些团队尝试只用 Function Call 实现 Agent 功能，但会遇到明显瓶颈：

单次调用 vs 多步规划：Function Call 天然是一次性的，如果需要分步骤调用三个工具，必须在外围代码中写循环或状态机。
错误处理缺失：工具返回异常时，模型不会自动调整行为，因为模型无法感知“执行失败了”这个事实（它只看到了文本化的错误消息）。
上下文膨胀：每多一次工具调用，对话就增加几轮消息，很快就跑满上下文窗口。需要开发者手动设计压缩策略。

因此，一个实用的结论是：Function Call 是构建 Agent 的必要基础设施，但不是充分条件。必须搭配编排框架（如 LangGraph、CrewAI）或自主协议（如 MCP）才能补全 Agent 能力。

5. 实战：构建一个最小 Agent —— 基于 Function Call + 外部工具

为了更直观地说明原生大模型和 Agent 的差异，下面通过一个最小示例演示如何使用 Function Call 接口让大模型完成一个简单的天气查询与决策任务。示例使用 Python 模拟实现，不依赖真实 API 密钥。

5.1 直接对比：原生大模型 vs Agent

from typing import List, Dict, Callable

# 模拟一个原生大模型：只有语言理解，无法执行动作
def llm_reply(prompt: str) -> str:
    if "天气" in prompt:
        return "抱歉，我无法获取实时数据，请查天气网站。"
    return "我只有文本能力，不能执行任务。"

# 定义一个工具函数
def get_weather(city: str) -> str:
    # 模拟天气查询
    return f"{city}今日天气晴，25°C"

# 简单的Agent：借助大模型理解意图 + 调用工具
class SimpleAgent:
    def __init__(self, tools: Dict[str, Callable]):
        self.tools = tools

def act(self, user_input: str) -> str:
        # 1. 用大模型理解意图（这里简化关键词匹配）
        intent = "get_weather" if "天气" in user_input else "unknown"
        if intent in self.tools:
            # 2. 提取参数（模拟）
            city = user_input.split("天气")[0].strip() or "北京"
            return self.tools[intent](city)
        return llm_reply(user_input)

# 对比：原生大模型 vs Agent
user_query = "北京天气怎么样？"
print("【原生大模型】:", llm_reply(user_query))
agent = SimpleAgent({"get_weather": get_weather})
print("【Agent】:", agent.act(user_query))

输出结果：

原生大模型：抱歉，我无法获取实时数据，请查天气网站。
Agent：北京今日天气晴，25°C

这个简单的示例清晰展示了关键差异：大模型负责文本理解（提取意图和参数），外围代码负责实际执行。模型本身没有任何动作，Agent 的行为来自编排逻辑。

5.2 基于真实 Function Call API 的构建步骤

如果接入真实的大模型 API（如 OpenAI、Claude），构建 Agent 的标准流程如下：

步骤 1：定义工具函数

1
2
3

def get_weather(city: str, date: str = "today") -> dict:
    # 实现天气查询逻辑，返回结构化数据
    return {"city": city, "temperature": 25, "condition": "晴"}

步骤 2：构造 API 可识别的工具描述

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取指定城市指定日期的天气信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称"},
                    "date": {"type": "string", "description": "日期，格式 YYYY-MM-DD"}
                },
                "required": ["city"]
            }
        }
    }
]

步骤 3：调用 API 并处理 tool_calls

# 伪代码示意
response = openai_client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "北京今天天气怎么样？

"}],
    tools=tools,
    tool_choice="auto"
)

# 检查是否有工具调用指令
if response.choices[0].message.tool_calls:
    tool_call = response.choices[0].message.tool_calls[0]
    function_name = tool_call.function.name
    arguments = json.loads(tool_call.function.arguments)
    # 执行对应函数
    result = get_weather(**arguments)
    # 将结果追加到对话中
    messages.append({
        "role": "tool",
        "name": function_name,
        "content": json.dumps(result)
    })
    # 第二次调用，让模型基于结果生成回答
    final_response = openai_client.chat.completions.create(
        model="gpt-4o",
        messages=messages
    )

关键说明：从代码可以清楚看到，真正的决策逻辑是外围编排代码控制的 —— 开发者决定是否执行工具、如何执行、如何将结果回传给模型。模型本身生成的 tool_calls 只是“建议”，如果不经过执行和回传，Agent 就不具备任何执行能力。这正是 Function Call 与 Agent 区别的核心：前者是能力机制，后者是完整的系统架构。

6. 进阶技巧与踩坑记录

在将原生大模型转化为 Agent 的工程实践中，我总结了几个容易踩坑的问题和对应的解决方案。

6.1 稳定性问题：调用指令格式漂移

大型语言模型（尤其是参数规模超过 70B 的模型）在生成 JSON 格式的 arguments 时，偶尔会出现格式错误：缺少括号、键名大小写不一致、布尔值写作字符串等。随着模型规模的扩大，这种漂移现象反而可能加剧，而不是减弱。

解决方案：

使用如 pydantic 的 schema 校验，对模型输出的参数进行严格验证
对格式不合法的调用执行重试（最多 3 次，每次请求带上更严格的提示词约束）
在生产环境中，建议使用格式约束更强的模型路线，或使用专门函数生成的微调模型

6.2 真实环境不确定性：工具返回异常的处理

Agent 在封闭测试环境表现良好，但当它面对真实系统的不确定性时，挑战立刻显现：API 超时、第三方服务返回 HTTP 500、数据库连接中断、参数值超出预期范围。大模型本身不具备对这些异常的感知能力 —— 它只会将异常信息当作普通文本，并按语言模式继续生成回复，可能导致更严重的错误。

工程建议：

工具函数中实现健壮的错误处理，对异常返回标准化的错误码
在外围编排层添加 fallback 逻辑：当工具返回错误时，预设降级方案（例如：本地缓存 → 默认值 → 人工介入）
在 tool_calls 验证阶段就引入业务规则检查

6.3 上下文窗口管理

多轮工具调用后，对话历史会迅速膨胀。以一个简单的“帮我规划周末北京游”任务为例：可能需要调用天气查询、酒店搜索、景点推荐、交通查询等 4-5 个工具，每个工具调用至少产生 2 条消息（调用指令 + 结果），很快超出大多数模型的 4K-8K tokens 最佳窗口。

实用策略：

滑动窗口：只保留最近 K 轮交互，移除早期工具调用细节
摘要中间结果：每执行完一个工具，用 LLM 将结果摘要为 1-2 句话，替代原始长文本
分片处理：如果任务可拆分子任务，每个子任务使用独立的上下文窗口

6.4 安全边界

Agent 失控最危险的情况是：用户通过提示注入诱导模型调用一个危险的工具操作，例如 delete_file、transfer_funds、shutdown_server。模型本身的指令遵循能力越强，此类风险越高。

防御措施：

明确区分“只读工具”和“写操作工具”，写操作工具在执行前要求用户二次确认
工具调用参数严格校验：禁止传入 shell 命令、文件名中的目录穿越字符等
在编排层建立白名单机制：只允许调用预先注册的工具和参数范围
对工具的返回结果进行审查，防止 LLM 被诱导输出恶意内容

7. 总结与拓展

7.1 核心要点回顾

原生大模型无法做 Agent 的根源在于三个根本性缺失：

缺失维度	具体表现	工程弥补方案
执行能力	只能输出文本，无法触发系统调用	Function Call + 外围编排代码
环境感知	对实时数据、系统状态、用户上下文无感知	工具定义中加入感知类函数（get_time、get_location 等）
规划与恢复	没有目标分解和错误恢复的自主机制	MCP 协议 / ReAct 框架的分层调度层

必须明确：这些缺失是模型架构的本质限制（无执行引擎、无感知接口、无反馈闭环），无法通过数据训练或提示工程在模型内部解决。“大模型缺乏自主决策能力” 是结构性缺陷，不是参数规模可以弥补的。

7.2 拓展方向

多智能体协作：未来 Agent 将走向多智能体架构，每个 Agent 负责一个专业领域，由编排层协调。这比单个大模型包揽所有任务在稳定性、可扩展性上更具优势。
AI 原生组织架构：业界（如 UBC 研究团队）已经提出“AI 原生组织架构”，即不模仿人类组织形态（经理、工程师、产品经理），而是按照模块职责设计 Agent 角色。

这是与当前主流实践不同的新方向。

标准化协议成熟：MCP 协议等标准化框架正在成熟，它们将逐步减少每个团队重复造轮子的成本。预计 2025-2026 年会出现几个主流的 Agent 协议标准。

7.3 内部建议

基于上述分析，在我们的业务系统中，建议遵循以下原则：

不要期望模型自身进化出 Agent 能力：模型版本迭代更多在理解和生成质量上改进，不会突然具备执行和感知能力。把 Agent 能力看作独立工程层。
优先选用成熟框架：如 LangGraph、CrewAI、AutoGen，这些框架已经封装了编排、状态管理、错误恢复等大部分非功能性需求。

不要从零搭建。
3. 对高安全等级场景额外加码：涉及写操作、支付、数据集修改的任务，Agent 的执行必须经过审批流程，不能完全自动。
4. 持续关注 MCP 协议生态：当协议标准趋于稳定且被主流模型服务支持时，可显著降低 Agent 系统的集成与维护成本。

原生大模型是优秀的“大脑”，但要让它们成为真正的“智能体”，还需要一副完整的“躯干和四肢”。理解这条分界线，是设计可靠 Agent 系统的第一步。

总结

通过本文的学习，相信你已经对「原生大模型无法做Agent原因」有了更深入的理解。建议结合实际项目多加练习。如有疑问，欢迎交流！