Agent 是什么

「Agent」这个词现在被用得太滥了，滥到几乎失去了含义：一个套了三层提示词的客服机器人自称 Agent，一个能查天气的插件也自称 Agent。所以这一节要做的第一件事不是夸它，而是把定义收紧——一个东西凭什么才配叫 Agent，以及它现在的真实水平到底在哪个刻度上。后半节我们会把四个权威基准的原始分数摊开来看，你会发现一件让人清醒的事：论文发表时，这些基准上的最好成绩普遍低到不像样。不是低 10%、20% 那种低，是「人类 78%、模型 14%」那种低。这不是要打击你，恰恰相反——只有知道它现在有多不靠谱，你才知道该在哪里放安全网。

把定义收紧：什么才算 Agent

业界对 Agent 没有一个像 RFC 那样的官方定义，但如果你把那些公认的 Agent 系统（能改代码的、能操作浏览器的、能跑多步研究的）摊在一起看，会发现它们共享四个特征。这四个特征缺一个，就退化成别的东西了。

简单说，用大白话总结这张表：Agent = 大脑（模型）+ 手（工具）+ 记性（状态）+ 一个「没干完就再来一遍」的循环。四样里最容易被忽略的是第四样。很多产品把前三样都做了，但只跑一轮就交差——那不叫 Agent，那叫一个接了工具的问答接口。

为什么「一个 while 循环」是关键分界

这里值得停一下，因为这是全章最重要的直觉。模型本身是一个纯函数：给它一段文字，它返回一段文字，中间没有任何「时间」。换成大白话——它不会等，不会看，不会试。所谓的「自主」完全不在模型里，而在模型外面那个循环里。

打个厨房的比方：模型是那口锅，火候到了它就把菜炒出来，你放什么它炒什么，它不会自己去尝一口。而 Agent 是站在锅前的人：他尝一口觉得淡了，撒盐，再尝一口，还是淡，再撒一点，直到觉得对了才关火。「尝—调—再尝」这个动作根本不在锅里，锅永远只是那口锅。

相当于再换一个更贴近办公室的说法：模型是那台打印机，你发什么它印什么，印歪了它不知道；Agent 是那个盯着打印机的人，他会拿起纸看一眼，发现歪了就重新对齐纸盒再印一次。本质上就是「谁在负责检查结果」这一件事的归属变了。

说白了，当有人说「这个模型是一个 Agent」时，严格来说是句错话。模型不是 Agent，模型是 Agent 的一个零件。Agent 是一段程序，这段程序恰好在每一轮里都去问一次模型。这个循环最朴素的形态，我们在这一节末尾会直接给出代码，你会发现它短得让人意外。

一个真实的多 Agent 系统长什么样

讲局限之前，先看一个真东西。Anthropic 在工程博客《How we built our multi-agent research system》（我们是怎么造出多智能体研究系统的）里，把他们自家研究功能的架构完整地公开了。作者是 Jeremy Hadfield、Barry Zhang、Kenneth Lien 等人。这份材料的价值在于：它不是宣传稿，里面大半篇幅在讲踩过的坑。

它的架构叫 orchestrator-worker（编排者—工人模式）。用餐厅打比方最好懂：orchestrator 是那位站在传菜口的主厨，他不亲自炒菜，只负责看单、拆菜、分派给各个灶台；worker 是各个灶台的厨师，各自炒自己那一道，互不干扰。

这里有一个细节特别值得单独拎出来说：LeadResearcher 为什么要把规划「存进 Memory」？因为上下文一旦超过 200,000 token 就会被截断。换成大白话：它的短期记忆有一个明确的物理上限，超过就会被剪掉，剪掉的部分就真的消失了。所以它必须像出门前把清单抄在纸上一样，把计划落到外部存储里，否则跑到一半自己都忘了原本要干什么。这是「为什么 Agent 一定需要外部记忆」这个问题最具体、最有出处的官方答案，我们在 §11.3 会顺着这条线往下讲。

另外要注意「各自持有独立上下文」这个设计。它的好处是互不干扰、能并行、总的可用上下文被放大了好几倍；它的坏处是三个 Subagent 之间是瞎的——A 查过的东西 B 不知道，于是很容易重复劳动。这个坏处马上就会在下面的「协调失控」里现形。

局限一：错误会累积，而且没有刹车

这一条听着玄，其实就是「一步错、步步错」在自动化系统里的放大版。这是 Agent 和普通软件最本质的差别，也是官方讲得最重的一条。原文是：

