1-What is LLM?

很多专家认为，大语言模型（LLM）是一场前所未有的变革。有的将它类比为“印刷术”，认为它将促进教育和知识的极大普及，引领我们走向一场新的文艺复兴；有的将它类比为“蒸汽机”，认为它将作为一种新的动力源，极大促进知识工作效率的提升，带来一次新的信息革命。

印刷术本身是信息的复制，蒸汽机本身是物理做功。大语言模型既不是单纯的知识检索库，也不是纯粹的算力引擎。如果把LLM看作工具，再以工具类比，那么，用来砸钉子的钳子就是锤子。然而，简单类比是危险的。LLM是什么，取决于你怎样用它。当然，LLM是否是仅仅是个工具，也存在争议，之前，有人认为它是一个幽灵，阅尽人间书籍；现在，有人认为它是硅基生物，一个与碳基生物已经平起平坐、未来将远远超过的新物种。

坐而论道无益。不妨暂时放下宏大的叙事，深入代码与工程，从应用角度看看，自变革开端，发生了什么、什么正在发生、以及未来可能发生什么。

Gemini: 在应用架构中，一端是用户（前端），一端是服务器（后端），中间是网络。大模型的应用落地，依然无法脱离互联网与移动互联网时代积累的基础设施（如数据库、API、前端框架）。

我们先从模型本身说起。

2-How to use LLM?

2.1 Input and Output

模型内部是一个高维参数空间上的映射函数：输入文本序列，输出文本序列。我们从过去数年，这个映射的输入协议、输出协议以及训练范式的变化说起。

阶段	代表模型及时间	能力	问题
文本续写/Text completions	GPT-2 (2019) / GPT-3 (2020)	基于给定的上文，预测下一个词（Next-token prediction）出现的概率。跑通了 Scaling Law（缩放定律）：证明了只要参数量和高质量文本数据足够大，大力确实能出奇迹。涌现了 In-context Learning（上下文学习）：虽然它只会续写，但如果你在前面给它几个例子（Few-shot prompting），它就能学着你的模式往下写，不需要修改底层代码就能完成翻译、总结等任务。	没有“对话”的概念，没有“提问与回答”的概念，更没有“人”的概念。输入：`"请帮我写一首关于秋天的诗。"` 文本续写模型可能不会给你写诗，而是输出：`"请帮我写一首关于冬天的诗。请帮我写一首关于春天的诗。"` （因为它在训练数据中见过很多这种排比句形式，它只是在做模式匹配和续写）。
指令遵循/Instruction Tuning	InstructGPT / ChatGPT (2022.11)	从基座模型（Foundation Model）向对话模型（Chat Model）的跨越。研究人员引入了监督微调（SFT）和基于人类反馈的强化学习（RLHF）。打通了普通人使用 AI 的门槛（ChatGPT 时刻）：。用户不需要懂复杂的 Few-shot 提示词工程，只要用自然语言下达命令，模型就能听懂并执行。实现了“对齐（Alignment）”：AI 安全的基石，让模型的输出符合人类的价值观、意图和伦理规范。
角色分层/Role Stratification / ChatML	GPT-4 API (2023.3)	引入System、User、 Assistant角色和数组标签。
工具调用	GPT-3.5/4 (2023.6)	Function Calling。模型可生成结构化函数调用，打通外部 API、数据库、互联网。本质是模型主动触发外部计算逻辑的协议。消除知识截止日期与幻觉：彻底解决了大模型无法获取实时数据的问题（通过对接搜索引擎 API 或内网数据库）。Agentic Workflow 的技术底座：这是实现多步复杂任务（如让模型自主查询数据库、清洗数据然后发送邮件）的核心技术设施，使得大模型从单纯的信息处理器转变为具有执行力的系统主控节点。
结构化输出	OpenAI Structured Outputs (2024.8)	从概率性（Probabilistic）到确定性（Deterministic）：通过干预底层采样器，将大模型的生成自由度强行限制在开发者定义的严格数据契约（Data Contract）之内。
显式推理	o1-preview (2024.9) / DeepSeek-R1 (2025.1)	通过 RL （PPO或者GRPO）训练出内置思维链（CoT），数学与编码能力阶跃式提升。将算力扩展（Scaling Law）的重心从预训练（Pre-training）转移到了后训练（Post-training）和推理阶段（Inference Time）。	用户需要接受“高延迟换高智力”，这也催生了新的交互方式。
多模态动作	Claude Computer Use (2024.10) Claude Computer Use (2024.10) 以及各种Agent SDK	直接输出鼠标键盘/终端指令，与真实环境闭环

