创建工单
在 CLI 中运行：source 设为 cli。--diagnostics 只添加二进制文件名、CLI 版本、操作系统和架构。运行 logbrew support --help 查看所有选项。
CLI 创建工单时不会发送重试键。如果结果不确定，先运行 logbrew support list --json，再决定是否重新运行命令。否则可能会创建第二个工单。
通过 API 创建时，发送 POST /api/support/tickets，并带上 source、category、title 和 description。为了能安全重试，为这份报告生成一次重试键，并放在 Idempotency-Key 请求头中发送。以下示例使用的是虚构的值：
Idempotency-Key 请求头是可选的。不带它时，重复的请求可能会再创建一个工单。
可选字段有 project_id、environment、runtime、framework、sdk_package、sdk_version、release、trace_id、event_id 和 diagnostics。如果情况与特定项目无关，省略 project_id。project_id 必须指向你账号中的一个活动项目。
请求成功时返回 HTTP
200：
sup_ 开头。next 是给人看的提示，next_action 用于程序控制。
要删除项目，使用项目设置或 logbrew projects delete。不要通过支持工单申请删除项目。
写一份有用的报告
- 每个工单只报告一件事。
- 选择最接近的
category。只有没有合适的类别时，才使用other。 title写明一个症状和它出现的位置。description先写步骤，再写预期结果和实际结果。- 只有项目、版本、链路或事件 ID 指向同一个故障时，才添加它们。
diagnostics 键：
diagnostics 是一个 JSON 对象，隐藏敏感信息后最大 16 KB。如果某个键名表示凭据、会话或邮箱地址，LogBrew 会把它的值替换为 [redacted]。看起来像凭据、URL 或本地路径的文本也会被替换。LogBrew 还会缩短过长的字符串，并限制嵌套层数、键的数量和列表项数量。不要依赖这种自动隐藏。发送请求之前，先删除私密数据。
跟踪工单
列表接受
project_id、status、source、category、release 和 limit。limit 默认为 100，最大为 500。使用游标分页时，发送 pagination=cursor。请求后续页面时，重复相同的筛选条件，并发送 next_cursor 中的 cursor_time 和 cursor_id。游标 ID 是一个 sup_ 工单 ID。next_cursor 为 null 时停止。CLI 对应的选项是 --project、--status、--source、--category、--release、--limit、--pagination、--cursor-time 和 --cursor-id。
状态值包括 open、routed、in_progress、waiting_on_user、resolved 和 closed。你只能设置 open 或 closed。重复的关闭或重新打开请求会成功返回，但不做任何更改，因此可以原样重试。根据返回的状态和 next_action 操作：
补充所需的上下文
工单要求提供上下文时再回复。这时工单的状态为waiting_on_user，next_action.code 为 provide_context。
context 和可选的 diagnostics。context 文本长度必须为 1 到 4000 个字符。不要在 context 中写入凭据、URL、主机名或本地路径。API 会以 422 拒绝这类文本。在 Idempotency-Key 请求头中发送重试键。上下文路由必须带这个请求头。键由 1 到 128 个可见 ASCII 字符组成，不含空格。每次回复使用新的键。只有重试同一条回复时才复用键。
工单状态为 open、routed、in_progress 或 waiting_on_user 时，API 接受上下文。每个工单状态只接受 1 条回复。回复后，等状态变化后再发送更多上下文。回复 waiting_on_user 状态的工单后，工单会变为 open。以返回的 status 为准，不要假定状态已经变化。
回复成功后返回 ticket_id、context_id、status、created_at、next 和 next_action。context_id 以 ctx_ 开头。回应后续请求之前，先重新读取工单。
GET /api/support/tickets/{ticket_id}/context 返回最近的 20 条上下文记录，按从旧到新排列。每条记录包含 context_id、context、diagnostics 和 created_at。这个列表没有游标。
回复 resolved 或 closed 状态的工单会返回 422 和 code: "validation_failed"。只有用户想继续这个支持请求时，才重新打开工单。next_action 并不授予智能体更改账号状态的权限。
从错误中恢复
错误响应包含
error、code、next 和 next_action。参见 API 错误。