晚上 10 点，纽约的产品经理在 Linear 上建了一个竞品分析的 ticket，在群里 @ 了东京的工程师，又发了一封邮件给伦敦的设计师。三个渠道，三种状态，没有一个地方能看到全貌。
第二天早上，产品经理问：「进度怎么样了？」东京说：「刚看到群消息，还没开始。」伦敦说：「邮件？我昨天没在线。」Linear 上的 ticket 状态还是 To Do——因为没人记得去更新它。
这个场景每天都在全球化团队里上演。我们用了二十年时间解决「人怎么跨时区协作」——异步文档、录屏、standup 录音、follow-the-sun 排班。但本质上，所有方案都在做同一件事： 让不在场的人也能跟上进度。
如果有一种同事，它没有时区、不需要睡觉、7×24 在线、能在你下班后继续推进工作呢？
这种同事已经存在了。它叫 Agent。但我们的协同办公产品——通讯录、IM、邮件——还没有为它做好准备。
Agent 不是「虚拟人」，是新物种的一等公民
大多数产品对 Agent 的处理方式是：给它一个 bot 账号，拉进群里，能收消息能回消息。
你在群里 @ 一个 bot 说「帮我约张三下周的时间开个评审会」。bot 回了句「抱歉，我不理解你的意思」。因为它没有日历权限、不知道张三是谁、不知道「下周」在你的时区是哪几天、不知道「评审会」需要拉哪些人。它有的只是一个消息收发接口——一个 二等公民伪装成一等。
真正的一等公民意味着： 系统为 Agent 重新设计了交互原语，而不是让 Agent 适配人类的交互原语。
这不是语义上的区别。它决定了三件事要不要重新设计：
- 通讯录：Agent 怎么被找到、怎么被路由
- 通信：Agent 和人之间用什么通道、什么频率、什么格式
- 时区：Agent 怎么桥接不同时区的人
这三个重设计，构成了下一代协同办公产品的骨架。
重设计一：通讯录——从「人的目录」到「能力的目录」
传统通讯录回答的问题是： 谁是谁、谁管谁。
Person {
name: "张三"
title: "财务总监"
department: "财务部"
email: "zhangsan@acme.com"
reports_to: "李四"
}
# generated by hugo AI
这是组织架构图的数字化。你搜一个名字，看到他的职位、部门、上级。然后你靠经验推断：「财务总监大概能审批采购」「HR 大概能回答社保问题」。
Agent 时代，「靠经验推断」不成立了。 因为 Agent 没有 title——你不能从一个名字推断它能做什么。而且路由的需求变了：你不是在「找人」，你是在「找能力」。
一个 Agent 在群里收到任务：「帮我审批这笔 48 万的采购。」它需要的不是「财务总监的手机号」，而是：
- 谁有权限审批 50 万以下的采购？
- 这个人（或 Agent）现在可用吗？
- 审批需要哪些前置条件（预算确认、供应商资质）？
下一代通讯录的数据模型应该是这样的：
Entity {
id: "entity://sales-agent-001"
type: human | agent | squad
identity: { name, avatar, org_id }
capabilities: [ # 能做什么
{ domain: "sales",
actions: ["send_quote", "update_crm", "follow_up"],
scope: { max_amount: 100000, regions: ["east-china"] } }
]
availability: { # 什么时候可用
timezone: "Asia/Shanghai", # 人是 Asia/Shanghai
working_hours: "09:00-18:00", # Agent 是 24/7
response_sla: "4h" # Agent 是 "30s"
}
relationships: {
reports_to: "entity://vp-sales",
delegates_to: ["entity://report-agent"], # 委托关系
collaborates_with: ["entity://finance-agent"]
}
}
# generated by hugo AI
三个关键变化：
第一，人和 Agent 共享同一个 Entity 模型。 不是两套系统，是一套系统里的两种实体。这让路由变得统一——「这件事谁能做」不需要先判断找人还是找 Agent。
第二，Capability 是第一级字段。 传统通讯录里「这个人能做什么」是隐含在 title 里的。Agent 时代这必须显式化——因为 Agent 的路由不能靠推断，必须靠查询。
第三，委托关系（delegates_to）成为一等关系。 张三把周报委托给周报 Agent，把客户跟进委托给销售 Agent。这个委托关系决定了 Agent 以谁的身份、在什么范围内行动。
路由方式的对比：
| 传统路由 | 能力路由 | |
|---|---|---|
| 触发 | 「这件事应该找谁？」 | 「这件事需要 approval:purchase, max_amount:50000」 |
| 过程 | 人凭经验判断 → 找错人 → 转交 | 系统查询 Capability → 返回匹配实体 |
| 结果 | 浪费两天 | 秒级路由，返回 3 个候选（2 人 + 1 Agent），按 availability 排序 |
| 容错 | 找错人靠人情转交 | 第一候选无响应 → 自动升级到第二候选 |
我在 数字分身和数字员工的分界线 中讨论过：数字分身和数字员工的区别不是能力，是服务关系。通讯录里的委托关系，正是这种服务关系的结构化表达。
重设计二：通信——IM 是工作场所，邮件是 Agent 的外交渠道
「邮件和 IM 哪个更重要？」这个问题本身就问错了。它们服务不同的时间尺度和信任层级：
| IM | 邮件 | |
|---|---|---|
| 时间尺度 | 秒到分钟 | 小时到天 |
| 交互模式 | 同步、多轮、即时 | 异步、单轮、可延迟 |
| 信任层级 | 内部协作 | 跨组织正式通信 |
| 可追溯性 | 弱（消息流淹没） | 强（每封邮件是独立文档） |
对 Agent 来说，IM 是工作场所，邮件是外交渠道。
IM：不只是消息通道，是上下文流
IM 对 Agent 的真正价值不是「收发消息」，而是 上下文。
群里的每一条消息、每一个决策、每一次确认，都是 Agent 的上下文来源。产品经理在群里说「这个方案不行，客户要的是 SSO 不是 OAuth」——这句话对 Agent 来说不是噪音，是 需求变更信号。它应该被结构化、被记录、被关联到对应的任务上。
邮件做不到这一点——邮件是快照，IM 是流。Agent 需要流。
这就是为什么群不是「聊天群」，而是「项目空间」。Agent 在群里不是被动等 @，而是主动监听上下文变化、推进工作、在关键节点请求确认。长程任务用卡片原地进化——一张卡片承载一个任务的完整生命周期，更新而非追加。
邮件：Agent 的外交工具
邮件在 Agent 时代不会消失——它会变成 Agent 替人处理正式通信的渠道。
三个场景是 IM 做不了的：
- 跨组织通信：你和供应商之间没有共同的 IM 群，但有邮件
- 正式审批记录：「这封邮件确认了 50 万的采购」比「群里说了句 OK」有法律效力
- 长链追溯：一个项目从立项到交付，邮件链是天然的审计轨迹
Agent 时代的邮件体验是什么样的？
周一早上，你打开 IM，Agent 说：「周末收到 12 封外部邮件。3 封需要你回复——供应商报价确认、客户投诉、合作伙伴会议邀请。其余 9 封已按规则处理。供应商报价那封，我起草了回复，你确认后我发出。」
你看了 30 秒，点了确认。整个过程你没打开邮件客户端。
邮件不再是人的工作负担，而是 Agent 的外交工具。 人只在需要判断和决策的节点介入。
结构化通信：Agent-to-Agent 的机器协议
还有一层通信对人类是不可见的——Agent 之间的协作。
Agent A 需要 Agent B 的数据，不应该在群里发消息（太吵），也不应该发邮件（太慢）。它走结构化的任务协议——请求、响应、超时、重试，全部机器处理。
为什么这层必须存在？因为如果 Agent 之间的协作也走 IM，一个 10 个 Agent 的项目群一天会产生上万条消息，人类会被淹没。结构化协议让 Agent 之间的通信对人类 不可见但可审计——你需要的时候可以查，不需要的时候不打扰。
这三层通信——IM（人+Agent 日常）、邮件（跨组织外交）、结构化协议（机器到机器）——构成了完整的通信架构。不是「IM 替代邮件」或「邮件替代 IM」，而是 每一层服务不同的信任层级和时间尺度。
重设计三：时区——Agent 是天然的时区桥接器
回到开头的场景。纽约、东京、伦敦，三个时区，三种工作节奏。
传统解法是「异步化」——写文档、录视频、留 comment，让不在场的人自己看。这解决了「信息传递」的问题，但没解决「工作推进」的问题。你看了文档，然后呢？谁来执行？谁来跟进？谁来决定下一步？
Agent 解决的不是信息传递，而是工作推进。
纽约 18:00 产品经理把需求委托给 Agent
↓
纽约 18:01 Agent 开始执行：拉数据、做分析、写初稿
↓
东京 09:00 东京工程师上班，Agent 推送：
「初稿已完成，有 2 个技术问题需要你确认」
↓
东京 09:15 工程师确认，Agent 继续执行
↓
伦敦 09:00 伦敦设计师上班，Agent 推送：
「设计需求已整理好，需要你出 3 张图」
↓
伦敦 17:00 设计师交付，Agent 整合
↓
纽约 09:00 产品经理上班，看到完整交付物
从需求到交付：15 小时（传统方式：3 天）
Agent 不需要「等别人上班」。它在纽约的夜里工作，在东京的早上交接，在伦敦的下午收拢。 它把三个时区的 8 小时工作日，串成了一个 24 小时的连续工作流。
这对通讯录的设计也有影响——availability 字段不只是「工作时间」，还包括「这个人的 Agent 代理在什么时区活跃」。你找张三，张三在睡觉，但张三的 Agent 在线。你找 Agent，Agent 秒回。
不是更好的 IM，是组织的操作系统
把三个重设计放在一起看：
| 重设计 | 从 | 到 |
|---|---|---|
| 通讯录 | 人的目录（谁是谁） | 能力的目录（谁能做什么） |
| 通信 | IM 和邮件二选一 | 三层通信各服务不同信任层级 |
| 时区 | 异步文档等人看 | Agent 24 小时推进工作 |
这三个重设计指向同一个结论：
下一代协同办公产品的核心不是「更好的 IM」或「更好的邮件」，而是一个让人和 Agent 在同一个组织里协作的运行时。
「运行时」是什么？它管理生命周期（Agent 什么时候上线、什么时候下线）、分配资源（这个任务给谁做）、处理异常（Agent 卡住了怎么办）。翻译成协同语言： 运行时就是组织的操作系统——人和 Agent 都是进程，通讯录是进程表，通信协议是 IPC，权限是访问控制。
IM、邮件、审批、日历——这些都是这个操作系统的 交互界面，不是产品本身。产品本身是：
- 统一的 Entity 模型（人 + Agent + Squad）
- 显式的 Capability 和 Permission
- 委托关系和路由协议
- 跨时区的异步协作能力
在 Agent 进入企业，还差一个工位 中，我讨论了 Agent 需要的五层工位基础设施。那篇是从「Agent 怎么在企业里落地」的角度切入。本文是从「协同产品怎么为 Agent 重新设计」的角度切入。两者互补：工位是 Agent 的硬件，通讯录和通信协议是 Agent 的软件。
谁先把这个操作系统做出来，谁就定义了下一代协同办公。
不是做一个更好的 Slack，不是做一个更好的 Gmail。而是让组织里的每一个实体——人和 Agent——都能在同一个系统里被找到、被路由、被委托、被审计。
你的组织，准备好让 Agent 成为一等公民了吗？
下一篇：Agent 时代的权限：从 RBAC 到五层信任架构——当 Agent 一秒调 100 次 API，传统权限模型为什么不够用。
你觉得下一代协同办公最迫切需要重设计的是什么？欢迎留言讨论。