我是安徽最忧郁程序员无隅

如果简历里写了 RAG、LangGraph、Multi-Agent、MCP，面试官很少满足于一句“我用这个框架搭了一个 Agent”。他接下来往往会问：文档为什么这样切？状态里到底放了什么？为什么要拆成多个 Agent？工具执行失败怎么恢复？新策略上线以后，怎么证明效果真的变好了？

这些问题看似从大模型一路跳到了数据库、Kafka、线程安全和 A/B Test，实际上都在追问同一件事：你能不能把一个具有不确定性的模型，放进一个可靠的软件系统，并证明这个系统解决了真实问题。

本文基于一份公开的 AI Agent 面试复盘转写稿进行重组。原材料记录了分享者在不同业务场景下遇到的追问，本文不按面试公司逐场复述，而是把这些问题整理成一条工程链：业务问题、架构选择、上下文与状态、工具执行、可靠性保障、效果评估。

文中面试经历属于原分享者；招聘趋势、框架热度和公司内部做法只作为背景，不写成确定事实。技术部分会补充原转写中没有展开的边界、失败场景和验证方法。

一、Agent 面试正在从“会不会用框架”转向“能不能做工程决策”

1. 技术名词只是追问的入口

准备 Agent 项目时，我们很容易把注意力放在名词上：Prompt 怎么写、LangGraph 怎么连边、向量数据库选哪个、MCP 如何接工具。学习这些没有问题，但它们只能证明你知道“有哪些积木”，还不能证明你知道“为什么这样搭”。

面试官顺着简历继续问，问题通常会转向四个层次：业务为什么需要它，数据如何流动，失败如何处理，结果如何验证。

例如，“项目使用了 Multi-Agent”会自然引出下面这些追问：

• 单个 Agent 为什么不能完成？
• 各 Agent 的上下文、工具和权限是否真的不同？
• 多个 Agent 是并行协作，还是按顺序调用了几次模型？
• 中间某个 Agent 失败后，整条任务如何重试？
• 拆分增加了延迟和成本，换来了什么可衡量的收益？

如果这些问题答不出来，Multi-Agent 更像一个包装词，而不是从业务约束推导出的架构选择。

2. Agent Demo 和生产系统的差距藏在箭头里

从最高层看，许多 Agent 都可以被画成同一个结构：

输入 → 模型判断 → 工具调用 → 输出

这个抽象没有错，但它隐藏了生产系统最难的部分。输入是否完整，模型能看到哪些资料，工具参数由谁校验，用户有没有操作权限，失败之后从哪里恢复，重复执行是否造成副作用，最终答案是否可信，都被压缩进了几个箭头。

将箭头展开以后，链路更接近下面这样：

输入解析
→ 上下文获取
→ 任务规划
→ 权限与参数检查
→ 工具执行
→ 状态持久化
→ 失败恢复
→ 结果验证
→ 评估与反馈

模型负责其中一部分判断，但整个系统的正确性不能只由模型承担。生产系统需要把可确定的规则写进程序，把不可接受的动作挡在权限边界外，把关键决策和工具结果记录下来，再用评测证明系统表现。

Agent Loop 本身可能很短，生产化的复杂度主要来自它周围的 Harness。 Harness 可以理解为承载模型工作的工程环境，包括提示词、上下文、工具、状态、权限、预算、日志、测试和评估机制。

3. 六层 Agent 工程能力

原分享最后把面试问题归纳成了六层能力。把它们重新整理后，可以得到一张从模型调用通向业务价值的阶梯。

第一层是使用模型，包括 Prompt、Structured Output 和 Tool Calling。它解决“怎样让模型产生系统可以继续处理的结果”。如果输出仍然是一段随意文本，后续程序很难稳定读取；结构化输出则把结果约束为预先定义的字段和类型。

第二层是提供正确的信息，包括 RAG、Retrieval、Rerank 和 Context Management。模型并不知道企业内部的全部事实，知识也可能过期，因此系统要决定检索什么、返回哪些片段，以及哪些证据允许进入当前上下文。

