We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode Agent 开发的上半场: 环境、Tools 和 Context 如何决定 Agent|对谈 Sheet0 创始人王文锋

Agent 开发的上半场: 环境、Tools 和 Context 如何决定 Agent|对谈 Sheet0 创始人王文锋

2025/4/19
logo of podcast 42章经

42章经

AI Deep Dive AI Chapters Transcript
People
王文锋
Topics
@王文锋 :我认为Agent是模型基于环境反馈去使用工具的程序,包含模型、环境反馈和工具三个关键要素。这波Agent浪潮与以往不同,因为它真正解决了实际问题。Agent的发展主要源于底层模型的进步(特别是OpenAI的出现)和Agent工程的突破(构建合适的context)。Context定义了大模型需要利用的所有信息,包括代码库结构、原文件、API、用户输入等。Agent与以往RAG等方法不同,它强调信息来源是通过自动化方式获取的。Function Call、MCP、A2A等方法都是为了给大模型提供更好的工具使用方式,让其更好地采取行动。Agent的工具使用方式可分为代码方式和模拟人类方式,两者并不矛盾,也可以混合使用。即使SaaS软件不支持MCP,开发者也可以通过MCP标准自行包装其开放的Open API;如果SaaS软件没有开放Open API或SDK,则可以使用视觉方式(模拟人操作)来调用。视觉方式虽然准确度不高,但成本低,速度快,token消耗少。使用浏览器方式的成本更低,并能更好地营造用户信任感,让用户看到整个过程。AI Coding是大模型的灵巧手,是其在没有现成工具时的补充工具。未来Agent市场将长期处于通用Agent和垂直Agent并存的时代。强化学习是Agent概念的基础,脱离强化学习,Agent概念就不成立。强化学习中的状态、行动和激励信号分别对应Agent中的Context、Tool Use和结果评估。Agent创业公司需要将产品设计成一个环境,定义好状态、行动空间和结果,才能设计激励信号,让Agent自我迭代。好的Agent产品应该尽可能地减少用户的认知负担,让用户无需动脑即可使用。聊天框是Agent最好的交互形态,因为它能最大限度地提高用户交互的自由度。判断Agent好坏的关键在于其交付的结果(delivered result),而非其功能的多寡。AI Coding可以保证每一步操作的准确性,避免因单步错误导致最终结果错误。Agent开发者需要解决两个信任问题:相信大模型和让用户相信结果。预测Agent未来发展,需关注Context和RLM的突破,以及模型成本的下降。判断Agent公司好坏,关键在于其团队是否理解强化学习,以及如何设计环境反馈的激励信号。选择Sheet0而非其他Agent工具的理由:100%准确率、稳定性和数据完整性。 @曲凯 :对Agent的理解和分析,以及对Agent未来发展的思考。 [object Object]

Deep Dive

Chapters
本节探讨了Agent的定义,并比较了当前Agent热潮与过去两年的区别。嘉宾王文锋认为,当前Agent能够真正解决实际问题,而过去更多的是玩具。这种变化主要源于底层模型的进步和Agent工程的突破,尤其是在构建合适的Context方面。
  • Agent定义:模型基于环境反馈使用工具的程序
  • 当前Agent能够解决实际问题,过去更多是玩具
  • 模型进步和Agent工程突破是主要变化
  • Context定义:大模型利用信息总和

Shownotes Transcript

今天北京风特别大感谢文峰今天还跑过来录着几播客

正如北京的大峰一个非常尴尬的转场今年 AI 最热的大峰现在就是 agent 了所以文峰正好做了满长时间 agent 你可以跟大家介绍一下自己大家好我是王文峰是一个做 agent 两年的一个程序员出身的创业者同时也是徐老师的粉丝然后我们在做的一个产品是 data agent

现在大家都在讲各种各样的 agent 但 agent 到底怎么定义我觉得最好的定义是 astropy 的一个定义 astropy 的定义的话是说 agent 是模型基于环境反馈去使用 to 的一个程序

那这里面的话其实我觉得有三个点需要去拆开说一下第一点是模型那这个大家其实是最容易理解的第二个的话我觉得是环境反馈这很关键第三个的话就是 to 就是说 agent 我们需要去 take action 那其实通过调用 to 的方式去实现所以你怎么看最近这波 agent 的热我觉得这波 agent 跟过去非常不一样的一个点是这次 agent 真正的是能够去

实际的解决问题了像上一轮 agent 大家讨论的时候其实是在 23 年的 4 月份当时代表性的产品是 LGBT 但当时呢它更多的可能是一个玩具它并没有什么实际能解决的一些问题但是经过两年的发展 agent 现在真的已经落地了而且在实际的工作生活场里面给大家带来真正的价值这两年主要的变化就是什么

我看到的有两点第一点的话确实是底层的模型有了非常大的一个进步尤其是 OE 出来之后给 Agent 带来了长次位能力主要这个就是因为 RL 深度学习在这个角色上的使用对吧

对我觉得这个是一部分还有另外一部分可能是大家没有关注到的一个点就是说其实 agent 工程这个事情上面也有非常大的突破就是说是怎么去给 agent 更好去构建一个合适的 context 然后去解决问题这个我觉得是从工程这一侧或者说产品这一侧的一个进展

所以你刚说第一点是模型的进展对第一点是模型第二点是 agent 的 contextcontext 这个怎么理解 context 其实是定义了所有大模型需要去利用的信息的一个总和嗯

比如说呢比如说以代码为例的话那它包括了整个代码库的结构代码库的原文件代码还有整个代码库里面我有哪些 API 可以使用包括人类的输入其实这些都算 context 比如说呢可以举一个具体的产品的例子其实每家的产品的 context 不一样我以我们产品的为例子的话其实我们产品是一个帮助大家去收集数据分析数据的一个 agent 对于我们而言我们的 context 其实就包括了

网页还有是我们帮用户设计过来的数据表格还有包括说用户他想要一个什么样的数据就是那句段 prompt 还有包括我们分析数据的时候生成的这些 sql 其实都是 context 其实 context 是比较琐碎的东西大家加在一起一个整体我把这些整体然后去一起输给大模型让大模型来判断出来说我应该给用户一个什么样的一个结果

我明白但我在想这些过程当中的信息被留下来再使用或者不管是加到 prompt 还是 reg 里面这个不是之前本来大家就都应该是约定俗成的一套做法其实这个核心是你的这些 context 从哪来比如说

