1. 从能跑到扛造Agent 系统在 2026 上半年到底变了什么如果你在 2024 年搭过一个能调用工具的 Agent大概率经历过这样的阶段Demo 跑通那一刻很兴奋接上真实业务之后三天两头翻车。到了 2026 年上半年这个领域最明显的变化不是模型又强了多少而是围绕 Agent 的工程层——也就是 harness——开始真正成熟了。我自己的几个项目从去年底到今年上半年做了一轮比较大的重构踩了不少坑也总结出一些能直接复用的东西这篇就当作一次阶段性的技术复盘。先把话说清楚这里讲的 Agent 系统指的是以大模型为决策核心、能自主调用工具、维护上下文、跨轮次保持记忆的软件系统。它可能是你写的一个自动化脚本也可能是一个跑在服务器上、每天处理上千次请求的服务。而 harness简单理解就是套在模型外面的那层工程骨架——它负责把用户输入、历史上下文、工具定义、记忆检索结果组装成模型能吃的 prompt再把模型吐出来的东西解析成实际动作执行、回填、循环。很多人把 harness 和 Agent 混为一谈其实 Agent 是智能体这个概念本身harness 是让它稳定运转的那套管道和脚手架。为什么 2026 上半年值得单独拿出来说因为这一年里几个关键问题终于有了相对靠谱的工程答案上下文怎么管才不爆、记忆怎么存才不串、工具循环怎么跑才不死、并发怎么扛才不崩。这些问题在 2024 年基本靠调 prompt 玄学到 2026 年已经变成了一套有章可循的工程实践。下面我按自己实际重构的顺序一块一块拆开讲。提示本文所有方案都基于我实际项目中的取舍不同业务场景下参数需要自己调。凡是涉及具体数值的地方我都会说明推导逻辑你照着改就行。2. 上下文管理从塞满窗口到分层装配2.1 为什么把历史全塞进去必然失败早期最省事的做法是把所有对话历史拼成一个长字符串丢给模型。这个做法在小规模下没问题但一旦对话轮次超过二三十轮就会遇到三个硬伤。第一是成本。上下文长度直接决定 token 消耗一个 128K 窗口的请求如果每轮都全量重发成本会随轮次线性甚至超线性增长。我实测过一个客服场景全量重发到第 40 轮时单次请求的输入 token 是首轮的 15 倍以上账单直接失控。第二是注意力稀释。模型对长上下文的利用效率并不是均匀的中间部分的信息容易被忽略这在业界被称为lost in the middle现象。你把关键的工具返回结果塞在第 50 条消息里模型很可能根本没注意到。第三是状态污染。历史里如果有过期的工具返回、失败的重试记录、用户中途改口的需求全塞进去会让模型在矛盾信息里做决策输出变得不稳定。所以 2026 年上半年我在上下文管理上做的核心改变是从扁平拼接转向分层装配。2.2 分层装配的具体结构我把每次请求的上下文拆成五个层次按优先级从高到低装配层级内容是否常驻典型 token 占比系统层角色定义、能力边界、输出格式约束常驻10%任务层当前任务目标、验收标准常驻10%记忆层检索出的相关长期记忆动态20%工作层最近 N 轮的对话与工具调用滑动窗口40%即时层本轮用户输入 最新工具返回常驻20%这个比例不是拍脑袋定的而是根据模型的实际表现调的。系统层和任务层必须常驻因为它们定义了我是谁、要干什么一旦被挤掉Agent 就会跑偏。记忆层是动态检索的只放和当前任务相关的片段。工作层用滑动窗口只保留最近若干轮更早的内容要么被压缩成摘要要么进入长期记忆。即时层永远放在最靠近模型输出的位置因为这里的注意力权重最高。装配顺序也有讲究把最稳定的放前面最易变的放后面。这样做的好处是前面部分的内容可以命中 prompt 缓存大幅降低重复计算成本。我实测下来把系统层和任务层固定住之后缓存命中率能到 70% 以上响应延迟明显下降。2.3 滑动窗口的裁剪策略工作层的滑动窗口不是简单地保留最近 10 轮那样会丢掉关键信息。我用的是带锚点的裁剪锚点一任务开始时的原始需求永远保留。锚点二最近一次成功的工具调用及其结果保留。锚点三用户最近一次明确纠正或补充的指令保留。其余中间轮次按时间倒序填充直到达到窗口上限。这样做的逻辑是Agent 最需要知道的是最初要干什么现在进展到哪用户最新说了什么中间的探索过程可以丢。我试过纯时间窗口和带锚点窗口的对比在同一个多步任务上带锚点的方案任务完成率高出约 25%因为模型不会忘记原始目标。2.4 上下文压缩的时机与方式当滑动窗口里的内容还是太多时就需要压缩。压缩的时机很关键不要等到快爆窗口才压而是在窗口使用率达到 70% 左右就开始。因为压缩本身也要消耗一次模型调用如果等到 95% 才压可能连压缩请求都塞不进去。压缩方式我试过三种摘要式让模型把旧对话总结成一段话。优点是信息密度高缺点是可能丢细节。结构化提取把旧对话里的关键实体、决策、待办提取成 JSON。优点是精确缺点是提取规则要维护。混合式先结构化提取再对提取不出来的部分做摘要。实测下来混合式最稳。纯摘要容易把用户说不要用某个方案这种否定信息丢掉纯结构化又覆盖不全。混合式相当于双保险。注意压缩后的内容一定要标注时间戳和来源否则模型会把压缩摘要当成当前事实导致用过期信息做决策。我在摘要前面统一加了[历史摘要截至第 N 轮]这样的前缀效果立竿见影。3. 记忆系统短期、长期与双网络的取舍3.1 短期记忆和长期记忆的边界在哪很多人一上来就问记忆库选哪个其实更该先问的是哪些东西该进长期记忆。我的判断标准很简单跨会话还需要用到的才进长期记忆当前会话内用完就废的留在短期记忆。短期记忆就是上面说的上下文工作层生命周期是单次会话。长期记忆是持久化的跨会话可检索。两者的边界如果划不清会出现两种典型故障一是把临时状态写进长期记忆导致下次会话被污染二是该记住的用户偏好没记住每次都要重新问。我踩过最典型的一个坑早期把工具调用的中间结果也写进了长期记忆结果下次会话检索时把上次的临时数据当成了当前事实Agent 直接给出了错误答案。后来我加了一条规则——只有经过确认的、稳定的信息才写入长期记忆比如用户明确表达的偏好、确认过的事实、固定的业务流程。3.2 双网络记忆模型的实践2026 年上半年我重点实践的是双网络记忆模型这个思路在社区里讨论得比较多。核心是把记忆分成两个网络事实网络存储结构化的事实、实体、关系。查询方式是精确匹配或图遍历。经验网络存储非结构化的经验、案例、对话片段。查询方式是向量相似度检索。为什么要分两个网络因为这两类信息的检索需求完全不同。事实查询要的是准确比如用户的订单号是多少向量检索可能返回一堆语义相似但数字不对的结果。经验查询要的是相关比如上次遇到类似问题是怎么解决的这时候向量检索就比精确匹配好用。我的实现里事实网络用关系型数据库加索引经验网络用向量库。每次检索时先判断当前需要的是事实还是经验再走对应的网络。判断逻辑可以交给模型也可以用规则——比如输入里包含明确的实体名或 ID就走事实网络。3.3 记忆写入的去重与冲突处理记忆写多了会重复重复会导致检索时返回一堆相似内容浪费上下文。我的做法是写入前先做相似度检查如果新记忆和已有记忆的相似度超过阈值我用的 0.92就不新增而是更新已有记忆的时间戳和置信度。冲突处理更麻烦。比如用户上次说我喜欢简洁的回答这次说请详细解释这两条记忆是冲突的。我的处理方式是保留两条但给新的更高的权重和更新的时间戳检索时按时间衰减排序。这样既不会丢掉历史偏好又能让最新意图优先。场景处理方式理由完全重复更新时间戳不新增避免冗余语义相似但细节不同合并保留差异字段信息互补直接冲突都保留新记忆权重更高尊重最新意图过期事实标记失效不删除保留审计线索3.4 记忆检索的排序策略检索出记忆之后排序决定了哪些能进上下文。我用的是多因子加权排序语义相似度权重 0.4时间新鲜度权重 0.3历史命中率权重 0.2置信度权重 0.1历史命中率这个因子容易被忽略但很有用如果某条记忆在过去被检索出来后任务成功完成了说明它质量高下次应该优先。这个反馈信号需要你在任务结束时回写形成闭环。4. 工具循环让 Agent 不死循环、不空转4.1 工具循环的本质是一个状态机Agent 调用工具的过程本质是一个思考—行动—观察的循环。模型输出一个工具调用请求harness 执行工具把结果回填模型再决定下一步。这个循环如果没有边界就会出现两种病死循环反复调用同一个工具和空转一直思考不行动。2026 年上半年我在这一块最大的改变是把工具循环显式建模成状态机而不是靠模型自觉。状态机里有几个关键状态初始化、规划中、执行中、等待确认、完成、失败。每个状态有明确的进入条件和退出条件模型只能在状态允许的范围内行动。4.2 循环终止条件的设置终止条件必须有多重保险我一般设四道最大轮次硬性上限比如 15 轮。超过就强制结束并返回当前最佳结果。重复检测如果连续两轮调用了同一个工具且参数相同判定为死循环中断。无进展检测如果连续三轮没有产生新的有效信息比如工具返回都是空或错误中断。目标达成检测模型显式声明任务完成或输出符合验收标准的最终答案。这四道里无进展检测最容易被忽略但最有用。我遇到过 Agent 反复调用搜索工具每次返回都差不多但模型就是不肯下结论。加了无进展检测后这种情况基本消失。4.3 工具返回结果的清洗工具返回的原始数据往往很脏HTML 标签、超长 JSON、无关字段。直接塞给模型既浪费 token 又干扰判断。我在 harness 里加了一层结果清洗管道去掉 HTML 标签和多余空白对超长结果做截断保留头尾和关键字段提取结构化字段转成紧凑格式标注结果的类型和来源这一步看起来不起眼但对稳定性影响很大。我实测过清洗后的工具结果能让模型的下一步决策准确率提升约 15%因为干扰信息少了。4.4 工具调用的并发与串行判断有些工具调用可以并发有些必须串行。判断标准是是否存在数据依赖如果工具 B 的输入依赖工具 A 的输出就必须串行如果两个工具互不依赖可以并发。并发能显著降低延迟但要注意两点一是并发结果回填时要有明确的标识否则模型分不清哪个结果对应哪个调用二是并发数量要有上限我一般限制在 5 个以内太多会导致结果混乱和资源争抢。提示并发工具调用时一定要给每个调用分配唯一 ID回填结果时带上 ID。我早期没做这个模型经常把 A 的结果当成 B 的排查了很久才发现是回填错位。5. 并发与稳定性Agent 服务化的硬骨头5.1 单机 Agent 和服务化 Agent 的区别单机跑 Agent你只需要关心逻辑对不对。服务化之后你要关心的是多个请求同时进来怎么办、某个请求卡住了怎么办、模型接口限流了怎么办、工具执行超时了怎么办。这些问题在 2026 年上半年我做的服务化改造里全部遇到了。核心思路是把 Agent 的每个环节都做成可超时、可重试、可降级的。模型调用要设超时工具执行要设超时整个任务也要设总超时。任何一层超时都要有明确的降级策略而不是直接报错。5.2 请求隔离与资源配额多个请求共享同一套 harness 时必须做隔离。我的做法是每个请求分配独立的上下文空间和记忆会话 ID避免串号。同时给每个请求设资源配额最大 token 消耗、最大工具调用次数、最大执行时长。超过配额就优雅终止返回部分结果。资源配额的意义在于防止单个请求拖垮整个服务。我遇到过恶意构造的超长任务如果不设配额一个请求就能把模型接口的额度耗光影响其他所有用户。5.3 限流与重试的配合模型接口和外部工具接口都可能限流。我的策略是指数退避重试 令牌桶限流令牌桶控制整体请求速率避免突发流量打爆下游。指数退避处理偶发的限流错误第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 3 次。重试时要区分错误类型限流错误可以重试参数错误重试也没用直接失败。这里有个细节重试的请求要复用之前的上下文而不是从头开始。否则重试一次就多消耗一次完整上下文成本翻倍。5.4 可观测性没有日志就没有稳定性Agent 系统最怕的是黑盒。出了问题你不知道是哪一步错了。我在 harness 里加了全链路日志记录每个环节的输入、输出、耗时、token 消耗。关键节点包括上下文装配、模型调用、工具执行、记忆读写、结果回填。日志要结构化方便查询和统计。我用的是 JSON 格式每条日志带 trace ID可以串起一个完整请求的所有环节。有了这个排查问题从猜变成了看。监控指标含义告警阈值建议单请求 token 消耗成本控制超过预算 80%工具调用失败率稳定性超过 10%平均循环轮次效率超过 10 轮任务完成率效果低于 85%P99 响应延迟体验超过 30 秒6. 踩坑实录那些文档里不会写的教训6.1 记忆串号一个会话 ID 引发的血案最惨的一次事故是记忆串号。两个用户的会话 ID 因为生成逻辑有 bug撞到了一起结果 A 用户看到了 B 用户的记忆内容。这个问题排查了两天才定位到因为表面现象是Agent 偶尔答非所问很难联想到是 ID 冲突。教训是会话 ID 必须用足够随机的生成方式并且加用户维度做前缀。我后来改成 UUID 加用户 ID 哈希再也没出过问题。另外记忆读写时一定要校验会话 ID 和用户 ID 是否匹配不匹配直接拒绝。6.2 工具超时导致的上下文污染工具有一次超时了harness 把超时错误信息回填给了模型。模型看到错误后自己编了一个工具返回结果继续往下走最后给出了完全错误的答案。这个问题的根源是错误信息没有明确标注为错误模型把它当成了正常结果。修复方式是工具返回错误时回填内容必须带明确的错误标记并且告诉模型这个工具失败了你可以选择重试或换方案。同时harness 层面要记录失败如果同一工具连续失败直接中断循环。6.3 上下文压缩把关键约束压没了有一次压缩上下文时把用户说的不要用外部 API这条约束压没了。结果 Agent 调用了外部 API违反了合规要求。这个问题很隐蔽因为压缩后的对话看起来很正常只是少了一条约束。后来我加了一条规则压缩前先提取所有否定性约束和硬性要求单独存成一个约束清单永远常驻上下文。这个清单不参与压缩确保关键约束不丢。6.4 并发下的记忆写冲突多个请求同时写同一条记忆时会出现覆盖。比如两个请求同时更新用户的偏好后写的把先写的覆盖了。这个问题在低并发下不明显高并发下必现。解决方案是记忆写入加乐观锁写入时带上版本号版本号不匹配就重试。或者用队列串行化同一用户的记忆写入。我选的是后者因为实现简单而且同一用户的写入本来就不需要高并发。7. 我对 2026 下半年的一点判断从上半年的实践看Agent 系统的竞争已经从模型能力转向了工程能力。同样的模型harness 做得好不好效果能差出一倍。下半年我比较关注几个方向一是记忆系统的自动化治理比如自动识别过期记忆、自动合并冲突二是工具生态的标准化现在每个 Agent 框架的工具定义都不一样迁移成本很高三是成本优化尤其是上下文缓存和记忆检索的缓存复用。如果你现在正在搭 Agent 系统我的建议是先把 harness 的骨架搭稳再谈模型选型。上下文管理、记忆系统、工具循环、并发控制这四块每一块都值得单独花时间打磨。我见过太多项目在模型上反复折腾最后发现瓶颈其实在工程层。最后分享一个我一直在用的小技巧给 Agent 加一个自检环节。在输出最终答案前让模型自己检查一遍是否满足了所有约束、是否用了过期信息、是否有未完成的步骤。这个环节增加了一次模型调用但能拦下相当一部分低级错误性价比很高。 
长河君 · 2026/10/28 8:35:02 · 阅读 1.2k Agent系统harness工程实践：上下文管理、记忆系统与工具循环的稳定性设计
1. 从能跑到扛造Agent 系统在 2026 上半年到底变了什么如果你在 2024 年搭过一个能调用工具的 Agent大概率经历过这样的阶段Demo 跑通那一刻很兴奋接上真实业务之后三天两头翻车。到了 2026 年上半年这个领域最明显的变化不是模型又强了多少而是围绕 Agent 的工程层——也就是 harness——开始真正成熟了。我自己的几个项目从去年底到今年上半年做了一轮比较大的重构踩了不少坑也总结出一些能直接复用的东西这篇就当作一次阶段性的技术复盘。先把话说清楚这里讲的 Agent 系统指的是以大模型为决策核心、能自主调用工具、维护上下文、跨轮次保持记忆的软件系统。它可能是你写的一个自动化脚本也可能是一个跑在服务器上、每天处理上千次请求的服务。而 harness简单理解就是套在模型外面的那层工程骨架——它负责把用户输入、历史上下文、工具定义、记忆检索结果组装成模型能吃的 prompt再把模型吐出来的东西解析成实际动作执行、回填、循环。很多人把 harness 和 Agent 混为一谈其实 Agent 是智能体这个概念本身harness 是让它稳定运转的那套管道和脚手架。为什么 2026 上半年值得单独拿出来说因为这一年里几个关键问题终于有了相对靠谱的工程答案上下文怎么管才不爆、记忆怎么存才不串、工具循环怎么跑才不死、并发怎么扛才不崩。这些问题在 2024 年基本靠调 prompt 玄学到 2026 年已经变成了一套有章可循的工程实践。下面我按自己实际重构的顺序一块一块拆开讲。提示本文所有方案都基于我实际项目中的取舍不同业务场景下参数需要自己调。凡是涉及具体数值的地方我都会说明推导逻辑你照着改就行。2. 上下文管理从塞满窗口到分层装配2.1 为什么把历史全塞进去必然失败早期最省事的做法是把所有对话历史拼成一个长字符串丢给模型。这个做法在小规模下没问题但一旦对话轮次超过二三十轮就会遇到三个硬伤。第一是成本。上下文长度直接决定 token 消耗一个 128K 窗口的请求如果每轮都全量重发成本会随轮次线性甚至超线性增长。我实测过一个客服场景全量重发到第 40 轮时单次请求的输入 token 是首轮的 15 倍以上账单直接失控。第二是注意力稀释。模型对长上下文的利用效率并不是均匀的中间部分的信息容易被忽略这在业界被称为lost in the middle现象。你把关键的工具返回结果塞在第 50 条消息里模型很可能根本没注意到。第三是状态污染。历史里如果有过期的工具返回、失败的重试记录、用户中途改口的需求全塞进去会让模型在矛盾信息里做决策输出变得不稳定。所以 2026 年上半年我在上下文管理上做的核心改变是从扁平拼接转向分层装配。2.2 分层装配的具体结构我把每次请求的上下文拆成五个层次按优先级从高到低装配层级内容是否常驻典型 token 占比系统层角色定义、能力边界、输出格式约束常驻10%任务层当前任务目标、验收标准常驻10%记忆层检索出的相关长期记忆动态20%工作层最近 N 轮的对话与工具调用滑动窗口40%即时层本轮用户输入 最新工具返回常驻20%这个比例不是拍脑袋定的而是根据模型的实际表现调的。系统层和任务层必须常驻因为它们定义了我是谁、要干什么一旦被挤掉Agent 就会跑偏。记忆层是动态检索的只放和当前任务相关的片段。工作层用滑动窗口只保留最近若干轮更早的内容要么被压缩成摘要要么进入长期记忆。即时层永远放在最靠近模型输出的位置因为这里的注意力权重最高。装配顺序也有讲究把最稳定的放前面最易变的放后面。这样做的好处是前面部分的内容可以命中 prompt 缓存大幅降低重复计算成本。我实测下来把系统层和任务层固定住之后缓存命中率能到 70% 以上响应延迟明显下降。2.3 滑动窗口的裁剪策略工作层的滑动窗口不是简单地保留最近 10 轮那样会丢掉关键信息。我用的是带锚点的裁剪锚点一任务开始时的原始需求永远保留。锚点二最近一次成功的工具调用及其结果保留。锚点三用户最近一次明确纠正或补充的指令保留。其余中间轮次按时间倒序填充直到达到窗口上限。这样做的逻辑是Agent 最需要知道的是最初要干什么现在进展到哪用户最新说了什么中间的探索过程可以丢。我试过纯时间窗口和带锚点窗口的对比在同一个多步任务上带锚点的方案任务完成率高出约 25%因为模型不会忘记原始目标。2.4 上下文压缩的时机与方式当滑动窗口里的内容还是太多时就需要压缩。压缩的时机很关键不要等到快爆窗口才压而是在窗口使用率达到 70% 左右就开始。因为压缩本身也要消耗一次模型调用如果等到 95% 才压可能连压缩请求都塞不进去。压缩方式我试过三种摘要式让模型把旧对话总结成一段话。优点是信息密度高缺点是可能丢细节。结构化提取把旧对话里的关键实体、决策、待办提取成 JSON。优点是精确缺点是提取规则要维护。混合式先结构化提取再对提取不出来的部分做摘要。实测下来混合式最稳。纯摘要容易把用户说不要用某个方案这种否定信息丢掉纯结构化又覆盖不全。混合式相当于双保险。注意压缩后的内容一定要标注时间戳和来源否则模型会把压缩摘要当成当前事实导致用过期信息做决策。我在摘要前面统一加了[历史摘要截至第 N 轮]这样的前缀效果立竿见影。3. 记忆系统短期、长期与双网络的取舍3.1 短期记忆和长期记忆的边界在哪很多人一上来就问记忆库选哪个其实更该先问的是哪些东西该进长期记忆。我的判断标准很简单跨会话还需要用到的才进长期记忆当前会话内用完就废的留在短期记忆。短期记忆就是上面说的上下文工作层生命周期是单次会话。长期记忆是持久化的跨会话可检索。两者的边界如果划不清会出现两种典型故障一是把临时状态写进长期记忆导致下次会话被污染二是该记住的用户偏好没记住每次都要重新问。我踩过最典型的一个坑早期把工具调用的中间结果也写进了长期记忆结果下次会话检索时把上次的临时数据当成了当前事实Agent 直接给出了错误答案。后来我加了一条规则——只有经过确认的、稳定的信息才写入长期记忆比如用户明确表达的偏好、确认过的事实、固定的业务流程。3.2 双网络记忆模型的实践2026 年上半年我重点实践的是双网络记忆模型这个思路在社区里讨论得比较多。核心是把记忆分成两个网络事实网络存储结构化的事实、实体、关系。查询方式是精确匹配或图遍历。经验网络存储非结构化的经验、案例、对话片段。查询方式是向量相似度检索。为什么要分两个网络因为这两类信息的检索需求完全不同。事实查询要的是准确比如用户的订单号是多少向量检索可能返回一堆语义相似但数字不对的结果。经验查询要的是相关比如上次遇到类似问题是怎么解决的这时候向量检索就比精确匹配好用。我的实现里事实网络用关系型数据库加索引经验网络用向量库。每次检索时先判断当前需要的是事实还是经验再走对应的网络。判断逻辑可以交给模型也可以用规则——比如输入里包含明确的实体名或 ID就走事实网络。3.3 记忆写入的去重与冲突处理记忆写多了会重复重复会导致检索时返回一堆相似内容浪费上下文。我的做法是写入前先做相似度检查如果新记忆和已有记忆的相似度超过阈值我用的 0.92就不新增而是更新已有记忆的时间戳和置信度。冲突处理更麻烦。比如用户上次说我喜欢简洁的回答这次说请详细解释这两条记忆是冲突的。我的处理方式是保留两条但给新的更高的权重和更新的时间戳检索时按时间衰减排序。这样既不会丢掉历史偏好又能让最新意图优先。场景处理方式理由完全重复更新时间戳不新增避免冗余语义相似但细节不同合并保留差异字段信息互补直接冲突都保留新记忆权重更高尊重最新意图过期事实标记失效不删除保留审计线索3.4 记忆检索的排序策略检索出记忆之后排序决定了哪些能进上下文。我用的是多因子加权排序语义相似度权重 0.4时间新鲜度权重 0.3历史命中率权重 0.2置信度权重 0.1历史命中率这个因子容易被忽略但很有用如果某条记忆在过去被检索出来后任务成功完成了说明它质量高下次应该优先。这个反馈信号需要你在任务结束时回写形成闭环。4. 工具循环让 Agent 不死循环、不空转4.1 工具循环的本质是一个状态机Agent 调用工具的过程本质是一个思考—行动—观察的循环。模型输出一个工具调用请求harness 执行工具把结果回填模型再决定下一步。这个循环如果没有边界就会出现两种病死循环反复调用同一个工具和空转一直思考不行动。2026 年上半年我在这一块最大的改变是把工具循环显式建模成状态机而不是靠模型自觉。状态机里有几个关键状态初始化、规划中、执行中、等待确认、完成、失败。每个状态有明确的进入条件和退出条件模型只能在状态允许的范围内行动。4.2 循环终止条件的设置终止条件必须有多重保险我一般设四道最大轮次硬性上限比如 15 轮。超过就强制结束并返回当前最佳结果。重复检测如果连续两轮调用了同一个工具且参数相同判定为死循环中断。无进展检测如果连续三轮没有产生新的有效信息比如工具返回都是空或错误中断。目标达成检测模型显式声明任务完成或输出符合验收标准的最终答案。这四道里无进展检测最容易被忽略但最有用。我遇到过 Agent 反复调用搜索工具每次返回都差不多但模型就是不肯下结论。加了无进展检测后这种情况基本消失。4.3 工具返回结果的清洗工具返回的原始数据往往很脏HTML 标签、超长 JSON、无关字段。直接塞给模型既浪费 token 又干扰判断。我在 harness 里加了一层结果清洗管道去掉 HTML 标签和多余空白对超长结果做截断保留头尾和关键字段提取结构化字段转成紧凑格式标注结果的类型和来源这一步看起来不起眼但对稳定性影响很大。我实测过清洗后的工具结果能让模型的下一步决策准确率提升约 15%因为干扰信息少了。4.4 工具调用的并发与串行判断有些工具调用可以并发有些必须串行。判断标准是是否存在数据依赖如果工具 B 的输入依赖工具 A 的输出就必须串行如果两个工具互不依赖可以并发。并发能显著降低延迟但要注意两点一是并发结果回填时要有明确的标识否则模型分不清哪个结果对应哪个调用二是并发数量要有上限我一般限制在 5 个以内太多会导致结果混乱和资源争抢。提示并发工具调用时一定要给每个调用分配唯一 ID回填结果时带上 ID。我早期没做这个模型经常把 A 的结果当成 B 的排查了很久才发现是回填错位。5. 并发与稳定性Agent 服务化的硬骨头5.1 单机 Agent 和服务化 Agent 的区别单机跑 Agent你只需要关心逻辑对不对。服务化之后你要关心的是多个请求同时进来怎么办、某个请求卡住了怎么办、模型接口限流了怎么办、工具执行超时了怎么办。这些问题在 2026 年上半年我做的服务化改造里全部遇到了。核心思路是把 Agent 的每个环节都做成可超时、可重试、可降级的。模型调用要设超时工具执行要设超时整个任务也要设总超时。任何一层超时都要有明确的降级策略而不是直接报错。5.2 请求隔离与资源配额多个请求共享同一套 harness 时必须做隔离。我的做法是每个请求分配独立的上下文空间和记忆会话 ID避免串号。同时给每个请求设资源配额最大 token 消耗、最大工具调用次数、最大执行时长。超过配额就优雅终止返回部分结果。资源配额的意义在于防止单个请求拖垮整个服务。我遇到过恶意构造的超长任务如果不设配额一个请求就能把模型接口的额度耗光影响其他所有用户。5.3 限流与重试的配合模型接口和外部工具接口都可能限流。我的策略是指数退避重试 令牌桶限流令牌桶控制整体请求速率避免突发流量打爆下游。指数退避处理偶发的限流错误第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 3 次。重试时要区分错误类型限流错误可以重试参数错误重试也没用直接失败。这里有个细节重试的请求要复用之前的上下文而不是从头开始。否则重试一次就多消耗一次完整上下文成本翻倍。5.4 可观测性没有日志就没有稳定性Agent 系统最怕的是黑盒。出了问题你不知道是哪一步错了。我在 harness 里加了全链路日志记录每个环节的输入、输出、耗时、token 消耗。关键节点包括上下文装配、模型调用、工具执行、记忆读写、结果回填。日志要结构化方便查询和统计。我用的是 JSON 格式每条日志带 trace ID可以串起一个完整请求的所有环节。有了这个排查问题从猜变成了看。监控指标含义告警阈值建议单请求 token 消耗成本控制超过预算 80%工具调用失败率稳定性超过 10%平均循环轮次效率超过 10 轮任务完成率效果低于 85%P99 响应延迟体验超过 30 秒6. 踩坑实录那些文档里不会写的教训6.1 记忆串号一个会话 ID 引发的血案最惨的一次事故是记忆串号。两个用户的会话 ID 因为生成逻辑有 bug撞到了一起结果 A 用户看到了 B 用户的记忆内容。这个问题排查了两天才定位到因为表面现象是Agent 偶尔答非所问很难联想到是 ID 冲突。教训是会话 ID 必须用足够随机的生成方式并且加用户维度做前缀。我后来改成 UUID 加用户 ID 哈希再也没出过问题。另外记忆读写时一定要校验会话 ID 和用户 ID 是否匹配不匹配直接拒绝。6.2 工具超时导致的上下文污染工具有一次超时了harness 把超时错误信息回填给了模型。模型看到错误后自己编了一个工具返回结果继续往下走最后给出了完全错误的答案。这个问题的根源是错误信息没有明确标注为错误模型把它当成了正常结果。修复方式是工具返回错误时回填内容必须带明确的错误标记并且告诉模型这个工具失败了你可以选择重试或换方案。同时harness 层面要记录失败如果同一工具连续失败直接中断循环。6.3 上下文压缩把关键约束压没了有一次压缩上下文时把用户说的不要用外部 API这条约束压没了。结果 Agent 调用了外部 API违反了合规要求。这个问题很隐蔽因为压缩后的对话看起来很正常只是少了一条约束。后来我加了一条规则压缩前先提取所有否定性约束和硬性要求单独存成一个约束清单永远常驻上下文。这个清单不参与压缩确保关键约束不丢。6.4 并发下的记忆写冲突多个请求同时写同一条记忆时会出现覆盖。比如两个请求同时更新用户的偏好后写的把先写的覆盖了。这个问题在低并发下不明显高并发下必现。解决方案是记忆写入加乐观锁写入时带上版本号版本号不匹配就重试。或者用队列串行化同一用户的记忆写入。我选的是后者因为实现简单而且同一用户的写入本来就不需要高并发。7. 我对 2026 下半年的一点判断从上半年的实践看Agent 系统的竞争已经从模型能力转向了工程能力。同样的模型harness 做得好不好效果能差出一倍。下半年我比较关注几个方向一是记忆系统的自动化治理比如自动识别过期记忆、自动合并冲突二是工具生态的标准化现在每个 Agent 框架的工具定义都不一样迁移成本很高三是成本优化尤其是上下文缓存和记忆检索的缓存复用。如果你现在正在搭 Agent 系统我的建议是先把 harness 的骨架搭稳再谈模型选型。上下文管理、记忆系统、工具循环、并发控制这四块每一块都值得单独花时间打磨。我见过太多项目在模型上反复折腾最后发现瓶颈其实在工程层。最后分享一个我一直在用的小技巧给 Agent 加一个自检环节。在输出最终答案前让模型自己检查一遍是否满足了所有约束、是否用了过期信息、是否有未完成的步骤。这个环节增加了一次模型调用但能拦下相当一部分低级错误性价比很高。