第三层是控制模型行为，包括 Workflow、状态机、路由、Planning 和 Multi-Agent。它解决“下一步由谁决定”和“模型能在多大范围内自主行动”。

第四层是连接真实世界，包括 API、数据库、MCP、消息队列和代码执行。模型在这一层不再只是生成文字，而是可能查询数据、创建工单或改变业务状态。

第五层是处理失败，包括权限、沙盒、重试、幂等、恢复和可观测性。这一层决定系统犯错时影响有多大，以及能否定位和恢复。

第六层是证明价值，包括离线评测、回归测试、A/B Test 和业务指标。能够搭出系统，并不等于系统有用；能够修复几个案例，也不等于整体质量稳定提升。

一次真实任务会从上到下穿过每一层：模型理解目标，从 RAG 获取资料，根据状态选择工具，经过权限检查后执行，发生故障时恢复，最后进入评估系统。框架使用能力是起点，工程判断力体现在这条链能否闭合。

二、如何把一个人工业务流程改造成 Agent 系统

原分享里有一道非常适合做系统设计的场景题：客户端埋点记录了应用启动的不同阶段，希望用 Agent 自动发现性能退化、定位问题并生成分析报告。

这道题的价值不在于“能不能调用大模型”，而在于如何把工程师原本完成的分析流程拆成机器可执行的步骤。

1. 先还原人工 Workflow

假设工程师每天需要检查新版本的性能数据，他可能会按下面的顺序工作：

1. 获取新旧版本的启动耗时。
2. 按启动、网络请求、图片加载等阶段比较指标。
3. 找到性能退化最明显的阶段。
4. 按设备、网络、地区或资源类型继续下钻。
5. 结合发布变更和历史经验提出原因假设。
6. 形成报告，把证据和待确认问题交给负责人。

只有先还原这条人工链路，才能判断哪些步骤已有明确算法，哪些依赖经验，哪些需要外部系统支持。否则“做成 Agent”很容易退化为：把所有数据塞给模型，然后要求它给出结论。

拆解时可以逐环追问：输入是什么，输出是什么，判断标准是什么，失败后怎么办，结果能否验证。比如“找到退化阶段”的输入是各阶段指标，输出是异常阶段及变化幅度，判断标准可能是统计阈值和最小样本量。这一环完全可以由程序完成。

2. Agent 可以没有聊天界面

很多人最熟悉的 Agent 是聊天框：用户说一句，模型回一句。但业务 Agent 完全可以在后台运行。

性能分析 Agent 可以每天定时触发，读取前一天的数据，发现某版本的图片加载阶段变慢，自动查询更细维度，并在固定时间生成报告。工程师不必先提出问题，Agent 也依然完成了感知、判断、行动和反馈闭环。

这里真正产生价值的是自动化重复的人工分析，并把异常证据整理到工程师可以继续处理的程度。聊天界面只是交互方式，不是 Agent 的必要定义。

3. 确定性程序和模型判断如何分工

性能分析对数值精度要求很高。让模型直接阅读大量日志并心算变化，很容易产生数字错误，也难以追溯。因此，固定 SQL、指标聚合、差值计算和阈值判断应由程序完成。

模型更适合处理需要理解上下文和选择路径的部分，例如：看到网络阶段异常后，是先按运营商拆分，还是先检查请求失败率；看到图片加载变慢后，需要补查资源体积、缓存命中还是弱网占比。

这条链路可以设计成一个受控循环：

程序获取数据并计算指标
→ 模型依据证据提出下一步假设
→ 执行层校验查询参数和预算
→ 程序执行补充查询
→ 新证据返回模型
→ 证据充分后生成报告

假设某阶段 P95 耗时从 200 毫秒变成 260 毫秒，“增长 30%”是程序计算出的观测事实；“可能由图片资源变大导致”只是归因假设。只有继续获得资源体积、缓存命中率、网络分布等证据，才能提高这条假设的可信度。

最终报告应区分三类内容：已验证事实、基于证据的推断、仍需人工确认的问题。这样即使模型无法确定根因，报告仍然可以帮助工程师缩小排查范围。

