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

今天北京风特别大啊，感谢文峰今天还跑过来录这期播客。正如北京的大风，今年 AI 最热的风口，今天就是 Agent 了。文峰正好做了蛮长时间的 Agent，你可以跟大家介绍一下自己。

大家好，我是王文锋，一个做了 2 年 Agent 的程序员出身的创业者，同时也是徐老师的粉丝。我们现在做的产品是 Data Agent。

1. Defining The Agent

现在大家都在讲各种各样的 Agent，但 Agent 到底怎么定义？我觉得最好的定义是 Anthropic 的一个定义：Agent 是模型基于环境反馈去使用工具的一个程序。

这里面其实有 3 个点需要拆开说。第一点是模型，这个大家最容易理解。第二点是环境反馈，这个很关键。第三点是工具，也就是说 Agent 需要去采取行动，而采取行动其实是通过调用工具来实现的。

所以你怎么看最近这波 Agent 的热潮？

我觉得这波 Agent 跟过去非常不一样的一点是，这次 Agent 真正能够解决实际问题了。

上一轮大家讨论 Agent 的时候，其实是在 2023 年 4 月，当时代表性的产品是 AutoGPT。但当时它更多可能是一个玩具，并没有真正解决什么实际问题。经过 2 年的发展，Agent 现在真的已经落地了，而且在实际的工作和生活场景里面给大家带来了真正的价值。

这 2 年主要的变化，你觉得是什么？

2. Context Drives The Breakthrough

我看到的有两点。第一点，底层模型确实有了非常大的进步，尤其是 o1 出来之后，给 Agent 带来了长思维能力，主要是因为强化学习在决策上的使用。

第二点，可能是大家没有关注到的，就是 Agent 工程也有了非常大的突破：怎么去给 Agent 更好地构建一个合适的 Context，然后去解决问题。我觉得这是工程侧或者产品侧的一个进展。

所以你刚才说，第一点是模型的进展，第二点是 Agent 的 Context。Context 这个怎么理解？

Context 其实是定义了所有大模型需要利用的信息的总和。

比如说以代码为例，它包括整个代码库的结构、代码库的源文件代码，还有整个代码库里面有哪些 API 可以使用，包括人类的输入，这些都算 Context。

再举一个具体的产品例子。每家的产品 Context 都不一样。以我们产品为例，我们的产品是一个帮助大家收集数据、分析数据的 Agent。对我们而言，Context 包括网页、我们帮用户收集过来的数据表格、用户想要什么样的数据，也就是那句 Prompt，还包括我们分析数据时生成的 SQL，这些其实都是 Context。

这些 Context 都是比较琐碎的东西，大家加在一起形成一个整体。我把这些信息一起输入给大模型，让大模型判断应该给用户一个什么样的结果。

我明白。但我在想，这些过程当中的信息被留下来再使用，不管是加到 Prompt 里还是 RAG 里面，这不是之前本来就应该约定俗成的一套做法吗？

其实核心是：这些 Context 从哪里来？

比如我刚才举的网页，网页里面一般有很多无关紧要的信息。首先，我怎么把自己关注的信息抽取出来，这是一部分。另一方面，比如我要生成 SQL，这个 SQL 怎么保证准确？我需要去校验。校验的话就需要利用数据库，判断一条 SQL 能不能执行成功。

这些信息需要以某种自动化的形式被提炼出来。以前用 RAG 也好，还是其他方法也好，这些信息的主要输入来源是人。Agent 更强调的是，我的信息来源是通过某种自动化的方式获取到的。

我觉得我们先把一些基础概念快速介绍一下。大家经常听到很多概念，比如 Function Calling、MCP，包括 Google 前两天出的 A2A，还有所谓的 Computer Use、Browser Use 等等各种说法。

在你看来，这些东西应该怎么分类？有没有什么优劣之分？

3. The Tool Use Stack

刚才曲老师提到的 Function Calling、MCP、A2A、Browser Use，这些其实都在解决同一件事：给大模型提供更好的使用工具的方法，让大模型更好地采取行动。

这里面的区别是什么？你可以理解为，Function Calling 是最早由 OpenAI 提出来的一套让大模型使用工具的方法，可以理解为 0.1 版本。MCP 在这个基础之上又进了一步，可以理解为大模型使用工具的 0.2 版本。

但 MCP 非常大的作用在于，它类似于统一度量衡。以前大家使用工具的标准不一样，相当于每个国家可能都有自己的一套度量衡。到了另外一个国家之后，就得重新学一遍。但 MCP 把这件事标准化了，相当于有了一个放之四海而皆准的方法，大家都可以调用任何人的工具，整个事情的门槛一下子降低了。

然后是 A2A。我觉得 A2A 没什么意思，更像是一个 KPI 工程。A2A 自己定位和 MCP 的区别是，MCP 只能跟其他工具或者 API 交互，而 A2A 说的是 Agent 之间可以交互。

