零基础一天（9小时）学完Agent！¶

学会 Agent 只需要 1 天 * 9 小时！¶

零基础一天（9 小时）学完 agent！写这个教程就是想告诉大家，Agent 其实非常简单！并且能帮助你找到 Agent 相关工作 / 实习！目前有很多个同学看这个教程找到了实习，且本教程在同学群里备受好评，现在开源给大伙！

项目地址

一、拥有你自己的 llm api-key（阅读需约 15 分钟）¶

Python 或 Java 任选一，会基本语法就行。拿到一个 LLM APIKey，能跑通一次 API 调用就算入门了。

• 你可能需要学会使用 python 和 uv 用 rust 编写，类似于 rust 里面的 cargo，速度非常快

• 为什么不用 conda 而是 uv：uv 开源无商用风险，Conda 在超过 200 人的组织有潜在商用授权问题

• uv 可以像 pip 一样编辑镜像源，mac 和 linux 系统修改 ~/.config/uv/uv.toml 并写入如下配置，Windows 系统可自行查询配置方式。项目初始化执行 uv sync 即可。

[[index]]
url = "https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple"
default = true

• 你可能需要 llm api-key，推荐 kimi 或者智谱

• 配置环境变量 OPENAI_API_KEY 和 OPENAI_BASE_URL，并尝试运行 core/llm.py

二、实现 Node / Workflow / Agent（阅读需约 1 小时）¶

• 我们最终的目标是打造一个 Agent，具备联网搜索、运行命令行、文件编辑能力。

• Agent 底层可以用 Node 来抽象，教程提供了极简实现，可查看 core/node.py，不到 60 行就实现了 Agent 轻框架。如果没有 Python 基础看不懂，可以把代码复制给 AI 帮你解释。

• Node 的使用方式：新建 3 个 Node 串联，实现 接收输入 -> 上网搜索 -> 大模型生成总结 的功能，你就实现了 workflow，对应代码在 examples/workflow

• 新建一个 workflow，实现 接收用户输入 -> 大模型回复，再通过 loop 反复调用这个 workflow，你就实现了 chatbot，对应代码在 examples/chatbot

• 给 chatbot 接入 tools（下文会详细讲解），让它能上网搜索、编辑文件、运行命令，你就实现了 agent，对应代码在 examples/chatbot_with_tools

核心公式总结¶

• workflow = node + node

• chatbot = workflow + loop

• agent = chatbot + tools = workflow + loop + tools

恭喜你已经理解 Agent 的核心了！你可能会疑惑：这么简单的轻框架真的有用吗？为什么不选 LangChain / Dify / Coze / Google ADK / Spring AI？

现实中很少有人用 LangChain 开发出优质产品，且它曾出现过严重安全漏洞 CVE-2025-68664，还存在过度抽象、依赖地狱、Bug 多、定制化不灵活等问题。事实上 claude-code、cursor、kimi-cli、pi-mono、Pocketflow-examples 等优秀 Agent 项目，都是自研轻框架或直接调用 LLM API 开发的，因此非常推荐你自建轻框架。

三、RAG 基础（阅读需约 1 小时）¶

• RAG（Retrieval-Augmented-Generation）即检索增强生成，核心逻辑就是 “先搜再答”。

• 向量数据库选择 Chroma，而非 Milvus、LanceDB、pgvector 等，原因是 Chroma 部署简单、API 简洁、使用成本低。

• 注意：你需要的是 embedding model api，而非 llm api，Kimi、智谱等平台官网都提供对应的 embedding 模型。

• 恭喜你，你已经学会 RAG 了！

RAG 的本质¶

RAG 概念刚提出时，大家认为它包含「检索 - 增强 - 生成」三个环节，完整链路是： 文档 → 切块 → Embedding 向量化 → 存入向量数据库 → 用户提问时检索相似块 → 塞入 Prompt → LLM 生成回答

但实际落地中，大家最终只用到了检索能力，向量数据库（VectorDB）就能完美完成这个任务。