确定性程序也不等于天然正确。SQL 可能查错字段，统计代码可能使用错误口径。它的真正优势是规则明确、结果可复现，可以通过测试和审查发现问题。

4. Workflow 与 Agent 不是二选一

Anthropic 在《Building Effective Agents》中区分了两种形态：Workflow 通过预定义代码路径编排模型和工具，Agent 则由模型动态决定处理过程和工具使用。它同时建议从满足需求的简单方案开始，因为更强的自主性通常会增加延迟与成本。参考：Building Effective Agents

对于规则明确、分支有限的任务，Workflow 更容易测试和预测。例如数据获取、权限检查和报告发布，都可以固定为节点。对于需要根据中间证据调整分析方向的局部问题，可以让模型动态选择下一项工具。

生产系统经常采用“外层工作流固定，局部决策动态”的方式：

固定入口
→ 固定数据校验
→ 动态分析循环
→ 固定结果审查
→ 固定输出与记录

这种设计根据业务风险分配自主性。低风险、可撤销的分析行为可以更灵活；写数据库、发消息和操作资金等行为需要更严格的程序控制。

5. 什么时候才需要 Multi-Agent

把一个流程拆成多个模型调用，并不会自动变成合理的 Multi-Agent 系统。拆分至少应该解决一个真实问题。

第一种理由是上下文隔离。不同子任务依赖完全不同的资料，把所有内容都塞给同一个模型会增加干扰和成本。例如一个子任务只分析网络指标，另一个只检查图片资源，两者可以维护不同上下文。

第二种理由是工具和权限隔离。检索 Agent 只允许读知识库，执行 Agent 才能访问受控工具，审查 Agent 只能读取结果并给出通过或拒绝。职责边界在系统层真实存在，而不只是提示词里的角色名称。

第三种理由是并行性。多个彼此独立的调查方向可以同时执行，最后由协调者汇总。如果步骤本来就严格串行，拆成多个 Agent 只会增加通信和序列化开销。

第四种理由是独立评估与恢复。某个子任务可以单独计量成功率、成本和延迟，也可以失败后单独重试，而不必重跑整条链路。

反过来，如果流程固定、上下文相同、工具相同，而且几个所谓的 Agent 只是轮流接收不同角色提示词，那么一个 Pipeline、Workflow 或带工具的 Agent 可能更合适。

Multi-Agent 是一种复杂度交换：用协调成本换取上下文隔离、任务并行、权限分离或独立恢复。 面试时真正应该回答的，是业务为什么愿意支付这笔成本。

三、Agent 如何获得正确的信息，并记住执行到了哪里

如果模型的判断依赖错误或残缺的信息，再复杂的规划也无法挽救结果。原分享从文档切分一路追问到向量数据库、LangGraph State 和持久化，背后其实是两个连续的问题：模型看到了什么，任务记住了什么。

1. RAG 不等于接入向量数据库

RAG，即检索增强生成，通常先从外部资料中找出相关内容，再把这些内容提供给模型。完整链路至少包括：

原始文档
→ 解析与清洗
→ Chunk
→ 元数据补充
→ Embedding
→ 候选召回
→ 过滤
→ Rerank
→ 上下文组装
→ 模型生成
→ 引用验证

每一层都有独立的失败方式。解析可能丢失表格结构，Chunk 可能拆散完整步骤，召回可能没找到正确片段，Rerank 可能把相关证据排到后面，上下文组装可能超过预算，最终生成还可能误读证据。

所以项目介绍不能停在“使用向量数据库进行语义检索”。更有信息量的表达是：原始资料有什么结构，采用什么切分策略，保留哪些元数据，查询如何过滤和重排，最后怎样验证引用支持答案。

2. 为什么不能机械地每 500 Token 切一刀

以车辆故障手册为例，一条完整知识可能由车型、故障码、故障现象、适用条件、检查步骤和处理办法组成。如果按固定 Token 数直接截断，很可能上一段只有故障现象，下一段才出现处理办法。

