AI面试八股文-17_17-AI 编程工具与自主 Coding Agent 面试题

pdf版下载链：https://pan.quark.cn/s/9cc742e9c2a8

17 AI 编程工具与 Coding Agent：原理、评测与工程实践

更新： 2026-10-12
难度： ⭐⭐⭐⭐
考点： Coding Agent、Harness、沙箱、权限、Skills、长任务、评测与工具选型

时效说明：具体模型、版本、价格和榜单会频繁变化。本文优先保留“当前状态 + 稳定选型维度”；只有官方来源明确且标注核对日期时才保留动态事实。

📋 目录

1. AI 编程工具生态
2. IDE Agent、CLI Agent 与云端 Agent
3. Coding Agent 核心架构
4. Harness、Sandbox、Skills 与权限
5. 评测与团队落地
6. 动态产品信息如何核验
7. 官方来源

一、AI 编程工具生态

Q1: 2026 年 AI 编程工具市场如何分类？各适合什么场景？

不要背“市场份额前三”，按执行位置和工作流分类更稳定：

选型先问：任务在哪执行、能访问什么、谁批准、怎样验证、失败如何恢复。

Q2: AI 编程工具的核心能力和评测指标是什么？

核心能力：

• 代码补全、对话和多文件编辑；
• 仓库检索、计划与工具调用；
• shell/build/test/debug；
• Git 分支、PR 和代码审查；
• 长任务、后台执行和恢复；
• Rules/AGENTS.md、Skills、Hooks、MCP；
• 沙箱、权限、审批、审计。

指标分四层：

公开 benchmark 只是一部分；团队应使用自己的仓库任务集。

Q3: Claude Code、Cursor、GitHub Copilot 的设计哲学有什么区别？

• Terminal-first：以仓库、命令和自动化为中心，适合复杂后端、调试和脚本化。
• AI-native IDE：以编辑器心流、Tab、可视化 diff 和交互迭代为中心。
• GitHub/IDE platform：以多 IDE、Issue、PR、Actions 和企业治理为中心。

这不是永久能力排名。面试时应从执行环境、上下文、验证、权限、企业策略和成本解释选择。

Q4: Cursor 的 Agent/多文件编辑和 Tab 补全应如何理解？

Tab 属于低延迟预测式编辑；Agent 属于目标驱动的多步工具循环。多文件能力不等于“把全仓库塞进上下文”，通常依赖搜索、索引、规则、打开文件、工具结果和上下文压缩。

实践：

• 用明确范围和验收条件给 Agent 任务；
• 用 Rules/AGENTS.md 放稳定约束，不塞完整文档；
• 大改前建立测试基线和独立分支/worktree；
• 检查 diff、测试和生成文件，不用“Agent 已完成”作为验收。

二、自主 Coding Agent 与代码智能

Q5: 什么是自主 Coding Agent？核心架构是什么？

需求 → 探索仓库 → 计划 → 编辑 → 执行测试 ↑ ↓ └──── 观察/修复/重试 ┘

核心模块：

1. 上下文检索和项目指令；
2. patch/file editor；
3. shell、测试、静态分析、浏览器等工具；
4. Agent loop 和状态机；
5. workspace/container sandbox；
6. permission/approval policy；
7. trace、checkpoint、budget、termination；
8. Git/PR 交付与人工 review。

Q6: Code World Model（CWM）是什么？应如何避免误传？

“代码世界模型”是让模型学习程序状态变化、执行结果和环境反馈的研究方向，不应把它自动等同于某个已发布产品、厂商模型或固定 SWE-bench 分数。

工程上对应三种能力：

• 静态推断：类型、数据流、调用图；
• 动态观察：测试、日志、调试器、运行结果；
• 交互闭环：根据观察修改并再次验证。

面试加分点是说明“真实执行反馈比模型臆测执行结果可靠”。

Q7: FIM（Fill-in-the-Middle）为什么适合代码补全？

FIM 用 prefix 和 suffix 共同预测中间代码，比单纯左到右生成更适合在已有函数中插入逻辑。

典型训练排列包括 PSM（prefix-suffix-middle）和 SPM（suffix-prefix-middle）。实际补全质量还取决于：

• 当前文件和邻近代码选择；
• 语法树/符号信息；
• 跨文件检索；
• 延迟预算；
• 去重、停止条件和用户编辑信号。

FIM 主要解释补全，不足以解释完整 Coding Agent。

Q8: SWE-bench 是什么？怎样正确解读？