# 角色：
{
  "model": "gpt-3.5-turbo",
  "messages": [
    {"role": "system", "content": "你是一个严谨的翻译引擎，只输出翻译结果。"},
    {"role": "user", "content": "Hello world"},
    {"role": "assistant", "content": "你好，世界"},
    {"role": "user", "content": "Good morning"}
  ]
}

# Structured Output：使用Python的Pydantic
from pydantic import BaseModel
from openai import OpenAI
client = OpenAI()

# 1. 像写普通后端数据类一样，定义预期的数据结构
class Resume(BaseModel):
    name: str
    age: int
    skills: list[str]

# 2. 直接将类传入 response_format，SDK 会自动完成 Schema 转换与校验
completion = client.beta.chat.completions.parse(
    model="gpt-4o-2024-08-06",
    messages=[{"role": "user", "content": "张三，30岁，熟悉Java，3年经验"}],
    response_format=Resume, # 极简！直接传入 Pydantic 类
)

# 3. 得到的就是完美结构化的 Python 对象，告别 JSON 解析错误
print(completion.choices[0].message.parsed.name)

# 推理：DeepSeek R1 响应示例
{
  "message": {
    "role": "assistant",
    "reasoning_content": "用户想问... 我需要先计算... 假设... 不对，如果是这样的话... 所以最终答案是...",
    "content": "经过计算，最终答案为 42。"
  }
}

工具调用的本质是模型主动触发外部计算逻辑的协议。在 API 层面，开发者通过 tools 字段将外部函数的签名（Function Signatures，包括名称、描述和参数的 JSON Schema）注入给模型。经过特定微调（Fine-tuning）的模型在生成 Token 时，一旦计算出当前上下文需要依赖外部数据或动作，便会中断标准的文本生成流（Text Generation Flow）。转而生成一个符合规范的 JSON 对象（即 Tool Call 指令），并将控制权交还给调用方（Client）。调用方执行相应的本地代码或 API 后，将结果以 tool 角色追加回上下文窗口，模型再基于此结果继续生成最终响应。

Structured Outputs 的工程意义常被低估：它让 LLM 从"输出不可控的文本发生器"变成了后端函数签名意义上的可组合组件，这是一切生产级 Agent 架构的前提。虽然 Function Calling 也能输出 JSON，但早期的模型依然是概率模型，存在输出非法 JSON（如漏掉引号、多出逗号）的概率。结构化输出（Structured Outputs）在底层算法上引入了受限解码机制（Constrained Decoding）。在模型逐个生成 Token 的解码阶段（Decoding Phase），系统会实时解析开发者提供的 JSON Schema。如果模型预测的下一个 Token 违反了给定的语法树结构或类型约束，系统会直接将其 Logits（生成概率）掩码（Mask）为负无穷大，强制模型只能从合法的 Token 集合中进行采样。

2.2 上下文长度

从 GPT-3 的 2K 到 GPT-4 Turbo 的 128K，再到 Gemini 1.5/2.5 与 Claude 的 1M 级别（26年主流模型），上下文窗口的扩张改变了"信息如何进入模型"的工程范式。

长上下文在准确性上受 lost-in-the-middle 效应影响，超过一定长度召回率会下降。
在延迟上，1M tokens 的 prefill 需要数秒到数十秒。
在成本上，每次对话重复塞入完整语料不可持续。

现实工程中的趋势是长上下文 + 检索 + 缓存（Prompt Caching / KV Cache）的组合。

2.3 向量模型

Embedding：将文本映射为稠密向量，用于语义检索、聚类、去重。
Reranker：对 Embedding 粗排结果做 Cross-Encoder 精排，召回精度显著优于单阶段检索。生产 RAG 系统建议默认采用"Embedding 召回 + Reranker 精排 + LLM 生成"三段式。

2.4 模型架构

Dense 架构：所有参数参与每次前向计算，训练目标与推理路径简单，但规模扩展时推理成本线性上升。
MoE（Mixture of Experts）：每次推理仅激活部分专家子网络（典型为 top-k=2），在总参数量不变的前提下显著降低推理 FLOPs。

2.5 使用方式及价格

本地部署：vLLM / SGLang / Ollama 等推理引擎 + 开源权重（Llama、Qwen、DeepSeek、GLM）。适合数据合规要求高、调用量大、延迟敏感的场景。
云端 API：OpenAI、Anthropic、Google、字节、阿里、DeepSeek 等均提供。得益于Prompt Caching、Batch API、稀疏激活模型，近两年单位 token 价格下降了一到两个数量级，大模型进入寻常百姓家。但随着任务更加复杂，单一任务消耗token量更多，SOTA模型的价格离普通用户仍有一段距离。

