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

60 Commits

Author SHA1 Message Date
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 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 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 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 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 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 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 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 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 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 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
Blizzard 7388f2741d feat(mcp-go,dispatcher): 自主 agent 工具集动态化 —— list_tools 自描述 + 动态发现 
杜绝硬编码：自主 agent 的工具菜单不再写死在 dispatcher，而是从 mcp-go
注册表（单一事实源）动态发现。加工具只改 mcp-go 一处，dispatcher 零改动。

- mcp-go：toolDef 增 agent/agentName/params/inject 元信息（paramSpec 声明
  模型可填参数；inject 声明服务端注入、不暴露给模型的参数如 user_id）；
  list_tools 上报这些。当前标 agent 的 4 个：wiki_search / recall_user_memory
  / remember_user_fact / history_get。
- dispatcher：agentTools() 改为调 list_tools → 取 agent_exposed → 按上报的
  params 建 schema.ToolInfo → 生成 mcpTool；inject 参数（user_id/session_id/
  kb/task_id）运行时绑定。删除硬编码的 2 个工具。

验收：实测自主 agent 调用新暴露的 remember_user_fact（memory_upsert）成功——
参数由模型按 schema 自生成（key/value），user_id 服务端注入（map 带 task_id
佐证）；make test-go 全绿；管理端状态面板兼容（忽略多余 JSON 字段）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 14:29:20 +08:00
Blizzard 45ad852806 feat(dispatcher): Eino 组件化补完 —— 检索 Retriever + 提示词 ChatTemplate 
补完终态架构剩余两层（A 收尾）：
- 检索：新增 ragRetriever（eino_components.go）实现 components/retriever.Retriever，
  包 mcp-go kb_search（NATS）、命中转 *schema.Document；retrieve() 改经组件，
  retriever 节点与报告分章检索统一走它。
- 提示词：buildMessages 改用 prompt.FromMessages + MessagesPlaceholder
  （FString 仅解析模板串、值原样注入 → JSON 花括号安全），产出消息序列与旧手拼等价。
- 工具：mcpTool 即 InvokableTool（Phase B），用于模型自主调用；静态 tool 节点
  确定性裸调用 by design。

测试：buildMessages 形状（含花括号）+ ragRetriever 文档解析单测；make test-go 全绿。

性能：compose 每任务编译实测 ~13µs（基准），相对 LLM 秒级可忽略 → 编译图缓存
判为 premature optimization 暂不做；并行效率已由 Phase C DAG 调度拿到。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 11:20:52 +08:00
Blizzard 2e927eca0a feat(dispatcher): Eino 采纳 Phase C 完成 —— 全图 DSL→compose.Graph 编译器 
把整张 DSL 图编译为 Eino compose.Graph 执行（编排归一）：
- compose_compiler.go：每节点=Lambda，节点体复用 execDSLNode（全节点类型）；
  黑板进 compose 本地状态（WithGenLocalState + ProcessState）；branch 走
  AddBranch + 状态感知条件（复用 branchNode）；边载荷 flowSignal（注册 no-op
  合并支持 fan-in，真实数据全走黑板）。
- WithNodeTriggerMode(AllPredecessor) DAG 模式：无依赖节点并行调度（效率）。
- Handle→executeGraph 按 EINO_COMPOSE 开关选 compose/graph.go；compose 编译
  失败自动降级回 graph.go（安全网）。默认关，graph.go 仍权威。

等价回归：线性图 + 分支图经解释器与 compose 两路径产出逐字一致（单测）；
live 多节点分支图 compose 路径 2800 字答复 eval 1.00、FSM done、0 幽灵；
make test-go 全绿。

过渡期 soak 后翻默认到 compose、退役 graph.go。性能后续：编译图按 DSL-hash 缓存。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 11:02:32 +08:00
Blizzard 2ee16d1f99 feat(dispatcher): Eino 采纳 Phase C —— 对话主流程跑 compose.Graph + callbacks 归一 
按"并存 + 等价回归"策略，对话主流程可跑在 Eino compose.Graph 上：
- compose_graph.go：runConversation 按 EINO_COMPOSE 灰度开关分流；
  runComposeConversation 建图 START→ChatModel→END，Compile→Stream 回流 token；
  模型未就绪/编译失败降级回 runAgent。默认关，graph.go 仍是默认且权威。
- compose_callbacks.go：composeTracer 用 utils/callbacks 把 ChatModel/Tool 的
  start/end/error 桥到 ExecEvent（可观测归一，不再各处手写 emit）。
