★ FEATURED ARTICLE 做了几年大模型应用我越来越确认一件事大多数人用LLM做Agent问题不是模型不够聪明而是架构太单薄。很多人拿到一个调用接口写几行系统提示词把工具函数一股脑塞进去就以为“Agent”成型了。结果一跑真实场景就露馅漏参数、绕圈子、记不住上下文、多轮调用之后完全跑偏。我常说一句话模型决定的是Agent的下限真正决定上限的是外挂的那套增强架构。这篇东西就是围绕“LLM Agent增强架构”这个主题把我自己在落地过程中实打实的拆解、设计思路、工程实现和踩坑记录整理出来。内容适合两类人一类是准备把LLM接进业务流的开发者另一类是已经在做Agent却觉得效果不稳定的研究者。我会尽量讲得直白一点把“为什么这么设计”放在“怎么做”前面读完你可以直接抄作业也清楚自己到底在干什么。1. LLM Agent为什么不“智能”先从架构层面拆掉障眼法很多团队一开始都把一个核心问题搞错了大家以为LLM Agent就是“给模型一个会调函数的权利”。实际上你去看任何一套能稳定跑完多轮任务的Agent它外围一定有一套复杂的工程系统在托底。这个系统不是模型的附属品而是整个Agent的主体。模型只是其中一个会“思考”的组件它负责生成决策文本剩下的记忆管理、工具路由、状态校验、异常恢复全是工程架构的事。我最早踩坑是在做一个模拟项目X一个需要查订单、改地址、算运费、生成售后工单的客服Agent。当时我用裸的大模型加几个函数描述跑起来相当“惊艳”能听懂人话能调工具。但测了二十个真实用户问法之后我心态崩了。有用户说“帮我看看上个月那单怎么还没到”模型把它拆成了“查订单”和“查物流”两次调用逻辑上没问题但因为我没有设计任务状态管理第二次工具调用时已经忘了第一轮查到的订单号。这个例子特别能说明问题模型在单轮推理上是强的但跨调用状态保持是架构该管的事不是提示词能管的事。所以后来我给自己定了一个原则增强架构本质上是在LLM外面加四层东西——工具接入层、记忆管理层、规划执行层、安全校验层。有了这四层模型就能从“会说话”变成“能办事”。而且这四层每一层都不是简单的接口封装它背后对应着一整套数据结构和流程约束。这也是我在工作里反复跟团队强调的评估一个Agent框架好不好不能看它接了多少模型要看它在这四层上做得有多深。1.1 单次调用与完整行动之间的鸿沟先把这个最基础的鸿沟讲透。单次调用就是你给模型一段输入它给你一段输出完事。而一个完整行动可能是“获取用户意图、查询数据库、调用第三方接口、根据结果生成回复、必要时再发起一轮追问”这里面包含多次LLM调用并且每一次调用都依赖前一次的状态。这条鸿沟不是靠模型参数量能填平的因为它本质上是状态管理问题。举个例子用户说“我要退掉昨天买的那双鞋然后帮我换双大一号的”。一个能干的Agent需要先查订单、确认商品是否在退货期内、再查库存有没有大一号、然后生成退货单和换货单。如果系统里没有一个地方记录“当前这个会话的目标是什么、已经完成了哪些子步骤、还缺哪些信息”那模型哪怕再聪明也无法把任务完整执行完。因为它每次生成输出的时候拿到的上下文里可能压根没有“昨天那双鞋的订单号”这种关键信息。我见过很多团队的解决方案就是在系统提示词里写“请记住用户说的是哪双鞋”这完全没有用。模型不是数据库它的上下文窗口再大也经不起多轮工具结果互相覆盖。真正可靠的架构必须把中间状态放到外部存储里并且在每一轮决策前把需要的状态显式注入到提示词里。我后面会详细讲这个注入是怎么做的。1.2 增强架构的核心让模型从“会说话”变成“能办事”我再打一个比方希望大家能一下抓住“增强架构”这四个字的含义。把LLM想象成一个高智商但极度健忘的实习生。你给他一个任务他能说得头头是道但他没有办公桌没有记事本没有任何工具的操作手册。你每次找他他都得凭记忆和你上一次聊天内容来猜。你指望他独立办成一件事那他必须有一个配套的工作台桌面上有便利贴记忆、手边有操作手册工具说明、面前有流程清单任务规划、头顶还有监工校验器。这个“工作台”就是增强架构。我把这个思路落实成一张可复用的清单每次设计Agent先对着过一遍明确哪些信息需要跨调用保留设计对应的状态存储结构。明确Agent能调用哪些工具每个工具的参数边界是什么是否做了Schema校验。明确任务在什么条件下算完成什么条件下算失败失败后有没有恢复路径。明确在哪个环节用LLM做自主推理在哪个环节用代码做强制控制。这套清单听起来不复杂但很多实现得非常粗糙的Agent一上来就栽在第三点上任务做一半模型编了一个不存在的接口参数然后整个对话就卡死了。增强架构的意义就是用工程手段把这类“模型随机性”兜住让整个系统在统计意义上更稳。记住一个关键认知增强架构不是为了发挥模型的上限而是为了兜住模型的下限。2. 增强架构的分层设计接入、记忆、规划、护栏一个都不能少架构到底怎么拆我习惯的拆分方式就是四个层次接入、记忆、规划、护栏。这个拆法不是拍脑袋而是从LLM Agent运行的自然链路反推出来的。系统先接收用户请求然后要做意图拆解这个过程需要工具信息和历史记忆拆解完之后进入执行阶段可能是一轮或多轮工具调用每一轮调用的结果再回填到上下文循环往复直到任务收口。你把这个链路走一遍就会发现每一个环节的痛点分别对应接入、记忆、规划、护栏这四层的职责。下面我分层展开讲每一层我都会说清楚三个东西这一层解决什么、常见设计有哪些、实际落地时最容易被忽略的细节点是什么。2.1 工具接入层函数调用不是“调接口”那么简单工具接入层最核心的任务是让LLM能准确地把自然语言请求转换成结构化的函数调用。但如果只是把函数定义扔给模型你会遇到一个很现实的问题模型有时会漏参数有时会编造枚举值有时干脆连续调用三次同一个查询函数。所以工具接入层实际上应该包含三块函数Schema定义、调用参数校验器、调用的幂等与重试策略。Schema定义这一块我的经验是必须用严格类型并且对参数描述写清楚边界。举个例子一个查询订单的函数如果参数是“订单号”你光写“订单号”三个字是不够的。你要写清楚格式是什么、几位数、从哪里获取、参数不存在时应该怎么做。别看这些细节琐碎它们直接决定模型第一次调用的准确率。我自己实测过一个对比把参数描述从一句话扩展成带格式说明和示例的三句话函数调用成功率高了一截这个改动成本极低收益却非常稳。参数校验器是很多人偷懒跳过的一环。我的建议是所有工具接收参数之前必须过一遍程序化校验用类型检查加正则必要的时候写自定义校验规则。校验过了再执行不过就把错误信息返回给模型让它重新生成调用。这一下就把“模型编参数”这个经典问题的危害降到了最低。至于幂等和重试很多人会觉得这是后话但其实是你日志里最多的一种异常类型。Agent在跑批处理任务时经常出现网络抖动一次查询超时模型就会反复调用同一函数。如果你不做幂等设计轻则数据重复重则触发下游系统的脏数据。我当时做那个客服Agent时就因为查询函数没有幂等测试环境里生成了几百条重复工单排查了大半天。从那以后所有写操作一律带上请求ID重试前先查状态这个习惯我建议所有人都刻进肌肉记忆。2.2 记忆系统窗口、向量库、结构化记忆怎么搭配记忆增强是我认为“增强架构”里信息密度最高的一层。很多Agent表现不好就是因为模型每次推理时只有当前这一轮对话或者虽然有历史记录但被截断得不科学。记忆系统设计的核心是搞清楚哪些信息值得长期保留、哪些信息只需要短期保留、哪些信息应该用自然语言记录、哪些信息必须用结构化字段保存。全塞进上下文窗口是最偷懒也最昂贵的方式。我自己的习惯是分三层来做。第一层是短期对话记忆也就是最近几轮的用户输入和系统输出。这一层可以用滑动窗口实现窗口大小根据模型的上下文预算动态调整。第二层是长期事实记忆用向量库存历史交互中抽取的要点比如“用户偏好顺丰”“用户上次投诉过配送慢”“该订单已申请退换货”。每次新会话开始时做一次相关召回把命中的要点拼进提示词。第三层是结构化业务记忆专门存订单状态、流程节点这类数据这一层在LLM调用周期里同步查询作为工具参数或校验依据使用。这三个层次的取舍我建议用一个简单标准来判断这些信息如果没有了后续决策会不会出错。会出错就是必须记忆不会出错就不必记忆。很多人把记忆设计得无比复杂什么都往向量库里塞结果召回一堆噪声反而干扰了模型判断。我见过最离谱的一个案例是把用户的生日和星座也塞进提示词模型就顺着星座发表了一通性格分析完全忘记了用户本来是要售后维权。记忆不是越多越好是越精炼越好。向量检索这块我再额外提醒一点不要只看相似度分数。你一定要做metadata过滤比如限定业务类型、限定时间范围。否则你召回的内容可能文不对题。以前有个同事跟我炫耀他的向量检索准确率我问他在哪个业务场景测的他说通用问答。这没有参考价值。真实的Agent使用场景检索结果往往需要在特定业务上下文里才有效没有过滤条件的向量召回在工业级场景里几乎不可用。2.3 规划与执行把ReAct循环改造成可控的工作流ReAct循环大家都听过让模型思考Thought再行动Action观察结果Observation再继续思考。这个范式很漂亮但直接裸用会出问题。最大的问题在于模型会在循环里“空转”或者“绕圈”。它可能提出一个行动计划然后调了两次工具发现结果不对又提出一个完全不同的计划把之前的工作推倒重来。整个过程消耗了大量token而用户看到的就是这个Agent在不停转圈。我的做法是把ReAct循环改造成“规划-执行-校验”的三段式工作流。模型不在每一步都重新做全局规划而是先对整段任务做一次拆解生成一个有序的子任务列表每个子任务对应一个工具调用或一轮信息收集动作。执行过程中系统按这个列表推进每完成一个子任务就做一次校验校验通过才进入下一个校验失败则触发局部重规划而不是全盘重来。这个改动看起来只是流程控制上的调整实际上对稳定性的提升非常明显。因为模型在局部重规划时只需要面对“当前子任务出了什么问题”这个小范围上下文不需要重新理解整段任务。就好比写代码报错你只需要看报错的那一行而不是把整个项目重读一遍。这种局部化处理能大幅降低模型出错的概率。我在实际项目里还会加一个动作预算机制限制每轮任务的工具调用次数上限比如最多8次。如果超出预算还没完成任务系统直接终止并且上报“需要人工介入”。这个机制听起来很笨但它保证了一个最基础的用户体验Agent不会无休止地耗下去。宁可让任务失败也不能让用户看着它原地转圈五分钟。有时候失败得干脆一点反而是一种好的设计。3. 从零搭建一个带增强架构的Agent完整实操记录这一节我拿一个能落地的场景走一遍完整流程让大家看得见摸得着。场景定为“订单查询与售后工单Agent”这也是很多电商、零售团队都会遇到的需求。用户可能问订单到哪了、想退款、想换货、想催发货或者问运费怎么算。这个场景要调的工具有订单查询、物流查询、退换货政策查询、工单创建看起来不多但足够演示增强架构的核心要点。3.1 场景设计先约束边界再谈智能开始写代码之前第一步永远不是写代码而是把Agent的行为边界画清楚。我拿到的原始需求是“做一个能自动处理售后问题的机器人”。这话太空了落到架构上根本没法设计。我把它拆成了四个明确的能力单元查订单、查物流、解释政策、创建工单。同时我也明确它不做什么不做支付操作、不做外部投诉升级、不承诺赔偿金额。这些“不做”的约束写清楚后面模型才不会越权。边界定了之后我习惯用一个表格把每个能力的触发条件和关键参数列出来当作开发阶段的“架构契约”。比如订单查询的触发条件是“用户提到订单相关疑问”关键参数是用户ID、订单号、查询时间范围物流查询的触发条件是“用户询问配送进度”关键参数是订单号或运单号。这份契约不仅是给开发看的也是后面写系统提示词和校验器的依据。这一步很多人不愿意花时间觉得“差不多可以了直接做”。但我要说边界设计花一天后面调试能省一周。因为Agent一旦开始自由发挥你根本不知道它为什么会调一个无关工具。有了边界契约你就可以在日志里对每一个行为做审计快速定位是哪一层设计出了问题。3.2 工具层Schema设计与执行器编写工具层我直接用OpenAI兼容的function calling格式做一个示意但思路不绑定于任何一家厂商。关键在于Schema要写得很仔细我当时实现的一个订单查询函数长这样{ type: function, function: { name: query_order, description: 根据订单号查询订单基本信息包括商品、金额、状态、收货地址等。仅在用户明确提到订单号或能推断出具体订单时调用。, parameters: { type: object, properties: { order_id: { type: string, description: 订单号通常为字母T开头的10位数字例如T202408001。如果用户没有提供订单号不要猜测返回需要用户提供订单号的提示。 }, include_items: { type: boolean, description: 是否返回订单内的商品明细默认false。用户提到商品相关疑问时设为true。, default: false } }, required: [order_id] } } }这里有几个细节我要特别强调。第一description尽量写清楚“什么时候不调用”这比写“什么时候调用”更能约束模型。第二如果参数依赖前文信息要在description里提示模型从对话历史中提取而不是凭空编造。第三required字段一定要准确可选的参数必须有default否则模型容易在不需要时也塞一个值进来。执行器的代码相对直白但要注意把错误信息和执行结果区分开。我的实现框架大致是def execute_tool(name: str, arguments: dict, context: dict): # 1. 参数校验 schema TOOL_SCHEMAS.get(name) errors validate_arguments(arguments, schema) if errors: return {status: error, message: f参数校验失败: {errors}, suggest: 请修正参数后重新调用} # 2. 权限检查 if not check_permission(name, context.get(user_id)): return {status: error, message: 该账户无权执行此操作} # 3. 执行工具 try: result call_actual_api(name, arguments, context) return {status: success, result: result} except Exception as e: return {status: error, message: f工具执行异常: {e}}看到执行结果里那个suggest字段没有这是我一个比较得意的设计。当工具返回错误的时候除了错误信息我还返回一条给模型的“建议动作”比如“请检查order_id是否为T开头”。这个值不是给用户的是给模型看的可以帮助它快速修正下一步生成。这样做之后错误恢复的成功率明显提升因为模型不需要自己猜下一步该怎么办。3.3 记忆分层的工程实现记忆这块我给出一个可以直接套用的工程结构。短期对话记忆用一个有最大长度的消息队列长期事实记忆用向量库结构化业务记忆用一个状态对象。三个组件在每一轮Agent运行前合并成一份“记忆上下文包”。对话记忆的实现比较简单就是一个列表超过长度就淘汰最旧的消息。但我做了一点改进淘汰之前先把旧消息做一次摘要把摘要作为一条系统消息保留。这样相当于给了模型一个“压缩过的过去”。这个摘要的生成也有讲究不是整段压缩而是只提取那些影响后续决策的事实比如用户已经提供了哪些关键信息、已经完成过哪些操作、结果如何。向量记忆的写入是在每一轮工具调用成功之后进行的。我写了一个简单的记录函数def memorize_fact(user_id: str, fact: str, fact_type: str, ttl_hours: int 72): embedding embed_text(fact) vector_store.upsert( idf{user_id}:{fact_type}:{time.time()}, vectorembedding, metadata{ user_id: user_id, fact_type: fact_type, expire_at: time.time() ttl_hours * 3600 }, textfact )每个记忆都带过期时间这算是我吃过亏之后的强制要求。之前不带过期时间向量库里积攒了大量已经失效的订单状态记忆比如一次退货流程已经走完记忆里还留着“用户申请退货”的信息。后来模型老是给出过期结论排查了很久才发现是记忆没有设置生命周期。现在所有写入都要求显式声明过期策略宁可多删不可错留。结构化业务记忆我用了一个状态对象它保存当前任务的关键变量class AgentState: def __init__(self, user_id: str, session_id: str): self.current_order_id None self.current_step None self.collected_facts {} self.pending_actions [] self.tool_call_count 0 self.max_tool_calls 8这个状态对象是整个增强架构里最核心的数据结构。每一轮LLM调用之前系统会把当前状态序列化成一段文本放进提示词里每次工具调用之后系统根据结果更新状态对象。这样就实现了“外部状态”和“模型上下文”的同步模型永远不需要靠猜去回忆之前的工具结果。3.4 执行循环与参数预算执行循环是整个Agent的主干。我写一个极简的循环框架def run_agent(user_input: str, user_id: str, session_id: str): state get_or_create_state(user_id, session_id) memory_pack build_memory_pack(user_id, session_id, state) messages build_prompt(user_input, memory_pack, TOOL_SCHEMAS) while state.tool_call_count state.max_tool_calls: response llm_chat(messages, toolsTOOL_SCHEMAS) tool_calls response.get(tool_calls) if not tool_calls: # 模型认为可以回复用户了 final_reply response.get(content) save_session_history(session_id, user_input, final_reply) return final_reply for call in tool_calls: state.tool_call_count 1 result execute_tool(call[name], json.loads(call[arguments]), state) update_state(state, call[name], result) messages.append(role_tool_message(call[id], json.dumps(result))) if state.pending_actions: messages.append(build_plan_hint(state.pending_actions)) return 抱歉我尝试了多次操作仍未完成任务已为你转接人工客服。这里有一个动作预算的概念max_tool_calls设成8。这个数字怎么定的我按平均每个任务需要3到4次工具调用估算过再留一倍冗余8次是合理的。如果8次还没完成说明流程可能出问题了硬跑下去只会消耗更多token还可能越跑越偏。我还加了一个plan_hint的机制当状态对象里有pending_actions时系统会在最新一轮LLM调用前附加上“当前待办事项”的提示让模型不要偏离计划。参数预算这块我强烈建议算清楚每一轮调用中各类内容的占比。我常用一个分配方案假设模型上下文8K token系统提示词与固定背景1200工具Schema大约4个工具1600短期对话记忆最近6轮2000长期事实记忆召回的要点最多5条600状态序列化文本400预留输出空间2200加起来刚好8000左右。这个预算不是死的但你要时刻有这个意识如果工具增加到8个那Schema占用可能到3000你得压缩对话记忆窗口或者提升模型上下文规格。我见过很多Agent效果不好原因根本不是模型能力不行而是上下文被塞爆关键信息被挤出了窗口。上下文管理永远是增强架构里最现实的一个课题。4. 常见问题与排查技巧实录做Agent跟写普通程序最大的不同就是它的错误模式不固定。同一个问题换个说法就触发不同的路径。这导致排查起来特别考验方法。这一节我把这几年遇到的高频问题整理成一个速查表每个问题都按“现象、原因、解决思路”三个维度来写。这些内容都是我实际调试中反复遇到过的比任何理论都有参考价值。4.1 模型老是漏参数或编参数怎么办先讲最经典的一个问题模型在调用工具时漏参数或者干脆编一个不存在的参数值。比如查询订单模型可能不传order_id直接调函数然后返回“抱歉我查不到”。这其实不怪模型在你的工具定义和校验逻辑里就给模型留了太多自由发挥的空间。排查方向有三个。第一检查Schema里required字段是否精确描述里是否明确说了“用户没有提供时不要猜测”。第二检查执行器在参数缺失时返回的报错信息是否给模型提供了修正路径我在执行器设计部分提到的suggest字段就是为了解决这个问题。第三检查对话历史里是否真的有这个参数如果用户从没说过订单号模型当然无法生成这种情况下本来就不该进入查询逻辑而应该主动追问。如果试了这些还有问题那就需要在LLM调用的参数里加入强制JSON Schema支持很多平台已经支持让模型输出严格符合Schema的内容。再不济可以在工具调用前加一个小模型预处理专门做参数抽取和校验。这个方案多一层调用但准确率提升非常明显。我在一个高并发场景里应用过参数漏传率降了一个量级。4.2 多轮工具调用后节奏跑偏第二个高频问题任务刚开头的几步执行蛮好做到第三轮第四轮模型就开始做一些和任务无关的调用或者反复调用同一函数。我印象最深的一次是模型在查完订单状态后连续调了三次物流查询每次查到的结果都一样白白浪费了token最后因为动作预算超限被终止。接着说排查思路。先查状态对象里的current_step有没有正确更新。很多时候是工具结果回来了但state没有同步更新导致模型在下轮决策时看到的还是“待查询”状态于是又查了一遍。这个问题的根因在update_state逻辑里。第二查一下每轮tool result的反馈信息是不是太长太杂。如果工具返回的是一个巨大的JSON模型可能抓不住重点就会重复调用同一个工具来“确认”。我的解决办法是在执行器返回前做一次字段精简把工具结果的原始输出压缩成几条精炼信息只留模型决策必需的关键字段。还有一个偏门的原因模型对plan_hint不够敏感。如果系统里设置了待办事项提示但提示文本太软比如“你可以考虑下一步该做什么”模型就会忽略。我会把提示写得更硬“请严格按下述待办顺序执行当前待办为确认换货库存。请调用check_stock并返回结果确认后进入下一步。”明确指令加上工具名模型执行符合度会高很多。4.3 上下文占用过高和记忆窜扰上下文开销大是每个Agent项目走到后期都会遇到的问题。症状很典型跑了几轮之后模型的回复变迟钝或者开始遗忘最初的指令。原因就一个上下文塞了太多冗余信息窗口不够用了。我的建议是给每类信息设置硬性预算。上一节给的8K参数分配方案就是一个模板。此外要在每次工具调用结束后把历史中的工具结果做压缩只保留“动作名核心结论”而不是完整返回体。原始返回体可以存到外部日志里备查但不需要继续留在上下文中。这一步需要日常就做不要等上下文爆了再想对策。记忆窜扰指的是召回的长时记忆里混入了不相关的内容干扰了当前决策。处理办法在metadata过滤这个前面说过。还有一个附加手段就是给每条记忆打上“临时性”标签。我通常把用户提供的临时信息比如“用户当前在南京出差”标成24小时有效把用户长期偏好标成90天有效。检索时只召回当前任务相关类型且未过期的记忆窜扰概率能压到很低。日常我把记忆相关的异常问题做成了一张自检清单每次上线前过一遍命中率还挺高记忆写入是否带上了过期时间召回是否限制了业务类型和用户ID召回结果是否按相关度截断到最近5条以内被替换的旧记忆是否已经从上下文里物理移除结构化状态与对话记忆会不会重复描述同一件事这些问题看起来琐碎但每一个都足以让Agent从“聪明”变成“神经质”。我记得有一次模型忽然在对话里说“您的收货地址是朝阳区XX路”而用户根本没在本轮提过地址。查了半天是三个月前的某个历史订单地址被向量召回了并且没有加user_id过滤。那之后我才下了死命令所有向量查询必须带全metadata过滤条件。4.4 增强后的Agent怎么验证和调优最后聊一下验证和调优。Agent的评测比传统软件困难因为同样的输入它每次输出可能不完全一样。所以我的策略是“场景化样例集关键行为断言”。我建了一个几十条真实用户问法的回放集每一条都标注了期望的动作链比如用户问“我的鞋什么时候到”期望动作是query_order拿到order_id后再query_logistics然后结束。跑完自动比对实际动作链与期望动作链按精确匹配和宽松匹配计算通过率。这个验证方式能抓住大部分回归问题比如某次改了Schema之后模型忽然不再调用物流查询这个测试立刻就能发现。除了离线测试还要做线上影子验证把部分真实流量复制一份喂给新版Agent只记录动作结果不直接服务用户。跑几天之后对比新旧两版的完成度、平均调用次数、错误类型分布。优先上线那些在影子环境里没有引入新问题的改动。调优的顺序我也有一个默认的优先级表通常照着这个顺序排查能少走很多弯路优先级排查对象常见手段1工具Schema与参数描述补充边界描述、格式示例、触发条件2记忆策略调整窗口长度、过期时间、召回数量3提示词结构强化状态注入、增加待办提示4动作预算与重试逻辑调整max_tool_calls、退避重试间隔5模型选择升级大参数模型或换更强推理模型优先级其实就说明一个道理先改低成本的再动高成本的。动不动就换模型或者堆复杂框架是最容易把问题带偏的做法。我见过一个团队Agent效果差二话不说把模型换成了更强的版本结果倒是好了点一查日志发现纯粹是因为新模型对混乱的工具描述更宽容治标不治本。后来把Schema改清楚之后原来的模型也跑得很好。做Agent这一年多我个人最大的体会是真正的门槛不在“让模型做出一次正确推理”而在“让系统允许模型犯错并且能低成本地从错误中恢复”。增强架构的价值恰恰在这里——它不是把模型变成永不出错的完美机器而是搭建一个容许出错、能够修正、可以审计的工作环境。所以每次有人问我“为什么我的Agent就是不稳”我几乎都会反问一句你的架构给它铺好了那层兜底的地板吗先搭好这层结构再去指望模型发挥聪明顺序就对了。
阅读完成 · 觉得有帮助？
