memind/docs/architecture/intent-layer-v1-assessment-20260828.md

Intent Layer V1 与现网架构对照评估

日期: 2026-08-28

状态: 只读仓库核查完成；不作为当前开发主线。当前开发主线仍以 聊天 ↔ 任务执行意图层评估 的 Context Stability First（§11）为准。

适用范围:

• 外部提案「TKMind Intent Layer V1」（Intent Relation → Goal Compiler → Goal Lock → Planner → Evaluator）。
• 对照对象：main 上已落地的 Portal / goosed 主链路，以及同日的 chat-to-task 评估文档。

非目标:

• 不把 V1 全文再抄进仓库。
• 不在本文件中授权新建 goals/plans/tasks/observations/evaluations 表系。
• 不替代 Intent Transaction Layer（副作用 Draft→Confirm→Commit）。

---

0. 结论

V1 的核心原则成立：Goal ≠ Plan，Replan ≠ Re-goal，Goose 应逐渐变成 Executor 而不是唯一总控。

但 V1 不能作为当前第一刀。同日核查已经证明：H5 上可观测的「意图飘忽」主要由路由层 R1–R3 造成（direct→agent 上下文丢失、纯聊天会话 LLM router 吸收态、direct 安全网放行 + 谎报文案）。Task Resolver / 九态 FSM / Working Memory 权威化 修不了这三项。

更准确的定位：

问题域	谁负责	当前动作
普通聊天如何正确升级为 Agent，并带上历史	chat-task-intent-layer-review §11	阶段 A 观测 → B 上下文注入 → C 打开已有 LLM router
Agent 已进入复杂执行后，如何锁 Goal、验证完成、安全 Replan	V1 中后期能力	后置；仅在有数据证明「多步状态丢失」是主因后再试点

两套问题可以同时成立，不能互相否决。当前仓库尚未读取 goosed 内核，因此不能断言复杂 Tool Loop 内不存在重复规划；同样也不能在没有 R1–R3 基线数据时先上 Global Planner。

---

1. 必须先纠正的三个前提

1. 主 Portal 持久化是 MySQL（InnoDB），不是 PostgreSQL。 schema.sql + db.mjs。Postgres 仅用于旁路（pgvector、MindSpace 用户数据空间、Goose session、Orchestrator checkpoint）。V1 草案中的 UUID / JSONB DDL 不能直接套用；h5_plan_catalog 已被订阅套餐占用，不能再当 Agent Plan 表名。
2. Memind 每轮只向 goosed 提交 { request_id, user_message }（tkmind-proxy.mjs prepareSessionReplyBody）。完整历史与 Tool Loop 在 goosed 会话内。Goal Lock 若只锁 Portal 字段，对模型注意力是软约束。
3. 当前主路径上意图 LLM 往往是 0 次，不是「反复解释」。 规则兜底恒返回 direct_chat / 0.72；LLM router 入口要求 activeTaskContext.hasRecentAgentTask。纯聊天会话形成吸收态。MEMIND_CHAT_LLM_ROUTER_ENABLED=1 在生产打开，不等于聊天会话里真的会调用该 LLM。

---

2. 与现网能力对照（可复用 / 冲突 / 后置）

2.1 应复用，不要重建

V1 组件	现网对应
Conversation Gateway	POST /api/agent/runs → agent-run-gateway → tkmind-proxy
Intent Router（路径选择）	chat-intent-router.mjs（规则优先 + 可选 LLM + shadow + minConfidence）
Goal 存储	goal-run-service.mjs：h5_goal_runs / h5_goal_checkpoints
Goal 注入	goal-run-context.mjs buildGoalContextEnvelope
历史注入	agent-run-gateway.mjs buildFreshSessionContext / appendFreshSessionContext（16 条 / 12000 字符）
审计事件	h5_agent_run_events（已有 intent_routed 等）
SSE 生命周期	双通道 run + session；h5_session_stream_events replay；Portal id ≠ goosed Last-Event-ID
同 session 串行	SESSION_RUN_CONFLICT（direct session 豁免）
Capability → 实际工具	capabilities.mjs buildAgentExtensionPolicy；搜索域另有 mindsearch-config routes→adapter
副作用意图	ITL：h5_intent_drafts + Draft→Confirm→Commit

2.2 与既有决策冲突（当前不要做）

与 chat-task-intent-layer-review §2 / §6 及 H5 Session 架构 冲突：

• 每轮阻塞式 Intent Relation LLM（CONTINUE/REFINE/EXPAND/CORRECT/NEW_GOAL/CANCEL）
• 九态 Conversation FSM（含不可观测的 UNDERSTANDING / PLANNING）
• Working Memory / Goal Contract 取代完整会话历史作为权威源
• 新建第四/第五套任务存储（现已有 h5_agent_runs、h5_goal_*、h5_tasks、h5_scheduled_tasks、Orchestrator job）
• Router 升级为多步 Global Planner
• 把 goosed 改成无规划哑执行器（与「不改 goosed 协议」、worker affinity、proxy 已有 tool/finish/billing 职责冲突）

2.3 原则正确、时机后置

• Goal Version + goal_hash（审计列，挂在现有 h5_goal_runs，不新建表）
• Completion Criteria + 独立 Evaluator（仅用户显式长任务）
• Tool Raw 与 Observation Summary 分离（goosed 会话里 tool 结果目前全量保留）
• Capability Registry 从搜索域推广到全工具（加在 buildAgentExtensionPolicy 之上，不另起注册中心）
• Error Taxonomy、Prompt 版本记入 h5_agent_run_events
• 面向 UI 的语义 SSE（理解/规划/搜索），走现有 taxonomy，未知事件必须可忽略