我刚才举的例子网页是吧网页里面它其实网页一般有很多无关紧要的信息首先第一点我怎么把一些我关注的信息我抽取出来这是一部分另外一部分的话比如说我要生成 C 口这个 C 口是怎么准确的我需要去校验我校验的话我需要利用到数据库我一条 C 口能够执行成功其实这些信息是需要以某种自动化的形式去提炼出来

以前用 RAG 也好 还能说其他什么办法也好其实这些信息主要输入来源是人 Agent 更强调的是我的这些信息来源是我通过某种自动化的方式获取到的我觉得我们先把一些基础概念快速的给大家介绍一下因为大家经常听到很多概念对吧比如说什么 function code 包括 mcp 包括 Google 前两天出的 A2A 然后也有这种所谓的 computer use browser use 等等各种各样的说法

就在你看来你觉得这些是怎么分类或者有没有什么优点其实刚才曲凯老师你提到的像 Function Call 也好像 MTP 也好或者 A2 也好或者 Bright Use 这些东西也好它们其实都是在解决一个事情给大模型提供更好的一种使用工具的方法让大模型更好的去 take action 这里面的区别是什么其实你可以理解 Function Call 是最早 OpenAI 提出来的让大模型使用工具的一套方法

可以理解它是个 0.1 的一个版本然后 MCP 在这个基础之上它又更近了一步我们可以理解它是大模型使用工具的 0.2 的版本但是 MCP 非常大的作用在于它其实类似于说统一度量衡的一个事情因为以前的 function count 那个阶段大家使用工具的标准是不一样的像每个国家它可能有自己的这么一套度量衡的一个方法我到另外一个国家之后我就得重新学一遍

但是呢 MCP 把这个事情做成标准化了那这个时候相当于有了一个说放置赛都接准的一个方法大家都可以去调用任何人的工具那其实相当于这个事情的门槛一下子降低了然后 A2A 其实我觉得 A2A 没什么意思更像是一个 KPI 工程因为 A2A 它自己定位自己跟 MCP 的区别是说 MCP 它只能跟

其他的 tool 或者说是 APH 交互但是呢 A2A 它说的是我可以 agent 与 agent 之间交互其实从我们开发者的角度来讲这个事情是没有区别的因为 agent 其实你也可以定义成一个 tool 就是说它可能有个调用的那个函数入口那个东西用 mcp 的包装下

他也可以被其他的 agent 去教育可以纳入 mcp 的范围之内所以从这个角度来讲 a 推我觉得是属于强行一造了一个自己的一个概念然后找了一堆合作伙伴过来去推这个东西我觉得这本账是一种标准快选权的一个争夺但我觉得从工程师的角度来讲我们是更喜欢 mcp 的 a 推没有提供性的东西明白

然后 Brother Use 他其实强调的是说我把浏览器这个事情当作一个工具我让大模型去调用可能说全世界有成家三万的工具那浏览器可能是最重要的工具的一种明白我现在听起来我感觉其实整体是分成两派吧一派是直接用代码来解决问题我理解不管是 mcp 还是 AA2A 等等的东西他是用代码去解决问题然后另外一派是模拟人去解决问题是吧

不管是 Community Use 还是 Browser Use 其实它是通过视觉识别加上一些 RPA 的方案去解决其实不矛盾你也可以用一 MCP 的方式去进行所谓的 Browser Use 怎么做到因为实际上我们是怎么去用 Browser Use 的一种方式其实就是

纯粹通过普向 GY 的方式就是说我腿转出来某一个坐标然后可能把鼠标移到这个坐标上面我点击一下我说我输入个什么东西但实际这个方式是远远不成熟的就国外有一个 Adapt 的公司其实是在 23 年 24 年非常火的一家公司但实际上公司已经死掉了就是因为这个事太难了

所以说现在大家去用 browser 的时候其实也是通过浏览器的 API 把它包装成一个类似于说 mcp 的 tool 然后我再通过代码的形式我去调用这个 browser 明白明白就是其实它前面类似演了一场戏给人看背后还是用的那些因为 mcp 跟 browser 就其实两个叫做正交的两个东西就是互不影响

但现在是不是有个问题就是说因为毕竟很多公司没有兼容 MCPA 这些东西然后甚至于说往后走可能有些公司为了保护自己的用户和数据它也不会兼容

所以就变成有些产品是必须要使用真的 browser use 真的是模拟人操作的来去完成我觉得首先是这个样子的这儿巴仅去使用 MCP 的标准姿势是什么假如我是开发者我现在发现我想要用 MCP 去用某一个 SaaS 软件这个时候我其实不需要 SaaS 软件本身去支持 MCP 所以我不需要它已经给我提供了一个 MCP 的一个接口了

因为 MCP 是个标准化的东西我自己可以按照这个 SaaS 软件它开放出来那些 Open API 在 Open AI 之上包一层我就可以把它当成一个 MCP 去用了所以说前提在于说我这个 SaaS 是不是它已经有了一个 Open API 因为 Open API 在国外的软件生产来讲基本算是一个标配了基本上所有的 SaaS 都会有不但国内还都是没有的对所以这个问题就是国内海外是非常不一样的

如果说这个 SaaS 产品或者另外一个软件产品它确实没有开放出来一个所谓的 OpenAPI 或者一个什么样的 SDK 的话这个时候确实是没有办法以代码的形式去用但是你也可以这个时候尝试着去用视觉的方式就是我们前面提到了我用浏览器相当于我把浏览器的截图我传给大模型和大模型判断上面的一些交互元素把坐标算出来然后我再通过鼠标键盘的方式去控制

这两种办法就是 API 也可以然后 GUI 也可以就取决于说在什么样子你下面更高效对所以简单可以得到一条结论就是说如果未来 MCP 或者后端各种接口支持的话其实它直接调用就 OK 那如果它不支持的话那就只能通过视觉和模拟人去使用电脑的方式来去解决这个问题

对而且我觉得这边还有一个点的话是每个的 agent 他可能想解决的问题会不太好所以我觉得具体说哪个部分占的比例更高一点可能是需要 agent 咖根据自己的需求实际的配比另外一点我觉得视觉的方式虽然说现在包括稳定性准确度没有结果那么高但是它有个好处是它的成本低

因为我们自己的产品其实这两种方法都用了实际体验下来你给他截个图然后让他去判断其实速度要更快的而且 token 消耗量也会很少至少会少一个数量级的这么一个情况问题是 GUI 的生成的结果有些时候会不准确比如说我图片上有一个提交表单的按钮很多时候可能会去把坐标位置算错明白

