Agent 架构与多智能体面试模块

视频中 Agent 是最高频主题之一。面试回答的关键不是“Agent 很智能”，而是能否解释它如何拆解任务、选择工具、读取状态、处理失败，并在可控边界内完成业务目标。

#Agent 的核心组成

组成	作用	面试要点
Planner	把目标拆成步骤	是否支持重规划、最大步数、用户确认
Executor	执行具体动作	工具调用、参数校验、错误处理
Tool Registry	管理可用工具	权限、Schema、速率限制、审计
Memory	保存短期或长期信息	会话状态、用户偏好、任务历史
State	记录当前任务进度	可恢复、可回放、可观测
Evaluator	判断结果是否达标	自动检查、人工审批、失败重试

#高频问题与参考回答

#Agent 和 ChatBot 的区别是什么？

ChatBot 主要围绕对话生成回答；Agent 以目标为中心，能根据上下文调用工具、读取外部系统、执行多步任务，并根据工具反馈继续决策。Agent 更接近“带工具和状态的自动化执行器”，所以必须重视权限、审计和失败恢复。

#Agent 和工作流的区别是什么？

工作流路径固定，适合审批、表单、客服分流等稳定流程。Agent 路径动态，适合信息收集、文件整理、代码修改、复杂查询等开放任务。生产中经常混合使用：高风险步骤用固定工作流，开放步骤交给 Agent，关键节点人工确认。

#多 Agent 协作怎么设计？

不要为了炫技拆多个 Agent。只有当角色、工具权限、上下文或评估标准明显不同，才适合拆分。例如研究 Agent 负责收集资料，写作 Agent 负责生成报告，审校 Agent 负责事实检查。协作方式可以是串行交接、共享黑板、主管 Agent 分派任务或事件队列。关键是定义输入输出协议和终止条件。

#如何避免 Agent 失控？

限制工具权限，给每个工具定义参数 Schema 和危险操作审批；设置最大步骤数、超时和预算；记录每一步的思考摘要、工具输入、工具输出和最终结果；对外部写入、发消息、删文件、花钱等操作加人工确认；失败后支持回滚或恢复。

#项目表达模板

我做的 Agent 系统用于【任务场景】。用户输入目标后，Planner 会拆分成【步骤类型】，Executor 根据步骤调用【工具列表】。每次工具调用都会经过参数校验和权限检查，状态写入【存储/队列】。如果遇到失败，会进入【重试/降级/人工确认】。我们用【成功率、平均步骤数、耗时、人工接管率、成本】评估效果。

#常见追问

• 工具 Schema 如何设计，参数错误如何处理？
• 工具调用失败后是重试、换工具，还是终止？
• Agent 的记忆保存在哪里，如何避免隐私泄漏？
• 多轮任务中断后能不能恢复？
• 如何判断 Agent 已经完成任务？
• 如何做日志回放和问题定位？
• 如何处理模型一直循环调用工具？

#回答中的风险边界

面试里不要把 Agent 说成“完全自主”。成熟回答应该强调边界：高风险动作要审批；模型输出要校验；外部写入要审计；预算要可控；系统要能降级到人工或传统流程。能主动讲风险，反而更像工程候选人。

#Agent 执行循环

一个可讲清楚的 Agent 通常包含 Observe、Plan、Act、Reflect 四步。Observe 读取用户目标、历史状态和工具反馈；Plan 生成下一步计划；Act 调用工具或输出结果；Reflect 判断是否完成、是否需要重试或重规划。面试回答里要强调每一步都应记录日志，因为 Agent 的错误经常不是单点错误，而是多步决策累积。

#工具调用设计细节

工具不是函数列表那么简单。每个工具需要有名称、用途、参数 Schema、权限级别、超时时间、返回格式、错误码和审计字段。只读工具和写入工具要分开；写入工具如发消息、改文档、删文件、提交工单，应该默认要求确认或至少进入审批队列。