此时单个 Chunk 的语义不完整。检索虽然找到了“看起来相关”的片段，模型仍然缺少回答所需条件。

一个更贴合文档结构的方案是先按标题和章节做一级切分，再对过长章节使用带重叠的滑动窗口，并在每个 Chunk 上保留章节路径、车型、故障码和文档版本等元数据。查询时先过滤适用范围，再执行语义召回，必要时补取相邻片段。

这仍不是万能答案。表格、跨页步骤、图片说明和扫描件有各自的问题；章节切分也可能生成过大的片段。选择切分策略的依据，应来自真实问题对完整证据的需求。

3. 如何验证 Chunk 和检索策略

RAG 评测需要把“有没有找到资料”和“模型有没有正确回答”拆开。

检索层可以构造一组问题和对应证据，检查正确片段是否进入 Top-K、排序是否合理、元数据过滤是否误删结果。Recall@K 描述目标证据是否进入前 K 个结果，MRR 更关注第一个相关结果出现的位置。

生成层则检查答案是否正确、引用是否支持结论，以及模型是否加入了资料中不存在的内容。答案语气流畅，不能证明 RAG 有效；引用了三段资料，也不能证明这些资料支持答案。

还应该收集失败类型：没有召回、召回错文档、证据被截断、业务条件缺失、模型误读证据。只有知道错误发生在哪一层，优化才有明确对象。

4. 向量数据库选型是在匹配约束

“哪个向量数据库最好”没有脱离场景的答案。选型至少要考虑数据规模、更新频率、查询并发、过滤能力、多租户隔离、持久化、备份、高可用和运维成本。

如果项目只有几十份技术手册、几千到几万个 Chunk，处于低并发原型阶段，轻量、本地、易迭代的方案往往足够。此时过早引入重型分布式服务，会把精力消耗在部署和运维上。

当约束变成多租户、频繁更新、高并发、严格可用性或复杂过滤时，再重新评估存储方案。面试官真正想听到的通常不是产品参数背诵，而是：当前业务约束是什么，为什么方案足够，出现哪些信号时会升级。

5. Context、State 和 Memory 的边界

Context 是当前一次模型调用能看到的信息，包括用户问题、系统指令、检索证据和工具结果。它受上下文窗口和成本约束。

State 是一次任务执行过程中需要跨节点传递的数据。例如车辆故障诊断任务的 State 可以包含用户问题、车辆信息、故障码、检索证据、当前假设、已执行工具、失败信息和剩余预算。

Memory 更强调跨任务或跨会话保留的信息，例如用户长期偏好、历史业务事实或过去任务形成的经验。是否应该长期保存，要同时考虑有效期、隐私和错误传播。

RAG 决定当前模型能取得哪些外部证据，State 决定当前任务进行到哪里，Memory 决定不同任务之间能共享什么。把所有内容都塞进消息历史，既昂贵，也很难管理数据生命周期。

6. LangGraph 的核心是状态流转

使用 LangGraph 时，仅仅说“我构建了一张图”仍然过于抽象。更具体的问题包括：图里有哪些 State 字段，每个 Node 读写哪些字段，条件 Edge 根据什么选择下一节点，工具失败后状态如何变化，任务何时结束。

LangGraph 官方文档说明，配置 Checkpointer 后，图会在执行步骤保存 State Snapshot，并以 Thread 组织这些检查点。它们支持中断恢复、人机协作和历史调试。参考：LangGraph Persistence

这里要区分“程序内存中存在 State”与“State 已经持久化”。前者在进程退出后就会丢失；后者还涉及存储后端、序列化、Thread 标识和恢复策略。

State 也不应无边界增长。把全部日志、完整文档和每轮消息不断追加，会增加存储和模型上下文成本。可以在 State 中保存引用、摘要和结构化结果，把大对象放到专门存储中。

7. 恢复状态不等于恢复外部世界

假设 Agent 已经成功创建工单，但在保存“创建成功”这个状态前进程崩溃。从上一个 Checkpoint 恢复后，系统可能再次调用创建工单接口，于是出现重复工单。

