Agent 面试通关 / 15

概念考察：Harness Engineering、Context Engineering 与前沿范式

2026 年面试出现了一类新题型：面试官直接问“你了解 X 吗？”——不考具体实现，考的是你对 Agent 领域前沿概念的认知深度和独立思考。

这类题的特点是：答浅了（“听说过”）等于没答，答深了需要展示概念的本质、演进逻辑、与相关概念的区别、以及你的判断。

Harness Engineering

Q：Harness Engineering 是什么？如果让你构建一个 Harness 体系，你会做哪些工作？

来源：快手 AI业务应用设计开发 / 阿里国际 Agent 开发三面 / 阿里千问平台开发复活赛一面 【字节后端开发日常实习二面同题：“harness有了解吗”】【腾讯AI后端开发一面同题：“了解harness嘛，具体是做什么的”】【美团Agent方向面经同题：“harness工程了解吗？主要内容？项目里怎么用？还能补什么？”】【社招五年Go面经同题：“了解harness engineer吗”】【腾讯音乐暑期+日常同题：“有了解过Harness么？有用过Harness么？”】；本轮来源；本轮来源；千问AI研发一面凉经；4399-agent开发面经；(秋招) vivo线下面面经 - Agent开发；本轮追问：在让 AI 开始工作前，你通常会做什么来提高输出正确性和可控性？（度小满 AI 全栈二面）；小鹏二面

新手答：“好像是跟测试框架有关的东西？不太了解。”

高手答：

Harness 的原意是“线束”——把散乱的线缆约束成有序的束。在 Agent 工程中，Harness Engineering 是用工程化手段约束和增强 Agent 行为的系统方法论。核心思想：模型是引擎，Harness 是方向盘、安全带和仪表盘。

具体来说，Harness 包含三层：

如果让我从零构建 Harness 体系，关键工作：

flowchart TB
    subgraph constrain["约束层"]
        C1["定义行为边界\nRules/安全护栏"]
        C2["权限分级\n工具白名单/敏感操作审批"]
        C3["输出校验\n格式检查/合规过滤"]
    end

    subgraph enhance["增强层"]
        E1["Skill 体系\n可复用能力单元"]
        E2["上下文工程\n动态注入/渐进披露"]
        E3["Hooks 自动化\n事件驱动的增强行为"]
    end

    subgraph verify["验证层"]
        V1["可重复环境\n固定镜像/标准输入输出"]
        V2["自动评测\n回归用例/版本对比"]
        V3["可观测性\n全链路日志/决策归因"]
    end

    constrain --> enhance --> verify
    verify -->|"反馈驱动迭代"| constrain

验证层是最容易被忽视但最关键的——没有可重复的评测环境，你不知道 Prompt 改动是变好了还是变差了。我们项目里用 Harness 做三件事：① 回归固定用例（确保改动不破坏已有能力）；② 对比 Prompt/模型版本（量化改进效果）；③ 日志归因（失败时精准定位是约束不够、工具出错、还是模型幻觉）。

可以补充的方向：更接近真实业务的“半合成”评测环境（不是纯 mock，而是真实 API + 可控输入）、对抗性用例（测试安全边界）、成本与性能的持续监控。

差距在哪：新手不了解这个概念，或只知道“跟测试有关”。高手能讲清 Harness 的三层结构（约束/增强/验证）和核心价值（不是规定 Agent 怎么做，而是确保它在安全范围内自主做事），且能给出具体的构建方案。面试官考的是你对“Agent 工程化”这件事有多深的理解——是只会调 Prompt，还是能搭建完整的工程保障体系。

Q：Prompt Engineering、Context Engineering、Harness Engineering 三者有什么区别？

来源：阿里淘天 Agent开发 日常实习一面【字节火山引擎 Managed Agent 一面追问：为开发、测试、运维任务组织 Skills】

新手答：“Prompt Engineering 是写提示词，其他两个不太清楚。”

高手答：

这三个“工程”代表三种关注范围。业界常把关注重点从 Prompt 扩展到 Context、再扩展到 Harness 描述成一种演进，但它们会同时存在，并不是互斥或严格逐层的架构：

为什么会演进：

Prompt Engineering 的瓶颈：模型能力提升后，精心调优的 Prompt 不再是瓶颈——模型已经“聪明到不需要手把手教”。真正的瓶颈变成了“给它什么信息”。

Context Engineering 的瓶颈：即使上下文信息完美，模型仍然会犯错——选错工具、幻觉、死循环、违反安全规则。纯靠上下文无法解决“如何保障行为正确性”的问题。

Harness Engineering 的价值：把保障能力从模型内部（靠 Prompt 约束）转移到模型外部（靠工程体系保障）。模型负责“思考和执行”，Harness 负责“约束、增强和验证”。

一句话总结：Prompt Engineering 解决“说什么”，Context Engineering 解决“给什么”，Harness Engineering 解决“怎么保障”。

差距在哪：新手只知道 Prompt Engineering，对后两者模糊。高手能清晰区分三者的操作对象和责任边界，也知道它们在同一个系统中互相配合。面试官考的是你对 Agent 工程方法论的全景认知。

追问变体：加入 Loop Engineering 作为第四个观察视角（来源：成都某中厂 Agent 产品开发实习）——Loop Engineering 指的是对 Agent 执行循环的退出条件、纠错策略和资源约束进行系统化设计。它通常是 Harness 内部的循环控制部分，不是凌驾于 Harness 之上的独立层级；Harness 还包括上下文装配、工具权限、验证和人工审批等循环之外的能力。

Q：你的项目中体现了哪些 Harness Engineering 的思想？

来源：阿里国际 一面；本轮追问：LLM 和 Harness 你怎么看待？（本轮追问）；面完字节Agent，我人都傻了；美团AI Agent一面；本轮追问：如果把这些 Harness 和你实习中的 Agent 项目结合，你会怎么做？是否有必要替换当前方案？（字节 Agent 秋招一面）

新手答：“我用了 System Prompt 来约束模型行为，算 Harness 吗？”

高手答：

System Prompt 约束只是 Harness 最原始的形态。真正的 Harness Engineering 思想体现在模型外部的工程保障是否系统化。我的项目中有三个层面的体现：

1. 约束层：行为边界不依赖 Prompt 遵循

