如果你已经读过之前的版本，不需要从头再看一遍。先展开下面的更新日志，就能快速了解这次改了什么，以及哪些章节值得重新读。
版本更新日志（当前 v1.2）
v1.2 — 2026-07-25
- 第五章从六件内功扩到八件，并新增一个架构判断：新增“5.5 安全”，把原本散在 1.4、2.3、5.3 的安全内容收拢成完整一节；新增“5.7 观测与调试”，讲清 trace / trajectory / transcript 是同一件事、一条执行记录该留什么，以及它和 Eval 的分工；新增“5.9 多 Agent”，补上第四章承诺了面试会考、正文却没讲的部分。
- 第五章小节重新编号（原 5.5 成本控制 → 5.6，原 5.6 Eval → 5.8，原 5.7 总结 → 5.10），总结改为按“做对 / 扛得住 / 可判断”分组。
- 1.3“Agent 开发 = 做 Harness”补上实证：Databricks 千万行代码库评测显示，同一模型换一个 harness，部分任务的单次成本相差超过 2 倍而质量基本一致。
- 4.5 新增“读真实代码理解 Agent Loop”一条：Pi（极简内核 + 插件扩展）与 Hugging Face 的 Tau（Python 教学向重写）。
- 5.6 补上 Pi 团队的 prefix cache 复盘：什么会让缓存悄悄失效，以及“上下文剪枝”和缓存之间的取舍。
- 5.8 补上 LLM-as-Judge 的自家模型偏好问题，以及 judge 要交叉评、并和干活的模型分开固定参数。
- 全文精简加粗高亮（377 → 308 处），去掉链接上的加粗、列表项内的二次强调和并列枚举，使每段最多保留一处高亮。
- 阅读时间随篇幅更新为约 60–65 分钟（全文约 1.85 万中文字）。
v1.1 — 2026-07-13
- 内容和来源更新至 2026 年 7 月：模型格局（Claude 5 家族、GPT-5.6、Gemini 3.5 Flash / 3.1 Pro、Qwen3.7、K2.7、GLM-5.2、MiniMax M3）、框架生态（AI SDK 7、LangChain 1.0、Microsoft Agent Framework）、MCP 捐入 Agentic AI Foundation、Skills 开放标准与供应链风险；对第三方行业统计明确标注口径。
- 修正安全边界、Skills 渐进式披露、开源协议、MiniMax 多模态、缓存折扣和若干时间线等表述。
- 第一章重写：明确“大脑 = 模型本身、Agent 开发 = 做 Harness”，并加入包含失败处理、tool search 和执行层安全的 Coding Agent 示例。
- 新增官方 Agent SDK、Cloudflare Agents SDK / eve、Eino，以及 Skills 供应链风险。
- 第四章重写为“用 → 懂 → 造”三级跳，增加边界感、工程级代码实践、项目对照组和每一跳的验收标准。
- 付费服务移出正文，改为独立折叠附件；移除“技术栈图谱”和原 2.5“应用层”小节。
- 阅读时间改为中文 350 字/分钟、英文 200 词/分钟分别计算，并排除付费服务与更新日志附件；本篇由错误的 91 分钟修正为约 50 分钟。
- 重写结尾，增加 Agent 交流群、B 站线上自习室和 GitHub 反馈入口；更新日志改为折叠附件。
v1.0 — 2026-05-17
首次发布。查看原文存档。
开篇｜在你读下去之前#
这份文档是写给谁的#
如果你最近的状态是这样的——身边的人在聊 Agent、聊 MCP、聊 Vibe Coding，你看到一堆陌生的名词在飘，大概知道这是一个值得入门的方向，但每次想动手就被劝退，要么不知道从哪个名词开始查，要么打开”30 天速成”的教程看到第三页就关掉——那这份文档就是给你写的。
我把读者大致分两类，这份材料对两类都有用：
- 完全没有编程或者完全没有 LLM 背景的人：你需要的是一张”地图”，告诉你这个领域全貌长什么样、从哪里开始走。
- 有一些编程基础但还没真正接触过 LLM 应用的人：你需要一份”对照表”，把你已经会的东西和这个新方向之间的桥搭起来。
读完这份文档你应该能：
- 用三句话解释清楚什么是 Agent、它和普通 LLM 应用的区别；
- 知道接下来 1–2 个月按什么顺序学什么内容；
- 听到那些行话时不再发懵；
- 不再焦虑——知道这条路有方向、可以走，现在出发并不晚。
同样要说清楚：读完它你还不会写 Agent。 这份文档给你的是地图，会走路只能来自你按第四章的路线动手——地图的价值是让你少走弯路，不是替你走。第四章给每一步都写了”验收标准”，用它检验自己有没有真的在走。
阅读时间预估：全文约 1.85 万中文字，并夹有较多英文技术名词。按中文 350 字/分钟、英文 200 词/分钟分别估算，连贯读完约 60–65 分钟；如果你边读边查、边想边停，实际约 2–2.5 小时。
这份文档不是什么#
为了让你的预期对齐到位，也说清楚这份材料不是什么：
- 不是代码教程——不会有大段 Python / TypeScript 代码。
- 不是框架手册——不会逐条讲 LangChain / Vercel AI SDK 的 API。
- 不是论文综述——不会推 Transformer 公式、不会带你读论文。
如果上面这三件事是你来找的，这份材料不适合你，建议直接读一线大厂的官方文档。如果你需要的是”先帮我搞清楚我在面对一个什么样的领域”——你来对地方了。
关于作者#
我叫 Joye，墨尔本大学计算与软件工程在读，目前在上海一家独角兽公司做 Agent 全栈开发实习，日常就是这份文档里写的那些东西：Harness、上下文工程、工具调用、Eval。
2025 年底到 2026 年初，我密集面过 100+ 家 AI 公司的 Agent 相关岗位，拿到了 30+ 个 offer。这段经历是这份文档的来源，也沉淀成了它的两篇”前传”：
- 《一个大二实习生的 Agent 开发面试修炼手册》 ↗（2026 年 3 月）——我自己求职过程的完整复盘。这篇是我开始接咨询的起点。
- 《一场 1 小时 19 分钟的 Agent 工程师模拟面试，我们到底聊了什么》 ↗（2026 年 5 月）——和另一位面试官 W 一起做的 80 分钟有偿模拟面试的全程复盘。有读者按里面的方法重新深挖项目之后，拿到了大厂 offer。
入职之后我一直在持续输出：
- 《从实习面试到 Agent 开发：名词换得比模型还快，我为什么不焦虑》 ↗（2026 年 6 月）——Prompt → Context → Harness → Loop，一年四拨名词接力背后不变的是什么。这份指南第三章的很多判断，在那篇里有更完整的展开。
- 定期在粉丝群做 AI 技术分享（Talks 系列 ↗），聊每两周的 Agent 新动向，讲稿和视频都会公开。
开源项目（GitHub @joyehuang ↗）：
- minimind-notes ↗（140+ Stars）：从零构建 LLM 的详细注解教程。
- Learn-Open-Harness ↗：OpenHarness 零基础交互式教程，带你读懂真实 Agent Harness 的实现。
- skills ↗：基于 Anthropic Skills 范式的个人 Skill 集合。
我不是行业里资历最深的人，但我刚刚走完你正要走的这条路——这种”刚走过”的视角，有时候比”走得很远”的视角更适合做带路人。
怎么使用这份文档#
我建议你第一遍按顺序通读，建立整体轮廓感。读完之后回到你最有共鸣的章节细读第二遍。
阅读时配合实际动手——每读完一章，找一个最让你有感觉的点，去搜一下相关的开源项目、看一段官方文档、或者直接打开一个 LLM 让它给你解释一下。只读不动手是这个领域最大的坑。
如果你看完觉得有帮助，欢迎在小红书 / X 上转发给同样在准备的朋友。这份文档会定期更新（预计每 3–6 个月一版），后续版本也会继续免费。
我们开始。
第一章｜认识 AI Agent#
在你能”开发 Agent”之前，先要能”看懂 Agent”。这一章帮你三句话讲清楚 Agent 是什么、它和已经知道的那些东西（ChatGPT、API、聊天机器人）的区别在哪。
1.1 一个不严谨但好理解的定义#
如果说大语言模型（LLM）是一颗”大脑”，那么 Agent 就是这颗大脑加上了眼睛、手、记忆，以及一个能让它自己循环工作的身体。
更严谨一点的说法：Agent 是一个以 LLM 为决策核心、能够感知环境、调用工具，并通过循环完成多步任务的系统；很多 Agent 还会维护任务状态或跨会话记忆。关键词四个：LLM、工具、状态 / 记忆、循环（“感知”并入工具——环境信息本来就是通过工具进来的）。
1.2 Agent 不是什么：三个常见误解#
误解一：Agent ≠ 聊天机器人。 聊天机器人的核心是”对话”；Agent 的核心是”完成任务”——对话只是它接收任务的一种方式。
误解二：Agent ≠ 单次 LLM API 调用。 单轮调用是”输入 → 输出”——没有循环、没有工具、没有状态；这几样凑齐（至少是”循环 + 工具”）才谈得上 Agent。
误解三：Agent ≠ 一个用 LLM 包装的表单 App。 把 LLM 塞进一个用户填表单的产品里——和”加了 LLM 的搜索框”没本质区别。真正的 Agent 应该让模型有”自己决定下一步做什么”的空间，而不是按人类预设流程走完一遍。不过这里要马上补一句：“自主程度”是一个旋钮，不是资格考试。 真实生产系统里最常见的形态，是确定性工作流做主干、LLM 只在分类、规划、选工具这些节点上做局部决策——很多可靠的 Agent，恰恰是故意调低模型自由度换来的。别把”全自主循环”当成正统、把工作流当成伪 Agent，那会诱导你一上来就造不可控的循环。
需要补充一点：2022–2023 年的早期 ChatGPT 已经能进行多轮对话，但主要仍停留在文本交互，缺少今天成熟的联网搜索、代码执行、文件读写和任务循环。到了 2025–2026 年，主流 ChatGPT、Claude、Gemini 网页端已经把不少 Agent 化能力内置进了产品。但这是”厂商在产品层把 Agent 能力打包好给用户用了”，而不是”LLM 本身变成了 Agent”。 底层模型仍然是那颗大脑，能动手是因为外面套了一整套 Agent 工程——而你要学的，就是这一整套工程。
1.3 Agent 的四件套#
把这四件套串起来，你就建立了理解 Agent 工程的基本框架。它们是便于入门的典型组件，不是判断一个系统”算不算 Agent”的硬性清单。
大脑（LLM）：就是模型本身。思考和决策，接收当前状态，输出下一步动作（回答用户 / 调用工具）。这里有一个值得尽早建立的视角：模型是四件套里唯一一件你不用（也没法）自己做的——所以 Agent 开发，做的其实是”模型以外的一切”。业内把这套外围工程统称为 Harness：记忆、工具、循环、上下文管理、可靠性兜底，全是 Harness 的一部分。我的开源教程 Learn-Open-Harness ↗ 拆的就是一个真实 Harness 的实现。
这不只是一种说法，它有实测支撑。 Databricks 在 2026 年 7 月公布了一次内部评测——在自己的千万行代码库上，同一个模型、同样的思考强度，只是换一个 harness，部分任务的单次成本相差超过 2 倍 ↗，而完成质量基本一致；差别来自各家管理上下文的方式不同，其中一个每轮发送的上下文只有另一个的约三分之一。同一颗大脑，Harness 决定了它被用得好不好。 这也正是”Agent 开发”值得成为一个独立方向的原因。
记忆（Memory）：先按两层建立直觉——短期记忆是当前任务的上下文（用户刚说了什么、刚调了什么工具）；长期记忆是跨会话的持久信息（用户偏好、关键事实）。工程实现里其实再细分为 Working / Short-term / Long-term 三层，第五章会展开。
手（Tools / Function Calling / MCP）：Agent 与外部世界交互的接口——搜索引擎、代码执行、邮件 API、数据库查询都是工具。主流 LLM 厂商都提供原生的 Function Calling 能力；第三方工具的标准化接入方式是 MCP（第二章会讲）。
循环（Agent Loop）：感知 → 思考 → 行动 → 感知 → ... 最经典的实现叫 ReAct ↗（Reason + Act）。终止条件通常是：模型自己判断完成 / 达到最大步数 / 用户中断。
1.4 一个最小 Agent 工作流：以 Coding Agent 为例#
你对一个 Coding Agent 说：“把项目里所有旧的 logV1() 调用换成 logV2()，跑通测试。“它内部大致这样跑：
第一轮：思考”先找到所有调用点” → 调用 grep("logV1(") → 12 个文件、37 处调用。
第二轮：思考”逐个文件替换” → 调用 edit_file(...) 批量修改 → 其中一处替换失败（有人手写了带空格的变体 logV1 (，和预期字符串对不上）→ 模型读到失败信息，换更宽松的匹配方式重试，成功。
第三轮：思考”改完了，跑测试确认” → 当前上下文里没有现成的测试工具 → 调用 tool_search("run tests")，从工具库里按需加载出 run_tests → 执行。
第四轮：测试挂了 3 个 → 模型读报错，发现 logV2() 的参数顺序和 v1 不一样 → 回去重新修正那几处调用 → 再跑测试 → 全绿。
第五轮：思考”任务完成” → 向用户汇报：改了哪些文件、中途踩了什么坑、测试结果。
注意五个关键点：
- 下一步动作主要由模型动态选择——在运行时允许的边界内，它判断要不要调工具、调哪个、是否重试以及何时完成；权限、审批、最大步数和停止规则仍由系统控制。这种”局部动态决策”是 Agent 和完全硬编码工作流的重要区别。
- 工具执行不是模型在做——模型只是输出”我想调这个工具”，真正执行是你程序的工作。这也是安全边界所在：
edit_file是有真实副作用的（真的在改用户的代码），所以真实的 Coding Agent 会在执行层做保护——在独立分支或沙箱里改、危险操作要用户确认，而不是指望模型自觉（第五章会展开）。 - 失败是主路径，不是异常路径——第二轮的替换失败、第四轮的测试失败，在真实运行里是常态。Agent 的核心能力之一就是”读到失败信息 → 调整 → 重试”；一个只演示”一路成功”的 Demo 和生产级 Agent 之间，差的就是这些。
- 工具不是全量塞给模型的——第三轮的
tool_search是”搜索工具的工具”：工具库可以有上百个工具，模型平时只看到核心几个，需要时按需加载（第二章讲 Skills 时会再遇到这个思路）。 - 记忆贯穿了整个流程——第四轮修 bug 时，模型还记得最初任务是”v1 换 v2”，也记得第一轮找到的那 37 处调用点。
1.5 本章一句话#
Agent = 一个 LLM 在一个循环里，反复地”想一下、做一下”，直到任务完成。
第二章｜Agent 生态地图#
这一章是给那些”看招聘 JD 看到一半就要去查 10 个名词”的人写的。我们不深挖每个概念，但把这个领域的术语地图铺平，让你看完之后再看任何一份 JD、博客、开源项目的 README，都知道每个名词大致在说什么。
整个 Agent 技术栈分五层。先声明：这个五层划分是帮助记忆的地图，不是严谨的架构分层——MCP 和 Skills 其实不是同一类东西，框架和 Runtime 的边界也在互相渗透。地图的作用是让你听到一个名词时知道它大概在哪一格，不是让你把格子当教条。我们从下往上看。
2.1 模型层：选哪颗大脑#
截至 2026 年 7 月，模型格局已经分化为两个区域池：海外闭源三巨头 + 国内开源五家。（提醒：版本号和跑分是这份文档里最易过期的内容，永远以厂商官网为准；但各家的定位变化要慢得多——优先记定位。）
海外三大闭源模型：
- Claude（Anthropic）：在 Coding Agent、工具调用和长任务场景中口碑较好。旗舰线已进入 Claude 5 时代——Fable 5 是当前能力最高的公开型号之一，Sonnet 5 是面向日常开发的主力选择（上一代 Opus 4.8 仍在服役），这些型号支持 1M token 上下文。仓库级 Coding Agent 和长程任务值得优先实测 Claude，但仍要以自己的 Eval 为准。
- GPT（OpenAI）：也是 Agent 模型的主要选择。旗舰 GPT-5.6 家族（2026 年 7 月发布）分 Sol / Terra / Luna 三档：OpenAI 公布的结果中，Sol 在 Terminal-Bench 2.1 达到当时最高分，第三方综合指数上与 Fable 5 相差不到一分；Terra / Luna 按能力和价格分级，适合承接任务路由里的中低档调用。跨模型成绩仍要注意 harness、推理预算和发布时间是否一致。
- Gemini（Google）：多模态是它最鲜明的优势之一，公开可用的 Gemini 3.5 Flash ↗ 覆盖文本、图像、视频和音频等输入；当前公开的 Pro 旗舰仍是 Gemini 3.1 Pro Preview ↗，上下文窗口为 1M token。做多模态 Agent 时值得优先评估。
国内开源 / 半开源五家（按梯队和差异化）：
- Qwen（阿里通义千问）：背靠阿里云生态，旗舰已迭代到 Qwen3.7 系列；Qwen3.7-Plus ↗ 支持文本、图像和视频输入并输出文本。开源的 Qwen3.6-35B-A3B（Apache 2.0）只有约 3B 激活参数，量化后可以在部分消费级显卡上运行，实际显存需求取决于量化精度和上下文长度。
- DeepSeek：性价比是它最鲜明的优势之一。V4 系列 ↗ 以 MIT 协议开源，提供 1M 上下文；API 价格明显低于多数海外旗舰模型，但具体比例取决于 Pro / Flash、缓存命中和比较对象。如果所在地区可用，入门调 API 时值得优先比较。
- Kimi（月之暗面）：K2.6 在官方公布的 SWE-Bench Pro 结果中表现较强，最新的 K2.7-Code ↗ 是编程专项模型。是否适合具体代码仓库，仍应在相同 harness 下比较。
- GLM（智谱）：GLM-5.2 ↗ 以 MIT 协议开源，支持 1M 上下文，并重点优化长程 Agent 与代码任务。它适合纳入私有化部署和研究场景的候选列表；具体基准名次要同时看评测日期、harness 和推理预算。
- MiniMax：M3 ↗ 的差异化能力包括图像、视频理解，以及 MoE 架构带来的推理效率（约 428B 总参数、23B 激活参数）。实际成本还取决于部署方式、上下文和硬件利用率。
关于选型的三条真实建议：
- 不是越大越好，按任务分级使用——简单意图识别、路由用便宜小模型；复杂代码生成、推理才用旗舰。这是控制成本的关键技巧。
- 大部分国内模型都提供 OpenAI 兼容 API 端点——基础文本调用通常改
base_url和模型名就能迁移；工具调用、结构化输出、流式事件和多模态参数仍可能有厂商差异。 - 不要无条件押宝单一模型——如果业务对可用性、成本或能力覆盖要求较高，可以接入多家并按任务路由；小项目则没必要一开始就增加这种复杂度。
2.2 框架层：用什么搭脚手架#
主流选择分两类：官方 SDK 和 第三方框架。
官方 SDK：
- OpenAI SDK：最古老、最稳定。默认面向 OpenAI 自家模型——但因为它的接口协议是事实标准，DeepSeek / Qwen / Kimi / GLM 这些国内模型都可以通过改
base_url用它调。 - Anthropic SDK：Claude 官方 SDK，Tool Use、Computer Use 这些原生能力都用它接最顺。
- Google Gen AI SDK：Gemini 官方 SDK，多模态接入最直接。
第三方框架（按推荐度排序）：
Vercel AI SDK ↗（我个人最推荐的入门选择）：
- 跨模型提供统一接口——
import { anthropic } from '@ai-sdk/anthropic'用 Claude，换成 OpenAI / Google / DeepSeek 通常只需替换 provider 和模型配置；但厂商专属参数与能力仍需分别处理。 - 它以 SDK 而非重框架的姿态存在——既提供”流式输出""工具调用""结构化输出”这些原语，也提供
ToolLoopAgent等预置 Agent Loop。你可以直接使用默认循环，也可以下沉到原语层自己控制编排，这种自由度对理解 Agent 工作机制很友好。 - 当前稳定版是 AI SDK 7 ↗，新增工具审批（human-in-the-loop）、持久化执行、harness adapters 和可观测性等生产能力。
- TypeScript / Next.js 生态尤其顺。
- 同门还有一个新物种值得知道：Vercel 在 2026 年 6 月发布了开源 Agent 框架 eve ↗——“一个 Agent 就是一个目录”，指令、Skills、工具、渠道、日程全是目录里的文件，自带持久化执行（会话可以断点续跑、扛住崩溃和重新部署）和沙箱。一句话区分：AI SDK 给你搭 Agent 的原语，eve 直接给你一个完整的 Agent 形态。
LangChain / LangGraph：最老牌、生态最大、文档最丰富。1.0（2025 年 10 月）之前长期被吐槽”抽象太重”，1.0 把核心收敛成了 create_agent + middleware，风评有所回升。但除非你的项目特别需要 LangChain 的现成组件（200+ 文档加载器、LangSmith 评估），仍然不建议作为第一站。
CrewAI / Microsoft Agent Framework ↗ / Mastra：分别针对多 Agent 协作、企业级编排（前身是 AutoGen + Semantic Kernel，两者已合并于此，AutoGen 本身进入维护模式）、TypeScript 全栈，有具体场景再选。
Eino ↗（字节 CloudWeGo）：Go 生态中较活跃的 Agent 框架之一，提供类似 LangChain 的编排能力和 ADK（Agent 开发套件）。如果你的技术栈是 Go 后端，或者目标是字节系岗位，值得认识它。
2026 年还要认识两类新物种：
- 官方 Agent SDK：三大厂都把”完整的 Agent 循环”直接做成了 SDK——Claude Agent SDK ↗（从 Claude Code 演化而来，“给 Agent 一台电脑”的范式，自带文件系统和终端工具）、OpenAI Agents SDK ↗、Google ADK ↗。它们和上面的”官方模型 SDK”的区别：模型 SDK 给你的是”调一次模型”，Agent SDK 给你的是”一个开箱能跑的 Agent harness”。
- Agent Runtime：Cloudflare Agents SDK ↗ 值得单独点名。它建立在 Durable Objects 之上，每个 Agent 实例是一个自带 SQLite 状态、WebSocket 连接和定时调度的”持久微服务器”——状态在重启、部署、崩溃之后依然存在（durable），实例闲置时不花钱。它解决的不是”怎么写 Agent Loop”，而是”长时间运行的 stateful Agent 跑在哪、怎么活下来”。研究它的时候我记下了一句话：用确定性的基础设施，包住非确定性的模型——这也是第五章”可靠性”一节的核心思想。我个人认为这种 durable、stateful 的 Agent Runtime 是接下来最值得关注的方向之一：Agent 正在从”一次性的请求”变成”长期在线的服务”，runtime 层的重要性只会越来越高。
给入门者的建议：第一个 Agent 建议直接用 Vercel AI SDK 或者厂商官方 SDK——它们的抽象足够轻，不会挡住你看清”Agent Loop 到底在做什么”。不要为了”学框架”而学框架——框架本身不是简历资产，“我用某个框架做了什么有价值的事”才是。
2.3 协议层：MCP 与 Skills#
MCP ↗（Model Context Protocol，模型上下文协议） 是 Anthropic 2024 年底推出的开放协议，让”LLM 应用”和”工具/数据源”之间有了标准化的对话方式。
类比一下——以前每个 Agent 想接一个新工具都得自己写适配代码；MCP 就像 Agent 领域的”USB 标准”。Anthropic、OpenAI、Cursor、Cline、Claude Code 都已经支持 MCP——它已经成为事实标准。而且这个”事实标准”已经有了制度背书：2025 年 12 月 Anthropic 把 MCP 捐给了 Linux 基金会旗下新成立的 Agentic AI Foundation ↗（由 Anthropic、OpenAI、Block 共同发起，OpenAI 同时捐出了 AGENTS.md）。
入门建议是先用别人写好的 MCP Server（官方公开列表 ↗），把 Notion / GitHub / Slack 这些工具直接接到你的 Agent 上。
Skills 是同样需要重点理解的概念。 它是 Anthropic 在 2025 年 10 月正式推出、随后迅速被业界跟进的产品形态——把一个”打包好的、可复用的 Agent 能力模块”作为一等公民。
要理解 Skills，先看一个工程现实：一个真正能用的 Agent，往往不只是”模型 + 几个工具”，它还需要——一组专门的工具（生成 PPT 需要 pptx 库）、一份精心调过的 Prompt 指导（什么时候用什么、有哪些坑）、一些示例和参考资料（让模型知道”好的输出长什么样”）、有时候还需要特定的代码片段。
如果这些散落在 Prompt、工具描述、代码注释里，会发生两件事：模型不知道什么时候该用什么；这些能力没法被复用、分发、版本化。
Skills 把这套”能力包”变成一个可独立存在、可加载、可分享的产品形态。 一个 Skill 通常是一个文件夹，里面有 SKILL.md（描述这个 Skill 做什么、什么时候触发）+ 相关脚本、工具、参考资料。Agent 在需要的时候自动加载对应的 Skill。
几个关键直觉：
- Skills 是给 Agent 用的”使用说明书”，不是给人看的文档——语言是写给模型读的。
- Skills 的核心机制是渐进式披露（progressive disclosure）：平时模型只看到每个 Skill 的一行简介，匹配到场景才把 SKILL.md 正文、脚本、参考资料加载进上下文——50 份”说明书”不会一次性把上下文撑爆。至于”工具太多模型选不对”这个相邻问题，业界的答案是配套的 tool search：工具不全量注册，模型通过一个”搜索工具的工具”按需把要用的工具调进来。两者经常配合出现。
- Skills 和 MCP 互补：MCP 解决”工具如何被调用”（接口标准化）；Skills 解决”工具如何被组织和触发”（能力打包）。一个 Skill 内部可以调用多个 MCP Server。
如果你看过 Anthropic 官方的 Skills 仓库 ↗，会发现它已经把”创建 docx""创建 pptx""创建 xlsx""填 PDF 表单”这些常用能力都做成了 Skills——Claude.ai 的”Create Files”功能背后就是这些 Skills 在跑。2025 年 12 月，Agent Skills 被发布为开放标准，随后 VS Code、Cursor、Gemini CLI、JetBrains 等工具陆续支持兼容的 SKILL.md 形式。分发生态也开始出现——Vercel 上线了技能市场 skills.sh ↗，社区还有 ClawHub 等注册表；安装体验越来越简单，但兼容程度、审核机制和运行权限并不完全一致。
但正因为传播性太强，必须讲清楚 Skills 现在的边界：质量和安全还远远跟不上。 Skill 的本质是”让模型照做的指令 + 可执行的脚本”，而发布门槛低到一个 SKILL.md 加一个 GitHub 账号。2026 年 2 月的 ClawHub 投毒事件是教科书级案例：安全研究者在公开技能市场里发现数百个恶意 Skill，用伪装成”安装步骤”的指令诱导 Agent 执行命令、安装窃取凭证的恶意软件；Snyk 随后对 ClawHub 和 skills.sh 上近 4000 个公开 Skill 做了首次全面审计 ↗——约三分之一存在安全缺陷，13.4% 至少有一个 critical-level 问题。所以装第三方 Skill 请拿出装 npm 包的供应链警惕：看来源和作者、通读 SKILL.md 正文、附带脚本先审后跑。这也再次印证第五章会讲的原则——安全边界要做在执行层（沙箱、权限白名单），不能指望模型自己识别恶意指令。
三者的关系：
- Function Calling / Tool Use 其实指的是同一回事——OpenAI 叫 Function Calling，Anthropic 叫 Tool Use，本质都是”LLM 能不能输出’我想调这个工具’的指令”这个底层能力。
- Skill 是另一层抽象——把一组工具 + Prompt 指导 + 参考资料打包成一个可复用、可加载的能力模块。
2.4 数据层：RAG、Memory、LLM Wiki#
这一层在 2026 年变化最快——传统 RAG 范式正在被几种新形态部分替代。
RAG（Retrieval-Augmented Generation） ↗ 在 2020 年被系统提出，并在 2023–2024 年随着 LLM 应用爆发成为主流工程范式。它的核心不是某一种数据库，而是在生成前检索外部信息作为依据；检索可以用向量、关键词、SQL、知识图谱，也可以混合使用。Milvus、ChromaDB、Pinecone、pgvector、sqlite-vec 都是常见的向量检索组件。
但 RAG 在 2026 年的角色正在变化——这件事需要展开讲。
RAG 在 2023–2024 年进入应用高峰时，主流模型的上下文窗口大多只有 4K–32K tokens，长文档放不进去，“切片 + 检索 + 拼回 prompt”往往是必要方案。今天 Claude 5 家族、Gemini 3.1 Pro Preview、DeepSeek V4、GLM-5.2 等模型已经支持 1M 级上下文——对于语料规模适中、更新不频繁、查询范围较集中的场景，先尝试长上下文或结构化整理，可能比一开始就搭复杂 RAG 管道更简单。 但”放得下”不等于”一定找得准”，长上下文仍有成本、延迟和注意力衰减问题。
Karpathy 在 2026 年 4 月提出了一个值得尝试的思路——LLM Wiki ↗：对个人/小团队的中等规模知识库，让 LLM 把原始资料增量整理并持续维护成互相链接的 Markdown”维基”，查询时按需读取相关页面。它减少了碎片切片和黑盒召回带来的调试困难，也容易利用 Prefix Cache；但生成出来的 Wiki 是二次整理层，原始资料仍应保留为可追溯的事实来源。
但 RAG 没死。 以下情况通常更值得优先评估检索方案：
- 语料规模很大或更新频繁——不适合每次把全部内容放入上下文。
- 查询高度局部，且要求精确引用和证据回溯——需要知道答案来自哪一段原文。
- 延迟和 Token 成本敏感——只取相关片段可能比反复发送长上下文更经济。
- 权限粒度细——检索层可以先按用户权限过滤，再把允许看到的结果交给模型。
数据隐私和多租户本身并不决定是否使用 RAG：长上下文、LLM Wiki 和 RAG 都可以本地部署，也都必须单独做好身份、权限和数据隔离。简单说：先按语料规模、更新频率、引用要求、权限粒度、延迟和成本选方案，而不是按”个人 / toB”一刀切。
Memory（记忆系统） 和 RAG 有重叠但不同——Memory 更强调”对当前用户/会话的个性化记忆”（用户偏好、对话摘要、关键事实），通常分三层：Working / Short-term / Long-term。第五章会专门讲。
Agentic Retrieval / Agentic Memory 是 2025–2026 年的新趋势：传统 RAG 常被实现成固定的”先检索再生成”管道，Agentic 模式则让 Agent 决定要不要检索、检索什么、结果是否需要提炼或继续搜索。这种”主动检索”更像是在复杂任务上扩展传统 RAG，而不是把检索本身替换掉。
第三章｜怎么看这个方向：趋势、心态与避雷#
这一章不讲技术。讲三件事：为什么 Agent 是当下最值得入门的方向、为什么你不需要焦虑、以及怎么避开那些看上去很美但其实是坑的机会。
3.1 “晚不晚”是一个伪命题#
咨询中我被问得最多的一个问题是：“Joye，我现在才开始学是不是太晚了？”
我的标准回答是：这条赛道上”老人”也才两三年经验。
简单梳理时间线：
- 2022 年 11 月 ChatGPT 发布
- 2023 年初 AutoGPT 等开源项目兴起，“Agent”开始被广泛讨论
- 2023 年 6 月 OpenAI 推出 Function Calling，Agent 工程化进入新阶段
- 2024 年 Cursor 进入商业化爆发期，Devin 发布引爆”AI 程序员”讨论
- 2024 年底 Anthropic 推出 MCP，Agent 协议层开始成形
- 2025 年 Manus、Claude Code 等 Agent 产品集中爆发
- 2025 年底 MCP 捐入 Linux 基金会（Agentic AI Foundation）、Agent Skills 成为开放标准——协议与能力打包层进入标准化加速期
- 2025–2026 年 Skills 体系、Agentic Search、Agentic Memory 等新范式快速演进
也就是说——目前行业里所谓的”资深 Agent 工程师”，从入行到现在最多两到三年。 这意味着你今天开始入门，三年后你也是”老人”。和传统开发领域那些有十年、二十年经验的方向比，这是一个真正可以靠学习速度追赶上来的方向。
3.2 为什么是现在：三个判断#
判断一：Agent 正在从”Demo 期”走向”生产期”。
2023–2024 上半年，行业里大量 Agent 项目停留在 Demo 阶段。从 2024 年下半年开始，可靠性、可观测性、Eval 体系、成本控制这些”工业级”问题被认真对待——这是一个工程师真正能发挥价值的阶段。
判断二：基础设施层的标准化窗口期。
MCP、Skills、AI Gateway 这些基础设施层的标准还在快速成形。这意味着如果你现在入场，有机会真正参与到一个新行业基础设施的建设里——这种窗口期在传统开发领域非常稀缺。
判断三：人才需求正在系统性增长。
2026 年开始，国内头部大厂在日常实习、暑期实习、秋招里都开始系统性地开 Agent 工程师/大模型应用工程师岗——这在两年前还是凤毛麟角的事。
更直观的信号来自 Y Combinator。一份基于公开公司描述的第三方批次分析 ↗把 W26 约 194 家公司中的 41.5% 归为 Agent 基础设施——身份验证、测试、安全、可观测性、上下文管理、计费这些 Agent 周边的”卖铲子”生意。这个数字不是 YC 官方分类，边界也取决于分析者如何定义”Agent 基础设施”，更适合当作趋势信号而不是精确行业统计。E2B 的官方复盘 ↗则提到，近期部分 YC 批次中接近一半的公司可以被视为 AI Agent 公司。它们共同说明 Agent 已经从独立产品类别渗透进许多垂直业务；至于岗位数量和持续时间，还要结合真实招聘数据继续观察。
3.3 你不需要焦虑的几个理由#
第一，行业没有”绝对权威”。 传统计算机科学有那种”我看过他的论文""我读过他的书”的权威专家。Agent 这个方向太新，没有这种人物。OpenAI、Anthropic 的最佳实践都是工程师在边做边写——他们和你的差距是”实践积累”，不是”天赋差距”。
第二，公开学习资料比过去丰富得多。 OpenAI 和 Anthropic 把关于 Prompt 工程、Agent 设计、Skills 体系的许多最佳实践直接发在公司博客上，任何人都能读到。公开资料足以帮助你入门，但生产数据、内部评测和真实故障经验仍然构成明显的信息差——最终还是要靠项目实践补齐。
第三，工具门槛的”简单部分”在下降，但”深的部分”在上升。 这一点需要分两半讲。
往简单方向看：过去如果要私有部署模型，通常需要 GPU 和机器学习基础设施；而商业 LLM API 早在 2020 年就已出现，今天的 SDK、文档和 Coding Agent 又进一步降低了接入门槛。Vibe Coding 也让”做一个个人网站""做一个简单 ChatBot”容易了很多。
但这恰好意味着——当造一个”没有壁垒的 Agent 项目”变得很简单时，没有壁垒的项目本身就不值钱了。 你在 GitHub 上能找到一千个”AI 健康助手""AI 客服 Bot”，因为每个人都能用 Vibe Coding 在一个周末造一个。这些项目放在简历上，面试官扫一眼就知道含金量。
真正的入门门槛被推到了更深的位置：你能不能选一个真实存在的、不是用现成 ChatGPT 就能解决的问题做项目？你能不能在工程层面做出像样的取舍？你能不能讲清楚每一个技术选型”为什么是它”？
简单说：这不是”门槛下降”，而是”门槛从代码能力转移到思考深度”。
第四，对手不是别人，是去年没动手的你自己。 Agent 领域真正拉开差距的，不只是知识储备，还有”动手量”。读很多博客也替代不了自己写一个能跑的小 Agent；只要持续动手，你就会比停留在收藏和围观阶段更快建立真实的边界感。
3.4 六个常见误区#
这六个误区是我接咨询时遇到最频繁的，逐条破除——
误区一：“我数学不好，搞不了 AI。” 你想做的是 AI 应用，不是 AI 算法。应用层的工程实践基本用不到数学。
误区二：“要先把 LLM 原理学完才能学 Agent。” 不必。应用层和底层算法是两条相对独立的赛道。先做应用，遇到具体问题再回头补理论，通常更容易把抽象知识和真实问题对应起来。
误区三：“学这个是不是要会很多框架？” 框架是工具不是目标。理解模型调用、工具执行、状态和循环这些基本机制后，迁移到新框架会容易很多；只记 API 而不理解底层，遇到框架没有覆盖的场景就很难判断怎么改。
误区四：“我没大厂背景就找不到工作。” 大厂背景不是唯一通行证。许多做 Agent 的创业公司更看重”你能不能尽快解决真实问题”，项目经验、GitHub 和技术复盘可以帮助你证明这一点；不同公司对学历和经历的权重仍然不同。
误区五：“AI 发展这么快，学了会不会马上过时？” 表层工具会快速变化，但 ReAct、上下文工程、记忆系统、工具调用、Eval 这些问题已经反复出现在不同产品里。具体范式仍会演进，理解问题本身通常比背某一版框架 API 更耐用。
误区六：“Agent 是不是已经是红海了？” Coding、Research、Customer Support、BI、Marketing 等方向已经有大量团队进入，但多数领域仍处在寻找可靠产品形态和商业模式的阶段。机会存在，竞争也真实存在；真正的区分度来自具体场景、数据、可靠性和落地能力。
第四章｜怎么入门和准备求职#
这是这份文档最实操的一章。从你装上第一个 Coding Agent 开始，到”拿到第一个 offer”为止，需要做的事都在这里。
4.1 前置技能：你需要会什么、可以不会什么#
这条路线的第一步，不是挑语言、配环境，而是装上一个 Coding Agent（Claude Code ↗ / Codex ↗）——它会是你接下来的老师、工具、教材和对照组，4.2 会展开。也因为有它，前置技能清单比你想象的短得多。
先说语言。 Agent 开发当前主流是 Python 和 TypeScript / JavaScript 两个生态：
- 偏后端、偏数据、偏算法对接的项目，Python 更常见。
- 偏前端、偏 Web 产品形态的项目，TypeScript 更主流。
- 我自己写得最多的是 Next.js + Vercel AI SDK 的 TS 全栈，也有 React 前端 + Go / Python 后端的组合。语言从来不是重点，生态和团队才是。
但先说一个 AI-native 时代的前提：不要先花一两个月”学完语言”再开始。 Coding Agent（Claude Code / Codex）已经能替你完成大量代码编写，逐行手写所有代码不再是开始做 Agent 项目的前置条件；但你仍然需要逐步建立读懂、提问、判断和验证的能力。语言和工程基础可以在项目中同步学习，而不是完全跳过。
最先要练的是三个动作：
- 读——AI 写的代码，能看出大概在做什么（不要求每一行都懂）；
- 问——看不懂的地方，追问到能用自己的话复述为止；
- 判断——跑挂了，能把报错丢回去让它修；修完之后，知道怎么验证”真的好了”。
同时给自己设一条最低工程能力线：在第一个项目里补齐变量与函数、JSON、HTTP、环境变量、Git 基本操作、日志、依赖管理和测试。不用先背完再开始，但项目结束时应该能用自己的话解释它们在系统里做什么。
不需要会的（先放下）： 深度学习数学、PyTorch / TensorFlow / 模型训练 / 微调、Transformer 内部细节、LangChain / LangGraph 等 Agent 框架的 API（第一个 Agent 不应该从这些开始）。
关于 Git 和命令行： 这些是工程师的”基础卫生”，但在 2026 年它们的学习曲线已经被 AI 工具大幅压平——遇到不会的就问 Cursor / Claude Code，它会一步一步带你做。不要因为不熟悉 Git 就觉得”还没准备好开始学 Agent”，本末倒置。
4.2 学习路线：用 → 懂 → 造#
2026 年的新人和三年前的新人有一个根本区别：你从第一天起，手里就有顶级的生产级 Agent——Claude Code 和 Codex。所以这条路线不是”从零学造 Agent”，而是三级跳：把”会用”变成”懂”，把”懂”变成”能造”（至于把”能造”讲成”能被雇佣”，是 4.3 的事）。
整条路线里，你手里的 Coding Agent 会扮演四个角色：老师（带你配环境、随时答疑）、工具（替你写大部分代码）、教材（一个每天在你眼前跑的真实 Agent 样本）、以及最后你项目的对照组。
四个角色里，“老师”是 AI-native 很重要的心法：卡住时先让 Agent 按你的水平解释、出题检查理解、review 作业；涉及版本、价格、安全和 API 行为时，再回到官方文档交叉验证。下面三跳会反复用到这两个动作。
顺带把一个老问题了结掉：我不建议新人从零手写 ReAct Loop——三年前那是必经之路，今天没必要重复造轮子。但”不用手写”不等于”不用理解”：Agent Loop 的本质——第一章 1.4 那个最小 Agent——你必须能自己讲出来。第二跳就是干这个的。
第一跳：用（3–7 天）——成为 Agent 的重度用户
做 Agent 开发的人，理应先成为 Agent 的高频用户。装上 Claude Code 或 Codex，让它带你把环境配好——这本身就是你第一次”用 Agent 干活”。有条件可以两个都试：把同一个任务交给两边，比较它们拆任务、使用工具和处理失败的方式；只装一个时，就按所在地区的可用性、官方条款、预算和技术栈选择。然后把它用进手头的小事：写脚本、改配置、做小工具、整理文件。零编程基础也可以开始这一跳，但要同步补前面那条最低工程能力线。
这一跳要拿到两样东西：
一是边界感。 它什么任务一把过？什么任务会自信地给你错误答案？多长的任务它会开始迷失？边界感只能用出来，读十篇测评都读不出来——而且它直接决定你第三跳的选题质量。
二是”让它产出工程级代码”的手艺。 同一个 Coding Agent，在不同人手里产出的质量天差地别，差别全在用法：
- 给足上下文：在项目里放一份
CLAUDE.md/AGENTS.md↗，写清技术栈、约定、禁区——这其实就是第五章”上下文工程”的用户版。 - 把任务拆小、说清：“帮我做个网站”和”给这个页面加一个带防抖的搜索框，复用现有的 Input 组件”，得到的是两种东西。
- 要求它自证：让它跑测试、跑 lint、亲自验证结果，而不是它说”改好了”你就信。
- 读 diff：每次改动都读一遍它改了什么。这既是质检，也是零基础的人学代码最快的路径——看不懂的地方别跳过，想起来它同时是你的老师：让它解释，追问到你真懂了为止。
第一跳验收标准：能具体讲出它三次失败的样子（什么任务、怎么败的）；你的项目里有一份自己写的 CLAUDE.md / AGENTS.md，而且你能说出加它前后输出质量的差别。
第二跳：懂（1–2 周）——从用户变成拆解者
换一副眼镜：你每天在用的这个东西，本身就是很直观的 Agent 教材。这一跳做两件事——
一，拆解你手里的 Agent。 干活时有意识地看：它什么时候决定调工具？工具失败后它做了什么？长任务里它怎么压缩上下文？对照 1.4 的五个关键点，画出它完成一次任务的时序图。先看 trace、工具调用记录、命令输出和 diff，再问它：“你刚才为什么先跑测试再改代码？""上下文快满了你会怎么办？“Agent 的事后解释可以帮助你形成假设，但不一定忠实反映内部推理，要以可观察的执行记录为准。
二，让 AI 带你复现一个最小 Agent。 把”学”这件事本身也交给 AI：让 Coding Agent 写一段 10 行以内的代码，把”你好”发给一个 LLM API（例如使用价格较低的 DeepSeek ↗），并要求它逐行讲解；然后让它把”扩成多轮对话""加一个搜索工具”留成作业，你来改、它来 review。分工可以是：代码由它起草，理解和验证由你负责。 小 Agent 跑起来之后，把它的失败和第一跳记录的 Coding Agent 失败案例对照着看——两者都可能出现选错工具、死循环、参数错误，只是生产级产品会有更多上下文管理和执行层保护。到这里，1.4 的五个关键点就有了双重印证，你也会拿到两个重要体感：LLM 可以被当作 HTTP 服务调用；Agent Loop 也就是模型与工具反复交互的循环。SDK 按 2.2 选：TypeScript 可以从 Vercel AI SDK ↗ 开始，Python 可以用 OpenAI SDK + base_url 或 Pydantic AI ↗。
第二跳验收标准：能对着 SDK 代码，指出 Agent Loop 每一步对应 1.4 的哪个关键点；画得出你的 Coding Agent 完成一次任务的时序；你的最小 Agent 有一份失败案例清单，每一条你都能说出对应哪类问题。用低价模型和小规模测试时，API 花费通常不高，但仍要以实际模型价格和调用量为准。
第三跳：造（1–2 个月）——做一个跨得过灵魂拷问的真实项目
挑一个你自己每天会用的真实场景——不要做”通用问答助手”这种烂大街的项目。
判断项目”够不够格”，现在是双重灵魂拷问：
- 我那篇《模拟面试》博客里 W 的经典问题：“用豆包 / ChatGPT 直接就能解决，为什么要做这个？”
- 2026 年的升级版：“用 Claude Code 装个 Skill 就能解决，为什么要做这个？“——你的对照组已经不是聊天框，是一个通用 Agent。
这两问不用凭空想——直接把想法丢给你的 Coding Agent，让它当场试。 如果它二十分钟内就覆盖了核心价值，继续追问你的项目在可靠性、专有数据、持续运行、用户体验或领域约束上增加了什么；它卡住的地方——拿不到你的私有数据和私有工作流、记不住你上周的偏好、没法长驻着替你盯一个流程、可靠性到不了敢真用的程度——往往就是值得深入的项目空间。这就是四个角色里”对照组”的用法，也是第一跳攒下的边界感真正的用武之地。
选题从你自己的重复劳动里挖，别从网上的”项目点子清单”里挑。举一个升级示例：“每周帮我摘要 Newsletter”——Claude Code 一句话就能干，不够格；但”接上我的私有阅读源，记住我每次点’没兴趣’之后越推越准，每周一早上自动跑好等我醒来”——私有数据、长期记忆、长驻运行三个卡点全占，这才有了壁垒。同一个题材，壁垒从来不在功能本身，在通用 Agent 够不着的那几厘米。
做的过程中可以让 Coding Agent 完成大量代码，但你必须能解释和验证最终产物。不同面试官对 AI 生成代码的接受度不同，普遍更难伪造的是选题、取舍、Eval、失败复盘和你对实现的掌握程度。你的精力应该花在：定义”什么叫做好了”（Eval）、处理通用 Agent 做不好的部分，以及第五章那八件内功。
每个项目完成后尽量写一篇复盘——“我做了什么""遇到了什么坑""怎么解决的”。它会成为简历和面试中很有说服力的补充材料。
第三跳验收标准：项目部署在别人能访问到的地方（Vercel / Cloudflare 的免费档通常就够）；有真实用户用过——哪怕只有你室友；复盘博客或完整 README 写完。能让别人实际使用并反馈，通常比只有本地截图更有说服力。
4.3 求职准备：项目要”讲到极致”#
如果你只能把准备时间花在一件事上，就是把你的项目讲到极致——说清楚四件事：
- 做了什么（What）：项目背景、你的角色、整体架构
- 为什么这么做（Why）：每一个关键决策的依据
- 踩过什么坑（How it failed）：失败案例 + 解决方案
- 学到了什么（What you learned）：重做你会怎么改
反例：“我用 Vercel AI SDK 做了一个 Newsletter 摘要 Agent。“——这种描述等于没说，是面试杀手。
正例（继续用 4.2 的 Newsletter Agent；以下数字是为了演示叙事结构而设定的示例）：
“我做了一个 Newsletter Agent。第一版每周把 30 多封邮件全文塞给旗舰模型做摘要，单次成本 4 块多，而且长上下文里它经常漏掉我真正关心的内容。我改成了两级：先用便宜模型按我的历史反馈给每封邮件打分做预筛，只有前 10 封进旗舰模型深度摘要——成本降到 8 毛。但预筛带来了新问题：偶尔把我感兴趣的邮件筛掉了。我给预筛加了两条硬规则：我点过’没兴趣’的来源降权、我点开读完过的来源永远直进精选，把’漏掉重要内容’从每周两三次压到基本为零。最后我加了个每周自动跑的 Eval：拿我上周的真实点击当标准答案回测预筛准确率，低于 85% 就提醒我调整。”
这段话有：指标（成本 4 块 → 8 毛、漏检两三次 → 0）+ 决策（模型分级 + 反馈规则）+ 权衡（成本 vs 漏检）+ Eval（用真实行为回测）。这就是”讲到极致”——注意它还顺手展示了 2.1 的模型分级和第五章的成本控制、Eval，全是面试官想追问的钩子。
简历层面的三个要点：不要只堆技术名词（“熟练掌握 LangChain、LangGraph、Vercel AI SDK、CrewAI……”不能代替真实项目）；每段项目按”问题 — 方案 — 结果”结构；尽量提供可复现的指标，如果是估算，必须注明样本、口径和估算方式。
面试层面——Agent 岗考的不是八股文，是”你经历过什么”。具体四个维度：
- 基础认知：LLM / Agent / Chatbot 的本质区别、Function Calling 怎么工作、MCP 是什么……
- 系统设计：上下文工程方案、记忆分层、工具调用可靠性、多 Agent 协作（5.9 专门讲了这一类问题该怎么答）……
- 工程取舍：模型选型依据、成本和效果平衡、框架选型判断、失败重试策略……
- 行业认知：Manus / Claude Code / OpenCode 的设计思路、最近读了什么、关注什么开源项目……
第一层靠经验、第二层靠理解、第三层靠判断、第四层靠 taste 和阅读量。越往后越能拉开候选人差距。 我那篇《模拟面试》博客里把每一类都举了具体例子，需要的话可以去看。
还要点破一个 2026 年的变化：越来越多面试官会假设候选人在开发中使用过 AI 工具。 因此他们更可能验证难以伪造的东西——你见过多少 Agent 的失败模式、每个选型的”为什么”、被追问几层之后还能不能讲清楚取舍，以及你是否真的读懂并验证过代码。这也是为什么 4.2 每一跳既要求”能讲出来”，也要求留下可运行、可检查的产物。
4.4 六个不要走的弯路#
弯路一：一上来就啃 LangChain 源码。 设计复杂，源码对新人极不友好。等你用 SDK 跑过几个项目之后再去看，体感会完全不一样。
弯路二：过早卷模型微调。 对多数入门级 Agent 应用，应该先把 Prompt、上下文、检索、工具和 Eval 做扎实；只有当你有稳定数据、明确目标，而且现有方案已经触顶时，再评估微调。
弯路三：追新框架不沉淀基本功。 每隔两周就有新框架。一旦你形成”追新”习惯，就永远在学新东西、永远没有自己的项目。
弯路四：看完教程就觉得自己会了。 Agent 领域很多”看起来很简单”的概念，真正动手都会出现一堆细节。阅读能建立地图，但必须用可运行的项目和失败案例检验理解。
弯路五：只做不沉淀。 项目可以不开源，但至少应该留下 README、架构图、指标口径和失败复盘。公开博客或开源项目会进一步增加求职可见度，但内部项目和私有经验并不等于白做。
弯路六：把 Coding Agent 用成黑盒——或者反过来，拒绝用它。 只复制粘贴、从不读 diff，用得越久越空心，面试一追问就露馅；反过来把用 AI 当”作弊”、坚持全手写，速度和视野又都跟不上。正确姿势就是 4.1 的三个动作：读、问、判断。
4.5 推荐学习资源（精选）#
想要一门系统课可以选这个：Hugging Face 的免费 AI Agents Course ↗——从概念、框架到期末项目一条龙，学完有证书。适合喜欢”有课程结构”的人；不喜欢上课的可以直接走下面的文档路线。
想通过读真实代码理解 Agent Loop，而不是看示意图：Pi ↗（GitHub ↗）是一个 MIT 协议的开源 Coding Agent，核心思路是把”核心”和”能力”彻底拆开——核心只负责把 Agent Loop 跑对，其他一切都是可选的：
- Pi Core 做得很轻：系统提示词约 150 词，默认工具只有 read / write / edit / bash 四个，不内置子 Agent、Plan 模式和 MCP 支持，权限也不做在核心里——官方选择把这些都交给外部沙箱（容器 / VM），核心因此小到可以整个读完、放心改。
- 要什么能力用插件加：Plan 模式、更多工具、自定义命令这些”别的 Agent 都内置”的功能，Pi 做成运行时加载的 TypeScript Extension、Skill 或第三方 Pi Package——不用重新编译，装哪个多哪个能力。
- Databricks 验证过它的效率：Databricks 2026 年 7 月的一篇工程博客 ↗在自己的千万行代码库上做内部评测——同一个模型、同样的思考强度，分别套 Pi 和 Claude Code / Codex 的 harness 跑同一批任务，结论是质量基本一致，但部分任务的单次成本相差超过 2 倍，Pi 每轮发送的上下文只有约三分之一。换句话说，Pi 省的不是”智商”，是用更少上下文和更低成本做到同样的活——这也是 Databricks 把它选进开源元框架 Omnigent ↗（可以在 Claude Code / Codex / Pi 之间无缝切换 harness）的原因之一。
如果翻开 Pi 的源码觉得有点难啃，可以先读 Tau ↗（GitHub ↗，域名 twotimespi.dev 是”2π=τ”的双关）——Hugging Face 照着 Pi 的思路用 Python 做的教学向重写，官方定位就是”a working example of how coding agents are built”：代码分三层（tau_ai 模型适配 / tau_agent 核心 Loop / tau_coding 终端应用），坚持”小层胜过魔法”，专门讲清教程常常跳过的问题——工具调用怎么发起、会话怎么持久化。两条路线思路相通，挑一个读得下去的先啃；这也是 4.2”第二跳”里”复现最小 Agent”之外的另一个选项——不想从零写，直接通读现成的、专为可读性设计的实现，一样能补上那五个关键点的体感。
先读你天天在用的工具的文档：Claude Code ↗ / Codex ↗ 的官方 Best Practices——怎么写 CLAUDE.md / AGENTS.md、怎么拆任务、怎么让它自证。这些是第一跳很合适的配套教材，也是理解厂商推荐工作方式的一手资料。
官方文档（按顺序读）：Vercel AI SDK 官方文档 ↗（适合 TypeScript 入门）→ Anthropic 官方文档 ↗的 Tool Use / Skills / Prompt Engineering 章节 → OpenAI Cookbook ↗（Python 实战补充）→ 你选的国产模型厂商的文档（DeepSeek / Qwen / Kimi / GLM 任一）。
一线博客（每周扫一眼）：Anthropic Engineering Blog ↗、OpenAI Blog ↗ / Cookbook ↗、Sequoia ↗ / a16z ↗ 的 AI 板块、Hacker News ↗ 的 AI 板块。
社区：Twitter / X 关注 @karpathy、@AnthropicAI、@OpenAIDevs、@simonw、@_philschmid、@jxnlco。
我不在这一阶段推荐任何 LLM 内部机制类资源（Karpathy 的 “Let’s build GPT” 系列、各种 minimind 类源码教程——包括我自己的 minimind-notes）。它们都很优秀，但解决的是”理解 LLM 怎么训练出来的”问题，跟做 Agent 应用是两条赛道。等你做完第一个真实项目、有了具体好奇心，再回头看会更有体感。
第五章｜真正重要的那几件事#
前面四章讲清楚了”是什么、怎么入门、怎么求职”。最后这一章是给那些已经做完第一个项目、想知道”再往深里走是什么”的人——也是 Agent 工程师真正的内功心法。
每节都用一个生活类比帮你建立直觉。这一章读完，你就有了和资深工程师对话的共同语言。
5.1 上下文工程#
类比：你给同事交接工作，给的是 100 页项目档案，还是一份 1 页精要 brief？
LLM 的注意力是有限的——上下文越长、信息密度越低，它越容易”看走神”，同时 Token 成本越高、响应越慢。Context Engineering 解决的就是”在有限空间里，把最该被看到的信息以最有效的方式呈现给模型”。
在实际项目里，一个商业级 Agent 一次对话可能要处理几十轮交互、调用几十次工具。如果不做上下文管理，长任务很容易接近模型上限，或者在到达上限之前就因信息过载而降质。常见技巧——
- 结构化 Prompt：用 XML 标签、JSON 块、明确分隔符代替自然语言流水账。
- 关键信息前置 / 后置：模型对开头和结尾的注意力更高（“Lost in the Middle” ↗ 现象）。重要约束放 System Prompt 顶部或 User 消息末尾。
- 历史摘要替代历史明文：长对话里把早期对话压缩成摘要。
- Prefix Cache 友好的上下文设计：不变的内容放前面、变化的放后面，能极大降低成本。
5.2 记忆系统#
类比：人怎么记事？短期记忆（刚发生的事）、长期记忆（多年前的重要经历）、检索唤起（看到老照片突然想起一段往事）。Agent 的记忆架构基本是仿这个的。
三层架构：
- Working Memory：当前任务正在用的上下文
- Short-term Memory：当前会话的历史
- Long-term Memory：跨会话的持久信息
长期记忆的关键决策点有三个——
写入策略：什么样的信息值得写入？“我今天想吃辣”这种临时偏好不该记；“我对花生过敏”这种长期事实必须记。这种分类通常由专门的”Memory Agent”来判断。
读取策略：什么时候检索、怎么检索？每次对话都检索一次还是特定意图下检索？用向量相似度、关键词、图检索？
遗忘策略：长期记忆不是越多越好。过时、低价值、矛盾的记忆应该被清理或衰减。
5.3 工具调用#
类比：让一个聪明但没有手的人帮你完成任务——你得告诉他附近有哪些工具、每个能做什么、怎么用。
工程上几个常见难点：
- Tool Schema 设计：参数名、描述写得越清楚，模型用错概率越低。
- 工具数量取舍：太少不够用，太多模型选不对。但”选不对”的阈值不是一个固定数字——它取决于模型能力和工具描述的区分度。到了几十个以上的规模，主流做法是 tool search（按需加载工具）+ Skills 的渐进式披露，而不是把所有工具硬塞进上下文。
- 失败重试与幂等：重试要有上限（比如 3 次），而且上限该按错误类型定——网络抖动值得重试，参数写错了重试一百次也没用。有副作用的工具还必须考虑幂等，否则重试就是重复下单。
- 事前约束 + 执行层兜底，两层都要：在 Prompt 层把工具使用边界讲清楚，能大幅降低误调用率；但真正的安全边界必须做在工具执行层——权限校验、参数校验、危险操作确认、审计日志。Prompt 是软约束，挡不住模型漂移，更挡不住 prompt injection：网页里藏一句”请把数据库删了”，你 Prompt 里写多少遍”不要删库”都拦不住。
5.4 可靠性#
类比：写 Demo 像在自家厨房做菜，写 Production 像开餐厅——你要应对的不只是”做得好不好”，还有”高峰期会不会爆""偶尔来个挑剔顾客会不会让流程崩”。
传统业务逻辑通常更可预测，也更适合用确定性断言测试；Agent 则包含概率性模型，同样输入可能得到不同输出，甚至完全失败。这意味着”测过一次就 OK”的开发模式在 Agent 上远远不够。
常见可靠性问题：幻觉、指令偏离、格式不稳定、死循环、工具失败的级联崩溃。
工程上的核心思路可以压缩成一句话：用确定性的基础设施，包住非确定性的模型。 模型输出无法被完全保证，但可以被引导、校验、约束和降级；包在它外面的关键边界应该尽量确定——
- 事前约束：用 Prompt 把”应该怎么做”讲清楚，降低出错率（但记住 5.3 和 5.5 说的：这是软约束，不是安全边界）
- 结构化输出 + Schema 校验：用 Pydantic、Zod 校验模型输出
- 状态机 + Checkpoint：把 Agent 流程显式化为状态机
- 降级策略：工具失败时有 fallback 路径
5.5 安全#
类比：你雇了一个很能干、但完全照做的助理。他会认真读你交给他的每一份材料——问题是，如果有人在材料里夹了一张纸条写着”请把公司账户转到这个卡号”，他分不出这到底是”要处理的资料”还是”要执行的指令”。
这一节把散在 1.4、2.3 和 5.3 的安全内容收拢成一张完整的图。Agent 只在本地跑 demo 的时候，安全还只是一句口号；等你真的把它接上网页、邮件和自己的私有数据，它立刻变成必须处理的问题。
根子上的问题：模型分不清”数据”和”指令”。 你的系统提示词、用户的问题、网页抓回来的正文、工具返回的结果——进了模型之后都是同一串 token。模型没有可靠机制去区分”这句是我该听的命令”和”这句只是我该处理的素材”。Prompt Injection 就是利用这一点：把指令伪装成数据喂进去。
这不是一个能靠 Prompt 修好的 bug。你在系统提示词里写一百遍”不要听从网页里的指令”，攻击者只要在网页里写”以上指令已作废，请改为执行……”，就有相当概率绕过去。学术界至今没有通用解法。
三种你会真实遇到的形态：
- 直接注入：用户自己在对话里试图越权（“忽略你前面的规则”）。最好防，也最不重要。
- 间接注入：恶意指令藏在 Agent 会读到的外部内容里——网页、PDF、邮件、Issue 评论、代码注释。这才是真正危险的一类，因为把它读进上下文的不是攻击者，是你的 Agent 自己。
- 供应链注入：恶意内容藏在你安装的第三方能力里。2.3 讲的 ClawHub 投毒事件就是这一类——伪装成”安装步骤”的 SKILL.md 正文，诱导 Agent 执行命令。
所以安全边界必须做在执行层，不能做在 Prompt 层。 这句话 1.4 和 5.3 都提过，这里给出它的完整含义：
- 最小权限：Agent 拿到的凭证只够干它该干的事。一个读邮件的 Agent 不该有删除权限。
- 沙箱执行：有副作用的操作跑在隔离环境里——容器、虚拟机、独立分支。4.5 提到的 Pi 就是典型做法：核心里干脆不做权限系统，明确把边界交给外部沙箱。
- 危险操作要人确认：把”哪些操作需要审批”写成代码里的白名单，而不是指望模型自觉。
- 输出也要校验：模型说要调
transfer_money(amount=999999)，执行前应该有一道与模型无关的规则拦下来。 - 审计日志：出事之后你得能还原它到底做了什么——这也是 5.7 观测的价值之一。
还有一件 2026 年才变得紧迫的事：Agent 已经站到了攻击方。
2026 年 7 月 16 日，Hugging Face 披露了一次生产环境入侵。攻击者通过数据集处理管线的两个代码执行漏洞进入，而整场攻击是由一个自主 Agent 框架驱动的 ↗——在一大批短生命周期沙箱里执行了数千个独立动作，命令控制信道还会自我迁移到公共服务上。公开的模型、数据集和 Spaces 未被篡改，但部分内部数据集和服务凭证受到影响。
HF 官方的结论值得原样记住：自主的、AI 驱动的攻击工具”已不再是理论”——它大幅降低了发动长期、多阶段攻击的成本，并且以机器速度运行。
这件事对入门者的意义不是”所以别做 Agent”，而是：你写的每一个能联网、能执行、能读外部内容的 Agent，既是一个潜在的攻击面，也是一件潜在的武器。 把执行层边界当成必选项，不是加分项。
5.6 成本控制#
类比：开车——油价、路程、车型都会影响油钱。Agent 也一样：模型、上下文长度、调用次数共同决定一次任务的成本。
Agent 的成本远比传统应用高。一次复杂任务可能要几十次 LLM 调用、累计几万到几十万 Token——单次任务可能花几块到几十块人民币。如果你的产品是 toC 免费的，成本控制不好就是赔本赚吆喝。
几个高 ROI 的优化手段：
- Prefix Cache 友好设计：主流厂商对”前缀命中”通常有缓存优惠，最高可节省约 90% 的输入成本，但比例随厂商和模型变化（Anthropic 部分模型的缓存读取按 0.1 倍计价；OpenAI 不同模型目前有 50%、75% 或 90% 等不同折扣；Gemini 也要以具体模型价格页为准）。把不变的内容放前面，并在上线前按实际模型核价。
- 模型分级使用：简单任务用便宜模型，复杂任务才用旗舰。
- 减少 Agent Step 数：能在一步讲清楚的事就不要拆成多步。
- 上下文剪枝：把不相关的工具结果、过时对话历史从上下文剔除。
“缓存友好”比”把不变的内容放前面”更微妙——真正该知道的是什么会让它悄悄失效。 Pi 团队那篇 prefix cache 复盘 ↗值得在动手优化前读一遍：
- 会话中途动态增删工具、改 schema：这是最容易踩的坑，它可能把”第一个不匹配的位置”推到 prompt 很靠前的地方，让后面整段缓存全部作废。系统提示词里的时间戳、会话中会变的项目信息同理。
- 激进的历史剪枝会和缓存打架：删掉早期内容就等于改了前缀，而重写一段长缓存上下文的即时代价，可能超过省下那点便宜 Token 的收益。所以上面那条”上下文剪枝”要和这条一起看——剪枝省的是本次输入，代价是缓存失效，值不值得取决于这轮对话还要走多久。
- 闲置之后大概率是 miss：多数厂商默认只保留约 5 分钟，所以隔了一会儿再发一句”hi”，花的钱会比你预期的多。
5.7 观测与调试#
类比：车子熄火了。一个只会说”它坏了”的司机，和一个能打开仪表盘看到”三缸失火、水温 110 度”的技师，差的往往不是修车技术，而是有没有仪表盘。
这一节解决的是新手最早、也最频繁遇到的问题：“它刚才为什么这么干？到底哪一步崩的？”
先厘清它和下一节 Eval 的分工，这两件事经常被混为一谈：
- 观测（Observability）回答”发生了什么”：这一次运行里，它调了哪些工具、传了什么参数、拿回什么结果、从哪一步开始跑偏。是单次、事后、诊断性的。
- Eval 回答”是不是变好了”：新版本比上一版强还是弱。是批量、对比、决策性的。
没有观测，你连 Eval 跑出来的失败案例都读不懂。 所以顺序是先有观测，再谈 Eval。
为什么 print 不够用？单次 LLM 调用打印一下输入输出还行；但 Agent 是循环——一次任务几十轮交互、几十次工具调用，每轮上下文都在变。你需要的是结构化、有层级、能回放的执行记录，而不是一屏滚过去的日志。
这个记录有个通用名字：Trace（执行轨迹）。一次任务是一条 trace，其中每一次模型调用、每一次工具执行是一个 Span（片段），span 之间有父子关系，拼起来就是这次任务完整的决策树。
顺带认一下同义词，免得被术语绕住：同一件东西在评测、论文和 RL 语境里常叫 trajectory（轨迹），在偏”完整对话记录”的语境里常叫 transcript，也有直接叫 session 或 run 的。听到哪个都别慌，说的都是”这次任务从头到尾发生了什么”。
一条够用的 trace 至少要记下：
- 每次模型调用的完整输入和输出——包括系统提示词。很多”它怎么突然不听话了”的答案就在这里：你以为传进去的东西，和实际传进去的并不一样。
- 每次工具调用的参数、返回值和耗时——“参数写错了”和”工具本身报错了”是两类完全不同的 bug。
- 每一步的 Token 消耗——这是 5.6 成本控制的数据来源。没有它，省钱全靠猜。
- 失败和重试——第几次重试成功的，还是最后放弃了。
- 一个能把整条链路串起来的 ID——这样你能从”用户投诉的那一次对话”直接跳到对应的 trace。
别被”可观测性平台”这个词吓住，它本质就是日志。一条 trace 说到底是一份结构化的文本记录，你完全不需要先搭一套平台才能开始看：把它按行存成 JSONL（一行一个 span），出问题时新开一个对话整段丢给 AI，让它替你读——哪一步开始跑偏、哪个工具返回了空、上下文在哪里被截断，它扫几百行日志比你快得多。这就是 4.2 里”把学习本身也交给 AI”那套用法搬到了调试场景。
一个能立刻用上的习惯：每当 Agent 给出一个让你意外的结果，先别急着改 Prompt，先去读那一次的 trace。绝大多数时候你会发现，问题不在”模型笨”，而在某个工具返回了空结果、某段上下文被截断了、或者某个参数传错了。改 Prompt 是猜，读 trace 是查。
这个习惯也正是 4.2 第二跳”拆解你手里的 Agent”能做下去的前提。
5.8 评估（Eval）#
类比：传统软件能用单元测试——输入 1+1，期望输出 2，错了就是 Bug。Agent 没有”标准答案”——你怎么知道它做得”好”？
先纠正一个容易说过头的话：Agent 并非”没有对错”。订错票就是错、泄露数据就是错、调了禁用工具就是错——这些硬约束是可判定的，直接用规则卡住。Eval 处理的是剩下那部分真正”没有标准答案、只有好坏”的质量问题：这时你需要一套机制回答”我新版本的 Agent 比上一版好还是坏？“——没有这个机制，你优化半天根本不知道方向对不对。Eval 体系是 Agent 工程从”作坊”到”工业”的标志。
主流评估方法：
- 离线评估：准备一批测试用例，让 Agent 跑，人工或 LLM-as-Judge 打分
- 在线评估：在生产环境里收集真实用户反馈（点赞点踩、停留时长、是否继续追问）
- LLM as a Judge：用更强的模型当裁判——注意它本身的偏差（倾向打高分、偏好长答案等）
- 对照实验：A/B Test，把新版和旧版分流给不同用户
LLM-as-Judge 这条值得单独多说两句，因为它最容易做出”看起来在涨”的假分数。 除了倾向打高分、偏好长答案，还有一种最常被忽略的偏差：模型会偏爱自己家族的输出。让 Claude 去评判 Claude 写的答案、让 GPT 去评判 GPT 写的答案，分数会系统性地偏高——你以为在测质量，其实一部分在测”像不像自己”。
所以 judge 至少要守两条规矩：
- 交叉评，别自己判自己：让另一家的模型来当裁判，或者用两家分别打一遍看差异；分歧大的那些样本，恰恰是最值得你亲自去看的。要求更高时可以让多个 judge 投票取多数。
- judge 和干活的模型分开管：不只是换模型，采样参数也要分开固定。judge 应该低温度（甚至贪心解码），保证同样的输入给出同样的分数，否则你根本分不清分数波动是产品变了还是裁判抖了；actor 该用什么参数就用什么。judge 的模型、版本和参数应该像测试代码一样被写死并记录在案，不然某天”分数涨了”，真实原因可能只是裁判换了。
5.9 多 Agent#
类比：几乎所有人的直觉都站在”多 Agent 更强”那一边——毕竟进公司、做项目靠的都是团队协作，“人多力量大”听起来天经地义。
但你回想一下学校里的小组作业。你是组长，组里另外三个人态度消极、能拖就拖。你要开会对齐、要把同一件事解释三遍、要检查他们交上来的东西、最后还要把风格对不上的几段重写一遍。这些沟通和返工的时间，全都是成本。最后交出去的作业，很可能还不如你一开始就一个人从头做完——不是因为那三个人智商不够，而是因为协作本身是要收费的，而这笔费用在队友不靠谱的时候，会迅速超过他们贡献的那点产能。
多 Agent 是完全相同的一件事。你多开的每一个 Agent，都要额外付出”把上下文同步给它”和”把它的产出接回来”两笔开销。更麻烦的是，它还不像人——人不确定的时候至少会回头问你一句”这里你是什么意思”，而 Agent 会自己默默假设一个答案，然后带着这个假设一路做到底。
先说结论：新手遇到质量问题时最常见的错误反应，就是”再加一个 Agent”。 一个本来靠补上下文、改 Prompt、加一道校验就能解决的问题，拆成三个 Agent 之后，往往变成三个 Agent 互相甩锅——更难调试，也更贵。
为什么拆开容易更糟。 根子上是一件事：上下文在拆分的那一刻就断了，而断掉的往往不是明面上的信息，恰恰是那些没被写下来的隐含假设。典型的失败长这样——主 Agent 让子 Agent A 做背景、子 Agent B 做主角，两个子 Agent 各自都”完成得很好”，但风格完全对不上，因为谁都不知道对方替这个任务做了哪些默认决定。
所以更稳妥的顺序是：优先用单线程的线性 Agent，让上下文一路连续下来；上下文塞不下时，先把力气花在压缩和上下文工程上，而不是急着拆。
那什么时候多 Agent 是对的？ 当任务同时满足这三条：
- 天然可并行——比如同时查 20 家公司的公开信息，彼此不依赖。
- 信息量超过单个上下文窗口——需要多个独立上下文各自压缩后再汇总。
- 任务价值足够高——每个 Agent 都要维护自己那份上下文，总 Token 开销可能是单 Agent 的数倍到十几倍，你得付得起。
反过来说，大多数任务（尤其是写代码）并没有那么多真正可并行的部分，单 Agent 更划算。
给入门者的建议：第一个项目不要做多 Agent。 把单 Agent 的上下文工程、工具调用和可靠性做扎实，你会发现原本想拆的理由消失了一大半。等你真的撞上”这个任务必须并行”或者”上下文真的装不下”的那一天再拆——那时你也才有能力判断拆得对不对。
面试里被问到多 Agent 时，能讲清楚”我为什么没有拆”，往往比背出几种编排模式更有说服力。
5.10 这八件事是 Agent 工程师真正的”内功”#
总结一下——按”解决什么问题”分组会更好记：
让它把事做对：
- 上下文工程：有限空间里最大化信息密度
- 记忆系统：让 Agent 像人一样分层记事
- 工具调用：让 Agent 能”动手”——并且不要乱来
让它扛得住真实世界：
- 可靠性：从确定性思维切换到概率性思维
- 安全：模型分不清数据和指令，边界只能做在执行层
让它可控、可判断：
- 成本控制：钱是真的会烧的
- 观测与调试：先能看见，才谈得上优化
- 评估：没有 Eval 的 Agent 优化都是玄学
最后还有一个架构判断：
- 要不要拆成多个 Agent——大多数时候，答案是”先不拆”
如果你能结合真实项目讲清楚这八件事，并且能说明白你为什么没有把系统拆成多个 Agent，就已经能和面试官讨论 Agent 工程中真正影响质量、成本和可靠性的取舍。
写在最后#
如果你看到这里——谢谢你花时间读完。
这份指南免费开放。当前版本为 v1.2（更新于 2026-07-25）。
后续更新#
- 大约每 3–6 个月集中修订一次
- 遇到重要模型或行业变化时及时补充
- 历史版本保留存档，方便对照
关于反馈#
如果你看完这份文档有任何意见、建议，或者发现错误，非常希望你能告诉我。这个项目已经开源在 GitHub：joyehuang/blog ↗，具体问题可以直接提 Issue ↗，也可以通过网站留言或私信联系我。读者反馈是我持续修订这份指南最重要的依据。
特别欢迎的反馈类型：
- 某个概念你觉得讲得不够清楚
- 某个判断你不同意，想和我讨论
- 你按路线图实践了，发现某个建议不太适用
- 你自己摸索出了文档里没有的好做法
附录｜1v1 付费服务说明（可选阅读）
每个人的情况不一样：
- 你的简历应该怎么改，通用文档给不了具体到段落、句子的建议；
- 你的项目应该怎么讲，通用文档无法针对你的经历重写“问题—方案—结果”；
- 你的学习节奏应该怎么定，需要结合基础、目标和每周可投入时间；
- 你即将面的公司可能会问什么，需要结合岗位和简历准备。
如果你需要这种具体的 1v1 帮助，我提供以下三档服务。所有服务都由我亲自交付，不外包、不批量。
服务一：简历修改（￥）
适合谁：
- 已经有简历和项目经历，但不确定怎么讲清亮点；
- 简历上有项目，但讲不出“问题—方案—结果”；
- 想转 Agent 方向，不知道怎么改造旧简历。
服务内容：
- 详细 review 简历，提供具体到段落、句子的修改建议；
- 重新组织项目叙事，让项目能在面试中被清楚讲明白；
- 提供 Agent 工程 / LLM 应用 / Multi-Agent / RAG 等方向的关键词建议；
- 一次 30–60 分钟的 1v1 沟通，复查修改后的版本。
服务二：1v1 模拟面试（￥￥）
适合谁：
- 正在准备 Agent 工程师岗位，但缺乏实战面试经验；
- 已经复盘过项目，希望有人专业地追问和检验；
- 即将面试心仪公司，希望提前热身。
服务内容：
- 结合简历和目标公司定制题目；
- 覆盖基础认知、系统设计、工程取舍和行业认知；
- 按时间收费，最少 1 小时起；
- 可按需要录音 / 录像，结束后整理延伸资源。
服务三：学习路线 / 入门陪跑（￥￥￥）
适合谁：
- 零基础或有基础但缺少方向，希望有人系统带一段时间；
- 自学容易卡住或中断，需要节奏督促和答疑；
- 希望在 1–3 个月内完成一个可展示的 Agent 项目。
服务内容：
- 入门评估和个性化周度学习计划；
- 每周一次 30–60 分钟 1v1 答疑；
- 项目全程跟进和关键节点 review；
- 结束时完成至少一个 Agent 项目和一份复盘文档。
典型陪跑周期：4 周 / 8 周 / 12 周，具体根据目标和时间决定。
所有服务的具体价格请联系咨询。咨询本身免费，我会先了解你的情况，再判断哪种服务适合你；不合适会直接说明。
如何联系
加微信 ，备注 “付费咨询”。
最后的祝福#
Build fast, learn faster.
这是我博客的 slogan，但这里的 faster 不是催你和别人赛跑。
Agent 发展得很快，信息每天都在变，看到别人一天冒出十个新名词，很容易觉得自己起步太晚、学得太慢。但这个方向里没有谁已经把一切学完了，大家都在一边做、一边踩坑、一边更新认知。你不需要一次读懂这 1.85 万字，也不需要一周做出一个改变行业的项目——今天比昨天多理解一个概念、多跑通一个小功能，就已经是在往前走。
如果你想找人一起学、交流最近看到的工具，或者分享项目里刚踩过的坑，我有一个氛围很友好的 Agent 交流群。不管你是零基础、正在转方向，还是已经在做 Agent 工程，都欢迎加入： 。
我也会不定期在 B 站主页 ↗直播。它不一定每次都有正式主题，更像一个线上自习室：我写代码、读文档、做项目，你可以一起学习、提问，或者安静挂着各做各的事。一个人学容易焦虑，一群人一起学会轻松很多。
这份文档到这里就结束了，但你的旅程才刚刚开始。慢一点没关系，先动起来；走弯路也没关系，记得复盘。如果它帮到了你哪怕一点点，那就值得了。
希望某天我们能在某家 AI 公司、某个开源项目、某个 GitHub Issue，或者直播间里相遇。到那时，记得告诉我——“这份文档我当年也读过。”
—— Joye
Updated: 2026-07-25 · v1.2
版权所有。如需转载请联系作者。