Linear：把 Agent 做成团队中的可委托成员
Our approach to building the Agent Interaction SDK
01 · 先读这里
为什么推荐
当 Agent 开始接手真实任务，最难的不是入口放在哪里，而是谁在做、做到哪一步、出了问题找谁。Linear 给出了完整的身份、会话和委托机制，还解释为什么旧集成与子工单模型不够用。适合复杂 B 端 Agent 的信息架构设计。
02
这篇讲什么
Linear 设计 Agent Interaction SDK 时，没有简单把智能体当作普通集成或真人同事。团队先让 Agent 拥有独立身份、权限和原生提及入口；再把分散的 webhook 与回复行为收束为 Agent Session，让工作中、等待输入、完成与出错成为可见状态；最后将任务的“负责人”与“执行代理”拆开，人继续承担结果责任。原文交代了旧方案为何不够用，也展示了命令菜单、会话和委托界面的真实截图。可迁移的不是某个控件，而是复杂 B 端 Agent 的身份、生命周期和责任模型。
扩展评分
一句话带走
把执行交给 Agent，不等于把责任也交给 Agent。
交互范式
交互到底改变了什么
- 原来的交互
- 旧集成只能经 OAuth/API 创建工单或评论，难以被分配任务、提及和追踪；通知 webhook 需要开发者自行拼接上下文。
- Agent 带来的变化
- Agent 成为原生应用用户；任务通过 Agent Session 承载；人类 assignee 与 agent delegate 分离。
- 用户的新成本
- 需要理解“负责人”和“委托 Agent”的差异，监督会话状态，并在产出后继续承担复核责任。
- 关键交互机制
- 独立 Agent 身份与权限；原生 @mention/菜单入口；Agent Session 状态；人类负责人+Agent 委托双角色。
- HCI 依据
- 作者描述旧 webhook 缺少统一回复模式，导致有的集成只回表情、有的发新评论、有的完全不响应；这是团队实践观察，非用户实验。
- 团队设计信号
- 团队先尝试复用现有 webhook 和子工单，再基于局限引入更小的 Agent 原语。
设计策略
从具体设计中学习
01
让 Agent 进入原生协作入口，但必须显式区分真人
- 看图重点
- 看 Agent 如何出现在已有命令菜单/成员入口，而非另开孤立聊天窗口。
- 图像作用
- 官方产品截图
- 问题
- 传统集成不是可提及、可分派的工作参与者。
- 方案
- 通过 actor=app 创建带独立权限和身份的 Agent 用户，融入菜单与 @mention。
- 为什么这样做
- 复用熟悉的协作入口，同时通过 Agent 身份标识避免把其误认成人。
- 取舍
- 根据方案推断：像成员一样出现，可能让用户高估 Agent 能力，需要标识和权限提示。
原文依据与解读
clearly marked as agents—not people
- 译文
- 明确标识为智能体，而不是人。
- 解读
- 这是身份建模，不只是给按钮加一个 AI 图标。
可迁移规则在协作平台中先定义 Agent 身份、权限、可被触发方式，再画入口。
02
把异步执行收束为可追踪的 Agent Session
- 看图重点
- 看任务上下文、会话消息及状态如何落在同一个业务对象中。
- 图像作用
- 官方产品截图
- 问题
- 旧 webhook 只有通知，没有统一上下文和回复模式。
- 方案
- Agent Session 封装触发来源、任务上下文与响应位置，跟踪工作中、等待输入、完成或出错。
- 为什么这样做
- 把异步动作变成可追踪的交互对象，减少开发者各自拼接 UI。
- 取舍
- 根据方案推断：统一会话结构可能约束极特殊的 Agent 工作流。
原文依据与解读
waiting for input, actively working, completed, or errored
- 译文
- 等待输入、执行中、完成或出错。
- 解读
- 状态是产品契约，不能只靠对话文案描述。
可迁移规则每个长任务至少具备会话 ID、状态、事件和可恢复入口。
03
将任务执行者与最终负责人拆成两个角色
- 看图重点
- 看工单 assignee 和 delegated agent 如何同时出现。
- 图像作用
- 官方产品截图
- 问题
- 把工单直接分给 Agent 后，出了偏差不清楚谁负责。
- 方案
- 保留人类 assignee，增加 agent delegate 表达受托执行。
- 为什么这样做
- 明确“做事”与“问责”是不同关系，适合需要审核的业务。
- 取舍
- 根据方案推断：双角色增加字段与认知负担，需要清晰文案。
原文依据与解读
the responsibility doesn’t transfer
- 译文
- 责任不会随任务委托转移。
- 解读
- 这是一条治理约束落到信息架构的典型案例。
可迁移规则高风险业务对象同时显示人类责任人和 AI 执行者。
推理链
从问题到设计判断
- 问题
- 旧集成无法自然参与任务协作，状态与责任不清。
- 证据
- 原文记述旧 webhook 反馈形式混乱；团队认为子工单的独立责任模型不适合委托。
- 判断
- 需要最少的原生 Agent 对象，并保留人类问责。
- 设计策略
- Agent 用户身份 + Agent Session + 人类 assignee / Agent delegate。
- 结果
- 原文展示了上线的协作 UI 与 SDK 机制；用户效率或可靠性量化结果原文未提供。
迁移原则
带回自己的项目
- 给 Agent 独立身份与权限，不复用真人头像/角色。
- 长任务必须拥有可定位的 Session 与状态，而非只在聊天中滚动。
- 在任务详情同时显示 human owner 与 agent delegate。
03
它真正解决的问题
如何让第三方 Agent 自然进入既有项目协作流程，同时保持身份可辨、状态可追踪、责任不混淆。
04
作者用了什么依据
团队在原文明确比较了旧 webhook 方案与 Agent Session，并说明曾考虑用子工单建模委托，但因子工单是独立负责人而放弃。
05
核心设计洞察
Agent 可以执行工作，但最终责任必须仍由可识别的人承担。
06
具体做了什么
让 Agent 以明确标识的原生身份出现；用 Agent Session 统一状态与回复；保留人类负责人并将 Agent 标为 delegate。
07
为什么这样做
Problem：旧集成难融入工作流且责任模糊 → Evidence：webhook 无统一反馈，子工单无法表达委托关系 → Judgment：需要原生身份、会话与责任拆分 → Strategy：app actor + Agent Session + delegation → Result：形成可见的身份/状态/责任 UI；量化结果原文未提供。
08
有什么关键取舍
原生入口与统一状态降低集成差异，但引入权限、会话和双角色认知；后者为根据方案推断。
09
最终有没有验证
原文未提供
从这篇学习
值得学什么
Agent 身份、执行状态与责任归属要分别建模。
在原有工单信息架构中显示委托关系，不把任务迁出独立聊天。
作者基于实际集成行为观察到反馈不一致会妨碍协作；没有定量研究。
先检验既有对象模型是否足以表达新关系，再增加最小新原语。
把 Agent 当成“有权限的参与者”，但不能当成“可问责的人”。
用“旧 webhook→Session”“子工单→Delegation”的被否决方案解释设计判断。
10 · 迁移
可以带走什么
工单、审批或运营任务中同时显示人类 owner、Agent delegate 和会话状态。
你的反馈
这篇对你有用吗？
反馈只会记录下来，不会自动改变推荐算法。