Vibe Coding / Agentic Flow 面试题集

注：本题集不存在唯一标准答案。文中的“参考答案”主要用于启发思考，方便读者建立自己的判断框架。

适用对象：每天使用 Claude Code、Codex 等 agentic CLI 工具的开发者，尤其是希望把 AI 编程从“人机聊天”升级为“工程化工作流”的用户。

目录

1. 背景知识篇 2. 细节梳理篇 3. 工作流篇 4. 系统设计篇：开放思辨 5. 概念哲学篇：开放思辨 6. 附录：推荐学习路径 7. 参考链接

一、背景知识篇

Q1. 什么是 /command？它和 skill 的区别是什么？什么时候用 command，什么时候用 skill？

参考答案

/command，也就是 Slash Command，是 Claude Code 早期的扩展机制。用户可以在 .claude/commands/ 下放置 .md 文件，然后通过在对话中输入 /command-name 来触发。本质上，它是“用户主动调用的一段 prompt 片段”。

Skill 是新一代扩展机制，一般位于 .claude/skills/<name>/SKILL.md、~/.claude/skills/ 或 plugin 中。它和 command 的主要区别在于：

实际使用中，几乎所有新场景都应优先考虑 skill。尤其是当你希望模型在合适时机自动启用某套规程，或者需要附带脚本、示例文件、模板时，skill 更合适。

command 仍然可以用于少数简单场景，例如团队遗留资产，或者某些必须由用户显式触发的一行 prompt 包装。但新项目中不建议继续重度依赖 command。

Q2. 什么是 agent？什么情况下使用 agent，什么情况下使用 skill？

参考答案

Agent，尤其是 Sub-agent，可以理解为一个拥有独立 system prompt、独立上下文窗口、独立工具白名单的“小型 Claude”。在 Claude Code 中，sub-agent 通常通过 .claude/agents/<name>.md 定义，由主对话派发任务。Sub-agent 完成任务后，只把总结返回给主对话，中间的大量搜索、读取、日志输出不会污染主上下文。

Skill 则是一套指令或规程。它不开新上下文，而是在当前对话里指导 Claude 接下来怎么做。

一个简单判断原则是：

• 如果任务是在告诉 Claude 一套工作规程，例如“提交前先跑 lint 和测试”，用 skill。
• 如果任务会产生大量工具输出，例如读几十个文件、跑很多 grep、分析日志，用 agent。
• 如果任务只是读取一个已知文件，主对话直接读即可，不必开 agent。
• 如果任务需要把完整推理过程留在主对话里，就不要交给 sub-agent。

Q3. Sub-agent 是什么？Sub-agent 之间可以互相通信吗？

参考答案

Sub-agent 的核心特征是：独立上下文、独立工具集、只向主对话返回 summary。

默认情况下，sub-agent 之间不能直接通信。它们的通信模型更像星型结构：主对话是中心节点，所有 sub-agent 都只和主对话通信。如果 A agent 的发现需要传给 B agent，通常由主对话转述。

这种设计的好处是：

• 信息汇聚到主对话，便于用户审计。
• 避免 agent 之间形成不可控的循环对话。
• 防止上下文和工具调用成本失控。

实验性的 Agent Teams 模型可能引入同级 agent 之间的消息通信能力，但那已经是另一套更复杂的协作模型。

Q4. Agent Team 和 Sub-agent 最大的区别是什么？

参考答案

Sub-agent 更像“雇一个临时工去做一件事，回来汇报”。它通常是一次性的，主对话发起任务，sub-agent 执行，然后返回 summary。

Agent Team 更像“组建一个长期协作的小团队”。每个 teammate 可以有独立角色、独立上下文，并可能通过消息机制互相沟通。

现实中，大多数日常开发任务用 sub-agent 已经足够。Agent Team 更接近多 agent 协作研究方向，适合复杂项目，但也更难调试。

Q5. MCP 是什么？它和 API 接口的区别是什么？

参考答案

