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

2025 年 4 月的一个大风天，王文锋跑到 42 章经的录音间，和曲凯聊了将近一个小时。他是 Sheet0 的创始人，程序员出身，做 Agent 两年多，自称是强化学习之父 Sutton 的粉丝。这期播客里，两个人把 Agent 领域最常被问、也最容易被含糊带过的一批问题挨个拆开：Agent 到底怎么定义，Function Call、MCP、A2A、Browser Use 这些名词之间是什么关系，通用 Agent 和垂直 Agent 谁会赢，AI Coding 和 Agent 是不是一件事。

王文锋给出的答案有不少反常识的地方。他认为 A2A 更像一场 KPI 工程，认为聊天框加适时弹出的场景推荐界面就是最好的交互形态，认为脱离了强化学习，Agent 这个概念根本不成立。他还留下一句让曲凯印象很深的话：AI Coding 是大模型的灵巧手。

这期对话的信息密度不低，但结构清楚。沿着 Agent 的三要素往下走，能看清过去两年这个行业真正发生了什么变化，也能拿到几个判断 Agent 公司好坏的实操问题。

Agent 的三要素：模型、环境反馈、工具 0:00:47

曲凯开场就问了一个基础问题：Agent 到底怎么定义。王文锋用的是 Anthropic 的说法，Agent 是模型基于环境反馈去使用工具的程序。他把这句话拆成三块：模型、环境反馈、工具调用。

模型这一块最好理解。环境反馈是王文锋认为最关键的、也最容易被忽略的部分。工具则是 Agent 采取行动的方式，通过调用工具去改变外部世界。

这个定义直接引出下一个问题：这一波 Agent 和两年前有什么不同。2023 年 4 月，AutoGPT 火过一阵，但王文锋的评价很直接，那时候的产品更多是个玩具，解决不了实际问题。两年之后，Agent 真的能在工作和生活场景里产生价值了。

变化来自两头。一头是底层模型的进步，尤其是 o1 出来之后，模型有了长思维能力，强化学习在决策上的使用让模型能想得更久、更远。另一头是王文锋认为大家关注不够的：Agent 工程本身的突破，也就是怎么给 Agent 构建合适的 Context 去解决问题。这是工程侧和产品侧的进展。

Context 被王文锋定义为「所有大模型需要去利用的信息的总和」。以代码场景为例，它包括代码库的结构、原文件、可用的 API，也包括人类的输入。换成 Sheet0 自己的产品，Context 包括网页、帮用户收集的数据表格、用户那句需求 prompt，以及分析数据时生成的 SQL。

曲凯追问：这些信息留下来、塞进 prompt 或 RAG，不是大家早就约定俗成的做法吗。王文锋的回答指向了差别所在：核心是这些 Context 从哪里来。网页里有大量无关信息，怎么把关注的信息抽取出来是一层；生成的 SQL 准不准确，需要拿题库去校验，一条 SQL 能不能执行成功，这些信息需要以自动化的方式提炼出来。以前 RAG 也好、别的办法也好，信息的主要来源是人。Agent 更强调信息来源是通过某种自动化方式获取的。

用代码调用，还是模拟人操作 0:04:21

曲凯把市面上流传的一堆名词摆出来：Function Call、MCP、Google 刚出的 A2A、Computer Use、Browser Use。王文锋的归纳是，这些东西都在解决同一件事，给大模型提供更好的使用工具的方法，让大模型更好地 take action。

区别在版本和路线。Function Call 是 OpenAI 最早提出的让大模型使用工具的方法，可以理解为 0.1 版本。MCP 在此基础上更进一步，是 0.2 版本，它最大的作用是统一度量衡。以前每个国家有自己的度量衡，换个国家就得重新学一遍；MCP 把这件事标准化了，大家可以去调用任何人的工具，门槛一下子降低。

对 A2A，王文锋的评价不留情面，认为它没什么意思，更像一个 KPI 工程。A2A 定位自己与 MCP 的区别是，MCP 只能跟工具或 API 交互，A2A 可以让 Agent 与 Agent 交互。但从开发者角度看，这两件事没有区别，因为 Agent 本身也可以定义成一个图，有个函数入口，用 MCP 包装一下就能被其他 Agent 调用，可以纳入 MCP 的范围。所以他判断 A2A 是强行造了一个概念，找了一堆合作伙伴来推，本质是一种标准化叙事。工程师会更喜欢 MCP，A2A 没有提供新的东西。