所以你看我前几周在美国的时候就有一个也是很专一的做 agent 钻法相关的人问了我一个问题他说他非常不理解为什么 minus 要用浏览器来做这件事情他的理解是其实后端的代码什么都可以接通就直接实现了如果是你的话你会怎么回答这个问题因为我看你们的产品里面其实也用了类似 minus 那套逻辑对吧

我觉得这边其实会有两个视角可以来去回答一下这个问题一方面就是从技术的视角一方面是从产品的视角技术的视角我简单说一下就是用浏览器这个方式在成本上来讲会更低一些对另外一点的话其实让 agent 实行结果还有一个很重要的一个点是在说这个结果我用户是不是可信的我们再去让用户使用 agent 的过程当中怎么去给

用户营造这么一种可信的氛围感我觉得这个非常关键其中一个非常重要的一个手段就是说我让用户可以全程看到我是在怎么去帮你完成你这个工作让他能看到其中的每个细节而且这个细节是以他能懂的方式去 get 到那浏览器这种天然来讲对于人友好的这种视觉化的呈现方式是要比代码这种看起来黑乎乎的一个窗口来讲要更生动更直观的嗯

Devon 算是哪一种方案 Devon 其实就是纯 coding 的方案 Devon 其实都有它也算有 computer use 对然后 manus 是典型的也是 coding 和 browser use 结合的对然后最近那个 gen spark 新出的我不知道你看没看我看了一些对你觉得它是什么方案的跟 manus 是很类似吗还是怎么样稍微会有点不一样 gen spark 我自己跑了些任务其实我没有看到特别多的

像 devin 或者说是 mass 这样就是有一个肉眼人能看到的浏览器或者说是感觉他是在后端去对他应该后端也会用了一些网页的 ap 但没有把这个事情包的灵乎

所以我觉得他可能还不是一个我心目当中的 agent 但从用户视角来讲你反正最后帮我解决问题就好了我为什么要 care 说你到底有没有在哪跑一个什么东西或者他多 fancy 的在像人一样在使用电脑或者使用浏览器这是一个非常好的一个问题从我的视角来讲其实我想举个例子就比如说薛老师我们俩是同事我们两个之间应该怎么去建立信任关系我觉得更多的一个办法就是假如你给我分配一个任务

你能看到我是怎么做这个事情的以及说你后面知道我大概是一个什么样的思路就相当于你足够的了解我之后你才会给我产生信任我觉得这个点是 make sense 的就是包括像 Mance 这种我觉得其实一个核心的点在于说大家觉得 agent 的这个事还是对 ID 不靠谱所以我需要在给你看到过程当中的东西然后我需要说人不断的去 invoke 进来对吧你要回答他的问题就是让人时刻感受到你是在

掌控一切的因为跟人一样大家其实都会有这种不安全的这种感觉那怎么去给人建立起这种安全感的这种边界其实把一切做透明是很关键的对但这个在我自己用 mind on 的时候就也会觉得他也有个缺点就是有时候他跑着跑着他提了个问题我可能没看到我就也没管然后我本来等了可能半小时小时我觉得他要跑完了回来一看可能还在第二步问了个问题其实这个就是一个 UI 上还是可以去优化的一个点

另外一个这个事情的话其实我觉得也是可能是他们现在极端性的一个点吧就是后面比如说他给你的邮件或者给你的短信或者说给你平时工作用的 IM 打通之后其实你会以一个更容易去看到的方式去收到这个通知所以我觉得这不是什么大问题

所以总结一下就是其实应该所有的这些不管是什么 use 也好还是什么 coding 也好都是当下 agent 可以用的工具对然后根据不同的场景好像目前来看大多是一个组合的方案来实现一些东西是的然后最终你觉得

比如说 AI coding 和现在大家讲的 agent 最终是不是一件事情因为至少过去半年里面就是市场上最热的拿到最多钱的两条隧道就是 agent 和 AI coding 然后本来这两条隧道我觉得是分别的两件事情但越看这两条隧道好像越未来有可能走到一起

因为现在反正很多 agent 也在用 AI coding 的解决方案然后 AI coding 里面也有在讲说其实 coding 这个东西是整个互联网整个一切的基础设施这两天我忘了看到哪个新闻说 coding 可能也是未来什么 AGI 的一个基础理论来说也确实是这样比如说我举一个可能不那么恰当极端的例子你说 browser use 对吧我可以让 AI coding 自己做个 browser 然后自己用对理论上是的只是说服务用的问题经济性的问题还有是时间成本的问题

AI coding 我认为其实只能说是大模型的一个 tool 这里面其实我觉得有两个点很关键第一个是协作第二个是服用现在大家说 AI coding 讲的就是说我现在有一个问题然后把它拆解拆解完之后我对每一个子问题可能我都去写个程序把它跑起来像我这个事我是从头到尾去做的但实际上这是一个非常

低效且消耗成本的一个事情那其实我们去看在现代化的软件开播当中我们非常强调说我怎么去服用本账其实是为了让这个事情更高效所以对于 agent 而言

最优的一个选择是我现在解决一个问题是我首先看我手边有没有一个我直接能用的工具当假如说 agent 找了一圈之后我现在没有一个我可以直接拿来用的工具这个时候其实他可以在退化的时候

我用 AI coding 的方案我去现场造一个我自己独特的工具出来所以我觉得他们两个之间是一个这样的关系所以你觉得 AI coding 可能是对 agent 的一个补充对就是一个很强有力的一个工具对然后另外一个问题就是我自己是觉得当下这个市场大家对于 agent 的

讨论和理解跟两年前大家对于大模型什么的是有点像的当时大家在问说会不会有一个通用的 AGI 模型还是会有垂直的模型还是说很多创业公司要做自己的小模型等等现在其实大家也在开始讨论说未来是通用的 agent 还是垂直 agent

我不知道你怎么看这个问题我觉得我们其实现在处于也将长期处于一个所谓的 trade agent 的这么一个时代对我最近其实非常喜欢去举一个例子就是比如说做饭这个事就很多人都会做饭但大家的区别是说假如说曲老师咱俩做饭可能就是我们把手机拿出来把菜谱软件打开然后对着菜谱我们做顿饭但可能更好的 agent 是说他就像五星级绝电的一个大厨

我们能说我们跟那个五星级的大厨是一样吗不能核心区别是因为人家做的那个饭可能从美观程度从这个美味程度来讲都超出我们很多倍所以说人家是专业厨师我们可能就是一个会做饭的一个普通人那