- LLM 接口 + Pool 增 ChatModel()；fakeLLM 加 cm 字段 + stub Eino 模型。
- 测试：compose 图编译运行 / compose 对话流式 / 开关关→走 runAgent。

顺带修真 bug：SubjectTaskStatus 原 sundynix.tasks.status 落在任务流通配
sundynix.tasks.> 内 → 状态事件被当成"幽灵任务"自我放大（实测污染 2300+ 条）。
挪到 sundynix.status.task + dispatcher 加空任务护栏。

验收：make test-go 全绿；live compose 路径 54 字答复 eval 1.00、默认路径
eval 1.00、幽灵任务 0 复发。剩余 branch/map/render 等节点逐步迁移后 graph.go 退役。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 10:42:50 +08:00
Blizzard 71102d2424 feat(dispatcher,gateway): Eino 采纳 Phase D —— 任务生命周期状态机 
submitted → running → done / failed / timeout 显式状态机，根治"卡运行中
看不出来"（此前 Task.Status 只写死 submitted、从不流转）。

- contract：新增 SubjectTaskStatus 主题 + TaskStatusEvent + 状态常量
- shared/bus：PublishTaskStatus / SubscribeTaskStatus（core NATS pub-sub）
- dispatcher：StatusSink 接口 + Orchestrator.Handle 状态钩子——进入执行
  →running、收尾 finishStatus→done/failed、整体超时上限 taskExecTimeout
  =3min→timeout；经 sub 回写
- gateway：SubscribeTaskStatus 落 PG（Task 增 Detail 字段，AutoMigrate）；
  新增 GET /api/v1/tasks/:id 供 UI 轮询状态

验收：实测 submitted→running→done 流转 + PG 持久化 + 端点查询闭环；
make test-go 全绿。HITL 中断恢复 / 多智能体仍按场景待做。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-23 09:48:44 +08:00
Blizzard fa2e2ebeeb feat(dispatcher): Eino 采纳 Phase B —— ReAct 智能体 + MCP 工具自主调用 
agent 节点带 autonomous:true 时走 ReAct（flow/agent/react），模型在
推理-工具循环里自行决定调哪些 MCP 工具，而非只跑画死的工具节点。

- 新增 eino/react_agent.go：mcpTool 把 MCP 工具（NATS）适配成
  components/tool.InvokableTool；agentTools 暴露 wiki_search +
  recall_user_memory（context 参数 user_id 服务端注入，不暴露给模型）；
  runReactAgent 流式回流答复，工具调用经适配器落 ExecEvent 轨迹。
- LLM 接口 + *llm.Pool 增 ToolCallingModel()（openai 组件实现
  model.ToolCallingChatModel）；fakeLLM 同步桩（返回 nil → 降级普通对话）。
- graph.go：agent 节点按 autonomous 开关分流 ReAct / 普通；自主 agent
  不预注入画像（让其经 recall_user_memory 工具按需自取）。

关键修复：默认 StreamToolCallChecker 只看首个流片段，deepseek 常先吐
文本再给 tool call 致漏判 → 改 streamHasToolCall 扫整段流（命中率 ~0→7/7）。

验收：自主工具调用 7/7 命中，args={} 证明注入生效，完整闭环跑通；
make test-go 全绿。已知 eval 看不到工具结果会误判 agent（Phase C 修）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-22 17:35:19 +08:00
Blizzard 1674252d81 feat(memory): P1 长期记忆升级 —— 异步攒批 Consolidate + 软删 + importance/last_seen 
把"逐轮盲写抽取"升级为 Mem0 式对账（方案见 memory_industry_analysis.md 落地节）：

mcp-go：
- Profile 加 Importance(1~10, poignancy) + LastSeenAt（为 Generative Agents 读路径
  Score=w1·Relevance+w2·Recency+w3·Importance 铺路）。
- Upsert 收 importance + 每次置 last_seen（印证）；新增 Delete（软删，BaseModel.DeletedAt
  已具备，失效不物删可审计）+ Touch；memory_upsert 透传 importance、新增 memory_delete 工具。

dispatcher：
- extractMemory → consolidateMemory：一次 LLM 调用同时做 抽取+对账，输出
  [{op:ADD|UPDATE|DELETE|NOOP,key,value,importance}]；ADD/UPDATE→upsert、DELETE→软删；
  sanitizeOps 防幻删(DELETE 须命中已有)/夹 importance[1,10]/同key保末个/丢 NOOP。
- 攒批：每 3 轮（per-session 计数）才 consolidate 一次，省成本，对齐 ChatGPT 周期整理。
  从根上解决 exact-key 盲写的记忆腐烂。

