sundynix/sundynix-agentix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
276 Commits 5 Branches 0 Tags
dev
Commit Graph

82 Commits

Author SHA1 Message Date
Blizzard 7ae7f7be67 feat(memory): 记忆召回加 Relevance —— Generative Agents 打分补齐第三项 (P1) 
审计三真桩之一。记忆召回此前打分只有 Recency+Importance,缺 Relevance(对当前
任务的语义相关性)——注释写"待接 Milvus",但召回时甚至不知道当前问什么。

关键发现:dispatcher 注入点 fetchMemory(ctx,uid,_) 手上已有当前任务文本(b.query),
只是被 `_` 丢弃了。所以不是"接 Milvus"那么重,把 query 一路传下去 + 缓存嵌入即可。

设计(偏离注释的"接 Milvus"——用户偏好量小,不值当上向量库):
- Profile 加 embedding 列(float32 小端打包存 bytea);Upsert 时对 value 向量化缓存
  (value 没变不重算,失败留空不阻断)。
- memory 包定义 Embedder 小接口,gateway 注入 rag.Engine(复用同一控制面下发的
  embedding 模型),不硬依赖 rag 内部;rag.Engine 加导出 Embed 方法。
- memory_get 工具加可选 query 入参;fetchMemory 停止丢弃 b.query 传下去。
- Get(ctx,uid,query):query 非空且 embedder 就绪 → embed(query) 对每条缓存向量
  内存算余弦 → 三项打分 0.25R+0.35I+0.4Rel;否则回落两项(升级前行为)。
- 优雅降级贯穿:无 query/无 embedder/query 嵌入失败/行无向量 → 静默回落,绝不报错。
  零 Milvus 依赖、零向量库同步问题、保住"没 embedding 也能跑"。

验证:单测(编解码往返/cosine 截0/三项模式相关性翻转顺序/降级返 nil)+ 端到端
(真 PG:写入即向量化、query=咖啡把低重要度的咖啡记忆翻到运动前面)。migration
加列已 live;embedding 复用 RAG 已验证基建。三模块 build/vet/test 全绿。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-18 12:47:55 +08:00
Blizzard 940330cdb7 feat(eval): 评测结果回写升 JetStream 持久 —— 消灭最后一处 core NATS 回写 (P1) 
完成度审计 P1 + 记忆 nats-durability 的既定规矩「计费/需落库的回写一律
JetStream+幂等,别fire-and-forget」。此前 eval 是全仓最后一处 core NATS pub-sub
回写:网关离线/慢消费者时评测结果直接丢——而质量趋势/门控都依赖它。

照抄已升级的 status/usage 范式(同为 dispatcher→gateway→PG 回写):
- contract 加 StreamEval/ConsumerEval;bus 加 EnsureEvalStream + ConsumeEval
  (durable consumer,AckExplicit,落库失败 Nak 重投自愈),PublishEval 改
  js.Publish 同步等 ack。删 core NATS 的 SubscribeEval。
- gateway/dispatcher 两个 wrapper 在 connect 时 EnsureEvalStream;gateway main
  的评测订阅从 SubscribeEval(fire-and-forget)换 ConsumeEval(handler 返 error→
  Nak),接入优雅停机 drain。
- 幂等前提已满足:SaveEval 按 task_id upsert,at-least-once 重投只覆盖不重复。

验证:e2e 去重测试(TestGatewayQueueDedup)升级到 ConsumeEval,50 条两副本合计
处理50次零重复;live 真端到端:提交任务→跑完→评测经新 eval 流落 PG(level=ok)
一次成功;两服务启动 eval 流 ensure 无报错。go build/vet/test 全绿。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-18 11:52:40 +08:00
Blizzard c2811e79a3 fix(desktop,dispatcher): 从编排执行的多 agent 图看不到「团队」tab 
现象：编排里并排三个 agent(研究/撰写/审查)跑完，运行页没有团队 tab。

两处卡住，不是一处：
1) isMultiAgent 只认 coordinator: 节点。用户自己在图里并排多个 agent 也是
   团队，却被整个漏掉。改成：有协调者，或 ≥2 个 agent: 节点。
2) 就算放宽 1，deriveTeam 仍按 kind==="agent" 挑工位——而两条产生 agent 的
   路径 kind 并不一致：协调者派发的专家是 kind=agent，图里的 agent 节点是
   kind=model。改成按节点名前缀(agent:/tool:)判，这本来就是后端一直遵守的
   约定；顺带天然把 retriever:/map:/render: 这些同为 kind=tool 的节点挡在
   工位之外(之前它们会混进来当工位)。

连带修一个更要命的：runAgent 把轨迹标签写死成"模型流式推理"、runReactAgent
写死成"ReAct 智能体（自主调工具）"，用户在编排里给节点起的名字(研究 Agent /
撰写 Agent / 审查 Agent)整个丢了。后果不止办公室：执行轨迹里三行同名，根本
分不出谁是谁；团队视图只能退回节点 ID，工位显示成 r/w/rev。
改成一律 labelOf(n, 兜底) 由调用方传入，+2 单测钉住。

另：没有协调者时不再凭空画一个"协调者"小人(白板改挂「任务产出」)，也不演
递简报那一程(没人可递)，✓ 气泡改为收工即冒。

注意：已存的历史轨迹是落库的，仍是旧标签；只有新跑的任务才有节点名。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-15 17:41:21 +08:00
Blizzard 2d5b72930a fix(dispatcher): 中文专家名导致多智能体协调 400 挂死 
buildSpecialists 把专家名原样当 OpenAI function-calling 的 tools[].function.name，
而该字段受约束 ^[a-zA-Z0-9_-]+$。中文命名专家（中文产品里最自然的用法，如"条款专家"）
会让模型直接 400：
  Invalid 'tools[0].function.name': string does not match pattern
整个协调节点挂掉，再沿 failover 链把备用模型也拖垮。

修：toolFuncName() 规范化给模型看的函数名——非法字符→下划线，清空→expert_N，
同批内撞名加序号保证唯一；展示名与执行轨迹(agent:<原名>)仍用原名不变。
模型靠 Desc(spec.Use) 判断何时调用，函数名不承载语义，故退化命名不影响派发质量。

实测(真 deepseek)：修前中文名必现 tools[0].function.name 400；修后该 400 归零。
补 TestToolFuncName 覆盖：纯中文/合法ASCII/混合名/撞名唯一性。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-15 17:41:21 +08:00
Blizzard 484cc18664 chore(dispatcher): 升级 eino v0.9.9 → v0.9.12 
v0.9.9→v0.9.12 共 3 个提交，仅 1 个与我们相关：
- fix(compose): checkpoint/runnable 的 typed-nil 归一化 —— 直接加固我们用的
  compose.Interrupt + checkpoint 恢复路径（HITL 审批 resume），修 typed-nil gob 序列化边界。被动获益，无需改代码。
- refactor(adk FailoverProxyModel) / fix(summarization)：我们未用 eino ADK/摘要组件，无影响。

build + eino 包测试全过。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-09 17:18:57 +08:00
Blizzard 1ee1e87371 fix: 状态/用量回写升级 JetStream 持久 —— 堵住漏账（core NATS fire-and-forget） 
问题：usage(计费)/status 回写走 core NATS，网关离线/慢消费者/NATS 抖动期间
dispatcher 发的事件直接丢——任务照跑照烧 token，但这次计费凭空消失（漏账），且零重试零对账。
（对比：提交/审批/入库本就 JetStream 持久，唯独回写是 best-effort。）

修复（照 tasks/approvals 套路）：
- 新增 JetStream 流 SUNDYNIX_USAGE(MaxAge 72h) / SUNDYNIX_STATUS(24h)，捕获 usage.task/status.task。
- PublishUsage/PublishTaskStatus 改 js.Publish（同步等 stream ack）；dispatcher+gateway 启动各自 ensure 流。
- ConsumeUsage/ConsumeTaskStatus 持久消费者 + 显式 ack：落库成功 Ack、失败 Nak 重投自愈、脏数据 Term。
- 幂等保证 at-least-once 安全：usage_event.task_id 唯一 + 门控；SaveUsageEvent 返回 inserted，
  仅新插入才累计 Redis 日计数（非幂等旁路，防重投重复累加）；UpdateTaskStatus 按 task_id 覆盖幂等。

