# 面试准备指南 — Codev / Claude Code 架构知识体系 > 适用场景: 系统设计面试、技术深挖面试、架构师/高级工程师面试 > 目标: 覆盖 AI CLI 代理的核心设计决策、权衡、以及可以引申到通用分布式系统的知识点 --- ## 1. 项目概述 (30-second pitch) **Codev 是什么?** Codev 是从 Anthropic Claude Code fork 出来的 AI CLI 代理 (Agentic Coding Assistant)，运行在终端中，核心能力是理解自然语言开发指令并自动执行多步骤编码任务。 **三个核心差异化:** 1. **多 Provider 支持** — 不锁定 Anthropic API，可接入 OpenAI、NVIDIA NIM、opencode、vLLM 等第三方 LLM Provider 2. **VRM 桌面伴侣 (Friend)** — 带 3D 虚拟角色 (VRM 模型)、情感表情、语音对话能力的同进程桌宠系统 3. **语音对话** — 实时语音输入 (WASM VAD) + STT/TTS，支持端到端语音编程交互 **一句话概括:** > "一个带 3D 桌宠的 AI 编程助手 CLI" --- ## 2. 核心架构问答 (Q&A format) --- ### Q: 解释 Agent Loop (代理主循环) 的工作原理 Agent Loop 是整个系统的核心, 实现在 `src/agent/agent-loop.ts`, 约 88 行核心逻辑, 是一个 async generator。 **5 阶段循环:** ``` [Pre-model Shaping] → [Model Invocation] → [Tool Execution] → [Stop Hooks] → [Continuation Decision] │ ┌─────┘ ▼ 回到 [Pre-model Shaping] ``` 1. **Pre-model Shaping** — 处理 Hook, 注入系统提示词, 计算预算, 决定是否触发压缩 (compact) 2. **Model Invocation** — 调用 LLM, 处理 API 错误和重试逻辑 3. **Tool Execution** — 执行 LLM 返回的工具调用, 收集结果 4. **Stop Hooks** — 处理 Stop 状态 (token 耗尽、tool_use、end_turn、max_tokens) 5. **Continuation Decision** — 决定是否继续循环 **关键数字:** - `queryLoop()` 核心逻辑 ~88 行 - 周边基础设施 (工具注册、权限检查、压缩管道、预算跟踪等) 构成 98.4% 的代码量 - 仅 1.6% 是 AI 决策逻辑 (LLM 调用) **关键特征:** - **追加式状态 (Append-only JSONL)** — 所有消息追加到消息列表, 永不修改历史, 保证可恢复性 - **恢复机制 (Resilience)** — `max_output_tokens` 耗尽时自动重试 3 次, token 限额从 8K 自动升级到 64K - **预算跟踪 (Budget Tracking)** — 每次迭代跟踪输入/输出 token, 超出预算时触发 Reactive Compact --- ### Q: 描述权限系统的 7 种模式和防御纵深 **7 种权限模式 (安全光谱从严格到宽松):** | 模式 | 行为 | 适用场景 | |------|------|----------| | `default` | 每次工具调用都询问用户 | 默认/安全模式 | | `acceptEdits` | 自动批准编辑类工具, 其余询问 | 开发日常 | | `plan` | 仅允许读操作, 拒绝写操作 | 探索/设计阶段 | | `auto` | ML 分类器自动决策 | 有经验的开发者 | | `bypassPermissions` | 完全绕过权限检查 | 调试/开发 | | `dontAsk` | 静默拒绝所有非白名单工具 | 受限环境 | | `bubble` | 权限检查冒泡到父进程 | CI/CD 集成 | **4 层防御纵深:** ``` Layer 1: Pre-filtering (Deny Rules) → 在权限系统外先做 deny 规则匹配, 如 `--dangerously-skip-permissions` 会直接跳过某些工具的白名单检查 Layer 2: Hooks → 用户自定义 hook, 在权限检查前后注入逻辑 → 可实现自定义审批流程 (如通知 Slack) Layer 3: Rule Evaluation → 工具级别的 allow/deny 规则 → 基于工具名称、参数、文件路径的正则匹配 Layer 4: Permission Handler → 最终决策层, 根据 mode 决定是否向用户显示提示 ``` **Auto Mode 的 ML 分类器:** - 两阶段分类: 先判断工具类别 (Read vs Action), 再决定自动批准/询问 - 官方报告的 FNR (假阴性率) 约 17% — 即 17% 本该自动批准的操作被错误地询问用户 - 渐进信任机制: 系统跟踪用户的 auto-approve rate, 从初期 ~20% 增长到熟练用户的 40%+ **核心设计原则:** - **Deny-first**: 任何未明确允许的操作都被拒绝 - **渐进信任**: 用户必须主动证明可靠性才能获得更多自主权 --- ### Q: 上下文压缩的 5 层管道是什么? 上下文窗口有限, 每次消息增长都需要压缩。压缩管道在 `src/agent/compact.ts` 实现。 **5 层压缩管道 (按触发顺序):** ``` Layer 1: Budget Reduction (预算削减) → 截断超出预算的历史消息 → 优先丢弃旧消息, 保留最近的工具调用结果 → 触发条件: 总 token 超过 budget Layer 2: Snip (低价值裁剪) → 移除低价值消息 → 判断标准: 工具输出是否为错误/空/重复 → 保留工具调用本身但删除冗余输出 Layer 3: Micro-compact (微压缩) → 对单条消息做摘要 → 使用 "Condense" 工具让 LLM 对长输出做一句话总结 → 保留原始消息的语义但大幅缩减 token Layer 4: Context Collapse (上下文折叠) → 折叠多轮交互 → 将多轮 tool_use + tool_result 对合并为一段摘要 → 保留最终状态但丢失中间过程 Layer 5: Auto-compact (自动摘要) → 完整语义摘要 → 使用 LLM 对整个对话历史执行摘要 → 最激进, 丢失信息最多, 但 token 节省最大 ``` **核心权衡:** ``` Context Efficiency (节省 token, 降低成本, 减少超预算风险) vs Transparency (丢失细节, LLM 可能遗忘关键上下文) ``` **补充机制:** - **Reactive Compact**: 当 LLM 回复 `max_tokens` 截断时自动触发压缩重试 - **JSONL 持久化**: 压缩只影响发送给 LLM 的上下文, 原始 JSONL 日志完整保留 --- ### Q: 多 Provider 架构如何实现? Codev 支持多种 LLM Provider, 架构分为两层: **Tier 1: Anthropic 原生通道** - 直接使用 Anthropic SDK - 支持 Bedrock、Vertex AI、Foundry 三种部署方式 - 不需要协议转换, 性能最优 **Tier 2: 第三方 Provider 通道** - 使用 **Fetch Override 模式**: 拦截 `globalThis.fetch` 方法 - 将 Anthropic Messages API 请求重写到目标 Provider 的 API 格式 - 协议转换: Anthropic Messages ↔ OpenAI Chat/Responses API **Fetch Override 的工作原理:** ``` 原始调用: client.messages.create({model, messages, tools}) → SDK 内部调用 fetch("https://api.anthropic.com/v1/messages", body) → 被 override 拦截 → 转换 body 格式 (Anthropic → OpenAI) → 发送到目标 Provider (如 https://api.openai.com/v1/chat/completions) → 转换 response 格式 (OpenAI → Anthropic) → 返回给 SDK ``` **模型列表管理:** - `modelStrings()` 缓存所有可用模型 - Provider 切换后必须调用 `clearModelStrings()` 清除缓存 - 模型信息包括: Provider 名、模型 ID、上下文窗口、价格、速率限制 **为什么用 Fetch Override 而不是独立 SDK?** 1. 保持统一的 Anthropic Messages 接口, 不需要为每个 Provider 写独立适配 2. Fetch Override 是无侵入的: 所有依赖 Anthropic SDK 的代码无需修改 3. 对用户透明: 用户配置 Provider 后, 体验完全一致 --- ### Q: Friend VRM 系统为什么设计为同进程 + SSE? Friend 是 Codev 的 3D 桌面伴侣系统, 使用 VRM 模型 (3D 虚拟角色), 具备表情、动作、语音对话能力。 **架构选择:** ``` 同进程 (In-process) └── Agent 直接调用 messageQueueManager.enqueue() └── VRM 渲染在独立窗口 (WebKitGTK) └── SSE 从 Agent 进程推到 VRM 窗口 vs 微服务 (Microservices) └── 需要 IPC/进程间通信 └── 额外的 HTTP Server 部署 └── 开发、调试复杂度高 ``` **选择同进程的原因:** 1. **不需要 IPC/进程间通信** — 直接调用 `messageQueueManager.enqueue()` 即可推送消息 2. **低延迟** — 同进程调用延迟 <1ms, IPC 至少 1-10ms 3. **简化部署** — 用户只需要启动一个二进制文件 4. **状态共享** — Agent 的上下文、配置、日志直接可访问 **选择 SSE (Server-Sent Events) 而不是 WebSocket 的原因:** | 维度 | SSE | WebSocket | |------|-----|-----------| | 通信方向 | Server → Client 单向 | 双向 | | 协议 | HTTP (简单) | WS (复杂, 需要握手机制) | | 适用场景 | LLM → VRM 广播 (推送表情/动作指令) | 双向实时通信 | | 浏览器支持 | EventSource API | WebSocket API | | 自动重连 | 原生支持 | 需手动实现 | - **核心原因**: VRM 系统的主要通信模式是 Agent → VRM 的单向推送 (LLM 决定表情 → 推送到 VRM 渲染), 不存在 VRM → Agent 的实时控制需求, 因此 SSE 完全足够, 且比 WebSocket 更轻量 **WASM VAD 的选择:** - 使用 Silero VAD 的 WASM 编译版本 - 原因: 避免 `onnxruntime-node` 在 Bun 运行时下的 segfault (Bun 的 napi 兼容性问题) - WASM 运行在 WebView 沙箱中, 更稳定 **服务端采音 (Server-side Audio Capture):** - 不依赖浏览器 `getUserMedia` API - 避免 WebKitGTK 的权限弹窗问题 - 使用 PulseAudio/ALSA 直接在服务端录制麦克风 --- ### Q: Feature Flag 系统如何实现死代码消除? Codev 使用编译时 Feature Flag 系统, 实现 `#ifdef` 风格的死代码消除。 **实现位置:** `src/feature/feature.ts` / `feature()` 函数 **工作原理:** ``` 编译时: Bun build --define 注入常量值 if (feature("VOICE_MODE")) { // 注册语音工具 registerVoiceTools(); } else { // 这段代码在编译时被消除 // 不产生任何字节码 } ``` **Bun 编译器的支持:** - Bun 的 `feature()` 函数在编译时做 if/ternary 位置的静态分析 - 当 feature 为 false 时, 整个分支被 DCE (Dead Code Elimination) - 最终二进制中完全不包含被禁用的功能代码 **编译标志:** - 命令行: `--feature=VOICE_MODE` (编译时启用) - 环境变量: `FEATURE_VOICE_MODE=1` (开发时启用) - 两者效果等价 **Feature 统计:** - 总共 48 个实验性 feature - 默认仅 `VOICE_MODE` 启用 - 其他 feature 如: `ANTHROPIC_BRAZIL`, `BYPASS_PERMISSIONS`, `ORGANIZATION_CODE`, `TOOLTIP` 等 **用户类型门控:** - `USER_TYPE='ant'` → Anthropic 内部员工, 解锁内部工具和功能 - `USER_TYPE='external'` → 外部用户, 仅暴露稳定的公共功能 - 在编译时通过 `feature()` 检查, 用户类型相关的内部代码完全不会出现在外部构建中 --- ### Q: 错误恢复策略有哪些? 一个多层级、渐进式的错误恢复系统: ``` 1. max_output_tokens 恢复 └── LLM 输出被截断 (max_tokens 耗尽) └── 自动升级 token 限额: 8K → 16K → 32K → 64K └── 最多重试 3 次, 之后不再尝试 2. 流式回退 (Streaming Fallback) └── SSE 流式连接中断 └── 自动回退到非流式 (non-streaming) 模式 └── 用户感知: 延迟增加但可用 3. Reactive Compact (响应式压缩) └── LLM 回复被 max_tokens 截断 └── 触发自动压缩管道, 压缩上下文 └── 然后重试请求 4. 工具执行重试 └── 工具调用失败 (网络错误、文件权限等) └── 最多重试 3 次 └── 指数退避 (100ms, 200ms, 400ms) 5. API Fallback Provider └── 当前 Provider 不可用 (429/5xx) └── 自动切换到下一个配置的 Provider └── 配置在 environment.json 中 ``` **核心原则:** 3 次重试后不再尝试 — 避免无限重试的资源浪费和用户等待。 --- ## 3. 系统设计面试题 --- ### 设计一个 AI 编程助手的权限系统 **需求分析:** - AI Agent 可以执行文件读写、命令执行、网络请求等敏感操作 - 用户需要控制 Agent 的能力范围 - 不同用户有不同的风险和信任水平 - 需要有审计和回溯能力 **方案设计 (参考 Codev):** ``` 权限光谱: default → acceptEdits → plan → auto → bypassPermissions → dontAsk → bubble 防御纵深: Layer 1: Deny Rules (静态规则) └── 基于文件名/路径/工具名的正则匹配 └── 如: 拒绝所有 /etc/shadow 的读写 Layer 2: Permission Hooks (自定义逻辑) └── 用户可注入 $HOME/.claude/settings.json 中的钩子 └── 如: 检查 git status 后才允许 git commit Layer 3: Mode-based Decision (模式决策) └── 根据当前 mode 决定审批流程 └── auto mode 走 ML 分类器, default mode 询问用户 Layer 4: ML Classifier (自动分类) └── 两阶段: Read vs Action └── 特征: 工具名、参数路径、文件类型、操作频率 └── 输出: allow / ask / deny Layer 5: Execution Sandbox (执行沙箱) └── 工具执行在受限环境 └── 不允许绕过操作系统权限 ``` **面试讨论要点:** 1. **17% FNR 意味着什么?** 每 6 个操作就有 1 个被错误询问用户, 累积使用会造成显著的摩擦。改进方向: 用户反馈闭环、个性化模型微调、规则叠加 ML 的混合系统。 2. **安全 vs 体验的平衡:** 太严格的权限系统用户会绕过 (直接终端操作), 太宽松的系统有安全风险。渐进信任是核心思路。 3. **审计与追溯:** 所有权限决策写 JSONL 日志, 支持后续分析。 --- ### 设计一个实时语音聊天系统 (类似 Friend F2) **需求分析:** - 用户通过语音与 AI Agent 对话 - AI 回复也通过语音播放 - 需要低延迟 (实时感) - 3D 虚拟角色根据对话内容做表情和动作 **架构选择: 同进程 vs 微服务** ``` 方案 A: 同进程 (Codev 的选择) ┌─────────────────────────────┐ │ Agent Process │ │ ┌──────┐ ┌──────────────┐ │ │ │ LLM │ │ Audio Engine │ │ │ │ Call │→│ STT → VAD │ │ │ └──────┘ │ TTS → Mixer │ │ │ └──────────────┘ │ │ ┌────────────────────────┐ │ │ │ VRM (3D Avatar) │ │ │ │ SSE ← Emotion Queue │ │ │ └────────────────────────┘ │ └─────────────────────────────┘ 方案 B: 微服务 ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Agent │──▶│ Audio │──▶│ VRM │ │ Service │ │ Service │ │ Service │ └─────────┘ └─────────┘ └─────────┘ ``` **VAD (Voice Activity Detection) 策略:** - **Silero ML VAD** (WASM): 深度学习模型, 准确率高, 能区分人声和环境噪音 - **Energy-based VAD** (备选): 基于音量的简单检测, 适合信噪比高的环境 - **回声消除**: 播放 AI 回复时关闭 VAD/采音, 避免识别到 AI 自己的声音 **静音策略:** - AI 处理期间: 全程阻断采音 (Press-to-mute) - 用户说完后: VAD 检测到静音 → 触发 LLM 调用 - LLM 回复时: 音频输出独占, 不接收新输入 **Provider 切换:** - STT: Whisper (本地) / Azure Speech / Google STT - TTS: Piper TTS (本地) / ElevenLabs / Azure TTS - 可热切换, 无需重启 Agent **面试追问:** 1. **为什么不用 WebSocket 而是 SSE?** — 因为 VRM 的主要通信是单向推送 (Agent → Avatar), SSE 更轻量, 原生支持自动重连。WebSocket 的额外开销 (握手机制、帧协议) 在单向场景下是过度设计。 2. **为什么不用 onnxruntime-node?** — Bun 运行时对 napi 的兼容性问题, 导致 segfault。WASM 在 WebView 沙箱中运行更稳定。 --- ### 设计多 Provider LLM 代理 **需求分析:** - 支持多种 LLM Provider (Anthropic, OpenAI, NVIDIA, opencode, vLLM) - 统一的接口, 对用户透明 - Provider 切换不影响 Agent 状态 - 优雅降级 (Provider 不可用时自动切换) **方案对比:** ``` 方案 A: Fetch Override (Codev 选型) 优点: - 无侵入: 不修改 SDK, 不修改 Agent 核心逻辑 - 统一接口: 所有代码只认识 Anthropic Messages 格式 - 易于扩展: 新增 Provider 只需要写协议转换层 缺点: - 依赖 fetch API 的完整性 - 调试复杂 (请求经过转换层) - 无法利用 SDK 原生功能 (如 streaming 的细节) 方案 B: Proxy 模式 优点: - 请求在中间层转换, 客户端 SDK 无需修改 - 可以添加缓存、限流、日志 缺点: - 需要额外部署 Proxy 服务 - 增加网络延迟 ``` **协议转换 (Anthropic ↔ OpenAI):** ``` Anthropic Messages → OpenAI Chat/Responses API 关键映射: system: system_message messages: messages (角色映射: assistant/assistant, user/user) tools: tools (function calling 格式) tool_use: tool_calls tool_result: tool (function response) max_tokens: max_tokens stop_sequences: stop OpenAI → Anthropic 逆映射同理 ``` **模型列表管理:** - `modelStrings()` 函数缓存所有可用模型的元数据 - 缓存包括: Provider、模型 ID、上下文窗口、价格信息 - Provider 切换时必须调用 `clearModelStrings()` 清除缓存 - 缓存预热: 启动时异步加载所有 Provider 的模型列表 **面试追问:** 1. **为什么用 Fetch Override 而不是独立 SDK?** — 对现有代码的侵入最小化。所有依赖 Anthropic SDK 的代码 (包括第三方库) 无需任何修改即可支持新 Provider。 2. **如何处理 Provider 特有的能力?** — 有些 Provider 不支持 tool use 或 streaming, Fetch Override 层需要做降级处理。 --- ## 4. 架构权衡 (Trade-offs) --- ### Safety vs. Autonomy (安全 vs 自主性) ``` 安全优先 自主性优先 │ │ │ │ └── default ─ auto ─ bypassPermissions ──┐ │ 更多权限提示 更少摩擦, 更多风险 更安全 更高效 ``` - **37signals 二分法**: 权限提示是摩擦, 但也是安全护栏 - **Codev 的答案**: 渐进信任 + 4 层防御 + ML 辅助 - **面试价值**: 展示对安全架构和 UX 权衡的深度理解 --- ### Context Efficiency vs. Transparency (上下文效率 vs 透明度) ``` 节省 token, 降低成本 保留完整上下文 │ │ │ │ └── budget reduction ─ auto-compact ──┐ │ 更便宜的调用 LLM "记住" 更多细节 更快响应 更高质量的推理 但可能丢失关键信息 但 token 成本更高 ``` - **Codev 的答案**: 5 层压缩管道 + JSONL 持久化 + Append-only 日志 - **关键洞察**: 压缩丢弃的是"发送给 LLM 的内容", 不是"系统记录的内容" - **面试价值**: 展示对 LLM 上下文窗口限制的实际工程理解 --- ### Simplicity vs. Extensibility (简单性 vs 可扩展性) ``` Agent Loop 简单 (~88 行) 扩展机制丰富 │ │ │ │ └── MCP ─ Plugin ─ Skill ─ Hook ──┐ │ 核心逻辑易于理解 4 种不同的扩展点 但扩展需要理解多套机制 灵活但复杂度分散 ``` - **4 种扩展机制:** 1. **MCP** (Model Context Protocol): 外部工具和资源, 标准化协议 2. **Plugin**: 内部插件系统, 可注册新工具和事件监听 3. **Skill**: 可组合的预定义工作流 (如 `/review-pr`, `/commit`) 4. **Hook**: settings.json 配置, 在事件前后注入用户定义逻辑 - **面试价值**: 展示对"保持核心简单, 外围可扩展"架构哲学的理解 --- ### 同进程 vs 微服务 (Friend 系统的选择) ``` 同进程 微服务 │ │ │ │ └── 低延迟 ─ 简单部署 ─ 状态共享 ──┐ │ 适合单用户桌面应用 适合多租户/云端 不需要分布式能力 但部署复杂 开发效率高 但调试困难 ``` - **Codev 的答案**: 同进程, 因为这是一个单用户终端工具, 不是分布式系统 - **何时应该选微服务?** 多用户 Web 服务、需要独立扩缩容、团队分工明确 - **面试价值**: 展示架构选型不是技术炫耀, 而是根据实际场景做合理决策 --- ## 5. 关键数据 | 指标 | 数值 | 说明 | |------|------|------| | 代码量 | ~512K 行 TypeScript | 比 Claude Code 原始 fork 增加约 30% | | 文件数 | ~1,900 | 模块化程度高 | | 测试 | 55 文件, ~22K 行 | 覆盖率低, 无 CI/CD | | 构建产物 | 192-202MB 编译二进制 | 包含 Bun runtime + JS bundle | | JS Bundle | ~20MB | 除去 Bun runtime 后的纯 JS | | Feature Flags | 48 个实验性 feature | 默认仅 VOICE_MODE 启用 | | 权限模式 | 7 种 | default → bubble | | 压缩管道 | 5 层 | Budget Reduction → Auto-compact | | 扩展机制 | 4 种 | MCP / Plugin / Skill / Hook | | AI 工具 | ~60+ | 文件操作、Shell 执行、搜索等 | | Slash 命令 | ~75+ | /commit, /review-pr, /clear 等 | | OpenTelemetry | ~5K 行基础设施 | OSS 构建中全部 stub | | VAD 模型 | WASM Silero VAD | 在 WebView 沙箱中运行 | | 3D 渲染 | WebKitGTK + Three.js | VRM 模型渲染 | --- ## 6. 常见面试追问 ### "为什么不直接用 Vector DB 做记忆?" **答案:** Memdir 文件系统优先, LLM 选择检索。 - Vector DB 引入额外的运维复杂度 (需要部署、索引、备份) - 文件系统 (Memdir) 更简单、可审计、可编辑 - LLM 自己决定检索什么: 不是系统自动做 RAG, 而是通过 `Read` 工具让 LLM 按需读取 memdir 文件 - 适用场景: 单用户桌面工具, 不需要多租户的向量检索 ### "为什么 Agent Loop 这么短?" **答案:** 确定性基础设施在周围, 不是在里面。 - 88 行核心循环只做"编排" (orchestration), 不做"实现" - 工具注册、权限检查、压缩、预算跟踪等逻辑被拆到各自的模块 - 这是**策略模式 (Strategy Pattern)** 的体现: 主循环是稳定的骨架, 各个阶段的行为通过依赖注入可配置 ### "SSE 和 WebSocket 怎么选?" **答案:** 看通信方向。 | 场景 | 推荐 | 原因 | |------|------|------| | Server → Client 单向推送 | SSE | 更轻量, 原生重连, HTTP 友好 | | 双向实时通信 | WebSocket | 全双工, 低延迟 | | 浏览器 → Server 流式上传 | WebSocket | SSE 只支持下行 | Friend VRM 的场景是 Agent → Avatar 的单向广播, SSE 是最优解。如果未来需要 Avatar → Agent 的控制 (如用户点击 VRM 触发动作), 那才需要 WebSocket。 ### "为什么不用 onnxruntime-node?" **答案:** Bun 的 napi 兼容性问题。 - `onnxruntime-node` 依赖 Node.js 的 napi (Native API), Bun 的实现在某些版本存在 segfault - WASM 版本在 WebView 沙箱中运行, 稳定性更好 - 这不是架构决策, 是运行时兼容性的务实现实 ### "Compaction 丢失信息怎么办?" **答案:** JSONL 持久化, append-only 日志。 - 压缩只影响"发送给 LLM 的上下文", 不影响"系统记录的数据" - 所有原始消息追加到 JSONL 文件, 永不删除 - 如果 LLM 需要回看被压缩的内容, 可以通过 `Read` 工具读取 JSONL 日志 - 这也是为什么压缩管道有 5 层: 渐进式压缩, 先丢最不重要的, 最后才做语义摘要 ### "如何测试一个 AI Agent 系统?" **答案:** 测试 AI Agent 的挑战和策略。 - **黄金数据集**: 录制真实的 Agent 交互 (JSONL), 用作回归测试 - **Tool 模拟**: Mock 工具执行结果, 测试 LLM 的决策逻辑 - **快照测试**: 对比压缩/权限决策的输出快照 - **E2E 测试**: 实际调用 LLM (成本高, 运行慢), 只在关键路径使用 - **当前状态**: 55 个测试文件, ~22K 行, 但无 CI/CD — 这是需要改进的地方 ### "这个系统的最大弱点是什么?" **诚实回答 (面试加分项):** 1. **测试覆盖不足** — 无 CI/CD, 55 个测试文件对 ~512K 行代码几乎不可靠 2. **Monorepo 膨胀** — ~1,900 文件, 构建产物 200MB, 模块边界模糊 3. **ML 分类器的 17% FNR** — 虽然可以接受, 但累积使用会造成显著摩擦 4. **同进程限制扩展** — Friend 系统无法独立部署, 难以支持多实例 5. **依赖 Bun 生态** — Bun 的稳定性影响整个系统 (napi 问题, undici fetch 兼容性等) --- ## 附录: 面试应答策略 ### 当被问到不熟悉的问题时 - "这个问题我没有直接经验, 但基于我对系统的理解, 我会这样分析..." - **STAR 法则**: Situation → Task → Action → Result - 始终展示**架构思维**: 不管多小的功能, 都能讨论 trade-off ### 描述项目的三种粒度 ``` 30 秒: "一个带 3D 桌宠的 AI 编程助手 CLI" 2 分钟: "Codev 是从 Claude Code fork 的 AI CLI 代理, 核心增强是多 Provider 支持和 VRM 桌面伴侣, 采用同进程 + SSE 架构实现低延迟语音对话" 10 分钟: 深入 Agent Loop、权限系统、压缩管道、Friend 架构 ``` ### 把 Codev 经验映射到通用系统设计 | Codev 概念 | 通用系统设计概念 | |------------------|-------------------| | Agent Loop | Event-driven orchestration | | 4 层防御纵深 | Defense in depth | | 5 层压缩管道 | Multi-stage data processing pipeline | | Append-only JSONL | Event sourcing / Write-ahead log | | Feature Flag 死代码消除 | Compile-time configuration | | Fetch Override | API Gateway / Proxy pattern | | Provider 切换 | Circuit breaker / Fallback | | 渐进信任 | Zero-trust architecture (gradual) | | 同进程 Friend | Embedded system / Co-located deployment | | SSE 推送 | Publisher-Subscriber pattern (one-way) | --- > 最后更新: 2026-06-22 > 基于 Codev main branch (commit 835ff5a)