| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat(m2/eval): q5 基线侧试跑；查出新闻 MCP 的 date 字段全是空串（P1-17） q5 这一对（n=1，不计分）：HCA 7 轮 13 次调用 / 62.6s / 199k token / 2172 字符； 基线 2 轮 3 次调用 / 16.4s / 33k token / 550 字符。两边都覆盖三只票、都带来源 与日期。这一对正好把 D 维度那道闸要处理的张力摆出来了 —— 基线快 4 倍省 6 倍， HCA 多花的 10 次调用换来宏观 / 异动 / 交易所公告的覆盖面，该不该给分由 A 维度 决定，这就是「A < 12/25 时 D 记 0」的用意。 顺带查出 watchlist_stock_news 一次返回 30 条、**30 个 "date":""** —— 日期 字段全是空串（两边同一个 MCP，都受影响）。模型只能从东方财富 URL 里推日期， 两次都推对了但那是运气；q5 的评分点「每条情报带日期」因此变成考「会不会推」。 记入待办池 P1-17（修在 apps/api，属导入来的既有问题，排 M3）。 audit_numbers.py 相应认识「紧凑写法命中」（2026-09-19 ↔ 20260919），免得把 合理推断报成编造 —— 基线 q5 的 4 个「没找到」由此归零。补 1 条单测，107 → 108。 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): 报告补 §4.2（q5 试跑排除超时风险）与 §4.3（两边工具清单本来就不一样） §4.2 —— 用当天剩余额度跑了最吃工具的 q5（HCA 侧）：7 轮、13 次工具调用全成功、 9/9 MCP、墙钟 62.6 秒、199 152 token。正式批次的 900 秒上限有充分余量， 超时风险排除。按 q1 + q5 外推，30 次约 240 万 token。 §4.3 —— **读这份 A/B 之前必须知道的前提**，零 token 取证、三处交叉核对： 社区版 1.2.0 的 opencode.jsonc 只注册 4 个 MCP（watchlist / portfolio / uzi / hunter_user），HCA 注册 9 个。不是我们把基线配坏了：仓库里从 1.2.0 镜像取的 那份、测试机上另一条链路的真实部署、我们的评测基线，三份逐字一致。 所以总分是「agent 引擎 + 工具清单」的合成，**只有 C 维度与工具清单无关** —— 结论一节会把「总分比」与「只看 C 维度的比」分开列，并点明 fork 闸门 （总分 ≥ 80%）因此偏松。 顺带把 q3 的基准答案零 token 取好了（matched 313 / universe 5237， 前 10 只带 ROE 与 PE-TTM），A1/A2 对着它打分；正式批次跑完再取一次同口径对照。 另记一条：market_screen 的脚本语言没有 fundamental() 函数，要筛基本面得直接写 扫描源字段名 —— 模型能不能自己找到这条路正是 q3 要考的。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
docs(m2): 报告补 §4.2（q5 试跑排除超时风险）与 §4.3（两边工具清单本来就不一样） §4.2 —— 用当天剩余额度跑了最吃工具的 q5（HCA 侧）：7 轮、13 次工具调用全成功、 9/9 MCP、墙钟 62.6 秒、199 152 token。正式批次的 900 秒上限有充分余量， 超时风险排除。按 q1 + q5 外推，30 次约 240 万 token。 §4.3 —— **读这份 A/B 之前必须知道的前提**，零 token 取证、三处交叉核对： 社区版 1.2.0 的 opencode.jsonc 只注册 4 个 MCP（watchlist / portfolio / uzi / hunter_user），HCA 注册 9 个。不是我们把基线配坏了：仓库里从 1.2.0 镜像取的 那份、测试机上另一条链路的真实部署、我们的评测基线，三份逐字一致。 所以总分是「agent 引擎 + 工具清单」的合成，**只有 C 维度与工具清单无关** —— 结论一节会把「总分比」与「只看 C 维度的比」分开列，并点明 fork 闸门 （总分 ≥ 80%）因此偏松。 顺带把 q3 的基准答案零 token 取好了（matched 313 / universe 5237， 前 10 只带 ROE 与 PE-TTM），A1/A2 对着它打分；正式批次跑完再取一次同口径对照。 另记一条：market_screen 的脚本语言没有 fundamental() 函数，要筛基本面得直接写 扫描源字段名 —— 模型能不能自己找到这条路正是 q3 要考的。 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 个月前 | |
feat(m2/eval): q5 基线侧试跑；查出新闻 MCP 的 date 字段全是空串（P1-17） q5 这一对（n=1，不计分）：HCA 7 轮 13 次调用 / 62.6s / 199k token / 2172 字符； 基线 2 轮 3 次调用 / 16.4s / 33k token / 550 字符。两边都覆盖三只票、都带来源 与日期。这一对正好把 D 维度那道闸要处理的张力摆出来了 —— 基线快 4 倍省 6 倍， HCA 多花的 10 次调用换来宏观 / 异动 / 交易所公告的覆盖面，该不该给分由 A 维度 决定，这就是「A < 12/25 时 D 记 0」的用意。 顺带查出 watchlist_stock_news 一次返回 30 条、**30 个 "date":""** —— 日期 字段全是空串（两边同一个 MCP，都受影响）。模型只能从东方财富 URL 里推日期， 两次都推对了但那是运气；q5 的评分点「每条情报带日期」因此变成考「会不会推」。 记入待办池 P1-17（修在 apps/api，属导入来的既有问题，排 M3）。 audit_numbers.py 相应认识「紧凑写法命中」（2026-09-19 ↔ 20260919），免得把 合理推断报成编造 —— 基线 q5 的 4 个「没找到」由此归零。补 1 条单测，107 → 108。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
feat(m2/eval): q5 基线侧试跑；查出新闻 MCP 的 date 字段全是空串（P1-17） q5 这一对（n=1，不计分）：HCA 7 轮 13 次调用 / 62.6s / 199k token / 2172 字符； 基线 2 轮 3 次调用 / 16.4s / 33k token / 550 字符。两边都覆盖三只票、都带来源 与日期。这一对正好把 D 维度那道闸要处理的张力摆出来了 —— 基线快 4 倍省 6 倍， HCA 多花的 10 次调用换来宏观 / 异动 / 交易所公告的覆盖面，该不该给分由 A 维度 决定，这就是「A < 12/25 时 D 记 0」的用意。 顺带查出 watchlist_stock_news 一次返回 30 条、**30 个 "date":""** —— 日期 字段全是空串（两边同一个 MCP，都受影响）。模型只能从东方财富 URL 里推日期， 两次都推对了但那是运气；q5 的评分点「每条情报带日期」因此变成考「会不会推」。 记入待办池 P1-17（修在 apps/api，属导入来的既有问题，排 M3）。 audit_numbers.py 相应认识「紧凑写法命中」（2026-09-19 ↔ 20260919），免得把 合理推断报成编造 —— 基线 q5 的 4 个「没找到」由此归零。补 1 条单测，107 → 108。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 |