live 验证（复现原漏账场景）：提交任务→立刻杀网关→dispatcher 跑完把 usage 发进持久流
（网关离线，usage_event=0 但流积压 1 条=钱没丢）→重启网关→自动补消费：任务 done、
usage_event 补上、公司A 余额扣 0.098、消费者 num_pending/ack_pending 归零。旧设计下这笔会永久丢失。

eval 回写仍 core NATS（仅观测，低价值，暂不改）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-09 17:07:31 +08:00
Blizzard d032c198c8 feat: SaaS P2 计量·增量1 —— 用量按租户落持久明细 + 积分/成本折算 
链路打通 tenant → 计费事实源：
- 契约：Task.Meta 加 MetaTenantID；UsageEvent 加 TenantID。
- 提交：网关 task.Meta[MetaTenantID]=tenantID(c)；dispatcher emitUsage 带租户。
- 明细表 sundynix_usage_event（追加式，task_id 唯一→幂等防重投重复计费）：
  tenant/owner/model/tokens + credits_micro + cost_micros。
- 折算：credits=total_tok/TOKENS_PER_CREDIT×credit_weight（token 基准，设 1 即 token 直计）；
  cost 按 Pricing 折算；Pricing 加 credit_weight 列（每模型积分权重，缺省 1）。
  模型名空则回退激活 chat 模型（近似，忽略 failover 备用模型，已在设计标注）。
- 网关 SubscribeUsage 折算落明细（保留 Redis 日计数作快速配额校验）。

live 验证：提交任务→一行 usage_event，tenant 匹配用户租户、
credits=89tok/1000×2×1e6=178000 微积分、cost=45/1000×1+44/1000×2=133000 微元 CNY，
折算数学与幂等键均正确。

设计见 SAAS_P2_DESIGN.md。增量2（credit_ledger 余额软扣 + rollup）待做。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-07 10:54:29 +08:00
Blizzard 55d50417a9 feat: 模型健康/熔断态 surface 到管理端（T4.F 可观测） 
failover/熔断的运行时态原来只在 dispatcher 日志、admin 看不到 —— 本次接到概览可见：
- harness: CircuitBreaker.Snapshot() 只读观测访问器（state + fails，不动状态机）
- llm: Pool.ModelHealth() 上报主备链每模型 {provider,model,role,state,fails}；
  buildWithFallbacks 把模型名↔breaker 配对（同包直接读 failoverModel.breakers）；
  newFailoverModel 改返回具体类型以便读 breakers
- dispatcher 心跳 payload 加 models[]
- gateway /admin/overview 独立超时 Ping dispatcher，合并进 models.health
- admin 概览「模型路由」新增「运行时链路态(实时)」：逐模型状态点
  (🟢在线/🔴熔断中+失败数/🟡半开探测/单点)
- 单测：Snapshot、Pool.ModelHealth(名字↔态配对/单点/空)
- live：配坏主→提交任务打熔断→概览显示 broken-demo「熔断中·失败3」，备用在线

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-06 12:00:13 +08:00
Blizzard 7c211719d2 fix(dispatcher): 熔断器接回 failover —— 挂掉的主模型跳过而非每次白试（T4.E 收官） 
- failoverModel 加每模型熔断器(阈值3/冷却20s，比编排层更紧)：
  主模型持续失败达阈值 → 熔断 → 后续请求直接跳过主、直连备用(省掉每次白试主的失败往返)；
  冷却到点半开放行探测打回主，成功即自动恢复走主(靠熔断器半开机制，无需外部通知)
- 全部模型都熔断时强制试主兜底(编排层 o.breaker 兜"全挂")
- WithTools 重包共享同一批 breakers(状态不清零)——否则每次 rewrap 熔断失效，关键坑
- harness 加 NewCircuitBreakerWith(threshold,cooldown,halfOpenMax) 参数化构造
- Generate/Stream 用泛型 runFailover 共用选路循环(去重)
- 3 新单测：熔断跳过主/WithTools 共享熔断状态/冷却后半开恢复(全三态)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-02 10:49:54 +08:00
Blizzard 4bec95fde1 fix(dispatcher): Branch else 兜底 + 选路留痕（T4.E） 
- branchNode 识别 default/else 边：主选择(true/false 或边序)未命中任何下游时，
  走显式 default 边而非悄悄落 END
- trace 明确区分「走 default / 未匹配收口结束(END) / 正常选路」，
  杜绝静默 fall-through 被误当 bug
- compose 层原有 len(chosen)==0 → END 收口保留（无 default 时的安全兜底）
- 3 断言单测：default 命中 / 条件真走 true / 无 default 未命中仍返回空

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-02 10:08:05 +08:00
Blizzard f9c849b14b fix(dispatcher): 多智能体专家超时 —— 卡死专家不再拖垮协调（T4.E） 
- specialistTool 加 timeout 字段(默认 specialistTimeout=3min，专家可多轮 react+工具故给宽)
- InvokableRun 用 WithTimeout 包裹专家派发；超时(DeadlineExceeded)作为"观察"
  跳过该专家(err=nil)，lead 据其余专家继续综合，不中断整个协调
- 2 单测：卡死专家 ~50ms 跳过并返回超时观察 / 正常专家不受影响
- timeout=0 时不包裹(向后兼容既有 specialistTool 构造)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-02 10:03:29 +08:00
Blizzard de36ed4cb3 fix(dispatcher): Map 节点错误传播 —— 并行子项失败不再静默（T4.E） 
- writeSection 返回 (body, error)：仅真·LLM 调用失败返 err；预算触顶/模型未配置
  是主动降级(可见降级正文，err=nil)不计失败
- writeSections 返回 ([]section, failed)：失败项 Body 带可见「撰写失败」标记 + 汇总失败数
- mapNode：全部子项失败 → 置 b.fatalErr(任务判 failed 而非静默 done-空)；
  部分失败 → trace span + 流式 ⚠️ 告警
- report handleReport：部分章节失败时流式提示，不再当全成功
- 3 单测：全失败/部分精确计数(=1 非 all-or-nothing)/mapNode 置 fatalErr

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-02 09:56:26 +08:00
Blizzard 5736ad145e feat(prompts): v2 DB 控制面热切换 —— 版本留存 + 不重启即生效 
在 v1(注册表+文件覆盖)上加 DB 管理层与热切换，镜像 model-config 控制面：
- store: sundynix_prompt 表(key/version/content/active) + ActivePrompts/ListPrompts/
  CreateVersion/Activate/Deactivate
- 控制面: ServePrompts/RequestActivePrompts(+Retry)/PublishPromptsUpdated/SubscribePromptsUpdated；
  prompts.ApplyOverrides 整体替换覆盖集(DB 激活集为权威)
- gateway API: GET/POST /api/v1/prompts、version/activate/deactivate；激活/撤销即广播
- dispatcher/mcp-go: 启动拉激活集 + 订阅热更新(不重启)
- live: 建版本→激活→mcp-go 图谱抽取 2→0→回滚 2(全程不重启)；deactivate 回退代码默认；版本可回溯

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-30 14:59:52 +08:00
Blizzard 9a3a816c80 feat(prompts): prompt 版本化地基 —— 注册表 + 运行期文件覆盖 
把散落各服务的硬编码 system prompt 收口为受管注册表，不重编译即可改/回滚/对比：
- shared/prompts：内置默认(随代码) + 运行期覆盖(PROMPTS_FILE) + Get/Keys，并发安全，含单测
- 接入 9 处：mcp-go(graph.extract)；dispatcher(eval.quality/eval.refine/guard.jailbreak/
  coordinator.lead/memory.extract，按引用登记默认、无文本重复)
- main 启动调 LoadFile 加载 PROMPTS_FILE 覆盖
- live A/B：覆盖 graph.extract → 图谱抽取 2 条→0 条、向量仍正常（覆盖生效、管道未坏）
- v2(DB 控制面热切换 + 灰度)留后续

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-30 14:36:04 +08:00
Blizzard e80e481f9f feat(llm): T2.3 输出缓存 —— 同输入命中跳过 LLM 调用（省成本+提速） 
在 eino model 层加 cachingModel 装饰器，包在 failover 链最外层：命中直接跳过整条链。

