企业官网建设流程全解析

本文深入浅出地解析了 Agent 的工作原理，强调 Agent 是一个持续循环的过程而非单次 API 调用。通过 ReAct（推理+行动）循环模式，类比前端开发中的 useEffect 依赖循环，阐述了 Agent 如何通过观察、思考、行动不断迭代直至任务完成。文章还提供了 50 行手写 Agent 循环的 TypeScript 代码示例，并详细讨论了循环终止条件、Backtracking 回退机制等关键知识点，帮助读者快速掌握 Agent 开发核心，是入门大模型开发的实用指南。

Agent 不是一次 API 调用，是一个死循环。你跟它的区别在于，你知道什么时候该停。

开篇

上篇写完 Tool Use 和 Streaming 之后，有个读者在后台留言，说了一段让我愣了半天的话。

他说：“我照着你的代码写了工具调用，模型确实能查天气了。但我发现一个问题——它查完天气就停了。我以为 Agent 会’自己接着干活’，结果它跟普通 API 没什么区别，调一次工具就下班。”

我说你这个问题问到点子上了。Tool Use 只是给了模型一双手。但一双手不是一个人。人之所以能干活，是因为他会反复地"看一眼→想一下→动手→看一眼结果→再想→再动手"，直到把事情做完。

你缺的不是工具，是循环。

ReAct 循环全景：观察→思考→行动→观察→思考→行动，Agent 的核心工作模式

● ● ●

● ● ●

Agent 的工作方式：一个死循环

Agent 这个词被用得有点滥了。但如果你让我用一句话说清楚 Agent 跟"调一次 API"的本质区别，我会说：Agent 在循环，调 API 是一次性的。

学术上有个词叫 ReAct——Reasoning + Acting。说人话就是：模型先推理"我现在该干什么"，然后动手干，干完之后看结果，再推理下一步该干什么。

你仔细想一下你自己写代码的流程。你接到一个需求，你不是上来就写。你先看需求文档（观察），想一想怎么实现（思考），然后写一段代码（行动），运行一下看有没有报错（观察），修 bug（思考+行动），再跑一遍测试（观察），直到功能跑通。

Agent 跟你一模一样。唯一的区别是，你做这套动作不需要人给你写 while 循环，Agent 需要。

// Agent 的本质：一个while循环while(true){const observation=getCurrentState();// 观察 const thought=await model.reason(observation);// 思考 const action=await executeAction(thought);// 行动if(shouldStop(thought, action))break;// 该停了？}

就这四行。剩下所有东西——Max Steps、Backtracking、Termination——都是在给这个骨架加血肉。框架给你加了一万行，但核心就这些。

useEffect vs Agent 循环：前端工程师每天都在写类似的东西

● ● ●

● ● ●

50 行手写一个 React 循环

我不想让你觉得我在画饼。下面这 50 行 TypeScript，不依赖任何框架，复制出来就能跑。

