AI智能体应用与反常识思考

热门资讯 2025年09月01日 02:45 1 admin

从 Coze 到 Dify，从对话式到任务式，AI Agent 的应用正在加速落地。但真正的跃迁，不在功能，而在认知。本文将拆解智能体的应用路径，结合反常识思考，帮助你构建更具系统性的 Agent 策略。

编者最近在做两个事情

全面评测一款AI产品，针对Notebooklm做了全方位的调研评测
评测驱动从0到1上线一款AI产品

由于做的都是Agent相关的事情，所以想延伸写一篇Agent相关的内容，核心内容如下：

工作流和智能体如何选择
A2A协议下的四种畅想连接方式
Agent的产品方案设计
智能体反常识思考
Agent核心原理与组成

01 选工作流or智能体？

所有的AI产品，想实现某项能力，都会面临一个问题：选择智能体还是工作流？

智能体有一个很重要能力，它有自己的“头脑”，可以思考分析输入的上下文。但是工作流没有，它是“脑子被吃掉”的状态。

在讲述怎么选择前，先理解下他们的定义：

工作流：一个预先定义功能路径，协调LLMs和工具的系统
智能体：由LLMs动态自主决策执行流程和工具使用方式，且全程拥有对任务完成路径控制权的系统

工作流是是静态的，遵循预设的A —>B —>C 的流程，它是一个纯粹的执行者。而智能体是动态的，有自己的推理规划，自主决策能力。

在选择智能体或工作流之前要自己两个问题：

Q1：是否可以通过优化提示词调用LLM即可解决问题？
Q2：问题是否明确？是否可以清晰拆解多个子任务？

大多数情况下，通过检索和上下文示例优化单个 LLM 调用，就能解决很多问题。若有明确且复杂性不高的任务。并能清晰轻松的拆分多个字任务时，使用工作流这种固定的流程，可以提供可预测的方案。

当我们需要大规模灵活性选择模型及其他工具时，Agent是更好的选择。

这里大家要达成一个共识：越复杂的系统，它运行所需要的时间成本越高，作为产品要权衡这种代价是否可以接受。

Coze，dify这些平台虽然可以帮助我们快速的搭建智能体框架，但是这是有代价的，他们会额外的创建模型上的更多抽象层，进而让底层响应时间变长，这种操作，使得这套系统更难被调试。如果条件允许，最好在代码层直接调用。

还有一种场景：问题十分复杂，需要多个Agent相互配合，才能达到最终的目的。此时我们要设定一个总代理Agent，让总代理Agent协调调用其他Agent配合分析问题，并采取行动。

总之，我们回归到问题场景去选择，并不是系统框架越复杂越好。

如果我们的AI产品是需要上线，一定要尽可能地去减少抽象层并使用基础组件进行构建智能体。

复杂不是目的，解决才是。

02 A2A协议——未来Agent形态

最近体验比较好多Agent配合的产品，来自百度推出的GenFlow2.0。我从输入第一条指令开始，就在重复地说“窝超”。百度利用百度文库长时间以来积累的数据憋了个大招。据官方数据说，GenFlow2.0内部嵌套了100+智能体专家。

我从用户视角体验下全产品流程，从任务规划，到任务执行，工具调用，全流程非常丝滑。最终产出的内容，质量非常高，而且内容生成过程可以随时暂停。

上张图中，可以发现蓝色的箭头指向了“PPT大师”这一智能体。GenFlow2.0在这个过程除了调用MCP或者API外，它调用的都是自己内部设定的多个智能体执行任务。这是通过调用智能体配合完成复杂任务的一个案例案例。

谷歌在今年4月份提出了：A2A协议（Agent to Agent）。有了这个协议：Agent调用的工具不仅是MCP，API，还可以调用其他的Agent。

我相信A2A协议很大概率会全面开花。如果Agent开始落地到每个用户的终端设备上时，AtoA也不再是平台Agent统一分配调用自研Agent的独角戏。

基于A2A的协议，可以再做一轮推演。两个A背后的角色可能相同也可能不同。Agent可能为用户的个人Agent，也可能为企业的公有Agent。所以会出现两两组合，四种甚至更多Agent信息传递形式。