- 只缓存 Generate（非流式）：Stream 是用户可见的创作型输出、重复率低且回放复杂，透传不缓存。
- 键 = 模型名 + 绑定工具哈希 + 消息内容哈希，不同模型/工具集/输入互不串味。
- 默认 TTL 60s（env LLM_CACHE_TTL_S，0=关）：只覆盖短窗内的重试/双发/重复点击 —— 这类
  几乎一定同一意图，命中省成本+提速；又短到不让助手对同一问题长期"复读"。容量上限
  LLM_CACHE_MAX(512) 满则随机淘汰。换激活模型 → 键含模型名自然失效。

测试：命中跳底层/不同输入不串味/TTL 过期重调/流式不缓存/工具集不同键/TTL=0 禁用。

诚实说明：本平台以创作型流式为主、且 Generate 输入(专家简报/评测)每次都变，**真实命中率
天然偏低**——主要吃"短窗内逐字相同"的重试/双发。机制正确、零风险(可 env 关)，但不是大
成本杠杆；更大的省钱项(语义缓存/确定性工具结果缓存)是后续。Prompt 版本管理(T2.3 另一半)
未做。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-30 09:40:20 +08:00
Blizzard ecf4a80466 feat(llm): T2.1 模型路由 + Fallback —— 单 provider 抖动不再整体宕 
现状：单 provider，一家 API 抖动/挂掉全平台不可用。加主备 failover：主模型调用失败
自动按序切备用，compose/ReAct/Chat 全路径透明白嫖。

- llm/failover.go: failoverModel 把多个 ToolCallingChatModel 串成主备链，按序调用、
  遇错切下一个；它本身是 model.ToolCallingChatModel 故全路径透明。调用方主动取消
  (ctx.Err()!=nil) 不切；模型自身请求超时走内部 ctx、不污染父 ctx 故仍 failover。
  局限(v1)：Stream 仅建流同步报错时切（已回流 token 的中途失败不切）。
- llm/pool.go: SetConfig 用激活配置(含 Fallbacks)重建——主+可用备用串成 failover 链，
  无备用则直接用主；备用单个构建失败跳过不影响主链。
- contract.ModelConfig: 加 Fallbacks 字段（骑在主配置里下发，不改任何 bus/ServeConfig 签名）。
- gateway store.ActiveConfig: chat 把"其它已登记 chat 模型"按序填进 Fallbacks；
  provide(main) + broadcast(admin) 共用 → 注册多个 chat 模型即自动成主备。
- bus.decryptConfig: 备用模型的 api_key（密文）一并解密。

测试：failover 单测（主可用不调备/主挂切备/全挂报错/取消不切/Stream 切备/WithTools 链）。
live 验证：active=死 ollama 主 + deepseek 备 → 任务连主拒连→自动切 deepseek→4s 完成。
DEPTH_ROADMAP T2.1（admin 注册多模型即主备，无需新 UI）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-30 09:26:18 +08:00
Blizzard ef6f525a74 refactor(dispatcher): T1.1 退役 graph.go —— 编排引擎收成单一 compose 
compose 已默认数天、HITL/多智能体/评测全在其上真实跑过，soak 充分。删掉自研拓扑
解释器这第二套引擎，消灭"双实现 drift"税：

- 删 runGraph（graph.go 的自研解释器）+ composeEnabled/EINO_COMPOSE 逃生舱开关
  + runConversation（仅 runGraph 用的死代码）。
- executeGraph 直接走 runComposeGraph；compose 编译失败兜底改单轮对话（不再回退
  graph.go）；清掉仅 runGraph 用的 import（otel attribute/trace/otelx）。
- 保留 board / 各节点执行器(retriever/tool/agent/branch/approval/map/render/aggregate)
  / 工具函数 —— 它们是 compose 各节点 lambda 复用的，非 graph.go 专属。
- 测试：8 处 runGraph→runComposeGraph；等价测试(对照两引擎)转为 compose 正确性测试；
  runConversation 的开关测试转为「无 ChatModel 降级 runAgent」。

go test ./... 全绿 + vet 干净；冒烟 简单 agent/分支图 跑通。此后每个编排改动不再两边
对齐，成本减半。DEPTH_ROADMAP T1.1 ✅。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-30 08:53:02 +08:00
Blizzard 835a6d7432 fix(harness): 评测不再误判长答案「截断」—— 评审截断从 1500 抬到 6000 + 明确标注 
T0.1 校准后 judge 变严，但被评测自己的截断坑了：judge 评分前把模型回答截到 1500 字
(evalTruncate(output,1500))，而报告/多智能体综合等长答案普遍 2000+ 字 → judge 只看到
前半截、误判「回答不完整/截断」，给出假阴性 warn。多智能体一跑就暴露(2278 字答案被
误判 0.55 warn「截断」)。

- evalReviewOutput: 评审长度上限 6000(覆盖绝大多数长答案)；确被截断时明确标注
  「已被评审系统截断，勿因结尾不完整扣分」，杜绝 judge 因自身截断而扣分。
- llmJudge / llmJudgeGrounded 改用 evalReviewOutput 喂模型回答。

live 验证:同款 2 专家协调任务，修复前 0.55 warn「截断」→ 修复后 0.85 ok，且 judge
挑出真实缺陷(推荐逻辑前后矛盾)而非假截断。既公平又严格。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 17:35:13 +08:00
Blizzard 158fe094ab fix(hitl): 审批复盘轨迹补全 —— 中断不关 exec 流，resume 事件续录 
现象:已完成的审批任务，复盘轨迹停在「已中断等待审批」、审批节点永远转圈，看着
像卡住（实际任务已 done、有输出）。

根因:任务中断时 Handle 的 defer tr.done() 给 exec 流发了 CompleteExec → 网关 exec
录制器关闭。resume 是另一次独立调用，其 exec 事件（审批通过/拒绝、续跑节点）发到
同一主题时录制器已关 → 没录进去。（token 流中断时特意没关，所以输出录到了；exec
流却被关了，不对称。）

- exec.go: execTracer 加 suspended 标志，done() 挂起时不关流。
- orchestrator.go: 中断分支置 tr.suspended=true（与 token 流一致）。
- ExecTrace.tsx: 前端兜底——运行已完成(phase done)时把悬挂的 waiting/running 节点
  收敛为 done，修旧任务（已 done、轨迹缺 resume 事件）的转圈假象。

live 验证:审批任务批准后复盘轨迹完整呈现 approval await→end「批准：放行」→
agent start→推理→end，审批节点不再转圈。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 16:57:11 +08:00
Blizzard 5fb6e3ffa8 fix(harness): T0.1 校准评测裁判 —— 让恒温器真触发(此前全 1.00 空转) 
诊断:旧评测 LLM judge 恒给 0.94/1.00、从不判 poor → 低分自动纠偏闭环几乎从没
启动。根因两层:
1. 提示词软:只说"严格"但无评分基准、不强制挑毛病 → 模型恒锚定 4–5。
2. 数学更致命:归一 score/5 下限 0.2，叠加无来源 Overall=0.4*rule+0.6*s 的
   0.4*rule≈0.4 底 → Overall 恒 ≥0.52、poor(<0.5)对"流畅但跑题/错误"永不可达。

修复:
- judge 提示词改对抗性+rubric:默认怀疑、先点缺陷再打分、给死 1–5 评分基准、
  要求用满区间;grounded judge 忠实度按编造说法递减(一处编造≤2)。
- 归一 score/5 → normJudge=(v-1)/4(1→0)，让低质能压到 poor 触发纠偏。
- 测试:normJudge 区间 + 流畅跑题(judge=1)可达 poor + 好坏区分度;更新两处旧
  断言(4→0.75, 2→0.25)。

live 验证(deepseek):跑题→0.40 poor→自动纠偏(0.40→0.55);截断→0.55 warn;
好答案→1.00 ok。校准前三者全 1.00。评测+纠偏的投入由"摆设"变"在用"。

DEPTH_ROADMAP T0.1 ✅。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 16:23:30 +08:00
Blizzard 66caeef35c feat(agent): 多智能体协同 v1 —— coordinator 节点(Eino×Anthropic 融合) 
LLM 自主在 agent 间路由/委派:orchestrator=ReAct(Eino 出机器),编排认知按 Anthropic
orchestrator-worker 配方(出脑子)。专家=包成工具的子 agent(agent-as-tool),lead 给
每个专家写定制简报(brief)后并行派发、综合。方案见 MULTI_AGENT.md。

