企业官网建设流程全解析

最近被问得最多的一个问题就是：“我想学 AI Agent，是不是直接上手 LangChain 就行？”每次听到这种问法，我都想把对方按住先聊十分钟。不是框架不好，是顺序真的不太对。你想想，学做饭总得先会切菜、会开火，再琢磨用什么锅；结果你一上来就买了个智能炒菜机，菜谱没看两页，机器报错你也听不懂。AI Agent 入门也一样，先学什么、后学什么，直接决定了你是三个月上手，还是三个月弃坑。

这篇文章我不打算给你讲一堆花哨的框架概念，而是想站在“带过不少转行者”的角度，把 AI Agent 学习路径里最容易被忽略、又最关键的部分拆开聊清楚。新手和转行者最该先学的不是某一个框架，而是 Agent 背后那套“循环”逻辑、裸调大模型 API 的能力、Function Calling 的用法，以及一点必要的 Python 基础。把这些打好，之后再碰 LangChain、Dify、CrewAI 这类框架，你会发现自己不是在背文档，而是在挑工具。

1. 先读懂 Agent 的底层运转逻辑：别把框架当 Agent 本身

1.1 Agent 的本质是一个“循环”，而不是某个库

先说个最容易被误解的点：很多人以为“用了 LangChain 就等于在做 Agent”，其实 Agent 根本不是一个库，而是一种运行方式。

你可以把 Agent 理解成一个带手带脚的实习生。大模型本身只是这个实习生的“大脑”，它很聪明，但它没有手，不能帮你查数据库，不能帮你发请求，也不知道你公司的内部系统长什么样。Agent 要做的就是给这个“大脑”配上工具、记忆和一套行动规则，然后让它在一个循环里反复工作：看懂任务、决定调用什么工具、拿到结果、再继续做下一步判断，直到任务完成。

这个“循环”就是 Agent 的灵魂。现在市面上不管叫 Agent 也好、叫智能体也好，不管底层用的是 LangChain、Dify 还是 CrewAI，跑的核心逻辑都是这同一个循环。所以我在带新手的时候，第一课从来不讲任何框架，而是先让他在一张白纸上，把这个循环画出来：用户输入进去，模型判断要调用哪个工具，工具返回结果，模型再根据结果组织回答。这个图画明白了，后面学任何框架都只是换 API 而已。

生活里类似的例子其实很多。你点外卖，先是自己看菜单（理解任务），然后决定点哪家（决策），下单之后等外卖送到（工具执行），收到餐之后你发现不够吃，于是再加一单（观察结果后继续决策）。这就是一个非常典型的 Agent 循环。理解了这个，你就能解释为什么 Agent 有时候会“绕来绕去”——因为它本来就是在循环里反复思考、执行、验证。

1.2 LLM 为什么会“卡住”？核心是缺少闭环

很多新手第一次调用大模型 API 的时候，都会产生一个困惑：我只给它一个 Prompt 让它“帮我查一下明天的机票”，为什么它回复我说“我是一个 AI 模型，无法实时查询”？这其实不是你 Prompt 写得不好，而是你只用了大模型，没用 Agent。

普通 API 调用是“一次性的”：你问一句，它答一句，答完就结束。Agent 则是“闭环的”：模型发现自己需要实时数据，就会抛出“我需要调用查票工具”这个意图，程序拦截到这个意图后，真的去请求票务接口，拿到结果再放回对话里，让模型继续回答。这就是闭环的意义——模型不再是一个只会“脑补”的回答机器，而是能借助外部世界的信息来完成推理。

理解了这个之后，你就会明白为什么我坚决反对新手上来就啃框架。因为框架把“循环”这件事包装得太好了，你写几行代码就能跑起来一个 Agent，但遇到问题的时候，你根本不知道是模型的判断错了，还是工具调用没配上，还是上下文被写坏了。你没有亲手搭过这个循环，就很难定位问题在哪一环。框架给你的是脚手架，但你不能因为有了脚手架，就不知道房子是怎么盖的。

1.3 ReAct 模式：当前主流 Agent 的基本盘

聊到 Agent 的底层逻辑，就绕不开 ReAct。这个名词看着高级，拆开就是 Reasoning + Acting，也就是“边推理边行动”。