SWE-bench 把真实 GitHub issue 对应到仓库状态，Agent 生成 patch，官方 Docker harness 应用 patch 并运行测试，以% Resolved计分。

重要口径：

• 原始、Lite、Verified、Multilingual、Multimodal 是不同数据集。
• Verified 是 500 个经人工筛选的实例。
• 模型分数必须同时标注 Agent/Harness、版本、预算和运行设置。
• 官方 Bash-only 视图用统一 mini-SWE-agent，更适合比较模型；完整榜单比较的是“模型 + Harness 系统”。

Q9: SWE-bench Multimodal、Terminal-Bench 等评测分别测什么？

截至 2026-10-12，Terminal-Bench 官方主页已展示 4.0，因此旧文中的“2.0 最新榜单”已经失效。不要跨版本比较分数。

Q10: Agent 模式和普通补全有什么本质区别？

Agent 必须配套 sandbox、approval、budget、trace 和 verification。

Q11: 团队如何落地 AI 编程工具？

1. 从可回滚、测试较好的仓库试点。
2. 建立真实任务基线，不用自报“效率提升”。
3. 配置最小权限、隐私和数据保留策略。
4. 把编码规范写入可版本化项目指令/Skill。
5. 要求测试、静态扫描和人工 review。
6. 监控成功率、返工、缺陷、成本、审批和安全事件。
7. 分角色推广：补全、Agent、云 Agent 权限不同。

三、产品更新题：从新闻改为核验方法

Q12: 如何判断 Cursor 的某次 “全新 Agent” 发布是否值得关注？

先查 Cursor 官方文档和 changelog，再看是否改变以下稳定能力：

• 本地还是云端执行；
• 支持何种模型和上下文策略；
• 是否能后台/并行运行；
• 如何设置 Rules、Skills、MCP；
• workspace、网络、secret 和 approval 如何隔离；
• 输出是 diff、分支还是 PR；
• 企业能否审计、路由和选择运行位置。

没有官方页面的发布日期、代号和“革命性”描述只放扩展阅读，不作为面试事实。

Q13: Coding Agent 的 Harness 包含什么？

Harness 是模型外部的运行系统：

Instructions + Context + Tools + State + Sandbox + Permissions + Approvals + Verification + Evals + Tracing + Budget

同一个模型在不同 Harness 下表现可能明显不同，但不要随意引用“相差多少个百分点”。应通过受控实验验证：固定模型和任务，仅替换搜索、工具、Prompt、重试或验证策略。

Q14: GitHub Copilot Workspace 和当前 Copilot agent 应如何区分？

旧的 Copilot Workspace 产品新闻不应继续当作当前能力名称背诵。当前官方文档明确区分：

• agent mode in IDE：直接在本地开发环境自主编辑和运行命令。
• Copilot cloud agent：在 GitHub Actions 驱动的云环境中处理任务、修改分支并可创建 PR。
• custom agents / skills / MCP：定制提示、工具和专业工作流。

面试以当前官方命名和执行边界为准。

Q15: 如何处理未经官方确认的 Cursor 代号和并行 Agent 数量？

若官方 Release Notes 无法确认具体代号、数量或上线范围，就删除数字。稳定回答：

• 并行 Agent 的价值在任务可分解性和隔离，而非数量。
• Design-to-code 要用视觉回归、DOM/无障碍和测试验收。
• 云 Agent 要核对代码、构建产物、密钥和网络实际在哪里。
• Enterprise/self-hosted 不应仅凭营销语判断，需看官方部署与数据流文档。

Q16: Claude Code 的版本题应该怎么答？

不要背旧文中的周报编号或孤立版本功能清单。Claude Code 发布频繁，回答方法：

1. 给出官方 Release Notes 核对日期。
2. 只讲已经进入官方文档的稳定能力。
3. 把 preview、plan、research preview 明确标注。
4. 演示时用当前--help、设置 schema 和文档验证命令。

稳定主题包括 Skills、Hooks、subagents、MCP、permissions、sandbox 和 sessions；具体 flag 以当前文档为准。

Q17: “Self-Hosted Cloud Agent” 与本地 Agent 有什么区别？

先画数据流，不看名称：

• Agent 控制面在哪里？
• 仓库 clone、build、test 在哪里执行？
• 模型请求是否离开内网？
• secret 在 setup 还是 agent phase 可见？
• 网络 egress、日志和 artifact 存在哪里？

本地执行、客户 VPC 执行、厂商托管容器是三种不同信任模型。“执行器自托管”不必然意味着“模型和所有数据都不出域”。

