企业官网建设流程全解析

1. 这份清单到底在解决什么问题

每隔一段时间，圈子里就会冒出一份"大模型全家福"式的整理清单。标题里带着日期，说明它是一份持续更新的快照，而不是一次性写完就丢在那里的静态文档。我最早接触这类清单是在做技术选型的时候，当时团队要为一个客服场景挑底座模型，市面上能叫得出名字的就有十来个，每个都号称自己某方面最强，翻官网、翻榜单、翻论文，三天下来脑子是糊的。后来我意识到，真正有用的不是"哪个模型最强"这种问题，而是"在我这个约束条件下，哪个模型最合适"。

这份清单的价值就在这里。它把模型维度和应用维度分开来看，模型维度关注的是底座能力——上下文长度、推理能力、多模态支持、开源与否、部署成本；应用维度关注的是这些底座被包装成了什么产品——是聊天助手、是编程工具、还是可编排的Agent框架。这两条线经常被混在一起谈，导致很多人在选型时把"模型能力"和"产品体验"搞混，最后踩坑。

适合读这份内容的人大概有三类。第一类是技术负责人，需要为团队定技术栈，关心的是稳定性、成本、可维护性；第二类是开发者，想基于某个模型或框架做二次开发，关心的是API设计、文档质量、社区活跃度；第三类是对这个领域保持关注的从业者，不一定马上要用，但需要知道当前格局长什么样，避免在信息差上吃亏。这三类人的关注点不同，但都需要一份结构清晰的参照。

我写这篇东西的思路是：不重复罗列参数，而是把清单背后的分类逻辑讲透，把每一类模型和应用的核心差异点拆开，再补上我在实际选型和部署中踩过的坑。参数会过时，但判断框架不会。

2. 模型维度的分类逻辑与选型判断

2.1 闭源旗舰、开源权重、垂直专用三条线

把当前市面上的大模型按获取方式分，基本就是三条线。第一条是闭源旗舰，代表是GPT系列、Claude系列、Gemini系列，特点是能力上限高、更新快、有官方托管服务，但你不能把权重拿回家，调用要走API，数据要过别人的服务器。第二条是开源权重，代表是Llama系列、Qwen系列、DeepSeek系列等，权重可以下载，能本地部署，能微调，代价是你得自己搞定算力和运维。第三条是垂直专用，比如专门做代码的、专门做数学推理的、专门做多模态理解的，这类模型在通用能力上可能不如旗舰，但在特定任务上性价比极高。

这三条线不是互斥的，很多团队的实际做法是混合使用。我见过一个比较典型的配置：线上主链路用闭源旗舰保证效果，离线批处理和敏感数据场景用开源权重本地跑，代码补全这种高频低价值任务用垂直专用模型压成本。这个思路值得参考，因为单一模型打天下在成本和效果上都不划算。

选型时最容易犯的错是只看榜单分数。榜单上的分数是在特定测试集上跑出来的，和你的真实业务分布可能差很远。我的经验是，先明确你的任务类型——是生成、是分类、是抽取、还是多轮对话——然后找几个候选模型，用你自己的真实数据跑一轮小规模对比，看的是实际输出质量而不是榜单排名。这一步花不了多少时间，但能避免后面大规模返工。

2.2 上下文长度这个参数被高估了吗

上下文长度是这两年最卷的参数之一，从早期的4K一路卷到现在的百万级。但我在实际使用中发现，长上下文和"能用好长上下文"是两回事。很多模型标称支持128K甚至更长，但你真塞进去十万字的文档，它在中间部分的信息召回率会明显下降，这就是所谓的"lost in the middle"现象。

所以看上下文长度这个参数时，我建议关注三个层面。第一是标称上限，这个看官方文档就行。第二是有效召回长度，这个得自己测，方法是把关键信息放在不同位置，看模型能不能稳定找到。第三是长上下文下的成本，因为注意力机制的关系，上下文越长，推理成本和延迟增长往往不是线性的。

实际场景里，如果你的任务是长文档问答，与其硬塞长上下文，不如先做一轮检索或摘要，把真正相关的片段喂给模型。这个思路在RAG架构里已经是标配了，但很多人还是会图省事直接全文塞进去，结果又慢又贵还不准。

2.3 多模态能力的分层理解

多模态现在是个热词，但不同模型的"多模态"含金量差别很大。我把它分成三个层次来看。第一层是能看懂图片，比如你发一张截图，它能描述里面有什么。第二层是能理解图片里的细节和关系，比如看懂图表的数据趋势、看懂界面元素的布局逻辑。第三层是能基于图片做推理和操作，比如根据一张设计稿生成代码、根据一张流程图规划执行步骤。

大部分标称多模态的模型在第一层做得都不错，第二层开始分化，第三层目前只有少数几个旗舰模型能稳定做到。你在选型时，要先想清楚自己的场景需要哪一层能力。如果只是做图片内容审核，第一层就够了；如果要做UI自动化，那得看第三层。

还有一个容易被忽略的点是输入和输出的模态组合。有些模型支持图片输入但不支持图片输出，有些支持语音输入但不支持语音输出。这些细节在官方文档里通常写得很清楚，但选型时容易被"多模态"三个字带过去。

