补齐真实体验回归测试：context window、工具静默调用与 compact 失败必须自动暴露

[zhuqingyv]

Problem

用户手动运行 MA 很快暴露两个问题，但 npm test 仍然全绿，说明现有测试主要证明代码可运行，不能证明 agent 真实好用：

1. DeepSeek V4 Flash/Pro 实际支持 1M context，但 MA 状态栏显示 ctx: 25k/33k，并在 25157/24576 tokens 时报 active context still too large after compaction。
2. Agent 连续调用大量工具时，用户只看到工具列表，没有阶段性解释；最后 compact 失败后直接显示系统错误，缺少“已做了什么、卡在哪、下一步怎么办”的可读总结。

这类问题不能靠普通单元测试发现。需要把真实用户体验、provider capability、compact failure、tool-only silence 纳入 benchmark/CLI 自动化验收。

Evidence

• 当前代码默认 context window 写死为 32768：src/agent.ts 的 DEFAULT_CONTEXT_WINDOW = 32768。
• compact 阈值是 contextWindow * 0.75，所以截图中的 24576 正好来自 32768 * 0.75。
• DeepSeek V4 Flash/Pro 官方 API 文档标注 CONTEXT LENGTH 1M，base URL 为 https://api.deepseek.com：https://api-docs.deepseek.com/quick_start/pricing
• 当前动态 context 探测只查 LM Studio native API /api/v0/models，DeepSeek/OpenAI-compatible provider 不会得到正确窗口。
• src/cli/hooks/useAgent.ts 对 tool:call 只更新 thinking 状态；如果模型只返回 tool calls 且没有 text/token，用户只会看到工具调用流。
• compactActiveContext 在下一轮请求前失败时，任务直接 task:failed；模型没有机会输出最终解释，用户只看到系统错误。
• AGENT.md 已经明确：dry-run、unit tests、mock adapter 不能作为 agent 质量证据；真实 L3 claim 需要 real CLI adapter + real judge。
• mnemo 既有结论：MA benchmark 不是“几乎全通过”；L0/L1 通过，L2 未过 gate，L3 全量未过 gate。

Architecture Direction

把“agent 好不好用”的 source of truth 从 npm test 扩展为三层：

• Provider Capability Source：统一维护 provider/model 能力表，至少包含 contextWindow、maxOutputTokens、tool-call 支持、vision 支持；DeepSeek V4 Flash/Pro 默认 1_000_000，配置允许覆盖。
• Runtime Trace Source：benchmark runner 记录用户可见事件、工具序列、compact 前后 token、provider attempt/retry、task failure reason、final text。
• User-Visible UX Source：CLI/PTY 层验证用户实际看到的内容，不只看内部 event。工具很多时必须有阶段性说明；失败时必须有可读总结。

目标不是“让测试更复杂”，而是让自动化能抓到用户一眼就能发现的问题。

Reuse / Mature Solution Plan

• 复用现有 benchmark runner、RunTrace、event-collector、hard assertions、L2/L3 task schema，不新造一套测试框架。
• 复用现有 node-pty devDependency 做 CLI 级 user-visible smoke，专门覆盖 TUI 输出和状态栏，不用 mock agent。
• 复用现有 judge-client，让 L2/L3 对“解释是否充分、失败是否可执行、工具过程是否让用户理解进展”做独立裁判。
• provider capability 先用项目内 registry；外部事实只引用官方 provider docs，避免从 /models 响应臆测不存在的字段。

Implementation Checklist

• 新增 provider capability registry，例如 src/provider/capabilities.ts：
  • DeepSeek deepseek-v4-flash / deepseek-v4-pro：contextWindow=1_000_000。
  • LM Studio 仍优先使用 /api/v0/models.max_context_length。
  • 用户配置 model.contextWindow 优先级最高。
• 修改 bootstrap/context usage：
  • 非 LM Studio provider 不再沉默回落到 32768。
  • 状态栏显示 request tokens / compact threshold / model window，避免 77% 看起来像还能继续但实际已失败。
• 新增 agent 过程说明机制：
  • 连续 N 个工具调用或超过 M 秒没有 text/token 时，发 progress/text 事件。
  • 内容必须基于已完成工具结果生成，不允许空泛“正在努力”。
  • compact 失败、provider 失败、max loop 失败时，必须输出用户可读失败总结。
• 扩展 benchmark trace：
  • contextWindow、compactThreshold、maxContextUsed。
  • silentToolStreak：连续 tool calls 中间没有用户可见 text/progress 的最大长度。
  • userVisibleErrorSummary：失败时是否有可读总结。
  • statusBarContextTotal 或 CLI stdout 中的 context window 展示。
• 新增 hard assertions：
  • context_window_min。
  • no_silent_tool_streak。
  • compact_failure_has_user_summary。
  • task_failure_has_actionable_summary。
  • status_bar_context_total_min。
• 新增真实场景任务：
  • L2：DeepSeek config 下 context window 不应显示/使用 33k。
  • L2：tool-heavy repo investigation，连续工具调用中必须穿插进度说明。
  • L2：强制 compact failure，最终必须有可读总结而不是只有 [error]。
  • L3：真实 CLI adapter + fixture repo，使用 PTY 捕获 TUI 输出，验证用户可见状态栏和进度说明。
• benchmark report 增加“体验红线”区块：
  • 是否只通过了 unit/dry-run。
  • 是否真实跑了 MA CLI。
  • 是否真实 judge。
  • 用户可见失败原因和关键截图/stdout 摘要。

Validation

必须同时通过：

npm run build
npm test
npx tsx test/benchmark/runner/index.ts --dry-run
npx tsx --test test/benchmark/runner/__tests__/*.test.ts
npm run benchmark -- --level L2 --task <新增context/tool/compact任务> --adapter test/benchmark/adapters/ma.yaml --runs 1
npm run benchmark -- --level L3 --task <新增CLI体验任务> --adapter test/benchmark/adapters/ma.yaml --runs 1

真实 MA benchmark 必须使用真实模型和真实 judge；不能用 echo/mock adapter 当 agent 质量证据。

Acceptance Criteria

• DeepSeek V4 Flash/Pro 默认 context window 不再是 32768，状态栏不再显示 33k。
• 当工具连续执行较多时，用户至少能看到阶段性进度说明，而不是只看到工具列表。
• compact/provider/max-loop 失败时，最终输出包含：已完成动作、失败点、可执行下一步。
• 新增 benchmark 能在这些问题回归时失败；不能再出现“手动一用就坏，但测试全通过”的误导汇报。
• 报告必须区分：unit pass、dry-run pass、real MA run pass、judge pass。

Non-goals

• 本 issue 不直接优化 agent 推理质量。
• 不要求一次性解决所有 L2/L3 任务通过率。
• 不把 DeepSeek 1M context 当成无限上下文；仍需要 compact，但阈值必须来自正确 capability。
• 不用 mock CLI/echo adapter 证明用户体验。