工具类型	示例	风险	控制方式
只读查询	搜索文档、查订单、读网页	信息泄漏	权限过滤、脱敏
内容生成	写报告、生成代码、写邮件	事实错误、格式错误	模板、校验、人工审核
外部写入	发飞书、建工单、改数据库	误操作	审批、幂等、回滚
本地执行	文件整理、脚本运行	环境差异、安全风险	沙箱、白名单、日志

#状态与记忆

短期状态记录当前任务步骤，例如已经读取哪些文件、调用过哪些工具、下一步要做什么。长期记忆保存用户偏好、常用项目、历史任务经验，但必须有权限边界和删除机制。不要把所有历史对话都塞进上下文，否则会增加成本并引入隐私风险。更稳的做法是把记忆结构化，检索相关部分后再进入上下文。

#多 Agent 协作细节

多 Agent 常见模式有三种。第一是主管-执行者模式，主管拆任务并分派给专门 Agent；第二是流水线模式，研究、生成、审校依次执行；第三是共享黑板模式，多个 Agent 围绕同一个状态区写入和读取结果。面试时要主动说明终止条件：什么时候认为任务完成，什么时候停止继续讨论，什么时候转人工。

#失败恢复方案

Agent 失败要能分类处理。参数错误让模型修正一次；权限错误直接终止并提示授权；网络错误按指数退避重试；工具业务错误返回用户可理解的原因；连续失败进入人工接管。对于长任务，状态应持久化到数据库或任务队列，避免进程重启后整条链路丢失。

#Workflow、Agent 和 Multi-Agent 的选择

最佳实践不是一上来做复杂 Agent。固定流程优先工作流，例如分类、摘要、审批、表单填充；需要动态判断但工具少的任务用单 Agent；角色、权限、上下文或评价标准明显不同，才拆成多 Agent。复杂度越高，成本、延迟、调试难度和安全面越大。

方案	适用场景	优点	风险
Prompt Chain	多步但路径固定	可测、可控、便宜	灵活性有限
Routing	意图分类后分发	专家提示词更精准	分类错会走错链路
Parallelization	多个子任务并行	降低总耗时	汇总和冲突处理复杂
Evaluator-Optimizer	生成后自检迭代	适合高质量生成	成本上升，可能循环
Agent	开放任务动态决策	灵活，能处理未知路径	失控、越权、难调试
Multi-Agent	专家角色协作	分工清晰，可并行	协作协议和状态复杂

#Durable Execution 和 Human-in-the-Loop

生产 Agent 要支持持久化执行。每一步状态、工具输入输出、错误和人工决策都要能保存成 checkpoint，这样任务中断后可恢复，出现问题可回放。Human-in-the-loop 不应只在最后加一个“批准”按钮，而应放在高风险节点：外部写入、删除、付款、发消息、访问敏感数据、修改生产配置。

#Agent 观测和评测

Agent 评测要覆盖工具选择、参数准确性、步骤数、成功率、人工接管率和成本。Trace 里至少记录用户目标、计划、工具名、参数摘要、返回摘要、模型版本、Token、耗时、最终结果和失败原因。没有 Trace 的 Agent 很难进入生产，因为失败时无法判断是计划错、工具错、模型错还是数据错。

#安全护栏

Agent 的最大风险是 excessive agency，也就是给了模型过多自主权。护栏包括工具白名单、只读优先、最小权限、危险动作审批、预算上限、最大步数、输出校验、外部内容隔离和审计日志。面试时要主动讲“哪些动作我不会交给 Agent 自动执行”，这比盲目强调自动化更成熟。

#候选人自检清单

• 能否在 2 分钟内讲清楚这个模块解决什么业务问题、为什么不是简单调用模型 API。
• 能否说清输入、处理、模型调用、后处理、评测、监控、回滚的完整链路。
• 能否给出至少一个真实项目指标，例如召回率、命中率、延迟、Token 成本、人工复核通过率或线上失败率。
• 能否解释一个失败案例：问题如何发现、如何定位、怎么修复、修复后用什么指标验证。
• 能否区分“学习过概念”和“真正落地过系统”，面试回答要用具体约束、权衡和数据支撑。