Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第 0 章:从 Chatbot 到 Agent — 这本书带你建什么

一句话定位:在你打开终端写第一行代码之前,先用一章的篇幅讲清楚 chatbot 和 agent 到底差在哪、我们最终要造什么、十个章节是怎么把它一步步搭起来的。

如果你只是想“现在就开始干活“,直接跳到第 1 章也行,代码和命令都是自洽的。但如果你时不时会冒出“我现在到底在做哪一部分?为什么要这么做?“的疑问,这一章是来解决那个问题的。

0.1 你已经用过的 Chatbot 是怎么跑的

打开 ChatGPT、Claude.ai、Gemini、文心一言里随便一个,你提一个问题,它给一段回答 —— 这就是 chatbot。它的工作流程其实只有四步,而且短到可以一张图说完:

图 0-1:一问一答的 Chatbot 长什么样

用户发一句话,服务转交给 LLM,拿到回答原样回送 — 就这么四步 一问一答 Chatbot 单回合 · 无状态 · 仅文本输出 用户 输入一段话 Web 服务 转给 LLM LLM 生成一段文字 回答 回送给用户 下一句话来时,整段历史要么手动重发、要么靠前端缓存 — 服务本身记不住任何东西

它能做的事情有上限:回答你能用一段文字解决的问题。翻译、改文案、写一段代码、解释一个概念 —— 这些都行。但你让它“帮我把这个仓库里所有 lint 报错改掉、跑一遍测试、给我提个 PR“,它就傻了 —— 它没有“动手“的能力,也没有“长期记得这个项目“的能力。

下一节我们就从这个 chatbot 出发,一步一步把它升级成 agent。每一步只加一项能力,看看新加的这一项让它多了什么本事。

0.2 把 Chatbot 一步步升级成 Agent

我们要加四样东西:身份 + 记忆 → 工具循环 → 副作用与持久产物。每一步配一张图。

第一步:给它一个“身份“,顺便就有了“记忆“

先解决最浅、也最直觉的问题:chatbot 不记得你之前说过什么。

把 chatbot 升级成 agent 的第一刀,是给每一个用户/会话分配一个独立的、有名字的实例。这个实例本身存着对话历史,所以下次同一个名字的请求进来,服务自己就知道“哦上次我们聊到 X 了“。前端不用每次把整段历史重新塞进 body。

图 0-2a:Chatbot + 身份 + 记忆

为每个会话开一个有名字的实例,实例本身存对话历史 + 身份 / 记忆 每个 user 一个有名字的实例,自己存历史 用户 不用带历史 Agent 实例 user-42 LLM 调用 对话历史(SQLite,实例自己存) 回答 流式给用户 同一个名字第二次请求时,还是这个实例,带着上次的对话继续聊 — 不用前端往返带 history

到这一步,你已经从 chatbot 升级成了“有记忆的对话机器人“。但它还是只能输出文字 —— 跟它说“读一下 src/index.ts“,它只能回“我看不到你的文件,你贴给我吧”。

下一步把这个限制砸掉。

第二步:让它能“动手“ — 工具循环

LLM 输出的内容不一定是文字,也可以是“我要调一个叫 read_file 的函数,参数是 src/index.ts“。

agent 框架看到这种输出之后,真的去调那个函数,把返回结果再塞回 LLM,LLM 看到内容再决定下一步。这一来一回叫“工具循环“,一次任务可能循环几十轮 —— LLM 可能先 list_files 看目录、再 read_file 看具体文件、再 grep 搜某个 symbol、最后才下结论。

图 0-2b:再加上 — 工具循环

LLM 输出工具调用,系统真的执行,把结果回塞 LLM,循环若干轮直到给出最终回答 + 工具循环 LLM 想 → 调工具 → 看结果 → 继续想 …… 用户 提需求 Agent 实例(带记忆) LLM 思考 下一步该干啥? 工具调用 read_file / grep / curl 想 → 干 → 看结果 → 再想 …… 对话历史 + 工具调用历史(都自动存) 最终回答 几十轮之后给 这一坨"想 → 干 → 看 → 再想"的循环,就是"agent 比 chatbot 多出来的那一截"

