网上流传的 Agent 学习路线，大多数都错了——不是内容错，是顺序错。

几乎所有路线都从"学框架"开始：LangChain → LangGraph → AutoGen → 整个 demo。结果学了一堆 API，搭出来的东西一遇到真实场景就崩。你根本不知道它为什么崩，也不知道怎么让它不崩。

正确的顺序应该反过来：先搞懂 Agent 在工程上会坏在哪里，再去学怎么用框架把这些坑填上。

第一阶段：底层机制（3-5 天，绝不要跳）

1. Function Calling / Tool Use 怎么工作

LLM 不是真的在"调用"工具，它只是根据你给的 schema 描述，输出一段 JSON：你的代码解析 JSON → 调真实函数 → 把结果塞回对话 → 模型继续。

整个过程模型完全依赖你写的 schema 描述。描述含糊 → 传错参数；类型没说清 → 传错类型。这不是玄学，是工程问题。

2026 必须知道：Claude Opus 4.7、GPT-5、Gemini 2.5 Pro、DeepSeek-V3、Qwen3 都已支持并行工具调用（parallel tool calls）——一次返回多个 tool_use block，可并发执行后批量回填，链路延迟降到 1/N。

2. ReAct 循环及其四大失败模式

Thought → Action → Observation → 再 Thought。理解之后才能识别 Agent 失败模式：

• 死循环：Observation 不满意一直重试
• Context 爆炸：循环轮次太多塞满上下文
• 早停：在拿到关键信息前判定"任务完成"
• 过度思考（2026 新增）：推理模型（Claude extended thinking、GPT-5 reasoning、R1）开启后，thought 阶段消耗几千几万 token 钻牛角尖。生产必须设 thinking.budget_tokens 上限，简单任务用 reasoning_effort: minimal

3. Context Window 的物理限制

但是！长 ≠ 好用。三个必须警惕的现象：

• Lost in the Middle：中段信息利用率低 → 关键信息放头尾
• Context Rot：irrelevant context 越多准确率越低 → 主动剪枝比无脑塞效果好
• 延迟成本爆炸：1M token 单次请求 TTFT 十几秒，$2-3/请求

Memory 管理在 2026 依然是核心问题，不是因为 context 不够，而是因为长 context 反而更难管。

4. Prompt Caching（2026 最关键的成本工程）

Anthropic / OpenAI / Gemini 都支持把 KV Cache 在服务端持久化，后续请求 prompt 前缀完全匹配则跳过 prefill 复用——命中后延迟降 80%、成本降 90%。

实战要点：

• system prompt + 工具定义 + 长文档前缀几乎必开 cache
• Anthropic 提供 5min / 1h TTL，最多 4 个 cache breakpoints
• 不要在 cached 前缀里塞时间戳/随机 ID，会破坏 cache

自己写一个 50 行 minimal Agent

不用任何框架，直接调 Anthropic / OpenAI API：

• 手动解析 tool_use，手动拼 messages 数组
• 实现 Calculator + Web Search 两个工具
• 额外加一层 prompt caching（5 行代码，体感巨大）

这一步搞透，省掉后面 80% 的迷茫。

第二阶段：框架选型（2026 大变天）

很多老路线力推 LangGraph，但 2026 年厂商 SDK 强势崛起：

第三阶段：核心模块工程深度

1. Tool 设计（2026 升级：必学 MCP）

schema 设计原则保持不变（清楚、有示例、枚举值列全），补充 2026 三件大事：

(a) MCP 协议（2026 必学） Model Context Protocol — Anthropic 2024 年开源，2025 年被 OpenAI、Google、Cursor、Windsurf 全面采纳，已是事实标准。

• 解决 "M 个模型 × N 个工具" 集成爆炸
• 五种 primitive：Tools / Resources / Prompts / Sampling / Roots
• 截至 2026 年初社区已有数千个公开 MCP Server（GitHub、Slack、Notion、Figma、Playwright、PostgreSQL 等）
• 简历写"熟悉 MCP 协议"+"自己写过一个 MCP Server"，面试官眼睛会亮