但从开发者的角度来讲，这件事没有区别。Agent 其实也可以定义成一个工具，它可能有一个调用函数的入口。这个东西用 MCP 包装一下，也可以被其他 Agent 调用，也可以纳入 MCP 的范围之内。

所以从这个角度来讲，我觉得 A2A 属于强行造了一个自己的概念，然后找了一堆合作伙伴来推动这个东西。本质上是一种标准化话语权的争夺。从工程师的角度来讲，我们更喜欢 MCP，A2A 并没有提供新的东西。

Browser Use 强调的是把浏览器当作一个工具，让大模型去调用。全世界有成千上万的工具，浏览器可能是最重要的工具之一。

我现在听起来，整体好像分成两派。一派是直接用代码来解决问题，我理解不管是 MCP 还是 A2A，都是用代码解决问题。另一派是模拟人去解决问题，不管是 Computer Use 还是 Browser Use，其实都是通过视觉识别加上一些 RPA 的方案来解决。

4. API Versus GUI

其实这两者并不矛盾，你也可以用 MCP 的方式去进行所谓的 Browser Use。

实际上，我们使用 Browser Use 的一种方式，就是纯粹通过图像 GUI。比如推算出某一个坐标，把鼠标移到这个坐标上，点击一下，或者输入一些东西。但这个方案远远不成熟。

国外有一家叫 Adept 的公司，在 2023 年、2024 年非常火，但实际上公司已经停摆了，就是因为这件事太难。所以现在大家使用浏览器时，其实也是通过浏览器 API，把它包装成一个类似 MCP 的工具，然后再通过代码去调用这个浏览器。

明白了。其实它前面类似于演了一场戏给人看，背后还是用的那些东西。因为 MCP 跟 Browser Use 是两个正交的东西，互不影响。

但现在是不是有一个问题：很多公司没有兼容 MCP，甚至往后走，有些公司为了保护自己的用户和数据，也不会兼容。所以有些产品可能必须使用真正模拟人的方式来操作。

首先，正儿八经使用 MCP 的标准姿势是什么？

假如我是开发者，现在想用 MCP 去使用某一个 SaaS 软件，其实不需要 SaaS 软件本身支持 MCP，也不需要它已经提供一个 MCP 接口。因为 MCP 是一个标准化的东西，我可以按照这个 SaaS 软件开放出来的 OpenAPI，在 OpenAPI 之上包一层，就可以把它当成 MCP 使用。

所以前提在于，这个 SaaS 有没有 OpenAPI。OpenAPI 在国外的软件生态里基本算是标配，几乎所有 SaaS 都会有，但国内大多还没有。

如果这个 SaaS 产品或者其他软件确实没有开放 OpenAPI 或者 SDK，那确实没办法用代码的形式去调用。但这时也可以尝试视觉的方式。比如使用浏览器，把浏览器截图传给大模型，让大模型判断上面的交互元素，把坐标算出来，再通过鼠标和键盘去控制。

这两种办法就是 API 和 GUI，取决于什么场景下更高效。

所以简单可以得到一个结论：如果未来 MCP 或者后端的各种接口支持，那直接调用就可以了。如果不支持，就只能通过视觉和模拟人使用电脑的方式来解决。

对，而且我觉得这里还有一点：每个 Agent 想解决的问题可能不太一样。所以具体哪个部分占的比例更高，可能需要 Agent 开发者根据自己的需求进行配比。

另外，视觉方式虽然现在稳定性和准确度没有 API 方式高，但它有一个好处，就是成本低。我们自己的产品其实两种方法都用了。实际体验下来，给它截一个图，让它去判断，速度更快，而且 Token 消耗量也会少很多，至少会少一个数量级。

问题是，GUI 生成的结果有时会不准确。比如图片上有一个提交表单的按钮，很多时候它可能会把坐标位置算错。

我前几周在美国的时候，有一个非常专业的 Agent 算法从业者问了我一个问题。他说他非常不理解为什么 Manus 要用浏览器来做这件事。在他的理解里，后端的代码什么都可以接通，直接实现就行。

如果是你的话，你会怎么回答这个问题？因为我看你们的产品里，其实也用了类似 Manus 的逻辑。

5. Trust Through Transparency

我觉得可以从两个视角回答这个问题：一方面是技术视角，另一方面是产品视角。

技术视角上，简单说，使用浏览器这种方式，成本会更低一些。

另外，让 Agent 生成结果，还有一个很重要的点：用户是不是信任这个结果？我们让用户使用 Agent 的过程中，怎么营造一种可信的氛围感，这非常关键。

其中一个重要手段，就是让用户全程看到我是怎么帮你完成工作的，让他看到其中的每个细节，而且这些细节是以他能理解的方式呈现出来的。浏览器天然是对人友好的视觉化呈现方式，相比代码那种看起来黑乎乎的窗口，要更生动、更直观。

Devin 算是哪种方案？

Devin 其实是纯 Coding 的方案，但它也有 Computer Use。

Manus 是典型的 Coding 和 Browser Use 结合。最近 Genspark 新出的产品，我不知道你看没看？