• 工具调用前有参数校验中间层——模型传的参数必须符合 JSON Schema，不符合直接拦截并给模型结构化错误信息，而不是让模型“自己注意”
• 敏感操作（删除数据、发送消息）有人工确认门控——不是在 Prompt 里写“重要操作要确认”，而是在代码层面强制拦截
• 执行有硬性预算——最大步数、最大 token 消耗、最大工具调用次数，超过直接终止

2. 增强层：能力可复用且按需加载

• 将常见任务的最佳实践抽象为 Skill 文件——新人接手项目不需要重新摸索“怎么做代码审查”或“怎么处理部署”，Skill 里有完整的步骤和约束
• 上下文采用渐进式披露——不是把所有信息塞给模型，而是先给摘要，需要时再展开细节
• 工具描述动态精简——根据当前任务只注入相关工具子集，而不是 100 个工具的描述全部塞进上下文

3. 验证层：改动效果可量化

• 维护了一个核心评测集（50+ 条覆盖主要场景的 case），每次改 Prompt 或切模型后必须跑回归
• 全链路结构化日志——每个决策节点（意图识别→规划→工具选择→执行→生成）都记录输入输出，失败时能精准归因
• 线上有异常模式告警——步数异常多、重复调用同一工具、输出过长等模式自动报警

结合实习项目时，我会先保留现有业务链路，再把参数校验、权限门控、预算、日志和回归评测接入关键节点。是否替换不看概念是否新，而看故障率、延迟、成本和可观测性；若当前方案已稳定，只做增量改造，只有存在明确收益且可灰度回滚时才替换。

差距在哪：新手把 Harness 等同于“写了 System Prompt”。高手能从约束/增强/验证三层展示自己项目中的工程化实践——不是“有没有用 Harness”的问题，而是“你的工程保障做到了什么程度”。面试官考的是你有没有系统性工程思维，以及能否把抽象概念落地到真实项目。

Q：讲一讲 Agent 的发展路线——从以前的架构到现在的 Harness Engineering

来源：阿里淘天 AI应用开发 暑期二面 【淘天 AI 应用开发秋招二面追问：模型升级与 Harness 的边界】；本轮追问：如何看待工具、记忆、权限管理和 Agent Loop 全面插件化的发展趋势？（9.21 蚂蚁二面）

新手答：“以前是 ReAct，现在有了 MCP 和多 Agent。”

高手答：

Agent 架构的演进可以分为四个阶段，每个阶段解决的核心问题不同：

flowchart LR
    A["2023\nPrompt Chain"] --> B["2024 H1\nAgent Framework"]
    B --> C["2024 H2\nAgent + Workflow 混合"]
    C --> D["2025-2026\nHarness Engineering"]

    A1["问题：能力固定\n不够灵活"] -.-> A
    B1["问题：纯自主\n不够可控"] -.-> B
    C1["问题：可控了\n但工程保障缺失"] -.-> C
    D1["解决：全套工程体系\n约束+增强+验证"] -.-> D

阶段 1：Prompt Chain（2023）

代表：LangChain 的 SequentialChain、Flowise 等。本质是预定义的流程图——每个节点做一件事，按固定顺序执行。优点是可预测，缺点是不灵活——遇到预期之外的情况无法应对。

阶段 2：Autonomous Agent（2024 上半年）

代表：AutoGPT、BabyAGI、早期 ReAct Agent。让模型自主规划和执行，不限制路径。优点是灵活，缺点是极度不可控——死循环、幻觉、胡乱调工具。大量团队发现“Demo 很惊艳，上线就崩”。

阶段 3：Workflow + Agent 混合（2024 下半年）

代表：LangGraph 的状态机、Dify 的工作流。核心思想是“确定性环节用 Workflow 控制，不确定性环节嵌入 Agent 节点”。解决了可控性问题，但缺少系统性的工程保障——评测靠手动、约束写在 Prompt 里容易被忽略、没有持续验证机制。

阶段 4：Harness Engineering（2025-2026）

代表：Claude Code 的 Rules/Skills/Hooks 体系、企业级 Agent 平台。核心转变是把 Agent 的保障能力从模型内部迁移到外部工程体系：

• 约束不再写在 Prompt 里（容易被忽略）→ 用 Rules 和权限系统强制执行
• 能力不再硬编码 → 用 Skills 实现可复用、可组合、可热更新
• 质量不再靠手动检查 → 用持续评测管线自动验证
• 行为不再是黑盒 → 用全链路 Trace 实现可观测

本质变化：从“让模型更强”转向“让模型周围的工程体系更强”。模型能力是给定的（你不能改 GPT-4 的权重），但 Harness 是你能控制的——这才是工程师的主战场。

追问：模型能力持续升级，会不会让 Harness Engineering 失去价值？

会被模型能力吃掉的是一部分“教模型怎么思考”的脆弱补丁，例如过度细化的步骤提示和针对单模型缺陷的格式修补；不应交给模型概率遵守的能力不会消失，包括身份与权限校验、工具参数验证、预算、幂等、审计、人工审批、独立验收和回滚。模型更强通常会扩大可处理任务范围，也会让错误副作用更大，因此 Harness 的重点会从“扶着模型完成步骤”转向“定义可放权边界并验证结果”。

不要靠观点判断边界。固定任务集和模型版本，分别移除 Prompt 约束、上下文检索、Skill、确定性 Hook 和验证器做消融；比较任务成功率、违规率、成本和人工接管率。只有某层在新模型上不再提供稳定增益，且移除后风险没有上升，才有证据简化它。

插件化能降低耦合并支持按场景替换，但不等于把控制权外包：工具、记忆、权限和 Loop 应通过稳定接口接入，明确状态、超时、版本兼容、错误恢复与审计；权限插件必须在工具调用前独立校验，记忆插件区分读写范围，Loop 仍由 Harness 设预算、终止条件和人工接管，并用回归评测验证替换后的行为。

差距在哪：新手只能说出技术名词（ReAct、MCP），但说不清“为什么从 A 演进到 B”。高手能讲清每个阶段解决的问题和暴露的新瓶颈，形成“问题→解法→新问题→新解法”的递进逻辑。面试官考的是你对 Agent 技术演进有没有结构化的认知——不是背时间线，而是理解每一步“为什么”。

Vibe Coding vs Harness