曲凯顺势总结出两条路线：一条用代码解决问题，Function Call、MCP、A2A 都算；另一条模拟人解决问题，Computer Use、Browser Use 靠视觉识别加 RPA。王文锋说这两条不矛盾，甚至可以用 MCP 的方式去做 Browser Use。

他解释了背后的实情。纯粹靠视觉的方式，是让模型推算某个坐标，把鼠标移过去点击、输入，这个方案远远不成熟。国外有家叫 Adept 的公司，2023 到 2024 年非常火，后来死掉了，就是因为这件事太难。现在大家做 Browser Use，其实是通过浏览器的 API 把它包装成一个类似 MCP 的工具，再用代码去调用。前面类似演了一场戏给人看，背后还是那些东西。MCP 和 Browser Use 是两个正交的概念，互不影响。

那为什么还需要真的模拟人操作？王文锋说，正经使用 MCP 的姿势是：如果某个 SaaS 软件已经有 Open API，开发者自己按它的 API 包一层就能当 MCP 用，不需要软件本身支持 MCP。Open API 在国外软件生态里基本是标配，国内则普遍没有。没有开放接口的产品，就只能走视觉这条路。

两种方式各有适用场景，比例要根据 Agent 自己的需求去配。视觉方式虽然稳定性和准确度不如接口，但成本低。Sheet0 两种方法都用了，实测下来，截图让模型判断，速度更快，token 消耗至少少一个数量级。问题在于 GUI 生成的结果有时不准，比如图片上有个提交表单的按钮，模型经常把坐标算错。

Manus 为什么用浏览器：安全感比效率更值钱 0:10:27

曲凯转述了一个他在美国听到的问题：一位做 Agent 算法的专业人士不理解，为什么 Manus 要用浏览器来做这件事，后端代码明明可以直接接通实现。王文锋从两个视角回答。

技术视角很简单，用浏览器在成本上更低。产品视角更关键：用户是不是相信这个结果。让用户使用 Agent 的过程中，怎么营造一种可信的氛围感，非常重要。其中一个重要手段，是让用户全程看到 Agent 怎么帮他完成工作，看到每一个细节，而且这个细节要以其能懂的方式呈现。浏览器天然对人友好，视觉化的呈现比黑乎乎的代码窗口更生动直观。

曲凯接着让王文锋判断几家产品的方案。Devin 是纯 Coding 的方案，也有 Computer Use；Manus 是 Coding 和 Browser Use 结合的典型；Genspark 稍有不同，王文锋自己跑了一些任务，没看到像 Devin 或 Manus 那样肉眼可见的浏览器，感觉它是在后端跑，也用了一些网页应用，但没有把过程暴露给用户。所以在他的标准里，Genspark 可能不算他心目中的 Agent。

曲凯提出一个用户视角的反驳：反正最后帮我解决问题就行，我为什么要关心它有没有像人一样在用电脑。王文锋用一个类比回应：两个人怎么建立信任？你给我分配一个任务，你能看到我怎么做这件事，知道我大概是什么思路，足够了解我之后才会产生信任。Agent 眼下还不如人靠谱，所以需要把过程透明化，让人时刻感觉自己在掌控一切。

把一切做透明是很关键。

曲凯也提了 Manus 的一个体验缺点：它跑到一半弹出一个问题，人没看到，等了半小时回来发现还停在第二步。王文锋承认这是 UI 上可以优化的点，也认为后续通过邮件、短信、工作 IM 打通通知，这个问题不难解决。

这一节的结论是，不管 Computer Use 还是 Coding，都是当下 Agent 可以用的工具，大多数产品是根据场景做组合方案。

AI Coding 是 Agent 的灵巧手 0:14:19

过去半年市场上最热、拿钱最多的两条赛道是 Agent 和 AI Coding。曲凯观察到，这两件本来分开的事，越看越可能走到一起。王文锋同意，还举了个极端的例子：可以让 AI Coding 自己做一个浏览器，然后自己用。理论上成立，只是有经济性和时间成本的问题。

他把 AI Coding 定位成大模型的一个工具，其中两个点很关键：协作和复用。现在大家说 AI Coding，往往是把一个问题拆解，每个子问题写个程序包起来，从头到尾做一遍。这在王文锋看来非常低效且消耗成本。现代软件工程强调复用，是为了让事情更高效。

