fix: scope proposals to chat users
This commit is contained in:
zenord
@@ -169,7 +169,7 @@ QQ websocket 示例：
|
||||
}
|
||||
```
|
||||
|
||||
正式 Bot 应通过 `gateway.policy.allowedUsers` / `allowedChats` 限制入口。QQ 群 chat ID 为 `group:<group_openid>`。
|
||||
正式 Bot 应通过 `gateway.policy.allowedUsers` / `allowedChats` 限制入口。QQ 群 chat ID 为 `group:<group_openid>`；用户 ID 按 QQ 官方语义取值：群聊作者用 `member_openid`，C2C 私聊作者用 `user_openid`。
|
||||
|
||||
### ACP 生命周期
|
||||
|
||||
@@ -188,8 +188,8 @@ QQ websocket 示例：
|
||||
|
||||
运行链路是三层：
|
||||
|
||||
- **Assistant**：每个 chat 一个无工具 ACP 会话，只与用户对话。它把用户意图整理成 Proposal（title、goal、steps），并解释 Worker 的反馈。Assistant 每条回复必须以隐藏 `GORI_ASSISTANT_ACTION_V1` envelope 结尾（`reply` + `actions`），action 只有 `create_proposal`、`confirm`、`start_next`、`cancel`、`stop`；格式错误只修复一次。
|
||||
- **Proposal**：一份待确认的工作单。状态流为 `proposed → queued → working → awaiting_user_confirmation → completed | failed | cancelled`。`proposed` 只有用户确认后才进入 `queued`；空闲时最早确认的 queued Proposal 才开始执行。
|
||||
- **Assistant**：每个 conversation（chat + user）一个无工具 ACP 会话，只与用户对话；同群不同用户的会话互相隔离。它把用户意图整理成 Proposal（title、goal、steps），并解释 Worker 的反馈。Assistant 每条回复必须以隐藏 `GORI_ASSISTANT_ACTION_V1` envelope 结尾（`reply` + `actions`），action 只有 `create_proposal`、`confirm`、`start_next`、`cancel`、`stop`；格式错误只修复一次。
|
||||
- **Proposal**：一份待确认的工作单，owner 是 chat + 发起用户；只有发起人本人可以 confirm/stop/cancel/list 它，`start_next` 也只启动发起人自己的 queued Proposal。状态流为 `proposed → queued → working → awaiting_user_confirmation → completed | failed | cancelled`。`proposed` 只有用户确认后才进入 `queued`；空闲时最早确认的 queued Proposal 才开始执行。
|
||||
- **Worker**：同一时刻全实例只有一个，在 `bot.workspace` 用 `bot.permissions` policy 执行一个已确认 Proposal。每轮必须以隐藏 `GORI_WORKER_RESULT_V1` envelope 收尾：`SUCCESS`、`FAILED` 或 `NEEDS_CONFIRMATION`（可带 `question`、`nextStep`、`dirty`）。
|
||||
|
||||
确认语义是刻意的：
|
||||
@@ -197,17 +197,18 @@ QQ websocket 示例：
|
||||
- `SUCCESS` 和 `FAILED` 都进入 `awaiting_user_confirmation`，都需要用户确认后才分别落定为 `completed` / `failed`；对 failed Proposal 用 answer `retry` 确认可以重试。
|
||||
- 系统**不会**在一个 Proposal 完成后自动开始下一个；只有用户确认新 Proposal 或 Assistant 发出 `start_next` 才会推进队列。
|
||||
- Worker 执行中遇到 dirty 或意外目标时报告 `NEEDS_CONFIRMATION`，这是正常的执行中确认点，不是 blocked 终态；用户回答后同一 Worker 继续执行。
|
||||
- `stop` 对 `awaiting_user_confirmation` 的 Proposal 有兜底语义：pending success 落定为 `completed`，pending failure 落定为 `failed`，pending step 落定为 `cancelled`（并清理 worker 状态）；不会自动开始下一个 Proposal。
|
||||
- Gateway 不再有 15/60/180/480 秒的固定时间提醒；Worker 落定结果时通过 Assistant 生成一条事件说明，由平台 adapter 作为**新消息**发给 owner chat（QQ 同样是新消息，不引用原消息）。
|
||||
|
||||
Assistant 隔离与旧 side Session 一致且更严格：
|
||||
|
||||
- cwd 位于实例私有 `state/assistant-workspaces/`，目录名由进程随机 salt 和 chat key 计算 HMAC，不直接编码 chat 标识，并且不能与项目 workspace 重叠；重启后按 binding 恢复同一目录。
|
||||
- cwd 位于实例私有 `state/assistant-workspaces/`，目录名由进程随机 salt 和 conversation key（chat + user）计算 HMAC，不直接编码 chat 标识，并且不能与项目 workspace 重叠；重启后按 binding 恢复同一目录。
|
||||
- 项目级 `agent.md` override 显式设置 `tools: []` 与 `subagents: []`；ACP 传入空 `mcpServers`；Assistant 只接受 Kimi Code ACP，并强制 permission deny 作为附加层。
|
||||
- 除非 `bot.agent.env` 已显式设置，Assistant 进程的 `KIMI_CODE_HOME` 指向实例私有 `state/kimi/assistant/`（`0700`），与真实用户配置隔离。
|
||||
- 一旦出现 tool update 或 permission request，即视为隔离违约：当前 turn fail closed、终止整个 ACP 进程组并删除 binding。Worker 的 cancel、timeout、crash 同样按进程组清理工具后代；bootstrap 禁止 `setsid`、`nohup`、detached/daemon/background 遗留进程，主动脱离进程组仍属于无 Bubblewrap/cgroup 方案的信任边界。
|
||||
- 每个 ACP worker 以独立进程组运行并携带随机 `GORI_AGENT_WORKER_TOKEN`；runner 重启时会把仍处于 `working` 的 Proposal 校验 token 后清理旧进程组，并标记为 failed（`worker_lost`），交给用户确认或重试。
|
||||
|
||||
state v3（`acp-sessions.json`）只保存 header（version 3、`botId`、platform）和 Assistant binding：chat key、agent ID、native session ID、assistant workspace、Bot fingerprint 与时间戳。`proposals.json`（version 1）保存 Proposal 记录：title/goal/steps、owner chat、状态、pending（`step | success | failure`）、worker native session ID 与进程组 PGID/token、时间戳；不保存消息正文。两个 store 都做单 writer lock、串行持久化、临时文件 + fsync + 原子 rename；version 或 identity 不匹配（含旧 state v1/v2）一律拒绝启动并保留原文件，不清空、不迁移。
|
||||
state v3（`acp-sessions.json`）只保存 header（version 3、`botId`、platform）和 Assistant binding：conversation key（chat + user）、agent ID、native session ID、assistant workspace、Bot fingerprint 与时间戳。`proposals.json`（version 1）保存 Proposal 记录：title/goal/steps、owner chat、发起用户、状态、pending（`step | success | failure`）、worker native session ID 与进程组 PGID/token、时间戳；不保存消息正文。两个 store 都做单 writer lock、串行持久化、临时文件 + fsync + 原子 rename；version 或 identity 不匹配（含旧 state v1/v2）一律拒绝启动并保留原文件，不清空、不迁移。
|
||||
|
||||
Bot fingerprint 包含 bootstrap schema version、Bot ID、workspace、persona、agent 定义、permission policy 和 skill 路径/内容 hash；fingerprint 或 agent 不匹配的 binding 会被丢弃并重建 Assistant 会话。失败 prompt 不会自动重放，因为工具操作可能已有副作用。
|
||||
|
||||
@@ -227,15 +228,15 @@ Bot fingerprint 包含 bootstrap schema version、Bot ID、workspace、persona
|
||||
```
|
||||
|
||||
- `/help`：显示自然语言使用说明和兜底命令列表。
|
||||
- `/status`：显示固定 Bot、agent、workspace、Assistant 会话数、各状态 Proposal 计数、Worker 是否在执行及当前 chat 是否 owner。
|
||||
- `/list`：列出当前 chat 拥有的 Proposal（id、状态、title）。
|
||||
- `/confirm`：确认当前 chat 最近待确认的 Proposal（`proposed` 进入队列，`awaiting_user_confirmation` 落定完成/失败或带着回答继续）。
|
||||
- `/stop`：停止当前正在执行的 Worker 并将其 Proposal 标记为 cancelled；只有 owner chat 可用。
|
||||
- `/cancel`：取消当前 chat 最近未开始的 Proposal（`proposed` / `queued`）。
|
||||
- `/status`：显示固定 Bot、agent、workspace、Assistant 会话数、各状态 Proposal 计数、Worker 是否在执行及当前用户是否 owner。
|
||||
- `/list`：列出当前 chat 中当前用户拥有的 Proposal（id、状态、title）。
|
||||
- `/confirm`：确认当前用户最近待确认的 Proposal（`proposed` 进入队列，`awaiting_user_confirmation` 落定完成/失败或带着回答继续）。
|
||||
- `/stop`：停止当前用户正在执行的 Worker 并将其 Proposal 标记为 cancelled；对等待确认的 Proposal 按 pending 类型兜底落定（success→completed、failure→failed、step→cancelled）；只有 Proposal 发起人可用。
|
||||
- `/cancel`：取消当前用户最近未开始的 Proposal（`proposed` / `queued`）。
|
||||
|
||||
日常操作以自然语言为主，Assistant 会自己生成 confirm/cancel/stop 等 action；这些命令是旁路 Assistant 的兜底入口。未识别的 `/` 命令按普通消息交给 Assistant。
|
||||
|
||||
Gateway 不维护普通消息队列或 per-chat task lock，也不再有固定时间（15/60/180/480 秒）的处理中提醒；每条 allowlist 普通消息按 chat 串行交给 AssistantManager。Worker 落定结果（成功、失败或提问）时，AssistantManager 生成事件文案并经 `Gateway.sendEvent` 由平台 adapter 作为**新消息**发出（QQ 也是新消息，不引用原消息）；发送失败只记录不含消息正文或 provider 错误详情的安全日志，不影响任务或后续发送。
|
||||
Gateway 不维护普通消息队列或 per-chat task lock，也不再有固定时间（15/60/180/480 秒）的处理中提醒；每条 allowlist 普通消息按 conversation（chat + user）串行交给 AssistantManager。Worker 落定结果（成功、失败或提问）时，AssistantManager 生成事件文案并经 `Gateway.sendEvent` 由平台 adapter 作为**新消息**发出（QQ 也是新消息，不引用原消息）；发送失败只记录不含消息正文或 provider 错误详情的安全日志，不影响任务或后续发送。
|
||||
|
||||
每条异步入站使用独立、串行的回复流，`replySequence` 从 1 动态递增；同步 webhook 直接返回 JSON 结果。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user