企业官网建设流程全解析

上周连着两条模型更新，又把"上下文窗口"这个参数往上推了一截。9 月 22 日 Anthropic 发布 Claude Opus 5.5，默认上下文 100 万 token、单次最多输出 12.8 万 token，输入输出定价每百万 token 4 美元和 20 美元，缓存读取 0.2 美元；一周后 9 月 29 日，OpenAI 的 GPT-6.1 Sol 把上下文拉到约 105 万 token，定价 2 美元和 10 美元（以上均据报道）。同一个星期里，两家头部厂商在做同一件事：把能塞进去的文档量做大，同时把单价往下压。

每次这种新闻出来，评论区都会冒出一句"RAG 要死了"。这话 2024 年就说过一轮，2025 年又反转回去。所以先把两件事分清楚：窗口变大是真的，但"能塞进去"和"该塞进去"是两码事。

变了什么，没变什么

变的是三样东西。窗口到了百万级，把一整份合同、一个中小型仓库的代码、一整本操作手册塞进去，已经技术上可行；单价这一代普遍降了 20% 左右，缓存读取更便宜；输出速度也提了一档。以前要绕着走的场景，现在能直着走。

没变的是另外三样。

一是上下文窗口不等于有效上下文。据相关的模型评测研究，"上下文腐烂"是个真实现象——模型性能随输入变长是非均匀退化的，真正的有效上下文大概只有窗口的 30% 到 60%，具体看任务。也就是说 100 万 token 的窗口，能稳定用上的可能就几十万，中间位置的信息最容易被忽略。

二是成本仍随 token 线性增长。把 100 万 token 整篇喂进去，光输入就 4 美元一次。对话还得每轮重发，长链路 Agent 每一轮都要重传上下文和工具描述，账单很快就不是"订阅费"能覆盖的。缓存能把重复部分压到 0.2 美元/百万，但缓存有生存时间，过期后第一次仍按标准价重算。

三是延迟。token 越多，首字延迟越长，这是 transformer 的结构决定的，短时间改不了。

结论很朴素：这两年在长上下文和 RAG 之间来回摇摆、还按整个产品押注单一架构的团队，很多是当年没把账算细。2026 年更合理的做法，是按单个功能分别决定。

上手：先算账，再选架构

别凭感觉选。下面这段纯标准库的 Python 可以直接跑，改数字就行：

# 长上下文 vs 检索，单次请求成本粗算（纯标准库，可运行）defcost(input_tokens,output_tokens,price_in,price_out):returninput_tokens/1_000_000*price_in+output_tokens/1_000_000*price_out OPUS_IN,OPUS_OUT=4.0,20.0# 美元/百万 token，Opus 5.5 标准价SOL_IN,SOL_OUT=2.0,10.0# GPT-6.1 Sol 标准价full_doc=300_000# 把 30 万 token 的文档整篇塞进去retrieved=6_000# 检索后只带 6 千 token 的片段out=800# 回答长度print("整篇塞入 Opus:",cost(full_doc,out,OPUS_IN,OPUS_OUT))print("检索后 Opus: ",cost(retrieved,out,OPUS_IN,OPUS_OUT))print("整篇塞入 Sol: ",cost(full_doc,out,SOL_IN,SOL_OUT))print("检索后 Sol: ",cost(retrieved,out,SOL_IN,SOL_OUT))

跑一下就能看到，整篇塞入比检索贵一到两个数量级。再乘上每轮对话的次数、每天的调用量，差距就非常具体了。注意价格会随版本变，跑之前去官网核一遍。

第二个动作是把便宜的地方用满。把重复的前缀——系统提示、工具定义、固定的参考文档——固定放在最前面并打开缓存，缓存读按 0.2 美元/百万算，能压掉大头；但记住缓存会过期，隔一段时间没命中就得重算。调接口时模型 id 用官方公布的那个（这一代是claude-opus-5-5），走标准 messages 结构即可：

# 真实的 Anthropic 调用形态，模型 id 与请求结构以官方文档为准fromanthropicimportAnthropic client=Anthropic()# 读环境变量 ANTHROPIC_API_KEYresp=client.messages.create(model="claude-opus-5-5",max_tokens=4096,system="<把固定不变的系统提示放这里，便于命中缓存>",messages=[{"role":"user","content":"把这份模块重构一下，并说明改动原因。"}],)print(resp.content[0].text)```## 几个容易踩的坑-**把大窗口当成"越大越稳"。**中间位置的信息最容易被跳过。长文档里插一句关键约束，模型未必抓得住，重要要求尽量放头尾、或者重复一次。--**忽略阶梯定价。**有的模型输入超过某一档（比如27万 token）会整次请求按更高倍率计费，长文档加长回答很容易"踩线"，成本不是线性的。--**忘了输出也是钱。**输出单价通常是输入的五倍上下。让模型"顺手把全文总结一遍"，会同时顶高输入和输出两头。--**觉得检索是免费的。**向量库要维护，重新切块和重新嵌入的预算一般占每月推理支出约两成，还要算上维护 pipeline 的人力。只比模型账单会比出错误结论。## 收尾窗口变大是好事，但它解决的是"能不能放进去"，不是"该不该放进去"。真正决定架构的是每个功能的四个属性：数据量、查询频率、对延迟的容忍度、以及缓存能不能命中。 你现在做知识库、做 Agent，是整篇塞，还是老老实实检索？还是两者混着用？评论区聊聊你的选择和踩过的坑。