@提及智能体

本指南介绍如何在空间中 @提及智能体和队友。

提及智能体

在输入框中输入 @，从自动补全中选择一个智能体，或者自己把名字打出来：

@alice fix the login bug

被提及的智能体如果还不是该空间的参与者，会被作为参与者加入该空间，并以该空间的上下文和模式派发。未被提及的参与者会看到这条消息，但不会被派发。

如果你发送的消息没有提及任何智能体，Control Center 会自己挑选一个响应者：先是该对话中最后发言的智能体，否则是对话的所有者（如果它有一个），再否则是空间参与者中的第一个顶层智能体。在只有一个智能体的空间里，那始终是这唯一的智能体。

一个提及 token 按精确名称或前缀匹配，且不区分大小写。因此 @arch 能匹配到名为 architect 的智能体，@Alice 能匹配到 alice。

有两个后果值得提前规划：

短 token 不是错误。 如果两个智能体共享一个前缀，先找到的那个胜出，而究竟是哪一个取决于排序——不取决于任何平局规则。名称有重叠时就使用完整名称。
只有字母、数字和下划线构成 token。 解析器匹配 @(\w+)，因此 @code-reviewer 会被读作 token code，@my agent 会被读作 my。名称中含连字符、点或空格的智能体无法被可靠地提及——包括通过自动补全，因为它会把名称作为纯文本插入。给智能体命名时用一个单词，或者用下划线。

提及会在文本到达智能体之前被剥离。因此，一条_只有_提及的消息（@alice）不会派发任何东西——给它点事做。

@alice refactor the auth module. @bob write tests for it.

两个智能体会并行派发到同一个对话中，并且都会收到完整消息。

它们还会共享那个空间的工作树。仓库工作树是按空间预配的，而不是按智能体；每个智能体都会得到自己的覆盖层工作目录，用于存放它的 AGENTS.md、技能和配置，共享的仓库以读写方式链接进来。因此，被一起提及的两个智能体可以看到彼此的改动——并与之发生冲突。

任何不匹配任何智能体的 @token 都会按用户名拿去与工作区的人类成员比对，遵循同样不区分大小写的精确匹配或前缀匹配规则。

匹配成功的人类提及不会派发任何东西。它只是搭载在消息的元数据上，好让通知路由器能提醒那个人。

智能体名称始终会被优先尝试，而一个已被某个智能体占用的 token 绝不会再提供给成员列表——一个 @word 永远只能解析到一个主体。

被派发的智能体会在提示词中看到一个“Summons”区块，其中写明是谁召唤了它，并列出空间名册——其他智能体（标注为顶层或下属）和人类成员——这样它就知道自己可以向谁交接工作。该区块还会告诉它：在回复中提及另一个智能体会唤醒那个智能体，而提及它自己则会被忽略。

智能体可以在自己的回复中交接工作。当一个回合干净地结束时，它文本中的提及会被解析，那些智能体会被加入该空间并被派发到同一个对话中，以那次提及的回合作为它们的提示词。失败或被中断的回合不会唤醒任何人——它在思考中途就停下了。

这些规则刻意比输入框的更严格，因为没有人会盯着去纠正一次错误的猜测：

只匹配精确名称。 不做前缀匹配。人类输入 @arch 能匹配到 architect；来自智能体时，它谁都匹配不到。一个能匹配到两个智能体的名称同样谁都匹配不到。
代码不是普通文本。 围栏代码块或 `backticks` 中的提及会被忽略，因此引用 @Override 注解或 pip install foo@1.2 是安全的。未闭合的围栏会让它之后的一切都失效。
紧贴前一个 token 的 @ 不是提及——sam@host.com、pkg/@scope 和 node@20 都解析不到任何人。
连字符会被保留，因此 @code-reviewer 会解析为它本身，而不是 token code。
每个回合最多三个智能体。 一个智能体在总结里列出六个队友，那是在罗列，而不是在召唤。

唤醒链的约束方式与委派相同：深度 3，而且已经在链上的智能体不能再被这条链唤醒（不允许 A → B → A）。一个有序对还会跨链受到速率限制。被拒绝的唤醒会向对话中发布一条系统消息，说明哪条提及没有被送达以及原因——无法解析的名称则不会，否则句子里的任何一个 @ 都会自说自话。

如果一次交接不能依赖普通文本——比如请求/回复，或者要触达空间之外的智能体——请改用 send_to_agent、ask_agent 和 delegate_task 这些工具。