因此 RAG 是个已经过时的概念，你只需要掌握 VectorDB 即可，或者说 RAG = VectorDB。

四、实现 Tool、MCP、Skill（阅读需约 1 小时）¶

基础定义¶

• Tool：process call（function call），本质是调用一个函数

• MCP：remote process call，对应后端的 RPC 概念，调用服务器上的函数

• Skill：local process call，调用本地的函数

三者本质上都属于 Tool 范畴。

发展历程¶

1. Tool 的起源 早期为了让 chatbot 不止能聊天、还能执行实际任务，诞生了 Tool 概念。实现方式各不相同，最常见的做法是在 prompt 中加入 function 的名称、参数、描述，要求 LLM 输出 JSON 格式，再调用对应函数。

2. MCP 的出现 为了解决 Tool 实现标准不统一的问题，Anthropic 制定了 Tool 标准 MCP（Model Context Protocol），让各类 Tool 可以远程 “即插即用”。只要提供 MCP 服务，就能让 AI 从 “只会聊天” 升级为 “能做事”，因此 2025 年各家公司都在大力推行自己的 MCP 服务。

3. Skill 的诞生 大家逐渐发现 MCP 的弊端：每次调用 LLM 时，都要在 prompt 中额外加入所有 MCP Tool 的信息（名称、参数、描述等），但大部分 MCP 服务实际使用率很低，反而造成性能下降和 Token 浪费。 Anthropic 在博客 Code execution with MCP: Building more efficient agents 中提出了解决方案：渐进式加载 + 多用代码执行，后续发布的 Skill 概念也与此一脉相承，核心就是渐进式加载和优先用代码执行任务。

Tool 设计原则¶

实际开发 Agent 不需要五花八门的 Tool，Linux 下的 bash、edit、find、grep、ls、read、write 就足以完成绝大多数任务，且效果很好。 Vercel 通过移除大部分 Tool，将 text-to-sql 准确率从 80% 提升到了 100%；pi-mono 的作者也提到，read、write、edit、bash 这四个工具就是构建高效 Coding Agent 的全部所需。

实践建议¶

可阅读 tools 目录和 examples/chatbot_with_tools 文件夹里的实现代码。

总结¶

MCP 是远程 Tool，Skill 是本地 Tool；尽量不要自定义 Tool，优先用 Linux bash 解决问题。

五、实现 Context / Memory（阅读需约 1 分钟）¶

• 短期 Context：最近几轮的完整对话内容

• 长期 Context：更早的对话历史，会经过一次总结压缩

• Memory = 短期 Context + 长期 Context

六、实现 Multi-Agent / Subagent / Agent Teams（阅读需约 1 小时）¶

• Multi-Agent 最初的设想是 Google 制定的 A2A（agent to agent）协议，让不同的 Agent 互相交互，但这个方案最终失败了。Multi-Agent 逻辑复杂，多数场景下性能还不如简单的 Single Agent，现实中也几乎没有 Agent 使用 A2A 协议交互。

• 但大家也发现了 Multi-Agent 的适用场景：实现上下文隔离、只回传压缩后的结果、避免主上下文被工具细节污染，以此提升 Agent 效果。可参考博客 How we built our multi-agent research system 深入了解。

• Subagent 概念由此发展而来，甚至出现了自定义 Subagent 的方案。但并不推荐自定义 Subagent，由 master agent 自动生成 subagent 是更简单高效的选择。

Agent Teams¶

Agent Teams 是当前最前沿的发展方向，它摒弃了主从式 Agent 结构，采用并行协作模式，能成倍提升效率，且 Agent 之间不会互相冲突，非常适合项目开发场景，目前行业内都在研究。 可参考资料：

• Claude 的 agent-teams 方案

• 博客 Building a C compiler with a team of parallel Claudes

• Cursor 的两篇博客：《扩展长时间运行的自主编码能力》《迈向自动驾驶代码库》

补充：Agent Teams 可以用 Tmux 简单实现，且效果很好。可参考文章 What I learned building an opinionated and minimal coding agent 中关于 tmux 的部分。

