摘要：曲凯：Agent 是当下绝对的风口。关于 Agent 这个，我自己有一些核心在思考的问题，相信也是很多人同样会有疑问的地方。所以今天我们请来了长时间对 Agent 有研究和实操的文锋，想就这些问题展开一些讨论。

曲凯： Agent 是当下绝对的风口。关于 Agent 这个，我自己有一些核心在思考的问题，相信也是很多人同样会有疑问的地方。所以今天我们请来了长时间对 Agent 有研究和实操的文锋，想就这些问题展开一些讨论。

首先我想问，到底怎么定义 Agent？

文锋： 我认为最好的就是 Anthropic 的定义：Agent 是让模型基于环境反馈去使用工具的一个程序。

曲凯： 那你怎么看最近这波 Agent 热？

文锋： 这波 Agent 跟过去非常不一样。

23 年 4 月以 AutoGPT 为代表的那一波里，Agent 更像是一个玩具，demo 都很炫，但实际应用价值很有限。

经过两年的发展，这波 Agent 确实能够在实际的工作和生活场景中解决问题，为大家带来价值了。

之所以会有这种跃迁，一是因为底层模型能力有了很大的进步，尤其是在结合了 RL 之后，以 o1 为代表的模型还赋予了 Agent 长思维能力。

二是因为 Agent 的工程侧和产品侧也有很大的突破，主要表现就是大家更知道该怎么给 Agent 构建一个合适的 Context，从而更好地解决问题了。

曲凯： 怎么理解这个 Context？

文锋： Context 指的就是大模型执行任务时所需的各种信息的总和。

具体来说，不同产品的 Context 都不太一样。拿我们的产品举个例子， Sheet0 是一个 Data Agent，核心目标是打通整个数据工作流，让 Agent 自动完成在网页上收集数据、处理数据，再到基于数据采取行动的全过程。

我们的 Context 就包括网页、收集整理的数据表格、用户下达的指令，以及分析数据时生成的一些 SQL 等等。

曲凯： 但 Agent 中的 Context 有什么不同？因为大家做其它产品时，好像也约定俗成地会把各种信息收集起来，然后加到 Prompt 或者是 RAG 中去使用。

文锋： 核心区别在于 Context 的来源。

还以 Sheet0 为例，如果用之前 RAG 之类的方式，会有很多需要人工干预的步骤，比如网页里有很多无关紧要的信息，那就需要人工把有效信息提取出来，再比如过程中生成了一个 SQL，也需要人工校验它的准确性。

但在 Agent 中，这些信息会以某种自动化的形式被提炼出来，不需要人的参与。

曲凯： 明白。然后最近大家经常听到 Function Call、MCP、A2A、Computer Use、Browser Use 等概念，能不能帮大家快速梳理一下它们之间的区别？

文锋： 这些概念本质上都是在解决同一个问题，就是让大模型更有效地通过工具调用 (Tool Use) 去执行任务。

Function Call 最早由 OpenAI 提出，能够让大模型通过调用外部函数实现 Tool Use。但是因为不同系统的调用标准都不太一样，就好比 +86 的手机号在美国就没法接打电话一样，很可能你到了另外一个国家，就得把所有东西都重做一遍，所以它不太通用。

为了解决这个问题，就有了 MCP（Multi-Component Program）。MCP 的核心价值在于「统一了 Tool Use 的度量衡」， 极大地降低了这件事的门槛。它可以把任务拆解成多个子任务，而每个子任务都有模块化、有统一标准的组件。通过这种方式，最后大家就能更加自由地调用各种工具。

至于 Google 最近推出的 A2A，我认为它并没有提供新的技术解决方案，更像是一个大厂为了争夺 Tool Use 话语权而强行推出的 KPI 工程，然后找了一堆合作伙伴来推广。

A2A 号称自己和 MCP 的区别在于，MCP 只能让 Agent 通过函数接口去调用外部工具或者 API，而 A2A 却可以实现 Agent 之间的交互。但其实这两种交互方式并没有本质区别，因为 Agent 本身也有函数调用的接口，所以 MCP 也能间接实现 Agent 之间的交互。

Computer Use 和 Browser Use 指的是让大模型把电脑和浏览器作为工具来调用。浏览器可能是大模型目前能调用的最重要的工具之一。

