Agent 系统架构与 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]]场景里特别常见。