核心判断

Agent 产品真正要争夺的，不是聊天入口，也不是更强的自动执行能力，而是谁来定义“任务”这个共同对象。

如果任务没有稳定的边界、状态、上下文和交接方式，Agent 越强，只会把工作流变得越难追踪；如果任务对象本身设计得足够好，Agent 反而可以自然地成为团队或个人工作的一种参与者。

背景与产品现象

Linear 最近几年值得看，不只是因为它是一个更快、更漂亮的 issue tracker。Linear 真正厉害的地方，是它一直在把软件团队的工作压缩成几个稳定对象：issue、project、cycle、triage、update。它不急着把所有协作形态都做成无限自由的白板，也不把管理需求摊平成一堆可配置字段，而是反复强调一件事：工作要能被快速写下来、被放进节奏里、被推进、被关闭。

这也是为什么它进入 Agent 时代时显得很自然。Linear 的产品页和案例里已经出现了这样的工作方式：工程师可以在 Linear 里把 issue 分配给 Codex 一类 coding agent；评论、状态变化、关联 PR 都留在 issue 里；项目更新也可以让 Agent 根据 issue、文档、讨论和 Slack 变化生成草稿，再由人修改发布。

这不是“给项目管理软件加一个 AI 按钮”那么简单。更关键的是，Linear 原本就把任务做成了一个适合人类和机器共同操作的对象：它有标题、描述、负责人、状态、评论、关系、代码链接、时间节奏和团队归属。Agent 只是进入了一个已经被产品设计整理过的场。

真正值得看的不是 AI，而是任务边界

大多数人看 Agent 产品，容易盯着模型能不能写代码、能不能跨应用、能不能自动跑完整个流程。这些能力当然重要，但它们不是产品体验的第一层。

第一层问题是：用户到底把什么东西交给 Agent？交出去以后，这个东西在哪里？谁能看见？什么时候算完成？失败以后怎么接回来？

如果这些问题没有对象承载，Agent 就只能躲在聊天里。用户发一段话，Agent 回一段话，中间发生了什么靠日志补救，最后产物散落在聊天记录、文件、PR、通知和用户脑子里。看起来很智能，实际很脆弱。

Linear 的启发在于，它没有先把 Agent 包装成一个神秘助手，而是把 Agent 放进 issue 这个朴素对象里。issue 不是聊天消息，也不是一段临时 prompt。它是一个可以被团队共享、被系统索引、被状态机推进、被未来重新进入的工作容器。

拆解

1. 这个产品相信什么用户行为

Linear 相信好团队不是靠更复杂的计划系统运转，而是靠高频、清晰、低摩擦的任务流运转。

这点从它的产品哲学里能看出来。Linear Method 里强调 scope projects down、generate momentum、write issues not user stories、launch and keep launching。这里的关键词不是“全面管理”，而是“推进”。它默认用户不是想维护一个完美的管理数据库，而是想持续把工作切成可执行的小块，然后让这些小块不断向前移动。

所以 Linear 非常重视速度和默认路径。快速创建 issue、键盘快捷键、GitHub 集成、cycle、triage，这些设计都在服务同一个判断：工作一旦需要被记录，记录动作就不能比做事本身更重；工作一旦进入系统，系统就应该推动它进入某种节奏，而不是把它丢进一个没有尽头的 backlog。

这对 Agent 产品尤其关键。Agent 最怕的不是不会执行，而是用户不知道该怎么把任务交给它。一个好的 Agent-native 产品，应该让“委托”像创建一张清楚的工作卡片一样自然，而不是像写一篇玄学 prompt 一样脆弱。

2. 它牺牲了什么

Linear 牺牲的是很多企业协作软件喜欢炫耀的“无限适配”。

它没有把自己做成一个每家公司都能随意改造成内部官僚流程的容器。它当然有配置能力，但整体产品气质是克制的：状态不要太多，路径不要太散，工作对象要清楚，界面要快，节奏要稳定。换句话说，它宁愿让一部分复杂组织觉得“不够贴合我们的流程”，也不愿让产品退化成一个字段和权限的仓库。

这是一种很重要的产品判断：当你服务的是高质量执行，而不是流程留痕，你就不能把所有例外都产品化。因为每增加一个“也可以这样”的选项，都会稀释默认路径的力量。

Agent 产品也会遇到同样诱惑。为了显得强大，很容易加上无限工具、无限模式、无限自动化开关。但真正有用的 Agent 工作流，往往需要更少的自由度：明确输入、明确边界、明确检查点、明确产物位置。自由度太高，用户反而不知道它现在在做什么，也不知道什么时候该介入。

3. 这个判断如何体现在具体体验里

Linear 的关键体验不是某个单点功能，而是它把“任务”做成了一个连续界面。

