面试题 · Prompt
搜索「RAG」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在设计Agent系统时，从整体架构到内部prompt设计，应该遵循哪些原则和方法？
四层架构模型
关键设计点
学习内容与项目面试，在同一条路上。
结构化模板
[角色定义] + [任务目标] + [可用工具说明] + [输出格式约束] + [ few-shot示例 ]核心原则
description + parameters + required，LLM据此决策thought字段暴露推理过程动态组装
| 机制 | 实现要点 |
|---|---|
| 自我反思 | 执行后追加"检查结果是否正确"步骤，错误时触发重规划 |
| 中断恢复 | 保存执行状态快照，支持从断点继续而非重启 |
| 人机协同 | 置信度低于阈值或涉及敏感操作时，转人工确认 |
场景切入
假设我们要做一个智能客服Agent，用户问“帮我查一下订单”，Agent需要调用订单API。你会怎么设计这个Agent的整体架构？从感知输入到最终回复，有哪些关键层？
层层追问
你在设计Agent的时候，一般怎么组织它的能力？……如果Agent需要调用多个工具，怎么让LLM知道什么时候该用哪个？……那如果工具调用失败了，Agent能自己恢复吗？……再往细了说，给LLM的prompt里，工具描述怎么写才不容易出错？
直球架构
直接讲一下设计一个Agent系统时，从整体架构到内部prompt设计，应该遵循哪些原则和方法？比如架构分几层，每层做什么，prompt怎么结构化，怎么支持工具调用和错误恢复。
这道题我觉得本质上是在问，怎么把一个LLM从一个单轮对话工具，变成一个能自主完成任务、能应对环境变化的系统。核心不是堆功能，而是做取舍。
先说整体架构。我一般会拆成四层：感知、规划、执行、记忆。感知层就是统一输入入口，不管文本、图片还是API数据，都转成内部标准格式。规划层是大脑，负责任务分解和策略选择。执行层是手脚，跟具体工具解耦，比如调数据库、发邮件。记忆层分短期和长期，短期就是对话上下文，长期存知识和经验。
这里有个关键点：规划层和执行层必须分离。你不能让LLM直接操作外部系统，那样太危险，一旦[[Hallucination]]，它可能乱调用工具造成破坏。所以规划层只输出意图和参数，执行层做安全校验。
再说Prompt设计。我会用结构化模板，固定角色定义、任务目标，动态塞工具描述和[[Few-shot]]示例。工具描述用[[Function Calling]]的Schema格式，每个工具写明description、parameters、required。输出强制JSON格式，预留thought字段暴露推理过程，这样出了问题能回溯。
一个常见的坑是工具列表太长，上下文窗口被无关工具占满，LLM决策质量下降。所以我上线前会做工具按需加载，根据当前任务只加载可能用到的工具。
举个例子，在客服退款场景里，[[Agent]]需要查订单、查退款规则、执行退款。规划层会先分解：先查订单状态，再匹配退款政策，然后判断是自动退还是转人工。执行层分别调订单系统、规则引擎。如果中间某个步骤失败，比如订单查不到，规划层要能触发重规划，而不是卡死。
记忆机制上，短期记忆就是对话历史，但我会用[[滑动窗口]]控制长度。长期记忆我用[[RAG]]，把历史案例和知识文档[[向量化]]，需要时检索。这里有个前提：知识库要定期更新，并且做质量校验，不然检索到过期信息反而害了Agent。
容错方面，我特别关注两点。一是自我反思，每次执行后追加一步检查结果，如果发现错误就回退重来。二是中断恢复，保存执行状态快照，万一超时或崩溃，可以从断点继续，不用从头开始。
其实还有一个更难的问题我还在想，就是当多个Agent协作时，怎么协调它们之间的依赖和冲突，比如一个Agent要等另一个Agent的结果，但结果一直不出，整个系统就僵住了。这个在[[Multi-Agent]]场景里特别常见。
所以最后我的判断是：没有万能架构。简单任务用[[ReAct]]循环就够了，复杂任务才需要完整四层。我更倾向先搭一个最小闭环，跑通后再逐步加记忆、加反思。上线后我会重点监控两个指标：一是任务完成率，二是平均重试次数。如果重试太多，说明规划层或者工具描述有问题。