Agent 学习路线：从大模型到可交付智能体的体系化路径

一、先建立心智模型：Agent 到底是什么

很多人对 Agent 的理解停留在”能聊天的 AI”，这个心智模型会导致后面所有的学习都抓不住重点。我建议用这个定义：

Agent = LLM + 工具 + 循环 + 记忆，在目标驱动下自主决策调用工具、观察结果、迭代推进，直到达成目标或耗尽资源。

拆开看四个组件各自的角色：

• LLM 是大脑：负责理解目标、规划步骤、决策下一步。它是概率性的，这是后面所有工程手段要围绕的核心特性；
• 工具（Tools）是手脚：函数调用让模型能读写文件、调 API、查数据库。工具集定义了 Agent 的能力边界；
• 循环（Loop）是生命线：感知 → 思考 → 行动 → 观察 → 再思考，这个循环把”单次生成”变成”多步任务推进”。ReAct 是这类循环的经典范式（Reasoning + Acting 交替）；
• 记忆（Memory）是状态：短期记忆是对话上下文，长期记忆是向量库/文件/数据库，解决”超出上下文窗口的知识”和”跨会话的状态延续”。

这个心智模型的价值在于：遇到任何 Agent 相关的新概念，都能挂到这四个组件上。MCP 是工具层的标准化协议，RAG 是记忆层的检索实现，Function Calling 是工具层的调用机制，多 Agent 是把单循环扩展成协作网络。

二、能力栈分层：六层递进的学习地图

第 1 层：提示词工程——不是背咒语，是学会给”大脑”写需求

很多人觉得提示词工程很简单，会聊天就行。实际上这层要掌握的是把模糊意图翻译成模型可执行指令的能力，核心技巧按优先级：

1. 给上下文而不是给形容词：“你是一个资深专家”不如”以下是项目的技术栈和编码规范”；
2. few-shot 示例：给两个正确输入输出样例，比一段描述更有效；
3. 结构化输出约束：明确要求 JSON Schema，下游代码才好接；
4. 思维链（CoT）：复杂任务要求”先列出步骤再执行”，可显著提升正确率；
5. 负面清单：明确”不要做什么”，比堆正面要求更能防止跑偏。

练习方式：同一个任务写三个版本提示词，对比产出差异，把差异原因写下来。一周就有感觉。

第 2 层：Function Calling / Tool Use——从”会说”到”会做”

工具调用是 Agent 与普通对话的分水岭。要理解的核心流程：

用户请求 → 模型返回结构化调用意图（工具名 + 参数 JSON）
        → 你的代码执行真正的函数
        → 把执行结果回传给模型
        → 模型基于结果继续生成（可能再调用下一个工具）

关键认知：模型从不真正”执行”任何东西，它只输出意图，执行永远在你的代码里。所以工具设计是一门工程手艺：

• 工具的 description 是给模型看的 API 文档，写不清模型就会用错；
• 参数设计宁少勿多，可选参数带默认值；
• 返回值要克制——返回 1000 行日志不如返回 3 行摘要 + 定位指针；
• 工具要有幂等性和错误信息自解释（模型会根据错误信息自我修正）。

练习方式：不借助任何框架，裸写一个 100 行的 tool-use 循环，做一个”能查天气 + 能查日历”的 Agent。自己动手写一遍循环，比读十篇教程都有用。

第 3 层：RAG 与记忆——知识层的扩展

上下文窗口再大也装不下企业知识库，而且塞满上下文既贵又降低准确率。RAG（检索增强生成）的标准链路：文档切分 → 向量化 → 相似度检索 → 把相关片段注入上下文。

工程重点不在向量库选型，而在检索质量：

• 切分策略（按语义边界而非固定字数）对效果的影响远大于向量模型选择；
• 混合检索（向量 + 关键词）比纯向量稳得多；
• rerank 是性价比最高的一环，加一个重排序模型通常立竿见影；
• 评估要建”金标准问答集”，没有评估集的 RAG 调优全靠感觉。

记忆层还有一个常被忽略的维度：Agent 的长期状态。多轮任务的中间产物（已完成的步骤、失败的尝试）需要外置存储（文件/数据库），否则上下文一满就”失忆”。

第 4 层：MCP 与协议——工具生态的标准化

Function Calling 解决了”单应用里模型调工具”，但每个应用都重复实现一遍工具接入。MCP（Model Context Protocol）把这一层标准化：工具提供方实现一次 MCP Server，任何支持 MCP 的客户端（如 Claude Code、各类 IDE Agent）都能用。

MCP 的三类原语值得记住：Tools（模型可调用的动作）、Resources（可读取的上下文数据）、Prompts（预置的提示词模板）。我实践里的 MCP 设计稿路由，本质就是把设计稿解析成 Resources、把组件查询和代码写入做成 Tools，让 Agent 在标准协议下拿到项目上下文。