MCP，即 Model Context Protocol，是一种把外部工具、资源和 prompt 以标准格式暴露给大模型客户端的协议。一个 MCP server 可以声明自己提供哪些 tools、resources、prompts，客户端连接后可以自动发现并调用。

裸 API 和 MCP 的区别可以这样理解：

类比一下：API 是“每家形状不同的接口线”，MCP 更像“面向 LLM 工具调用的 USB-C”。

它的核心价值不只是传数据，而是让工具具备“自描述能力”：模型可以知道工具叫什么、参数是什么、是否可写、是否需要确认，从而推理什么时候调用、怎么调用。

Q6. Sub-agent 可以再派生它自己的 sub-agent 吗？

参考答案

通常不可以。Sub-agent 不应再启动自己的 sub-agent。

这样设计主要是为了避免三个问题：

1. 无限递归：如果 agent 可以无限派生 agent，调用树很容易失控。 2. 信息不可审计：嵌套太深后，主对话难以知道每层到底发生了什么。 3. 上下文和成本爆炸：每层 agent 都可能拥有独立上下文，费用和延迟会迅速上升。

如果确实需要“嵌套委托”，更好的做法是：

• 让主对话扁平化地派发多个 sub-agent。
• 在 sub-agent 内部使用 skill 组织步骤。
• 对极复杂任务，考虑 Agent Team，但要设置明确的边界和预算。

二、细节梳理篇

Q7. CLAUDE.md / AGENTS.md 是什么？加载顺序和优先级如何？

参考答案

CLAUDE.md 和 AGENTS.md 可以理解为项目或用户级别的“持久 prompt 注入”。它们用于声明 agent 每次启动时都应该知道的规则，例如代码风格、测试命令、禁止修改的文件、提交规范等。

常见层级包括：

建议不要把它写成项目介绍文章，而要写成 agent 必须遵守的硬规则。例如：

• 修改代码前先读相关测试。
• 不要改 .env 和密钥文件。
• 完成后必须运行 npm run typecheck。
• 不要新增不必要的依赖。

一个实用经验是：每个文件尽量控制在 200 行以内。太长的内容应拆分为独立文档，再通过引用方式组织。

Q8. Hooks 是什么？列举几种常用 hook 场景。

参考答案

Hook 是在 Claude Code 或类似 agentic 工具生命周期事件上注册的确定性回调。它不是由模型“记得去做”，而是由工具运行时强制执行。

常见事件包括：

• 工具调用前：例如阻止危险命令。
• 工具调用后：例如文件修改后自动格式化。
• Session 开始时：例如注入当前 git 状态。
• 停止时：例如发桌面通知。

常用场景包括：

Hooks 的价值在于“确定性”。Prompt 可能被模型忽略，但 hook 是工具层面的约束。

Q9. Permission Mode 有哪些？各自适合什么场景？

参考答案

Permission Mode 决定 agent 在执行文件读写、命令运行、外部工具调用时是否需要用户确认。

原则上，越接近生产环境，权限越应保守；越接近一次性实验或隔离沙箱，权限可以更开放。

Q10. /compact 时，哪些上下文会保留，哪些会丢失？

参考答案

/compact 的本质是压缩对话上下文。它会保留部分高优先级信息，但不会完整保留历史工具调用细节。

通常会保留或重新注入的内容包括：

• System prompt。
• 项目级规则文件，例如 CLAUDE.md。
• 用户或项目 memory。
• 对话摘要。
• 部分高优先级 skill 描述。

容易丢失的内容包括：

• 历史工具调用的完整输出。
• 曾经读过但没有写入持久文件的细节。
• 只存在于对话里的临时约定。
• 某些按需加载工具的完整 schema。

实践建议是：不要把长期约束只放在聊天里。重要规则应写入 CLAUDE.md、AGENTS.md、memory、PROGRESS.md 或项目文档。

Q11. Plugin 和 Skill 的关系是什么？

参考答案

Skill 是一个能力单元；Plugin 是一个打包发布的扩展包。

一个 plugin 可以包含：