ReAct 模式的思路很直白：模型不是一口气给出最终答案，而是先输出一小段思考（比如“用户想知道北京天气，我手里有天气查询工具，我应该调用它”），然后输出一个具体的动作（调用工具），工具返回结果后，模型再基于这个“观察”继续推理，最后给出回答。整个过程像是一个人边想边做，而不是闭着眼瞎猜。

现在市面上大多数主流 Agent 的运行模式，不管底层叫不叫 ReAct，本质上都脱离不了这个框架。包括最早火过一阵的 AutoGPT 类项目，也是类似的套路。所以如果你能徒手写出一个 ReAct 循环，你就掌握了理解一切 Agent 框架的钥匙。当你之后翻开 LangChain 的文档，看到 AgentExecutor、Agent 这类名词的时候，你会发现它们只不过是把 ReAct 这个模式封装成了类和函数。

顺带解释一个常被问到的高频词：“AI Agent token 是什么意思”。Token 是大模型处理文本的基本单位，可以粗略理解成“字或词被切碎后的碎片”。模型计费按 token 算，上下文窗口上限也按 token 算，Agent 每多一轮调用、每塞一段工具返回结果，都会消耗 token。新手常常忽略这一点，结果跑了几轮 Agent 之后发现账单吓人，还以为是框架出了 bug。我个人经验是：在学 Agent 的第一天就把 token 消耗这个概念刻在脑子里，能帮你省下不少冤枉钱。

2. 新手真正要打的先修课：不是框架，是这四样

2.1 Python 不用学成专家，但 requests 和 json 必须会用

我知道很多转行者看到“Python 基础”四个字就头大，以为要把语法、面向对象、装饰器、生成器全学一遍才能碰 Agent。真不用。一个做 Agent 应用开发的人，日常百分之七八十的时间都在做同一件事：用 HTTP 请求去调用 API，然后把返回的 JSON 数据处理好，再塞给模型。就这么简单。

我建议新手把 Python 的学习范围先收缩到这几样：变量和数据类型、函数、字典和列表的增删改查、requests 库发 GET/POST 请求、json 库做序列化和反序列化、try/except 处理异常。会了这些，你就已经具备写一个 Agent 雏形的基础了。我见过太多人花了三个月啃 Python 教程，啃到正则表达式和装饰器，觉得自己“还没准备好”，其实那些东西对入门阶段的 Agent 开发帮助很小。

这里给你一个我自己常用的入门级代码模板，别小看它，它以后会反复出现在你的 Agent 代码里：

import requests import json def call_llm(messages, tools=None): url = "https://你的api服务地址/v1/chat/completions" headers = {"Authorization": "Bearer 你的密钥", "Content-Type": "application/json"} payload = {"model": "你用的模型名", "messages": messages} if tools: payload["tools"] = tools resp = requests.post(url, headers=headers, json=payload) resp.raise_for_status() return resp.json()

这段代码粗糙但够用，核心就是构造一个 messages 列表，发给模型，拿到返回。你会发现后面学什么框架，框架内部帮你做的也是这件事，只是包装得更友好而已。所以先把裸调用练熟，你就能在任何框架的报错信息里，一眼看出问题出在“消息格式”还是“接口地址”还是“权限校验”。

2.2 裸调一次大模型 API：框架之前先会“聊天”

接着上面说的，我强烈建议新手在接触任何 Agent 框架之前，先亲手裸调一次大模型 API。不是用官方 SDK，而是直接用 requests 或者 curl 调一次“对话补全”接口。

为什么非要这么干？因为 SDK 和框架帮你把很多东西藏起来了，尤其是 messages 这个结构。你直接用 requests 调一次，就能很直观地看到：模型接收的不是一串字符串，而是一个消息列表，里面每条消息带有 role 和 content。role 有 system、user、assistant，system 是给模型设定身份和行为规则的，user 是用户输入，assistant 是模型的历史回答。Agent 和工具之间的交互，本质上也是往这个列表里追加不同类型的消息。

你可能会问，这有什么难的？不就是发个请求吗？但真正自己写过一遍之后，你会有一种“打通了任督二脉”的感觉。因为后面所有 Agent 框架里那些复杂的 Prompt 模板、记忆管理模块、对话历史管理模块，本质上都在做同一件事：帮你维护好这个 messages 列表，别让它越界、别让它乱掉。如果你连 messages 结构都亲手打印过、看清楚过，框架里的类似概念对你来说就是旧相识。