那讲回来就是今天我感觉至少从资本市场来讲当你说你要做个 agent 大家就会尤其想问说那你有没有好的算法的人你后面要怎么做 IL 怎么做差异化那从你的视角来讲你觉得 IL 这件事跟创业公司的关系是怎么样的或者说 IL 跟 agent 之间的关系它最后到底怎么应用的

RL 这个事情呢我觉得有几个点比较关键首先是 agent 这个概念就是从强化学习里面出来的所以不是说 RL 对 agent 多重要而是说你脱离了强化学习这门领域你 agent 这个概念它就不成立了

所以说我们做产品的人一定要追根溯源的看最早 agent 他们的定义在强化学里面是怎么定义的在强化学里面 agent 的定义其实主要有三个关键的东西第一个就是状态第二个就是行动然后第三个就是激励信号怎么去理解呢实际上状态其实就是我们前面一直在强调的 context

就是说我在经过了 rong 按步骤以后我当前这个 agent 是在一个什么样一个情况这个地方去包括了可能是说他的记忆他现在看到的东西然后 action 其实就是 to use 我现在有了一个判断了以后我怎么把 action 实际的去执行它其实就是通过函数调用的方式去执行因为函数接口这个东西就是代码与数字世界交互的这么一个媒介

所以这个是 action 另外一个就是最后激励信号怎么来理解其实就是说我现在 action 通过含水调用的方式执行完了这个时候我需要做一件事情来判断是说这一步我做完之后我的整个的状态离我想要达到的目标是更接近了还是更远的这个其实就是一个 1 跟-1 的这么一个区别就是说我需要去通过这种激励信号我来判断我应该是往左边走还是往右边走

对于创业公司来讲非常关键的一个点是你如何去让你的产品变成一个环境因为你只有有了环境你才能够去描述说强化学习里面的状态是什么以及说你可选的行动空间有多大这时候就是说你程序里面我 flow 这个事情就是说你有多少的节点

它其实是由你的这个行动空间去决定的以及说你怎么去定义你的结果那为什么一定要把结果定义好呢因为只有把结果定义好了它才能收敛只有我能收敛你才能够让大模型去判断是说我一个行动做完之后我离你的这个目标是更近了

还是更远这个时候你才能够去设计这么一个激烈信号不断的去让你一步两步一轮两轮三轮的去让 agent 自我迭代直到实现了那个目标所以说具体的建议我是建议所有的 agent 的开发者或者说产品设计者他们去看一下《强化学习之父》沙特写的那本书

你只有看完这本书之后或者说有了这样的一个 mindset 之后你才能够在设计产品的时候不断地去思考不断地去调整去定义你是一个什么样的 environment 在这个 environment 里面你的程序之间的状态是什么样子的然后你的行动空间有多大通过这种方式我觉得才能够去

定义出来一个好的能够自我迭代然后能够去基于动态的情况然后去不断地修正自己的路径最后能够实现用户目标的这么一个程序出来所以说我觉得就是你不理解强化学习你就很难理解 agent 到底是什么你很难理解 agent 到底是什么你就很难去设计你的产品长什么样子

对然后我们捋一下你刚才说的那几个点第一是状态对第二是类似于行动对第三个是奖励函数对我觉得第二和第三个其实是相对好理解的因为哪怕不是 agent 领域里面包括所有的模型领域里面大家在讲说其实最重要的是 evaluation 体系的搭建对就评估体系你这个东西的标准等等这个东西肯定是特别重要的一部分

然后 Toyots 其实我们刚才已经讲了很多了不外乎在现有的环境之下我不管是用 workflow 还是用 agent 还是 agent 的去使用 workflow 还是用各种 browser use 还是用 coding 反正各种方式都上怎么样能把它解决好然后第一个它的状态跟环境或者说 context 这件事情从这个角度来讲 IDE 肯定是一个特别好的环境

但 Mindless 那种其实浏览器你很难讲它是一个读好的环境相对不是通用的一个工具对于 Mindless 来讲浏览器它的 tool 不是它的环境它的环境是它的 Ubuntu 系统下面的目录我觉得是这样子首先我们来讨论一下怎么去定义一个环境是好的还是坏的其实刚才我们在讲消化学里面 agent 概念的时候我们讲奖励信号环境的核心

作用是提供奖励信号的反馈机制所以我们要去看一个环境好不好我们得要去看这个环境能不能基于我行动的结果对这个结果提供一个奖励信号那 ID 为什么是好呢是因为它的全名叫做集成开发环境

我 agent 现在申请一段代码我这代码立马我能在这个环境里面我去运行一下这个时候代码它如果出错了跑不起来这时候 IDE 它其实就会生成一个错误信息这个错误信息天然就是一个反馈信号 Ubermantoo 它提供不了这种反馈机制

它其实是更多是个容器你为了构建起来这种反馈信号你可能还需要围绕 Ubuntu 然后去自己在上面搭一套东西出来 OK 然后你自己是之前做了一年多的 agent 对吧

所以你在做了一年多里面你觉得跟今年比如说新进来做的人对这件事的理解因为我知道你也聊过很多做业生的人你觉得大家认知上有哪些区别或者有哪些是你踩过的坑什么的可以跟大家分享有一个非常重要一个点的话就是一个好的 agent 应该是尽可能的去不让用户动脑子的一个产品那这个怎么理解呢就是说我们可以来看上个世代产品怎么样子

上个时代的话我们会看到一个产品功能越多它就能够解决的问题越复杂但用户学习理解使用这个软件的成本会越来越大就是用户的整个认知负担是会不断被加重的但是 agent 我觉得不一样 agent 我觉得应该是一个让用户越简单不用动脑子然后就能够用起来一个产品然后它越强大它应该更懂用户的偏好所以我觉得整个 agent 的产品设计

应该是得往这个方面去走的就像是我能积累更多的 context 我有更多的用户的数据用户的意图识别我还知道怎么样在适合的时间问出对的问题是所以说从这个角度出发的话我觉得其中我自己的一个跟大家可能现在有些不一样的观点是大家现在可能会想说 chart 到底是不是一个对 Azure Nairn 好的一个交互形态我认为其实聊天框就是

最最最重要的一个交互入口因为我觉得对于一个 agent 产品来讲用户交互的自由度是远远要比用户交互的准确度要

