What LLMs Should Do大模型的能力边界比“能做什么”更值得想清楚过去一年多我们见过太多关于大语言模型LLM的讨论铺天盖地都是“LLM 能做什么”能写代码、能总结文档、能聊客服、能跑 Agent、能当知识库问答机器人。但真正在项目里落过地的人大概率会碰到另一类问题LLM 明明什么都能干一点为什么放到生产环境里反而处处别扭我见过不少团队踩同样的坑一上来就把核心业务逻辑整个交给大模型结果延迟、成本、一致性、安全性全线告急。回头复盘问题往往不在模型本身而在于一开始就没想清楚一个更本质的问题——LLM 应该做什么不应该做什么。这篇文章想聊的不是“LLM 有哪些能力”而是“LLM 的能力边界在哪里”。我会从三个实际问题切入怎么判断一个任务该不该交给 LLM、LLM 框架在中间起到什么作用、以及 ComfyUI 这类工具和 LLM 到底是不是必须放在同一台机器上跑。前两个问题决定架构选型和工程质量第三个问题看起来很小却经常让刚开始接触多模态和 Agent 的开发者纠结半天。如果你正在做 LLM 应用开发或者在选型阶段拿不准该让模型承担多少职责这篇文章可以帮你建立一个更清晰的判断框架。1. 为什么“LLM 该做什么”比“LLM 能做什么”更重要先思考一个问题同样是聊天机器人为什么有的做出来又稳又省钱有的做出来又慢又贵还不听指挥答案往往不是模型选得不好而是职责划分错了。大模型的本质是一个概率语言模型它的强项是“从大量文本中学习模式并生成合理的下一个词”。这意味着凡是接近“语言理解、生成、转换”的任务它都表现不错凡是需要“精确、确定、可复现、低延迟”的任务它的短板就会暴露出来。举个最典型的例子让 LLM 计算123456789 * 987654321。模型很可能给你一个接近但错误的答案而一个三行 Python 代码的print(123456789 * 987654321)永远不会错。这不是模型笨而是它的设计目标根本不负责精确计算。同样的道理扩展到业务系统里就会出现一系列问题让 LLM 直接充当规则引擎根据订单金额判断审批人结果某天模型改了判断逻辑让 LLM 返回 JSON 并写入数据库结果偶尔多出一个字段直接破坏了数据约束让 LLM 做实时风控平均响应延迟 2 秒结果钱没拦住用户还骂了一顿让 LLM 处理用户上传的敏感文件结果没做隔离数据直接从模型 API 走了一遍。这些问题并非 LLM 本身“不行”而是我们在架构设计时把不适合它的任务硬塞给了它。所以本文的核心判断是在 LLM 应用里最重要的设计工作不是提示词而是职责划分。先决定“哪些步骤必须由确定性代码完成”再决定“哪些步骤适合交给 LLM 生成”顺序永远不能反过来。2. 基础概念LLM 擅长什么不擅长什么为了让后面的判断框架有依据先简单过一遍决定 LLM 能力边界的关键概念。2.1 LLM 的基本工作原理LLM 的底层是 Transformer 架构通过海量文本训练学会预测下一个标记token。它没有真正的“理解”也不存在“数据库查询”这样的内部行为它只是在给定上下文的条件下计算最可能出现的下一段文本。这个机制决定了它的两个核心特征统计性输出天然带概率同一个问题可以给出不同答案没有严格的对错概念上下文约束模型只能基于聊天上下文内提供的信息做推理超过上下文窗口的内容它“看不见”。从这两个特征可以引出很多直接可用的推论。比如你希望它“始终按固定格式输出”就需要在提示词里给出格式示例甚至用函数调用约束你希望它回答公司内部知识库的问题就必须先把知识文档检索出来放进上下文否则它只能“自由发挥”。2.2 LLM 适合与不适合的任务清单我习惯把任务按“是否依赖语言能力”和“是否要求精确执行”分成四类评估速度非常快。任务类型例子适合 LLM 吗原因语言生成类写周报、生成广告文案、改写翻译非常合适LLM 的核心强项语言理解类抽取关键字段、情感分类、摘要、意图识别合适需要配合结构化输出和校验知识问答类基于给定文档回答或结合检索增强部分合适必须把可靠知识放进上下文否则易幻觉精确计算类金额计算、数量校验、时间换算不适合概率模型不适合确定逻辑规则执行类权限判断、状态机流转、审批条件不适合模型判断不稳定且难以审计低延迟高频类点击数统计、接口鉴权、日志解析不适合延迟高、成本高确定性逻辑更优一对一教学/陪伴角色对话、学习答疑、灵感助手很合适包容错误强调自然交互这个表并不绝对但它能帮你快速排除“明显错误”的方案。比如有人想用 LLM 判断“用户是否已登录”这完全是逻辑判断应该由会话层做有人想用 LLM 生成一段工作日报则非常合理。2.3 幻觉与不确定性的根源前面提到 LLM 是统计模型这里必须延伸讲一下幻觉。幻觉不是 bug而是概率生成的副作用。模型在训练时学到的是“语言模式”不是“事实数据库”。当它遇到一个知识空白不会像搜索引擎一样返回“找不到”而是倾向于生成一段看起来通顺的内容这段内容可能完全错误。明白了这一点就不会再奢望“换一个更大的模型幻觉就消失了”。真正有效的做法是在需要准确性的场景里用确定性手段补偿。典型方案把 LLM 的输入和输出都约束住。输入侧把外部资料经过检索后塞进上下文模型只能基于资料回答输出侧用函数调用、JSON Schema 校验、规则过滤等手段确保输出结构可控。这也是后面最佳实践部分要展开的关键点。3. LLM 框架的角色帮你做“LLM 该做的事”的一半理解了能力边界再看“LLM 框架”这个话题就清楚多了。现在开源社区里各种框架层出不穷很多初学者一上来就选框架其实应该先想清楚框架到底帮你解决了什么。3.1 框架解决的核心问题一个裸的 LLM API 只做一件事输入文本、输出文本。但在真实应用里我们还需要管理对话历史把多轮消息拼成模型需要的格式管理上下文窗口超出长度时做截断、摘要或检索让模型调用外部工具如查询数据库、访问内部 API维护 Agent 的执行循环让模型决定下一步动作同时对接多个模型供应商方便切换和容灾。这些工作如果全部自己写重复代码量很大而且很容易出错。框架的价值就是把这些通用能力做成可复用的组件让开发者专注于业务本身。3.2 框架不是越多越好框架确实有用但它不是银弹。从工程经验看引入框架会带来三个直接成本抽象成本框架帮你封装了复杂逻辑但出了问题你得先理解框架的实现排查链路更多升级成本LLM 领域迭代飞快框架版本经常变化接口不兼容是常事锁定的风险如果业务完全依赖某个框架的工具调用格式以后切换框架等于重写一层逻辑。所以我的建议是小项目、原型验证、学习阶段先用裸 API 跑通只有当项目确实出现跨模型接入、复杂工具调用、多 Agent 协作等需求时再引入框架。3.3 框架选择三要素如果决定用框架优先看三个点社区活跃度与维护频率太冷门的框架风险高是否支持你实际使用的模型供应商文档中是否有完整的生产部署案例而不是只有 demo。框架只是工具不是目标。你需要的是“把 LLM 嵌入到合适的任务里”框架顶多让这个过程更顺一些。4. 一个容易误解的问题ComfyUI 与 LLM 必须在同一台电脑上吗在讨论“LLM 该做什么”时还有一个经常被新手问到的实际问题ComfyUI 与 LLM 必须在同一台电脑上吗先说结论不需要。ComfyUI 是一个用于构建图像生成工作流的开源工具通常用于跑 Stable Diffusion 等图像模型它和 LLM 不是同一个东西也不要求部署在同一台机器上。很多开发者把“ComfyUI”和“LLM”搞混脑子里形成一个模糊场景“我要做一个既能聊天又能画图的应用是不是要在一台超级电脑上同时跑两个大模型”实际上这两者的关系完全可以通过网络解耦。4.1 推荐的架构服务分离从工程上看更合理的做法是把 ComfyUI 和 LLM 拆成独立服务各自部署在适合它的硬件上通过 HTTP 或消息队列通信。LLM 服务负责文本理解、对话、工具规划通常部署在 CPU 推理优化较好或 GPU 规格合适的机器上ComfyUI 服务负责图像生成通常需要独立 GPU且显存需求较大两者之间通过 API 调用上层应用先调用 LLM 生成绘图提示词再调用 ComfyUI 接口出图。这种架构的好处很直接可以分别扩缩容、分别升级、互相不影响。图像生成请求峰值高就给 ComfyUI 服务多挂几台 GPU 机器文本对话请求量大就给 LLM 服务做负载均衡。放在同一台机器上反而会因为显存和 CPU 争抢导致两边都跑不顺。4.2 什么时候需要考虑同机部署虽然默认不需要同机部署但有两种场景确实可以考虑就近部署低延迟要求极高比如本地实时交互应用网络调用延迟不可接受那就把两者放到同一内网甚至同一台机器离线环境在数据不能出内网的场景里ComfyUI 和 LLM 都只能本地化的机器上跑物理距离就近部署是合理的。但即便物理上同机也建议用进程隔离 不同端口的方式运行不要让两个服务直接耦合在一个进程里。5. 实操从零构建一个 LLM 任务适配判断器理论讲完了接下来写一个可落地的示例。这个示例不是做一个完整的聊天机器人而是做一个更贴近实际需求的工程组件在调用 LLM 前后自动判断一个任务该不该交给 LLM以及如何校验 LLM 的输出。这个组件的应用场景很常见后端收到一个用户请求先做规则判断只有满足条件时才调用 LLM最后对 LLM 输出做格式校验。这样可以在架构层面保证“确定性逻辑不依赖模型”“模型的输出必须可控”。5.1 项目结构与环境准备示例使用 Python 3.9不需要任何第三方框架核心代码只依赖标准库。如果你要对接真实模型可以在此基础上替换成对应的 SDK比如 OpenAI 兼容接口。llm-task-adapter/ ├── main.py ├── task_classifier.py ├── llm_client.py └── validator.py先创建一个虚拟环境确保基础环境干净python -m venv .venv source .venv/bin/activate5.2 判断逻辑任务是否应该交给 LLMtask_classifier.py负责规则判断。这个文件的意义是把“该不该用 LLM”这个决策变成代码而不是靠人脑临时判断。# 文件路径llm-task-adapter/task_classifier.py from dataclasses import dataclass from enum import Enum class TaskCategory(str, Enum): RULE_BASED rule_based # 必须走确定性逻辑 LLM_GENERATION llm_generation # 适合 LLM 生成 LLM_WITH_VALIDATION llm_with_validation # 可以 LLM但必须校验结构 REJECTED rejected # 直接拒绝不处理 dataclass class TaskDecision: category: TaskCategory reason: str # 关键词黑名单命中这些词的请求不应直接交给 LLM FORBIDDEN_KEYWORDS [password, token, secret, id_card, phone] # 精确计算类纯数字运算不建议 LLM 处理 MATH_PATTERN [calculate, sum, multiply, subtract] def classify_task(user_input: str) - TaskDecision: text user_input.lower() # 1. 敏感数据直接拦截 for keyword in FORBIDDEN_KEYWORDS: if keyword in text: return TaskDecision( categoryTaskCategory.REJECTED, reasonf包含敏感关键词: {keyword}, ) # 2. 纯数学计算走代码逻辑 if any(word in text for word in MATH_PATTERN) and any( ch.isdigit() for ch in text ): return TaskDecision( categoryTaskCategory.RULE_BASED, reason检测到精确计算需求应使用确定性代码, ) # 3. 需要结构化输出的任务走 LLM 校验 if 提取 in user_input or json in user_input or 结构化 in user_input: return TaskDecision( categoryTaskCategory.LLM_WITH_VALIDATION, reason需要从文本中抽取结构化信息, ) # 4. 默认语言生成任务 return TaskDecision( categoryTaskCategory.LLM_GENERATION, reason默认语言生成场景, )这段代码体现了一个核心思想先拦截确定不该让 LLM 处理的请求再分流到不同处理路径。规则逻辑不复杂但比“所有请求一律丢给 LLM”稳健得多。5.3 LLM 客户端封装llm_client.py封装模型调用。为了不绑定具体厂商这里用一个最小化的 HTTP 示例兼容 OpenAI 格式的接口。实际项目中你可能需要配置base_url、api_key等参数代码里用环境变量读取。# 文件路径llm-task-adapter/llm_client.py import os import requests def generate_text( system_prompt: str, user_content: str, temperature: float 0.2, ) - str: 调用 OpenAI 兼容接口。 请在环境变量中配置 LLM_API_BASE 和 LLM_API_KEY。 api_base os.environ.get(LLM_API_BASE, https://api.openai.com/v1) api_key os.environ.get(LLM_API_KEY, ) resp requests.post( f{api_base}/chat/completions, headers{ Authorization: fBearer {api_key}, Content-Type: application/json, }, json{ model: os.environ.get(LLM_MODEL, gpt-4o-mini), messages: [ {role: system, content: system_prompt}, {role: user, content: user_content}, ], temperature: temperature, }, timeout30, ) resp.raise_for_status() data resp.json() return data[choices][0][message][content]这里的重点是temperature。做结构化抽取时建议设为 0.2 以下降低输出随机性做创意文案时再适当调高。工程上永远要记住大模型的随机性是特性也是风险必须根据任务类型动态调整。5.4 输出校验器validator.py负责校验 LLM 返回的结果结构。下面的例子校验“是否是一个合法 JSON 数组且数组元素包含name字段”。如果校验失败宁可报错重试也不要直接写入下游系统。# 文件路径llm-task-adapter/validator.py import json from typing import Any def extract_json_object(text: str) - dict[str, Any]: 从模型输出中提取 JSON 对象并做基础校验。 text text.strip() # 兼容模型输出包含 json 代码块的情况 if text.startswith(): text text.strip() if text.startswith(json): text text[4:] text text.strip() data json.loads(text) if not isinstance(data, dict): raise ValueError(模型输出不是 JSON 对象) return data def validate_json_array_with_name_field(text: str) - list[dict[str, Any]]: 校验 JSON 数组且每个元素必须包含 name 字段。 text text.strip() if text.startswith(): text text.strip() if text.startswith(json): text text[4:] text text.strip() data json.loads(text) if not isinstance(data, list): raise ValueError(模型输出不是 JSON 数组) for item in data: if not isinstance(item, dict): raise ValueError(数组元素不是对象) if name not in item: raise ValueError(数组元素缺少 name 字段) return data对于结构化输出另一种更推荐的做法是使用模型的函数调用function calling或 JSON Schema 模式。如果模型供应商支持优先用模型侧约束而不是输出后解析。输出后校验仍然建议保留作为最后一道防线。5.5 主流程串联main.py把上面的模块串起来模拟一个完整的处理流程收到用户请求 → 规则判断 → 决定是否调用 LLM → 校验输出 → 返回结果。# 文件路径llm-task-adapter/main.py from task_classifier import classify_task, TaskCategory from llm_client import generate_text from validator import extract_json_object def handle_request(user_input: str) - dict: decision classify_task(user_input) if decision.category TaskCategory.REJECTED: return {error: 请求被拒绝, reason: decision.reason} if decision.category TaskCategory.RULE_BASED: # 示例纯数字加法直接走确定性代码 numbers [int(ch) for ch in user_input.split() if ch.isdigit()] return {result: str(sum(numbers)), path: rule_based} if decision.category TaskCategory.LLM_WITH_VALIDATION: system_prompt ( 你是一个信息抽取助手。请从用户输入中提取所有人名 返回 JSON 数组每个元素包含 name 字段。只输出 JSON不要多余解释。 ) raw_output generate_text(system_prompt, user_input, temperature0.1) try: validated extract_json_object(raw_output) return {result: validated, path: llm_with_validation} except Exception as exc: return {error: f输出校验失败: {exc}, raw_output: raw_output} # 默认LLM 自由文本生成 system_prompt 你是一个有用的助手请用简洁的中文回答用户问题。 raw_output generate_text(system_prompt, user_input, temperature0.7) return {result: raw_output, path: llm_generation} if __name__ __main__: cases [ 帮我计算 12 45, 请从这里提取人名张三和李四参加了会议, 写一首关于秋天的短诗, 我的密码是 secret123请帮我处理, ] for case in cases: print(输入:, case) print(输出:, handle_request(case)) print(---)5.6 运行与预期结果安装依赖后运行主程序pip install requests python main.py如果没有配置真实 LLM 的 API Key涉及 LLM 调用的用例会抛异常这本身也是正确的表现。你可以先注释掉需要调用模型的分支比如只保留纯计算和敏感拦截两种场景验证规则判断部分是否工作。配置了真实模型后预期输出接近这样输入: 帮我计算 12 45 输出: {result: 57, path: rule_based} --- 输入: 请从这里提取人名张三和李四参加了会议 输出: {result: {names: [{name: 张三}, {name: 李四}]}, path: llm_with_validation} --- 输入: 写一首关于秋天的短诗 输出: {result: 秋风扫过林间路落叶纷飞似旧书。..., path: llm_generation} --- 输入: 我的密码是 secret123请帮我处理 输出: {error: 请求被拒绝, reason: 包含敏感关键词: secret}每次运行输出可能略有不同这符合预期因为 LLM 本身带有随机性。你更应该关注的是不稳定的部分是否被约束在可接受范围内确定性的部分是否没有被模型污染。这正是“LLM 该做什么”的工程化体现。6. 判断 LLM 是否适合某一任务的五个问题很多团队在设计阶段纠结“这个功能要不要用 LLM 做”。下面这五个问题可以作为快速评估标准逐个过一遍答案自然浮出水面。问题一这个任务允许出错吗允许一定的不稳定和创造性 → 适合 LLM比如文案生成、头脑风暴完全不允许出错比如金额计算、身份鉴权 → 不建议用 LLM 做主逻辑。问题二这个任务的延迟要求多高秒级甚至分钟级可接受 → 可以考虑 LLM要求毫秒级响应 → 应该用缓存、规则或更好预测的模型而不是通用大模型。问题三错误发生之后能追查、能回滚吗能记录日志、能人工修正、能回滚 → LLM 可以参与一旦出错会产生不可逆后果比如发送营销邮件、删除数据 → 必须加人审或规则闸门。问题四你的数据安全边界允许把数据发给模型供应商吗纯内部数据且不能出内网 → 要么私有化部署模型要么不要使用云 API数据脱敏后允许出网 → 需要先脱敏再调用。问题五这个任务真的需要“语言能力”吗核心是自然语言理解与生成 → LLM 是合理选择核心是查表、计算、状态判断 → 用传统代码更合适。这个清单适合贴在团队文档里。每次评审需求时拿出来逐条过能少很多无效的技术方案讨论。7. 常见问题与排查方法在落地 LLM 应用时下面几个问题出现频率最高。这里给出具体的排查路径。问题现象可能原因排查方式解决方案模型输出结果不稳定时好时坏temperature 设置过高或提示词缺少格式约束检查请求参数和提示词中是否给出输出示例把 temperature 降到 0.2 以下配合 function calling 或 JSON Schema模型胡编乱造知识库内容上下文没有提供可靠的参考资料或检索增强未落地查看实际发送给模型的 messages确认知识文档是否真的在上下文中先检索再生成并在提示词中限定“只能基于资料回答”调用 LLM 的接口频繁超时模型供应商端延迟高或请求体过大查看耗时日志定位是排队还是响应慢增加超时与重试策略必要时换更快的模型或走异步队列输出 JSON 偶尔解析失败模型返回了额外的解释文字或转义字符异常打印原始输出确认前后格式在提示词中强制“只输出 JSON”并在代码中做代码块剥除和二次解析明明设计了规则某些请求还是走到了 LLM分类规则覆盖不全兜底逻辑过于宽松增加对全量日志的分类结果统计细化规则分支敏感场景设置默认拒绝多个模型切换后发现输出风格差异大不同模型的 system prompt 遵循能力不同对比同一提示词在两个模型上的输出按模型能力微调提示词不要假设一次提示词到处通用排查 LLM 应用问题时最重要的不是瞎试而是先看真实请求和真实输出。记录下每一次上送到模型的完整 messages 和返回的原始内容很多“玄学问题”会立刻变清楚。8. 最佳实践把 LLM 放对位置的工程建议最后这部分是实践经验的沉淀按重要程度从高到低排列。8.1 确定性逻辑与生成逻辑分离这是本文最重要的建议。账务计算、状态流转、权限判断、数据存储这些必须由确定性代码完成LLM 只负责“生成”和“理解”部分。哪怕模型有一天突然抽风最坏情况也只是生成内容不对而不会把钱算错、权限放错。8.2 输出一定要做结构约束无论用什么模型都建议对输出做两层约束请求侧使用函数调用、JSON Schema、few-shot 示例让模型在生成前就“知道”格式响应侧写一个解析和校验模块对模型输出做结构检查不合法就重试或降级。两层约束缺一不可。请求侧降低出错概率响应侧兜底避免脏数据进入下游。8.3 敏感数据处理要前置拦截只要涉及用户个人信息、密码、密钥就必须在业务代码层做拦截不要把数据直接作为提示词发给外部模型服务。即使模型供应商承诺数据安全从合规和最小权限原则出发也应该在源头控制。8.4 需要准确的回答必须搭配检索增强LLM 不该承担“记忆海量事实”的职责。需要回答具体事实时先把相关资料检索出来放进上下文中。这样答案有依据幻觉概率显著降低。8.5 为每个 LLM 调用设计降级策略线上调用必然会出现超时、限流、模型故障。必须在设计阶段就想好降级策略超时后重试一次再失败则返回静态文案校验失败后可以重新生成但最多重试两次核心链路必要时切换到规则引擎兜底。降级策略本身不复杂关键是别等到出事了再补。8.6 日志里永远保留原始输入输出所有人都会犯错模型也不例外。生产环境必须记录每次 LLM 调用的完整原始请求和原始响应。这样一旦线上用户报告异常可以快速回放现场而不是靠猜。9. 想清楚“不该做什么”比猛学“能做什么”更重要这篇文章围绕“WLLMs Should Do”展开核心观点反复指向一句话给 LLM 划定职责边界是 LLM 应用工程化的第一步。我们聊了 LLM 的能力边界结论是它擅长语言理解和生成不适合精确计算与规则执行聊了 LLM 框架的角色结论是框架解决复用问题但不要在项目早期盲目引入聊了 ComfyUI 与 LLM 是否需要同机部署结论是可以通过 API 服务化拆开物理部署与逻辑职责完全解耦最后用一个最小示例演示了如何在代码层面把“该不该调 LLM”变成可执行的决策逻辑。下一步你可以从两件事开始打开你现在负责的 LLM 项目把所有调用了大模型接口的地方列出来逐个问一遍“这一步真的需要 LLM 吗”“如果模型返回垃圾系统会不会崩”在这个清单里找出至少一个“其实不该让 LLM 做”的环节改成确定性代码再对比一次延迟和成本。这个过程做完你会对“LLM 该做什么”有比这篇文章更深刻的答案。模型能力还在快速演进今天不适合的任务明天也许就适合了但只要判断框架还在架构就不会因为模型升级而失控。