1. 为什么671B大模型非得做“联网应用”
1.1 671B到底强在哪，普通人怎么玩
很多朋友第一次听到“671B”第一反应是：这玩意儿是不是要几百张显卡才能跑？这里有个关键认知要纠正。DeepSeek的671B大模型是MoE（混合专家）架构，它的总参数量确实是6710亿，但实际推理时并不会把每个参数都跑一遍，而是根据输入内容动态激活其中的一部分参数（公开资料里常说激活参数在37B这个量级）。这个设计有点像一个大公司，总部有六百多个部门，但具体接到一个客户需求时，只有少数几个相关部门会被拉来干活，而不是全员出动。
所以671B模型才能以相对可接受的成本被云厂商托管起来，通过API接口对外提供服务。对个人开发者和小团队来说，以前想玩这种量级的大模型，基本得准备八卡甚至更多的高端显卡服务器，软硬件成本、运维成本都让人劝退。现在云平台上已经把模型部署、算力调度、负载均衡都搞定了，你只需要在控制台里点几个按钮，把模型绑定到应用上，就能用上671B的推理能力。这也是“零代码玩转671B”这件事真正成立的前提。
1.2 离线模型最头疼的问题：知识过时和编造
纯离线部署的大模型，无论参数多大，都有一个绕不过去的短板：它学到的知识截止于训练数据的时间点。比如模型训练时用的是去年之前的语料，那今年发生的热点事件、最新的股价行情、当下正在生效的政策条款，它确实是不知道的。你说它会不会直接承认自己不知道？不会。大模型在不确定答案的时候，很容易用逻辑通顺但内容错误的话来“圆场”，这就是大家常说的幻觉问题。
解决这个问题最直接的办法，就是给模型接上“联网搜索”能力：它遇到自己不知道、或者不确定的问题时，可以先调用搜索引擎去查最新的网页内容，再把搜索结果作为参考资料，综合整理之后给出答案。这相当于给模型配了一个实时更新的外挂记忆库。正经的联网应用方案，不是把模型本身“升级”到能知道所有实时信息，而是借助检索工具把最新信息喂给它。理解了这层原理，你再去配置应用，就会清楚每一步操作是在做什么，而不只是机械地点开关。
2. 准备工作：账号、密钥与联网搜索能力开通
2.1 账号注册、实名认证与平台入口
创建应用第一步，当然是注册腾讯云账号。如果本来就有账号，直接登录控制台即可。这里要提醒一句：务必完成实名认证，否则很多AI能力、API服务都无法开通。个人实名认证和企业实名认证在大多数功能上都能用，但如果你后续要做高并发生产环境，或者需要申请企业专属配额，企业认证会更有优势。
登录之后，进入腾讯云的大模型相关产品控制台。不同时期控制台入口名称可能会有调整，但大体方向是找“大模型知识引擎”“智能体平台”或“应用编排”这类入口。你可以直接在产品搜索框里搜“大模型”或“DeepSeek”，一般都能直达。进去之后，先别急着创建应用，先在“模型列表”或“模型广场”里确认你要用的DeepSeek 671B模型是否已经在当前地域开通，以及对应的模型名称、上下文长度和价格。
2.2 弄清模型ID和参数规格，不要选错型号
腾讯云上列的DeepSeek模型通常会有多个版本，比如通用对话版本和推理增强版本。很多人的误区是：看到“DeepSeek”几个字就下单，结果发现模型ID不对，应用创建完调用时报错。实操里建议这样做：
在模型列表里先确认每条模型的模型ID、是否671B版本、上下文窗口长度、价格这三项。通用场景选择对话型模型即可，复杂推理、数学、代码生成类的任务可以选推理增强版本。但要注意，推理增强模型会输出“思考过程”，响应的Token消耗会比普通对话模型更高，速度也会慢一些。如果你的应用只是做知识问答，没必要盲目上推理模型。
另外，上下文长度决定了模型能“记住”多少对话历史。现在很多模型支持长上下文，但不要一上来就把历史窗口拉到最大，因为每次请求都会把历史记录重新发给模型，上下文窗口越长，单次请求的Token开销越大，响应延迟也越高。后面我会讲怎么在成本和效果之间找平衡。
2.3 开通联网搜索组件
零代码创建应用时，联网能力通常不是模型自带的，而是以“插件”“工具”或“组件”的形式挂在应用中。在平台的插件中心找到一个叫“联网搜索”或“Web Search”的组件，开通它。开通后一般会有几个配置项：
- 搜索引擎类型：有的平台让你选通用网页搜索还是指定站点搜索。
- 默认搜索返回条数：比如每次搜索返回3条、5条或10条结果。
- 是否允许自动触发：由模型自行判断“这个问题要不要联网”，还是强制每轮都先搜索。
这里我的建议是：不要一开始就设成“每轮强制搜索”。没有时效性需求的问题，比如“帮我写一段欢迎词”，搜索只会引入噪声，还会增加响应耗时和费用。比较好的默认配置是“自动判断触发+返回5条结果”，后面根据实际问答效果再微调。
2.4 API密钥该不该提前准备
很多零代码教程都会提到“获取API密钥”，但我要澄清一下：如果你是纯零代码方式，在腾讯云控制台里可视化创建应用，大部分情况下根本用不到自己的API密钥。密钥是给通过API/SDK直接调用模型时的身份凭证。只有当你打算把做好的应用发布成API服务，供自己的网站、小程序或外部系统调用时，才需要去“访问管理”里创建API密钥，并在调用接口时带上鉴权信息。
不过，你仍然建议提前把密钥创建好，因为发布API这一步早晚会用上。创建路径一般是：控制台右上角头像 → 访问管理 → API密钥管理 → 新建密钥。创建后把SecretId和SecretKey保存到安全的地方，建议不要提交到Git仓库或公开代码里。
3. 零代码创建联网应用的完整流程
3.1 新建应用，先定“人设”再选模型
进入应用编排平台后，点击“创建应用”。通常会让你选择应用类型，一般有“对话型应用”“知识问答型应用”“流程型应用”等。绝大多数DeepSeek联网应用场景，选“对话型应用”就够了。
创建之后第一步不是配运算，而是写清应用的基本信息，包括应用名称、应用描述、欢迎语。很多人觉得这些是形式化的东西，应付一下就过去了。实际上，应用描述和欢迎语会影响模型对任务的理解。比如你做一个“实时热点问答助手”，应用描述可以写“面向运营人员，提供最新热点事件、舆情趋势和新闻背景的实时查询服务”。模型看到这个描述后，会倾向于用更严谨、更咨询式的方式作答。欢迎语则是对用户的引导，直接告诉用户可以问哪些类型的问题，能显著降低对话的试错成本。
接下来是选模型。在下拉列表找到你开通的DeepSeek 671B模型，点选即可。这一栏最需要设置的是“系统提示词”。它不是给普通用户看的东西，而是给模型看的“底层指令”。我来给一个常用模板：
你是一个实时信息助手。你的知识截止于训练数据时间，而不是当前时间。 当用户的问题涉及新闻、事件、行情、天气、政策、榜单等时效性信息时， 你必须先调用联网搜索获取最新资料，再基于搜索内容回答。 如果搜索结果无法回答用户问题，请明确说“我暂时无法确认”，绝不能编造数据。 回答时尽量提供信息来源和链接，保持客观中立。这段提示词把“什么时候必须联网”“搜不到怎么办”“要不要给来源”都约束住了。很多人配置完联网插件还是觉得模型“不听话”，八成就是系统提示词里没有把这些规则写清楚。
3.2 打开联网搜索插件并设置触发条件
在应用编辑界面找到“插件”或“工具”区域，把“联网搜索”打开。打开后，仔细看它的触发设置，一般有三种模式：
- 自动：由模型根据问题判断是否需要联网。
- 强制：每轮对话都先搜索再回答。
- 条件触发：根据你配置的规则判断，比如检测到“最新、今天、2026、几月几日、多少钱、比分”等词时触发。
对于大部分场景，我建议用“自动+关键词补充”的组合。比如在触发词表里加入“最新、新闻、暴跌、暴涨、推荐、价格、天气、政策、比赛、发布”，这样既不会每题都搜，又能在明显需要实时信息的问题上稳定触发。
搜索条数默认5条是个不错的起点。如果回答经常出现信息量不足，可以改成8条；如果回答太散、总是被无关网页带偏，就退回3条。搜索条数不是越多越好，模型在长网页里提取关键信息的难度也会增大。
3.3 配置对话变量与多轮记忆
零代码平台里有个“变量”功能，很容易被忽略。它可以让用户在对话时填入固定信息，比如城市、行业、账号ID等，然后再用这些信息去拼接问题。
举个例子。你做一个“本地生活实时问答助手”，可以新建两个变量，一个叫“城市”，一个叫“兴趣品类”。用户在开始对话前会收到表单，填了“上海”和“美食”之后，模型再接收到“有什么新的餐厅推荐”这类问题时，就会自动把问题补全为“上海新开的美食餐厅推荐”，再触发联网搜索。这比让用户每句话都重复“我在上海、我要找美食”要贴心得多。
多轮记忆功能我建议默认打开，但要在发布前测一下。多轮记忆意味着模型要携带历史对话一起请求，长对话的Token消耗会快速累积。对偏工具型的应用，比如“查完即走”的行情问答，可以考虑限制每轮最多携带5到10条历史消息，超出后只保留摘要。
3.4 可选：绑定知识库再联网
如果你的问题集中在某个垂直领域，比如公司内部规章制度、产品使用手册、专业术语解释，推荐先给应用挂一个知识库，再让模型使用“知识库优先，联网兜底”的策略。
在平台上创建知识库，上传文档（格式一般支持TXT、PDF、Markdown，有的支持Word），平台会做切分和向量化。然后在应用编排里把知识库拖进去，设置检索策略：当知识库中找到相关度足够高的内容时，直接基于知识库回答；当知识库检索不到或有明确时效性需求时，才调用联网搜索。
这个组合能显著提升回答稳定性，还能降低无意义的搜索费用。但要记住，知识库内容和联网结果混合出现时，模型有可能把两者混淆，所以系统提示词里最好再加一句：“知识库内容优先于搜索内容；如果两者冲突，说明存在差异，并分别标注来源。”这样能避免一套答案里同时出现自相矛盾的内容。
3.5 测试窗口实测，验证“先搜索后回答”
配置完成后，先不要急着发布，在平台自带的调试窗口里做三轮测试：
第一轮问一个无需联网的问题，比如“用一句话介绍量子计算”，确认模型正常回答且没有强行搜索造成延迟。 第二轮问一个强时效问题，比如“过去24小时科技圈有哪些大新闻”，重点观察模型会不会去搜索、答案里有没有引用来源。 第三轮问一个容易引发幻觉的问题，比如“某只你虚构的股票代码现在价格是多少”，看模型会不会硬编一个数字。如果它回答“无法确认”，说明配置到位；如果它编了个价格，说明系统提示词约束还不够，要去把“绝不编造数据”写得更强硬。
这几轮测试基本能判断应用是否达到上线标准。
3.6 发布：链接分享、API接入还是嵌入网页
测试没问题就可以发布。平台一般提供三种发布形式：
- 分享链接：生成一个网页链接，发给别人就能直接对话，适合内部试用、MVP验证、个人作品展示。
- 发布为API：拿到API地址和鉴权密钥，供自己的程序调用，适合产品集成。
- 嵌入网页：复制一段JS代码或iframe，把对话窗口嵌入到自己的官网或后台系统。
零代码的第一步通常用“分享链接”就够了，跑通后再升级为API接入。要注意，分享链接如果设为“任何人可访问”，拿到链接的人就能消耗你的模型配额。正式使用务必开启访问鉴权，或设置每日调用上限。
4. 关键参数调优与成本控制心头好
4.1 温度、Top P和Max Tokens怎么定
很多人在应用编排里看到一堆参数直接懵：温度是什么？Top P有什么用？Max Tokens该设多少？我用最简单的话解释：
温度（Temperature）控制答案的随机性。数值越高越“天马行空”，适合创意写作；数值越低越“一本正经”，适合事实问答。做联网问答应用，温度建议设在0.2到0.4之间，让模型尽量忠实于搜索结果，而不是自由发挥。
Top P控制候选词的概率累计范围。它和温度是配合关系，一般保持默认就好，不用同时调。如果你想调试，可以先固定一个值（比如0.8），只动温度，否则两个变量一起改，你根本分不清是哪个参数导致回答风格变了。
Max Tokens是单次回答的最长Token数。这个值不是越大越好。设置太大会导致模型啰嗦、响应变慢，费用也高。一般联网问答应用设置在1024到2048之间足够了。如果你的应用涉及长文生成，再单独调高。注意，回答长度和上下文长度是两个概念，别混在一起。
下面是一个速查表，适合直接抄作业：
| 参数 | 推荐值 | 使用场景 | 备注 |
|---|---|---|---|
| Temperature | 0.2-0.4 | 实时问答、知识检索 | 越低越忠实事实 |
| Temperature | 0.7-1.0 | 创意写作、头脑风暴 | 越高越有发散性 |
| Top P | 0.8-0.95 | 通用场景 | 一般不用大改 |
| Max Tokens | 1024-2048 | 联网问答 | 长文任务再调高 |
| 搜索条数 | 3-5 | 大部分问答 | 信息不足再加 |
4.2 联网结果太少或太杂怎么办
联网搜索并不是“开启即完美”。最常见的两个问题：
一是结果太少，模型答不出来。这时候优先看是不是搜索关键词写得不好。模型自己构造搜索词的能力参差不齐，你可以在系统提示词里教它：搜索时提取核心实体+限定词，比如把“最近有什么新手机发布”转化为“2026年3月 新手机 发布”。有些平台支持手动设置搜索的保留词和排除词，比如排除“广告”“推广”类的站点，效果立竿见影。
二是结果太杂，出现大量无关或低质网页。可以在搜索插件的高级设置里配置域名过滤规则，只允许特定网站的结果进入模型参考范围。比如做科技资讯问答，可以优先允许几个主流科技媒体的域名。如果平台不支持域名过滤，那就靠提示词兜底：“优先参考权威媒体来源，忽略论坛、自媒体和个人博客的内容。”实测下来这一句能明显改善答案质量。
4.3 联网搜索计费与调用量监控
用671B模型加联网搜索，费用主要来自三块：模型Token费用、搜索服务费用、可能的知识库检索费用。Token费用是大头。同样是671B模型，输入和输出价格不同，输出Token通常比输入贵几倍。而联网搜索一般按次计费，每次搜索的价格相对较低，但如果你的应用每一轮对话都触发搜索，日积月累也不是小数目。
要控制成本，我的经验是：
- 严格区分“需要联网”和“不需要联网”的对话，能用自动触发就别用强制搜索。
- 高频固定问题（公司介绍、价格表、营业时间）做成知识库或预设回复，不从模型走，能省掉大量重复调用。
- 在平台设置每日调用量预警，比如单日费用超过某个金额就报警，防止应用被刷或者出现死循环调用。
- 对生产环境应用做并发限制，防止瞬时大量请求把配额耗尽。
平台的监控面板能看到每轮对话的Token消耗、搜索调用次数和费用明细，建议发布初期每天看一次，跑一周后基本能摸清规律。所有价格数字都在变化，我就不写具体价格误导你了，以控制台实时展示为准。
5. 常见问题与排查技巧实录
5.1 模型就是不联网，回答明显过时
这是出现频率最高的问题。检查顺序是这样的：
第一步，确认联网搜索插件确实在“已开启”状态，而不是只添加了没打开。 第二步，确认系统提示词里有没有明确要求“涉及时效性问题时先搜索”。如果提示词写得含糊，模型很可能偷懒只靠内部知识回答。 第三步，去调试窗口手动输入一个强时效问题，看后台日志里有没有生成搜索记录。如果日志里没有搜索记录，说明触发条件没生效，去检查触发关键词是否覆盖了你的测试问题。 第四步，如果用的是“自动触发模式”，个别模型为了追求低延迟会漏掉一些该搜的场景，改用“强制模式”验证一下，如果强制模式正常，说明问题出在判断逻辑上。
有一类情况比较隐蔽：平台把“联网搜索”和“大模型内置联网能力”当成两个开关。你只开了搜索插件但没在模型设置里打开“允许模型调用外部工具”，就会导致搜索组件被挂载但模型始终不调用。这种问题日志里往往显示“用户问题已回复，未调用工具”，非常值得注意。
5.2 请求超时、响应很慢
671B模型推理本身比小模型耗时，配置联网搜索后又要先搜索再生成，响应变慢是正常的。但慢到明显超时，一般是这几个原因：
上下文太长。如果应用绑定了知识库，且每次提问都把几千条历史记录带进去，模型光处理输入就要好几秒。 搜索返回的网页内容太多。每个网页几百甚至几千字，全部塞给模型后，解析时间当然久。 并发过高导致限流。平台对免费配额或默认并发有限制，超过后请求会排队。
排查思路：先看日志里的耗时分布。如果是“搜索耗时2秒、模型首字返回8秒”，那属于正常范围；如果是“搜索耗时5秒以上”，去精简搜索条数和网页摘要长度；如果是“模型处理阶段特别慢”，去缩减上下文携带量和Max Tokens。
5.3 回答引用了不存在的链接
有一种情况特别迷惑：模型给出了看起来像模像样的链接，但点击后发现是死链或根本不存在。这其实是模型“脑补”了链接格式。它见过大量URL的模式，虽然搜索结果里没有对应来源，但它会根据印象拼接出一个假的URL出来。
要杜绝这个问题，两条路：第一是在系统提示词里加死命令——“只允许引用联网搜索实际返回的网页链接，不允许自己构造或猜测链接，如果没有任何可信链接，明确说没有来源。”第二是在平台层面开启“引用来源校验”，如果平台支持，它能保证输出的链接来自真实搜索结果。这两个措施一起上，基本能消除假链接问题。
5.4 多轮对话中搜索越搜越偏
用户第一问“最近有什么AI新闻”，模型搜索结果还行。追问“那家公司后来回应了什么”，模型却搜出一堆无关内容。原因是模型在第二轮构造搜索词时，没有带上第一轮的语境，结果搜到了同名或泛化内容。
解决办法：在系统提示词里加上“搜索词构造策略”：用户问题含指代词（这家、该公司、这个事件）时，先根据历史对话还原完整上下文，再生成搜索词。比如“那家公司”要还原为上一轮提到的公司全名。如果平台支持“对话历史注入搜索词”，记得打开。实测下来，这个细节能把多轮搜索的准确率提升一大截。
5.5 发布后被刷，费用飙升
公开的分享链接很容易被有心人拿去刷量。应用上线后突然某天亮起警报告诉你费用异常，多数就是链接被公开传播了。
防御措施在发布那一刻就要做好：第一，分享链接设置访问密码或开启鉴权；第二，控制台设置单用户单日对话上限；第三，配置费用预警；第四，如果只是自用，别用“任何人可访问”，改成“指定账号登录后才能访问”。
6. 一些真正提升效率的实操心得
6.1 先用“通用问题集”给应用做压力测试
在正式上线前，找几个非技术背景的朋友帮忙问，比你一个人调半天效果都好。我给内部测试固定用的三个问题集：
时效题：“帮我查一下今天的热搜榜单。”主要看搜索触发是否稳定。 事实题：“大语言模型和传统搜索引擎有什么区别。”主要看普通回答质量。 刁钻题：“某明星最近一天宣布了什么活动。”用于观察陌生信息是否能被搜索到并正确引用。
这三类测完，一个问题翻车概率最高的底座就清楚了。如果是企业内部场景，再补充行业专属问题集，比如金融的问行情、电商的问促销政策。
6.2 把系统提示词当成“产品说明书”迭代
很多人配完一个prompt就不再动了，这是不对的。系统提示词应该像产品说明书一样，随着测试反馈不断更新。我一般会在每个版本的提示词开头写注释，比如“v3版本：新增链接校验规则，防止伪造链接”。平台若支持版本管理，每次改动都留下记录，方便回滚。
我也习惯在提示词末尾加一句自我检查指令：“在你给出最终回答前，请检查是否有足够的信息来源支撑；若没有，请建议用户再提供具体关键词或重新提问。”这句话能让模型在回答前多一道自检机制，减少许多看起来莫名其妙的结果。
6.3 零代码应用上线后的每周维护
很多人以为应用发布就万事大吉。实际上，零代码应用也需要定期维护：每周看一次日志里的失败问题样例，每两周更新一次触发关键词，每月复盘一次费用趋势。搜索互联网的网页结构经常变化，搜索插件偶尔会返回异常或质量变差，不维护的话效果会慢慢下滑。
另外，关注模型版本更新。云平台会不定期上架模型新版本，如果你的应用还钉在旧版本，可能在效果和价格上都吃亏。去看一眼模型列表里的新版本提示，确认兼容性后一键切换，是成本最低的优化手段。
6.4 最后再分享一个小技巧
如果你做的应用要接入到自己的产品里，别让用户每次提问都面对一个空白对话框。在应用里可以预设几个“示例问题”，用户一点就能自动填充，比如“2026年最新的AI行业融资事件”、“今天北京天气和空气质量”等。这既能让用户迅速理解这个应用擅长什么，又能引导用户提出更符合联网搜索能力边界的问题。预设问题的选取原则是：问题应当是“有明确时效性、可被搜索验证、你不能随口编造”的，这样才能让用户一试用就感受到联网的价值。
我个人在实际操作中的体会是：零代码搭出一个联网应用并不难，难的是让它在真实业务里稳定、靠谱、成本受控。把每一个开关的含义搞清楚，把系统提示词当成产品说明书去迭代，把测试用例变成固定流程，这三件事比任何参数调优都要更能决定最终效果。做完这些，你的671B联网应用就不是一个demo，而是一个真正能对外服务的产品了。