要来的关键就是用户想怎么讲都可以对吧如果你一旦限制用户交互自由度对于用户来讲就是说他得要习惯你而不是你习惯用户那就是说用户的这个认知负担就加重了对所以我认为 A 站的产品用户交互的自由度是第一重要的东西那从目前看到形态里面来看什么样子的形态是最有助于用户交互自由度提高的其实就是这么一个聊天框他说什么都行那难道用户

用户交互的准确度不重要吗其实也很重要就是现在大家都讲说我需要写了一个很好的一个 prompt 那这个其实就是说你准确度的问题但是我觉得你作为开发者或者说产品设计者而言其实有很多的方法能够辅助提高这个准确度的

比如说 Humanized loop 包括说你可能记录了一些用户的偏好其实现在 Devin 也好 Mindless 也好他能够积累一些知识下来知识可能是用户的偏好其实你可以在产品设计里面不断的去做些向用户提问的问题比如说他提问一个比较模糊的东西然后你去跟他不断的去澄清然后具体然后 detail

到最后这个东西逐渐就变准确了所以从这个角度出发的话由于你有很多的方法可以提高用户交互的准确度其实这应该是你作为产品开发者需要考虑的事你不能把这个任务交给用户我们要做的是怎么让你这个产品更智能让用户就像一个

非常幸福的小朋友一样能够用你的产品这个就又有点所谓的 web coding 的那种感觉了对就是当用户在 web 里面心流的状态对你可能感受不到时间而流逝你不需要动脑子你就感觉自己坐在那就是一个非常放松的状态

最后事情就做完了对让事情做完我觉得 agent 就应该做到这点所有实现不了这个承诺或者在设计上没有这种意识的 agent 产品我觉得都是为 agent 所以说聊天框就是最好的交互形态你不需要加额外的接口你不需要再加其他的组件你只需要做的事情是你把合适的一个组件在适当的时机跳到用户面前

然后让他去交互就比如说可能你在后台设计的底层代码时间里面可能有 200 个组件这 200 个组件可能对部分用户来讲他可能一直只能看到 10 个那剩下一般 90 个他用不到用不到就意味着不会影响用户的理解这个我是同意的我觉得如果纯是聊天框

不一定是最高效的方式但是我觉得它在适时的时候推出一个合适的产品界面然后用户去选应该是一个很合理的选择对所以总结一下我觉得首先意图识别是特别重要的首先得知道用户到底要干嘛是的但是这个我觉得 context 是两个互相印证的就是我如果 context 足够多我可能能猜到用户要干嘛是的

或者用户要告诉我要干嘛以后我还是要收集更多的 context 来帮助用户完成以及说我要知道中间有哪些问题是要提出来的所以这里面很重要一点就是你自己的模型得有能力判断当前的 context 是不是足够的如果不够你应该在环境里面通过环境给你提供的 API 你自动的去 get

无论是 rag 一样或什么样方式也好这个我觉得跟模型的智能是相关另外可能也是跟垂直流运的 node 号是相关的其实这边有一个点就是 system promptsystem prompt 其实就是你作为 agent 的开发人你需要去负责的东西 system prompt 基本上现在像我们看 cursor 也好 windsor 也好你会发现他们 system prompt 非常长

几千行对就是预制的 prompt 对而且我觉得这个确实在随时领域里面才成立的东西因为我只有知道他上来要干嘛我才能写好这个 system prompt 对而且我必须要了解这个领域我可能才能写的更好比如说就举研究的例子我就知道说他肯定是要去搜网页肯定要去搜集一些数据跟文章然后他肯定要把其中的一些东西要摘出来把这些东西再放到不管 Excel 还是一个 PPT 一个什么这样的报告里面

我知道他一定会做这几步所以我可以针对每一步去做优化去提前预制好我的 prompt 等等这些东西是的但如果这个东西它不是一个比如说研究类的 agent 它是个 tune agent 的话这个人上来他有可能是想做研究有可能想做个动画片也可能想生成个什么东西这个准确率一下子就下降了因为他可能尽管每一步就 90%成功

但是若干步骤以后它是一个陈述的关系而不像垂涎认得首先第一个他可以把每一步的成功率提到 100%第二个他哪怕出现问题了他也不会说上一步会影响下一步的结果所以我记得之前好像是苹果还是谁他做过一个事情是说你打开网页的上一步你是在看什么网页也是一种 context 对其实就是

我们讲康奈尔里面包括历史的对话信息其实历史对话信息只是说人看到的历史对话信息其实对于机器人他在你没看到的后台可能访问了很多个网页相当于说我当前的状态其实由我过去做的所有的事情所决定的我过去所有的这些事情包括我做了什么我看了什么我发了什么

整体而言构成了现在的这么一个状态这个状态的整个集合其实就是所谓的上下文也有 context 对然后包括 openAI 最近刚出的它的记忆系统其实也是一种 context 对所以我总想我觉得如果起手的时候能有更多的 context 肯定是最好的你看我前几周跟张玉光吃顿饭我觉得他提的一个点就特别好他就说当你点开某一个 app 的时候就打开你一下其实就已经提供了海量的 context

是的我点美团我就告诉他我要点外卖了然后点滴滴我就告诉他我要打车了然后这个产品里面的所有的东西是基于这个 context 在设计的对因为这个样子的话相当于把大家去拉到了一个共同的氛围下面对就把一度识别收集到然后再在跟他交互合作的过程当中不断的去积累 context 是的

是的然后这看来有可能是有用户的信息有各种你在执行流程当中的信息然后有各种网站各种环境的信息等等对吧所有的是一切都集合起来然后去继续去识别意图然后去判断中间哪一步可能会遇到什么问题然后再问用户准确的问题

对就是我们说你想更好地了解一个人你就去看他的过去你更好地想了解用户的意图你就去看他从哪里来他中间的路径是怎么样你把这些路径都需要保存下来所以 Google 很早就在保存 cache 对所以这个就是 Google 在 AI Native 时代最大的经济优势它是有一大堆的用户的点击的数据然后可以去帮忙去分析意图的

对就包括其实大家讲说到底数据对 agent 这么重要数据这个东西还是很重要但我觉得有一个限制条件是说它得是高质量的数据那什么是高质量的数据高质量的数据是说我不仅要知道数据的输入是什么我还得要知道结果是什么

我同时更要知道从输入到输出中间发生的事情中间的这种各个变化的数据是什么只有这些数据综合在一起就是它其实是一个数据序列这个是很关键比如说下围棋我只知道这一步棋怎么下不关键

