Yutori联合CEO: AI Agent最大的问题，没人真正聊过丨EO

Yutori联合CEO: AI Agent最大的问题，没人真正聊过丨EO Yutori联合CEO: AI Agent最大的问题，没人真正聊过丨EO Modified May 17 🔗 原文链接： https://mp.weixin.qq.com/s/t8N2YG0k... 原创 Capihom Capihom 晚点再听LaterCast2026年5月17日 22:40 北京我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约3900 字，如果你现在没有时间，试试转成播客稍后再听 "如果第一次用就跑不通，它还不够好。" "10 步、20 步、50 步的流程里，10% 的错误会很快复利。" "原型现在很容易做出来，差异在品味和工艺。" Abhishek Das 是 Yutori 的联合创始人兼联合 CEO，团队正在做能替用户在网页上完成任务的 AI Agent。他和另外两位联合创始人都出身 AI 研究，Abhishek 还参与过 Grad CAM 论文，用可视化方式解释模型到底看了图像的哪一部分。EO 这期对话短，但判断很硬：Agent 产品现在最大的问题，并非想象力不够，而是行业正在接受低可靠。当一个产品说自己能替你做事，第一次试用却跑不通，用户失去的不是耐心，是信任。 Abhishek 来自医生家庭，却因为怕血没有走医学路线，后来在 IIT Roorkee 学电气工程。大一之后，他发现自己更想写软件，开始泡在学校的 SDS Labs 编程社群里，和一群同样着迷的人为校园用户做应用、熬夜加功能、观察真实用户怎样点击和反馈。这个早期经历，让他谈 Agent 时一直盯着可用性，而不是只谈模型能力。低可靠，正在被包装成新常态 Abhishek 开场就把矛头指向今天常见的 Agent 产品：市面上有上百个产品都在说自己“能做网页上的任何事”，用户点进去试一次，结果常常并不能工作。他最反感的，是行业开始习惯这种状态，仿佛 Agent 天然就该不稳定，试十次能跑对三五次也可以交付。他把这件事看成产品底线问题：替用户行动的系统，不能把失败当成体验的一部分。 "我不喜欢大家把粗糙、非确定性和低可靠正常化，尤其是在 Agent 产品里。" 对产品团队来说，这个判断很刺耳。很多 AI 产品把“模型还会进化”当成缓冲，把失败解释成早期技术的必经阶段。Abhishek 的标准更接近传统软件交付：用户第一次把任务交给你，就应该看到结果。网页 Agent 涉及登录、点击、滚动、输入、确认，每一步都在替用户承担后果，可靠性不再是加分项，而是进入场景的门票。他甚至用了一个产品人很少会绕开的词：annoyed。这份不满来自 builder 的日常追问：为什么一个产品可以宣称“什么都能做”，同时又默认用户第一次就要容忍失败？网页任务里的失败往往不是小瑕疵，可能是表单填错、订单点错、信息抓错、流程停在一半。Agent 一旦开始替人操作，产品责任也跟着变重。长任务失败，常常死在第十步 Agent 和聊天机器人最大的差别，在于它要连续做决定。Abhishek 举了一个非常产品化的算法账：一个 10 步、20 步甚至 50 步的网页流程，即使每一步准确率都有 90%，那 10% 的错误也会连续累积。到整条流程结束时，成功率会明显下滑。长任务不是把短任务串起来那么简单，错误会沿着流程放大。 "如果每一步有 90% 的准确率，10% 的错误率会很快复利，整个工作流的成功率就会很低。" 这也是他认为长周期工作流还没到位的原因。Agent 可以在演示里完成一个漂亮动作，却可能在真实网站里卡在第八个按钮、第二十次跳转、一次验证码或一个文案变化上。对工程师和产品经理来说，判断一个 Agent 能不能上线，不能只看单点 demo，要看整条链路的累计成功率，尤其要看它在失败后的恢复能力。 Abhishek 描述的未来浏览器体验，并不是用户继续打开网页、逐项点击、手动完成“数字家务”。他认为 5 到 10 年后，人和网页的交互会进入更高抽象层：用户告诉助手目标，助手在后台替你完成具体动作。这个愿景很诱人，但也把可靠性要求拉高了。用户愿意把琐事交出去，前提是系统别把琐事变成返工。会认错，才有资格替用户行动 Yutori 在训练和上线 Agent 时，把“认错”和“回退”放在很重要的位置。Abhishek 说，模型在新网站上点错按钮、误读页面，是自然会发生的事，人类也会犯类似错误。差别在于，系统能不能发现路径不对，退回上一步，换一个分支继续完成任务。 Agent 产品的可靠性，不只来自做对，也来自犯错后的自我修复。 "当它犯错时，能不能识别错误、回退，然后走另一条路径，这是训练和发布模型时非常重要的部分。" 为此，Yutori 给每一次生产环境查询都接入一套相对完整的 evals 和 guardrails，用来识别 Agent 在哪些领域表现好、哪些领域还需要训练。这个做法没有演示视频那么性感，却更接近真实产品工程：每个用户任务都在产生质量信号，团队必须知道失败发生在哪个域名、哪类页面、哪种动作上。网页不会等模型训练完 Web Agent 面临一个很现实的约束：团队永远不可能在世界上所有网站上训练模型。新网站每天出现，老网站也会改版。Yutori 能训练的，只会是有限网站集合，然后让模型带着这些经验去处理更开放的网页环境。Abhishek 用这个事实解释了为什么错误不可避免，但产品不能停在“模型会错”这一步。 "我们永远只能在有限的网站集合上训练模型，世界上的网站数量已经非常大，新网站还在不断出现。" 这段话对创业公司尤其直接。很多团队会把能力边界藏在营销话术里，用“能操作网页”覆盖复杂差异。Abhishek 的路线更克制：承认开放网页很难，然后把训练、回退、错误识别和质量评估一起做厚。用户不需要知道每个网站背后的技术难点，但用户会立刻感受到一次失败的点击。他还提到一个很生活化的目标：让更多人能使用网页。比如父母不需要重新学习每个新网站的操作逻辑，只要告诉助手“我想在这个网站上做什么”，系统就能可靠执行。这里的重点放在降低门槛：把不会用、懒得用、用起来费劲的网页流程交给助手处理。Agent 如果能做到这一点，价值会比炫技式自动点击更扎实。用户没说出口的需求，靠直觉补上谈到产品取舍，Abhishek 没把用户反馈神化。Yutori 会听用户说想要什么，也会在 100 个可做功能里挑最该做的 10 个。但他强调，很多好功能并不会被用户明确说出来，团队要靠产品直觉补上。iOS 和 Android 自动读取短信验证码、填入对应 App，就是他喜欢的案例：用户很难主动提出这个功能，却每天省下几秒钟。 "它每天为全世界的人节省好几次几秒钟，那种小东西会让用户觉得：有人真的在替我减少日常里的摩擦。" 这段对 AI 产品尤其重要。Agent 要进入的是用户日常里最琐碎、最烦、最不想重复的“数字家务”。只听需求列表，团队很容易堆功能；盯住摩擦，团队才会把等待、复制、验证、回填、检查这些细节做顺。好 Agent 不只替用户完成大任务，也应该消掉那些一天出现很多次的小刺。原型越容易，品味越值钱 Abhishek 对 coding LLM 的判断很清楚：现在做第一个原型变得非常容易，真正拉开差距的地方，会转向 taste 和 craft，也就是产品品味和工艺。任何团队都能很快拼出一个“能跑”的版本，但用户会在交互、直觉、可靠性、细节一致性上判断它是否值得信任。 AI 降低的是起步门槛，抬高的是成品标准。 "在用 coding LLM 很容易做出第一个原型的世界里，差异在品味和工艺，在产品是否直觉、是否设计良好。" 这也是很多 AI 工具团队接下来会遇到的分水岭。早期演示靠能力抓眼球，后期留存靠体验留住人。尤其是 Agent，产品品味不只是视觉和文案，还包括什么时候请求权限、失败时怎么说、执行中给多少可见进度、任务完成后让用户怎样复核。技术能力相近时，这些细节会成为用户迁移成本。每周 dogfood，训练“魔法感” Yutori 团队每周都会留出一到一个半小时，专门 dogfood 自己的新功能。Abhishek 说，团队内部任何时候都在跑几十个实验，最后可能只有一个会进入外部用户能看到的生产版本。这个节奏听上去很朴素，却是他们校准“好”和“坏”的主要方式。所谓魔法感，不靠会议定义，靠团队反复亲手使用。 "我们每周都会留出一小时到一个半小时 dogfood 新功能；任何时候内部都跑着几十个实验，也许只有一个会发到生产版本。" 这套方法对小团队很实用。AI 产品变化快，外部用户反馈慢半拍，团队如果不把自己放进真实流程，很容易只优化指标表里的数字。每周固定使用，让工程、产品和研究一起面对同一个卡点：页面理解失败、动作太慢、结果不可复核、反馈太含糊。使用次数越多，团队越能分辨“差一点能用”和“用户愿意交给它”。这也和他早年在校园里做应用的经历连在一起：把东西做出来，放到真实用户面前，看他们怎么用，再熬夜补功能。今天工具变强了，团队更容易跳过这些笨功夫。Abhishek 的态度相反，AI 可以加速原型，但不能替团队积累产品手感。一次次亲手使用，才会知道哪里像魔法，哪里只是模型侥幸跑通。让用户看见 Agent 做过什么 Abhishek 早年参与的 Grad CAM 论文，关心的是模型做出分类预测时，到底看了图像的哪一部分。他把这种“proof of work”的思路带到了 Yutori 产品里。用户设置 scouts 和 agents 监控网页后，系统会生成报告并提醒用户；界面里还有一个按钮，可以检查背后访问了哪些网站、Agent 看了什么、信息从哪里来。 "模型不只要给出最终预测或答案，也要能传达背后的工作过程。" 信任往往来自这些可检查的痕迹。用户看不到模型权重、训练集和内部规划，但能看到产品有没有给出路径、来源和复核入口。Abhishek 说，如果团队在用户看得见的部分投入足够细节，用户也更可能相信那些看不见的部分。 Agent 想拿到更多权限，先要让用户知道它刚才怎样完成任务。写在最后 Agent 产品最容易让人兴奋的地方，是它看起来能替人做很多事。Abhishek 提醒团队先回到一个更硬的标准：第一次能不能跑通，失败后能不能修复，用户能不能复核过程。把这些做好，AI 才会从演示里的能力，变成日常工作里可以托付、可以反复复用的工具。内容来源："The Problem with AI Agents No One is Talking About"丨EO 原视频：https://www.youtube.com/watch?v=wRDk9 JoIic No access e2b042fb6ae54254af330d848cb2bcad 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/t8N2YG0k... 🔗 原文链接： https://mp.weixin.qq.com/s/t8N2YG0k... https://mp.weixin.qq.com/s/t8N2YG0k... 原创 Capihom Capihom 晚点再听LaterCast2026年5月17日 22:40 北京我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约3900 字，如果你现在没有时间，试试转成播客稍后再听 "如果第一次用就跑不通，它还不够好。" "10 步、20 步、50 步的流程里，10% 的错误会很快复利。" "原型现在很容易做出来，差异在品味和工艺。" Abhishek Das 是 Yutori 的联合创始人兼联合 CEO，团队正在做能替用户在网页上完成任务的 AI Agent。他和另外两位联合创始人都出身 AI 研究，Abhishek 还参与过 Grad CAM 论文，用可视化方式解释模型到底看了图像的哪一部分。EO 这期对话短，但判断很硬：Agent 产品现在最大的问题，并非想象力不够，而是行业正在接受低可靠。当一个产品说自己能替你做事，第一次试用却跑不通，用户失去的不是耐心，是信任。 Abhishek 来自医生家庭，却因为怕血没有走医学路线，后来在 IIT Roorkee 学电气工程。大一之后，他发现自己更想写软件，开始泡在学校的 SDS Labs 编程社群里，和一群同样着迷的人为校园用户做应用、熬夜加功能、观察真实用户怎样点击和反馈。这个早期经历，让他谈 Agent 时一直盯着可用性，而不是只谈模型能力。低可靠，正在被包装成新常态 Abhishek 开场就把矛头指向今天常见的 Agent 产品：市面上有上百个产品都在说自己“能做网页上的任何事”，用户点进去试一次，结果常常并不能工作。他最反感的，是行业开始习惯这种状态，仿佛 Agent 天然就该不稳定，试十次能跑对三五次也可以交付。他把这件事看成产品底线问题：替用户行动的系统，不能把失败当成体验的一部分。 "我不喜欢大家把粗糙、非确定性和低可靠正常化，尤其是在 Agent 产品里。" 对产品团队来说，这个判断很刺耳。很多 AI 产品把“模型还会进化”当成缓冲，把失败解释成早期技术的必经阶段。Abhishek 的标准更接近传统软件交付：用户第一次把任务交给你，就应该看到结果。网页 Agent 涉及登录、点击、滚动、输入、确认，每一步都在替用户承担后果，可靠性不再是加分项，而是进入场景的门票。他甚至用了一个产品人很少会绕开的词：annoyed。这份不满来自 builder 的日常追问：为什么一个产品可以宣称“什么都能做”，同时又默认用户第一次就要容忍失败？网页任务里的失败往往不是小瑕疵，可能是表单填错、订单点错、信息抓错、流程停在一半。Agent 一旦开始替人操作，产品责任也跟着变重。长任务失败，常常死在第十步 Agent 和聊天机器人最大的差别，在于它要连续做决定。Abhishek 举了一个非常产品化的算法账：一个 10 步、20 步甚至 50 步的网页流程，即使每一步准确率都有 90%，那 10% 的错误也会连续累积。到整条流程结束时，成功率会明显下滑。长任务不是把短任务串起来那么简单，错误会沿着流程放大。 "如果每一步有 90% 的准确率，10% 的错误率会很快复利，整个工作流的成功率就会很低。" 这也是他认为长周期工作流还没到位的原因。Agent 可以在演示里完成一个漂亮动作，却可能在真实网站里卡在第八个按钮、第二十次跳转、一次验证码或一个文案变化上。对工程师和产品经理来说，判断一个 Agent 能不能上线，不能只看单点 demo，要看整条链路的累计成功率，尤其要看它在失败后的恢复能力。 Abhishek 描述的未来浏览器体验，并不是用户继续打开网页、逐项点击、手动完成“数字家务”。他认为 5 到 10 年后，人和网页的交互会进入更高抽象层：用户告诉助手目标，助手在后台替你完成具体动作。这个愿景很诱人，但也把可靠性要求拉高了。用户愿意把琐事交出去，前提是系统别把琐事变成返工。会认错，才有资格替用户行动 Yutori 在训练和上线 Agent 时，把“认错”和“回退”放在很重要的位置。Abhishek 说，模型在新网站上点错按钮、误读页面，是自然会发生的事，人类也会犯类似错误。差别在于，系统能不能发现路径不对，退回上一步，换一个分支继续完成任务。 Agent 产品的可靠性，不只来自做对，也来自犯错后的自我修复。 "当它犯错时，能不能识别错误、回退，然后走另一条路径，这是训练和发布模型时非常重要的部分。" 为此，Yutori 给每一次生产环境查询都接入一套相对完整的 evals 和 guardrails，用来识别 Agent 在哪些领域表现好、哪些领域还需要训练。这个做法没有演示视频那么性感，却更接近真实产品工程：每个用户任务都在产生质量信号，团队必须知道失败发生在哪个域名、哪类页面、哪种动作上。网页不会等模型训练完 Web Agent 面临一个很现实的约束：团队永远不可能在世界上所有网站上训练模型。新网站每天出现，老网站也会改版。Yutori 能训练的，只会是有限网站集合，然后让模型带着这些经验去处理更开放的网页环境。Abhishek 用这个事实解释了为什么错误不可避免，但产品不能停在“模型会错”这一步。 "我们永远只能在有限的网站集合上训练模型，世界上的网站数量已经非常大，新网站还在不断出现。" 这段话对创业公司尤其直接。很多团队会把能力边界藏在营销话术里，用“能操作网页”覆盖复杂差异。Abhishek 的路线更克制：承认开放网页很难，然后把训练、回退、错误识别和质量评估一起做厚。用户不需要知道每个网站背后的技术难点，但用户会立刻感受到一次失败的点击。他还提到一个很生活化的目标：让更多人能使用网页。比如父母不需要重新学习每个新网站的操作逻辑，只要告诉助手“我想在这个网站上做什么”，系统就能可靠执行。这里的重点放在降低门槛：把不会用、懒得用、用起来费劲的网页流程交给助手处理。Agent 如果能做到这一点，价值会比炫技式自动点击更扎实。用户没说出口的需求，靠直觉补上谈到产品取舍，Abhishek 没把用户反馈神化。Yutori 会听用户说想要什么，也会在 100 个可做功能里挑最该做的 10 个。但他强调，很多好功能并不会被用户明确说出来，团队要靠产品直觉补上。iOS 和 Android 自动读取短信验证码、填入对应 App，就是他喜欢的案例：用户很难主动提出这个功能，却每天省下几秒钟。 "它每天为全世界的人节省好几次几秒钟，那种小东西会让用户觉得：有人真的在替我减少日常里的摩擦。" 这段对 AI 产品尤其重要。Agent 要进入的是用户日常里最琐碎、最烦、最不想重复的“数字家务”。只听需求列表，团队很容易堆功能；盯住摩擦，团队才会把等待、复制、验证、回填、检查这些细节做顺。好 Agent 不只替用户完成大任务，也应该消掉那些一天出现很多次的小刺。原型越容易，品味越值钱 Abhishek 对 coding LLM 的判断很清楚：现在做第一个原型变得非常容易，真正拉开差距的地方，会转向 taste 和 craft，也就是产品品味和工艺。任何团队都能很快拼出一个“能跑”的版本，但用户会在交互、直觉、可靠性、细节一致性上判断它是否值得信任。 AI 降低的是起步门槛，抬高的是成品标准。 "在用 coding LLM 很容易做出第一个原型的世界里，差异在品味和工艺，在产品是否直觉、是否设计良好。" 这也是很多 AI 工具团队接下来会遇到的分水岭。早期演示靠能力抓眼球，后期留存靠体验留住人。尤其是 Agent，产品品味不只是视觉和文案，还包括什么时候请求权限、失败时怎么说、执行中给多少可见进度、任务完成后让用户怎样复核。技术能力相近时，这些细节会成为用户迁移成本。每周 dogfood，训练“魔法感” Yutori 团队每周都会留出一到一个半小时，专门 dogfood 自己的新功能。Abhishek 说，团队内部任何时候都在跑几十个实验，最后可能只有一个会进入外部用户能看到的生产版本。这个节奏听上去很朴素，却是他们校准“好”和“坏”的主要方式。所谓魔法感，不靠会议定义，靠团队反复亲手使用。 "我们每周都会留出一小时到一个半小时 dogfood 新功能；任何时候内部都跑着几十个实验，也许只有一个会发到生产版本。" 这套方法对小团队很实用。AI 产品变化快，外部用户反馈慢半拍，团队如果不把自己放进真实流程，很容易只优化指标表里的数字。每周固定使用，让工程、产品和研究一起面对同一个卡点：页面理解失败、动作太慢、结果不可复核、反馈太含糊。使用次数越多，团队越能分辨“差一点能用”和“用户愿意交给它”。这也和他早年在校园里做应用的经历连在一起：把东西做出来，放到真实用户面前，看他们怎么用，再熬夜补功能。今天工具变强了，团队更容易跳过这些笨功夫。Abhishek 的态度相反，AI 可以加速原型，但不能替团队积累产品手感。一次次亲手使用，才会知道哪里像魔法，哪里只是模型侥幸跑通。让用户看见 Agent 做过什么 Abhishek 早年参与的 Grad CAM 论文，关心的是模型做出分类预测时，到底看了图像的哪一部分。他把这种“proof of work”的思路带到了 Yutori 产品里。用户设置 scouts 和 agents 监控网页后，系统会生成报告并提醒用户；界面里还有一个按钮，可以检查背后访问了哪些网站、Agent 看了什么、信息从哪里来。 "模型不只要给出最终预测或答案，也要能传达背后的工作过程。" 信任往往来自这些可检查的痕迹。用户看不到模型权重、训练集和内部规划，但能看到产品有没有给出路径、来源和复核入口。Abhishek 说，如果团队在用户看得见的部分投入足够细节，用户也更可能相信那些看不见的部分。 Agent 想拿到更多权限，先要让用户知道它刚才怎样完成任务。写在最后 Agent 产品最容易让人兴奋的地方，是它看起来能替人做很多事。Abhishek 提醒团队先回到一个更硬的标准：第一次能不能跑通，失败后能不能修复，用户能不能复核过程。把这些做好，AI 才会从演示里的能力，变成日常工作里可以托付、可以反复复用的工具。内容来源："The Problem with AI Agents No One is Talking About"丨EO 原视频：https://www.youtube.com/watch?v=wRDk9 JoIic No access e2b042fb6ae54254af330d848cb2bcad 00:00 No access e2b042fb6ae54254af330d848cb2bcad 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣

在小宇宙note 阅读完整内容