| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
test: add vllm metric fixtures | 19 天前 | |
feat: implement AB scoring v2.1 algorithm and update documentation | 1 个月前 | |
feat: add remaining test files - Add ab-scoring, ab-significance tests - Add agent registration and trace tests - Add skill attribution and generation tests Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
删除任务输入和输出的提取处理步骤 | 4 天前 | |
严格校验数据集字段 key，避免重复或非法字段被静默丢弃 | 4 天前 | |
feat: 优化 AgentDebug 结构化查询流程 | 4 天前 | |
feat: 优化 AgentDebug 结构化查询流程 | 4 天前 | |
fix: 兼容展示旧版 AgentDebug 报告 | 3 天前 | |
feat: 优化 AgentDebug 结构化查询流程 | 4 天前 | |
feat(agent-debug): 轨迹诊断器——检出单点诊断漏掉的死循环 - 确定性轨迹检测器(trajectory-detector)：在完整 turns 上按"复发 vs 首见" 密度定位循环/无进展区段，零 LLM 成本 - LLM 富化(trajectory-enricher)：一次调用基于真实证据写机制/故障链/建议，失败降级回确定性文案 - 结果折叠进「关键发现」列表，默认只展示总结 - 文档：AgentDebug 诊断原理与「检测不到循环」根因分析 + 采纳方案 - 单测覆盖检测器 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 24 天前 | |
修复agent评测自动观测功能 Co-authored-by: mintuyang<yangmintu@huawei.com> | 1 个月前 | |
fix: 修复 Claude trace 输出回填与子代理建树 Co-authored-by: ljnkirito<16688211838@163.com> | 1 个月前 | |
feat(ingest): 解析 Claude Code/Hermes/Jiuwen 已采到未解析的 LLM 元数据到 trace 这些数据原本已被采集进原始遥测，只是 adapter 没解析。统一下游契约： adapter 产出 role:'system' 交互 / assistant 交互带 parts[type=reasoning] → buildAgentCallTree 收进节点 systemPrompts / 前端 extractReasoningText 渲染 → System Prompt 卡片 + "Thought for Ns" 折叠块。 系统提示词（三框架）： - Claude Code: 从 api_request_body 顶层 body.system（string / text-block 数组）按 promptKey 收集，appendAssistantFromApiResponse 按 scope（root / 各 Agent 子会话）去重 emit。 - Hermes: 从 api span 的 llm.input_messages / input.value 解析 role=system， makeSystemInteraction 按 owner session 去重 emit。 - Jiuwen: 从 gen_ai.prompt.{n}（role=system）取出，leadInteractions 在 transformSingle/Team/Task 头部插入，归属 root agent / leader / coordinator。 思考过程（仅 Claude Code，同属已采到未解析）： - reasoningPartsFromContent 从响应 content_blocks 挑出 type:'thinking' 块 （redacted_thinking 跳过），仅在有 thinking 时给 assistant 交互附加 parts:[{type:'reasoning', text}]；可见回答仍走 content。 Hermes / Jiuwen 的思考过程属真·缺数据（上游未导出 reasoning 正文），暂不动， 详见计划文档阶段二/三。 每个项补专项测试；全量 391 通过（4 个失败为既有、与本次无关）。 同步更新 docs/plans/2026-06-25-llm-system-prompt-thinking-capture.md。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 21 天前 | |
fix: 修复 OpenCode 和 Jiuwen 安装脚本 | 18 天前 | |
修复 jiuwenswarm 执行状态一直显示「执行中」 trace 完成判定依赖 Session.endTime：jiuwenswarm 既不在入库写 trace_completed_at，也不在读取侧的静默窗口推断里，endTime 永不写入 → 链路追踪列表/详情永久停在「执行中」。对齐 !150 的两路完成信号： - 显式信号（team / fan-out）：聚合时从 team.<name> root span（agent-core 把它排除在强制 span cleanup 外，整轮跑完才 end/导出）推断 trace_completed_at，经 saveExecutionRecord 既有通用路径落 Session.endTime。 - 静默窗口（single-agent run_agent / ReAct，无 root span）：把 claudecode 的 quiet-window 推断泛化到 jiuwenswarm（QUIET_WINDOW_INFERRED_FRAMEWORKS）， 覆盖列表（fields=light 无 final_result）与详情（skipAutoEvalReady）两条路径。 附 jiuwen 生命周期单测（两路机制）；顺带补 TimestampCarrier 缺 role/content 的类型错误（!150 测试遗留）。 | 1 个月前 | |
关键观点提取从评估阶段转移到数据集存储阶段，加速评估 Co-authored-by: mintuyang<yangmintu@huawei.com> | 1 个月前 | |
refactor(debug): token 用量改用与 Execution.tokens 同源的派生链路（去掉自起的流式统计） 承上一版评审意见——不另起平行统计。撤掉上一版在 opencode-client.chat() 里新增的 逐 message 流式 token 采集 + sumOpencodeTokenUsages helper，改为在 runGeneralAgentWithClient 的 chat() 之后**复用既有真值链路**： client.listMessages → normalizeEvaluatorExecutionInteractions → deriveOpencodeExecutionFields，取 derived.tokens 等写入 stats.totalTokens + 明细。 好处：单一真值源，与落库 Execution.tokens 字节级同口径，消除上一版「裸 info.tokens 经 usageTotals 重算」与「含 reasoning 的 usageTotalsFromTokens」之间的细微差。 - opencode-client.ts / opencode-derived-metrics.ts 回退到 upstream/master （移除流式采集与 sumOpencodeTokenUsages）。 - runner.ts 改为同源派生；normalize 牵连 prisma，沿用 recordTraceAs 的动态 import。 - test/debug-token-usage.test.ts 改用 deriveOpencodeExecutionFields 端到端覆盖。 - RunGeneralAgentResult.stats 的 totalTokens/tokens、extractDebugJobTokenUsage 嵌套 cache 加固（上一版已含、未改动）保留。 tsc --noEmit 通过；改动文件不新增 lint 错误；token 测试 8/8 过。 | 1 个月前 | |
feat: 完善结果评测优化点落库映射 Co-authored-by: mintuyang<yangmintu@huawei.com> | 1 个月前 | |
fix(startup): 启动时确保内置示例日志存在(不在才补, 存在即跳过) 配合上一条 ~/ 展开: 内置 case query 指向 ~/.agent-insight/example/messages, 展开成绝对 路径后那个文件得真的存在。seed.ts 只写了 skill 文件、没写示例日志, 且示例日志原本只在 客户端 curl|bash 时下到客户端 HOME —— 换台干净服务器/重装后, 服务器侧那个路径没文件, agent 一读就 "No such file" 直接结束。 启动钩子(instrumentation-node)里加一次 ensureExampleMessagesFile(): - 语义 A: 存在即跳过, 绝不覆盖(用户/旧版本那份原样保留); 仅缺失时从 public/example/messages 复制到 <home>/.agent-insight/example/messages。全平台共用一份(静态示例)。 - 幂等: 每次重启只是一次 existsSync, 已有就不写。非致命(try/catch 包住, 不阻塞启动)。 测试: ensure-example-file 单测 4/4(copied/exists不覆盖/幂等/源缺失skipped); 全量 239 pass / 0 fail; tsc 0。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix: DATABASE_URL 统一默认到 ~/.agent-insight/data,不再需要手动传 平台本就想"默认从 ~/.agent-insight/data 读库",但 resolveDefaultDatabaseUrl 只在 DATABASE_URL 恰好等于模板相对路径时才解析;实际 .env 里写的是 file:~/...(带 ~),dotenv/node 不展开 ~ (只有 start.sh 的 bash source 会),于是出现"server 正常、手动 node 脚本写错库/报 DATABASE_URL not found"的坑。 修复 resolveDefaultDatabaseUrl 统一归一: 1) 未设置/空 → ~/.agent-insight/data/witty_insight.db(旧实现返回 undefined 会让 Prisma 报错) 2) 模板默认相对路径 → home 绝对路径 3) file:~/… → 展开 ~ 为家目录(server 与手动脚本行为一致) 4) 其它(绝对路径/非 file:)→ 原样 并移除 backfill 脚本里"DATABASE_URL 未设置就回落 <cwd>/data"的兜底——它在 loadAgentInsightEnv 之前 就把库设歪了,正是上次回填写错库的原因。现在 backfill 无需任何前缀即可命中正确库。 效果:server / 手动脚本 / 无 DATABASE_URL 都自动落到 ~/.agent-insight/data;.env 里那行 DATABASE_URL 可删可留(留着的 ~ 也会被正确展开)。新增 test/env-database-url.test.ts。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
数据库转移到根目录相应位置 | 1 个月前 | |
修复direct_llm,hermes执行状态 | 1 个月前 | |
A/B测试优化 | 1 个月前 | |
feat: add infra endpoint persistence | 19 天前 | |
feat: 支持 Langfuse LangGraph 后端接入 | 19 天前 | |
feat: add more test files and tools - Add agent trace dedupe and otel ingest tests - Add execution skill version guard test - Add opencode otel schema test - Add tools directory Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
fix(exec): 执行前把 query 里的 ~/ 展开成绝对 HOME, 根治内置 case "找不到文件直接结束" 内置「messages 日志分析」数据集的 case query 里写的是 ~/.agent-insight/example/messages。 ~ 是 shell 语法糖, 只有交互式 shell / 未加引号的 bash 才展开; agent 一旦用文件读取工具、 给路径加引号、或用 Node/Python 读, 拿到字面量 ~ 就 "No such file" 直接结束 —— 取决于 agent 当时用哪种工具, 所以时好时坏。 在执行链路唯一入口 runGeneralAgent 里, query 进 agent 前先 expandHomePathsInText(): - 只展开边界处紧跟斜杠的 ~/(行首/空白/冒号(含全角)/引号/括号/等号 之后), 不动 a~b、~100、孤立 ~。 - 展开目标用平台进程 HOME(os.homedir()=/root, 内置示例文件就在那), 而非 agent 可能被 isolateHome 改掉的 HOME; 同机同文件系统, 绝对路径在 shared / ephemeral 两种模式都能读到。 - 数据集仍存 ~(可移植), 仅运行时解析。 测试: expand-home 单测 7/7; tsc 0。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(eval): 评分喂"核心输出"而非最后一条 assistant 消息（修假 0 分） 实测发现评测假 0 的一大根因：多轮 agent 的分析写在前几轮，最后一条 assistant 消息常是空或"分析完毕，见上"。原 client.chat 的 text 只取最后一条消息 (textAcc.get(assistantMsgId))，judge 拿到的就是那句废话/空串 → 评 0。 （实测 c7 同一 skill 因此 [1,1,0,1] 摇摆；最后一条消息长度=0。） 修复（既不只取最后一条、也不简单拼接全部——拼接会把过程旁白喂给 judge）： - 新增 extractCoreOutput：以最长的 assistant 消息为主报告 + 同等量级(≥50%)兄弟消息， 滤掉短旁白/"见上"指针。6 例单测。 - client.chat 返回新增 transcriptText（核心输出）；runner 暴露为 fullOutput。 - 评测/打分应消费 fullOutput 而非 output（最后一条，仅交互展示用）。 验证：c7 假 0 → 1.00 恢复；c9 仍 0（真实失败，非提取问题，正确不被抬升）。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 1 个月前 | |
fix(filters): latency 单位改秒 + 否定操作符包含 NULL 行(对抗测试) 对抗测试(真实 API vs DB ground truth ~25 例)发现并修: - latency:DB 存秒(claude durationMs/1000、jiuwen ns/1e9),原标 ms 致裸下推匹配错 → 单位改秒(unit:'s') - 否定丢 NULL:does not contain / none of 用 NOT/notIn 会排除 NULL 行;nullable 列结果改 OR IS NULL (subagentType 全 NULL 时 none-of 从 0 → 60) - 列注册表加 description(langfuse FIELDS 右侧灰字);分数列标注 0–1;agents 标 nullable - 记录局限:Prisma SQLite contains 不转义 LIKE 通配符 _/%(过匹配,非漏匹配) - 16 单测全过;设计文档 §8 记录对抗测试结论 | 19 天前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
refactor: 统一框架适配器注册表处理 Skill 抽取和 Claude 归一化 Co-authored-by: ljnkirito<16688211838@163.com> | 1 个月前 | |
fix: 优化标签与版本分析交互 | 12 天前 | |
fix(grayscale): 崩溃后解卡但不自动重评, 改由用户点「重评」恢复 问题: 服务崩溃/重启后, 打开任务页会"自己重评起来", 还把看着已有分数的 run 又评一遍 —— 来自 GET handler 里的 gray_recover_ 自动补评逻辑。 按用户决策(解卡但不自动重评)调整: - 移除 GET handler 中崩溃残骸的自动补评(gray_recover_)整块, 及随之失效的 getAutoEvaluationBacklogCaseIds。打开页面不再自动跑任何评测。 - reconcileStaleGrayscaleRun 改为把"被打断的评测"解卡成「执行完成 + 评测失败 (中断)」: status='fail' 但 failureType 留空(关键: 有值会被前端当执行失败显示 「重跑」)、保留 sessionId、把进行中的评估器标 failed 并附可读原因。前端据此显示 「重评」(仅重评、复用 session), 等用户点。 - 新增"误标恢复": 若 run 其实早已评完(评估器全 done + 有分)只是被崩溃误标, 直接恢复成 pass 并保留分数, 连重评都不用 —— 避免有分却又被退回重评。 - 正常"执行→自动评测"(执行完成后的 autoEval)不受影响。 测试: reconcile 单测 8/8; 全量 228 pass / 0 fail / 1 skipped; tsc 0。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(debug): 真实回收 agent token 用量到 chat stats，修 tokenUsage 恒为 0 根因不在 ephemeralServer 分支，而更底层：opencode-client.chat() 返回的 stats 从来只有 eventCount/toolCallCount 等计数，根本没带 token——所以 extractDebugJobTokenUsage(result.stats) 在**任何**路径下都恒返回 0 （DebugJobResult.tokenUsage、灰度 run.tokenUsage 同理失真）。每条 assistant message 的真实 token 走 message.updated 的 info.tokens 流过，但被丢弃了。 - chat() 按 messageID 去重收集每条 assistant/subagent message 的 info.tokens， 收尾用新 helper sumOpencodeTokenUsages 按 Execution.tokens 同口径 （复用 deriveOpencodeExecutionFields 的 usageTotals）合计，写入 stats.totalTokens + stats.tokens 明细；并加 sendPrompt 同步返回兜底。 - RunGeneralAgentResult.stats 类型同步补 totalTokens/tokens，全链路透传。 - extractDebugJobTokenUsage 加固：明细对象的 cache 兼容嵌套 { read, write } （旧实现把嵌套 cache 当 0 漏算）；顶层 totalTokens 优先，行为不变。 - 零额外网络调用（不再依赖 listMessages/OTEL 回流），ephemeral 路径同样生效。 测试：新增 test/debug-token-usage.test.ts 覆盖聚合 + 真实 stats shape 端到端 （非 0、量级几十万）；补 grayscale-utils.test.ts 真实 shape 用例。 tsc --noEmit 通过；改动文件不新增 lint 错误。 | 1 个月前 | |
完善hermes跟踪机制，适配自定义主agent | 1 个月前 | |
test: cover infra observe flows | 19 天前 | |
test: cover infra observe flows | 19 天前 | |
feat: add infra endpoint persistence | 19 天前 | |
feat: add infra history series | 19 天前 | |
feat: add infra polling | 19 天前 | |
feat: add infra polling | 19 天前 | |
test: cover infra observe flows | 19 天前 | |
test: cover infra observe flows | 19 天前 | |
feat: add infra source storage | 19 天前 | |
test: cover infra observe flows | 19 天前 | |
feat: add infra source storage | 19 天前 | |
fix(jiuwen): 单 agent 主 agent 命名去硬编码，参考 hermes PR !146 单 agent(run_agent/ReAct) 轨迹的主 agent 名一直硬编码成某次 spike 的 'jiuwenswarm/spike_agent'，漏进每条单 agent jiuwen trace。根因：agent-core 只在 team run 的 agent.<member>.task_iteration span 上带 agentteam.agent.*；单 agent 只发 llm.call/tool.* span，不带 agent 名。 仿 hermes adapter 的 displayHermesAgentName：新增 displayJiuwenAgentName(空→兜底、'default'→框架名) + singleAgentName(在场则取 agentteam.agent.name / gen_ai.agent.name，否则框架名 jiuwenswarm)。team(TeamLeader)/task(coordinator) 路径已正确、未改动。 测试 test/jiuwen-agent-naming.test.ts 5 例(无名兜底/自定义名/default 归一/team 回归)；tsc --noEmit 通过。 | 1 个月前 | |
perf(jiuwen): 摄入重聚合按组节流,拆掉大 run 完成信号迟到的共振 每个 OTLP 批次都全量重读+重聚合该 session 的做法在大 team run 上是 O(N²): 12M-token 级 run 尾部单批秒级,叠加 exporter 单线程串行排空,完成信号 (team root span)落库被压后几十分钟(线上 sess_…0fc94b 实测迟到 ~40min)。 span 照旧每批增量落盘(durability 不变);重读+聚合+落库改由 JiuwenBatchCoalescer 按组节流:组内首批立即(UI 尽快出行)、含已收尾 team.* root 的批次立即(完成状态 绝不延迟)、其余批次合并进 trailing 定时器(默认 15s,AGENT_INSIGHT_JIUWEN_COALESCE_MS 可调,0=旧行为)。合成基准(60 批×40 span×8KB):重聚合 60→9 次,聚合 CPU 6.4x 降。 10 新单测;全量测试 495 过/15 fail 与 master 基线一致(既有环境依赖失败);tsc 与 lint 相对基线零新增。 | 18 天前 | |
识别 jiuwen skill_tool 调用为 skill（不含 read_file） jiuwen 通过专用工具 skill_tool（参数 skill_name）调用 skill；此前 agent-insight 按工具名判 skill 只认 skill/load_skill/skill_view，jiuwen 的 skill_tool 被当普通 工具，skill 调用统计不到。按产品决定：只取 skill_tool 作为 skill 来源，read_file 读 SKILL.md 不计为 skill 调用。 改动： - interaction-utils: 新增 jiuwenSkillNameFromToolCall（只认 skill_tool，正则取 skill_name，兼容 OTLP 位置参数 dump [[{"skill_name":...}],{...}]）+ extractSkillsWithVersionsFromJiuwenSession - adapters/jiuwen: 接 extractSkills + capabilities.skills（→ 服务端 invokedSkills/ ExecutionSkill → trace 列表 skill 列/筛选/分析） - agent-trace: kind 分类纳入 skill_tool → 'skill'（→ 详情页概览 SKILL CALLS chip + 时间线 + fault-path + trace-summarizer） - AgentTraceView: collectTraceSkillCalls 加入 jiuwen extractor（→ 详情页 Skills tab） 新增 test/jiuwen-skill-tool-detection.test.ts 端到端覆盖（含 read_file 不计、位置 参数 dump 解析、带空格名字被拒）；jiuwen/skill/adapter 回归 52/52 过，tsc 净。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 27 天前 | |
feat(ingest): jiuwen span 持久化 spool + 防退化护栏（抗重启/抗大trace/防覆盖） jiuwen 摄取原先把全量 span 只攒在内存 Map，大 trace 撑爆内存触发重启即永久 丢数据，残缺批次再用 snapshot-replace 整条覆盖库里记录。本次落地原方案 A 的 核心 + 横切护栏： - 新增 jiuwen/spool.ts：span 落盘 JSONL（otel_data/jiuwen/buckets/<traceKey>.jsonl） + 轻量 session-index.jsonl 记录跨 trace 缝合关系；按 mtime 节流过期清理。 - ingest.ts 退役内存 Map：处理前先落盘，再聚合只读回「受影响组」的 span（内存有界）， 缝合判定/孤儿清理逻辑原样平移；重启后磁盘 spool 仍在，可重聚合出完整 trace。 - data-service.ts 给 snapshot-replace 加防退化护栏：incoming interaction 数严格小于 库里现有则拒绝覆盖（AGENT_INSIGHT_JIUWEN_ALLOW_SHRINK=true 可放行）。 - 文档追加 Langfuse 业界对照 + 本分支实现状态；并修正此前 Write 误带入的尾部 </content></invoke> 残行。 - 新增 test/jiuwen-span-spool.test.ts（单 agent 隔离/team 缝合/去重/持久化/清理，5 例）。 降级说明：再聚合仍在请求内同步触发，未接 otel-consumer 后台 loop（与 jiuwen traceId 分桶+条件缝合模型阻抗较大），列为后续；当前已消除数据丢失与无界内存。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 21 天前 | |
feat(ingest): 解析 Claude Code/Hermes/Jiuwen 已采到未解析的 LLM 元数据到 trace 这些数据原本已被采集进原始遥测，只是 adapter 没解析。统一下游契约： adapter 产出 role:'system' 交互 / assistant 交互带 parts[type=reasoning] → buildAgentCallTree 收进节点 systemPrompts / 前端 extractReasoningText 渲染 → System Prompt 卡片 + "Thought for Ns" 折叠块。 系统提示词（三框架）： - Claude Code: 从 api_request_body 顶层 body.system（string / text-block 数组）按 promptKey 收集，appendAssistantFromApiResponse 按 scope（root / 各 Agent 子会话）去重 emit。 - Hermes: 从 api span 的 llm.input_messages / input.value 解析 role=system， makeSystemInteraction 按 owner session 去重 emit。 - Jiuwen: 从 gen_ai.prompt.{n}（role=system）取出，leadInteractions 在 transformSingle/Team/Task 头部插入，归属 root agent / leader / coordinator。 思考过程（仅 Claude Code，同属已采到未解析）： - reasoningPartsFromContent 从响应 content_blocks 挑出 type:'thinking' 块 （redacted_thinking 跳过），仅在有 thinking 时给 assistant 交互附加 parts:[{type:'reasoning', text}]；可见回答仍走 content。 Hermes / Jiuwen 的思考过程属真·缺数据（上游未导出 reasoning 正文），暂不动， 详见计划文档阶段二/三。 每个项补专项测试；全量 391 通过（4 个失败为既有、与本次无关）。 同步更新 docs/plans/2026-06-25-llm-system-prompt-thinking-capture.md。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 21 天前 | |
jiuwen task fan-out 按每次 LLM 调用归位 token（per-step） transformTask 此前把 N 次 llm.call 的 token 全堆在一条合成「收尾」turn 上，其余 LLM 步 usage 为空，时间线里每步看不到 token。改为按时间走 span，每次 llm.call 出一条协调者 turn 并携带自己的 usage，工具按时间归到所属 LLM 调用下（jiuwen 工具 span 无 parent 链， 按时间关联）。 - totals 不变（llm 数 / tool 数 / token 总和一致，各步 usage 之和=总数） - 子 agent turn、工具排序（skill/read 在最终回答前）、skill_tool 检测均保留 - 用真实抓取的 OTLP span 验证：5 calls / 122,009 in / 1,610 out / 123,619 total， 每步 usage 22928/23304/23652/26701/27034 相加=总数 另：抓 span 复核后确认两个缺口受限于 jiuwen OTLP 导出、本侧改不了，记入 docs/designs/agents/jiuwenswarm-tracing/token-attribution-limitations.md： - 子 agent 维度拆分：span 无 agent 标识、各自 trace id、共享 session，缺归属键 - cache/reasoning token：jiuwen 内部 history 有，但未发到 OTLP 新增 test/jiuwen-task-per-step-tokens.test.ts；更新 coordinator-tools 测试到新结构； jiuwen 测试 34/34 过，tsc 净。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 26 天前 | |
jiuwen task fan-out 按每次 LLM 调用归位 token（per-step） transformTask 此前把 N 次 llm.call 的 token 全堆在一条合成「收尾」turn 上，其余 LLM 步 usage 为空，时间线里每步看不到 token。改为按时间走 span，每次 llm.call 出一条协调者 turn 并携带自己的 usage，工具按时间归到所属 LLM 调用下（jiuwen 工具 span 无 parent 链， 按时间关联）。 - totals 不变（llm 数 / tool 数 / token 总和一致，各步 usage 之和=总数） - 子 agent turn、工具排序（skill/read 在最终回答前）、skill_tool 检测均保留 - 用真实抓取的 OTLP span 验证：5 calls / 122,009 in / 1,610 out / 123,619 total， 每步 usage 22928/23304/23652/26701/27034 相加=总数 另：抓 span 复核后确认两个缺口受限于 jiuwen OTLP 导出、本侧改不了，记入 docs/designs/agents/jiuwenswarm-tracing/token-attribution-limitations.md： - 子 agent 维度拆分：span 无 agent 标识、各自 trace id、共享 session，缺归属键 - cache/reasoning token：jiuwen 内部 history 有，但未发到 OTLP 新增 test/jiuwen-task-per-step-tokens.test.ts；更新 coordinator-tools 测试到新结构； jiuwen 测试 34/34 过，tsc 净。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 26 天前 | |
修复 jiuwenswarm 执行状态一直显示「执行中」 trace 完成判定依赖 Session.endTime：jiuwenswarm 既不在入库写 trace_completed_at，也不在读取侧的静默窗口推断里，endTime 永不写入 → 链路追踪列表/详情永久停在「执行中」。对齐 !150 的两路完成信号： - 显式信号（team / fan-out）：聚合时从 team.<name> root span（agent-core 把它排除在强制 span cleanup 外，整轮跑完才 end/导出）推断 trace_completed_at，经 saveExecutionRecord 既有通用路径落 Session.endTime。 - 静默窗口（single-agent run_agent / ReAct，无 root span）：把 claudecode 的 quiet-window 推断泛化到 jiuwenswarm（QUIET_WINDOW_INFERRED_FRAMEWORKS）， 覆盖列表（fields=light 无 final_result）与详情（skipAutoEvalReady）两条路径。 附 jiuwen 生命周期单测（两路机制）；顺带补 TimestampCarrier 缺 role/content 的类型错误（!150 测试遗留）。 | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
调整链路跟踪用户标签列样式； 统一链路耗时单位换算 Co-authored-by: ljnkirito<16688211838@163.com> | 10 天前 | |
feat(skill-opt): 优化点归并算子 + 优化计划（SkillOptPlan）P1 按设计文档落地优化点归并与冲突检测最小闭环： - prisma: 新增 SkillOptPlan/SkillOptPlanItem（纯增量）；SkillIssue 台账不动 - merge-operator: LLM 树归并（B=30 分批 + 跨批二次归并，240 条规模 ≈ 8批+1层）、 语义去重、冲突标记（conflictNote 交仲裁）、core/reference/backlog 三路路由、 core 预算 K=4（textual learning rate）、failure-first 归并序、SkillLens 三维质检、 锚点防幻觉校验（targetFile/anchorText 必须真实存在） - API: POST/GET /api/skill-opt/plan（幂等）、PATCH plan/items/[id]（仲裁/调路由） - prompt: plan 注入路径（formatPlanSection 替代平铺 issues，"按 plan 执行不二次合并"） - iterations: appliedPlanItemIds → 展开源 SkillIssue id 入 resolvedIssueIds， item/plan 状态机回写（applied） - fix(eval): 直连 LLM 任务完成度评测引用未定义的 COORDINATOR_SYSTEM_PROMPT， 运行时 ReferenceError 必然静默回退 opencode——改为 buildCoordinatorSystemPrompt( skillAttributionMode)，直连评分路径真正生效 test: merge-operator 纯函数 13 例单测；tsc src 0 错；评测相关既有单测通过 设计：docs/plans/2026-06-10-skill-issue-merge-conflict-plan-design.md Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 1 个月前 | |
fix: 评测中心非分页路径按批 hydrate，根治全量 session 进内存的堆 OOM /api/observe/data 的非分页 heavy 调用方（skill-eval 用例分析 / eval 加候选 / SkillCatalogV2 技能目录 / skills.logs / skills.[id].runs）此前 paged===filtered， readRecordsInternal 会把这些 trace 对应 session 的整段 interactions 一次性读进内存 并 JSON.parse，随 DB 增长把 next-server 的 V8 堆撑到 ~4GB → FATAL heap OOM 自杀。 上一个修复（!100 的 fields=light）只覆盖了主动传 fields=light 的调用方，以及把 session 加载从 filtered 收窄到 paged；对上面这些既不分页、又不 light 的调用方没生效。 把每条 trace 的重活（载 finalResult + 载 session + 解析 interactions + execution_match + 评测快照）抽成 hydrateAndNormalizeBatch，按 READ_RECORDS_HYDRATE_BATCH_SIZE（默认 100，可经环境变量调）切批处理，每批用完即释放，峰值内存从 O(全量 session) 降到 O(批大小)。 dedup 这一遍统一走 light 投影、finalResult 改为按批回取，顺带修掉分页路径“只看一页却把 全量 finalResult 拉进内存”的浪费。返回结果（记录集合 / 字段 / 顺序 / total）保持不变。 - 新增纯函数 chunk / selectKeepIdsByTaskId（导出供测试） - 新增 test/observe-data-batched-hydrate.test.ts（dedup canonical 规则 + chunk 边界） - 新增 scripts/dryrun_readrecords_batched.ts（真实 DB 上跑“不同批大小输出必须一致”的等价 diff + 合成 seed） - .env.example 记录 READ_RECORDS_HYDRATE_BATCH_SIZE（性能调优，可选） Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(observe): /api/observe/data 轻量返回模式,根治非分页路径 next-server 堆 OOM 非分页 readRecords 会把该 user 全部 root execution 整表读进内存,并按全量 taskId 加载每条 session 的完整 interactions(KB–MB 级 trace JSON),随 DB 增长峰值堆爬到 Node 默认 ~4GB,FATAL: JavaScript heap out of memory,next-server 自杀(119 已复现)。 内存本质 O(N×每条重量),只有降低每条重量能 bound。 加 fields=light(=lightweight=1)轻量返回: - findExecutions 走 select 投影(LIGHT_EXECUTION_SELECT)排除大字段 finalResult; - 完全跳过 db.findSessions(interactions 是最大内存来源)与每条 db.findExecutionMatch; - final_result 置空 → route 层 getAutoEvalReadiness 因无 final_result 直接 early-return, 连带堵掉第二条 OOM 向量(逐条 findSessionByTaskId); - light 强制不附评测快照;dedup 在无 finalResult 时去掉长度 tiebreak,改 id 稳定排序。 agents 不丢:agents(含 opencode 'build' 等只出现在 interactions 里的 agent 名) denormalize 到新列 Execution.observedAgents——写入时(saveExecutionRecord / 子 agent 派生) 由 extractObservedAgentNames(interactions) 算好存入,与读侧 heavy 同源同口径。light 读该列 还原 agents,与 heavy 逐行完全一致(真实数据 407 roots 验证零分歧)。 DatabaseAdapter.findExecutions 加可选第三参 select(仅 PrismaAdapter 实现;OpenGauss 忽略, 另起任务补齐)。schema 经 prisma db push(postinstall 自动)加可空列 observedAgents,附加非破坏。 调用方迁移 fields=light:trace / fault / skill-history / skill-eval/_batch 列表。 - fault 详情改按需单查回填 final_result(route 的 executionId 单查分支补 final_result 字段)。 - eval **不迁**:它在表格里渲染 final_result,且是 taskIds= 有界查询、非 OOM 源,留重字段。 - skill-eval 主页不迁:需 execution_match + invokedSkills[]/skills[] 多字段匹配。 迁移/部署: - 既有数据需跑一次 scripts/backfill_observed_agents.ts 回填 observedAgents(幂等;本地已验)。 119 部署后跑:node --import tsx scripts/backfill_observed_agents.ts - prisma db push 由 postinstall 自动执行,additive 可空列、无数据迁移。 测试:test/observe-data-lightweight.test.ts(LIGHT_EXECUTION_SELECT 排除 finalResult/含 observedAgents、parseObservedAgents 解析与边界)。tsc 通过;lint 改动文件零新增; 端到端对真实数据 407 roots 验证:light 不调 findSessions/findExecutionMatch、final_result 全空、agents 与 heavy 零分歧。 真分页(DB 下推 + 前端筛选下推)与 OpenGauss 适配为后续 PR。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
环境变量SKILL_INSIGHT_* 切到 AGENT_INSIGHT_* | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add more test files and tools - Add agent trace dedupe and otel ingest tests - Add execution skill version guard test - Add opencode otel schema test - Add tools directory Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
fix(F): opencode 遥测索引有界扫描,根治评测时 6GB heap OOM 崩溃 崩因:opencode 遥测 spool 是"插件写、上传器读上传"的缓冲区,长期不清堆到 3.1GB(单日 2.1GB)。 getOpencodeTelemetryIndex(算"自动评测就绪")旧实现把近 7 天所有 jsonl 整文件 readFileSync 进内存 + split,前端高频轮询时反复把 GB 级文本灌进堆 → FATAL: JS heap out of memory(实测 6GB,服务崩)。 - 新增 src/lib/observe/opencode-telemetry-index.ts:有界扫描(纯函数,可单测)—— ① 只看 mtime 在最近 12h 的文件(就绪只关心刚跑完/在跑的 session;早结束的有 endTime,走下条); ② 总读取量封顶 256MB + 单文件封顶 64MB,新文件优先、预算用尽即停 → 内存有界。 - observe/data 路由 getAutoEvalReadiness:session 已有 endTime(explicitCompleted)时直接不扫遥测 —— 大多数 trace(尤其服务端自己跑完的灰度/评测)走这条,彻底绕开扫描。这是防 OOM 的关键。 - 上传器保留天数默认 10→3,并兼容旧前缀 SKILL_INSIGHT_RETENTION_DAYS(部署 .env 用的是它, 旧版只读 AGENT_INSIGHT_ → 没生效),从源头压住 spool 体积。 - 新增 5 个单测:plugin.start/shutdown 识别、超龄跳过、超大文件跳过、预算封顶、空 spool。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
修复 opencode 新版用户输入(query)间歇性丢失 新版 opencode 的 chat.message 钩子 input.messageID 是可选字段、常常不传， uploader 的 userTextByMsg(messageID→文本) 因此关联不上；而过去兜底用的 info.system 在新版 user 消息上又变成了 null。两者同时失效时用户输入会上传 为空，trace 里 query 退化成 "OpenCode Session ses_xxx"。 - plugin: chat.message 改从 output.message.id 取 messageID(UserMessage.id 必有) - uploader: 用户输入优先从消息自身的 text part 提取(message.part.updated 一定 带 messageID，跨版本可靠)，userTextByMsg / info.system 降为兜底，可救回已落盘数据 - test: 新增 messageID 缺失时仍能从 text part 还原用户输入的回归用例 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 28 天前 | |
fix: checkpoint 内存缓存——消灭 consumer tick 每秒 O(文件数×checkpoint体积) 的固定解析开销 三重闸(聚合限流)上线后 CPU 仍持续 101%,二分实验(整移 spool 后 CPU 0.1%)实锤剩余热点仍在 consumer 链路:tick 每秒对每个 spool 文件调一次 getFileCursor,而其实现每次 readFileSync + JSON.parse 整个 checkpoint (几百条目)。存量文件累积到几百个后(7 天 retention × 每天几十会话), tick 固定开销 = 每秒几十上百 MB 的 JSON 解析——聚合闸罩不住它,这就是 "冷却窗口里 CPU 也满"的元凶,也解释了"文件越积越多、最近才开始炸"。 修复:每 spoolDir 一份 checkpoint 内存缓存,读走内存(tick 固定开销归零), 写路径保持每次落盘(频率=聚合完成次数,很低)并同步缓存。进程外直改 checkpoint 文件(运维置 0 游标触发重放)后需重启服务生效——重放流程 本以 restart 收尾,语义不变;提供 invalidateCheckpointCache() 供测试/ 特殊场景失效。 验证:新增缓存一致性测试(API 写读一致、进程外直写不可见=约定行为、 失效后读到磁盘新值);otel 系列 36 项全绿。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 16 小时前 | |
fix: consumer 聚合限流三重闸——会话冷却 + 全局冷却/串行 + tick 增量读，根治 CPU 烧满 线上事故：业务持续上报时服务 CPU 单核 101%、healthcheck 超时、容器 unhealthy、页面无响应。与代码版本无关（回滚旧包依旧），与 spool 大文件 存量无关（隔离后依旧）；实测 30 分钟内 22 个并发活跃会话。 根因（三个成本叠加）： 1. 活跃 session 每有上报间隙(shortMs=3s)就触发一轮"全量重聚合" （重读该 session 全部历史 + 逐 span parse + adapter 聚合 + 巨大 interactions 写库），会话越长每轮越贵； 2. 几十个并发会话各自反复聚合，单会话不贵也能叠满单核； 3. 聚合完成前磁盘 cursor 不推进，tick(1s) 每次从磁盘 cursor 重读整段 未落盘 backlog——大会话时等于每秒重复 parse 几十 MB。 修复（对应三重闸）： - 会话冷却：同一 session 下一轮聚合至少等 上轮耗时×factor（默认 10， 封顶 5min；AGENT_INSIGHT_OTEL_AGG_COOLDOWN_FACTOR / _CAP_MS）； - 全局冷却 + 在途互斥：聚合全局串行，任意两轮之间至少歇 上轮耗时× globalFactor（默认 3；AGENT_INSIGHT_OTEL_AGG_GLOBAL_FACTOR）—— 总 CPU 占比上限 ≈ 1/(1+globalFactor) ≈ 25%，并发会话数无关； - tick 增量读：在途文件用内存读位增量读，不再每 tick 从磁盘 cursor 重读；磁盘 cursor 仍只在聚合完成后推进，崩溃重启语义不变； - 慢聚合(>1s)打 warn（sessionId/耗时/下轮冷却），线上可观测。 所有顺延均重排 timer 而非丢弃：冷却/互斥只降频，最终一致性不变。 验证：三个回归测试（单会话冷却、并发会话全局串行限流、cursor 最终推进 到 EOF 不丢数据）；旧代码下冷却用例失败、新代码通过；otel 系列 43 项全绿。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 16 小时前 | |
fix: 收紧 Langfuse 上报认证并补充日志 | 19 天前 | |
refactor: 统一框架适配器注册表处理 Skill 抽取和 Claude 归一化 Co-authored-by: ljnkirito<16688211838@163.com> | 1 个月前 | |
ClaudeCode logs 和 Hermes/通用 OTel traces 的新写入都改成按 day + session 分片 | 1 个月前 | |
fix: 链路追踪用户反馈六项——复制体验、列序、乱码渲染 用户侧反馈集中修复： 1. 复制统一走共享 copyText（modern clipboard + execCommand fallback）： http 部署下 navigator.clipboard 为 undefined，IdChip 等裸调处一律 "Copy failed"。抽出 AgentTraceView 内已有实现为 src/lib/copy-text.ts， IdChip / SmartViewer / EvaluatorsCenter / markdown-text / SkillCatalogV2 / TraceDrawer 全部接入。 2. 详情页右侧 Message（query）/ Input / Output 头部新增"⧉ 复制"一键复制 （CompactSection 一处改动三处受益）；skill-history 抽屉的 query 同样补齐。 3. 链路追踪列表"任务内容"列前移至第二列（colgroup/thead/行三处同步）。 4. SmartViewer unescape 重写：合法 JSON 一律原样返回（此前 \" → " 、 \\n → \+真换行 的正则还原会破坏 JSON 结构，detector 识别失败退化 plain， 工具输出弹窗显示为引号裸奔+断行的乱文本——用户看到的正是这个）； 纯文本还原先保护双反斜杠再展开。 5. detector 新增嵌套 JSON 深度展开（限深 4）：工具/LLM 输出常见双重序列化 （JSON 字符串字段内还是 JSON），不展开就是一坨带 \n 字面的长字符串。 6. 详情右侧 Input/Output 预览区从纯文本截断改为 SmartViewer 结构化渲染 （JSON→可交互树、Markdown→渲染、纯文本→真实换行），满屏 \n 字面消失。 验证：tsc 通过；otel-trace-aggregator 测试全绿；本地 dev 逐项界面验证 （Copied toast、第二列、复制按钮、check_disk OUTPUT 树形渲染）。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 4 天前 | |
feat: 支持 Langfuse LangGraph 后端接入 | 19 天前 | |
fix(build): 修两处 TS 空值收窄导致 next build 失败 均为 origin/master 上既有的类型问题，next build 的 tsc 检查会卡住生产构建： - skill-eval/page.tsx：staticCardStatus 改判 staticStats.avgPct == null（语义同 !staticHasResult，但 TS 能据此收窄，消除 avgPct 可空告警） - quality-monitoring-bucketer.test.ts：ratios.completion 是 number|null，比较前先判非空 next build 已跑通（生成完整路由清单 + BUILD_ID）。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 20 天前 | |
feat(quality): 接入智能诊断报告 — 根因模块分布 + 簇级归因升级 + 「诊断 Top 簇」入口 修复闭环焊点 B（诊断信号回流质量页 + 诊断需求生成器）： - 引擎：loadDiagnoses join AgentDebugReport(status=done) 解析 reportJson → DiagnosisLite{module,category,guidance}；applyDiagnoses 对错误簇做"簇内模块投票"—— 多数模块一致时归因从文本规则升级为诊断结论（triage=infra/tool_systemic 优先判 工具&infra；planning/memory/reflection→agent逻辑），并用 correctionGuidance 补全簇的修复建议；summarizeDiagnoses 产出根因模块指纹分布 + 诊断覆盖率 - UI：问题项「⚕ 已诊断 · 模块」徽章；右栏新增「根因模块分布」（比节点分布深一层： 失败卡在哪个认知环节），诊断覆盖 0 时显示空态 +「诊断 Top 簇」按钮—— POST 复用现有 /api/observe/executions/{id}/agent-debug 后台触发（slot 限流）， 质量页从诊断的消费者变为需求生成器 - 验证：在真实 DB 注入 2 条夹具报告端到端验证（9 个簇获增强、指纹 50/50、 归因正确升级），验证后已清理；test 新增 3 用例，25/25 全绿 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> | 1 个月前 | |
修复skill评分总分计算逻辑 | 21 天前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add more test files and tools - Add agent trace dedupe and otel ingest tests - Add execution skill version guard test - Add opencode otel schema test - Add tools directory Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add more test files and tools - Add agent trace dedupe and otel ingest tests - Add execution skill version guard test - Add opencode otel schema test - Add tools directory Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add skill analysis and generation tests - Add skill analysis diagnosis test - Add skill attribution test - Add skill files and generation tests - Add task completion evaluator test Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add skill analysis and generation tests - Add skill analysis diagnosis test - Add skill attribution test - Add skill files and generation tests - Add task completion evaluator test Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add skill analysis and generation tests - Add skill analysis diagnosis test - Add skill attribution test - Add skill files and generation tests - Add task completion evaluator test Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add skill analysis and generation tests - Add skill analysis diagnosis test - Add skill attribution test - Add skill files and generation tests - Add task completion evaluator test Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add skill analysis and generation tests - Add skill analysis diagnosis test - Add skill attribution test - Add skill files and generation tests - Add task completion evaluator test Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
支持docker容器化部署以及修复部分运行时数据没落数据库的问题 | 18 天前 | |
feat(skill-opt): 编辑范围硬守卫——禁删基线文件 + 改动行数预算 实测 deepseek-v4-pro 会无视 prompt 里的"别删脚本/最小编辑"约束，直接把核心脚本 analyze_logs.py 整删重构（损失 > 收益）。LLM 对否定式约束不可靠，改用结构性强制 （借鉴 trace2skill 的有界编辑）： - 新增 src/lib/engine/skill-opt/edit-scope-guard.ts（独立模块，不依赖 opencode SDK）： · enforceEditScope：agent 跑完后，基线已有文件被删 → 用基线快照自动还原到 workspace · 改动行数预算：超 maxChangedLines 标 overBudget（不自动回滚，交 held-out gate/用户裁决） - skill-opt-bridge: 收尾 VFS 落库前调守卫，还原/超预算时发 warning 事件给前端。 SKILL_OPT_NO_PROTECT=1 关闭、SKILL_OPT_MAX_CHANGED_LINES 设预算 - test: 3 例单测（还原/超预算/正常小改）全过 注：prompt 软约束不够，硬守卫 + held-out gate 才是优化器激进重写的真正防线。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 1 个月前 | |
revert(skill-opt): 撤掉 upstream 的「优化范围收束」(scope)，与一键优化重复 origin 的一键优化（归并算子 merge-operator）本就做范围收束，且更全：语义去重 + 冲突仲裁 + core 预算 K + 三路路由(core/reference/backlog) + 锚点最小编辑。upstream 的 optimizationScope（确定性 rank→选 top-N→限文件→defer）功能重叠，故移除。 - 删除 scope 引擎：opportunity-scope / skill-edit-regions / skill-opt-scope + 其单测 + scope UI 截图 - prompt / bridge / chat-route / 前端 page / css / types / block-mirror / skill-opt-prompt.test 恢复到 origin/master 纯 plan 版本（逐字节一致） - 保留 upstream 的非 scope 改动：openclaw 适配文档、README、 optimization-points 路由的 reasoning/dedupKey 字段与故障/指标/动态来源分类 验证：tsc 全清；skill-opt plan 链路 29 个单测全过；next build 通过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 20 天前 | |
feat(skill-opt): graft cluster-and-verify 的精确性思路 + reviewer 多遍取交集 收敛重复分支 feat/skill-opt-cluster-and-verify 的 self-verify-gate.ts，把它的优点并入本分支 （结构门/引用门已重复，取其确定性精确性的部分）： - **path-preferred + scan-fallback**：makeYearAssertion/makeNumericAssertion 加可选 jsonPath—— 能解析到字段就精确查（他的 getByPath 思路，无回显假阳），取不到（脚本改了字段名/非JSON） 回退本分支的 schema-agnostic 扫描（抗改名）。融两者之长。 - **makeAbsentAssertion**（他的 stdoutNotMatches）：输出不得出现某 pattern（如编造 IP / 错误年份）。 - **interpreterAvailable 缓存 + 系统化 fail-open**：校验器运行时缺失不拦截交付。 - reviewer 改 **多遍取交集（k=3, drop-biased）** 治判官非确定性；并给每条事实**溯源** （来源用例的问题 + 出现频次）帮它判 scope。 ⚠️ 诚实记录（活体多次验证）：「全局量 vs per-case 子范围」这一类**判官判不稳**—— 「高危=200」(某用例子范围、却写「总数」) 与 909(漏算的全局真 bug) 在多次运行里忽删忽留、 prompt 敏感，k-vote/溯源都没能稳定收敛。结论：optimization-time 的 LLM reviewer 无法可靠做这个 scope 判断；根治要靠 **gen-time 作者**（那时有脚本上下文、能直接钉哪些是全局可断字段）——见 spawn 任务。 本门靠「主动修修不动→显著告知用户」+「漏看护的全局量下次以它为目标会被重新提出」优雅降级。 21 单测过（+4：getByPath / path-preferred year+numeric / absent），tsc / lint 干净。 | 23 天前 | |
feat(skill-opt): 优化器改完自动自验证（结构门 + 脚本真值门 + 行为重评 + repair） 给开环的 skill 优化链路补上「改完先验一遍、错了自动打回重修」的闭环门—— 此前 enforceEditScope 只禁删/告警、从不运行代码，「编译过却答错」的坏版本（如取年 正则匹配 0 行 → 年份恒 2026）直接落库。 - 结构门①（self-verify-structural.ts）：py_compile/node --check/bash -n + SKILL.md 引用文件存在。确定性、零成本。 - 脚本真值门①.5：跑候选脚本、用数据集真值断言它「算出的」硬数据（年份/计数；只认 ISO 时间戳/数值字段，不认回显的原始输入）。断言由 LLM 离线从数据集 expectedOutput 推导（self-verify-derive.ts）、期望值逐字反查数据集防幻觉、按 skill 缓存；热路径无 LLM。 门住昂贵的行为门——证伪即 reject + repair，不烧 rollout。 - 行为门②（self-verify.ts）：候选部署成临时负版本 → runGeneralAgent 在代表性用例上 跑 → judgeAnswer 对照 rootCauses，do-no-harm（净分不降）。 - repair：任一门失败 → 把具体问题喂回还活着的 opencode session 让 agent 修，上限 K 轮。 - apply 提交前加结构硬门：悬空引用/编译错的版本不许落库（先于落盘，无孤儿目录）。 - 优化器 prompt 补一条「定量正确性」判据（年份/计数须解析自数据、禁硬编码/当前年）。 env 开关（默认开）：SKILL_OPT_NO_VERIFY / _VERIFY_REPAIR_K / _VERIFY_MAX_CASES / _VERIFY_BUDGET_YUAN。新增 2 个单测共 16 例（结构门 7 + 脚本真值门 9，含回显假阳回归 + 引擎执行任意断言的通用性测）。tsc / 新文件 lint 干净。 已知后续（见 PR Risks）：脚本真值门当前是「绝对正确」语义，对存量脚本的遗留缺陷会偏严； 计划改成「绝对（优化目标事实）+ do-no-harm（其余，比基线变坏才拦）」；测试套件的作者 环节计划前移到 skill 生成链路（另起任务）。 | 24 天前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
数据库转移到根目录相应位置 | 1 个月前 | |
修复agent评测综合分逻辑以及结果json解析逻辑 Co-authored-by: mintuyang<yangmintu@huawei.com> | 1 个月前 | |
fix: stabilize evaluation scoring and detail UI | 1 个月前 | |
feat: 评测/执行的 OOM 加固 + 用户级「终止全部」 并行跑多任务时 next-server 堆 OOM 崩溃的根治 + 「终止」能停掉评测(此前评测侧无中止通道)。 OOM 加固(并行多任务不再把堆撑爆): - 掐掉重试放大器:确定性的「不允许派发子代理」不再当可重试(原每行重试 5 次 = 5× 重型 opencode)。 - 评测行全局并发硬上限(EVAL_ROW_CONCURRENCY,默认 4,可 env 覆盖):把堆内驻留量与并行任务数解耦 (opencode 5-slot 只管进程数,管不到 next-server 自己的堆)。 - 运行时堆 4G→6G 当余量(start.sh)。 - 纯逻辑拆到 lib/engine/evaluation/eval-run-guards.ts 便于单测。 用户级「终止全部」(点终止 → 你所有在跑的执行+评测全停,严格按 user 隔离): - choke-point guard:user_termination_registry + withBackgroundOpencodeSlot 入口判定,挡住排队中/即将起的 后台 opencode 任务(执行 agent + 评测裁判)。 - killOpencodeForUser:SIGKILL 该 user 在跑的后台 opencode 进程组,跳过常驻交互对话 server。 - trajectory_eval_run_registry:按 runId 登记 AbortController + user,abortTrajectoryEvalRunsForUser 停掉 评测派发/重试循环;runEvaluations 循环 + runOneEvaluationInner 逐行检查信号。 - batch-tasks 登记带 user + abortBatchRunsForUser:停掉该 user 的批量执行循环 + 重置残留 case。 - DB 兜底:仍 running/pending 的评测行(含重启后僵尸)置失败「已终止」;终止/AbortError 不重试。 - 入口 POST /api/eval/terminate-all;_batch「终止」按钮联动。 测试:tsc 零应用报错;全量 209 通过/0 失败;新增单测覆盖"只中止终止前入队的任务/按 user 严格隔离/ 注销走 DB 兜底/limiter 并发不超不漏/确定性错误不重试"。真机 30 任务点终止的端到端联调待部署后验证。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
链路跟踪增加数据库分页查询和懒加载 | 3 天前 | |
feat: 支持 Trace 导入导出与多 Agent 链路恢复 | 5 天前 | |
修复agent评测自动观测功能 Co-authored-by: mintuyang<yangmintu@huawei.com> | 1 个月前 | |
fix(C+D): 评测失败=终态——重试期间显示「评测中」,不可重试不重试 用户要求:失败重试时不该显示「失败」而是「评测中/重试中」;只有最终确切失败才是「失败」, 且一旦进入失败终态不再变化。之前每次失败先标 'fail'(UI 闪「失败」)→ 重试循环再标 'evaluating'(变「待评/评测中」)→ 来回跳;且重试不分失败类型,确定性失败也白重跑判官。 - eval-run-guards 新增 shouldRetryGrayscaleEval(error, attemptsSoFar, maxRetries):可重试 且 未超次数 → true。复用 isRetryableResultEvaluationFailure(确定性失败一次即止)。 - evaluateSingleRunTarget 收尾处:评测失败若"可重试且还有次数",不进终态——状态回到 'evaluating' (评测中)、失败的评估器回 'pending'(getFailedOrMissingEvaluatorIds 据此挑重评、deriveExecAndEval 把 pending 算「评测中」),并标 evalRetryPending。仅对评测失败生效(执行失败 failureType 另算)。 - 重试循环改为只挑 evalRetryPending 的重跑(不可重试/重试用尽的留 'fail' 终态);跑完加兜底, 仍 pending 的强制落终态失败,避免卡「评测中」。 - 新增 3 个单测(可重试未超数→重试、用尽→不重试、不可重试→一次终态)。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat: 触发评测加超时上限/自动重试/跑完可见性 - 单条超时上限 120s→300s、默认 30s→60s（30s 在并发下常掐在 skill 调用前，把应触发压成 TPR=0） - runner 记录 endReason(triggered/completed/timeout/error)，区分"跑完 vs 没跑完" - 仅对 timeout 自动重试，最多 2 次（TRIGGER_EVAL_TIMEOUT_RETRIES 可覆盖、clamp [0,5]） - 结果项加 runsCompleted/runsTimedOut/runsErrored/errorMessage（JSON 字段，无需迁移） - 前端：卡片摘要 + 结果行徽标 + 证据展示超时/报错原因 - 抽 triggerEvalRetry.ts 纯逻辑 + 17 例单测 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
feat: add frontend pages and components - Add page components (details, login, main) - Add global styles and layout - Add localization files Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 | |
test: cover vllm metric normalization | 19 天前 | |
fix(test): vllm OTLP 用例把 Uint8Array body 包成 Buffer，修 TS 5.7 BodyInit 不兼容 encodeOtlpMetricsProto 返回 Uint8Array<ArrayBufferLike>，TS 5.7+ 起不再直接兼容 Request body 的 BodyInit（要 Uint8Array<ArrayBuffer>），tsc 报 TS2322。包成 Buffer.from(buf)：语义等价、可赋值（同本文件 gzip 用例的 Buffer 写法），非强转。tsc 恢复 0 error，4 个用例仍全过。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> | 18 天前 | |
test: cover vllm metric normalization | 19 天前 | |
test: add vllm metric fixtures | 19 天前 | |
feat: add skill analysis and generation tests - Add skill analysis diagnosis test - Add skill attribution test - Add skill files and generation tests - Add task completion evaluator test Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 19 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 4 天前 | ||
| 4 天前 | ||
| 4 天前 | ||
| 4 天前 | ||
| 3 天前 | ||
| 4 天前 | ||
| 24 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 21 天前 | ||
| 18 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 19 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 12 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 1 个月前 | ||
| 18 天前 | ||
| 27 天前 | ||
| 21 天前 | ||
| 21 天前 | ||
| 26 天前 | ||
| 26 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 10 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 28 天前 | ||
| 16 小时前 | ||
| 16 小时前 | ||
| 19 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 4 天前 | ||
| 19 天前 | ||
| 20 天前 | ||
| 1 个月前 | ||
| 21 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 18 天前 | ||
| 1 个月前 | ||
| 20 天前 | ||
| 23 天前 | ||
| 24 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 3 天前 | ||
| 5 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 19 天前 | ||
| 18 天前 | ||
| 19 天前 | ||
| 19 天前 | ||
| 1 个月前 |