所以对 Agent 而言，最优的选择是：先看手边有没有能直接用的工具；找了一圈没有，再退一步，用 AI Coding 现场造一个独特的工具出来。两者是这样的关系，AI Coding 是对 Agent 的补充，是一个很强有力的工具。他特别强调复用的价值：下次遇到同类任务，把已经测试过的工具直接拿来用，效率更高、成本更低，不必从头到尾重新写一遍代码。

曲凯追问，是不是所有任务中间都可以加一点 AI Coding，来解决正确率和幻觉问题。王文锋说 yes，并给出了那个被曲凯记住的说法：AI Coding 是大模型的灵巧手。

逻辑是这样的：让大模型做任务规划，如果每一步成功率是 90%，十步之后就是 0.9 的十次方，成功率很低。怎么让上一步的失败不影响下一步？用代码的形式去运行它。代码只要能保证 90% 的成功率，十次里九次成功，就把九次成功的那份代码留下，做成正确的 case，再进入下一步，这样每一步都能保证百分百准确。

他还拿 MCP 举例：MCP 背后调用的那些工具，本质上全是代码。所以「每个大模型操作都应该先翻译成一段程序」这个问题的答案是肯定的。

垂直 Agent 的时代会很长，RL 是它的地基 0:16:15

曲凯把当下的讨论类比成两年前关于通用大模型和垂直模型的争论。王文锋的判断是，我们现在处于、也将长期处于一个垂直 Agent 的时代。

他举了做饭的例子：很多人都会做饭，拿手机打开菜谱软件对着做，也能做出一顿饭。但这和五星级酒店的大厨不是一回事，人家做出来的饭在美观和美味程度上超出很多倍，所以人家是专业厨师。言下之意，通用 Agent 和垂直 Agent 的差距，类似会做饭的人和职业厨师。

话题转到 RL。王文锋的说法很重：Agent 这个概念就是从强化学习里出来的，脱离了强化学习这门领域，Agent 概念就不成立。所以做产品的人要追根溯源，看强化学习里 Agent 最早怎么定义。

强化学习里的 Agent 有三个关键：状态、行动、激励信号。状态就是前面一直在强调的 Context，经过若干步骤后 Agent 当前处于什么情况，包括记忆、眼前看到的东西。行动就是 Tool Use，有了判断之后怎么执行，通过函数调用去执行，因为函数接口是代码与数字世界交互的媒介。激励信号则是判断这一步做完之后，状态离目标是更近还是更远，是一个正一和负一的区别，靠它决定往左走还是往右走。

对创业公司来说，关键的一步是让产品变成一个环境。只有有了环境，才能描述状态是什么、可选行动空间有多大。程序里 workflow 有多少节点，由行动空间决定。还要定义结果，因为只有结果定义好了，系统才能收敛；能收敛，大模型才能判断一个行动做完之后离目标是近了还是远了，才能设计激励信号，让 Agent 一轮一轮自我迭代直到实现目标。

他建议所有 Agent 开发者和产品设计者去读 Sutton 那本《Reinforcement Learning: An Introduction》。有了这个 mindset，设计产品时才会不断思考：我定义的是一个什么环境，环境里的状态是什么样，行动空间有多大。

你不理解强化学习，你就很难理解 Agent 到底是什么。

曲凯把三要素重新捋了一遍：状态对应 Context，行动对应 Tool Use，奖励函数对应评估体系。他认为后两个相对好理解，因为所有模型领域都在讲 evaluation 体系的搭建。第一个状态与环境，也就是 Context，才是各家产品拉开差距的地方。

顺着这个思路，曲凯问：IDE 是不是一个好环境？Manus 用的浏览器算不算？王文锋给了一个判断环境好坏的标准：环境的核心作用是提供奖励信号的反馈机制，所以要看这个环境能不能基于行动结果给出奖励信号。IDE 的学名是集成开发环境，Agent 写一段代码，立刻能在环境里运行，代码跑不起来就生成错误信息，这个错误信息天然是反馈信号。Ubuntu 提供不了这种机制，它更多是个容器，要在上面搭一套东西才能构建反馈信号。对 Manus 来说，浏览器不是它的环境，它的环境是 Ubuntu 系统下的目录。

聊天框加场景推荐，就是最好的交互形态 0:22:54