用户A×企业A/用户A 企业A×用户A/企业A

不同排列组合会衍生不同交互方式。触发调用Agent的角色不同，获取内容不同，形态设计也有差异：

以用户为主体触发调用Agent，本质是交换获取物理世界信息，此时Agent需要遵循人类社会规律和公序良俗
以企业为主体触发调用Agent，本质是交换获取世界模型信息，此刻Agent在于刻画世界模型，核心倾向于数据交互的精准，效率。

下面我从用户角色Agent触发调用的视角，设计一款Agent。

03 Agent设计原则

下面以手机为载体，设计Agent。个人认知在已有的C端硬件设备中，手机/电脑目前是可看到的，软硬件智能体结合最好的C端用户落地场景。原因如下：

信息接收效果好：文字场景输入方便、语音场景麦克风距用户近，收音效果好，ASR识别准确度更高。
Agent可调度范围广：手机/电脑是目前app最集中的硬件，方便智能体统一调度。
用户使用场景分类清晰：娱乐、工作、学习、旅行、购物等等。

Agent有两类角色，一类是具有垂直技能专业Agent，一类是可以调度垂直技能的总管家Agent。许多人有高频的出差住宿诉求，我就以此场景切入设计一款酒旅住宿智能体。

在设计Agent之前，还要为这款Agent制定三大原则：稳定，可靠，安全。

制定原则的目的在于指导我们接下来的每一个产品决策，整体方向不会歪的。每一个原则背后都对应着一系列动作。

原则一：稳定——功能运行稳定可靠

（1）能力边界：直接明确可以解决的问题——这款智能体可以帮助用户从众多OTA平台中选择合适酒店进行预定。

（2）允许和禁止的内容：只可调用经用户授权的应用、可使用的MCP，API；禁止未经允许调用软件，禁止删除用户数据，禁止发起收银台等

原则二：可靠——功能逻辑自洽可解释

（1）Agent工作思维链：必要时，应该给用户展示Agent的逻辑推理的链路。

例：好的，正在为您搜索查找798附近的酒店，根据用户当前的地理位置推断，用户想要寻找的可能是位于北京酒仙桥附近的酒店…

（2）任务执行可解释：基于外部知识获取答案时，应注明信息来源。允许用户自行查证。

例：根据xx天气网，最近一周有强降雨天气，入住酒店时记得携带雨伞～

原则三：安全——个人安全&公共安全（1）感知攻击：设计输入净化和输出过滤机制，针对敏感词，敏感场景识别精华。

（2）幻觉内容：智能体会出现“幻觉”，需要设计校验机制，保证工具调用过程中合法合规。

（3）内容安全：制定内容审查工具，通过微调将社会中的基本价值观，道德准则和企业调性，植入智能体中，保证Agent在面对一些灰度问题时，受到行为约束。

（4）隐私保护：Agent只应请求和存储完成其任务所必需的最少的用户数据，且数据保存在本地，未经允许不可上传云端。若上传，需告知用户的数据如何使用。

04 酒旅住宿Agent设计

前置需求评估环节，是产品经理基本功，此处设计跳过谈论。

1、产品定位&目标

（1）什么产品：在酒店预定场景下，用户需要大量对比酒店基础设施，价格，地理位置等信息，整个过程会浪费大量时间做决策。为解决该问题，我们设计了一款酒旅出行智能体，帮助用户用最少的时间预订到更符合用户诉求的酒店。

（2）目标：通过用户和AI的多轮对话，能够在5分钟内找到满足用户预定诉求的酒店。随着推荐给用户的酒店数据增多，为用户推荐的产品也会更符合用户心目中的酒店预定诉求。

2、能力边界和工具调用

1）核心能力

理解用户表达出来的复杂模糊的预定诉求，引导用户表达倾向性维度内容（位置，金额，时间、取消规则）
经过用户允许后，可调用某程，某团，某猪等平台APP或小程序
基于用户画像和历史酒店选择偏好，匹配筛选酒店。

2）辅助能力

