#七、Agent、工具调用、工作流编排与协议
#代表笔试题
Agent 不是“更会聊天的 Chatbot”，也不是“加了检索的 RAG”。普通 Chat 系统通常是单轮或多轮文本生成：用户给问题，模型根据上下文直接回答；RAG 多了一步外部知识注入：先检索相关文档，再让模型基于证据回答。Agent 的关键差异在于闭环控制：它会把目标拆成步骤，选择工具，执行动作，读取观察结果，再决定是否继续、修正或结束。换句话说，Chat/RAG 的输出主要是文本，Agent 的输出既可能是文本，也可能是一串对外部系统产生影响的动作。
面试里可以用一个判别句：如果系统只是“生成答案”，重点是提示词、检索质量和事实一致性；如果系统需要“完成任务”，重点就变成状态机、工具契约、权限控制、错误恢复和审计。比如“回答某公司财报里收入是多少”更像 RAG；“读取财报、生成表格、发邮件给团队并在 CRM 创建跟进任务”才进入 Agent 范畴，因为它需要多步规划、工具调用和 side-effect 管理。
- Agent 与 Chat/RAG 的差异：Agent 具备目标、状态、动作、观察和终止条件；Chat/RAG 主要在上下文内完成回答，通常不负责外部世界的持续执行。
- ReAct 的基本思想：让模型在 Reasoning 与 Acting 之间循环：先思考下一步，再调用工具，再观察返回结果，再继续决策。它的价值不在“把思考写出来”，而在把推理过程和外部反馈接起来。
- tool calling / function calling 的作用：把模型的自然语言意图约束成结构化调用，例如函数名、参数 JSON、枚举值和必填字段，从而让后端能安全、可解析、可校验地执行。
- workflow 与 autonomous agent 的差别：workflow 是人预先定义好的 DAG 或状态机，模型只在局部节点做判断；autonomous agent 的路径更开放，由模型动态决定下一步。生产系统常常采用二者混合：主流程固定，局部让模型选择工具。
- memory 的类型：短期记忆保存本轮任务状态，长期记忆保存用户偏好或历史事实，工作记忆保存中间产物，情节记忆保存过去任务轨迹。真正难点是写入策略、过期策略和纠错，而不是“把所有历史塞进上下文”。
- MCP / A2A 的意义：MCP 更偏向模型应用和外部工具、资源、上下文之间的标准连接；A2A 更偏向 Agent 之间的任务委托、状态同步和结果交付。面试考点不是背协议字段，而是理解协议化为什么能降低工具接入和多 Agent 协作的集成成本。
#代表面试题
一个完整 Agent 通常可以拆成六类职责。planner 负责把目标拆成可执行子任务，并决定依赖关系、优先级和终止条件；它不一定每一步都重新规划，短任务可以只做一次计划，长任务需要阶段性重规划。executor 负责执行当前步骤，选择模型调用、工具调用或普通代码路径，并处理重试、超时和幂等。memory 负责保存必要状态，包括用户约束、已完成步骤、工具返回值和可复用经验，但必须能区分事实、偏好、猜测和临时中间结果。
tool 是 Agent 接触外部世界的接口，例如搜索、数据库、文件系统、浏览器、代码执行器、工单系统和支付系统。工具设计的核心是 schema：函数名要表达单一职责，description 要说明何时调用，参数要有类型、枚举、默认值、约束和示例，返回值要稳定且机器可读。好的 tool schema 会减少模型猜参数、错用工具、重复调用；坏的 schema 会把系统问题伪装成“模型不聪明”。
critic 负责检查计划或结果是否满足目标，可以是规则、模型评审、单元测试、检索验证或业务校验。critic 不应只写“看起来不错”，而要绑定可执行检查，例如任务是否完成、引用是否存在、金额是否一致、是否违反权限。observer 负责记录运行轨迹和外部反馈，包括每次模型输入输出、工具调用参数、工具返回、错误码、人工接管和最终状态。没有 observer，就很难调试循环调用、权限越界和线上失败。
- 如何区分工作流自动化和 Agent？看路径是否主要由预定义流程决定。固定审批、固定 ETL、固定通知链路是 workflow；需要根据环境反馈动态选择工具、修正计划、处理未知异常时，才需要 Agent 能力。
- ReAct、Plan-and-Execute、Reflexion 适合什么任务？ReAct 适合信息不完整、需要边查边做的任务；Plan-and-Execute 适合目标清楚、步骤较多、依赖关系明确的任务；Reflexion 类方法适合有可验证反馈、能从失败轨迹中改进下一轮尝试的任务。
- Agent 乱调用工具怎么诊断？先看 tool schema 是否重叠、描述是否含糊、参数是否可校验；再看 planner 是否给了明确终止条件；最后看执行层是否设置最大步数、重复调用检测、超时、回滚和人工确认。
- Multi-Agent 什么时候值得拆？只有当角色拥有不同权限、不同工具、不同知识边界或需要相互审查时才拆。为了“看起来智能”拆多个 Agent，往往只会增加通信成本、状态不一致和责任不清。
- 协议化的面试意义是什么？MCP / A2A 代表 Agent 工程从 demo 走向生态集成：工具提供方、模型应用、企业系统和其他 Agent 需要稳定契约，而不是每个项目手写一套适配层。
- memory 保留什么？保留会影响未来决策且经过确认的信息，例如用户偏好、长期项目背景、任务结果摘要；不保留一次性检索片段、模型猜测、错误工具输出和敏感凭证。写入长期记忆前最好有置信度、来源、时间戳和删除机制。
#这一块真正考什么
这一块真正考的是工程边界感。短任务工作流，例如“查一个 API 文档并生成示例代码”，可以采用轻量循环：明确目标、调用搜索或文档工具、生成结果、做一次校验后结束。长任务工作流，例如“迁移一个仓库、跑测试、修复失败、生成报告”，需要显式状态管理：任务拆分、阶段检查点、失败恢复、日志归档、人工确认点和最终验收标准。长任务不能只靠一个超长 prompt，因为上下文会膨胀，局部错误会累积，外部环境也会变化。
权限和 side-effect 是 Agent 落地的分水岭。只读工具的风险相对可控，写文件、发邮件、下单、删除资源、修改数据库这类有副作用的工具必须分级授权。常见做法是把工具分为 read、write、dangerous 三类；write 类需要参数校验和操作摘要，dangerous 类需要人工确认、幂等键、dry-run 或回滚方案。Agent 不能把“模型认为应该执行”当成授权依据，授权必须来自系统策略、用户确认或受控服务。
prompt injection 是 Agent 比普通 RAG 更危险的地方。RAG 中的恶意文档可能诱导模型回答错误；Agent 中的恶意网页、邮件或工单可能诱导模型调用工具、泄露上下文或执行删除操作。因此要区分数据与指令：检索内容、网页正文、邮件正文都应被视为不可信数据，不能覆盖系统指令和工具权限。工程上可以用内容隔离、工具 allowlist、参数白名单、敏感字段脱敏、二次确认和审计日志降低风险。
评测不能只看“回答像不像”。Agent 评测至少包括任务成功率、步骤成功率、工具调用正确率、恢复率、成本、耗时和人工接管率。任务成功率衡量最终是否完成目标；恢复率衡量遇到工具失败、无结果、权限拒绝、格式错误后能否修正并继续；工具调用正确率衡量是否选对工具、参数是否有效、调用顺序是否合理。一个系统如果简单任务成功率高但恢复率低，说明它适合 demo，不适合生产长任务。
#作答抓手
回答 Agent 题时，不要只说“会用 LangChain / LangGraph”，而要围绕一条链路说清楚：目标怎么定义、状态怎么存、计划怎么做、工具怎么选、权限怎么控、失败怎么回退、结果怎么观测。一个高质量答案通常会先承认 Agent 不是万能形态：稳定高频流程优先用 workflow，只有在环境复杂、路径不确定、需要动态决策时才引入 Agent。
常见误区有四类。第一，把 Agent 等同于“大模型循环调用自己”，忽略状态机、工具契约和终止条件。第二，把工具越多当成能力越强，实际工具越多，选择空间越大，误调用概率越高，schema 和权限设计越重要。第三，把 memory 当成无限上下文，导致错误事实长期污染；正确做法是压缩、分层、带来源并允许删除。第四，只用一次性 benchmark 看效果，不看线上长尾失败、恢复率、成本和审计。
#追问链路
面试追问通常会沿着这条链路推进：先问“Agent 和 RAG 有什么区别”，再问“你会怎么设计 planner、executor、memory、tool、critic、observer”，然后追问“function calling 的 schema 怎么写才能减少误调用”，接着问“MCP / A2A 为什么有价值”，最后落到“如果工具失败、越权、被 prompt injection、任务循环不停止，你怎么定位和修复”。准备时不要背框架名，而要准备一个可落地案例，把输入、状态、工具、权限、日志、评测指标和失败恢复讲完整。
一个简洁作答模板是：先定义 Agent 是目标驱动的闭环执行系统；再和 Chat/RAG 区分；然后画出 planner 到 observer 的职责分工；接着说明 tool schema 与协议化接入；再讨论短任务与长任务的编排差异；最后补上安全与评测。这样回答既覆盖概念，也体现你理解生产系统的约束。