大模型发展史总复盘：从生成文本到可执行系统
写到第 100 篇，我回头看了一遍这条路线，最明显的感受不是模型参数越来越大，而是模型在系统里承担的角色变了。
2023 年，我们主要在问：“模型能不能理解我的问题，生成一段像样的文字？”到了后面，问题逐渐变成：“模型能不能看图、查资料、调用工具、修改代码、完成一个长任务，并且在出错时停下来？”
这不是简单的能力叠加。模型从一个生成器变成系统中的决策组件以后，数据、权限、状态、成本、评测和人工确认都必须跟上。只会生成文本的模型，错了通常是一段错话；能够操作外部系统的 Agent，错了可能是一次错误付款、一次越权读取或一批重复创建的任务。
这 100 篇文章真正想整理的，正是这条从“会回答”到“能负责地执行”的工程路径。
一、2023：模型走出研究论文，进入开发者工具箱
这一年的变化可以概括成一句话：大模型 API 让普通开发者第一次能够直接使用生成能力。
Transformer、Token、位置编码、Decoder-only 和自回归生成，解释了模型怎样处理文字；预训练、指令微调和 RLHF，解释了模型为什么从“续写文本”变成“听懂指令”。但真正让开发者兴奋的，是调用 API 的门槛突然降低了。
大家开始做聊天机器人、摘要、翻译、代码补全、结构化抽取和函数调用。Prompt Engineering 也在这一时期迅速流行起来。我们学会给模型角色、约束、示例和输出格式，开始意识到：同一个模型，输入组织方式不同，结果可能差很多。
但 2023 年的很多 Demo 都有一个共同问题：它们展示了第一次成功，却没有回答第二天会不会继续成功。没有对话记忆，没有错误分类，没有输出校验，没有成本预算，Demo 很聪明，产品却很脆弱。
这一年最重要的工程收获，是把模型当成不完全可靠的外部依赖。API 会超时，输出会漂移，Token 会超预算，模型会自信地说错话。系统必须有超时、重试、Schema 校验、日志和降级，不能把所有希望寄托在 Prompt 上。
二、2024：从“调用模型”走向“组织上下文”
模型能力继续提升以后，大家发现一个事实：很多业务问题不是模型不知道，而是模型没有拿到正确的信息。
RAG 因此成为主线。Embedding 把文字变成可比较的向量，向量数据库提供相似度检索，Reranker 帮助正确片段排到前面，模型再根据上下文生成答案。看起来只是多了一个搜索步骤，实际上它引入了完整的数据工程：文档解析、切分、版本、权限、增量更新和删除。
RAG 最让我印象深刻的教训是：模型回答错，不等于模型本身有问题。可能是文档没有索引，切分破坏了语义，召回被相似噪声干扰，权限过滤漏了，或者上下文太长让关键证据被淹没。
多模态和长上下文则改变了输入边界。图片、音频、表格和长文档都可以进入模型，但“能接受”不等于“能可靠理解”。图像分辨率、表格结构、音频分段和上下文成本，都需要工程处理。
微调、LoRA、QLoRA、SFT 和 DPO 让开发者可以把模型调整得更贴近任务。与此同时，我们也更加清楚地认识到：数据质量通常比训练命令更重要。错误标签、重复样本、数据污染和没有授权的内容，都会让模型学到不该学的东西。
三、2025：模型开始规划、推理和调用工具
当模型不再只生成一句答案，而要完成多步任务，Agent 的概念变得重要。一个 Agent 至少包含模型、工具、状态和循环：模型决定下一步，工具改变外部世界，状态保存历史，循环让任务继续推进。
ReAct、Tool Calling、多智能体、Computer Use 和 MCP 等方向，解决的是模型如何与外部能力连接。但连接能力越强，系统风险越高。
工具 Schema 必须严格，参数要校验，权限要明确，副作用操作要幂等；工具执行失败不能让模型编造结果；高风险动作需要用户确认；长任务要有检查点和恢复机制。Agent 不是一段更长的 Prompt，而是一个小型分布式系统。
推理模型和 Test-time Compute 让我们重新认识“速度”。有些问题不是增加训练数据就能解决，模型需要在回答前花更多计算进行规划、验证和自我检查。但这也带来成本、延迟和可解释性的取舍。
推理基础设施同样成为核心：KV Cache、PagedAttention、Continuous Batching、Speculative Decoding、量化和 vLLM，解决的是如何把模型能力以合理成本提供给真实用户。模型效果、GPU 利用率和用户等待时间，已经不能分开讨论。
四、2026：真正的重点是系统能不能长期运行
到了现在，单纯追逐更大的模型已经不够了。生产环境更关心：答案质量能否评测，延迟是否稳定，数据是否隔离，成本是否可控，失败能否恢复，用户能否理解系统正在做什么。
生产级 RAG 需要离线评测、在线监控和增量索引；多租户 AI 需要隔离数据、权限、缓存、配额和账单；隐私与版权需要数据来源、用途、留存和删除链路；小模型和端侧 AI 则让我们重新计算质量、速度、功耗和隐私的平衡。
Coding Agent 和软件工程 Agent 也提醒我们，自动生成补丁只是很小的一步。真正重要的是代码库理解、变更边界、测试验证、工作区隔离、失败停止和可审查的 PR。一个会写代码但不会证明自己没改坏系统的 Agent，不足以进入工程流程。
五、四条一直没有改变的主线
1. 数据比想象中更重要
模型、Embedding、RAG 和 Agent 最后都绕不开数据。数据是否真实、相关、最新、获得授权、经过脱敏，直接影响质量和风险。把更多脏数据喂给模型，通常不会得到更聪明的系统，只会得到更难解释的错误。
2. 评测比感觉更重要
一次 Demo 成功不能证明系统可靠。黄金数据集、失败样本、Recall、忠实性、任务成功率、P95 延迟和用户反馈，组成了真正的证据链。没有基线和回归测试，任何“变好了”都值得怀疑。
3. 边界比能力更重要
模型知道什么固然重要，但它是否知道什么时候不知道、谁可以访问什么、哪些动作需要确认，同样重要。拒答、降级、人工介入、权限过滤和回滚不是削弱 AI，而是让 AI 能够进入真实世界的条件。
4. 系统比模型更重要
同一个模型放进不同的上下文、检索、缓存、工具、状态和监控系统，表现可以完全不同。模型是一个重要组件，但不是产品本身。真正的产品是围绕模型建立的完整闭环。
六、我会怎样继续学习大模型
以后遇到一个新模型，我会先问：它解决了哪个具体问题？用什么数据和预算证明的？适合我的语言、场景和延迟吗？失败时怎么降级？
遇到一个新框架，我会看：它抽象了哪一层，能否观察和调试，迁移成本多大，出现问题能否绕过，是否真的比已有工具简单。
遇到一个新 Agent，我会看：状态在哪里，工具有没有权限边界，重复执行会怎样，长任务如何恢复，高风险动作谁确认，日志能不能还原全过程。
遇到一个新 benchmark，我会看：测试数据是否独立，指标是否适合任务，基线是否公平，提升是否超过随机波动，和真实用户问题有多大关系。
这套问题不保证每次都选对，但能防止自己被热度牵着走。技术雷达的价值，不是知道所有新名字，而是知道哪些名字值得花时间验证。
七、100 篇之后，真正值得留下的东西
如果这 100 篇只留下模型名称和框架命令，很快就会过时。希望留下的是几种稳定的工作方式：
- 先定义问题，再选择模型。
- 先建立基线，再宣称提升。
- 先保证数据边界，再扩大能力。
- 先设计失败路径，再接入工具。
- 先做小实验，再投入完整训练。
- 先保存证据，再决定是否上线。
这些原则看起来不够刺激，却能让学习真正累积起来。大模型时代变化很快，今天的热门模型明天可能被替代，但如何拆问题、做实验、看数据、查边界和守住质量，不会因为版本更新就失效。
总结：从“会生成”到“值得托付”
回顾 2023—2026，我看到的不是一条简单的模型升级曲线，而是一个系统逐渐长出来的过程：先有生成文本，再有结构化输出；先有 API，再有 RAG 和工具；先有单轮回答，再有 Agent 和长任务；最后，评测、权限、成本、隐私和可靠性把这些能力拉回真实世界。
模型让机器更会表达，工具让机器更能行动，工程让行动变得可控，人的判断则决定什么事情值得交给它。
100 篇文章写完，不意味着大模型已经学完了。恰恰相反，真正的学习才刚开始：继续读论文，做实验，维护自己的基准集，观察线上失败，删掉过时知识，也承认自己不知道。
我希望我们最终追求的不是一个永远正确的 AI，而是一个知道边界、能够解释、出了问题可以恢复，并且愿意把决定权交还给人的系统。因为从生成文本到可执行系统，最难的从来不是让机器多做一点，而是让它在做更多事情以后，仍然值得我们托付。