(b) BFCL 评估 Berkeley Function-Calling Leaderboard — 2026 工具调用事实评测榜。你的 Agent 在 BFCL 跑出多少分是硬通货。

(c) 流式工具调用 Claude fine-grained tool streaming + OpenAI Responses API 都支持边推理边输出参数，延迟敏感场景必学。

2. Memory 分层

三层结构（短期 / 长期 / 系统级）经典且正确，2026 实现细节：

• 短期：messages + sliding window + 自动 summary，Claude Code 的 /compact 机制是经典实现
• 长期：向量库 + 时间衰减 + 重要性加权，Mem0 / Zep 是 2026 主流封装框架
• 系统级：RAG + Reranker + Hybrid Search（BM25 + Dense），2026 主流 Embedding 模型：Voyage 3 / Qwen3-Embedding / OpenAI text-embedding-3-large

能把这三层画出来 + 说清每层读写策略，面试已经超过大多数候选人。

3. 可观测性（2026 工具更多了）

第四阶段：做项目

学到第三阶段，很多人状态是"概念都懂能跑通 demo，一问效果就卡住"——因为没评估。

2026 最有故事性的项目方向

1. Text2SQL Agent on BIRD-SQL（Spider 已饱和，BIRD-SQL 是 2024 年新基准）
2. Code Agent on SWE-Bench Verified（Anthropic 官方人工核验子集 500 题）
3. Browser Agent on WebArena / VisualWebArena
4. Customer Service Agent on τ-bench（客服多轮工具调用）
5. GUI Agent on OSWorld（桌面操作系统任务）

简历金标准描述模板

"基于 LangGraph + Claude Agent SDK 构建了 Code Agent，在 SWE-Bench Verified 上从基线 32% 优化到 51%。主要手段： ① 改进文件搜索工具的 schema 设计 → +8pp ② 增加测试失败后的反思-修正子图 → +6pp ③ 用 prompt caching 把单任务成本从 0.6，延迟降 70%"

这种描述，面试官能顺着追问十个方向，你每个方向都有话说。

容易踩的坑（2026 版）

坑 1：Multi-Agent 不要早学

Anthropic 官方博客《Building effective agents》核心结论：单 Agent + Workflow 优先，Multi-Agent 仅在必要时引入。两个 Agent 之间的状态同步、消息传递、循环依赖，在单 Agent 没吃透前上手就是陷阱。

坑 2：不要被推理模型迷信

R1 / Extended Thinking / GPT-5 reasoning 出来后，很多人觉得"开 thinking 就更准"。事实是：

• 简单任务开 thinking 反而拖慢且更贵
• 应该按任务复杂度分级：reasoning_effort: minimal / low / medium / high
• 客服 / FAQ 用 minimal，工程任务才开 high

坑 3：不要堆框架

LangChain + LlamaIndex + AutoGen + Dify + Coze + MCP + A2A —— 简历堆这一堆，面试官会觉得你哪个都没深用过。专精 1-2 个，讲清楚为什么选它，这比堆十个值钱。

坑 4：不要绕过 Prompt Caching

2026 年成本最大的杀手不是模型贵，而是不开 cache。一个不开 cache 的 Agent 在生产环境 = 烧钱机器。这个细节面试一问就扣分。

坑 5：不要忽视 cost 数据

简历光说"准确率提升"现在不够。面试官会追问"成本是多少 / 延迟是多少"——能把 accuracy / latency / cost 三个数据同时讲清楚的，才是 2026 合格的 Agent 工程师。

一句话总结

以前学 Agent 顺序：底层 → LangGraph → 工程深度 → 项目

2026 年学 Agent 顺序：底层（含 prompt caching / MCP） → LangGraph + 厂商 SDK → 工程深度（含 MCP / BFCL） → 在 SWE-Bench / τ-bench 上能讲三维数据（精度 / 延迟 / 成本）的项目

底层机制 + 工程直觉是不会过期的资产。