四、工具选型与项目配置

Q18: Windsurf、Trae、通义灵码、Cline 等新兴工具如何比较？

不保留易失真的价格和“免费”承诺，按以下维度实测：

1. 补全延迟与接受率；
2. Agent 在本仓库任务集的成功率；
3. 支持的 IDE/CLI/模型；
4. Rules/AGENTS.md、Skills、Hooks、MCP；
5. 本地/云端执行和数据保留；
6. sandbox、network、secret、approval；
7. 团队 SSO、RBAC、审计和策略；
8. 总成本：订阅 + API + 工程维护。

Q19: Cursor Rules 应如何做企业级配置？

旧.cursorrulesJSON 示例不应当作当前标准。应使用 Cursor 官方当前 Rules 机制，并核对项目规则、用户规则、AGENTS.md 和作用域。

Rules 只描述模型应怎样工作，不是安全边界。企业实践：

• 规则短、可执行、按目录分层；
• 指向真实规范和测试命令；
• 把安全强制项落在 lint、CI、权限和 sandbox；
• 用违规测试验证规则是否生效；
• 版本化、owner review、定期清理冲突规则。

Q20: 2026 年主流 Coding Agent 的榜单和价格如何回答？

不在常青文档中复制快照榜单或套餐表。若面试必须给数字：

• 引用官方 benchmark/价格页；
• 写明核对日期；
• 标注 dataset、agent/harness、模型、预算和是否官方验证；
• 不把模型分数写成产品分数；
• 不跨 SWE-bench/Terminal-Bench 版本比较。

选型用本地任务集给出质量—延迟—成本—安全的 Pareto 前沿。

Q21: Claude Code 的稳定能力框架是什么？

截至核对日，官方文档可稳定确认：

• Agent loop 和内置文件/shell/web 工具；
• MCP、Skills、Hooks、subagents；
• permissions、sandbox 和项目配置；
• session resume/fork；
• Python/TypeScript Claude Agent SDK；
• 长时间异步场景可使用独立的 Managed Agents 产品。

Scheduled task、voice、auto mode、teams 等具体可用性应单独查当前产品文档和账户范围。

Q22: 如何实测 Claude Code、Cursor 等工具的 Token 效率和代码质量？

拒绝引用无原始数据的“5.5 倍 Token”或“5 文件阈值”。设计受控实验：

• 固定仓库 commit、任务、模型、最大预算、网络和工具；
• 每个条件多次运行；
• 记录输入/输出/缓存 Token、总成本、墙钟时间；
• 运行相同测试、lint 和人工盲审；
• 统计首次成功、最终成功、返工和方差；
• 保存完整轨迹并注明失败/超时。

上下文窗口上限也不等于实际有效上下文；检索和压缩策略同样重要。

Q23: 如何比较 SWE-bench Multimodal 与 Terminal-Bench 的最新结果？

先锁定版本。SWE-bench 官方页提供不同数据集和 Docker harness；Terminal-Bench 当前主页显示 4.0，并在榜单中同时展示 model、agent、resolution、cost 和 tokens。

比较原则：

• 同版本、同任务集；
• 同 agent/harness；
• 同预算和超时；
• 相同网络与工具权限；
• 区分官方复核和自报；
• 查看任务级日志，不只看平均分。

Q24: Gemini CLI、Codex CLI、Claude Code、开源 CLI 如何选择？

稳定维度：

• 模型和 provider 可替换性；
• 项目指令与 Skills；
• MCP/外部工具；
• sandbox、network 和 approval 默认值；
• headless/CI 支持；
• session/long task 恢复；
• trace 与机器可读输出；
• 本地和云端执行边界。

CLI 不是天然比 IDE 更自主；能力取决于 Harness 和权限。

Q25: Claude Code 与 Cursor 如何组合使用？

一种常见分工：

• IDE 负责快速补全、局部编辑、可视化 diff；
• Terminal/Cloud Agent 负责仓库探索、跨文件改动、测试和后台任务；
• 最终统一通过 Git diff、测试和 review 验收。

组合前要解决同一项目指令来源、并发编辑冲突、模型/成本记录和权限一致性。不要同时让两个 Agent 修改同一 working tree。

Q26: 如何做全景工具选型？

建立加权评分而非五强排名：

总分 = 任务质量 × 权重 + 工作流适配 + 安全合规 + 可观测与治理 + 成本与供应商风险

先用 20～50 个真实任务试点，再决定采购。不同角色可使用不同工具，不必全员统一最高权限的 Agent。

