#模块七：Agent、工具调用、工作流编排与协议知识点

面试里谈 Agent，第一句要先划边界：Agent 不是“更会聊天的 Chatbot”，也不等于“套了检索的 RAG”。普通 Chat 主要把用户输入映射成一次或几次自然语言回复；RAG 的核心是把外部证据检索进上下文，让答案更忠于资料；Agent 则多了一层“对环境采取行动”的闭环：观察任务和环境状态，决定下一步，调用工具或委托子任务，读取执行结果，再继续调整计划，直到成功、失败或触发人工接管。换句话说，Chat/RAG 更像回答系统，Agent 更像带状态、工具和恢复策略的任务执行系统。

一、Agent 的基本部件

一个可解释的 Agent 通常可以拆成 planner、executor、memory、tool、critic 和 observer。planner 负责把用户目标分解成可执行步骤，并决定先做什么、后做什么；executor 把计划落到具体动作，例如发起检索、写文件、调用 API、运行代码；observer 负责把工具返回、页面状态、错误日志、用户反馈转成下一轮模型能理解的 observation；memory 保存当前任务状态、长期偏好、历史成功经验和失败教训；critic 检查计划和结果是否满足约束，必要时触发重试、回滚、降级或人工确认；tool 是 Agent 影响外部世界的接口。这里的关键不是部件名字，而是责任边界：计划和执行要分开，观察和判断要可追踪，记忆写入要有门槛，工具调用要能审计。

ReAct、Plan-and-Execute、Reflexion 可以理解成这些部件的不同编排方式。ReAct 强调 reasoning 与 acting 交替，适合探索型任务：先推测下一步，再调工具，根据 observation 修正；Plan-and-Execute 先做较完整计划，再逐步执行，适合多步骤但目标相对稳定的任务；Reflexion 把失败经验显式写回反思或记忆，适合需要多轮尝试、错误模式可复用的任务。工程上不要迷信名称，真正要问的是：任务是否需要动态改路，失败信号能否被观察到，反思是否会降低下一次失败率。

二、工具调用与 schema

function calling 或 tool calling 的本质，是把模型的自然语言意图转成机器可执行的结构化调用。一个工具 schema 至少要说明工具名、用途、参数类型、必填字段、枚举范围、默认值、返回格式和错误语义。好的 schema 应该让模型“容易调对、难以调错”：工具名要贴近动作，描述要写清适用场景和禁用场景，参数不要把多个概念塞进一个自由文本字段，危险参数要有枚举或校验，返回结果要包含足够的状态码和可读解释。

工具调用的执行权不在模型手里，而在宿主应用手里。模型只提出“我想调用哪个工具、参数是什么”，应用负责鉴权、参数校验、执行、限流、记录日志，并把结果再喂回模型。这个边界非常重要：如果把模型输出直接当 shell、SQL、转账、邮件发送指令执行，就等于把不可信文本变成生产权限。生产系统通常会按 side-effect 分级：只读工具可自动执行；低风险写操作需要策略校验；高风险动作如删除、付款、对外发送、改权限，需要用户确认、双人审批或沙箱演练。

三、MCP、A2A 与协议化价值

MCP 解决的是“模型应用如何标准化接入外部资源和工具”的问题。没有协议时，每接一个数据库、文件系统、日历、搜索、代码仓库，都要写一套私有适配；有 MCP 后，工具提供方可以按统一方式暴露能力，客户端按统一方式发现和调用资源、工具、提示模板。它的价值不只是省胶水代码，更是把模型、应用、工具生态解耦：同一个工具服务可以被多个客户端复用，同一个 Agent 也能更换底层模型或运行环境。

A2A 关注的是另一个层面：Agent 与 Agent 之间如何发现能力、交换任务、协作产出，而不要求互相暴露内部 memory、prompt、工具实现或推理细节。可以把 MCP 理解成“Agent 接工具和上下文”的协议化，把 A2A 理解成“Agent 接另一个 Agent”的协议化。两者不是替代关系：一个研究助理 Agent 可能通过 MCP 调企业知识库和浏览器工具，同时通过 A2A 把制图、代码审查、法务检查委托给其他专业 Agent。面试时要说清协议不是魔法，它只统一接口和交互模型，不自动保证工具质量、权限安全、任务成功率或业务收益。