• 多个 skills。
• sub-agent 定义。
• hooks。
• MCP server。
• LSP server。
• 二进制工具。
• 默认 settings。

可以这样理解：skill 是零件，plugin 是装好的工具箱。团队内部如果有一套稳定的 AI 编程流程，就可以把它打包成 plugin，让新成员一键安装。

Q12. 什么是 ToolSearch / Deferred Tools？为什么要这样设计？

参考答案

Deferred Tools 的核心思想是：启动时不把所有工具的完整 schema 全部塞进上下文，而是先让模型知道工具名。等模型真的要用某个工具时，再通过 ToolSearch 或类似机制加载详细参数结构。

这样设计的原因包括：

1. 节省 token：大型 MCP server 可能有几十甚至上百个工具，全部 schema 非常占上下文。 2. 降低注意力噪声：不相关工具长期挂在 prompt 里，会干扰模型决策。 3. 按需加载：只有真正需要时才加载详细说明。

代价是第一次使用某个工具时可能多一次 round trip，但总体上更划算。

三、工作流篇

Q13. 接到一个中等复杂度的新功能任务，应该怎么用 agentic 工具拆解？

参考答案

一个典型流程可以是：

1. 先进入 plan mode，只读探索代码，不急着改。 2. 用 Explore sub-agent 并行搜索相关文件，找入口、数据流、测试位置。 3. 由主对话或 Plan sub-agent 产出 TDD 风格方案：验收标准、测试用例、最小实现、验证策略。 4. 用第二个模型或 review agent 做 cross-model review，补盲点。 5. 在关键设计岔路上询问用户，而不是擅自决定高影响改动。 6. 退出 plan mode，进入可编辑模式。 7. 先写或更新测试，再实现功能。 8. 实现后跑相关测试、typecheck、lint。 9. 最后用 review skill 或 code-review agent 自查。

这个流程的重点不是“多开 agent 显得高级”，而是把探索、设计、实现、验证、复盘拆开。

Q14. 什么时候应该开 sub-agent，什么时候不该？

参考答案

应该开 sub-agent 的情况：

• 要读 10 个以上文件做调研。
• 要跑大量 grep、find、日志分析。
• 要做独立代码 review 或安全 review。
• 要并行处理多个无依赖子任务。
• 工具输出会很长，不希望污染主上下文。

不应该开 sub-agent 的情况：

• 任务只需要 1–3 个工具调用。
• 只是读取一个已知路径。
• 任务需要频繁和用户确认。
• 你希望完整推理过程保留在主对话中。

一句话：sub-agent 适合“重搜索、重读取、重日志”的任务，不适合“短平快”的任务。

Q15. 怎么避免主对话上下文被污染？

参考答案

可以从几个方面控制：

• 大量读取和调研交给 Explore sub-agent，只让它返回 summary。
• 长命令输出用 head、tail、grep 收敛，不要把几千行日志直接塞进对话。
• 重复性流程封装成 skill，而不是每次重新粘贴一大段规则。
• 阶段性完成后及时 /compact。
• 重要长期信息写进 CLAUDE.md、AGENTS.md、memory 或 PROGRESS.md。
• 不要让 agent 反复读同一个文件；文件状态应通过 diff、测试和版本控制确认。

核心原则是：上下文不是越多越好，而是信噪比越高越好。

Q16. 代码出了 bug，如何用 agentic 工具调试？

参考答案

比较稳妥的流程是：

1. 不要急着改代码，先复现 bug。 2. 写一个能稳定失败的最小测试或最小用例。 3. 确认测试确实失败，证明你理解了问题。 4. 用 Explore 找出 bug 发生路径上的相关文件。 5. 提出假设，然后逐个验证，而不是猜测式打补丁。 6. 修复后跑相关测试。 7. 最后跑全量或关键验证命令。 8. 如果 agent 连续多次修不对，停止当前上下文，换思路或让另一个模型独立诊断。

Agent 调试最怕的是“边猜边改”。没有可复现用例，模型很容易把代码越改越乱。