到这一步,你已经能让 LLM 操作“虚拟的“东西 —— 它能读你的文件、搜你的代码、调你的内部 API。但所有这些动作都还是只读的,或者只是临时算个值给你看,没有改变外部世界

下一步让它真的能改。

第三步:让它能产生“副作用“和“留下东西“

工具循环里的工具,可以是只读的(read_filegrep),也可以是写的(write_filegit pushsend_emailrun_shell)。

写工具就意味着 agent 会改变外部世界:改文件、推 PR、发邮件、给数据库写一行。同时它产出的代码、报告、日志也得真的存下来,不能跟着会话生命周期消失。

到这一步,你才有了一个真正的 agent

图 0-2c:再加上 — 副作用 + 持久产物

工具循环里的写操作产生外部副作用,代码与报告落到持久产物存储里 + 副作用 / 持久产物 工具不再只读 — agent 真的改外部世界,产物落地保存 用户 提需求 Agent 实例(带工具循环 + 记忆) LLM 思考 下一步该干啥? 工具调用(读 + 写) read / write / shell / api 对话历史 / 工具调用历史 / 学到的事实 沙箱 / 文件系统 — 跑命令的地方 文字回答 流式给用户 外部副作用 推 PR / 发邮件 / 写文件 持久产物 代码 / 报告 / 日志 从这里开始,agent 跟用户的关系不再只是"问答" — 它接活,产生看得见的成果

把上面三步串起来,agent = chatbot + (身份 + 记忆) + 工具循环 + (副作用 + 持久产物)

每一步都不是空想:身份解决“是谁“,记忆解决“在哪“,工具循环解决“能干啥“,副作用 + 持久产物解决“干完留下了什么“。少任何一项,agent 就退化成 chatbot 或者一次性脚本。

到这里可能会出现一个直觉问题:“既然这么强,我自己写个 Express + OpenAI SDK + Postgres 不也能拼出来吗?”

技术上能。但你会被四件事拖累:怎么给每个用户分配一个独立的、有身份的实例?状态怎么持久化才不会丢?进程死了任务怎么从中断点继续?跑用户代码的沙箱怎么开,跑完怎么销毁? 这些每一件单独看都不难,但加在一起够你写半年。

Cloudflare 的回答是:这些零件我都给你准备好了,你只用拼。

0.3 给 Agent 找一个家:为什么是 Cloudflare

Cloudflare 在 2026 年的 Agents Week 上把它的“agent 平台“凑齐了。不是一两个产品,而是一整套配合:

图 0-3:Cloudflare 给 agent 准备的零件

Cloudflare 把 Worker、Durable Object、AI binding、Sandbox、R2、Email、Browser、Workflow 等十多个 primitive 拼成一套 agent 平台 Agent 的平台:Cloudflare 全家桶 Worker + Durable Object agent 的"身体" 每实例独立 / 边缘运行 AI Platform env.AI = 70+ 模型统一接入 Sandbox 隔离容器跑用户代码 Session API 树形对话 + FTS5 全文检索 Agent Memory 语义记忆 + 自动召回 R2 / Artifacts 文件 / 版本化产物 Workflows 长任务 / 持久执行 / 重试 Email Service 收 / 发邮件作为接口 Browser Run 让 agent 操控浏览器

这张图传达的核心是:核心是中间那块 Worker + Durable Object —— agent 的“身体“。所有外圈的能力都是它的延伸。 你不用自己搭 Postgres、不用自己开 EC2 跑沙箱、不用自己写 retry 逻辑。每个圈圈都是一个能在 wrangler.jsonc 里加一行就用上的 binding。