为什么 agent-as-tool 而非 Eino host:host 的 specialist 拿原始输入(preHandler
return state.msgs),传不了 lead 写的定制简报,而定制简报正是 Anthropic 多智能体的
精髓。agent-as-tool 让 orchestrator 自己 emit 工具调用、参数 brief 即简报。
= OpenAI agent.as_tool() / Anthropic 研究系统的 orchestrator-worker。

- coordinator.go: specialistTool(react.Agent/ChatModel 包成 InvokableTool,入参 brief,
  精炼返回) + parseSpecialists/buildSpecialists(带工具→react,不带→ChatModel,MCP 工具
  按 spec.tools 过滤) + runCoordinator(lead 提示词=Anthropic 配方) + leadOrchestratorPrompt。
- 双路接入 execDSLNode(compose)+ runGraph(graph.go)的 case coordinator。
- 护栏:禁套娃(专家是内联叶子)/ MaxStep / 专家 I/O 计入共享 Budget / 降级(无
  ToolCallingModel 或 0 专家 → runAgent)。
- streamAgentReply:抽出 runReactAgent 与 runCoordinator 共用的流式回流尾段。
- 复用即得:evaluator-optimizer=harness 低分纠偏;成本天花板=预算护栏;上下文隔离=
  专家独立 react.Agent;观测=每次派发落 agent 轨迹。

测试:parseSpecialists / agent-as-tool 包装(brief 透传+精炼返回+失败作观察) / 降级。
live 验证(真 deepseek):两专家**并行派发**、lead 给各自写**不同定制简报**、最终
**综合**(非拼接)成稿,评测 1.00。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 15:37:23 +08:00
Blizzard 0378a770ca fix(hitl): resume 记录 KV 键不可含冒号（NATS: invalid key） 
live NATS 联调发现：resume 记录键用 "pending:"+taskID，冒号是 NATS JetStream KV
非法字符（仅允许 [-/_=.a-zA-Z0-9]）→ 中断时 persistResume 的 Put 静默失败、决定
到达时 loadResume 报 "nats: invalid key"，任务永卡 waiting、无法恢复。内存桩接受
任意键，故单测漏过——正是只有 live NATS 才暴露的那类。

- pendingKey: "pending:"+id → "pending_"+id（合法键）。
- persistResume: Put 失败改 log.Printf 大声告警（不止 exec 轨迹），关键失败可见。
- 回归测试 TestPendingKeyIsNATSValid：直接钉键形匹配 NATS KV 字符集，绕开内存桩盲区。

live 验证（devnats + 真链路）：提交 HITL 任务→waiting→杀 dispatcher→离线批准→
重启→1s waiting→2s running→3s done，deepseek 真实出稿。证明 checkpoint 抗重启 +
决定经 JetStream 抗离线 + 断点恢复。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 14:25:47 +08:00
Blizzard 515cf7f87a feat(hitl): 增量3b —— 持久决定投递 + 生产激活（HITL 中断/恢复上线） 
把中断/恢复模型在 dispatcher 接线启用，并让审批决定持久化抗离线。至此 HITL
从「阻塞 goroutine 等 5min、core NATS 非持久、不抗重启」升级为「持久化中断 +
决定持久投递 + 从 checkpoint 恢复续跑」。

- contract: 新增审批决定流 StreamApprovals(SUNDYNIX_APPROVALS)/通配
  SubjectApprovalAll/消费者 ConsumerApprovals + checkpoint 桶 BucketCheckpoints。
- bus: EnsureApprovalStream（JetStream 流持久捕获 sundynix.approval.>，MaxAge 24h；
  gateway 现有 nc.Publish 的决定被本流自动捕获，无需改 gateway）+ ConsumeApprovals
  （持久消费者，队列组多副本安全）。
- orchestrator: HandleApprovalDecision（据 task_id 取 resume 记录续跑；无记录则忽略，
  兼容阻塞态任务的决定 + 决定重投幂等）+ finishResumed（收尾对齐 Handle 尾段：
  中断/拒绝/预算/失败/成功+评测落历史）。
- main: 开 checkpoint 存储 + 审批流 + 起决定消费者 → SetCheckpoints 启用中断模型；
  任一步失败优雅降级回阻塞模型；停机 drain 在途 resume。

决定经 JetStream 持久：dispatcher 在决定发出时离线，重连后仍消费到并续跑；任一
dispatcher 副本都能据共享 KV 的 checkpoint+记录恢复（HA）。
测试：决定驱动恢复（续跑下游+判 done+清记录）、无记录忽略（幂等/兼容）。
全模块 go build + go test 绿。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 13:08:41 +08:00
Blizzard 368938ce89 feat(hitl): 增量3a —— resume 重入闭环（从 checkpoint 续跑审批） 
把 HITL 的恢复半边补上：人工决定到达后从 checkpoint 重入图、喂给审批节点续跑。
至此中断→恢复全闭环在 compose 路径打通（in-process 端到端测试钉死）。

- runComposeGraph 重构为统一入口 execComposeGraph(rc)：rc==nil 全新执行、rc!=nil
  从 checkpoint resume，两路共用建图/编译，仅三处分叉——①记忆注入仅 fresh（resume
  时黑板由 checkpoint 还原，重注入会覆盖已积累态）；②Invoke ctx（resume 经
  ResumeWithData 注入决定）；③终态黑板来源。
- live 捕获：resume 时 compose 用 checkpoint 还原的实例作 local state（非闭包 b），
  故节点 ProcessState 内捕获 live 指针，Invoke 后据此读终态（fresh 仍读 b）。
- resume 记录：中断时把 {interruptID, Task} 落 KV(pending:task_id)，供决定在另一
  goroutine/重启进程独立重建任务并续跑；终态清记录 + checkpoint（幂等）。
- ResumeApproval(t, dec) 入口：载记录定位中断点 → execComposeGraph resume。续跑
  语义同 fresh：再遇审批→errInterrupted、批准跑完→稿+refs、拒绝→errRejected。

测试：批准（黑板无损还原 + 下游执行 + 状态拨回 running + 清记录/checkpoint）、
拒绝（errRejected + 拒绝语 + 下游不跑 + 清 checkpoint）。这条用例也透过 eino 真实
checkpoint 路径端到端验证了 board 序列化（2a）。全量 go test ./... 绿。

下一步 3b：审批决定改 JetStream 持久投递 + orchestrator 持久消费者触发 ResumeApproval
+ main 接 Bus.Checkpoints 打开开关。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 12:57:07 +08:00
Blizzard bc7600625d feat(hitl): 增量2b —— 审批节点改 compose.Interrupt + orchestrator 识别中断 
接了 checkpoint 后端时，审批节点从「阻塞 goroutine 等 5min」改为持久化中断：
首次执行发待审 + 置 waiting + compose.Interrupt → compose 把整图状态（含 board）
落进 checkpoint store 并返回中断错误 → Handle 释放 goroutine、任务停在 waiting，
不收尾不评测不判 done。抗 dispatcher 重启。

- orchestrator: 新增 errInterrupted 哨兵 + checkpoints 字段 + SetCheckpoints
  setter（沿用 guard/usageSink 的 setter 注入，不动构造签名）；Handle 识别
  errInterrupted → 释放 goroutine、保留 waiting、SSE 流不关。
- compose_compiler: 编译挂 WithCheckPointStore + WithGraphName("root")，Invoke
  带 WithCheckPointID(task_id)；审批节点接 checkpoint 时改走专用
  approvalInterruptLambda（须把中断错误作节点返回值上抛，泛型 lambda 会吞掉）；
  ExtractInterruptInfo 识别中断 → 上抛 errInterrupted。
- graph.go: 抽出 approvalSummary / applyApprovalDecision，阻塞式与中断式审批共用，
  杜绝两路文案/语义漂移。

双路径并存：未接 checkpoint 后端（store=nil）维持阻塞模型，行为不变；main 暂不
接，生产保持阻塞，待增量3 resume 闭环补齐再打开（建在 flag 后）。