我看了一些。

你觉得它是什么方案？跟 Manus 很类似吗？

稍微有点不一样。我自己跑了一些任务，没有看到特别多像 Devin 或者 Manus 那样、肉眼能看到的浏览器，也没有感觉它是在前端操作，更像是在后端运行。它应该也会用一些网页 API，但没有把这个过程暴露给用户。

所以我觉得它可能还不是我心目中的那种 Agent。

但从用户视角来讲，你最后帮我解决问题就好了。我为什么要在意你到底在哪里跑了什么，或者你是不是很 fancy 地像人在使用电脑、使用浏览器？

这是一个非常好的问题。

从我的视角来讲，举个例子。比如曲老师，我们两个是同事，那我们之间应该怎么建立信任关系？我觉得更重要的办法是，假如你给我分配一个任务，你能看到我是怎么做这件事的，之后也知道我大概是什么思路。相当于你足够了解我之后，才会对我产生信任。

我觉得这个逻辑是成立的。包括 Manus 这种产品，我觉得核心问题在于，大家还是觉得 Agent 没有准备好、不靠谱。所以我需要把过程中的东西展示给你，同时不断把人引入进来，让人时刻感受到自己在掌控一切。

这跟人是一样的。大家其实都会有一种不安全感，怎么给人建立起安全感的边界？把一切做透明是很关键的。

但我自己用 Manus 的时候，也会觉得它有一个缺点：有时候它跑着跑着会提一个问题，我可能没看到，也没管。本来等了半小时、一小时，以为它要跑完了，回来一看，它可能还在第二步问问题。

这个在 UI 上还是可以优化的。

另外，这也可能是他们现阶段的一个问题。后面比如给你发邮件、短信，或者跟你平时工作使用的即时通信工具打通之后，你就能以更容易看到的方式收到通知。所以我觉得这不是什么大问题。

总结一下，不管是什么 Use，还是 Coding，都是当前 Agent 可以使用的工具。根据不同场景，目前大多是一个组合方案来实现一些事情。

是的。

最终你觉得，比如 AI Coding 和现在大家讲的 Agent，未来是不是一件事情？

过去半年里，市场上最热、拿到最多钱的两条赛道就是 Agent 和 AI Coding。本来我觉得这是两件分开的事情，但越看越觉得，未来它们可能会走到一起。

现在很多 Agent 也在用 AI Coding 的解决方案，AI Coding 里面也在讲，Coding 是整个互联网、整个一切的基础设施。这两天我还看到一个新闻，说 Coding 可能也是未来 AGI 的一个基础。理论上确实如此。

举一个可能不太恰当的极端例子，Browser Use 可以让 AI Coding 自己做一个浏览器，然后自己使用。

6. Coding As A Tool

理论上是这样，只是涉及复用、经济性和时间成本的问题。

AI Coding 我认为只能说是大模型的一个工具。这里面有两个点很关键：第一是协作，第二是复用。

现在大家讲 AI Coding，通常是说我有一个问题，把它拆解，拆解完之后每个子问题都写一个程序跑起来。相当于这件事从头到尾都是我自己做的，实际上这是一个非常低效、非常消耗成本的事情。

现代化的软件开发非常强调复用，本质上是为了让事情更高效。对于 Agent 来说，最优的选择是：我现在解决一个问题，首先去看手边有没有可以直接使用的工具。

如果 Agent 找了一圈之后发现没有可以直接拿来用的工具，这时候它可以再退化到 AI Coding 方案，现场造一个自己独特的工具出来。

所以我觉得它们之间是这样的关系。

所以你觉得 AI Coding 可能是对 Agent 的一个补充？

对，是一个很有力的工具。

另外一个问题，我自己觉得当下市场对于 Agent 的讨论和理解，跟 2 年前大家对于大模型的讨论有点像。

当时大家在问，会不会有一个通用的 AGI 模型，还是会有垂直模型，或者很多创业公司要做自己的小模型。现在大家也开始讨论，未来是通用 Agent，还是垂直 Agent。

你怎么看这个问题？

7. Why Vertical Agents Win

我觉得我们现在处于、也将长期处于一个所谓的垂直 Agent 时代。

我最近很喜欢举一个例子，比如做饭。很多人都会做饭，但大家的区别在于，假如曲老师和我做饭，可能就是拿出手机，打开菜谱软件，对着菜谱做一顿饭。但更好的 Agent，可能像五星级酒店的大厨。

我们能说自己跟五星级大厨是一样的吗？不能。核心区别是，人家做的饭从美观程度和美味程度上，都超出我们很多倍。人家是专业出身，我们可能只是一个会做饭的普通人。

至少从资本市场来讲，当你说要做一个 Agent，大家就会特别想问：有没有好的算法人才，后面怎么做强化学习，怎么做差异化。

从你的视角来看，强化学习这件事跟创业公司的关系是怎么样的？或者说，强化学习跟 Agent 的关系是什么？最后到底怎么应用？

