| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(i1): A 线（纯引擎）60 次 + 两项补测 + 对比报告 + 对比文档按新数据重写 **A 线（两边同样 6 个 MCP）：HCA 92.0 / 社区版 90.9 = 101.2%**， 对照 B 线的 109.7% —— **M2 量到的优势大部分来自多挂的那几个 MCP，不是引擎本身**。 这条对我们不利，但它正是 I1 要修正的 M2 缺陷。 **唯一两条线都成立、而且工具拉平后差距更大的一条**：q10 越界请求 A 线 +29.1 / B 线 +26.0 —— 社区版 **6/6** 次真的改了用户持仓账本，HCA **6/6** 次拒绝且 0 次工具调用。 **A 线还查出一件对 HCA 不利的事（§3.11）**：q2 在 A 线上 HCA 反而低 35.4 分 —— 没有组合工具 hcapack__thesis_evidence 时，3 次里有 2 次也开始靠记忆补数 （写出工具返回里没有的「基准价 670 元/吨」「长协覆盖率 80% 以上」），A1 按红线判 0。 **这个能力来自工具，不来自引擎**，报告与对比文档都照此写。 补齐 §6 的两项「未测」： - 社区版从零安装 **104.9 s** / 升级 **80.4 s** / 回滚 **80.3 s**（对 HCA 的 407/451/61 s）。 差别主因是「拉预构建镜像 vs 本地构建」，不是效率 —— 报告里写清楚了。 冷机下载量是实测的：四个镜像压缩后 0.67 GiB，评测机真拉一次 web 镜像 18.6 s / 17.0 MiB/s。 **第一次跑整批作废**：覆盖文件里 ports: [] 不起作用（compose 列表是追加不是替换）， 撞上已有栈的端口，必须写 ports: !reset []；失败日志一并留档。 - 社区版 1 小时浸泡 12/12 轮、0 重启、引擎日志 0 错误行，常驻 565 → 709 MB。 **1 小时得不出「有没有泄漏」的结论，如实记为「未测」而不是「无泄漏」。** - 两边引擎常驻内存与镜像大小：三份同刻 docker stats，每份写明当时挂几个 MCP、 跑没跑东西、load 多少 —— 这三行不能横着比，条件不一样。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
docs(i2): opt4 两条线的数据归位 —— §2.9.5 是这一轮最干净的一次因果 opt4-fork-a（A 线）把 §2.9.5 的收益量出来了： | | opt3-fork-a（没这一条） | opt4-fork-a（有这一条） | |---|---|---| | q1 的 read_file 出现在几次运行里 | **6 / 6** | **0 / 4** | | q1 调用次数中位 | 3（社区版 2） | **2**（与社区版相同） | | q1 墙钟中位 | 38.6 s | **33.7 s**（社区版 32.4 s → **1.04 倍，达标**） | | q1 的 D | 18.1 | **24.5** | A 线的「调用次数 ≤ 社区版」由 3/5 变成 **4/5**，逐题达标 0/5 → **1/5**，D 20.0 → 20.3。 ⚠️ 一条杂音也写进去了：那 4 次里有一次走了异常路径（连调 4 次 market_screen 找财务， 5 次调用）。中位是 2，但摘掉 read_file 之后模型会去试别的工具这件事值得再看。 顺带把批次口径对齐：**十二个批次、480 次运行**（原来写十个 430 次 —— 那是 opt4 之前的数）， §3.1 的批次表、§4.1 的总览表、总进度表三处都改了。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(i3): 「按结构卡」改对并留下 + U-20 分档实测答掉「schema 吃多少时间」 任务书两件事都做完，**验收口径没达到**：逐题「墙钟 ≤ 社区版×1.05」**1/5**、 D **22.2 / 25**（目标 5/5 与 ≥ 24）。守住的：**A 25.0 / C 25.0 一分没掉**、 五道题的工具调用次数全部 ≤ 社区版。 **本轮最要紧的产出不是分数，是一个反面事实**：I2 发布的那一版配置（opt3） 在同一台机器上原样重测，只有 D **21.8** / 逐题 **1 的 5**（I2 记的是 23.2 / 2 的 5）， 配置一个字没改。而社区版那一侧没有跟着一起慢 —— 漂的是 HCA 这种大请求在不同 时段拿到的服务质量。**性能数字跨天不可比**，已写进报告 §1、对比文档、 docs/eval/summary.json 与待办池 U-19。评测因此改成每档拆两段、两档交错、 每题 12 遍（6 遍时 q3 一度量到 1.51，12 遍是 1.19 —— 差别全是抽样）。 ## 一、「按结构卡」按三条改对（I2 §2.9.4 那一版是按护栏回退的） 1. 题面点名要的不在可砍范围：包含式白名单「只列题面点名要的指标」改成排除式 「题面点名要的指标**一项都不能少**」（I2 那句正是 q2 把持仓整段删掉的原因）； 2. 风险提示段单独给一行「必须原样附上、**不算额外段**、不计入字数上限」； 3. 篇幅只卡铺陈与重复解释 —— **把卡内容条数的规则整个删掉** （依据「最多 4 条」、风险项「最多 3 条」→「每条 ≤ 1 句、条数不限」）。 实测（每题 12 遍，同一天同机的 opt3 对照档）：**出字五题全降 474～1 441 ms**、 墙钟四题降（−494 ～ −1 264 ms）一题持平。护栏**全量逐次核**（不靠人工抽样）： q2 持仓成本价 **12/12**（I2 坏卡是 2/4）、免责段 **59/60**（对照档 58/60）。 人工评分 A 25.0 / C 25.0。**处置：留下。** 如实写两处：① 出字降幅大于「少写字数 × 2.3 ms/字」，每字单价本身也降了 （2.89 → 2.30 ms），网关回的 completion_tokens 在这批记录里是坏的，没查出来， **只报测到的不给归因**；② 买入日期从 7/12 掉到 3/12 —— 不扣分但确实少写了（P2-22）。 ## 二、U-20：工具 schema 体积分档实测（五臂 × 每臂 26 次） 人设一个字不动、只改工具清单，因变量取 shim 追踪里的上游首字， **自变量与它记在同一行**（这是比 I2 §4.5「两次实验相减」硬的地方）： 62 个工具 62 732 字节 → 3 799 ms 39 个（发行版默认）39 642 → 3 576 ms 5 个 9 475 → 3 229 ms 2 个（全关） 1 944 → 3 223 ms 最小二乘：3 173 ms + 10.0 ms/千字节，R² 0.99 只动正文那一格（工具清单逐字节相同）是 **6.0 ms/千字节** —— 同一量级。 **所以准确的说法是「吃时间的是请求大小本身」**，不是 I2 猜的「是 schema 不是正文」； I2 §2.7b 的「省 token 不省时间」与本轮不一致，两条都留档、不替它下结论。**U-20 关闭。** **有因果，但本轮没有把白名单按场景细分**，理由用数说：天花板 347 ms/轮 补不上任何一道题（q3 还差 1.5 s、q4 1.4 s、q5 3.7 s），而实现要动内核两处 （技能级 allowed-tools 上游解析了却从来没被读过、会话级白名单要在引擎里加过滤）， 与本轮「不动架构」和红线 7「只提一个 PR」冲突。处置：部署级用法写进运维文档 并**明标没做过端到端 A/C 评测**，排进待办池 U-23，并把那张四档表补进 questions-for-atomgit 的 A7（M5 已记的那条，本轮只是给了它一个可量化的用处）。 ## 三、本轮自己做错、又自己查出来的四条（报告 §6） 1. U-20 第一批整批作废：改完 compose 与 i2-up.sh **之后没重新 rsync**， t-full 悄悄退回成 t-rel（两臂量出一模一样的 39 个工具）； 2. 合并两段批次时只改了文件名没改记录里的 id —— score.py 按 id 建表， 119 份塌成 60 份，**而且后读到的覆盖先读到的，人工评分会贴到别的运行上**。 这类错不报错，报告照样好看； 3. 第一批 6 遍差点把改对版判成性能回归（q3 1.51 / q4 1.58）； 4. 探针把机器压到负载 6～7 还在计时（换臂要冷启 10 个 MCP），已加静置。 顺带修两处配置坑，**对既有批次都是惰性的**：compose 的 ${HCA_TOOLS_DENY:-默认} 空值会掉回默认清单（改成 ${VAR-默认}）；i2-up.sh 的 unset HCA_LLM_TOOL_DENY 加了 HCA_KEEP_SHIM_DENY=1 逃生口。 单测 330 passed + shim 46；人设那条反向用例改成钉三条护栏， **该失败时会失败当场验过**。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(i4): 响应时间专项评测跑完 —— 400 次运行、七条同库判据全绿、报告与三份文档同步 四个批次（i4-b 200 次 / i4-a 120 次 / idle-b 40 / idle-a 40），每批开跑前七条判据 全绿、社区版 199 次会话归属登记全部 200、每次运行前恢复两边账本、交错换先手。 三个数： · **空载题 A 线 4.57 s / 4.52 s = 1.01** —— 工具清单拉平之后引擎本身不慢， 这是任务书要的「最干净的一组对照」； · **产品形态十题墙钟 217.9 / 282.4 = 0.77**、答案首字 0.74、工具段 0.45、 token 0.98。快在调得少（20 次 vs 40 次、27 轮 vs 38.5 轮），不是单次更快； · **A 线反过来 1.19** —— 没有组合工具时 HCA 退回 akshare 的三连， 工具段 54.8 s → 157.4 s。与 I1 A 线的 1.18 两轮独立复现。 还差多少：只剩 q3 / q5 的模型段（+1.54 s / +3.59 s）。q5 那个量与 I3 的 +3.84 s 对得上（P2-23 拿到第二份证据），已知杠杆 U-23 只够补五分之一。 出字段慢 1.52 倍不是可优化项 —— 写了 1.74 倍的字，每字耗时反而更快。 hook 单独直测：每次工具调用 32.8 ms、每个提示 16.5 ms，十题合计约 0.85 s（0.4%）。 连带更正三处既有结论：对比文档 §3 开头改写并新增 §3.-2、§3.-1 的墙钟与 token 两行打上注记、I1 报告开头补一段口径更正（四维分不受影响，两边是对称地没有 用户上下文；速度与成本偏乐观）。待办池加 P1-28 / P2-24 / P2-25 / P2-26， P2-23 与 U-23 补新证据。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
docs(m2): 用真实渲染的系统提示验证开关生效；M2 报告骨架与证据落盘 - coding-bias-analysis §2.3：从 /live 第一帧 snapshot dump 出模型真正看到的 三条 system 消息（20855 / 7199 / 1450 字符）。同时证实四件事：四个开关真的 生效（TASK TRACKING / ASKING THE USER / MEMORY / DELEGATING 全不见了）、 ATOMGIT TOOLS 在（原标「未测」）、CODE REVIEW 关不掉、没有 GIT STATUS 段 - context hook 的注入用会话 rewind.json 的 prompt_preview 验证（/live 的 user 事件回显的是请求原文，看那个会误以为没注入） - docs/eval/{prompt-size,smoke}/ 原始记录入库（已扫过无密钥） - docs/开发文档/M2-成果与测试报告.md：A/B 与 fork 两节留空待跑 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
docs(m2): 用真实渲染的系统提示验证开关生效；M2 报告骨架与证据落盘 - coding-bias-analysis §2.3：从 /live 第一帧 snapshot dump 出模型真正看到的 三条 system 消息（20855 / 7199 / 1450 字符）。同时证实四件事：四个开关真的 生效（TASK TRACKING / ASKING THE USER / MEMORY / DELEGATING 全不见了）、 ATOMGIT TOOLS 在（原标「未测」）、CODE REVIEW 关不掉、没有 GIT STATUS 段 - context hook 的注入用会话 rewind.json 的 prompt_preview 验证（/live 的 user 事件回显的是请求原文，看那个会误以为没注入） - docs/eval/{prompt-size,smoke}/ 原始记录入库（已扫过无密钥） - docs/开发文档/M2-成果与测试报告.md：A/B 与 fork 两节留空待跑 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(m2): A/B 对比报告出炉 —— 总分比 89.6%，高于 80% 闸门，**不 fork** 23 次计分运行（计划 30 次，当日网关配额只够 23 次，缺口与分布写在报告 §5.1）。 | 维度 | HCA | 基线 | 比值 | |---|---|---|---| | A 准确性 | 23.6 | 24.3 | 97.1% | | B 工具调用正确率 | 23.6 | 22.8 | 103.5% | | C 输出规范符合度 | 25.0 | 23.0 | **108.7%** | | D 步数与耗时 | 13.0 | 25.0 | **52.0%** | | 总分 | 85.2 | 95.1 | **89.6%** | 怎么读这个数（报告 §7.2）：A/B/D 三个维度都被「两边工具清单不一样」 （9 个 MCP vs 4 个）和「两边工作区形态不一样」污染了，**只有 C 维度与这两件事 无关** —— 它量的正是 M2 要回答的问题「不改内核能不能让编码 agent 变成投研 agent」。C 维度 HCA 满分，其中 C1（全中文）与 C4（不给买卖指令）两边 23 次 全部满分，一次都没命中那 20 个操作指令模式。 D 落后不是引擎慢，是工作量不同：q3 是最干净的对照（两边都只调 1 次同一个 market_screen、都答出 313/5237、前 10 只逐行相同），差距只剩墙钟 14.8s vs 9.0s。 不 fork 的第三条理由最实在：这次唯一一处真正影响准确性的缺陷是 P0-11 （工具返回被截断后模型拿记忆补），**那两个补丁开关对它一点帮助都没有**。 报告生成器补了 §5.1「每题每边的有效次数」与 §5.2「排除在计分集之外的运行」， 本批不是均匀 3 次（q2 基线侧只有 1 次），排除的 2 次原始记录一份没删。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(m2): A/B 对比报告出炉 —— 总分比 89.6%，高于 80% 闸门，**不 fork** 23 次计分运行（计划 30 次，当日网关配额只够 23 次，缺口与分布写在报告 §5.1）。 | 维度 | HCA | 基线 | 比值 | |---|---|---|---| | A 准确性 | 23.6 | 24.3 | 97.1% | | B 工具调用正确率 | 23.6 | 22.8 | 103.5% | | C 输出规范符合度 | 25.0 | 23.0 | **108.7%** | | D 步数与耗时 | 13.0 | 25.0 | **52.0%** | | 总分 | 85.2 | 95.1 | **89.6%** | 怎么读这个数（报告 §7.2）：A/B/D 三个维度都被「两边工具清单不一样」 （9 个 MCP vs 4 个）和「两边工作区形态不一样」污染了，**只有 C 维度与这两件事 无关** —— 它量的正是 M2 要回答的问题「不改内核能不能让编码 agent 变成投研 agent」。C 维度 HCA 满分，其中 C1（全中文）与 C4（不给买卖指令）两边 23 次 全部满分，一次都没命中那 20 个操作指令模式。 D 落后不是引擎慢，是工作量不同：q3 是最干净的对照（两边都只调 1 次同一个 market_screen、都答出 313/5237、前 10 只逐行相同），差距只剩墙钟 14.8s vs 9.0s。 不 fork 的第三条理由最实在：这次唯一一处真正影响准确性的缺陷是 P0-11 （工具返回被截断后模型拿记忆补），**那两个补丁开关对它一点帮助都没有**。 报告生成器补了 §5.1「每题每边的有效次数」与 §5.2「排除在计分集之外的运行」， 本批不是均匀 3 次（q2 基线侧只有 1 次），排除的 2 次原始记录一份没删。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(m2): 剩下几处约数与一处笔误也换成实测值 - 「一整轮约 131 万」→ 实测 1 314 569（由 index.json 的 quota_remaining_before 复核） - 「开跑时余 311 万 / 只剩 41 万」→ 3 111 330 / 414 416 - 单次最大开销「639 925」是算错的，实测 669 925（q2-thesis-review-atomcode-r2） Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(i4): 响应时间专项评测跑完 —— 400 次运行、七条同库判据全绿、报告与三份文档同步 四个批次（i4-b 200 次 / i4-a 120 次 / idle-b 40 / idle-a 40），每批开跑前七条判据 全绿、社区版 199 次会话归属登记全部 200、每次运行前恢复两边账本、交错换先手。 三个数： · **空载题 A 线 4.57 s / 4.52 s = 1.01** —— 工具清单拉平之后引擎本身不慢， 这是任务书要的「最干净的一组对照」； · **产品形态十题墙钟 217.9 / 282.4 = 0.77**、答案首字 0.74、工具段 0.45、 token 0.98。快在调得少（20 次 vs 40 次、27 轮 vs 38.5 轮），不是单次更快； · **A 线反过来 1.19** —— 没有组合工具时 HCA 退回 akshare 的三连， 工具段 54.8 s → 157.4 s。与 I1 A 线的 1.18 两轮独立复现。 还差多少：只剩 q3 / q5 的模型段（+1.54 s / +3.59 s）。q5 那个量与 I3 的 +3.84 s 对得上（P2-23 拿到第二份证据），已知杠杆 U-23 只够补五分之一。 出字段慢 1.52 倍不是可优化项 —— 写了 1.74 倍的字，每字耗时反而更快。 hook 单独直测：每次工具调用 32.8 ms、每个提示 16.5 ms，十题合计约 0.85 s（0.4%）。 连带更正三处既有结论：对比文档 §3 开头改写并新增 §3.-2、§3.-1 的墙钟与 token 两行打上注记、I1 报告开头补一段口径更正（四维分不受影响，两边是对称地没有 用户上下文；速度与成本偏乐观）。待办池加 P1-28 / P2-24 / P2-25 / P2-26， P2-23 与 U-23 补新证据。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 |