每个做 Agent 的人应该都有过这种体验第一个 Demo 惊艳全场仿佛请来了一个全知全能的数字化员工用了一周之后开始皱眉一个月之后恨不得把它删掉重写。更让人绝望的是你以为是模型不够聪明于是从开源小模型换到闭源大模型又换到本地微调模型结果问题不但没消失反而在一个新维度上变本加厉——模型越强Agent 犯错时越理直气壮。我做了快两年的 Agent 项目踩过模型偏航、记忆污染、工具失控、并发打崩、无限循环这些坑之后才慢慢意识到一个最关键的事实Agent 越用越坑的真正原因缺的从来不是模型能力而是工程纪律。所谓工程纪律不是代码规范那种表面东西而是你在 Agent 周围建立的一整套行为约束、数据治理、观测反馈和容错机制。这篇文章我就把这套东西掰开揉碎讲清楚包括我对 context 窗口的管理方式、记忆分层的滤波策略、工具调用权限的最小化设计、并发控制的具体参数以及真实项目里排查过的那些诡异 bug。无论你是在搭 AI Agent 框架、做 agent 开发还是只想把现有 Agent 稳住这篇应该能帮你省下几周的返工时间。1. 为什么模型越换越强Agent 却越用越坑1.1 先看一个真实案例换模型救不了混乱系统我去年给一家公司做客服工单 Agent第一版直接接最强商用模型效果确实惊艳。但上线三周后它开始出现一个诡异现象早上的回答精准利落下午就开始胡言乱语月底的时候连用户的名字都能记错。团队第一反应是换模型从 A 家换到 B 家又从大模型换成微调过的领域模型。结果最有代表性的一次是这样的换了模型后的第一天Agent 异常聪明甚至能把用户隐含的退款诉求都识别出来第二天开始退化第三天又犯同样的错——把旧工单里的错误结论当成正确答案引用。那一刻我意识到问题根本不在模型而在系统本身每次请求都把几千条历史工单塞进上下文早期的错误信息没有被过滤Agent 的注意力被海量噪音淹没于是越用越笨越用越乱。这个案例不是特例。模型只负责“理解与生成”而 Agent 是“模型 数据 工具 流程”的复合系统。系统的性能上限取决于它最弱的那个环节。模型换得再多如果上下文爆炸、记忆污染、工具失控、观测缺失这四个问题不解决效果永远只会短命。1.2 Agent 效果衰减的四个典型病因我在多个 Agent 项目中反复踩坑后总结出四个高频病根几乎覆盖了绝大多数“越用越坑”的场景上下文失序这是最常见的坑。Agent 的 context 窗口不是无限大的即便现在主流模型支持 128K 甚至更长上下文注意力机制的现实是“中间遗忘”。把所有历史记录、系统文档、用户对话一股脑塞进去模型反而抓不住最关键的指令。尤其当系统提示词被后续对话或工具返回结果挤到后面时Agent 会逐渐“忘记”自己的角色和约束。记忆污染Agent 记忆本身不是坏事坏在写入太随意。很多实现把每一次工具返回、每一段用户输入甚至模型的错误输出全部存入长期记忆。这些噪音会在后续检索时被当成事实引用形成“错误-引用-再错误”的正反馈回路最终让 Agent 的输出越来越离谱。工具失控Agent 有工具权限之后问题成倍增加。参数校验缺失、没有配额限制、结果不校验工具成了模型的“放大器”——模型犯了错工具就把错误放大成系统级故障。常见的是把写数据库的工具暴露给 Agent它一个循环就能把生产数据改得面目全非。观测缺失大多数 Agent 项目早期根本没有 trace没有日志没有中间过程记录。出了错只能看到最终结果却看不见模型为什么做出这个决策、调了哪些工具、读了哪些记忆。黑盒状态下问题根本没法定位更别说修复。很多人把这些问题归结为“模型不够聪明”于是拼命换模型这属于典型的归因错误。工程纪律解决的不是模型的理解能力而是系统的可控性。换模型是在提升上限而纪律是在保证下限。没有下限的保障上限再高也守不住。1.3 分清 harness 与 Agent自由是有边界的在谈纪律之前有一个概念需要先厘清就是 harness套具/框架和 Agent 的区别。很多人在热词里搜“harness 和 agent 区别”实际上这两者是不同层级的东西。Agent 是那个做决策、调用工具的“大脑”harness 是大脑之外的控制层——负责对话循环、工具注册、权限校验、上下文组装、错误处理、重试策略、观测上报这些机制。说得直白一点Agent 负责“想”harness 负责“管”。如果你只有 Agent 没有 harness等于让一个极聪明的实习生完全没有规章制度地干活他当然能把活干得漂亮但也会把公司搞垮。反过来harness 设计得足够强Agent 的模型哪怕平庸一些也能在约束范围内稳定交付。我后来所有项目的核心改动都是把重心从“调模型”转移到“搭 harness”——从 agent 框架与编排层面去控制行为边界而不是寄希望于模型自己守规矩。2. 工程纪律的核心给 Agent 定四条铁律2.1 上下文纪律越短越稳越精简越强很多人对上下文管理有一个误区觉得 context 越大越好恨不得把整个知识库都塞进去。我在实践中得出一条反直觉的经验上下文越短Agent 越稳。模型在长上下文中的表现不是均匀的前段和末段的指令更容易被关注中间内容常常被“稀释”。这被称为 Lost in the Middle 现象。所以我现在对上下文采取严格的“分级装载”策略。第一系统提示词固定且精简只写角色定义、能力边界和三条最核心的铁律最多不超过两三百字第二用户对话和历史记录按需加载而不是全量重放最多留最近几轮关键对话第三领域知识走检索增强按查询命中后把最相关的片段拼进上下文而不是把整本文档放进去第四工具定义要精简只注册当前任务可能用到的工具别把全家桶都暴露给模型。举一个具体参数配置的例子。我此前为一个“数据分析 Agent”设计上下文时系统提示词里明确写了“你只能调用 read_csv、aggregate、plot 三个工具禁止执行写操作”工具描述压缩到一句话历史记录用滑动窗口保留最近 6 轮对话知识库检索用 top_k5每个片段 chunk_size512 token。这组配置上线后单次请求的 token 消耗下降了约 40%回答准确率反而提升了 20% 以上。上下文纪律的本质是帮模型把注意力集中在真正重要的事情上。2.2 记忆纪律可写、可查、可删还得会滤波Agent 记忆是提升连贯性的利器也是最容易养出“毒数据”的温床。之前我见过很多 Agent 实现会话结束后把所有内容一股脑写进向量库结果第二天检索出来的全是废话和错误结论。所以我对记忆系统定了三条硬性约束第一分级存储。短期记忆放在会话上下文里只保存最近几轮交互过期即丢长期记忆放进向量库或结构化 KV只存经过筛选的高价值信息——比如用户偏好、已确认的事实、关键决策节点。短期记忆负责“当下对话的连贯”长期记忆负责“跨会话的个性化”两者不混用。第二写入前校验。每一次记忆写入都要经过过滤器这一步我借用了“滑动窗口滤波模型”的思路——并不存所有历史而是存一段时间窗口内的精华信息同时对错误信息进行衰减处理。比如用户在某轮对话里提供了一个地址之后在下一轮又更正了这个地址那旧值就应该被新值覆盖而不是两条都存。常见的做法是给每条记忆打上 temporal score时间越久、得分越低冲突时高得分者胜出。第三可查可删。记忆系统必须提供访问审计和删除接口。用户说自己“不喜欢这个推荐”你得能精准定位到是哪条记忆导致的然后删掉它。如果记忆不可删Agent 就会一直带着用户的“旧标签”工作越用越别扭。记忆纪律的核心只有一个让 Agent 记住的每一条内容都在写入时经历质疑在引用时接受检验。2.3 工具纪律把工具当接口不当玩具Agent 能力再强最终都要通过工具落地。工具层面的纪律如果立不起来前面所有努力都会白费。我给团队定了四条工具底线权限最小化每个工具都要有明确的职责边界只暴露任务必需的最小能力集。比如一个工具可以读数据库但绝不应该同时拥有写权限一个工具可以发邮件但发送范围必须限定在公司白名单内。不要相信模型“不会乱来”要假设模型一定会乱来然后从机制上不让它乱来。参数强校验工具入口要做严格的 schema 校验和值域检查。以 JSON 工具调用为例工具入参必须符合预设 JSON Schema枚举值、正则模式、长度限制都要配齐。别把校验工作交给模型——模型生成的参数里充满了幻觉尤其日期、ID 这类精确值它经常编出一个不存在的数字。副作用隔离所有有副作用的工具写操作、外部请求、文件修改都要标记为 critical执行前需要二次确认或进入审核队列。我见过一个最惨痛的例子Agent 把测试环境的配置改到了生产环境因为它的工具列表里写环境参数用的是同一个字段名。从那以后所有危险工具一律加 environment 前缀并且在 harness 层做环境隔离检查。配额与超时每个工具调用都要有超时时间、重试策略和频次配额。一个工具如果 3 秒没返回就记录超时并给调用方返回可读的错误消息连续失败 3 次就熔断避免 Agent 陷入“调用-失败-再调用”的死循环。工具纪律的本质是把工具调用从“模型的自由发挥”变成“受控的接口调用”。自由度降低之后稳定性大幅提升。我的朋友问我这样会不会限制 Agent 的能力我的回答是限制的是它的闯祸半径不是它的能力边界。2.4 并发与安全纪律扛得住流量防得住攻击“AI Agent 怎么扛并发”是团队在从 Demo 走向生产时绕不开的坎。Agent 服务和普通 API 服务有一个本质区别它的单次请求可能耗时几十秒甚至几分钟期间会发起多个子任务调用。如果每一路请求都独占一个进程并发一高就会资源耗尽。我的做法是三层分流第一层用标准负载均衡按请求分发第二层为每个 Agent 实例维护一个内部任务队列控制同一时刻并行执行的子任务数这个值不要超过实例数的 2 倍否则模型服务的超时率会骤升第三层在模型 API 调用上做令牌桶限流比如配置每分钟 300 个补丁超过就直接 429 返回宁可让请求排队也不能打爆上游。并发控制的哲学只有一句话把不可控的并发流量转化为可控的队列压力。安全纪律同样重要。最近的热搜词里有“模型中毒攻击”这在 Agent 场景里不是危言耸听。Agent 的输入可能来自用户、可能来自网页检索结果、还可能来自工具返回数据攻击者可以把恶意指令藏在这些输入里诱导模型执行未授权的操作。典型对策有三层一是输入输出隔离把“指令内容”和“待处理数据”分开放进系统提示词的两段让模型明确区分二是工具权限 allowlist模型能调用的工具必须经过注册白名单杜绝自由解释空间三是审计日志每个工具调用都要记录 trace_id、调用者、参数摘要和结果出问题后能回溯到源头。Agent 安全的核心是全天候默认模型会犯傻、会中招、会被诱导而工程纪律能兜住这些风险。3. 实操记录把混乱 Agent 改造成受控 Agent3.1 改造前的问题清单与目标这一节我把一个真实项目拿出来做复盘。这个 Agent 是一个面向业务团队的“数据分析助手”最初架构非常简单一个模型 API 一个嵌入了所有工具定义的 system prompt 一个把所有历史记录全量拼接的轮次管理器。上线两周后它出现了以下症状现状问题风险等级表现上下文无限膨胀高每轮重放全部历史最长一次 prompt 超过 40K token记忆无过滤写入高错误结论进入长期记忆被反复引用工具权限过大高数据分析 Agent 拥有文件删除和数据写入权限无 trace 链路中出错后无法判断是模型幻觉、工具异常还是检索偏差无并发控制高同时 20 个会话就把模型服务的延迟拉高到 30 秒以上改造目标很明确让 Agent 在模型能力不变的前提下通过工程纪律把成功率从 60% 拉到 90% 以上同时把单次请求的平均 token 消耗降下来并让所有异常都可以被追踪和复现。3.2 关键落地动作与配置示例改造过程我拆成了五个动作每个动作都对应一条纪律动作一重写系统提示词。原提示词有 2000 多字里面塞满了产品介绍和历史背景。我压缩成三段式身份和任务一句话、能力清单只列 4 个工具的用途、红线禁止修改数据、禁止删除文件、遇到敏感操作必须向用户确认。所有冗余内容全部移入按需检索的知识库不再常驻上下文。动作二引入滑动窗口记忆滤波。会话历史按最近 6 轮对话截断更早的内容如果有关键决策信息则提炼成一条短摘要存入短期记忆段。长期记忆写入前经过一个 filter 函数伪代码大致是def filter_memory(candidate, state): # 只保留有事实价值或用户明确表达的偏好 if not candidate[is_fact] and not candidate[is_preference]: return None # 与已有记忆冲突时用时间得分高的覆盖 conflict find_conflict(candidate, state) if conflict and conflict[score] candidate[score]: return None return candidate这条 filter 帮我挡掉了大约 70% 的噪音写入。前两天还残留的错误结论在改造后自然衰减不再被检索出来。动作三工具瘦身与权限收口。工具从 12 个缩减到 4 个read_csv、aggregate、plot、confirm。其中 read_csv 只允许读取指定目录plot 只生成图表不上传写操作一律走 confirm 工具先给用户看预览再执行。每个工具都配了超时读操作 5 秒、聚合 10 秒、写操作 20 秒和调用频次限制。动作四加 trace 链路。每次会话生成一个 trace_id把模型输入输出、工具调用参数、返回结果、耗时、token 数全部记录到结构化日志里。这一步是后期排查问题的救星——以前查 bug 靠猜现在查 bug 靠搜 trace_id精确到模型在哪一步被误导、冲着哪个工具发了什么请求。动作五并发治理。在 Agent 服务主体和模型 API 之间加了一层令牌桶限流跑在服务进程内部同时在接入层做排队把瞬时并发超过上限的请求放进等待队列客户端收到明确的排队提示。具体配置是最大并发实例 16 个单实例内同时处理的子任务数不超过 3模型 API 并发限制为 40 QPS。3.3 改造后的效果与关键经验改造上线后跑了一个月我拉了几组数据做对比指标改造前改造后任务成功率用户可接受结果占比61%89%单次请求平均 token 消耗约 18K约 9.5K平均响应时延24 秒12 秒问题可定位率不到 30%接近 100%这组数据证明了一个结论Agent 的系统性收益很大一部分不来自模型升级而来自工程纪律的完善。整个改造没有换任何模型纯粹是围绕上下文、记忆、工具、观测和并发做了治理。经验上最值得提的一条治理 Agent 要按系统治理的思路做而不是按提示词工程做——把 Agent 当成一个生产系统来看该有的生命周期管理、权限管理、可观测性、限流降级一项都不能少。你可以在 agent 开发学习路线里看到框架、模型、评测这些内容但真正让 Agent 在生产环境站稳脚跟的往往就是这些容易被忽略的“非模型”部分。4. 常见问题与排查技巧实录4.1 症状Agent 越用越笨输出质量断崖式下跌这是最常见也最让人沮丧的情况。排查思路要按下面的顺序来先看上下文是否过长再看记忆是否被污染最后才怀疑模型本身。我见过 90% 的“越来越笨”都是前两个原因。一个实用的排查技巧是打开 trace把用户的原始输入、过去几轮的对话和模型引用过的记忆全部拉出来人工读一遍。你会发现要么系统提示词被工具返回结果挤出了注意力区间要么某条错误记忆成了模型的“权威参考”。修复方式也不难——裁剪上下文窗口清理记忆库把关键指令固化到系统提示词的第一段。如果做完这些模型输出质量仍在下降再考虑调模型温度参数或切换模型。4.2 症状Agent 绕圈子同一个操作反复执行Agent 陷入循环是一个高频故障。典型表现是模型不断调用同一个工具、拿到相同结果、然后又调用一次。原因通常是缺少“终止条件”——Agent 不知道自己已经完成了任务或者工具返回值不够明确让它误解为还需要继续。对策有三层。第一给每个工具增加 completes 标记在工具返回值末尾附上一句“任务已完成请停止后续操作”之类的显式信号这类指令比隐式判断可靠得多第二在 harness 层做循环检测比如检测到同一个工具、同样的参数连续调用超过 3 次就强制中断并通知用户确认第三设置全局步数上限单次任务最多允许 15 步工具调用超过默认判定失败。实际的 Agent 框架都支持这类断路器很多时候是没启用。4.3 症状并发一高Agent 直接崩溃或大量超时这个问题在将 Agent 接入生产时几乎必然遇到。表象是模型 API 返回 429 或超时深层原因是 Agent 服务没有做并发控制和上游保护。排查时先看 QPS 和超时分布如果 429 很多说明限流没生效如果超时集中在某个工具调用上说明那个工具的时延抖动是整个系统的瓶颈。我建议的加固顺序是先做接入层排队和队列长度限制再给每个 Agent 实例加子任务并发上限最后在模型 API 客户端上做令牌桶。同时要在工具和服务之间加超时熔断一个慢工具绝不能拖垮整条调用链。你在网上搜“AI Agent 怎么扛并发”答案翻来覆去其实就是这几招难在真正把它当成必做项而不是可选项。4.4 症状Agent 被“带偏”输出不该输出的内容当 Agent 的行为突然变得不像它自己比如开始用用户的话攻击系统规则、尝试越权调用工具、或者引用一段从未出现在合法输入里的指令基本可以判断是受到了提示注入攻击也就是常说的模型中毒攻击。攻击载体通常是用户输入、网页抓取内容或工具返回数据被直接拼接进了 prompt。应急处理三步走。第一步隔离输入输出把外部数据统一封装成“数据块”并用清晰的边界标签包裹让模型知道“这段内容仅供参考不是指示”第二步开启工具调用审核对危险操作一律要求人工确认第三步翻 trace 日志找攻击源头定位是哪条输入触发了异常行为然后将该输入来源拉黑。安全纪律的核心假设是模型一定会被诱导所以机制上要让它“诱导了也做不了坏事”。4.5 一个容易被忽略的小细节模型切换后的失忆最后分享一个很隐蔽的坑。很多团队会在不同阶段切换不同的模型比如从闭源大模型切到本地微调模型。切换后 Agent 经常出现“行为风格突变”或“忘记指令”的现象不少人的第一反应是新模型不行。实际上问题常出在记忆和上下文配置上——不同模型对提示词格式的敏感度不一样上一套模型的记忆清洗规则在新的 tokenizer 下可能失效。所以在模型切换时不要只换基础 URL 和 API Key还应该重新验证三件事提示词格式是否被新模型完整理解、记忆库的检索阈值是否需要重新调优、工具调用格式比如 function calling schema是否兼容。这个细节我在拿 Codex 模型和本地模型做对比测试时踩过好几次。说实话我见过太多 Agent 项目死在了“模型焦虑”上——总是觉得只要上游再给我一个更强的模型现在的问题就迎刃而解。但真实世界的工程里没有哪一个稳定系统是单靠核心部件撑起来的。Agent 也是一样它的可靠性来自你愿意花多少心思去立纪律、做治理、补观测。从一开始就把工程纪律纳入系统设计比事后追着模型换版本要省心得多。最后分享一个小经验每次迭代完给自己的 Agent 出一份“行为契约”写清楚它该做什么、不该做什么、出了错谁负责。光这一个小习惯就能帮你挡掉一半以上的隐性问题。