这不是单纯增加 Checkpoint 就能解决的问题。外部操作需要幂等设计，例如为同一个业务动作生成稳定的幂等键，执行前查询是否已完成，或者让下游接口识别重复请求。

LangGraph 的函数式 API 文档也提醒，可能重放的 API 调用需要放在任务中，并把操作设计成幂等，以避免失败恢复时产生重复副作用。参考：LangGraph Functional API

一套完整的恢复设计需要同时回答：状态保存在哪里，从哪个点恢复，哪些步骤会重放，外部动作怎样去重。RAG 决定 Agent 看到了什么，State 决定 Agent 记住了什么，持久化和幂等决定 Agent 出错后能否安全继续。

四、Agent 如何安全地连接数据库、工具和真实业务系统

当 Agent 只能输出一段文本时，错误通常停留在回答层；当它开始查询数据库、运行代码、发送消息或修改业务状态时，同一次错误就可能产生真实影响。

原分享中的 Text-to-SQL、MCP、Skill、代码沙盒和 Kafka 问题，都围绕同一个主题：模型提出的行动，怎样经过系统约束后安全执行。

1. Text-to-SQL 为什么是生产 Agent 的缩影

用户说：“帮我查一下最近卖得最好的商品。”这句话至少有四处歧义：“最近”是一天还是一个月，“最好”按销量还是销售额，退款订单是否计入，统计全部地区还是特定市场。

模型最危险的行为不是承认不知道，而是默默选择一种解释，生成可以执行的 SQL，再把结果包装成确定答案。在数据库场景中，语义猜错就是查询错。

如果业务已定义默认口径，系统可以展示口径后执行；如果不同解释会明显改变结果，就应该要求用户澄清；如果问题超出权限，则应该拒绝。模型输出的置信度可以作为信号，但不能代替业务规则和澄清机制。

一个好的 Agent 不追求回答所有问题，而是知道什么时候执行、什么时候澄清、什么时候停止。

2. Text-to-SQL 的完整执行链

生产链路不能从自然语言直接跳到数据库执行：

自然语言问题
→ 指标与条件解析
→ Schema Retrieval
→ 表和字段选择
→ Join 关系构建
→ SQL 生成
→ 静态检查
→ 权限检查
→ 受限执行
→ 结果校验
→ 业务解释

当数据库表很多时，不适合把完整 Schema 全塞进上下文。可以先检索相关表、字段描述、表之间的关系和业务口径，再让模型基于候选 Schema 生成 SQL。

SQL 通过语法检查，只能证明语法成立；SQL 执行成功，也只能证明数据库接受了它。表关联是否正确、指标口径是否符合业务含义，仍需单独验证。重要指标还可以加入结果范围检查、历史基线比较或人工复核。

执行账户应尽量只读，并限制可访问的表、查询时间和返回行数。这样即使模型生成代价很高或访问范围过大的 SQL，执行层仍可拒绝。

3. Tool、MCP 和 Skill 分别解决什么

Tool 是一个可调用的具体能力，例如查询性能数据、读取工单、发送报告。它需要清晰的名称、参数、返回值和错误语义。

MCP 提供客户端与外部工具、资源和提示模板之间的标准化连接方式。它解决“能力怎样被发现和调用”，不会自动替你设计业务权限、执行幂等和评估方法。

Skill 更接近完成某类任务所需的一组操作知识，包括按什么顺序做、使用哪些工具、遵守哪些约束、如何检查结果。比如一个性能归因 Skill 可以规定先比较总体指标，再定位异常阶段，最后按设备和网络维度下钻。

三者可以组合成：Skill 告诉 Agent 怎样完成性能归因，MCP 把内部查询服务暴露给客户端，Tool 完成某一次具体查询。

Skill 上线后还会出现新的工程问题：怎样根据任务选择 Skill，如何管理版本，正在运行的任务使用哪个版本，出现问题时怎样回滚，以及如何记录某次结果究竟用了哪条规则。这些问题会在下一章进入评估与归因。

