Linear AIG — Agent 时代的交互协议标准

核心判断：Linear AIG 是一个交互协议提案。它定义了”人类软件如何接纳 Agent 用户”的标准范式。任何现有 SaaS 都可以 follow 这套设计，把自己变成 Agent-friendly 的服务。

什么是 AIG

Agent Interaction Guidelines（Agent 交互指南），Linear 发布的一套原则 + 实践 + API 设计，定义了 Agent 如何作为”平台原生居民”参与人类工作流。

不是”给 Linear 加 AI 功能”，而是”重新定义软件应该如何对待 Agent 用户”。

六条核心原则

#	原则	本质
1	Agent 必须表明身份	Agent 不能伪装成人——有独立的视觉标记
2	Agent 应原生融入平台	不需要特殊界面，用和人类相同的操作
3	Agent 必须即时反馈	10 秒内回应，沉默 = 不确定性
4	Agent 必须透明内部状态	thinking / waiting / executing / finished 对用户可见
5	Agent 必须尊重停止请求	`stop` 信号 → 立即停止，不做任何额外操作
6	Agent 不可被问责	人类始终持有最终责任，Agent 是 delegate 不是 assignee

技术架构：从 API 到协议

Agent Session 生命周期

用户 @mention 或 delegate → 自动创建 AgentSession
  → pending → active → (awaitingInput) → complete
                    ↘ error
                    ↘ stale（30 分钟无活动）

关键设计：Session 状态由 Agent 发出的 Activity 自动推进，不需要手动管理状态机。

Agent Activity 类型系统

类型	方向	用途
`thought`	Agent → 人	展示思考过程（“正在分析…“）
`action`	Agent → 人	展示执行动作（修改状态、链接 PR）
`elicitation`	Agent → 人	向人类提问/请求选择
`response`	Agent → 人	最终回复
`error`	Agent → 人	错误信息
`prompt`	人 → Agent	人类输入（只有人类可以发）

Signal 系统

双向信号机制：

人 → Agent：

stop — 立即停止工作

Agent → 人：

auth — 需要用户完成账号关联（渲染临时 UI）
select — 展示选项列表让用户选择

Agent Plan（任务清单）

Agent 可以维护一个 session 级别的任务清单：

[
  { "content": "分析 issue 上下文", "status": "completed" },
  { "content": "编写修复代码", "status": "inProgress" },
  { "content": "创建 PR", "status": "pending" }
]

注意：每次更新必须替换整个数组（不能单独更新一项）。

关键 API 设计决策

delegate ≠ assignee — Agent 被分配 issue 时设为 delegate，人类保持 assignee。责任归属从协议层保证。
10 秒超时 — 收到 webhook 后 10 秒内必须回应 thought，否则标记为 unresponsive
Activity 不可变 — Agent Activity 是”时间冻结的快照”，不同于 Comment 可编辑。保证审计可靠性
promptContext 字段 — Webhook 自动携带 issue 详情、评论历史、团队指引，Agent 不需要自己抓上下文
Agent 不计费 — Agent 安装到 workspace 不算 billable user。降低采用门槛到零。

为什么这是一个协议而不只是一个功能

任何服务都能 follow 这套设计

Linear AIG 的真正价值不在于 Linear 自己用了它，而在于它定义了一套可通用的交互范式：

对外（让外部 Agent 接入自己）：

OAuth + actor=app 认证
Webhook → AgentSession → AgentActivity 的标准生命周期
Signal 系统处理 auth/stop/select 等跨平台交互
delegate/assignee 分离确保责任归属

对内（自己产品的 Agent 交互）：

6 条原则作为设计检查清单
Activity 类型系统（thought/action/elicitation/response/error）作为 UI 组件参考
Session 状态机作为后端设计参考
Plan API 作为任务进度透明化的参考

这套设计解决的核心问题

问题	传统做法	AIG 做法
Agent 和人混在一起	无区分	强制身份标记
Agent 在干嘛不知道	黑盒	Activity 流 + Plan 可见
Agent 做错了谁负责	不清楚	delegate ≠ assignee
Agent 怎么停下来	祈祷	`stop` signal 强制停止
Agent 需要人类输入	卡死	`elicitation` + `select` signal
Agent 需要认证	失败	`auth` signal + 临时 UI

对几个在分析产品的影响

对 Multica 的影响 — 🔴 致命

Linear 的 AIG 正是我们在 Case - Multica - Agent协作项目管理中预警的：“Linear 自己做 Agent 集成只需要几个月”。现在它来了，而且不只是”加一个 Agent assignee”——它是一个完整的 Agent 交互协议。

Multica 的核心功能（assign to agent、看 agent 进度、agent 发评论）被 Linear 用一个 Developer Preview 覆盖了 90%。而且 Linear 做得更优雅——delegate/assignee 分离、Activity 不可变、Signal 双向通信。

Multica 的窗口期不是 6-12 个月，是已经关闭了。

对 Clawith 的影响 — 🟡 中性

Clawith 的 Aware 系统（自主感知 + 自适应调度）是 Linear AIG 没有覆盖的层面。AIG 定义的是”Agent 如何在人类平台中行动”，Clawith 定义的是”Agent 如何自主决定何时行动”。两者是互补关系。

Clawith 甚至可以 follow AIG 来实现自己的 Agent 交互层。

协议标准化的更大含义

如果 Linear AIG 被广泛采纳（或被其他大厂参考），那么：

“Agent 友好”变成 SaaS 的 table stakes — 就像”移动端适配”在 2015 年一样，不做就是落后
协调层产品被挤压 — Multica 这类”让 Agent 和人协作”的独立产品，其功能会被各平台原生实现
Agent 基础设施层受益 — 身份（agentcard.sh）、支付、邮件（AgentMail）等底层基础设施需求反而增加，因为更多平台接入 Agent 意味着更多 Agent 需要身份/支付/通信能力

可推广的设计模式清单

任何想让自己的产品 Agent-friendly 的团队，可以从 AIG 中提取这些模式：

actor=app 认证 — OAuth 扩展，区分人类登录和 Agent 安装
delegate/assignee 分离 — 责任归属的协议级保证
Activity 类型系统 — 5 种语义化活动类型，覆盖 Agent 所有行为
Signal 双向通信 — 人可以 stop，Agent 可以请求 auth/select
10 秒超时 — 即时反馈的硬性约束
Activity 不可变 — 审计和可追溯的基础
promptContext 自动注入 — 减少 Agent 的上下文工程负担
Agent 零成本安装 — 不计费 = 零采用摩擦
Plan API — 多步骤任务的进度透明化
Ephemeral Activity — 临时状态显示（思考中…），不污染永久记录

Product Hunter

探索

2026-04-01 - Linear AIG - Agent时代的交互协议标准