Q27: 开发者调查数据如何使用？

调查数据只说明特定样本和时间的采用/偏好，不等于产品质量。

引用时必须写：

• 调查机构和原始链接；
• 样本数、地区、角色和收集时间；
• 问题措辞；
• “认知、试用、日常使用、付费、满意度”的区别。

没有官方原始报告，不引用具体百分比。

Q28: 跨会话记忆、团队知识库和 PR Review Agent 如何设计？

不要依赖具体产品名。通用方案：

• 稳定约束放 Rules/AGENTS.md/Skill；
• 项目事实从代码和文档检索；
• 决策记录用 ADR/Issue/PR，而不是黑盒记忆；
• session 摘要带来源、时间和失效条件；
• PR review 结合静态工具、diff 证据和行号校验；
• 记忆按租户、仓库、分支隔离，并支持删除。

Q29: Cline、Amazon Q Developer 等适合谁？

• 开源 Agent 适合需要自选模型、自定义执行器和愿意自担维护的团队。
• 云厂商工具适合深度使用该云的开发、迁移、运维和策略场景。

选型时核对代码发送位置、遥测、IAM、区域、模型、插件权限和离线能力，不把“开源”自动等同于“数据不外发”。

五、权限、长任务与 Agent SDK

Q30: 如何阅读 Claude Code 等工具的 Release Notes？

用变更分类法：

版本号本身没有面试价值；能解释变更如何影响权限、可靠性和迁移才有价值。

Q31: Coding Agent 应如何选择 MCP Server？

从最小权限开始：

• 读仓库不一定需要 filesystem MCP，Agent 可能已有本地读工具。
• GitHub/数据库/浏览器 Server 只开放任务所需工具。
• 写操作与只读操作分开凭证。
• 固定版本、审查来源、限制 egress、记录审计。
• 工具描述和 annotations 视为不可信元数据。
• 优先官方 Registry 发现，仍需组织 allowlist。

Q32: Anthropic Managed Agents 与 Claude Agent SDK 有什么区别？

官方定位：

• Claude Agent SDK：Python/TypeScript 库，开发者管理运行环境和生命周期。
• Managed Agents：托管 REST 产品，Anthropic 运行 agent 与 sandbox，适合不想自管长任务环境和 session 基础设施的场景。

选型看数据边界、执行环境、扩展性、网络/secret、状态恢复、合规和成本。不要使用未经当前价格页确认的 session-hour 数字。

Q33: OpenAI Agents SDK 的稳定能力有哪些？

当前官方文档覆盖：

• Agent、tools、handoffs；
• sessions；
• input/output/tool guardrails；
• tracing；
• human-in-the-loop interruptions 和恢复；
• MCP；
• Shell/ApplyPatch 等执行工具；
• Sandbox Agent 与 Shell、Filesystem、Skills capabilities。

注意：本地 Shell/ApplyPatch 的needs_approval不自动提供沙箱；执行器本身必须实施资源隔离。Approval 是决策门，sandbox 是技术边界。

Q34: 为什么 Coding Agent benchmark 容易被 “reward hacking”？

Agent 能访问文件、网络和测试环境，可能利用评测器漏洞、读取答案、修改测试或优化指标而非任务。

可信评测要求：

• Agent 与 grader 隔离；
• 测试和答案不可访问/修改；
• 网络最小化；
• 环境与依赖固定；
• 轨迹审计和异常检测；
• 私有 holdout 与动态任务；
• 人工复核高分样本。

不要传播“所有 benchmark 都已被某论文 100% 攻破”这类无官方原文支持的绝对结论。

Q35: 为什么 AI 编程需要 Workflow Harness 和可控记忆？

Workflow Harness 把随机 Agent loop 变成可治理流程：

plan → implement → deterministic tests → review → approval → PR

记忆只保存可追溯事实：已完成任务、ADR、测试结果、失败模式。它必须有 scope、TTL、来源和删除机制。未经 eval 的自动总结可能固化错误，不能直接当真相。

Q36: 如何处理 “Claude Mythos 未发布 / Project Glasswing” 这类说法？

旧文把未核验传闻写成发布事实，这是错误做法。截至 2026-10-12，应以 Anthropic 官方模型页、API Release Notes 和 System Card 为准；官方资料已经出现 Mythos 系列相关条目，不能继续声称“官方决定不公开发布某旗舰模型”。

安全能力应按正式 System Card 的 threat model、评测方法、访问策略和限制讨论，不引用二手夸张引语。