曲凯： 我听下来感觉这些 Tool Use 方案整体分为两派，一派是 Function Call、MCP、A2A，背后的逻辑是直接用代码来解决问题，另一派是 Computer Use 和 Browser Use ，会结合一些视觉识别或者是 RPA (机器人流程自动化) 的方案，模拟人类来解决问题。

文锋： 是的。但这两派并不互斥，比如你也可以用 MCP 的方式来进行 Browser Use。

Browser Use 本质上是让 Agent 通过 GUI (图形用户界面) 与网页进行交互。具体来说，可能后端的大模型会收到一张浏览器的截图，然后去判断上面的交互元素、推算出一个坐标，之后再在前端模拟人类的一系列操作，比如驱动鼠标移动到那个坐标上点击一下，或者输入一些内容，就好像 Agent 真的在使用浏览器一样。

但这个纯视觉的方案还远远不够成熟。国外有一家在 23、24 年非常火的叫 Adept 的公司就是这么做的，但这家公司现在已经死了，因为这个事太难了。

所以实际上，现在大家调用 Browser Use 时，通常需要 MCP 作为中间媒介。大家会把浏览器的 API 包装成 MCP 的组件，然后通过代码的形式让 Agent 完成后续的操作。

曲凯： 类似于 Agent 在前端给人演了一场戏。看似它在模拟人类的操作，其实背后还是代码在驱动。

但毕竟很多公司还没有兼容 MCP，甚至之后可能有的公司为了保护自己的用户数据，更不愿意去兼容。那会不会之后大家就不得不用模拟人类的这种方式去进行 Browser Use？

文锋： MCP 是一个标准化的接口，所以这些 SaaS 软件是不是兼容 MCP 不重要，重要的是它们有没有 Open API，因为 Open API 都可以被包装成 MCP 来使用。而在国外的软件生态中，Open API 基本是标配，所以 MCP 的适用范围非常广泛。

不过海内外情况很不一样，因为国内大多数公司还没有开放 Open API 或者 SDK（软件开发工具包），所以这条路径确实被堵住了。

曲凯： 所以我们可以得出一个结论，如果未来公司能够开放各种后端接口，那我们就可以直接通过代码的方式去调用工具。如果不支持，那就只能通过视觉和模拟人类使用电脑的方式来解决问题。

文锋： 对。这两种方案我们都试过，虽然现在视觉的方案在稳定性和准确度上还不够高，比如我给 LLM 的截图中有一个提交表单的按钮，它常常会把那个坐标算错，但这种方式的优势是成本低、速度快，消耗的 token 至少会少一个数量级。

所以这两种方案各有优缺点，可以结合起来使用。至于具体如何结合才能更高效，就需要开发者根据实际需求调整配比了，因为每个 Agent 想解决的问题都不太一样。

曲凯： 说起来我想到前几周我在美国时，有一个专业做 Agent 算法的人问过我一个问题。他非常不理解为什么 Manus 要用 Browser Use，因为在他的理解中，只要后端的代码能打通，那就能直接解决所有问题了，没必要再在前端搞个浏览器窗口。

你会怎么回答他这个问题？

文锋： 我们在设计 Agent 时，一个关键问题是怎么给用户营造一个「可信的氛围感」，让用户更相信 Agent 生成的结果。

为了做到这件事，非常重要的一个手段就是让用户以一种好理解的方式看到 Agent 执行任务的全过程。

那浏览器就是一种天然对人更友好的呈现方式，远比代码界面这种黑乎乎的窗口要来得生动、直观。

曲凯： 那 Devin、Manus、GenSpark 各自用的什么方案？

文锋： Devin 和 Manus 都是 Coding 和 Computer Use 混合的方案。

至于 GenSpark，我用它跑了一些任务，感觉它可能也在后端调用了一些网页的 API，但前端并没有像 Devin 或者 Manus 那样，通过浏览器窗口将网页使用的过程暴露给用户。

从这个角度讲，我觉得 GenSpark 可能还不太符合我心目中 Agent 该有的体验。

曲凯： 但从用户的角度来看，最终能解决问题不就行了？为什么要在意 Agent 后端到底有没有在运行什么东西，或者能不能像人一样使用电脑或浏览器？

文锋： 这是一个非常好的问题。

这个问题的核心在于要让用户时刻感受到自己在掌控一切，因为人都会有不安全感，那把一切都透明化就是建立安全感的关键所在。