重要的是我得知道前面它 100 首棋是怎么下的最后才可能说下这一部棋总而言之我能够推理到后面几部棋它怎么样子这个时候整个的过程的数据棋盘盘面怎么来的才是最关键我们再回到刚才那个地方就是有没有技术或产品上的点我觉得 Predator Modified 很重要你得要去能够去理解到现在

模型的边界上限在哪对吧哪怕是现在最先进的 O1 还有就是 3.7 也好你得要知道在

极限情况下你想做的那个事情他们能给你做到顺便可以聊一下你们现在在做的产品你之前给我说过一个你们的 demo 我觉得这个点上可能就是你刚才讲的一个相关的一个延伸你们选的一个方向是基本是已经实现的一个东西其他的好多做 agent 的我觉得还是在偏讲故事的阶段所以你可以给大家介绍一下你们目前的一些产品我们的产品其实是一个 data agent

目标是把整个的数据收集然后到数据处理以及到最后给予数据的行动整个链路都闭环

然后我们现在其实是在数据的收集处理这上面其实已经做得比较好了大概的他使用的场景会是怎么样的能不能举一两个例子首先第一个场景的话就比如说是你需要去找一些销售线索比如说我们的一个用户现在是他们有很多的开源用户然后他们希望知道这些开源用户是哪个公司的因为他们很有可能想把他们自己的商业化的版本去卖到公司里面去以前这个事情其实没有办法做的

你只能可能人肉的一个一个去分析但现在的话模型是能够做这个事情的具体怎么做呢其实我们会进入到用户的 GitHub 的主页上面去在主页上面去分析它有没有一些可能跟它是哪个公司的一些线索比如说代码提交记录或者它自己的一些社交媒体账号如果有社交媒体账号我们会进入到社交媒体账号里面再去看它有没有公司信息其实跟人去手动翻它是一样的我们是模拟了人的入门一个过程 OK

还有别的例子吗另外一个例子就比如说是找到 YC 他们最近几个 batch 的公司列表然后再找到公司列表的创始人然后再找到创始人的 Twitter 去关注一下然后给他们发个私信然后由于我们用一些 AI coding 的一些技术所以我们能够保证这个流程是百分百准确的实际我们也跟 DeepSearch 的产品还有是 Magic 的产品对比了一下他们其实并不能保证这些公司一个不落的

抓取下来这是一个点第二点的话其实我拿到数据以后我是需要有进一步的动作的就是我可能要去跟这个公司的创始人去建立一个联系跟他 reach out 一下但像 Depriest 这样的产品他报告申请完就是一个报告在美国后面了 minus 他们现在也不能做后面那一步吗他们好像可以 minus 的话现在就是没有办法保证成功率因为他是

在中间动态随机生成的代码它需要不断的去做 debug 跟调整所以你们从技术上是怎么解决这个问题其实我们相当于自己内部做了很多的这种小的 to 然后在让它去调用这些小的 to 的时候因为这个 to 我们自己内部人是已经验过测过了的所以它能够去保证白白准确

你给他提供了一些更好的工具是的而且这个工具其实因为我是程序员出身所以我非常喜欢用一个词叫附用如果有一个工具我下次用的时候我不是把它从头到尾重新写变代码而是我把已经测试过的工具我用起来之后其实效率是更高还是成本更低的但像 minus 的话现在它没有这个机制它每次都是打开 IDE 然后从零开始写代码明白所以听起来就还是 AI coding 的能力还不足够 100%的准确率完成这件事情

所以是人先去做了很多工作然后再让 AI 去调用这些工具会是一个更好的结果对所以这就是你要选择通用性还是准确性的这么一个区别你越通用就意味着你的方法要

更泛化更泛化就意味着它随机性更高我觉得这是吹道夫对因为如果很通用的话团队自己要写超多量的一些工具对我觉得核心还是你怎么去更好的去利用这些工具比如说发邮件或者这样你可能这种场景比较简单但如果你写一个比如说我们讲你数据库你有可能从头给他写一个吗不可能你更好的想我怎么去更好的方式然后 mcp 要

或者什么样其他方式也好我去在我的 agent 里面跟数据库做交付明白然后我就紧接着想到另外一个问题就现在也开始有人在讲说 workflow 是不是未来要被 agent 颠覆掉那如果这么讲的话可能至少相当长时间内 workflow 还是非常有价值的

因为我觉得可能跟人性有关系吧大家在去聊一个事情的时候非常希望去把一个什么东西踩一下创造一种对立的视角然后无论是从流量角度或者怎么样获得更多的眼球吧那实际上我觉得 agent 跟 wallflow 长期会处于一个共存的一个状态那 wallflow 跟 agent 的核心的区别其实很简单就是 wallflow 是人驱动的 agent 是 AI 驱动的

那人驱动的好处是什么好处就是它一定是稳定可靠靠谱的但是它的缺点是在于说它不够泛化那 agent 的特点是反过来了就 AI 驱动它足够的泛化它能够解决我之前没有想到的问题但问题在于说识字里面它可能会有五次把这事情搞砸所以我觉得可能 AI 会负责 20%更开放的问题但剩下 80%可能是更常见的问题换言之其实 AI 主要负责常理明白

所以你最终你们现在在做的产品跟其他的那些 agent 的区别你觉得是什么我判断 agent 不同的标准是我去看他们的 delivered result 而不是说大家好像看下一个事情都能干对那从 delivered result 的角度去看的话你会发现 genspark 也好 deep research 也好 mans 也好其实最后给大家呈现的主要的形式的内容其实就是一个报告

当然 minus 要做得更深入一点他们有可能还给你呈现图表或者说是简单的一个网页但我觉得这个只是报告的另外一种表现形式但本账而言他是给你提供的一个报告所以我觉得从这个角度出发其实我觉得大家都是调研 agent 这个是一类因为至少我们目前没看到 minus 可以帮我去美团下个单或者京东买个什么东西另外一类的 agent 就是所谓的 coding agent

coding agent 的 deliver 的结果就是代码转生我觉得你刚才定义挺好的可能像 mindless agent bug 什么它其实属于调研类 agent 对然后还有大家可能是 coding agent 对你把自己定义成什么类我自己其实是个表格 agent 我们这样的核心区别是说大家在去分析问题的时候一般来讲会有两种 mindset 第一种就是我可能只是说电信的去分析一下某一类问题电信分析一般来讲我可能就是用 deep research 之类的报告

然后我去看一下大概是什么样一个情况建立一种感觉那另外一种分析场景其实是定量的分析我需要知道一个非常准确的一个数字

