随着Nano Banana Pro的爆火，AI Agent的必要性再次成为热议话题。本文将探讨AI Agent的三种演进范式：工具调用、系统协作和原生智能，解析它们在不同阶段的技术本质和现实挑战。

最近一直在想，这AI Agent到底是什么？

这个问题原本没那么急，直到 Nano Banana Pro 突然爆火。

我第一次看到它处理中文长段文本、图中文字这种原本模型最容易翻车的场景时，说真的有点愣住。那效果……不夸张地讲，是直接把之前所有痛点 一刀砍掉的那种

如果有同学还没体验过，我也不瞒你——这篇文章里的所有配图全是用 Nano Banana Pro 生成出来的。

于是一个很现实的问题就摆在眼前：模型越来越强，那 Agent 还需要吗？

我也确实纠结过，尤其是我在公司做了很多图像类的 Agent：海报 Agent、电商商品 Agent、素材生成 Agent……

以前为了让模型不犯傻，我们得在 sys prompt 里写一大堆规则、逻辑说明、流程限制，生怕它跑偏。

但如果换成 Nano Banana Pro，sys prompt 可以直接砍掉三分之二，剩下的基本就是“workflow 指令”——告诉它你要做什么，它自己基本能推下去。

这时候你很容易产生一个直觉：

“那 Agent 不就是给 API 套个壳吗？模型够强了，壳自然没用了。”

但后来我越想越觉得，这个理解还是太肤浅。

模型变强确实会让系统搭建的复杂度骤减，但 Agent 的意义从来不是简单把模型包一层 UI，也不是写个调用 API 的壳子，更不是把 prompt 贴在前面就算完事。

回到我刚接触 AI Agent 的那段时间，我也天真地以为 Agent 就是给模型套个壳。后来真正参与公司里的商业化项目后才意识到： Agent 不是一个静态概念，它是 随着底层模型能力的跃迁 + 工程方法论的演化 一起往前跑的。

最开始，我们只是希望让 LLM 能“动起来”——

别只会输出文字，也能查资料、调接口、跑代码。

那会儿的目标特别朴素：给模型多几只手、多几只脚，让它能真的跟外部世界连接。

走着走着，发现光靠一个模型肯定不够，就开始让多个智能体协作：

有人规划、有人执行、有人兜底、有人复盘……

系统慢慢变成一个“小团队”，但说实话，这很大一部分都是工程师在堆出来的，不算真正的智能。

而现在，我们又进入一个新阶段——

我们不再满足于堆角色、堆流程，而是开始希望：“规划、反思、记忆、工具使用”这种更高阶的能力，可以被内化到模型里，让它是真的会“工作”，而不是按我们写好的剧本往下跑。

为什么演进会发生？

答案也不复杂：模型能力在狂飙。

OpenAI 的报告里提到，最前沿的模型现在已经能连续推理数小时，任务完成时长每七个月就翻倍。

回想几年前，模型也就撑个三十秒推理，顶多帮你补补代码。现在它能撑完整个开发链路，从需求拆到上线。

你如果站在这个角度回头看，会发现：

Agent 的范式演进不是大家拍脑袋发明出来的，而是模型能力推着我们往前走——

能用工具 → 能协作 → 能自己长能力。

写下这些，也不是想给谁上理论课，更像是把自己这两年踩过的坑、读过的报告、做过的项目揉在一起，整理点感觉出来。后面我会依着这三个范式，一个个拆开聊：它们各自的技术底子是什么，为什么能跑通，又在哪些地方会明显卡壳。

说到底，我们都在同一条船上。

早点把方向想清楚，走路的时候，心里多少能少点焦虑吧

Agent的演进框架

范式一：工具调用（Tool-Use）

这是 Agent 的起点形态，也是最早一批产品能真正落地的地方。说白了，就是给大模型装上手脚，让它别只会在那儿打字，而是真的能去查资料、调接口、算数据、跑流程。模型按你的指令先想一想怎么干，然后再去调工具拿结果，最后再回来继续推理。

这个阶段的 Agent，最像一个很聪明、执行力很强的助理。工具怎么用，它门儿清；流程跑不跑得通，也基本都能搞定。只是，它更多是按照“教条”在做事，知道怎么调用，但并不真正明白为什么这么选是最优解。很多时候，只要任务一复杂，流程一分叉，就很容易卡在线性路径的某个节点上。

范式二：系统协作（Multi-Agent System）

当大家发现单一模型扛不住复杂任务时，行业自然而然就开始拆分能力，搞协作。于是就出现了各种多智能体架构：有人负责规划，有人专做执行，有人盯着校验，有人做兜底，每个角色各司其职，再通过状态管理和反馈循环把这些人“焊”成一个系统，像个小型项目组。

这种模式的威力确实大，很多过去几乎做不了的复杂任务，忽然就变得可行了。但问题也逐渐显现出来：这些“智能”，本质上都是工程堆出来的。协作逻辑写得越多，系统就越复杂，也越脆。实际落地的时候，经常会有一种很真实的感觉——不是 Agent 自己变聪明了，而是我们在拼命帮它补脑子。可以说，这是一种典型的组装式智能。

范式三：原生智能（Native Intelligence）

而现在，事情正在进入一个完全不同的阶段。我们已经不太满足于靠外部角色编排、流程控制、规则补丁来硬怼能力了，而是开始希望，把规划、记忆、反思和工具使用这些认知能力，直接内化到模型本身——像肌肉记忆一样刻进去。不是告诉它“一步步怎么做”，而是让它自己学会怎么干活。

这其实是从工程智能向模型智能的一次大转向，从拼装系统，到智能体自己生长。这个阶段的 Agent，更像一个真正独立干活的专家，而不是被牵着线跑流程的执行器。

详细拆解一下：

范式一：工具调用

AI Agent的第一个范式，也是所有后续复杂系统的基础，是”工具调用”（Tool-Use）。其核心思想简单而强大：大型语言模型本质上是一个封闭的、基于其训练数据的文本生成系统，它没有实时的外部信息，也无法直接与现实世界或数字环境进行交互。

说白了，它做的事情很简单：给大模型装上手脚。

原本 LLM 只活在自己的语料世界里，没实时信息，没办法直接动外部系统，更别说操作真实的数据和流程。工具调用这套玩法，就是给模型配一整套工具箱，让它能查资料、调接口、算数据、跑代码，也就终于能“下场干活”了。

1. 技术本质：一次次“思考-行动”的朴素循环