我当时带过的一个学员就是这样，他一开始连 HTTP 请求都发不利索，硬着头皮跑通了一次裸调用之后，后面学什么框架都特别快。用他的话来说：“我现在终于知道模型吃的是什么格式的饭了。”

2.3 Function Calling：给 Agent 装“手”和“脚”

如果你只学会了裸调 API，那你还只是在“和模型聊天”。Agent 和普通聊天的最大区别，就是它能调用工具。而当前实现工具调用最主流的方式，就是 Function Calling。

Function Calling 说白了就是：你在请求里附带一份“工具箱清单”，里面描述每个工具叫什么、接收什么参数、有什么用。模型看到你的问题后，会在回答里告诉你“我想调用 xx 工具，参数是 yy”，而不是真的去执行工具。真正的执行，还是由你的代码来完成。

听起来有点绕，但我用一个例子你就懂了。假设你给模型提供了一个天气查询工具，工具说明写着“输入城市名，返回该城市天气”。用户说“北京今天冷不冷”，模型就会输出一个结构化的调用请求：调用 get_weather，参数为 {"city": "北京"}。你的程序收到这个请求，真的去天气接口查了，拿到“晴，-3℃到5℃”，再把这个结果作为一条工具消息放回对话里，模型看了之后就能给出一个自然、完整的回答：“北京今天晴，气温在 -3℃到 5℃，比较冷，建议穿羽绒服。”

这就是 Agent 有“手脚”的关键。我强调先学 Function Calling，是因为它是所有工具调用类 Agent 的地基。不管你是做一个能查天气的 Agent，还是做一个能自动发消息、定时推送内容的自动化 Agent，你都要用到这个机制。框架里的 Tool、ToolExecutor、Agent Tool 这些概念，全都是建立在 Function Calling 之上的封装。

这里给你一个工具定义的最小例子，以后你写任何 Agent 工具，都是照这个模子来：

tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的实时天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，如北京、上海"} }, "required": ["city"], }, }, } ]

注意，这段 JSON 结构看着啰嗦，但它非常重要。你在 description 里写的话要足够清楚，因为模型全靠这段描述来决定什么时候调用这个工具、参数该怎么填。描述写模糊了，模型就会在不需要调用的时候瞎调用，或者在需要的时候视而不见。这种细节，框架不会替你解决，得靠你自己慢慢练出“写工具说明书”的手感。

2.4 异步、流式与上下文：迟早绕不开的进阶基础

前面说的三样是入门必须，下面这几样是“你迟早要碰到，不如提前混脸熟”的东西。

第一个是异步。你调大模型 API，一般要等一到几秒才返回结果，如果 Agent 里要连续调用两三次工具，用户就会明显感觉到“它在思考”。要想让 Agent 同时处理多个请求，或者在等待模型返回的时候不阻塞其他任务，就需要用到 Python 的 async/await。新手不用一开始就精通，但最好知道有这个机制存在，免得以后看到别人代码里全是 async def 的时候一脸懵。

第二个是流式输出。现在很多 Agent 应用都有“打字机效果”，就是模型一边生成，一边把内容实时吐出来。这个效果靠的就是流式接口，也就是把普通请求改成 stream=true，然后不断读取返回的数据块。流式输出的好处不只是体验好，它还能让你在模型还在生成的时候就开始处理前一部分内容，对长回答尤其有用。

第三个是上下文管理，这是最容易出问题的地方。Agent 每一轮都要把历史消息重新发给模型，历史越长，token 消耗越大，模型也越容易“忘事”。很多新手写完一个 Agent 跑了几轮就发现回答质量直线下降，不是因为模型不行，而是因为没做上下文裁剪。常用的做法有：只保留最近几轮对话、用摘要压缩历史、把超长工具结果先做总结再放回对话。这些技巧看着不起眼，但直接决定你的 Agent 在真实场景里能跑多久、跑多稳。

3. 手写一个不依赖框架的 Mini Agent（完整实现）

3.1 需求拆解：做一个能查天气的 Agent

前面讲了一堆原理，现在来点实在的。我带新手入门的时候，通常会让他做一个最简单的 Agent：用户输入“北京天气怎么样”，Agent 调用天气查询工具，最后返回一个自然语言回答。