做了一年多 Agent，王文锋踩过的坑里，最重要的一条是产品观：好的 Agent 应该是尽可能不让用户动脑子的产品。

他对比了两个时代。上一个时代，产品功能越多，能解决的问题越复杂，但用户学习、理解、使用软件的成本越来越大，认知负担不断加重。Agent 应该反过来，用户越简单、越不用动脑子就能用起来，产品越强大，就越懂用户偏好。积累更多 Context、更多用户数据，做好意图识别，知道在合适的时间问出对的问题。

由此他提出一个跟当下一些讨论不太一样的观点：聊天框是最重要的交互入口。理由是，对 Agent 产品来说，用户交互的自由度远比交互的准确度关键。用户想怎么讲都可以；一旦限制交互自由度，就变成用户要习惯产品，而不是产品习惯用户，认知负担立刻加重。

准确度不重要吗？也重要。但提高准确度是产品开发者的事，有很多方法：human in the loop、记录用户偏好、在用户给出模糊需求时不断澄清、逐步细化。不能把这个任务交给用户。王文锋的描述是，要让用户像一个非常幸福的小朋友一样使用产品，类似心流状态，感受不到时间流逝，不需要动脑子，坐在那儿很放松，事情就做完了。

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

那聊天框是不是意味着界面只有一行输入框？不是。他的设计思路是：后台可能有 200 个组件，对某个用户来说，可能一直只看到 10 个，剩下 190 个用不到，用不到就不会影响理解。产品要做的是把合适的组件在适当的时机推到用户面前让他交互。曲凯补了一句，纯聊天框不一定最高效，但在适时的时候推出一个合适的界面让用户选，是很合适的选择。

这套设计对意图识别提出了很高要求。王文锋说，Context 和意图是互相印证的：Context 足够多，可能猜到用户要干嘛；用户告诉你要干嘛之后，还要收集更多 Context 来完成任务，并判断中间有哪些问题需要提出来。这里很关键的一点是，模型得有能力判断当前 Context 是否足够；不够的话，要通过环境提供的 API 自动去 get，无论用 RAG 还是别的方式。这既跟模型智能相关，也跟垂直领域的 knowhow 相关。

System prompt 是另一个抓手。Cursor、Windsurf 这些产品的 system prompt 非常长，几千行，都是预制的。王文锋认为这只有在垂直领域才成立：只有知道用户上来要干嘛，才能写好 system prompt；必须了解这个领域，才能写得更好。以研究类 Agent 为例，它肯定要搜网页、收集数据和文章、把内容摘出来放进 Excel 或 PPT 报告，这几步是确定的，就可以针对每一步做优化、预置 prompt。换成通用 Agent，用户可能想做研究，可能想做动画，也可能想生成别的东西，准确率立刻下降。因为每一步就算有 90% 的成功率，若干步之后是乘数关系；垂直 Agent 则可以把每一步的成功率提到百分百，而且一步出问题不会影响下一步的结果。

曲凯提到一个细节：打开网页的上一步你在看什么网页，也是一种 Context。王文锋把它扩展了：历史对话信息只是人看到的部分，Agent 在后台可能访问了很多网页。当前状态由过去做的所有事情决定，做了什么、看了什么、发了什么，整体构成现在的状态，这个状态的集合就是上下文。OpenAI 最近出的记忆系统也是一种 Context。

曲凯引了张宇光的一个观察：点开某一个 App 的那一刻，就已经提供了海量 Context。点美团就是告诉它我要点外卖，点滴滴就是告诉它我要打车，产品里所有东西都基于这个 Context 设计。王文锋认同，这相当于把大家拉到一个共同的氛围下面，先完成意图识别，再在交互过程中不断积累 Context。

他还给「高质量数据」下了个定义：不仅要知道输入是什么、结果是什么，更要知道从输入到输出中间发生的各个变化。这些数据综合起来是一个数据序列。就像下围棋，只知道这一步怎么下不关键，得知道前面一百手怎么下的，整个盘面怎么来的，才是最关键的。

Sheet0 怎么把准确率做到 100% 0:31:54

Sheet0 是一个 Data Agent，目标是把数据收集、数据处理到基于数据采取行动的整条链路闭环。目前数据收集和处理这一段做得比较好。