至于为什么不在自己服务器 / Vercel / Lambda 上做这件事,有三个具体理由:

  1. agent 需要“身份“。每个用户、每个会话都是一个有自己 SQLite 的独立实例 —— 这正是 Durable Object 的天职。在普通后端框架上要拿 Postgres + Redis + 一堆死锁姿势模拟。
  2. agent 用户来自全世界。Cloudflare 的 Worker 默认就跑在最靠近用户的边缘节点;agent 实例本身也会被自动迁移到合适的位置。低延迟不需要你额外做事。
  3. Cloudflare 把“agent 闭环要的零件“补齐了。沙箱、邮件、浏览器、长任务、artifacts —— 这些原本要拼 5+ 家服务的功能,现在都在同一份账单、同一份控制面板里。

0.4 这本书最终给你的东西:agent-coder

我们不是在写一个抽象 demo,是在搭一个agent-coder 的真实工具。读完十章你会有这样一个东西:

图 0-4:agent-coder 完成形态长什么样

agent-coder 接 issue、读代码、改代码、跑测试、推 PR、发邮件 — 完整闭环都在 Cloudflare 上完成 agent-coder:接 issue、改代码、推 PR 的完整闭环 用户 / 浏览器 chat UI 提需求 GitHub webhook issue 触发 收件邮箱 回邮件即可 CoderAgent extends Think · 跑在边缘 DO 里 流式 LLM 树形 Session Code Mode 人类审批 Skills Memory 长任务编排:Workflow + 子 agent 限流 / 可观测 / 灰度(上线必备) Sandbox 容器 npm install / pytest R2 / Artifacts 代码 / 报告版本化 GitHub App 读代码 / 推 PR Email 发送 通知 / 日报 三个入口都打到同一个 CoderAgent 实例上;它调用四类外部资源,产生代码 / PR / 邮件三种产物

这个 agent 能干的事情列表(也是判断你“读完这本书学会了什么“的硬指标):

  • 接受用户的自然语言指令(HTTP / WebSocket / 邮件 / GitHub webhook 都能进)
  • 流式输出回答,模型可在 Workers AI / Anthropic / OpenAI / Google 之间切
  • 每个会话独立持久化,刷新页面记忆不丢,过去的对话能被全文搜
  • 调用工具读写代码、查 GitHub
  • 关键操作走 human-in-the-loop 确认(避免它头脑发热把生产分支删了)
  • 加载可复用的 Skills(代码评审套路、lint 修复套路、自定义业务规则)
  • 在沙箱容器里执行任意命令(npm installpytest 都能跑)
  • 把生成的产物落到 R2 持久化,带版本
  • 接到 issue 后自己规划、改代码、跑测试、提 PR
  • 通过 GitHub App 安全集成,token 短时效、可吊销
  • 上线带限流、可观测、灰度发布

部署目标全部在 Cloudflare 上。月成本可控制在 0(免费额度)到几十美元(中等使用量)。

0.5 十章路线图:每章把 agent 加一个能力

如果把整个 agent 比作一辆车,十章是按下面这个顺序往上装零件的:

图 0-5:十章在 agent-coder 上累加什么

十章按顺序往 agent-coder 上加能力 — 第 1 章打地基,第 10 章上线 十章 = 十块拼图 每章只新增一项能力,代码是上一章的增量,不重写 第 1 章 会回话 最小 Think + 流式 第 2 章 换大脑 AI Platform 切 provider 第 3 章 记得住 Session 树形对话 第 4 章 能动手 Code Mode + 工具 + HITL 第 5 章 懂规矩 Skills + Memory 第 6 章 能跑代码 Sandbox 容器 第 7 章 留得下 Artifacts + R2 第 8 章 写代码闭环 Coding Agent loop 第 9 章 接得上 Git/GitHub + Email 第 10 章 上线 限流 / 观测 / 灰度 第一阶段 · 基础能力(章 1–4) 让 agent 能聊、能换模型、能记住、能调工具 — 一个能用的对话 agent 就成了 第二阶段 · 真正会做事(章 5–7) 规则 / 沙箱 / 持久产物 — 让它能在真实环境里执行、留下能复用的成果 第三阶段 · 走进现实工程(章 8–9) 闭合写代码循环 + 接 GitHub / 邮件 — 从 demo 变成你团队真的会用的工具 第四阶段 · 上线(章 10) 限流 / 观测 / 灰度 — 别让 agent 一上线就把你账号烧爆

