推荐AI Agent为什么这么难：它们根本还不属于同一类别

开篇

同一时刻，两个人向搜索框输入了不同的话。一个人搜“AI Agent推荐”，另一个人搜“AI Agent含义”。

人们很容易认为搜索“含义”的是入门新手。然而，在本次分析的搜索路径模型中，先确认含义、再去寻找推荐的连接反复出现。这并不是同一个个体按此顺序进行搜索的真实记录，而是推测多个搜索词之间关联度的结果。

这个顺序之所以重要，是有原因的。进入今年以来，Agent已跨过演示阶段，开始真正登上企业的引入审查报告。审查报告需要候选名单和对比表，而要制作对比表，首先必须确定把什么和什么放在同一维度进行横向对比。

读者，我认为这一顺序释放了一个信号：目前对比Agent产品的基准尚未明朗。因为在获得推荐之前，必须先确定应当把具备哪些功能和权限的工具放在一起比较。

搜索路径模型中，“含义”排在了“推荐”前面

我们先来看数据。

“AI Agent”近3个月的月均搜索量为29,416次。按12个月趋势通过回归分析推算，年化增幅达+107%（R² 0.515），关注度本身显然在不断升温。

耐人寻味的是后续的发现。在分析得出的前15条核心模型路径中，无一例外都包含了“AI Agent含义”。而在“含义”与“推荐”同时出现的13条路径中，无一例外都是“含义”排在前面。

在此有一点需要先讲清楚：这些数据并非个人的点击记录，而是综合推算搜索词之间如何关联的图谱模型。因此，若将其解读为“韩国人搜索含义的次数多于推荐”，那就错了。事实上，单纯从路径频次来看，“推荐”为367，略高于“含义”的347。我们能够读出的不是量级的大小，而是先后顺序。

在前15条路径中共同呈现的这一顺序，确实值得深入观察。不过，这并非大样本，也不是个人的真实行为记录。仅凭这一结果，并不能断定所有买家的行为或整个市场的属性。

在通常的产品品类中，这个顺序恰恰是相反的。购买无线耳机或笔记本电脑时，我们不会先去搜定义，而是直奔对比表。搜索定义排在前面，意味着该市场尚未真正步入采购决策阶段。

这里也存在一种反论：这可能是针对“含义”的大量入门级内容被生产出来后引发的供给效应。即便如此，疑问依然存在：为什么在这个市场中，定义类内容至今仍被持续消费？因为即便供给再多，如果没有需求，它也不会留在搜索路径之中。

要做推荐，首先得在功能和权限相同的工具之间进行比较

推荐笔记应用并不难，只要在笔记应用之间做比较就行。价格、同步、协作功能等比较维度早已有共识。

但智能体的情况大不相同。如今在这个标签之下，既有只会回答问题的聊天机器人、只按固定顺序运行的自动化程序，也有代人点击浏览器的工具，以及在多个系统间穿梭并自主决定下一步行动的循环系统。这些工具能够承担的任务以及自主行动的范围各不相同，很难用统一的标准排出高下。

Anthropic 对这一界限的划分相对清晰。他们的区分是：工作流¹是由 LLM 与工具在预设的代码路径中被调度的系统；而智能体则是 LLM 自主指挥执行过程与工具调用的系统。在同一篇文章中，他们也承认不同的客户对智能体的定义各有不同。这相当于服务商在给出定义的同时，也承认了业内尚未形成共识。

有一点需要说明。这种划分并非全行业在法律或学术层面达成的共识，而是一家头部服务商基于自身经验划定的实践界线。其他公司的分类方法并不相同。因此，如果合同里只写了“智能体”，这个词实际上什么都没有明确。一旦出现问题，判断的依据不是名称，而是其下附带的权限清单与审批流程。在定义尚未达成共识的市场中，起草文件的人必须写明具体动作，而非仅仅使用词汇。

范畴正在分化的证据，在技术标准层面同样看得到。在 Google 于 2026 年 3 月梳理的智能体协议全景中，MCP²、A2A、UCP、AP2³、A2UI 和 AG-UI 同时登场。

如果把这份清单从开发者视角转换为采购者视角，可以这样理解：