王文锋举了两个场景。一个是找销售线索：客户有很多开源用户，想知道这些用户是哪个公司的，好把商业版卖过去。以前只能人肉一个个分析，现在模型能做。具体做法是进入用户的 GitHub 主页，分析代码提交记录、社交媒体账号等线索，再顺着社交媒体账号看有没有公司信息，整个过程模拟人手动翻看。

另一个场景是找到 YC 最近几批的公司列表，再找到创始人，找到创始人的 Twitter 去关注、发私信。因为用了 AI Coding 的技术，这个流程能保证百分百准确。

跟同类产品比，差别在哪？王文锋说，Deep Research 这类产品不能保证把公司一个不漏地抓下来；拿到数据之后还需要进一步动作，比如跟创始人建立联系、reach out，而 Deep Research 给完报告就结束了。Manus 能做后面那步，但没办法保证成功率，因为它在中间动态随机生成代码，需要不断 debug 和调整。

Sheet0 的解法是在内部做了很多小的工具，让 Agent 去调用。这些工具自己人验过、测过，所以能保证百分百准确。王文锋程序员出身，很喜欢「复用」这个词：下次用的时候，把已经测试过的工具直接拿起来用，效率更高、成本更低，不必每次都从头到尾重新写一遍代码。Manus 现在没有这个机制，每次都是打开 IDE 从零开始写代码。

这背后是一个取舍：通用性和准确性。越通用，方法要越泛化，泛化意味着随机性更高。团队要写海量的工具才能覆盖通用场景，所以核心是怎么更好地利用工具。发邮件这类场景简单，可以从头写；但让 Agent 跟数据库交互，不可能从头写一个数据库，更好的方式是把它包装成 MCP 或其他形式，在 Agent 里调用。

曲凯顺势问到 Workflow 会不会被 Agent 颠覆。王文锋认为这跟人性有关，大家聊一个事情时总喜欢踩一个、创造对立视角，无论为了流量还是眼球。实际上 Agent 和 Workflow 长期共存。区别很简单：Workflow 是人驱动的，Agent 是 AI 驱动的。人驱动的好处是稳定可靠靠谱，缺点是不够泛化；AI 驱动反过来，足够泛化，能解决之前没想到的问题，但十次里可能有五次搞砸。所以 AI 可能负责 20% 更开放的问题，剩下 80% 更常见的问题还是 Workflow。

那 Sheet0 跟其他 Agent 的核心区别是什么？王文锋的判断标准是看 deliver result，而不是看它好像什么都能干。按这个标准，Genspark、Deep Research、Manus 最后呈现的主要形式都是报告，Manus 做得更深一些，会给图表或简单网页，但本质还是报告的另一种表现形式，所以它们都是调研 Agent。另一类是 Coding Agent，结果就是代码本身。

Sheet0 把自己定义为表格 Agent。区别在分析问题的两种 mindset：定性分析用 Deep Research 这类报告，建立一种感觉；定量分析需要非常准确的数字，就要求数据源准确，数据源一般是一张完整干净的表格。Sheet0 做的事是把各种数据源先变成一张完整的结构化表格，再拿表格做下一步分析，而不是拿搜索接口抓一堆网页去总结。这是定性分析与定量分析的差异。

表格里的数据怎么避免幻觉？王文锋说工程上已经解决了。大模型负责分析页面结构、页面与页面之间的关系，通过这些分析生成一段脚本，真正收集数据、生成数据的过程用代码实现。代码是典型的能提供反馈信号的机制。另一个反馈信号来自表格本身：一个地方是空的，一眼就能看见。报告不一样，很难精确描述哪一行哪个字怎么样；表格是结构化的，可以描述。

两个信任命题，和一个判断 Agent 公司的提问 0:41:41

做 Agent 要解决两个信任问题。第一个是 Agent 开发者要足够相信大模型。如果不相信，就会在代码里不断加限制条件，比如在 prompt 里写「你是谁谁谁，你只能干某某事，不能干别的」。这样做的后果是大模型的泛化能力被人为压低，用王文锋的话说，Agent 对大模型的智能利用率下降。这种不信任会产生内心的不安感，促使开发者用传统的 rule-based 方式解决问题，最后发现是在开倒车。

第二个是用户对结果的信任，要靠产品设计去解决。他举了 DeepSeek R1 的例子：在 R1 之前用 Deep Research 类产品，看到报告第一眼会以批判的角度看，这东西到底是对的还是错的，因为不理解它怎么来的。R1 把中间的 reasoning 过程展示出来，心理上更舒适，看到它怎么想的，就更愿意信任结果。