Q：Vibe Coding 和 Harness，你更偏向哪种路线？为什么？

来源：字节 TikTok 实习后端AI开发 一面

新手答：“Vibe Coding 就是用 AI 写代码吧，Harness 我不太清楚。”

高手答：

这两个代表了 AI 辅助开发的两种哲学——不是非此即彼，而是适用于不同阶段和场景：

我的判断：两者不是替代关系，而是开发生命周期的不同阶段：

flowchart LR
    A["Vibe Coding\n快速原型"] --> B["验证可行性"]
    B --> C["Harness Engineering\n工程化落地"]
    C --> D["持续迭代"]
    D -->|"探索新方向"| A

• 0→1 阶段用 Vibe Coding：快速试错，验证想法是否可行。此时约束太多反而降低创造力
• 1→N 阶段用 Harness：把验证通过的方案工程化——加约束保安全、加 Skill 保复用、加评测保质量

如果只能选一个，我选 Harness——因为面试官问这个问题的背景是“你要加入我们的生产系统”。生产系统的核心需求是可控性和可维护性，Vibe Coding 无法满足。但我不会否定 Vibe Coding 的价值——它在探索阶段是最高效的工具。

差距在哪：新手不了解两者的区别，或只认识 Vibe Coding。高手能讲清两种路线的适用场景和本质差异，且能结合面试岗位的需求给出有判断力的回答。面试官考的不是“你选哪个”，而是“你能不能看清两者的本质，并在具体场景下做出合理选择”。

前沿概念辨析

Q：你会关注 Harness、Context Engineering 这类行业热点吗？你觉得它们有什么优势劣势？

来源：腾讯 CDG 产品经理（技术背景）一面 【腾讯音乐追问：“为什么没用过这些来辅助提升效率？”】【DeepSeek（深度求索）- Agent 开发 / Harness 方向（独角兽）追问：你最近在关注 Agent 领域的什么新技术？】；美团Agent一面凉经

新手答：“关注，我看到过这些词。”

高手答：

会关注，而且我认为需要区分“概念创新”和“营销术语”——Agent 领域概念更迭很快，但真正改变工程实践的不多。我的判断标准是：这个概念有没有解决一个以前解决不了的问题？

这些概念的共同趋势：从“让模型更强”转向“让模型周围的工程更强”。这说明行业进入了工程化阶段——模型能力已经足够，瓶颈在于怎么可靠地把能力落地。

我没有盲目追每个热词，而是看它是否能解决我当前项目的具体痛点。比如 Harness 中的评测管线思想，我已经在项目里落地了（每次改 Prompt 跑回归评测集）；但 A2A 协议我还没有使用场景，所以只保持关注不深入投入。

追问补充：需求文档和技术方案应作为高价值上下文源纳入，但不宜默认全文塞入。先按任务检索相关章节，结合版本、权限和生效状态过滤，并保留文档来源；实现方案需与代码、配置等运行时事实交叉验证，避免文档过期导致错误决策。

差距在哪：新手只能说“看到过这些词”。高手对每个概念有独立判断（解决什么问题、有什么局限），且能说清自己的取舍逻辑。面试官考的是你对行业动态的批判性思考能力——不是追热点，而是能辨别哪些值得投入。

Q：Harness、Hermes 这种比较新的 Agent 设计了解吗？

来源：字节 大模型算法 暑期实习 二面；本轮追问：你了解的 DeepSeek Harness 和 Pi Agent 分别是什么？（字节 Agent 秋招一面）

新手答：“Harness 听说过，Hermes 不了解。”

高手答：

两者代表了 Agent 设计的两个不同方向——外部约束 vs 内部增强：

Harness（外部约束工程）：

核心思想是“模型不变，改周围的工程体系”。通过 Rules、Skills、Hooks、评测管线等外部机制，约束和增强 Agent 行为。优势是不需要训练模型，任何团队都能快速搭建；劣势是完全依赖模型的指令遵循能力，模型“不听话”时约束可能失效。

Hermes（内部能力增强）：

Hermes 是 Nous Research 的开源微调模型系列，核心思想是通过训练让模型内化 Agent 能力——工具调用格式、多轮推理模式、结构化输出等能力直接训练进模型权重。优势是模型本身就具备 Agent 行为，不需要复杂的外部框架；劣势是需要训练资源，且模型能力固定后不易调整。

两者的关系：

Harness（外部）和 Hermes（内部）不矛盾——最佳实践是结合：
  - 用 Hermes 类模型获得更强的基础 Agent 能力
  - 用 Harness 工程体系保障行为可控和可验证
  - 模型提供能力上限，Harness 提供安全下限

DeepSeek Harness 可理解为围绕模型组织提示、上下文、工具调用和执行循环的运行时外壳，重点是把模型能力接入可控流程；Pi Agent 则是偏轻量、可编程的代码 Agent，强调最小核心、终端交互以及通过工具和扩展组合能力。二者都不是单独的基础模型。

差距在哪：新手只知道名字。高手能区分两者的设计哲学（外部约束 vs 内部增强），且理解它们是互补而非替代的关系。面试官考的是你对 Agent 设计范式的全面认知。

协议标准化：MCP

Q：MCP 是什么？它解决了 Function Calling 的什么根本问题？

来源：蚂蚁集团智能体与大模型应用二面 / 钉钉一面 【蚂蚁Agent开发一面追问：“有了FC是否可以没有MCP”】【高德实习一面同题：“MCP协议的完整调用过程”】【字节实习Agent开发一面追问：“MCP和Function Calling的关系”】【阿里 Agent Infra 一面题库同题】；阳光电源 AI应用开发工程师 一面；本轮追问：MCP和普通本地Tools很像，MCP解决了Tools的什么问题？（斑头雁（Agent实习生面试一面））；阿里云 ai应用开发 一面；本轮追问：你说到 function call、tool 和 MCP，讲讲这几个概念。（9.18 虾皮shopee chatbot研发实习一面凉经）；9.24 普通の快手一面（发券）；腾讯 260824 一面面经；字节业务中台AI全栈面经——日常实习；美团一面全栈开发日常实习面经

新手答：“MCP 就是 Anthropic 出的一个调用工具的协议，跟 Function Calling 差不多。”

高手答：