举个例子，假如你是我老板，然后给我分配了一个任务，如果我们之间要建立信任关系，可能就得让你看到我是怎么做事的，并且能了解到我大致的思路。当你足够了解我之后，你才会对我产生信任。

曲凯： 这点很 make sense。其实本质上是大家觉得 Agent 还不 ready、不靠谱，所以需要看到它执行任务的过程，也需要通过回答问题之类的方式时不时地参与到它执行任务的过程中。

然后我觉得当下市场对 Agent 的讨论和理解，其实很像两年前 LLM 那一波。当时很多人都在讨论未来究竟属于通用的 AGI 模型，还是垂直领域的模型，又或者是创业公司自己开发的小模型等等。

那现在大家也开始讨论 Agent 的终局会走向通用还是垂直。你怎么看这个问题？

文锋： 我认为我们现在处于，并且将长期处于一个垂直 Agent 的时代。

我最近特别喜欢用做饭来举例。很多人都会做饭，但我们做饭可能就是拿出手机、打开菜谱软件，然后再照着菜谱一步步操作。

而一个更好的 Agent 就像是一位五星级酒店的大厨，受过多年的专业培训，不仅不需要菜谱，而且做出来的菜色香味俱全，比我们强很多倍。所以人家是大厨，我们只是会做饭的普通人。

曲凯： 明白。然后至少在过去半年中，市场上最热、拿到最多钱的两条赛道就是 Agent 和 AI Coding。那最终 AI Coding 和以 Coding 为核心的 Agent 会殊途同归吗？

我原本觉得这两条赛道井水不犯河水，但越来越觉得它们未来很有可能会走到一起，因为现在很多 Agent 都在用 AI Coding 的解决方案。

文锋： 而 AI Coding 那边也在讲 Coding 是一切的基础设施（笑）。

曲凯： 是啊哈哈，甚至前几天我还看到一条新闻说 Coding 可能也是未来 AGI 的基础。

理论上讲，AI Coding 和 Agent 最终好像确实可能会殊途同归，举个极端的例子，如果我们要做 Browser Use，其实完全可以让 AI Coding 直接做出一个 Browser 然后自己去 Use，不是吗？

文锋： 理论上 是可以，但这种方式的经济成本和时间成本都太高了。

AI Coding 只能说是大模型执行任务的一个强有力的工具，这个工具存在两个关键问题，一是很难和其他工具协同，二是很难复用。

如果我们用 AI Coding 直接去执行任务，那它需要先拆解任务，然后针对每个子任务逐一写出能够运行的程序，并且之后每遇到一个新任务，都要从头到尾来这么一遍，非常低效且消耗成本。

所以对于 Agent 而言，最好的选择是在解决任务时先看看手边有没有现成的工具，如果找了一圈实在没有，再考虑用 AI Coding 现场造。

曲凯： 明白。那 RL 和 Agent 之间的关系是怎样的？创业公司最终应该如何应用 RL？

文锋： Agent 这个概念本身就源于 RL，所以如果你不理解 RL，就很难理解 Agent 到底是什么，也就很难设计出一个好的产品。

那要做好 Agent，我们就先得了解 RL 中对 Agent 的定义。RL 中的 Agent 有三个要素：

1) 状态，对应 Context。

2) 行动，对应 Tool Use。

3) 激励信号，指的是当 LLM 采取行动后，用于评估它每一步操作的效果、指导它下一步行动的反馈信号。

那么对于创业公司而言，非常关键的就是如何在你的产品中打造出一个好的「环境」。这个环境需要清晰地描述当前的状态，Agent 可以采取哪些动作，也就是行动空间，以及对于结果好坏的定义。

其中，行动空间决定了你设计的 Workflow 中要有多少个节点。

而之所以一定要定义好结果，是因为只有这样，你才有可能设计出一套有效的评估体系和激励机制，进而不断让 Agent 基于动态的反馈去自我迭代。

如果你没定义好结果，那整个系统就没办法收敛。无法收敛就意味着最终 Agent 很可能给用户一个质量很差的结果，或者呈现出一种「什么都会一点、但什么都不精通」的状态。

所以我也很建议所有 Agent 开发者和产品设计者都去读一下强化学习之父 Richard Sutton 的《Reinforcement Learning: An Introduction》。看完这本书你会收获一个 mindset，让你能够在设计产品的时候不断地思考、调整、定义你的环境。

曲凯： 怎么评判环境的好坏？

