Every 最新播客：AI 产品的下一层，是把上下文交给人和代理共同使用 (2026)

先说结论

本轮 Every 的新信号不在官网新增文章，而在「AI & I」第 105 集逐字稿于 7 月 18 日更新。节目发布于 7 月 15 日，Dan Shipper 与 Granola 联合创始人兼 CEO Chris Pedregal 讨论的重点，不是下一代会议纪要该多写几行，而是 AI 产品怎样把「工作上下文」交给人和代理共同使用。1

一句话概括：Every 正在把产品竞争从「模型能不能完成任务」推进到「人和代理能不能在同一个工作界面里协作」。这条线，和它近期反复出现的 Codex、Proof、Tend 以及 AI 原生工作循环，已经连成了一条更具体的产品判断。

访谈里最值得追踪的三层信号

1. 会议纪要只是入口，真正的资产是上下文

Pedregal 认为，会议纪要有用，但不是用户最终要买的全部价值。更大的问题是：在 AI 原生的工作方式里，人究竟通过什么界面工作，以及软件能否理解工作的上下文。Granola 因此希望把会议中积累的上下文开放给 Codex、个人代理或其它工具使用，并把 API 与 MCP 的改进列为接下来一段时间的重点。这里是产品负责人的方向判断，不是已经完成的功能清单。1

这对 Every 的意义在于：它追踪的已经不只是「哪个模型更强」，而是哪些产品能成为个人工作上下文的长期容器。一个工具如果只能生成一次答案，价值会被模型更新迅速稀释；如果它能保存、整理并调用用户的上下文，才可能成为其它代理愿意接入的工作基础设施。

2. 「代理使用产品」正在变成「人与代理共同使用同一界面」

Dan 在访谈中描述了自己的工作方式：他把许多软件放进 Codex 的应用内浏览器里，让自己和代理看到同一个界面，代理可以操作，人在关键处介入。访谈还提到 Every 的 Proof：Codex 可以进入文档，用户能看到它在文档中的位置和存在状态。这个细节比「给代理一个 MCP」更进一步，因为代理不再只是后台调用工具，而是和人一起面对同一个有状态的工作表面。1

这也解释了为什么 Every 同时在做内容、软件和工作方法：它要验证的不是一个孤立的 AI 功能，而是人如何在代理参与后重新组织自己的工作界面。当前官网把 Proof 描述为供人和 AI 代理共同使用的协作编辑器；这一定位与本次访谈里的产品判断是相互呼应的。2

3. AI 产品的价值，不能只看打开次数

Pedregal 用「扶手」来形容 Granola 想做的产品：平时几乎感觉不到，真正失足时却要在手边、足够可靠。由此引出的难题是，低频不等于低价值。有些功能可能很少被打开，但在一次关键会议前、一次艰难的管理沟通中，恰好承担了很重的作用；只看使用次数，会漏掉这类价值。访谈中他也承认，团队还没有一个足够好的指标来衡量这种「承重」能力。1

这是一条对 Every 自身很重要的提醒。AI 原生产品可以快速生成大量功能，也可以把大量 token 花在预生成和自动化上，但「生成了多少」和「用户因此少走了多少弯路」不是一回事。Every 后续若要证明自己的产品矩阵正在形成公司级工作系统，必须回答的不只是活跃度，还有代理是否在关键时刻接住了人、上下文是否真的被复用，以及产品被拿走后工作是否明显变差。

对 Every 追踪的判断

这期播客把 Every 的产品路线从方法论拉到了一个更容易验证的层面：

入口：用 Codex 这样的代理工作面承接日常任务，而不是让用户在多个 AI 应用之间来回搬运上下文。
协作面：让人和代理共享一个有状态的 UI；代理可以行动，人可以看见、修正并接管。
资产层：把会议、邮件、文档和个人判断沉淀成可调用的上下文，并通过 API 或 MCP 流向其它工作工具。
度量层：从频次指标扩展到关键时刻的可靠性与承重能力。

这四层里，前两层已经能在访谈中的 Codex 使用方式和 Proof 细节里看到；后两层仍是正在形成的产品命题，尤其是上下文如何跨产品流动、以及怎样证明低频高价值功能值得长期维护。不要把它们误读成 Every 已经公布的完整路线图。

接下来关注什么

Granola 是否会按访谈所说，把 API / MCP 做成一等入口，以及这会不会改变它与 Codex、个人代理的关系。
Every 的 Proof、Tend 或其它产品，是否继续把「人和代理同时在场」做成明确的交互，而不只是后台自动化。
Every 是否会公开更接近「承重能力」的产品指标：哪些功能在关键任务中真正减少了人的判断成本，而不只是被点击过。

对 Every 来说，下一阶段的竞争可能不是再做一个更聪明的助手，而是把上下文、界面和代理行为接成一个人愿意长期依赖的工作循环。

Every 最新播客：AI 产品的下一层，是把上下文交给人和代理共同使用