MCP（Model Context Protocol）和 Function Calling 解决的是不同层面的问题——把两者等同是最常见的误区。

Function Calling 解决的是“模型怎么表达工具调用意图”：

模型输出一段结构化 JSON（工具名 + 参数），宿主程序解析后执行。FC 是模型侧的能力——让模型能以结构化格式表达“我想调用什么”。

MCP 解决的是“工具怎么被发现、连接和管理”：

MCP 是一个连接协议——定义了 Agent（Client）和工具提供者（Server）之间的通信标准。类比：FC 是“会说话”，MCP 是“有电话网络”。

为什么“有了 FC 还需要 MCP”：

FC 的根本问题是不可复用——每个 Agent 应用都要自己实现工具的发现、鉴权、调用、错误处理逻辑。A 团队写了一个“查天气”工具，B 团队要用就得重新适配。MCP 把这层标准化了：

flowchart LR
    subgraph before["没有 MCP"]
        A1["Agent A"] -->|"自定义调用"| T1["天气 API"]
        A2["Agent B"] -->|"另一套调用"| T1
        A3["Agent C"] -->|"又一套调用"| T1
    end

    subgraph after["有了 MCP"]
        B1["Agent A"] -->|"MCP 协议"| S1["天气 MCP Server"]
        B2["Agent B"] -->|"MCP 协议"| S1
        B3["Agent C"] -->|"MCP 协议"| S1
    end

一个 MCP Server 写一次，所有支持 MCP 的 Agent 都能用——这就是协议标准化的价值。

MCP 的完整架构：

Host（宿主应用，如 Claude Code）
  └── MCP Client（协议客户端）
        ├── 连接 MCP Server A（文件系统）
        ├── 连接 MCP Server B（数据库）
        └── 连接 MCP Server C（第三方 API）

MCP Server 通过 tools/list 声明能力，Client 通过 tools/call 调用。通信方式支持 stdio（本地进程）和 HTTP+SSE（远程服务）。

追问补充：MCP 不是唯一方案。单一应用、少量稳定工具可直接用本地函数、SDK、内部 API 或插件，由宿主自行完成注册和鉴权；只有在需要跨宿主复用、远程隔离、动态发现或统一治理时，MCP 的标准化收益才更明显，不能为使用协议而引入额外复杂度。

追问补充：REST API 是业务接口的常见形式；MCP 标准化宿主与 Server 间的能力发现和调用交互，可以封装 REST API，但不必构建在业务 REST 接口之上。Function Calling 是模型提出结构化调用的能力，真正执行与鉴权仍由宿主及工具实现。参见 MCP 架构文档。

差距在哪：新手把 MCP 等同于 FC 的升级版。高手理解两者是不同层面的东西——FC 是模型能力，MCP 是连接协议。面试官考的是你对 Agent 工具链架构的分层理解，以及对“标准化为什么重要”的工程认知。

Q：MCP 和 A2A 分别解决什么层面的问题？为什么需要两个协议？

来源：Agent 30 题 【蚂蚁一面追问：“MCP 和 A2A 什么关系”】【币安AI大模型实习一面追问：“Multi-Agent如何通信”】

新手答：“MCP 是调工具的，A2A 是 Agent 之间通信的。”

高手答：

这个回答对了但不够深——关键是理解为什么不能用一个协议解决两个问题。

层次不同：

为什么不能合并成一个协议：

工具调用和 Agent 协作的语义不同：

• 调用工具是同步的、确定的——“查天气”，马上返回结果，不需要“协商”
• Agent 协作是异步的、不确定的——“帮我做市场调研”，可能需要几分钟，中间可能需要追问，结果不确定

把两者合并会导致协议过于复杂。MCP 保持简单（请求-响应），A2A 处理复杂性（任务生命周期、能力协商、进度报告）。

在系统中的位置：

flowchart TB
    U["用户"] --> MA["主 Agent"]
    MA -->|"A2A 协议"| SA1["子 Agent A\n（数据分析）"]
    MA -->|"A2A 协议"| SA2["子 Agent B\n（报告撰写）"]
    SA1 -->|"MCP 协议"| T1["数据库 Server"]
    SA1 -->|"MCP 协议"| T2["Python 执行 Server"]
    SA2 -->|"MCP 协议"| T3["文档 Server"]

MCP 在底层（Agent 到工具），A2A 在上层（Agent 到 Agent）。两者组合形成完整的 Agent 生态连接标准。

当前状态的判断：MCP 已经相对成熟，主流 Agent 框架（Claude Code、Cursor 等）都已支持。A2A 还在早期阶段，实际落地的案例少，协议本身还在快速迭代。如果现在要做技术选型，MCP 可以直接用，A2A 建议保持关注但不急于深度投入。

差距在哪：新手只说了“一个调工具一个通信”——这是表面区别。高手理解两者的语义差异（同步确定 vs 异步不确定）和架构位置（底层 vs 上层），且对当前成熟度有自己的判断。面试官考的是你对 Agent 生态协议层次的理解深度。

Skills 机制

Q：Skills 是什么？为什么有了 MCP 和 Function Calling，还需要 Skills？

来源：字节实习一面 【蚂蚁一面同题：“Skills 的原理有没有了解过？”】【小红书AI应用开发同题：“Skills了解+如何管理”】【CVTE AI应用工程师一面追问：“怎么理解 Skill？能解决什么问题？”】【科大讯飞一面追问：“写Skills和写提示词的区别与共同点”】；字节广告团队agent面经（一二面）；本轮追问：Skills的能力直接写进系统提示词也能实现，为什么要单独拆出Skills？（斑头雁（Agent实习生面试一面））；苏州科达AI业务开 - 9月15日 - 一面 - 秋招；8.25 小红书实习 AI全栈开发实习一面挂凉经；美团Agent一面凉经

新手答：“Skills 就是预写好的 Prompt 模板吧，调用时注入进去。”

高手答：

Skills、MCP、Function Calling 解决的是 Agent 能力扩展的三个不同层面——把它们混为一谈是常见误区：

为什么有了 FC/MCP 还需要 Skills：

FC 和 MCP 解决“Agent 能调用什么工具”，但不解决“Agent 该怎么组合使用这些工具完成一个复杂任务”。举例：

