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

推荐订阅源

cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
AWS News Blog
AWS News Blog
V
Vulnerabilities – Threatpost
D
Darknet – Hacking Tools, Hacker News & Cyber Security
量子位
博客园 - 叶小钗
AI
AI
T
Tor Project blog
Forbes - Security
Forbes - Security
W
WeLiveSecurity
博客园_首页
爱范儿
爱范儿
J
Java Code Geeks
B
Blog
G
GRAHAM CLULEY
aimingoo的专栏
aimingoo的专栏
Cloudbric
Cloudbric
C
CXSECURITY Database RSS Feed - CXSecurity.com
TaoSecurity Blog
TaoSecurity Blog
L
LINUX DO - 热门话题
阮一峰的网络日志
阮一峰的网络日志
有赞技术团队
有赞技术团队
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Simon Willison's Weblog
Simon Willison's Weblog
云风的 BLOG
云风的 BLOG
Google DeepMind News
Google DeepMind News
H
Help Net Security
博客园 - 三生石上(FineUI控件)
C
Cisco Blogs
C
Cybersecurity and Infrastructure Security Agency CISA
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
P
Palo Alto Networks Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recent Commits to openclaw:main
Recent Commits to openclaw:main
博客园 - 司徒正美
The Last Watchdog
The Last Watchdog
Blog — PlanetScale
Blog — PlanetScale
T
The Blog of Author Tim Ferriss
S
Secure Thoughts
Spread Privacy
Spread Privacy
F
Fortinet All Blogs
月光博客
月光博客
大猫的无限游戏
大猫的无限游戏
S
SegmentFault 最新的问题
H
Hackread – Cybersecurity News, Data Breaches, AI and More
A
About on SuperTechFans
Security Latest
Security Latest
Webroot Blog
Webroot Blog
Scott Helme
Scott Helme
Hugging Face - Blog
Hugging Face - 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迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
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协议