Grok Bot 的发布页很会抓人:一支常驻 Agent 团队,各自有电脑,会互相发消息,还能 24 小时干活。看到这里,我脑子里冒出的却是一个很扫兴的问题:东西呢?
八个 Bot 在群聊里分工、复述进度,看起来很忙。页面没做出来、文件找不到、外部动作没人敢确认,这支“团队”仍然只是八个聊天窗口。Grok Bot 值得看的地方,是它把多 Agent 协作接到了云电脑、应用和 Routine;也正因为接了出去,所有权和权限问题躲不过去了。
邓明瑞 / 纯粹
Grok Bot 的发布页很会抓人:一支常驻 Agent 团队,各自有电脑,会互相发消息,还能 24 小时干活。看到这里,我脑子里冒出的却是一个很扫兴的问题:东西呢?
八个 Bot 在群聊里分工、复述进度,看起来很忙。页面没做出来、文件找不到、外部动作没人敢确认,这支“团队”仍然只是八个聊天窗口。Grok Bot 值得看的地方,是它把多 Agent 协作接到了云电脑、应用和 Routine;也正因为接了出去,所有权和权限问题躲不过去了。
把一个任务拆给多个 Agent,吞吐量看起来会立刻提升。真正跑到共享仓库、文档或业务系统时,问题也随之出现:两个 Agent 同时改同一文件,研究 Agent 更新了结论,写作 Agent 还在引用旧证据,两个执行 Agent 重复提交同一工单。
多 Agent 首先是并发系统,其次才是角色设计。分工名称并不会自动提供隔离、一致性和幂等。共享状态必须有 owner、版本和合并语义,外部副作用必须回到单一的授权与提交边界。
多 Agent Demo 里,主 Agent 常给子 Agent 发一句“去查一下这个问题”,子 Agent 回一段文字,主 Agent 再综合。任务一复杂,就会出现范围重叠、工具权限过宽、结果无法验收、两个 worker 重复做同一副作用,最后也不知道谁还持有任务。
我把交接设计成协议,不是聊天。Orchestrator 创建 Handoff Manifest,worker 获取带期限的 lease,过程产物写共享 Artifact Store,返回结构化 Result Contract;Orchestrator 通过 Acceptance Gate 后才把子任务标完成。