为什么普通软件不会这样？因为普通软件是无状态的流水线：这一步的输出就是下一步的输入，输错了通常当场报错。而 Agent 是把前面所有步骤的结果都塞回上下文里，然后基于这一整坨去决定下一步。一步错了不会报错，只会让它基于错误的前提继续做出看起来完全合理的决策。

用洗衣服类比：普通程序像洗衣机，你放错了洗涤剂，它顶多把衣服洗坏，程序本身照跑照停。Agent 像一个替你打理全屋衣物的人：他第一步把「羊毛衫」误判成了「化纤」，于是接下来选了高温水、选了强力甩干、烘干时又选了高档，最后拿出来一件缩成童装的毛衣。每一个后续动作单独看都是「对化纤衣物的标准处理」，完全合理，错只错在第一步的前提。这就是错误累积最可怕的地方：它不表现为报错，而表现为一整套自洽的错事。

所以做 Agent 的第一手艺不是提示词，而是在哪里放检查点。凡是「做了就无法撤销」的动作——发邮件、付款、删数据、提交代码——都应该有一道人工确认或者一道可回滚设计。这个原则在 §11.5 讲 ReAct 循环时会具体落成代码。

局限二：同样的提示词，跑两次结果不同

换成大白话：同一道题让它做两遍，它可能走两条完全不同的路。官方原文：

这句话对工程师的杀伤力比它看起来大得多。传统测试的整个地基是「输入固定 → 输出固定」：你写一个断言说 assert f(2) == 4，明天跑、明年跑都成立。而 Agent 这里，同一个输入今天走了 5 步查了 3 个来源，明天走了 9 步查了 7 个来源，两次的答案都对但内容不一样，你连断言都不知道该怎么写。

更麻烦的是调试。普通 bug 你能稳定复现：跑十次错十次，打断点一步步看。Agent 的 bug 常常是跑十次错一次，而且你复现不出来。用看病打比方：普通 bug 像骨折，拍个片子清清楚楚；Agent 的 bug 像偶发的心悸，你带着病人去医院，到了那儿他好了。

业界应对这件事的办法（属于工程实践共识，不是某篇论文的结论）大致三条：第一，记全量轨迹——把每一轮的模型输入、模型输出、工具调用、工具返回全部落盘，出问题时靠回放而不是靠复现；第二，改用统计式评测——不再问「这次对不对」，而是问「跑 50 次里对了几次」；第三，用模型评模型——让另一个模型按评分标准去判断结果好坏，因为答案不唯一，字符串比较已经没意义了。第二条恰好就是下面 τ-bench 那个 pass^k 指标的思路来源。

局限三：协调失控——50 个副手去查一件小事

这一条是全节最好笑也最有教育意义的一条，因为它太具体了。官方原文：

三个错各对应一种典型病症，我们逐个翻成大白话。

第一个，「50 个 subagent 查一件小事」——用力过猛，没有成本感。类比一下：你让办公室的组长去查一下「公司门口那家咖啡店几点关门」，他召集了 50 个人开会，给每个人分配了一个调研方向。模型没有「这件事值多少功夫」的天然分寸感——它不知道派 50 个副手意味着 50 倍的 token 花费和 50 倍的出错面。这个分寸感必须由你在提示词和代码里硬性规定：简单问题最多派 1 个，复杂问题上限 5 个，等等。

第二个，「为不存在的资料把网翻个底朝天」——不会承认查不到。人类研究员翻了二十分钟没找到，会说「这个数据可能没有公开」。而 Agent 会继续换关键词、继续翻页、继续换搜索引擎，因为它的任务描述里写着「找到 X」，而「X 不存在」这个结论它不敢下。这就像让一个新来的实习生去档案室找一份从来没归档过的文件，他会在档案室待到下班——因为他觉得找不到就是自己没本事。所以你必须显式告诉它：「如果找了三轮还没有，就直接回答「未找到」，这是一个合格的答案。」

第三个，「用过多的更新互相干扰」——通信本身也是噪音。三个 subagent 互相汇报进度，结果每个人的上下文里都塞满了别人的碎片进度，真正干活的空间被挤掉了。像一个五十人的项目群，每个人每十分钟发一句「我这边还在跑」——群是活的，活是死的。

官方还给了一个更精细的分工失效例子，非常值得记住：一次任务里，一个 subagent 跑去调查 2021 年的汽车芯片危机，而另外两个 subagent 在重复调查 2025 年的供应链。三个人干了两件事，其中一件被干了两遍，还有一件跑偏到了四年前。

为什么会这样？回到前面说的架构细节：Subagent 各自持有独立上下文，它们彼此是瞎的。A 不知道 B 正在查什么，所以「不要重复」这件事只能靠 LeadResearcher 在派活时就把边界划死。用装修类比：如果包工头只说一句「你们三个把这屋子弄好」，那必然有两个人在同一面墙上打钉。他必须说「你负责水电、你负责吊顶、你负责地面，谁都别碰别人的活」。Agent 的任务描述里，「你不负责什么」和「你负责什么」一样重要。