实际跑起来的时候，模型先理解需求，心里大概过一遍：这事我靠嘴能解决吗？解决不了就得工具上场。接着它就会输出一段很规范的调用指令——感觉特别像我们在公司里给开发提需求那一刻：接口怎么调，参数怎么传，期望什么结果，全写清楚。外部系统照着指令真去调 API、跑代码、执行命令，再把结果丢回给模型。模型再基于返回结果继续判断，往下推，或者直接收尾给答案。

看起来一整套流程挺复杂，其实本质就是一个非常朴素的循环：想一想 → 干一件事 → 看结果 → 再想下一步。

现在很多 coding agent，基本都在用这一套。

OpenAI 的报告里也提到，新的模型已经可以直接调用编译器、测试运行器、扫描器，能产出“可验证结果”，而不是只给一些听着还行、实际上没法落地的建议。就拿修 bug 这个最常见的场景来说，一个标准的工具调用 Agent，真正跑任务时，往往是这么一套流程：

1. 调用ReadFile工具读取相关代码文件，获取问题代码的完整上下文。
2. 分析代码逻辑后，调用WriteFile工具应用补丁，修改相应的函数或模块。
3. 调用RunTests工具（一个测试运行器）来验证修复是否成功，获得客观的反馈。

如果测试失败，它会接收到详细的错误日志，并基于此信息进行新一轮的修复尝试，形成反馈循环。

这个过程的本质，说白了，就是模型在一个单次或简单的多步推理中，不断地与一系列预设的、功能明确的工具进行交互。这一趟下来，说到底也没什么玄学。模型就是在多步推理里，不断跟一堆功能很清晰、能力很固定的工具打交道而已。最原始的 Agent，本质就是一个循环，而工具调用，是这个循环里最核心的动作。

2. 能力边界与现实挑战

工具调用范式极大地扩展了LLM的能力边界。它使得模型能够：

• 获取实时信息 ：通过调用搜索引擎或新闻API，Agent可以回答关于当前事件的问题，突破了LLM训练数据的时间限制。
• 执行计算与逻辑操作 ：通过调用计算器或代码解释器，Agent可以解决复杂的数学问题和算法挑战，弥补了LLM在精确计算上的不足。
• 与外部服务交互 ：通过调用各类Web API，Agent可以实现预订、下单、发送邮件等功能，真正与数字生态集成。
• 操作本地环境 ：通过执行代码或命令行工具，Agent可以管理文件、运行程序、配置系统，拓展其影响力边界。

但真正做项目的时候，很快就能感受到另一面——这种聪明，其实特别依赖我们背后的工程设计。工具本身好不好用，SDK 抽象稳不稳，流程预设清不清晰，都会直接影响 Agent 最终跑得有多顺。

有点像一个重度工具依赖型工匠。

你给他一套顺手的工具，他干活快、准、稳；

给他一套凑合能用但经常卡壳的工具，他能干是能干，就是各种翻车。

我自己在项目里踩过的坑，几乎全都和这里有关。很多开发者分享的一线实践，也都绕不开这些问题：

2.1 SDK抽象不稳

为了简化工具调用，社区涌现了许多高层抽象SDK（如Vercel AI SDK）。这些SDK试图在不同的LLM提供商（OpenAI、Anthropic、Google等）之上建立一个统一的接口，使开发者能够更容易地切换模型或支持多个提供商。但其实，这些统一抽象在面对真实的工具使用场景时往往会崩溃 。 开发者发现，不同模型在工具调用机制、消息格式、缓存管理等方面存在显著差异。

例如，Anthropic的provider-side tools 在使用Vercel SDK时，消息历史经常丢，模型根本接不上之前的状态；但一换回官方原生 SDK，问题就立刻少很多，错误提示也更明确，缓存管理也舒服不少。

这就说明即使是看起来最简单的工具调用，底层实现也远没有标准化。我们为了获得完全的控制权，为了应对模型之间的细微差异，往往得放弃这些高层抽象，回归到更底层的原生SDK，甚至得自己驱动Agent循环。

这一下子就增加了开发难度和复杂度，也说明这个范式在工程实践上，还处于一个混乱的阶段。

作为产品经理，每次面对这种选择，心里都犯嘀咕，是选省事儿但可能踩坑的抽象层，还是选麻烦但更稳定的底层方案？这些细节，只有自己亲自落地跑过一遍，才会真正意识到

2.2 工具设计的复杂性与行为不可控

工具本身的设计，也是个大挑战。我记得有个特别有意思的例子，就是”output_tool”。在一个不直接跟用户聊天的Agent里，你可能会设计一个专门的工具，比如`SendEmail`，让Agent在任务完成的时候，主动给用户发邮件。

可实际操作起来，你会发现，要引导Agent在合适的时机、用合适的语气、合适的措辞去使用这个工具，是惊人地困难。

尝试过让输出工具内部再调用一个轻量级LLM来调整语气，但这又会增加延迟，降低输出质量，因为子工具没法完全获取主Agent的完整上下文。

更要命的是，Agent有时会“忘记”调用这个输出工具，或者因为各种原因压根就没触发 所以，我们还得通过外部机制，比如在Agent循环结束时，检查它有没有调用这个工具，如果没有，就强制给它注入一条消息，让它必须执行。

这揭示了工具调用范式的一个深层问题：模型的行为，并不总是像我们想象中那样可控。简单的指令和工具定义，根本不足以保证在复杂场景下的可靠性。就像你教一个小朋友用剪刀，他学会了剪东西，但什么时候剪、剪什么、怎么剪才好看，他可不一定能完全理解你的意图。

2.3 线性流程的局限性：当Agent走进死胡同

工具调用这一套，天生就特别擅长干那种“按步骤走就能搞定”的活儿。

一步一步来，先干这个，再干那个，只要路径是清楚的，基本不会出什么大问题。很多自动化任务能跑通，靠的也是这个逻辑。

但真到复杂一点的场景，这套线性思路就开始明显吃力了。

比如任务要并行推进：多条线同时搜集信息、同步对比结果；

比如需要回溯纠错：走到一半发现方向错了，得退回到某个关键节点重新选路；

又比如本身就存在多种失败分支，需要不断试错、切换路径去探索。

这些事，本质上都对“全局状态管理”和“动态调度能力”要求很高。而简单的工具调用循环，并没有把这些能力内置进去。它就像只会沿着一条既定轨道往前开的小火车，一旦轨道断了，列车就只能原地趴窝，没有“绕路”和“掉头”的选项。

实际体验的时候，这种局限感受会特别明显。

举个最容易理解的例子。

如果你让 Agent 做一份市场调研，需要同时搜好几个关键词，把结果拉回来横向对比分析。在理想情况下，它应该多线并发：一边查 A，一边查 B，一边查 C，最后统一整理。

可在线性工具调用模式下，它往往会老老实实一个一个搜：