• MCP 决定了该工具能把手伸到我们数据的多深处。这是安全审查的对象。
• A2A 决定了我们的智能体是否与其他公司的智能体直接对话。这是合同与责任归属的问题。
• UCP 和 AP2 涉及下单与支付权限。这是财务与内部风控需要把关的项目。
• A2UI 和 AG-UI 决定了这一过程在人类眼中如何呈现。这是审计与用户体验的问题。

同样是“引入智能体”，审查部门却分流到了四个不同的地方。这意味着它不再是单一的产品品类，而是正在分化为多层架构的技术栈。在这种状态下，“五大智能体推荐”这类的清单很难提供实质信息。因为没有统一比较维度的清单算不上排名，充其量只是罗列。

即使使用相同的模型，也是不同的产品

还有一种情况更加棘手：名称相同，内部使用的模型也相同，但彼此却属于完全不同的产品。

在一种配置下，该工具仅仅是读取日历。它把日程整理出来展示给用户就结束了。而在另一种配置下，相同的工具却会发送邀请函。它会拟定参会人员名单、发送邮件、预订会议室。

在技术规格书上，这两者并没有区别。在功能清单里，它们都被同样写成“日历集成”这一行字。然而在组织内部，这两者是截然不同的东西。前者就算出错，用户只要关掉界面就结束了；但后者一旦出错，邮件就已经发送给 30 位外部接收人了。

是否具备可逆性，正是分水岭所在。在 Anthropic 的自身使用数据中，不可逆的操作在全部工具调用中占比也不足 1%。虽然占比很小，但由于一旦执行就难以挽回，因此需要单独的确认步骤。当然也需要明确区分的是，其他调用同样可能引发事故。

正因如此，如果将对比表的行标题设为产品名称，就注定会失败。因为常常会出现同一个产品必须归入两个不同行的情况。行标题所代表的应当不是产品，而是权限组合。

必须确认究竟能放权到什么程度

读者在核实定义时，真正想知道的并不是词语的词典释义，而是究竟能放权到什么程度。

Anthropic 在 2026 年 4 月提出的操作性定义也阐明了它能自主执行什么。智能体是一种为了实现目标而自主循环执行“规划、行动、观察结果并修正”的系统，直到任务完成或需要向人类请示为止。同一份文档还说明了如何针对不同工具分别配置“始终允许”、“需要审批”以及“阻止”。

由此显现出一个关键点：真正定义一款产品的，既不是模型名称，也不是营销话术，而是设置界面。因此，将定义转化为三个维度来考量才最具实用性。

维度	要问的问题	确认位置	危险信号
自主性	是自主选择方法，还是仅遵循既定流程？	架构文档、失败时的重试机制	只有“全自动处理”，没有任何路径说明
行动权	仅限于读取，还是涵盖发送、支付、删除？	权限范围、集成列表	将读取与写入权限捆绑索取
中断点	何时向人类请示，失败时如何回滚？	审批策略、审计日志4、回滚流程	审批环节为可选配置且默认全盘允许

带着这张表去参加供应商会议，提问的角度就会发生改变。你不再会问“这是智能体吗？”，而是会问“默认设置是什么？”。面对前一个问题，所有供应商都会给出肯定的回答；但面对后一个问题，答案就会立见分晓。

在上述三个维度中，答案分歧出现在哪里也是完全可以预见到的。询问自主性时，回答通常都很宽泛大方，因为显得越自主越具吸引力。询问行动权时，回答就会变短，相当多的人当场根本拿不出权限范围文档。而一旦问及中断点，往往就会扯到产品规划路线图上去。如果得到的回答是“我们计划在下个季度接入审计日志”，那么这款产品目前充其量只能作为试点对象，而非引入采纳的对象。

在三个维度上都能用文档给出明确答案的供应商，其实远比想象中要少。而这极少数才是真正有资格进入比选清单的候选对象。缩小推荐清单范围的并不是功能对比，而是这一步文档核实工作。

我想关注权限配置与合同条款是否正在具体化

在上一期中，我们讨论过：那些真正深入消费者的 AI，都是抹去了自身名字的 AI。这次的观察则比那更往前一步。在抹去名字之前，市场首先得对这个名字下面究竟要装入什么达成共识。

我认为，一个范畴走向成熟的时刻，并非定义它的语句变得精妙之时，而是权限配置界面与合同条款变得精细之时。