学习建议：写一个简单的 MCP Server（比如封装你们团队的内部 API），在 Claude Code 里跑通，你对”AI 工程化的基础设施层”的理解就到位了。

第 5 层：规划与多 Agent 编排——从单兵到团队

单 Agent 循环在长任务上会暴露两个问题：上下文膨胀导致”迷失”，和单线程串行效率低。于是有了规划模式（Plan-and-Execute：先产出任务清单再逐项执行）和多 Agent 协作（拆成 Planner / Coder / Reviewer 各司其职）。

我的实践建议是慎用多 Agent：大多数场景把单 Agent 的上下文管理做好（任务清单落盘、阶段性总结压缩上下文）就够了。多 Agent 引入的通信成本、状态同步、错误传播问题，很多时候比它解决的问题还多。判断标准：如果任务能拆成清晰无歧义的子任务且子任务间低耦合，才考虑编排；否则老老实实单 Agent 加好的工具集。

第 6 层：评估（Evals）——工程化的分水岭

这是大多数人跳过、却最重要的一层。没有评估体系，Agent 开发就是”改提示词 → 感觉好一点 → 上线 → 出事”的玄学循环。最简评估体系三件套：

1. 测试集：20~50 个覆盖典型场景和边界场景的输入，以及期望行为描述；
2. 自动断言：结构化输出校验、关键事实核对、工具调用序列是否符合预期；
3. 回归习惯：每次改提示词/换模型/加工具，跑一遍测试集，杜绝”改好一处坏三处”。

有了评估，Agent 才能从”演示玩具”走向”可维护的生产系统”。我在团队推广 Skill 体系时坚持”每个 Skill 带验收标准”，本质上就是把这层评估思想下沉到了每个具体场景。

三、我的实践对照：六层如何串成一条线

以在业务团队做的 AI 开发流水线为例，六层能力栈分别落在哪：

这条线串下来的体感是：低层能力（13）决定单点效果，高层能力（46）决定系统质量。大多数人卡在第 2 层（工具设计粗糙），直接跳到第 5 层（急着上多 Agent），结果就是”demo 惊艳、生产拉胯”。

四、常见误区

误区一：把 Agent 当人看。它没有常识判断的可靠性，一个 99% 正确率的步骤连乘十步就只剩 90%。工程手段（校验、回归、人工卡点）不是可选项，是必需品。

误区二：框架先行。LangChain、各类 Agent 框架可以加速起步，但跳过裸写循环直接用框架，等于不会 SQL 直接用 ORM——出问题时完全没头绪。建议顺序：裸写 → 理解机制 → 再用框架提效。

误区三：追求全能 Agent。一个想做所有事的 Agent 意味着工具集巨大、提示词臃肿、行为不可预测。窄而深（工具 10 个以内、场景边界清晰）的 Agent 几乎总是比宽而浅的靠谱。

误区四：忽视成本与延迟。多步循环 = 多次 LLM 调用，token 成本和响应时间线性叠加。生产 Agent 必须做成本预算（max steps、上下文裁剪策略），demo 思维直接上线会烧钱。

五、给工程师的 90 天学习计划

按每周 5~8 小时的投入，一个可执行的计划：

• 第 1~2 周：提示词工程。把日常工作里三个真实任务改造成结构化提示词，对比效果差异；
• 第 3~4 周：裸写 tool-use 循环（不借助框架），做一个能操作文件系统的小 Agent，重点体会”意图→执行→观察”循环；
• 第 5~6 周：RAG。用自己博客/笔记做知识库，重点打磨切分与 rerank，建立小型评估集；
• 第 7~8 周：MCP。写一个封装内部 API 或常用工具的 MCP Server，接入 Claude Code 日常使用；
• 第 9~10 周：规划模式。给自己的 Agent 加任务清单落盘与上下文压缩，跑通一个 20 步以上的长任务；
• 第 11~12 周：评估与生产化。给前面的 Agent 补测试集与自动断言，加成本预算，然后找一个真实业务场景落地。

学完这条线，你对 Agent 的理解会从”概念”变成”工程”，也自然能判断哪些场景值得上 Agent、哪些是伪需求——这个判断力，比任何单个技术点都值钱。

六、写在最后

Agent 技术还在快速演化，今天的最优实践半年后可能被模型能力的跃升直接淘汰。但有几样东西不会过时：对概率性系统的工程化思维（校验、评估、兜底）、工具与上下文的设计能力、把业务场景拆解成可验证范式的能力。模型越强，这些”给强模型搭梯子”的工程手艺反而越值钱——这也是我从写业务代码转向 AI 工程化方向的原因：执行在贬值，组织执行的架构在升值。