当模型能接受数十万标记时，您可能会倾向于粘贴完整文档或代码库。但问题是：注意力分配并非均匀。深埋或置于干扰信息之前的关键信息可能被忽略，长上下文性能会因格式、分块边界和叙述流而异。优先采用嵌入检索，保持片段简短，并明确标注上下文（例如，来源：合同A，第4.2条）以固定引用并减少漂移。

实际测试胜过合成测试。使用固定答案和模拟现实的干扰进行评估：扫描PDF、混合风格代码、错序页面和冲突草稿。跟踪：关键信息回忆率、引用忠实度、对提示顺序的敏感性以及随着标记数增加的性能下降。如果质量在某个窗口后急剧下降，应限制上下文，转而依赖地图-归约摘要和稀疏检索。

复杂工作流——财务分析、补救规划、根因分析——受益于能保持多步计划、调用工具和修正中间假设的模型。但更深的推理通常意味着更高延迟和成本。避免一刀切的流程：将简单提示路由到高效模型，仅在不确定或风险高时升级，并为特定意图或用户开放推理深度控制。

使用需要中间状态的组合任务测试推理：多表连接、政策例外或设计权衡。分别评分最终答案和中间论证，并惩罚自信错误。如果系统使用工具，应评估规划器而非仅生成器：衡量工具调用正确性、步骤数和错误恢复能力。逻辑严密但速度慢的模型可能无法满足SLA约束的助理需求。

企业很少仅处理纯文本。支持工单包含截图，审计以扫描件形式出现，技术人员通过移动应用口述发现。多模态模型简化了这些交接，但质量参差不齐：混乱发票的OCR、小字体UI截图或微弱音频都可能影响模型表现。请使用实际文件类型、语言和噪声特征进行验证。视频成本随帧数增长；长视频优先使用关键帧提取或视觉+自动语音识别混合方案。

工具进一步扩展了模态：浏览器用于溯源，电子表格用于计算，绘图工具用于输出，数据库用于检索。确认模型能解析并遵循工具架构，遵守速率限制，并能从工具错误中恢复。在受监管的工作流中，需记录每种模态的输入/输出，并要求可验证的引用以通过审计。

感知性能取决于首标响应时间（TTFT）和流式稳定性，而非仅看总吞吐量。对于交互式应用，目标是TTFT低于500毫秒，并在负载下保持稳定的每秒标记数。将计算资源靠近用户，保持提示简洁，优先使用结构化引用而非臃肿上下文。对于代理，分析工具调用的排队时间，并并行化安全步骤以避免串行瓶颈。

运营技巧至关重要：缓存提示和检索片段，为重复任务预热会话，延迟激增时限制推理深度。分别监控95和99百分位延迟与中位数，因为尾部行为会破坏用户体验。如果工作负载有突发性，应购买余量——用户记住的是突发时的延迟。

端到端成本不仅是输入和输出标记。长上下文会在重试、RAG失误和代理重读状态时放大开销。缓存、提炼摘要和更小的专业模型能大幅降低运行成本。跟踪每个功能的单位经济：每解决一张工单、每条红线或每个警报的成本，而非仅按每千标记计费。设定预算护栏，在预算紧张时优雅降级到更便宜的路径。

采用组合策略：一个快速低成本的模型用于路由和模板化任务；一个强大的通用模型用于中等推理；一个顶级模型用于关键场景。基于置信度、引用和异常规则自动升级。随着时间推移，将常见模式转为模板或微调，将昂贵推理保留给能改变决策的边缘案例。