3-LLM应用的方式

没有看到明确的定义。秉持实用主义就好。

3.1 工作流（Workflow）

工作流是确定性有向图：节点与边由开发者预先定义，LLM 在每个节点完成一个明确的子任务。优点是可预测，缺点是不灵活。ChatGPT-3 时代的大量"脚手架项目"——围绕弱模型的重度提示工程与逻辑补丁——在模型自身能力提升后迅速贬值。

代表形态：

低代码平台：n8n、Dify、Coze 适合业务团队快速拼装。
代码框架：LangChain（1.0 版本引入 Middleware ）、LlamaIndex（现已聚焦非结构化数据的摄取、解析与索引）。

3.2 智能体（Agent）

Agent 的本质是LLM 在循环中自主决策下一步动作，工作流图不再由人预先铺设，而是由模型在每一步根据观察动态生成。其与"调包侠"式伪 Agent（API 包一层提示词）的核心差异在于：是否真正形成了“观察—思考—行动—反馈”的闭环。

2024–2025 年的几个公开里程碑：

Claude Code / Cursor Agent：Coding 率先跑通 Agent 范式，因为代码有天然的确定性反馈信号（编译、测试、运行）。
Manus（2025.3）：首个在通用任务上引起广泛讨论的 Agent 产品，验证了浏览器 + 终端 + 文件系统 + 长时任务的可行性。
OpenAI，Claude的cowork类桌面应用：头部厂商将 Agent 能力产品化，面向更广泛用户群。

关于国内大厂跟进 Agent 的动机，需要分层看待：既有卖 token / 抢占入口的商业逻辑，也有真实的 B 端生产力场景驱动。判断一个 Agent 项目是否有持续价值，关键不在 Demo，而在它是否在某个具体业务流程中替代了实际人工工时。

3.3 建议

先用原生 SDK（OpenAI、Anthropic、google-genai）把链路跑通，再按需引入框架。

从MVP起步，便于理解上下文构造、工具调用协议、流式输出机制。避免使用框架的高昂抽象成本。
当系统出现多 Agent 协同、复杂状态机、可恢复的长任务时，再引入 LangChain等。

4-Data Pipeline：Data as moat

4.1 采集（Gather）：从爬虫到搜索引擎

静态网页：BeautifulSoup、lxml 仍然适用。
动态网页：Playwright、Selenium 处理 JS 渲染。
反爬对抗：登录态维持（Cookie/Session 池）、IP 轮换（住宅代理）、指纹伪装、验证码识别。
托管化抓取：Firecrawl、Jina Reader、Bright Data、博查搜索、Tavily 等 API 将"抓取 + 渲染 + Markdown 化"打包为一次 HTTP 调用，适合不希望维护爬虫基础设施的团队。

4.2 解析（Parse）

非结构化文档（PDF、扫描件、双栏论文、财报、PPT、表格）的结构化是长期技术难题。当前可选路径：

传统 OCR + 版面分析：PaddleOCR、MinerU、Marker。
专用解析服务：LlamaParse（对表格、公式友好）、Unstructured.io（格式覆盖广）。
多模态大模型直接解析：对版面复杂文档的端到端解析能力已逐步可用，但需要权衡成本与延迟。

4.3 清洗与结构化（LLM as ETL）

ETL 是数据工程（Data Engineering）领域最古老、也最核心的概念，三个字母分别代表Extract（提取）、Transform（转换）、Load（加载）。

传统数据清洗依赖正则、规则引擎、启发式代码。现在，利用小而快的模型（Claude Haiku等）的强大语义理解能力，作为 ETL 管道中的一个算子，替换掉传统 ETL 中最耗时、最脆弱的“Transform（转换）”环节代码。

5-业务逻辑

All yours.

6-部署

6.1 原型MVP（Python）

适用场景：内部工具、PoC 验证。优势是从模型代码到 UI 只有一个语言栈。

前端：Streamlit / Gradio。
后端：FastAPI。
数据库：SQLite / DuckDB / Postgres（Supabase）。
部署：Render、Railway、Fly.io、Streamlit Community Cloud、Hugging Face Spaces。

6.2 生产（TypeScript）

全栈框架：Next.js + Tailwind CSS。
LLM 集成：Vercel AI SDK（处理流式、工具调用、结构化输出的统一抽象）。
数据与身份：Supabase / Neon（Postgres）+ Clerk / Auth0。
部署：Vercel / Cloudflare。

适用场景：面向消费者或 B 端 SaaS，需要良好的流式交互、边缘部署、SEO。

6.3 混合路径（前后端分离）