有 MCP/FC：Agent 能查数据库、能读文件、能跑代码
缺 Skills：Agent 不知道"做代码审查"该先查 git diff → 再读相关文件 →
          再按规范检查 → 最后输出结构化报告

有 Skills：注入"代码审查"Skill 后，Agent 知道完整的任务流程、
          输出格式、检查规范、常见陷阱

Skills 的核心价值是“经验封装”——把团队的最佳实践、任务流程、约束规则打包成一个可复用单元，让 Agent 不用每次从零摸索。

Skills 和 Prompt 的关键区别：

一句话总结：Function Calling 给 Agent 装了工具箱，MCP 让工具箱标准化可插拔，Skills 给 Agent 配了岗位操作手册。三者分别解决“能做什么”“怎么连接”“怎么做好”。

追问补充：Workflow 是预先编排的确定性流程，适合固定步骤、分支和重试；SubAgent 是把子任务委派给独立 Agent，适合复杂任务拆解与并行。组合时由主 Agent 用 Skill 选择策略，调用 Workflow 执行稳定链路，必要时再委派 SubAgent 处理需要独立推理的子任务。

差距在哪：新手把 Skills 等同于 Prompt 模板。高手理解 Skills 是能力扩展的第三层——不是“调什么工具”的问题，而是“怎么组合工具完成复杂任务”的问题。面试官考的是你对 Agent 能力体系分层的理解。

Q：Skill、MCP、Rule 三者在 Agent 系统中各自扮演什么角色？

来源：蚂蚁一面 / 淘宝闪购 AI 应用研发二面 / 虾皮一面 【快手AI应用开发一面追问：“Tool/Skill/Agent 三层抽象的本质区别”】

新手答：“都是给 Agent 加能力的，只是形式不同。”

高手答：

三者不是“加能力的不同形式”，而是 Agent 行为管控的三个正交维度：

flowchart TB
    subgraph system["Agent 行为管控体系"]
        R["Rules\n（不能做什么）"]
        S["Skills\n（怎么做某事）"]
        M["MCP/Tools\n（能调用什么）"]
    end

    R -->|"约束边界"| A["Agent 行为空间"]
    S -->|"提供方法"| A
    M -->|"提供能力"| A

为什么需要三个维度：

只有 Tools 没有 Rules → Agent 有能力但无边界，可能删除生产数据 只有 Rules 没有 Skills → Agent 知道边界但不知道最佳实践，做事低效 只有 Skills 没有 Tools → Agent 知道怎么做但没有执行手段

三者组合才构成完整的 Agent 行为管控体系：Rules 画红线，Skills 铺方法，Tools 提供手段。

差距在哪：新手觉得三者“差不多”。高手理解它们是正交的三个维度——约束、方法、能力——缺任何一个 Agent 系统都有缺陷。面试官考的是你对 Agent 系统设计的分层思维。

Q：Hermes、OpenCode、Claude Code、OpenClaw 等热门 Coding Agent 工具的核心差异和适用场景？

来源：哆咔互娱 Agent开发实习一面 / 蚂蚁 Agent 开发一面 / 快手 AI 全栈一面 【唯品会大模型算法实习追问：主流 Agent 框架在 Harness 上有什么差异】；本轮来源；本轮追问：有没有看过市面上流行的开源 Agent 框架，比如 openclaw？讲讲 claw 的实现、记忆机制？（本轮追问）；本轮追问：你认为 Claude Code 哪些功能做得比较好？（本轮追问）；字节剪映AI应用开发一面；本轮追问：Claude和Codex二者有什么差别，哪个更好？（药明康德（AI数据方向-二面））；小鹏二面

新手答：“Claude Code 最强，其他的也差不多，都是用大模型写代码的工具。”

高手答：

这几个工具虽然都属于 Coding Agent，但设计哲学和定位差异很大：

从工程角度看几个关键差异维度：

1. 上下文管理：Claude Code 用 Harness + 渐进式披露 + compaction；Hermes 用分层压缩 + 外挂记忆；OpenCode 相对简单靠窗口截断
2. 工具协议：Claude Code 原生支持 MCP + Skills 分层；OpenClaw 以 MCP 为核心协议；Hermes 和 OpenCode 各有自己的工具注册方式
3. 可控性：Claude Code 的 Hooks 机制允许在工具调用前后插入自定义逻辑，企业级场景必需；开源方案需自行实现类似能力
4. 成本与隐私：闭源方案调用付费 API，数据过云端；开源方案可本地部署 + 接本地模型，但能力上限受限于底层模型

还要把底层模型与 Agent 实现分开做对照。固定同一模型和任务集，再比较 Harness 的规则与 Hook、工具权限、Context 组装、状态恢复、Sandbox 以及验证闭环。两个产品即使使用同模型，也会因这些工程契约得到不同的成功率、副作用风险和可恢复性；不能将 Agent 适配简化为换模型或换 Prompt。

选型建议：如果是企业内部需要可控、可审计、安全性要求高 → Claude Code；如果需要深度定制 Runtime 行为 → Hermes/OpenClaw；如果只想快速上手轻量使用 → OpenCode。

Claude 与 Codex 的差别不能只看模型名称：还要比较运行环境、上下文组装、工具权限、代码修改与验证闭环，以及数据和成本约束。没有绝对更好；固定任务集和模型后，以成功率、回滚率、耗时、费用和可审计性选型。

追问补充：框架设计还应把运行时调度显式化：先依据工具描述、权限、上下文相关性和预计成本筛选候选，再由执行器串行或并行调用，并设置超时、重试、取消、人工确认和幂等边界。每次决策记录输入上下文、工具参数、结果与失败原因，才能复盘选择错误并评估调度策略。

差距在哪：面试官考的不是你“用过几个工具”，而是你能否从架构层面理解不同 Agent 工具的设计取舍——上下文管理策略、工具协议选型、可控性与开放性的平衡。能说出具体差异而非只报名字，说明你对 Agent 工程有深度认知。

Q：如何比较 Coding Agent、通用助手与办公 Agent？

来源：百度大模型研发工程师二面（2026-08-21） / 杭州和为机电 AI 应用工程师面试；本轮追问：通用办公类的Agent你接触过吗？（本轮追问）

新手答：“Claude Code 和 Codex 用来写代码，豆包、千问办公等产品面向普通用户，底层都是大模型。”

高手答：

