什么是AI智能体？它与聊天机器人的本质区别

同一个问题，交给两个AI：一个让你上传文件，另一个自己打开文件夹、写脚本、跑出答案——而且中途发现文件名错了，还能自己列目录纠正。这就是智能体（Agent）与聊天机器人（Chatbot）的差距。本文综合OpenAI、Anthropic、Google三家的官方定义，以及一个可复现的双模型对照实验，把"智能体到底是什么"讲清楚。

三份官方文档，指向同一个定义

据OpenAI的智能体指南，智能体是"代表你独立完成任务的系统"；同一份文档还明确列出了什么不算智能体——集成了模型但不用模型控制执行流程的应用、单轮响应的模型、分类器，都不算。Anthropic则把系统分成两类：工作流（Workflow）由代码预设固定路径，模型只负责填空；智能体（Agent）由模型动态决定流程和工具使用。Google在其白皮书中给出的说法是：智能体是"通过观察世界并借助可用工具对世界采取行动、以达成目标的应用"。

三份来源、三种措辞，但共同点高度一致：目标、工具、由模型自己决定路径。用一句话概括——聊天机器人负责回答，智能体负责做事。

对照实验：四个工具如何让模型"活"起来

实验设置很简单：同一个模型、同一个问题（那摞剧本里有多少场戏？哪段旁白最长？），唯一的变量是是否挂载工具。工具指的是模型可以请求执行的函数——列目录、读文件、写文件、跑脚本，四个工具全部限定在一个隔离的沙箱文件夹内。

没有工具时，聊天机器人只能回一句"请把文件发给我"：一次调用、一秒结束。挂上四个工具后，同一个模型变成了智能体：先列目录、再读文件，发现文件太大就写个脚本去跑，最后报出准确结果。路径完全不同——提问变成目标，然后观察、思考、调用工具行动、核验结果，最后才作答。整个循环多花了若干步、若干秒和大量token，代价更高，但答案是对的。

这个循环有学术源头：ReAct论文提出"推理与行动交替"——模型先想一点、行动一步、看结果、再想，循环往复。每次模型调用都能看到上一次的结果，所以它不是一次回答，而是一串调用。论文中测得的收益包括在任务类基准上显著提升、在购物类环境中同样有增益，且因行动带回了外部信息，幻觉有所减少。

ReAct（Reasoning and Acting）是2022年由Shunyu Yao等人在论文《ReAct: Synergizing Reasoning and Acting in Language Models》中提出的提示与推理框架。其核心思想是让大语言模型把"推理"（生成思考轨迹）与"行动"（调用外部工具并观察结果）交错进行，形成一个可追溯的循环。与只做链式思考（Chain-of-Thought）或只做行动的方法不同，ReAct让模型每走一步都能依据环境反馈修正下一步计划，因此特别适合需要多步查询、检索或操作工具的任务。论文在问答、事实核查、购物等基准上验证了效果：相比纯推理基线，ReAct减少了事实幻觉；相比纯行动基线，它又具备更好的规划和可解释性。这也解释了为何现代智能体普遍采用类似的"想—做—看"循环结构。

循环的四个环节，最关键是"核验"

这个循环可以拆成四步：观察（读目录、读文件、读报错）、思考（决定下一步）、行动（调用工具）、核验（检查返回结果），然后回到起点，直到任务完成或触达轮次上限。Anthropic在其Cloud Code文档中描述的也是同一套：收集上下文、行动、核验工作、重复。

实验中最能说明问题的是核验环节。研究者让智能体读"剧本第5版"，文件不存在——智能体收到报错后列目录、找到实际文件名、读取、写脚本、跑出结果。而把核验规则去掉之后，智能体只读了文件开头，重复了多次，最终给出了错误答案。区分有用的智能体和危险的智能体，不是智能水平，而是核验。

模型怎么"按按钮"？Function Calling与MCP

文本模型无法真的点击按钮。OpenAI推出的Function Calling机制解决了这个问题：你描述好函数，模型选择返回一段JSON，包含函数名和参数；你的代码执行后把结果回传给模型，模型再用自然语言作答。JSON是一种程序可以无歧义读取的文本格式，本质上是模型与代码之间的消息往返。OpenAI对它的概括是：一种更可靠地连接模型能力与外部工具、API的新方式，可用于让聊天机器人查数据、把自然语言变成API调用、抽取结构化数据。

实验里的对比例子很直观：要一个统计词频的脚本，聊天机器人把脚本正文贴给你；智能体则把脚本写成文件、跑起来、报出结果——它不是描述任务，而是完成任务。

