Agent 编排八股：面试必会的 5 个 agent 术语
📍 AI 求职速查
你会遇到的开场
Section titled “你会遇到的开场”2025-2026 年 AI PM 面试 agent 是必考。开场最爱问：
「简单讲一下你怎么搭一个 AI Agent？」
升级：
「ReAct 和 Plan-and-Execute 啥时候用哪个？」
「你做过 Multi-Agent 吗？怎么协调？」
「Subagent 是啥？你见过生产环境用过吗？」
这一篇把 5 个 agent 核心术语讲清楚 —— 重点是啥时候选哪个架构(面试官最爱听的就是判断口径)。
💡 想深入看 agent 原理实战的，推荐配合看 Agent 通用知识板块 —— 这一篇是面试速记，那个板块是完整知识体系。
先建立大局观
Section titled “先建立大局观”Agent 跟普通 LLM 调用的本质差别:
| 普通 LLM 调用 | Agent |
|---|---|
| 一问一答 | 多步自主行动 |
| 你给 prompt 它给 text | 你给目标它自己拆任务 + 调工具 + 反思 |
| 输入输出固定 | 过程长度不定(可能 1 步可能 50 步) |
| 没记忆 | 跨步骤 / 跨会话有记忆 |
关键认知:Agent 不是「LLM 升级版」，是用 LLM 当大脑的自主系统。
一、AI Agent(总览)
Section titled “一、AI Agent(总览)”是啥：接收任务 → 自主规划 → 调用工具 → 反思 → 输出结果的 LLM 驱动系统。不是单次对话，是多步自主行动。
核心 5 能力:
| 能力 | 干啥 |
|---|---|
| 1. 任务理解 | 把用户目标拆成子任务 |
| 2. 规划 | 决定子任务的顺序 + 调哪个工具 |
| 3. 工具调用(Tool Use) | 调外部 API / 函数 |
| 4. 记忆 | 跨步骤 / 跨会话记上下文 |
| 5. 反思(Reflection) | 看自己输出对不对，错了重试 |
直观例子(订机票):
用户: "帮我订周五飞北京最便宜的票"
Agent 内部:1. 调航班 API 拿候选(任务理解 + 工具调用)2. 按价格排序(规划)3. 调用户 calendar 验证空闲时间(工具调用)4. 把方案和价格发给用户确认(人在回路：付款这类高风险动作，先问人)5. 用户点头后，调付款 API 下单(工具调用)6. 写确认信给用户(任务完成)普通 LLM 干不了这事 —— 它只能给你「教程文本」，不能真的去订。Agent 能。但付款、发邮件、删数据这类动作，要留一步让人确认（human-in-the-loop，人在回路），这是 agent 面试必问的安全点。
面试怎么答(总览题):
“Agent 不是单次对话，是多步自主行动。我看一个东西是不是 agent，核心看 5 件事：能不能拆任务 / 能不能规划 / 能不能调工具 / 能不能记上下文 / 能不能反思。少一个都只能算「半个 agent」。”
二、ReAct(Reasoning + Acting，推理与行动)
Section titled “二、ReAct(Reasoning + Acting，推理与行动)”是啥:Agent 最经典的模式。每一步让模型输出 Thought(思考)+ Action(行动)，执行行动后看 Observation(观察)，然后再推理下一步。
模板:
Thought: 我需要先查用户 calendar 看周五什么时间空Action: calendar_check("Friday")Observation: 周五 9-12 空, 14-18 空Thought: 早上 9 点航班比较合理Action: flight_search("Friday morning", "BJ")Observation: ...优势:显式推理过程 → 调试容易 + 减少幻觉。
啥时候用:
- 任务动态 / 不可预知(不知道下一步要干啥，得看上一步结果)
- 任务步骤不太多（经验上十来步以内；配上计划清单和检查点能跑得更长）
- 需要人能看见思考过程(调试期 / 合规期)
啥时候别用:
- 任务步骤清晰可一次性规划(用 Plan-and-Execute 更稳)
- 任务几十上百步，又没有计划清单和检查点（纯 ReAct 容易被中间错误累积带歪）
面试怎么答:
「ReAct 适合动态任务 —— 每一步根据上一步结果决定下一步。但步骤多了容易累积错误，所以我会按任务复杂度选 —— 单步用函数调用，步数不多的动态任务用 ReAct，步骤明确的长流程先规划再执行，跨多角色用 Multi-Agent（步数只是经验划分，不是硬门槛）。实际产品里两种常组合着用：像 Claude Code 这类编程 agent，会先列待办清单，再在 ReAct 式的循环里逐项执行、按反馈调整计划，靠上下文压缩和检查点控制误差累积，能连续跑很多步。」
💡 想深入 ReAct 的设计细节，看 AI agent 是怎么思考的：ReAct 模式 那一篇。
三、Plan-and-Execute(先规划后执行)
Section titled “三、Plan-and-Execute(先规划后执行)”是啥:Agent 第二种模式。一次性规划整个任务流(规划 agent)，再一步步执行(执行 agent)。规划跟执行分离。
ReAct vs Plan-and-Execute:
| 模式 | 决策时机 | 适合 |
|---|---|---|
| ReAct | 每步现场决定下一步 | 动态 / 未知任务 |
| Plan-and-Execute | 一开始全局规划，再执行 | 任务边界清晰 / 步骤多 |
啥时候用:
- 任务目标明确 + 步骤可枚举(写一篇文章 / 调研一个产品 / 跑一个固定流程)
- 每步成本高(不能边跑边猜)
- 需要给用户预览整个计划(用户先批准再执行)
直观例子(自动写报告):
- 不用 Plan-Execute：每写完一段决定下一段，容易跑题
- 用 Plan-Execute：先 plan 章节大纲(「引言 / 现状 / 问题 / 方案 / 结论」)，再一章一章写，结构稳
面试怎么答:
“Plan-and-Execute 适合任务结构清晰但步骤多的场景。比如自动写 6 章节研究报告，先规划章节顺序 + 每章要点，再一章一章写 —— 比 ReAct 边写边决定下一段稳定得多。关键判断：用户能不能在执行前预览整个 plan，如果能，Plan-Execute 体验更好(给用户掌控感)。”
四、Multi-Agent 编排(Multi-Agent Orchestration)
Section titled “四、Multi-Agent 编排(Multi-Agent Orchestration)”是啥:多个专精 agent 协作完成复杂任务。每个 agent 有自己角色 / 工具 / 上下文。
3 种主流编排架构:
| 架构 | 谁分活 | 适合 |
|---|---|---|
| Hierarchical(主从) | 1 个总调度 + N 个专精 agent | 多数企业场景（有「老板」） |
| Peer-to-peer(对等) | agent 之间直接发消息 | 路由 / 接力链（LangGraph / Microsoft Agent Framework，后者是 AutoGen 的继任者，AutoGen 已进入维护模式） |
| Pipeline(流水线) | A 输出 = B 输入 | 内容创作 / 业务流程 |
啥时候用 Multi-Agent:
- 任务能拆开 + 不同子任务需要不同专精(数据 / 文案 / 设计 / 测试)
- 单 agent 上下文撑不下(任务太复杂)
- 业务流程本来就分多角色(企业内部审批 / 客服路由)
啥时候别用:
- 任务能用单 agent 解决 —— 多 agent 增加复杂度 + 成本(LLM 调用 × N)+ 调试地狱
- agent 之间的协作设计没想清楚 —— 上来就 multi-agent 容易死锁 / 死循环
面试怎么答:
“Multi-Agent 不是越多越好。我的判断口径是先单 agent 跑通，撑不下了再拆。拆的时候先看任务边界 —— 数据 / 文案 / 测试这种真分得开才拆，强耦合的任务别拆(拆了协调成本超过收益)。架构选 Hierarchical 最稳（总调度好调试），Peer-to-peer 适合边界清晰的路由场景。”
💡 想看 5 种 multi-agent 编排模式 + 真实案例 → 多 agent 编排：谁分谁干活 那一篇。
五、Subagent(子智能体)
Section titled “五、Subagent(子智能体)”最直观的类比:主管派实习生。
主管(主 agent)接到大任务「审整个项目 + 写部署计划」，但他不想自己翻 100 个文件(累 + 占用主管的脑子)。怎么办？
派 3 个实习生分头干:1 号去搜代码，2 号去看测试结果，3 号去看部署历史。每个实习生只把摘要报回给主管，原始日志主管不用看。最后主管基于摘要写计划。
是啥：主 agent 可以临时派一个 subagent 处理子任务，subagent 跑完把结果交回主 agent。Claude Code 把它做成了显式功能，带火了这个叫法，但它不是 Claude Code 独有：OpenAI Codex 默认就开着子智能体（自带 default、worker、explorer 三种，见 Codex 官方文档），Google ADK 也用 sub_agents 把多个 agent 组成父子层级。
Subagent vs Multi-Agent:
| 维度 | Multi-Agent | Subagent |
|---|---|---|
| 关系 | 多个 agent 同级别持续协作 | 主 agent 按需派出 sub，干完交回结果 |
| 上下文 | 各自维持上下文 | 主上下文 + sub 短期上下文 |
| 生命周期 | 长期运行 | 按任务派出，多数用完即止 |
| 典型用法 | 业务流程 / 客服 | 保护主上下文(让 sub 干脏活) |
最常见用法:
主 agent 收到：「帮我审整个仓库 + 写部署计划」
- 主 agent 不去亲自读整个代码仓库（repo），那会撑爆它的上下文
- 而是派一个 Explore subagent 去搜代码，只返回摘要给主
- 再派一个 Plan subagent 写计划
- 主 agent 综合两个 sub 的返回，输出最终答案
核心价值：保护主上下文不被脏数据污染 + 可以并行多个 sub（并行能明显缩短总耗时，但 token 消耗也会大涨：Anthropic 的工程文章说，多智能体系统大约要用普通聊天 15 倍的 token）。
面试怎么答:
「Subagent 就是主 agent 按需派出去的『临时工』。Claude Code 把它做成显式功能、带火了这个叫法，OpenAI Codex、Google ADK 也都有类似机制。它主要解决三个问题：一是隔离上下文 —— 比如让 sub 去读 100 个文件，只返回摘要给主，主不用看原始日志；二是并行 —— 派 5 个 sub 同时跑不同任务；三是按任务限权 —— 负责搜代码的 sub 只给读权限，不给改文件的权限。代价是 token 消耗明显更高，所以简单任务不必拆。如果面试官做 agent 产品（比如火山引擎的 ArkClaw、开源的 OpenClaw 生态），顺着聊聊 subagent 的取舍，能显示你跟上了业界节奏。」
💡 别给 OpenClaw 贴错标签：它是奥地利开发者 Peter Steinberger 发起的开源个人 AI 助理（原名 Clawdbot），不是 Anthropic 的项目。作者 2026-02 加入 OpenAI，项目交给 OpenClaw 基金会运作（基金会 2026-07 正式亮相，OpenAI 是主要捐助方之一，见基金会公告）。ArkClaw 是字节旗下火山引擎 2026-03 上线的「云上版 OpenClaw」。
💡 想看 subagent 实战玩法 → Subagents(子智能体) 那一篇。
总结：5 个术语怎么记
Section titled “总结：5 个术语怎么记”按任务复杂度递进记：
| 复杂度 | 适合架构 |
|---|---|
| 单次问答 | 函数调用 / Tool Use（工具调用） |
| 步数不多的动态任务 | ReAct |
| 步骤明确的长流程 | Plan-and-Execute |
| 跨角色协作 | Multi-Agent |
| 上下文保护 / 并行子任务 | Subagent |
关键认知：这 5 个不是非此即彼，经常组合使用 —— 比如一个 Multi-Agent 系统里某个 agent 内部用 ReAct，某个 agent 派 Subagent。
面试加分小贴士
Section titled “面试加分小贴士”- 能讲权衡(trade-off) > 能讲是啥(ReAct vs Plan-Execute 各自代价)
- 能讲选型口径 > 能讲所有架构(任务多复杂选哪个)
- 能讲为啥不上 multi-agent > 一上来就吹 multi-agent(显示成熟度)
- 能讲生产环境失败案例 > 完美故事(讲一次 multi-agent 死循环怎么调试)
- 能讲权限与护栏 > 只讲能力（付款、发邮件、删数据前要人确认，工具权限按任务给到最小，见 Safe Autonomy 那一篇）
- 能讲跨工具兼容 > 单点架构（LangGraph / Claude Agent SDK / OpenAI Agents SDK / Google ADK / CrewAI 大致区别）
- 想深入 agent 原理 → Agent 通用知识 5 篇