不要按品牌做功能清单，要按任务环境和执行边界比较：

Claude Code、Codex、Trae 等更接近开发环境中的 Coding Agent；豆包、通用千问等更接近通用助手；WorkBuddy、千问办公等偏办公协同。具体产品会跨界，因此最终要比较上下文来源、工具权限、执行持续性、验证方式、部署形态和目标用户，而不是把市场名称当成固定技术分类。

选型时先问任务能否在明确环境中验证：代码可通过测试，表格可通过公式和格式校验，开放式生活建议则更依赖事实核验和用户确认。任务的可验证性与副作用边界，决定 Agent 能被放权到什么程度。

差距在哪：新手按产品名字分类，高手按工作空间、工具、验证和权限边界建立可迁移的比较框架。

Q：使用 LangChain 构建 Agent 时有哪些核心模块？各模块如何协作？

来源：字节跳动 AI Agent研发工程师｜AI算力基础设施 27秋招面经；合肥某头部企业软件开发实习生面试问题汇总（时长1个小时）；字节AI全栈二面；中科曙光 AI Agent 一面

新手答：“LangChain Agent通常由模型、工具、提示词和执行循环组成，模型决定下一步是否调用工具，工具返回结果后继续推理或输出答案。”

高手答：

用 LangChain 构建 Agent，核心包括模型、工具、Agent 执行循环、消息与状态，以及可选的中间件和结构化输出；这些能力在 LangChain Agents Documentation 中有对应说明。模型根据提示和当前状态选择工具或结束，工具执行外部检索、数据库或业务操作，结果再回到循环，直到满足停止条件。工程上应限制最大步数、超时和预算，校验工具参数并隔离权限；对写操作设置人工确认或幂等键，记录轨迹以便排查。不要把模型输出当作可信指令，应通过 schema、沙箱和拒绝策略验证；评估需覆盖任务成功率、工具调用准确性、延迟、成本及异常恢复，而非只看 Demo 对话效果。

追问补充：LangChain提供模型、工具与 Agent 构建抽象。工程上可据此组织模型调用、检索与工具执行，再按需要接入状态管理、中间件和观测。面试回答应说明实际选用了哪些模块，以及异常恢复、权限和成本如何验证，不能把框架提供抽象等同于业务已经可靠。

差距在哪：浅层回答能列出模型、工具和循环，深入考点在状态管理、中间件、结构化输出、权限与失败控制，以及如何用轨迹和任务指标验证 Agent。

Q：知识库与 Skills 如何分工承载业务知识？

来源：9.21 蚂蚁二面；本轮追问：AI pipeline 对业务知识的理解如何保证准确？（(秋招) 9.16 字节中交广 - 交易与广告业务 - AI全栈开发工程师）；度小满 - AI 全栈研发 - 一面

新手答：“知识库主要存放可检索的业务事实和资料，Skills 主要封装完成任务的流程与能力，并通过真实案例测试覆盖率。”

高手答：

知识库适合承载相对稳定、可检索且需要频繁更新的事实，例如制度、产品资料、字段定义和操作文档；重点是切分、元数据、权限、版本、召回与引用。Skills 更像可调用的任务能力，承载目标、输入输出契约、工具调用顺序、参数校验、异常处理和完成标准，而不是把大量事实硬编码进去。二者边界应通过变更频率、复用方式和可测试性划分：事实变化通常更新知识库，流程或工具行为变化更新 Skill。验证不能只做问答 Demo，应建立真实业务场景集，覆盖高频、长尾、权限、缺失信息、冲突版本和工具失败；用任务成功率、关键步骤正确率、引用支持率、越权率、人工返工率和成本延迟评估。还要做离线回归、线上抽样与失败案例闭环，防止“能回答”被误判为“能完成业务”。

追问补充：原始知识文档承载可核验事实，向量库提供检索索引，二者仍需版本、权限和原文引用。Skill 则可封装操作说明、流程和配套资源，不一定是工具调用或有副作用；需要执行动作时仍由实际工具及权限检查落实。小而稳定的规则可随 Skill 提供，大量且常更新的业务事实适合按需检索。

差距在哪：浅层回答只做内容分类，深入回答还要定义边界、执行契约、权限与更新机制，并用真实任务指标验证覆盖而非只测生成文本。

Q：Hooks 在 Agent 系统中应该拦截哪些阶段，和 Prompt 约束有什么区别？

来源：B站 Agent 二面（2026-08-19）；本轮追问：使用主 Agent 做输出约束，与另设一个 Agent 执行或评审任务有什么区别？（本轮追问）；本轮追问：你重写的 Agent 层到底对需求做了什么约束？（本轮追问）

新手答：“在工具调用前后运行 Hook，做日志和安全检查。”

高手答：Hooks 可位于请求进入、上下文组装、模型调用、工具前后、状态提交和最终输出，但每个 Hook 必须有明确输入、超时、失败策略和副作用。权限、路径、参数和发布门禁由确定性 Hook 强制执行；Prompt 只提供行为指导。Hook 版本进入 trace，禁止任意插件获取全量秘密；高风险阻断需可解释、可审批和可回滚。

差距在哪：新手把 Hook 当回调，高手把它当模型之外的策略执行点。

Q：Coding Agent 如何通过规则和 Skills 治理代码规范？

来源：百度 Agent Harness 研发工程师 - 9月8日 - 一面 - 秋招；本轮追问：是否尝试过把 Skill 规则写入更底层、优先级更高的规范，以提高遵从性？（字节 AI 全栈一面（飞书））

新手答：把规范写成可复用指令，在生成前约束、生成后检查。

高手答：

将项目规则、工具调用和验收步骤组织为版本化 Skills/配置；Agent 每次修改前读取适用规则，执行后运行 formatter、测试和 diff 检查。高风险操作需人工确认，规则结果写入日志；借鉴“上下文按需加载”和“工具边界”思路，但要结合本项目 CI、权限和回滚机制，不能只依赖提示词。

对关键规则会下沉到系统/开发者级规范或项目强制配置，并在工具层限制可执行操作；格式化、静态检查、测试和 CI 作为最终门禁，模型提示只能辅助。若规则冲突按既定优先级处理并记录拒绝原因，避免把安全约束只写在 Skill 正文。

差距在哪：考察对 Coding Agent 机制的抽象和工程化迁移能力。