interface AgentState{messages: Message[];tools: Record<string, Tool>;maxSteps: number;currentStep: number;}asyncfunctionagentLoop(state: AgentState): Promise<string>{while(state.currentStep<state.maxSteps){state.currentStep++;// Step1: 调模型，让它决定下一步 const response=await client.messages.create({model:"claude-sonnet-4-20250514", max_tokens:1024, tools: Object.values(state.tools), messages: state.messages,});// Step2: 把模型的回复记下来 state.messages.push({role:"assistant", content: response.content});// Step3: 找 tool_use const toolUses=response.content.filter((block)=>block.type==="tool_use");// Step4: 没有工具调用=模型觉得做完了if(toolUses.length===0){const textBlock=response.content.find(b=>b.type==="text");return(textBlock as any)?.text ??"任务完成";}// Step5: 执行工具 const results=await Promise.all(toolUses.map(async(tool)=>{const fn=state.tools[tool.name];if(!fn)return{error:`未知工具: ${tool.name}`};try{const output=await fn(tool.input);return{tool_use_id: tool.id, content: JSON.stringify(output)};}catch(e){return{tool_use_id: tool.id, content: JSON.stringify({error: String(e)}),};}}));// Step6: 把结果塞回消息列表，进入下一轮 state.messages.push({role:"user", content: results});}// 超过 maxSteps，强制退出return"Agent 达到最大步数限制，任务未完成";}

几件事值得注意。

第一，没有工具调用就停。这是很自然的一个判断——模型如果只回了文字没调工具，说明它认为任务结束了。但实际上这里有个坑，我后面说。

第二，工具执行结果要原样塞回去。模型不会"记住"之前的工具调用结果，你必须把新的 user message 带着工具结果一起发过去。这就是为什么state.messages在不断增长。

第三，maxSteps 是硬兜底。模型有时候会卡住——反复调同一个工具、反复问同样的问题。maxSteps是你最后的安全网。我一般设 20-30 步，看任务复杂度。

扯远一句：我第一次写 Agent 循环的时候，忘了加maxSteps，一个简单的查天气任务跑了 90 步才自己停。原因是模型在拿到"找不到该城市"的结果之后，换了一个拼音写法又查了一次，没查到，又换了英文名，又没查到……它把地球上叫"Springfield"的城市全遍历了一遍。那次之后我学乖了——永远设 maxSteps，永远。

Agent 循环代码结构：while 循环 + 模型推理 + 工具执行 + 消息累积

什么时候停：Loop Termination

上面那个循环看似简单，但真正难的地方在终止条件。

我见过三种典型的"停不下来"：

1. 01模型不知道完了

：任务已经完成但模型还在"确认"，问用户"是否可以帮到您"

3. 02工具出错死循环

：工具报错了，模型重试，又报同样的错，又重试

5. 03模型失忆

：消息太长，模型"忘掉"了最初的任务，开始做别的事

第一种最烦人。你让 Agent “帮我查一下北京天气然后发邮件给我”，它查完天气、发完邮件……然后问了一句"还需要我帮您做别的吗？"你不在场，循环就卡在这了。

解决方案是你在一开始的 System Prompt 里写清楚：“任务完成后直接给出结果，不要问用户是否需要其他帮助”。这不是技术问题，是 prompt 问题。

第二种更难搞。刚才说的查天气死循环就是一个例子。解决的思路不是阻止出错——出错是常态——而是给同类错误设上限。同一工具同一错误连续出现 3 次 = 停，告诉用户"这个工具暂时用不了"。

// 在循环里加一个错误计数器 const errorKey=`${tool.name}:${extractErrorType(result)}`;errorCount.set(errorKey,(errorCount.get(errorKey)??0)+1);if(errorCount.get(errorKey)!>=3){return`工具 ${tool.name}连续失败3次，任务中断`;}

第三种是上下文窗口的锅。消息越积越多，超过一定长度之后模型会"遗忘"最前面的内容。这个留到下一篇文章专门说（记忆系统），今天你只需要知道它会发生就行了。

Loop 终止条件决策：无工具调用/任务完成/错误上限/maxSteps，四种退出路径

等一下。上面这三种"停不下来"我写得好像很全面——但我想了一下，其实还有一种情况更隐蔽：模型自己觉得做完了，但其实没做完。

比如你让它"整理项目里所有 TODO 注释并创建 GitHub issues"。它搜了一个文件，找到 3 个 TODO，建了 3 个 issue，然后开心地告诉你"已完成"。但实际上项目里有 84 个 TODO，它只搜了一个文件。

这不是循环的问题，是工具设计的问题。如果你给模型的"搜索 TODO"工具只返回当前文件的结果，它天然不知道还有别的文件。解决方案一般是让你的工具返回更完整的上下文——比如"在 12 个文件中找到 84 个 TODO"。模型看到"12 个文件"就知道不能只查一个。

我说的可能不太对，这种情况其实跟终止条件的关联不大，更多是工具返回信息的完备性。但管它呢，既然我觉得这是个坑，就写在这了。

Backtracking：走错了能不能回头

这个特性大部分 Agent 框架都不支持，但我觉得它才是 生产级 Agent 跟 demo 的分界线。

什么叫 Backtracking？模型调用了一个工具，拿到的结果跟它预期不一样——不是错误，而是"这个信息不是我需要的"。这时候它能"回退"到调用工具之前的状态，换一个工具或者换一个参数再试。

说实话，完整的 Backtracking 实现起来挺复杂的——你需要保存每一步的状态快照，维护一个状态栈。大多数场景你用不上。但有一个简化版本非常好用：允许模型自己说"这个不对，我重来"。

// 在 System Prompt 里加一句： //"如果你认为前一个工具调用拿到的信息不对，可以说 'BACKTRACK: <原因>'， // 系统会撤销上一次工具调用的结果，让你重新决策。"const lastAssistantMsg=state.messages.at(-2);if(lastAssistantMsg?.role==="assistant"){const text=getTextContent(lastAssistantMsg);if(text.startsWith("BACKTRACK:")){// 撤销上一个工具调用 state.messages.splice(-2,2);continue;// 不增加 step 计数，重新来}}

这里有个细节：我用了continue而不是让 step 计数增加。因为这个"回退"本身不应该消耗步数——它是模型的自我纠错，不是继续往前拱。

我在一个订票 Agent 里试过这个模式。模型第一次调了"搜索航班"工具，拿到 30 个结果，它愣了一下（它自己的描述），说"结果太多需要缩小范围"，触发了 BACKTRACK，换了时间参数重新搜。最终它花了 4 步完成任务，如果没有 Backtracking 它会在 30 个结果里硬选一个。

但我也要泼个冷水：Backtracking 只在特定的场景有用。如果模型的每一步都是确定性的——查天气、发邮件、建 issue——那不需要 Backtracking。它的价值在于模型需要探索的场景：搜索、对比、筛选。你八成的情况不需要这个，别过度设计。

Backtracking 回退机制：模型自我检测 → 撤销上一步 → 换策略重试

● ● ●

● ● ●

useEffect 是最诚实的类比

写到这儿，我突然意识到我应该在系列第一篇就用这个类比。Agent 循环跟useEffect的依赖循环，不说一模一样，至少是失散多年的亲兄弟。

你每天写的useEffect：

useEffect(() => {

fetchUser(userId).then(setUser); // Action

}, [userId]); // Dependency → 变了就重新触发

Agent 循环：

while (true) {

const r = await model.reason(messages); // Think

const result = await executeTools®; // Act

messages.push(result); // Observe → 更新依赖

// 新消息 → 新的 Thought → 新的 Action

}

共同点是：状态变化触发副作用，副作用产生新状态，新状态再次触发副作用。区别只是useEffect的"思考"是你写的逻辑，Agent 的"思考"是模型在推理。但循环模式一模一样。

有人可能会说"这比喻不太精确，useEffect 是声明式、Agent 是命令式"。对，是不精确，但你懂我意思就行。我的目的不是做学术对比，是让你在第一分钟就理解 Agent 循环不是新东西——它是你写了几年的模式换了一身皮。

这个比喻一旦成立，你就会发现很多认知可以平移：

• useEffect