8. Reinforcement Learning Blueprint

强化学习这个事情有几个点比较关键。

首先，Agent 这个概念就是从强化学习里面来的。所以不是说强化学习对 Agent 有多重要，而是说如果脱离强化学习这个领域，Agent 这个概念本身就不成立。

做产品的人一定要追根溯源，看看最早的 Agent 在强化学习里面是怎么定义的。

在强化学习里面，Agent 的定义主要有 3 个关键东西：第一个是状态，第二个是行动，第三个是激励信号。

怎么理解？实际上，状态就是我们前面一直强调的 Context。经过若干步骤之后，当前 Agent 处于什么情况，这里面包括它的记忆、它现在看到的东西。

Action 就是 Tool Use。现在有了判断之后，怎么把这个 Action 实际执行出来？它其实是通过函数调用的方式执行的。函数接口是代码与数字世界交互的媒介，所以这就是 Action。

最后是激励信号。Action 通过函数调用执行完之后，需要判断这一步做完，整个状态距离想要达到的目标是更近了，还是更远了。这其实就是正一和负一的区别：需要通过激励信号判断应该往左走还是往右走。

对于创业公司来说，非常关键的一点是，如何让产品变成一个环境。因为只有有了环境，才能描述强化学习里的状态是什么，以及可选的行动空间有多大。

程序里面的 Workflow 有多少节点，其实由行动空间决定。你还需要定义结果。为什么一定要把结果定义好？因为只有把结果定义好，它才能收敛。

只有能够收敛，才能让大模型判断一个行动做完之后，距离目标是更近了还是更远了。这样才能设计激励信号，不断让 Agent 一步、两步，一轮、两轮、三轮地自我迭代，直到实现目标。

具体建议是，我建议所有 Agent 的开发者或者产品设计者，都去看一下强化学习之父 Sutton 写的那本书。只有看完这本书，或者形成这样的 Mindset，才能在设计产品时不断思考、不断调整，定义好自己的 Environment。

在这个 Environment 里面，程序的状态是什么，行动空间有多大。通过这种方式，才能定义出一个能够自我迭代、基于动态情况不断修正路径，最后实现用户目标的程序。

所以我觉得，如果不理解强化学习，就很难理解 Agent 到底是什么；如果很难理解 Agent 到底是什么，就很难设计你的产品应该长什么样。

我们捋一下你刚才说的几个点。第一是状态，第二是行动，也就是 Tool Use，第三是奖励函数。

我觉得第二和第三个相对好理解。即使不是 Agent 领域，在所有模型领域里大家也都在讲，最重要的是评估体系的搭建，也就是评估标准。这个肯定是特别重要的一部分。

Tool Use 我们刚才也讲了很多，无非是在现有环境之下，不管是 Workflow、Agent 使用 Workflow、Browser Use 还是 Coding，各种方式都用上，看怎么样能把问题解决好。

第一个就是它的状态、环境或者 Context。那从这个角度来讲，IDE 肯定是一个特别好的环境。但 Manus 那种浏览器，你很难说它是一个多好的环境，相对来说不是一个通用工具。

对 Manus 来讲，浏览器不是它的环境，它的环境是 Ubuntu 系统下面的那个目录。

首先我们讨论一下，怎么定义一个环境是好还是坏。刚才讲强化学习里的 Agent 概念时，我们讲到奖励信号。环境的核心作用，是提供奖励信号的反馈机制。

所以要判断一个环境好不好，就要看这个环境能不能基于行动的结果，提供奖励信号。

IDE 为什么是好环境？因为它的学名叫集成开发环境。Agent 现在生成一段代码，可以立刻在这个环境里面运行一下。如果代码出错、跑不起来，IDE 就会生成错误信息。这个错误信息天然就是一个反馈信号。

Ubuntu 提供不了这种反馈机制，它更多是一个容器。为了构建反馈信号，可能还需要围绕 Ubuntu 自己搭一套东西出来。

你之前做了 1 年多 Agent。在这 1 年多里，你觉得跟今年新进入这个领域的人相比，大家对这件事的理解有哪些区别？你踩过哪些坑，可以跟大家分享一下？

9. Designing For Less Effort

有一个非常重要的点：一个好的 Agent，应该尽可能不让用户动脑子。

上个时代的产品，功能越多，能够解决的问题越复杂，但用户学习、理解和使用软件的成本也会越来越大，用户的认知负担会不断加重。

但 Agent 不一样。Agent 应该让用户越简单、越不用动脑子，就越能够使用起来；它越强大，就应该越懂用户的偏好。所以我觉得 Agent 的产品设计应该往这个方向走。

它应该能够积累更多 Context，拥有更多用户数据，识别用户意图，还知道如何在适当的时间问出正确的问题。

从这个角度出发，我有一个可能跟现在很多人不太一样的观点：大家现在会讨论，Chat 到底是不是一个对 AI 来说好的交互形态。我认为聊天框就是最重要的交互入口。

