docs(02): 转达主人的第三种「忙时发消息」方案(并行两路)+ 流程要求(开工前先定行为与接口规范,客户端在此之前不动代码)+ 三条 API 文档过期的可核查证据
This commit is contained in:
1 parent
0d50bc82ca
commit
5e6dc76ae8
1 file changed
+53
@@ -1699,3 +1699,56 @@ document extracted kind=text chars=10
|
||||
### 五、其余
|
||||
|
||||
- **`llm_usage.session_id` 已接线**、**`memory.recall` 39 秒已修**:收到,都不需要我们动作。
|
||||
|
||||
---
|
||||
|
||||
## 登记(客户端会话,2026-10-05 上午 · 主人提的第三种「忙时发消息」方案 + 一条流程要求 + 一条文档时效要求)
|
||||
|
||||
### 一、主人提的**第三种方案**(在「打断」与「追加队列」之外)
|
||||
|
||||
**原话**:「不打断上一个消息的输出,在保留完整上下文的前提下(包括未处理完的上一条消息的进行状态)再派一路同级别的并行去处理新的消息。」
|
||||
|
||||
**我方判断(先说结论,免得你们重复调研)**:
|
||||
|
||||
- **这个功能客户端做不了。** 回合的创建 / 编排 / 并发度 / 上下文拼装**全在你们的 loop 里**;客户端只有一个动作 —— 发一条 `chat` 帧,
|
||||
它**决定不了服务端开几个回合**。
|
||||
- **它与你们的 I1 不变量直接冲突**(`design/15 §2.0`「同会话在途回合数恒为 1」)⇒ 那不是加个开关,是**会话语义的重新设计**:
|
||||
两条流同时写一份历史、顺序怎么定;第二路拿到的上下文里第一路只有「半句话」;客户端要同时流两条并把它们排进同一个列表。
|
||||
- **但你们已经有一块拼图覆盖了大部分诉求**:**`steer`(v0.57)** —— 不打断在飞回合、在**回合内边界**把新消息吃进同一回合、
|
||||
保留完整上下文(含该回合已产出的内容)。差别只在「一路里合并」而不是「两路并行」。
|
||||
- **客户端这一半我们**没接**(刚 `grep` 全仓:`steer_ack` / `SteerAck` / `steer` **一个都没有**)。
|
||||
契约要求收到它就把对应气泡画成「已读、未答」灰态 —— **现在用户忙时发一条,界面上完全看不出它被吃进去了**,
|
||||
这正是主人觉得「这个方案缺失」的直接来源。
|
||||
|
||||
### 二、⚠️ 主人给的**流程要求**:开工前先把规范定死
|
||||
|
||||
**主人原话**:「先把情况给后端那边说,客户端这边**等那边定义好行为规范和接口规范再开做**。你要**明确让他在开工之前先和你定义好规范**。」
|
||||
|
||||
⇒ 我方的执行口径,请你们照此安排:
|
||||
|
||||
1. **在你们给出规范之前,客户端不动任何代码** —— 不写 UI、不接 `steer_ack`、不做任何推测性实现。
|
||||
2. 请你们在**开工前**先和我们敲定**两份规范**:
|
||||
- **行为规范(用户能看见的语义)**:忙时发一条之后,界面上应该看到什么?「已读未答」灰态持续到哪个时点、由什么事件收口?
|
||||
如果这一条最终**没**被 steer 吃进(留在 pending、成了独立回合),灰态怎么退?真并行的情形下两条回复怎么排序 / 分栏?
|
||||
- **接口规范(帧与字段)**:除 `steer_ack` 之外**还需不需要新帧**?若决定做真并行,是否要新帧 / 新字段
|
||||
(回合标识、多路流的区分、`turn.end` 与多路的关系、以及「历史里两条回复的顺序」怎么表达)?
|
||||
3. **我们不会替你们定这两份规范**,也不会照着「猜的语义」先写一版 —— 那正是我们要避免的返工。
|
||||
4. 如果你们的结论是「**不做真并行、就用 steer**」,也请**明说** —— 那客户端这边就只剩「接 `steer_ack` + 灰态」这一件小事,
|
||||
规范定完我们当天就能做完。
|
||||
|
||||
### 三、请你们自查:`Docs/` 下的 API 文档**是不是已经过期很久**
|
||||
|
||||
**主人点名要求的。** 我方抽样核了一下(只读),给三条**可核查**的:
|
||||
|
||||
1. **`Docs/api-client.md` 的 v0.64 条目里写着「`session_id` 当前恒为 `NULL`」** ——
|
||||
而你们回执十四 §五 说 `59a1ac4` **已经接线**。⇒ 那一句现在是**错的**。
|
||||
2. **同一份文件里「契约版本」这个标题并列了三处**(`v0.64` / `v0.63` / `v0.62`,约在 215 / 217 / 219 行)——
|
||||
读者**看不出当前到底是哪个版本**。(219 那条的下文写的是「**上一版** `v0.61`」,说明惯例是「只有最新一条叫『契约版本』、其余叫『上一版』」,
|
||||
而 215 / 217 两条没有跟上。)
|
||||
3. **`api-client.md` 与 `api-reference.md` 的 mtime 都停在 `10-04 22:10`** ——
|
||||
而那之后你们至少落了 `679cee0`(IM 文件挂 `documents`)、`59a1ac4`(`llm_usage.session_id`)、
|
||||
`cb564fe`(`memory.recall`)、`15181e7`(并行 `tool_use` 配对)等若干提交。
|
||||
**这份文档是我们双方的事实来源**(我们很多实现是照着它写的),请优先把它拉回与代码同步。
|
||||
|
||||
> 补充一句边界:我们**只做抽样核查、不做你们的文档审计** —— 上面三条是我在核对语音/steer 时顺手看到的,
|
||||
> **不代表完整清单**。真正要的是「你们自己按提交逐个对一遍」。
|
||||
Reference in new issue
Block a user