Deep Dive
Shownotes Transcript
大家好,欢迎收听尼海克,我是赛头,我是一笑
我是龟龟本期节目由 Podwise 赞助播出 Podwise 是一款为播客听众制作的 AI 学习软件产品的 slogan 是 Read Before ListenPodwise 通过 AI 对播客内容进行转录提取 总结 分析等一系列操作帮你掰开了 揉碎了 硬核的播客内容同时与 Notion、Readwise 等平台的打通嵌入知识管理工作流协助您的其他包括新闻 NewsletterBlog 的内容帮你打造第二大脑
Podwise 也为本期听众准备了三个 5 折优惠码针对本期在小宇宙与我们互动的精选回复欢迎大家踊跃来玩好的,那开始我们本期的节目吧最近 Manus 的横空出世让 Agent 的这个概念又受到了巨大的关注啊连 A 股都出现了 Manus 概念股不过我们今天不聊 Manus 我想跟大家一起来聊聊 AI Agent 这个品类我算了一下从 AutoGBT 开始啊
到今天其实已经快两年了但是我感觉 AI Agent 的这个概念就一直有点雷声大雨点小的意思所以我想讨论一下说今天是这个时间点到了吗还是说这个又是一轮新的炒作那这个炒作过后然后热度过去了又会一样归于平静那我们今天就跟大家一起讨论一下这个话题
首先我想跟大家掰扯一下这个定义啊就是到底什么是一个 agent 那我为什么想问这个问题啊因为 Maths 在宣传的时候他在讲说他自己叫通用 AI agent 对吧那我做一个天气预报的一个功能的一个 agent 是不是也是一个 agent 就感觉好像啥都能叫自己是 agent 就是感觉这个 agent 这个概念有点包罗万象的那种感觉呢就这个 agent 到底就怎么去定义这个 agent 呢
对其实什么是 agent 我自己都想过很久很久像我们从传统的软件工程可能过来的到人工智能领域
其实一直不太理解什么是 agent 就总感觉这个是一个很迷糊的一个概念反正现在给我的感受是在 AI 领域的概念是真的很多它造词的这种概念比我们传统软件工程造词要造得夸张很多我们以前可能一个技术性的一个东西可能一取个名字就是取的很贴近的一个东西比如说我们以前做配置管理可能就叫配置中心了对吧
那你可能现在在 AI 领域为了稍微存一点商下文数据就把那个东西叫记忆了对吧对所以这些这种造词的和我们以前的时候那种概念是完全不一样的所以我更多的觉得这有一定的概念的成分在里面的
然后最近刚好看到 Google 的一个产品总监也是 GitHub Copilator 的一个负责人然后他也在就是说关于代理 agent 这个名词他也觉得这个词其实
不是一个好的名词至少今天被大家讨论的过多了过度使用了不管是媒体还是行业等等对这个词的有一定的滥用的程度在里面对吧更多的是一种照概念的程度在里面对然后另外回到
比如说什么是一个 agent 这个概念上来说的话我现在反正总觉得有两个方面要去理解这件事第一个方面就是可能从一个更抽象的程度或者说从产品的程度或者说从那种技术领域之外的那些人比如说自媒体很多人他们理解的 agent 可能就是一个真正的很高级的一个智能体
他能够帮你干很多很多的活或者说能干一个特定领域的一个事情就是一个比较抽象的概念或者说 agent 他还具有一些什么自主意识或者说他能够去感知环境能够去获得一些反馈然后再去修正自己的一些行为或者说结果之类的这种话其实你听上去他很抽象对吧就你从技术的角度其实你很难
去理解这件事它究竟是一个什么东西这个我觉得说是一种抽象的概念或者说从现在大家去定义产品的这样的一个比较高维度的一个角度去看 A 镜头的话它可能今天大多数的人认为这样的东西是一个 A 镜头反正就是一个智能体它是具有一些智能性在里面的但是我觉得
从开发的角度或者说从工程时间或者说从我们这些程序员的角度来说你最终还是要回到怎么去实现一个 agent
角度去看待什么是 A-GEN 它因为你如果不能从实现的角度去定义什么是 A-GEN 的话其实你最终是没办法去实现它的没办法去把这个东西给做出来的因为太抽象的概念是没办法落地的所以从这个角度我觉得来理解 A-GEN 的话我就发现今天大家
包括那些什么 AutoGPT 也好还微软的什么 AutoGPT 等等各种框架里面大家去定义什么是 agent 就会发现 agent 可能就是一个大元模型再加上它要扮演的一个角色
就是这一个对象在我们的程序里面这样的一个对象它可能是用某个大元模型来承担的然后给它了一些 Parameter 的描述它可能扮演了一个什么样的角色它能做什么样的事情这样的一个组合就代表了一个 agent 的实体然后在一个可能框架内可以同时运行很多的这样的一个实体的组合然后他们可以协同的去
完成一件更大的事情更复杂的任务从这个角度来理解 agent 的话就更符合程序员的思维了你可能就有办法去实现
不管你是一个小到一个天气还是大到一个像今天的 Miles 或者说其他的一个东西有感觉好像也没有那么难理解什么东西我要从环境获得反馈然后去制冷决策就这些听上去就很复杂的一个东西其实好像你从这种角度去理解好像它也没那么复杂了这就是反正我一直觉得这个概念还是挺迷糊的
对你如果说 agent 这个词本身啊就是不讲 AI 这个语境的话它本身使用就很宽泛如果你翻译成中文的话像什么代理人啊经纪人啊经理人啊中介啊可能还有猎头啊专员啊还有特工对吧还有间谍都是 agent 反正就是这些词就都有一个说帮你去干或者说代为执行的这个意思在都可以算
例如猎头就是招聘的 agent,他因为帮你招聘嘛,旅行社专员其实就是旅游的 agent,因为他帮你订票啊,或者规划旅游线路之类的。特工怎么算,特工就是国家机器的 agent,带国家执行秘密任务。就按这个意思,其实几乎什么职业你都可以往 agent 这个词上靠,所以就非常宽泛。
放到 AI agent 这个场景下那你理解说我 AI 带你去做各种事情那叫 AI agent 好像也确实就也是这么个意思翻译成中文的话 AI 专员像你说的这位是你的查天器 AI 专员这位是你的市场研究 AI 专员那 Manas 就是你的通用 AI 专员啥都能代替你去做但实际上 Manas 并不是真的啥都能做
对但这里有个很重要的特征我觉得有必要单独拿出来强调一下就是 AI Agent 它其实更加强调自主性就是无需持续的人工干预我觉得有别于之前的像 AI Assistant 就是助手嘛然后还有包括以前更多像这个 AI 的使用场景其实是 Chatbot 对吧 联络机器人
那 AI Agent 其实是它应该有的特点是说它能够对目标进行持续的自主的推进包括你说我自主的去设定计划然后去获取数据以各种可能有效的方式来使用和处理数据比如说去把它做成图表甚至 Manager 还演示说我去做个网站给你展示这些数据对吧
那其实最终就是为了去达成你交付给他的这个目标那还包括说多个 AI 之间可以协同这个我觉得是有别于说传统前面像 AI 助手或者说 AI 聊天机器人之类的重要区别只不过呢这些特征在 Agent 过去指代的人这个目标上它其实是自然而然的特质人自然就会干这些事情但是你放到今天的 AI 语境上其实就可以算是比较先进的特性了
那这个其实就是 AI agent 它比较特别的地方相对于人的 agent 这个词来讲
然后我还去查了一下我原本总以为 AI Aging 的这个词是大模型出现后才有的结果发现这词岁数比我们都大对它可能是 1960 几年还是五几年的时候就是由马文明斯基图灵奖的得主提出来的对已经有点历史了所以可能也确实跟今天的这个他最初的这个提出来的这个时候可能跟今天大家相似
想要去表达的也有一些差距了对我自己觉得这个 agent 这个概念混淆有一个很大的一个原因我们以前在写框架然后那个框架里面可能有一部分的内容需要到别的地方然后去把内容传回来我可能会写一个 xxxagent
对吧到别人的手机去执行然后把那个东西传回来对吧但这个 agent 是我们以前经常写的时候我们会这样子去用对吧但是今天到这个逻辑上面的 agent 到 AI agent 的这个逻辑跟我们那个逻辑好像就不太一样了对那当前的这个 AI agent 我觉得它很核心的能力就是它可以执行很多很多个 task 对吧比如说我们刚才讲说去查天气对吧那真正去执行查天气的那个动作它其实就是一个 task
那 task 怎么讲就简化一下的话我觉得它可能就是一个 function 对吧那 AI agent 它其实说白了就是利用 IIM 去做 function calling 对然后这个事情追根溯源来讲一开始应该是 ChatGPT 开始做的自从有 IIM 之后对就我想问一下就是这个 function calling 它具体是怎么被调用的
我其实不太清楚就是因为 LM 跟 function 本身 function 本身是带参数的嘛它是需要被调用的但是这个 LM 是怎么跟 function 结合到一起的它背后是怎么实现这个调用怎么实现返回的怎么实现输出的这个部分我真的不太清楚
对能不能给我们介绍一下其实一刚开始说实话就是那个 CHAT GPT-1 推出这种 Function Calling 这样的功能的时候我自己也觉得说 ALM 可以这么强大的吗它都可以自己去获取天气或者说去获取一个比如说 Hackers 6 上的一个
post 的一个列表它就已经这么强了可以到这种程度我说那可能我们程序员可能真的是没啥用了已经对如果有这么厉害的话我觉得最后当你可能去看了它的介绍文档过后你会发现这个功能它并不是理想象中的那个样子对其实包括今天我和很多非程序员或者说
不是开发者的同学有时候在聊天的时候他们总会提到一点说现在的大语言模型都可以自己去执行工具了执行一个动作就他们的理解其实是说是大语言模型 GPT 或者 Jomina 他们帮你去做了一次 Google 的搜索或者说去获取了一个天气就是做了但是其实本质上它
不是这个样子的所以说我们今天当然我们回到从程序员的视角来看这个问题的话编程的角度来看的话其实它大概就是有这样的几个步骤其实我们一看这几个步骤就知道了这个其实与大圆模型没有任何关系第一步就是比如还是就用问的就是获取天气这个例子为例的话那我可能首先就要定义一个所谓的工具定义一个理说的 task
那我去编程怎么定义一个它是个不就是写一个 function 写一个函数对这个函数可能有参数当然你获取天气可能需要有个参数比如我要获取杭州的天气对吧可能参数就是杭州了可能就是这个样子的对所以我首先要写一个 function 然后带来一个 location 的一个位置
这样的一个东西但也可能你的方格性是去查询数据库我的数据库里面可能已经存有天气可能不是去调一个 web 的 API 对吧我就从 MySeq 里面去 slack 我的一个天气的数据出来都是一样的对甚至是访问浏览器这些总之来说我就是先要封装一个函数这是我的第一步这是我的本地代码其实这个时候与 gpt 没有任何关系对
第二步的话可能就是在 chapboard 上去问了一个问题说我要查询一下杭州的天气这个时候其实当你把这个问题发送给 AOLM 的时候当然前面我们刚才说我们定义的工具其实我已经给它注册到大圆模型上了已经注册给 AOLM 了所以当你提一个问题的时候
他这个时候就会理解你这个问题发现你是要一个天气但是我自己又不知道刚好你又给我注册了一个工具的 list 这个时候我去匹配你的一个工具发现有一个工具好像可以获取到天气所以他最后就会返回这个时候 AM 返回的并不是
一个正常的 answer text 不是这样的了它可能就是直接给你返回一个匹配到的一个工具的列表告诉给你接下来第三步作为我们自己就是程序员开发者这一端我发现 LM 给我返回了一个匹配到的一个工具的函数的名字是 XXX 比较 getweather 这个时候我就可能发现我本地就是我之前定义的那个 getweather 那个 function 所以我就去执行一下我的那个 function
然后并且 AOM 它也已经把我说我要过去杭州或者北京的天气然后它把北京杭州参数也返回给我了然后我就给它传进去所以我再调一下我本地的代码其实真正执行 API core 的代码还是在我本地运行的这我运行完了然后就拿到了一个比如说今天 20 多度的这样的一个数值然后我就把这个数值又再发回给大远模型发给 GPT
这个时候 GPT 收到了工具的结果然后它在真正开始做一个 answer 回答 Eddy 的提问所以你会发现它其实是一来一回有好几个步骤的所以说 LM 在这里面起到了一个最关键的作用就是帮你去路由工具对 它会帮你去匹配工具说你现在
给我提的这个比较快的事情或者是做的是一个快的查询发现我自己没有能力回答你的时候我会去给你匹配一个最合适的工具给你对就他其实做的是这件事情其实他做的还是一个自然语言的理解
对 这个是我们传统编程无法解决的问题比如说你说你要获取一个天气这句话我传统编程我是没办法去调用 getWeather 这个函数的但是大语言模型它天生的要解决的能力就是这样的一个能力所以它帮我们处理了自然语言理解的这一个关键的步骤所以剩下的事情还是我们程序员自己要去做的事情 对
我觉得这是一个 function calling 或者说去执行一个 task 一个 tool 的一个今天应该所有的预言模型
大概的一个步骤都是这样的一个步骤其实我们可以看出来就像这种执行一个 task 或者说叫 function calling 的时候其实它更多的时候就像获取天气一样可能就是用来获取一个 web 的数据当然除了 web 的数据可能还要去做一个 web 的动作因为获取天气还是太简单了我们可能说想去操作 web 的浏览器
怎么怎么样的通过浏览器然后去访问一个网站之类的就像曼乐士的演示的一些功能一样这些都是做一些外部的动作这就是我们之前有很多期的节目里面在聊今天的 AI 可能更多的是扮演了我们的一个大佬他们可以思考
可以决策一些结论但是他没办法去操控外部的整个世界就是没有手和脚这件事但是现在有了 Function Corner 有了这些可以执行到外部的一些 Tool 的这样的一些机制其实相当于弥补了手和脚的这样的一个很关键的一个环节我也觉得说这个可能是今天大家在理解 agent 上一个很关键的一个环节就是说你一定要有
这种执行 web 工具的能力可能对一个比较通用或者说是比较智能的一个 agent 来说的话可能是这样的然后再补充一点就是像 fungus-in-coding 我们可以看到我们除了可以去执行 web 的动作或者说去获取 web 的数据以外其实我们很多时候可以用它去做一些
意图识别可以看那个用户的查询的问题它的意图究竟是做什么其实这件事情也可以直接用这个工具来做比如说我们自己在 Polarize 的那个 Ask AI 的功能里面我希望能够区分用户提的那个问题究竟是在做哪几类查询比如他可能有些用户一上来就是在里面输入一个你可以做什么或者说你是谁
就是提一些这其实和我们刚开始预设的这个 askedlooker 它的功能可能就是想用用户来提一些查询播客内容的一些问题但是你永远不知道用户会怎么去使用你的产品对吧对所以他上来问的问题都很奇怪然后比较可能就是你可以做什么你是谁
等等就是这样一些问题这个时候我肯定希望还是给用户一个好的响应要告诉他我是 Pro S 开发的什么 20 个助手我可以给你提供一些 XXX 的能力你可以怎么去使用它所以这是一个好的
面对这种问题的一个回答那可能用户也可能在里面去搜索我最喜欢的一些节目根据我的 list 有可能我去搜索关于 AI 的节目我也有可能会去搜索
节目的具体的内容的一些相关的一些信息比如讲睡眠的或者说讲 building public 等等这些其实它的意图是不一样的其实我可以完全给每一种给它分类好了过后每一个类型就给它定义成一个 function
然后再描述好这个 function 它是干什么的这个时候再把它注册给大圆模型最后用户来到这个问题的时候就靠大圆模型能够去帮我去路由好做好匹配这个用户原来来的是这一类问题那我就给他这样的回复在背后或者说查数据库的时候就用这种方式去查询这也是一个比较好用的一个地方否则的话你就要靠自己可能去写个 prompt
然后去做用户的 query 的意图识别先去判断它这个 query 大概是一个什么什么样的分类里面对然后最后其实本质上最后达到的效果也是一样的但是可能放个性 query 看上去很自然很
有时更流畅一点吧对那我就有一个疑问啊你说像 function calling 的这个逻辑啊就是它这种利用 IOM 来实现 pass 和调用的就它的成功率是怎么保证的我感觉这里边有两种成功率啊就一种是说我定向的我就想调这个 guideweather 它是不是一定能够被触发
对吧这是一种然后还有一种就是在多个 task 的情况下面我能不能找到正确的 task 比如说我现在我给那个 LM 里边然后我注册了比如说 10 个 task 对吧那他能不能帮我找到正确的 task 然后去出发我就想问一下就这种的成功率他是怎么保证的对
我觉得这件事情肯定是属于你说的一个大圆模型你支持了 Banking Calling 这样的功能然后这件事情它一定是比较基础的门槛了所以你连多工具或者多 Task 都不支持那肯定这个是用不上的对吧但是这个工具确实就像你说的成功率这件事一定是有影响的
比如说像 Chad Gibbett 他给出了一个 best practice 里面有你的工具的数量可能最好控制在 20 个以内对你如果太多太多那你可能是真的是会很难去保证这件事就是保证这件事情能把你自然语言的那一句话匹配到需要用哪些工具
这件事就是一个大语言模型的能力问题这是我们开发者里是无法控制的一件事情当然你可以去优化这件事情对那比如说当你在定义这个 tool 那个 y 部的工具的时候
它有三个很关键的信息是我们需要像写 prompt 这样去斟酌的比如它的 name 名字比如像 getweather 这个名字还是比较清晰的对吧一个 description 就是描述我们去写一个函数的时候除了有个名字以外其实我们人也是这样你看到了那个函数名叫 getweather 它大概率就是 getweather 这个名字其实很关键对我们程序员老讲求
可读性对吧所以说对于大圆模型来说可读性其实更重要然后 description 就是向大家写一个 comment 写一个注释
这个注释就是你就是要给他描述的很简洁清晰易懂对大学人来说可能比人的要求还更高一点包括你的参数的定义你的参数比如就是我要获取杭州的天际给 location 或者说某个国家 country 你这个参数显然就是很重要的因为你把参数定义成 country 一个国家可能和你定义成 location 它的表现可能有时候会不一样
因为他理解国家的话比如你说我要获取美国的天气他就能精准的找到了当然有个参数里如果写个 ABC 这个可能就会有点误差了所以说不能像我们平时写代码我们因为经常自己写代码可能在里面会去写一些参数 A 参数 B 参数 C 其实我们人也不好读那对于大羽毛也是一样的
这个就和我们平时开发一个函数功能本质上是一样的对就是要触发的准就是要这些东西描述的很清晰很准确对第二个很关键的一个优化点就是涉及到多 task 多 tool 之间的时候如果离这些 function 之间功能差异很大的时候
其实效果也会匹配的效果也会很好比如说我提供了两个 function 一个是 getWeather 对吧另外一个是 searchPodcast 这两个东西明显都不是不同的领域的差距很大就从人的角度你一看都知道这个 getWeather 是干啥的 searchPodcast 是干啥的对于大约模型的时候也是同样如此对像刚才我前面就提到了我们在做意图识别的时候比如说我要去
去 search podcast 是吧 with 一个 theme 一个主题 topic 然后我去 search podcastwith favorite 你最喜欢的甚至是去 searchinformationfrom podcast 你会发现
这三个听上去你先别说大元模型就是你作为人作为一个程序你听上去有时候就迷糊了对吧就发现他们反正都是在 search podcast 只是他们然后有一个非常细微的差别对那这种情况它的成功率的控制上就要费事情很多了就它的准确率就比那种差距很大的工具要差很多很多对所以说这两个点我觉得是比较
关键的嘛然后剩下的我就说了就是大圆模型的能力了当然我个人还是相信这一块根据我自己反复去测试的话我觉得这一块至少越往后面走这个的保障性是会非常非常高的对
作为开发者的话你肯定是要根据你自己的场景然后去反复去调试去测试这个点对听下来还是有种 trade off 因为你自己用模糊的方式去查所以说它可能就会影响一些正确率但如果你用精确的方式查那它就不会那么灵活对吧就这两个事还是有一点 trade off 是的
对那我就想到另外一件事就是其实你看 ChartGPT 它有那个 function calling 对吧然后我知道是 Cloud 其实它在前段时间也推出了一个协议叫 MCP 叫 Model Context Protocol 对它好像是一个协议我觉得就自从它推出这个 MCP 之后社区上对 MCP 的接受度比 ChartGPT 的 function calling 要高很多比如说你像 Cursor 像 WindServe
然后他们在自己的这个 IDE 里面都支持了 MCP 协议而且现在市面上面有很多的那种 MCP 集合站就他在讲说我收集了很多人做的 MCP 都在这里然后你可以选选过来之后你不管你在 Cursor 上执行 Windows 上执行还是去 Cloud 的 Desktop 上面执行我都允许让你去执行我就想问一下你说 function calling 跟 MCP 就他们算是两种协议吗就是他们之间是个什么关系嗯
我觉得理解他们之间的关系也很简单比如说可以简单的理解成啥呢有方格性 coding 它其实是一个底层的能力比如说我们经常可能大家都能理解我去开发一个浏览器的插件那你可能说你开发一个浏览器插件的时候你可能要调用很多浏览器提供的 API 的一些能力比如说你要去给 Chrome 给你定义了一个标准你去写这个插件应该按什么框架什么样的一个种方式去写
那这件事其实是 mcp 对你必须得要按这个方式去写出来的这个浏览器的插件才能在我的 chrome 上运行
对就这有一个 SPAC 那这个我觉得它是属于 MCP 但是你去写那个浏览器插件的事你肯定为了让你这个插件有用的话你肯定得要去调用一些浏览器的能力吧它否则是说你总不会总是写一个 Hardware 的这样的毫无意义的插件对吧你如果要想真正的去干一些事情那你肯定得去调一些底层能力所以说
那这个底层的能力其实就是 Function Calling 对这也是为什么有时候我们可能会觉得 Function Calling 没有 MCP 那么火毕竟 MCP 它其实最终是封装出了各种的插件那些插件可以被终端的 end user 可以直接去使用的东西但是 Function Calling 它本身是一个程序员的东西所以说这个东西它肯定就不会有那么多的人去关注了对它是一个两个维度
那我们再回到一个细节上来说的话 MCP 里面
它其实真的就是在管理开发者最需要管理的三种东西一类就是数据这个就不用说了对就是我可能通过 MCPC 协议可以去获取一个外部的数据比如说去获取一篇博客的文章获取本地的 PDF 的文件等等对就是用来去管理数据的第二个就是要管理可以管理你的 prompt 对为了执行这个能力我写了一个什么样的 prompt
那这个也是做 AI Application 的关键之一第三类就是我们刚才聊到的 function calling 就是 tools 我这个 MCP 提供了哪样的一些 function 可以给你调用这三类其实是属于三大类资产我们可以理解成做一个 AI Application 的话我们简单的其实去理解一下 MCP 的流程其实就更理解这件事了
那一起开发了一个 AI 的 application 的话那它首先会去访问一个叫 MCP 的 client 这个 client 其实就是被我们集成到了 application 里面的一个,也可以理解成一个 SDK 对,然后这个东西就去访问 MCP 的 server 那这个 MCP 的 server 它可能就是部署在云上的远端的一个东西它这个 server 它在背后就可以去干各种事情比如说可以从我的数据库里面去查询数据
或者说去调用 Google Search 的 API 去帮我去做达到搜索的列表接果页等等反正可以干各种各样的事情对它总之这个 MCP 的 server 就给我爆了出来
这三种东西三种可用的资产作为 AI 的 application 你只需要去访问这三种资产就可以了所以说如果我们自己有理想给现在的那些 AI 的 application 或者说叫 AOAM 的 application 去提供包入你的数据能力的话你就选择去开发一个 MCP 的售货然后就放到你刚才说的那些什么 MCP 的导航站可能就有人来用你了对就是这个样子
但是如果我们是 AI Application 的开发者我们可能有时候想去访问别人的数据去做一个功能或者说访问别人的能力比如就访问 Search 搜索的能力这个时候我们就去那些导航站上去找一个现成的别人做好的 MCP 的 Server 去摆嫖就可以了这是两类人两类开发者
对在干的事情对再说回到 tools 也就是 Function Calling 的话对那就是我们就会去你写代码的时候你肯定就会去访问这个 MP Server 就会拿到一个在 MP Server 上托管好的一个这样的一个 tools 的列表那其实这个过程就是我们以前去做微服务的服务发现
对其实 MCP 的协议它本身就是一个传统的软件工程它与 AI 其实没有任何关系它本质上它上面全是传统软件工程的东西比如它的通信协议对吧采用双向的 SSE 就是 Client 这些都是传统的软件工程所以说这儿本身就有一个服务发现 MCP 它本身扮演的第一步就是一个服务发现我可以发现一下你上面有些什么东西然后就在我本地可能注册一下对然后就接下来的代码
同样就是回到了之前的 Function Calling 的流程当中去了所以这样看就会发现 MCP 它其实只是一种管理方式通过我这种协议来管理所有的这些数据这些资产一些能力它是用了一种更加标准化大众化的方式来管理管理我们之前的 Function Calling 就不用大家都从底层
去从头写嘛大家可以分享可以共享我觉得这也是一个肯定是一个很大的好处从生态的角度来说的话
嗯那就说 mcp 其实是定义了一种标准嘛反正这种标准让所有的只要你自己是一个工具的话你可以去实现一个那个 mcp client 对吧然后你实现一个标准的 mcp client 然后你就可以去调用所有的 mcp server 对吧因为大家的通信方式已经在整个程序里面已经完全被定义了嘛在整个 mcp 的这个框架里面已经被定义过了对
其实看 client 的话各种语言其实都已经提供好了嘛所以说离职需要集成可能对主要是要我们要去实现收入端的那些能力嘛对吧嗯对对对对是的那刚才我们有讲说你看 IOM 做 MCP 调用也好做 function calling 也好它其实有一个成功率的问题嘛这个就让我有一点想到了另外一类产品啊在 AI agent 在 AutoGPT 这个产品出来的这个过程里边其实还有一类叫 workflow 类的产品比如说国内字节做的这个 code
还有那个 define 就这些 workflow 的产品我感觉他们是可以解决调用稳定性的问题的因为它是靠程序链接起来的那我就想问一下这个 workflow 跟 agent 他们之间是一个什么样的关系是一种竞争的关系呢还是其实是可以合作的还是他们之间是一个什么关系其实我觉得这个问题真的是很好的一个可以探讨的一个问题这也是我觉得今天在
整个开发者社区里面其实争论的最多的一个问题像什么传统的软件工程过来的程序员其实都知道 workflow 是一个靠代码控制的那所有坚持这条路径的人都是觉得可控性这件事情很好
对吧那一定很好只要我能写代码我一定能让他百分百的运行的准就是这件事是这一帮人今天特别坚持的一个观点我觉得这个是对的另外今天就是确实有很多的一些新人进入这个领域他们其实更崇尚这种今天说的那种不受 workflow 的这种规则空置的 agent 的这种
很放飞自我的这种模式就是抛开技术的话我觉得这也是一个很有意思的一个现象就是也算是一种心脑的关联的冲突我觉得对反正我觉得这个还挺有意思的当然这是一点点观察吧对当然这个没有什么结论就是大家可以有自己的思考就好了对那回到
存技术问题上来说的话那在实际应用的开发中其实我个人是支持 workflow 的至少今天的话那在去年就是 2024 年年底不是那个 Anthropic 他们总结了一个 building effectiveagents 的一个模式的一篇文章这篇文章也很火对
其实那篇文章里面讲的东西就是大多数我觉得是今天去构建一个 AI 应用涉及到的所有的内容其实本质上就是 workflow 的一些模式但是 workflow 我觉得这个东西没什么特别好聊的因为大家都能理解这件事但是如果回到 agent 的话
我觉得今天又有一点新的因为我们自己其实是从 workflow 做过来的一路比如说我们去做 portalize 的话我们一路可能从什么我们要下载音频开始然后去做 transcribe 最后去做总结总结里面又分了因为总结阶段其实是来到了大圆模型的阶段在这个阶段里面就是我们把它拆成了很多很多的步骤比如说可以去总结章节总结完了又可以做
提取什么 QA 等等做 MineMap 你会发现每一个功能点都是被我们拆到了 workflow 的一个
一个步骤里面或者说一个具体的一个 task 里面去完成的在这个 task 里面其实做的事情就非常简单了你可能对吧就是用 proampt 去处理相关 input 进来的数据对这反正就是 workflow 的思维这里面我觉得没有什么特别过多讲的东西我觉得我自己可能还是有一点在认知上有一点点的改变对虽然说今天你让我去做一个新的东西可能我也会用 workflow 去快速拿到那个效果
稳定性但是我觉得今天 agent 确实也有一些道理在里面对也就像刚才贵贵说的现在的 agent 可能更强调一些自主性
这个确实现在在我的脑子里面我觉得 agent 也是他一定具备自主性这件事他能够自己做 planning 就是我给他一个任务给他一个目标他能够自己去做好 planning 做好规划做好 to-do list 要解决的问题最后你再去做分析做推理也好最终还有去调用 web 的 calling 一些工具也好最终再给我一个结果但这个年度听上去就很长并且也不是 work flow 的那种
环节的控制对但是我觉得这个就是确实挺 fancy 的一件事情所以说我自己也在最近也在思考也在尝试说比如说我们回到播客总结这件事情上那理论上其实可能最好的一个就是很 fancy 的一个形态是啥呢比如我给他提了一个任务说帮我总结某个节目的这样的一个任务给他可能最多在设定一个目标
剩下的 agent 就能够自动去首先第一步就是帮我做一个 planning 其实做 planning 这一步它显然是非常非常关键的其实把 planning 做好了后面的过程其实就会简单很多然后最终再去做执行最后过生成一个整个的总结的报告看我们今天的 workflow 的样子它其实有个很大的问题它生成的内容就是什么章节 takeaway QA mind map
就是整个你会发现它任何节目并且对于任何人它其实都是一个统一的模板我觉得这个东西它可能有点不太符合 AI 时代的那种样子反正这是我走到今天的一种感觉就它是一个统一的模板所有的东西都是统一的所有的节目是统一的面对所有的人也是统一的对它不知道这个人的喜好也就是说它没有记忆能力就它记不住这个人
比如我现在很关注 AI 的博客然后在 AI 博客里面我的关注点肯定和贵贵和 Scythe 的关注点是不一样的这个很正常我们三个人去读同一本书最终给大家留下印象最深刻的事情一定是不一样的看一个电视剧也是不一样的看一部电影大家的笑点我相信大家都是有自己的不同之处的所以说我觉得人这件事其实真的很重要所以说为什么 Agentor 里面有个概念叫基因
所以我觉得它的存在确实是有道理的这就是我觉得说我们今天去思考这种总结类的东西不管你是总结播客还是总结文章你是不是能够根据这个人的喜好或者说还要根据这个目标内容它是一个讲相声的播客是一个单口相声还是说它是一个访谈节目还是说它是一个
讲历史文学讲技术分享的就像我们今天这样他们的内容形式或者内容点都完全不一样其实他们可能在总结之前的那个 planning 出来的任务就应该是不一样的它就不应该是一个固定的套路和模板所以这是我觉得说 agent 这种模式让我觉得说它可能确实具有更高的智能性
所以这是我今天还比较认可的一个方向从这样来看就是 workflow 归在啥归在稳定高效对拿结果很快 agent 的方式显然就是能给人的那种想象空间很大很 fancy 如果你做到了成果结果的话它明显就是一件震惊能给人更多的 Aha moment 的这种的一个形态对
那我自己今天比较倾向说这种无规则少规则的 agent 能够让他们去自主探索对这里面可能就是没有规则没有 SOP 没有 prompt 但所谓的没有 prompt 就是没有那种常 prompt 对就像我们可能给一个员工去分配了一个研究的主题
他自己去折腾你没有给他设定任何的框架对那可能一两个月过后他就可能会给你一个成果那这个成果可能是惊喜也可能是惊吓所以说因为我一直最近在思考这件事你可能从这个 agent 的事情你就会发现一点就是说今天比如说为什么大厂的创新可能有时候要慢一些小团队或者个人有时候他创新就是会快一些
他可能点也在这里大厂可能更讲求 SOP 对你看我们在大厂里面会发现所有的工作岗位都有自己的 SOP 你会发现所有的人都要遵循我们这个 SOP 去做事情那 SOP 这种东西它的好处当然是有它就像刚才我们讲过好处就是保证了我的下线对吧
就是我的工作的线一定是有保障的我整家公司的运行的最低水平我们都是清晰可见的有保障的能拿到那个结果但是它的伤线可能就太低了
所以说没有规则没有 SOP 往往可能会带来一个很好的上限反正这是我自己今天感觉就是 workflow 和 agent 的一点反正值得大家去思考的一个东西对 其实一加说这个是挺有意思怎么说呢就是你比如说你去招人的话那对于人这个 agent 来说其实你本身就是会对他有不同的职能有不同的期望比如说他是个研究员
你当然希望他给你一些惊喜但是如果他就是个车间工人你可能就希望他不要去做任何的自主发挥按照这个标准的这个 SOP 能把事情做完就好了那我们其实对于这个 workflow 也好还是 agent 也好可能希望也是一样的就是在某些场景下我们希望他稳定有下限但是在某些场景下我可以接受他给我惊喜那今天其实很多时候
Aging 它会让你先去做一下判断比如说 Gemini 的 Deep Research 你给它一个目标说你帮我去研究个啥东西的时候它首先会说我打算怎么怎么做给你看一下然后让你去选说你要调整这个计划还是说就开始执行你其实怎么说呢这么一个交互能够让你大概稍微能控制一下它但是确实过程并还是不是那么可控的然后结果可能还是会有一些惊喜的
所以我理解其实这两个东西呢看需求吧而且其实可以协同的我去查资料的时候啊有一个文章讲到说
有一个趋势是很多人认为说 AI agent 应该往更小更专业的方向去做就是每一个 AI agent 能做的事情都很专业精准且强大然后做成一个很完善的这个 AI agent 生态之后那上层还会有一层协作的这层那这层协作的层可以是不同的方式就比如说
Workflow 对吧它是去保下限的同时也是保效率的一种办法那你再套一个 AI Agent 说让他来做这个总协调总指挥那就可能更加灵活对吧可期待他的结果所以我理解这两个东西不是说我就是要二选一去选一个来用而是说你要看不同的场景你可以去
选不同的方式但是它其实不冲突它其实是一个调度的作用对你这个逻辑挺好的就是现在很多写代码的都是用 DeepSync R1 做一个 planning 但是执行的时候用 Sonic 3.5 3.7 去做执行没错对吧用这种方式然后来提高它的整体的那个就是效果可能会更好一些
我觉得依效刚才讲的那个公司的那个事类比一下 workflow 跟 agent 然后跟公司里边的 SOP 我觉得这个还真的挺有意思的对我觉得如果大家对这方面有别的思考或者说你有别的不同意见的话也可以在下方跟我们留言大家一起讨论一下对我还想到一个问题我感觉就是现在不管是 workflow 还是 agent
都不太好解决这个牛边效应的问题就什么是牛边效应啊这是其实是一个供应链里面的概念当我的一个需求方比如说我这边要采购 1000 个冰箱前面的那拨人可能他就会采购比如说 1200 个压缩机对吧这个压缩机再往前那些人可能会采购能造出 1500 个压缩机的那些钢材啊等等之类的就是会产生这样子不断循环的这种牛边效应对因为 LM 本身它其实也有这种幻觉嘛
对然后还有就是在每一集的这个调用过程里面其实它一定会存在信息损失对吧比如说当我链路越长的时候不管是 workflow 还是 agent 就我感觉说他们的效果应该会越来越差因为我自己没有去做过 agent 跟 workflow 的开发我不知道这个在现实中是不是真实存在这是我的一个设想我在想这个牛边选这件事对然后如果真的有这个问题的话有没有好的解决办法对
对现在去翻看我们早期我们自己的话比如 Portwise 你翻看早期很早很早的那些节目的总结的数据的时候和今天去对比就会明显的看就像你说的这个流边效应的问题这个信息损失一级一级的信息损失非常非常的严重对这个就是说它是一个肉眼可见的为什么那个时候的严重就是就是你说的这种流边效应带来的问题那我们可能那个
那个时候为了顾及成本早期的整个大圆模型并且成本也很贵嘛对吧那你可能去做的时候就是这样的我第一步要做一个 chapter 的总结章节的总结过后那你在去做总的总结的时候你可能就会直接用章节的总结去聚合然后再总结嘛对吧比如说你不太会用原始的信息
去处理每一级的数据就是你会用一种方式就是后一级能不能依赖前一级如果可以依赖那就先这样依赖吧当然这个是一定会有比如说信息损失的问题并且在一环一环里面就逐渐被放大的很大了其实到后面的话当你运行了时间越长就放大的很大这些其实我觉得奉便随着这些大运模型他们自己
在开发在训练的时候他们也知道开发者可能会遇到很多很多的这样的一些问题所以说比如后面除了像救命赖率生在国外便宜了过后除了成本下降成本下降是一个非常非常关键的问题你首先要知道它成本下降过后我可能会选择说我每一个环节都是独立的都可以在原始的数据上去做分析
我可能就不想让他有信息损失首先我有原始的数据然后同时我还可以把前面的那些数据所谓辅助信息加进来所以说其实每一个环节的信息还变多了往后面走的话对它其实是这样的一种关系那这种关系显然就必须要来自于那个大元模型便宜了这件事否则开发者你就是用不起了对
所以说后面就越来越便宜那你可以发挥的空间在信息的损失这件事情上就游刃有余很多了然后为了进一步去降低这种信息损失这件事比如说现在各大语言模型又支持了 contextcache 就是 cache 这件事其实当然 deep seek 其实做得非常非常的好
有像 Jumi 来的话还是以我们自己 Protobies 为例那我们可能经常要面对一个几个小时长的一个播客节目那那个 token 确实是非常非常的多任何一个节目可能就是几万十几万的 token 很正常那这个时候比如说你先去做一个章节的总结然后再去里面提取 QA 或者做 mindmap 其实每一步
如果你都想在原始的这个信息上去做分析那你肯定就是要付出很多很多 token 的成本在里面那这个时候他们就开始推出了这种 context question 的这种技术让你可以去把你的原始的大的 transcript 文本给缓存掉
对这个东西只要缓存下来你可以记忆这个缓存每次就去不断的去分析就像对话一样你可以记忆这个缓存去对话了那这个缓存过后的这些 token 比不缓存要便宜很多很多了又要便宜很多很多
我们今天所有的人在聊成本的时候都是聊的不缓存的成本所以说只要一缓存过后还会砍掉好几倍的成本所以说这个时候你可以在上面发挥很多很多的事情了就像我们今天就已经完全是走 cash 的方式所以我们做所有的任务都是在 cash 上原始信息上去做分析甚至还加入前面步骤产生的中间结果所以它信息量其实本质是变多的
对但要达到这样的一个效果信息量变多其实还有一个东西就是我们说的那个商下文要变大嘛对吧就是 Jumilite 在这一方面很有优势就是 Jumilite 一上来就是百万 token 的商下文这个已经超越了很多很多的大元模型所以说他在做这件事情上解决这个信息损失这件事情上就会方便很多很多对当然今天其实有很多很多的 agent 方式包括像 Miles 也好还有 AltGBT 这些
为什么 AutoGB 在早期大家都觉得它成本贵对吧就是这些 agent 方案包括我们刚才聊的我现在我们期望的 agent 的方式比如自己做 planning 自己做规划然后自己再反复执行拿到一个希望的结果其实所有的这些方案
他们都是在我是觉得他们都是在燃烧 token 反正都是忽略 token 的成本不计对就是疯狂烧 token 把这个 token 的数量烧上去了过后那个信息自然就不损失了对我觉得这是一个很关键的就是今天有很多很多的产品对但这个不是我们一刚开始的理念对我们从一刚开始在这件事就是我们其实可能很多时候在
某个任务上效果他做的可能不是最好的但是我觉得我们一定是在效果和成本的平衡上做的最好的对所以说我们的理念一上来一定不是燃烧 token 对所以说我觉得这些吧组合起来可能对你所谓的这个流变效应是一定程度的解决的对
对你刚才讲这个燃烧 token 这件事就是因为 minus 它第一天火了之后第二天他们举行了一个小的一个发布会也好见面会也好有一批人在里面然后他们在里面就披露说 minus 的一次任务执行然后要花大概两美金对啊这个就很贵很贵了对然后我听了这个之后我就在极客里面发了一条我说一次执行要两美金的话我就在想说 minus 到底要怎么赚钱就它的商业模式到底是什么
我想不清楚,谁连你给就好了嘛。对,然后我在下面提说,
我说 minus 这件事到底是 to b 的还是 to c 的还是 to vc 的哈哈哈哈现在看起来 to vc 可能是最成功的啊对回过头来刚才一笑有在提到说 auto gbt 嘛对假如以 minus 为通用 ai agent 的标杆的话那 minus 跟最早在 2023 年 auto gbt 现在 minus 跟之前的这些框架就本质上有什么不同吗它进步在哪了啊
首先我自己是觉得 Manos 是并不通用的虽然他自己是觉得自己是一个通用的 agent 因为我觉得通用 agent 的话最终还是要我们之前可能一直说的 AGI 的那种吧
可能吧才能称自己为通用吧当然这个不是重点了我们就忽略吧这个可能也就是一个营销的 keyword 而已那回到 AutoGPT 然后微软现在也有 AutoGN 等我觉得这些东西可能他们确实还是更停留在
框架层面你可以借这些东西去做很多自己的事情出来对但 minus 其实确实人家已经是一个面向终端用户的一个产品了我觉得他们可能还是不太一样的但如果我们抛开产品这件事情不谈只回到从工程
上面来讲的话我的观点是肯定是没有质的突破的就是没有那种本质性的工程上面的突破我们不谈那种大圆模型只谈软件工程的话我觉得也没什么突破对它本质上还是属于一个在应用集成上我觉得做得挺好的一件事情对
当然我自己也比较喜欢他们那个 planning 然后在执行 planning 的整个过程的那个透明的那个程度的设计我觉得这个东西挺好的让你看见嘛我看他们最近也有在其他博客里面也有讲到这个点他们专门就是让你看见这件事对那这个事情它其实和那个 deep seek 让你看见它的 thinking 的过程其实是一样的嘛因为早期的 GPT-OE
他的那个 thinking 过程不是不让你看的吗但是 DPC 做了这个不是当时大家也觉得说这个东西好啊对吧能够看到他是怎么在想的对其实怎么想的就和你在怎么做 planning 这些其实是他们是有点一样的味道在里面对但是这种设计其实我发现在我们传统的整个软件开发里面其实是很少见的你不太会把内部的状态直接暴露给 N
end user 我觉得这个是好像我们不太会有这种情况出现的对这个我觉得是值得今天所有的 AI 的应用去参考的一件事情因为我一直在想就是今天大家为什么除了程序员可能程序员有时候对 agent 这种概念确实不太感冒觉得它就是造的一个概念
就像 GitHub Compiler 的负责人,那他显然也属于程序员开发者这个范畴嘛,他就很讨厌这个概念。我觉得可能对于这些技术人员,大家可能对这些概念确实没那么感冒,但是从产品的传播的角度,从自媒体这些角度,他们可能就很感冒这个词,觉得 agent。
他觉得说一个 agent 的话就是因为在他们的那种可能人的那个意识里面会觉得 agent 是一个智能体有点像人一样至少造出来的是一个人工的一个智能体那我要能够实实在在的看得见摸得着我才会觉得它是存在的就是会有这种感受它和传统的那个软件可能还不太一样传统的软件你就是给它一个界面有功能你可以操作就可以了
但是今天 agent 它好像是一个活生生的东西你可以理解我们会认为它是一个活生生的东西甚至它实际上就是一个传统的程序好像也没什么太大的差别如果你从这个角度去思考的话觉得说 agent 它是一个智能体是一个活生生的一个内人的东西的话
我能够看见他看见他正在做什么在 thinking 在 planning 在做什么动作这个就感觉他真的存在一样了可能就会有这种感受吧所以说我觉得这个让他拥护看见反正有点意思当然这可能是我自己的这座一个大脑的意识在这里面存在
这个确实让我想到另外一个东西就是以前我们其实也在说一个好的产品它可能不只是让你好看好用因为我们在传统的产品里面其实我们好用其实是基础门槛对吧你必须要做得好用有价值对然后其次然后你的产品做得比别人漂亮又更好一步了对然后大家说你的产品如果还对用户来说挺好玩的
那里就更好了对所以我理解像 minus 这种看得见它可能就有一点点的那种好玩的属性在里面那你说它有什么用吗其实它没什么用对吧拥触就没有那么大肯定赶不上你这个产品本身提供的能力那么有用对那可能就是稍微好玩我能够感受到它的存在
我比较同意一小说的这个 Mainas 的这个说法就是他并不通用甚至也不专其实就像不同的人有不同的专业性小而专的这种 AI 进程能在更少的资源要求下在特定领域拿到更好的结果
但这个专业性今天肯定不是说你专业查天气专业做表格这个程度 Mainland 现在能做的事情我觉得其实是所有 AI 都应该具备的基础能力因为你去看他做的动作的话其实无非就是理解目标然后制定计划然后查资料查数据然后就使用数据那我觉得任何一个 AI 就都应该是一个这样的过程当然今天就像一小时候他把这个东西拿出来给你看到了那给了很多人就是一个比较
比较直观的概念说 AI 可能是怎么做事情的小小的震撼但是这个视觉的震撼肯定是要比听别人说这个东西应该怎么样要高得多嘛这也是为什么他忽然就对话爆了就火了算是火出圈了嘛火出技术圈的这种
是原因但是他做这些事情呢我觉得还没有涉及到真正的专业信仰的差异就比如说我希望 AI Agent 帮我开发一个 iOS App 或者说帮我去渲染一段就是按脚本去渲染一段 3D 动画这个事情就别说 Manus 今天没有任何一个 AI Agent 能够把这个事情做得足够好那更不用说 Manus 的通用去覆盖到这个事情上其实肯定是不够的在我的探机大脑的概念里面啊
人因为脑容量和寿命的限制其实每个人能做到的专业精通的领域是有限的那我觉得 AI 其实也同样受限它受限于算力和成本那你可能算力无限成本无限那一个 AI Agent
可以真的通用去做到所有的事情但是它终究会受限到算力和成本只不过这个限制是随着 AI 能力的提升随着这个硬件的提升可能在很短的未来内就大大超过我们的碳基大脑但显然那时候我们对专业性的要求也会变得更高今天我们对专业性的要求我们对比如说你是一个 LSF 开发专家的要求和
以后这个 AI Agent 变得特别强之后我们对这个 AI Agent 你是一个专业开发 iOS App 的 AI Agent 的这个要求肯定也是不一样的所以我是挺认可 AI Agent 应该往专业方向去做的这么一个看法的然后也包括说像 Manas 这样的它其实可能你可以把它理解为它是一个专业的
调度 AI agent 或者说专业的管理 AI agent 这样的方向是 OK 的对吧但是你说它真的是一个通用 AI agent 吗我确实觉得说可能真的到哪天 AGI 要到来然后算力和成本要无限你才能够真正的
到这么一个理想的概念对你讲这个专业型 AI Agent 其实现在像 WindServeWindServe 里面 Cascade 然后 Cursor 里面的那些那些东西其实他们自己也把自己叫做 Agent 他自己也在规划说到底应该怎么写这段代码对吧还有包括就像 Bot 还有那个 Lovable 他们本身是生成前端的其实他们自己内部其实也有一段自己的 Agent 相关的一些东西对我觉得这些专业 Agent 其实现在也赚了大钱了
对吧但反倒同用 agent 其实我倒觉得说其实现在甚至可以把 minus 类比成比如说 deep researchdeep search 对吧等等这些东西它其实更多可能查资料上比较比较有用一些反倒说我让他去真实做点事的话可能他没有那么有用比如说可能生成一个 PPT 但现在其实 Cloud Sonnet 其实他自己也能生成 PPT 对吧其实大家都可以做 artifacts 对吧等等都可以对我自己还挺认可说 agent 再往专业方向去做一些的对
那回到最后就回到我们自己啊就说因为今年的这个 agent 的这个概念嘛也是因为 minus 可能突然爆火了一下包括其实今年各种各样的 deep search 工具都出来了对吧你觉得说像我们比如就像 podwise 或者说就像我们硬厉害客我们应该去拥抱 agent 吗还是说其实现在我们用 workflow 来实现实现功能就挺好的对就这个你们有什么样的想法吗
我的想法其实很简单都是很务实的我觉得做应用的话特别是小团队我觉得说你做应用你一刚开始就是要遵循简单原则也就是怎么快拿结果怎么简单怎么来就像你刚才在 workflow 或者自己随便调 API 还要去做这种复杂的 agent 的模式的话那一定是你自己随便调个 API 来得最快的这个一定是的产品在初期阶段
一定是这个模式我觉得是最简单的方式然后大家也可以去看一下 Anthropic 关于 Build Effective Agents 的总结里面其实回答了这个问题说现在市面上有
有一些框架他甚至把框架名字都点出来了我相信这个东西对那些框架团队也是一个打击比如什么 Long Graph 来自于 Long Chain 的框架等等等等还有很多框架然后他的结论是并不支持大家去用这些框架我觉得他也是真的是在生态里面也是不顾及这些人的颜面反正就是那种他就说他给大家的建议就是
你只需要简单的去调他们的或者这些大语言模型的 API 然后就可以很容易的去做到他给出来的今天的这些 LM Application 的
这些应用的这些模式可能就是掉一个 API 就很容易的去实现了对没错因为今天 AOM 大家去如果用那种流水线 Pipeline 的方式去理解的话那这些 AOM 它的模式其实很简单要么就是拆成了一个一个的 task 的步骤然后串联执行对吧要么就是并发的
并发执行要么就是有个反馈循环我生成的内容不好然后给你一个反馈让你重新生成再加上工具的话这种 React 的模式就是说我能够去执行一个 web 的工具拿到结果就是 Gitweather 刚才我们聊的所以它的模式其实不复杂就是对今天大多数的 AI 应用来说的话我觉得它可能
就是这样集成到你的应用里面它就依旧能够看到最保障的效果对所以这件事情我个人从开发的角度还是比较支持大家一刚开始这样去做的对
但是还是那句话我非常相信随着你的代码越写越多你会发现你自己逐渐可能会出现一个框架的样子对这个我相信它一定会演变成这样的一个形状形态像我们自己也是越写越写你就会发现说你要管理的东西比如要管理很多的 plumpt 你的 plumpt 可能是动态的渲染了
那这个事就涉及到你一定有一个东西在管理你的 prompt 然后最后你会发现其他的框架里面他们也有一个管理的 prompt 只是管理的有没有你那么顺手而已然后你会发现要管理商下文就像我说的你可能在 pipeline 一个流水线或者说叫 workflow 里面你可能前面生成的一些数据你希望作为后一步数据的辅助的一些信息再去做一些
LM 相关的事情的时候那这个时候你可能就涉及到很多的上下文的管理那这个时候你会发现你也有了一个 memory 的概念就和那些框架是一模一样的最后你要调用 tool 你发现你定义的 tool 刚开始定义一个两个还好最后当你想定义 10 个 tool 的时候你会发现你也有了一个 tool 管理的模块
反正最后你做起做来你就会发现其实这个模式你也有了大家我觉得反正这个东西就是这样发展了对但是我觉得还是这句话对于 Indie Hacker 来说你可能刚开始去做应用你就是从最简单入手就可以了对如果你真的效果好对吧你的产品在市场上效果好那你长期的要去维护它那它最后怎么发展你最后是用其他的框架充血还是你自己变成了一个框架的样子我觉得这些都是
无关紧要的事情了因为你如果成功了的话对吧在不成功之前简单就是最好的最快的当然除非你是图 VC 的我需要去构造一个很 fancy 的东西然后一个很好的故事那这个时候可能这种我们说的这种很暴力的直接掉一个 API 掏个壳你就是告诉别人我就是掉了一个 API 掏了一个壳对吧
就完成了这件事儿那这个确实怎么听它也不翻谁对吧怎么听也没有故事可讲对所以说你如果要吐威胁那可能就完全不一样了对嗯
了解我自己现在有一个感慨就是你看大模型这件事从 22 年年底开始出来 3.5 嘛对吧到今天看似两年多的时间其实如果从 workflow 到 agent 的这个转化的话其实它也经过了一些就是有可能你两年前写的代码跟今天你要做同一件事写的代码可能会差别非常大这里边包括 LM 本身的进步对吧包括 context 的大小
对吧以前很小现在很大包括 agent 的能力包括 planet 的能力等等之类的就是以前我可能需要写很长一段 prompt 现在我可能调一个 agent 也好干嘛也好然后我让他自己做 planet 也好其实我可能都不需要写 prompt
或者写一个很简单的 prompt 都可以其实事情的发展还是挺快的今天跟两位聊了很多我自己反正也学到很多然后也解答了我很多关于 agent 的疑问我觉得如果大家对这个话题有什么自己的想法也欢迎在下方给我们评论区留言然后跟我们讨论那我们本期节目就先到这里吧我们下期再见拜拜拜拜拜拜
以上就是我们本期播客的全部内容感谢大家收听也欢迎大家踊跃留言如果你喜欢我们欢迎点赞并分享给感兴趣的朋友如果你在用苹果播客收听也希望你花几秒钟给我们一个好评这会让更多的人了解到我们要是能再点击一下订阅那就再好不过了我们下周见