这个数字怎么能保证准确就一定是说我得要分析数据源是准确的数据源一般来讲就是一个比较完整干净的表格我们做的事情其实就是把各种各样的数据源首先变成一个完整的表格而不是说我就是用一个什么搜索的接口拿到各种各样的网页去做总结对我们不是的我们是先把各种各样数据变成一个结构化的表格然后再拿这个表格去做下一步的分析

所以说我们之间是一个定性分析与定量分析的一个差异对所以你的核心是中间会有一个

AI 圣神的表格对但你这个表格里的尤其是里面数据什么的会遇到 AI 我们经常讲的那些它的幻觉什么这些问题我们在工程上把这个问题已经解决了 OK 然后我想到了一件事就是是不是 AI coding 它相当于是大模型的一个翻译跟一个助手的感觉就是是不是所有的任务都中间可以加的 AI coding 来解决准确率的问题来解决所有的幻觉等等的问题

我觉得是的用现在还比较时髦的话来讲我觉得 L-Coding 就是大模型的一个灵巧手对因为我们现在都在讲说如果让大模型不断的去做一个任务规划的话一旦它每个任务的成功率是 90%那可能 10 步以后它就是一个 0.9 的十次方它成功率就很低了这样的话我们怎么去让上一步失败不影响下一步那可能我们就需要中间以代码的心去运行它因为代码我只要能保证

90%成功率我可能 10 次里面 9 次成功我只能把 9 次成功代码留下然后做一个正确的 case 然后再进入到下一步那就是说其实就能保证每一步都 8%正确的这个很合理但因为我不知道你们从实际的操作和经验来讲是每一个大模型的操作都应该先翻译成 coding 翻译成一段程序吗我觉得这个地方还是想拿 mcp 来说的意思因为 mcp

背后调用的那些所有的 tool 本质上全是代码对所以从这个角度来回答徐老师你的问题来讲我的答案是是的我想再回到刚才问过的一个问题是说你自己做了一年多 agent 然后你有什么能跟别人分享的对这个问题没讲完

刚才其实提到了 Program Model Fit 第二点我觉得很重要的就是你得想明白你给用户到底 deliver 的 result 是什么你只有把 result 想明白了之后你才能够不断的去通过设立起反馈的一个激励机制然后不断去优化这个结果因为如果你这个事情想不明白他就不收敛不收敛就意味着你可能 deliver 那个结果就是一个比较差的质量比如说像我们做 DataShift 这个场景

我们其实试过 operator 试过 james buck 试过 gork 你会发现他确实也能帮你比如说 yc 刚才提到的例子他确实也能深深 yc 公司的表格但是你会发现那个表格永远是缺一些公司的而且你让他去进一步的你想去知道公司的创始人是谁创始人是哪个学校的工作了多少年他的推特账号是谁

它是完全解决不了问题的我已经有了一个基本的数据之后我在这个数据之上我进一步去吩咐我的数据它做不到你就把结果想明白了你才能够去不断的在基于第一步的结果的进步之上去优化第二步结果

就是一旦你把结果想不明白你会发现你这个东西就算不好变成一个所谓的看起来有点像通的一个 agent 我觉得另外一点还有很重要的就是我觉得做 agent 的人呢你要解决两个信任的问题第一个信任的问题呢是你作为 agent 的 cage 你要足够的去相信大模型

这个点会产生什么影响如果你不相信大模型你会做一个事情就是说你不断在代码里面加一些什么限制条件比如说就写 prompt 你就是个谁谁谁你只能干某某事情不能干别的事情这种事的影响在于说你会发现大模型的整个的泛化能力其实被你认为的影响变低了

用现在我自己的一个词来讲就是说你会导致你们的 agent 对大模型的智能利用率下降对我们跟人聊也经常会发现确实有这种例子就是本来在大模型上你是想去做更好然后封装了很多东西最后反而做了半天可能不如我把需求直接放大模型里对 是的这个就是由于你自己对大模型不够的信任你作为开发者你会产生一种内心的不安感这种不安感会促使一下你

用一些传统的所谓 Rubase 的方式挤着这个过程的时间最后你会发现这是在开倒车所以说 agent 的开发者需要去解决自己内心对弹幕性认认另外一个点就是你得一定要想好你的这个产品该怎么通过设计去解决用户对你结果的信任很好一个例子的话我觉得还是 DeepSeek R1 在 DeepSeek R1 之前其实

我用一些像 DeepSeal 这样的产品它申请那个报告我在看到的第一眼我其实是会以一种更批判的角度去看说这东西到底是对答还是错的为什么呢是因为我不理解它这个东西怎么来的但是呢 R1 穿以后它把中间这个 Running 的过程告诉我在我心里这样会让我更舒适的感觉说我看到它怎么想的所以我更

愿意去幸运这个结果对我前几天跟朋友聊我就讲了一个事儿我说其实 minus 很大的一个价值是它给所有的 agent 创业者打了个样也许过一段时间以后大家回头看 minus 这个产品形态就好像当年的 carrier.ai 一样让大家知道说 ok 上一代的大模型最适合的就是 chatbotchatbot 类似 cai 这样的产品形态对话题大概就是这么做然后大家在这个基础之上去不断的怎么样改

然后现在的 agent 可能很多都是在 mindless 那个技术上去不断的去修改我不知道你怎么看这个问题它是不是一个比较通用的一个产品形态我觉得是的我觉得 mindless 是在 diaming 的技术上在 UI 世界上跟进一步了

其实核心就是他把中间所有的细节都暴露出来人看这个东西之后他心里面就会存在一种满足感跟安全感是你对于未来几年 Agen 的发展会有什么预测吗我觉得以现在 AI 的发展速度去预测几年这么一个时间宽度我觉得太难了预测半年到一年对所以我其实想分享一个框架就是跟大家一起去思考这个事情首先想要去预测一定得要先去抓关键变量

agent 这个事情里面关键变量是什么其实前面也讲到了区分 agent 的方法是去看它的结果的好坏通过结果的好坏来判断它到底是不是一个更专业的 agent 结果其实就是上下文 context+ilm 所以说我觉得核心变量就是这两个你想 agent 突破你就要 context 或者说 ilm 至少有一个是突破了的

首先来看 RMRM 的下一个突破我觉得基本上也就是看 GPT-5 什么时候出来我觉得从时间节点上来讲我觉得可能 GPT-5 是在今年年底左右会出来可能年底的时候或者明年元旦之后我们可能发现 Agent 的能力会更进一步这个是一个节点另外一个节点的话就是说

