前几天 Linear 在开发者页面发布了 AIG（Agent Interaction Guidelines）。

原文在这里：Agent Interaction Guidelines

六条原则，看起来是写给自家产品用的设计规范。但它讨论的东西其实是通用的：当 Agent 正式进入团队协作流之后，人和机器之间的交互规则该怎么定。

---

为什么是 Linear 来提这件事

如果你用过 Linear，大概知道它的产品思路一直很明确：给工程团队用的项目管理工具，强调速度、清晰、少废话。

Linear 也是最早把 AI Agent 当成"团队成员"来做的一家。在 Linear 里面，Agent 可以像真人一样被指派 issue、更新状态、关联 PR、写评论。

这意味着在它的产品场景里，人和 Agent 是真正混在一起干活的。

这跟你在聊天框里问 AI 一个问题不一样。聊天是临时的、一对一的。但在 Linear 这种协作工具里面，Agent 的动作是可见的、持久的、会影响其他人的。

所以 Linear 遇到的那些问题，比如用户怎么知道这个 issue 是谁改的、Agent 能不能被信任、出了问题谁负责，这些不是理论推演，是实际踩过的坑。

AIG 就是从这些实际场景里长出来的。

---

六条原则

AIG 的内容其实很紧凑，六条，每条一句核心判断。

Agent 必须表明自己是 Agent

When humans and agents work side by side, humans need instant certainty about who they are interacting with.

人和 Agent 并行工作时，人类需要立刻知道自己在跟谁交互。

这条看起来简单，但实际场景里很容易被忽略。比如一个 issue 的评论区里面，Agent 和真人同时发言，如果界面没有明确标识，读者会下意识把它当成同事的回复。

Linear 的做法是在用户列表里给 Agent 打一个明显的 badge。不是小字标注，是头像级别的区分。

Agent 不能冒充人，这不是礼貌问题，是信任基础。

Agent 应原生融入平台

Agents should be able to work through existing UI patterns and standard actions of the platform they operate in.

Agent 应该能用平台已有的 UI 模式和标准操作来工作。

这条的意思是，不要给 Agent 单独做一套特权接口。Agent 修改 issue 状态、关联 GitHub PR、写评论，这些操作应该和真人用户的操作走同一条路径。

为什么要这样做？因为如果 Agent 走的是后门，团队就看不到它的完整行为轨迹。而协作工具的核心价值恰恰是所有动作可追溯。

所以 Linear 让 Agent 用和人类一样的 action 来操作。你在 activity feed 里看到的 Agent 动作，和真人动作格式完全一样。

Agent 应提供即时反馈

Silence leads to uncertainty.

沉默导致不确定性。Agent 被调用时，应该立刻给出反馈。

这条特别实际。你在评论里 @了一个 Agent 让它排查 bug，如果它什么反应都没有，你会不确定：收到了吗？在处理吗？还是挂了？

Linear 的方案是一个 "Thinking" 状态指示器。Agent 收到请求的瞬间就亮起来，告诉你它在处理了。

这和人类协作的场景是一样的。你给同事发消息，对方回个"收到，在看"，你心里就踏实了。Agent 也需要这个"收到"。

Agent 应对内部状态保持透明

Humans should be able to understand what's happening at a glance and, when needed, inspect the underlying reasoning, tool calls, prompts, and decision logic.

人类应该能一眼看到 Agent 在干什么，需要时还能展开看底层的推理、工具调用和决策逻辑。

这条我觉得是六条里最有深度的一条。

Linear 为此做了一个 "Agent Session" 界面，把 Agent 的每一步思考过程都展示出来：它读了什么、调了什么工具、做了什么判断、最终怎么得出结论的。

这解决的是一个很根本的信任问题。如果 Agent 只给你一个结果，你只能选择信或不信。但如果你能看到过程，你就能自己判断这个结果可不可靠。

透明不是目的，可审计才是。

Agent 应尊重退出请求

When asked to disengage, an agent should step back, immediately.

收到退出指令时，Agent 应该立刻停止介入。

这条解决的是 Agent 过度活跃的问题。有时候 Agent 在持续处理某个任务，但你想让它停下来，也许是你发现了方向不对，也许是你想自己接手。

Agent 应该理解这是一个停止信号，不要继续追问"你确定吗"，也不要自作主张地总结一下当前进度再走。

退出这个权利，在 Agent 交互里也是最基本的。

Agent 不能被追究责任

There should be a clear delegation model between humans and agents. An agent can carry out tasks, but the final responsibility should always remain with a human.

Agent 可以执行任务，但最终责任始终在人。

Linear 在产品里做了一个很清晰的委派模型：你把一个 issue 分配给 Agent，界面上会同时标注谁来负责，而且始终是一个真人。

这条我觉得不只是产品设计，更像是一个组织原则。Agent 可以干活，但拍板、担责、对结果负责的，必须是人。

如果 Agent 写了一段有 bug 的代码上线了，这不是 Agent 的责任，是批准它上线的人的责任。

---

这六条背后的问题

读完这六条，我觉得 Linear 其实是在回答一个更底层的问题：当 Agent 从"工具"变成"协作者"，交互设计需要怎么变？

以前的 AI 产品设计，核心是"怎么让 AI 更好用"。重点在输入端：prompt 怎么写、上下文怎么给、模型怎么选。

但 AIG 指向的是另一个维度：输出端和协作端。当 AI 的输出不再是单次回答，而是持续的、可见的、影响他人的动作时，你需要回答这些问题：

• 别人怎么知道这是 Agent 做的
• Agent 的动作是否遵循团队已有的规则
• 出了问题谁负责
• Agent 能不能被叫停
• Agent 的决策过程能不能被检查

这些问题，在一个人用 AI 写邮件的场景里不重要。但在一个 Agent 能改代码、关 issue、触发部署的场景里面，就变得很关键。

---

文档本身也值得说一下

Linear 把这份文档放在了 /developers/aig 这个路径下，标题写的是 "Agent Interaction Guidelines"。

没有叫 "Linear Agent Design Spec" 之类的内部文档名。措辞上是在提一个行业议题，不只是在写自家产品的设计备忘。

文档最后写了一句：

This page is a living document and we expect to continually add to it as we learn more in practice.

这份文档会持续更新，随着实践不断迭代。这件事目前还没有最终答案。

但方向是清楚的：Agent 交互设计，正在从"让 AI 更聪明"转向"让人和 AI 的协作更可控"。

如果你在做 Agent 相关的产品，或者你的团队正在引入 Agent 参与日常工作，AIG 值得花十分钟读一遍。不是因为这六条多高深，而是因为它提了一个正确的框架：先把人和 Agent 的边界画清楚，再谈能力。