验证：parseOps/sanitizeOps/parseProfile 纯逻辑单测；store 集成测试(真 PG)覆盖
importance/last_seen 写入 + 软删(live 0 / 物理 1)；dispatcher -race 全过。
（注：完整多轮 LLM consolidate 未做实跑，属构造性验证 + 沿用已证 pool.Chat 模式。）

P2 待做：读路径按 Score(Recency+Importance) 排序/衰减/截断 + 桌面端记忆面板。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-22 14:27:16 +08:00
Blizzard 8f619c2a62 test(dispatcher): 引擎主链路集成测试（pool 抽接口 + 假替身端到端） 
把 Orchestrator.pool 从 *llm.Pool 抽成 LLM 接口（Ready/ChatStream/StreamText/Chat），
*llm.Pool 天然满足、main 不变；从而可注入假模型做端到端测试，不依赖网络/Docker/LLM。

新增 integration_test.go（假 LLM/工具/sink/exec 替身）：
- runGraph 分支路由：true/false 边标签精确选路（true 边故意列后）。
- runGraph 工具→agent：工具产出注入 agent 上下文。
- runGraph map fan-out：拆项 → 各章并行撰写 → 多章成稿。
- runGraph 输出护栏：流式 token 中疑似密钥被脱敏。
- handleReport：规划 → 分章撰写 → report_store 存源 → 流含标题/各章 + CompleteStream。

全部 go test -race 通过（修了测试替身 fakeExec 的并发追加竞态；生产 ExecSink 安全）。
至此引擎与报告主链路从"仅手动验证"升级为自动化端到端覆盖。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-19 10:51:39 +08:00
Blizzard 9c19bb44f1 feat(dispatcher): 长期偏好记忆抽取（补全记忆闭环） 
memorize 的 TODO 落地：写回阶段（异步、离热路径）从本轮对话用 LLM 抽取用户
长期稳定偏好 → 与已有画像去重 → memory_upsert 登记。

- extractMemory：模型/工具不可用或输入过短则跳过；复用 llmCtx 超时；
  抽取 prompt 只取长期偏好、忽略一次性信息。
- 纯逻辑（可单测）：parsePrefs（容忍 json 代码围栏）、parseProfile（把 memory_get
  渲染的"- 维度：值"解析回 map，兼容全/半角冒号）、filterNewPrefs（新增/变更才留，
  同批同 key 去重）。
- 单测覆盖三者；LLM 抽取调用沿用已验证的 pool.Chat 模式。

至此记忆闭环：召回(memory_get) + 历史写回 + 偏好自动抽取 全通。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-18 12:47:49 +08:00
Blizzard b7360439ab feat(dispatcher): 输出护栏 —— 发射层脱敏疑似密钥/令牌 
补齐 Harness 输出侧：harness.RedactSecrets 识别并脱敏 sk-/AKIA/JWT/Bearer 等
疑似密钥令牌（纯逻辑 + 单测）。runAgent 在每个 token 分片发射前调用（流式无法回收
已发，故逐片脱敏），脱敏会累计进 b.answer（写回历史也是脱敏版）；有命中则在
运行·观测打一条'已脱敏 N 处'轨迹。

注：跨分片的密钥可能漏（流式现实），逐片为最佳努力；生产可加滑窗缓冲增强。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-18 11:52:53 +08:00
Blizzard 718140239d fix(dispatcher): 报告 LLM 调用加单次超时上限，治偶发卡死 
之前 writeSection/planOutline/planItems 的 pool.Chat 用无 deadline 的 ctx，个别
DeepSeek 流连接挂住会一直占着（曾累积把整篇卡死）。给每次 LLM 调用套 60s 超时
(llmCtx)：超时即 cancel → 底层 http 请求中断 → Chat 返回错误 → 走兜底，不无限等。
happy path(约18s 完成)不变，仅加上限。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-18 11:47:46 +08:00
Blizzard 3ae009db38 feat(dispatcher): LLM 自动化评测落地（规则 + LLM-as-judge）+ 单测 
Evaluator 此前是空桩（Score 恒返 0）且未接线。落地为真实自动化评测并接入：

- 规则评测（always-on，纯函数）：空输出/过短/疑似拒答/重复啰嗦各扣分 → 0–1 分 + 标签。
- LLM-as-judge（模型就绪时）：让模型对(输入,输出)按相关性/准确性/完整性 1–5 打分给理由，
  归一化后与规则分加权（0.4 规则 + 0.6 LLM）；解析失败/无模型则回退纯规则分。