这个需求看着简单，但它涵盖了 Agent 核心的所有环节：理解用户意图、决定调用工具、执行工具、把结果返回给模型、生成最终回答。你把这个跑通，就相当于亲手搭了一条完整的 Agent 流水线。以后不管是加数据库查询、加网页搜索、加内容平台自动发文，都是在同一条流水线上加新工具而已。

为了能真的跑起来，你需要以下几个东西：一个大模型 API 地址和密钥（只要是 OpenAI 兼容接口的都行）、一个能返回天气的接口或本地模拟函数、以及一台能跑 Python 的电脑。如果暂时找不到合适的天气接口，直接用函数返回假数据也行，核心是打通流程，不是纠结数据真实性。

我自己在实际带人的时候，一定会强调：“把流程跑通比数据对不对更重要。”因为新手最容易陷入的误区，就是卡在找天气接口、注册账号、研究参数这些外围环节，结果一晚上过去了，Agent 的核心循环代码一行没写。

3.2 核心代码：Model、Tool、Loop 三段式

下面这段代码就是我给新手准备的 Mini Agent 实现，结构非常清晰，分三块：模型调用函数、工具定义、Agent 主循环。

import json import requests # ---------- 模型调用 ---------- def call_llm(messages, tools=None): url = "https://你的api服务地址/v1/chat/completions" headers = {"Authorization": "Bearer 你的密钥", "Content-Type": "application/json"} payload = {"model": "你的模型名", "messages": messages} if tools: payload["tools"] = tools resp = requests.post(url, headers=headers, json=payload) resp.raise_for_status() return resp.json() # ---------- 工具定义 ---------- def get_weather(city): # 这里先返回模拟数据，真实场景可换成天气服务接口 data = { "北京": {"weather": "晴", "temp": "-3~5℃"}, "上海": {"weather": "小雨", "temp": "8~12℃"}, } return json.dumps(data.get(city, {"weather": "未知", "temp": "未知"}), ensure_ascii=False) TOOLS = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的实时天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，如北京、上海"} }, "required": ["city"], }, }, } ] # ---------- Agent 主循环 ---------- def run_agent(user_input, max_steps=5): messages = [{"role": "user", "content": user_input}] for step in range(max_steps): result = call_llm(messages, tools=TOOLS) msg = result["choices"][0]["message"] messages.append(msg) # 如果模型没有要求调用工具，就直接返回回答 if not msg.get("tool_calls"): return msg["content"] # 如果有工具调用请求，就逐个执行 for tc in msg["tool_calls"]: fn_name = tc["function"]["name"] args = json.loads(tc["function"]["arguments"]) print(f"[Agent] 调用工具: {fn_name}, 参数: {args}") if fn_name == "get_weather": tool_result = get_weather(args["city"]) else: tool_result = json.dumps({"error": "未知工具"}) messages.append({ "role": "tool", "tool_call_id": tc["id"], "content": tool_result, }) print(f"[Agent] 工具返回: {tool_result}") return "已达最大步数，提前结束" # ---------- 跑一个例子 ---------- if __name__ == "__main__": print(run_agent("北京今天天气怎么样？"))

这段代码里最关键的，是 messages 的变化过程。你仔细看就会发现，模型返回的 assistant 消息会被原样追加到列表里，工具返回的结果也以 role=tool 的消息追加进去。这个“不断追加、不断把新信息喂回去”的过程，就是 Agent 闭环的本质。

我特别想提醒的一点是：你在跑代码的时候，一定要把上面的 print 语句保留下来。这是新手最好的 debugging 方式——看着控制台打印出的“调用工具”“工具返回”过程，你能直观地看到 Agent 每一步在想什么、做了什么。很多转行者一开始总想用高端调试工具，其实对入门来说，打印日志就是这个阶段最有效的老师。

3.3 跑通后的复盘：你其实已经学会了 80%

我第一次带人写这个 Mini Agent 的时候，学员跑通之后特别兴奋，说原来 Agent 没那么神秘。确实是这样的。等你亲手写完这个小项目，你会发现自己已经理解了 Agent 最核心的骨架：模型是大脑、函数是手、循环是神经系统。剩下的 20%，无非是怎么把 get_weather 换成真正的数据库查询，把单轮工具调用扩展成多轮协作，把函数返回结果做得更丰富。