4. 模型请求和系统执行之间必须有边界

模型生成一个工具调用，只表示“模型建议执行这个动作”，不表示系统必须照做。真正执行前至少要完成参数校验、身份鉴别、权限检查、风险判断和预算控制。

读操作和写操作通常风险不同。查询公开资料可以自动执行，读取私有数据需要权限，删除数据、转账或对外发布可能需要人工确认。权限还应根据当前用户和任务上下文动态计算，不能只在提示词里写一句“不要做危险操作”。

Prompt 可以帮助模型减少不合规请求，但最后一道检查必须由程序和权限系统执行。因为模型可能误解指令，也可能受到不可信输入影响。

执行后还需要审计记录：谁发起任务，模型请求了什么，系统批准了什么，使用了哪些参数，工具返回什么，最终结果如何。这些信息决定问题发生后能否还原链路。

5. 为什么生成代码需要受控执行环境

如果允许 Agent 生成并运行 Python 脚本，风险会明显提高。代码可能访问不该读取的文件，连接未经授权的地址，消耗过多 CPU 或内存，甚至因为逻辑错误长时间不退出。

受控执行环境需要明确限制文件系统、网络、凭据、运行时间、CPU、内存和子进程等资源。超时后要能终止执行，访问未授权资源时要拒绝，并保存足够日志供审计。

单独启动一个进程，或者给脚本创建一个临时目录，并不等于已经建立安全沙盒。真正的隔离取决于操作系统权限、容器或虚拟化边界、网络策略、凭据注入方式和资源限制。

模型生成的代码也不能因为运行成功就视为正确。执行前可以做静态检查，执行时限制权限，执行后验证输出；高风险操作仍应由人确认。

6. 为什么 Agent 岗位会追问 Kafka、数据库和并发

生产 Agent 往往不是孤立进程。它可能消费业务事件，调用多个模型和工具，保存中间状态，再把结果写回消息队列：

业务事件
→ 消息队列
→ Agent 任务
→ 模型与工具调用
→ 状态持久化
→ 结果事件

模型调用延迟高且有波动。如果请求速度超过消费者处理能力，消息就会堆积。定位时不能只看队列长度，还要区分流量突然增大、消费者不足、下游变慢、频繁失败重试或 Rebalance 等原因。

Kafka 中，一个 Consumer Group 内的一个 Partition 在同一时间只分配给一个 Consumer，因此消费者数量超过 Partition 数量时，额外消费者不能提高该 Topic 分区的并行消费能力。Offset 提交时机还会影响故障后的重复处理或数据丢失风险。

真实系统不应轻易宣称实现端到端 Exactly Once。即使消息系统提供相关语义，只要任务还调用外部 API 或数据库，就仍需考虑跨系统副作用。更常见的工程思路是接受“可能重复”，再通过业务幂等、去重记录和可重试操作保证最终结果。

线程安全问题也会出现在 Agent 服务中。两个事件可能同时修改一个任务状态，两个工具回调可能以不同顺序返回，超时重试可能与原请求同时完成。锁、版本号、条件更新和状态机约束，都是传统软件工程里早已存在的工具。

7. 可靠系统的四个目标

正确性要求结果符合数据和业务规则。它不仅包括模型回答，也包括查询口径、状态迁移和工具参数。

一致性要求并发、失败和重试不会破坏业务状态。这里会用到事务、幂等、去重和补偿机制。

安全性要求模型不能越过身份、权限和执行环境边界。最小权限、风险分级和人工确认都服务于这个目标。

可追溯性要求能够还原模型看到了什么、作出了什么决定、调用了什么工具，以及最终结果依据什么产生。

传统后端知识没有因为 Agent 出现而失效。数据库、消息队列、并发、缓存、网络、监控和容灾，构成了约束模型不确定性的基础设施。

五、如何证明 Agent 真的在变好，以及 AI Coding 面试真正考什么