测试：中断半边端到端——errInterrupted + 置 waiting + checkpoint 落 KV(key=task_id)
+ 下游 agent 不执行。既有阻塞式审批/等价测试全绿。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 12:46:48 +08:00
Blizzard 5a1a994cc2 feat(hitl): 增量2a —— board 可序列化（compose checkpoint 的状态载体） 
compose checkpoint 把图执行态（含 GenLocalState 的 board）序列化进 store，但
Eino 序列化器只认导出字段，而 board 字段全未导出 → 直接持久化会落成空、resume
丢全部状态。Eino 对同时实现 json.Marshaler+Unmarshaler 的类型改走自定义 JSON
（internal/serialization checkMarshaler），故给 *board 实现一对 JSON 方法映射到
导出 DTO，无需把 board 字段全导出（牵连几十处调用点）。

- board_serde.go: *board 的 MarshalJSON/UnmarshalJSON ↔ boardSnapshot；丢弃
  fatalErr（transient error，中断点必为 nil）；schema.RegisterName[*board] 注册
  类型名供 checkpoint 的 State(any) 还原。
- 测试: 快照往返无损 + 编译期断言实现 json.Marshaler/Unmarshaler + fatalErr
  不被持久化。

零行为变更（纯新增）。go test ./... 全绿。
下一步 2b：审批节点 compose.Interrupt + 编译挂 checkpoint store + orchestrator
识别 InterruptInfo 置 waiting 并释放 goroutine。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 12:38:23 +08:00
Blizzard f3bf42c432 feat(hitl): 增量1 —— JetStream KV checkpoint store（持久化中断地基） 
HITL 持久化中断/恢复的地基：compose checkpoint 需要一个可持久化、抗重启的
存储后端。dispatcher 是"只说 NATS、无 DB"的纯净设计，故复用既有 JetStream
（bus.js）开 KV 桶，不引 Redis、不破坏架构原则。

- shared/bus: 新增 KVHandle + Bus.Checkpoints(bucket, ttl)。薄封装把 NATS
  细节（ErrKeyNotFound→ok=false、Delete 幂等）挡在 bus 内，对外是朴素
  Get/Put/Delete；bus 无需反向依赖 eino。File 存储 + 桶级 TTL 兜底清理。
- dispatcher/eino: checkpointStore 把 CheckpointKV 适配成 compose.CheckPointStore
  （Get/Set + 可选 Delete）。CheckpointKV 是最小接口，bus.KVHandle 结构化满足。
- 测试: 内存桩往返（Set→Get→Delete→miss）+ 编译期契约断言
  `var _ CheckpointKV = (*bus.KVHandle)(nil)` 钉死 bus↔eino 隐式契约。

零爆炸半径（纯新增）。go test ./... 全绿。
下一步增量2：审批节点改 compose.Interrupt + Orchestrator 识别中断置 waiting。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 11:39:20 +08:00
Blizzard 03225e31a9 refactor(dispatcher): compose 翻默认 —— 补平三缺口后退役 graph.go 在望 
EINO_COMPOSE 默认改为开（留 =0 逃生舱回退权威 graph.go）。翻默认前补平
compose 路径三个会静默吃掉治理能力的缺口：

- HITL 审批：execDSLNode 无 approval 分支 → 审批节点被当未识别跳过、下游照跑；
  补 case 调 approvalNode。
- 忠实度评测：executeGraph 把 refs 硬写 nil → 评测静默失效；runComposeGraph
  改签名回传 refsOf(b)。
- 终态传播：rejected/fatalErr 不传播也不阻断下游 → 任务误判 done-空；加节点
  lambda 入口守卫 + branch cond 守卫 + 终态上抛 errRejected/fatalErr，并让
  runComposeConversation 模型失败置 fatalErr（对齐 graph.go 的 break 语义）。

新增等价测试：审批拒绝停下游、refs 回流。go test ./... 全绿。
soak 无回归后即可物理退役 graph.go。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-29 11:13:46 +08:00
Blizzard 594be6a317 fix(desktop): 模型输出渲染图表 + Markdown 支持表格/代码围栏；ReAct 步数提至可配 12 
针对运行页输出的两个渲染缺口 + 一个节点报错：
- 图表：模型输出走 chart 块分段渲染（文本 Markdown，```chart 块用 ChartView 出图），
  不再把图表 spec 显示成原始代码。
- 表格：轻量 Markdown 组件原本不支持 GFM 表格（| … | 显示成原始竖线）与 ``` 围栏代码，
  现补上：表格解析成 <table>、围栏渲染成 <pre>。
- ReAct 步数：reactMaxStep 由常量 8 改 env 可配（REACT_MAX_STEP，默认 12）。研究型任务
  （搜索→抓取→推理多轮）8 步偏紧易触顶报 exceeds max steps；提到 12 覆盖多数。

tsc+vite 通过，dispatcher build/vet 绿；wails 重启加载。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 17:33:58 +08:00
Blizzard a5fd251fc0 feat(deploy): 容器化 + 一键独立部署 —— 5 服务镜像 + prod compose + 安装/备份/许可 
此前应用服务只是本机裸二进制、无 Dockerfile、无法交付。本提交把项目从"只能在我笔记本
跑"变成"任何人一条命令起一整套"，是「演示 / 拉投资 / 卖给客户独立部署」的可交付基础。

- Dockerfile ×5：gateway/dispatcher/mcp-go 多阶段(distroless static, 36–55MB)；
  mcp-py(python-slim, 268MB)；admin(node 构建→nginx 托管 SPA + 反代 /api，76MB)。
  Go 构建上下文为仓库根以兜住 replace ../sundynix-shared；.dockerignore 瘦上下文。
- docker-compose.prod.yml：应用 + 基建一把起；经服务名互连（顺带避开 localhost DNS 坑）；
  基建端口不对宿主暴露；depends_on 健康检查保序（mcp-go 待 Milvus healthy）；
  APP_ENV=production 强制密钥校验 + 锁 CORS + 管理员白名单。
- .env.example + DEPLOY.md：两类密钥分层（引导密钥走 .env，模型 key 控制台加密存库）；
  首次管理员流程；安全建议。LICENSE 专有（授权模型可后定）。
- scripts/backup.sh + restore.sh：PG 逻辑备份 + 各数据卷快照 / 恢复。
- .gitignore 挡 .env*（密钥不入库）。

live：5 镜像全构建通过；独立 project 起整套 → nginx→gateway→NATS→dispatcher→mcp 全链路
注册+提任务 running→done，depends_on 保序生效。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 15:23:36 +08:00
Blizzard 165ecb4ec6 test(dispatcher): RAG 管线集成测试 —— 检索→注入→生成→refs→忠实度评测整条链 
补全核心链路最后一块。此前只测了 retriever 组件的解析，整条 RAG 管线没被集成覆盖。

新增 rag_integration_test.go 4 例：
- ConversationInjectsAndReturnsRefs：input→retriever→agent，断言 kb_search 被调、
  kb 按 owner 作用域(u42/travel)、检索片段注入 agent system prompt、refs 经 runGraph 回流。
- RefsDriveGroundedEval：有 refs 时 evaluate 走「含检索资料」的 grounded judge 路径，
  记录忠实度分（而非无来源路径）。
- ReportSectionInjectsRefs：报告 writeSection 检索命中注入撰写 prompt。
- DegradesWhenRetrieverDown：kb_search 失败 → 空 refs，agent 仍正常出答案、整图不失败。

go test -race ./internal/eino 干净，四模块全绿。至此核心编排链 + RAG 管线均有集成兜底。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 14:21:11 +08:00
Blizzard 32f50cd983 test(dispatcher): Handle 入口级集成测试 —— 钉死核心编排链 + harness 治理栈协同 
此前测试都直打 runGraph/evaluate，绕过真正的任务入口 Handle()——熔断、输入护栏门控、
状态机流转、token 预算、异步评测/用量这些治理逻辑的协同从未在入口级被覆盖。

新增 handle_test.go 6 例（全 fake 依赖，可断言各出口）：
- HappyPath：running→done + token 流出/收尾 + 异步评测落库(ok)
- ToolFeedsAgent：图执行→工具→agent 全程经 Handle，工具被调、产出注入
- CircuitBreakerOpen：熔断开 → 快速 failed、不执行图
- BudgetExceeded：meta token_budget=3 → failed + 用量回写带 Exceeded
- GuardrailBlocks：灰区 + LLM 分类器命中 → rejected、不进 running
- EmptyTaskDropped：空 id 直接丢弃、无状态回写

