惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hugging Face - Blog
Hugging Face - Blog
云风的 BLOG
云风的 BLOG
大猫的无限游戏
大猫的无限游戏
M
MIT News - Artificial intelligence
L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Recent Announcements
Recent Announcements
IT之家
IT之家
Google DeepMind News
Google DeepMind News
罗磊的独立博客
爱范儿
爱范儿
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
U
Unit 42
MongoDB | Blog
MongoDB | Blog
S
SegmentFault 最新的问题
B
Blog
博客园 - 叶小钗
月光博客
月光博客
Stack Overflow Blog
Stack Overflow Blog
V
Visual Studio Blog
C
Check Point Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
AI智能体应用与反常识思考
糊研乱宇 · 2025-08-26 · via 人人都是产品经理

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

编者最近在做两个事情

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

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

  1. 工作流和智能体如何选择
  2. A2A协议下的四种畅想连接方式
  3. Agent的产品方案设计
  4. 智能体反常识思考
  5. 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(检索增强生成)技术,让用户发起请求时,去向量数据库中,搜索相关内容进行匹配。这个技术,还能有效地减少模型的幻觉问题。

写在最后

AI相关的内容太杂,太多了。前天的先驱技术,今天就被超越了。面对如此庞大的信息,静心思考很重要。

作为人类,我们不应该选择成为工作流。

创作不易,欢迎大家点赞转发评论。

参考资料

[1]《AI智能体需求规格设计指南》比克

[2]《Building effective agents》Erik Schluntz Barry Zhang

[3]《Tree of Thoughts》Shunyu Yao and et al

本文由 @单车胡思 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议