搭建 Agent 的门槛正在降低，但“系统是否真的变好”仍然很难回答。原分享中最有价值的一组追问来自这里：新 Skill 上线后，原来的 Bad Case 消失了，怎么证明是 Skill 起了作用？

1. Bad Case 消失不等于优化有效

某类错误上线后不再出现，可能是新 Skill 修复了问题，也可能是用户输入分布变化、上游服务已修复、模型版本改变、路由策略变化，或者监控漏掉了问题。

这就是原分享描述的悖论：如果评测系统只从线上失败中收集样例，那么错误一旦暂时消失，系统也失去了继续观察它的能力。之后即使问题复发，也可能直到用户再次撞上才被发现。

历史失败样例要转化为可重复运行的回归集，而不能只留在日志里。回归集至少应该保存输入、必要上下文、工具结果、期望行为、不允许出现的行为，以及当时使用的模型、Prompt 和 Skill 版本。

2. 四种证据分别回答什么问题

历史回归回答“旧问题是否修复，以及其他能力有没有退化”。对输出存在随机性的任务，还要多次运行，观察通过率和波动，而不是把一次成功当成稳定修复。

同期对照回答“真实流量中的整体效果是否提升”。尽量固定其他变量，把可比较请求分配到旧版和新版，提前确定成功率、人工介入率、延迟和成本等指标。多久能得到可信结果，取决于样本量、效果差异和数据波动，不能统一拍一个天数。

执行轨迹回答“系统实际做了什么”。它可以确认使用哪个 Skill 版本、检索到哪些内容、调用了什么工具、失败发生在哪一步。但“加载过新规则”和“加载后成功”只能说明相关性，不能单独证明因果。

消融实验用于进一步判断某项规则的贡献。在其他条件尽量一致时，移除某条规则或模块，观察结果是否明显变差。它同样需要足够样本，并警惕不同规则之间的交互。

回归看稳定性，对照看效果，轨迹帮助定位，消融帮助归因。 这四类证据彼此补充，不能相互替代。

Anthropic 的 Agent 评测文章也强调，Agent 会进行多轮工具调用并修改状态，因此评测不应只看最终一句回答，还需要观察任务结果、执行轨迹与中间行为。参考：Demystifying Evals for AI Agents

3. 怎样从多条轨迹提炼 Skill

如果手上有五条成功 Session，它们分别调用了不同工具，不能直接把五条轨迹拼进 Skill。首先要对齐它们解决的任务和成功标准，再找到共同的关键决策点。

可以比较：它们在什么状态下选择了同一类信息，哪些工具调用对结果有必要贡献，哪些步骤只是偶然路径，失败轨迹缺少了什么。最终提炼的应该是跨样例稳定成立的策略，而不是某一条轨迹的完整复刻。

还要防止过拟合。如果为了修复一个 Bad Case，把这个案例的具体答案写进 Skill，离线回归会显得很好看，遇到新输入时却未必有帮助。更合理的做法是提炼可迁移的判断规则，并用独立样例验证。

4. Agent 的价值如何落到业务指标

模型评测分数提升，不一定代表业务价值提升。一个客服 Agent 的答案更长、更像人工表达，但如果转人工率、严重错误率和平均解决时间没有改善，项目价值仍然存疑。

不同场景可以组合使用任务成功率、人工介入率、严重错误率、平均处理时间、单任务成本、用户采纳率和业务损失等指标。指标选择应从业务问题反推。

例如性能分析 Agent 的价值不一定是“完全替代工程师”，也可能是把每天两小时的数据筛查缩短到十分钟，把异常定位到两个候选模块，并让工程师看到完整证据。这样的目标更容易验证，也更符合系统早期能力。

评估时还要同时看质量、延迟和成本。增加更多模型调用可能提高少量准确率，却让处理时间和费用大幅上升。技术方案是否合理，取决于这组权衡是否符合业务要求。

5. AI Coding 面试真正考什么

原分享还提到一场允许使用 AI 的现场编码题：设计一个可扩展、线程安全、逻辑清晰的订单状态机引擎。题目允许 AI 生成代码，但面试官仍可以观察候选人如何定义问题、拆分任务、约束实现和验收结果。