七、阅读和理解 pi-mono（阅读需约 4 小时）¶

• Openclaw 项目的底层就是 pi-mono，它是目前开源领域最优秀的 coding-agent。

• 为什么要学习 coding-agent：经过发展迭代，coding-agent 已经成为了通用 Agent，几乎能完成所有任务，且效果出色。

• 必看博客：What I learned building an opinionated and minimal coding agent

学习方法¶

clone pi-mono 项目后，不要直接肉眼读源码（代码大多是 AI 生成的），建议用 Claude、Cursor 等 AI 工具分析整个项目结构，要求 AI 生成 mermaid 架构图并写入 md 文件，通过 AI 的分析报告来理解项目内部逻辑。

核心模块¶

pi-mono 共有 7 个 package：pi-ai、pi-agent-core、pi-coding-agent、pi-mom、pi-tui、pi-web-ui、pi-pods，只需要重点看 pi-ai、pi-agent-core、pi-coding-agent 三个模块，其余可以忽略。

额外内容：达到面试 / 实习要求¶

学习需约 2 天 × 8 小时

如果你想找 Agent 相关工作 / 实习，或者想更深入理解 Agent，一定要学习这部分内容。PS：已经有很多同学通过这套教程拿到了实习 offer。

1. 面试考点与项目推荐（阅读需约 1 小时）¶

• Agent 面试只考察项目实践，没有八股文

• 推荐实战项目：实现属于你的 Openclaw，项目名可以命名为 XXXClaw（例如 PoiClaw）。 具体路径：基于 pi-mono 二次开发，对接 pm2 和 IM 接口。clone pi-mono 后，用 Cursor、Claude 等 AI 工具分析项目架构，重点理解 pi-ai、pi-agent-core、pi-coding-agent、pi-mom 模块，最终开发出自己的 coding-agent，并用 pm2 实现常驻运行、接入 IM 工具（预计耗时 2 天 × 8 小时）。

• 面试高频概念（理解流程即可，不要求全部实践）：Agent 效果可评估、提示词自动优化、Agentic Sandbox、Agent Teams

• 简历工具推荐：开源免费简历网站 [rxresu.me]\(rxresu\.me\)

• 避坑提醒：不要在简历上写 “智能客服项目（langchain/dify + rag）”，这类项目已经非常过时

• 掌握以上内容，就足以投递 Agent 相关实习岗位

2. Agent 效果可评估与提示词自动优化（阅读需约 15 分钟）¶

• Agent 效果可评估（难度较高）

• 提示词自动优化的设计思路与上述博客逻辑一致，核心是设计评估指标并持续观测

3. Agent Teams 深入学习（阅读需约 15 分钟）¶

• Agent Teams 核心概念，参考博客 Building a C compiler with a team of parallel Claudes

• 扩展长时间运行的自主编码能力（难度较高）

• 迈向自动驾驶代码库（难度较高）

4. Sandbox 相关知识（阅读需约 15 分钟）¶

• 掌握 Docker 即可，用 Docker 做 Sandbox 能应对绝大多数场景

• 对延迟要求极高的场景，需要专门的 Agentic 基础设施优化延迟（复杂度高，做基础了解即可）

• 推荐阅读：《为本地代理实现安全沙箱》

5. Harness 相关知识（阅读需约 15 分钟）¶

• Harness 概念来源于 OpenAI 2026 年 2 月 11 日的文章《工程技术：在智能体优先的世界中利用 Codex》。虽然这篇文

（注：部分内容可能由 AI 生成）

AI Agent 工程师成长指南¶

背景与现状¶

6 年经验后端 → 转 AI Agent 是正确方向。现在懂 System Design 又懂 AI 应用落地的工程师（AI Engineer）确实是稀缺物种。后端转 Agent 优势非常大——很多算法工程师写出来的工程代码没法看。Agent 落地到最后，拼的是工程能力、系统稳定性、并发处理、数据流转，这些都是后端的看家本领。

