AI Agent 本质就是一个循环：用 TypeScript 零框架实现

别急着上框架，Agent 的本质只是一个循环

一提到构建 AI Agent，很多人下意识就会去装 LangChain、学习图（graph）API、配置一堆参数。但这位 YouTube 创作者抛出了一个颇具冲击力的观点：Agent 本质上就是一个循环（loop），不需要框架，不需要图构建器，不需要配置文件，纯 TypeScript 加一个循环就能搞定。

演示中，一个问题触发模型请求两次工具调用，最终用真实数值正确作答——整个过程没有任何框架介入。作者犀利地指出，大多数所谓的框架，不过是为了运行一个模型请求的函数，却套上了厚重的机器装置。

核心认知：模型从不调用你的代码，它只是「请求」

理解 Agent 的关键在于一个认知转变：**模型永远不会直接调用你的代码，它只是提出请求。**模型返回的是一条消息，内容类似「请用这些参数运行这个工具」，而真正决定执行什么的，是你写的那个循环。

因此，模型的回复不是一个字符串，而是一组「块」（blocks）：有些是文本块，有些是工具调用请求块，每个请求块带着工具名称和参数。此外还有一个 stop reason（停止原因），用来告诉你模型是否已经完成任务。

这个数据结构上的理解，恰恰是整个 Agent 逻辑的基石。你不需要魔法，只需要读懂模型回传的这几种块。

这一设计并非偶然，而是源于大语言模型的推理机制。模型在生成回复时，本质上是在做下一个 token 的概率预测，它并不具备「主动执行」的能力。工具调用（Function Calling / Tool Use）是各家模型提供商在微调阶段加入的能力：通过特殊的系统提示和训练数据，让模型学会在适当时机输出结构化的 JSON 请求，而非自由文本。Anthropic 的 Claude 将这一结构称为「tool use block」，OpenAI 称之为「function call」，但底层机制相同——都是模型输出一段结构化数据，由外部代码负责解析和执行。

理解这一点有助于消除一个常见误区：框架并没有给模型赋予「调用代码」的神奇能力，它只是帮你自动完成了解析回复、路由到对应函数、将结果写回消息历史这几步机械性工作。手写循环让这个过程透明可见，框架则将其封装成黑盒。

整个 Agent 的逻辑：发送、接收、判断、循环

作者把完整的 Agent 流程拆解得极其清晰：

• 发送消息给模型，获取回复；
• 如果 stop reason 不是 tool use，说明模型已经完成，直接返回它的文本；
• 否则，模型想要调用工具。遍历每个工具调用块，验证参数、运行对应的函数，再把结果作为 tool result 消息推回去；
• 然后循环，让模型看到工具返回的内容。

而所谓的「工具」也毫不神秘——它就是一个普通函数，接收参数、返回 JSON。可以是计算器、搜索、HTTP 调用，每一个都只是一个函数而已。这种去魅的描述，让 Agent 从一个玄乎的概念回归到了工程本质。

两道防线让它达到生产可用

裸写循环并不意味着草率，作者提出了两个关键的「守卫」（guard）来保证生产环境的安全：

守卫一：派发前校验参数。 模型可能会「幻觉」出一个格式错误的参数结构。在真正执行工具之前先做校验，一个坏的调用应当直接抛出异常，而不是污染到你的工具函数里。

守卫二：步数上限（step cap）。 如果模型不停请求工具却永远不说「我完成了」，循环就会无限运行。设置一个 max steps 计数器，比如在第 5 步时抛出异常，就能阻止循环失控。

这两道防线补齐了「手写循环」在健壮性上的短板，让它不只是一个 demo，而是可以真正投入使用的方案。

什么时候该用框架，什么时候该手写

作者特别澄清：这不是说框架不好，而是要让工具匹配任务。

手写循环的适用场景是：你只有少量工具、单一模型提供商，并且希望能够清楚地读懂控制流。而当你需要支持多个模型提供商、需要链路追踪（tracing）、需要团队统一的开发约定时，就应该转向框架。

这种务实的分寸感，比单纯鼓吹「框架无用论」更有价值。它承认框架在复杂场景下的意义，同时也提醒开发者：在简单场景下，一个你能从头读到尾的循环，往往比一堆黑盒抽象更可控。

真实工具从哪来？答案是 MCP

最后一个问题：真实的工具从何而来？作者给出的答案是 MCP（Model Context Protocol）服务器。循环是大脑，而 MCP 是这个大脑安全触达你的文件、数据库和 API 的方式。

整套方案的理念贯穿始终——没有框架，没有魔法，只有一个你能从头读到尾的循环。值得一提的是，作者还强调这是「用 TypeScript 做 AI 工程，而非 Python」，这对习惯了 Python 生态的 AI 开发者来说，是一个有趣的视角切换。

MCP（Model Context Protocol）是由 Anthropic 于 2024 年底提出并开源的标准化协议，旨在解决 AI 模型与外部工具、数据源之间的集成碎片化问题。在 MCP 出现之前，每个应用需要为每个数据源单独编写集成代码，形成 M×N 的维护噩梦。MCP 将这一关系简化为 M+N：任何支持 MCP 的客户端（如 Claude、Cursor 等）都能与任何 MCP 服务器通信，而无需额外适配。

MCP 服务器本质上是一个轻量级进程，通过标准输入/输出或 HTTP+SSE 与宿主应用通信，对外暴露三类能力：工具（Tools）——模型可调用的函数；资源（Resources）——模型可读取的数据；提示词（Prompts）——可复用的提示模板。在 Agent 循环的语境下，MCP 服务器充当工具注册表与执行沙箱，既让模型能够发现可用工具，又通过进程隔离限制了工具的权限边界，避免 Agent 直接操作宿主进程的敏感资源。

写在最后

这篇内容的价值不在于教你一个新框架，而在于帮你撕开 Agent 的神秘外衣。当你理解了「模型只是请求、循环才是决策者」这一本质，你会发现很多复杂的框架概念都能被还原成几十行可读的代码。对于想真正掌握 Agent 工作原理、而不只是会调 API 的开发者来说，手写一遍这个循环，可能比看十篇框架教程都更有收获。