局限四：它不会天然地判断来源可靠性

打个比方，这就像一个刚学会用超市货架的人：他会拿最显眼、摆在最前排的那一盒，而不是翻到后面去看保质期更好的那一盒。本质上就是「显眼」被误当成了「可靠」。这一条我认为是普通人最该知道的一条，因为它直接关系到你该不该相信 Agent 给你的答案。官方在人工测试中发现，早期 agent：

先翻译两个词。SEO（Search Engine Optimization，搜索引擎优化，读作「艾斯依欧」）就是「专门想办法让自己排在搜索结果前面」的一整套手艺。内容农场（content farm）指那种批量生产、互相抄袭、质量很水但极其擅长排名的网站。

这件事的机制一点都不神秘：Agent 看到的「世界」，就是搜索结果的前几条。而搜索结果的排序是 SEO 竞赛的结果，不是可靠性竞赛的结果。它没有办法像一个老研究员那样，看一眼域名就知道「这家不能引」。

用菜市场类比最贴切：一个刚学做饭的人去买鱼，摊位上摆得最漂亮、灯打得最亮、老板嘴最甜的那家，他就买了。老手会绕到市场最里面那个不起眼的摊位，因为他知道那家的货是今早刚到的。Agent 现在就是那个刚学做饭的人——它分不清「摆得漂亮」和「货好」。

所以在真实系统里，来源可靠性必须由你外部注入，常见做法（工程实践，非官方规范）包括：白名单/黑名单域名、给不同来源打权重分、要求它必须给出原始出处链接、用一个独立的核对环节复查引用——最后这条正是官方那个 CitationAgent 存在的理由。

局限五：同步执行的瓶颈

还有一条偏工程但影响很大的局限：lead agent 是同步等待 subagent 的。翻成大白话就是三件事：

• 中途没法插手派出去之后，在它跑完之前你没法改指令、没法叫停、没法追加信息。像把一封信寄出去了，剩下的只能等回信。
• 一个卡住，全体卡住五个 subagent 里有一个卡在一个死循环搜索上，整个系统就停在那里等它。木桶效应，最慢的那块板决定一切。
• 不能边跑边协作subagent 之间无法在过程中互相看到彼此的发现，只能各跑完各自的、最后汇总。这也是上面「重复调查」的结构性原因。

为什么不做成异步？因为异步会带来更难的问题：状态一致性、结果乱序到达、部分失败怎么处理。这是一个典型的「简单但有瓶颈」对「复杂但更强」的工程取舍，不是能力不够，而是复杂度预算的分配。

它现在到底行不行：四个权威基准

前面讲的都是「怎么坏」，现在讲「坏到什么程度」——用数字。下面四个基准是目前学术界和工业界公认最能衡量 Agent 能力的四把尺子。重要提醒：下表所有分数都是「论文发表时」的数字，不是今天的水平。这三年模型进步很快，这些分数都涨了不少。但我们仍然要看这些原始数字，因为它们标出了一个起点，让你知道这条路有多陡。

先说一件事：GAIA 那一行的对比是最刺眼的。人类 92%，GPT-4 带插件 15%。而 GAIA 的题目按官方描述是「对人类很简单」的问题。这个 92% 对 15% 的落差，恰好说明了 Agent 现在真正缺的不是知识，而是「把好几个步骤串起来不出错」的这种能力。用学校打比方：这不是知识点没背会，是应用题读不懂题意、算到第三步串行了。

pass^k：一个比「成功率」诚实得多的指标

τ-bench 提出的 pass^k（读作「pass 的 k 次方」）这个指标，我认为是整个 Agent 评测领域最值得普通人理解的一个概念。说白了它就一句话：同一个任务连续跑 k 次，k 次全都成功的概率。

为什么这比普通成功率重要得多？打个外卖的比方。有两个骑手：

两个人的「成功率」写在报表上都是 90%，但你会愿意长期用 A，不愿意用 B。因为生活是连续的，你不是只点一次外卖。同理，一个客服 Agent 每天处理 500 个咨询，你关心的不是「平均对 80%」，而是「会不会今天下午突然连着搞砸五个客户」。

数学上，如果每次都独立且成功率为 p，那么 pass^k 就是 p 的 k 次方。我们把这个算出来看看有多残酷：