配套 fakeStatus/fakeUsageSink；fakeEvalSink 加锁（Handle 异步评测在 goroutine 写）。
go test -race ./internal/eino 干净，四模块全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 14:10:53 +08:00
Blizzard 7bfea74cc0 feat(perf): 容量压测器 + 平台天花板实测曲线 
cmd/loadtest：闭环加压器，阶梯并发，经 SSE 流检测完成（非轮询，避免轮询放大把网关
压成假瓶颈），输出吞吐 + 延迟分位。配套两个 benchmark 开关：
- dispatcher LLM_FORCE_STUB=1 + LLM_STUB_TTFT_MS/INTERTOKEN_MS=0：绕开真实 LLM 推理，
  量平台自身全链路天花板（不烧 token、不被模型节奏掩盖）。
- gateway RATE_LIMIT_PER_MIN 可配（缺省 120）：压测放开限流。

实测（单 dispatcher、并发64、stub）：
- 单任务纯平台开销 ~42ms；吞吐峰值 ~110 全链路任务/秒（饱和点 并发32–64）；
  并发128 优雅降速，256 硬崩。
- 吞吐瓶颈不是 DB 连接数（池 25→80 吞吐不变），是每任务多跳管线综合成本；
  256 崩根因为 DSN 用 localhost、pgx 每连接解析 → 连接churn致 DNS 取消（易修）。
- 关键判断：平台 42ms ≪ LLM 秒级出答案，平台不是瓶颈、GPU 才是；横向拆服务喂满 GPU 集群
  的意义成立。细节与曲线见 project_analysis「容量实测」。

stub 延迟改 env 可配（默认值不变）；不影响线上路径。dispatcher+gateway build/vet/test 全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 11:46:50 +08:00
Blizzard 075d41f5b3 feat(llm): 本地模型接入 vLLM / Ollama + reasoning 思考过程入轨迹 
vLLM 与 Ollama 都暴露 OpenAI 兼容 API（底层 go-openai 请求 {base}/chat/completions），
故统一走 openai 客户端，按 provider 归一化连接参数：
- Ollama/vLLM 的 OpenAI 端点固定在 /v1，BaseURL 漏写自动补全（否则打到 /chat/completions 404）
- 本地后端默认不校验 api_key → 缺省补占位（ollama→"ollama"，vllm→"EMPTY"；openai 客户端要求非空）
- 显式 key 一律尊重（vLLM --api-key 启动）；在线 provider 原样不动（DeepSeek 两种都收）

reasoning_content 适配：ChatStream 增 onReasoning 回调，捕获 reasoning 模型
（本地 Qwen3 思考 / DeepSeek-R1 / QwQ、在线 deepseek-v4-pro）的思考分片。思考阶段分片
Content 为空本就不污染答案；runAgent 把思考累计后 surface 到 exec 轨迹「推理过程」事件。

控制台 ModelManager 加 ollama 选项；llm 包补 normalizeBaseURL / apiKeyOrPlaceholder 单测。
四模块全绿。live：经 admin 配 ollama qwen2.5:0.5b → dispatcher 热切（日志 base 自动 .../v1）
→ POST /v1/chat/completions 200 端到端出答案；切回 deepseek-v4-pro → exec 轨迹现「推理过程：思考26字…」。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 11:10:18 +08:00
Blizzard 05c25d7099 feat(ops): 优雅停机 drain —— 三 Go 服务 SIGTERM 后排空在途，不硬切 
滚动更新/重启时旧的"信号到→进程退"会硬切在途工作：dispatcher 在途任务被掐断、
mcp-go 在途工具调用让 dispatcher 干等超时、gateway 在途 HTTP 请求被截断。

共享 bus 加在途追踪 + drain：
- ConsumeTasks/ServeTool 各加 sync.WaitGroup 跟踪在途 goroutine，返回 drain(ctx)：
  先停止接新活（cc.Stop / Unsubscribe），再等在途跑完至 drain 超时。
- 关键修复：任务 handler 的 ctx 改为派生自 context.Background()（而非信号 ctx），
  否则 SIGTERM 会立即取消在途任务的 ctx，drain 形同虚设。超时未跑完才由 JetStream
  AckWait 重投兜底（不丢任务）。
- DrainTimeout()：SHUTDOWN_DRAIN_TIMEOUT 秒，默认 30s。

各服务收尾：
- gateway：r.Run → http.Server + signal.NotifyContext + srv.Shutdown(drain 在途请求)，
  随后 defer 关 db/redis/bus（HTTP 排空后才断后端连接）。
- dispatcher：收到信号 → drain 在途任务跑完再退。
- mcp-go：收到信号 → drain 在途工具调用回完再退（dispatcher 拿到结果而非超时）。

bus 加 TestGracefulDrain（drain 等满在途任务 + 验证在途 ctx 不被取消），e2e 测试适配
新签名，四模块全绿。live：在途任务执行中 kill -TERM dispatcher → 日志「drain 在途任务」
→ 11s 后 task done(511字完整生成) → 「drain 完成，退出」，任务终态 done 非 failed；
gateway/mcp-go 同样优雅退出。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 10:29:23 +08:00
Blizzard faa1871760 feat(harness): 成本/Token 预算护栏 —— 单任务硬上限 + 单用户日预算（恒温器最后一环） 
token 用量估算计量（CJK≈1/字、ASCII≈1/4字，无需分词器，护栏够用）。

单任务硬上限（dispatcher）：Budget 挂 ctx 沿图透传，各 LLM 节点（对话/ReAct/compose/
报告）入口计输入 token、出口计输出，触顶即中止整图——防失控成本（死循环/超大报告）。
报告路径优雅降级：触顶跳过剩余章节出部分稿，不整体失败。预算来源 Meta.token_budget
或 env TASK_TOKEN_BUDGET（默认 20 万）。

单用户日预算（gateway）：dispatcher 收尾经 NATS 回写 UsageEvent → 网关按用户按天累计
Redis（48h 过期自滚动）→ 提交前门控 USER_DAILY_TOKEN_BUDGET（0=不限，超额 402）。
/billing 升级为真实用量：当日已用 / 日预算 / 余额。

契约 UsageEvent + MetaTokenBudget + SubjectUsage；bus Publish/SubscribeUsage；
orchestrator SetUsageSink + 预算触顶 failed（不计熔断）。harness budget 5 单测，三模块全绿。
live：单任务 budget=30 → failed(已用约689)；用户日 budget=200 → /billing remaining=0 → 402。

至此 harness 由「测温计」完成向「恒温器」的演进（评测闭环/纠偏/忠实度/脱敏/输入护栏/预算六项）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 10:00:51 +08:00
Blizzard 2f78fc565e feat(harness): 输入护栏升级 —— 归一化反绕过(Tier1) + LLM 越狱分类器(Tier2) 
原输入护栏纯正则，空格/编码/同形字一改写即漏，且 bannedTerms 空置。升级为两层：

Tier1（网关同步、无 LLM）：先归一化再匹配，干掉绕过——
- 小写 + 去零宽字符 + 去变音符 + 同形字折叠(西里尔/希腊→拉丁) +
  拆字间隔还原(i g n o r e / i.g.n.o.r.e → ignore) + base64 解码回扫
- 多视图(原文/归一化/紧凑/解码)匹配高精度注入正则，无需穷举变体
- bannedTerms 经 GUARDRAIL_BANNED_TERMS env 落地
- 软信号(jailbreak/developer mode/无限制…)→ 灰区，放行但打 safety_check 标志

Tier2（dispatcher harness LLM 分类器，escalation）：
- 仅对灰区任务执行前调 LLM 裁决 jailbreak+severity，≥0.7 → rejected
- 明确干净/恶意的不付 LLM 成本；模型抖动/解析失败 fail-open 不误锁正常用户

契约新增 MetaSafetyCheck 透传灰区标志；orchestrator 加执行前护栏门控 + SetGuardian。
网关 6 单测 + dispatcher 4 单测，三模块全绿。live：拆字/base64/西里尔同形字均 422 拦，
恶意灰区被 LLM 拒(severity 1)、良性灰区(海盗 roleplay)放行完成。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-26 09:38:34 +08:00
Blizzard 9506a82be9 feat(harness): 输出脱敏增强 —— 跨分片 StreamRedactor + PII，杜绝密钥碎片泄漏 
原逐片脱敏有两个漏：①密钥被切成两片（"sk-912cf85b"|"16d0..."）逐片都不命中正则而漏检；
②贪婪正则在缓冲末尾凑够最短长度就把半截密钥提前脱敏发走、剩余字符随后明文流出（碎片泄漏）。

