LLM 概览

大语言模型的能力边界、典型局限，以及它与 Agent 系统的分工关系。

LLM（Large Language Model，大语言模型）是 Agent 的推理核心，但不是 Agent 本身。它擅长语言理解、生成、归纳和在一定约束下的推理；不擅长直接访问实时数据、持久记忆、精确计算和对外部系统产生可验证副作用。

一句话定义

LLM 是基于海量文本预训练的概率模型，给定上下文后预测下一个 Token 序列。它的输出是“最可能的续写”，不是数据库查询结果，也不是经过验证的执行计划。

能力分层

能力	模型层能做什么	通常需要系统层补什么
语言理解与生成	总结、改写、分类、翻译、解释	任务模板、输出格式约束
推理与规划	分解步骤、提出假设、比较方案	工具验证、状态机、人工确认
工具意图识别	判断何时调用工具、生成参数草稿	Schema 校验、权限、执行、重试
知识回忆	复述训练分布内的常识和模式	RAG、联网检索、版本化知识库
多轮对话	在当前上下文中保持连贯	Session、压缩、长期记忆、审计日志

三类典型局限

幻觉（Hallucination）：模型会生成听起来合理但不符合事实的内容。Agent 系统要用工具结果、引用来源和评测样例约束它，而不是只靠提示词“请不要说错”。
静态知识截止：模型不知道训练后的新事件，也不知道你的私有代码库。需要 RAG、MCP、API 和文件工具补足。
无原生副作用：模型本身不能改文件、发请求、跑命令。需要编排层把“工具调用意图”转成真实动作，并记录输入输出。

LLM 与 Agent 的分工

正在渲染图表…

《Claude Code Harness Engineering》把 LLM 的局限概括为三类：不能直接行动、缺少跨会话记忆、难以完成需要多步反馈的任务。Agent 的价值正在于给模型补上工具、记忆和行动-观察循环。来源：《Claude Code Harness Engineering：从入门到实战》，pp. 8-11。

工程师应记住的判断方式

阅读任何模型能力宣传时，先问：

这是单次生成就行，还是需要外部反馈闭环。
错误输出是可接受的草稿，还是会造成真实损失。
失败时能否定位到模型版本、提示词、工具结果还是编排逻辑。

如果第 2 条答案是“会造成真实损失”，就不要把责任只压在模型层。权限、沙箱、人工审批和可回放 trace 必须同时存在。

不要把 LLM 当成事实源

LLM 的强项是根据上下文组织语言和候选方案，不是维护一份自动更新的事实数据库。工程上应把“事实”和“表达”分开：

场景	可以让 LLM 做	不应只让 LLM 做
文档问答	总结检索结果、解释引用片段	凭记忆回答版本号、价格、政策
代码理解	根据已读文件归纳模块边界	猜测未读取文件的实现
运维排障	整理日志、提出排查顺序	不经验证直接执行高风险命令
产品客服	组织回答、识别意图	编造订单状态、库存和退款规则

这也是 RAG、MCP、数据库工具和浏览器工具存在的原因：让事实来自外部可验证系统，让模型负责解释、比较和决策建议。

Agent 中的模型输入输出

一个生产级 Agent 通常不会把用户消息直接丢给模型，而是装配成多层输入：

系统规则：身份、权限、安全边界、输出格式。
开发者规则：当前产品或任务流的流程约束。
用户目标：当前轮要完成的真实任务。
状态摘要：已经完成的步骤、失败原因、待办项。
证据片段：文件、检索结果、工具返回、日志。
工具定义：模型可用工具的名称、用途和参数 schema。

模型输出也不只有“回答文本”。在 Agent Loop 里，更重要的是计划、工具调用意图、结构化参数、停止原因和需要人工确认的风险点。

调试定位流程

当 LLM 驱动的 Agent 失败时，可以按下面顺序缩小范围：

输入是否足够：关键文件、工具结果、用户约束是否真的进入上下文。
指令是否冲突：系统提示、开发者提示、用户请求是否给出互相矛盾的目标。
输出是否可验证：自然语言结论有没有引用、schema、测试或工具结果支撑。
工具是否可靠：模型有没有选错工具，工具本身有没有失败或返回过长内容。
模型是否适配：任务是否超过当前模型的推理深度、上下文长度或多模态能力。

如果没有 trace，只看最终回答很难判断是哪一层失败。至少应记录 model、prompt version、输入摘要、工具调用、输出 token、错误码和人工确认点。

检查清单

需要实时事实时，是否接入了可验证的数据源，而不是依赖模型记忆。
需要外部动作时，是否有工具执行层、权限检查和回滚方案。
需要长任务时，是否有状态摘要、压缩和恢复机制。
需要高可靠结果时，是否有评测集、schema 校验或人工审核。
需要解释结论时，是否能追溯到具体证据，而不是只追溯到模型回答。