.png?table=collection&id=cbe6506e-1263-8358-a4d7-07ce62fcbb3f&t=cbe6506e-1263-8358-a4d7-07ce62fcbb3f)
AI Agent 协作新范式：Paperboy 探索人机协作的未来
type
status
date
slug
summary
tags
category
icon
password
网址
🚥本周，十字路口的嘉宾是 Paperboy 团队（https://www.paperboy.com[1]）。John Yang 21 岁，CEO。Jett Chen 19 岁，CMU 大一在读，同时是 founding engineer。Paperboy 团队 12 人，10 位工程师，融资 470 万美金。
John 认为：人类和 AI Agent 配合工作的最佳方式，很可能还没被发明出来。虽然已经有了 Claude Code、Codex、Manus、OpenClaw，但它们本质上都是 session-based + prompt-based。用户需要打开一个窗口，输入 prompt，等完成，关掉。下次从零开始。
Paperboy 正在尝试找到一种更自然、更连续、更可协作的 Agent 界面与记忆结构——Agent 应该通过观察你用电脑来自己学习，用 IM 而不是 session 来组织对话，主动找你，而不是等你 prompt。
如果你在做 AI 产品、AI infra、或正在思考 Agent 如何进入团队工作流，希望这期内容会给你启发。
快问快答
👦🏻 Koji
我们还是从十字路口的传统，快问快答开始，请问二位的年龄？
🧑🏻💻 John Yang
21。
👨🏻💻 Jett Chen
19。
👦🏻 Koji
毕业院校是？
🧑🏻💻 John Yang
没毕业，之前在 Pratt Institute 读建筑。
👨🏻💻 Jett Chen
我高中毕业于上海星河湾双语学校，现在在 CMU 读大一，刚刚结束。
👦🏻 Koji
你们的 MBTI 和星座是什么？
🧑🏻💻 John Yang
ISTJ，双子座。
👨🏻💻 Jett Chen
INTJ，处女座。
👦🏻 Koji
创业之前，你们做了些什么？
🧑🏻💻 John Yang
Paperboy 是我的第二家公司。我的第一家公司叫 Million，我们在 React Ecosystem 里做了很多开源的 Dev Tools，后来做了一个产品叫 Same.Dev，能让普通人通过输入一个 URL，就做出和任何网站一模一样的 UI。
Million 是在 YC Winter 24 中的。
👨🏻💻 Jett Chen
在 Paperboy 之前我是个高中生，喜欢做开源项目和打 CTF。我做了一个叫 EarthKit 的东西，可以基于一张照片，用多模态技术推测出它的拍摄地点，效果比传统的纯神经网络模型更好。
👦🏻 Koji
那是什么时候做的？
👨🏻💻 Jett Chen
差不多一两年前。
起点：现在的 AI 产品，我用着不爽
👦🏻 Koji
我们来介绍一下，Paperboy 是一个什么样的产品？
🧑🏻💻 John Yang
Paperboy 是一家刚刚起步的公司，使命是探索我和 AI 协作的最佳方式。
去年，在我做完 Same 和用过 Manus 之后，我对市面上的 AI 产品总有一些不爽。Paperboy 就是从我尝试各种方法，不断摸索不同路径开始的。我们试图解决一些技术问题，也包括产品形态的问题。
比如，我不应该需要把自己的文件、Email 和所有个人信息都丢到一个聊天框里。如果我要和别人协作，同时跟一个 Agent 对话，应该有一种非常简单的方式，让我们在同一个上下文窗口里完成。
再比如，Agent 在知道我的很多信息后，应该能主动地提前帮我做一些事情，但现在的聊天窗口完全做不到。而且，现在所有的产品都是基于会话的，session 一多，你就找不到之前聊天的上下文了。
这些问题，总体上是模型能力和实际应用之间的差距。我觉得在产品体验上，依然有巨大的探索和创新机会，所以我们公司叫“Paperboy Products”，是产品、是复数。
👦🏻 Koji
我们稍后展开聊。先完成快问快答，你们的融资情况如何？
🧑🏻💻 John Yang
25年我们融了470万。
👦🏻 Koji
Cool。收入和利润呢？产品还没发布对吧？
🧑🏻💻 John Yang
毛利为零甚至是负的，我们每天都在亏钱哈哈哈。
👦🏻 Koji
大家大概什么时候能用上产品？
🧑🏻💻 John Yang
我们已经把一个能从操作系统活动中学习的 Agent 原型发给了一些朋友。
但它成本太高了，而且运行得不太好。我们正在努力这个月内完成下一代产品，然后会再次推向市场。
👦🏻 Koji
我们发布这期播客时，会把链接放在下面，感兴趣的朋友可以去 sign up for waitlist。
🧑🏻💻 John Yang
Yeah，我想当这期播客发布时，大家应该就能看到了。
👦🏻 Koji
好的，目前团队规模是？
🧑🏻💻 John Yang
12 个全职员工，其中 10 位是工程师。
👦🏻 Koji
我第一次见 John 的时候，你给我看了一份给团队内部开会用的文档，第一句话就是：“人类与 AI 协作的最佳方式，很可能还没有被发明出来。”
写下这句话时你看到了什么？到现在，你的看法有变化吗？
🧑🏻💻 John Yang
对，那是我们第一次全体会议时我准备的文档。当时公司只有我、杜哥、Chen、Jett 四个人。
我们从一个核心理念出发：与 AI 协作的最佳方式尚未被发明，而我们有机会成为找到那个答案的团队。Cursor 最早开始努力寻找与 AI 编程的最佳方式，并且取得了巨大的成功，他们是第一家真正专注在这个目标上的公司，也证明了抢先一步是多么重要。
你问我从那时到现在有什么新的感悟。我觉得很酷的一点是，这其实是一个不断移动的目标。
你永远无法真正达到市场的期望，只能不断变得更好。因为每当你做出新东西，其他人都会看到。如果别的团队有品味，用户有品味，他们就能发现新的痛点，痛点永远存在，所以你唯一能做的就是持续改进。
这是一个不断移动的目标。自从 OpenClaw 和 Anthropic 的 Claude Cowork 发布以来，这个感觉更强烈了。
👦🏻 Koji
最近很多创始人感到有些绝望，因为创业过程中不断有“王炸”出现。你们公司成立的这半年，也恰好是行业剧烈变化的半年，从 Claude Code 到 OpenClaw，再到 Hermes。
你的感受是什么？你最初想做的东西，和现在在做的，有没有因为这些巨头的出现而发生剧烈改变？
Claude Code 轰炸之下
🧑🏻💻 John Yang
其实没有。我认为问题的探索空间源自于人。
从技术和产品的角度看，问题可以分为三类：
第一，技术上，要让 Agent 能够真正从用户的环境中学习。它必须融入用户已有的工作流，也就是数据产生的地方，比如电脑上的文件和各种软件。
第二，它必须是个性化的。个性化意味着你不需要频繁地提示它，可以信任它处理更复杂、更重要的任务和决策。这也意味着它要更可靠，能在更长的时间周期里持续运行。
第三，设计上，它的体验必须极其直观，用户不需要像学一个新工具那样去学习它。如果你的 Agent 足够主动，能自己提出新想法，那么用什么形态来承载这些主动的产出呢？它需要在一个完整的环境中，需要个性化，并且能和你现有的团队很好地协作。
所以，当你审视市面上的新工具时，会发现并没有出现什么新的维度。这三个维度的发展，仍然受限于人类团队本身。
Agent 的两大问题
Cursor 和 Manus 是目前最成功的 agent 形态，但 John 说它们有两个根本性的问题——这直接定义了 Paperboy 要做的事。
👦🏻 Koji
可以简单向大家推荐一下 Paperboy 吗？听我们播客的很多人可能已经是 Claude Code、Manus 或其他 Agent 的重度用户了，为什么他们要给 Paperboy 一个机会？
🧑🏻💻 John Yang
目前，Claude Code 和 Manus 是最成功的 Agent 形式，但它们是基于会话的（session-based），也是一对一、基于prompt的。
这带来了两个重要问题。首先，session-based 意味着在它们的侧边栏里，你有多个工作区（项目），每个项目下又有一堆会话。每次想让模型做点新事，就得开启一个新会话。
其次，你与模型的交互方式是，你输入提示词，然后等待，再发一条消息，它再回复。
这种方式的问题在于：
第一，Agent 是被动的。你必须描述得非常具体。你可以创建技能文档（比如 agent.md）来告诉它该做什么，但你得主动维护它，而且很难把你的品味、判断和做事方式，完整地转化为纯文本。
第二，会话是不连续的。拥有几百个甚至几千个会话是件很糟糕的事。我知道在过去的某些会话里，上下文窗口中包含了非常有价值的见解，但如果我当时没有刻意保存下来，那这些信息就永远丢失了。
Paperboy 正面解决了这两个问题。
第一，Agent 必须通过观察你如何使用电脑来自己学习。这包括你的屏幕截图、键盘敲击、鼠标移动、会议音视频、浏览记录、iMessage 等等——当然，前提是你授权 Paperboy 访问这些信息。
第二，交互应该存在于持续的聊天流中，拥有比单个上下文窗口长得多的历史记录，并且可以被搜索。标准的产品形态应该像 iMessage 或微信，你有一堆聊天，点进去就可以和里面的参与者继续对话。
👨🏻💻 Jett Chen
补充一下 session 和 context window 的问题。现在类似 Claude Code、Manus 这类产品，你可以 argue 它们有无限的 context window，因为它们有 compaction 机制。
一些更新的产品，比如 Interaction 公司的 Poke、Zo Computer，甚至 OpenClaw，也采用了类似的形式——不存在 session，你和 Agent 的互动一直是持续的对话流。
Paperboy 和这类产品的一个主要区分点在于 context 的来源。它们的 context 主要来自用户与 Agent 的历史聊天记录，或者用户主动提供的 Email、messages 等。我们一开始也尝试过导出用户的微信或 iMessage 聊天数据，但很快发现这不是一个可规模化的方式。
最 scalable 的方式，其实是通过操作系统层面，去观察用户的日常电脑使用来收集数据。我们发现，这样能非常全面地了解用户每天在做什么。
而且从信息浓度的角度看，用户日常使用电脑的信息浓度非常高，观察 60 分钟电脑使用，能学到的东西远比观察 60 分钟微信聊天要多。
所以，我们很早就决定，通过 OS 层面的 context 来实现用户自适应。
屏幕数据成了行业共识之后
「收集用户屏幕数据去构建 Context Layer，已经一定程度上成为行业共识。」
👦🏻 Koji
之前播客的嘉宾，AirJelly 的创始人，他们做的也是一个桌面客户端，用来捕捉用户尽可能多的上下文。最近 OpenAI 的 Chronicle 也是类似的想法。
你们的做法和大家类似吗？还是有什么不同？
🧑🏻💻 John Yang
从电脑上抓取原始数据并将其处理成记忆，这将成为一个普遍的趋势。不只是像 AirJelly 这样专注做这件事的创业公司，Codex、Claude Cowork、Claude Code 这些产品最终都会这么做，这是下一个最显而易见的上下文前沿。
当然，不同团队处理这些原始流数据的方式会很不一样。你如何选择和结构化这些信息，直接关系到 Agent 的具体应用。比如，一家专注于研究用户如何回复邮件的公司，和我们的记忆结构、压缩原始数据流的方式就会完全不同。
这个行动空间足够大，现在还有足够的机会，让你成为第一个真正理解用户在所有应用、所有人际关系中的身份，并对用户一天的行为进行建模的公司。
单凭这种能力，就很明显会吸引所有人涌入。但根据具体应用的不同，算法的定制和改变仍有很大空间。
👨🏻💻 Jett Chen
我也认为通过收集用户屏幕或电脑使用数据来构建 context，在某种程度上已经成为行业共识。更重要的是，在这个范式下你具体做什么。
目前像 Codex 或 Littlebird 这类产品，会把屏幕数据当作一个 context layer。比如 Codex Chronicle 的用例是，通过收集屏幕数据，学习用户通常如何开发一个应用。如果你的用例不同，最终的 pipeline 也会不同。
这是一个非常新的领域。在收集用户数据的基础上，其实还可以做非常多的事，这需要大量的工程和研究。比如，如何做出最好的主动型 Agent？是预测用户的下一个按键，还是预测他接下来一小时要做什么？这些都是相对未被充分探索的问题空间。
目前我认为还没有人找到一个绝对最好的方案，所以对一家公司来说，探索这个领域仍然是很好的选择。
👦🏻 Koji
如果一个用户今天安装了 Paperboy，他在第一个小时甚至前 5 分钟，能感受到的最大价值是什么？你们希望用户第一时间感受到的亮点是什么？
🧑🏻💻 John Yang
我们可能会从会议准备开始。
在一个小时内，很重要的一点是向用户展示你的产品能做什么的框架，设定好预期。关于记忆，有一个特点是，你用得越久，它就越好。所以你需要一个初始阶段让用户信任它去学习。
当你打开它，会看到一个真实的聊天窗口，而不是一个简单的提示框。一旦你授权它访问你的日历和邮件，它就会开始阅读你给它的信息，然后会问一些关于你是谁的小问题，并开始给出一些建议，比如：“嘿，我看到你接下来有个会议，需要我帮你看看相关资料吗？”
在这方面，我觉得 Interaction 公司的 Poke 做得最好，他们找到了秘诀：连接到用户已有的上下文，并向用户展示你是一个能真正互动、适应他们性格、并且以一种主动而不烦人的方式提供帮助的智能体。
这样，你就能让用户建立起一种期望：我们是一个能以合理方式主动给你发消息的 Agent。
MiniVivian & AutoJohn
👦🏻 Koji
你们团队自己用 Paperboy 多久了？在这个过程中，有什么可以分享的 “Aha Moment” 吗？
🧑🏻💻 John Yang
我们团队的 Vivian，她之前在小红书和红杉YUE 工作。我们有一个 Vivian 的 Paperboy，叫 MiniVivian。我的 Paperboy 叫 AutoJohn。在我们的 Slack 里，团队成员会一直直接问 AutoJohn 问题，它能处理所有进来的询问，帮助产品和设计团队找到他们需要的帮助。
以 MiniVivian 为例，Vivian 做很多招聘工作，MiniVivian 就像是她在团队里的招聘实习生。因为它理解我曾对它说过的所有关于我们想招什么样的人、从哪里招人的判断和品味——这些信息来自我们的会议和 Slack 沟通。它能更准确地帮助 Vivian 在 GitHub、小红书、Twitter 上挖掘候选人，为她节省了大量时间。
我想 Vivian 从今年二月起就没再用过 Claude 了。她没法用，因为 Claude 不了解这些背景，你没法让它帮你做候选人背调，有太多关于判断标准的事情你必须从头告诉它。
👦🏻 Koji
因为它有了更多的 context，所以你 prompt 的时候，甚至可以不 prompt。
🧑🏻💻 John Yang
是的，我讨厌 prompting。从我做 Same 的时候开始，我就不想写提示词。当然你需要沟通，但我们人类思考不是用提示词，我们是发信息，并且期望对方知道我们在说什么。我们享受那种高带宽的沟通关系。
我想，聪明的人都乐于被告知自己不知道的事情，尤其是那些“我们不知道自己不知道”的事。
今天的模型比我们更聪明，所以坦白说，我期待有一天，我可以直接躺平，让 AutoJohn 成为一个比我更聪明、IQ 更高的存在。
👦🏻 Koji
Jett 呢？你在使用 Paperboy 的过程中有什么 “Aha Moment”？
👨🏻💻 Jett Chen
首先，确实很多时候和 John 的 “AutoJohn” 聊天，会比和 John 本人聊天更好。
👦🏻 Koji
当你和他的 Agent 替身对话时，会担心它的意志不能完全代表 John，从而产生误解吗？
🧑🏻💻 John Yang
我的看法是，用户最终必须为自己的 Agent 负责。AutoJohn 的设置过程不是一蹴而就的，不是说某天突然就有了一个可以拉进 Slack 的实体。
这中间有一个引导流程，Agent 会问你问题，比如：“允许我向这个人分享多少信息？” 默认情况下，它会模仿我的行为，比如我和 Jett 分享得多，和新入职的工程师就分享得少，Agent 通过观察我所有的聊天记录就能知道这一点。
👨🏻💻 Jett Chen
和一个人互动其实分很多种情况。有些事我不会去和 AutoJohn 说，比如需要 John 本人批准的权限问题。但在工作场景中，很多沟通是基于信息的。John 有整个 Paperboy 公司的 context，我作为一个工程师，需要知道如何做才能对公司产生最大价值。
这时候，因为 AutoJohn 一方面在事实上拥有 John 大部分的 context，另一方面通过观察 John 的工作，它的启发式能力和 John 本人非常相似。所以，在做关于 context 和 heuristic 的决策时，我觉得 AutoJohn 非常有用。
我其他的 “Aha Moment” 来得比较早。当我们做出文本补全功能时，我就觉得对我日常编程很有用。
现在有很多 AI 命令行工具很火，但它们不如传统的流畅。而传统工具又往往没有 AI 集成，写脚本时很烦。有了文本补全后，我写完一堆代码，要发一个 git commit 时，可以直接在命令行里输入 “@pb commit”，它就会自动帮我写好整个 commit message，我按一下 enter 就能发送。
👦🏻 Koji
可以展开讲讲这个功能吗？
👨🏻💻 Jett Chen
我们的开发流程是，先建立一套能从操作系统收集用户数据并形成有效记忆的系统。在这套系统之上，我们有一个框架，能实时生成并更新一个关于用户的 Markdown 文档。
这个文档包括用户的职业、过去几天的活动，甚至过去几秒、几分钟在做什么。离当前时间点越近，信息的颗粒度就越细。
所以，Paperboy Agent 始终拥有这个 context。有了这个基础后，我们就在寻找应用场景。第一个找到的好场景，就是在操作系统的任何地方实现自动补全。
比如，你在发微信时，可以在输入框里打 “@pb” 这个激活词，后面可以跟一个简短的指令，也可以什么都不输入。
👦🏻 Koji
不输入它也会猜你此刻找我是要干嘛？
👨🏻💻 Jett Chen
对，因为它有 context。
👦🏻 Koji
就像你和一个默契的同事，有时候你不需要说话，一个眼神他就懂了。指一下屏幕，“看这儿”。
👨🏻💻 Jett Chen
对，他一看就知道是哪个问题。Paperboy 当时就差不多达到了这个效果。所以无论你在做什么，它都能适时地提供 context。
对我来说，一个 “Aha Moment” 是在命令行或 GitHub 里。当我发一个 PR 时，它能直接帮我写好整个 PR 的描述。
我发现它写出来的描述，比 Cursor 或 Claude Code 写的要好。因为我开发一个功能时，可能一会儿在和...
Loading...