完整题目
在设计基于大模型的Agent系统时，如何从整体系统架构层面统筹考虑，并具体落实到Agent内部的prompt设计？请阐述你的设计思路和方法论。
本文目录
答案要点
- 系统架构分层设计（感知层/决策层/执行层/记忆层）
- Prompt模块化与职责分离
- ReAct/CoT等推理范式与工具调用的结合
- 状态管理与上下文压缩策略
- 安全边界与异常回退机制
一、系统架构层面：四层分离设计
感知层（Perception）
- 统一输入网关：处理多模态输入、用户意图识别、安全过滤
- 关键决策：是否走Agent链路 vs 直接回复（简单问答短路）
决策层（Planning）
- 核心模块：任务分解、工具选择、执行计划生成
- 支持多范式：ReAct、Plan-and-Solve、Reflexion自我修正
执行层（Action）
- 工具注册中心：标准化Tool Schema（OpenAI Function格式）
- 执行沙箱：超时控制、并发限制、结果缓存
记忆层（Memory）
- 短期：对话窗口、KV Cache复用
- 长期：向量检索 + 结构化知识库 + 用户画像
二、Prompt设计方法论：三层递进
1. 元指令层（Meta-Prompt）
角色定义 + 能力边界 + 安全约束- 明确"能做什么、不能做什么"，设置拒绝话术模板
2. 推理范式层（Reasoning Pattern）
- ReAct格式：Thought → Action → Observation 循环
- 结构化输出：强制JSON Schema，降低解析失败率
- Few-shot示例：2-3个典型场景的标准推理轨迹
3. 动态上下文层（Runtime Context）
- 工具描述：仅注入相关工具（RAG检索筛选），非全量
- 历史轨迹：关键节点摘要 + 最近3轮完整对话
- 状态变量：当前步骤数、已用token、用户偏好
三、关键落地技巧
| 问题 | 解法 |
|---|---|
| 上下文过长 | 滑动窗口 + 关键信息提取（LLM二次压缩） |
| 工具选择错误 | 增加工具使用条件说明 + 负例Few-shot |
| 循环/死锁 | Prompt显式限制最大步数 + 强制终止规则 |
| 幻觉累积 | Observation必须严格基于工具返回，禁止臆造 |
核心原则：架构决定上限，Prompt决定稳定性。复杂逻辑下沉到代码（状态机、规则引擎），LLM专注"模糊决策"环节。
换一种问法，检查是否真正理解
场景切入
我看你做过客服助手，假设用户问“帮我查一下订单”，然后你让Agent去调接口，接着用户又问“那再帮我改个地址”，这时候Agent内部怎么决定是继续用之前的工具还是重新规划？你从架构上怎么把prompt和整个流程串起来设计？
层层追问
你设计过Agent系统吧，整体架构你是怎么考虑的？……比如感知、决策这些层怎么分？……那落实到每个Agent内部的prompt，你怎么保证它不乱调用工具？……具体怎么把ReAct思路写进prompt里？
直球架构
设计一个基于大模型的Agent系统，要求从架构层面分层，并且每层的设计要直接指导Agent内部prompt的写法。请给出你的分层方案和prompt设计方法论，比如元指令、推理范式、动态上下文这些怎么落地。
练习口述回答 · 约4分钟
- 本质问架构与prompt的配合
- 四层架构：感知决策执行记忆
- prompt三层递进：元指令推理动态上下文
- 落地风险：上下文过长工具误选循环
- 我的取舍：复杂逻辑下沉LLM专注模糊决策
这道题我觉得本质上是在问，怎么把大模型的能力稳定地封装到一个可落地的系统里，同时让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容易选错工具顺序。比如先查库存再改价格，顺序反了就会出问题。这个可能得引入图结构或者规则约束来辅助工具选择，但我还没完全想清楚最优方案。