有状态 StreamRedactor 跨分片缓冲，切点在「原文」上定且绝不切断任何完整匹配：
- opener 暂留末尾仍在增长的疑似密钥（sk/AKIA/JWT/Bearer/手机/邮箱/长数字）
- 始终留 16B 尾窗兜底 opener 未覆盖的短模式；勿切断完整匹配（循环至稳定）
- rune 边界安全：cut 退到最近 rune 起点，中文不被切成半个发出乱码
- 暂留封顶 256B，防对抗性长串无限暂留 / O(n²)
- 新增 PII：手机号 / 邮箱 / 身份证（18 位）

3 个流式点（graph/react_agent/compose_graph）统一接入，逐片 Push + 收尾 Flush。
7 单测（跨片/逐字符 JWT/碎片回归/尾窗内匹配/干净重建/PII/无误伤），-race 干净。
live 实测：26 位密钥（曾泄漏 ijkl90mnop 碎片）与邮箱整条 [已脱敏]。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-25 16:46:08 +08:00
Blizzard 93e9d3b195 feat(harness): 低分自动纠偏 —— poor 触发评语驱动重生成，取更优者（测温计→恒温器） 
评测闭环延伸出自愈：当自动评测判定输出为 poor(综合<0.5)，dispatcher 在热路径外
自动用「原问题+初版回答+评审短板(flags/评语)」(有来源则连来源一并喂回、要求严格基于来源)
让模型重写，重评后仅当新分严格更高才采纳(绝不退步)；采纳的修订版落会话历史，
保证多轮上下文用的是好答案而非被判低分的初版。评测终值带 corrected 标记经 NATS→网关落库。

- maxRefineRounds=1：poor 稀少，1 轮重写+重评够用，防成本失控
- canRefine 门控：模型就绪且熔断未开才纠偏，避免后端抖时雪上加霜
- 单 goroutine 串 评测→纠偏→落历史，杜绝原两 goroutine 对答案版本的竞态
- 契约 EvalEvent / Eval 表 / upsert / GET /tasks/:id/eval 均加 corrected 字段
- refine_test.go：采纳更优 / 不退步 / 非低分不触发 三测；live 验证好答案不误触发

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-25 16:22:45 +08:00
Blizzard 10f08ffb14 feat(harness): 评测闭环 —— 评测结果落库 + 分级 + 告警 + 可查（测温计→恒温器） 
此前 eval 只打日志、不闭环。现在：
- 分级：evalLevel 据综合分+忠实度 → ok(≥0.75) / warn(≥0.5 或忠实<0.6) / poor(<0.5)；poor 出 slog.Warn 告警。
- 落库：dispatcher 评完经 NATS(SubjectEval) 广播 EvalEvent → 网关订阅写 PG（新表 sundynix_eval，
  按 task_id upsert）。沿用任务状态回写那套（dispatcher 无 DB，经 bus→gateway 落库）。
- 可查：GET /api/v1/tasks/:id/eval 返回 overall/rule/llm/faithful/level/flags/reason/sources。
- 契约 EvalEvent + EvalOK/Warn/Poor；bus PublishEval/SubscribeEval；dispatcher EvalSink（NewOrchestrator 第9参）。

验证：三模块 build+vet+test 全绿；live RAG 任务评测落库，端点返回 overall~1.0 / level=ok / faithful=1 / sources=1。
剩：桌面端质量面板、低分自动重试(P3)。project_analysis 勾掉该项。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-25 15:26:19 +08:00
Blizzard 446b784fc6 feat(harness): RAG 忠实度评测 —— judge 拿检索原文评幻觉 
补 Harness 已知洞：此前 LLM-judge 只看 input+output，看不到检索来源，幻觉其实没评。

- Evaluator.Score 增 sources 参数；有来源时走 llmJudgeGrounded：一次调用同时评 quality 质量 +
  faithfulness 忠实度，并列出 unsupported（未被来源支持的说法）→ 进 Flags。
  综合分(有来源)=0.3规则+0.35质量+0.35忠实；无来源时维持原 0.4规则+0.6质量。Result 增 Faithful 字段。
- 透传检索来源：runGraph 返回 (answer, refs, err)，executeGraph 同步；Handle→evaluate(input,output,refs)；
  refsOf(board)=检索资料+工具产出。compose 路径暂返回 nil refs（不评忠实度）。
- eval 日志增「忠实 X.XX，来源 N」。

测试：单测覆盖 grounded（quality/faithfulness/unsupported 解析 + 加权 + flags）与无来源跳过；
3 处测试 runGraph 三返回值更新。live 实测 RAG 任务忠实 1.00/来源 1，judge 正确判定无编造。
project_analysis Harness 清单勾掉该项。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-25 15:03:17 +08:00
Blizzard 700845d64a feat(prod): DB 连接池上限 + LLM 失败暴露为 failed（生产级并发收尾） 
为高并发生产做的三项收尾（配合已有的任务/工具并发消费）：

1. DB 连接池上限（pgsql.go / memory/store.go）：SetMaxOpenConns（默认 25，
   DB_MAX_OPEN_CONNS 可调）+ MaxIdleConns 5 + ConnMaxLifetime 1h。
   防高并发无限开连接打爆 PG（max_connections 默认 100）。
2. LLM 失败暴露为 failed（graph.go）：board.fatalErr —— agent 模型调用出错即上抛，
   runGraph 中止后续节点并返回错误 → Handle 判 failed（带原因），不再静默 done-空。
   可观测/可告警，生产排障必需。

压测验证（dispatcher 并发=50, 池=25, deepseek-v4-pro 推理）：
- 平台同一秒并发收下 40 任务，全程零 DB/连接错误，平台开销≈0（裸 LLM 1.8s vs 平台 P50 1.7s）。
- 并发 10 健康 4.7/s；20+ 延迟暴涨 = DeepSeek 开发账号并发限流（外部），非平台。
- 失败注入（错误模型名）→ 任务正确判 failed 并回传原因。

结论：平台并发机制达生产级；真实吞吐上限 = 自托管模型容量（生产 Qwen，可加卡线性扩）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 16:14:19 +08:00
Blizzard 38a74e3911 fix(history): 空答复不落历史 + 发送前过滤空消息（根治会话毒化） 
现象：某轮 LLM 返回空（余额不足/失败/降级）→ 空 assistant 消息被写进会话历史
→ 此后该 session 每次请求都带一条空 content 的 assistant 消息 → DeepSeek 400
"Invalid assistant message: content or tool_calls must be set" → 又空 → 又写空 → 自我循环毒化。

- Fix A（断源）：orchestrator.memorize 对空答复直接 return，不落历史（失败的一轮不留痕）。
- Fix B（兜底）：buildMessages 发送前剔除 content 与 tool_calls 均空的历史消息，
  防御任何来源的脏历史（含存量）。

验证：清理被污染的 default 会话后恢复正常；新逻辑下空答复不再写入。dispatcher
build+vet+test 全绿。

注：诊断中发现激活模型 deepseek-v4-pro 是推理模型（答案在 reasoning_content，content 为空），
已在管理端切回 deepseek-chat。仍待办：LLM 调用失败应暴露为 failed 而非 done-空输出。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 15:53:30 +08:00
Blizzard 16a6c4b1aa feat(hitl): 人工审批中断（Eino Phase D）—— 审批节点暂停→批准续跑/拒绝中止 
专用「审批」节点方案，全栈打通。

后端：
- contract：TaskWaiting/TaskRejected 状态 + ApprovalSubject/ApprovalDecision。
- bus：PublishApproval + WaitApproval（订阅决定主题，带超时）；消费者 AckWait
  30s→15min（阻塞等人审期间消息未 ack，否则重投成重复任务）。
- dispatcher：ApprovalWaiter 接口 + approvalNode——执行到审批节点发 await 事件 +
  置 waiting，阻塞等决定。批准→回 running 放行下游；拒绝/超时→errRejected 哨兵→
  剪下游→rejected，优雅收尾不计熔断。超时安全默认拒绝。
  taskExecTimeout 3→10min（审批5 < 执行10 < AckWait15）。