而且这个代码的扩展性很好。今天你想给 Agent 加一个“查询航班”的工具，只需要再加一个新的函数、在 TOOLS 里加一段描述，然后在主循环里加一个 if 分支就行。整个过程中，你对 Agent 如何思考、如何决定调用、如何把结果汇报出去，都会有很强的掌控感。这种掌控感，是直接啃框架学不来的。

更重要的是，你自己手写过一遍之后，再去看 LangChain 之类的文档，你会发自内心地觉得“原来 AgentExecutor 就是把我的 for 循环封装了一下”“原来 Tool 类就是在把我的 TOOLS 列表包装成对象”。到这一步，框架对你来说已经不是天书，而是工具箱。

4. 框架什么时候学、怎么选：LangChain/Dify/CrewAI 避坑指南

4.1 为什么新手一上来啃框架容易翻车

我不是反对框架，我是反对“零基础直接上框架”。这里头有三个很现实的原因。

第一个原因是调试地狱。框架帮你做了很多事，但也把很多逻辑藏了起来。你调用框架里的 Agent 跑了一遍，发现结果不对，你想搞清楚是 Prompt 写得有问题，还是工具参数传错了，还是记忆模块把历史搞混了。结果你打开框架的抽象层，看到一堆类、回调、链式调用，瞬间头皮发麻。我见过太多新手卡在“框架本身报的错”上，而不是卡在“Agent 业务逻辑”上。

第二个原因是版本更新太快。现在的框架迭代速度非常夸张，今天学的一行代码，明天可能就换成另一个写法了。你如果不是对底层逻辑有清晰认识，光靠“照着文档抄”，很容易陷入一种困境：昨天还能跑的代码，今天跑不起来了，你完全不知道是哪里变了。

第三个原因，也是最根本的：框架解决的是“工程化”问题，而不是“认知”问题。你缺的不是怎么优雅地把工具注册进框架，而是怎么理解整个 Agent 循环。认知没到位，框架只会放大你的混乱。

所以我的观点很明确：先手动写一个 Agent，再考虑框架。手动写过之后，框架对你来说是提高效率的工具；没写过就上框架，框架对你来说是增加焦虑的黑洞。

4.2 三大框架选型对照（新手特供版）

等你手动实现过一个 Mini Agent，下一个很自然的问题就是：市面上这么多框架，到底该学哪个？我以新手视角，把目前最常被提到的三个方向做个对照。

先说你为什么需要关注这三个。LangChain 是目前生态最全的 Agent 开发框架，适合你之后想深度定制自己的 Agent 的时候用。Dify 这类平台化工具，适合你不想从零写代码、想快速把一个 Agent 应用搭起来看效果，尤其适合产品向、运营向的转行者。CrewAI 则是你进入“多 Agent 协作”领域的一个入口，它让你可以定义不同的 Agent 角色，让它们像团队一样分工配合。

但不管你最后选哪一个，我都会建议你先把时间花在“理解 Agent 循环”上，而不是花在选择框架上。框架只是实现思想的工具，思想才是你真正要学的。而且个人经验是：一旦你理解了 Agent 的本质，你换框架的成本其实很低的，因为它们的核心概念都差不多，无非是 Tool、Memory、Agent、Task 这几个词的变体。

4.3 绕不开的主流架构概念：提前混个脸熟

在学框架之前，有几个 Agent 架构层面的词，你最好先有个印象。因为不管哪个框架的文档，都会反复出现它们。

第一个是 Plan-and-Execute。这个架构比简单的 ReAct 多了一层“先规划后执行”的过程。模型先不急着调用工具，而是先把整个任务拆成几个步骤，然后一步步执行。比如“帮我写一篇行业报告”，Agent 会先规划：查资料、列提纲、写初稿、润色。这样做的优势是任务更可控，不会像纯 ReAct 那样容易跑偏。很多复杂业务型 Agent 都倾向于用这种架构。

第二个是 Multi-Agent。也就是多个 Agent 分工协作。常见的有“主管 Agent 分派任务，下属 Agent 各自完成”“一个 Agent 负责想点子，另一个负责挑毛病”。CrewAI 就是这一类。多 Agent 的难点在于角色定义和通信机制，你要是连单个 Agent 都还没跑明白，玩多 Agent 只会一地鸡毛。

