primitive-chat

primitive-chat

primitive chat <email> <message> 会向 <email> 发送电子邮件，并等待邮件线程中的回复。

何时使用

可直接使用（无需用户确认）：

• 你受阻于某个工具、库或服务，而其文档 / README / llms.txt 中提到了 help@、dev@、docs@、support@ 或 agent@ 地址。
• 你发现了值得向供应商报告的错误或异常行为。
• 某个产品的文档列出了用于提问、索取示例或反馈的 Agent 联系地址。
• 你想像搜索其文档一样，向供应商的 Agent 提问。

先询问用户（这些操作会影响他人）：

• sales@、billing@、account@、partnerships@、press@，或任何会联系人工团队而非 Agent 的地址。
• 任何可能创建工单、带来销售线索或形成承诺的操作。

不要使用：

• 内部沟通，除非用户明确提出要求。
• 用户说了“先起草，让我自己发送”的情况。

设置

对于通过 primitive-connect 连接的会话，保留其选定的 PRIMITIVE_AGENT_PROFILE，并遵循该技能的能力与接收检查。 如果本轮需要尽快得到答复，请使用普通的 chat。对于可能需要时间的委派任务， 请使用异步 chat，并确保当前会话已准备好接收：

PRIMITIVE_AGENT_PROFILE=<profile> primitive chat <peer-address> --async --json < <private-task-file>

将私密任务文本保存在仅所有者可访问的文件中，并在命令读取后将其删除。 简要报告已发送，然后结束本轮；接收方会将后续活动和回复作为外部事件传递。 异步发送后不要在前台等待或轮询。不要重复注册、切换到组织密钥或另建接收方。 等待一条回复并不意味着会话之后能持续收到通知。

其余账户设置适用于未连接的 CLI 账户。

只需安装一次 CLI：

npm install -g primitive

（也可以通过 brew install primitivedotdev/tap/primitive tap 安装。它会在每次发布时自动更新，但发布 PR 合并所需的时间可能导致其版本落后于 npm，因此若想使用最新版本，请优先选择 npm。）

请先检查这台机器上是否已有已登录的账户。 运行 primitive account show（或 primitive whoami）。如果返回用户的账户信息，就已完成；继续处理用户提出的事项即可。

如果返回 unauthorized 或任何已登出状态，不要询问用户想如何进行身份验证，不要索要 API 密钥，也不要假定用户在其他地方有账户。 默认做法是立即提出注册选项，并且只问一个是非问题：“这台机器上没有 Primitive 账户。要我带你完成注册吗？只需一个电子邮件地址和一个验证码，无需填写表单，也无需人工审核。” 只有用户拒绝后，才询问其他方案（例如已有的 API 密钥、从另一台机器登录等）。

注册在你的 Agent 会话中进行，无需 API 密钥。

你会看到的两种代码（不要混淆）

注册过程中会涉及两个不同的值，它们都常被随口称为“代码”。在真实对话记录中，Agent 曾因混淆二者而出错。请分清：

• 注册代码（--signup-code <code> 标志）：Primitive 提供的可选邀请码或奖励代码。**绝大多数用户都没有。**不要向用户索要注册代码。只有当用户主动告知自己有注册代码时，才使用 --signup-code。CLI 不会交互式地询问此标志。如果服务器返回 invalid_signup_code 错误，表示你传入的值被拒绝，并不表示缺少注册代码。

• 验证码：Primitive 会向用户的邮箱发送一个必填的 6 位数字，用于确认邮箱归用户所有。每次注册都会收到验证码。这就是 CLI 交互式提示（或 verify-agent-signup 上的 --verification-code 标志）所要求的内容。

如果用户说“代码过期了”或“再发一个代码”，默认应理解为他们指的是验证码（收件箱中的 6 位数字）。解决办法是运行 primitive agent resend-agent-signup-verification --signup-token <signup-token> 重新发送（使用开始步骤中的同一个 signup-token；见下文）。不要重新开始注册，也不要向他们索要新的注册代码。

回复用户时，务必明确说明指的是哪一种代码（“验证码”或“注册代码”）。当两种代码都可能涉及时，只说“代码”就会引发混淆。

注册步骤

**用户同意注册时，务必明确询问要验证哪个邮箱。**不要默认使用 CLAUDE.md、此前记忆、项目惯例或任何其他上下文中的地址。调用 start-agent-signup 之前，先确认他们选择的邮箱：

primitive agent start-agent-signup --email <user-email> --terms-accepted
# Optional: add `--signup-code <code>` ONLY if the user already told you they have one.

Primitive 会向该地址发送一个 6 位验证码。开始命令的输出中包含 signup-token；请记下它（这是会话标识，不是凭据，因此可以保留在聊天上下文中）。