先搜第一个，等结果出来；

再搜第二个；

然后第三个……

效率本来就低，一旦中途有个站点打不开、接口超时、返回异常，它很容易就卡在那一步，不知道该怎么处理。既没有机制让它自动切换其他路径，也不会主动退回到上一步重新选择策略，就像程序死循环一样，一直耗着。

你会明显感觉到：

不是模型变笨了，而是框架本身限制了它的行动方式。

说到底，这也是工具调用范式最核心的天花板之一——它过度依赖“单链路 + 顺序执行”的工程逻辑，在复杂任务下，几乎没有弹性空间。

能跑的都很稳，跑不了的，基本直接撞墙。

也正是因为这些越积越多的死胡同体验，大家才慢慢意识到，光靠给一个 Agent 加工具，解决不了复杂协作和动态决策的问题。于是，才有了后续的思路转向：不再死磕单体智能体，而是开始尝试用“组织化”的方式，去拼一个能分工协作、彼此兜底的系统。

这，也自然把我们带到了第二个范式——系统协作。

范式二：系统协作

当大家发现单一模型扛不住复杂任务时，行业自然而然就开始拆分能力，搞协作。于是就出现了各种多智能体架构：有人负责规划，有人专做执行，有人盯着校验，有人做兜底，每个角色各司其职，再通过状态管理和反馈循环把这些人“焊”成一个系统，像个小型项目组。

这种模式的威力确实大，很多过去几乎做不了的复杂任务，忽然就变得可行了。但问题也逐渐显现出来：这些“智能”，本质上都是工程堆出来的。协作逻辑写得越多，系统就越复杂，也越脆。实际落地的时候，经常会有一种很真实的感觉——不是 Agent 自己变聪明了，而是我们在拼命帮它补脑子。可以说，这是一种典型的组装式智能。

1. 技术本质：工程驱动的“组装智能”

范式二的本质，我理解就是一种组装智能。单个LLM在长程规划、复杂状态管理、从错误中学习等方面仍有局限，因此通过外部的工程手段来弥补这些不足。其系统架构通常包含以下几个关键组件，这些组件在开发者的一线实践中得到了反复验证和强调。

1.1 主-子智能体架构

复杂的任务被分解，并分配给不同的专家子智能体。一个主智能体（或称为协调者、主循环）负责理解总体目标、分解任务、调度子智能体，并整合它们的结果。这种分工模式在编码Agent中尤为常见。例如，一个复杂的软件开发任务可能被分解为：

• 规划Agent ：读取需求文档，深入理解业务目标，生成详细的执行计划（如PLAN.md），明确每个开发步骤。
• 代码生成Agent ：根据计划的某个步骤，编写具体的代码，专注于代码质量和设计模式。
• 测试Agent ：为生成的代码编写并执行单元测试和集成测试，确保功能正确性。
• 调试Agent ：在测试失败时，分析错误日志并提出修复方案，有时甚至直接生成修复代码。

这种分工模式的优势是显而易见的。每个子Agent可以专注于自己的特定领域，累积该领域的”专业知识”（通过系统提示和上下文），从而比一个通用Agent更加高效和准确。

包括我之前做过的设计类的Agent，则是分解为：规划Agent、设计方案Agent、提示词撰写Agent、生图Agent。

这种架构还带来了另一个重要优势： 失败隔离 。当一个子Agent失败时，只有该Agent的上下文被污染，而不会影响其他Agent或主循环的决策。这种隔离可以防止失败的级联效应。

1.2 共享状态层 的关键作用

真正在做多智能体和复杂工具协作的时候，我越来越觉得，一个共享、可持久化的工作空间，几乎就是整个系统的命根子。

我们经常在内部说一句话：不要做一个“有死胡同”的 Agent 系统。听着有点抽象，但干过的都懂。

所谓死胡同，其实非常具体——

就是某个工具的输出，只能被另一个指定工具消费，数据流被写死，流程就被卡死了。一旦真实需求和这条固定链路对不上，整个 Agent 就像走进了断头路，继续不下去，也不会拐弯。

举个特别典型的例子。

如果有一个图像生成工具，它产出的图片只能直接交给图片编辑工具处理，那这条链路看上去很顺。但万一用户真正想干的是——把几张生成图直接打包成 zip 发邮件呢？这时候 Agent 就懵了。因为系统根本没给它预留“跳出原流程”的空间，它不知道该怎么把图片交给压缩工具、更别提再接到发件流程里。

问题根本不在模型能力，而在好多早期系统的架构设计，本身就没给数据流留出口。

比较靠谱的解决思路，其实也不复杂——引入一个类似文件系统的共享状态层，通常就是一个虚拟文件系统。所有工具不再直接把数据塞给指定的下一个工具，而是统一读写这个公共空间，相当于给整个 Agent 系统准备了一块共享硬盘。

一旦有了这层东西，事情立刻就变得灵活起来。

比如：

图像生成工具 generate_image，不是把图片“交给下游工具”，而是直接把输出写到一个共享路径，比如： /workspace/images/output.png

一个完全不同的工具，比如 ExecuteCode，可以随时从这个路径把图片读出来，用 zip 命令压缩打包，再输出成新的文件。

反过来，假如是代码执行工具解压了某个文件： unzip /workspace/data.zip -d /workspace/extracted/ 那么 RunInference 之类的分析工具，也可以直接读取解压后的内容继续往下跑流程。

所有工具围绕着这一块共享空间运转，彼此之间不需要认识对方是谁，只需要遵守同一套读写规范

说实话，这个改动，对整个 Agent 架构的影响非常大

它几乎是把系统从“固定流程拼装机”，直接拉到了 即插即用平台 的形态：新工具只要接入统一接口、能对共享空间读写，就可以立刻融入系统，主 Agent 的逻辑根本不用动。

从某种意义上讲，这个共享状态层就是 AI 内部真正的一块共享硬盘。

而正是靠它，跨工具的数据流才不再被写死，跨 Agent 的协作才真正有了现实基础。

1.3 强化与反馈循环

在系统协作这个范式里，我越来越觉得，所谓“智能”，其实很大一部分就藏在那套不断运行的反馈循环里。

这里讲的强化，跟训练阶段用的强化学习不是一回事。不是给模型涨奖励、调权重，而是发生在 运行时 ——在 Agent 执行任务的过程中，我们不断往上下文里注入提示信息，去提醒、校正、拉回它的行为。

真实项目里特别常见的一种情况是： Agent 出问题，往往不是因为它“不会做”，而是单纯 走丢了 ——要么忘了最初在干嘛，要么做着做着偏离了原本的路线。这个时候，比起重新推翻重来，大多数时候只需要一次轻量的提醒，它就能被拉回正轨。