Q17. 在多人协作仓库里，如何让 agentic 工作流团队化？

参考答案

团队化的关键是把个人经验沉淀为仓库资产。

共享层可以包括：

• 仓库根目录 CLAUDE.md / AGENTS.md：团队硬规则。
• .claude/skills/：共享工作流。
• .claude/agents/：共享 sub-agent。
• .claude/settings.json：共享 permission、hooks、工具白名单。
• PR 模板：要求说明 AI 参与的关键决策和验证命令。

个人层可以包括：

• CLAUDE.local.md：个人偏好，通常不提交。
• .claude/settings.local.json：个人权限覆盖。

更进一步，可以把团队通用能力打包成 plugin，统一安装、统一升级、统一维护。

四、系统设计篇：开放思辨

以下问题没有标准答案，重点是训练取舍框架和风险意识。

Q18. 设计一个 agentic 低代码平台，优先考虑哪些原则？

讨论方向

首先要确定 source of truth。到底是 agent 生成的代码为准，还是低代码 DSL 为准？二者双向同步看似美好，实际很容易变成工程地狱。

还要考虑：

• 可逆性与版本控制：agent 一次改 50 个组件后，必须能 diff、revert、review。
• 沙箱与权限分级：平台用户的 agent 不能直接访问数据库，必须经过权限网关。
• 上下文供给：业务知识如何进入 agent？靠用户写规则，还是从已有文档自动提炼？
• 失败可观测性：agent 调用第三方 API 或 MCP 失败后，必须能回放。
• 关键决策确认：不要替代用户思考，高影响决策必须显式确认。
• 成本可见：每个操作的 token、API 调用、时延都要可见。

好的 agentic 低代码平台不是“魔法按钮”，而是一个可审计、可回滚、可组合的工程系统。

Q19. 设计企业内部 MCP 网关，如何处理权限、审计、限流？

讨论方向

一个企业级 MCP 网关至少要处理以下问题：

• 权限：不同角色能看到不同工具。只读角色不应该看到 delete_* 工具的 schema。
• 审计：每次 tool call 都记录 user、agent_id、参数、返回大小、耗时和结果状态。
• 限流：限制同一用户或同一 agent 的 QPS、并发数和日调用量。
• 数据脱敏：返回给 agent 前先处理 PII、密钥、内部敏感字段。
• 降级策略：后端服务异常时返回 structured error，而不是无限等待。
• 版本管理：tool schema 变更要有版本号，避免旧客户端突然失效。
• 租户隔离：不同团队、不同项目的工具和数据必须隔离。

MCP 网关的核心不是“接入更多工具”，而是“安全地让模型使用工具”。

Q20. 多 agent 协作模型应该选择星型还是网状？为什么？

讨论方向

星型结构的优点是清晰、可控、易审计。主对话是中心，所有 sub-agent 都向它汇报。缺点是主对话会成为瓶颈，并行度有限。

网状结构更接近真实团队，多个 agent 可以互相沟通，理论上并行度更高。但问题也明显：

• agent 之间可能循环对话。
• 上下文容易爆炸。
• 责任边界不清。
• 调试难度大幅提升。

现实中，大多数任务星型已经够用。只有在复杂多角色任务中，才值得尝试网状协作，而且必须配合消息预算、线程上限、对话图可视化和强审计机制。

更深一层的问题是：多 agent 协作的 ROI 是否真的高于“一个更强的单 agent”？如果模型能力继续增强，多 agent 编排可能只在少数复杂场景中有稳定价值。

Q21. 设计一个 AI 安全 review agent，要避免哪些坑？

讨论方向

安全 review agent 不能只看 diff。很多安全问题出现在调用链和上下文中，而不是当前改动的几行代码里。

还要避免：