文锋： 评判一个环境好不好，关键是要看这个环境能不能基于行动的结果来提供一个激励信号。

这么看，IDE 就是一个好的环境，因为只要 Agent 生成一段代码，就能立马在 IDE 中运行，而一旦这段代码跑不起来，IDE 就会生成一个报错信息。这个报错信息天然就是一个激励信号。

曲凯： 明白。那你觉得 Workflow 会完全被 Agent 取代吗？

文锋： 不。我认为 Workflow 和 Agent 会长期共存。

这两者的本质区别在于，Workflow 由人类驱动，而 Agent 由 AI 驱动。

人驱动的好处就是稳定、可靠，但缺点就是它缺乏泛化能力，比较死板。AI 驱动则恰恰相反，它更泛化、更灵活，能应对一些你事先没想过的问题，但它的缺点就是不确定性很高，10 次里面可能有 5 次都会搞砸。

所以 Agent 适合解决世界上 20% 更开放、需要长期探索和试错的任务，而其余 80% 更日常的问题，用 Workflow 完全足够。

曲凯： 你已经做了一年多的 Agent，有积累哪些非共识的认知吗？

文锋： 我认为「Chat」是 Agent 最重要的交互入口。

因为对于 Agent 来说，用户交互的自由度是第一重要的事情，其重要性远高于交互的准确度。

一旦你限制了用户的自由度，其实就是在让用户来适应你的产品，加重用户的认知负担。而一个好的 Agent 应该足够智能，能让用户像幸福的小朋友一样自由地使用它。

那么在现有的交互方式中，Chat 就是最能保障用户交互自由度的形态。

当然，并不是说准确度就不重要，只是我认为这不该是用户需要承担的问题，而应该由开发者和产品设计者去解决。实际上，业界也有很多方法来提升准确度，比如引入 Human-in-the-loop，或者像 Devin、Manus 那样积累用户偏好，再比如你也可以做更多的产品设计，比如通过向用户提问，来引导用户逐步把模糊的需求细化，直到变得具体可执行。

你不需要额外设计很多接口，也不需要在前端堆砌太多组件，但可以在恰当的时机把合适的组件推到用户面前。就算你设计了 200 个组件，但实际上用户的需求都不大一样，所以每个用户可能只用得上其中的 10 个，那就没必要把这 200 个组件全摆出来，徒增用户的认知负担。

曲凯： 综合你说最后这点我很同意。单纯一个聊天框不一定是最高效的交互方式，但如果在聊天框基础上能结合一些场景推荐的 UI 组件，确实是一个挺合理的方案。

不过要实现这种交互形态，首先得做好意图识别，判断好用户到底想要什么。而且意图识别和 Context 好像是互为依赖的，Context 越多，模型就越有可能猜准用户的意图；反过来，在理解了用户的意图之后，模型也需要更多 Context，来判断该怎么做才能更好地完成整个任务。

文锋： 所以模型本身要有能力去判断当前的 Context 是否充分，如果不够，就得通过调用外部 API，或者借助 RAG 之类的方式去获取更多的 Context。

曲凯： 这件事其实和模型本身的智能程度，还有垂直领域的 know-how 都很相关。

文锋： 是，另外开发者在 Agent 中预设的 System Prompt 也可以辅助模型的表现，像 Cursor 和 Windsurf 就有几千行的 System Prompt。

曲凯： System Prompt 其实也只在垂直领域才奏效，因为你要写出有针对性的 Prompt，就得知道用户的目标，而且你对这个领域越了解，写出的 Prompt 可能就越精准。

举个例子，如果你要做一个专门搞研究的 Agent，那你就可以针对研究这个场景提前预设一个 System Prompt，因为它每次执行任务都可以按照搜网页、找数据和相关文章、摘要重点信息、最后输出成 Excel 或 PPT 这个流程去操作，而且每一步都是独立的，可以单独进行优化。

但如果你要做一个通用 Agent，那面对用户千差万别的需求，你就很难写出一个适配所有任务的 System Prompt。而且通用 Agent 每一步动作都高度依赖上一步的结果，所以很可能会「一步错，步步错」，拉低最终结果的准确率。

文锋： 是的。总之起手收集到的 Context 越多越好。

曲凯： 所以我记得之前苹果会记录你打开某网页之前刚看过的那个网页，其实这就是在收集 Context。包括 OpenAI 最近刚出的记忆系统，本质上也是在构建一个 Context。