警惕：千万别信网上那些三天速成课。那些教程大部分是拿个 LangChain 的 Demo 跑一下，跑通了 Hello World 就告诉你学会了。真到了生产环境，这种代码上线就是事故。

打破认知误区：Agent 并非简单调 API¶

很多后端兄弟觉得，Agent 不就是调 API 吗？这是初级阶段。现在的 Agent 工程，本质上是在写 概率性代码。以前写后端，输入 A 必然得到 B，这是确定性的。现在写 Agent，输入 A，可能得到 B，也可能得到 C，还可能给你胡说八道。你要做的是用工程手段，把这个概率性的过程约束在一个可控的范围内。

需要恶补的内容¶

（1）Prompt Engineering 进阶学习¶

• 推荐资料：OpenAI 官方 Cookbook（最好教材）、Lilian Weng《LLM Powered Autonomous Agents》（Agent 领域圣经）
• 重点内容：Chain of Thought 思维链、ReAct 推理加行动模式

（2）开源模型与私有化部署¶

2026 年的标准答案是 DeepSeek 系列和 Qwen 3 系列： - DeepSeek 系列：DeepSeek-V3.2 和 R1 版本，推理能力和 Agentic 任务处理能力已能和闭源顶尖模型掰手腕 - Qwen 3 系列：企业内部超一半私有化部署在用 Qwen 3，尤其是 Qwen3-Thinking 版本

（3）RAG 技术深度掌握¶

2026 年的主流是 GraphRAG（结合知识图谱的检索增强生成），需要了解怎么把非结构化文本提取成实体和关系，存到图数据库里。

除了 GraphRAG，还要了解 Adaptive RAG——让 Agent 自己判断是直接回答、查数据库还是查互联网。

框架选择： - Haystack：生产级 RAG 首选，Pipeline 设计清晰，监控和可视化做得好 - LlamaIndex：在复杂索引和 GraphRAG 支持上最强 - 别死磕 LangChain，封装太厚，调试像黑盒

LangGraph 与 Agent 状态机实现¶

Agent 本质上就是一个有状态的循环系统：

Start → 思考 → 决定调用工具 → 执行工具 → 拿到结果 → 再次思考 → End

自学时不要光看，要动手写： 1. 不要用 LangChain，尝试用原生 Python 代码手写一个 ReAct 模式的 Agent 2. 定义一个 While 循环，在循环里维护一个 Messages 列表模拟内存 3. 定义几个 Python 函数作为工具，传给模型的 Function Calling 接口

当你亲手把这个循环跑通，看到模型自己决定调用你的函数，拿到结果后再组织语言回答的时候，你就入门了。

实战项目：打造 P7 水平的 SQL Agent¶

技术组合：RAG 检索表结构说明 + Few-shot 优秀 SQL 示例 + Code Execution Environment 安全执行。

难点： 1. 数据库表结构怎么告诉模型？→ Schema Linking 2. 模型生成的 SQL 要是错的怎么办？→ Self-Correction 3. 怎么防止模型执行删库跑路的操作？→ 权限控制

2026 年还可以加 Multi-Agent：设计 Writer（写 SQL）+ Reviewer（检查语法错误）两个 Agent 互相交互，直到产出正确的 SQL。

工程化能力：Agent 上线关键问题¶

面试官问：Agent 上线了，响应太慢怎么办？幻觉严重怎么办？

从工程角度回答： 1. 流式输出 Streaming：不用等整个答案生成完，一个字一个字往回吐 2. 缓存 Caching：相似问题用语义缓存返回结果 3. 评测 Evaluation（重点中的重点）：用更强模型给弱模型打分（LLM-as-a-Judge）、Ragas 框架评测 RAG 系统、Langfuse / Ariane Phoenix——主流 Trace 和评测平台

如果面试时能拿出一套自己设计的自动化评测方案，证明你的 Agent 在准确率上提升了 10%，这比说精通 Python 有用一万倍。

17.7 学习路径与资源汇总¶