Agent 架构与工具
归纳 Agent 架构、工具调用、工作流、Skills 和多 Agent 协作的面试要点。
Agent 架构与工具
Agent 是什么
Agent 根据目标和当前状态决定下一步，调用工具执行，再利用结果继续推进，直到完成或触发终止条件。常见组成是模型、任务状态、工具、反馈循环和权限控制；复杂任务再加入规划与长期记忆。
ChatBot 描述聊天交互形式，Agent 描述执行方式，两者可以重叠。区别应看系统能否根据反馈自主推进任务，而不是界面是不是聊天框。
Workflow、ReAct 与多 Agent
| 方式 | 决策如何发生 |
|---|---|
| Workflow | 代码预先定义主要步骤和分支，适合路径明确的任务 |
| ReAct | 在“推理 → 行动 → 观察”的循环中决定下一步 |
| 多 Agent | 按职责拆分任务，由多个 Agent 交接或并行协作 |
三者可以组合，也不都等于 DAG。DAG 表达无环依赖；ReAct 和可循环的工作流需要额外表达迭代和终止条件。
需要展开理解执行过程时，可看 范式说明与课程中的框架示例。
工具调用
模型产生工具名和结构化参数，宿主程序校验工具、参数和权限，执行真实代码，再把结果与调用 ID 回传给模型。模型据此继续调用或生成回答。
JSON 是调用描述，本身不会执行代码。运行时还要负责超时、错误返回、副作用的幂等性和调用预算；工具输出也应作为外部数据处理，不能自动获得修改指令的权限。
MCP 规范客户端与外部工具、资源等能力的交互；Tool Calling 描述模型提出调用的过程，两者可以配合使用。
Skills
Skill 把可复用的说明、流程、脚本和资源打包，供 Agent 在相关任务中使用；它不是另一种替代 Agent 的执行主体，也不自动保证结果稳定。
工具型 Skill 偏向可复用的局部能力，场景型 Skill 串起某类任务的处理流程。这是组织方式上的区分；是否更好，应通过任务成功率和维护成本验证。
多 Agent 怎么设计
先确认子任务是否有独立输入、输出和验收标准。职责差异不大或依赖很强时，增加 Agent 可能只增加通信、延迟和错误传播。
需要拆分时，按需设置 Planner、Executor、Reviewer、Router 等职责，不必每个角色都单独建 Agent。统一编排者分发任务，子 Agent 返回结果，是较容易控制的一种结构。
设计重点：
- 任务边界：明确目标、输入、输出、约束和完成条件；歧义会影响结果时先澄清。
- 状态归属：区分已确认事实、任务状态与模型推测，明确谁可以修改哪部分状态。
- 通信：传递必要上下文和结构化结果，避免整段聊天反复转发或摘要丢失关键约束。
- 失败处理：设定超时、有限重试、权限和人工介入条件；独立子任务才能安全并行。
- 效果验证：与单 Agent 比较成功率、成本、延迟及冲突率，确认拆分有收益。
LangGraph 侧重显式状态图，AutoGen 提供多 Agent 协作抽象，CrewAI 按角色和任务组织执行，OpenAI Agents SDK 提供工具、交接与追踪等能力。框架常见组件仍是模型适配、工具执行、状态存储、编排、检索、权限和观测；选择取决于任务需要。
A2A 与递归协作
A2A 用于 Agent 之间发现能力、委派任务和交换状态、结果。协议连通不代表任务会自动收敛，运行时仍需控制：
- 每个任务的目标、输入、输出及终止条件。
- 任务 ID、调用链、最大层数、轮数和总时间。
- 是否允许继续转发，如何检测重复委派和无进展循环。
职责不清、互相把任务抛回上游，容易导致递归。由编排者分发任务、执行者返回结果，是限制这种情况的一种方式。
Planning 与死循环
Plan-and-Execute 先生成步骤，再执行各步，并根据结果调整计划。步骤粒度应小到可验证，大到不必为每个细小动作增加一次规划调用。
反复调用相同工具、状态没有更新、反馈没有新信息、目标或终止条件不清，都可能导致循环。运行时应限制总步数、时间和成本，检测重复调用及无进展状态，再决定重新规划、澄清或停止。
Harness engineering
Harness 是围绕模型的执行环境，包括工具、上下文、任务状态、权限、测试和反馈。代码 Agent 场景中，可以用简短的项目说明提供入口，用局部文档描述约定，再通过测试、格式检查、CI 和评审提供可验证反馈。
重点是让执行结果可检查，失败可定位；增加更多说明文件或模型评审本身不等于质量提高。
To C 与 To B 的产品取舍
一种判断是：个人产品更看重易用性、响应速度、个性化与成本；企业产品更看重系统集成、权限、审计、稳定性和业务收益。这是需求侧的判断，不代表某种架构必然胜出。