大模型的能力边界：为什么光靠 LLM 不够用

在正式介绍 LangChain 之前，我们需要先回答一个根本性的问题：大语言模型本身有什么做不到的事情？ 只有理解了 LLM 的短板，你才能真正理解 LangChain 这类框架存在的意义——它本质上就是一套"补丁系统"，专门用来弥补大模型的那些先天缺陷。

大模型很强，但不是万能的

先承认一个事实：GPT-4o、Claude 这些前沿模型确实令人印象深刻。它们能写诗、编代码、翻译语言、做数学题、甚至通过律师资格考试。但如果你真正把它们投入到生产环境中去解决实际业务问题，很快就会碰到一系列让人头疼的问题。

问题一：知识有"保质期"

这是最直观也最普遍的痛点。大模型的知识来自于它的训练数据，而训练数据有一个时间截点。比如 GPT-4o 的训练数据大致截止到某个日期之前——这意味着它不知道这之后发生的任何事。

# 假设今天是 2025 年，你问 GPT-4o：
question = "2025 年诺贝尔物理学奖得主是谁？"
# 它可能会一本正经地胡说八道 —— 因为它根本不知道这件事

这个问题在快速变化的领域里尤为致命。技术文档更新了、产品功能改版了、法律法规调整了——但模型还停留在旧认知上。更麻烦的是，它不会告诉你"我不知道"，而是会自信地编造答案。

这就是所谓的幻觉（Hallucination）问题——模型生成的内容看起来非常合理、语法正确、逻辑通顺，但事实完全错误。对于用户来说，这种错误比直接报错更危险，因为你可能根本意识不到它在撒谎。

问题二：没有真正的"记忆"

你跟 ChatGPT 聊了一个小时，聊了很多个人偏好和工作细节。你以为它"记住"了？其实没有。每次新对话开始时，它对你一无所知。

这是因为大模型本身是无状态的（stateless）。它接收输入、产生输出，然后对话结束——没有任何持久化的存储机制能把这次对话的内容带到下一次。当然，现在的产品级应用（如 ChatGPT 网页版）通过外部数据库实现了"历史记录"，但这不是模型本身的能力，而是工程层面的包装。

# 模型的本质是这样的：
def llm_chat(input_text: str) -> str:
    """每次调用都是独立的，不保留任何状态"""
    return generate_response(input_text)

# 第一次调用
response_1 = llm_chat("我叫小明")
# 第二次调用 —— 模型完全不知道你刚才说过什么
response_2 = llm_chat("我刚才叫什么名字？")  
# 结果：它大概率猜不出来

对于需要多轮交互的应用场景（比如客服机器人、私人助手），这种"失忆症"是致命的。

问题三：无法连接真实世界

大模型生活在纯文本的世界里。它能理解"北京今天多少度"这句话的含义，但它不能真的去查天气 API；它能帮你写一段 SQL 查询语句，但它不能真的连上你的数据库执行查询；它能解释一段代码的逻辑，但它不能真的运行这段代码看输出结果。

换句话说，LLM 是一个信息处理引擎，不是一个行动执行引擎。它擅长的是理解和生成文本，而不是与外部世界进行交互。

# LLM 能做的：
llm_response = """
SELECT * FROM users WHERE created_at > '2025-01-01'
"""
# 但它不能执行这条 SQL —— 除非有东西帮它执行

# LLM 能做的：
calculation = "23 * 45 + 67"
# 但它不一定算得准 —— 尤其是大数字或复杂运算

这就引出了一个关键需求：如果能让 LLM 在需要的时候调用外部工具——搜索引擎、数据库、代码执行器、计算器——那它的能力边界就会被极大地扩展。而这正是 LangChain 要解决的核心问题之一。

问题四：复杂任务容易"跑偏"

当你给 LLM 一个简单明确的任务（比如"把这段话翻译成英文"），它通常表现很好。但当任务变得复杂——需要多步推理、需要遵循严格的格式约束、需要在多个子目标之间切换注意力——模型的出错率就会显著上升。

一个典型的例子：让模型从一篇长文章中提取结构化信息并填入表格。如果文章很短、字段很少，模型大概率做得不错。但如果文章有 50 页、表格有 20 列、某些字段需要跨段落综合判断，模型就开始丢三落四：漏掉某些行、把值填错列、或者干脆自己编造一些看起来合理但原文中没有的数据。

这是因为大模型的**上下文窗口（Context Window）虽然很大（比如 128K tokens），但它的"注意力"是均匀分布的——当信息量过大时，它对每个细节的关注度都会被稀释。就像一个人同时听 10 个人说话，大概率谁的话都听不全。

总结：四大核心痛点

把上面讨论的所有问题归纳一下：

痛点	表现	根因
知识陈旧	不知道训练截止后的事	训练数据有时间边界
幻觉	自信地编造错误信息	优化目标是"下一个 token 最可能是什么"而非"事实正确"
无记忆	对话之间无状态	架构设计为无状态的请求-响应模式
无工具	只能处理文本，不能行动	没有连接外部系统的接口
复杂任务易出错	长链路任务容易丢失细节	注意力分散 + 缺乏结构化推理框架

这些问题中的每一个，都在呼唤同一类解决方案：需要一个编排层（Orchestration Layer），站在 LLM 和真实世界之间，负责管理上下文、调度工具、控制流程。而这个编排层，正是 LangChain 要做的事情。

下一节我们就来看看：LangChain 到底是怎么设计的？它的核心理念是什么？