3. 应用维度的真实分野

3.1 聊天助手、编程工具、Agent框架的本质差异

应用维度上，当前最主流的三个形态是聊天助手、编程工具和Agent框架。这三者的差异不只是界面不同，底层的交互范式完全不一样。

聊天助手是回合制的，你问一句它答一句，上下文靠对话历史维持。这种形态适合信息查询、内容生成、头脑风暴这类任务。它的局限在于，模型本身不主动做事，你不问它就不动。

编程工具是任务制的，你给它一个目标，它在代码库里自己找文件、改代码、跑测试。这种形态的核心能力是工具调用和长程规划，代表就是各种代码助手。它的难点在于，模型要能理解代码库的结构，要能判断改动的副作用，要能在出错时回滚。

Agent框架是流程制的，你把一个复杂任务拆成多个步骤，每个步骤可以调用不同的工具或模型，框架负责编排和状态管理。这种形态适合需要多步骤协作的场景，比如自动化的数据处理流水线、多轮调研任务。它的挑战在于可靠性和可观测性，因为链路一长，出错的地方就多，排查起来也麻烦。

我见过不少团队在这三者之间选错。比如明明是个简单的问答需求，非要上Agent框架，结果复杂度上去了，效果没提升多少。反过来，明明需要多步骤自动化，却用聊天助手硬凑，最后靠人工在中间传话，效率极低。判断标准其实很简单：如果你的任务可以用一句话描述清楚且不需要外部工具，聊天助手就够了；如果任务涉及代码修改，用编程工具；如果任务需要多个工具按顺序协作，才考虑Agent框架。

3.2 Agent框架选型时真正该看的指标

Agent框架这两年冒出来很多，名字我就不一一列了。选型时大家容易盯着功能列表看，但功能多不等于好用。我自己的判断顺序是这样的。

第一看工具调用的稳定性。Agent的核心就是调工具，如果工具调用经常失败或者参数传错，后面全白搭。测试方法是拿几个边界case跑一下，看它怎么处理参数缺失、返回值异常这些情况。

第二看状态管理能力。多步骤任务里，中间状态怎么存、怎么恢复、怎么避免重复执行，这些决定了框架能不能扛住真实场景。有些框架在demo里跑得很顺，一到生产环境遇到超时重试就乱套。

第三看可观测性。链路一长，你必须能知道每一步发生了什么、耗时多少、失败在哪。没有好的日志和追踪，排查问题就是盲人摸象。

第四看社区活跃度和文档质量。这个不用多说，遇到问题能不能快速找到答案，直接决定你的开发效率。

至于支持多少种模型、内置多少工具，这些反而是次要的，因为大部分框架都支持自定义扩展，真正卡你的是上面那四条。

3.3 从Demo到生产之间隔着什么

我参与过几个从零到一的Agent项目，最大的感受是：Demo和生产之间的距离，比想象中大得多。Demo阶段你只需要证明"这条路能走通"，生产阶段你要保证"这条路每天走一万次都不出错"。

具体来说，Demo阶段可以忽略的问题，在生产阶段都是致命的。比如并发，Demo里一个人用，生产里可能几百个人同时用，模型API的限流、工具调用的排队、状态的并发读写，每一个都可能成为瓶颈。再比如异常处理，Demo里出错就重跑，生产里你得有重试策略、降级方案、人工兜底。

还有一个常被低估的问题是成本。Agent的多步骤特性意味着一次用户请求可能触发十几次模型调用，token消耗是普通聊天的好几倍。如果不做成本监控和优化，账单会很难看。我一般的做法是给每个步骤设token上限，对简单步骤用便宜模型，只在关键决策点用旗舰模型。

4. 部署与微调：绕不开的工程问题

4.1 本地部署的硬件账怎么算

本地部署大模型，第一个要算的就是硬件账。很多人上来就问"跑某个模型需要什么显卡"，这个问题其实没法直接回答，因为取决于你的量化精度、并发量、上下文长度。

我一般按这个顺序估算。先确定模型参数量，比如7B、13B、70B。然后确定量化精度，FP16大概每B参数需要2GB显存，INT8减半，INT4再减半。所以一个7B模型FP16大概需要14GB显存，INT4大概需要4GB左右。但这只是权重占用的下限，实际运行时还要留出KV Cache的空间，上下文越长、并发越高，这部分占用越大。

我的经验是，在权重占用基础上至少留50%的余量给KV Cache和运行时开销。比如7B INT4权重约4GB，那实际部署建议至少8GB显存起步。如果要支持较长上下文或者多并发，还得往上加。

除了显存，还要考虑内存和存储。模型加载时需要把权重读进内存再传到显存，所以内存不能太小。存储方面，一个7B INT4模型大概4GB左右，多个模型并存的话要提前规划。

提示：量化会损失精度，INT4在通用对话上可能感觉不明显，但在需要精确推理的任务上退化会比较明显。如果任务对精度敏感，建议用INT8或者FP16。

