面试题 · Prompt
搜索「检索增强」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在设计基于大模型的Agent系统时，如何从整体系统架构层面统筹考虑，并具体落实到Agent内部的prompt设计？请阐述你的设计思路和方法论。
感知层（Perception）
决策层（Planning）
执行层（Action）
学习内容与项目面试，在同一条路上。
记忆层（Memory）
1. 元指令层（Meta-Prompt）
角色定义 + 能力边界 + 安全约束2. 推理范式层（Reasoning Pattern）
3. 动态上下文层（Runtime Context）
| 问题 | 解法 |
|---|---|
| 上下文过长 | 滑动窗口 + 关键信息提取（LLM二次压缩） |
| 工具选择错误 | 增加工具使用条件说明 + 负例Few-shot |
| 循环/死锁 | Prompt显式限制最大步数 + 强制终止规则 |
| 幻觉累积 | Observation必须严格基于工具返回，禁止臆造 |
核心原则：架构决定上限，Prompt决定稳定性。复杂逻辑下沉到代码（状态机、规则引擎），LLM专注"模糊决策"环节。
场景切入
我看你做过客服助手，假设用户问“帮我查一下订单”，然后你让Agent去调接口，接着用户又问“那再帮我改个地址”，这时候Agent内部怎么决定是继续用之前的工具还是重新规划？你从架构上怎么把prompt和整个流程串起来设计？
层层追问
你设计过Agent系统吧，整体架构你是怎么考虑的？……比如感知、决策这些层怎么分？……那落实到每个Agent内部的prompt，你怎么保证它不乱调用工具？……具体怎么把ReAct思路写进prompt里？
直球架构
设计一个基于大模型的Agent系统，要求从架构层面分层，并且每层的设计要直接指导Agent内部prompt的写法。请给出你的分层方案和prompt设计方法论，比如元指令、推理范式、动态上下文这些怎么落地。
这道题我觉得本质上是在问，怎么把大模型的能力稳定地封装到一个可落地的系统里，同时让prompt设计能跟上架构的节奏，而不是各自为战。我先说整体架构，再说prompt怎么跟它配合。
我会把系统分成四个层。感知层做输入网关，处理[[多模态]]、做安全过滤，还有一个很关键的决策：判断这个请求是走完整的[[Agent]]链路，还是简单问答短路直接回复。比如客服场景里用户问“退款流程是什么”，直接给标准答案就行，没必要走规划执行。决策层是核心，负责任务分解和工具选择，我一般用 [[ReAct]] 范式，就是Thought、Action、Observation循环，也会结合 [[Chain-of-Thought]] 做复杂推理。执行层是工具注册中心，工具要标准化成OpenAI Function格式，还要做执行沙箱，控制超时和并发，避免一个工具卡死整个Agent。记忆层分短期和长期，短期用对话窗口和 [[KV Cache]] 复用，长期用向量检索加结构化知识库。
prompt设计我按三层递进来做。第一层是元指令，定义角色、能力边界和安全约束，明确告诉模型什么能做、什么不能做，比如金融场景里绝不能给投资建议，一旦用户问这个，直接拒绝。第二层是推理范式层，我用ReAct格式，强制输出JSON Schema，这样解析失败率会很低。还会给两三个[[Few-shot]]例子，让模型知道标准推理轨迹长什么样。第三层是动态上下文层，这是最关键的。工具描述不能全量塞进去，要用 [[RAG]] 检索只注入相关工具，比如用户问天气，你只给天气工具的描述，别把计算器、日历都扔进去。历史轨迹要压缩，关键节点摘要加最近三轮对话就够了。状态变量像当前步骤数、已用token也要跟踪。
举个例子，电商场景里用户问“为什么我用了满减券但订单金额没变”，Agent先感知到这是订单异常，决策层分解成查订单、查优惠券、查商品价格三个子任务，执行层依次调接口，最后推理出是商品不参与满减，然后生成回复。这个过程中，prompt里的工具描述只注入订单查询和优惠券查询两个相关工具，历史轨迹压缩成“用户已提交订单号，查询优惠券规则中”，避免上下文过长。
这里有个坑，就是上下文过长。我会用[[滑动窗口]]加关键信息提取，让LLM二次压缩历史。还有工具误选，我会在工具描述里加使用条件说明和负例Few-shot，比如“这个工具只用于查询已支付订单，未支付订单不要用”。循环死锁问题，prompt里显式限制最大步数，比如最多五步，超过就强制终止并返回兜底话术。[[幻觉]]累积也很常见，我会要求Observation必须严格基于工具返回，禁止模型自己编造。
所以说，架构决定上限，prompt决定稳定性。复杂逻辑像状态机、规则引擎这些，我会下沉到代码里，LLM只专注做模糊决策那部分。上线前我会特别关注边界情况，比如工具返回空结果时模型怎么处理，会不会自己编一个。
还有一个我最近在思考的点，就是当工具数量超过一定规模时，光靠RAG检索工具描述可能不够，工具之间的依赖关系如果没处理好，Agent容易选错工具顺序。比如先查库存再改价格，顺序反了就会出问题。这个可能得引入图结构或者规则约束来辅助工具选择，但我还没完全想清楚最优方案。