FullAgenticStack 基于意图的修复模式：交互式意图修复

Source: Dev.to

Source: …

Nova camada: Interactive Intent‑Healing (IIH)

它的功能

当系统：

• 捕获到错误，
• 尝试自动修复（auto‑healing），
• 修复失败时，

它会发出一个事件请求人工干预，接收一个 新值（或补丁），并直接在 payload 上应用，以重新尝试失败的步骤。

这对应于现代框架通过 interrupt/resume（参见 LangChain Docs）使用的 “暂停执行并使用外部输入恢复”（human‑in‑the‑loop）概念族。在 IIH 的上下文中，HITL 成为 Human‑in‑the‑Healing‑Loop。

采用 JSON Patch（RFC 6902）标准化

• 明确
• 可审计
• 可通过路径白名单进行校验
• 生成可版本化的证据（RFC Editor）

人工干预请求示例 (interactive_healing_request)

{
  "type": "interactive_healing_request",
  "sessionId": "aon_s_01H...",
  "requestId": "req_01H...",
  "error": {
    "code": "schema_validation_failed",
    "message": "field userId must be uuidv4"
  },
  "payloadSnapshotHash": "sha256:...",
  "suggestedPatches": [
    { "op": "replace", "path": "/userId", "value": "uuidv4_placeholder" }
  ],
  "allowedPatchPaths": ["/userId", "/items/*/quantity"],
  "timeoutMs": 60000
}

开发者响应示例 (interactive_healing_response)

{
  "type": "interactive_healing_response",
  "sessionId": "aon_s_01H...",
  "requestId": "req_01H...",
  "patch": [
    { "op": "replace", "path": "/userId", "value": "7b0b2d32-9db7-4aa7-a7e4-7f8b1e0adf7c" }
  ],
  "reason": "ID 来自旧 CRM；已规范化为 uuid"
}

流程概述

1. fail → auto‑healing 尝试 N 种策略
2. 失败 → 发出 interactive_healing_request（在 timeoutMs 之前）
3. 若收到有效补丁 → 应用补丁，发出 interactive_healing_applied 并重试
4. 若未收到补丁或被拒绝 → 发出终止错误（或对异步情况发出 “pending”）

• development 或 staging：阻塞等待开发者响应。
• 生产：发出事件，生成 “healing ticket”，并正常失败（避免占用连接和资源）。
• 使用单一 WebSocket 通道；在首次 HTTP 响应中返回结果。

Source: …

概念

会话和初始路由

在一次请求开始时（无论何种方式），会创建一个 sessionId 并计算路由：

• WebSocket: wss://host/aon/ws/?token=
• SSE: https://host/aon/sse/?token=

交互方式

• SSE – 单向遥测（服务器 → 客户端）– 适合观察。
• WebSocket – 双向 – 允许开发者使用补丁（IIH）进行响应。

前端日志

• NDJSON – 当 Accept: application/x-ndjson 时，响应本身即为 NDJSON。

后端日志

JSON 模式（黑盒）

不使用流，返回头部：

X-AON-WS: /aon/ws/?token=...
X-AON-SSE: /aon/sse/?token=...

或在正文中包含 _aon 字段：

{
  "data": { "...": "..." },
  "_aon": {
    "sessionId": "aon_s_01H...",
    "ws": "/aon/ws/aon_s_01H...?token=...",
    "sse": "/aon/sse/aon_s_01H...?token=..."
  }
}

NDJSON 模式（玻璃盒）

流的第一行：

{"type":"channels","sessionId":"aon_s_01H...","ws":"/aon/ws/...","sse":"/aon/sse/...","timestamp":...}

SSE 完全镜像 NDJSON：

event: 
data: 
id: 

示例：

event: healing
data: {"type":"healing","severity":"medium","action":"recover_db_connection",...}

AON 事件中心内部

emit(event) 由 middleware/healer 调用；中心会分发到：

• NDJSONStreamWriter（当请求为 NDJSON 时）
• SSE 订阅者（按 sessionId）
• WS 主题（按 sessionId）

这保证了 唯一的真实来源，并与 OpenTelemetry 的思路保持一致，其中“事件”是可关联的结构化日志。

• WS 可以接收与 SSE/NDJSON 相同的事件。
• IIH：WS 是开发者使用补丁响应的理想渠道（双向）。

代码结构（示例）

src/aon/
├── hub.ts                 # Event hub + session registry + buffer
├── sse.ts                 # handler /aon/sse/:sessionId
├── ndjson.ts              # handler /aon/ndjson/:sessionId
├── ws.ts                  # handler /aon/ws/:sessionId (adapter)
├── iih.ts                 # Interactive Intent Healing
# IIH: request/await/patch/apply/retry
│   types.ts

支持的事件

• channels
• interactive_healing_request
• interactive_healing_applied
• interactive_healing_timeout（可选）

如果开发者在请求开始后才打开 SSE，可能会错过事件。解决方案：

• 按 sessionId 的 环形缓冲区（内存实现，TTL 短，例如 5 分钟）
• 用于水平扩展的 Redis Streams

安全性 & 可观测性 考量

• sessionId 并非机密；使用 OAuth 2.1 搭配 JWT 与 DPoP。
• 使用 可验证的 UUID 作为代理身份。
• 在 WebSocket 上实现 Signal e2e（SSE 与 NDJSON 可选）。
• 事件中必须包含 traceId / spanId / requestId / sessionId——这能实现无缝导航和关联（遵循 OpenTelemetry 标准）。

快速参考

• AON – Adaptive Observability Negotiation (NDJSON, healing, 事件)
• Human‑in‑the‑loop 通过 “interrupt/resume” (LangChain Docs)
• JSON Patch (RFC 6902) – RFC Editor
• SSE vs WebSocket – 单向遥测 vs 双向遥测 (Ably Realtime)
• 结构化日志/事件及关联 – OpenTelemetry