能力边界、上下文窗口与模型选型
理性认识模型能做什么、做不到什么，掌握效果—成本—延迟三角与主流选型方法
- 区分“知识边界、推理边界、上下文边界、工具边界”
- 理解上下文窗口、长上下文的代价与“中间遗忘”
- 建立效果、成本、延迟的量化权衡意识
- 掌握一套可落地的模型选型流程
选型的本质：不是选最强，而是选最合适
新手最常犯的错，就是不管啥任务都直接上最强、最大、最贵的模型。工业界实际是这么干的：先把任务拆解开，看每个环节对能力的要求是什么，再用“刚好够用”的模型组合去匹配，贵的模型只留着用在真正难的环节上。
2.1 四类能力边界
知识边界：模型参数里“记住”的信息，有训练截止时间，且不包含你的私有数据。推理边界：多步逻辑、长链计算、精确算术的可靠度有限，越复杂越容易在某一步出错并传导。上下文边界：一次能读入的 Token 上限，以及在超长文本里准确找到并使用信息的能力。工具边界：模型本身不能联网、不能查你的数据库、不能执行操作，必须靠工具调用（Function/Tool Calling）把能力“外接”出去。
好的 Agent 设计，本质是用工程手段补模型边界：用 RAG 补知识边界，用代码/计算器/工具补推理边界，用检索与分块补上下文边界，用受控工具补操作边界。别指望靠“更大的模型”一次性解决所有边界问题。
2.2 上下文窗口不是越大越“好用”
上下文窗口（Context Window）指一次请求能容纳的输入+输出 Token 总量。窗口从几千到上百万 Token 不等，但要注意三点：
成本随输入长度近似线性增长，塞得越多越贵；注意力计算对长度敏感，长文本更慢、更耗显存；存在“大海捞针/中间遗忘”现象——信息放在超长上下文的中间位置时，被正确引用的概率可能下降，并非窗口够大就一定用得上。
下列关于长上下文的说法，最准确的是？
上下文工程（Context Engineering）
比“写好提示词”更重要的是“管理好进入上下文的内容”：系统提示、历史对话、检索片段、工具返回、用户输入，都会抢占有限窗口。
常见手段：历史对话滑动窗口或摘要压缩；检索片段去重、重排（rerank）、只保留最相关的几块；工具返回做裁剪而不是原样灌入；把稳定的规则放系统提示、把易变信息放靠近问题的位置（recency 效应）。
2.3 效果—成本—延迟的不可能三角
效果越好，一般对应模型越大、推理用的 Token 越多（尤其是推理模型，会先“想”一大段）、延迟越高。想降成本提速度，就得在效果上让步。三者没法同时拉满，工程上靠「模型分层 + 缓存 + 精简上下文」凑出最接近最优的组合。
单次成本 ≈ 输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价（输出通常更贵）。日成本 = 单次成本 × 日调用量。优化优先级通常是：减少无效上下文 → 简单任务换小模型 → 相同问题加缓存 → 最后才是换供应商。
2.4 一套可落地的选型流程
建评测集：从真实场景抽50~200条有代表性的样本，定义“答对”的客观标准。用同一套提示与评测集跑不同档位模型，记录准确率、平均延迟、单次成本。定分层策略：哪一步用小模型、哪一步升级到大模型，什么情况下触发升级（路由）。上线后持续用Badcase扩充评测集，模型或提示变更必须先过评测集，避免“改好一个、改坏三个”。
团队想为客服场景选型，最科学的第一步是？
推理模型的工作方式是先出“思考过程”，再给最终答案。复杂任务用它效果更稳，但代价是耗 Token 多、速度慢。简单分类、信息抽取这类任务用它纯浪费。数学题、复杂规划、难搞的调试这类场景，才值得花这个成本。可以搭个小模型先判断任务难度，简单题自己处理，难题再转给推理模型。
本节小结
给我记死这几个核心：四类边界、不可能三角。边界不够，工程来补；要性价比，就做分层；别拍脑袋定效果，拿评测集说话。 模型迭代快得很，换了一茬又一茬，但「以任务定能力、以数据做决策、以分层控成本」这套思路，长期能用。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
四大件：规划（任务分解、ReAct 思考-行动循环）、记忆（短期上下文 + 长期向量记忆）、工具（函数调用 / MCP 协议）、执行与自我校验。工程上真正难的不是让它「更聪明」，而是让它可中断、可回滚、全程可观测、每一步可验证、失败后能恢复——可靠性来自机制而非玄学。