Q：Dify/Coze 这种低代码工作流平台和 Codex/Claude Code 这类 Coding Agent 的本质区别是什么？

来源：成都某中厂 Agent 产品开发实习面经；本轮追问：这个产品相比其他 Agent 产品有哪些优势和缺点？（本轮追问）

新手答：“一个是拖拽的，一个是命令行的，都是做 AI 应用的工具。”

高手答：

两者虽然都叫“Agent 工具”，但设计哲学和能力边界有根本性差异——它们解决的是 Agent 应用开发中完全不同层次的问题。

本质区别一：编排者 vs 执行者

Dify/Coze 是编排工具——帮你把 LLM 调用、知识库检索、条件判断、API 调用等节点“编排”成一条固定管线。它本身不是 Agent，而是用来构建简单 Agent 应用的 IDE。编排的上限取决于设计者能否穷举所有分支。

Codex/Claude Code 本身就是 Agent——它接收一个目标后自主决定做什么、读什么文件、调什么工具、怎么验证。它不需要预定义路径，每次执行都是动态决策。

本质区别二：确定性流程 vs 非确定性探索

flowchart LR
    subgraph dify["Dify/Coze 模式"]
        direction LR
        D1["输入"] --> D2["节点A：\n意图分类"]
        D2 -->|"类型1"| D3["节点B：\n查知识库"]
        D2 -->|"类型2"| D4["节点C：\n调API"]
        D3 --> D5["节点D：\n生成回复"]
        D4 --> D5
    end

    subgraph coding["Coding Agent 模式"]
        direction TB
        C1["目标：实现X功能"] --> C2["自主探索代码库"]
        C2 --> C3["自主决定修改方案"]
        C3 --> C4["自主实现+验证"]
        C4 -->|"验证失败"| C3
        C4 -->|"验证通过"| C5["完成"]
    end

Dify/Coze 的每条路径在设计时就确定了——用户输入只是“选择走哪条预设路径”。Coding Agent 的路径在运行时才产生——面对从未见过的代码库也能自主探索和实现。

本质区别三：能力天花板

低代码平台的天花板是设计者的想象力——它只能做设计者预见到的事。如果需求变了、场景复杂了，就要重新拖拽连线。适合标准化、重复性高的任务（客服问答、表单处理、简单 RAG 应用）。

Coding Agent 的天花板是底层模型的能力——理论上只要模型能理解，就能做。适合开放性、创造性、需要探索和试错的任务（代码开发、复杂分析、研究性工作）。

两者的互补关系：

实际生产中两者经常组合使用：用 Dify/Coze 搭建用户可见的 AI 应用（确定性高、用户体验可控），用 Coding Agent 开发和维护这个应用本身的代码（灵活性高、效率高）。

差距在哪：新手只看到了交互形式的差异（拖拽 vs 命令行）。高手理解两者的本质区别在于决策模式（预定义路径 vs 运行时自主决策）和能力上限（设计者想象力 vs 模型能力）。面试官考的是你对 Agent 产品形态的分类认知——不是所有带 AI 的产品都是 Agent，关键区别在于“谁在做决策”。

Q：Function Calling 和 RAG 分别解决什么问题？如何配合使用？

来源：字节跳动Agent开发1面凉经；字节全栈一面

新手答：“Function Calling 让模型调用外部工具，RAG 让模型检索外部知识；实际系统可以先用 RAG 找资料，再通过 Function Calling 执行业务操作。”

高手答：

Function Calling 解决“让模型按结构化参数请求外部能力”的问题，例如查订单、调用计算服务或提交变更；真正执行仍由应用控制，必须做参数校验、权限检查、超时、重试和幂等。RAG 解决“让模型基于外部或私有资料回答”的问题，通常包括切分、索引、召回、重排和把证据放入上下文，可降低仅依赖模型参数记忆的风险，但会受检索质量、时效性、权限隔离和上下文长度影响。两者可以串联：先检索授权资料，再让模型决定是否调用工具，或工具返回结果后再次生成答案。验证应分别评估召回率、引用与答案正确性、工具参数准确率、拒答率及端到端失败恢复；不能把检索结果或模型输出直接当作可信指令。

差距在哪：浅层只会区分“调用工具”和“检索知识”，深入回答还应说明编排顺序、权限与幂等边界，以及如何评估检索和工具执行的可靠性。

Q：Agent 和 Siri 这种传统助手的核心差别在哪？

来源：字节AI产品（智能体方向）

新手答：“Agent 更智能，Siri 比较笨。”

高手答：

核心差别不在“智能程度”，而在架构范式：

1. 决策模式：Siri 是“意图识别→槽位填充→调用固定 API”的管道式架构，每个能力是工程师预定义的；Agent 是“理解目标→自主规划→动态选择工具→反思调整”的闭环架构，能力边界由模型能力决定
2. 任务复杂度：Siri 处理单轮单意图（“设个闹钟”），Agent 能处理多步骤复合任务（“帮我规划周末行程并预订”）
3. 容错方式：Siri 失败了说“我不太明白”，Agent 失败了会自主尝试其他路径（Reflection + Retry）
4. 上下文利用：Siri 基本无记忆（每次对话独立），Agent 有长短期记忆，能利用历史交互持续优化
5. 工具扩展性：Siri 的技能由苹果开发团队预定义，Agent 可以通过 MCP/Function Calling 动态接入任意新工具
6. 不确定性处理：Siri 要求精确匹配意图才能执行，Agent 能处理模糊需求并主动澄清

差距在哪：面试官考的是你对“Agent 本质是自主决策系统”的理解——传统助手是确定性流水线，Agent 是非确定性闭环。

Q：LangChain 的传统 Chain 和 LCEL 有什么区别？LCEL 解决了哪些工程问题？

来源：哔哩哔哩 AI 应用岗 Agent 开发一面（2026-08-18）

新手答：“LCEL 用管道符连接组件，写起来更简洁。”

高手答：

传统 Chain 往往由具体类封装固定调用流程，扩展、并行和流式行为取决于各类实现。LCEL 把 Prompt、模型、解析器、Retriever 和自定义函数统一抽象为 Runnable，通过 |、并行映射和分支组合声明数据流，并统一提供 invoke/batch/stream/async、配置传递、重试与 tracing 接口。