Q37: 如何评价 “Self-Evolving Agent Model”？

将它作为方法，不把某个模型的参数量、跑分和“自主开发自己”当作无来源事实。

受控自改进流程：

1. 从失败轨迹提出 Harness/Skill 候选修改；
2. 冻结训练集和 holdout eval；
3. 检查 reward hacking、安全回归和成本；
4. 人工批准并版本化；
5. 灰度、监控、可回滚。

没有评测门和发布门的“自进化”是配置漂移。

Q38: OpenAI Codex 与其他 Coding Agent 如何比较？

Codex 当前官方文档应从三层理解：

• 本地 CLI/IDE：OS 级 sandbox、workspace write、approval policy。
• Cloud：隔离容器，setup 与 agent phase 的网络/secret 边界。
• 自定义：AGENTS.md、Skills、MCP 和自动化。

与其他工具比较时统一任务和模型，重点看执行位置、权限、验证、session、PR 交付和团队治理，不复制易变价格。

Q39: 向量数据库插件对 Coding Agent 有什么价值？

它可作为扩展阅读，用于检索大量文档、历史决策或跨仓库知识，但不是每个 Agent 的默认记忆方案。

风险：

• 陈旧摘要覆盖当前代码；
• tenant/repo 泄露；
• 向量命中无来源；
• 删除和权限同步滞后；
• 把所有会话写入长期记忆造成敏感数据积累。

优先让代码、测试、ADR 和官方文档成为事实来源。

Q40: Routines / Scheduled Agent 的核心工程问题是什么？

不管产品名，持久自动化都需要：

• trigger：cron、webhook、GitHub event；
• idempotency 和事件去重；
• 固定代码/Skill/模型版本；
• 独立 sandbox 和短期凭证；
• 预算、超时、取消、重试、死信；
• 输出目标和审批；
• 全链路审计。

无人值守并不意味着无人负责；必须有 owner 和 kill switch。

Q41: Browser/Computer-use Agent 如何评估？

稳定指标：

• 任务完成率和误操作率；
• DOM/无障碍树与纯视觉的适配；
• 登录态、验证码和人工接管；
• 网站条款与数据合规；
• 下载/上传/支付等高风险审批；
• prompt injection 和跨站数据泄露；
• 可重放 trace、截图和动作日志。

具体浏览器扩展或模型新闻只放扩展阅读，未核验不写发布日期和免费承诺。

Q42: “自进化技能树” 怎样落地才安全？

Agent 完成任务后可以提炼候选 Skill，但不能自动信任：

轨迹 → 候选 SKILL.md / script → 静态扫描 → 回归 eval → 人工 review → 版本化发布

Skill 使用渐进披露，脚本依赖应固定版本，执行仍受 sandbox、network 和 approval 约束。对失败 Skill 要能撤回并定位影响版本。

Q43: OpenAI Agents SDK Sandbox Agent 与普通 Agent 有何不同？

Sandbox Agent 将工作区和执行 capability 显式建模。官方文档中的 capability 包括：

• Shell：exec_command，支持时还可write_stdin；
• Filesystem：apply_patch、view_image；
• Skills：发现并 materialize Skills。

Manifest 定义初始 workspace；cwd只影响相对路径解析，不自动收紧整个 workspace policy。仍需配置资源、网络、用户身份和审批。

Q44: AI 能否帮助编写 SIMD/汇编优化？

可以作为扩展阅读，但必须用严格验证替代故事性跑分：

1. 明确 ISA、CPU、编译器和 ABI。
2. 写 property test、fuzz 和边界用例。
3. 与正确基线比对。
4. 用稳定 benchmark、固定频率/绑核、足够迭代统计。
5. 检查未定义行为、越界、对齐和跨平台 fallback。
6. 让人审查可维护性。

性能数字只对特定硬件、编译选项和输入分布有效，不能泛化为“AI 比编译器快 N 倍”。

高频面试话术

我不会按某个月的榜单选 Coding Agent。先用真实仓库任务固定模型、Harness、预算和权限，比较成功率、返工、时长、成本和安全；再根据 IDE/CLI/云端工作流与企业治理选工具。

Coding Agent 的核心不是“模型会写代码”，而是 Harness 能否让它在隔离工作区里查找、修改、执行、观察和验证，并在越权、无进展或预算耗尽时停下来。

Rules 和 Skills 是行为指导，permissions 决定允许什么，sandbox 从 OS/容器层限制能触达什么，approval 决定何时需要人。四者不能互相替代。