所以强化在实际系统里，承担的责任，比最初预想的要重得多。

这种运行时强化，用得地方其实特别广：

第一种，目标提醒。

在多步复杂任务中，每次工具调用之后，系统都可以塞一条简单明了的消息给 Agent，比如：

别忘了你的最终目标是 X，目前子任务 Y 已经完成。

它的作用非常直接——对抗长上下文导致的目标漂移。步骤一多，模型就很容易忘掉最开始是要去哪。

一个非常实在的例子是 Claude Code 里的 todo write 工具，本质上就是让 Agent 把自己规划好的任务列表重新写出来再读一遍。听着简单，但这种“回声式自我强化”，往往就足够支撑 Agent 持续往正确方向推进。

第二种，失败引导。

当工具调用翻车的时候，系统不只是甩给模型一句冷冰冰的 error 日志，而是顺带给点“人味儿”的提示，比如：

可以试试参数 A 替代 B；

或者你可能得先调用 Z 工具才能拿到依赖。

这种提示，其实极大提升了 Agent 的自我修正能力。相比让模型自己在错误里盲撞，有方向的引导往往效果要好得多。

第三种，环境变化通知。

当 Agent 并行处理多个任务时，一个节点完成，往往会改变整体共享状态。系统就需要在其他循环中插一条消息告诉它：

文件 X 已经生成了，可以用了；

或者上游任务结束了，下游可以继续推进。

这其实是在用最土的方式，解决并行协作里最现实的信息同步问题。

第四种，行为纠正。

有时候 Agent 会做出明显偏离预期的操作，比如该输出结果却迟迟不调最终的输出工具。这时系统可以注入一条偏强制的指令，直接把它往正确行为上“推一把”。

OpenAI 报告里提到的评估循环，本质上也是同一套思路的延伸。模型的输出会被自动拿去跟单元测试、延迟目标或者风格规范做对比，让改进建立在可量化的质量基准上。

说人话就是：

像我们做产品，每次上线之后要看数据、看反馈、看留存、看转化，只有基于这些东西，我们才知道哪些功能真在变好，哪些不过是自嗨。Agent 的反馈强化，本质上干的也是同样的事

1.4 失败隔离与上下文管理

越复杂的任务，失败就越多，这几乎是必然的。

最头疼的一点在于：

如果把所有失败尝试、完整报错日志、每一次无效探索，全部原封不动塞进上下文，不光 Token 消耗飞快，还很容易把模型带偏。

于是，失败隔离就变成整个系统设计里一个绕不开的关键点。

实践下来，一个非常高性价比的方式就是：用子智能体去承担试错。

也就是让子 Agent 在自己的小循环内部反复跑、反复撞，直到找到可行方案，再把 最终成功路径 + 哪些路走不通的简要总结 反馈给主循环。 主 Agent 不需要知道全部废稿，只要掌握结果和教训就够了。

这套模式特别像真实团队分工：

一个小组成员埋头死磕技术难题，自己消化所有弯路和踩坑；最后只把最终方案和几条明确的“避坑经验”同步给项目负责人。

没人会把所有中间报废方案一股脑丢到老板桌上——那只会制造噪音。

另一种更激进的做法是上下文编辑（Context Editing），比如 Anthropic 就支持直接从上下文里把失败尝试人为删除，用来节省后续推理的 Token 开销。

听上去挺诱人，但在实际使用中，我们发现这条路并不那么好走——一方面成功经验很少，另一方面一旦动了上下文，缓存机制立刻失效，调用成本也会随之暴涨。

到底什么时候该删，删多少才合适，目前几乎没有一个通用标准。

这事儿给我的感觉，特别像整理会议纪要：

记得太详细，大家根本懒得看；

删得太狠，又怕把关键信息顺手抹掉。

这个度，很难拿捏，到现在也还是个持续摸索的事情。

2. 优势与局限：强大的系统与”外挂”的智能

客观说，系统协作这个范式，确实把 Agent 的能力硬生生拔高了一个台阶。真正做过的人心里都很清楚，如果没有前面那些主子 Agent、共享状态、反馈循环这一整套工程体系，现在很多复杂任务，基本是想都不敢想的。

像 OpenAI 在编码场景下的实践里，就已经能看到一个比较成熟的形态：一个编码 Agent 可以一次性把从数据模型到 API，再到 UI 组件、测试用例、文档，全流程串起来，端到端跑完一整次开发协作。

以前这是几个人、甚至一个小团队才做得下来的事，现在交给系统化 Agent 跑一轮，虽然还谈不上完美，但“能落地”已经不再是幻想。

这种范式，是能让Agent的能力跨越了一个大台阶，使得它能够：

• 处理复杂、多步骤的任务 ：通过任务分解和协作，将”不可能完成”的任务变为”可以完成”。
• 保持长期记忆和一致性 ：通过持久化的项目记忆和共享状态 ，Agent可以在长时间内保持对全局目标的认识。
• 从错误中恢复和学习 ：通过失败隔离和反馈循环，Agent可以更快地发现问题并改正。

但慢慢做下来，也越来越绕不开它最根本的那个问题——

这些所谓的“智能”，其实都是被外挂在系统架构之上的，而不是模型自己真正内生出来的。

系统极其复杂 ：

多模块、多循环、多状态层叠在一起，系统本身就像一台精密机器，构建和维护成本极高。很多时候，一个很小的业务需求调整，都可能牵一发动全身：改一次主循环，补一个反馈规则，调一层状态管理，就很容易意外引出新的副作用。Agent 系统的工程复杂度，说实话，到今天依然极其混乱。

成本高昂 ：

多次模型调用叠加复杂流程，再加上上下文注入、缓存失效、动态状态更新，Token 消耗和计算成本快速堆叠。

有人会说：那是不是换一个调用更“省 Token”的模型就好了？

但实际跑下来发现并不是这么简单——模型单次便宜，不代表整个 Agent 运行便宜。真正的成本计算，一定是放到整条链路里综合去看的，而不是只盯着某一次推理。

可解释性和调试困难 ：

系统一旦出问题，定位几乎像是在做“刑侦”工作：

• 是模型幻觉？
• 是工具接口出 bug？
• 是状态同步出了偏差？
• 还是哪一次反馈消息误导了决策？

很多时候要在日志里层层倒推，比调一个普通分布式系统还要费劲。

测试和评估，也因此成了整个 Agent 体系里最难啃的一块骨头。黑盒程度太高了，系统的行为不够透明，理性上可以信它，感性上却总是不太敢彻底放心。

