1. 工具调用格式失控解析链路上的暗雷做 agent 的朋友都懂最让人抓狂的不是模型答错题而是模型“答对了但格式错了”。你说好了返回 JSON它给你夹带 Markdown你说好了用action字段它给你换成Action更有甚者在工具参数里直接写自然语言“请帮我查一下北京的天气”而不是结构化参数{city: 北京, date: 2025-01-06}。这个问题我在实际项目里栽过不止一次必须放在最前面讲因为它是 agent 一切后续逻辑的地基。很多刚上手中控框架的团队第一周几乎都在跟格式问题搏斗。1.1 隐藏的触发器与共性解法把不同项目里的报错样本收敛一下会发现格式失控几乎都发生在三类场景里系统提示词里同时塞入了“工具描述”“输出示例”“少样本问答”三段内容模型被示例带偏学会了“多余的前缀后缀”。工具返回结果里残留了异常字符比如某个数据库字段带了换行符和引号模型为了“忠实于原文”把这些脏字符一起复制进了下一次工具参数。长上下文场景下格式漂移前面几轮都用对了到第五轮忽然夹带了一段思考过程。针对这些问题我目前实测下来最稳的方案是三重校验缺一不可第一重强制工具调用走独立的tool_calls通道而不是让模型把参数写进普通对话文本里。市面上的主流模型 API 都原生支持这种结构化的工具调用方式你只要在请求里声明工具列表模型会在独立的字段里返回结构化的参数天然避开“夹带多余内容”的问题。这一层能挡掉大概 80% 的格式错误成本极低。第二重JSON 解析失败后不做“二次启发式修复”而是直接重试。很多框架会自作主张去“补全残缺 JSON”比如自动在末尾补一个}或者把单引号替换成双引号。我的经验是宁可让 agent 多调用一次模型也不要在解析层做这种投机取巧的修复。因为你修复出来的参数大概率是错的而模型下一次重新生成时自己会意识到问题产出正确参数的概率反而高得多。第三重对关键参数做最终的类型与取值校验。比如日期字段必须匹配\d{4}-\d{2}-\d{2}枚举字段必须在预设列表中。这层校验不依赖模型纯粹是确定性逻辑能在工具真正执行前再兜一次底。1.2 建立可观测的失败样本池解决格式问题不能靠“改了再试”你得有数据。我在项目里做了一个非常轻量的事情把所有解析失败、重试成功、重试仍失败的请求都落成结构化日志字段包含模型返回的原始文本、解析期望格式、失败原因分类、重试次数和最终结果。这样跑一周之后你会发现格式问题根本不像想象中那么随机。某些模型在特定温度参数下格式漂移率明显更高某些复杂工具参数超过 8 个的那个出错率是简单工具的 3 倍。这些结论不靠日志你永远没法量化。有了这个失败样本池之后你就可以针对性地做两件事一是把最高频出错的工具描述改写得更简洁二是给复杂工具增加“参数默认值”减少模型必须输出的字段数量。2. 上下文管理失效窗口不是垃圾桶“给 agent 塞了多少上下文决定了它上限有多高也决定了它下限有多低。”这句话在实践中经常被极端化理解——有人恨不得把整个知识库都塞进上下文也有人因为怕超限而砍掉关键信息。两种极端都很危险。上下文管理失效的症状很典型agent 在用完窗口边缘的数据时开始“胡言乱语”复述早期内容或者干脆忽略系统提示词中的硬性指令。原因大家都猜到了就是大模型对长上下文中间段的注意力会明显衰减不过真正让人头疼的是“衰减”不是平滑的而是呈现一种“中间断层”的模式。2.1 窗口预算的分层分配策略我自己用下来最顺手的分配方式是把窗口想象成一间三居室而不是一个垃圾桶预算区域占比放什么内容常驻区15%~20%系统提示词、用户核心目标、硬性约束工作区50%~60%当前任务的工具调用记录、最近 2~3 轮对话、入参出参摘要边缘区20%~30%需要引用的历史结论、知识库检索结果、长文档切片核心思路是系统指令区永远保留最精简的版本用“不要做什么”取代“要做什么”的冗长罗列工作区只保留当前任务链相关的中间结果更早的内容降级为摘要边缘区内容随用随取用完之后立即从工作区移出。关于摘要降级不是简单让模型用一句话总结上一轮对话而是按照“任务目标→已执行步骤→关键结论→遗留问题”四段式来生成摘要。这样即使历史内容被压缩成几百个字agent 在执行后续步骤时依然能找到自己“进行到哪一步了”的锚点。2.2 截断顺序与关键内容保护需要主动截断时一定要遵循“先截工具输出再截历史对话最后截系统提示词”的顺序。原因很好理解工具输出的体量往往最大但大多数属于“用过即弃”的过程性数据历史对话里保留了用户意图的演进过程价值比工具输出高一档而系统提示词是行为基线万万不可动。实操层面还有一个容易忽略的细节截断时不要只按 Token 数切要按“语义完整块”切。比如某个工具调用包含一条用户的原始问题、一次工具返回、一次模型的分析结论这三者要作为一个整体保留或移出不要单独切断工具返回。一旦切碎了后续轮到模型分析时它会面对一份没有前因后果的孤立数据很容易产生错误解读。3. 记忆机制的分叉与污染串味比遗忘更可怕如果说上下文管理是“内存”问题那记忆机制就是“磁盘”问题——它决定了 agent 能跨会话记住什么、忘掉什么。这一块的问题有两个极端一个是“记不住”另一个是“记太乱”。“记不住”好理解就是每次新会话 agent 都像失忆一样问你重复的问题。这个问题的解法相对成熟无非是做外部记忆库按会话 ID 存取摘要。真正让我头疼的是第二个记忆污染。所谓污染指的是 agent 把某一次对话里的暂时性状态比如“用户今天心情不好”或“当前任务遇到阻塞”当成了用户的长期偏好写进了长期记忆库然后在未来的所有会话中都带着这份偏见做决策。3.1 区分短期状态与长期画像这个问题的根源在于记忆写入时没有分类。我现在要求记忆写入必须带标签至少分为三类episodic情景记忆某一次会话中发生了什么适用于单次任务的连续执行。semantic语义记忆从对话中提炼出的用户偏好、事实结论、领域知识适用于跨会话复用。procedural流程记忆用户希望 agent 在处理某类任务时遵循的习惯性流程比如“周报要用表格”“回复要附原文链接”。写入规则也很明确情景记忆默认只保留 7 天或者随会话销毁语义记忆写入前必须经过一次“去情景化”校验——问一句“如果用户明天看到这条记忆他会觉得这仍然成立吗”流程记忆的写入需要更审慎要求必须见到同类行为至少两次才能沉淀为流程只出现一次的不算。3.2 让记忆“可删除”比“可写入”更重要实际项目里记忆系统最大的工程质量问题不是写入而是删除。用户明确说“以后别再这样了”agent 说好好好但下次回来它还是老样子——因为记忆库里根本没有提供删除和修改的入口或者虽然有入口但记忆条目没有关联来源无法定位到具体是哪一次的哪句话生成了这条记忆。这个问题的工程解法是每一条长期记忆生成时必须带回源指针来源会话 ID、原文摘录、可信度评分。有了源指针之后删改就不再是改一条孤立记录了而是“从用户反馈反查到来源对话再回到记忆条目上做变更”形成一条完整闭环。我在团队里反复强调记忆库的表结构设计从第一天起就要考虑“谁创建了这条记录”“依据是什么”“怎么反查”否则三个月后它会变成一笔算不清的烂账。4. 工具选择错误与参数幻觉模型在“不懂装懂”agent 和普通聊天机器人的最大差异在于“执行力”而执行力最直接的体现就是工具调用的准确性。不过大家普遍反馈模型在选择工具时经常“犯错”错误集中在两处一是工具选错二是在参数里编造不存在的选项。一个非常经典的案例某项目里给 agent 挂了一个天气查询工具、一个穿衣建议工具结果用户问“明天去上海出差要带什么衣服”模型直接调用了天气查询工具并传参{days: 明天}然后基于查询结果自己“推算”穿衣建议。如果当时没有把穿衣建议工具挂上去这个方案看起来还挺顺理成章的但既然工具列表里明明有“穿衣建议”这个更贴切的选项模型这种绕路行为依然让人费解。4.1 参数幻觉在 RAG 类工具中特别高发参数幻觉在数据库查询类、RAG 检索类工具上尤其严重。原因在于这类工具的入参通常是“语义检索关键字”而模型在生成关键字时会把对话上下文里出现过的专有名词随意拼凑。比如用户明明只提到“上个月的项目”模型在调 RAG 工具时会自作主张加上“成本超支”这种从未出现过的限定词导致检索结果被过滤到几乎为空。应对方面我实测下来最有效的办法是把 RAG 工具的入参从“自由文本”改成“结构化枚举结合自由补充”固定字段用枚举值时间范围确定性写成选项自由补充字段限制最长 20 字并明确提示“只能使用用户原话中的词语禁止自行添加修饰词”。这招虽然牺牲了灵活性但检索准确率的提升非常明显。4.2 关键执行前的不可逆操作复核另外一个必须做的事是对“不可逆操作”执行前增加一道用户确认。这里指的不仅是删除、转账、发送邮件这类高成本动作还包括那些“执行了很难撤销”的工具比如覆盖一份文件、给所有群发消息、创建一条对外发布的内容。实现方式就是给工具加一个requires_confirmation元字段agent 在执行前必须先输出一次待确认摘要等用户明确同意后再真正触发工具。别嫌多此一举在用户可感知的高成本场景中一次误操作对信任的伤害远大于多一步确认带来的交互负担。5. 循环、死锁与失控递归当 agent 走不出来时如果说前面的问题都是“质量”问题那这一步就是“事故”问题。循环与失控递归是 agent 在生产环境里最让人头秃的表现同一个工具被调用几十次、陷入反复重试、把单次任务的调用量烧到几百次还是没结果。这类问题往往不是模型单独造成的更多是工程架构没做护栏。5.1 三步收敛循环的终止条件设计打破循环的设计其实不复杂核心是给 agent 的每一步行动加上“确定性护栏”。我通常实现三层调用次数上限单个任务最多允许 N 次工具调用根据任务复杂度定我常用 10~15 次超了强制转入“汇报当前状态请求用户指导”的收尾流程。重复动作检测如果模型调用了同一个工具且传参完全相同或高度相似超过两次直接中断并主动提示“这个方案已经尝试过请更换思路或请求用户确认”。收益评估节点每完成三次工具调用追加一次中间评估“目前离目标还有多远是否需要调整方案”这一步的价值在于让模型自己发现当前路线走不通而不是闷头把 15 次调用全部烧完。很多人以为循环问题是模型“傻”但实测下来有很大比例是“提示词里没有告诉模型什么时候该停下来”。你在系统提示词里白纸黑字写清楚“如果连续两次工具调用返回结果没有新增有效信息必须停下并总结现状”循环率能肉眼可见地下降。5.2 子 agent 的任务归属与退出协议多 agent 协作场景里的死锁就更隐蔽了。当主控 agent 把某子任务委托给子 agent 后常见的失控形态是子 agent 完成不了任务但又不归还控制权一直在内部尝试主控 agent 等不到结果又不敢继续后续步骤两边僵住。这个问题的根源在于没有定义“任务退出协议”。我最初只定义了“子 agent 用 finalize 工具结束任务”结果它遇到完不成的活儿时干脆不调用让主控一直空等。改进方案是给子 agent 增加一个明确的退出条件和超时兜底当子任务执行超过预设轮数或时间主动返回“未完成原因已获取的部分成果建议下一步由主控处理”。这样即使子 agent 失败了主控也能基于它带回的部分结果继续推进不至于整条任务链断掉。6. 多 agent 协作中的消息风暴与角色错位最后一个值得重点讨论的问题是复杂场景中的多 agent 编排。多 agent 不是“多个单 agent 的简单拼接”当你真正让几个各司其职的 agent 协作时第一个遇到的经典问题就是消息风暴。6.1 核心日志保留与噪音截断我见过的情况是这样的主控 agent 在推进一个跨部门任务时触发了市场调研 agent、竞品分析 agent、文案生成 agent 三个子任务子 agent 之间又各自向主控汇报中间进度。由于没有全局协调主控在同一时刻收到七八条消息上下文瞬间被打爆。更离谱的是主控 agent 还经常在中间被一些“进度汇报型”消息带跑把注意力从任务目标转移到查询子 agent 的细节工作上。这个问题的解法是给多 agent 协作加上“消息分级”机制。主控与子 agent 之间只允许传递以下三类消息任务下发含明确的目标和交付物标准、结果回传含最终产出或无法完成的说明、异常上报仅限无法自行决策的阻塞。除此之外所有“过程进展”“中间思考”“额外发现”一律写入共享的状态存储区主控不主动订阅需要时再按需读取。这么说可能有点抽象打个比方子 agent 像一个外包团队你只需要它交付成果、报告阻塞、说明延期它不需要每分钟跟你同步“我正在写第二段”。如果你不加约束agent 之间也天然倾向于过度同步因为模型总觉得尽报详情是一种负责任的表现最终结果就是把上下文塞爆。6.2 基于角色隔离解决责任悬空角色错位是另一个容易被忽略的坑。典型场景是文案生成 agent 在生成内容时发现需要参考一份数据报表它直接调用了一个数据查询工具这个工具原本被预设为主控专用结果查询条件不完整返回的数据用不上白消费一次调用还让主控以为“文案 agent 卡在数据上”误判了瓶颈。我在设计协作架构时现在会在发起每个子 agent 时明确用系统提示词声明它的工具白名单超出白名单的工具一律不在它的可调用列表里出现。同时在提示词里写清楚“你需要查看数据时将需求描述为『请求主控提供数据』而不是自行调用未授权的工具”让子 agent 把“自行解决”的冲动转换为“请求协作”的正确行为。这算是一种角色隔离原则的落地。7. 一个更隐蔽的问题评估缺失比缺陷本身更致命最后这点是我最想跟同行们分享的。上面的所有问题单拎出来都有解法真正让人反复吃瘪的原因是团队里没有一套评估体系导致每次优化都像盲人摸象。你改了上下文策略是变好了还是变差了你调整了工具描述是不是顺便把另一个场景搞坏了如果没有评估这些问题永远没有答案。7.1 轻量级评测集的建设思路很多人一听“评测集”就本能地觉得是个大工程需要标注大量数据还要搭一个复杂的评估流水线。其实你可以也从最小闭环起步拿最近一周的真实用户会话人工挑出 30~50 个有代表性的任务场景每个场景标注好“期望调用哪些工具”“期望产出什么结果”“哪些行为属于必须避免的禁区”。然后把这些场景作为固定输入每次改动 prompt 或工具配置之后全量跑一遍比较改动前后的工具选择准确率、任务完成率、平均调用次数、上下文消耗量。这四组数字的变化幅度就是你这次改动真实效果的量化指标。有了这套东西之后优化就不再是拍脑袋了你能明确知道哪一次改动是正向的、哪一次是负向的团队里吵架的概率也直线下降。7.2 把“失败路径”纳入评审视野另外评测场景不要只挑“正常任务”一定要包含失败路径。我每次建评测集都刻意准备 10% 左右的“用户表达模糊”“工具返回异常”“同一问题多轮追问”的案例专门考察 agent 在异常场景下还能不能保持冷静和遵守流程。坦白讲agent 在正常路径上表现再好遇到一次异常就开始胡言乱语在真实用户面前依然是不可用的。结合实践我认为 agent 开发里最值得敬畏的事不是模型能力而是工程护栏的完备程度。格式校验、上下水分层、记忆分类、循环终止、消息分级、评估闭环——每一层都不是多么花哨的技术但每一层都决定了一个 agent 项目是能长期稳定运行还是只会停留在 Demo 阶段。而评估闭环恰恰又是这些工程能力能持续优化的前提。想把这个方向做扎实的同学我建议的路径是先建评测集再逐层补护栏每补一层都用评测集验证效果。顺序反过来做很容易陷入“修了一个 bug引入三个新 bug”的怪圈。