这几年做大模型应用的人越来越多但真正能把一个智能体从概念跑通到能处理真实任务的并没有想象中那么多。市面上讲提示词调优、讲模型选型的文章很多但把感知—规划—执行—记忆这条链路完整拆开、并且告诉你怎么稳定落地的内容相对稀缺。这篇内容就围绕大模型智能体开发实战展开从感知层的输入处理讲起经过规划层的任务拆解再到执行层的工具调用最后落到贯穿全程的记忆与上下文管理。想用大模型做客服助理、自动化执行、个人助理这类项目的朋友可以直接把它当作一张落地地图来读。我见过很多失败的智能体项目失败原因往往不是模型不够强而是工程层没有接住模型的不确定性。模型负责想系统负责稳两头都得有硬功夫。下面我会按实际开发顺序把每一层的设计思路、实现要点和踩坑经验逐一展开。1. 智能体到底是什么先把概念拆清楚再动手1.1 感知、规划、执行、记忆四个环节是一个闭环不要把大模型智能体理解成一个能聊天的接口它本质上是一个循环先从外部世界拿到信息也就是感知再决定自己要干什么也就是规划接着调用具体手段去改变外部世界也就是执行最后把执行结果收回来作为下一轮决策的依据。任何一个能在生产环境里稳定干活的智能体都逃不开这四个环节。感知不等于简单地把用户输入传给模型。感知要处理的是用户的一句话、后台的一条日志、某个系统返回的一段 JSON、甚至一张图片这些信息如何被清洗、组织成模型能理解、且有利于决策的输入结构。我见过不少项目模型能力很强工具也接好了最后却在感知这层翻车——因为扔给模型的原始信息太乱模型把噪声当成了决策依据。规划是智能体最像人的部分。模型接收到感知结果后需要判断当前目标是什么要拆成几步每一步用什么工具步骤之间有没有依赖关系。规划的结果一般是一段结构化的行动序列可能是一个 JSON 数组也可能是一次或多次工具调用。比模型能不能规划更关键的是规划错了之后系统怎么兜底这部分工作量至少要占整个项目的一半。执行层最容易理解也最容易被低估。一个智能体没有工具调用能力就只能停留在聊天层面。执行层的关键是把模型输出的意图翻译成真实的系统动作比如查数据库、发请求、写文件、调第三方服务再把结果安全地送回模型。权限、校验、容错最容易出问题的地方就在这里。记忆层负责让智能体在多次交互中保持一致。会话内的问题靠短期记忆解决跨会话的偏好和积累靠长期记忆解决。很多人做智能体只记住了把记录塞进上下文却忽略了记忆也会引入噪声也会被伪造也需要做质量评估。记忆不是越多越好而是越准越好。1.2 为什么传统流程编排不够用了早年的自动化系统都是写死的流程先调接口 A再判断返回值满足条件就调接口 B否则走异常分支。优点是稳定缺点是只能处理被预定义好的情况。真实任务往往没有固定路线用户的需求千奇百怪工具的执行顺序要根据当下情况动态调整。这正是大模型智能体存在的意义用模型的开放语义能力替代硬编码的条件判断让系统在语义空间里自行规划路径。但我也得说句实话这不是要彻底否定流程编排。智能体更适合开放理解型任务比如工单分类与流转、报表解读、个人助理、内容生成后再执行发布这类任务是目标明确、路径不固定。反而适合固定流程的比如高频交易订单处理、严格财务结算强行引入大模型等于给自己埋雷。选型的第一步是分清场景属于路径固定还是路径开放。核心判断标准很简单如果领域知识可以被穷举成明确分支就用流程编排如果需求描述无法穷举、需要根据上下文理解来动态选择动作才适合上智能体。这个判断错了后面所有技术选型都会变得别扭。2. 全栈技术选型动手写代码之前先想清楚2.1 模型能力与调用方式怎么选做智能体最核心的选型一定是模型。我自己的标准并不复杂第一是否具备稳定的工具调用能力第二能否接受较长的上下文输入第三在目标领域上的指令遵循能力是否够用。不要只看知识问答排行榜智能体对模型的要求和聊天不一样。模型必须在正确的时候输出结构化函数调用意图而不是车轱辘话或者一堆免责声明。调用方式上当前主流有两条路线。一条是直接调用大模型推理接口自己在工程层实现循环、记忆和工具调度。优点是自由度最高故障定位快每一层逻辑都握在自己手里另一条是借助第三方面向智能体的编排框架通过配置文件把模型、工具、记忆串起来。优点是起步快、生态成熟代价是一旦流程复杂起来框架本身的抽象层会成为新的学习成本和排查负担。我在早期项目里两条路线都试过。如果要验证一个概念原型用框架一天就能跑通从感知到执行的最小闭环但如果面向生产、对稳定性和可观测性要求高我个人倾向于用很薄的封装自己做。智能体的每一步都涉及模型输出解析、意图校验、上下文改写这些逻辑和业务绑得很紧直接用代码控制最直观。框架能让你跑得快但不见得能让你走得远。2.2 工具调用能力是智能体的手没有工具调用能力的模型只能做一个问答机器人。要成为智能体模型必须能输出这样的意图我要调用某个函数参数是什么。当前主流模型对这个能力的叫法略有差异有的叫函数调用有的叫工具调用内核都一样把工具的 schema 描述给模型模型在推理时自行决定要不要调用、带什么参数。工具调用的技术关键有几个。第一工具描述要写得尽量像 API 文档字段含义、取值范围、示例都写清楚模型才能生成准确参数。第二返回结果要结构化模型拿到执行结果后才能继续推理所以工具返回不能是一段写给用户看的自然语言最好是带明确状态的 JSON。第三工具数量不能无脑堆一次会话把几十个工具全塞给模型模型大概率会混乱。更合理的方式是做多级分组或者先用检索挑出候选工具。还有一个容易被忽视的问题工具调用是概率性的模型偶尔会输出一个格式合法但语义离谱的调用请求。系统层必须对参数做二次校验不能信任模型的输出。这个点我会在执行层章节重点展开。2.3 记忆层怎么选临时上下文还是持久化存储记忆是一个独立于模型的选择。短期记忆基本就是上下文窗口的管理把最近的对话与中间结果持续组织进每一轮请求长期记忆一般有两种路线一种是基于向量检索把历史交互切成片段、做向量化当前任务需要时再检索出相关内容注入提示词另一种是基于摘要定期对历史做浓缩丢弃细节只保留结论。我实际用下来的感受是向量检索适合细节查找型记忆比如用户上次说让系统记住某个具体偏好摘要适合背景共识型记忆比如当前这轮任务整体的目标和关键约束。很多应用会把两种机制同时用上。但记忆不是越丰富越好历史信息注入太多模型可能把旧事实当成当前事实引发幻觉。记忆层设计的目标应该是一句话让模型始终知道哪些信息是当前决策必须的哪些只是背景。注意不要试图把所有的业务数据都塞进上下文。上下文一长成本高、速度慢、噪音大三个问题会同时出现。在真实项目里先问自己哪些信息会直接影响模型下一轮的动作先只保留这些其余放到检索层按需取用。3. 感知层实战怎么把外部信息喂给大模型3.1 结构化输入与非结构化输入的归一化先说感知层最容易犯的错把原始输入直接当作最终的提示词输入。真实场景里模型接收到的信息来自四面八方格式五花八门。一个客服机器人可能同时收到工单文本、用户上传的截图、后端系统的订单 JSON、第三方服务返回的报错。如果不做归一化模型会在格式解释上浪费大量能力甚至误解字段含义。我的做法是先定义一层统一事件结构把所有外部输入转换成同一种格式角色谁发起的、内容主体要处理的核心信息、关联数据订单号、时间、状态等结构化字段、来源上下文来自哪个渠道、哪个系统。转换这一步用规则层完成不建议让大模型去处理因为转换规则是确定的大模型只会增加延迟和不确定性。归一化还有一个附带好处方便后续审计和排障。你可以在系统里存一份干净的事件结构再存一份原始输入两边做对照。一旦某个智能体行为出问题能很快定位到是信息源头的问题还是模型理解的问题。这个做法在排查环节能省下大量时间。3.2 上下文构造把信息变成模型能理解的指令归一化之后下一步是把信息编排进提示词。编排的顺序、语气、边界条件都很讲究。我惯用的结构分四段先描述角色与当前任务再给出现有信息经过筛选的感知结果然后明确目标和约束最后列出可用工具。这个结构不花哨但实用因为每一部分都对应模型决策链路里的一个环节。有一个反直觉的经验给模型的信息不是越详细越好而是越有序越好。同样一段内容分散塞在对话的不同位置与整齐放在当前状态小节里模型的决策质量差别很大。因为大模型对上下文的注意力并不均匀冗长的、杂乱的信息会被模型选择性忽略。感知层的核心能力其实是判断什么该说、什么不该说。我还建议在提示词里明确标注信息的来源和时效。比如以下是 10:32 分的系统状态快照以上来自用户最新一条消息。这能帮模型区分刚刚发生的和历史遗留的。很多上下文混乱问题源头就是模型没有办法判断信息的新旧优先级。3.3 多模态信息与日志类场景的处理要点现在的智能体经常碰到图片、音频、文件这类非文本输入。处理多模态要分两种情况如果模型本身就支持多模态可以直接把图片和文字一起送进去问题会变成如何压缩图片分辨率、如何裁剪出有效区域如果模型不支持就得先做一步感知预处理用单独的视觉模型提取关键信息再把摘要作为文本输入。我倾向于后一种因为把图像摘要转成结构化文本对后续工具调用的准确率提升非常明显。日志和系统状态这类输入是感知层一个特别容易踩的坑时间。日志里充满了相对时间、时区和状态变更如果直接塞给模型模型很容易把上一次请求理解成当前请求。我通常会把日志按时间戳重新对齐并在每条日志前标注事件发生于某某时刻把上下文里隐含的时间关系显式化。感知层做到这一步规划层的模型才能做出正确判断。处理日志类数据还建议做一次去噪。日志里大量的 INFO 级信息对决策毫无帮助反而会稀释关键告警的权重。我会用规则把日志按级别和关键词分类只把 ERROR、WARN以及与当前任务相关的上下文喂给模型。让模型在你筛选过的信息上做判断永远比让它自己从海量日志里淘金稳定。4. 规划层实战从能聊天到会分解任务4.1 先让模型输出计划再让它执行我实践下来最稳的做法是先让模型输出计划再让它按计划行动也就是常说的 Plan-then-Act。实现上很简单第一轮请求告诉模型目标和现状要求它返回一个 JSON 格式的计划包含步骤列表、每步使用的工具、依赖关系系统解析计划后再逐步执行。好处是你能在动手之前看到模型的意图发现异常可以及时终止而不是让它一路错到底。这会带来额外一次模型调用。要不要为这一步等待支付代价取决于任务风险。如果智能体要执行的是不可逆操作比如删除数据或发出扣款指令我强烈建议保留计划层如果是低风险的查询类任务跳过计划直接调工具会更高效。我在实际项目里采用的做法是默认有计划层低风险任务用配置标记跳过。计划输出之后系统要做一次计划校验。校验包括步骤数是否在合理范围内、是否引用了不存在的工具、参数是否完整、是否存在循环依赖。这一步可以用规则也可以用另一个轻量模型来审查。我的经验是规则校验更适合拦截明显错误模型审查更适合发现逻辑漏洞。两者结合才敢放模型去执行。4.2 反思和自我纠错ReAct 思路的简化落地ReActReasoning Acting本质上就是让模型在思考—行动—观察结果之间循环。在具体工程里我不要求模型每轮都长篇大论地思考而是要求它在工具返回失败或者结果不满意时先输出一段简短的原因分析再决定下一步。这就是最基本的反思机制。真正落地时有一个细节反思不能只靠模型自觉。我见过很多智能体在工具报错后硬着头皮再试一次结果变成无限重试因为模型没有收到错误的核心原因。正确的做法是把工具返回的错误信息做结构化区分参数错误目标资源不存在权限不足服务暂不可用再让模型依据错误类型决定是修改参数重试、换一个工具、还是直接放弃并给人反馈。这比让模型读原始报错文本再去猜要可靠得多。实现反思机制时建议给模型设置尝试次数上限和策略切换阈值。比如最多连续重试两次两次失败后必须更换策略或上报人工。没有这些限制模型会在一个错误路径上来回打转消耗大量 token 和用户耐心。4.3 用状态机给智能体画一个合法活动范围把规划完全交给大模型并不可靠所以工程上要用状态机做边界约束。一个智能体应该处于等待输入规划中执行中等待评价已结束这类状态里每种状态只允许特定的模型行为和工具调用。比如在已结束状态下任何模型的自主行动请求都要被拦截在等待评价状态下模型可以提出建议但不能直接触发新的外部动作。这看起来像是把灵活的智能体锁死了但这是为了保证可控性。大模型本身不会遵守规则只有系统层用代码帮它守住规则。状态机和模型是互补关系状态机负责定义合法路径模型负责在合法路径里做选择。开发时我最重视非法动作拦截的测试比如故意让模型越权调用某个工具看系统能否正确拒绝。这类测试比功能测试更重要。状态机的状态流转本身也需要留日志。每做一次流转就把从什么状态、因为什么事件、转到什么状态记录下来。智能体上线后排查问题基本靠这份状态流转记录它能告诉你模型是在哪个环节开始偏离预期。5. 执行层实战工具调用的闭环实现5.1 工具定义规范给模型一份看得懂的说明书工具定义是执行层一切的基础。每个工具至少要包含名称、一句话用途说明、参数列表、参数类型、必填项、返回结构、可能抛出的错误码。这些信息不光是给人看的也是给模型看的。工具描述直接影响模型选择工具的准确性写得越明确模型越不会乱选。我通常会把工具描述和实际校验逻辑分开维护。模型面对的是一份友好的 schema实际调用的则是经过严格校验的业务接口。举个例子模型可能会传一个不存在的订单号工具层必须在调用业务接口前先校验格式而不是让错误直接穿透到后端。这样即使模型犯了错我们也能在工具层把影响兜住。工具描述还有一个细节尽量提供一到两个参数示例。模型对带具体示例的 schema的理解准确率明显高于只有抽象字段说明的 schema。尤其遇到枚举值、时间格式、编码这类容易出错的参数示例就是最好的约束。5.2 意图路由让模型自己决定调用哪个工具工具多起来之后模型会面临选择困难。有的项目把全部工具一次性塞进提示词结果模型经常选错。我的做法是加一层工具路由先用一次轻量的模型查询从工具清单里筛出最相关的三五个候选再把这些候选及其描述传给第二轮完整推理。相当于让智能体先想一想该用什么工具再认真想具体怎么做。这个方法虽然多花一次模型调用但在工具数量超过十个的项目里准确率提升非常明显。工具描述占用的上下文变短了模型注意力更集中同时对无关工具的幻觉调用明显减少。也可以用向量相似度来做工具检索但作用有限因为工具选择依赖语义意图的细微差别纯向量匹配经常把删除和修改这类动作搞混。工具路由的结果也要记录。哪怕最终没选对你至少能回顾模型认为哪些工具最相关、基于什么上下文做出的选择。这对优化工具描述非常有帮助。我每隔一段时间会拿历史请求重新跑一次工具路由看看模型选得准不准并据此调整工具描述。5.3 执行结果的校验与回填不是取回来就能用工具执行完后不能把结果原样抛给模型要先做校验和回填。校验包括结果格式是否符合预期、是否有空值、是否触发了错误码、是否需要裁剪大字段。回填则是指把执行结果按固定模板写成模型容易理解的叙述加上执行状态、耗时、后续可用动作等元信息。我们做过一个项目工具的返回结果越大模型下一步的执行越混乱。因为模型把大量无关数据都当成了决策依据甚至开始复述工具返回值。解决办法是执行层增加摘要化步骤如果工具返回的是几百行的列表系统先用规则提取关键数字和重点字段再让模型处理简版。记住回填给模型的永远是决策所需的最小信息集。回填模板可以这样设计先给结论再给支撑数据最后给可以选择的下一个动作。这比丢一张原始 JSON 给模型要友好得多因为模板本身就在引导模型做正确决策。最初做这个设计时会感觉是在替模型做一部分思考但长期来看它对系统稳定性的提升非常值。5.4 异步任务与多智能体协作的经验工具调用不都是同步的有的操作要花几秒甚至几分钟比如生成一份报告、等待外部服务确认。这类任务不能阻塞模型推理循环否则用户体验极差。工程上要用异步任务机制智能体先返回任务已受理任务 ID 为 XXX然后由后台任务执行器处理完成后回调把结果写回记忆等下一轮对话时再让模型接管。多智能体协作现在被提起得越来越多。我的实际感受是多智能体不是银弹两个智能体互相调用在日志和排查上会成倍复杂。能用单个智能体加多个工具解决就不上多智能体。真需要协作时采用主控-worker结构主控负责目标拆解与结果汇总worker 只负责单类任务。最忌讳的是让智能体之间直接自由对话无边界协商最后一定会出现上下文失控。如果是多智能体协作每个 worker 必须有自己的独立记忆空间而不是共享全部上下文。共享上下文会造成严重的信息串扰一个智能体的中间思考被另一个智能体当作事实引用错误会成倍放大。主控负责汇总时也应该只接收 worker 的结论而不接收 worker 的完整思维链。6. 记忆和上下文的生命周期管理6.1 短期记忆会话窗口的压缩与裁剪短期记忆的核心矛盾是上下文窗口有限而多轮智能体的中间结果会不断累积。我处理短期记忆的做法是三道裁剪第一道裁剪发生在每轮请求前删掉已经用过的工具返回大字段只保留结论第二道裁剪发生在计划完成后把长计划压缩成已完成步骤 当前步骤 剩余步骤第三道裁剪是把早期对话的完整文本换成摘要。这里有一个细节裁剪不能只在请求层做还要同步更新引用关系。如果早期内容被裁掉了而模型下一轮还在依赖一个被删掉的中间值系统必须提前把关键中间值提升到持久变量单独放进当前上下文。说到底短期记忆管理的目标不是省钱省 token而是确保每一轮模型输入都保持干净、完整、不冗余。还有一个容易被忽略的点摘要本身要标注由历史对话自动生成。模型对摘要的信任度应该不同于原始记录否则它会把摘要里的模糊表述当成精确事实。我会在摘要前加一行限定说明明确告诉模型这段是摘要如需精确内容请查看具体记录。6.2 长期记忆向量检索和摘要并存长期记忆跨会话存在我用两层结构向量库负责存储可检索的细节摘要库负责存储可引用的结论。写入向量库时要注意切片粒度切得太粗检索结果不精确切得太细多个片段语义重叠。我一般以一个完整交互事件为最小切片单位把事件背景、动作、结果整体存入再打上标签和时间戳。摘要库则会在每个任务结束时让模型生成一段这一段应该记住什么的总结再存进结构化的记忆表里。注意摘要内容和向量片段不要重复冗余。摘要要回答这件事的结论是什么向量片段要回答这件事的细节长什么样。模型读到摘要能快速建立背景需要更多细节时再搜向量库。长期记忆检索有一个建议检索到的内容必须带上时间信息和来源标签。比如根据 2024 年 11 月的交流记录用户偏好 X。有了来源标注模型才能判断该信息的可信度。否则历史信息一旦与当前事实矛盾模型容易混乱。6.3 上下文注入的顺序与权重我踩过很多次坑之后发现上下文注入的顺序对模型决策质量影响很大。我现在的标准顺序是系统角色说明、当前任务目标、用户最新输入、最近决策摘要、当前相关历史记录、候选工具描述。越靠前的内容被模型当作越重要的前提越靠后的内容则被视为参考信息。除了顺序还要控制注入的权重也就是数量配比。任务目标必须展开写用户输入可以原文保留历史记录按相关度排序后截取工具描述只保留候选。很多人做上下文把历史记录铺满用户输入被淹没模型就会猜测用户意图。让模型始终看见不完整但优先级正确的信息比让它看见完整但杂乱的信息更可靠。权重控制还需要考虑近期优先。同一话题的上下文离当前时间越近的片段信息价值越高。我会给历史片段打一个时间衰减权重超过一定时长的内容默认进入摘要层而不是原文注入。这个策略在处理长会话时尤其管用能显著降低模型被早期细节带偏的概率。7. 工程化与稳定性从 Demo 到上线的距离7.1 可观测性把智能体的每一步都记录下来智能体的调试难度远超普通程序因为它的决策是概率性的同一个输入在两次运行里可能出现不同路径。上线之前必须把每一步都留痕。我要求所有智能体项目至少记录以下内容完整输入输出、模型每一轮返回的原始内容包括工具调用、工具调用的参数与结果、计划变更的原因、上下文注入的截断情况。没有这些记录出了问题基本靠猜。我见过一个典型案例线上某个智能体突然开始重复调用同一个接口排查了半天才发现是因为某次工具返回里包含了错误的时间字段模型一直以为任务没有完成。如果没有完整日志这个问题的定位时间是按小时计的。可观测性不是可选项是智能体系统的地基。记录日志时随手把关键中间值单独抽出来打点。比如当前任务 ID、目标、已执行步骤数、最近一次异常码。这些打点数据可以按时序重放能轻易还原出智能体每一步的决策上下文。重放能力是大模型应用排障的一个利器。7.2 容错与重试模型输出不可控怎么办模型输出不稳定是常态工程上必须用重试和兜底两条路解决。重试针对偶发错误比如模型返回了格式非法的结果、网络超时可以在退避策略下重新请求一两次兜底针对系统性错误比如多次重试仍然无法得到合法输出系统必须能切换到一个确定性的规则分支而不是无限重试。特别提一个常见坑对模型输出的 JSON 直接做解析一旦格式错误整个流程崩溃。我的做法是先做一层清洗把常见的模型输出问题比如多余的标记、注释、前后杂文本先剥掉再用容错解析器做解析。解析失败时不要甩给用户而是把模型原始输出留档然后走重试。模型输出不稳定这不可怕可怕的是系统没有一点对不稳定的准备。重试策略要区分错误类型。网络超时可以快速重试模型输出格式错误说明模型本身上下文可能有歧义重试前可以先微调提示词工具调用权限不足的重试则是多余的应该直接改走人工流程。把错误分类做好重试才不会变成瞎试。7.3 性能优化缓存、并发与成本控制智能体的每次决策都可能涉及多次模型调用比普通聊天贵得多。成本控制第一招是缓存对于相同问题 相同上下文的查询直接复用上次结果。缓存键要设计得足够精确既不能误命中导致信息过时也不能因为太多变量导致缓存形同虚设。我通常会把任务类型、关键参数、时间窗口纳入缓存键。第二招是并发设计。多个智能体实例同时跑是很常见的但模型接口会有并发限制。我通常用带队列的任务池来管理并发必要时对请求做优先级排序保证高价值任务不被积压。第三招是降低无效调用能通过规则判断的意图就先走规则只有规则判断不了的才交给模型决策。每一层都能省一次模型调用这些省下来的成本加起来非常可观。还有一个经验把所有模型调用都放到一个统一网关后面方便做限流、熔断和成本统计。没有网关你会很难回答今天这个智能体花了多少钱、哪个环节最贵这类问题。有了网关还能针对不同任务的模型版本做实验对比效果后保留最优版本。8. 常见问题与排查案例实录8.1 模型虚晃一枪不调用工具现象模型在回答里说我将为您查询订单但并没有输出任何工具调用用户看到的是一个假的承诺。原因一般是工具描述不完整模型不知道用哪个工具或者提示词里没有明确要求必须调用工具。解决办法很直接在系统提示词里写清楚如果需要订单信息必须调用订单查询工具不能凭空回答同时检查工具 schema 是否把参数填写方式写清楚。测试时专门构造模型必须调工具才能回答的用例。8.2 上下文越滚越乱模型开始答非所问现象智能体在多轮交互后逐渐发散把前几轮的话题和最新问题混在一起。原因多半是早期上下文没有裁剪导致模型被历史话题带偏。解决办法是对每轮输入做一次相关性过滤把与当前目标无关的旧内容降权或移除。另一个技巧是每当任务目标发生变化时显式重置当前状态字段用全新状态掩住旧背景。8.3 工具报错后模型开始胡编现象工具调用失败后模型为了挽回颜面在回复里虚构了本该由工具返回的数据。原因在于工具调用失败的信息没有结构化返回模型只知道没成功不知道具体原因于是用幻觉补全。解决办法是把错误码和可读原因写清楚并在提示词里加硬规则任何时候都不能编造工具返回的数据失败时应明确说明失败原因并提供可选下一步。这条规则要反复验证最好在测试集里专门放几道工具必然失败的用例。8.4 疑难排查速查表问题现象可能原因优先排查项解决思路模型不调用工具工具描述不清或未强调工具必须调用提示词是否包含必须调用工具约束schema 参数是否完整补充约束与示例缩小候选工具范围工具参数传错参数说明缺失或参数类型不明确工具返回值与描述是否一致模型是否看到参数示例在工具描述中增加枚举值和格式示例上下文太长导致超时中间结果与历史未裁剪每次请求的实际 token 数与注入结构加入短期记忆裁剪用摘要替代原文多次重试仍失败模型输出不稳定原始输出格式与预期格式的差异增加清洗与容错解析设定重试上限系统执行越权操作状态机未拦截非法动作状态转换是否覆盖所有路径补全状态机的非法动作拦截逻辑多轮后偏离任务历史输入未被过滤当前上下文中无关历史占比增加相关性过滤重置当前状态字段我做了几个智能体项目之后最大的体会是调试智能体最难的不是某一层的技术实现而是把模型当人看。模型不是机器它的输出永远是概率性的真正的工程能力体现在确定性系统如何处理这种概率性用规则守住边界用工具调用降低幻觉用记忆管理保持一致性用状态机保证可控性。如果你正在做类似的系统建议按照这样的顺序推进先拿一个小范围场景跑通全链路不要一开始就设计大而全的智能体跑通后再逐步增加工具和记忆每加一个工具就配套做一轮失败用例测试最后再去优化成本和响应速度。先让智能体在一件小事上稳定干活比什么架构都重要。把这篇文章里的检查点逐项对照自己的项目过一遍你的智能体离生产可用就不远了。
