Linear Agent 的巧思：让 AI 当同事，但不让它当负责人

如果把 AI coding agent 只做成一个更聪明的聊天框，产品很容易滑向两种糟糕结果：用户要反复搬运上下文，团队也看不清这个 agent 到底在替谁做事。Linear Agent 的新一轮更新有意思的地方，不是「AI 可以写代码」这件事本身，而是 Linear 把 agent 放进了原本用于协作的 issue、triage、diff review 流程里。Linear 在 2026 年 6 月 11 日的 changelog 中宣布，Linear Agent 已经可以通过 Claude Code 和 Codex 写代码，并在 Linear 内完成 triage、plan、review、ship 这条链路。1

Linear Agent 这期最值得拆的巧思有两个：第一，Linear 把 agent 设计成工作空间里的「可委派对象」，但责任仍挂在人身上；第二，Linear 没有把代码生成当成终点，而是把 review surface 拉回 issue 旁边，让人审查的是「变更 + 变更为什么发生」。

很多 AI 产品喜欢把 agent 塑造成一个独立助手：打开侧边栏，输入任务，等待结果。Linear 的做法更反常识一点。Linear for Agents 页面明确写着，agents 是 Linear workspace 的成员，可以被分配到 issue、加入 project，或在评论中被 @mention。2 这个设计把 agent 的入口从「聊天框」挪到了「任务关系」里。

这个入口变化很小，但责任关系完全不同。Linear 同一页又写明：当一个 issue 被委派给 agent 时，人类用户仍是 primary assignee，agent 只是 contributor。2 Linear 的 Agent Interaction Guidelines 也把原则说得更直白：agent 可以执行任务，但最终责任应始终留在人类身上。3

这就是第一个巧思：Linear 没有把「像人一样」理解成让 agent 冒充人，而是把 agent 放进人类已经熟悉的协作语法里。用户可以分配、@、查看状态、继续追问；但界面同时保留一条硬边界，谁负责交付，谁只是参与执行。

这个边界解决的是 AI 产品里一个很隐蔽的痛点：用户并不只是担心 AI 答错，用户更担心答错之后算谁的。尤其在产品团队里，一个 issue 通常会连接客户请求、内部讨论、代码变更和发布判断。agent 如果成为「负责人」，团队就会失去责任锚点；agent 如果只是一个临时聊天窗口，团队又很难追踪它做过什么。Linear 选择了第三种位置：agent 是工作流里的参与者，不是责任链的终点。

AIG 里还有两个配套原则：agent 应该清楚标明自己是 agent，并且应该透明展示自己是在思考、等待输入、执行还是完成。3 这些看起来像界面细节，实际是在降低协作成本。团队不需要猜「这是人改的还是 AI 改的」，也不需要在 Slack、GitHub、Linear 之间拼凑 agent 的状态。

Linear Agent 另一处设计选择，是把「完成代码」从一个孤立动作改成一个回路。Linear 对 coding sessions 的描述很具体：用户可以把 issue 委派给 agent，agent 读取 issue 和相关讨论、调查 codebase、提出方案、写代码并打开 pull request；整个过程在云端运行。4 更关键的是，这个 coding session 是共享给团队的，任何人都可以跟进、补充上下文、调整方向、要求修改或接手。4

普通 coding agent 的断点常出现在这里：它能在编辑器里产出代码，但团队真正需要判断的是「这段代码是不是解决了那个 issue」。如果上下文在 Linear，代码在 IDE，review 在 GitHub，客户反馈又在 Slack 或 Intercom，审查者会被迫做一次逆向拼图。Linear 的 6 月更新把这个拼图动作产品化了。

Linear Diffs 是这个回路里的关键部件。Linear 在 5 月 28 日发布 Diffs 时写到，用户可以从任何带 PR 的 issue 直接 review diff、继续让 agent 迭代，并从 Linear ship code；Linear 内的 review 会同步回 GitHub。5 Guided reviews 还会先展示变更的核心，再解释影响，并把 glue code 和次要改动拆出去。5

这不是把 GitHub review 复制进 Linear。Linear 真正想保留的是 issue 的上下文：原始请求是什么，讨论里谁补过约束，客户信号来自哪里，agent 为什么走到这个实现。Linear 在 coding sessions 的文章里明确说，review sits right beside the issue and the discussion that caused the change，也就是 review 就贴在引发变更的 issue 和讨论旁边。4

这个设计的代价也很清楚。Linear 必须变成更重的系统：它要接 GitHub code access，要处理 diff，要让 agent 读 issue、docs、Slack thread、codebase，还要把状态同步回外部工具。Linear 的 Code Intelligence changelog 说明，管理员需要安装 GitHub integration 并启用 code access，之后还要选择纳入哪些 repositories，以及访问权限是否受成员既有 GitHub 权限限制。6

代价换来的是一个更稳定的审查单位。用户不是在审一段凭空出现的代码，而是在审一个从 issue 生出来的变更。Linear 自己也给了一个内部使用信号：在 6 月 11 日的 changelog 中，Linear 称它内部用这个 workflow 解决约 30% 的 incoming bug reports，且多数是在 first pass 完成。1 这个数字不必被解读成通用承诺，但它说明 Linear 在产品设计上押注的不是「让个人更快写代码」，而是让团队更快判断 agent 交回来的东西能不能合并。

Linear Agent 容易被归到「AI 写代码」这一类产品里，但这个分类会漏掉它的设计重点。Linear 更像是在回答一个协作问题：当 AI 可以参与软件生产，产品系统应该怎样给它安排位置。

Linear 的答案很克制：让 agent 使用人类已经在用的对象和动作，但不要把责任交给 agent；让 agent 写代码，但把代码带回 issue 旁边审；让自动化从 triage 触发，但保留人类接手、重定向、要求修改的入口。这个设计不如「全自动工程师」听起来刺激，却更接近团队真的敢用 AI 的条件。

对做 AI 产品的人来说，可迁移的点也在这里。AI 能力越强，产品越需要把它放进一个可追踪、可解释、可接手的工作对象里。Linear Agent 的巧思，是没有把 agent 设计成一个更会说话的人，而是把它归位成一种有身份、有状态、有边界的协作对象。