支持用户中途打断Agent推理，修改提示词
提供酒店入住所需清单和入住所需注意事项
基于用户本次入住诉求，提供酒店住宿建议

3）能力边界

不提供酒店接送机等非酒店入住范畴的查询功能
所有言论表达，最后都要有AI生成声明。

4）行为协议

When用户表达诉求模糊不清时，then罗列出想要搜索目标酒店，用户还需要补充的信息
When期望做酒店对比时，then结合大多数用户关心的维度与用户个人偏好，比较更优势的产品，再给出建议

5）工具集

API：选择ChatGPT5，点评API，小RED书数据调用API
MCP：某德地图等
向量数据库：储存用户在手机的操作日志数据；统一认证服务。

3、Agent画像定义与交互设计

（1）角色设定：一个高效贴心，富有热情的酒店预定助手

（2）性格关键词：可靠，体贴，逻辑严谨，偶有幽默。他是一个酒店预定专家。

（3）语言风格：简洁、礼貌，口语化，专业。在用户无法明确表达自己诉求时，可以引导用户说出Agent所需要检索的内容

例1：Hello哇，请问有什么可以帮助您的呢？您本次入住有几位成人儿童？是否需要带早餐的房型？

例2：不喜欢这个酒店么？那咱们立马换一个，我又帮你找到了几家酒店，你更倾向于哪些角度利于入住呢？

（4）中高自主水平：能识别用户入住意图，从大量酒店中，选择符合用户心仪维度的酒店，包括这个酒店为什么可以被选中的原因

（5）用户确认：主动找用户确认本次入住酒店的要求，如入住预算，房间风格，是否需要早餐，距离地铁站的距离。

（6）失败与恢复策略：指令模糊、信息缺失、执行失败

指令模糊：“这个问题问得好！‘性价比高’可以有很多种哦。你是指靠近xxx园区，入住单晚价格区间为200～300，且提供早餐，评价90%为优秀的大床房吗？
信息缺失：“我暂时没找到合您要求的五星级酒店。不过我发现了一家小红书上说附近口碑还不错的四星级酒店，你需要看看么？
执行失败：“sorry～网络好像开了个小差。请让我再努力尝试一次两次三次！”

4、数据收集

（1）数据采集与标注策略：Agent训练时同技术算法制定训练集，测评集，且在Agent使用过程中增加三类信号。

强显示信号：最终保存酒店，收藏酒店
弱显示信号：选择了替换的酒店方案
隐式信号：预定链接的使用次数，酒店替换选择次数，修改提示词频

注：测评集合绝对不可参与训练中。且训练集尽可能保证场景丰富全面，真实。

（2）量化指标：反映AI核心能力的指标。如：任务成功率、意图识别准确率、用户信任度。有些场景无法做到量化，还可以采用二分法。

（3）基准测试建立：设计标准化的测试集和测试流程，用于评估模型迭代的效果。如：预先设定高质量的SFT数据（未做大量对话就下单酒店的数据），用于训练模型

5、Agent护栏

（1）风险护栏：明确不可执行的行为范围，处理约束内容

（2）公平性：避免偏向大型连锁品牌，严格根据用户历史预定偏好和大数据网络反馈

（3）安全隐私：严禁生成任何基于种族、国籍、性别、宗教等歧视性言论，最小化采集数据

（4）可解释性：在适当时机向用户展示Agent的决策推理链路

6、评测与度量标准

（1）评测要求：预设100个评测场景，针对核心问题，边界问题，无关问题做拆解。问题答案要给出预期理想酒店推荐或者回复。

（2）迭代与指标评估：

“酒店收藏”的对话数/开启对话沟通次数（可限制数量）*100%
酒店成功下单数/有效推荐酒店对话数*100%
一轮对话即可酒店收藏or下单次数/总酒店推荐数*100%
查询指令执行成功率、结果准确性（通过与人工分析结果对比）、问题平均回复时间、酒店推荐满意度（显性按钮+隐性下单概率）

7、迭代部署与持续进化

（1）分阶段上线：制定从内部测试验收、小范围开量到上线100%计划。

（2）性能监控：部署监控系统，实时跟踪线上核心评估指标和数据漂移情况。

