- Unify ToolResultEnvelope (output vs content) for built-in tools - Fix shell.run AsyncGenerator consumption in ToolRegistry.call/streaming - Scheduler: consume WorkerResult.status instead of marking all running tasks completed - WorkerProcess/WorkerManager: surface exit events and generate failed/cancelled result - MainAgent: integrate ContextAssembler, Chinese destructive regex, ArchitectureDesigner impact gate - run.ts: pendingConfirmation flow, dispatch extracted, .air files filtered from /results - CapabilityRegistry wired into RuntimeApp and ServiceRegistry; DoctorService uses it - release.ts: findRepoRoot/findBun, run air e2e + depcruise + runtime regression - New gates: release-critical-gates, CLI run command regression - 14/14 e2e gates pass; 3/3 release dry-run pass Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
8.3 KiB
Executable File
8.3 KiB
Executable File
集成测试阶段 GLM-5.1 审查结果
审计日期: 2026-06-05 项目: AirCoding V1.0.0 Alpha 审计模型: GLM-5.1 审计模式: 四视角交叉审计(系统架构师 / 开发工程师 / 真实用户 / 测试工程师)
0. 前置验证
TypeScript 类型检查: PASS (contracts/runtime/llm/toolchain-cpp/workers 5 包通过) E2E Gates: 13/13 PASS (但与用户场景脱节)
1. 系统架构师审查报告
架构核心链路评估
已建立完整闭环:
- CLI → MainAgent → Scheduler → Worker → LLM → Tools → File
- 7-package TypeScript monorepo 结构完整
- NDJSON over stdio IPC 协议正确
- 5 Domain Invariants 基本遵守
关键架构偏离
| 设计 | 实际 | 影响 |
|---|---|---|
| FR-014 上下文分层 | MainAgent.chat_with_llm 无 ContextAssembler 集成 | 用户追问 100% 幻觉 |
| ToolResultEnvelope | BuiltInToolRegistrar 18 工具用 content 而非 output | Worker IPC 返回空 |
| AsyncGenerator 解包 | shell.run 生成器未处理 | shell 命令 100% 失败 |
| 事件驱动 | Scheduler MONITORING 轮询 200ms | 假完成风险 |
架构死代码
- ArchitectureDesigner - MainAgent.classify() 从未调用
- PermissionEngine - ToolRegistry.call() 未逐调用评估
架构师结论
V1.0.0 Alpha 架构核心可通,但存在 4 个 P0 结构性缺陷,不建议发布。
2. 开发工程师审查报告
P0 问题 (阻断发布)
P0-1: MainAgent.chat_with_llm 无 ContextAssembler 集成
- 位置: packages/runtime/src/agents/main/MainAgent.ts:102-122
- 问题: chat_with_llm() 仅有硬编码 system prompt,无项目上下文注入
- 影响: 用户追问"我的项目有哪些文件" → LLM 答"我无法访问文件系统"
P0-2: BuiltInToolRegistrar 18 工具返回形状不一致
- 位置: packages/runtime/src/tools/BuiltInToolRegistrar.ts:180-438
- 问题: create_real_executor 返回
{ content }而非{ output } - 影响: WorkerManager 第 191 行
result.output || result.error || {}返回空对象 - 受影响工具: fs.stat, process.kill, git.worktree.create, git.merge_workspace, project.scan, project.profile.write, cpp.detect, cpp.cmake.configure, cpp.build, cpp.test, cpp.static.cppcheck, cpp.clangd.query, debug.run, debug.parse_logs, gui.screenshot, network.capture, permission.request, doctor.run
P0-3: shell.run 生成器未解包
- 位置: packages/runtime/src/tools/shell/index.ts:35
- 问题: createShellExecutor 返回
async function*(AsyncGenerator),ToolRegistry.call() 直接调用返回生成器对象而非 ToolResultEnvelope - 影响: shell 命令 100% 失败
P0-4: 危险操作确认门路由断裂 (新发现)
- 位置: packages/cli/src/commands/run.ts:115-120
- 问题: MainAgent.classify() 返回 CONFIRMING 状态后,run.ts 直接 console.log 确认消息并 rl.prompt(),用户输入的 y/n 永远到不了 MainAgent.handle_confirmation()
- 影响: 删除/覆盖文件等破坏性操作无防护
P1 问题 (重要缺陷)
| ID | 问题 | 位置 | 状态 |
|---|---|---|---|
| P1-1 | Scheduler MONITORING 早判完成 | Scheduler.ts:252-260 | 未修复 |
| P1-2 | classify_via_llm API 不匹配 | MainAgent.ts:185 | 已修复 |
| P1-3 | TUI 无文本输入路径 | tui/index.ts | 部分修复 |
| P1-4 | 多文件任务协调缺失 | ExecutorRole.ts | 部分修复 |
| P1-5 | false-positive 成功 banner | ask.ts:182-186 | 新发现 |
P2 问题 (改进项)
- 资源泄漏: run.ts progressInterval 未清理
- 空 catch 块: scanDir 丢弃所有错误
- history/session 输出无辨识度
- doctor 语义误导 (FAIL vs WARNING)
3. 真实用户测试报告
测试结果汇总
| 测试 | 命令 | 结果 | 观察 |
|---|---|---|---|
| 初始化 | air init |
✅ PASS | 创建 .air/ 目录和 project.json |
| 简单文件创建 | air ask 创建 hello.txt |
✅ PASS | 文件创建成功 |
| 上下文追问 | air run: 我的项目有什么文件? |
❌ FAIL | LLM 答"无文件系统访问" |
| C++ 多文件 | air ask 用 C++ 写 hello world |
⚠️ PARTIAL | main.cpp + CMakeLists.txt 创建,但 cpp.build 报错 |
| Shell 执行 | air ask 列出当前目录 |
❌ FAIL | shell.run 返回 undefined |
| 诊断 | air doctor |
⚠️ PARTIAL | 5/6 通过,但 project_structure 报 FAIL(模板文件缺失) |
| 历史记录 | air history |
⚠️ PARTIAL | session_id 无辨识度 |
用户最痛 3 个问题
- shell.run 工具完全坏死 - 任何编译/运行命令都失败
- 工具报错但 LLM 说成功 - 用户无法区分真实成功和幻觉
- 追问上下文失效 - LLM 每次都"失忆"
用户体验评分: 4.5/10
4. QA 测试矩阵
测试矩阵
| Test | 描述 | 结果 | 严重度 |
|---|---|---|---|
| T1 | TypeScript 类型检查 | PASS | - |
| T2 | E2E Gates (13门) | 13/13 PASS | - |
| T3 | 简单文件创建 | PASS | P1 |
| T4 | C++ 多文件生成 | PARTIAL | P1 |
| T5 | 上下文追问 | FAIL | P0 |
| T6 | Shell 执行 | FAIL | P0 |
| T7 | 工具结果形状验证 | FAIL | P0 |
E2E Gates 盲区分析
当前 13 个 gate 全部基于静态检查:
- tsc 类型检查 ✓
- depcruise 依赖检查 ✓
- 单元测试 ✓
- 存根数量检查 ✓
缺失的 gate:
- ToolResultEnvelope shape 验证 (output 字段)
- Answer-mode context 验证
- Shell.run 功能验证
- Worker IPC 往返完整性验证
- 危险操作 confirmation 验证
5. 与前两轮审查对比
三轮审查问题对比
| 问题 | MiniMax-M3 | Deepseek | GLM-5.1 (本轮) |
|---|---|---|---|
| P0-1: chat_with_llm 无上下文 | ❌ 未修复 | ❌ 未修复 | ❌ 未修复 |
| P0-2: 18 工具结果形状不一致 | ❌ 未修复 | ❌ 未修复 | ❌ 未修复 |
| P0-3: shell.run 生成器未解包 | ❌ 未修复 | ❌ 未修复 | ❌ 未修复 |
| P0-4: 确认门路由断裂 | ❌ 未发现 | ❌ 未发现 | ⚠️ 新发现 |
| P1-1: Scheduler MONITORING 竞态 | ❌ 未修复 | ❌ 未修复 | ❌ 未修复 |
| P1-2: classify_via_llm API | ❌ 未修复 | ❌ 未修复 | ✅ 已修复 |
| P1-5: false-positive 成功 | ❌ 未发现 | ❌ 未发现 | ⚠️ 新发现 |
根因分析
三轮审计得到相同的 P0 问题,说明:
- 问题已被明确识别,但修复优先级不足
- E2E gates 无法捕获这些功能性问题
- 缺少端到端集成测试验证
6. 修复优先级矩阵
必须立即修复 (P0, 阻塞发布)
| # | 问题 | 影响范围 | 修复方向 |
|---|---|---|---|
| P0-2 | 18 工具返回 content 而非 output | 50% 工具通过 Worker 返回空 | BuiltInToolRegistrar.ts: 将 { content } 改为 { output } |
| P0-3 | shell.run AsyncGenerator 未解包 | shell 命令 100% 失败 | shell/index.ts: 解包 generator 或改为返回 Promise |
| P0-1 | chat_with_llm 无项目上下文 | 追问 100% 幻觉 | MainAgent.ts: 集成 ContextAssembler |
| P0-4 | 确认门路由断裂 | 破坏性操作无防护 | run.ts: 将 y/n 输入路由到 handle_confirmation() |
需要修复 (P1)
| # | 问题 | 修复方向 |
|---|---|---|
| P1-1 | Scheduler MONITORING 早判完成 | 检查任务实际状态而非仅 has_running() |
| P1-5 | false-positive 成功 banner | 工具报<EFBFBD><EFBFBD>时应显示错误而非成功 |
建议改进 (P2)
- TUI 文本输入路径统一
- history/session 输出可辨识
- doctor 语义准确性
7. 综合结论
发布建议: 不推荐发布
4 个 P0 问题阻塞 V1.0.0 Alpha 发布:
- shell.run 完全坏死 - 用户无法执行任何编译/运行命令
- 50% 工具返回空结果 - cpp.detect / project.scan / doctor.run 等全部失效
- 上下文追问 100% 幻觉 - 用户无法询问项目状态
- 破坏性操作无防护 - 删除/覆盖文件无确认
修复后验证清单
- shell.run 能执行
ls,echo等基础命令 - cpp.detect / project.scan 返回实际项目信息
- 追问"我的项目有哪些文件"返回真实文件列表
- 删除文件时弹出确认,用户确认后执行
核心教训
E2E gates 检查代码质量,用户场景验证功能可用性。两者正交,不能互相替代。
审计模型: GLM-5.1 审计时间: 2026-06-05