开场0:00
There's something there.
今天北京风特别大 ， 感谢文锋今天还跑过来录这期播客 。 然后正如北京的大风 ， 一个非常尴尬的转场 ： 今年 AI 最热的大风天就是 Agent 了 ， 所以文锋正好做了满长时间 Agent。
你可以跟大家介绍一下自己 。
大家好 ， 我是王文锋 ， 是一个做 Agent 两年的程序员出身的创业者 ， 同时也是曲老师的粉丝 。 然后我们在做的一个产品是 Data Agent。
现在大家都在讲各种各样的 Agent，但 Agent 到底怎么定义 ？
Agent定义0:47
我觉得最好的定义是 Anthropic 的一个定义 。Anthropic 的定义的话是说 Agent 是模型基于环境反馈去使用 Tool 的一个程序 。 那这里面的话 ，其实我觉得有三个点需要去拆开说一下 。
第一点是模型 ， 这个大家其实是最容易理解的 。 第二个的话 ， 我觉得是环境反馈 ， 这很关键 。 第三个的话就是 Tool， 就是说 Agent 我们需要去 take action， 那其实通过调用 Tool 的方式去实现的 。
所以你怎么看最近这波 Agent 热 ？
我觉得这波 Agent 跟过去非常不一样的一个点是 ， 这次 Agent 真正的是能够去实际的解决问题了 。 像上一轮 Agent 大家讨论的时候 ，其实是在 23 年的 4 月份 ， 当时代表性的产品是 Auto-GPT。
但当时它更多的可能是一个玩具 ， 它并没有什么实际能解决的一些问题 。 但是经过两年的发展 ，Agent 现在真的已经落地了 ，而且在实际的工作生活场景里面给大家带来了真正的价值 。
这两年主要的变化是什么 ？
我看到的有两点 。 第一点的话 ， 确实是底层的模型有了非常大的一个进步 ， 尤其是 O1 出来之后， 给 Agent 带来了长思维能力 。
主要这个就是因为 RL， 深度学习在这个决策上的使用 ， 对吧 ？
对 ， 我觉得这个是一部分吧 。 还有另外一部分可能是大家没有关注到的一个点 ， 就是说其实 Agent 工程这个事情上面也有非常大的突破 ， 就是说是怎么去给 Agent 更好去构建一个合适的 Context， 然后去解决问题 。
这个我觉得是从工程这一侧 ， 或者说产品这一侧的一个进展 。
所以你刚说第一点是模型的进展 ？
对 ， 第一点是模型 ， 第二点是 Agent 的 Context。
Context 这个怎么理解 ？
Context 其实是定义了所有大模型需要去利用的信息的一个总和 。
比如说呢 ？
比如说以代码为例的话 ， 那它包括了整个代码库的结构 ， 代码库的原文件代码 ， 还有整个代码库里面我有哪些 API 可以使用 ， 包括人类的输入 ，其实这些都算 Context。
比如说呢 ？ 可以举一个具体的产品的例子 ？
其实每家的产品的 Context 不一样 。 我以我们产品为例子的话 ，其实我们产品是一个帮助大家去收集数据 、 分析数据的一个 Agent。
对于我们而言 ， 我们的 Context 其实就包括了网页 ， 还有是我们帮用户收集过来的数据表格 ， 还有包括说用户他想要一个什么样的数据 ， 就是那句段 Prompt， 还有包括我们分析数据的时候生成的这些 SQL，其实都是 Context。其实这些 Context 是比较琐碎的东西 ， 大家加在一起一个整体 ， 我把这些整体然后去一起输入给大模型 ， 让大模型来判断出来说我应该给用户一个
什么样的一个结果 。
我明白 ，但我在想这些过程当中的信息被留下来在使用 ， 或者不管是 Java Prompt 还是 RAG 里面 ， 这个不是之前本来大家就都应该是约定俗成的一套做法吧 ？
其实这个核心是你的这些 Context 从哪里来 。 比如说我刚才举的例子网页 ，是吧 ？ 那网页里面它其实网页一般有很多无关紧要的信息 。
首先第一点 ， 我怎么把一些我关注的信息我抽取出来 ， 这是一部分 。 另一部分的话 ， 比如说我要生成 SQL， 那这个 SQL 是怎么准确的 ， 那我需要去校验 。
我校验的话 ， 我需要利用到数据库 ， 那我这条 SQL 能不能执行成功 。其实这些信息是需要以某种自动化的形式去提炼出来 。
那以前用 RAG 也好 ， 还是说其他什么办法也好 ，其实这些信息主要输入来源是人。Agent 更强调的是我的这些信息来源是我通过某种自动化的方式获取到的 。
是 。 我觉得我们先把一些基础概念快速的给大家介绍一下 ，因为大家经常听到很多概念 ， 对吧 ？
比如说什么 Function Call， 包括 MCP， 包括 Google 前两年出的 A2A， 然后也有这种所谓的 Computer Use、Browser Use 等等各种各样的说法吧 。
就在你看来 ， 你觉得这些是怎么分类 ， 或者有没有什么优劣之类的 ？
其实刚才曲凯老师你提到的像 Function Call 也好 ， 像 MCP 也好 ， 或者 A2A 也好 ， 或者 Browser Use 这些东西也好 ， 它们其实都是在解决一个事情 ： 给大模型提供更好的一种使用工具的方法 ， 让大模型更好的去 take action。
那这里面的区别是什么呢 ？ 其实你可以理解 Function Call 是最早 OpenAI 提出来的让大模型使用工具的一套方法 ， 可以理解它是个 0.1 的一个版本 。
然后 MCP 在这个基础之上， 它又更近了一步 ， 我们可以理解它是大模型使用工具的 0.2 的版本 。 但是 MCP 非常大的作用在于 ， 它其实是类似于说统一度量衡的一个事情 。
因为以前的 Function Call 那个阶段 ， 大家使用工具的标准是不一样的 ， 那相当于每个国家它可能有自己的这么一套度量衡的一个方法 。
我到另外一个国家之后， 我就得重新学一遍 。 但是 MCP 把这个事情做成标准化了 ， 那这个时候相当于有了一个说放之四海都皆准的一个方法 ， 大家都可以去调用任何人的工具 ， 那其实相当于这个事情的门槛一下子降低了 。
然后 A2A，其实我觉得 A2A 没什么意思 ， 更像是一个 KPI 工程 。 因为 A2A 它自己定位自己跟 MCP 的区别是说 ，MCP 它只能跟其他的 Tool 或者说是 API 去交互 ，但是 A2A 它说的是我可以 Agent 与 Agent 之间交互 。其实从我们开发者的角度来讲 ， 这个事情是没有区别的 。
因为 Agent 其实你也可以定义成一个 Tool， 就是说它可能有个调用的那个函数入口 ， 那个东西用 MCP 的包装下， 它也可以被其他的 Agent 去调用 ，也可以纳入 MCP 的范围之内 。
所以从这点来讲 ，A2A 我觉得是属于强行造了一个自己的一个概念 ， 然后找了一堆合作伙伴 ， 然后过来去推这个东西 。
我觉得这本质上是一种标准化有权的一个争夺吧 。 但我觉得从工程师的角度来讲 ， 我们是更喜欢 MCP 的 ，A2A 没有提供性的东西 。
明白 。 然后 Browser Use 它其实强调的是说 ， 我把浏览器这个事情当作一个工具 ， 我让大模型去调用 。
Browser Use6:35
可能说全世界有成千上万的工具 ， 那浏览器可能是最重要的工具的一种 。 明白 。 我现在听起来我感觉其实整体是分成两派吧 ， 一派是直接用代码来解决问题 ， 对吧 ？
我理解不管是 MCP 还是 A2A 等等东西 ， 它是用代码去解决问题 。 然后另外一派是模拟人去解决问题 ，是吧 ？
不管是 Computer Use 还是 Browser Use，其实它是通过可能视觉识别加上一些 RPA 的方案去解决 。
其实不矛盾 ， 你也可以用 MCP 的方式去进行所谓的 Browser Use。
怎么做到 ？
因为实际上我们是怎么去用 Browser Use 的一种方式 ，其实就是纯粹的通过图像 GUI 的方式 ， 就是我推算出来某一个坐标 ， 然后可能把鼠标移到这个坐标上面 ， 我点击一下， 或者说我输入个什么东西 。
但实际这个方案是远远不成熟的 。 就国外有家 Adapt 公司 ，其实是在 23 年、24 年非常火的一家公司 ，但实际上这家公司已经死掉了 ， 就是因为这个事太难了 。
所以说现在大家去用 Browser 的时候 ，其实也是通过浏览器的 API 把它包装成一个类似于说 MCP 的 Tool， 然后我再通过代码的形式我去调用这个 Browser。
明白 ， 明白 。 就是其实它前面类似演了一场戏给人看吧 ， 背后还是用的那些 。
MCP 跟 Browser Use 其实是两个叫做正交的两个东西 ， 就是互不影响 。
但现在是不是有个问题 ， 就是说因为毕竟很多公司没有兼容 MCP 的这些东西 ， 然后甚至于说往后走 ， 可能有些公司为了保护自己的用户和数据 ， 它也不会兼容 。
所以就变成有些产品是必须要使用真的 Browser Use， 真的是模拟人操作来去完成 。
我觉得首先是这个样子的 ， 正儿八经去使用 MCP 的标准姿势是什么呢 ？ 假如我是开发者 ， 我现在发现我想要用 MCP 去用某一个 SaaS 软件 ， 那这时候我其实不需要 SaaS 软件本身去支持 MCP， 就是我不需要它已经给我提供了一个 MCP 的一个接口了 。
因为 MCP 是个标准化的东西 ， 我自己可以按照这个 SaaS 软件它开放出来的那些 OpenAPI，在 OpenAPI 之上包一层 ， 我就可以把它当作一个 MCP 去用了 。
所以说前提在于说我这个 SaaS 是不是它已经有了一个 OpenAPI，因为 OpenAPI 在国外的软件生态来讲基本算是一个标配了 ， 基本上所有的 SaaS 都会有 。
但国内可能是没有的 。
对 ， 所以这个问题就是国内和海外是非常不一样的 。 那如果说这个 SaaS 产品或者另外一个软件产品 ， 它确实没有开放出来一个所谓的 OpenAPI 或者一个什么样的 SDK 的话 ， 那这个时候确实是没有办法以代码的形式去用 。
但是你也可以这个时候尝试着去用视觉的方式 ， 就是我们前面提到了 ， 我用浏览器 ， 相当于我把浏览器的截图我传给大模型 ， 让大模型判断上面的一些交互元素 ， 把坐标算出来 ， 然后我再通过鼠标键盘的方式去控制 。
这两种办法 ， 就是 API 也可以 ， 然后 GUI 也可以 ， 就取决于说在什么样的情况下面更高效 。
对 ， 所以简单可以得到一条结论就是说 ， 如果未来 MCP 或者后端各种接口支持的话 ，其实它直接调用就 OK。
那如果它不支持的话 ， 那就只能通过视觉和模拟人去使用电脑的方式来去解决这个问题 。
对 ，而且我觉得这边还有一个点的话是 ， 每个的 Agent 它可能想解决的问题会不太一样 ， 所以我觉得具体说哪个部分占的比例更高一点 ， 可能是需要 Agent 它根据自己的需求实际的配比 。
另一方面 ， 我觉得视觉的方式虽然说现在包括稳定性 、 准确度没有结果那么高 ，但是它有个好处是它的成本低 。
因为我们自己的产品其实这两种方法都用了 ， 实际体验下来 ， 你给它结构图 ， 然后让它去判断 ，其实速度要更快的 ，而且 Token 消耗量也会很少 ， 至少会少一个数量级的这么一个情况 。
问题是 GUI 的这个生成的结果有些时候会不准确 ， 比如说我图片上有一个提交表单的一个按钮 ， 很多时候可能会去把那个坐标位置算错 。
明白 。 所以你看我前几周在美国的时候就有一个也是很专业的做 Agent 算法相关的人问了我一个问题 ，他说他非常不理解为什么 Manus 要用浏览器来做这件事情 。
就他的理解是其实后端的代码什么都可以接通就直接实现了 。 如果是你的话 ， 你会怎么回答他这个问题 ？
因为我看你们的那个产品里面其实也用了 LazyManus 那套逻辑 ， 对吧 ？
我觉得这边其实会有两个视角可以来去回答他这个问题 。 一方面就是从技术的视角 ， 一方面是从产品的视角 。
技术的视角我简单说一下， 就是用浏览器这个方式在成本上来讲会更低一些 。 对 ， 另一方面的话 ，其实让 Agent 生成结果 ， 那还有很重要的一个点是在说这个结果我用户是不是可信的 ， 那我们再去让用户使用 Agent 的过程当中， 怎么去给用户营造这么一种可信的氛围感 ， 我觉得这个非常关键 。其中一个非常重要的一个手段就是说 ， 我让用户可以全程看到我是在怎么去
帮你完成你这个工作的 ， 让他能看到其中的每一个细节 ，而且这个细节是以他能懂的方式去 get 到 。 那浏览器这种天然来讲对于人友好的这种视觉化的呈现方式 ，是要比代码这种看起来黑乎乎的一个窗口来讲要更生动 、 更直观的 。
Devin 算是哪一种方案 ？Devin 其实就是纯 Coding 的方案 。
Devin 其实都有 。
它也算有 Computer Use。
对 。
然后 Manus 是典型的也是 Coding 和 Browser Use 结合的 。
对 。
然后最近那个 Genspark 新出的那个我不知道你看没看 。
我看了一些 。
对 ， 你觉得它是什么方案呢 ？ 跟 Manus 是很类似吗 ？ 还是怎么样 ？
稍微会有点不一样 。Genspark 我自己跑了些任务 ，其实我没有看到特别多的像 Devin 或者说是 Manus 这样就是有一个肉眼人能看到的浏览器 ， 或者说是 。
是 ， 感觉它是在后端去跑 。
对 ， 它应该后端也会用一些网页的 API，但没有把这个事情包给用户 。 所以我觉得它可能还不是一个我心目当中的那个 Agent。
但从用户视角来讲 ， 你反正最后帮我解决问题就好了 。 我为什么要 care 说你到底有没有在哪跑一个什么东西 ， 或者它多 fancy 的在像人一样在使用电脑或者使用浏览器 ？
这是个非常好的一个问题 。 从我的视角来讲 ，其实我想举个例子 ， 就比如说曲凯 ， 我们两个是同事 ， 那我们两个之间应该怎么去建立信任关系呢 ？
那我觉得更多的一个办法就是 ， 假如你给我分配一个任务 ， 你能看到我是怎么做这个事情的 ，以及说你后面知道我大概是一个什么样的思路 ， 就相当于你足够的了解我之后， 你才会对我产生信任 。
我觉得这个点是 make sense 的 ， 就是包括像 Manus 这种 ， 我觉得其实一个核心的点在于说大家觉得 Agent 这个事还是不太不靠谱 。
所以我需要在给你看到过程当中的东西 ， 然后我需要说人不断的去 involve 进来 ， 对吧 ？ 你要回答他的问题 。
对 ， 就是让人时刻感受到你是在掌控一切的 。 因为跟人一样 ， 就是大家其实都会有种不安全的这种感觉 ， 那怎么去给人建立起这种安全感的这种边界 ，其实把一切做透明是很关键的 。
对 ，但这个在我自己用 Manus 的时候 ， 就是也会觉得它也有个缺点 ， 就是有时候它跑着跑着 ， 它提了个问题 ， 我可能没看到 ， 我就也没管 。
然后我本来等了可能半小时小时， 我觉得它要跑完了 ， 回来一看可能还在第二步问了个问题 。其实这个就是一个 UI 上还是可以去优化的一个点 。
另一个这个事情的话 ，其实我觉得也是可能是他们现在极端性的一个点吧 ， 就是后面比如说它跟你的邮件 ， 或者跟你的短信 ， 或者说跟你平时工作用的 IRM 打通之后 ，其实你会以一个更容易去看到的方式去收到这个通知 。
所以我觉得这不是什么大问题 。 所以总结一下， 就是其实应该所有的这些 ，不管是什么 Use 也好 ， 还是什么 Coding 也好 ， 都是当下 Agent 可以用的工具 。
然后根据不同的场景 ， 好像目前来看大多是一个组合的方案来实现一些东西 。
是的 。
AI与Agent14:19
然后最终你觉得 ， 比如说 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 的一个补充 。
对 ， 就是一个很强有力的一个工具 。
通用vs垂直16:15
对 ， 然后另外一个问题就是我自己是觉得当下这个市场大家对于 Agent 的讨论和理解跟两年前大家对于大模型什么的是有点像的 。
比如当时大家在问说会不会有一个通用的 AGI 模型 ， 还是会有垂直的模型 ， 还是说很多创业公司要做自己的小模型等等 ， 对吧 ？
现在其实大家也在开始讨论说未来是通用的 Agent 还是垂直 Agent。 我不知道你怎么看这个问题 。
我觉得我们其实现在处于也将长期处于一个所谓的垂直 Agent 的这么一个时代 。 对 ， 我最近其实非常喜欢去举一个例子 ， 就是比如说做饭这个事 ， 就很多人都会做饭 ，但大家的区别是说假如说曲凯咱俩做饭 ， 可能就是我们把手机拿出来 ， 把菜谱软件打开 ， 然后对着菜谱我们做顿饭 。
但可能更好的 Agent 是说它就像是五星级酒店一个大厨 ， 我们能说我们跟那个五星级的大厨是一样吗 ？
不能 ， 核心区别是因为人家做的那个饭可能从美观程度 、 从这个美味程度来讲都超出我们很多倍 。
所以说人家是专业厨师 ， 我们可能就是一个会做饭的一个普通人。
那讲回来就是今天我感觉至少从资本市场来讲 ， 当你说你要做个 Agent， 大家就会尤其想问说那你有没有好的算法的人， 你后面要怎么做 RL， 怎么做差异化 。
RL的价值17:17
那从你的视角来讲 ， 你觉得 RL 这件事跟创业公司的关系是怎么样的 ？ 或者说 RL 跟 Agent 之间的关系 ， 它最后到底怎么应用呢 ？
RL 这个事情我觉得有几个点比较关键 。 首先是 Agent 这个概念就是从强化学习里面出来的 ， 所以不是说 RL 对 Agent 多重要 ，而是说你脱离了强化学习这门领域 ， 你 Agent 这个概念它就不成立了 。
所以说我们做产品的人一定要追根溯源的看 ， 最早 Agent 他们的定义在强化学习里面是怎么定义的 。
那在强化学习里面 ，Agent 的定义其实主要有三个关键的东西 ， 第一个就是状态 ， 第二个就是行动 ， 然后第三个就是激励信号 。
怎么去理解呢 ？ 首先状态其实就是我们前面一直在强调的 Context， 就是说我在经过了若干个步骤以后， 我当前这个 Agent 是在一个什么样一个情况 ， 这个地方去包括了可能是说它的记忆 ， 它现在看到的东西 。
然后呢 ，Action 其实就是 Tool Use。 那我现在有了一个判断了以后， 我怎么把这个 Action 实际的去执行 ， 它其实就是通过函数调用的方式去执行 。
因为函数接口这个东西就是代码与这个数字世界交互的这么一个媒介嘛 。 所以这个是 Action。 另一方面就是最后那个激励信号怎么来理解呢 ？
其实就是说我现在 Action 通过函数调用的方式执行完了 ， 那这时候我需要做一件事情来判断是说这一步我做完之后， 我的整个的状态离我想要达到的目标是更接近的还是更远的 。
那这个其实就是一个 1 跟 -1 的这么一个区别 ， 就是说我需要去通过这种激励信号来判断我应该是往左边走还是往右边走 。
那对于创业公司来讲 ， 非常关键的一个点是你如何去让你的产品变成一个环境 。 因为你只有有了环境 ， 你才能够去描述说强化学习里面的那个状态是什么 ，以及说你可选的这个行动空间有多大 。
那这时候就是说你程序里面 Workflow 这个事情 ， 就是说你有多少的这个节点 ， 它其实是由你的这个行动空间去决定的 ，以及说你怎么去定义你的结果 。
那为什么一定要把结果定义好呢 ？ 因为只有把结果定义好了 ， 它才能收敛 。 只有我能收敛 ， 你才能够让大模型去判断是说我一个行动做完之后， 我离你的这个目标是更近了还是更远了 。
那这时候你才能够去设计这么一个激励信号 ，不断的去让你一步两步 、 一轮两轮三轮的去让 Agent 自我迭代 ， 直到实现了那个目标 。
所以说具体的建议呢 ， 我是建议所有的 Agent 的开发者或者说产品设计者 ，他们去看一下强化学习之父 Sutton 写的那本书 。
你只有看完这本书之后， 或者说有了这样的一个 Mindset 之后， 你才能够在设计产品的时候不断的去思考 ，不断的去调整 ， 去定义你是一个什么样的 Environment，在这个 Environment 里面你的程序之间的状态是什么样子的 ， 然后你的行动空间有多大 。
通过这种方式 ， 我觉得才能够去定义出来一个好的能够自我迭代 ， 然后能够去基于动态的情况 ， 然后去不断的修正自己的这个路径 ， 最后能够实现用户目标的这么一个程序出来 。
所以说我觉得就是你不理解强化学习 ， 你就很难理解 Agent 到底是什么 ， 你很难理解 Agent 到底是什么 ， 你就很难去设计你的产品长什么样子 。
对 ， 然后我们留一下你刚才说的那几个点 。 第一是状态 ， 第二是类似于行动吧 。
Tool Use。
对 ， 然后第三个是奖励函数嘛 。 对 ， 我觉得第二和第三个其实是相对好理解的 。 因为哪怕不是 Agent 领域里面 ， 包括所有的模型领域里面 ， 大家都在讲说其实最重要的是 Evaluation 体系的搭建 ， 对吧 ？
就是评估体系 ， 你这个东西的标准啊等等 ， 这个东西肯定是特别重要的一部分 。 然后 Tool Use 其实我们刚才已经讲了很多了 ， 那不外乎就是在现有的环境之下， 我不管是用 Workflow 还是用 Agent， 还是 Agent 去使用 Workflow， 还是用各种 Browser Use， 还是用 Coding， 反正各种方式都上， 怎么样能把它解决好嘛 。
然后第一个它的状态跟环境 ， 或者说就是 Context 这件事情 。 那从这个角度来讲 ，IDE 肯定是一个特别好的环境嘛 ，但 Manus 那种其实浏览器你很难讲它是一个多好的环境吧 ， 相对不是通用的一个工具嘛 。
对于 Manus 来讲 ， 浏览器它的 Tool 不是它的环境 ， 它的环境是它的 Ubuntu 那个系统下面的那个目录 。 我觉得是这样的 ， 首先我们来讨论一下怎么去定义一个环境是好的还是坏的 。其实刚才我们在讲强化学习里面 Agent 的概念的时候 ， 我们讲奖励信号 ， 环境的核心作用是提供奖励信号的反馈机制 。
所以我们要去看一个环境好不好 ， 我们得要去看这个环境能不能基于我行动的结果 ， 对这个结果提供一个奖励信号 。
那 IDE 为什么是好呢 ？ 是因为它的学名叫做集成开发环境 ， 就是我 Agent 现在生成一段代码 ， 我这代码立马我能在这个环境里面我去运行一下 。
那这时候代码它如果出错了 ， 跑不起来 ， 那这时候这个 IDE 它其实就会生成一个错误信息 ， 那这个错误信息天然就是一个反馈信号 。
那 Ubuntu 它提供不了这种反馈机制 ， 它其实更多是个容器 。 你为了构建起来这种反馈信号 ， 你可能还需要围绕 Ubuntu， 然后去自己在上面搭一套东西出来 。
交互形态22:54
OK， 然后你自己是之前做了一年多的 Agent 嘛 ， 对吧 ？
对 。
所以你在做了一年多里面 ， 你觉得跟今年比如说新进来做的人对这件事的理解 ，因为我知道你也聊过很多做 Agent 的人， 对你觉得大家认知上有哪些区别吗 ？
或者有哪些是你踩过的坑啊什么的 ， 可以跟大家分享 。
有一个非常重要一个点的话 ， 就是一个好的 Agent 应该是尽可能的去不让用户动脑子的一个产品 。 那这个怎么理解呢 ？
就是说我们可以来看上个时代的产品怎么样子 。 那上个时代的话 ， 我们会看到一个产品功能越多 ， 它就能够解决的问题越复杂 ，但用户学习理解使用这个软件的成本会越来越大 ， 就是用户的整个认知负担是会不断被加重的 。
但是 Agent 我觉得不一样 ，Agent 我觉得应该是一个让用户越简单 ，不用动脑子 ， 然后就能够用起来的一个产品 ， 然后它越强大 ， 它应该更懂用户的偏好 。
所以我觉得整个 Agent 的这个产品设计应该是得往这个方向去走的 。
就像是我能积累更多的 Context， 我有更多的用户的数据 ， 用户的意图识别 ， 我还知道怎么样在适合的时间问出对的问题 。
是 ， 所以说从这个角度出发的话 ， 我觉得其中我自己的一个跟大家可能现在有些不一样的观点是 ， 大家现在可能会想说 Chat 到底是不是一个对于 Agent 来讲好的一个交互形态 。
我认为其实这个聊天框就是最最最重要的一个交互入口 。 因为我觉得对于一个 Agent 产品来讲 ， 用户交互的自由度是远远要比用户交互的准确度要来的关键 。
就是用户想怎么讲都可以 ， 对吧 ？ 如果你一旦限制用户交互自由度 ， 对用户来讲就说他得要习惯你 ，而不是你习惯用户 ， 那这时候用户的这个认知负担就加重了 。
所以我认为 Agent 产品用户交互的自由度是第一重要的东西 。 那从目前看到形态里面来看 ， 什么样的这个形态是最有助于用户交互自由度提高的 ？
其实就是这么一个聊天框 ， 它说什么都行 。 那难道用户交互的准确度不重要吗 ？ 其实也很重要 。 就是现在大家都讲说我需要写了一个很好的一个 Prompt， 那这个其实就是说你准确度的问题嘛 。
但是我觉得你作为开发者或者说产品设计者而言 ，其实有很多的方法能够辅助提高这个准确度的 。
那比如说 Human in the Loop， 包括说你可能记录了一些用户的偏好 ， 就现在 Devin 也好 ，Manus 也好 ， 它能够积累一些知识下来 ， 那知识可能就是用户的偏好 。其实你可以在产品设计里面不断的去做一些向用户提问的问题 ， 比如说它要提供一个比较模糊的东西 ， 然后你去跟它不断的去澄清 ， 然后具体 ， 然后 Detail， 到最后这个东西逐渐就变准确了 。
所以从这个角度出发的话 ，由于你有很多的方法可以提高用户交互的准确度 ， 那其实这应该是你作为产品开发者需要考虑的事 。
你不能把这任务交给用户 ， 我们要做的是怎么让你这个产品更智能 ， 让用户就像一个非常幸福的小朋友一样能够用你的产品 。
这个就又有点那个所谓的 Web Coding 的那种感觉了 ， 就是让用户在那个 Web 里面心流的那个状态 。
对 ， 你可能感受不到时间的流逝 ， 你不需要动脑子 ， 你就感觉自己坐在那就是一个非常放松的一个状态 。
最后事情就做完了 。
对 ， 然后事情就做完了 ， 我觉得 Agent 就应该做到这点 。 所有实现不了这个承诺 ， 或者在设计上没有这种意识的 Agent 产品 ， 我觉得都是伪 Agent。
所以说聊天框就是最好的交互形态 ， 你不需要加额外的接口 ， 你不需要再加其他的组件 ， 你只需要做的事情是你把合适的一个组件在适当的时机跳到用户面前 ， 然后让它去交互 。
就比如说可能你在后台设计的底层代码时间里面可能有 200 个组件 ， 那这 200 个组件可能对部分用户来讲 ，他可能一直只能看到 10 个 ， 那剩下 190 个他用不到 ， 用不到就意味着不会影响这个用户的理解 。
这个我是同意的 ， 我觉得如果纯是聊天框不一定是最高效的方式 ，但是我觉得它在适时的时候推出一个合适的产品界面 ， 能让用户去选 ， 应该是一个很合理的选择 。
所以总结一下我觉得首先意图识别是特别重要的 ， 首先得知道用户到底要干嘛 。
是的 。
当然这个我觉得 Context 是两个互相印证的吧 ， 就是我如果 Context 足够多 ， 我可能能猜到用户要干嘛 。
是的 。
或者用户要告诉我要干嘛以后呢 ， 我还是要收集更多的 Context 来帮助用户完成 ，以及说我要知道中间有哪些问题是要提出来的 。
所以这里面很重要一点就是你自己的模型得有能力判断当前的 Context 是不是足够的 。 如果不够 ， 你应该在环境里面通过环境给你提供的 API 你自动去 Get， 无论是 RAG 也好 ， 或者什么样的方式也好 。
这个我觉得跟模型的智能是相关 ， 另外可能也是跟垂直领域的 Know-how 是相关的 。
其实这里面有一个点就是 System Prompt， 那 System Prompt 其实就是你作为这个 Agent 的开发者你需要去负责的东西 。 那 System Prompt 基本上现在像我们看 Cursor 也好 ，Windsor 也好 ， 你会发现他们 System Prompt 非常长 ， 几千行 。
对 ， 就是预置的 Prompt 嘛 。
对 。
而且我觉得这个确实是在垂直领域里面才成立的东西 ，因为我只有知道它上来要干嘛 ， 我才能 。
写好这个 System Prompt。
对 ，而且我必须要了解这个领域 ， 我可能才能写得更好 。 比如说就举研究的例子 ， 我就是知道说它肯定是要去搜网页 ， 肯定要去搜集一些数据跟文章 ， 然后它肯定要把其中的一些东西要摘出来 ， 把这些东西再放到不管 Excel 还是一个 PPT， 一个什么这样的报告里面 。
我知道它一定会做这几步 ， 所以我可以针对每一步去做优化 ， 去提前预置好我的 Prompt 等等这些东西 。
是的 。
但如果这个东西它不是一个比如说研究类的 Agent， 它是个通用 Agent 的话 ， 这个人上来他有可能是想做研究 ，有可能想做个动画片 ，也可能想生成个什么东西 ， 那这个准确率一下子就下降了 。
对 ，因为它可能尽管每一步就 90% 成功率 ，但是若干步骤以后它是一个成数的一个关系 ，而不像垂直 Agent 的 。 首先第一个 ， 它可以把每一步的成功率提到 100%。
第二个 ， 它哪怕出现问题了 ， 它也不会说上一步会影响下一步的结果 。
所以我记得之前好像是苹果吧 ， 还是谁 ，他做过一个事情是说 ， 就你打开这个网页的上一步你是在看什么网页 ，也是一种 Context。
对 ，其实就是我们讲 Context 里面包括历史的对话信息嘛 ， 那其实历史对话信息只是说人看到的历史对话信息 ， 那其实对于机器人它在你没看到的后台可能访问了很多个网页 ， 相当于说我当前的这个状态其实由我过去做的所有的事情所决定的 。
那我过去所有的这些事情 ， 包括我做了什么 ， 我看了什么 ， 我发了什么 ， 整体而言构成了现在的这么一个状态 ， 那这个状态的整个集合其实就是所有的上下文 ，其实就是 Context。
对 ， 然后包括 OpenAI 最近刚出的那个它的记忆系统其实也是一种 Context 嘛 。
对对对 。
所以我总结我觉得就是如果起手的时候能有更多的 Context 肯定是最好的 。 你看我前几周跟张宇光吃了顿饭 ， 我觉得他提了一个点就特别好 ，他就说当你点开某一个 APP 的时候 ， 就打开你一下 ，其实就已经提供了海量的 Context。
是的是的 。
我点美团我就告诉他我要点外卖了 ， 然后我点滴滴我就告诉他我要打车了 。
对 。
然后这个产品里面的所有的东西是基于这个 Context 来设计的 。
对 ，因为这个样子的话相当于把大家去拉到了一个共同的氛围下面 。
对 ， 就把意图识别收集到 ， 然后再在跟它交互和做的过程当中不断的去积累 Context。
是的 。
然后这 Context 有可能是有用户的信息 ，有各种你在执行流程当中的信息 ， 然后有各种网站各种环境的信息等等 ， 对吧 ？
所有的这一切都集合起来 ， 然后去继续去识别意图 ， 然后去判断中间哪一步可能会遇到什么问题 ， 然后再问用户准确的问题 。
对 ， 就是我们说你想更好的了解一个人， 你就去看他的过去 ； 你更好的想了解用户的意图 ， 你就去看他从哪里来 ，他中间的路径是怎么样的 ， 你把这些路径都需要保存下来 。
所以 Google 很早就在保存 Cache 嘛 。
对 ， 所以这个就是 Google 在 AI Native 时代最大的竞争优势 ， 它是有一大堆的用户的点击的数据 ， 然后可以去帮忙去分析意图的 。
对 ， 就包括其实大家讲说到底数据对 Agent 这么重要 ， 数据这个东西还是很重要 ，但我觉得有一个限制条件是说它得是高质量的数据 。
那什么是高质量的数据 ？ 高质量的数据是说我不仅要知道数据的输入是什么 ， 我还得要知道结果是什么 ， 我同时更要知道从输入到输出中间发生的一些事情 ， 中间的这种各个变化的数据是什么 。
只有这些数据综合在一起 ， 就是它其实是一个数据序列 ， 这个就很关键 。 比如说下围棋 ， 我只知道这一步棋怎么下， 不关键 ， 重要的是我得知道前面他 100 手棋是怎么下的 ， 最后才可能说下这一步棋 ， 从而我能够推理到后面几步棋它是怎么样的 。
这个时候整个的这个过程的这个数据 ， 这个棋盘盘面怎么来的 ， 才是最关键的 。
那我们再回到刚才那个地方 ， 就是有没有技术或产品上的点 。
我觉得 Prediagnosis Fit 很重要 ， 就是你得要能够去理解到现在模型的边界 ， 上限在哪 ， 对吧 ？ 哪怕是现在最先进的 O1， 还有就是 3.7 也好 ， 你得要知道在极限情况下你想做的那个事情 ， 它能不能给你做到 。
产品实践31:54
对 ， 这个顺便可以聊一下你们现在在做的产品 ， 你之前给我授过一个你们的 Demo 嘛 。
对 。
我觉得这个点上可能就是你刚才讲那个相关的一个延伸 ， 就是你们选了一个方向是基本是已经实现的一个东西嘛 。
对 。
其他的好多做 Agent 的我觉得还是在偏讲故事的阶段 ， 所以你可以给大家介绍一下你们目前的一些产品吧 。
我们的产品其实是一个 AI Agent， 然后我们的目标呢是把整个的数据收集 ， 然后到数据处理 ，以及到最后基于数据的行动 ， 整个链路都闭环 。
然后我们现在呢其实是在数据的收集处理这上面其实已经做得比较好了 。
大概的它使用的场景会是怎么样的 ？ 能不能举一两个例子 ？
首先第一个场景的话 ， 就比如说是你需要去找一些泄露线索 ， 比如说我们的一个用户现在是他们有很多的这个开源用户 ，他们希望知道这些开源用户是哪些公司的 ，因为他们很有可能想把他们自己的商业化的版本去卖到这个公司里面去 。
那以前这个事情其实没有办法做的 ， 就是你只能可能人肉的一个一个去分析 ，但现在的话模型是能够做这个事情的 。
具体怎么做呢 ？
其实就是我们会进入到用户的 GitHub 的主页上面去 ，在主页上面去分析他有没有一些可能跟他是哪些公司的一些线索 ， 比如说代码提交记录 ， 或者他自己的一些社交媒体账号 。
如果有社交媒体账号 ， 我们会进入到社交媒体账号里面再去看他有没有公司信息 。其实跟人去手动翻它是一样的 ， 我们是模拟的人的这么一个过程 。
OK。 还有别的例子吗 ？
另外一个例子就比如说是找到 YC 他们最近几个 Batch 的公司列表 ， 然后再找到公司列表的这个创始人， 然后再找到创始人的 Twitter 去关注一下， 然后给他们发个私信 。
然后由于我们用一些 AI Coding 的一些技术 ， 所以我们能够保证这个流程是 100% 准确的 。 实际我们也跟 Developer Research 的产品 ， 还有什么 Manus 的产品对比了一下 ，他们其实并不能保证这些公司一个不落的抓取下来 。
这是一个点 。 第二点的话 ，其实我拿到数据以后， 我是需要有进一步的动作的 ， 就是我可能要去跟这个公司的创始人去建立一个联系 ， 跟他 Reach out 一下 。
但像 Developer Research 这样的产品 ， 它要报告生成完就是一个报告 ，在没有后面了 。
Manus 他们现在也不能做后面那步吗 ？ 他们可能可以啊 。
Manus 的话现在就是没有办法保证成功率 ，因为它是在中间动态随机生成的代码 ， 它需要不断的去做 Debug 跟调整 。
明白 。 那所以你们从技术上是怎么解决这个问题 ？
其实我们相当于自己内部做了很多的这种小的 Tool 嘛 ， 然后在让它去调用这些小的 Tool 的时候 ，因为这个 Tool 我们自己内部人是验过测过的 ， 所以它能够去保证 100% 准确 。
就是你给它提供了一些更好的工具 。
是的 ，而且这个工具呢其实因为我是程序员出身嘛 ， 所以我非常喜欢用一个词叫复用 。 如果有一个工具我下次用的时候 ， 我不是把它从头到尾重新写一遍代码 ，而是我把已经测试过的工具我用起来之后 ，其实效率是更高的 ， 成本更低的 。
但像 Manus 的话 ， 现在它没有这个机制 ， 它每次都是打开那个 IDE， 然后从 0 开始写代码 。
明白 。 所以这也就还是 AI Coding 的能力还不足够 100% 的准确率完成这件事情 ， 所以是人先去做了很多工作 ， 然后再让 AI 去调用这些工具 ， 会是一个更好的结果 。
对 ， 所以这就是你要选择通用性还是准确性的这么一个区别 。 你越通用就意味着你的方法要更泛化 ， 更泛化就意味着它随机性更高 。
我觉得这是 Trade-off 吧 。
对 ， 就是因为如果很通用的话 ， 团队自己要写超多量的一些工具和算法 。
对对对 ， 所以我觉得核心还是你怎么去更好的去利用这些工具 ， 比如说发邮件或者之类的 ， 你可能这种场景是比较简单 ，但如果你写一个比如说我们讲你数据库 ， 你有可能从头给它写一个吗 ？
不可能 。 你更好的是想我怎么去更好的方式 ， 然后以 MCP 也好 ， 或什么样其他方式也好 ， 我去在我的 Agent 里面跟数据库做交互 。
明白 。 然后我就紧接着想到另外一个问题啊 ， 就现在也开始有人在讲说 Workflow 是不是未来要被 Agent 颠覆掉了 。
那如果这么讲的话 ， 可能至少相当长时间内 Workflow 还是非常有价值的 。
因为我觉得这可能跟人性有关系吧 ， 大家在去聊一个事情的时候 ， 非常希望去把一个什么东西踩一下， 创造一种对立的视角 ， 然后无论是从流量角度或怎么样 ， 获得更多的眼球吧 。
那实际上我觉得 Agent 跟 Workflow 长期会处于一个共存的一个状态 。 那 Workflow 跟 Agent 的核心的区别其实很简单 ， 就是 Workflow 是人驱动的 ，Agent 是 AI 驱动的 。
那人驱动的好处是什么呢 ？ 好处就是它一定是稳定可靠靠谱的 ，但是它的缺点是在于说它不够泛化 。
那 Agent 的特点是反过来了嘛 ， 就 AI 驱动它足够的泛化 ， 它能够解决我之前没有想到的问题 ，但问题在于说十次里面它可能会有五次把这个事情搞砸 。
所以我觉得可能 AI 会负责 20% 更开放的问题 ，但剩下 80% 可能是更常见的问题 。 换言之其实 AI 主要负责常理 。
明白 。 所以你最终你们现在在做的产品跟其他的那些 Agent 的区别你觉得是什么 ？
我判断 Agent 不同的标准是我去看他们的 Delivered Result，而不是说大家好像看见一个事情都能干 。 对 ， 那从 Delivered Result 的角度去看的话 ， 你会发现 Genspark 也好 ，Developer Research 也好 ，Manus 也好 ，其实最后给大家呈现的主要的形式跟内容其实就是一个报告 。
当然 Manus 要做得更深入一点 ，他们有可能还给你呈现图表 ， 或者说是简单的一个网页 ，但我觉得这个只是报告的另外一种表现形式 ，但本质上而言它是给你提供了一个报告 。
所以我觉得从这个角度出发 ，其实我觉得大家都是调研 Agent。 那这个是一类 ，因为至少我目前没看到这个 Manus 可以帮我去美团下个单 ， 或者京东买个什么东西 。
另外一类的 Agent 呢 ， 就是所谓的 Coding Agent。 那 Coding Agent 的 Delivered 结果呢 ， 就是代码本身嘛 。
我觉得你刚才定义挺好的 ， 就是可能像 Manus、Genspark 什么 ， 它其实属于调研类 Agent。
对 。
然后还有一大类可能是 Coding Agent。
对 。
那你把自己定义成什么类 ？
我自己其实是个表格 Agent。 那我们之间的核心区别呢是说 ， 大家在去分析问题的时候 ， 一般来讲会有两种 Mindset。
第一种就是我可能只是说定性的去分析一下某一类问题 。 那定性分析一般来讲我可能就是用 Developer Research 这类的报告 ， 然后我去看一下大概是个什么样一个情况 ， 建立一种感觉 。
那另外一种分析场景呢 ，其实是定量的分析 ， 我需要知道一个非常准确的一个数字 。 那这个数字怎么能保证这个准确呢 ？
就一定是我得要这个分析的数据源是准确的 。 那这个数据源一般来讲就是一个比较完整干净的一个表格 。
那我们做的事情呢 ，其实就是把各种各样的数据源首先变成一个完整的表格 ，而不是说我就是用一个什么搜索的一个接口 ， 拿到各种各样的网页去做总结 。
对 ， 我们不是的 ， 我们是先把各种各样数据变成一个结构化的一个表格 ， 然后再拿这个表格去做下一步的分析 。
所以说我们之间是一个定性分析与定量分析的一个差异 。
对 。 所以你的核心是中间会有一个 AI 生成的表格 。
对 。
但你这个表格里的 ， 尤其是你们数据什么的 ， 会遇到 AI 我们经常讲的那些它的幻觉啊什么这些问题吗 ？
我们在工程上把这个问题已经解决了 。
OK。 然后我想到一件事啊 ， 就是是不是 AI Coding 它相当于是大模型的一个翻译跟一个助手的感觉 ？ 就是是不是所有的任务都中间可以加一点 AI Coding 来解决准确率的问题 ， 来解决所有的幻觉等等的问题 ？
我觉得是的 。 用现在比较时髦的话来讲 ， 我觉得 AI Coding 就是大模型的一个灵巧手 。 对 ，因为我们现在都在讲说 ， 如果让大模型不断的去做一个任务规划的话 ， 一旦它每个任务的成功率是 90%， 那可能十步以后它就是一个 0.9 的十次方 ， 它成功率就很低了 。
这样的话 ， 我们怎么去让上一步失败不影响下一步 ， 那可能我们就需要中间以代码的形式去运行它 。
因为代码我只要能保证 90% 成功率 ， 我可能十次里面九次成功 ， 我只要把九次成功那个代码我留下， 然后做一个正确的 Case， 然后我再进入到下一步 ， 那这个时候其实就能保证每一步都 100% 准确的 。
这个很合理啊 ，但这个因为我不知道你们从实际的操作和经验来讲 ，是每一个大模型的操作都应该先翻译成 Coding， 翻译成一段程序吗 ？
我觉得这地方还是想拿 MCP 来说例子吧 ，因为 MCP 背后调用的那些所有的 Tool 本质上全是代码 。 对 ， 所以从这个角度来回答曲老师你的问题来讲 ， 我的答案是是的 。
我想再回到刚才问过的一个问题是说 ， 你自己做了一年多 Agent， 然后你有什么能跟别人分享的吗 ？
对 ， 这个问题其实没讲完 。 刚才其实提到了 Prediagnosis Fit， 第二点我觉得很重要的就是你得想明白你给用户到底 Delivered Result 是什么 。
那你只有把 Result 想明白了之后， 你才能够不断的去通过设立起反馈的一个激励机制 ， 然后不断去优化这个结果 。
因为如果你这个事情想不明白 ， 它就不收敛 。 不收敛就意味着你可能 Deliver 那个结果就是一个比较差的一个质量 。
比如说像我们做 Datasheet 这个场景 ， 我们其实试过 Operator， 试过 Genspark， 试过 Grok， 你会发现它确实也能帮你 ， 比如说 YC 刚才提到的例子 ， 它确实也能生成 YC 公司的表格 ，但是你会发现那个表格永远是缺一些公司的 。
而且你让它去进一步的 ， 你想去知道公司的创始人是谁 ， 创始人是哪个学校的 ， 工作了多少年， 他的 Twitter 账号是谁 ， 它是完全解决不了这个问题的 。
就像我已经有了一个基本的数据之后， 我在这个数据上我进一步去分布我的数据 ， 它做不到 。 你只有把结果想明白了 ， 你才能够去不断的在基于第一步的结果的基础上去优化第二步结果 。
就是一旦你把结果想不明白 ， 你会发现你这个东西就 somehow 变成一个所谓的看起来有点像通用的一个 Agent。 我觉得另外一点还是很重要的就是 ， 我觉得做 Agent 的人呢 ， 要解决两个信任的问题 。
信任与未来41:41
第一个信任的问题呢 ，是你作为 Agent 的开发者 ， 你要足够的去相信大模型 。 那这个点会产生什么样的影响 ？
如果你不相信大模型 ， 你会做一个事情 ， 就是说你不断在代码里面加一些什么限制条件 ， 比如说就写 Prompt，Prompt 就是你就是个谁谁谁 ， 你只能干某某事情 ，不能干别的事情 。
那这种事的影响在于说 ， 你会发现大模型的整个的这个泛化能力其实被你人为的影响变低了 。
那用现在我自己的一个词来讲 ， 就是说你会导致你们的 Agent 对大模型的智能利用率下降 。
对 ， 我们跟人聊也经常会发现确实有这种例子 ， 就是本来在大模型上你是想去做更好 ， 然后封装很多东西 ， 最后反而做了半天可能不如我把这个需求直接放大模型里 。
对 ，是的是的 。 这个就是由于你自己对大模型不够的信任 ， 你作为开发者你会产生一种内心的不安感 ， 这种不安感会促使着你用一些传统的所谓 Rule-based 的方式解决这个问题 。
时间最后你会发现这是在开倒车 。 所以说 Agent 的开发者需要去解决自己内心对大模型的信任问题 。 另外一个点就是你得一定要想好你的这个产品该怎么通过设计去解决用户对你结果的信任 。
很好的一个例子的话 ， 我觉得还是 DeepSeek R1。 就是在 DeepSeek R1 之前 ，其实我用一些像 Developer Research 这样的产品 ， 它生成那个报告 ， 我在看到的第一眼 ， 我其实是会以一种更批判的角度去看说这个东西到底是对的还是错的 。
为什么呢 ？ 是因为我不理解它这个东西怎么来的 。 但是呢 ，R1 出来以后， 它把中间这个 Reading 的过程告诉我 ，在我心里让我更舒适的感觉说 ， 我看到它怎么想的 ， 所以我更愿意去信任这个结果 。
对 ， 我前几天跟朋友聊啊 ， 我就讲了一个事 ， 我说其实 Manus 很大的一个价值是它给所有的 Agent 的创业者打了个样 。
就也许过一段时间以后大家回头看 ， 就是 Manus 这个产品现在就好像当年的 Character.AI 一样 ， 就是让大家知道说 OK， 上一代的大模型那最适合的就是 Chatbot，Chatbot 就是类似 CAI 这样的产品形态 ， 对吧 ？
就是对话体大概就是这么做 ， 然后大家在这个基础之上去不断的怎么样改 。 然后现在的 Agent 呢 ， 可能很多都是在 Manus 那个基础上去不断的去修改 。
我不知道你怎么看这个问题 ， 就它是不是一个比较通用的一个产品形态 。
我觉得是的 。 我觉得 Manus 是在 Devin 的基础上 ，在 UI 世界上更进一步了 。其实核心就是它把中间所有的细节都暴露出来 ， 人看这个东西之后 ，他心里面就会存在一种满足感跟安全感 。
是 。 就你对于未来几年 Agent 的发展会有什么预测吗 ？
我觉得以现在 AI 发展速度去预测几年这么一个时间跨度 ， 我觉得太难了 。
预测半年到一年 。
对 ， 所以我其实是想分享一个框架 ， 就是跟大家一起去思考这个事情 。 首先想要去预测 ， 一定得要先去抓关键变量 。
那 Agent 这个事情里面关键变量是什么 ？ 其实前面也讲到了 ， 区分 Agent 的方法是去看它的结果的好坏 ， 通过结果的好坏来判断它到底是不是一个更专业的一个 Agent。
那结果呢 ，其实就是上下文 、Context 加 LM。 所以说我觉得核心变量就是这两个 ， 就是你想 Agent 的突破 ， 那你就要 Context 或者说 LM 至少有一个是突破了的 。
首先来看 LM， 那 LM 的下一个突破呢 ， 我觉得基本上也就是看 GPT-5 什么时候出来 。 那我觉得从时间节点上来讲 ， 我觉得可能 GPT-5 是在今年年底左右会出来 。
那可能年底的时候 ， 或者明年元旦之后， 我们可能发现 Agent 的能力会更进一步 。 这个是一个节点 。 另一个节点的话 ， 就是说 GPT-5 出来了以后， 什么时候成本会变成一出来的五分之一 ， 甚至说是十分之一 。
这个过程可能也得需要一年的时间 。
就比如说 DeepSeek R3。
Maybe。 我现在不知道它会有多大的突破哈 ，因为本质上我觉得这个事情还是得需要 Foundation Model 去做突破的 。
那也就是说可能比如说什么时候 DeepSeek V4 出来 ， 然后基于 V4 可能我再生成一个什么样的一个推理模型 。 所以我觉得这个是一个 ， 就是说你从模型的角度来讲 ， 第一个更先进的 Foundation Model 什么时候出来 ，以及说 Foundation Model 的成本什么时候能降下来 。
因为 Foundation Model 出来了之后， 我们就能做 Demo 了 。Demo 有了之后， 大家就有预期了 。 但是只有到成本降低之后， 这个东西才能规模化使用 。
所以我觉得接下来真正很好用的 Coding Agent 以外的 Agent 出来 ， 我觉得可能还是得到 26 年的下半年， 就是大规模的大家真正能用上啊 。
这个是一块 。 另一块的话 ， 我觉得就是从 Context 角度来出发 ，其实也可以来看个例子 ， 就是 Cursor。 它为了把整个 Coding 这个事情的 Context 做好 ， 围绕 VS Code 其实做了大量的 ARCS 开发 。他们是从 22 年开始 ， 然后到去年下半年， 其中间是花了一年半的时间 。
这里面呢 ， 我觉得工程量是非常大的 。 我觉得这也是大家现在普遍的 ， 我认为的一个误解 ， 就是会觉得 Agent 是个 Talker，其实我觉得不是 。Agent 里面的这工程复杂度 ， 我觉得是远远超出大家想象的 。
你想让 Agent 在 Context 这个层面去做突破 ， 你是需要大量的工程上的尝试跟积累的 。 所以说我们从现在这个时间点去看的话 ， 就是假如说 DeepSeek 出来之后， 大家第二天立马开始干这个 Agent， 然后优秀的团队干得快点 ， 我觉得也得要六个月 ， 就慢一点就可能就一年了 。
所以说可能到今年的 Q3 吧 ， 我觉得可能会有一些更好的 Agent 的一个产品出来 。
如何判断47:16
我再补一个问题 ，因为你都在讲到说判断 Agent 就是它的 Result 怎么样嘛 ，但 Result 好的就一定是说这个 Agent 公司好吗 ？
因为有可能有的公司它就是通过各种手段 ， 可能它就是某一个 Prompt 写得特别好 ， 然后它的 Result 在阶段性的就更好 。
所以我想说 ， 如果假设你是投资人的话 ， 现在你面前有好多做 Agent 的公司 ， 你会问哪几个问题来判断这家公司的好坏 ？
因为投资人现在遇到各种公司 ， 对吧 ？ 来了就是一个挺好 Profile 的 Founder， 对吧 ？ 然后可能有一个算法或者什么技术的挺好背景的一个人， 然后讲说我要做某某领域的 Agent， 然后其他的讲的东西呢 ，其实大差不差 ，也都差不多 。
那其实我会先问就一个问题 ， 我就会看他们团队里面有没有人就看过前面提到的那个 ， 就是 Sutton 那本书 。
因为我觉得你只要看过这个书 ， 你就一定会有这种 Mindset 的 。 有这种 Mindset 的人 ，他一定不会去能够长期容忍我用一些非常符号主义的那套方法去达到一个结果 。
但你这个要求可能有点高了 ，有很多人可能凑巧就没看过那本书嘛 。
那我其实就会可能问一个事情 ， 就是你的产品里面的环境反馈的激励信号是怎么设计的 ？ 对 ， 就是到底在你的产品里面 ， 什么样子的一个行为是一个好的行为 ， 什么样的一个行为是一个差的一个行为 。
我觉得这个问题很关键 ，因为有了这个信号之后， 你才能够让大模型去迭代 ， 就是说把上一轮的结果跟环境提供的这个好与坏的评价丢给大模型 ， 让大模型再去迭代一轮 。
从这个角度来讲 ， 确实通用好像就不如垂直 ， 通用你很难定义这个东西了 。
对 ， 就是这里面补充一个点 ， 就是说大家现在觉得有大模型之后， 结构化数据这个事情不重要了 。
不 ， 它其实还很重要 ，因为大模型的输入我们可以是非结构化的 ， 就是我把什么乱七八糟的文档 、 文本 、PDF、 图片我一股脑塞进去 ，但是大模型的输出一定得是结构化的 。
因为你只有结构化了 ， 你才能够去用代码或者说是规则那一套东西去校验 ， 要不然它是没有办法去校验的 。
所以说你的这个激励信号其实最后在代码上体现来讲的话 ， 就是你大模型里面输出的结果里面可能某个字段的值到底是什么 。
对 ， 就是你这套标准是什么 。 所以我觉得让我问的话 ， 我会问这样的一个问题 。
Manus 的激励信号可能是什么 ？ 如果你负责 Manus 这个产品的话 。
我想不到 。 因为现在他们官网的那些例子我看下来 ，其实本质上的判断还是在让大模型本身 ， 或者我写了另外一个 Prompt， 然后去判断说这个东西是好的一个结果还是坏的一个结果 。
但实际上如果大家去用 ChatGPT-4G 的产品 ， 你让它比如说我最近在写 PPT， 写了一段这个开场白 ， 然后我让它不断优化开场白 ， 我给它说不满意你改 ，不满意你改 ， 你只是说提供这样的一个 feedback 的话 ， 你会发现它最后是陷入一个奇怪的一个死循环里面 ， 它是出不来的 。
所以一定得要给它提供大模型本身所不具备的那些反馈信号 ， 我觉得它才能够把这个结果从这个死循环里面跑出来 。
所以如果我问你这个问题 ， 你们自己产品的那个反馈信号是什么 ？
其实我可以讲一点吧 ， 就是我们取数据这个事情不存在 hallucination， 就是因为我们其实让大模型负责的是整个页面结构的分析 ， 然后还有页面与页面之间关系的分析 。
通过这些分析的结果 ， 我会生成一段脚本 ， 然后正儿八经的其实往下来收集数据 ， 生成数据的这个过程其实是用代码实现的 。
那代码其实就是一个典型的能够给我提供反馈信号的这么一个机制 ， 这是一个点 。 另一个点的话 ， 表格这个东西啊 ，其实很直观 ， 一个地方是空的 ， 我一眼就能看见 ， 那其实这个也是一个反馈信号 。
明白 ， 很合理我觉得 。
对对对 ，因为跟报告不一样 ， 报告那个东西就是你很难去精确的去描述到说哪一行哪一个字怎么样 ，但表格的话由于是个结构化的 ， 所以我是可以去描述它的 。
好 ， 我觉得今天我们其实讨论了很多 Agent 相关的问题吧 ， 我相信把那些大家核心关注的问题都比较快速直接的去 cover 到了 ， 然后包括文锋也提了一些他自己做这么长时间 Agent 的一些经验吧 。
结尾51:26
我最后一个问题啊 ， 给大家三个理由说同样场景之下为什么用你们而不用 Manus 或者 Genspark 或者其他的工具产品 。
其实我觉得都不用三个 ， 就是你只要有对于高质量数据抓取的需求 ， 你会发现现在市面上的 Agent 产品只有我们的产品可以做到 。
就是百分百准确率 。
对 ， 百分百准确率 ， 然后百分百稳定 ， 百分百不给你丢数据 。
OK， 所以什么时候大家可以用到 ？
在这周的时候我们就会开放线上的 waiting list， 差不多大家注册 waiting list 以后， 可能在两到四周的左右时间 ， 你就会能够正儿八经的使用我们的产品 。
大家可以去访问我们的官方网站实际体验一下 。
以防大家不太知道怎么拼 ，shet0.com。
就是表格的那个单词嘛 。
OK， 好 ， 那谢谢文锋 。
好 ，也谢谢曲老师
。