归根结底，我现在对范式二的理解是：它本质上是在用“工程的确定性”，去对冲“模型智能本身的不确定性”。

这条路，非常成功，也确实让 Agent 的能力上了一个大台阶。但同时，它也慢慢顶到了自己的天花板。复杂度越来越高，成本越来越重，系统却依然脆弱。

也正因为这些矛盾越积越明显，行业才开始往更远的地方去想——

能不能不再靠外挂堆出来的系统，而是让模型自己长出这些能力？

于是，第三个范式登场：原生智能。

范式三：原生智能

如果说前两个范式还多少带着点工程味，那走到这一阶段，很多事情的重心就完全变了。

一路做下来我越来越清晰地感受到：行业现在追求的，不再是给模型外面套一层又一层复杂的结构让它听话，而是希望它能靠自己长出那些本来需要我们补丁、规则、循环去维持的能力。

可以把前两个阶段想象成，我们一直在耐心教一个孩子怎么用剪刀、怎么用锤子、怎么跟别人配合做一件事。

但到了原生智能这个阶段，我们的目标突然变成了另外一件事：

让这个孩子不靠指示也能判断、能规划、能反思，真正变成一个会自己做决定的人。

这个变化的意义，其实很难用一句话说清，但做了足够多 Agent 项目之后，会直觉地被震住——

原来智能真的可以“长”出来，而不是靠外部流程硬凹出来

1. 技术本质：端到端训练与能力的内化

范式三的关键点在于： 能力不是靠推理时的提示工程、控制器、循环结构拼出来的，而是在 训练阶段 就直接塞进模型里。

你可以把它理解成：以前我们在推理时不断往模型耳朵里碎碎念，而现在我们是把这些东西刻进它的大脑。

真正的原生智能，是靠大规模端到端训练出来的，特别是强化学习那种和环境不停互动的训练方式。它不是告诉模型“步骤 1 做什么、步骤 2 做什么”，而是让它在数以百万计的例子里自己悟出：

任务到底是怎么被完成的。

在这种范式下，一个理想的原生智能Agent，它会怎么工作？

举个非常具体的例子。

假设我们给它一个高层任务：

“给电商网站加一个用户评论区。”

按前两个范式的做法，我们要：

• 拆任务
• 注入提示
• 控制流程
• 注入反馈
• 看失败
• 回放日志
• 重新提示
• 再修……

流程复杂得像流水线。

但在范式三里，一个成熟的原生智能 Agent，做的事情可能完全不一样：

自主规划 ：

它会先在内部生成一份自己的“大纲式计划”，比如：

• 设计数据库表
• 写后端接口
• 做前端 UI
• 跑集成测试
• 更新文档

这不是我们告诉它的步骤，而是它自己理解任务后自然得出的规划。

动态工具调用 ：

它会自己想明白：

1. “现在要写代码，我应该用 ExecuteCode；
2. 要看文件，就调 ReadFile；
3. 要修改代码，就用 WriteFile；
4. 跑一下测试，调用 RunTests。”

重要的是，它能理解失败的原因，而不是只看到一个 error 字符串。

自我反思与修正 ：

如果它写的代码让测试挂了，它会自己判断：

• 是测试写错了？
• 是逻辑漏了？
• 还是数据结构不对？
• 需要回退吗？
• 要不要重写方案？

这一步在前两个范式里需要我们疯狂塞提示，而在这里，反思是它内建的能力。

长期记忆管理 ：

它不会因为中间处理了十几条工具调用就忘了最初的任务目标，也不会忘记哪些步骤已经完成、哪些依赖还没处理。

记忆不靠外部状态管理系统，而是长在模型里。

虽然 o1、R1 的内部机制都没公开，但从行业的各种迹象来看，方向很明确：

我们不再写代码教模型“怎样规划、怎样纠错、怎样分解任务”。 我们让它从 海量的模拟体验 里自己学会。

也就是说：

• 不再告诉它“如何规划”， 而是让它看无数个规划的例子，自己悟出规划是什么。
• 不再告诉它“失败后怎么处理”， 而是让它在数以亿计的失败里自然形成反思能力。
• 不再告诉它“什么时候用工具”， 而是让工具调用成为它内部世界的一部分。

这一切加起来，最终指向的是一个很简单、但非常激动人心的目标：

智能体不再是我们组装出来的，而是真正“长”出来的。

以前那些外部工程体系负责的工作——规划、拆解、反思、错误处理、工具调用策略——未来都可能成为模型的底层能力，就像语言理解一样天然存在。

这就是为什么我说，从范式二迈向范式三，是一次决定性的飞跃。

它不是更强的流水线，而是全新的生命力。

2. 范式对比：从”教它工作”到”学会工作”的转变

如果说前两个范式更像是在“带着模型做事”，那走到原生智能这里，感觉完全变了味道。

这不再是我们一条条告诉它“现在你应该做 A，做完以后去做 B”，而更像是——模型自己开始琢磨、自己规划、自己动手。

以前我们教它一步步来；现在它是自己长出了一套做事的方法。

我个人觉得，这才是真正意义上的范式变化：

从指令式，到涌现式。

从“我教你怎么工作”，到“你自己会工作”。

这个图其实特别直观。 随着模型能力不断提升，它能在 没有外部频繁干预 的情况下，把一件事坚持做几十分钟、甚至两小时以上，并且还能维持大概 50% 的成功率。 别小看这个数字。对人类任务来说，这已经意味着：模型开始具备靠自己完成复杂事情的潜力了。

以前，我们每隔几分钟、几秒钟都要去提醒它：“这里错了、下一步做这个”

但当一个模型可以连续跑两小时还不迷路，它就有点像一个能独立看家办事的实习生了，甚至能把任务拆开、重组、兜底、反思，全靠它自己。

2.1 与范式一的对比

范式一的时候，模型更像一个“工具使用者”。

每一步都要你说得清清楚楚：“现在你去调这个接口”“接下来处理这个文件”“注意要用 A 而不是 B”。

它只是按指令行动，缺乏真正的目标感，也理解不了任务为什么要这么做。

到了范式三，感觉模式完全翻过去了。

模型不再是被推动的，而是自己在“拥有任务”。工具在它这里变成可选项——它知道什么时候需要工具、为什么需要，以及该用哪一个。

这些判断不是外部写死的逻辑，而是它在训练过程中自己学出来的一部分

2.2 与范式二的对比

维度范式二范式三智能来源外部工程架构模型内生参数行为控制被遥控的木偶 拥有心智的生物决策方式规则驱动、确定性学习驱动、涌现式成本结构多次API调用单次或少量调用复杂性系统架构复杂 使用简洁

范式二靠的是工程。