4.2 微调这件事，什么时候该做什么时候不该做

微调是个诱惑很大的选项，因为听起来能让模型"更懂你的业务"。但我见过太多团队在不需要微调的场景上花了大量精力，最后效果还不如好好写提示词。

我的判断标准是这样的。如果你的需求是让模型掌握某种输出格式或风格，优先用提示词工程，成本低见效快。如果你的需求是让模型学会某个领域的知识，优先用RAG，把知识库外挂，更新也方便。只有当你的需求是让模型掌握某种难以用文字描述的"手感"，或者你需要大幅降低推理成本（用小模型微调替代大模型），才考虑微调。

微调本身也有坑。第一是数据质量，几百条高质量样本往往比几千条脏数据效果好。第二是过拟合，微调过头模型会变得只会回答训练集里的问题，泛化能力下降。第三是灾难性遗忘，微调后模型可能丢失原有的通用能力。我的做法是保留一部分通用数据混在训练集里，缓解遗忘问题。

4.3 提示词工程和上下文工程的边界

提示词工程和上下文工程经常被混为一谈，但我觉得它们关注的点不一样。提示词工程关注的是"怎么把话说清楚"，包括角色设定、任务描述、输出格式约束、few-shot示例。上下文工程关注的是"给模型看什么"，包括检索哪些文档、保留哪些对话历史、如何压缩和摘要。

在实际项目里，这两者是配合使用的。提示词决定了模型的行为模式，上下文决定了模型的信息基础。我见过提示词写得很漂亮但上下文喂了一堆无关内容的情况，结果模型被干扰得答非所问。也见过上下文很精准但提示词含糊的情况，模型不知道该用什么格式输出。

一个实用的做法是把这两块分开调试。先固定上下文，调提示词，看输出质量的变化；再固定提示词，调上下文，看信息完整度的影响。这样能快速定位问题出在哪一环。

5. 那些清单不会告诉你的实操细节

5.1 模型切换的成本比想象中高

很多团队在选型时会想"先用一个，不行再换"。这个思路本身没错，但模型切换的成本经常被低估。不同模型的API格式不一样，提示词的最佳写法不一样，输出风格不一样，甚至对同一个任务的理解方式都不一样。你为一个模型调好的提示词，换一个模型可能效果直接腰斩。

所以我的建议是，在早期就做一轮多模型对比，把候选缩小到两三个，然后针对这几个分别维护提示词模板。切换时不是简单换个API地址，而是要重新调优。如果业务对稳定性要求高，甚至可以考虑用路由层做灰度切换，先切一小部分流量验证效果。

5.2 成本控制要从架构层面做

模型调用的成本控制，不能等到账单出来才想办法。我一般从三个层面做。第一层是模型分层，简单任务用便宜模型，复杂任务用旗舰模型，这个在前面提过。第二层是缓存，对于重复性高的查询，把结果缓存起来，避免重复调用。第三层是压缩，把长上下文做摘要或检索，减少token消耗。

这三层里，缓存是最容易被忽略但收益最明显的。很多业务场景下，用户的问题有大量重复，比如客服场景里的常见问题。做一个语义缓存，命中率能到30%以上，成本直接降三成。

5.3 评测这件事得自己搭

市面上的榜单可以参考，但不能作为唯一依据。因为榜单的测试集和你的业务分布不一样，榜单上的第一名在你的场景里可能排不进前三。所以自己搭一套评测是必须的。

评测集不用很大，几百条覆盖主要场景的样本就够。关键是要有明确的评分标准，最好是可自动化的，比如分类任务看准确率，生成任务看关键信息覆盖率。然后每次模型更新或提示词调整，都跑一遍评测，看指标变化。这样你才能知道改动是变好了还是变坏了，而不是凭感觉。

我自己的评测集是持续维护的，每次线上发现bad case就补进去，慢慢就积累成了一个很贴合业务的测试集。这个东西的价值随着时间增长，比任何公开榜单都靠谱。

6. 关于这份清单的使用建议

回到这份清单本身。它是一份快照，日期标着2026年9月，意味着它反映的是那个时间点的格局。模型领域变化很快，几个月就可能有一批新模型出来，一批老模型退役。所以看这份清单时，不要把它当成永久参考，而是当成一个起点。

我的用法是：先用它建立整体认知，知道当前有哪些玩家、各自的位置在哪；然后针对自己关心的几个候选，去官网看最新文档，因为清单可能滞后；最后用自己的数据做小规模验证，这一步不能省。

另外，清单里的模型和应用是分开列的，但实际使用时两者是绑定的。一个模型可能同时以API形式提供，也被包装成聊天产品，还被集成进Agent框架。你在选型时要明确自己用的是哪一层，是直接用模型能力，还是用别人包装好的产品。这两者的灵活性和成本结构完全不同。

最后说一点个人体会。这个领域信息更新快，但底层判断逻辑其实变化不大。模型能力在涨，但选型的框架——明确需求、对比候选、小规模验证、持续评测——这套方法论一直适用。与其追着每个新模型跑，不如把这套框架练熟，这样无论出什么新东西，你都能快速判断它适不适合你。