沈奕斐最近频繁有做Web开发的朋友问我同样的问题：大家都在聊的LLM和Agent，到底是什么？学了对我写业务代码有什么帮助？为什么照着网上教程做出来的东西一上点复杂度就废？
这类问题问多了，我发现一个普遍的困境——Web开发者不缺编程能力，缺的是把LLM和Agent“去神秘化”的思维转换。很多人把大模型当成数据库或者普通API用，结果发现它既不可靠又不可控。还有人以为Agent是什么高深莫测的科幻技术，其实拆开看，背后就是一套工程模式。
这篇文章我会完全站在Web开发者的视角，把LLM到Agent这条链路拆开揉碎：先搞懂LLM底层到底怎么工作，然后讲提示词优化这种纯工程化的东西，再一步步过渡到Agent的架构设计、工具链选型，最后把上线前后会踩的坑也一并交代清楚。不管你是刚接触这个概念，还是已经跑过几个demo，这篇内容应该都能给你一些能直接用的东西。
1. 先搞明白：Web开发者为什么要关心LLM和Agent
1.1 你写的CRUD和大模型应用之间，差的不是技术而是思维
Web开发的底层模式其实很固定：接收请求、处理逻辑、读写数据、返回响应。哪怕你用了再复杂的微服务架构，核心还是这套“请求-响应”模型。这套模型有个巨大的隐含假设——所有逻辑都是确定性的。一个参数传进去，结果是可预测的，bug是可定位的。
LLM应用则完全不同。同样的Prompt，模型每次返回的内容可能都不一样；同一个问题，换个温度参数结果就飘了；甚至同一个输入，在不同时间点调用，模型能力可能已经悄悄升级导致输出风格变了。这种不确定性让习惯了“代码即逻辑”的Web开发者非常难受。
我刚上手LLM应用开发时最大的挫败感就来自于此。我习惯性地想“如果用户输入A，我就调用B接口”，但LLM的世界里没有这么线性的逻辑。后来我才想明白，做LLM应用，你的思维模式要从“编写指令”切换到“设计约束”。你不再告诉程序每一步做什么，而是通过Prompt、工具定义、上下文、上下文窗口等手段，划出一个能让模型稳定发挥的活动区间。这个思维转变，比学任何技术难，也比学任何技术重要。
1.2 LLM不是数据库，也不是API——它是个“会猜的实习生”
我经常用这个类比帮Web开发者理解LLM的本质：当你把一个问题抛给大模型，它不是去数据库里查答案，也不像普通API一样执行逻辑，它是在做一件事——根据你给的上下文，逐字预测最有可能出现的内容。
就像你新招了一个学东西很快但经验不足的实习生。你给他一个任务，他不会像老员工那样按照工作手册一步步执行，而是根据他“读过的资料”（训练数据）和对你的意图的理解，推断出你认为最合理的回答。这个回答可能看起来非常专业，但如果他“读过的资料”本身有问题，或者你的任务描述有歧义，他就会一本正经地给出一个错误答案。
理解这一点，你就明白了为什么LLM会有幻觉、为什么Prompt措辞不同结果天差地别、为什么RAG（检索增强生成）能有效缓解幻觉——因为你把上下文从“模型猜”变成了“你喂”。你不再指望模型凭空记住你的业务数据，而是主动把相关资料塞进上下文，让它基于这些资料去“猜”。这是Web开发者最容易接受也最应该先掌握的增强手段。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LLM是一台“高级自动补全机”——Web开发者视角的原理拆解
2.1 理解Transformer不用啃论文，抓住四个关键点就够了
Transformer架构的细节足够水几十小时的课，但作为Web开发者，你只需要在脑子里留下四个关键词：Token、注意力机制、上下文窗口、预训练。
Token是最小文本单元。你可以把它理解成“能独立理解的分词块”。一个Token可能是一个英文单词的一部分、一个汉字、或者一个标点符号。模型处理文本时做的事情，就是先把整段话切成Token序列，然后用注意力机制来判断这些Token之间的关系。
注意力机制听起来玄乎，其实可以用一句话概括：当模型要预测下一个Token时，它会“回看”前面所有Token，并计算每个Token对当前预测有多重要。“我在北京，我爱吃___”这句话里，“北京”和“爱吃”对预测下一个词至关重要，模型通过注意力机制给它们更高的权重，预测出大概率是“烤鸭”而不是“寿司”。
上下文窗口则是模型单次能“看到”的最大Token数。它就像你的应用能接收的最大请求体大小——一旦超出，模型要么报错，要么丢弃超出部分的信息。预训练就是模型在海量文本上做的“自动补全练习”，这个阶段让模型掌握了语言规律、知识甚至部分推理能力。
这四个概念连起来，你就明白LLM的本质了：它根据前文所有Token，通过注意力机制计算每个Token的权重，然后预测最合理的下一个Token。如此反复，一整个句子、甚至一整篇文章就诞生了。
2.2 Context Window、Token和Temperature：三个决定应用上限的参数
这三个参数是你在实际调优中打交道最多的。它们之间不是独立的，而是互相牵制。
Context Window决定了你能塞进多少上下文。拿GPT-4o来说，128K的上下文窗口看起来很大，但真实可用的没有那么多。一个很典型的场景是：你塞了大量业务文档进去，结果发现模型开始忘记你最开始给它的指令，或者在回复后半段时开始“发疯”。这有点像浏览器开了太多标签页导致内存吃紧——不是崩溃，但性能明显下降。实际开发中，我建议有效上下文用量控制在窗口上限的60%到70%以内，留出余量给模型生成的内容。
Token不仅是计费单位，也是模型处理信息的基本单位。这意味着你给模型的文本和你希望模型生成的文本，都在消耗同一份配额。优化Token的用量等于同时优化成本和上下文空间。很多自以为写得非常详尽的Prompt，实际浪费了大量Token在废话和重复描述上。
Temperature是控制“随