推理与数据密集任务用 Python（FastAPI / Modal / RunPod），交互层用 Next.js，通过 REST/SSE/WebSocket 连接。大多数中等规模生产系统最终会收敛到这个形态。

交互层（TS和Next.js主导）。负责UI界面的美观（Tailwind CSS），流式渲染（Vercel AI SDK），鉴权（Clerk/Auth0）、支付（Stripe）。部署在Vercel或者Cloudfare等边缘网络上。
数据负载层（Python和FastAPI主导）。负责LLM编排调用、RAG、数据清晰等。部署在专门提供持续计算能力的平台上。轻量的 API 可以部署在 Render/Railway；如果需要极高算力或 GPU 支持，则部署在 Modal、RunPod 这样的 Serverless AI 云上。
中间桥梁（REST/SSE/WebSocket）。两层是用不同的语言写的，不在一台服务器上。其中，REST API (HTTP 请求)：用于普通的交互。比如前端 Next.js 向后端 FastAPI 发送请求。SSE (Server-Sent Events)实现Streaming之类的效果。WebSocket 来保持双向长连接。

7-The Future

7.1 语言即思维，数据飞轮转向动作空间

维特根斯坦命题"语言的边界就是世界的边界"在 LLM 时代获得了新的工程解释：如果人类智力主要以语言为载体，那么在语言空间上的强化学习就是在直接优化智力本身。

Scaling Law 在预训练层面的边际收益趋缓，但在后训练（RLHF、RLAIF、RLVR）和推理时计算（test-time compute）两个方向仍有显著空间。下一阶段的数据飞轮主角不再是静态网页文本，而是 Claude Code、Cursor、Computer Use 这类 Agent 在真实环境中产生的端到端轨迹数据（观察—思考—动作—结果），这是传统互联网语料无法提供的。

7.2 组织层面的结构性迁移

Marc Levinson 在《集装箱改变世界》中描述的并非单纯的效率提升：集装箱化使曼哈顿与布鲁克林的码头工人群体解体，业务向纽瓦克-伊丽莎白港迁移，同时催生了全新的全球供应链形态。AI 对企业的影响很可能遵循同样的结构：不是让现有岗位"变快一点"，而是让整层中介环节消失、让业务边界重划、让新的组织形态在新的地理位置或新的公司中生长出来。

7.3 非对称赋能：强者恒强

关于 AI 就业影响的两种代表性观点：Anthropic CEO Dario Amodei 警告初级白领岗位面临显著风险；黄仁勋则强调生产率提升会扩大总需求。两者并不矛盾——总量可能扩张，但分布会剧烈重塑。

很多一线从业者都谈到，LLM 对高效能个体的赋能幅度远大于对低效能个体。用 Rumsfeld 的知识三分法来理解：

Known Knowns：LLM 大幅加速查询与应用。
Known Unknowns：LLM 降低了入门门槛，帮助更多人跨越自己已经意识到的知识缺口。
Unknown Unknowns：只有具备元认知、好奇心与工程素养的少数人，才有能力借助 LLM 主动拓展这一层——而这恰恰是生产力跃迁的真正来源。

历史上每次生产力变革，管理者都倾向于"招聘已经适应新工具的人"而非"培训既有员工"，这次大概率仍然如此。

7.4 矛盾：模型原生能力 vs 工程 Harness

一方面，基础模型在走向"暴力美学"：1M–10M 上下文、原生 Agent 能力、多模态统一。似乎只要把足够多的信息塞进 Prompt，模型就能自己解决问题。
另一方面，真实业务系统（Harness）需要处理长期状态维护、细粒度权限、增量数据更新、可审计性、成本控制、故障恢复——这些是严肃工程架构的刚性约束，与"把一切扔给模型"的范式存在根本摩擦。

1-What is LLM?#

2-How to use LLM?#

2.1 Input and Output#

2.2 上下文长度#

2.3 向量模型#

2.4 模型架构#

2.5 使用方式及价格#

3-LLM应用的方式#

3.1 工作流（Workflow）#

3.2 智能体（Agent）#

3.3 建议#

4-Data Pipeline：Data as moat#

4.1 采集（Gather）：从爬虫到搜索引擎#

4.2 解析（Parse）#

4.3 清洗与结构化（LLM as ETL）#

5-业务逻辑#

6-部署#

6.1 原型MVP（Python）#

6.2 生产（TypeScript）#

6.3 混合路径（前后端分离）#

7-The Future#

7.1 语言即思维，数据飞轮转向动作空间#

7.2 组织层面的结构性迁移#

7.3 非对称赋能：强者恒强#

7.4 矛盾：模型原生能力 vs 工程 Harness#