严格意义上，它是我们工程师用各种结构（状态机、主循环、反馈注入器）把系统撑起来，让多个小智能体像团队一样协作。模型能做复杂事没错，但本质上是一个被遥控的木偶

很多时候，它的表现好坏，更依赖我们代码写得怎么样，而不是它自己有多聪明

范式三完全不同。

这时候的智能体感觉更像一个有自己想法的生物。

它的行为逻辑不是我们外部定义的流程，而是烙在它参数里的经验

就像一个成熟的专家一样，你不用告诉他每一步怎么做，他会根据情况自己决定。

这种内化带来了三个变化：

效率和成本 ：

单次或少量调用就能解决复杂任务，因为内部已经跑了很多轮“思考 → 规划 → 修正”的循环。

范式二可能要 10 次调用（每次 5000 Token），范式三只需要一次（比如 40000 Token）。

不光便宜，还快。

鲁棒性和适应性 ：

强化学习出来的模型，对意外情况的适应能力往往强得惊人。

它不是靠一堆规则避免坑，而是“理解了坑的本质”，知道怎么探索、怎么调整。

简洁性 ：

之前那些复杂得离谱的 Agent 架构、状态机、嵌套循环，全都能大幅缩小。开发者不用再当“系统工程师”，而是回到更自然的位置： 定义目标，设计环境，让模型自己去学。

我越来越觉得，这不是在做技术路线优化，而是在改写我们对AI 智能到底是什么的认知。

从步骤执行机器，变成会自己判断、自己规划的系统。

从我们拼出来的智能，变成它自己生长出来的智能

这是为什么，我觉得范式三像一次真正的革命

3. 迈向原生智能的基石与挑战

要真把原生智能做出来，绝不是一句规模化训练能解决的事。

它更像是一条需要多项底层技术一起突破的长坡。现在我们确实看到了希望，但我总觉得，这更像是产品原型终于跑通了第一个 happy path，离真正上线还差好几层地狱级的坑要填。

3.1 模型选择依然是基础

即便我们憧憬的是原生智能那种“大一统能力”，现实里底层模型的差异依然大得惊人。

比如Anthropic的 Haiku 和 Sonnet 模型被认为是目前最好的工具调用者，具有更高的准确性和更好的工具调用效率；但Gemini模型则在处理大型文档和图像方面表现出色，其多模态能力更强；GPT系列在主循环中的表现则不尽如人意，在复杂的多步规划上相对较弱。

这件事本身就提醒我们：

即使是走向范式三，每类模型自己的“天赋”不会因为训练方式更先进就被抹平，相反很可能会被放大。工具调用精度、多模态能力、长上下文处理……这些还是构建强 Agent 的底座。

换句话说，底层模型仍然决定你能走多远。

3.2 训练数据的构建是不可避的瓶颈

如果说模型是骨架，那轨迹数据就是血肉。

为了让模型真的学会规划、反思、纠错、工具使用，你需要的不是 QA 对，而是一整条从“我接到任务”到“我把任务跑完”的完整行为轨迹：

• 它想了什么
• 它怎么判断
• 它为什么选这个工具
• 工具怎么回报结果
• 它如何修正
• 它哪一步犯了错
• 怎么把错修回来
• 最终怎么收尾

这种数据贵得离谱，而且还不容易搞到。

大概就三类来源：

1. 人类专家的完整示范记录 ：最靠谱，但成本爆表；
2. 真实项目的历史日志 ：便宜，但噪音巨大，质量参差不齐；
3. 模拟环境里的 RL 生成 ：规模大，但设计环境本身就很难，而且生成完还得筛、得修、得标注。

更麻烦的是，即使你成功把数据全收集到了，它们也不是“现成能用的”。

清洗、重构、检验……每一步都费时费力。

这是整个行业现在都在头疼的事。

3.3 评估和测试变得更加困难

范式二已经很难评估了，因为它是一个 agentic 系统，你没办法像测试 API 一样去跑固定输入输出，必须在真实运行里观察它怎么想、怎么动。

可范式三更夸张：

模型不仅行为路径不固定，它还具备了涌现式能力。

它的每一次规划和行动都可能跟上一次完全不一样。

那问题来了：

• 我们怎么知道它这次的判断是对的？
• 它的行为是不是安全的？
• 同样的任务，它是不是会突然走岔路？
• 如果跑 2 小时，它会不会越跑越偏？

没有答案。

行业的共识大概就是： 范式三的评估难度，是指数级上升的

我们需要新的评估框架，可能包括：

• 多维度的性能指标（不仅是正确性，还有效率、成本、安全性）
• 对抗性测试，以发现模型在边界情况下的失败
• 人类偏好反馈，评估输出的质量和可用性
• 长期的真实环境测试，以发现在实际应用中的问题

听起来很麻烦，但也没别的路能走了，说到底，从系统协作迈向原生智能，就是在追求一件事：

让模型自己成为一个能独立思考、独立执行的智能体。

它很难，但它值得。

就像人类从会用工具，到会协作，再到真正拥有独立思考，这条路 AI 也正在一步步往前走。

而我们这些在一线构建 Agent 的人，本质上就在参与、推动、甚至亲手塑造这一切。

有点辛苦，但也真的挺浪漫的。

为什么我们会走到这一步？

AI Agent范式的演进，从最初的简单工具调用，到后面复杂的系统协作，再到我们现在憧憬的原生智能，这绝对不是什么偶然的技术漂移。

它背后有一系列非常深刻的底层逻辑在驱动着，反映了我们整个行业对更强大、更实用、更普惠的人工智能的不懈追求。但话说回来，这条通往终极自主智能的道路上，也真的布满了各种严峻的技术挑战。所以到底是什么原因推动着范式不断演进，以及未来我们还要面对哪些问题？

1. 驱动范式演进的底层逻辑

AI Agent 的范式为什么会一路从工具调用走到系统协作，再到现在大家都在盯着的原生智能？

并不是哪家厂心血来潮发明了一个新概念，而是整个行业在被同一股力量推着往前走。

如果把时间线拉长一点看，你会发现这三次范式升级，背后的动机其实都很朴素——我们想让 Agent 更像一个能真正替我们干活的人，而不是一个按步骤跑脚本的程序。

归根结底，就是三个追求：

1. 更高的自主性
2. 更低的成本与更高的效率
3. 更强的可靠性与更好的用户体验

这三点加在一起，就形成了整个行业持续变化的底层推动力。

1.1 对更高自主性的追求：从被动响应到主动规划

这一点基本是所有范式演进的源头。

范式一的 Agent，说好听点是“听话”，说直白点就是完全被动——你告诉它干什么，它就照着做。

没有全局目标意识，也没有真正的理解。