GPT-5 出来了以后什么时候成本会变成一出来的五分之一甚至说是十分之一这个过程可能也得需要一年的时间就比如说 DeepSeek R3

我现在不知道它会有多大的突破因为本质上我觉得这个事情还是得需要仿内式 model 去做突破的也就是说可能比如说是什么时候 DPC 的 V4 出来然后 DPC V4 可能会再生成一个什么样的一个推理模型所以我觉得这个是一个就是说你从模型的角度来讲第一个更先进的仿内式 model 什么时候出来以及说仿内式 model 的成本什么时候能降下来因为仿内式 model 出来之后我们就能做 demo 了

demo 有了之后大家就有预期了但是只有到成本降低之后这个东西才能规模化使用所以我觉得接下来真正很好用的 coding agent 以外的 agent 出来我觉得可能还是得到 26 年的下半年就是大规模的大家之间能用上这个是一块另外一块的话我觉得就是从 context 角度来出发其实也可以来看个例子就是 cursor 它为了把整个 coding 这个事情的 context 做好围绕 vscode 其实做了大量的二次开发

他们是从 20 年开始然后到去年下半年其实中间是花了一年半的时间这里面呢我觉得工程量是非常大的我觉得这也是大家现在普遍的我认为的一个误解就是会觉得 agent 是个 talker 其实我觉得不是 agent 里面的这个工程复杂度我觉得是远超出大家想象你想让 agent 在 context 这个层面去做突破你是需要大量的工程量的尝试跟积累的

所以说我们从现在这个时间点去看的话就是假如说 DeepSick 出来之后大家第二天立马开始干这个 agent 然后优秀的团队干的快点我觉得也得要六个月就慢一点就可能就一年了所以说可能到今年的 Q3 吧我觉得可能会有一些更好的 agent 的一个产品出来

我再补一个问题因为你都在讲到说判断 agent 就是他的 result 怎么样但 result 好的就一定是说 agent 的公司好吗因为有可能有的公司他就是通过各种手段可能他某一个 prompt 写的特别好然后他的 result 在阶段性就更好所以我想说如果假设你是投资人的话现在你面前有好多做 agent 的公司你会问哪几个问题来判断这家公司的好坏

因为投资人现在遇到各种公司对吧你来了就是一个挺好 profile 的 founder 对吧然后可能有一个算法或者什么技术的挺好背景的一个人然后讲说我要做某某领域的 agent 然后其他的讲的东西其实大差不差也都差不多其实我为学位就一个问题我就会看他们团队里面有没有人去看我前面提到那个就是 Sata 那本书因为我觉得你只要看过这个书你就一定会有 mindset 有这 mindset 的人

他一定不会去能够长期容忍我用一些非常符号主义的那套方法去达到一个结果你这个要求可能有点高的有很多人可能凑巧就没看过那本书我其实就会可能问一个事情就是你的产品里面的环境反馈的激励信号是怎么设计的到底在你的产品里面什么样子的一个行为是一个好的行为什么样的一个行为是一个差的行为我觉得这个问题很关键

因为有了这个信号之后你才能够让大模型去迭代就是说把上一轮的结果跟环境提供的好与坏的评价丢给大模型让大模型再去迭代一轮从这个角度来讲确实通用好像就不如垂直通用你很难定义这个东西对这里面补充一个点就是说大家现在觉得有大模型之后结构化数据这个事情不重要了

不它其实还很重要因为大模型的输入我们可以是非结构化的就是我把什么乱七八糟的文档文本 pdf 图片我一股脑吸进去但是大模型的输出一定得是结构化的因为你只有结构化了你才能够去用代码或者说是规则的那一套东西去校验要不然它是没有办法去校验的

所以说你的激励信号其实最后在代码上体像来讲的话就是你弹模型里面输出的结果里面可能不够自断的值到底是什么对你这套标准是什么所以我觉得让我问的话我会问这样的一个问题 minus 的激励信号可能是什么如果你负责的 minus 这个产品的话我想不到因为现在他们官网的那些例子我看下来其实

本质上的判断还是在让大模型本身或者我写了另外一个 prompt 然后去判断说这个东西是好的一个结果还是坏的一个结果但实际上如果大家去用 XGB4G 的产品你让他比如说我最近在写 PTT 写了一段开场白然后让他不断优化开场白我给他说不满意你改不满意你改你只是说提供这样的一个 feedback 的话你会发现他最后是陷入一个奇怪的一个

死循环里面它是出不来的所以一定得要给它提供大模型本身所不具备的那些反馈信号我觉得它才能够把这个结果从死循环里面跑出来所以如果我问你这个问题你们自己产品的反馈信号是什么其实我可以讲一点我们取数据这个事情不存在 hallucination 因为我们其实

让大模型负责的是整个页面结构的分析然后还有页面与页面之间关系的分析通过这些分析的结果会生成一段脚本然后正儿八经的其实往下来收集数据生成数据的这个过程其实是用代码实现的那代码其实就是一个典型的能够给我提供反馈信号的这么一个机制这是一个点另外一个点的话表格这个东西其实很直观

一个地方是空的我一眼就能看见那其实这个也是一个反馈性明白很合理我觉得对对对因为报告不一样报告那个东西就是你很难去精确的去描述到说哪一行哪一个字怎么样但表格的话由于是个结构化的所以我是可以去描述它的嗯

我觉得今天我们其实讨论了很多 agent 相关的问题我相信把一些大家核心关注的问题都比较快速直接的去 cover 到了然后包括温峰也提了一些他自己做这么长时间 agent 的一些经验

我最后一个问题给大家三个理由说图像场景之下为什么用你们而不用 minus 或者 genspark 或者其他的工具产品其实我觉得都不用三个就是你只要有对于高质量数据抓取的需求你会发现现在市面上的 agent 产品只有我们的产品可以做到

就是 100%准确率对 100%准确率然后 100%稳定 100%不给你丢数据 OK 所以什么时候大家可以用到在这周的时候我们就会开放线上的 waitinglist 差不多大家注册了 waitinglist 以后可能在 2~4 周的左右时间你就会能够正儿八经的使用我们的产品大家可以去访问我们的官方网站实际体验一下以防大家不太知道怎么评 shet0.com 就是表格的单词 OK

好那谢谢文峰好也谢谢曲老师

We're sunsetting PodQuest on 2025-07-28. Thank you for your support!

Export Podcast Subscriptions