• 盲信测试通过：测试覆盖不到的地方，往往才是漏洞高发区。
• 自己执行攻击命令：review 阶段应尽量只读，避免 review agent 变成攻击面。
• 追求零误报：安全 review 宁可合理误报，也不要漏掉高危问题。
• 缺乏分级：必须区分 P0、P1、P2，帮助人工聚焦。
• 不可解释：不能只说“unsafe”，要说明为什么危险、影响范围是什么、如何修。

更稳妥的做法是：一个模型 review，另一个模型 cross-check，再由人工做最终判断。

Q22. 设计长期记忆机制，如何决定记什么、不记什么？

讨论方向

应该记的内容包括：

• 用户反复纠正过的代码风格。
• 项目级硬约束。
• 常用命令。
• 容易忘记但长期有效的工程信息，例如端口号、测试入口、文档位置。

不应该记的内容包括：

• 一次性的临时对话。
• 含有敏感数据的内容。
• 已经过时的 bug 状态。
• 不确定是否长期有效的猜测。

长期记忆还需要更新机制：写入时合并，避免重复；定期清理过时条目；允许用户审查、编辑、删除。跨项目共享也要谨慎：偏好可以跨项目，项目知识不应随便跨项目。

五、概念哲学篇：开放思辨

Q23. 为什么应该保持 context 简单？一个塞满信息的 prompt 不是更好吗？

讨论方向

Context 的价值不在于长，而在于信噪比。

塞满信息会带来几个问题：

• 注意力稀释：关键规则被大量无关信息淹没。
• 成本上升：每次推理都要处理更多 token。
• 延迟增加：长上下文通常意味着更慢的响应。
• 可调试性下降：出问题时，很难定位是哪条规则冲突。
• 演化困难：复杂 prompt 像一团 spaghetti，越改越乱。

好的 context 不是“少信息”，而是“只放当前任务真正需要的信息”。

Q24. Agent 应该主动还是被动？什么时候该问用户，什么时候该自己决定？

讨论方向

判断标准可以看三个维度：

1. 行动是否可逆：可逆的本地改动可以自决；不可逆的 push、delete、send email 必问。 2. 影响半径：只影响本机可以更主动；影响团队、生产、客户必须谨慎。 3. 不确定度：agent 自己没把握时应该问，而不是赌。

真正好的 agent 不是“什么都问”，也不是“什么都不问”，而是问对问题：关键岔路问，鸡毛蒜皮不打扰。

Q25. Vibe Coding 到底是 hype，还是范式革命？

讨论方向

Hype 派会说：这只是更智能的自动补全。复杂项目里 agent 仍会犯低级错误，维护成本被低估。

范式派会说：编程的主单位正在从“行 / 函数”上升到“意图 / 约束”。工程师的角色从打字员变成架构师、审稿人、系统设计者。

比较稳妥的中间立场是：它确实是范式变化，但不是 1:1 替代。它会放大高水平工程师的能力，因为他们能给出更好的 spec 和 review；也会放大低水平使用者的破坏力，因为他们可以更快地产出垃圾代码。

关键追问是：

• 如果 agent 写代码，知识在哪里沉淀？仓库、文档、测试，还是个人大脑？
• 代码 review 的重要性是否会超过写代码本身？
• 初级岗位和编程教育会如何变化？

Q26. 一个 agent 反复改不对一个 bug，应该让它继续试，还是关掉自己上？

讨论方向

如果 agent 已经反复尝试同一种错误解法，说明上下文可能被污染了。继续让它烧 token，往往只会把死胡同挖得更深。

更好的做法是：

• 给 agent 设定尝试上限，例如连续 3 次失败就停。
• 停止当前修补循环，重新整理最小复现、日志、失败测试。
• 换一个模型做独立诊断。
• 必要时人工接手关键路径。

Agent 卡住通常不是“推理不够努力”，而是信息缺失、测试不清、上下文污染或方向错误。

Q27. 为什么 TDD 在 agentic 工作流里比传统工作流更重要？

讨论方向

Agent 容易自信地写错。它可能编 API、编字段、编返回值。测试是少数能客观裁判它是否真的完成任务的机制。

TDD 对 agentic 工作流尤其重要，因为：

