尧图网站建设 
1. 为什么“七要素”和“七个决策点”是理解 Agent 的两把钥匙很多人第一次接触 AI Agent 这个概念时脑子里浮现的画面是科幻电影里那种能自己思考、自己行动的智能体。但真到了动手搭建的时候你会发现事情远没有那么玄乎——Agent 本质上就是一套围绕大语言模型构建的工程系统它的“智能”来自于精心设计的循环机制、工具调用和上下文管理而不是什么魔法。我刚开始研究 Agent 架构的时候最大的困惑就是市面上关于 Agent 的文章要么太浅只告诉你“Agent 就是 LLM 加工具调用”要么太深直接跳到某个框架的源码分析。中间那层“到底一个 Agent 由哪些核心部件组成、每个部件在工程上怎么做取舍”的内容反而很少有人系统讲清楚。后来我逐渐摸索出一个认知框架七要素回答的是“一个 Agent 由什么构成”七个决策点回答的是“在构建过程中你需要做哪些关键选择”。前者是静态的结构拆解后者是动态的工程决策。把这两条线交织起来看Agent 的工程实现就变得清晰了。这篇文章适合谁看如果你已经用过大模型 API知道什么是 prompt、什么是 token但还没系统性地搭建过一个完整的 Agent 系统那这篇内容就是为你准备的。如果你已经在做 Agent 开发但对某些设计选择还心存疑虑比如“记忆到底该怎么做”“工具调用失败了怎么办”那这篇文章也可以作为一份工程决策的对照清单。下面我会先拆解 Agent 的七个核心要素然后逐一展开七个关键决策点每个决策点都会给出我的实际经验、常见坑和可落地的方案。2. Agent 七要素从静态结构看一个智能体的完整解剖2.1 大语言模型Agent 的“大脑”到底该怎么选大语言模型是整个 Agent 系统的推理核心所有的决策、规划、工具选择、结果判断最终都要落到 LLM 的推理能力上。但选模型这件事远不是“选最强的那个”这么简单。我在实际项目中的经验是模型选型要同时考虑四个维度推理能力、响应延迟、调用成本和上下文窗口。这四个维度往往是互相矛盾的——推理能力强的模型通常更贵、更慢上下文窗口大的模型可能在特定任务上的精度反而不如专门优化过的中小模型。举个例子如果你做的是一个客服场景的 Agent需要快速响应用户的简单问题那用一个超大模型就是浪费。反过来如果你做的是一个代码审查 Agent需要理解复杂的代码逻辑和依赖关系那模型推理能力的优先级就远高于延迟和成本。还有一个容易被忽略的点模型输出格式的稳定性。Agent 系统通常需要 LLM 输出结构化的内容比如 JSON 格式的工具调用请求但不同模型对格式指令的遵循程度差异很大。我实测下来有些模型在简单对话中表现很好但一旦要求它输出严格的 JSON就开始“自由发挥”加一些额外的解释文字导致解析失败。所以在选模型时一定要用你的实际任务 prompt 做一轮格式遵循度的测试。提示不要只看模型排行榜上的综合得分。Agent 场景下模型在“指令遵循”和“结构化输出”这两个细分能力上的表现比综合得分更有参考价值。2.2 工具集Agent 与外部世界交互的桥梁工具是 Agent 能力的延伸。没有工具的 Agent 只能“纸上谈兵”有了工具它才能查数据库、调 API、读写文件、执行代码。工具集的设计直接决定了 Agent 能做什么、不能做什么。从工程角度看工具的定义需要包含几个关键信息工具名称、功能描述、参数 schema、返回值格式。其中功能描述和参数 schema 是给 LLM 看的它们决定了 LLM 能否正确地选择和使用工具。我见过很多新手在定义工具时犯的一个典型错误功能描述写得太简略。比如写一个“查询天气”的工具描述只写“查询天气”参数只写“城市”。这样 LLM 根本不知道这个工具支持哪些查询方式、返回什么格式的数据、有没有什么限制条件。结果就是 LLM 要么不用这个工具要么用了之后不知道怎么处理返回值。正确的做法是把工具描述当成一份给 LLM 看的“使用说明书”。要写清楚这个工具能做什么、输入参数的含义和格式、返回值的结构、有没有调用频率限制、出错时返回什么。描述越清晰LLM 调用工具的准确率就越高。2.3 记忆系统让 Agent 不再“金鱼脑”记忆系统是 Agent 工程中最容易被低估、也最容易做砸的部分。没有记忆的 Agent 每次对话都是“初次见面”用户上一句说的话、之前完成的任务、积累的偏好全都记不住。从工程实现上记忆通常分为三层短期记忆当前对话轮次内的上下文通常直接放在 prompt 里受限于模型的上下文窗口大小。长期记忆跨对话轮次持久化的信息需要外部存储支持比如向量数据库、关系数据库或文件系统。工作记忆Agent 在执行复杂任务过程中的中间状态比如已经完成了哪些子任务、当前正在处理哪一步。这三层记忆的管理策略完全不同。短期记忆的关键是“怎么在有限的上下文窗口里塞进最有用的信息”长期记忆的关键是“怎么高效地存储和检索”工作记忆的关键是“怎么在任务执行过程中保持状态的一致性”。2.4 规划模块把大目标拆成小步骤规划模块负责把用户的模糊需求拆解成可执行的步骤序列。比如用户说“帮我分析一下上个月的销售数据并生成报告”规划模块需要把这个需求拆成获取数据、清洗数据、计算关键指标、生成图表、撰写报告文字、整合输出。规划的实现方式有好几种。最简单的是隐式规划——不单独做规划而是让 LLM 在每一步根据当前状态决定下一步做什么。这种方式实现简单但对 LLM 的推理能力要求高而且容易出现“走一步看一步”导致全局效率低下的问题。另一种是显式规划——先让 LLM 生成一个完整的步骤列表然后按顺序执行。这种方式全局性好但灵活性差一旦中间某一步的结果和预期不符整个计划可能都需要调整。我在实际项目中更倾向于一种混合方式先让 LLM 生成一个粗粒度的计划框架然后在执行每一步时根据实际结果动态调整后续步骤。这样既有全局方向又有局部灵活性。2.5 执行引擎循环机制的核心执行引擎是 Agent 的“心脏”它负责驱动整个“感知-思考-行动”的循环。一个典型的 Agent 循环是这样的接收输入用户消息或上一步的执行结果调用 LLM 进行推理决定下一步行动如果 LLM 决定调用工具执行工具调用并获取结果把工具结果反馈给 LLM继续下一轮推理如果 LLM 决定输出最终答案循环结束这个循环看似简单但工程上有大量细节需要处理循环的最大轮次限制、超时控制、错误重试、状态保存与恢复、并发控制等等。任何一个细节处理不好都可能导致 Agent 陷入死循环、响应超时或者状态混乱。2.6 上下文管理决定 Agent 表现的关键变量上下文管理是很多人做 Agent 时最容易忽视的环节。它要解决的问题是在每一轮 LLM 调用时到底把哪些信息放进 prompt 里。上下文窗口是有限的而 Agent 在执行任务过程中产生的信息是不断增长的——对话历史、工具调用记录、中间结果、错误信息等等。如果不加管理地把所有信息都塞进 prompt很快就会超出上下文窗口限制而且大量无关信息还会干扰 LLM 的推理。好的上下文管理策略需要做到保留关键信息、压缩冗余信息、按需检索历史信息。具体怎么做后面在决策点部分会详细展开。2.7 安全与护栏让 Agent 不“失控”安全与护栏是 Agent 从 Demo 走向生产环境必须跨过的一道坎。一个没有护栏的 Agent可能会调用不该调用的工具、输出不该输出的内容、执行危险的操作。护栏通常包括几个层面输入过滤检查用户输入是否包含恶意指令、工具权限控制限制 Agent 能调用哪些工具、调用时的参数范围、输出审查检查 Agent 的输出是否符合规范、行为边界限制 Agent 的操作范围比如只能读不能写。这一块在实际项目中往往被放到最后才做但我的建议是从第一天就把护栏机制设计进去不要等到出问题了再补。3. 七个决策点构建 Agent 时必须做的关键选择3.1 决策点一Agent 的自主程度——从固定流程到完全自主这是构建 Agent 时第一个要做的决策也是最根本的决策你希望 Agent 有多自主这个决策可以用一个光谱来表示自主程度特点适用场景实现难度固定流程步骤预定义LLM 只在特定节点做判断流程稳定的业务场景低半自主LLM 可以在预定义的工具集中选择但流程框架固定客服、问答、数据分析中完全自主LLM 自主决定每一步做什么包括是否创建新工具开放式研究、复杂问题求解高我见过很多团队一上来就追求“完全自主”结果做出来的东西既不稳定也不可控。实际上大多数生产环境中的 Agent 都是“半自主”的——给 LLM 一定的选择空间但用工程手段框定它的行为边界。选择自主程度的核心依据是你的任务有多大的不确定性如果用户的请求类型是有限的、可枚举的那固定流程或半自主就够了。如果用户可能提出任何类型的请求那才需要完全自主的架构。3.2 决策点二工具调用的粒度——粗一点还是细一点工具调用的粒度设计直接影响 Agent 的灵活性和可靠性。粗粒度工具一个工具做很多事情。比如一个“处理订单”的工具内部包含了查询、修改、取消等多个操作。优点是 LLM 只需要选一个工具决策简单缺点是灵活性差LLM 无法精细控制具体做什么。细粒度工具一个工具只做一件事。比如“查询订单”“修改订单”“取消订单”分别是三个工具。优点是灵活LLM 可以精确控制缺点是 LLM 需要做更多的选择出错概率增加。我的经验是工具数量在 5-15 个之间时细粒度更好超过 15 个时需要做适当的分组和粗化。因为 LLM 在大量工具中选择时准确率会明显下降。一个实用的技巧是给工具加“分类标签”让 LLM 先选分类再选具体工具降低单次选择的复杂度。3.3 决策点三记忆的存储与检索策略记忆系统的决策点主要包括存什么、怎么存、怎么取。存什么不是所有信息都值得存。我的原则是存三类信息——用户的明确偏好和约束、任务执行的关键结果、之前失败过的尝试避免重复犯错。怎么存简单的键值对存储适合结构化信息向量数据库适合语义检索图数据库适合存储实体之间的关系。实际项目中往往是组合使用。怎么取这是最关键的。全量加载会撑爆上下文窗口随机采样可能漏掉关键信息。我常用的策略是“最近优先 相关性检索 重要性加权”三者结合最近的对话轮次直接加载历史信息通过向量相似度检索同时给不同类型的信息设置不同的重要性权重。注意记忆检索的时机也很重要。不要每一轮都做检索那样会增加延迟和成本。我通常是在任务开始时检索一次然后在执行过程中每隔几轮检索一次或者在 LLM 明确表示需要历史信息时才触发检索。3.4 决策点四错误处理与容错机制Agent 在执行过程中出错是常态不是异常。工具调用可能超时、LLM 可能输出格式错误、外部 API 可能返回异常数据。错误处理机制的设计直接决定了 Agent 是“能用”还是“好用”。我通常把错误分为三个等级可恢复错误比如工具调用超时、格式解析失败。处理方式是重试但要设置最大重试次数和退避策略。可降级错误比如某个工具暂时不可用。处理方式是切换到备用方案或者跳过这一步继续执行。不可恢复错误比如权限不足、关键依赖缺失。处理方式是终止当前任务向用户报告具体原因。一个容易被忽视的点是错误信息也要反馈给 LLM。很多开发者只把成功的结果传给 LLM出错时直接抛异常终止。更好的做法是把错误信息也作为上下文的一部分传给 LLM让它自己决定是重试、换方案还是放弃。这样 Agent 就有了“自主容错”的能力。3.5 决策点五上下文窗口的分配与压缩上下文窗口是 Agent 最稀缺的资源之一。每一轮 LLM 调用你都需要在有限的窗口里塞进系统提示词、工具定义、对话历史、工具调用记录、当前任务状态、检索到的记忆……我的分配策略通常是这样的系统提示词和工具定义固定占用尽量精简最近 3-5 轮对话完整保留更早的对话压缩成摘要工具调用记录只保留关键结果去掉中间过程检索到的记忆按相关性排序取 top-k压缩策略上我常用两种方法一种是摘要压缩让 LLM 把长对话压缩成简短摘要另一种是结构化压缩把对话历史提取成结构化的状态信息比如“用户已提供姓名、订单号已完成查询订单待完成修改地址”。3.6 决策点六多 Agent 协作还是单 Agent 全能当任务复杂度上升到一定程度时你会面临一个选择是让一个 Agent 做所有事情还是拆成多个 Agent 各司其职单 Agent 的优点是架构简单、状态一致性好、调试方便。缺点是当任务涉及多个领域时prompt 会变得非常臃肿工具集也会变得很大导致 LLM 的选择准确率下降。多 Agent 的优点是每个 Agent 可以专注于自己的领域prompt 和工具集都更精简。缺点是 Agent 之间的通信和协调需要额外设计状态同步也是个问题。我的建议是先用单 Agent 跑通当单 Agent 的 prompt 超过 2000 字或者工具超过 15 个时再考虑拆分。拆分时按照“职责边界清晰、交互频率低”的原则来划分不要为了拆而拆。3.7 决策点七评估与迭代机制最后一个决策点也是最容易被忽略的你怎么知道你的 Agent 表现好不好怎么持续改进Agent 的评估比传统软件测试复杂得多因为它的输出是非确定性的。同一个输入Agent 可能走不同的路径、调用不同的工具、给出不同的答案。我常用的评估方法是场景化测试集 人工评审 自动化指标三结合场景化测试集收集真实用户请求构建覆盖主要场景的测试用例人工评审定期抽样检查 Agent 的输出质量自动化指标工具调用准确率、任务完成率、平均轮次、平均 token 消耗迭代时我建议每次只改一个变量然后跑一遍测试集对比效果。同时改多个变量你根本不知道是哪个改动起了作用。4. 从零搭建一个 Agent 的实操路径4.1 环境准备与技术选型动手之前先把基础环境搭好。我以 Python 技术栈为例因为生态最成熟。核心依赖包括大模型 SDK用于调用 LLM、Web 框架用于提供 API 接口、向量数据库用于记忆存储、以及一些工具库用于 HTTP 请求、文件操作等。pip install openai fastapi uvicorn chromadb requests pydantic技术选型上我的建议是不要一上来就用重型框架。很多 Agent 框架封装了大量抽象层看起来很方便但一旦出问题你很难定位是框架的问题还是你的代码的问题。先用原生 SDK 手写一个最小可用的 Agent 循环理解每一层的运作机制然后再根据需要引入框架。4.2 定义工具与工具注册机制工具的定义我推荐用 Pydantic 模型来做参数校验这样既能保证参数类型的正确性又能自动生成 JSON Schema 给 LLM 看。from pydantic import BaseModel, Field from typing import Callable class ToolParameter(BaseModel): name: str Field(description参数名称) type: str Field(description参数类型) description: str Field(description参数说明) required: bool Field(defaultTrue) class Tool: def __init__(self, name: str, description: str, parameters: list[ToolParameter], func: Callable): self.name name self.description description self.parameters parameters self.func func def to_schema(self) - dict: return { type: function, function: { name: self.name, description: self.description, parameters: { type: object, properties: { p.name: {type: p.type, description: p.description} for p in self.parameters }, required: [p.name for p in self.parameters if p.required] } } }工具注册中心负责管理所有可用工具并提供按名称查找的能力。这里有个细节工具的描述文字要反复打磨它是 LLM 选择工具的唯一依据。4.3 实现核心循环机制核心循环是整个 Agent 的骨架。我用伪代码展示一下关键逻辑def agent_loop(user_input: str, max_turns: int 10): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_input}) for turn in range(max_turns): response call_llm(messages, toolstool_schemas) if response.has_tool_call(): tool_name response.tool_call.name tool_args response.tool_call.arguments try: result execute_tool(tool_name, tool_args) messages.append({role: tool, content: str(result)}) except Exception as e: messages.append({role: tool, content: f错误{str(e)}}) else: return response.content return 达到最大轮次限制任务未完成这个循环里有几个关键设计最大轮次限制防止死循环、工具执行异常被捕获并反馈给 LLM、每一轮都把工具结果追加到消息历史中。4.4 接入记忆系统记忆系统的接入分两步写入和读取。写入的时机是任务完成后或关键信息产生时。读取的时机是任务开始时和需要历史信息时。class MemoryStore: def __init__(self, collection_name: str agent_memory): self.client chromadb.Client() self.collection self.client.get_or_create_collection(collection_name) def save(self, content: str, metadata: dict): self.collection.add( documents[content], metadatas[metadata], ids[fmem_{time.time()}] ) def retrieve(self, query: str, top_k: int 3) - list[str]: results self.collection.query(query_texts[query], n_resultstop_k) return results[documents][0] if results[documents] else []实际使用中我会给每条记忆加上类型标签偏好、事实、经验和时间戳检索时根据类型和时间做加权排序。4.5 加入护栏与安全控制护栏的实现可以很简单但必须要有。最基本的护栏包括工具白名单只允许调用注册过的工具参数校验检查工具参数是否在允许范围内输出过滤检查 Agent 输出是否包含敏感信息轮次限制防止无限循环超时控制每个工具调用设置超时时间ALLOWED_TOOLS {search_web, read_file, calculate} MAX_TOOL_CALLS_PER_TURN 3 def execute_tool(name: str, args: dict): if name not in ALLOWED_TOOLS: raise PermissionError(f工具 {name} 不在允许列表中) if len(args) MAX_TOOL_CALLS_PER_TURN: raise ValueError(参数数量超出限制) # ... 执行工具这些护栏看起来简单但在实际项目中能避免大量问题。5. 实际项目中踩过的坑与应对经验5.1 LLM 输出格式不稳定导致的解析失败这是最常见的问题。你要求 LLM 输出 JSON它偏偏在 JSON 前面加一句“好的我来帮你调用工具”或者在 JSON 后面加一句“以上就是我的回答”。解析器直接崩溃。我的应对方案是三层防护第一层在 prompt 里用强烈的指令要求只输出 JSON并给出示例第二层用正则表达式提取 JSON 部分忽略前后的多余文字第三层如果解析仍然失败把解析错误信息反馈给 LLM让它重新输出。实测下来三层防护能把格式解析成功率从 85% 左右提升到 99% 以上。5.2 工具调用陷入死循环Agent 反复调用同一个工具每次都得到相同的结果但就是不停下来。这种情况通常发生在工具返回的结果不明确时——LLM 不确定任务是否完成就反复尝试。解决方案有两个一是设置工具调用的最大次数超过就强制终止二是在工具返回结果中明确标注“任务已完成”或“任务未完成原因如下”帮助 LLM 做判断。5.3 上下文窗口溢出任务执行到一半突然报错说超出了上下文窗口限制。这是因为对话历史和工具调用记录不断累积最终撑爆了窗口。我的处理方式是实时监控 token 数量当接近窗口上限的 80% 时触发压缩流程把最早的几轮对话压缩成摘要只保留关键信息。压缩后的摘要替换原始对话释放出空间。5.4 工具描述歧义导致选错工具有两个功能相似的工具LLM 总是选错。比如“查询用户信息”和“查询订单信息”LLM 经常搞混。解决方法是让工具描述之间的差异更加明显。不要只写“查询用户信息”而是写“根据用户 ID 查询用户的基本信息包括姓名、邮箱、注册时间。不包含订单信息”。把边界说清楚LLM 的选择准确率会大幅提升。6. 关于 Agent 工程实现的一些个人体会做 Agent 开发这段时间我最大的体会是Agent 的工程质量80% 取决于你对边界情况的处理而不是对正常流程的实现。正常流程谁都能跑通但真正决定一个 Agent 能不能上生产的是它在面对异常输入、工具故障、上下文溢出时的表现。另一个体会是不要追求一步到位的完美架构。我见过太多团队花大量时间设计“通用 Agent 框架”结果做出来的东西又复杂又不好用。更好的路径是先针对一个具体场景做一个能用的 Agent然后在迭代中逐步抽象出通用能力。还有一点评估机制要尽早建立。没有评估你就不知道你的改动是让 Agent 变好了还是变差了。哪怕一开始只有十几个测试用例也比没有强。最后Agent 这个领域变化很快新的模型、新的框架、新的模式层出不穷。但底层的工程原则——清晰的工具定义、健壮的错误处理、合理的上下文管理、严格的护栏控制——这些是不会变的。把基本功打扎实上层的技术怎么变都能跟上。 AI Agent 七要素与七个决策点：从零搭建智能体的工程实践指南
1. 为什么“七要素”和“七个决策点”是理解 Agent 的两把钥匙很多人第一次接触 AI Agent 这个概念时脑子里浮现的画面是科幻电影里那种能自己思考、自己行动的智能体。但真到了动手搭建的时候你会发现事情远没有那么玄乎——Agent 本质上就是一套围绕大语言模型构建的工程系统它的“智能”来自于精心设计的循环机制、工具调用和上下文管理而不是什么魔法。我刚开始研究 Agent 架构的时候最大的困惑就是市面上关于 Agent 的文章要么太浅只告诉你“Agent 就是 LLM 加工具调用”要么太深直接跳到某个框架的源码分析。中间那层“到底一个 Agent 由哪些核心部件组成、每个部件在工程上怎么做取舍”的内容反而很少有人系统讲清楚。后来我逐渐摸索出一个认知框架七要素回答的是“一个 Agent 由什么构成”七个决策点回答的是“在构建过程中你需要做哪些关键选择”。前者是静态的结构拆解后者是动态的工程决策。把这两条线交织起来看Agent 的工程实现就变得清晰了。这篇文章适合谁看如果你已经用过大模型 API知道什么是 prompt、什么是 token但还没系统性地搭建过一个完整的 Agent 系统那这篇内容就是为你准备的。如果你已经在做 Agent 开发但对某些设计选择还心存疑虑比如“记忆到底该怎么做”“工具调用失败了怎么办”那这篇文章也可以作为一份工程决策的对照清单。下面我会先拆解 Agent 的七个核心要素然后逐一展开七个关键决策点每个决策点都会给出我的实际经验、常见坑和可落地的方案。2. Agent 七要素从静态结构看一个智能体的完整解剖2.1 大语言模型Agent 的“大脑”到底该怎么选大语言模型是整个 Agent 系统的推理核心所有的决策、规划、工具选择、结果判断最终都要落到 LLM 的推理能力上。但选模型这件事远不是“选最强的那个”这么简单。我在实际项目中的经验是模型选型要同时考虑四个维度推理能力、响应延迟、调用成本和上下文窗口。这四个维度往往是互相矛盾的——推理能力强的模型通常更贵、更慢上下文窗口大的模型可能在特定任务上的精度反而不如专门优化过的中小模型。举个例子如果你做的是一个客服场景的 Agent需要快速响应用户的简单问题那用一个超大模型就是浪费。反过来如果你做的是一个代码审查 Agent需要理解复杂的代码逻辑和依赖关系那模型推理能力的优先级就远高于延迟和成本。还有一个容易被忽略的点模型输出格式的稳定性。Agent 系统通常需要 LLM 输出结构化的内容比如 JSON 格式的工具调用请求但不同模型对格式指令的遵循程度差异很大。我实测下来有些模型在简单对话中表现很好但一旦要求它输出严格的 JSON就开始“自由发挥”加一些额外的解释文字导致解析失败。所以在选模型时一定要用你的实际任务 prompt 做一轮格式遵循度的测试。提示不要只看模型排行榜上的综合得分。Agent 场景下模型在“指令遵循”和“结构化输出”这两个细分能力上的表现比综合得分更有参考价值。2.2 工具集Agent 与外部世界交互的桥梁工具是 Agent 能力的延伸。没有工具的 Agent 只能“纸上谈兵”有了工具它才能查数据库、调 API、读写文件、执行代码。工具集的设计直接决定了 Agent 能做什么、不能做什么。从工程角度看工具的定义需要包含几个关键信息工具名称、功能描述、参数 schema、返回值格式。其中功能描述和参数 schema 是给 LLM 看的它们决定了 LLM 能否正确地选择和使用工具。我见过很多新手在定义工具时犯的一个典型错误功能描述写得太简略。比如写一个“查询天气”的工具描述只写“查询天气”参数只写“城市”。这样 LLM 根本不知道这个工具支持哪些查询方式、返回什么格式的数据、有没有什么限制条件。结果就是 LLM 要么不用这个工具要么用了之后不知道怎么处理返回值。正确的做法是把工具描述当成一份给 LLM 看的“使用说明书”。要写清楚这个工具能做什么、输入参数的含义和格式、返回值的结构、有没有调用频率限制、出错时返回什么。描述越清晰LLM 调用工具的准确率就越高。2.3 记忆系统让 Agent 不再“金鱼脑”记忆系统是 Agent 工程中最容易被低估、也最容易做砸的部分。没有记忆的 Agent 每次对话都是“初次见面”用户上一句说的话、之前完成的任务、积累的偏好全都记不住。从工程实现上记忆通常分为三层短期记忆当前对话轮次内的上下文通常直接放在 prompt 里受限于模型的上下文窗口大小。长期记忆跨对话轮次持久化的信息需要外部存储支持比如向量数据库、关系数据库或文件系统。工作记忆Agent 在执行复杂任务过程中的中间状态比如已经完成了哪些子任务、当前正在处理哪一步。这三层记忆的管理策略完全不同。短期记忆的关键是“怎么在有限的上下文窗口里塞进最有用的信息”长期记忆的关键是“怎么高效地存储和检索”工作记忆的关键是“怎么在任务执行过程中保持状态的一致性”。2.4 规划模块把大目标拆成小步骤规划模块负责把用户的模糊需求拆解成可执行的步骤序列。比如用户说“帮我分析一下上个月的销售数据并生成报告”规划模块需要把这个需求拆成获取数据、清洗数据、计算关键指标、生成图表、撰写报告文字、整合输出。规划的实现方式有好几种。最简单的是隐式规划——不单独做规划而是让 LLM 在每一步根据当前状态决定下一步做什么。这种方式实现简单但对 LLM 的推理能力要求高而且容易出现“走一步看一步”导致全局效率低下的问题。另一种是显式规划——先让 LLM 生成一个完整的步骤列表然后按顺序执行。这种方式全局性好但灵活性差一旦中间某一步的结果和预期不符整个计划可能都需要调整。我在实际项目中更倾向于一种混合方式先让 LLM 生成一个粗粒度的计划框架然后在执行每一步时根据实际结果动态调整后续步骤。这样既有全局方向又有局部灵活性。2.5 执行引擎循环机制的核心执行引擎是 Agent 的“心脏”它负责驱动整个“感知-思考-行动”的循环。一个典型的 Agent 循环是这样的接收输入用户消息或上一步的执行结果调用 LLM 进行推理决定下一步行动如果 LLM 决定调用工具执行工具调用并获取结果把工具结果反馈给 LLM继续下一轮推理如果 LLM 决定输出最终答案循环结束这个循环看似简单但工程上有大量细节需要处理循环的最大轮次限制、超时控制、错误重试、状态保存与恢复、并发控制等等。任何一个细节处理不好都可能导致 Agent 陷入死循环、响应超时或者状态混乱。2.6 上下文管理决定 Agent 表现的关键变量上下文管理是很多人做 Agent 时最容易忽视的环节。它要解决的问题是在每一轮 LLM 调用时到底把哪些信息放进 prompt 里。上下文窗口是有限的而 Agent 在执行任务过程中产生的信息是不断增长的——对话历史、工具调用记录、中间结果、错误信息等等。如果不加管理地把所有信息都塞进 prompt很快就会超出上下文窗口限制而且大量无关信息还会干扰 LLM 的推理。好的上下文管理策略需要做到保留关键信息、压缩冗余信息、按需检索历史信息。具体怎么做后面在决策点部分会详细展开。2.7 安全与护栏让 Agent 不“失控”安全与护栏是 Agent 从 Demo 走向生产环境必须跨过的一道坎。一个没有护栏的 Agent可能会调用不该调用的工具、输出不该输出的内容、执行危险的操作。护栏通常包括几个层面输入过滤检查用户输入是否包含恶意指令、工具权限控制限制 Agent 能调用哪些工具、调用时的参数范围、输出审查检查 Agent 的输出是否符合规范、行为边界限制 Agent 的操作范围比如只能读不能写。这一块在实际项目中往往被放到最后才做但我的建议是从第一天就把护栏机制设计进去不要等到出问题了再补。3. 七个决策点构建 Agent 时必须做的关键选择3.1 决策点一Agent 的自主程度——从固定流程到完全自主这是构建 Agent 时第一个要做的决策也是最根本的决策你希望 Agent 有多自主这个决策可以用一个光谱来表示自主程度特点适用场景实现难度固定流程步骤预定义LLM 只在特定节点做判断流程稳定的业务场景低半自主LLM 可以在预定义的工具集中选择但流程框架固定客服、问答、数据分析中完全自主LLM 自主决定每一步做什么包括是否创建新工具开放式研究、复杂问题求解高我见过很多团队一上来就追求“完全自主”结果做出来的东西既不稳定也不可控。实际上大多数生产环境中的 Agent 都是“半自主”的——给 LLM 一定的选择空间但用工程手段框定它的行为边界。选择自主程度的核心依据是你的任务有多大的不确定性如果用户的请求类型是有限的、可枚举的那固定流程或半自主就够了。如果用户可能提出任何类型的请求那才需要完全自主的架构。3.2 决策点二工具调用的粒度——粗一点还是细一点工具调用的粒度设计直接影响 Agent 的灵活性和可靠性。粗粒度工具一个工具做很多事情。比如一个“处理订单”的工具内部包含了查询、修改、取消等多个操作。优点是 LLM 只需要选一个工具决策简单缺点是灵活性差LLM 无法精细控制具体做什么。细粒度工具一个工具只做一件事。比如“查询订单”“修改订单”“取消订单”分别是三个工具。优点是灵活LLM 可以精确控制缺点是 LLM 需要做更多的选择出错概率增加。我的经验是工具数量在 5-15 个之间时细粒度更好超过 15 个时需要做适当的分组和粗化。因为 LLM 在大量工具中选择时准确率会明显下降。一个实用的技巧是给工具加“分类标签”让 LLM 先选分类再选具体工具降低单次选择的复杂度。3.3 决策点三记忆的存储与检索策略记忆系统的决策点主要包括存什么、怎么存、怎么取。存什么不是所有信息都值得存。我的原则是存三类信息——用户的明确偏好和约束、任务执行的关键结果、之前失败过的尝试避免重复犯错。怎么存简单的键值对存储适合结构化信息向量数据库适合语义检索图数据库适合存储实体之间的关系。实际项目中往往是组合使用。怎么取这是最关键的。全量加载会撑爆上下文窗口随机采样可能漏掉关键信息。我常用的策略是“最近优先 相关性检索 重要性加权”三者结合最近的对话轮次直接加载历史信息通过向量相似度检索同时给不同类型的信息设置不同的重要性权重。注意记忆检索的时机也很重要。不要每一轮都做检索那样会增加延迟和成本。我通常是在任务开始时检索一次然后在执行过程中每隔几轮检索一次或者在 LLM 明确表示需要历史信息时才触发检索。3.4 决策点四错误处理与容错机制Agent 在执行过程中出错是常态不是异常。工具调用可能超时、LLM 可能输出格式错误、外部 API 可能返回异常数据。错误处理机制的设计直接决定了 Agent 是“能用”还是“好用”。我通常把错误分为三个等级可恢复错误比如工具调用超时、格式解析失败。处理方式是重试但要设置最大重试次数和退避策略。可降级错误比如某个工具暂时不可用。处理方式是切换到备用方案或者跳过这一步继续执行。不可恢复错误比如权限不足、关键依赖缺失。处理方式是终止当前任务向用户报告具体原因。一个容易被忽视的点是错误信息也要反馈给 LLM。很多开发者只把成功的结果传给 LLM出错时直接抛异常终止。更好的做法是把错误信息也作为上下文的一部分传给 LLM让它自己决定是重试、换方案还是放弃。这样 Agent 就有了“自主容错”的能力。3.5 决策点五上下文窗口的分配与压缩上下文窗口是 Agent 最稀缺的资源之一。每一轮 LLM 调用你都需要在有限的窗口里塞进系统提示词、工具定义、对话历史、工具调用记录、当前任务状态、检索到的记忆……我的分配策略通常是这样的系统提示词和工具定义固定占用尽量精简最近 3-5 轮对话完整保留更早的对话压缩成摘要工具调用记录只保留关键结果去掉中间过程检索到的记忆按相关性排序取 top-k压缩策略上我常用两种方法一种是摘要压缩让 LLM 把长对话压缩成简短摘要另一种是结构化压缩把对话历史提取成结构化的状态信息比如“用户已提供姓名、订单号已完成查询订单待完成修改地址”。3.6 决策点六多 Agent 协作还是单 Agent 全能当任务复杂度上升到一定程度时你会面临一个选择是让一个 Agent 做所有事情还是拆成多个 Agent 各司其职单 Agent 的优点是架构简单、状态一致性好、调试方便。缺点是当任务涉及多个领域时prompt 会变得非常臃肿工具集也会变得很大导致 LLM 的选择准确率下降。多 Agent 的优点是每个 Agent 可以专注于自己的领域prompt 和工具集都更精简。缺点是 Agent 之间的通信和协调需要额外设计状态同步也是个问题。我的建议是先用单 Agent 跑通当单 Agent 的 prompt 超过 2000 字或者工具超过 15 个时再考虑拆分。拆分时按照“职责边界清晰、交互频率低”的原则来划分不要为了拆而拆。3.7 决策点七评估与迭代机制最后一个决策点也是最容易被忽略的你怎么知道你的 Agent 表现好不好怎么持续改进Agent 的评估比传统软件测试复杂得多因为它的输出是非确定性的。同一个输入Agent 可能走不同的路径、调用不同的工具、给出不同的答案。我常用的评估方法是场景化测试集 人工评审 自动化指标三结合场景化测试集收集真实用户请求构建覆盖主要场景的测试用例人工评审定期抽样检查 Agent 的输出质量自动化指标工具调用准确率、任务完成率、平均轮次、平均 token 消耗迭代时我建议每次只改一个变量然后跑一遍测试集对比效果。同时改多个变量你根本不知道是哪个改动起了作用。4. 从零搭建一个 Agent 的实操路径4.1 环境准备与技术选型动手之前先把基础环境搭好。我以 Python 技术栈为例因为生态最成熟。核心依赖包括大模型 SDK用于调用 LLM、Web 框架用于提供 API 接口、向量数据库用于记忆存储、以及一些工具库用于 HTTP 请求、文件操作等。pip install openai fastapi uvicorn chromadb requests pydantic技术选型上我的建议是不要一上来就用重型框架。很多 Agent 框架封装了大量抽象层看起来很方便但一旦出问题你很难定位是框架的问题还是你的代码的问题。先用原生 SDK 手写一个最小可用的 Agent 循环理解每一层的运作机制然后再根据需要引入框架。4.2 定义工具与工具注册机制工具的定义我推荐用 Pydantic 模型来做参数校验这样既能保证参数类型的正确性又能自动生成 JSON Schema 给 LLM 看。from pydantic import BaseModel, Field from typing import Callable class ToolParameter(BaseModel): name: str Field(description参数名称) type: str Field(description参数类型) description: str Field(description参数说明) required: bool Field(defaultTrue) class Tool: def __init__(self, name: str, description: str, parameters: list[ToolParameter], func: Callable): self.name name self.description description self.parameters parameters self.func func def to_schema(self) - dict: return { type: function, function: { name: self.name, description: self.description, parameters: { type: object, properties: { p.name: {type: p.type, description: p.description} for p in self.parameters }, required: [p.name for p in self.parameters if p.required] } } }工具注册中心负责管理所有可用工具并提供按名称查找的能力。这里有个细节工具的描述文字要反复打磨它是 LLM 选择工具的唯一依据。4.3 实现核心循环机制核心循环是整个 Agent 的骨架。我用伪代码展示一下关键逻辑def agent_loop(user_input: str, max_turns: int 10): messages [{role: system, content: SYSTEM_PROMPT}] messages.append({role: user, content: user_input}) for turn in range(max_turns): response call_llm(messages, toolstool_schemas) if response.has_tool_call(): tool_name response.tool_call.name tool_args response.tool_call.arguments try: result execute_tool(tool_name, tool_args) messages.append({role: tool, content: str(result)}) except Exception as e: messages.append({role: tool, content: f错误{str(e)}}) else: return response.content return 达到最大轮次限制任务未完成这个循环里有几个关键设计最大轮次限制防止死循环、工具执行异常被捕获并反馈给 LLM、每一轮都把工具结果追加到消息历史中。4.4 接入记忆系统记忆系统的接入分两步写入和读取。写入的时机是任务完成后或关键信息产生时。读取的时机是任务开始时和需要历史信息时。class MemoryStore: def __init__(self, collection_name: str agent_memory): self.client chromadb.Client() self.collection self.client.get_or_create_collection(collection_name) def save(self, content: str, metadata: dict): self.collection.add( documents[content], metadatas[metadata], ids[fmem_{time.time()}] ) def retrieve(self, query: str, top_k: int 3) - list[str]: results self.collection.query(query_texts[query], n_resultstop_k) return results[documents][0] if results[documents] else []实际使用中我会给每条记忆加上类型标签偏好、事实、经验和时间戳检索时根据类型和时间做加权排序。4.5 加入护栏与安全控制护栏的实现可以很简单但必须要有。最基本的护栏包括工具白名单只允许调用注册过的工具参数校验检查工具参数是否在允许范围内输出过滤检查 Agent 输出是否包含敏感信息轮次限制防止无限循环超时控制每个工具调用设置超时时间ALLOWED_TOOLS {search_web, read_file, calculate} MAX_TOOL_CALLS_PER_TURN 3 def execute_tool(name: str, args: dict): if name not in ALLOWED_TOOLS: raise PermissionError(f工具 {name} 不在允许列表中) if len(args) MAX_TOOL_CALLS_PER_TURN: raise ValueError(参数数量超出限制) # ... 执行工具这些护栏看起来简单但在实际项目中能避免大量问题。5. 实际项目中踩过的坑与应对经验5.1 LLM 输出格式不稳定导致的解析失败这是最常见的问题。你要求 LLM 输出 JSON它偏偏在 JSON 前面加一句“好的我来帮你调用工具”或者在 JSON 后面加一句“以上就是我的回答”。解析器直接崩溃。我的应对方案是三层防护第一层在 prompt 里用强烈的指令要求只输出 JSON并给出示例第二层用正则表达式提取 JSON 部分忽略前后的多余文字第三层如果解析仍然失败把解析错误信息反馈给 LLM让它重新输出。实测下来三层防护能把格式解析成功率从 85% 左右提升到 99% 以上。5.2 工具调用陷入死循环Agent 反复调用同一个工具每次都得到相同的结果但就是不停下来。这种情况通常发生在工具返回的结果不明确时——LLM 不确定任务是否完成就反复尝试。解决方案有两个一是设置工具调用的最大次数超过就强制终止二是在工具返回结果中明确标注“任务已完成”或“任务未完成原因如下”帮助 LLM 做判断。5.3 上下文窗口溢出任务执行到一半突然报错说超出了上下文窗口限制。这是因为对话历史和工具调用记录不断累积最终撑爆了窗口。我的处理方式是实时监控 token 数量当接近窗口上限的 80% 时触发压缩流程把最早的几轮对话压缩成摘要只保留关键信息。压缩后的摘要替换原始对话释放出空间。5.4 工具描述歧义导致选错工具有两个功能相似的工具LLM 总是选错。比如“查询用户信息”和“查询订单信息”LLM 经常搞混。解决方法是让工具描述之间的差异更加明显。不要只写“查询用户信息”而是写“根据用户 ID 查询用户的基本信息包括姓名、邮箱、注册时间。不包含订单信息”。把边界说清楚LLM 的选择准确率会大幅提升。6. 关于 Agent 工程实现的一些个人体会做 Agent 开发这段时间我最大的体会是Agent 的工程质量80% 取决于你对边界情况的处理而不是对正常流程的实现。正常流程谁都能跑通但真正决定一个 Agent 能不能上生产的是它在面对异常输入、工具故障、上下文溢出时的表现。另一个体会是不要追求一步到位的完美架构。我见过太多团队花大量时间设计“通用 Agent 框架”结果做出来的东西又复杂又不好用。更好的路径是先针对一个具体场景做一个能用的 Agent然后在迭代中逐步抽象出通用能力。还有一点评估机制要尽早建立。没有评估你就不知道你的改动是让 Agent 变好了还是变差了。哪怕一开始只有十几个测试用例也比没有强。最后Agent 这个领域变化很快新的模型、新的框架、新的模式层出不穷。但底层的工程原则——清晰的工具定义、健壮的错误处理、合理的上下文管理、严格的护栏控制——这些是不会变的。把基本功打扎实上层的技术怎么变都能跟上。