就像一个刚入职的实习生，你不把步骤写到备忘录里，他根本不知道下一步要干嘛。

范式二靠工程手段把 Agent 包装成一个“项目经理”。

它能分任务、能拆步骤、能协调流程，看上去已经很聪明了。

但你心里知道，它的“聪明”其实是工程师写在代码里的，它只是照着跑，称不上真正的主动。

而范式三的目标，就不是工具人、也不是项目经理了。

我们想做的是一个带主人翁意识、能自己理解任务并自主推进的智能体：

• 懂意图
• 会自己规划
• 会试错
• 会反思
• 能闭环完成整件事

OpenAI 在报告里说的那种“从规划、设计、开发、测试到部署全流程接管”的能力，就是非常典型的范式三特征。

你不再需要告诉它每一步该怎么做，而是告诉它想要什么，它自己会铺路。

这才是真正的智能。

1.2 对更低成本、更高效率的追求：减少工程与调用开销

范式二强是强，但代价也跟着一起炸了。

复杂的循环、状态管理、强化注入，让我们开发者要维护一整套“小型操作系统”。

开发成本、人力成本都高得吓人，我自己做过几次复杂链路的 Agent，调一条反馈循环调到怀疑人生。

更夸张的是运行成本。

频繁调用模型、冗长的上下文、缓存随时失效……

Token 消耗直接飞天。

我之前跑一个多 Agent 的长视频任务，光因为多个节点疯狂调 veo 3，那天晚上老板先是被输出质量震得有点兴奋，下一秒看到后台的调用花费就彻底懵了……

这时候你才真正意识到：

原来 Agent 跑通一个任务的成本，可以贵成这样。

进入范式三后，这类开销有机会被彻底压下去。

不是因为我们工程更复杂，而是因为模型本身就变得足够强，不需要我们再塞那么多提示、外部循环、状态干预。

该模型自己能完成的，就不需要我们替它完成。

这是降本增效的根本路径。

1.3 对更强可靠性、更好用户体验的追求

最后这一点，往往是最容易被忽略但最关键的。

用户其实不关心你用了多少循环、多少工具，也不关心你在背后跑了多少次失败尝试。他们只关心： 结果能不能一次成功，能不能稳定，输出是不是靠谱。

但范式二有个天然的问题：

它内部太复杂了，模型可能在某个循环里莫名卡住，或者状态错位导致行为突然走偏，甚至输出的语气风格都可能完全不可控。

我以前给 Agent 写过一个专门的输出工具，本来以为能强制它稳定输出格式，结果发现它还是会时不时“跑偏”。

这就直接影响用户体验了。

而原生智能的方向（范式三），真正的价值就在这里。

如果规划能力、反思能力、修正能力都能内化到模型本身，那么那些中间的反复试错、纠结、补救，都可以在模型内部悄悄处理掉。

用户看到的，只是一个自然、流畅、靠谱的最终结果。

这，就是为什么整个行业最终一定会往范式三走。

一句话总结： 我们之所以走向原生智能，是因为这是唯一一条能同时提升自主性、效率和可靠性的路。

它很难，但方向已经越来越明确了。

2. 未来Agent发展的核心挑战

2.1 记忆与上下文管理

无论是哪个范式，Agent的智能都严重依赖于其对上下文的理解和记忆。

但是当前所有主流模型都受限于有限的上下文窗口。随着任务复杂度的增加，Agent的”记忆”会迅速被填满。

当处理一个长期项目时，早期的指令、关键信息或任务的总体目标可能会被挤出上下文窗口。

这会导致Agent遗忘重要信息，做出与早期决策不一致的选择，或偏离原定目标。

OpenAI 虽然提过长上下文、压缩技术是解决持久记忆的关键。但老实说，哪怕看了那么多论文，把它们真正放到生产环境里跑一跑，你还是会发现： 这依然是个大坑。

现在行业里常用的一些做法，比如：

• 在主循环里不断给模型注入“提醒消息”；
• 用子 Agent 隔离上下文，减少主上下文的负担；

这些多少都有点不得已而为之的味道，本质上就是打补丁。

说它们优雅，那真不敢；

但不用又不行。

更麻烦的是缓存管理。

显式缓存确实可以节省一点成本，可一旦你要对上下文做编辑、重写、删改……

缓存直接失效，调用成本立刻上去。

就像你脑子里硬盘不够用了，每次删一点、挪一点，最后甚至忘了自己删过什么。

这让我总想到一个很现实的对比：

人类记忆也不是无限的，但我们至少知道怎么“忘对东西”。

不重要的会自动淡掉，重要的会反复被提起，甚至分层管理：

短期记忆、长期记忆、工作记忆，各司其职。

AI 现在还完全做不到这一点。

不但不会分层记忆，还经常把无关信息记得死死的，把关键目标反而挤掉。

所以我一直觉得， 怎么在有限窗口里建立真正可持续的长期记忆结构，甚至做出类似人类“工作记忆 + 长期记忆”这种分层，是未来 Agent 能不能迈进下一个时代的核心门槛之一。

这个问题解决不了，Agent 智能再强，也只能算是短跑选手

但如果能解决——才有可能跑成真正的长期项目执行者

2.2 自我评估与反思能力

我总觉得，一个 Agent 的“聪明”，不只体现在它能不能把活干完，还要看它有没有能力“照镜子”——能不能判断自己刚刚做的东西是不是靠谱，哪里可能有漏洞，要不要回头修一修。

在范式二时代，这种反思其实大多不是模型自己的能力，而是我们工程层帮它搭的支架。

比如跑一套测试告诉它这里错了，或者主循环突然注入一句：你可能得退回几步。

说白了，就是老师站在旁边帮它批改作业。

但要迈向范式三，这点就完全不够用了。

真正的原生智能，必须让模型把 自我怀疑 这件事内化进去

不是外部告诉它哪里错、哪里怪怪的，而是它自己能察觉：

• 这个函数是不是写得太绕？
• 这里是不是会有性能坑？
• 这个方案是不是只是“能跑”，但不是“最优”？

它要能在多个解决路径中做权衡，而不是抓住一个能跑通的就不放手。

像极了一个成熟一点的工程师：

做题不是目的，能检查、能反思、能重新判断才是关键。

2.3 跨环境操作能力

现在大多数 Agent 还生活在一个“过于安全”的世界里——

代码库是干净的、API 是有文档的、网页结构是稳定的。

无论你让它查资料、调接口、跑脚本，一切都是可预测、可控的。

在这么规整的数字环境里，想跑顺当然不难。

我们给它构建虚拟文件系统、共享空间、统一接口，让它们彼此协作，其实都是在给它准备一个规则明确的边界。在这个边界里，Agent 的成功是有保证的。