对于 Agent 产品来讲，用户交互的自由度远远比用户交互的准确度更关键。用户想怎么说都可以。如果限制用户的交互自由度，用户就得适应你，而不是你适应用户，用户的认知负担就会加重。

所以我认为，Agent 产品的用户交互自由度是第一重要的东西。

从目前看到的形态来看，什么样的形态最有助于提高用户交互的自由度？

其实就是一个聊天框，用户想说什么都可以。

难道用户交互的准确度不重要吗？

也很重要。现在大家都在讲要写一个好的 Prompt，这其实就是准确度的问题。

但作为开发者或者产品设计者，有很多方法可以辅助提高准确度。比如 Human-in-the-Loop，也可以记录用户的偏好。现在 Devin、Manus 都能够积累一些知识，这些知识可能就是用户偏好。

在产品设计里面，可以不断向用户提问。用户一开始提供的东西可能比较模糊，你就不断跟他澄清，从具体到细节，最后这件事逐渐变得准确。

由于有很多方法可以提高用户交互的准确度，所以这是产品开发者需要考虑的事情，不能把这个任务交给用户。我们要做的是让产品更智能，让用户像一个非常幸福的小朋友一样使用产品。

这又有点像所谓的 Vibe Coding：让用户进入心流状态，感受不到时间流逝，不需要动脑子，只是坐在那里，最后事情就做完了。

我觉得 Agent 就应该做到这一点。所有实现不了这个承诺，或者在设计上没有这种意识的 Agent 产品，我觉得都是伪 Agent。

所以聊天框是最好的交互形态。你不需要增加额外的接口，也不需要增加其他组件，只需要在适当的时机，把合适的组件展示给用户，让他去交互。

比如你在后台设计的底层代码里可能有 200 个组件，但对某个用户来说，他可能一直只能看到 10 个。剩下 190 个他用不到，而用不到就意味着不会影响这个用户的理解。

这一点我同意。如果纯粹是聊天框，不一定是最高效的方式，但我觉得在适当的时候推出一个合适的产品界面，让用户进行选择，应该是很合理的选择。

所以总结一下，我觉得首先意图识别特别重要，首先得知道用户到底要干什么。

对。

这个我觉得跟 Context 是两个互相印证的东西。如果 Context 足够多，可能就能猜到用户要干什么。

或者用户告诉我要做什么之后，我还要收集更多 Context 来帮助用户完成，也要知道中间有哪些问题需要提出来。

这里面很重要的一点是，模型得有能力判断当前 Context 是否足够。如果不够，就应该在环境里面通过环境提供的信息自动获取。无论是 RAG 还是其他方式，这跟模型的智能有关，也可能跟垂直领域的 Know-how 有关。

这里面有一个点，就是 System Prompt。

System Prompt 是 Agent 开发者需要负责的东西。现在像 Cursor、Windsurf，你会发现它们的 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 手棋是怎么下的，最后才可能理解为什么下这一步棋，从而推理后面几步棋应该怎么走。整个过程的数据，以及棋盘盘面是怎么形成的，才是最关键的。

我们再回到刚才那个问题。我觉得 Product-Model Fit 很重要：你得理解现在模型的边界和上限在哪里。哪怕是现在最先进的 o1，或者 3.7，你也得知道在极限情况下，你想做的事情它到底能不能做到。

顺便可以聊一下你们现在做的产品。你之前给我演示过一个 Demo。我觉得这可能是刚才那个话题的延伸：你们选的方向，基本上已经实现了一个可用的东西；其他很多做 Agent 的公司，我觉得还处在偏讲故事的阶段。

你可以给大家介绍一下你们目前的产品。

我们的产品是一个 Data Agent，目标是把数据收集、数据处理，以及最后基于数据的行动，整个链路闭环起来。

现在我们在数据收集和处理这两件事上已经做得比较好。

具体使用场景会是怎样的？能不能举一两个例子？

第一个场景，比如找销售线索。

我们的一个用户有很多开源用户，希望知道这些开源用户分别属于哪个公司，因为他们很可能想把自己的商业化版本卖给这些公司。以前这件事基本没办法做，只能人工一个个分析，但现在模型能够完成。

具体来说，我们会进入用户的 GitHub 主页，分析上面有没有能够判断他属于哪家公司的线索，比如代码提交记录，或者他自己的社交媒体账号。

如果有社交媒体账号，我们会进入社交媒体账号，继续查看有没有公司信息。整个过程跟人手动翻查是一样的，我们模拟了人的过程。

还有别的例子吗？

另一个例子是找到 YC 最近几个 Batch 的公司列表，再找到这些公司的创始人，找到创始人的 Twitter，关注他们，然后给他们发私信。

由于我们使用了一些 AI Coding 技术，所以能够保证这个流程 100% 准确。我们也跟 Deep Research 这类产品，以及 Manus 做过对比。他们其实不能保证这些公司一个不漏地抓取下来。

第二点是，拿到数据以后还需要进一步行动。比如我要跟公司的创始人建立联系，跟他 Reach Out 一下。但像 Deep Research 这样的产品，报告生成完就是报告，后面没有更多动作了。

