2026 年的 LLM Agent 技术栈选型
2026 年，LLM Agent 的生态已经基本成熟到可以"选型"了。本文给出一份我个人在生产环境里使用过、觉得靠谱的栈，作为给同样在做 Agent 工程的同学的参考。
1. 模型层
主模型我会分用途选：
- 长上下文 + 高质量推理：闭源旗舰（Claude / GPT 系列的最新代）。
- 工具调用 / 结构化输出：开源旗舰（DeepSeek、Qwen、Llama 4 等的 Instruct/Function-Calling 版本）。
- 廉价的批量任务：参数量 8B-14B 的开源模型，本地推理或 Hosted API。
2. 编排层
编排框架我推荐两个：
- LangGraph：图结构，适合需要显式状态机的复杂 Agent。
- 轻量方案：直接写状态机 + Tool Loop，几十行代码就够用，避免重型框架锁定。
3. 工具调用规范
推荐：
- 工具接口统一走 OpenAI function-calling 兼容格式
- JSON Schema 描述工具行为
- Tool 的实现放在独立服务（HTTP / RPC），而不是直接嵌入 Agent 代码
4. 记忆与上下文
- 短期：消息数组 + 截断 / 重排
- 长期：向量库 + 元数据过滤
- 关键事实：结构化笔记（如 JSON 卡片），而不是堆到对话里
5. 可观测
无论 Agent 多简单，log LLM 调用 + Tool 调用 + 决策路径 是必须的。推荐 Langfuse / OpenTelemetry 兼容方案。
6. 评测
不要相信 demo。准备至少 20 个真实 case 做回归，每次 prompt / 模型 / 工具变更都跑一遍。
7. 部署
- Serverless 优先（Cloudflare Workers / Vercel / Modal）
- 长任务用队列（Cloudflare Queues / SQS）
- 冷启动敏感的场景留一档同步兜底
8. 兜底机制
三个兜底是底线：
- Tool 调用失败 → 重试 + 退避 + 提示模型重新组织输入
- 模型超时 → 切换到备用模型
- 幻觉 / 不合规 → 输出校验 + 人工审核标记
取舍原则
复杂度的真正敌人是"看起来很通用"的方案。建议：
先用一个会话循环 + 3 个工具 + 一个评测集跑通业务，再决定要不要引入框架。
等你的业务跑顺了，框架自然会用上。还没跑顺之前，框架只会让 debug 更难。
下一篇预告：写作 / 复盘 的工程化方法。