- 网关：POST /tasks/:id/approve（仅 waiting 态受理，幂等）。

桌面端：
- Studio 新增「人工审批」节点（nodeCatalog，可填标题/说明）。
- run.ts pendingApproval() 从 exec 流派生待审中断 + waiting 节点状态。
- BottomDrawer ApprovalBar：琥珀审批条（摘要 + 批准/拒绝 + 备注，调 api.approveTask）。
- ExecTrace waiting 状态灯。

验证：后端 curl 实测 waiting→批准→running→done；waiting→拒绝→rejected（下游未跑）。
前端 tsc + vitest 36 过（pendingApproval 4 例 + waiting 状态）。全模块 build+vet+test 全绿。
EINO_ADOPTION Phase D 标记 HITL 完成。

未覆盖：compose 路径（EINO_COMPOSE，默认关）的 approval 节点；桌面端审批条未在 GUI 实点。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 13:18:47 +08:00
Blizzard 218fba559c feat(observability): slog 日志带 trace_id，与链路双向互跳 
新增 sundynix-shared/otelx/slog.go：traceHandler 包装 slog.Handler，凡 ctx 有
活跃 span 的 slog.InfoContext(ctx,...) 自动注入 trace_id/span_id；SetupSlog(服务名)
装全局 JSON slog（service 标签 + LOG_LEVEL 控级）并设默认；TraceID(ctx) 辅助取 hex。

- 三个服务 main 启动调 otelx.SetupSlog。
- gateway 访问日志 Observe() 改用 slog.InfoContext(c.Request.Context(),...)（删旧
  accessLogger）→ 每条 HTTP 日志带 trace_id。
- dispatcher orchestrator.Handle 的 received/done/error 改 ctx-aware slog → 任务
  执行日志带 trace_id。
- otelx 单测 5 例（注入/无 span 不注入/With() 后仍生效/级别解析）。
- production_readiness.md 1.1：可观测性三件套（metrics+logs带trace_id+traces）闭环。

验证：dispatcher「task done」日志 trace_id 拿去 Jaeger /api/traces/<id> 命中同一条
11 span/3 服务链路；gateway 访问日志亦带同一 trace_id。四模块 build+vet+test 全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 12:41:33 +08:00
Blizzard a2d184b7ec feat(observability): OpenTelemetry 全链路追踪（Jaeger + NATS 跨总线传播） 
新增 sundynix-shared/otelx：otelx.Init(ctx,服务名) 注册 W3C 传播器 + OTLP/HTTP
批量导出（默认 localhost:4318，docker 里的 Jaeger）；OTEL_SDK_DISABLED=true 关导出。
Jaeger 不在线 / 导出器构建失败都不阻断启动（可观测性是增益而非依赖）。

- NATS 跨进程传播（无现成中间件）：bus/trace.go 的 natsHeaderCarrier + inject/extract，
  PublishTask/CallTool 注入 traceparent，ConsumeTasks/ServeTool 抽出续上 → 链路跨总线连成一棵树。
- 埋点：gateway 挂 otelgin（HTTP server span，链路根）；dispatcher task.execute →
  node.<kind>（每节点，nctx 下传使工具/LLM 挂到节点下）→ llm.stream/llm.generate；
  bus 自动出 tool.call(client)↔tool.serve(server) 成对跨服务 span。
- docker-compose 加 jaeger all-in-one（UI :16686，OTLP :4318）。
- 依赖修复：otlptracehttp 触发 genproto 单体(旧)vs 拆分模块 ambiguous import（milvus 拉旧版），
  pin genproto 至后拆分版（go.work 工作区全局生效）。
- production_readiness.md 1.1 更新为「已实现」。

验证：真实 input→retriever→agent 任务在 Jaeger 出 14 span / 3 服务的完整树，
跨 NATS（publish→consume）、跨服务（tool.call→tool.serve）均连通，
瓶颈 kb_search 692ms、llm 1597ms 一眼可见；四模块 build+vet+test 全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 11:35:08 +08:00
Blizzard 46ef3df221 feat(security): LLM api_key 端到端加密（AES-256-GCM，磁盘+线缆均密文） 
新增 sundynix-shared/secrets：AES-256-GCM，密钥由 SUNDYNIX_SECRET_KEY 经
SHA-256 派生；密文带 enc:1: 版本前缀，历史明文行自动透传（下次保存升级为密文）。

- 网关 SaveModel 加密落库；ListModels/TestModel 解密后脱敏/探测；
  空或脱敏占位的 api_key 视为「未改」→ 沿用库内既有密文（不二次加密）。
- 密文经 NATS 原样下发；消费方解密集中在 bus 层 decryptConfig
  （RequestConfig + SubscribeConfigUpdated）→ dispatcher/mcp-go 零改动。
- secrets.MustHaveKeyInProd()：生产未设 SUNDYNIX_SECRET_KEY 直接 fatal，
  gateway/dispatcher/mcp-go 启动各调一次（三服务须配相同密钥）。
- 修复 store.SaveModel 整行 Save 把 active 清零的旧 bug：改 Select(...).Updates
  只覆盖可编辑列，改 key 不再顺手取消模型激活。
- secrets 单测：往返/空串/随机 nonce/错密钥 fail-closed/历史明文透传。
- production_readiness.md 2.1 更新为「已落地」。

验证：DB 列由明文 sk-…(35) → 密文 enc:1:…(90)；dispatcher 从密文广播解密后
model config set；真实任务 √256→16、12×12→144 打通 DeepSeek（非降级桩）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 10:36:34 +08:00
Blizzard 5cfed55e91 fix(dispatcher,mcp-go): 配置拉取改为后台重试，根治启动竞态 
此前 dispatcher(chat)/mcp-go(embedding) 启动时一次性请求控制面配置，3s 扑空即
降级，且只能干等热更新广播——若消费方早于 gateway 启动，会全程降级（LLM 跑桩、
RAG 无向量），必须手动重启才恢复。

改为：先订阅热更新，再后台 RequestConfigWithRetry（重试至拿到配置，容忍 gateway
晚启）。新增 shared/bus.RequestConfigWithRetry + dispatcher Subscriber 包装。

验收：故意先起 dispatcher/mcp-go、后起 gateway，二者自动重试拿到 chat/embedding
配置，无需手动重启；make test-go 全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-24 09:57:06 +08:00
Blizzard f238ae1455 feat(dispatcher): 编排式多智能体接力 —— 上游 agent 产出沿图传给下游 
让画布上串联的多个 agent 真正协作完成一件事（如 检索→撰写→审查 出报告），
而非各自对原 query 重答：
- board 增 agentOut（各上游 agent 产出按序）；RunCtx 增 Upstream，buildMessages
  注入"前序协作 agent 的产出，请在此基础上继续"。
- runAgent / runReactAgent / runComposeConversation 三条路径统一：注入 b.agentOut
  作上下文，产出经 recordAgentOutput 入黑板（append agentOut + 设为当前成稿 answer，
  多 agent 时最后一个 agent 产出即最终成品）。

不需要 eino multiagent 组件——编排式协作由现有图引擎 + 上下文传递实现。
测试 TestAgentCollaborationPassesOutput：下游 agent 确见上游产出、成稿=下游产出；
make test-go 全绿。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 15:42:58 +08:00
Blizzard 79437e1c1c feat(mcp-py,dispatcher): 自主 agent 工具动态发现覆盖 mcp-py 
把动态工具发现从 mcp-go 扩到两台 MCP：
- mcp-py：TOOL_META 改成与 mcp-go 同形（cn/desc/agent/params/inject），
  list_tools 上报这些；run_code 标 agent 可用（params: code）→ 自主 agent
  可执行 Python 代码做计算/数据处理。
- dispatcher：agentTools 拆出 discoverTools(subject)，分别探 mcp-go / mcp-py
  的 list_tools 并合并；某台 MCP 离线即跳过（降级，不阻断）。

验收：mcp-py 未启动时自主 agent 仍正常（探测秒跳过），一次自主调用了
history_get + memory_get 两个动态发现的 go 工具（注入 session_id/user_id）；
go 全绿、mcp-py py_compile 通过。mcp-py 起着时 run_code 即自动入 agent 菜单。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 14:34:07 +08:00