前几周我和张月光吃了顿饭，他也提出了一个特别好的观点。

他说你点开某个 APP 的那一瞬间，其实就已经提供了海量 Context。比如你点开美团大概率就是想点外卖，点开滴滴就是想打车，所以这些 APP 的产品设计都是基于这些 Context 展开的。

然后用户使用你这个 APP 的过程中，还会持续产生更多的 Context，比如输入了什么内容、做了什么操作等等。所有这些信息结合在一起，就能帮助系统更精准地识别用户意图、预测下一步的需求，甚至主动发问，引导用户获得想要的结果。

文锋： 对。你想更好地了解一个人，就要看 Ta 的过去。同理，你想更好地理解用户的意图，就要追踪 Ta 从哪里来、以及过程中的路径是怎样的。

就好比下围棋，当前这一手没那么重要，重要的是你得理解对方前面一百手棋是怎么下的，因为只有这样你才能判断对方整盘棋的思路，进而推测出 Ta 接下来的策略，并做出相应的动作。

曲凯： 所以 Google 很早就在保存用户的 cache。

文锋： 这确实是 Google 在 AI Native 时代最大的竞争优势。这些海量的用户点击数据，未来都可以用在意图识别中。

曲凯： 是。你对于 Agent 还有什么其它的非共识理解吗？

文锋： Agent 开发者还要解决好两个信任问题。

第一，你要信任大模型的能力。

如果你不信任大模型，就会退回到 rule-based 的老路子上去，给模型加一堆限制条件，比如通过 Prompt 不断告诉模型「你是谁、你只能做什么、不能做什么」等等。但其实这样是在人为限制大模型的泛化能力，导致 Agent 对模型智能的利用率大大降低。

第二，你得思考怎么通过产品设计，让用户信任 Agent 给出的结果。

这方面有个特别好的例子就是 DeepSeek R1。在 R1 之前，我用一些类似的产品生成报告时，拿到结果的第一反应往往是「这靠谱吗？」，因为我不知道这个报告是怎么来的，中间有没有出错。

但 R1 第一次让我看到了 AI 的推理过程，所以我心理上更有安全感，也更愿意相信这个结果。Manus 其实也是类似的机制。

曲凯： 明白。再聊聊 Sheet0 吧，你前面说它可以自动完成数据收集、处理，以及基于数据采取行动的全过程。能不能举个具体的例子？

文锋： 比如我们可以自动化执行这样一套流程：先抓取 YC 最近几期的初创公司列表，然后找出每家公司的创始人是谁，再进一步查找他们的 Twitter 账号并完成关注，最后再发个私信去建联。

这个流程我们已经做到了 100% 的准确率。

我们也试过用 Deep Research 和 Manus 去执行这个任务，但发现它们都会丢数据。而且 Deep Research 拿到数据之后，只能生成一份报告，无法像我们一样完成后续的建联动作，而 Manus 虽然具备行动能力，但它每一步都在动态 Coding，过程中需要不断 Debug 和调整，所以很难保证稳定性和成功率。

曲凯： 所以你们怎么做到的 100% 准确？

文锋： 我们用了一些 AI Coding 的技术。但这还不够，我们还在整个流程中预先搭建了很多小的工具模块。这些工具都是我们提前验证过、确保好用的。每次拿到一个新的任务，模型都可以直接调用这些模块，而不是从头写一段程序。

这种方式背后的核心逻辑就是「复用」。这样做效率更高，成本也更低。

但 Manus 不是这种思路。Manus 每遇到一个问题，都要打开 IDE 从零开始写代码。

并不是说 Manus 的方式一定不好，因为 Agent 的通用性和准确率之间有一个 trade-off，你越追求通用性，就越依赖模型的泛化能力，但泛化程度越高，随机性也会越高，结果的不确定性也会变大。最终选择哪种模式，取决于你到底想做出什么样的 Agent。

曲凯： 所以如果你想要一个既通用又准确的 Agent，就得让团队投入大量时间和精力，手搓各种各样的工具组件。

文锋 ：是的。但也不是什么都要手搓，有时候用现成的工具反而更划算。比如像发邮件这种简单的流程，就很适合手搓一个模块，但如果是数据库相关的操作，你肯定不能每次都从头写一套脚本，更合理的做法可能是通过 MCP 之类的方式直接调用。

曲凯： 那 Sheet0 跟其它 Agent 相比，有什么区别？