一个 issue 可以从客户反馈、团队讨论、bug 报告或产品想法进入系统；进入以后，它可以被 triage，被放进 cycle，被关联到 project，被连接到 GitHub PR，被评论，被更新状态，被关闭。这个过程里，用户不是在不同工具之间搬运一团模糊意图，而是在围绕同一个对象补充上下文。

这解释了为什么 Agent 能自然进入 Linear。Agent 被分配到 issue 时，它拿到的不是一句孤立命令，而是一个上下文容器；它的行动也不是在黑盒里消失，而是可以通过评论、状态、PR、更新重新回到容器里。人类接手时，不需要从聊天历史里考古，而是回到这个任务对象本身。

“Write with Agent” 生成项目更新也是同一个逻辑。它没有让 AI 凭空写一篇管理周报，而是让 Agent 读取自上次更新以来的 issue、文档、讨论和 Slack 变化，生成草稿，再由人修改。这里 AI 的位置很准确：它不是替代人的判断，而是把已经发生的工作变化整理成可发布的表达。

这比“AI 自动总结一切”更有产品分寸。因为总结不是目的，对齐才是目的；自动不是目的，可被人审阅和发布才是目的。

4. 对个人产品 / Agent 产品的启发

对 Dewey 关心的 personal software 和 agent-native 产品来说，Linear 的启发不是“也做一个 issue tracker”，而是：先设计可复用的工作对象，再设计 AI 能力。

个人软件里，很多 AI 功能失败，不是因为模型不够聪明，而是因为它没有稳定对象可以附着。今天总结一篇文章，明天生成一个计划，后天回答一个问题，每次都像一次性魔法。用户很难回来继续，也很难把结果纳入自己的长期系统。

如果是个人知识工具，核心对象可能不是 issue，而是 source、note、claim、task、draft、decision。如果是 agent-native 工作台，核心对象可能是 work item、run、artifact、review、memory patch。名字不重要，重要的是它们必须具备几个性质：人能读懂，Agent 能引用；状态能变化，历史能追踪；产物能带走，失败能接手；索引可以重建，源文件不被黑盒吞掉。

这也解释了为什么“聊天不是工作台”不是一句界面偏好，而是产品结构判断。聊天可以启动任务，但不能成为任务唯一的身体。真正长期可用的 AI 产品，需要把聊天里的意图沉淀成对象，把对象再连接到文件、引用、状态和下一步行动。

对个人 agent 来说，一个很小但重要的版本可能不是“让它自动完成更多事”，而是“让它把每件事变成一张可回看的工作单”：目标是什么、用了哪些来源、改了哪些文件、等待什么输入、下一步是什么、用户如何撤销或接手。这个版本验证的不是模型能力，而是用户是否愿意把真实工作托付给一个有边界的对象系统。

5. 哪些不能照抄

不能照抄 Linear 的团队协作假设。

Linear 面向的是软件团队，issue、cycle、project、triage 都天然适合多人协作和工程节奏。个人产品如果照搬这些词，很容易变成一种小型企业软件，把用户自己的生活和创作也管理成 Jira。

个人软件需要更轻的对象。它不一定叫 issue，可能叫“片段”“草稿”“判断”“待处理”“上下文包”。它不一定需要负责人、优先级、冲刺周期，但需要清楚地区分：什么是原始材料，什么是用户写下的判断，什么是 Agent 推断出来的结构，什么是下一步行动。

也不能照抄 Linear 的封闭工作区形态。对 local-first personal software 来说，用户信任来自可带走、可重建、可在应用外阅读的材料。Linear 可以把任务对象放在云端协作系统里；个人知识和 agent memory 产品则更应该让核心事实落在 Markdown、文件夹、可导出的任务记录或明确的本地数据库里。AI 可以生成索引和视图，但不该把用户的长期上下文锁进不可解释的应用状态。

最后，不能照抄“速度崇拜”。Linear 的速度服务于高质量团队的推进，而不是让一切都更快地滑过去。Agent 产品如果只学到“更快创建任务、更快自动执行”，却没有学到审阅、交接、状态和关闭，就会把用户带进更快的混乱。

结论

1. **Agent 产品的核心界面不是聊天框，而是任务对象。**聊天负责协商意图，任务对象负责承载上下文、状态、产物和交接。

2. **好的自动化必须先有好的边界。**没有边界的 Agent 看起来能力更大，实际更难信任；有边界的 Agent 才能被委托、被检查、被接手。

3. **个人软件不该照搬团队管理工具，但应该学习它们如何让工作可返回。**一个能被重新进入的对象，比一次漂亮的 AI 回复更有长期价值。

4. **下一代 agent-native 产品的竞争，不只是模型能力竞争，而是谁能定义最自然的工作容器。**谁定义了容器，谁就定义了用户如何开始、如何暂停、如何相信、如何回来。