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 成本、人工复核通过率或线上失败率。
• 能否解释一个失败案例：问题如何发现、如何定位、怎么修复、修复后用什么指标验证。
• 能否区分“学习过概念”和“真正落地过系统”，面试回答要用具体约束、权衡和数据支撑。