它的价值不只是语法短，而是让组合后的链仍保留批处理、流式、异步和观测能力，便于局部替换和测试。LCEL 适合无复杂持久状态的可组合数据流；需要循环、长期状态、人工中断和 checkpoint 时，应使用 LangGraph 等状态图，不要把 LCEL 管道硬拗成工作流引擎。

差距在哪：新手只看到运算符，高手说清统一 Runnable 协议、组合能力和与状态图的边界。

Q：Computer Use Agent 如何感知并操作本地电脑？

来源：字节 Agent 秋招一面

新手答：“Computer Use Agent 通常通过截图感知界面，由模型选择点击、输入或滚动等动作，再由执行器操作电脑并循环观察结果。”

高手答：

Computer Use Agent 通常运行在隔离的桌面或浏览器环境中：先获取截图等视觉状态，模型据此规划点击、输入、滚动或键盘操作，再由执行器调用系统接口，继续截图形成“观察—行动”循环。OpenAI 的说明也强调环境执行、安全检查和必要的人类确认，参见 OpenAI Computer Use Guide。生产实现要限制权限、网络、文件和凭据范围，防止提示注入、误点删除或外传数据；高风险付款、发送消息等操作应暂停确认。验证不能只看任务成功率，还要记录动作轨迹、失败恢复、越权尝试和人工接管率，并权衡视觉延迟、脆弱性、成本与自动化收益。

差距在哪：浅层回答只描述“截图加点击”，深层回答还应说明执行闭环、隔离权限、提示注入与高风险确认，以及如何通过轨迹和失败率验证可靠性。

Q：DeepAgents 的核心难点、设计亮点及其解决的 Agent 工程痛点是什么？

来源：杭州微链词元 AI应用开发

新手答：“DeepAgents 是一种带有规划、工具调用、子 Agent 委派和上下文管理能力的 Agent 框架，用来处理复杂的长流程任务。”

高手答：

DeepAgents 的核心不是再写一个简单的“思考—调用工具”循环，而是提供一层可运行的 harness：Agent 可进行任务规划，把中间结果写入文件系统以减轻上下文压力，按需委派子 Agent，并通过权限控制限制工具和环境访问；底层运行时与 LangGraph 的状态、持久化和流程编排能力衔接。它解决的工程痛点包括长任务状态难维护、上下文不断膨胀、子任务边界不清以及工具权限难治理，具体能力可参考 Deep Agents Overview。但这些能力不等于任务一定可靠：规划可能走偏，文件状态可能过期，委派会增加延迟和成本，工具仍可能产生副作用。因此生产落地要为步骤设置超时、重试上限、幂等键和人工审批边界，隔离敏感凭据，并记录轨迹。验证时应分别测试任务完成率、工具调用正确率、恢复能力、成本、延迟和越权失败用例，再与单循环 Agent 做消融对比。

差距在哪：浅层只把 DeepAgents 当成带工具的 Agent，深层要解释 harness、上下文与委派机制、运行时关系、权限和失败模式，并给出可观测与评测方案。

Q：Self-Consistency 是什么？如何通过多次采样提升大模型输出的可靠性？

来源：南方基金 AI应用大模型方向 笔面试梳理

新手答：“Self-Consistency 就是让模型对同一问题多次生成不同推理过程，再通过多数投票选择最常见的最终答案。”

高手答：

Self-Consistency 的角色是把一次推理的单点结果，变成多条候选推理路径的聚合结果。工程上通常提高采样随机性，独立生成多条路径，抽取并规范化最终答案，再按多数票或任务评分选择结果；其核心不是比较文字表面相似度，而是聚合答案空间中的一致结论。论文讨论了多样化路径与最终答案聚合的思路：Self-Consistency 论文。它可能降低偶然推理错误，但一致性不是正确性证明，且会增加 token、延迟和费用。应在代表性基准上与单次推理比较准确率、成本、延迟和置信度，并检查答案归一化误差。涉及写库、付款、发消息等副作用时，建议只对规划阶段采样，执行阶段采用审批、幂等键和去重，不能无约束重复调用工具。

差距在哪：浅层回答只说“多采样投票”，深层回答还应说明答案归一化、成本延迟、评估方法，以及有副作用工具不能重复执行这一安全边界。

Q：Agent 开发与传统前后端开发有哪些核心区别？

来源：字节跳动火山引擎agent开发秋招一面

新手答：“传统前后端主要围绕确定的请求、数据和页面流程开发，而 Agent 还要处理模型推理、工具调用、上下文记忆和不确定结果。”

高手答：

传统前后端通常由代码明确控制流程：接口输入、业务规则、数据库操作和响应边界较稳定，测试可覆盖主要分支。Agent 的核心角色是根据目标和上下文进行规划，选择工具、调用外部系统并根据结果继续行动，输出具有概率性，流程可能动态变化。工程上要限制工具权限、参数和超时，隔离副作用，保护敏感数据，并设计会话状态、重试、幂等、人工确认和成本上限。不能只看 Demo 是否成功，还应通过固定评测集、轨迹审计、失败注入和线上指标验证正确性、安全性与可恢复性。传统系统更可预测、易回归；Agent 更灵活，但带来评估困难、延迟成本和不可控行为，适合让模型处理开放任务，把关键约束留在确定性代码中。

差距在哪：浅层回答只停留在“Agent 会调用工具、结果不确定”，面试官还会考察权限隔离、状态与副作用管理、评估回归以及确定性代码和模型的边界。

附：概念考察高频考点速查

下一篇建议继续看：

• Agent Infra：Runtime、Sandbox 与可靠执行
• 架构选型：ReAct、Plan-and-Execute 与 ToT 怎么选
• Prompt 工程与框架原理

这类题的答题模式

概念考察题的核心是独立思考 + 结构化表达：

1. 先给定义：一句话说清概念的本质（不要复述定义，要用自己的理解）
2. 再讲演进：为什么出现这个概念？解决了什么之前解不了的问题？
3. 做对比：和相关概念的关键区别是什么？（用表格最清晰）
4. 给判断：你怎么看这个概念？适用场景和局限各是什么？
5. 接项目：你在实际项目里怎么用的？或者为什么没用？

面试官问“你了解X吗”不是在考记忆力——“了解”只是入门，有判断才是高手。