这张表就是「为什么演示很惊艳、上线就出事」的全部数学原因。演示只跑一次，看的是 p。生产每天跑几千次，看的是 p 的 k 次方。0.95 的八次方只有 0.66——一个「95 分」的 Agent，在连续八步的任务上是个不及格的东西。

τ-bench 论文的结论原文是：

注意这里有个细节值得琢磨：如果真的完全独立，0.5 的八次方应该是 0.4%，而实测 pass^8 是「不到 25%」——比独立假设高很多。这说明失败不是随机撒开的，而是集中在特定的难题上：容易的任务它八次都能对，难的任务它八次都错。这其实是个好消息，意味着问题是可定位、可专项修的，而不是弥散性的手抖。

SWE-bench 的近况与它的五个变体

SWE-bench 是这四个里最出名的，也是变化最快的。截至 2026 年 8 月 7 日查询官网 swebench.com 的 News 栏目，能核实到的官方动态有：

• 2024-08 · Verified与 OpenAI 合作产出的 500 题人工筛选子集。为什么要做这个？因为原始 2294 题里有一部分题目本身描述不清或测试有问题，人工筛过一遍才能公平比较。现在大家报的分数基本都是 Verified 上的。
• 2025-07 · mini-SWE-agent用 100 行 Python 在 SWE-bench Verified 上取得 65%。这个数字很有意思：从 Claude 2 的 1.96% 到 65%，同时脚手架代码反而变得极简。说明这两年提升的主要不是「框架有多复杂」，而是模型本身的能力。
• 2025-11 · CodeClash官方推出的新项目，域名 codeclash.ai。方向是让不同的 Agent 在编码任务上直接对抗比较。

它的五个变体规模，做技术选型时会用到：

Agent、工作流、Copilot、RPA：四个最容易混的东西

本节开头那张表给了 Agent 的四个特征，但真正让人困惑的往往不是定义本身，而是「那我手上这个东西到底算不算」。所以再补一张横向对照表，把市面上四类经常被混为一谈的东西摆到一起。先把两个缩写当场翻译清楚：

• Copilot（副驾驶）字面意思就是飞机上的副驾驶。特点是——它坐在你旁边给建议，方向盘始终在你手上。代码补全就是最典型的形态：它写一段，你决定接不接受。
• RPA（Robotic Process Automation，机器人流程自动化）一种早于大模型很多年就有的技术。说白了就是：录一段「鼠标点这里、键盘敲那个、再复制到这一格」的操作脚本，让机器每天照着重放一遍。它极其可靠，但也极其死板——界面挪个位置它就全废了。

这张表里最值得琢磨的是第三行和第四行的分界——工作流和 Agent 的区别不在于用了多强的模型，而在于「路线是谁排的」。很多团队宣称自己上了 Agent，实际做的是：写了一段有七个步骤的流程，每步调一次大模型。这是工作流，而且这没什么不好——恰恰相反，凡是能用工作流解决的事情，就不该用 Agent。

为什么？因为前面那些基准分数已经说明了问题：自主性是要付代价的。你把「决定下一步」的权力交给模型，就同时把「决定错了」的风险也交出去了。而工作流的路线是你排的，它虽然笨，但它可预测、可测试、出错能定位。

用装修打个比方：贴瓷砖这种活儿，流程是固定的（弹线、抹灰、上砖、勾缝），你要的是一个严格照流程干活的工人，不是一个会「临场发挥换个新贴法」的工人。而「这套老房子该怎么改」这种活儿，才需要一个能自己看现场、自己判断、自己调整方案的人。所以选型的第一个问题永远是：这件事的步骤是固定的吗？固定就用工作流，不固定才上 Agent。

那什么任务现在真的适合交给 Agent

把上面全部内容合起来，可以得出一套相当实用的判断标准。核心思路是：既然它单次成功率不高、错误还会累积，那就只在「错了代价小、对了收益大、而且能验证」的地方用它。

第四行「失败的可见性」是最容易被忽略、也最要命的一条。换成大白话：一个会大声报错的 Agent，比一个悄悄给出似是而非答案的 Agent 安全得多。报错你会去修；而一份格式漂亮、语气自信、其中一个数字算错了的报表，会一路流到老板的会上。

这就像找人帮你去菜市场买菜：他买错了菜（拿了茄子而不是西葫芦），你回家一看就知道，换掉就行；可他要是买了一条不新鲜的鱼，看起来一模一样——这种错误你要到吃完才发现。所以正确的做法不是「不让他买」，而是「让他买那些一眼能看出好坏的东西」。

最后给一条贯穿全章的准则，后面五节都会不断回到它：给 Agent 的自主权，应当正好等于「它出错时你能承受的损失」。这句话既不悲观也不乐观，它只是把上面那些真实分数翻译成了工程决策。