考察点
「设计一个企业级 Agent 系统需要考虑哪些点」的缩小版，考察你能不能把 Agent 从「一个 prompt 循环」提升到「分层系统」的视角。面试官关心每层职责、层间协议，以及每层最容易出问题的地方。
参考答案
核心四组件
先答经典四件，再谈分层：
- LLM（大脑）：负责理解目标、做决策、生成响应。选型时关注的不是跑分，而是 tool calling 的稳定性、指令遵循能力和上下文窗口。
- Tools（手）：Function Call 或 MCP 接入的外部能力。工具描述的质量直接决定调用准确率——参数 schema 写清楚、每个字段给例子，比换更强的模型见效快。
- Memory（记忆）：短期记忆是工作上下文（对话历史 + 中间观察），长期记忆是跨会话的向量库或结构化存储。
- Planning & Loop（神经中枢）：任务分解策略（ReAct / Plan-and-Execute）加上循环控制（步数上限、超时、终止条件）。
分层架构
企业级系统我习惯画四层，自顶向下：
1. 交互层（Interface）。对接用户或上游系统：Web 聊天、API、IM 机器人。职责是会话管理、流式输出（SSE）、权限入口。这层最关键的是把流式中间过程暴露出来——Agent 跑十几秒没动静用户会以为挂了，把「正在调用 xxx 工具」实时推给前端，体验天差地别。
2. 编排层（Orchestration）。系统的心脏：Agent 循环、状态机、检查点（checkpoint）、中断恢复。LangGraph 这类框架就活在这层。生产上两个必备能力：持久化状态（跑到一半进程挂了能从 checkpoint 续跑）和人工介入点（高风险动作暂停等人审，human-in-the-loop）。
3. 能力层（Capability）。工具注册中心 + 记忆服务。工具要有统一的元数据（schema、超时、重试策略、权限级别），新工具注册即接入，不改编排代码。记忆服务对外暴露读写接口，内部可以是向量库 + KV + 关系库的混合。
4. 基础设施层（Infra）。模型网关（多模型路由、限流、降级）、可观测（trace 记录每次 LLM 调用和工具调用的完整输入输出）、评估流水线。这层决定系统是 demo 还是产品——没有 trace 的 Agent 出了 bug 等于黑盒。
各层最容易踩的坑
交互层：多轮会话的上下文拼接没管好，把上一轮的任务残留带进新任务（上下文污染）。
编排层：只设计了 happy path，没有给循环设终止条件，凌晨三点 Agent 自己跑了几千步把 token 预算烧光——这是真事。
能力层：工具失败时把原始堆栈报错（几百行）直接塞回上下文，模型被无关信息带偏。工具层应该返回「结构化错误摘要」。
基础设施层：早期为了省事直接写死调一家模型 API，后期想加国产模型降成本时发现到处是硬编码，模型网关要第一天就有。
和传统软件架构的关键差异
传统分层架构每层的行为是确定的，测试靠用例覆盖；Agent 系统编排层的行为是概率的，所以要在每层之间加确定性护栏：层间传结构化数据（schema 校验）、关键动作走规则而不是模型自由发挥、所有不确定输出落 trace 供事后审计。一句话：用确定性的工程结构去圈住不确定性的模型行为，这就是 Agent 架构设计的全部要义。
可能的追问
- 「状态持久化具体怎么做？」 每步执行后把 Agent 状态（消息历史、当前计划、变量）序列化存 Redis 或 Postgres，LangGraph 的 checkpointer 就是干这个的；崩溃恢复和人工审批都从 checkpoint 读。
- 「工具注册中心要解决什么问题？」 工具数量上来后（20+），全塞进 prompt 会爆窗口且干扰选择，需要按任务动态筛选相关工具子集，注册中心提供检索和元数据。
- 「网关层做多模型路由的依据是什么？」 按任务难度分流：规划、最终生成用强模型，工具结果摘要、格式转换用小模型，成本能降一半以上。