可如果我们要让 Agent 走向更大的世界，那完全是另一套难度。

比如：

• 操作复杂 GUI
• 读取真实屏幕信息
• 控制机器人
• 与物理世界互动

这些都不是靠接口调用能解决的。

现实世界是噪声巨大的、状态不连续的、反馈不确定的。

你甚至不知道下一帧屏幕上会突然弹出什么东西。

这时候，Agent 需要的能力至少包括：

• 更强的视觉理解能力 它要能读懂截图里的层级、按钮、状态、材质、位置关系，而不是只靠 HTML 标签。
• 更灵活的操作手段 不只会调 API，还得会点 GUI、点窗口、拖动、滚动、缩放，甚至理解“手指触摸”这种隐性交互。
• 对物理世界的直觉 知道物体为什么会掉下来、机械臂为什么会卡住、机器人转弯为什么会抖，这是模型现在完全欠缺的。

现在那些让 Agent 通过 CLI 工具操作交互式系统的尝试，说实话，还只是迈出去的一小步。

它们证明了一点：

• Agent 未来一定会进入更复杂、更真实的环境。
• 只是现在这条路才刚刚开始，前面还有无数坑等着踩。
• 但这恰恰是未来最值得期待的地方。

2.4 训练数据与成本

说到底，原生智能能不能做起来，数据是最硬的那块地基。

尤其是那种记录了“从接任务 → 思考 → 调工具 → 试错 → 反思 → 完成任务”全流程的轨迹数据——这个东西贵得离谱，而且还没法量产。

为什么？因为这些数据不是抓几段对话、写几个 prompt 就能有的。

你需要的是：

• 一个会做事的专家，把他真实解决问题的过程完整录下来；
• 或者搞一个超大模拟环境，让模型能在里面无限试错、无限踩坑，最后从海量的失败里自己悟出规律。

听上去很酷，但成本真的不友好。

数据团队要哭，训练团队也要哭。

前段时间 KIMI 做那个砍价好感度活动，不知道你有没有薅羊毛，0.99 的会员，搞得跟谈恋爱一样，你说几句话它价格就给你往下掉。

很多人觉得 KIMI 是在亏钱做慈善，我倒觉得他们可能是在以最低成本收集最高价值数据。

这个活动本质上是什么？

就是让用户主动配合它跑一大堆真实的、多轮的、带情绪的、带策略的对话行为数据。这些数据对 KIMI 的强化学习简直是宝藏级的，又便宜又自然。毕竟 KIMI 的 K2 模型本身就是 RL 架构。所以别小看这种看似“便宜又好玩的活动”，背后可能是一个巨大且低成本的数据采集工程。

2.5 测试与评估的困境

如果说数据是最贵的，那么评估可能就是最让人头疼的。

我真没夸张，评估 agent 的难度简直像是把软件测试这门学科整个重写一遍。

传统测试为什么没用？

因为 Agent 是不确定的、不固定的、有涌现行为的。

• 你今天给它一个任务，它可能 A 路线走通；
• 明天同样的任务，它突然走 B 路线也能通；
• 有时候甚至绕一圈 CDE 乱飞一通，也莫名成功。

这不是 bug，而是“灵活性”。

但从测试角度看，这就是噩梦。

我现在觉得，之所以评估这么难，大致有几类原因：

输出非确定性 同样输入，结果可能完全不同。 它不是函数，是一个情绪化的工程师。

成功条件不是黑白题 有时候结果是对的，但过程一塌糊涂；有时候过程很优雅，但最终没做完；那到底算不算成功？ 根本没有统一标准，只能靠“理解”。

长尾问题吓人 平时表现完美，但只要遇到一个奇怪边缘 case，立马翻车。 而这些场景通常只有在线上、用户手里才暴露出来。

所以，评估一个 Agent，并不仅仅是在测结果对不对，更像是在审查一个人的工作方式：

• 他是不是靠谱？
• 有没有乱来？
• 有没有在关键时刻走偏？

未来的评测体系肯定要重新设计，大概率会包含下面这些：

1. 可观察性数据 把 Agent 的每一步决策、每次工具调用、每个结果全都记录下来，像审计一样回放。
2. 对抗测试 丢各种怪题和不合理输入，看它怎么应对。 就像给医生考实战题，而不是卷子。
3. 人类偏好反馈 不只是正确性，还有“好不好”、“自然不自然”、“像不像专业人士”，这些只能靠人评。
4. 长期真实环境测试 模型在真实用户场景里连续跑一周、一月，问题才会浮出水面。 你模拟一万次，可能都模拟不出来一次真实线上事故。

也正因为这样， 没人敢拍胸脯说自己的 Agent 100% 稳定。 只要底层是 LLM，就永远会有不可预期性。 能做的只是把系统做得越来越稳，把风险压得越来越小。

这就是为什么我说，评测是 AI 产品里最难啃的一块骨头，真的没有之一。

结论

Agent 这条路，本质上就是从 能帮我做点事 – 能替我做成一件事 走过去的。

工具调用、系统协作、原生智能，像三层台阶，越往上越接近真正的自主智能。

但我不觉得它们是你死我活的关系。

很多时候，它们反而会长期并存，甚至在同一个系统里各司其职。

比如：

• 结构化、流程稳定的任务 直接用范式一最省心。能用简单规则解决，就别折腾复杂模型。
• 跨多个角色、需要严格流程的企业级任务 范式二依旧会是主力，架构稳定、成功率高，对公司来说就是价值。
• 探索型、开放性的、没有标准答案的问题 范式三的原生智能会像是顶尖大脑，它的灵活性和创造性，是前两种做不到的。

写这些，并不是想把谁说服到某个观点上。

更多是我自己在做 Agent 这些年，慢慢积累出来的一点理解：

这个方向又有意思，又复杂，但其实没必要把自己逼得太紧。

我们真正需要做的，可能就三件事：

1. 持续学习 技术更新太快了，你今天看到的最佳实践，明天可能直接失效。 多读、多看、多和社区互动，让自己的理解一直保持活着的状态。
2. 不断尝试 动手做比看十篇论文更有用。不怕乱、不怕失败，反而越乱越能看到本质。 你亲手踩过的坑，最后都会变成你独有的判断力。
3. 搭建自己的认知框架 从“委托—审查—拥有”到强化循环，再到原生智能，这些不是孤立的技巧，而是同一条进化链上的节点。 理解它们之间的关系，未来再遇到变化时，你就不会慌。

剩下的，就是一点耐心，一点好奇心。

喜欢这个方向，就慢慢走。

路是长一点，但真的挺值得的