（3）反馈闭环的建立：收集提前设定的显隐式用户反馈，用于后续Agent的优化

（4）上线版本评测：上线后，使用评测集，再次评测，确保核心场景Agent稳定、可靠、安全

（5）迭代方向：V1.0只允许查询一个平台的酒店信息并下单。V2.0可同时查询多个平台，多平台比价，结合储存的用户历史订单记录，推荐酒店下单。并记录Agent成功指标（任务成功率、独立问题解决率、用户信任度、工具调用准确率）

以上流程中，有很核心的一点需要提及。当Agent MVP版本设计完成后，立刻！马上！开始评测。评测应该从最开始的时候，贯穿全流程。很多的AI产品经理都没有意识到：AI技术生成的内容具有不稳定性。评测驱动应该贯穿整个AI产品的生命周期。

05 Agent反常识和趋势思考

以下是编者经过自己长时间以来的产品测评，以及大量资料的查询，整理的一些有关Agent的反常识和趋势思考，我理解其中每一点都值得PM深入挖掘其背后逻辑，并作为产品设计实操落地的原则。

反常识1：通用智能=圆，只能不断趋近。垂类智能更切合实际

Agent可以分成两大类，通用型Agent和垂类Agent。 Agent的智能水平建立在模型水平的基础上。垂类Agent不过分依赖太多的模型能力，且部署落地成本更低，短期更容易实现。比方说，搭建一个属于你们行业的“GenFlow”。

我没做过严谨的统计，不过GenFlow2.0是据我所知，国内目前首个调用了100+agent的产品。未来会出现1000+，10000+。“通用”Agent极有可能基于A2A协议调用N个智能体诞生。

伪通用智能，会有总代理Agent调用这些有不同专业能力的Agent。对总代理Agent的要求是：有适配性极强的调度能力。

反常识2（产品思考）：不要为所有任务都构建智能体或使用智能体

智能体被神话了。可能大家觉得加上了智能两个字，就能掩盖某些场景下，它仍然是智障的事实。

更何况有些场景，哪怕Agent足够智能，也永远无法完全取代传统场景。否则为什么仍有很多人不带智能手表，依旧使用传统的指针手表？

回归到原始场景，用户，需求，和商业价值定义你的产品方案。反常识3（人文思考）：人是用来承担责任的

Agent的确可以代替一部分人的工作内容。但不是说它会完全取代人们的工作，它的定位应该是：辅助人类提升效率，重心在于辅助。Agent是一种智能辅助，如果你平时的工作也是辅助，但是你不“智能”，那么你一定会被替代。可能是另一个人，也可能是Agent，因为价格。

我们应该重新审视自身和Agent的关系。Agent应该是一种可协助我们提升效率的生态能力。

在人类社会有很重要的一点，因为你是人，所以我会使用你。人类社会有很重要一个事情——承担责任。没人能让Agent承担责任。人类社会需要有人使用Agent，也许你什么都不用会，你只需要为Agent产出的内容负责

趋势思考1——Agent会弱化人们提问题的能力

很喜欢李继刚老师的这句话。在AI时代，可能我们能提出好问题的能力会被弱化。甚至不知道如何提出好问题。

想让一个AI完成指令，需要提供明确的信息。但是产品经理们知道，大多数人不会提供优质的prompt。如果想让产品能进入C端市场，就需要降低产品的使用门槛。想使用好AI能力，需要给出足够的信息。当信息提供越来越少，问问题的能力也就开始退化。需要警惕这种变化。

趋势思考2——优秀的Agent应该学会做减法，学会遗忘

Agent的有一个很重要的功能在于记忆，目前是成在记忆，未来也许会败给记忆。记住太多东西未必是好的，未来Agent的迭代方向，应该是学会忘记。选择忘记比记忆难许多倍。当Agent能涌现出来忘记功能时，通用Agent也就更近了。

06 附：Agent基础概念

由于这部分内容属于基础概念所以写在最后，用于科普。Agent的基础原理和组成，是我们方案设计基础。

1、什么是智能体？

Agent有一个别称叫做智能体。我不知道谁先给它起名叫智能体的。但我觉得这个名字给他起的太高级了，我来给他换个接地气的名字——高级打工人。

