2026-06-10 AI Agent 核心概念 拷问复盘

本轮概览

• 知识点：AI Agent 核心概念
• 模块：5. AI Agent 架构
• 分数：84
• 是否过关：是
• 来源卡片：[[../5. AI Agent 架构/AI Agent 核心概念]]

第 1 题

题目：

你怎么向面试官解释 AI Agent = Model + Harness 这个工程公式？请你重点讲清楚 Model 和 Harness 各自负责什么，为什么不能只说 “Agent 就是大模型加工具”。

你的回答：

你答到了核心边界：Model 负责建议和决策，Harness 负责持续执行、纠偏、观测、恢复和止损；也补充了 Harness 不只是工具层，而是完整执行时系统，并给出了六层拆分。

缺失点：

• 没把 Harness 和“工具集合”彻底拉开，少了 Agent Loop、状态持久化、上下文装配、安全熔断这些更工程化的关键词。
• 六层结构提到了名称，但没有顺手用一句话说明每层各自解决什么痛点，口头表达上还可以更紧。

推荐答案：

Model + Harness 的意思是，Model 只是 Agent 的大脑，负责理解语义、做推理、产出下一步意图；真正让系统跑起来的是 Harness。Harness 是包在模型外面的执行时系统，里面至少包括上下文装配、Agent Loop、工具执行器、记忆状态管理、观测评估和安全恢复。
所以不能把 Agent 简化成“大模型加工具”，因为“加工具”只解决了手脚问题，没解决怎么调度、怎么观测、怎么防失控、怎么在失败后恢复的问题。没有 Harness，大模型只是会给建议的生成器，不是可上线的 Agent 系统。

项目口径：

在我的项目里，模型主要负责理解用户诉求和表达调用意图，但真正落地是靠外围 Harness 工程完成的，比如 Advisor 链做上下文装配，工具白名单做能力裁剪，SafeToolCallAdvisor 做重复调用检测和最大轮数截断。也就是说，生产里的 Agent 不是“模型直接调 API”，而是“模型提出建议，Harness 决定能不能做、怎么做、做到哪一步必须停”。

第 2 题

题目：

你接着把 Harness 真正“跑起来”的核心闭环讲清楚。请你用一次完整的 Agent 执行过程来回答：从用户问题进来，到模型决策、工具调用、结果回写、再到下一轮决策，这个 Agent Loop 是怎么工作的？顺带说明为什么它本质上更适合不确定任务，而不是固定 Workflow。

你的回答：

你按顺序讲到了信息边界、任务拆解、工具选择、参数传递、工具侧校验、结果清洗回写、记忆状态记录，再进入下一轮决策，整体链路是对的；也提到了 Agent Loop 由大模型自主决策，而 Workflow 路径固定。

缺失点：

• Decide -> Act -> Observe 这个闭环不够凝练，面试时最好一句话就能打出来。
• “为什么适合不确定任务” 的解释偏短，没有明确==强调 Agent 是基于观察结果动态改计划==，而 Workflow 是预先编排好的图。
• 最后一小句口误了，应该是 Workflow 适合问题有固定解法、容错要求高的场景；Agent 更适合路径事先难以穷举的任务。

推荐答案：

Agent Loop 本质上就是一个循环：先把用户问题、系统规则、历史记忆和工具描述一起装进上下文，让模型先做一次 Decide，决定下一步是直接回复还是调用某个工具；如果需要调用工具，就进入 Act，由 Harness 去做参数校验、权限判断、超时熔断和真实执行；工具结果返回后，再经过清洗压缩写回上下文，形成新的 Observe，再让模型基于新观察做下一轮决策。
它适合不确定任务，是因为每一轮路径都要看上一步观察结果再决定，属于动态规划；而 Workflow 是流程图先定好，节点之间怎么走基本确定，更适合强约束、低容错、可预测的业务流程。

项目口径：

在苍穹外卖 AI 客服里，我们不是把所有接口一次性喂给模型让它自由发挥，而是先通过意图识别和上下文装配收缩问题空间，再由模型决定是否调用订单、退款、地址等工具。工具返回的结构化结果会再回写给模型，决定是继续追问用户、继续调下一个工具，还是直接生成答复。这个过程本质上就是一个受控的 Decide -> Act -> Observe 循环。

第 3 题

题目：

如果面试官继续追问你：“那你在项目里怎么防止 Agent 乱调工具、死循环，或者把高风险操作直接放给模型决定？”你就结合你的项目来答，讲清楚你会把哪些能力交给模型，哪些能力必须留在代码侧兜底。

你的回答：

你答到了最关键的边界：模型只负责表达意图和建议，执行权在 Harness；同时给出了 confirmation 字段做人审二次确认，也举了退款、取消订单、修改地址等高风险意图，并补充了基于“工具名 + 参数”签名的防重复调用和最大轮数限制。

缺失点：

• 还可以再补一层“工具白名单/权限校验/状态机校验”，这样回答会更像生产级治理，而不是只停留在确认弹窗。
• 没明确说明“模型不能直接决定高风险操作是否生效”，最好把“最终提交动作必须由代码侧判定”说死。

推荐答案：

我的原则是：模型只负责理解语义、判断意图、提出工具调用建议；真正能不能执行，必须由代码侧 Harness 再做一轮校验。
对于高风险操作，比如退款、取消订单、修改地址，我会先让上游意图识别产出结构化结果，并打上 confirmation=true 之类的确认标记；接下来代码侧必须检查用户身份、订单状态、权限范围和业务状态机，满足条件后才能继续，必要时还要人工二次确认。
另外我会在 Agent Loop 外围做重复调用签名检测、最大工具轮数限制、超时熔断和 fallback，避免模型在异常上下文里反复调用同一工具，保证系统不会因为模型幻觉进入死循环。

项目口径：

在我的项目里，高风险动作绝不会只靠一句 Prompt 来约束，而是放到代码层做硬性兜底。比如退款场景，模型最多只能表达“建议调用退款流程”，但最终是否能执行，要看后端权限校验、订单状态机、确认标记和审计链路是否通过。这样即使模型判断失误，系统也不会直接产生危险副作用。

下次复习动作

• 把 Model + Harness 压缩成 30 秒口播版本，重点记住 “模型负责意图，Harness 负责执行、观测、恢复、止损”。
• 把 Agent Loop 固化成 Decide -> Act -> Observe 三段式，并能顺手对比 Workflow。
• 第 3 题再补上三类代码侧硬约束：工具白名单、权限/状态机校验、最大轮数与签名防重。