Manus 现在也不能做后面那一步吗？他们好像可以。

Manus 现在没有办法保证成功率，因为它是在中间动态随机生成代码，需要不断 Debug 和调整。

明白。那你们从技术上是怎么解决这个问题的？

我们相当于在内部做了很多小工具。让 Agent 调用这些小工具时，因为这些工具都是我们内部人员验证、测试过的，所以能够保证 100% 准确。

就是给它提供了更好的工具。

对。而且因为我是程序员出身，所以我非常喜欢用一个词，叫复用。

如果有一个工具，下次使用时不是从头到尾重新写一遍代码，而是直接使用已经测试过的工具，效率就更高，成本也更低。

但 Manus 现在没有这个机制，它每次都是打开 IDE，从零开始写代码。

听下来，还是 AI Coding 的能力不足以 100% 准确地完成这件事。所以由人先做很多工作，再让 AI 调用这些工具，会得到更好的结果。

对，这就是要选择通用性还是准确性的区别。越通用，就意味着方法越泛化；越泛化，随机性就越高。

所以，如果很通用，团队自己要写非常多的工具和算法。

对对对。所以核心还是要看怎么更好地利用这些工具。

比如发邮件这样的场景比较简单，但如果是数据库，你不可能让它每次从头写一个数据库工具。更好的方式是想办法通过 MCP，或者其他方式，让 Agent 跟数据库交互。

我紧接着想到另外一个问题。现在也有人在讲，Workflow 是不是未来会被 Agent 颠覆。如果这么说，至少相当长时间内，Workflow 还是非常有价值的。

10. Workflow Meets Agents

我觉得这可能跟人性有关系。大家讨论一件事情时，非常希望把某个东西踩一下，创造一种对立视角，无论从流量角度还是其他角度，都能获得更多眼球。

但实际上，我觉得 Agent 和 Workflow 长期会处于共存状态。

Workflow 和 Agent 的核心区别很简单：Workflow 是人驱动的，Agent 是 AI 驱动的。

人驱动的好处是一定稳定、可靠、靠谱，但缺点是不够泛化。Agent 的特点则相反，AI 驱动意味着它足够泛化，能够解决之前没有想到的问题，但问题在于，10 次里面可能有 5 次把事情搞砸。

所以我觉得，AI 可能会负责 20% 更开放的问题，但剩下 80% 可能是更常见的问题。换句话说，AI 主要负责常规问题。

最终你们现在做的产品，跟其他 Agent 的区别是什么？

我判断 Agent 不同的标准，是看它 Delivered Result，而不是看起来好像什么事情都能干。

从 Delivered Result 的角度去看，你会发现 Genspark、Deep Research、Manus，最后呈现给大家的主要形式和内容其实都是一份报告。

当然，Manus 做得更深入一点，可能还会呈现图表或者一个简单的网页，但我觉得这只是报告的另一种表现形式。本质上，它提供的还是报告。

从这个角度出发，我觉得它们都是调研 Agent。这是一类 Agent。至少目前我们没看到 Manus 可以帮我去美团下单，或者去京东买东西。

另一类 Agent 是 Coding Agent。Coding Agent 最终交付的结果是代码本身。

你刚才这个定义挺好。Manus、Genspark 可能属于调研类 Agent，还有一大类是 Coding Agent。

那你把自己定义成什么类型？

我自己其实是一个表格 Agent。

我们的核心区别在于，大家分析问题时一般有两种 Mindset。

第一种是定性分析某一类问题。定性分析通常使用 Deep Research 之类的报告，了解大概情况，建立一种感觉。

第二种是定量分析，需要知道一个非常准确的数字。要保证数字准确，就必须保证分析所依据的数据源准确。数据源通常是一个完整、干净的表格。

我们做的事情，是先把各种各样的数据源变成一个完整的表格，而不是通过某个搜索接口拿到各种网页后做总结。我们会先把各种数据变成结构化表格，再拿这个表格进行下一步分析。

所以我们和其他产品之间的差异，是定性分析和定量分析的差异。

你的核心是中间会有一个 AI 生成的表格。但这个表格里的数据，会不会遇到 AI 经常讲的幻觉问题？

我们在工程上已经把这个问题解决了。

我想到一件事：AI Coding 是不是相当于大模型的翻译和助手？是不是所有任务中间都可以加一点 AI Coding，来解决准确率和幻觉的问题？

我觉得是。用现在比较时髦的话来说，AI Coding 就是大模型的一双灵巧手。

我们现在都在讲，如果让大模型不断进行任务规划，一旦每个任务的成功率是 90%，10 步之后就是 0.9 的 10 次方，成功率会很低。

那怎么让上一步失败不影响下一步？可能就需要中间以代码的形式运行。因为代码如果能保证 90% 的成功率，10 次里有 9 次成功，就可以把成功的那个代码留下，形成一个正确 Case，再进入下一步。这样就能保证每一步都接近 100% 准确。