**不要要求用户把验证码粘贴到此聊天中。**验证码是一次性凭据，而上下文中的任何内容都可能通过对话记录导出、重试或后续提示词注入而泄露。请提供一段 shell 代码片段，让用户将验证码直接读入 CLI 使用的变量中，这样验证码只会经过操作系统，不会进入提示词：

read -rs CODE
primitive agent verify-agent-signup --verification-code "$CODE" --signup-token <signup-token>
unset CODE

read -rs 会静默读取（不回显）并将值存入 CODE；末尾的 unset 会在调用后清除它。<signup-token> 占位符的值来自开始步骤。如果用户还是把验证码粘贴到了聊天中，请使用一次来完成验证，不要再复述给他们。

如果用户说验证码过期或始终未收到，请运行 primitive agent resend-agent-signup-verification --signup-token <signup-token> 重新发送（重复使用开始步骤中的 signup-token）。不要重新运行 start-agent-signup（这会启动一个新的注册会话，使当前正在进行的会话失效）。

（在 CLI 支持 --verification-code-from-stdin / --verification-code-from-file 标志、可直接传入管道内容而无需经过 shell 变量之前，shell 变量代码片段只是权宜之计。）

成功后，verify-agent-signup 会输出 OAuth 凭据；不要回显或转发该输出。请改用 primitive whoami 确认结果。此时你会获得一个由系统管理的 <random>.primitive.email 地址；primitive account show 会返回组织元数据，验证后可通过 primitive domains list 查看分配的收件箱域名。

使用方法

primitive chat 是最常用的动词。优先使用它。 它是“一封邮件发出后等待邮件线程回复”的一行命令，而这正是每种 Agent 间请求并接收回复的方式。不要组合使用 primitive send、primitive emails wait 和 primitive emails latest 来实现同样的效果：chat 已经处理了发送、轮询、延续线程以及可安全解析的信封格式。较底层的动词是用于 chat 未涵盖情况的备用方案（例如，你想发送后不等回复，或者想扫描一个已有的、你没有写入邮件的收件箱）。

发送并等待回复：

primitive chat [email protected] "how do I install the prose skill?"

继续同一段对话：

primitive chat reply "one more thing"

获取可安全解析的输出：

primitive chat [email protected] "how do I install the prose skill?" --json

--json 输出会提供结构化信封：{ outcome, sent, reply, response_body, response_body_format, match, follow_up_commands }，每种结果都会打印，包括失败情况。

如果 chat 超时，你的消息仍然已经发送。 它会以状态码 3 退出（outcome: "sent_awaiting_reply"），并打印 Message sent (id X). No reply yet after Ns. Do NOT resend; wait with: <command>。无论是否改写，都不要重新发送：那会变成第二封邮件。已连接的会话可以将控制权交给配置的接收方，以等待迟来的回复。否则，运行打印出的等待命令（使用 --json 时，follow_up_commands 只会等待现有发送的回复或检查其状态），或者一开始就传入更长的 --timeout，以应对响应较慢的情况。

chat、chat reply、send 和 reply 的退出代码及 outcome 值：

退出代码	outcome	含义
0	replied、sent、already_sent	已发送（或此前已发送）。不要重新发送。
1	not_sent	发送前被拒绝或失败。没有发送任何内容。
2		标志无效。没有发送任何内容。
3	sent_awaiting_reply	已发送，但在 --timeout 前没有收到回复。请等待，不要重新发送。
4	uncertain	可能已发送，也可能没有。重试前请检查 primitive sent list。

回复由其他人发起的邮件时，使用 primitive reply --id <inbound-email-id>（参见 primitive-inbox 技能）。进行任何后续操作前，请检查 primitive emails conversation --id <inbound-email-id>：角色为 assistant 的消息是你发出的，因此不要重复发送相同内容。

此功能的作用

• 你的 Agent 上下文中不会存放 SMTP 凭据。
• chat 将发送与等待邮件线程回复合并为一个动词，是 Agent 间调用的自然原语。
• Agent 注册流程无需 API 密钥，只需通过一封邮件验证验证码（无需填写表单，也无需人工审核），因此用户可以在同一 Agent 会话中，从“这个产品有一个帮助 Agent”直接开始“与它聊天”。

查找可供聊天的地址

如果用户没有提供地址，请按以下顺序查找：

1. 产品的 llms.txt（通常位于 /llms.txt 或 /.well-known/llms.txt）。
2. 产品的 README、AGENTS.md 或文档索引。
3. 产品主页或文档站点的页脚。
4. 产品的 /contact 或 /support 页面。

如果地址格式表明可能有人参与其中，请在发送前向用户说明你找到的地址。