---

3. 对 V1「15 个关键问题」的稳定答案

依据 2026-08-28 仓库只读核查（Portal 代码；不含 goosed 源码）。

1. 意图被 LLM 重新解释几次？ 规则 fast-path 下路由 LLM = 0。规则未命中且 LLM router 启用且非 shadow 时 = 1。Goal Run 绑定可能再 +1。下游再加 1 次 direct 回复或 goosed（含内部 Tool Loop，次数在 goosed 内，本仓库不可见）。
2. 谁能改执行方向？ chat-intent-router 的 route/skill/agent_brief；applyAgentOrchestrationToUserMessage；skill 长 prompt；injectTaskRoutingHint；vision 注入注脚；extension_overrides；会话压缩清空历史；goosed Tool Loop。
3. Goose 是否同时 Global + Local Planning？ 不完全。Portal 已拿走 route/skill/brief；Goose 在自持会话内做局部规划与工具循环。边界模糊，不是「Goose 什么都管」。
4. Tool Observation 是否污染 Context？ 是。全量留在 goosed conversation；Portal 只配对修复，不摘要。压缩阈值约 180 条 / 120k 字符后清空并注入 16 条摘要。
5. 有无 Active Goal？ 有 Goal Run 实体，但 h5_user_sessions 无 active_goal_id / conversation_state。Goal Run 默认单 checkpoint，且受开关门控。
6. 有无 Completion Criteria？ 无。近似物是 checkpoint 人工确认和交付启发式。
7. 有无独立 Evaluator？ 无。Page Data / workflow validation 为 shadow。
8. Intent Layer 插入点？ 已存在：agent-run-gateway executeRun 内 resolveRunRouting（约 chatIntentRouter.classify）。需要的是让聊天会话能走到已有 LLM 分支，而不是再插一层。
9. Goal 放哪一层？ Portal MySQL（现有 goal-run-service）。不要只放 Redis，不要放进 goosed。
10. Goal Lock 能否不改 goosed？ 能做 Portal 侧只读字段 + hash，但是软约束；压缩、harness 每轮重建、多层前缀仍会稀释 Goal。
11. Planner 边界？ Portal：route、skill、scope、goal envelope、run 生命周期。Goose：session、工具选择与顺序、task 内推理、局部 retry。不要让 Portal 重做 tool 卡片 / Finish / 计费变换。
12. Phase 1 最小改哪些文件？ 与 review §11 阶段 B/C 一致：chat-task-intent-config.mjs、chat-intent-router.mjs、agent-run-gateway.mjs、direct-chat-service.mjs（去谎报）。不要先做 Planner。
13. 可直接复用？ 见 §2.1。
14. 必须新增？ 若只做 B/C：不必新建表或新服务。 完整 V1 才需要 Plan/Observation/Evaluation 等，当前全部 not found。
15. 最大三个风险？ （1）再叠一套任务模型；（2）Goal Lock 对 goosed 自持历史无强制力；（3）每轮新 LLM + 流量从「direct 必注入记忆」转到「agent 默认不注入记忆」。

---

4. 下一步（开发顺序）

以 review §11 为准（与 §5 目标形态冲突时也以 §11 为准）。

1. 把工作区 B/C 草稿从脏 main 挪到基于最新 origin/main 的开发分支，只含意图层文件与对应测试；不要混入计费/认证。未批准前不 commit / 不 push / 不发 103。
2. 阶段 A 观测：0.72 兜底占比、direct→agent 升级频率、升级后失忆、shadow wouldChangeRoute。无基线则不扩大 C。
3. 阶段 B：direct→agent 接入 appendFreshSessionContext。Flag MEMIND_DIRECT_ESCALATION_CONTEXT_ENABLED 默认关 + canary。升级轮次 memory resolve 使用旧 sessionId。
4. 阶段 C：歧义闸门通过时规则返回 null，交给已部署 LLM router。先 SHADOW=1，再 canary。保留记忆召回 / FAQ / 寒暄硬规则。盯 Memory 注入率。
5. 阶段 D 及 V1 后置：仅当数据证明短句纠偏失败或「多步状态丢失」后再做。显式长任务复用 Goal Run，最多加 version/hash 列。

验收命令（B/C 落地后）：node --test chat-intent-router.test.mjs agent-run-gateway.test.mjs direct-chat-service.test.mjs chat-task-intent-config.test.mjs；npm run verify:h5-session-patches；可选 node scripts/verify-chat-task-intent-layer.mjs。

---

5. 与 chat-task 评估文档的关系

文档	角色
chat-task-intent-layer-review-20260828.md	现行开发规范：R1–R3、Context Stability、§11 落地路径
本文	对外部 V1 提案的对照结论，防止下一轮会话把 V1 当成未评估的新架构再设计一遍
intent-transaction-layer-design.md	副作用动作，与聊天↔Agent 路由并列
h5-session-architecture-20260706.md	Portal control plane / goosed execution；router 禁止多步 plan

V1 若在阶段 A/C 之后仍要推进，必须先满足 review §9：用观测证明主因是多步任务状态丢失，而不是 R1–R3 未修。届时优先复用 Goal Run，而不是新表系。