曲凯补了一个观察：Manus 很大的价值是给所有 Agent 创业者打了个样，也许过段时间回头看，它就像当年的 ChatGPT，让大家知道上一代大模型最适合的产品形态是 ChatBot，现在很多 Agent 都是在 Manus 的基础上改。王文锋认同，说 Manus 是在 Deep Research 基础上在 UI 上更进一步，核心是把中间所有细节暴露出来，人看了之后会有满足感和安全感。

关于未来，王文锋认为以现在 AI 的速度预测几年太难，预测半年到一年更现实。他分享了一个思考框架：先抓关键变量。Agent 的关键变量是结果，而结果等于 Context 加模型。所以 Agent 要有突破，Context 或模型至少有一个突破。

模型侧的突破看两件事：更先进的 frontier model 什么时候出来，以及成本什么时候降下来。他估计 GPT-5 在今年年底左右出来，年底或明年元旦之后 Agent 能力会进一步；之后成本降到现在的五分之一甚至十分之一，可能还需要一年。frontier model 出来之后大家能做 demo、有预期，但只有成本降低，这东西才能规模化使用。他判断真正好用的、泛化能力强的 Agent 大规模用上，可能要等到 2026 年下半年。

Context 侧的突破可以看 Cursor 的例子：围绕 VS Code 做了大量二次开发，从 2022 年开始到 2024 年下半年，花了一年半，工程量非常大。很多人以为 Agent 的工程复杂度不高，王文锋认为这是误解，想让 Agent 在 Context 层面突破，需要大量工程尝试和积累。所以假设 DeepSeek 某天出来，大家第二天开始干，优秀团队干得快也得六个月，慢一点一年，今年 Q3 可能会有些更好的 Agent 产品出来。

曲凯最后问了一个投资人视角的问题：如果面前有很多 Agent 公司，会问哪几个问题判断好坏。王文锋的第一个答案是看团队里有没有人读过 Sutton 那本书。读过就会有 mindset，有这种 mindset 的人不会长期容忍用符号主义那套方法去达到结果。曲凯觉得这个要求有点高，很多人可能凑巧没看过。王文锋的备选问题是：你产品里的环境反馈激励信号是怎么设计的？在你这产品里，什么样的行为是好行为，什么样是差行为？

这个问题很关键。有了信号，才能让大模型把上一轮结果和环境给出的好坏评价放在一起迭代。从这个角度看，通用 Agent 确实不如垂直 Agent，因为通用场景下这个信号很难定义。

他还补充了一个容易被忽略的点：有了大模型之后，结构化数据依然重要。大模型的输入可以是非结构化的，文档、文本、PDF、图片一股脑塞进去；但输出一定得结构化，因为只有结构化了，才能用代码或规则去校验，否则没法校验。所谓激励信号，在代码层面最后体现为模型输出结果里某个字段的值到底是什么。

曲凯追问，如果让王文锋负责 Manus 这个产品，它的激励信号可能是什么。王文锋说想不到，因为从 Manus 官网的例子看，本质上还是让大模型本身或另一个 prompt 去判断结果是好的还是坏的。他举了自己的体验：写 PPT 开场白，让模型不断改，只说「不满意你改」，最后会陷入一个奇怪的死循环出不来。一定得提供大模型本身不具备的反馈信号，才能把结果从这个死循环里拉出来。

节目最后，曲凯让王文锋给三个理由，说明同样场景下为什么用 Sheet0 而不用 Manus、Genspark 或其他工具。王文锋说不用三个，一个就够：只要有高质量数据抓取的需求，市面上只有 Sheet0 能做到百分百准确率、百分百稳定、百分百不丢数据。产品在这周开放线上 waiting list，注册后大概两到四周能正式使用，官网是 sheet0.com。

这期对话能带走的东西，可以归成三条。判断一个 Agent 产品，先看它的 deliver result 是什么，再看它有没有清晰的激励信号，能说清什么行为算好、什么算差。判断一个 Agent 团队，可以问它的环境是什么、行动空间有多大、结果怎么定义，答不上来的团队大概率还在用符号主义的思路做产品。至于自己动手做 Agent 的人，先读一遍 Sutton，再想清楚两件事：你的产品能不能变成一个能提供反馈的环境，以及你有没有因为不信任大模型而亲手压低了它的智能利用率。