把每一章用一句话总结一下,你后面读到任何一章都能定位在地图上的哪一格:

解决什么具体问题加上之后,agent 多了什么
1怎么让 LLM 接收 HTTP 请求并流式返回一个能聊天的最小骨架
2我想用 Claude / GPT 不只是 Llama不改业务代码就能切模型,可对比 / 可灰度
3上下文太长怎么办?用户想“换条思路重试“怎么办?树形会话 + 自动 compact + FTS5 检索
4LLM 怎么操作真实世界(读文件 / 调 API)?工具调用 + Code Mode + 危险操作前的人工审批
5怎么让 agent 跨会话记住“我团队的代码风格“可加载的 Skills(规则) + 长期 Memory(事实)
6LLM 想跑 npm test 怎么跑?边缘容器沙箱,跑完就毁,不污染主机
7agent 生成的代码 / 报告怎么留下来,能版本化Artifacts(类 git 的产物存储)+ R2
8把前 7 章拼成“接需求 → 改代码 → 跑测试 → 给结论“的真闭环一个会写代码的 agent
9接到 GitHub issue 自动开 PR、自动回邮件agent 走出 chat UI,接到外部触发器
10上线前的所有事:限流、监控、灰度、安全不会一上线就把你账号烧爆的生产姿势

这十章不是“十个独立的章节“,是一个项目从空目录到上线的完整时间线。每一章的代码都直接接在上一章后面 —— 第 6 章引入容器时,引用的是第 4 章的工具结构;第 8 章组装闭环时,Skills 来自第 5 章、容器来自第 6 章、artifacts 来自第 7 章。

跳读会很难拼回来。强烈建议按顺序

0.6 怎么读这本书

每章的结构都一样,这是为了让你能在该跳过的地方跳过:

  1. 想要什么 — 一段话 + 一段命令,告诉你“这一章读完你能 demo 出什么“。如果你想先看效果再决定要不要细读,只看这一段。
  2. 为什么 — 为什么不用更简单 / 更主流的别的方案。如果你只想干活、不想理解动机,这段可跳。
  3. 方案选择 — 一张取舍表。如果你有强烈的技术偏好(比如已经在用 LangChain),先看这里能省时间。
  4. 落地 — 真正的代码 + 配置 + 命令。这一段不能跳。
  5. 验证 — curl 一下、看输出。这一段也不能跳。 不验等于没读。
  6. 边界与坑 — 写书时踩过的坑。生产化时回来看一遍能少修一堆 bug。
  7. 下一章预告 — 留一个钩子,告诉你下一章为什么必须存在。

每章末尾都有“延伸阅读“链接到附录 E 的官方中译,需要查参数细节直接跳过去。

如果你完全不熟 Cloudflare Workers / Durable Objects 也没关系,需要的概念我们会现讲。但如果你完全没用过 Cloudflare,建议先花 20 分钟跟着官方 quick start 跑一个 hello world Worker,回来再继续 —— 不是怕你跟不上,是省得你被 wrangler 的命令行问题分神。

预算上,第 1–5 章完全免费(Workers AI 免费额度 + Durable Objects SQLite 免费层够用)。第 6 章起涉及 Containers 和外部 provider,需要少量预算(整本书走完预计 $5–20)。

跟着代码走完,大约 8–12 小时。如果你想真的吃透 —— 在每章“边界与坑“里动手验证一遍 —— 大概要 20 小时。

好了,概念铺垫到此为止。下一章我们打开终端,5 分钟跑通最小 Think agent。