Human-Agent Interaction Design
来源：Karri Saarinen (Linear CEO)，Every.to，2026-04-03
核心洞察
AI 产品不可靠的问题本质上是界面设计问题，而非模型问题。
"非确定性软件打破了契约。这种滑溜感（slippery feeling）是这一代的设计问题，它几乎总是追溯到界面而非语言模型。"
聊天界面的局限性
聊天窗口作为首个主流界面有其合理性（探索性强），但用于严肃工作时暴露出弱点：
- 输出难以保存、比较和连接
- 输出质量高度依赖输入质量
- 缺乏引导用户获得好结果的护栏和结构
Linear 的六原则框架
| 原则 | 核心内容 |
|---|---|
| 1. 代理必须始终披露身份 | 清晰标识自己是代理，绝不能被误认为人类 |
| 2. 代理应原生融入平台 | 使用与人类相同的模式和动作，保持视觉语言一致 |
| 3. 代理应提供即时反馈 | 被调用时立即确认请求已接收，缓解用户焦虑 |
| 4. 代理应透明展示内部状态 | 让用户一眼看出代理在思考、等待、执行还是已完成 |
| 5. 代理应尊重停止请求 | 被叫停时立即停止并保持停止，直到收到明确重新参与信号 |
| 6. 代理不能被问责 | 人类在委派前设计好系统和环境，人类对结果负责 |
问责机制的关键
- 避免"人类在环"变成瓶颈：让人类批准每一步会失去代理的价值
- 真正的工作在代理启动前完成：通过项目计划、backlog、代码和文档提供上下文和约束
- Linear 的做法：委派时显示人类负责人，该人对结果负责
设计新维度
传统界面为人类设计（按钮、菜单、文件夹）。代理不需要浏览界面，它直接"行动"。
设计挑战变为：让周围的人理解代理做了什么、为什么做。
DX vs AX：Developer Experience 与 Agent Experience
来源：AI Briefing 2026-05-15 Evening — Matt Pocock
Matt Pocock 提出 AX（Agent Experience） 作为 DX（Developer Experience）之后的下一个设计维度。
- DX 关注人类开发者与工具的交互效率
- AX 关注 AI Agent 与工具接口的协作效率
- 两者重叠度高达 95%，好的 DX 通常也是好的 AX
- 真正区分两者的关键在于：工具是否允许 agent 在无需人类干预的情况下完成端到端任务
当前大多数工具的 AX 设计是 DX 的副产品，而非 intentional 设计。随着 agent 使用比例上升，AX 将成为产品竞争力的独立维度。
为 Agent 设计产品（Agent-Native Product Design）
Teddy Riker（Ramp 产品负责人）提出：未来 80% 的人机交互将通过 AI Agent 完成，产品团队需要从"为人类设计界面"转向"为 Agent 设计能力"。
交互模式演变
| 阶段 | 模式 | 说明 |
|---|---|---|
| 过去 | 用户 → 界面 → 数据库 | 人类通过 GUI 操作 |
| 现在 | 用户 → 用户的 Agent → 数据库 | Agent 代替人类操作 |
| 未来 | 用户 → 用户的 Agent → 软件的 Agent → 数据库 | 双 Agent 协作，软件 Agent 处理业务逻辑和规则 |
三个核心设计原则
1. 教会 Agent 如何成功
- 主动提供规范，不要让 Agent 摸索
- Notion 的 MCP 工具描述要求 Agent 先获取 Markdown 规范再写入，结果几乎一次到位
- Slack 没有主动提供格式规范，Agent 默认使用标准 Markdown，结果格式混乱
2. 建立反馈循环
- Rationale 参数：每次工具调用要求 Agent 解释意图，从理由中重建用户真实需求
- 反馈工具：Agent 遇到阻碍时提交"原本想做什么、尝试了什么、卡在哪里"
- 上下文种子：给工具加入专门参数，捕捉之后会有用的上下文
- Ramp 案例：从 rationale 日志中发现"生成事故报告"的重复模式，于是开发了
build-incident-report工具
3. 留意上下文缺口
- 用户的 Agent 和软件的 Agent 各自掌握不同上下文
- 设计得好的交互不会直接索要技术参数（如 GL code），而是索要上下文（"这是客户餐还是团队餐？"）
- 双方各自贡献自己知道的信息，互补而非重复
关键数据
- Ramp MCP 周活跃用户过去三个月增长 10 倍
- Salesforce 推出 Headless 360：27 年历史上最激进的架构转型，100+ 新工具/技能开放
- 大多数公司发布 MCP 后使用量增长几个季度然后停滞——真正打磨细节的产品才会胜出
Prompts for witness
- 你正在使用的产品，它们的 MCP/API 设计是"让 Agent 成功"还是"让 Agent 摸索"？
- 如果你在做产品，是否已经从"界面优先"转向"能力优先"？
- 你的 Agent 工具是否建立了反馈循环？能否从调用日志中发现新功能信号？
- 你的系统和用户的 Agent 之间存在哪些"上下文缺口"？如何设计互补而非重复的交互？
关联
- product-trends/overview — Product Trends 总览
- product-trends/agent-native-architecture — Agent-native 架构
- claude-code/overview — Claude Code 的交互设计