零基础一天 （9小时）学完agent！写这个教程就是想告诉大家，Agent其实非常简单！ 并且能帮助你找到 Agent相关工作/实习！目前有很多个同学看我的教程找到了实习，且本教程在同学群里备受好评，现在开源给大伙！
-
拥有你自己的llm api-key（阅读需约15分钟）
- 你可能需要学会使用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，推荐DeepSeek、kimi或者智谱
- 配置环境变量
OPENAI_API_KEY和OPENAI_BASE_URL，并且尝试运行core/llm.py
-
实现 Node / Workflow / Agent （阅读需约1小时）
- 我们最终的目标是造一个Agent，能够联网搜索、运行命令行、文件编辑。
- Agent底层可以使用Node来抽象，我已经准备好了一个极简的实现，可以看
core/node.py，不到60行就实现了一个Agent的轻框架，实在是太容易理解了！如果没有py基础看不懂，可以把代码复制给ai让它来解释。 - 但我们应该怎么去用Node呢，我们可以新建3个Node并把它们串起来实现功能
接收输入->上网搜索->大模型生成总结，恭喜你已经实现了workflow，相关实现已经在examples/workflow - 现在新建个workflow，实现功能
接收用户输入->大模型回复，并且loop反复调用这个workflow，恭喜你已经实现了chatbot，相关实现已经在examples/chatbot - 现在尝试给chatbot一些tools(下文会详细讲tool)，让它能够上网搜索东西、编辑文件、运行命令行，恭喜你已经实现了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开发出来好产品，以及langchain还出过非常严重安全漏洞 CVE-2025-68664，以及存在过度抽象、依赖地狱、bug多、不灵活难以定制等问题。事实上优秀的agent都是采用自己搭建轻框架来开发的，例如claude-code、cursor、kimi-cli、pi-mono、Pocketflow-examples等等，所以非常推荐自己搭建轻框架或者直接调用llm api来开发。
-
实现 RAG （阅读需约1小时）
- 选择 Chroma 而不是Milvus、LanceDB、pgvector等等，因为Chroma部署简单、api简洁使用成本低
- 注意，你可能需要一个 embedding model api 而不是 llm api，你可以在Kimi、智谱等官网找到对应的 embedding 模型
- 恭喜你已经学会了rag！！！
- 为什么这就是全部了，真有这么简单？是的这就是全部，当初提出 RAG(Retrieval-Augmented Generation) 概念时，可能觉得得有 检索-增强-生成 这三个功能。
- 但实际上大伙最终只用到了检索，VectorDB 就能很完美执行这个任务
- 所以 RAG 是个很过时的概念，大伙只想要一个 VectorDB 而已，或者说 RAG=VectorDB
-
实现 Tool、MCP、Skill （阅读需约1小时）
- Tool: process call (function call)，也就是调用了一个函数
- MCP: remote process call 也就是后端里面的 RPC 概念，调用了服务器上的一个函数
- Skill: local process call 也就是调用了本地的一个函数
- 它们其实本质上都是 Tool
- 为什么Tool会有这么多形式？这就不得不说Tool的发展历程。
- Tool来源：在早期大伙为了chatbot不只是chat，而是实际做些事所以出现了Tool，实现Tool的形式各不一样，最常见的就是输入llm的prompt中里面加入function（等同于tool）的name、parameters、description并且要求llm输出json格式，最后再调用对应的function。
- MCP来源：为了解决Tool实现参差不齐的现象，anthropic定了一个Tool的标准，也就是MCP(Model Context Protocol)（感觉不如叫Remote Tool Protocol更易读），让各个Tool能够远程“即插即用”，看起来非常棒只要提供了MCP服务就能实现ai从just chat到do something的转变，于是2025年各个公司疯狂都在推行自己的MCP服务
- Skill来源：但人们渐渐发现了MCP的弊端：每次调用llm时候，都会把在prompt额外加上MCP的所有Tool的信息（包括name、parameters、description等等），发现大部分MCP服务并没有想象的那么有用，以及导致性能变差以及token浪费，anthropic在blog描述了这件事 Code execution with MCP: Building more efficient agents，并分享了它们的解决方案，就是渐进式加载和多用代码执行，后来anthropic发布了skill就和这个差不多，重点就是渐进式加载和多用代码执行。
- 设计Tool：实际Agent并不需要那么多五花八门的Tool，最重要的是linux中的bash、edit、find、grep、ls、read、write命令，这些就已经能做很多事且做得非常好，Vercel通过移除大部分的Tool反而提高了text-to-sql从80%到100%，以及pi-mono极简coding-agent作者提到这四个工具就是构建有效 Coding Agent 所需的全部：read、write、edit、bash
- 实践：可以阅读
tools和examples/chatbot_with_tools文件夹里的实现 - 总结: MCP是Remote Tool，Skill是Local Tool，尽量不要设计Tool并且优先用linux的bash来解决问题
-
实现 Context / Memory 管理（阅读需约25分钟）
- 对话 Memory：把用户和助手的每条消息追加写入
chat_memory/session.jsonl，下次启动时可以继续接上之前的对话。 - 长期 Memory：把用户偏好、重要事实、运行环境等值得长期记住的信息写入
chat_memory/MEMORY.md。 - Memory = 对话 Memory + 长期 Memory。对话 Memory 负责“记住刚才聊了什么”，长期 Memory 负责“记住以后也可能有用的信息”。
- 为什么需要管理 Memory：大模型的上下文窗口有限，消息越聊越多，迟早会超过模型能接收的长度。所以在接近上下文上限前，需要把较早的对话压缩成摘要。
- 摘要压缩会丢失细节，所以不要太早压缩。当前实现会读取大模型 API 返回的
usage.total_tokens，当 token 数超过最大上下文长度的 90% 时触发压缩。 - 压缩时，较早的消息会变成一条“对话历史摘要”，最近几条消息会原样保留。因为工具调用消息必须成组出现，所以代码会避免把
assistant的tool_calls和后续tool结果拆开。 - 我们尽量让已有对话内容保持不变，新消息追加写入
session.jsonl。这样更容易命中大模型服务商的 prefix KV Cache，让相同前缀的上下文复用缓存，生成速度可能更快。 - 实践：可以阅读
/core/memory.py和/examples/chatbot_with_memory文件夹里的实现。运行示例后，可以在默认记忆目录chat_memory/下看到session.jsonl和MEMORY.md。 - 总结：Memory 管理主要是为了防止上下文超长；摘要让模型还能知道之前发生过什么；长期记忆把重要信息从普通聊天记录里单独保存下来。
- 对话 Memory：把用户和助手的每条消息追加写入
-
实现 Multi-Agent / Subagent / Agent Teams （阅读需约1小时）
- multi-agent最初设想用google制定的A2A(agent to agent)协议，让不同地方的Agent进行交互，但这个设想失败了，multi-agent效果复杂且大部分性能还不如简单的single agent，且现实中没看到过agent用A2A协议进行交互
- 但大伙发现有些场景可以用multi-agent来实现上下文隔离、只回传压缩结果、避免主上下文被工具细节污染，这样能提高agent的效果，可以看这个blog了解multi-agent到底是什么How we built our multi-agent research system
- subagent概念由此发展出来，甚至推出了自定义subagent。但我并不推荐自定义subagent，毕竟由master agent来自动生成subagent总是个简单高效的选择
- Agent Teams则是目前最前沿的发展方向，摒弃了主从的agent结构，而采用并行的方式，能够成倍效率且agent间不冲突地开发项目，这是十分有价值的，大伙都在研究，可以参考claude的agent-teams以及blog Building a C compiler with a team of parallel Claudes 还有cursor的blog 扩展长时间运行的自主编码能力 和 迈向自动驾驶代码库
- 顺便一提Agent Teams可以通过Tmux来实现简单且效果非常好！可以看这个文章What I learned building an opinionated and minimal coding agent里面的tmux部分
-
阅读和理解 pi-mono （阅读需约4小时）
- Openclaw项目的底层就是pi-mono，pi-mono就是世界上开源里最好的coding-agent
- 你为什么应该学习这个 coding-agent 项目，因为 coding-agent经过时代的发展已经成为了通用 agent，它可以几乎做任何事情且效果很好
- 一定要看 blog What I learned building an opinionated and minimal coding agent
- clone pi-mono，然后使用你的claude、cursor等等ai来分析整个项目的结构并且要求有mermaid图写到md里，你就能理解pi-mono它内部是怎样的，因为代码都是ai写的，所以不推荐肉眼看源码，你应该让ai分析项目，然后你去读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，其他的不需要看呢
-
把 pi-mono 改造成 你的 OpenClaw（阅读约1小时）
- git clone https://github.com/badlogic/pi-mono.git
- cd pi-mono && git checkout 3ffc2b43
- 注意：pi-mono 在 2026-04-30 的 0ed0d434 提交移除了 packages/mom，下面的 mom 改造和 Slack 接入方式都依赖旧版 mom，所以需要 checkout 到移除前的提交
- 安装 pm2: 后台长期运行且崩溃后自动重启
npm install -g pm2 - 因为pi-mono写了hardcode强制用sonnet-4.5，我们要自定义模型的BASE_URL和模型id，所以修改./pi-mono/packages/mom/src/agent.ts，
const model = getModel("anthropic", "claude-sonnet-4-5");在这行下面写
model.id = process.env.ANTHROPIC_MODEL_ID || "claude-sonnet-4-5";
if (process.env.ANTHROPIC_BASE_URL) model.baseUrl = process.env.ANTHROPIC_BASE_URL;
- 准备好你的llm api，你需要添加下面环境变量，下面是以kimi举例，
export ANTHROPIC_MODEL_ID=kimi-k2.5
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
export ANTHROPIC_API_KEY=sk-m7q...
- 参考 im 接入方式slack-bot-minimal-guide，后面会更新飞书接入方式
- 运行
npm install，然后启动pm2 start packages/mom/dist/main.js --name mom --interpreter node -- --sandbox=host ./packages/mom/data - 恭喜你！你已经打造了属于你自己的OpenClaw，你可以去到Slack上与你的OpenClaw聊
- /goal 解锁长时间运行的agent
- 前面我们已经实现了
chatbot_with_tools：用户输入一句话，agent 搜索、读文件、运行命令，最后回复用户。 - 但它还是“一句话，跑一轮”。回复完，这一轮就结束了。
- 长任务不能这样。比如目标是“测试覆盖率达到 90%”，agent 跑了几分钟，做到 80% 就停下来等你催，这是不对的。
- 所以我们参考 Codex 的
/goal，给 agent 加一个长时间目标。设置了 goal 后，agent 就围绕这个 goal 一直跑，直到真的完成。 - 例如用户输入：
/goal 测试代码覆盖率达到90% - 程序会设置：
goal = "测试代码覆盖率达到90%"goal_active = True
- 后面每次 agent 自己停下来，只要
goal_active还是True，程序就自动提醒它继续完成这个 goal。 - 如果目标完成了，agent 必须调用
goal_complete。这个 tool 会把goal_active改成False，goal loop 才会结束。 - 最小实现可以看
examples/agent_with_goal。这个例子只是在原来的工具 agent 外面包了一层run_goal()。
- 前面我们已经实现了
如果你需要找Agent相关工作或者实习，又或者为了更深刻理解Agent，一定要看这一部分。 PS: 已经很多同学通过看我的教程找到了实习。
-
了解面试都会问什么，以及项目推荐（阅读需约1小时）
- agent 面试只问项目，没有八股
- 问你的项目，推荐实现你的 Openclaw，项目名字就写XXXClaw，例如我就写PoiClaw。具体为实现 pi-mono 和调用 pm2 以及 im 接口，clone pimono然后使用你的cursor、claude或其他ai工具，让它分析pi-mono整体架构流程看看分为哪些模块，其中只需要看pi-ai、pi-agent-core、pi-coding-agent、pi-mom这些模块，vide coding出来，最终你能实现一个属于你自己的coding-agent，然后使用pm2让它长期跑以及接入im（可能需要2天 * 8小时来完成）
- 可能会问以下内容，所以你需要知道整个流程运转（但不一定要实践出来）：Agent 效果可评估、提示词自动优化、Agentic Sandbox、Agent Teams
- 推荐编写简历的开源免费网站rxresu.me
- 注意不要写智能客服项目(langchain/dify + rag)，这真的很过时了
- 已经足够去实习面试了
-
关注 Agent 效果可评估 与 提示词自动优化（阅读需约15分钟）
- agent 效果可评估（较难）
- 提示词自动优化的设计思路和上面这个 blog 差不多，需要设计指标并观测
-
关注 Agent Teams（阅读需约15分钟）
-
了解 Sandbox（阅读需约15分钟）
- 用过 docker 就行了，使用docker作为sandbox可以应对绝大多数场景
- 部分对延时要求非常高的场景，需要做专门的agentic infra来优化延时（太复杂了了解下就好）
- 推荐阅读 为本地代理实现安全沙箱
-
了解 Harness（阅读需约15分钟）
- Harness 来源于 OpenAI 2026 年 2 月 11 日的文章 工程技术：在智能体优先的世界中利用 Codex。虽然这篇文章介绍了 Harness，但它仍然是一个很模糊的概念，我看完也不能理解 Harness 具体是指哪一项东西哈哈🤣。
- 可以先把 Harness 理解成：给 AI 一个更好的运行环境，让 AI 跑起来更流畅，更好地去使用 Agent。
- 我现在理解的 Harness 里，其中一种就是 PRD2PR，也就是从产品需求文档自动推进到代码变更和 Pull Request，这类实践已经有很多企业在做了。
- 看这个文章：Why Your “AI-First” Strategy Is Probably Wrong