最近一年我几乎被问了无数次同一个问题大模型的新花样这么多到底该学哪一个今天来个Agent明天冒出来一个多模态后天又开始讨论上下文工程。我自己的判断一直很朴素绝大多数新玩法并没有改变大模型本身的底层原理它们本质上都只发生在两个位置——你往里输入了什么以及模型输出的结果你做了哪些处理。这也是我反复跟团队讲的大模型三层架构模型核基本不动真正的战场在输入侧和输出侧。你可能觉得这个说法太绝对。但当我把聊天、写代码、做PPT、智能客服、自动数据分析这些场景一个个拆开看最后都能落回到同一句话所有 AI 新花样只在「输入什么 / 输出怎么处理」。接下来我会把这三层架构彻底拆一遍顺便把我平时排查AI项目问题的思路也分享出来。这篇文章适合两类人一是刚入门、被各种热词绕晕的学习者二是已经在做AI应用、但总觉得效果不稳定的一线开发者。1. 先拆清楚模型核、输入侧、输出侧三层各管什么1.1 模型核看似五花八门其实原地踏步的自回归很多朋友容易把大模型理解成一个什么都懂的超级大脑其实从工程角度看它更像一台极其擅长接着往下写的机器。无论是GPT系列还是开源的Llama、Qwen最核心的推理逻辑都是自回归给定一个token序列预测下一个token是什么然后把这个token拼到序列后面再预测下一个直到遇到停止条件。这也就是说模型内部的那几亿、几百亿甚至几千亿个参数本质上是一个从输入序列到下一个token概率分布的映射函数。你给它什么样的前缀它就沿着概率最大的方向往下续写。所谓微调也不是把模型换成另一种形态而是用一条条输入-输出对去调整权重分布让原本可能输出A的场景现在更倾向于输出B。我见过不少项目组在模型选型上反复纠结今天想换一个更大的模型明天想试试最新的微调框架。但冷静下来看如果输入侧和输出侧的基本功都没做好换模型往往只是从一个大坑跳进另一个大坑。模型核当然重要但它在实际项目里往往是相对稳定的部分真正每天都在变的是它前后两端的处理逻辑。1.2 输入侧决定模型看到什么的一切动作模型永远不会理解你的真实意图它只能看到你拼出来的那一串token。所以输入侧的核心任务是把用户的模糊需求、业务背景、历史信息、外部知识甚至工具能力尽可能准确、完整地翻译成模型擅长处理的文本序列。这里说的输入侧不单单是你打字框里的那句prompt它还包括系统提示词里定义的模型角色和输出规范历史对话是全部塞进去还是做摘要压缩检索出来的知识片段怎么和用户问题拼接在一起需要调用工具时函数描述和参数schema如何写入多模态场景里图片、音频如何转成模型能接受的token序列。这些动作全部发生在模型推理之前但它们直接决定了模型看到什么。我在实际项目中反复验证过一句话输入侧的信息密度和质量比模型参数的多少更能决定最终效果的底线。模型再聪明给它一堆残缺、混乱、没有重点的输入它也只能给你一个东拼西凑、看似流畅但经不起细看的输出。1.3 输出侧决定模型说出什么的一切处理模型生成完token之后事情并没有结束。输出侧承载的是从一个概率分布到一个可用结果的全部加工过程。先说最基础的采样环节。同一个模型temperature调低输出就稳定严谨适合写代码、做结构化抽取temperature调高输出就自由发散适合写文案、头脑风暴。你在产品里看到的文风差异很多时候不是模型不同而是输出侧采样参数不同。再往上走还有更复杂的输出处理要不要把输出强制约束成合法的JSON供下游程序直接解析要不要在生成过程中实时做敏感内容过滤要不要在Agent场景里先让模型输出一个调工具的动作程序根据这个动作去执行接口再把接口结果作为新的输入塞回去这里我想强调一个很多新手的误区他们以为Agent是模型自带的神奇能力其实Agent的一半工作量都花在输出侧的解析与回填上。模型负责输出的只是下一步该调用哪个工具、传什么参数这样的文本指令剩下的是工程代码在跑。所谓AI新花样越拆越会发现不过是把输入侧和输出侧的工序做得更精细而已。2. 输入侧的花样几乎覆盖了所有热词提示词、上下文、检索、工具2.1 提示词工程 vs 上下文工程单轮指令和多轮状态这两年大模型提示词工程与上下文工程成了高频词但很多人并不清楚两者的边界。我习惯这样区分提示词工程解决的是在单次请求里如何用指令和示例让模型输出更准上下文工程解决的是在多轮交互系统里如何管理和组织不断变长的历史信息。提示词工程最简单的例子就是角色设定。你让模型写一封邮件和你是一名工作十年的销售总监请以专业、克制但不失礼貌的语气写一封向客户解释延期交付的邮件后者效果几乎必然更好因为输入侧多了角色约束和风格约束。更进一步在输入里给一两个示例few-shot模型就更容易模仿示例的格式和口吻。上下文工程则是更麻烦的活。比如一个客服机器人聊到第50轮历史对话可能已经超出模型上下文窗口这时候你是把最旧的消息丢掉还是用另一波模型把历史总结成几句话塞进去每一步都在影响后续生成质量。我自己踩过的坑是早期图省事直接把所有历史全部拼接发给模型结果上下文一长模型反而把用户最早的需求忘了后面全在追着新话题跑。后来改成系统提示固定 最近消息保留 早期消息摘要压缩效果才稳定下来。这里有一件值得反复琢磨的事很多人印象里模型记忆力不行本质上不是模型记忆机制出了问题而是你在输入侧给它的上下文结构不健康。你输入侧把哪段信息放在了靠近结尾的位置模型大概率就会优先围绕哪段信息生成。利用好这个近因效应很多对话质量问题是可以在不换模型的情况下解决的。2.2 RAG把检索结果拼进输入输出瞬间变靠谱RAG检索增强生成是这两年落地最扎实的输入侧技术之一。它做的事概括起来很简单用户问一个需要专业知识的问题系统先去外部数据库或知识库里检索出相关内容把检索结果和原始问题一起拼到输入里再让模型基于这些材料生成答案。我知道很多第一次接触RAG的朋友会产生一种错觉模型是不是通过RAG学会了新知识不是。模型权重一点没变它只是这次请求的输入里多了一段以前没有的文字于是它顺着这段文字往下编。可别小看这个输入侧加料的动作它直接把模型输出从凭空猜测变成了基于给定材料的整理归纳准确率和可信度完全不在一个量级。做RAG有一个技术细节必须提醒检索出的片段不是越多越好。你把十个相关片段全塞进输入模型反而不知道以谁为准甚至被不相关的长段落带偏。我一般会在检索后加一层重排序把最相关的三条左右挑出来再按用户问题的语义顺序拼接。输入侧不是做加法而是做减法——把真正关键的信息放到模型眼前。2.3 工具调用与多模态输入让模型看得见世界的输入层技巧工具调用Function Calling表面上看是模型主动使用外部工具实际上仍然是输入侧的把戏你在系统提示词里把每个工具的用途、参数结构写得清清楚楚模型在生成时发现用户需求匹配某个工具就会输出一段符合格式的JSON例如要调用天气查询接口。程序拿到这段JSON后真正去执行接口拿到结果再拼进输入让模型继续生成。整个流程里模型自始至终只做了一件事——根据输入文本预测下一个token。但它通过输入侧工具描述 输出侧动作解析 执行结果回填这个循环看起来就像自己会使用计算器、会查数据库、会操作浏览器一样。这也是为什么我说Agent并不神秘它只是一套更完整的输入输出编排系统。多模态输入同理。图片进入系统后并不是模型直接看到了图而是视觉编码器把图片转换成一系列视觉token作为输入序列的一部分送给语言模型。音频、视频也没跳出这个框架。所以多模态模型本质上是在输入侧增加了新的编码通路模型内部预测下一个token的机制没有任何改变。3. 输出侧才是决定上限的地方解析、校验、循环、约束3.1 输出解析从token流到可编程的数据如果只是给人看聊天结果输出侧随便怎么处理都行。但只要涉及自动化、涉及把大模型接进业务流程输出侧的第一个关卡就是解析。我在项目里见过最典型的问题让模型输出一个包含姓名、意向等级、跟进建议的JSON结果模型偶尔会在JSON后面多补一句希望以上信息对您有帮助。就这一句多余的尾巴直接导致下游JSON解析崩溃整个流程卡住。后来我强制启用了结构化输出模式同时在提示词里明确要求只输出JSON不要任何解释文字解析成功率才从九成提高到接近满分。这里有个实操工具可以推荐如果你在用主流的模型服务试着开启JSON模式如果自己本地部署模型可以查一下vLLM这类推理框架的guided decoding功能。它们能让模型在生成过程中就受到语法约束从源头保证输出JSON合法。输出侧做的约束越多下游代码写的异常处理就越少。# 模拟一个经过输出侧解析后的结构化结果 import json raw_response {action: search_customer, params: {keyword: 张总, limit: 10}} parsed json.loads(raw_response) print(parsed[action]) # search_customer print(parsed[params][limit]) # 10这段代码看着简单但如果没有输出侧的约束和解析你拿到手的可能就是一段夹杂着自然语言、无法直接调用的文本后续所有自动化都无从谈起。3.2 采样参数同一个模型为什么能既写诗又写代码输出侧还有一批经常被忽略的旋钮temperature、top_p、max_tokens、stop序列。很多人以为这些参数是高级设置其实它们在产品体验里承担了决定性作用。我的经验是做代码生成、数据抽取、报表整理这类任务temperature调到0.1到0.3之间输出稳定、可复现性高做广告文案、故事创作、头脑风暴temperature可以放到0.7到0.9让模型敢于跑偏。有个反直觉的点是temperature不是越高越聪明它与聪明无关只与概率分布的采样激进程度有关。你调高temperature等于允许模型去选那些排序更靠后的词所以输出会更跳跃但错误率也会同步上升。如果你要排查线上问题可以把用户的每次请求参数日志打出来。很多时候用户投诉模型变笨了最后查到的是上游同事把temperature从0.2改成了0.8。模型压根没变变的只是输出侧的采样策略。3.3 Agent循环与输出安全输出侧不只是文本Agent为什么让人觉得惊艳因为它能自己规划任务、调用多个工具、一步步完成复杂目标。拆开看这不过是一个循环模型输出行动方案 → 程序解析动作参数 → 执行工具 → 把工具结果作为新输入 → 模型再输出下一步行动。在这个循环里输出侧承担的责任几乎和输入侧一样重。首先你要把模型的行动输出解析成程序能执行的动作常见的格式是JSON或固定的文本模板其次你要对工具执行结果做类型检查和错误判断不能把异常结果又原样塞给模型最后你还要给循环设置终止条件比如最大执行步数、关键目标达成判断否则模型会像一个跑偏的搜索引擎一样越绕越远。输出安全过滤同样属于输出侧。很多AI产品的合规感不是靠模型自觉而是靠生成后的过滤器完成的。模型输出了一段内容先过一层敏感词和违规内容检查再决定是否展示给用户。这块工具其实非常成熟用正则或调用内容审核接口都可以。关键是不要天真地认为模型会自己遵守规则提示词里的不要输出违规内容只是软约束输出侧的硬过滤才是兜底。我在做企业级AI助手时甚至还会加一道答案与知识库一致性校验模型生成的每句话里关键事实必须能在给定的知识片段中找到出处否则就丢弃重答。这个逻辑说白了也是在输出侧追加一道工序。4. 所有新花样的底层编排逻辑输入输出排列组合4.1 用一个映射表看穿所有应用把上述思考整理成一张表会很直观。我习惯在内部培训时用这张表让新人快速建立全局观AI应用形态输入侧的关键动作输出侧的关键处理普通聊天系统提示 历史对话拼接流式输出、适度格式化知识库问答RAG检索片段重排后拼入上下文答案引用来源、一致性校验代码生成助手项目上下文、代码片段、规范说明语法高亮、格式化、单元测试校验Agent自动化工具描述、目标拆解、历史行动记录动作JSON解析、执行结果回填、终止判断多智能体协作多个模型实例各自接收不同输入一个模型的输出作为另一个模型的输入多模态识图图像编码为视觉token拼入输入文本描述生成、坐标定位输出数据分析助手表结构、样例数据、分析目标输出SQL、执行结果再喂回模型解释你可以发现表格的左右两列几乎就是全部文章。大模型本身像一个功能固定的发动机不同方向盘的打法、不同路况的适配、不同驾驶模式的切换全部发生在输入和输出环节。4.2 多智能体、AutoGPT、工作流其实是循环和编排最近讨论很多的多智能体系统拆到底层也跑不出这个框架。主控Agent负责拆解任务工作Agent负责执行还有检查Agent负责验收本质上就是设计了一批不同的输入模板和输出处理规则让同一个模型在不同环节扮演不同角色。A的输出变成B的输入B的输出又变成C的输入最后汇总到主控那里。我参与过一个小型多智能体项目用来做竞品竞品分析报告。主控Agent把一个总任务拆成信息收集、数据整理、观点提炼、报告生成四个子任务分别交给四个子Agent执行。每一个子Agent都没被微调过都是同一个通用大模型。差别只在于每个子Agent的提示词、输入上下文和输出校验逻辑完全不同。报告最后的质量完全取决于我在输入侧给每层任务定义的指令质量以及输出侧对中间结果的校验严格程度。这个例子让我彻底放弃了追新模型就能追出新能力的想法。当一个应用表现不佳我第一反应是检查输入输出编排而不是马上换个更大的模型。4.3 微调和本地部署为什么它们也是输入输出映射的搬运工热词里有大模型微调实战和本地部署大模型让个人电脑智能化这两件事同样可以用三层架构来解释。微调的本质是把一批高质量的输入-输出对灌输给模型权重使得未来遇到类似输入时模型能直接输出期望的结果。它相当于把原本需要在输入侧精心构造提示词才能完成的事情压缩进了模型参数里。所以微调不是推翻三层架构而是把一部分输入输出映射提前固化到模型核中运行时依旧要经历输入处理和输出处理。本地部署则是把模型的运行环境拿回自己手里。云端API虽然方便但输入输出的处理往往受限于平台规则本地部署之后你可以完全掌控输入侧拼了什么、输出侧怎么解析甚至可以自由修改采样参数和结构化约束。我建议个人电脑智能化项目从7B到14B的小模型起步原因不是大模型不好而是小模型对输入输出编排的响应更直接迭代速度更快踩坑成本也低。5. 踩坑记录与实操调优用三层架构拆解你自己的项目5.1 一次实测对比同样的模型为什么别人的效果比你好去年我帮一个团队优化智能答疑助手。他们用的模型和我的一样提示词也看起来差不多但回答质量却有明显差距。我当时没有先改模型而是把两条请求做了逐字符对比发现差异全在输入侧和输出侧。对方的输入只有一句回答用户问题而且没有把用户的历史提问背景放进去我的输入里先有一段简洁的角色设定紧接着是已知材料和用户问题的结构化拼接。同一个模型前者经常给出泛泛而谈的通用回答后者能给出基于项目文档的具体步骤。这个案例我后来经常讲先别急着怀疑模型版本先用三层架构把自己项目里每一层做了什么列出来。5.2 输入侧调优检查清单角色和语气有没有写进系统提示用户当前问题的关键背景信息是否在输入序列里历史对话是否做了截断或摘要而不是无限堆积外部检索结果是否重排过是否控制了片段数量工具调用的函数描述是否够清晰参数schema是否完整多模态内容是否经过预处理图片是否被压缩成合适的token规模输入序列是否过长核心指令是否被淹没在冗长上下文中每次排查时你从最后一条往前看往往能快速定位问题。我自己见过太多案例是模型效果突然变差一看日志上游不小心把一段几千字的干扰信息拼进了输入。5.3 输出侧调优检查清单是否开启了JSON模式或引导解码是否明确设置了结束标记stop序列temperature与任务性质是否匹配是否有异常输出兜底逻辑比如字段缺失、格式非法时重新生成Agent场景里工具执行结果有没有校验和错误回填是否做了内容安全过滤是否记录并分析失败样本查是采样导致的偶发问题还是系统性偏差输出侧的调试往往需要看原始token流而不是只看最终界面。我建议你在开发阶段把模型的原始输出存一份日志哪怕它显示在界面上是正常的原始输出里可能已经混入了多余解释、换行符甚至乱码这些都会在自动化链路里埋雷。5.4 小实验方法快速验证是输入还是输出问题最后分享一个我常用来定位问题的方法控制变量法。假设你的AI应用表现不理想先固定模型不动只修改输入侧看输出是否改善如果输入改到极致仍不满意再调输出侧的处理逻辑最后实在不行才考虑微调或更换模型。实操时可以做一个A/B测试同一批测试问题A版本用原始输入 默认输出解析B版本用优化输入 结构化输出约束对比通过率和用户评分。大多数情况下B版本的效果提升会非常明显。这个实验成本很低但却是判断问题到底出在哪一层的最快路径。我自己在做任何AI项目时都会先写一份输入输出设计文档把模型的角色、上下文范围、检索策略、输出格式、校验规则全部写清楚再写业务逻辑代码。这个习惯帮我避开了无数个效果不稳定的坑。说到底大模型的三层架构并不复杂真正的难点在于你有没有耐心把输入侧和输出侧的细节做到位。