面对订单状态机，首先应明确状态和事件。例如订单可能处于待支付、已支付、已取消、已完成等状态；支付、取消和完成事件只允许在特定状态发生。还要定义重复事件如何处理，两个并发事件如何避免让同一订单进入矛盾状态，以及新增状态时需要修改哪些位置。

接下来才是让 AI 实现局部模块。可以先让它生成状态转移的数据结构，再实现合法性校验，最后补充并发控制和测试。每完成一块，都需要阅读代码、运行测试并核对边界，而不是看到生成结果没有语法错误就全部接受。

技术取舍也必须由候选人解释。例如使用枚举和代码定义状态，类型约束更强，修改通常需要重新发布；使用元数据或配置驱动，扩展更灵活，但配置校验、版本兼容和调试成本更高。AI 可以列出比较项，最终选择仍要联系题目约束。

6. 把 AI 当作执行者时，人负责什么

一个合适的类比是：人承担 Tech Lead 的责任，AI 承担执行型开发者的一部分工作。这里不是职位高低的判断，而是责任分配。

人需要理解问题、拆分任务、决定架构、定义约束、选择验收标准，并对最终结果负责。AI 可以生成局部实现、搜索相关代码、补充测试、比较候选方案和协助排查错误。

如果人在 AI 思考和生成期间完全退出决策过程，后面就很难判断它为什么这样设计，也难以解释 Trade-off。更有效的协作方式是先形成自己的问题框架，再利用 AI 扩展方案和执行细节，最后用证据验收。

验证顺序可以逐层加强：先阅读生成代码，再做类型和静态检查，然后运行单元测试、并发与边界测试、集成测试，最后完成真实使用流程。较低层通过，不能自动证明较高层正确。

以订单状态机为例，正常订单能完成支付，只证明主路径可用；它不能证明重复支付安全，也不能证明支付和取消并发到达时状态一致。面试官观察的正是候选人能否主动发现这些缺口。

7. 回到准备路线：成为 AI Native Software Engineer

完整看下来，Agent 岗位需要的能力可以按一条渐进路线准备。

先掌握模型调用、Structured Output 和 Tool Calling，理解模型擅长什么、哪些输出不可靠。再学习 RAG 和上下文工程，能够解释资料如何进入模型，以及怎样验证召回和引用。

接着学习 Workflow、状态机、路由和 Agent 编排，重点不是记框架 API，而是能描述 State、节点职责、分支条件和恢复策略。然后把 Agent 接到真实工具上，补齐数据库、Kafka、并发、权限、沙盒和可观测性。

最后建立评估思维：保存失败样例，构造回归集，记录执行轨迹，设计同期对照，把技术指标连接到业务结果。

面试时，所有技术选择都可以沿着同一个回答结构展开：

当时的业务约束是什么
→ 为什么选择这个方案
→ 还有哪些候选方案
→ 当前方案付出了什么代价
→ 约束变化后何时切换
→ 最后怎样验证它有效

对于没有在生产环境真正做过的方案，可以明确说明：“这个场景我没有上线经验，如果由我设计，我会从权限、状态、失败恢复、成本和评估几个方面展开。”承认经验边界，同时给出有依据的设计，比把推测包装成项目事实更可靠。

原复盘最值得保留的结论，可以在这里重新表达：AI Agent Engineer 正在成为一种 AI Native Software Engineer。 他既要知道模型能做什么，也要知道模型为什么不可靠；既能让模型完成任务，也能用软件工程把不确定性限制在业务可以接受的范围里。

真正有说服力的 Agent 项目，不是技术名词最多的项目，而是能回答三个问题的项目：它解决了什么真实问题，它怎样在失败时保持可控，以及我们凭什么相信它正在变好。

素材来源：公开分享《我的 AI Agent 面试复盘》。本文依据用户提供的转写稿进行主题重组、术语纠正和技术扩展。原视频。文中系统设计示例用于解释工程机制，不代表原分享者或相关公司的实际生产实现。