项目名称
- 中文名：
Agent 那些事儿 - 仓库名：
agent-things
AI 应用开发过程中，以“问题驱动”方式整理的学习笔记。
以“遇到问题 → 产生需求 → 诞生解决方案”的演进逻辑，从 Function Calling 一路学到 Agent OS，覆盖大模型应用工程的完整技术栈。最终以开源项目的形式发布，帮助更多同路人。
在做 AI 应用开发的过程中遇到了一个结构性的困境：
市面上不缺知识。论文、博客、官方文档、开源框架，多到溢出。但它们几乎都是按知识点分类的：这里一篇 RAG 教程，那里一篇 Agent 框架对比。
读完之后知道了很多“是什么”，但始终不清楚：
这些东西为什么会出现？它解决了谁的什么问题？它和上一个方案之间是什么关系？
碎片化的知识像散落的拼图，你拿到了每一块，但没有盒子上的完整图案。
一条有因果链的学习路线。不是“你应该学这些知识点”，而是“这些技术为什么会按这个顺序出现”。
这条路线在 2026 年 4 月的今天并不存在。所以我决定自己整理一份。
后端工程师学分布式系统，不是先背 Paxos 再背 Raft，而是：
单机扛不住了 → 要加机器 → 数据怎么一致？→ Paxos → Paxos 太难落地 → Raft
每一个方案都是对上一个问题的回应。没有前一个问题，后一个方案就没有存在的意义。
LLM 应用工程的演进也是这样一条因果链：
| 遇到的问题 | 诞生的解决方案 |
|---|---|
| 模型只会聊天，不会做事 | Function Calling |
| 模型知识有截止日期，私有数据不知道 | RAG |
| 工具接入碎片化，每家格式不一样 | MCP 协议 |
| 单次调用不够，需要多步规划执行 | Agent |
| Agent 反复编排相同的工具组合 | Skill 封装 |
| 每次对话都从零开始，跨会话失忆 | Memory |
| 检索策略越来越多，需要智能调度 | Agentic RAG |
| 单 Agent 搞不定，需要专业分工 | Multi-Agent + 协议栈 |
| 零件齐了，怎么组装成可用的产品 | Agent OS |
| Demo 和生产之间的鸿沟 | 工程实战 |
把这条链讲清楚，比把每个知识点讲透更重要。
每一项技术背后都有一个具体的事件：谁、在什么时间、面对什么问题、发布了什么。
你不需要先读 MCP 协议规范全文。你只需要知道：2024 年 11 月，Anthropic 发现 Function Calling 的碎片化已经严重阻碍了 Agent 生态，OpenAI、Claude、Gemini 各有各的格式，工具开发者要适配三遍，于是提出了一个标准化协议层。
知道了“为什么”，“是什么”自然就好理解了。
把技术挂在事件上，学习就有了时间感和因果感，不再是悬浮在空中的概念。这也是为什么本项目梳理了从 2017 年 Transformer 到 2026 年的 67 个关键事件。它们不是附录，而是叙事骨架。
AI 应用开发的资料大多出自两类人：AI 研究者（偏理论）和全栈独立开发者（偏 Demo）。
但真正在企业里把 AI 能力落地成产品的，往往是从后端 / 基础架构转型过来的工程师。
后端工程师天然关心的问题，可靠性、可观测性、协议标准化、系统分层、错误恢复，恰好是 AI 应用从 Demo 走向生产最缺的那一环。
这份笔记带着后端的思维惯性去审视 LLM 应用工程，这不是局限，而是一种独特的切入角度。
- 将零散的学习过程结构化，从“用过这些工具”变成“理解这条演进链”
- 写下来的过程就是整理思路的过程，写不清楚说明没想明白
- 提供一条有因果逻辑的学习路径，不用在碎片化资料中自己拼图
- 每章从“痛点”开始，天然解决“我为什么要学这个”的动机问题
- 67 个关键事件串联的时间线，本身就是一份有价值的行业演进记录
- 抽象概念配真实例子、真实交互和系统视角，帮助建立更稳的工程认知
这三个层级各自回答不同的问题：
README.md：这是什么，为什么值得读，应该怎么读TIMELINE.md：这些技术是怎么一步步出现的，为什么会在那个时间点出现- 各章
README.md：某个具体问题是怎么被解决的，方案又留下了什么新问题
如果你是第一次进入这个项目，最推荐的顺序是：
- 先读当前这份
README，理解项目立场和整体主线。 - 再读
TIMELINE.md，把 67 个关键事件放回一条连续的历史骨架里。 - 最后按
Ch0 -> Ch10进入章节正文。
完整时间线在 TIMELINE.md，但如果你先想抓住全局，可以先看这五个阶段：
- 2017 — 2022：基础奠基
Transformer、RLHF、ChatGPT 让模型具备了“会说话”的能力，但系统边界也同时暴露出来。 - 2023：工具与框架涌现
Function Calling、Plugins、AutoGPT、MetaGPT 让行业第一次认真尝试“让模型做事”。 - 2024：能力跃升与协议萌芽
长上下文、多模态、推理模型和 MCP 同时出现，模型开始真正接入外部世界。 - 2025：Agent 产品化与协议栈成型
Agent 从概念验证走向产品，协议分层和工程化设计开始成形。 - 2026：Agent OS 与多 Agent 时代
系统视角成为主角，多 Agent、Harness Engineering 和产品级架构被公开学习。
如果你更关心“时间线最终是怎么映射到章节里的”，可以直接跳到 TIMELINE.md 的章节映射部分。
| 章次 | 主题 | 引出的下一问题 |
|---|---|---|
| 第 0 章 | 被困在房间里的天才（LLM 的能力边界） | 模型需要“手”和“工具” |
| 第 1 章 | Function Calling — 让模型学会使用工具 | 模型知道怎么做了，但仍然不知道训练外的新知识 |
| 第 2 章 | RAG — 让模型获取外部知识 | 工具接入和数据接入都开始碎片化 |
| 第 3 章 | MCP — 工具与数据接入的标准化 | 有了能力接入，但还缺多步规划与执行 |
| 第 4 章 | Agent — 自主规划与多步执行 | Agent 反复重做相同流程，缺少能力封装 |
| 第 5 章 | Skill — 可复用的能力封装 | 会做事了，但系统还会失忆 |
| 第 6 章 | Memory — 给 Agent 装上长期记忆 | 检索仍然是一条静态管线 |
| 第 7 章 | Agentic RAG — 当 Agent 接管检索 | 单 Agent 开始逼近上限 |
| 第 8 章 | Multi-Agent 与协议全景 | 零件齐了，怎么组织成产品级系统 |
| 第 9 章 | Agent OS — 从组件到产品级系统 | Demo 和生产之间还有巨大鸿沟 |
| 第 10 章 | 工程实战 — 把 Agent 推向生产 |
| 专题 | 内容 | 学习价值 |
|---|---|---|
| A：Claude Code 源码泄露 | 2026.03 npm 包意外包含完整源码 | 目前最详实的产品级 Agent 系统设计公开资料 |
| B：协议之战 | MCP vs A2A vs ACP 三层协议栈 | 理解“为什么需要分层”而非“该选哪个” |
| C：Coding Agent 演化史 | 从 AutoGPT 到 OpenClaw | 理解 Agent 产品化的完整演进脉络 |
| D：Manus 与 Prompt 泄露 | System Prompt 泄露与安全反思 | Prompt Injection 是 Agent 时代的 SQL Injection |
| E：Zed ACP | AI 编码工具的 “LSP 时刻” | 理解 Agent 系统的前端协议层 |
原始设想里，每一章都可以有代码实践、可运行 lab 和更完整的工程实验。
但当前第一版的重点，不是先把整套内容做成代码课，而是先把问题和解法讲清楚。
所以当前版本优先做的是：
- 把 11 章主线讲顺
- 把章节统一成可公开阅读的长文 README
- 用真实例子、真实交互和真实数据形状把抽象概念讲具体
等整条叙事真正稳定下来，再决定哪些章节适合补代码、补 lab、补可运行示例。
这套内容原本的理想结构，仍然成立：
| 模块 | 内容 | 作用 |
|---|---|---|
| 问题引入 | “上一章的方案在 X 场景下失败了” | 建立学习动机 |
| 历史背景 | 关键事件、时间、发起者 | 建立时间感 |
| 概念讲解 | 核心原理、架构图、对比表 | 理解“是什么” |
| 真实例子 / 交互 | 具体数据形状、请求响应、运行轨迹 | 理解“系统里到底发生了什么” |
| 深入剖析 | 设计决策、trade-off、反直觉洞察 | 理解“为什么” |
| 遗留痛点 | 本章方案的局限，引出下一章 | 保持演进链 |
当前仓库里的第一版，优先保证这条叙事链不断裂。后续如果补代码，也会服务于这条主线，而不是反过来挤压它。
为了让定位更锐利，明确划定边界：
- 不是模型训练教程
聚焦应用层工程，不涉及预训练、RLHF、模型量化。 - 不是框架使用文档
不教“怎么用 LangChain”，而是讲“LangChain 要解决什么问题”。 - 不是知识百科
只保留因果链上的关键节点，有意识地做减法。 - 不是纯客观综述
会标注“我认为”和“行业共识”的区别，保留个人判断。 - 不是面向 AI 研究者的
面向想用 LLM 构建产品的工程师。
主要受众
有后端 / 系统编程基础，正在或准备转型 AI 应用开发的工程师。
典型画像
- 熟悉至少一门后端语言，有 API 设计和系统架构经验
- 用过 ChatGPT / Claude 等产品，对 LLM 有直觉但缺乏系统认知
- 试过一些 LLM API 调用或 RAG Demo，但不确定“下一步该学什么”
- 关心“怎么在生产环境跑起来”，而不只是“怎么跑通一个 Demo”
次要受众
任何对 LLM 应用工程全貌感兴趣、希望建立系统认知的技术人。
- 因果链优先
宁可少覆盖一个知识点，也不能断裂章与章之间的因果逻辑。 - 事件驱动叙事
每项技术都锚定在具体的历史事件上，有时间、有人物、有背景。 - 故事优先于代码堆砌
第一版先把问题和解法讲清楚，不急着把每章都做成代码课。 - 例子必须具体
抽象概念尽量配真实例子、真实交互或真实数据形状。 - 诚实标注主观
个人观点用“我认为”标注，与行业共识区分。 - 渐进式深入
同一个概念可以在不同章出现，每次加深一层，不要求一次讲透。