上一章我们知道了Agent的定义——它是能自主行动的AI系统，由LLM + 记忆 + 工具 + 规划组成。但一个问题还没回答：LLM明明只会生成文字，它到底是怎么一步步变成能干活的Agent的？
本章用5个知识点，带你走完这个"变身"过程：
你问AI一个很简单的问题："北京和上海今天哪个更热？"
一个普通人会怎么做？打开天气App，查北京的气温，再查上海的气温，比一下，告诉你答案。整个过程不到30秒。
但一个纯粹的LLM做不到这件事。它会说："北京夏天通常比较热，但上海的湿度更高……" ——听起来头头是道，但它其实不知道今天的真实气温，只是在根据训练数据里的一般规律来猜。
这不是因为LLM笨。恰恰相反，LLM有一颗非常聪明的"大脑"。问题在于，它只有脑子。
| 硬伤 | 说明 | 类比 |
|---|---|---|
| 没有手 | 不能查天气、不能上网、不能操作任何外部系统 | 一个被绑住手脚的专家 |
| 没有眼睛 | 做了事也看不到结果，无法根据反馈调整 | 闭着眼睛做手术 |
| 一次性 | 只能回答一次就结束，不能分步骤推进复杂任务 | 只能投一次篮就下场 |
LLM有脑子，但没有手，也没有眼睛。所以它只能猜，不能查；只能说，不能做。
那怎么办？ 能不能给它装上"手"和"眼睛"，让它能做事、能看到结果、能继续推进？——这就是下一节要解决的问题。
在回答之前，先别急着说答案，先分析一下任务需要什么。
我们在给LLM的指令中加一条规则："遇到问题时，不要直接回答，先说出你的思考过程。"
LLM的反应变了：
想：用户问北京和上海哪个更热。这是一个关于实时天气的问题，
我需要查到两个城市今天的气温才能比较。先查北京的。
这一步的改变：LLM不再冲动回答，而是先分析任务、制定计划。
光想没用，还得能动手。我们给LLM接上工具——比如一个天气查询API。
现在LLM不仅能想，还能行动了：
想：我需要查北京今天的气温。 做：调用天气API → weather_query(city="北京")
这一步的改变：LLM有了"手"，能够与外部世界交互。
工具返回了结果，但LLM看不到怎么办？我们把工具返回的结果喂回给LLM，让它能读到。
想：我需要查北京今天的气温。 做：调用天气API → weather_query(city="北京") 看：北京今天 32°C，晴
这一步的改变：LLM有了"眼睛"，能看到自己行动的结果。
一轮"想→做→看"查到了北京的气温。但任务还没完——还得查上海的，然后比较。怎么办？
让它回到"想"这一步，继续循环。
第1轮：
想：需要比较两个城市的气温。先查北京。
做：weather_query(city="北京")
看：北京今天 32°C，晴
第2轮：
想：北京的气温拿到了，是32°C。现在查上海。
做：weather_query(city="上海")
看：上海今天 28°C，多云
第3轮：
想：两个城市的气温都有了——北京32°C，上海28°C。
北京比上海高4度，可以回答用户了。
最终回答：今天北京更热。北京 32°C（晴），上海 28°C（多云），
北京比上海高 4 度。
三轮循环，任务完成。
把上面的过程抽象出来，就是这张图：
用户提出任务
│
▼
┌─────────┐
│ 想 │ LLM分析：我需要做什么？
│ (推理) │◄──────────────────┐
└────┬────┘ │
▼ │
┌─────────┐ │
│ 做 │ 调用工具执行操作 │
│ (行动) │ │
└────┬────┘ │
▼ │
┌─────────┐ 任务没完成 │
│ 看 │──────────────────┘
│ (观察) │ 拿到结果，喂回给LLM
└────┬────┘
│ 任务完成
▼
输出最终答案
这个"想→做→看"的循环，就是LLM变成Agent的核心机制。它有一个正式名字叫 ReAct（Reasoning + Acting，推理+行动），由Google和普林斯顿大学的研究者在2022年提出。
但名字不重要，理解这个循环才重要——给LLM装上工具让它能"做"，把结果喂回来让它能"看"，然后让它循环推进，就完成了从LLM到Agent的关键跨越。
一个侦探破案不会坐在办公室里纯靠想象，也不会不动脑子到处乱查。他的工作方式是：
每一步都是"想→做→看"，循环推进直到破案。Agent的工作方式完全一样。
| 缺了什么 | 会怎样 | 类比 |
|---|---|---|
| 只做不想 | 接到任务就乱来，不分析该查什么、该怎么查 | 闭着眼睛过马路 |
| 只想不做 | 分析得头头是道，但全凭记忆和猜测，说的可能是假的 | 闭卷考试靠猜 |
| 做了但不看 | 查了数据但不回头分析，无法进入下一步 | 考完试不看成绩 |
只做不想（没有推理环节）：
用户：北京和上海哪个更热？ Agent：调用 weather_query(city="广州") ← 查错城市了！
没有"想"的环节，Agent不知道该查什么，可能随机调用工具，效率极低甚至答非所问。
只想不做（没有工具）：
用户：北京和上海哪个更热？
Agent：根据一般规律，夏天北京通常更热，冬天上海湿冷体感更低……
所以我认为可能是北京更热。
听起来像那么回事，但它不知道今天的真实气温。这就是"幻觉"——说得很自信，但内容是猜的。
做了但不看（没有观察环节）：
用户：北京和上海哪个更热？
Agent：调用 weather_query(city="北京") → 返回 32°C
（结果返回了，但Agent看不到这个结果）
Agent：抱歉，我无法获取天气信息。
工具执行了，但结果没有喂回给LLM，相当于查了白查。
只有三步齐全并且循环起来，LLM才能从"聊天工具"变成"能干活的Agent"。想，是为了知道该做什么；做，是为了获取真实信息；看，是为了让结果回到大脑，驱动下一步。
用户说："帮我查一下订单12345什么时候到。"
第1轮：
想：用户想查订单12345的物流状态，我来查一下。
做：query_order(order_id="12345")
看：错误——订单不存在
第2轮：
想：订单不存在？可能用户记错了订单号。
我不应该瞎猜，应该请用户确认。
最终回答：抱歉，没有找到订单号12345的记录。
请您确认一下订单号是否正确？
您可以在购买确认邮件或APP的"我的订单"中找到它。
因为在"看"到错误结果后，Agent回到了"想"的环节。在这个环节中，LLM不只是机械地规划下一步，而是分析发生了什么、为什么出错、接下来应该怎么调整。
如果没有"想"这一步会怎样？
用户：帮我查一下订单12345什么时候到。
系统：调用 query_order("12345") → 订单不存在
系统：错误：订单不存在。 ← 直接把报错丢给用户，冷冰冰
一个没有推理能力的系统只能把错误原样抛出。而有了"想"这个环节，Agent能理解错误的含义，给出有建设性的回应。
用户说："帮我搜一下'张三'的联系方式。"
第1轮：
想：用户要查"张三"的联系方式，我来搜通讯录。
做：search_contacts(name="张三")
看：找到3个"张三"——张三(销售部)、张三(技术部)、张三(财务部)
第2轮：
想：有3个重名的，我不能随便挑一个。
应该让用户指定是哪个部门的张三。
最终回答：通讯录中有3位"张三"，分别在销售部、技术部和财务部。
请问您要找的是哪一位？
Agent没有随便返回一个结果，而是识别出了歧义，主动请用户澄清。这种"遇到问题能反思和调整"的能力，正是"想→做→看"循环带来的弹性。
循环中的"想"不只是规划下一步，更是遇到意外时反思和调整的能力。这让Agent不会因为一次失败就崩溃，而是能像人一样灵活应对。
会转圈：有时候Agent想来想去找不到出路，反复执行类似的操作却无法推进任务。所以实际产品中都会设置一个循环次数上限（通常5-15次），超过就停下来告诉用户"我搞不定这个任务"。
工具不行它也不行：Agent的能力取决于它能用什么工具。如果你让它查天气，但没给它接天气API，它照样只能猜。
脑子不行也白搭：底层LLM越强，"想"这一步的质量越高——分析更准确、计划更合理、纠错更聪明。如果底层模型很弱，给再多工具也发挥不出来。
不擅长超长任务：如果一个任务需要几十个步骤，中间的信息量可能超出LLM的处理能力，导致它"忘记"前面做过什么。
Agent不是魔法。它的天花板 = LLM能力 × 可用工具。"想→做→看"这个机制让LLM能做事了，但做得多好，取决于脑子有多聪明、手里有什么工具。
| 知识点 | 一句话总结 |
|---|---|
| LLM的硬伤 | 有脑子但没手没眼睛——只能猜不能查，只能说不能做 |
| 想→做→看循环 | 给LLM加上推理、工具调用、结果反馈三个环节并循环执行，就是LLM变成Agent的核心机制 |
| 三步缺一不可 | 只做不想会乱来，只想不做会幻觉，做了不看无法继续——必须三步齐全 |
| 自我纠错 | 循环中的"想"让Agent能分析错误、调整策略，不会因一次失败就崩溃 |
| 局限性 | Agent的天花板 = LLM能力 × 可用工具，会转圈、怕工具差、怕模型弱 |
本章的核心认知：LLM变成Agent的关键，不是某个高深的技术突破，而是一个简单而优雅的机制——让它"想一步、做一步、看一步"，然后循环起来。这个"想→做→看"的循环（正式名称叫ReAct）是当前绝大多数Agent产品的工作基础。理解了它，你就理解了Agent是怎么从"只会聊天"变成"能干活"的。
写出一个场景的"想→做→看"流程：假设你是一个旅行规划Agent，用户说"帮我规划一个三天的北京之旅"。试着写出至少3轮"想→做→看"的循环。思考：
回忆一下你最近用AI工具（如ChatGPT、Claude、豆包等）的经历。有没有遇到过AI"猜错"或"编造信息"的情况？如果当时AI能够调用工具去查真实数据，结果会不同吗？用本章的框架分析一下。