Jason Liu 这个名字关注大模型应用开发的人应该不陌生。他是 Instructor 库的作者也是 LiteLLM 的核心维护者之一长期泡在 LLM 工程化的一线写了不少关于结构化输出、函数调用、Agent 设计这些“脏活累活”的经验。他最近反复强调的一个观点概括起来就是“轻量思考”——不是教人偷懒而是劝大家在动手写 AI 应用前先别急着上重框架、堆复杂流程先用更轻的方式把问题想透。这个建议我觉得非常值得聊它直接戳中了很多团队在 LLM 项目里“重投入、低产出”的痛点。这篇就围绕 Jason Liu 的思路结合我自己做过的几个项目把“轻量思考”到底是什么、落地时怎么做、边界在哪里一次讲清楚。适合看这篇的主要是两类人一类是刚接触 LLM 应用开发喜欢跟风上 Agent 框架、但经常被复杂抽象绕晕的开发者另一类是已经在做 AI 应用但发现 Prompt 越来越难调、链路越来越难维护想换个思路做减法的技术负责人。内容不会涉及太深的研究算法更多是工程落地层面的思路和方法。1. “轻量思考”的来源一个常年写 LLM 框架的人为什么反框架1.1 从 Instructor 的设计哲学看他的技术偏好先说点背景。Instructor 这个库的核心能力是让大模型的输出直接映射到 Pydantic 模型上也就是说你可以定义好一个数据结构模型返回的内容会被自动校验、补全、重试直到符合结构要求。这个设计背后有个很明确的判断LLM 的文本生成能力再强在工程里真正可靠的是“结构”。Jason Liu 在多次分享里都提到过一个观点开发者最大的幻觉是以为模型“理解”了业务逻辑。实际上模型只理解文本模式不理解你的系统约束。所以他的做法是把业务逻辑尽量放在代码里把模型的职责收窄到“从自然语言里抽取信息”和“根据指令生成文本片段”。这正是“轻量思考”的雏形——不要指望模型像个全能 agent 一样替你思考而是让模型作为你代码逻辑里的一个组件插拔清晰边界明确。这套思维其实和传统软件工程里的“单一职责原则”一脉相承。你会发现 Instructor 没有试图去解决的问题比如多轮对话管理、长期记忆、任务规划它一概不碰。这些复杂的职责被刻意排除在框架核心之外留给开发者自己去组合。Jason Liu 经常说的一句话大意是框架越少你需要做对的决策就越少你的系统就越可控。1.2 “轻量思考”不是什么别把降低思考量理解成降低要求“轻量思考”这个名字很容易被误解成“别想太多赶紧写代码”。恰恰相反它要求你在动手前把问题想得更透只不过思考的对象不是“模型会怎么想”而是“我的系统需要什么输入、什么输出、什么边界条件”。我自己刚接触 LLM 开发时最常见的工作方式是这样的拿到需求先找一个 Agent 框架定义一堆 Tool再把历史对话塞进去然后开始调 Prompt。搞了两周发现模型经常调用错误的工具、漏掉必要参数问题出在哪儿都说不清楚。后来用 Jason Liu 的思路重新过了一遍才发现大部分复杂度是框架自带的而不是业务本身要求的。所以“轻量思考”的核心是区分哪些复杂度来自业务真实需求哪些复杂度来自技术选型。真实业务要处理多轮纠错、权限校验、知识库检索那这些必须有但如果只是因为“用了框架就得按框架的抽象写代码”这部分复杂度就是可以砍掉的。轻量思考不是不做设计而是把设计重点放在“数据怎么流转”而不是“模型怎么思考”上。2. 为什么 AI 应用容易陷入过度设计轻量思考怎么破局2.1 一上来就搭框架的冲动源自对不确定性的恐惧我自己踩过最大的坑是在一个知识库问答项目里一开始就选了一个重量级 Agent 框架。当时的心态很简单既然要做的功能多那框架的功能越全越好后面不用再改。结果框架的学习成本、概念负担、版本兼容问题直接拖慢了项目节奏。Jason Liu 对这种现象有个很有意思的观察很多团队之所以选重框架不是因为业务需要而是因为不想面对“从零开始做决策”的焦虑。框架替你规定好了 Agent、Tool、Memory、Planner 这些概念你觉得心里有底了但实际上这些概念是不是适配你的场景没人知道。轻量思考的破局方式是强迫自己回答四个问题再写代码用户输入是什么格式固定吗我期望的输出是什么结构化的还是自然语言的中间要经过几个步骤这些步骤是固定顺序还是动态决定的出错时我能接受重试几次代价有多大这四个问题不需要任何框架就能回答。而一旦回答清楚你会发现至少一半所谓的“Agent 能力”根本用不上。2.2 流程固定用代码流程动态才考虑模型决策业界关于什么时候该用 Agent、什么时候用普通 pipeline其实有过很多讨论。Jason Liu 的原则非常直接能用代码写死的流程绝不让模型参与决策。理由很简单模型决策有概率性同样的输入今天走这条路、明天走那条路这对调试和测试都是灾难。我后来在一个客户工单分类系统里实践了这个原则。最初版本我让模型自己判断“该查订单、查物流还是直接回复”结果准确率忽上忽下。后来改成先用一个轻量分类模型把工单分成三类再按类别各自走固定处理流程结构化的查库逻辑交给代码处理只有最终的回复文案交给模型生成。改完之后准确率不仅提升了而且每次出问题都知道该排查哪一段。这就是典型的重心转移把模型从“流程决策者”降级为“步骤执行者”。很多 AI 应用不稳定不是模型不够聪明而是把太多决策压给了模型。流程稳定的部分应该彻底代码化模型只负责它真正擅长的自然语言理解和生成。2.3 先定 Schema再写 Prompt顺序反了会一直返工Jason Liu 的另一个高频建议是先定义数据结构再围绕结构写 Prompt。这个顺序看似简单但绝大多数开发者是反着来的——先写 Prompt 让模型吐自然语言然后再从文本里解析字段解析失败就加正则、加重试最后变成一团乱麻。我建议的顺序是这样的先画出这个功能涉及的所有实体和字段例如“订单号、用户问题、分类、处理结果”用 Pydantic 或者 TypeScript Interface 把这些字段定义成强类型让模型直接以 JSON 格式返回并用校验库做类型校验校验失败就带着错误信息重试一次而不是默默解析出半成品。这样做的底层逻辑是把大模型当成一个“函数”输入是用户消息加指令输出是符合既定 Schema 的 JSON。这个“函数”内部怎么想的不重要只要输出结构稳定上层业务代码就能像调普通函数一样调它。轻量思考在这里的体现就是不要尊重模型输出的“自由意志”要尊重你自己定义的结构约束。3. 实操落地三个场景演示如何践行“轻量思考”3.1 场景一用户意图识别与槽位填充第一个场景是智能客服里的意图识别。很多人第一时间想到微调模型或者上对话理解平台但 Jason Liu 的思路会先问一句你的意图类别有多少种槽位是固定的还是开放的以我做过的一个售后支持系统为例。当时需要识别用户的问题是“退货”“换货”还是“维修”同时抽取“订单号”“商品名称”“问题描述”三个槽位。我的做法非常轻量系统提示词里写清三类意图的定义、三个槽位的 JSON 结构再给两个 few-shot 示例然后让模型直接返回 JSON。没有用任何 RAG没有知识库也没有复杂的对话状态管理。上线后准确率稳定在 92% 以上对不上的那部分主要是用户表述本身模糊靠人审兜底。这里的关键是意图类别只有三种槽位边界清楚模型完全能够胜任。轻量思考的价值在于识别出“这件事不需要重型方案”帮你省掉不必要的架构成本和延迟。3.2 场景二用工具调用替代 Agent 编排Agent 是现在最热门的概念但 Jason Liu 对 Agent 的态度一直比较谨慎。他在多个场合提到大部分业务里的“智能体”其实只是“带工具调用的多步骤流程”没必要套用复杂的规划算法。我做一个“周报助手”的时候最初的设想是让 Agent 自己决定先读取本周提交记录、再汇总项目进度、最后写成周报。看起来很美但模型经常在“读取记录”之后就停下来或者跳过某个步骤。后来我按照轻量思考拆了一下读取记录用代码直接做汇总数据用模板拼出来只有“写一段自然的周报描述”这一步交给模型。整个流程变成代码查询代码仓库和项目管理系统拿到本周 commit 和任务状态按固定模板生成结构化数据把数据送给模型让它用自然的语气写成人话输出 markdown 周报。这个方案跑了大半年再也没出现过“Agent 中途罢工”的情况。我理解 Jason Liu 说“少用 Agent”不是否定 Agent而是提醒大家Agent 框架引入的自主性和不可预测性只有在流程本身充满不确定性时才值得付出。流程一旦跑顺立马回归到普通代码这才是长期维护的正道。3.3 场景三模型分层——所有请求都走大模型就是最大的浪费轻量思考在资源层面还有一个重要体现不要所有请求都用最强的模型。GPT-4 级别的模型和轻量模型价格和延迟差很多倍但并非所有任务都需要那么强的推理能力。我在一个信息抽取项目里做过对比抽取出入口、日期、金额这些固定字段用轻量模型和用顶级模型准确率差距不到 2%但成本差了将近 10 倍。于是我把任务分了两层简单字段抽取走轻量模型复杂语义判断例如判断合同里是否存在隐含的违约责任走强模型两边通过同样的 JSON Schema 输出上层代码完全无感。这种分层策略就是 Jason Liu 常说的“模型也是需要管理的资源”。轻量思考不仅指流程设计上的克制也包括模型选择上的理性。别总想着用一个万能大模型解决所有问题拆开来看很多任务根本不需要“思考”。4. 轻量思考在模型推理层面的延伸控制推理深度别让模型想太多4.1 让模型“少想”反而能提升稳定性Jason Liu 建议用“轻量思考”在提示词层面有一个非常直接的体现不要一上来就要求模型“一步一步地思考”也不要让它自由发挥太长的推理链。原因在于推理步数越长模型跑偏的概率越高输出延迟也越大。我自己测试多轮对话去重和摘要任务时就发现当你让模型“深入思考用户意图”时模型经常把简单问题复杂化。比如用户问“你们几点上班”模型非要把经营范围、客服时间、节假日安排全猜一遍然后给出一大段话。反而是我加了一句“不需要分析背景直接基于已知信息回答”输出立刻干净很多。这背后的原因是大模型的推理能力是概率性的每一步都引入选择选择就有出错的可能。轻量思考的提示词策略应该是“只给最少必要信息只要求输出必要结果”。如果你确实需要复杂推理就在独立步骤里显式地要求模型做并且把中间推理结果放在数据结构里方便追踪而不是混在最终回答里。4.2 控制输出 token减少“废话”和“幻觉”输出 token 的长度和模型的幻觉概率呈正相关。这个规律虽然不绝对但在实践中很常见模型说得越多越容易编造细节。Jason Liu 团队在多个开源库里都强调过 response model 和 max_tokens 的组合使用。实操上我的习惯是两步走。第一用结构化输出格式限定模型的产出边界例如“只返回 JSON不要任何解释文字”。第二在合理范围内尽量压小 max_tokens。这不仅能省钱还能逼着模型只输出关键信息。比如生成商品简称时max_tokens 设为 40模型就不能长篇大论地给你写营销文案只能给一个短句这正好满足需求。很多人在意“模型不够聪明”但我见的更多情况是“模型太爱表现”。轻量思考要求你在设计阶段就把模型的“废话空间”给堵死。4.3 评测也要轻量用 30 条样本找方向别等 1000 条才动手说到这可能有人会问轻量思考对系统设计有指导意义那对评测和调试呢也有。很多团队搞评估一上来就想要几千条标注数据、全自动测评平台结果连第一步的提示词都还没定下来。Jason Liu 的建议是反过来的先准备 30 到 50 条典型样本人工看模型输出用肉眼记录哪里不对改完提示词或代码再重跑一遍。这个循环跑上三轮你对问题的理解会比盲目堆数据深刻得多。我实践下来这个“小步快跑”的方式确实有效。通常第一轮你会发现 10 个问题里有一半是 Schema 设计不合理第二轮再发现几个语义理解错误第三轮基本能把关键路径打磨到满意水平。等到最后的评估再用相对大的样本量化指标也来得及。轻量思考不是拒绝评测而是拒绝在问题还没定义清楚前就投入大量资源搭建评测基础设施。5. 常见问题与边界轻量思考不是银弹知道什么时候该放弃5.1 实际项目中常见的几个纠结点和化解方法在这一节整理几个我做项目时常遇到的问题和你分享一下我的处理经验。问题典型表现轻量思考下的处理方式Prompt 一直调不好改一句提示词另一个场景就崩别继续在提示词里打补丁先把任务拆细每步只做一件事结构化输出不稳定模型偶尔返回非法 JSON校验失败后把错误信息反馈给模型重试一次二次失败走默认值需要维护的内容太多提示词、工具、流程散落各处把共享 Schema 提炼成独立模块提示词只保留任务差异部分分不清是模型问题还是逻辑问题症状诡异复现率低固定输入、固定模型、关掉随机性先确认流程是否稳定再回来看模型框架升级导致行为变化版本一升级输出格式就变少用重框架核心逻辑自己实现业务不绑定框架版本这五个问题我全遇到过。印象最深的是“改一个场景崩另一个场景”当时我还在用一段超长 Prompt 管理所有意图最后花了三天拆成了五个子 Prompt问题才彻底解决。这就是典型的“重思考失败轻思考救场”。5.2 什么时候必须上重方案轻量思考的边界要划清楚说完了轻量思考的优点也得客观讲清楚它的边界。确实存在一些场景靠轻量思考和简单 Prompt 是解决不了的这时候硬撑反而会误事。第一类是开放式创作任务比如写小说大纲、做营销策划。这类任务的核心价值就是模型的发散性思考你不能用一个死 Schema 把它的输出框死。这时候“重思考”不是浪费而是必要的创造力投入。第二类是面向非结构化文本的复杂语义推理例如诉讼材料审查、医疗报告解读。这类任务输出结构相对固定但内部推理链条深、前提条件多需要模型综合上下文做推理。这种情况下可以把轻量思考体现在数据流分层上但推理部分要给模型足够的空间和上下文。第三类是超长上下文依赖的任务。比如分析整本合同的违约风险或者跨多文档寻找因果链。这类任务不适合本地单轮 Prompt需要真正的检索与多跳推理框架。这种场景下适当引入 Agent 式编排是合理的但建议你仍然以“人审界面 分步结果展示”的方式保留控制权而不是完全放任模型自动跑。判断标准很简单如果你能明确列出每一步做什么那就用代码写死如果你根本列不出来只能靠模型临场发挥那才该考虑复杂方案。Jason Liu 的“轻量思考”真正反对的不是复杂方案本身而是“明明流程可控却偏要靠模型随机探索”这种设计心态。6. 从“轻量思考”到“轻量团队”一种可以外溢的工作习惯写到这里我想分享一点超出技术本身的感悟。Jason Liu 建议的“轻量思考”表面上是技术选型和架构设计的取向实际上是一种工作习惯。它要求你在做任何东西之前先问一句“最低成本解决这个问题的方案是什么”这个习惯在团队协作里也一样适用。我做项目的时候见过不少团队开会聊了三个小时 Agent 架构却没人先把输入输出的字段定义下来。如果大家先花半小时把 Schema 定了把关键路径画清楚那个架构会可能根本不需要讨论。思考的颗粒度会影响行动的成本而轻量思考就是在提醒你把思考花在真正影响结果的地方。我现在的日常工作方式已经变成了“先写数据结构再写提示词最后写胶水代码”。看起来比一开始起个 Python 脚本慢一点但返工率大大降低。遇到的很多问题也都能很快定位到是数据结构定义得不够好还是模型对某类输入天然不够敏感。Jason Liu 的思路有没有争议有。比如有人觉得他太保守错过了 Agent 的红利期也有人认为他的方案只适合理解为“工程化 prompt”的场景处理不了真正的开放智能。这些声音都有道理但在大多数依赖 AI 提效的业务系统里稳定性和可维护性远比灵性重要。就冲这一点我认轻量思考这套理念。如果你现在正被一个复杂的 AI 项目搞得焦头烂额不妨停下来试试 Jason Liu 的路线把任务拆成最小可验证的步骤先定义清楚数据结构再用最轻的方式做通一版。很多时候你会发现你并不需要一个庞大的框架你只是需要想明白自己要什么。