- 经注入 ready/chat 解耦 LLM 后端，便于单测（无需真实模型）。
- 接线：orchestrator 在答复产出后 `go o.evaluate(...)` 异步评分并记日志（off 热路径，
  不影响响应与流式）；main.go 用 pool.Ready/pool.Chat 构造 Evaluator。

测试：规则各情形（正常/空/过短/拒答/重复）、纯规则模式、LLM-judge（带围栏 JSON 解析 +
归一化 + 加权）、坏 JSON 回退 —— 全过。

至此 Harness 三件：熔断降级 ✅ · 输入护栏 ✅ · LLM 自动化评测 ✅（输出护栏待 emit 层）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 15:32:02 +08:00
Blizzard 31bf3e5907 feat(dispatcher): 熔断降级真三态状态机（弃用空桩）+ 单测 
CircuitBreaker 此前是空桩（Allow 恒 true、Report 空操作），dispatcher 调 LLM/工具
无任何失败保护——今天就撞上 DeepSeek 流连接累积把报告卡死。改为真实三态熔断：

- Closed：正常放行；连续失败达阈值(默认5) → Open。
- Open：快速拒绝；冷却(默认10s)到点 → HalfOpen 放行少量探测(默认1)。
- HalfOpen：探测成功 → Closed 恢复；探测失败 → 重新 Open。
- sync.Mutex 并发安全（多任务 goroutine 共享）；时钟可注入便于确定性测试。

orchestrator.Handle：熔断开启时不再静默丢弃任务，改为回流"服务繁忙"提示 +
CompleteStream 收尾，让客户端解阻不挂死。

测试（含 -race）：达阈值断开、成功清零、半开恢复、探测失败重断、并发安全 —— 全过。
PROGRESS.md 勾掉熔断项。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 15:02:45 +08:00
Blizzard 9b0520e020 test(backend): 编排引擎/DSL/docx/报告导出 首批 Go 单测（19 用例，纯逻辑无依赖） 
补齐核心后端逻辑的自动化测试，全部纯函数级、不依赖 docker/NATS/LLM，毫秒级跑完，
把"手动起全栈 curl 验证"变成 `go test`：

- dispatcher/internal/eino (graph_test.go)
  evalCondition(各运算符+refs/tools/answer/profile 关键字+兜底)、resolveOperand、
  aggregate(拼接/去重合并/默认/全空)、branchNode(真假边标签精确选路 + 无标签退回边序 +
  单边剪枝)、cstr/cbool/countLines/labelOf/targetsOf。
- dispatcher/internal/dsl (compile_test.go)
  Topo(线性序 + 有环不丢节点)、Compile(system/query/tools 抽取 + 无输入兜底 + 空图用原文)、
  ToolBinding(tool/retriever/非工具)、Parse(合法/非法)。
- mcp-go/internal/office (unioffice_test.go)
  RenderReport 产物为合法 docx(zip 三部件 + 标题/章节文本 + XML 转义)、escapeXML。
- mcp-go/internal/mcp (report_test.go)
  reportMarkdown(标题+多章 / 无标题)。
- gateway/internal/dsl (parser_test.go)
  ParseAndAssemble(task_ 前缀 + Graph 透传 + Meta 初始化 + 空/非法报错)。

`go test ./...` 各模块全绿。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 14:13:13 +08:00
Blizzard 1dd6b0cce3 feat(report): 生成只出 Markdown 预览，导出时再渲染 Word/PDF/Markdown 
把"渲染"从生成阶段解耦到导出阶段（导出时再处理）：
- 生成阶段：报告正文按 Markdown 流式预览（前端 <Markdown> 已渲染），
  dispatcher 不再 eager 渲染 docx，改为经 mcp-go report_store 落盘报告源(title+sections JSON)。
- 导出阶段（按需现渲染）：
  - GET /reports/:id/export?format=docx → mcp-go report_export 读源渲染 .docx；
  - ?format=md → 返回 Markdown 文本；
  - PDF → 前端把已渲染的 Markdown 送进打印视图出 PDF（CJK 零字体依赖）。
- 旧 /reports/:id/download 兼容保留（默认 docx）。

改动：
- contract: ReportSourcePath(id) = <id>.json。
- mcp-go: 新增 report_store / report_export 工具（report_render 保留给 Studio render 节点）。
- dispatcher: handleReport 末尾 renderReport → storeReport。
- gateway: DownloadReport → ExportReport（经 NATS 调 report_export）。
- 前端: ReportView 单个「Word」→「导出」组 Word/PDF/Markdown；
  desktop.printReportHtml 客户端打印；api.reportExportUrl。