云计算正是如此。早期人们搜索的是“什么是云计算”，但如今几乎没有买家会问这个问题了。取而代之的是询问区域、权限策略、可用性保证条款。问题并没有消失，而是发生了转移。当抽象的范畴质问转向具体的合同条款质问时，那一刻便标志着该市场的成熟。

这一解释是可以转化为具体指标来验证的。如果我的判断正确，那么未来“Agent 含义”的搜索量不仅会减少，而且必须转移到其他搜索词上。“Agent 权限配置”、“审批工作流设计”、“Agent 审计日志”等运营层面的提问能否填补这一空白，就是关键指标。反之，如果仅仅是含义搜索悄然减少，而运营提问并未增加，那就不叫走向成熟，而是关注度冷却了。几个月后，我会用同样的数据再次进行验证。

对销售端而言，同样的道理依然适用。如果在产品页面上抹去“Agent”这个词，转而在那个位置明确写下它可以托付的任务以及停止介入的边界，买家去专门搜索其含义的理由就会减少。为了确认定义而跳转到其他页面的访客，很可能会因此中断对产品的考察。因为解释品类名称的内容，贡献的是整个品类，而不是你的具体产品。

结语

用三句话来做个总结：

• 在这次的模型中，“含义”排在“推荐”之前，我将其解读为希望先明确比较基准的信号。不过也请同时记住，就搜索频次本身而言，“推荐”确实要略高一些。
• 如今的“Agent”并非一个清晰的产品类别，而是一个混合了多重层次的标签。就连 Anthropic 在给出定义的同时，也明确写道业内尚无统一共识。
• 因此，我们需要调整判断的先后顺序。比起“该接受什么推荐”，更重要的首先是**“究竟能把什么托付给它”**。

下次当您拿到 Agent 引入评估材料时，不妨在产品名称一栏旁边多加三列：自主选择的范围、改变外部状态的行为，以及审批与回滚的位置。如果这三列还是空着的，那么该产品甚至还谈不上是比较对象，它充其量还停留在候选阶段之前。

此外，在评审会议上，请务必这样问一次：“当这个工具执行出错时，我们当中有谁能在几分钟内将其还原？”只有当这个问题能够同时给出具体的人名与时间，推荐清单才真正具备意义。

参考资料与延伸阅读

核心来源

• Anthropic, “Building effective agents”, 2024. 12. 19. 链接 ··· 划分工作流与 Agent 的基准线就在这里。相比具体的模式说明，建议先阅读前面的定义段落。
• Anthropic, “Trustworthy agents in practice”, 2026. 4. 9. 链接 ··· 文中给出了“规划·行动·观察·修正”闭环的操作性定义，并讨论了工具维度的允许·审批·拦截配置。今天这篇文章的三大支柱正来源于此。
• Google Developers Blog, “Developer’s Guide to AI Agent Protocols”, 2026. 3. 链接 ··· 梳理了 MCP、A2A、UCP、AP2、A2UI、AG-UI 各自负责哪一层。这是最快确认这些协议并非同一层级的参考资料。

往期相关内容

• 没进群聊的技术算不上产品 ··· 从验证负担的角度，探讨了 Agent 为何至今仍未真正普及。
• AI Agent 已经就绪，只是我们还不敢信任 ··· 借助实际使用数据，审视了自主性、审批比例以及不可逆操作比重的一期内容。

作者 安光涉（Oswarld） 现任世宗大学兼任教授，INLEVEL9 战略顾问。职业经历、研究、著作与近期活动会持续更新在作者简介。 最新动态 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

术语说明

注释

1. 工作流（Workflow）：按照人类预先设定的顺序依次调用工具和模型的自动化机制。由于执行前路径就已经确定，因此易于测试和预测。 ↩

2. MCP（Model Context Protocol）：将 AI 访问外部工具或数据的方式进行标准化的开放规格。让开发者无需为每个工具单独编写接入代码。 ↩

3. AP2（Agent Payments Protocol）：在 Agent 发起支付时，以可核验的形式记录由谁、在何种限额下批准了该操作的协议。它关注的核心不是买了什么，而是谁给出了许可。 ↩

4. 审计日志（Audit log）：记录系统在何时、以谁的权限执行了何种操作的凭据。在发生故障或事故时，它是寻找回滚节点的关键依据。 ↩