合理。

但从你们实际操作和经验来看，是不是每一个大模型的操作都应该先翻译成 Coding，翻译成一段程序？

我还是拿 MCP 举例。MCP 背后调用的所有工具，本质上全是代码。

所以从这个角度回答曲老师的问题，我的答案是：是的。

我想再回到刚才的问题。你自己做了 1 年多 Agent，有什么经验可以跟别人分享？

11. The Trust And Feedback Test

这个问题刚才其实还没讲完。

刚才提到了 Product-Model Fit。第二点我觉得很重要：你得想明白到底要给用户 Delivered Result 是什么。

只有把结果想明白，才能不断设立反馈和激励机制，持续优化结果。如果这件事想不明白，它就不会收敛；不收敛就意味着最终交付的结果质量比较差。

比如我们做 Data Search 这个场景，试过 Operator、Genspark、Grok。你会发现它们确实能帮你完成一些事情。比如刚才提到的 YC，它们确实能生成 YC 公司的表格，但表格永远会缺少一些公司。

如果进一步想知道公司创始人是谁、创始人毕业于哪所学校、工作了多少年、Twitter 账号是什么，它就完全解决不了。其实我已经有了一个基本的数据集，想在这个数据上进一步丰富信息，它做不到。

只有把结果想明白，才能基于第一步的结果不断优化第二步的结果。一旦结果想不明白，就会发现产品散掉，变成一个看起来有点像通用 Agent 的东西。

另外还有一个很重要的点：做 Agent 的人要解决两个信任问题。

第一个信任问题是，作为 Agent 的开发者，你要足够相信大模型。

如果你不相信大模型，会不断在代码里加限制条件，比如写 Prompt 说“你是谁，只能做什么，不能做其他事情”。这样做的影响是，大模型的泛化能力会被人为降低。

用我自己的一个词来说，这会导致 Agent 对大模型的智能利用率下降。

我们跟人聊时也经常发现这种例子：本来想在大模型上做得更好，封装了很多东西，最后做了半天，可能还不如把需求直接交给大模型。

这就是因为开发者不够信任大模型。作为开发者，你会产生一种内心的不安感，这种不安会促使你用一些传统的 Rule-Based 方法解决问题，实际上最后是在开倒车。

所以 Agent 开发者需要解决自己内心对大模型的信任。

另一个问题是，你一定要想好产品如何通过设计，解决用户对结果的信任。

一个很好的例子还是 DeepSeek R1。在 DeepSeek R1 之前，我用 DeepSeek 这类产品生成报告，第一眼其实会用一种更批判的角度去看：这个东西到底对不对？因为我不理解它是怎么来的。

但 R1 出来以后，它把中间的推理过程展示出来，让我心理上更舒服。我能看到它是怎么想的，所以更愿意相信这个结果。

我前几天跟朋友聊天时提到，Manus 很大的价值，是给所有 Agent 创业者打了一个样。

也许过一段时间以后，大家回头看，会觉得 Manus 就像当年的 OpenAI 一样，让大家知道上一代大模型最适合的是 Chatbot，Chatbot 就是类似 Character.AI 这样的产品形态，本质上是对话体。

大家在这个基础上不断改进。现在的 Agent 可能也会在 Manus 的基础上不断修改。你怎么看？它是不是一个比较通用的产品形态？

我觉得是。我觉得 Manus 是在 Deep Research 的基础上，在 UI 设计上更进一步了。

核心是它把中间所有的细节都暴露出来。人看到这些东西之后，心里会产生一种满足感和安全感。

所以你对未来几年 Agent 的发展有什么预测？

以现在 AI 的发展速度，去预测几年这么大的时间跨度太难了。预测半年到 1 年，可能更合适。

我想分享一个框架，跟大家一起思考这件事。首先，想要预测，一定要先抓住关键变量。

Agent 里面的关键变量是什么？前面也讲过，判断 Agent 的方法，是看结果好不好，通过结果判断它是不是一个更专业的 Agent。

而结果其实就是 Context 加上 Language Model。所以我觉得核心变量就是这两个。想让 Agent 突破，就要让 Context 或者 LM 至少有一个实现突破。

首先看 LM。LM 下游的突破，我觉得基本上要看 GPT-5 什么时候出来。我判断 GPT-5 会在今年年底左右出来。到年底或者明年元旦之后，我们可能会发现 Agent 的能力进一步提升，这是一个节点。

另一个节点是，GPT-5 出来以后，什么时候成本能降到现在的 1/5，甚至 1/10？这个过程可能也需要 1 年。

至于 DeepSeek R3，我现在不知道它会有多大突破。本质上，我觉得还是需要 Foundation Model 实现突破。比如 DeepSeek V4 什么时候出来，以及基于 V4 能不能再生成一个新的推理模型。

所以从模型角度看，第一个问题是更先进的 Foundation Model 什么时候出现；第二个问题是 Foundation Model 的成本什么时候能降下来。

