1. 伪闭环与真闭环先判断你做的到底算不算 AI AgentAI Agent 的工程实现卡住的从来不是 LangChain 的代码怎么写而是很多人一开始就把对象搞错了。我见过不少团队把旧系统里的 API 调用用 Agent 框架包装一遍然后对外说“我们用上了大模型智能体”。但产品上线后用户反馈非常一致看着聪明实际不干活。原因很简单——他们做的是“API 调用串烧”不是 Agent 闭环。一个真正的 AI Agent至少要具备三个特征有明确目标、能通过工具改变外部状态、执行过程中根据反馈调整下一步。做不到这三条无论你用多花哨的框架本质上还是脚本做到这三条哪怕代码只有几百行它也具备了 Agent 的内核。工程实现的难度指数级上升也正是从“返回一段文字”变成“让它反复尝试、自己纠错”的那一刻开始的。1.1 真闭环和伪闭环的判定标准我经常用一个小测试来区分两者把你的大模型调用放进一个循环里循环里每一步都让模型看到上一步的执行结果并且允许它决定换一种方式继续执行——如果有这个结构才有资格继续聊 Agent 架构如果没有那只是“生成式工作流”。伪闭环的典型长这样用户输入需求 - 一次大模型调用生成步骤 - 按步骤逐条调其他 API - 拼结果返回。整条链路里模型没有任何机会修正自己步骤执行失败时也不存在“重新规划”的能力模型其实是“编剧”不是“执行者”。真闭环则是让模型同时担任“决策者”和“调度者”。比如让 Agent 自主完成“选品、比价、下单”这类任务时它的每一步动作都会被记录下一步指令要基于上一步返回的商品列表、标价、库存等真实状态来生成。这听起来只是加了个 for 循环但随之而来的记忆管理、工具设计、终止条件、成本控制全是新的工程问题。1.2 从伪闭环到真闭环架构复杂度发生了什么变化伪闭环里流程是线性的出错是边缘情况真闭环里流程是发散的你无法枚举所有可能路径出错才是常态。这个区别直接决定了技术选型线性流程只需要 curl 和大模型结果解析真闭环需要考虑上下文窗口怎么裁剪、工具调用的 JSON 格式怎么稳定、模型陷入死循环时怎么截断、多步累积的错误信息会不会污染后续判断。所以后面要讲的七个要素和七个决策点本质上都在回答一个问题当模型开始自主行动时系统靠什么约束它、引导它、兜住它的错误。这篇就是在分享我实际落地这类系统时反复验证过的做法适合正在规划或维护 Agent 项目的开发者参考。2. 拆解 AI Agent 的七个核心要素它们是构成“执行能力”的组件我一直认为理解 Agent 最好的方式不是看框架文档而是回到要素层面。一个能稳定工作的 Agent至少要集齐下面七样东西。少了其中任何一样短期内可能看不出问题一旦任务变复杂短板一定会暴露。2.1 要素一目标设定目标不是一句 system prompt 里的“你要做一个助手”。工程意义上的目标要被拆成两层任务目标和终止条件。任务目标描述“要达成什么”终止条件描述“什么情况下算达成什么情况下算放弃”。没有终止条件的 Agent 就像没有刹车的车跑起来很猛停不下来。我在项目里几乎都会把目标写成结构化任务单包含任务描述、可调用的边界、验收标准而不是让模型从一段自然语言里自己领会。2.2 要素二大模型的推理内核大模型是 Agent 的“大脑”但选择模型时要区分两个能力推理能力和工具调用能力。推理能力决定它能不能把复杂问题拆出合理步骤工具调用能力决定它能不能稳定输出和输入。实际工程里很多问题不是模型不够聪明而是工具调用格式不稳定——比如同一个模型有时候返回 JSON有时候夹带解释。这也是为什么不少人最终会采用“小模型做分类/抽取大模型做规划”的混合架构而不是把全部需求压在一个旗舰模型上。2.3 要素三提示词与上下文构造提示词在 Agent 里的角色容易被低估。它不只是“告诉模型干什么”而是“告诉模型它手里有什么资源、当前处于哪一步、哪些信息可信”。这就要动态构造上下文把历史操作、工具返回结果、系统约束每一轮都拼进 prompt。很多初学者把上下文只理解为“聊天记录”但 Agent 的上下文应该更像“任务状态快照”每次循环前都刷新一次。2.4 要素四记忆管理记忆分三层会话记忆、任务记忆、长期记忆。会话记忆是最近几轮对话任务记忆是当前目标的中间状态长期记忆是跨任务沉淀的数据比如用户偏好、历史结论。工程实现时最怕的是把三者混在一个上下文里结果 token 爆掉模型开始抓不住重点。后面第五章会细说我在记忆策略上的取舍。2.5 要素五工具接口工具是 Agent 改变环境的“手”。工具设计的好坏直接决定 Agent 能不能在真实场景落地。每个工具需要被描述清楚三个点能做什么、输入参数是什么、返回什么。描述里最容易被忽略的是“什么时候不该用这个工具”。我在工具配置里都会补充负面约束例如“库存查询仅在订单场景使用”效果立竿见影模型误调用率会明显下降。2.6 要素六规划与反馈循环循环是 Agent 的骨架。模型在循环里经历“观察状态 - 决定动作 - 执行工具 - 获得结果”的反复。这个过程看起来简单但“谁来规划”的方案差别很大是每一步都由模型自由决策还是让模型先产出一份计划再逐步执行还是用固定模板引导步骤。不同方案适应不同任务。正文第四章会给出可参考的循环主链路。2.7 要素七安全护栏与终止机制最后一个要素最容易被忽略也最致命。只要 Agent 能调外部接口就必须考虑它能做什么、不能做什么、出错时怎么收场。这里的“安全”不是只谈权限还包括“烂尾保护”当步骤反复失败时Agent 要知道停止并返回已有结果。我在生产环境里给 Agent 规定了硬性上限——最大执行步数、最大工具调用次数、最长耗时同时让大模型输出每条操作的理由和依赖意图方便事后审计。七个要素之间的关系可以这样理解大模型提供决策能力工具提供行动能力记忆提供连续状态目标与护栏提供方向和控制上下文构造则是把这些东西在每轮循环里正确拼接起来。3. 工程化之前先想清楚的七个决策点每错一个都会用 Token 和稳定性买单要素是“必须有什么”决策点是“在特定场景怎么选”。这七个决策点我几乎在每个 Agent 项目里都会和团队来回拉扯因为它们没有标准答案只有权衡。3.1 决策点一编排方式用预设流程还是完全自主循环这是第一个要拍板的架构决策。预设流程也叫 workflow适合流程固定、步骤明确的场景比如“先查库存、再比价、最后生成订单”完全自主循环则让模型每一步自己决定调用什么适合开放领域。我的经验是能上预设流程就先上预设流程因为它的行为可预测容易测试只有当流程发散到无法枚举时才引入自主循环。不要把“自主”当成 Agent 的必须条件它是最后选项。很多人一上来就做完全自主理由是“这样才智能”结果是模型每轮都从一个不确定状态开始开发和排查成本飙高。3.2 决策点二规划策略选哪种直接决定了迟滞感和成功率主流方案大致三类ReAct、Plan-and-Execute、混合式。ReAct 是边想边做每一步都基于上一步结果Plan-and-Execute 是先把完整计划列出来再逐步执行混合式是先让模型生成粗计划执行中允许局部调整。我的取舍标准是看任务容错度需要中途获取信息才能继续的任务用 ReAct可以离线规划的任务用 Plan-and-Execute 更节省 token而涉及多步骤依赖、但环境可能变化的任务用混合式。特别提醒Plan-and-Execute 看起来省 token但如果计划建立在过期信息上后面每一步的纠错成本反而更高。3.3 决策点三记忆策略怎么分层是共鸣还是淘汰不少团队一谈到记忆就想着上向量数据库我认为这是过度设计。一个任务只要在几十轮以内滑动窗口加摘要完全可以覆盖。我通常这样分底层用最近 6~8 轮完整记录更早的内容由模型定期生成摘要压缩进去长期知识才交向量库。这背后的原因是大模型对上下文的注意力高度集中在前后两端中间大段历史很容易被“忽视”与其花 token 把所有历史塞进去不如提炼结论。你会惊讶地发现摘要后的上下文经常更准确因为模型不再被细节干扰。3.4 决策点四工具数量和描述方式之间如何平衡我见过不少 Agent 项目挂了三四十个工具结果模型在大多数场景只会用最顺手的几个多余工具反而增加了 token 开销和误调用概率。工具数量在 5~8 个时命中率往往最高。描述方式上也别写小作文工具描述越短、参数越明确模型就越容易做出正确选择。关键指标是“调用的平均轮次”和“误调用率”。如果工具返回的结果被反复塞进上下文中说明工具的输出格式也需要压缩比如只留关键字段而不是让大 JSON 原文进入 prompt。3.5 决策点五循环什么时候终止需要比预期更保守终止机制要同时做硬限制和软判断。硬限制在系统层面实现max_steps、max_tool_calls、max_duration。软判断在模型层面实现让它判断目标是“已完成、已失败、还是需要外部输入”。我曾经让 Agent 自己决定何时结束结果遇到一个 bug模型在成功生成答案后又反复去调用工具验证答案导致费用翻了三倍。后来我把“成功定义”写进系统约束同时加入finish动作模型一旦判定达标必须返回finish而不是继续试探。3.6 决策点六错误处理策略重试边界在哪里工具调用失败是常态重试策略因此很重要。但我提醒一点不要无脑重试必须分流错误类型。网络超时可以重试参数错误重试也没用业务规则拒绝比如库存不足应该把错误信息交给模型让它调整方案。需要把工具的异常设计成结构化返回例如{code, message, context}而不是一个纯文本报错这样模型才能准确判断下一步。3.7 决策点七可观测性和数据回放决定你能不能维护这个系统Agent 的不可预测性要求每一步都留痕。我要求任何 Agent 项目落地时必须具备“事件流”能力每一步的输入 prompt、模型原始输出、解析后的 action、工具返回值、耗时和 token 消耗全部落库。这不仅是排障也是构建评测集的基础数据。没有完整 trace 的 Agent调试起来基本靠猜等于失去维护能力。我把七个决策点的取舍汇总成下面这张表方便对照自己的场景决策点关键问题低复杂度方案更进阶的方案编排方式流程固定还是开放预设流程自主循环规划策略先想后做还是边做边想ReActPlan-and-Execute / 混合式记忆策略历史要保留多少、怎么提炼滑动窗口摘要向量库摘要实体记忆工具设计数量、描述、输出格式5~8 个工具紧凑描述动态工具注入结果压缩终止条件什么时候算成功/失败max_steps模型 finish 判断成功率阈值人工兜底错误处理重试还是调整方案按错误码分流重试上下文感知的自修复可观测性每一步能否回放全量 trace 落库自动化评测回归集4. 最小闭环的落地样式核心循环、工具契约与记忆接入方案决策点定完后剩下的事情就是把它们接起来。这一章给一个可参考的最小实现风格不是完整工业方案但足够让你把上面的设计落到代码里。4.1 一个 Agent 主循环可以长什么样下面是最核心的结构所有高级能力都是在这个循环上叠加的async def run_agent(task: str, tools: list[dict], max_steps: int 6) - dict: state { task: task, history: [], # 每一步的 action / observation summary: , # 早期历史压缩摘要 done: False, } for step in range(max_steps): messages build_messages(state, tools) response await llm.chat(messages) action parse_action(response) # 解析模型的工具调用意图 if action[type] finish: state[done] True return {ok: True, answer: action.get(answer), steps: state[history]} if action[type] tool_call: result await call_tool(action[tool], action[args]) state[history].append({ step: step, tool: action[tool], args: action[args], observation: compress(result), # 关键结果压缩 }) # 如果历史过长触发摘要压缩 if len(state[history]) 8: state[summary] await summarize_history(state[history][:-6]) state[history] state[history][-6:] return {ok: False, reason: max_steps_exceeded, steps: state[history]}这个循环最重要的两个设计点是第一finish必须和工具调用一样是显式动作模型只有返回finish才结束第二compress(result)和summarize_history一定要做否则跑不了几步上下文就会失控。4.2 工具调用契约模型要能稳定读懂你的接口工具调用在大模型里通常走 function calling但我们要把契约写得足够严格。一个工具的 schema 至少包含四部分名称、描述、参数、返回值格式。我在实践里会额外加一个when_not_to_use字段明确告诉模型什么时候不要用。示例{ name: search_products, description: 按关键词搜索商品返回标题、价格、库存。适合用户表达购买意图时使用。, when_not_to_use: 用户只是想聊天时不要调用用户还没有明确购买意图时不要调用。, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词 }, limit: { type: integer, default: 10 } }, required: [query] }, returns: { type: array, items: { title: string, price: number, stock: integer } } }工具描述要短而准但不能短到丢失边界。模型不是人它不会根据“生活常识”判断该不该调用工具它只认描述里的字面语义。4.3 记忆接入按照成本从低到高的顺序选择方案很多入门者一上来就堆向量库但我建议先做最简单的滑动窗口。滑动窗口加摘要的方案约能覆盖 70% 以上的业务场景尤其是任务导向型 Agent。它的实现就是上一节代码里的summary字段每轮把历史压成摘要再拼接最近几轮原文。只有当你要跨任务记忆用户偏好、或者构建问答型 Agent 时才引入向量库并且记得给每个向量带上业务标签和过期时间。过期的记忆还不如没有记忆否则旧信息会反复误导模型。5. 生产环境最容易翻车的三个盲区从项目复盘里反复踩过的教训写到这里已经把正面的搭建方式讲完了。但真正让项目上线后出问题的往往不是代码没写出来而是下面这三类盲区。5.1 工具返回膨胀引发的“整个上下文中毒”我见过一个客服 Agent工具会返回完整商品详情包含图片 URL、长描述、评论语料。结果一次调用后上下文里塞了八千多个 token后续几轮模型开始重复引用商品详情里的片段判断力直线下降。工具返回的信息只保留当前决策真正需要的字段就能大幅改善。你可以把压缩这一步放在工具侧而不是模型侧因为模型压缩会额外消耗 token。5.2 模型把工具结果当成“唯一真相”后的幻觉加剧大模型本身有较强的“服从惯性”工具返回什么它就容易无条件相信。但工具返回的可能是过期数据、接口错误占位符、甚至空结果。工程上必须在系统提示里写明工具的信任等级哪些字段是实时可靠的哪些只是参考。例如库存量是实时字段商品评分则是统计字段。模型需要根据信任等级调整说法而不是把任何数字都当成断言。5.3 没有一个“回归集”Agent 的行为只会越改越漂因为 Agent 每次执行都存在随机性所以它的测试方式和传统后端完全不同。你不能只测“正常路径”还要构建回归集把历史请求、当时的 trace、期望动作存下来每次改动提示词或工具后重新跑一遍这批样例。如果本来该调用搜索工具的请求现在被模型改成了闲聊这就是回归失败。没有回归集的 Agent 项目最终都会在某个版本迭代后出现“莫名其妙变笨”的现象原因通常不是模型变笨而是你改动的某个描述向模型传播了错误偏好。6. 我的收敛建议先做窄、做可控再做通用如果你问我有什么最想强调的经验那就是一开始别做太通用的 Agent。通用性意味着未知路径多未知路径多意味着终止条件、记忆策略、工具设计都难以收敛。我建议从“窄场景”出发把一个 Agent 控制在三到七个工具、一步到三步规划、单一目标域的范围内。先把闭环跑稳再逐步增加工具和放开规划空间。另外可观测性一定要从第一天就做。给每一步动作记录以下几样东西模型输入的 prompt 版本、动作参数、工具真实返回、最终是否达成目标。这些记录不只是运维排障用更是你未来做评测和回归集的原料。我个人反复使用的最后一个小技巧是给 Agent 加一个“意图确认”节点。在它执行高影响动作之前先输出一句话说明“我准备调用哪个工具、因为什么判断”再真正执行。这个步骤让系统有天然的审计底稿也让模型在生成意图时多一层自我检查误调用率通常能降低三到五成。搭建 Agent 的难度不体现在“让模型开口说话”上而体现在“让它有限度地行动、可预期地停下来、说清楚自己做了什么的每一个细节”上。