四、Workflow 与 Agent 的取舍

Workflow 是预先设计好的流程，路径、分支、状态和回滚点相对明确，例如“上传合同、抽取条款、规则校验、人工复核、归档”。Agent 是根据观察动态选择下一步，适合目标清楚但路径不确定的任务，例如排查线上故障、调研竞品、修复未知错误。两者不是高低关系，而是控制方式不同：workflow 稳定、可审计、可预测，适合强合规和高确定性场景；agent 灵活、覆盖长尾，但成本、延迟、不可重复性和安全风险更高。

成熟产品常用混合架构：外层 workflow 负责权限、状态机、预算、超时、人工确认和最终归档；内层 agent 只在需要开放探索的节点工作，例如生成候选方案、选择检索策略、定位报错根因。这样既保留 Agent 的动态能力，又避免让模型无限循环或越权行动。判断一个系统是不是“真正的 Agent”，不要看宣传词，而要看它是否有观察-行动闭环、是否能基于反馈改路、是否管理任务状态、是否能处理失败和恢复。

五、Multi-Agent 什么时候值得做

Multi-Agent 不是把一个任务随便拆成多个角色名。只有当角色之间存在清晰责任边界、上下文隔离能降低干扰、不同 agent 需要不同工具或权限、并行执行能显著节省时间，拆分才有价值。例如“调研、实现、测试、审计”可以拆，因为信息需求和评价标准不同；但一个简单问答硬拆成 planner、writer、reviewer，可能只会增加 token 成本和通信误差。多 agent 的核心成本是协调：谁拥有最终决策权，冲突如何解决，任务状态在哪里，部分失败如何回收，重复工作如何去重，日志如何归因。

六、安全、注入与可观测指标

Agent 安全的难点来自两点：它会读取不可信内容，也可能执行有副作用的动作。Prompt injection 的典型路径是网页、文档、邮件或工具返回里夹带“忽略系统指令、泄露密钥、调用某工具”的恶意文本。防护不能只靠一句系统提示，而要做分层隔离：把外部内容标记为不可信数据，禁止数据里的指令覆盖系统策略；工具按最小权限发放 token；敏感信息不进模型上下文或做脱敏；写操作前做策略引擎校验；高风险动作要求确认；全链路记录输入、工具调用、返回、决策理由和人工介入点。

评估 Agent 不能只看最终回答好不好。更有用的指标包括任务成功率、一次成功率、平均步数、平均成本、端到端延迟、工具调用成功率、无效调用率、循环率、恢复率、人工接管率、越权拦截率和用户确认后的撤销率。任务成功率回答“最后做成了吗”，恢复率回答“失败后能否自己修回来”，无效调用率回答“是不是在乱试工具”，人工接管率回答“自动化边界在哪里”。线上还要按任务类型分桶，否则简单任务会掩盖复杂任务的失败。

常见误区、复盘清单与追问链路

常见误区有六个：把 RAG 包装成 Agent；认为工具越多越智能；把模型输出直接执行；长期记忆什么都写；Multi-Agent 必然优于单 Agent；只评答案文本，不评执行过程。复盘一个 Agent 项目时，可以按清单检查：目标是否可验证，成功和失败是否有明确判定，工具 schema 是否足够窄，权限是否最小化，side-effect 是否分级，memory 是否有写入、更新、删除和纠错策略，planner 是否有预算和终止条件，observer 是否保留关键错误信息，critic 是否真的能阻止坏动作，日志是否能重放一次失败。

面试追问通常沿着一条链路推进：先问“Agent 和 Chat/RAG 区别是什么”，再问“你会怎么设计 planner、executor、memory 和 tools”，接着问“function calling schema 怎么写才可靠”，然后问“MCP/A2A 解决什么接口问题”，再追“为什么不用固定 workflow 或为什么要多 agent”，最后落到“怎么防 prompt injection、怎么限制权限、怎么评估成功率和恢复率”。回答时不要背概念，要始终回到工程闭环：目标、状态、工具、权限、观察、恢复、评估。能把这条链路讲顺，基本就说明你理解的是可落地的 Agent 系统，而不是只记住了几个热门名词。