文锋： 我区分 Agent 就是看它最终交付的结果。从这个角度去对比，市面上的 Agent 大体可以分成两类。

一类是 Coding Agent。它们交付的结果就是一段可执行的代码。

另外一类是调研 Agent。GenSpark、Deep Research、Manus 其实都属于这一类，它们最终给用户交付的结果就是一份报告，而不能真的帮你在美团上下个单，或者去京东买个什么东西。

而我们是个表格 Agent，和其它 Agent 相比，本质上其实是「定性分析」和「定量分析」之间的差异。

「定性分析」是很多 Agent 解决问题的方式。比如如果你想大致了解某一个问题，那就可以用 Deep Research 这样的工具去生成一份报告。这份报告能帮助你建立对这个问题的感知，但不能给你非常精确的数据。

而我们想解决的是生活中那些对精确度有要求的场景，所以需要用「定量分析」的方式去解决问题。

比如如果你想知道一个非常精准的数字，那就需要一个准确的数据源，而这个数据源通常是一个清晰完整的表格。Sheet0 所做的事情，就是借助 AI，从这些数据源中抓取各种数据，再把这些数据汇总到一个表格中，然后拿这个表格去做下一步的分析。

我们在工程上也解决了模型幻觉的问题，能够保证这个过程的准确度。

曲凯： 说到模型幻觉我突然想到，AI Coding 是不是就相当于大模型的翻译和助手？如果各个环节都引入一点 AI Coding，是不是就能提高结果的准确率，解决幻觉的问题？

文锋： 是的，AI Coding 是大模型的「灵巧手」。

大模型执行任务的过程有很多步，最终结果的准确率是前面所有步骤准确率的乘积。举个例子，如果它每一步的成功率都是 90%，连续执行 10 步之后，整体的成功率可能就会降到 0.9 的 10 次方，也就是 35%。

这是因为下一步都是在上一步的结果之上去执行，而每一步的结果又很难评估，所以就难以及时修正。

为了解决这个问题，我们就可以在每步中都引入 AI Coding，这样就可以把难以评估的结果，都转化成可验证的代码。

比如每一步我都可以通过 AI Coding 生成 10 段代码，因为代码很好验证，所以就算这些代码中只有一半是正确的也没关系，我完全可以只留下正确的那 5 段，用这 5 段去生成一个正确的阶段性结果，然后再进入下一步。这样就保证了最终结果 100% 的准确率。

MCP 其实也是通过这个方案打通了工具调用之间的壁垒。

曲凯： 那你对于未来几年 Agent 的发展有什么预测吗？

文锋： 现在 AI 发展的速度太快，与其分享一个具体的预测结果，我更想分享一个思考框架。

你想判断 Agent 未来的发展方向，最重要的是抓住关键变量。那就像我们之前聊的，Agent 做得好不好，核心是看它能不能真正交付出一个好的结果，而这个结果的质量，主要取决于两个因素：一是模型能力，二是你能不能构建出更好的 Context。

所以 Agent 要想有突破，至少需要模型更强了，或者我们在 Context 工程上走得更远了。

曲凯： 那假设你是投资人，你会问什么问题来判断一家 Agent 公司做得好还是不好？

文锋： 我首先会问他们团队里有没有人看过《Reinforcement Learning: An Introduction》（笑），因为看过这本书的人，大概率会具备一种正确的 mindset，能用很 solid 的方式来做好一个产品。

除此之外，我可能会问他们怎么设计产品中的激励信号，也就是他们怎么评估结果的好坏。这是一个非常关键的问题，决定了大模型能不能往更好的方向去持续迭代。

曲凯： 所以你们产品的激励信号是什么？

文锋： 我们产品的核心是任务执行的过程中 AI 生成的那个表格，那「表格中数据是否为空」本身就是一种很直观的反馈信号。

另外，前面也提到了，我们会通过 AI Coding 把一些难以直接评估的结果转化为可验证的代码，比如我们会把模型对于页面结构、页面与页面之间的关系之类的分析结果，通过 AI Coding 的方式生成一段脚本，那这个脚本能不能成功运行、运行的结果是不是符合预期，也是一种激励信号。

曲凯： 理解了，谢谢！最后说下 Sheet0 最近开放了 Waiting List，也即将开始内测，欢迎大家去 sheet0.com 注册体验一下。

来源：东窗史谈一点号