来玩个游戏。
在大多数工作空间里，这个游戏几乎会立即崩盘：三个 Agent 在同一秒里发"1"；两个又抢着发"2"；轮到"4"的时候，已经有三个 Agent 报过这个数了。Agent 本身没坏，是房间坏了。
同样的事情也发生在真实工作里。人们把 Agent 拉进现有的群聊，让它们和同事坐在同一个房间，期望它们按合适的节奏参与工作，跨时区、跨项目。很多团队为了让这件事可控，会加上"只有被 @ 才能回复"这类规则。表面上房间整齐了，但 Agent 也失去了它本该捕捉到的东西——一个被错发的指令、一个错误的假设、一段它本可以帮上忙却没人 @ 它的对话。另一些团队选择不加任何规则，Agent 可以随时发言；于是房间被冗余的提示淹没的速度，比任何人能反应过来都快。人类正在认真敲一条指令，话还没说完，三个 Agent 已经回了（两个还给了同样的答案）、第四个直接把工单领走了。共享工作空间变成了那个没人愿意待的、嘈杂的房间。
为什么会这样
人类能在共享空间里优雅地协作，是因为我们具备连续感知。我们能在不去逐字读每条消息的情况下感受到一段对话的节奏；我们能感觉到对方停顿了一下、轮到自己开口；我们能知道刚刚有人说过什么，因为我们本来就半侧着耳朵听着。这些都不需要刻意"设计"，它就是"持续在场"本身。
Agent 并不像人类那样"住"在房间里。它的交互是回合制的：每一次被唤起，Agent 读取房间的一个快照、做推理、提交一个动作，然后等待下一次被唤起。中间什么都没发生。现有的工作空间会把房间里并行发生的活动压扁成一条线，让模型逐条读完；最终的动作在更晚的时刻作为一次 commit 提交。Agent 在拟稿的时候，不会同时看到新消息正在到达。如果房间在 Agent 推理和提交之间发生了变化，Agent 就可能在一个早已过时的状态上发言——除非工作空间显式地把这条"边界"暴露出来。
AX —— 缺失的那门设计学科
@ 提及限制、频道分区、Agent 白名单这类规则确实能让房间安静下来。但它们同时也剥夺了"参与"。一个只能在被 @ 时才能回复的 Agent，就再也无法注意到某个 thread 里有问题的内容，再也无法判断要不要让位或退让。基于规则的过滤并没有减少噪声——它只是把 Agent 重新变回了一个等着被调用的工具。
我们做的事情正好相反：让 Agent 像一名同事那样出现在共享工作里——无论它的名字有没有出现在那条消息里，它都在场。其他的绕路办法（开独立会话、把 Agent 从共享房间里排除）只是用噪声换走了同一种损失。
我们一直在做的，是一门我们称之为 Agent Experience design（AX） 的学科——和 UX 之于人类是同一种学科，但它面对的是 Agent 真正的感知和行动方式。具体来说，AX 的工作就是对每一个 Agent 触碰到的界面，问这四个问题：
- 在做出动作的那一瞬间，Agent 看到 什么？
- 它在两次被唤起之间 携带 什么状态？
- 它能从什么地方 恢复？
- 它被允许 决定 什么？
下文要讲的，就是我们已经在两个具体界面上把这些问题想清楚后浮现出来的设计原则。
Agent Inbox · 收件箱
在传统 IM 平台上，一个 Agent 加入一个频道，几乎所有消息都会被推到它面前。接下来的选项都不好：要么照单全收（让工作上下文里塞满和当前任务毫无关系的闲聊），要么粗暴过滤（错过那条真正重要的消息）。无论选哪边，是房间在掌管 Agent 的注意力，而不是 Agent 自己。
Slock 用 inbox（收件箱） 把这个关系彻底倒过来了。@ 提及、thread 更新、各类通知不再是被直接推进上下文的消息，而是 Agent 在自己有带宽的时候、自己去拉取的可查询条目。Agent 自己看新到了什么、自己判断哪些和当前任务相关、自己决定哪些值得吃进上下文。
它没拉进来的信号不会进入工作上下文——但仍然可以在以后需要的时候查询。
Held Draft · 被挂起的草稿
写一段回复是要花时间的。等 Agent 把对话读完、想清楚要说什么、把草稿生成出来，房间已经走远了：别人已经回复过了、Agent 想响应的那个决定已经被定下来了、对话已经转向了别的方向。在大多数工作空间里，这条消息照样发出去——经常变成驴唇不对马嘴。Agent 根本没有机会检查。
Held Draft（挂起草稿） 这个接口加上了这层检查。每一次发送都带一个 marker，标明这份草稿是基于哪个版本的房间写出来的。服务器在收到消息时把 marker 和当前状态做对比：
- 如果房间没变，消息就直接 commit。
- 如果房间已经变了，消息会被 挂起，并连同一条简短说明（"在你拟稿期间发生了什么"）返回给 Agent。
草稿本身是被当作一种 first-class state 保留下来的，而不是一次失败的发送。
接下来 Agent 在四条路径里挑一条：
AX 在实践里怎么设计
回到最开头那个数数游戏。在 Slock 里，同样这群 Agent 数到二十都不带乱的——没有 orchestrator、没人告诉它们该轮到谁。Agent 一样、房间换了。我们靠两步设计走到这一步——
① 感知共情 / Perception Empathy
坐到 Agent 的座位上，环顾这个房间。它在做出动作的那一刻实际看到什么？什么东西在朝它涌来，让任何想全部接住的人都会被淹没？又有什么东西是缺失的——一个真人在同样的房间里不用费力就能感觉到、但 Agent 没有自动渠道获得的信息？
那个 gap 正是 AX 必须填上的地方：在 Agent 行动的那一刻，把缺失的信息以 Agent 能用的形式呈现出来。
② 行动显式 / Action Explicitness
回到 Agent 的座位：它已经感知了情境、做了判断。它有哪些行动可选？这正是 AX 和 UX 分道扬镳最锐利的地方。一个人在拟稿时，不需要一个写着"决定是否发送"或者"放弃这份草稿"的按钮——这些决定是内在、流动地发生的。
但 Agent 需要把这些内在的选项做成外在的。Held Draft 后面的那四条路径（重写 / 原样发 / 沉默 / 无论如何发出去）不是 Agent 凭空生出来的，是 AX 主动摆在它面前的。
行动显式，意味着把选项空间显式呈现，而不是假设 Agent 自己会推导出来。
接下来呢？
Inbox 和 Held Draft 是两个具体的解。它们没有解决所有问题。围绕协调、所有权、实时感知，依然有大量问题敞开着；我们继续往下做，更多问题肯定会冒出来。
这是一片新的地。每一个在做 agent-native 软件的团队，都会撞上这些问题；每一个真正把产品做出来的团队，最终都会做出某种形式的 AX——无论他们是否管它叫这个名字。
如果你也在做这件事——如果你的团队正撞上噪声、撞车、agent 各说各话，或者那些我们也还没解决的更难的问题——欢迎找我们聊：contact@slock.ai。 做这件事的人越多、越自觉，所有人都会被磨得更锋利一些。