  的 clean-up 函数 ≈ Agent 循环的终止条件

• 依赖数组忘记传导致无限循环 ≈ 模型没有收到完整的工具结果导致重复调用

• useCallback

  包一下避免不必要的 effect ≈ 给工具描述写清楚避免模型乱调

• React 的 strict mode 跑两次帮你发现 bug ≈ 加个 maxSteps 帮你抓死循环

你在前端领域积累的直觉，全都是 Agent 开发的直觉。只是没人帮你做过翻译。

useEffect 依赖循环 vs Agent 思考循环：同一模式不同实现

● ● ●

● ● ●

写在最后

说回开头那个留言的读者。我回了他的消息，把上面那 50 行代码贴给他。他过了大概二十分钟回了一句：“跑通了。它连续调了 5 次工具，最后自动停了。这种感觉好奇怪。”

我问他什么奇怪。

他说：“它好像在真的干活，不是我一个个按钮按出来的。有点恐怖，也有点爽。”

我说你这种感觉是对的。Agent 循环是你在代码里创造的第一个"看起来像在工作的东西"。之前的代码都是你让它干什么就干什么，每一步都是你推的。Agent 循环是你把"下一步怎么走"的决策权交了出去——你只定义了规则，模型在规则里自己做决定。

这个感觉不习惯是正常的。但一旦你习惯了，你就回不去了。

下一篇讲 Agent 的记忆系统——短期记忆、长期记忆、上下文窗口管理。Agent 循环告诉你"怎么让模型干活"，记忆告诉你"模型怎么不忘记正在干什么"。两样加起来，你就能写一个真正能用的 Agent 了。

当然，也可能我把这事儿想得太简单了。你们在自己项目里跑的时候肯定会遇到我没碰到过的问题。遇到了留言，我帮你一起想。反正这系列才写到第四篇，我也是边写边琢磨。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？