Foundation Model 出来之后，我们可以做 Demo；Demo 有了之后，大家会形成预期。但只有成本降低之后，这件事才能规模化使用。

所以我觉得，接下来真正好用的 Agent，可能要到 2026 年下半年，才能大规模地被大家真正用起来。

另外一个方面是 Context。以 Cursor 为例，为了把 Coding 这件事做好，它围绕 VS Code 做了大量二次开发。他们从 2022 年开始，到去年下半年，中间花了 1 年半时间。

这里面的工程量非常大。我觉得这也是大家现在普遍存在的一个误解：很多人会觉得 Agent 是一个 Talker，但我认为不是。Agent 的工程复杂度，远远超出大家的想象。

如果想让 Agent 在 Context 层面实现突破，就需要大量工程上的尝试和积累。

从现在这个时间点看，假如 DeepSeek 出来之后，大家第二天就开始做 Agent，优秀的团队做得快一点，我觉得也需要 6 个月；慢一点，可能就要 1 年。

所以可能到今年第 3 季度，会出现一些更好的 Agent 产品。

我再补一个问题。你一直在讲判断 Agent 要看它的 Result 怎么样，但 Result 好，就一定意味着这家 Agent 公司好吗？

有的公司可能通过各种手段，比如某一个 Prompt 写得特别好，阶段性地让 Result 更好。

假设你是投资人，现在面前有很多做 Agent 的公司，你会问哪几个问题来判断这家公司的好坏？

投资人现在遇到的公司，可能都是一个很好的 Founder，团队里有算法或技术背景不错的人，说要做某个领域的 Agent，其他讲的东西其实大差不差。

我可能会问一个问题：看他们团队里有没有人读过前面提到的 Sutton 那本书。

我觉得只要看过这本书，就一定会形成这种思维。有这种思维的人，不会长期容忍用一些非常符号主义的方法去达到结果。

但这个要求可能有点高。很多人可能只是碰巧没看过那本书。

那我会问另一个问题：你的产品里，环境反馈的激励信号是怎么设计的？

到底在你的产品里面，什么样的行为是好的行为，什么样的行为是不好的行为？我觉得这个问题很关键。

因为有了这个信号，才能让大模型进行迭代。把上一轮的结果和环境提供的好坏评价交给大模型，让大模型再迭代一轮。

从这个角度来讲，通用好像确实不如垂直。通用产品很难定义这个东西。

这里补充一个点：大家现在觉得有了大模型之后，结构化数据就不重要了。其实不是，它仍然非常重要。

大模型的输入可以是非结构化的，我可以把各种乱七八糟的文档、文本、PDF、图片一股脑塞进去。但大模型的输出一定要是结构化的，因为只有结构化之后，才能用代码或者规则去校验；否则就没有办法校验。

所以激励信号最后体现在代码上，就是大模型输出结果中的某个字段，它的值到底是什么。核心是你的标准是什么。

那如果让你负责 Manus 这个产品，你觉得它的激励信号可能是什么？

我想不到。因为我看了它官网上的例子，本质上还是让大模型本身，或者另写一个 Prompt，去判断这个结果是好还是坏。

但如果大家使用 ChatGPT 的产品，比如我最近在写 PPT，写了一段开场白，让它不断优化。我说“不满意，你改”，它再改；我再说“不满意，你改”。只提供这样的反馈，你会发现它最后会陷入一个奇怪的死循环，出不来。

所以一定要给它提供大模型本身不具备的反馈信号，才能让结果从这个死循环里跑出来。

那如果问你们自己产品的反馈信号是什么呢？

我可以讲一点。我们做数据抓取，不存在 Hallucination。

我们让大模型负责整个页面结构的分析，以及页面和页面之间关系的分析。基于这些分析结果，会生成一段脚本。真正往下收集数据、生成数据的过程，是用代码实现的。

代码就是一个典型的、能够提供反馈信号的机制。

另外，表格这个东西很直观：一个地方是空的，我一眼就能看见，这其实也是一个反馈信号。

明白，很合理。报告不一样，报告很难精确描述哪一行、哪一个字出了什么问题。但表格是结构化的，所以可以精确描述。

今天我们讨论了很多 Agent 相关的问题。我相信大家核心关注的问题，我们都比较快速、直接地覆盖到了，文峰也分享了自己做了这么长时间 Agent 的一些经验。

最后一个问题：同样的场景下，为什么要用你们，而不用 Manus、Genspark 或者其他工具？

其实不需要 3 个理由。只要你有高质量数据抓取的需求，就会发现现在市面上的 Agent 产品里，只有我们的产品可以做到 100% 准确率、100% 稳定，不会丢数据。

那什么时候大家可以用到？

这周我们就会开放线上的 Waiting List。大家注册 Waiting List 以后，可能在 2 到 4 周左右，就能够正式使用我们的产品。大家可以访问我们的官方网站，实际体验一下。网址是 SHEET0.com，就是“表格”的那个单词。

好，谢谢文峰。

好，也谢谢曲老师。