• 测试是和 agent 沟通的契约。
• 失败测试给 agent 提供明确反馈循环。
• 测试把模糊需求变成可执行规约。
• 验收测试能防止“看起来完成了，其实没完成”。

但也要注意：不要完全让 agent 自己写测试、自己写实现、自己宣布通过。关键验收测试和安全测试最好由人写，或由另一个模型独立 review。

Q28. “agent 写的代码可读性差”怎么办？这是工具问题还是用法问题？

讨论方向

两者都有。

工具侧，模型确实容易过度抽象、过度防御、过度注释。用法侧，如果用户不给约束、不 review、直接接受 first try，垃圾代码一定会堆积。

可操作的改法包括：

• 在 CLAUDE.md 或 AGENTS.md 中写明可读性硬规则。
• 限制函数长度、命名风格、注释风格。
• 把“简化 / 重构 / 删冗余”作为独立步骤。
• 用 code-review skill 强制 agent 自审。
• 对关键模块要求人工读一遍 diff。

如果完全不读 agent 写的代码，本质上就是把生产代码外包给一个不会被追责的实习生。

Q29. “我让 agent 跑了一整晚，它做了什么我看不懂”——这是 agent 的问题，还是用户的问题？

讨论方向

两边都有责任。

工具方应提供可观测性：文件 diff、命令日志、关键决策点、失败记录、阶段性总结。

用户方也要设置边界：不要无约束地让 agent 跨夜乱跑。长任务应拆成阶段，每个阶段有明确目标、权限范围和 checkpoint。

越长的自主任务，越需要强约束。完全无人监督的长跑 agent，有点像“无人监督的初级实习生 + sudo 权限”，在生产环境中风险很高。

Q30. Agentic 工具最终会让程序员这个职业消失吗？

讨论方向

更可能的情况不是“程序员消失”，而是“程序员的抽象层次上升”。

会被削弱的是那种只负责把明确 spec 翻译成代码的岗位。仍然重要的是：理解需求、拆分系统、判断对错、承担责任、维护长期架构。

未来可能更重要的角色包括：

• Agent 架构师：设计 agent 协作图、skill 库和上下文策略。
• AI 审稿员：高速 review agent 输出。
• Context 工程师：把领域知识结构化为 agent 可消化的形式。
• 工程负责人：决定哪些任务可以自动化，哪些必须人工把关。

历史类比是：编译器没有让程序员消失，但让手写汇编的人大幅减少。AI agent 也可能类似：不是取消工程师，而是把工程师推向更高抽象层。

六、附录：推荐学习路径

入门阶段

先读官方文档，跑通最基础能力：

• 项目规则文件：CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• Codex / Claude Code 的基本权限模式

目标不是记概念，而是知道它们分别解决什么问题。

进阶阶段

把自己最常做的 3 件事封装起来，例如：

1. 生成 commit message。 2. 写 PR 摘要。 3. 修改代码后自动跑测试和 typecheck。

这一步的关键是从“我每次都对 AI 重复说一遍”升级到“把流程沉淀为项目资产”。

高级阶段

为团队或个人项目建立一套 agentic workflow：

• CLAUDE.md / AGENTS.md：长期规则。
• skills/：可复用规程。
• agents/：调研、review、debug 等专用角色。
• hooks/：确定性约束。
• PROGRESS.md：长任务状态记录。
• TASKS.md：任务拆解。

专家阶段

开始研究更复杂的问题：

• hooks 在 PreToolUse 上的权限决策。
• MCP 网关和企业权限模型。
• 多 agent 协作的消息预算和审计。
• 长任务 overnight workflow 的 checkpoint 设计。
• 如何让测试、文档、规则文件共同成为 agent 的可靠上下文。

七、参考链接

• Claude Code Docs：llms.txt
• Claude Code Docs：Hooks Reference
• Claude Code Docs：Automate workflows with hooks
• OpenAI Codex：Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex：Installation Docs
• OpenAI Cookbook：Codex Prompting Guide