在工具接入层面，还有一个开放标准：MCP（Model Context Protocol），官方定义是"连接AI应用与外部系统的开源标准"，其类比是"AI应用的USB-C接口"。协议意味着格式约定：所有工具用同一套方式描述，任何模型都能理解；一个MCP服务器可以暴露数据、工具和流程。支持MCP的客户端已经覆盖主流IDE与助手产品，工具只需构建一次，各种智能体都能调用。

MCP（Model Context Protocol）由Anthropic于2024年底开源发布，采用客户端—服务器架构。MCP服务器负责暴露三类原语：资源（Resources，可供读取的数据）、工具（Tools，可被调用的函数）和提示（Prompts，预置的交互模板）；MCP客户端则运行在AI应用或IDE中，负责与服务器建立连接、发现能力并把工具描述交给模型。传输层支持标准输入输出（stdio）和基于HTTP的SSE等，因此本地进程和远程服务都能接入。它解决的是工具接入的"N×M问题"：过去每个模型与每个工具都要单独适配，有了统一协议后，工具实现一次即可被任意兼容客户端复用，这也是其被类比为"USB-C接口"的原因。

智能体的解剖结构：三件套加一圈围栏

按OpenAI指南的拆解，一个智能体由三个组件构成：模型（负责推理和决策的LLM）、工具（用于行动的函数和API）、指令（定义行为方式的准则与护栏）。三者拼合，智能体成立。围绕它的是护栏：轮次上限、只允许在沙箱内操作、敏感动作（取消订单、付款、删除）一律暂停并转交人类。护栏是模型之外的规则，限定它能做什么、什么时候必须停下来问人。

沙箱（Sandbox）是一种受限的执行环境，通过操作系统级隔离（如容器、虚拟机或权限降级）限制程序可访问的文件、网络和系统调用。在智能体场景中，沙箱的作用是把模型的"行动能力"关进可控范围：即便模型被提示注入诱导去删除文件或外发数据，也只能在隔离目录内操作，无法触及宿主机敏感资源。实践中常配合只读挂载、网络白名单、资源配额和操作审计日志使用。沙箱并不等同于护栏，护栏是模型层的规则（如轮次上限、敏感动作暂停），沙箱是执行层的强制边界，二者叠加才能构成纵深防御。

产品化：从论文走进2026年的真实产品

据OpenAI Dev Day发布的信息，其推出的常驻型智能体产品每个都配有云端计算机、浏览器和你连接的应用，可长时间待命处理事务。官方同时给出明确提醒：这类智能体仍会出错，务必有意识地复核其工作；改密码等敏感操作始终由用户本人完成。

Google则推出统一在Gemini中的企业级智能体，据其Google Cloud CEO的概括：它接受的是目标而不只是指令，会规划、使用工具，可连接Workspace、Slack、Jira以及任意MCP服务器。一个值得注意的细节：智能体拥有自己的账号，以及一个任务面板，你能看到它把任务分派给子智能体——子智能体是主智能体为任务的某个子部分创建的小型智能体，其结果由主智能体事后核验。

用一个判断概括2026年的转变：过去你给指令，现在你给目标。

泼冷水：基准测试里的真实水平

有一个必须摆出来的"但是"。据一项基准测试，让智能体在零售和航空客服场景中按规则和数据库完成任务，当时表现最好的模型正确率不到一半。更严格的指标是pass^k——不是答对一次，而是同一任务连续答对多次。在该测试中，连续多次全对的概率不到四分之一。

Anthropic对此的解释是：智能体的自主性意味着更高成本和会累积的错误——循环的每一轮都可能出错，而第一轮的错误会成为第二轮的上下文。所以他们给出的建议听起来最不性感：寻找最简单的可行方案，只在必要时才增加复杂度。 一个精心设计的提示词能解决的问题，就不需要智能体。OpenAI在同一份指南里也划了人类介入的边界：当智能体超出尝试次数上限时，以及在敏感、不可逆或高风险动作上——取消订单、批准大额退款、发起付款——必须有人。

三条经验法则可以收尾：任务可预测、步骤固定，用工作流，别用智能体；任务开放、需要工具和反馈，用智能体，且必须带核验；涉及金钱、数据、密码，永远保留人在回路。

所以下次有人跟你说"智能体"，问三个问题：它有工具吗？它跑循环并核验吗？谁在看着围栏？

pass^k是评估智能体可靠性的严格指标，常见于τ-bench等基准。与pass@k（k次尝试中至少一次成功）相反，pass^k要求同一任务连续k次全部成功，因此对稳定性要求极高。若单次成功率只有p，且假设各次独立，则pass^k约为p的k次方，微小的单次失败率会被指数放大。这正是文中"连续多次全对概率不到四分之一"的由来：它揭示的不是模型偶尔不会做，而是即使会做也常常不稳定。对生产环境而言，pass^k比平均准确率更能反映用户体验，因为用户往往只运行一次，任何一次失败都意味着任务失败。