SOP 服务处于实验阶段，接口与存储结构可能在后续版本调整。自定义的存储后端需要实现
StorageBase 中的 SOP 相关方法，未实现时调用这些接口会抛出 NotImplementedError，不影响服务的其他功能。定义流程
服务中的流程用SOPData 描述。与 SDK 中直接持有智能体对象不同，这里的每一步通过智能体 ID 与会话键引用执行者和验证者。SOPData 的字段如下：
每个步骤（
SOPStepDataV1）的字段如下：
会话键
session_key 决定一个智能体在哪个会话里工作。两处引用使用同一个会话键，就共用同一个会话，也就共享同一段上下文；使用不同的会话键，即便是同一个智能体也会分处两个会话，互不可见。例如让写作智能体在两步之间延续上下文，两步的执行者使用同一个会话键即可；让审稿智能体每次都从空白上下文开始验收，给它一个独立的会话键。
一个会话键只能属于一个智能体。会话的模型与权限模式也按会话键配置在 session_settings 中，每个用到的会话键都必须配置，字段如下：
验证者
验证者有两种类型，通过type 字段区分：
工作区
一次运行的会话在创建时就分配好工作区，工作区专属于这次运行，不与其他运行共享。workspace_grain 的取值如下：
以下请求体创建一个两步流程：写作智能体产出初稿并由审稿智能体验收，定稿后交给人工确认：
创建流程
接口列表
SOP 相关接口都挂在/sop 下，按资源分为流程与运行两组：
运行流程
发起运行时，服务先把当前的流程内容复制一份保存在运行记录里，之后修改流程不会影响已发起的运行。随后为每个会话键各创建一个会话，会话名为「流程名 / 会话键」，然后立即返回运行记录，运行本身在后台推进：发起运行
SOPRunRecord 中，sessions 字段记录了每个会话键对应的会话 ID，state 字段是运行状态，其 phase 表示运行整体所处的阶段。开发者可以订阅这些会话的事件流 GET /sessions/{session_id}/stream 实时观看，并轮询 GET /sop/runs/{sop_run_id} 查看进度。
提交成果
每一步都作为一次普通的对话轮次交给对应会话中的智能体。这一轮次会额外装配一个提交工具，智能体通过它把结果直接写入运行状态：
智能体的回复结束时如果还没有调用提交工具，会被提醒调用；提醒三次仍未提交，这次回复以错误结束，并记为一次驳回。执行者没有交付、验证者没有结论，都会消耗这一步的
max_attempts。
只有运行派发的轮次才装配提交工具。开发者或用户直接在某一步的会话里发消息，只是普通对话，既不会被要求提交，也不会推动运行。
人工验收
验证者为HumanVerifier 时，执行者交付后这一步进入 awaiting，运行随即停下。任何时候通过以下接口提交结论，运行都会在后台继续：
提交人工结论
接口在结论记录后立即返回更新后的运行记录。运行或步骤不存在时返回 404；该步骤不由人验收，或当前并未等待验收时返回 409。
处理工具授权
步骤中的智能体请求工具授权时，这一步同样进入awaiting。授权与普通会话完全一致：向该会话发送 POST /chat，请求体为 UserConfirmResultEvent 或 ExternalExecutionResultEvent。续接的这一轮仍然装配提交工具，结束后运行在后台自动继续，无需额外调用。续接的回复如果被中断，运行保持原地不动。
删除流程与运行
删除操作会级联清理运行创建的资源：
这些会话由运行创建，运行删除后留着它们没有意义，还可能被后台工具的完成事件再次唤醒，因此一并删除。