第三个是 RAG 增强。RAG 是“检索增强生成”，简单说就是让 Agent 先从外部知识库（比如你的文档库、数据库）里检索出相关内容，再把这些内容塞到提示词里，让模型基于真实资料回答。它解决的是模型“不知道你的私有知识”的问题。很多做客服 Agent、文档问答 Agent 的场景，都会用到 RAG。新手可以晚点再深挖，但这个词一定会频繁出现，提前知道它是干嘛的，你就不会在群里看到别人讨论的时候一头雾水。

第四个是 Memory（记忆）。Agent 的记忆分短期和长期。短期记忆就是对话上下文，长期记忆则可能存到数据库里，比如用户偏好、历史行为。框架里的 Memory 模块，本质上就是在帮你做这些持久化和回溯。你手写 Mini Agent 的时候，其实已经接触到了短期记忆——messages 列表就是最原始的短期记忆。

5. 转行者最容易卡住的 5 个问题与实操体检

5.1 常见问题速查：先别急着到处问

我接触过不少从测试、前端、运营、产品转来做 AI Agent 的朋友，大家问的问题其实高度相似。这里把最常出现的几个整理成速查表，希望能帮你少走弯路。

先说提示词这件事。我发现新手特别喜欢囤模板，看到一个“万能提示词模板”就收藏，实际上是给自己找安全感。模板当然有用，但你一定要能解释清楚里面每一句话是干嘛的。比如“你是一名资深数据分析师”是在设定身份，“请给出三段式回答”是在约束格式，“以下是一个例子”是在做少样本示范。理解了这些，你就能自己改模板，而不是永远被模板束缚。

再说要不要学机器学习。如果你是奔着“用 Agent 做应用”来的，那机器学习可以先不学。Agent 开发更接近传统后端开发，你的核心竞争力是“把模型能力、工具能力、业务流程串起来”，而不是从头训练一个模型。我见过太多转行者花半年啃吴恩达的课，结果一做项目还是不会写工具调用，这就是方向偏了。当然，你可以为了长期发展后来补一补，但绝不是你入门 Agent 的拦路虎。

5.2 我给新手和转行者的三条路线建议

结合我带人的经验，如果你想认真入门 AI Agent，我建议你按下面这条路线走一遍，别跳步。

第一步，用一天时间跑通裸调用。不借助任何框架，用 requests 调用一个大模型 API，熟悉 messages 结构，打印出返回的 JSON 慢慢看。这一步的目标是“和大模型建立原始连接”，让你感受到它就是个普通 HTTP 服务，没什么神奇的。

第二步，花两到三天手写一个带工具调用的 Mini Agent。就用我在第 3 节给的例子，把天气查询换成任何你感兴趣的工具。比如你可以换成股票查询、新闻查询、本地文件搜索、甚至一个能帮你生成日报的小工具。重点是把这个循环彻底吃透，做到闭上眼睛能画出整个数据流转过程。

第三步，到了这一步再碰框架。选一个你想深入的方向：想做应用快速落地就用 Dify 这类平台，想深度定制就研究 LangChain，想玩多 Agent 协作再看 CrewAI。而且我建议你做一个对比练习：把你手写的 Mini Agent，用框架再实现一遍，对比一下写法和调试方式有什么不同。这个对比练习会让你的理解上一个台阶。

走完这三步，你对 AI Agent 已经有了一个完整、扎实的骨架。之后再看到任何新技术、新框架，你都可以快速把它吸收进你自己的知识体系里。很多人问“AI Agent 入门到底要多久”，我的回答是：如果你按这条路线走，一周时间就足够入门，但如果你一上来就啃框架，可能三个月还在各种报错里挣扎。

我个人带过不少转行者的实际体会是，学 Agent 最大的瓶颈从来不是智商，也不完全是基础，而是那种“我是不是还差得远”的焦虑感。想一口气学完 Python、学完框架、学会编排、学会 RAG，结果每个都浅尝辄止。其实把心态放稳一点，把上面那个 Mini Agent 手写一遍，你就已经站在门槛里面了。之后再遇到框架里那些眼花缭乱的概念，你只会觉得它们是你那套循环逻辑的花式变体，不会再有雾里看花的感觉。