实测（docker 全栈 + mcp-go + gateway + dispatcher + DeepSeek 真跑）：
- 真实生成「绿茶的功效」18s 完成，report_store 落源(5章, 6280B) ✓
- export md 返回正确 Markdown(# 标题/## 小节/正文) ✓
- export docx 为合法「Microsoft Word 2007+」(含 document.xml/Content_Types) ✓
- 前端 tsc 干净 + 生产构建通过 ✓
（注：发现并修复一处环境问题——mcp-go 启动时若 Milvus 未起会阻塞在
 rag 初始化、永不订阅工具，导致所有 mcp-go 工具"no responders"；起全栈后正常。
 报告生成在累积大量未完成 DeepSeek 流连接时会偶发卡顿，干净进程下正常。
 前端导出按钮的实时点击因 React 受控输入自动化限制未在预览中走通，非代码缺陷。）

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 14:04:06 +08:00
Blizzard 1bd187874d feat(orchestration): Phase2 —— map 真并行 fan-out + branch 真/假边标签精确选路 
Phase1 让引擎按图执行后，本轮补上两块：

1) map 并行 fan-out（dispatcher）
   - map 节点：planItems 把主题拆成 3–6 子项 → 复用 report 的 writeSections
     有界并发(4)逐项撰写 → 结构化 sections 存黑板 + 拼进 answer + 流式呈现。
   - 检索节点记下 owner 作用域库名(b.kb)，供 map 各项并行检索复用。
   - render 节点优先用 map 产出的多章 sections 渲染，否则整段成稿当单章。

2) branch 真/假边标签（前端 + DSL + dispatcher）
   - TypedNode：分支节点渲染两个出口手柄 真(绿)/假(红)，连线各带 sourceHandle。
   - exportDsl / TaskDsl：边导出携带 sourceHandle。
   - dispatcher dsl.Edge 增 SourceHandle；branchNode 优先按 true/false 标签精确
     选路，无标签的旧图退回"出边顺序"约定，向后兼容。

实测（gateway+dispatcher+DeepSeek 真跑）：
- map：input→map→render，DeepSeek 拆出 5 章并行撰写(347–512字)，trace 见
  section:0..4 并发 + 有界并发(section3 等槽)；render 因 mcp-go 不在优雅降级 ✓
- branch 标签：把 true 边故意列第二位，条件真仍走 true 标签的分支A、假走分支B，
  证明按标签而非边序选路 ✓
- 桌面端：分支节点正确渲染 真/假 两手柄，无 console 报错 ✓

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 14:01:51 +08:00
Blizzard fd145b5852 feat(dispatcher): 编排引擎按图执行（拓扑+连线+分支剪枝），弃用线性拍平 
旧 compileFlow 把 DSL 图拍平成线性 init→tool…→prompt→model，连线/分支/
memory/aggregate/render 节点全被忽略——"画得出、跑不全"。改为纯 Go 图解释器
(graph.go)，按真实拓扑与连线执行，每种节点 kind 有真实行为：

- input     注入用户输入
- memory    按勾选注入画像/历史（无 memory 节点则沿用默认注入，不回归）
- retriever kb 按 owner 作用域 → kb_search 累计参考资料
- tool      调 MCP 工具，产出进黑板，失败降级不阻断
- agent     据黑板拼消息 → pool 流式回流 token，累计成稿
- aggregate 按策略合并参考资料（拼接/去重合并/摘要）
- render    把成稿经 report_render 渲染 docx
- branch    求值条件 + active-set 剪枝下游（边序约定 [true,false]）
- map       占位（fan-out 暂串行，路线图 Phase 2）
- output    终端

全程逐节点点亮"运行·观测"，token 流与记忆写回保持不变；报告 intent 走原专用
编排不动。compile.go 精简为只留 RunCtx/buildMessages/previewArgs。

实测（gateway+dispatcher+DeepSeek 实跑）：
- input→agent→output 真实流式答复 ✓
- branch 条件 2>1 走分支A、1>2 走分支B（下游真被剪枝）✓
- memory 节点按勾选注入；exec 事件按新节点名(agent:a 等)回流 ✓
- 桌面端 Studio 载示例→运行：4节点3连线校验通过，检索节点 mcp-go 不在时
  优雅降级，agent 据空资料如实作答，输出/轨迹面板正常 ✓

路线图 Phase 2：map 真并行 fan-out + aggregate reduce 接上 report 那套；
前端给 branch 的边打 true/false 标签，使条件分支完全精确（当前靠出边顺序约定）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 11:42:29 +08:00