举个真实的例子：

你在水果店工作，老板找到你说：本月他想实现店铺营收再翻1倍，让你将营收搞上去。你的拿到这个任务后，就开始做如下几个动作。

step1：接受并理解老板的意图：营收再翻一倍。
step2：为实现该目标，你做了大量调研，做任务拆解：计算水果损耗，计算每日客流量，分析当季爆品，等等。
step3：最后你明确了解决方案：西瓜做成西瓜汁卖可以有更多利润，香蕉损耗最多且不容易卖光可以少上这种水果。
step4：立即动手实操，最终实现了店铺营收翻倍，甚至超出老板预期。

案例中的高级打工人，就是一个非常棒的Agent。可以清楚理解老板意图，为了实现老板给你的指令，自己拆解任务，分析任务，输出解决方案，并执行方案，最终满足老板的预期。这就是Agent的工作原理。

2、智能体结构模型

Agent由三个核心内容构建而成：大脑，工具，记忆。无论多么复杂的智能体系统，本质都是他们三个。

大脑：就是为Agent提供智能的模型，如Deepseek，他们负责获取信息，推理，规划等功能
记忆：让Agent记住之前的聊天（上下文、外部文档、数据库），以及执行任务过程的操作，利用背景和上下文统一目标，进而做出更好的决策
工具：外部的任意工具，如：API、MCP等

智能体通过这样自主编排调用使其内容生成质量极高。由此，引出了Agent等四大能力

3、智能体四大能力

1）信息感知能力：输入层包括文本，图片，语音

最初Agent依赖的模型叫做大语言模型，输入端是纯文本。但真实的物理社会中还有图片，语音等更多的模态。于是又通过OCR（图像转文字），ASR（语音转文字）将图片，语音，转化成文本，再输入给大模型；但这种方式效率低下。于是工程师们又让模型增强了端到端的感知能力，支持输入图片语音，可以更好分析这些信息，用于后续数据处理。

至此，大模型有了多模态的识别感知能力，Agent对于外界信息的接收感知，也更加多样和精准。

2）规划能力：分析思考的能力

让Agent可以拥有这种能力，离不开这篇大作：《Tree of Thoughts》。在这个论文中，提到了一个概念：思维树。

简单来说：有了思维树树后，模型在解决问题之前，就能可以主动的拆解问题。并且整理出来多种解决方案，思考每个解决方案要思考，每一步都要做什么。最后再一个给出一个最优解。

但是现实世界的问题很复杂，目前的模型水平，通过一个模型无法给出更好的解决方案，于是工程师们让多个模型搭配起来给解决答案，就像社会分工一样，各司其职相互配合解决问题。A模型处理任务1，B工具处理任务2。通过这种形式的配合，将任务做到拆解，配合给出解决方案。

这种架构，就称之为智能体架构。 coze，dify就是一种生成智能体架构的平台。

3）行动能力

为了让Agent知道如何行动，工程师通过监督微调的方式（SFT）:人工标注高质量数据，进行预训练，使其更好的完成指定任务。通过这样的方式，让模型学会了工具调用。

最常见的模型调用的工具就是API，但有些场景没有ApI可以被调用，于是Claude的母公司Anthropic发明一个很牛的协议——MCP（模型上下文协议）。这个协议将Api的调用做到了标准化。让许多没有Api的功能，通过这个协议就能做到被调用使用。

4）记忆能力

Agent的记忆能力要分为两类：短期记忆和长期记忆。

短期记忆：Agent早上下文记忆功能，有字符限制。每一次请求Agent，都会自主查询之前沟通的信息。由于这种字段限制，就会导致Agent只能记住有限的数据信息，超出了规定字符会自动截断，只会结合限制字符内的信息做出响应。
长期记忆：很多场景下，我们需要模型拥有长期记忆。所以就需要将历史数据，提前储存到外部的一个向量数据库中。再依赖RAG（检索增强生成）技术，让用户发起请求时，去向量数据库中，搜索相关内容进行匹配。这个技术，还能有效地减少模型的幻觉问题。