每年年初都会有一批"AI 趋势预测"文章，大多读完感觉什么都写了又什么都没说。
这篇文章尝试不一样——只谈真正在改变工程实践的技术变化，跳过那些换汤不换药的营销概念。
趋势一：推理模型成为标配
2025 年最大的模型架构变化不是参数量暴增，而是推理时计算（Test-Time Compute） 的普及。
OpenAI o1/o3、DeepSeek R1、Claude 3.7 Sonnet（扩展思考）——这些模型的共同特点是：在给出最终答案前，会花更多时间"慢想"。技术上是在推理阶段运行更长的思维链，让模型有机会自我纠错。
差别是显著的。在竞赛数学（AIME 2024）上：
| 模型 | 准确率 |
|---|---|
| GPT-4o | 13.4% |
| Claude 3.5 Sonnet | 16% |
| o1 | 74.4% |
| o3 (high) | 96.7% |
这对工程实践的影响：推理模型不适合所有场景。回答"今天星期几"不需要深度推理，但调试复杂 Bug、证明算法正确性、多步数学推导，用推理模型效果会好很多，代价是延迟更高、成本更贵。
正确的做法是路由：简单问题用快模型，需要深度推理的问题切换到推理模型。
def route_to_model(query: str, context: dict) -> str:
"""根据问题复杂度路由到不同模型"""
complexity_indicators = [
"为什么", "证明", "分析", "推导",
"复杂", "比较", "权衡", "设计方案"
]
is_complex = any(kw in query for kw in complexity_indicators)
is_long_context = len(context.get("history", "")) > 5000
if is_complex or is_long_context:
return "o3-mini" # 推理模型
return "gpt-4o-mini" # 快速轻量模型
趋势二：上下文窗口不再是瓶颈，但不意味着"塞满就好"
Gemini 1.5 Pro 支持 100 万 token，Claude 3.5 支持 200K。上下文窗口限制基本上不是大多数应用的瓶颈了。
但"窗口大了就把所有内容塞进去"是个陷阱。研究（Lost in the Middle, 2023）表明：当上下文很长时，模型对中间部分的关注度显著下降，头部和尾部信息更容易被利用。
工程上的应对：
def prepare_context(documents: list[str], query: str, max_tokens: int = 50000) -> str:
"""智能上下文准备：相关内容优先，控制总长度"""
from langchain_openai import OpenAIEmbeddings
import numpy as np
embeddings = OpenAIEmbeddings()
query_emb = embeddings.embed_query(query)
scored_docs = []
for doc in documents:
doc_emb = embeddings.embed_documents([doc])[0]
score = np.dot(query_emb, doc_emb) / (
np.linalg.norm(query_emb) * np.linalg.norm(doc_emb)
)
scored_docs.append((score, doc))
scored_docs.sort(reverse=True)
selected = scored_docs[:10]
# 最相关放开头，次相关放结尾，避免 lost-in-the-middle
ordered = selected[:3] + selected[5:] + selected[3:5]
context_parts, total_tokens = [], 0
for _, doc in ordered:
doc_tokens = len(doc) // 4
if total_tokens + doc_tokens > max_tokens:
break
context_parts.append(doc)
total_tokens += doc_tokens
return "\n\n---\n\n".join(context_parts)
趋势三：Agent 基础设施走向成熟
2024 年大家都在探索 Agent 能做什么，2025-2026 年的问题变成了：怎么让 Agent 跑得稳。
核心工程挑战已经很清晰：
1. 持久化与恢复
Agent 任务可能跑几分钟到几小时，中间进程崩了需要从断点恢复，而不是从头开始。
from langgraph.checkpoint.postgres import PostgresSaver
conn_string = "postgresql://user:pass@localhost/agent_state"
checkpointer = PostgresSaver.from_conn_string(conn_string)
app = workflow.compile(checkpointer=checkpointer)
# 每次工具调用后自动保存状态，崩溃后用相同 thread_id 恢复
config = {"configurable": {"thread_id": "task-abc-123"}}
result = app.invoke({"messages": [...]}, config=config)
2. 可观测性
Agent 不透明最头疼：它做了什么决策？为什么调用这个工具？失败的是哪一步？
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "your_key"
os.environ["LANGCHAIN_PROJECT"] = "production-agent"
# 之后所有 LangChain/LangGraph 调用都会自动上传 trace
# 可以在 LangSmith UI 里看到完整的推理链
3. 并发与速率限制
生产环境 Agent 要同时服务多个用户，需要管理并发和 API 限速：
import asyncio
from asyncio import Semaphore
class RateLimitedAgentPool:
def __init__(self, max_concurrent: int = 10):
self.semaphore = Semaphore(max_concurrent)
async def run_agent(self, task: str) -> str:
async with self.semaphore:
return await agent_app.ainvoke({"input": task})
async def run_batch(self, tasks: list[str]) -> list[str]:
return await asyncio.gather(*[self.run_agent(t) for t in tasks])
pool = RateLimitedAgentPool(max_concurrent=10)
results = asyncio.run(pool.run_batch(user_tasks))
趋势四：本地小模型的实际可用性提升
Llama 3.1 8B、Qwen2.5 7B、Phi-4 这些小模型，量化后（GGUF Q4）在 M2 MacBook 上就能跑，速度不慢。
用 Ollama 一行命令启动本地模型：
ollama pull qwen2.5:7b
ollama serve # 启动本地 API 服务，绑定 localhost:11434
代码兼容 OpenAI API 格式：
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama"
)
response = client.chat.completions.create(
model="qwen2.5:7b",
messages=[{"role": "user", "content": "用 Python 写一个快速排序"}]
)
print(response.choices[0].message.content)
本地模型的适用场景：
- 数据隐私：不能把内部数据发给第三方 API
- 成本敏感：大量低难度任务（文本分类、信息提取）
- 低延迟：网络延迟不可接受的场景（边缘设备）
- 开发调试：本地快速迭代，不消耗 API 额度
局限也很明显：7B-13B 模型在复杂推理、代码生成上仍比不上 GPT-4o，量化会损失精度。用本地模型的正确姿势是分层使用：简单任务本地跑，复杂任务上云。
趋势五：多模态走向工程化
“看图说话"早过了展示阶段。2026 年多模态的工程价值在于：
文档理解：直接把 PDF/图片发给模型，跳过 OCR。Claude 和 GPT-4V 处理表格、图表的准确率已经实用：
import base64
from openai import OpenAI
def analyze_document(image_path: str, question: str) -> str:
with open(image_path, "rb") as f:
b64 = base64.b64encode(f.read()).decode()
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "user",
"content": [
{
"type": "image_url",
"image_url": {"url": f"data:image/jpeg;base64,{b64}"}
},
{"type": "text", "text": question}
]
}],
max_tokens=1000
)
return response.choices[0].message.content
# 提取财报表格数据
result = analyze_document(
"quarterly_report.png",
"提取表格中的营收数据，按季度整理成 JSON 格式"
)
截图直接转代码、UI bug 截图直接描述问题——这些场景在开发工作流里已经很常见，效率提升是实实在在的。
趋势六：Prompt 工程走向系统化
DSPy 是这个方向的典型代表——把 Prompt 优化变成一个可自动调优的编程问题：
import dspy
class AnswerWithReason(dspy.Signature):
"""根据上下文回答问题，并解释推理过程"""
context = dspy.InputField(desc="背景信息")
question = dspy.InputField(desc="用户问题")
answer = dspy.OutputField(desc="答案")
reasoning = dspy.OutputField(desc="推理过程")
class QAModule(dspy.Module):
def __init__(self):
self.generate = dspy.ChainOfThought(AnswerWithReason)
def forward(self, context, question):
return self.generate(context=context, question=question)
from dspy.teleprompt import BootstrapFewShot
optimizer = BootstrapFewShot(metric=your_metric_fn)
optimized_module = optimizer.compile(QAModule(), trainset=train_data)
result = optimized_module(context="...", question="...")
与其手动调 Prompt，不如定义评估指标，让优化器自动搜索最佳 Prompt（包括 few-shot 示例的选取）。
哪些趋势被高估了
“AGI 即将到来”：连最激进的研究者也承认，当前的 Scaling Law 在某些能力上开始出现边际递减。推理能力提升显著，但常识推理、长程规划仍有明显上限。
“Agent 会替代所有工作”：当前 Agent 在受控环境（明确工具集、有限任务域）下工作良好，在开放环境中可靠性远未达到"独立工作"的水平。LLM 的幻觉问题还没根本解决。
“本地模型会完全取代云 API”：7B-13B 的模型在特定任务上很有用，但不是所有任务的替代品。云端旗舰模型在复杂任务上仍有 2-3 代的领先优势。
工程师应该关注什么
从工程实践角度，2026 年值得重点投入的能力：
- LangGraph / Agent 工作流：复杂 AI 应用的事实标准在向图结构转变
- 评估体系：没有评估指标就没有可靠的迭代，RAGAS、LangSmith、自定义 eval 都要会
- 观测与调试：生产 Agent 的 trace 分析、性能瓶颈排查
- 模型路由与成本控制：混合使用不同等级的模型
核心不变：理解模型能力的上限，不要让"AI 能做的一切"遮住"AI 现在做不好的事情”。