第一次被 Agent 折腾到半夜是看到一个非常熟悉的报错the agent execution provider did not respond in time。翻译成人话就是不知道什么原因Agent 在执行过程中没有在规定时间里回应。日志里没有任何更多细节。换框架、调提示词、改重试它偶尔能跑通偶尔直接卡死。后来我把问题重新想了一遍才意识到这个报错大概率跟模型聪不聪明没有关系而是整个执行链路缺少“过程保障”。今天的 Agent 生态几乎每周都会冒出几个新概念Agent 框架、多 Agent 协作、Skill、MCP、Harness、记忆机制、编排模式。形态一天一个样但开发者面对的问题却稳定得惊人——执行不稳定、状态会丢、工具调用不可控、出问题不知道去哪查。很多团队做 AI 应用时最难受的地方就在这里Agent 形态一直在变Infra 到底该追着谁建我的判断很直接Infra 不能追着 Agent 形态建而应该为开发者建。更准确地说是为“一个带有状态、需要工具调用、需要外部资源协作的长时间运行任务”建。这个任务今天叫 Agent以后可能换一个名字但它底层的运行需求不会消失。1. Agent 形态一直在变开发者的问题却没怎么变1.1 “Agent 又卡住了”一次典型调试现场在社区里见过很多类似的求助帖报错无非是几类Agent 执行到一半被终止提示agent terminated due to error。工具调用超时或者模型没有按预期格式返回。上下文一长Agent 就开始“失忆”忘记最初的任务。多 Agent 协作时某个子任务失败整个流程就停了。遇到这些问题大家的直觉通常是换一个更强的模型或者把提示词写得再细一点。但很多时候真正的问题根本不在模型和提示词而是执行链路的某一层断了。一个传统 API 请求失败了你只要看请求和响应就能定位问题。Agent 不是这种一问一答的模型。它更像一个循环接收任务、拆解步骤、调用工具、读取结果、再决定下一步。这个循环中间有大量的状态、时序和外部依赖。只要你把 Agent 放进真实项目就必须面对这些基础设施问题。我见过一个团队为了“追潮流”引进了很复杂的多 Agent 框架结果两个月都没跑出一个稳定可用的流程。最后排查下来问题不在框架而在最基础的地方中间状态没有持久化、工具调用没有重试策略、日志里只有最终错误码。也就是说框架给了他们“形”但没有提供“运行保障”。1.2 框架、协议、概念不断更新为什么没有解决最基础的难受这几年 Agent 形态演进可以粗略分成几个阶段最初是单 Agent 的 ReAct 循环模型自己推理、自己决定调什么工具。然后出现任务分解Agent 把大任务拆成小步骤逐步执行。接着是全自主 Agent目标一给它可以连续跑十几轮。再后来大家发现全自主不可靠又开始用 Workflow、Graph、状态机做可控编排。近一年MCP 统一工具调用Skill 做能力封装Harness 做执行控制概念越来越多。每一波新概念都会带来一批新框架但开发者的问题列表几乎没有变Agent 为什么会卡住为什么上下文一长就丢信息为什么工具调用失败后不知道回退为什么多 Agent 协作结果不可控为什么日志里只有“终止了”没有“哪一步终止了”这些问题的根源不是形态选错了而是底座缺能力。所谓底座就是我们说的 Infra。如果只盯着 Agent 形态会发现今天 A 框架火、明天 B 协议火根本追不完。但如果你把视角放到运行需求上会发现不同形态之间其实共用同一套底层能力。2. Infra 不追形态要为“运行的底层需求”而建2.1 Agent Loop 的托底能力不管 Agent 形态怎么变剥掉外壳之后它本质上是一个循环通常叫 Agent Loop接收任务和环境信息模型推理规划下一步调用工具或 API读取执行结果把结果放回上下文进入下一轮直到任务完成或达到终止条件。在这个循环里基础设施要托底的东西其实非常固定。首先是执行引擎。它要负责任务调度知道哪一步依赖哪一步支持超时、重试、断点恢复。Agent 不是一次函数调用而是一串有依赖关系的步骤。当外部服务超时、模型返回格式异常、工具偶发失败时执行引擎能不能在合理策略下继续或安全停止决定了整个系统是否可靠。其次是状态存储。Agent 在跑的过程中会产生大量中间状态已经完成哪些步骤、哪些结果已经拿到、当前上下文里有哪些有效信息。如果这些状态只放在内存里进程一重启就什么都没了。很多 Agent 项目在开发环境跑得通一上生产就崩溃核心原因就是中间状态没有落盘。第三是任务队列和资源管理。当多个 Agent 任务并发时必须有队列、并发限制和资源配额否则下游工具或模型 API 很容易被打爆。第四是日志与追踪。每一步的输入、输出、耗时、Token 消耗最好都能被记录和回放。这几个能力做一个脚本调一次模型完全不需要但是做一个长期运行的 Agent 系统一个都不能少。2.2 记忆分层短期上下文与长期存储不是一回事Agent 记忆是经常被讨论的话题也是被误解最多的地方。很多人的第一反应是记忆 向量数据库把历史对话存进去下次检索出来塞给模型。这个理解太粗糙了。在真实工程里Agent 的记忆至少要分成三层第一层是短期上下文。这是模型每次调用时实际能看到的窗口受 Token 数限制。它的核心问题是如何压缩、裁剪以及优先保留哪些信息。一个 Agent 跑了十几轮之后如果上下文里塞满了旧的工具结果和中间推理很快就会超出窗口限制或者把重要目标挤掉。第二层是长期记忆。跨会话、跨任务的状态比如用户偏好、项目历史、之前做出的关键决策。这一层适合用向量库或普通数据库存储关键是检索的准确度和更新策略而不只是“能存”。第三层是工作记忆。这也是最容易被人忽视的。Agent 在执行当前任务时“我已经做到哪一步了”“这个结果对应哪个子任务”这些信息必须被保存。否则任何一次中断、超时、重试都可能导致 Agent 从头开始或者产生错误判断。所以基础设施要提供的不是一套“记忆算法”而是一套通用的状态读写接口。让不同 Agent 框架都可以快速“存档”和“读档”知道当前任务执行到哪个节点、哪些中间结果还在、哪些信息已经过期。这才是记忆作为基础设施的意义。2.3 可观测性让 Agent 的执行路径可以回放回到开头那个报错。agent terminated due to error难查不是因为错误信息不够细而是它只告诉你“终止了”没告诉你“在哪个环节终止的”。传统后端系统通过日志和链路追踪能还原一次请求的完整路径。Agent 任务更难因为每一步都可能涉及一次模型调用、一次工具调用、一次上下文更新。如果这些步骤没有记录出了问题就只能靠猜。可观测性至少要解决三件事链路一次 Agent 任务从开始到结束调用过哪些模型、哪些工具每步耗时多少。状态每步的输入输出是否完整上下文占用了多少工具返回是否符合预期。成本每轮消耗了多少 Token、花费多少哪一步最贵。实际落地时我建议从开发阶段就必须给每个 Agent 任务生成一个唯一的trace_id然后把所有日志、工具调用记录、模型请求都跟这个 ID 绑定。# 常见做法启动每个 Agent 任务时生成一个唯一追踪 ID export AGENT_TRACE_ID$(uuidgen)这样当用户反馈“Agent 出错了”时可以通过 trace_id 把一次任务的所有执行轨迹拉出来按时间轴回放。你会发现大部分问题在时间轴上就能定位不是某一轮模型推理错了而是某个工具调用从第 5 步开始就超时。建议任何 Agent 项目上线前先确认一件事——能不能通过一个任务 ID 还原出完整的执行时间轴。如果不能说明可观测性还没有准备好。3. 工具、记忆、安全比形态更容易被忽略的三块硬骨头3.1 Skill、MCP、Harness新概念背后的同一个小切口很多人会纠结Skill 和 MCP 到底有什么区别Harness 和 Agent 又是什么关系可以把这几个概念放在同一个坐标系里看。Skill通常指的是一种能力封装。把“查询数据库”“写周报”“操作某个后台系统”这类能力整理成 Agent 可以理解和使用的方式。它偏重的是“能力本身”。MCP是一种让 Agent 和外部工具、数据源对接的协议。它的价值在于标准化工具调用方式让不同 Agent 框架不需要各自实现一套对接逻辑。它偏重的是“协议”。Harness可以理解成 Agent 执行过程中的控制容器。它负责管理上下文、决定什么时候该停、什么时候该重试、怎么把模型输出转成可执行动作。它偏重的是“控制”。这些概念看起来是不同层的东西但背后有一个共同问题工具调用层一直没有被真正标准化。每换一个 Agent 框架工具调用逻辑可能就要重写一遍每引入一个新协议又要处理一遍鉴权、限流、超时、返回格式。这不是 Agent 形态的问题而是基础设施没有把工具调用层沉淀好。3.2 工具调用层鉴权、限流、幂等与审计工具调用是 Agent 连接真实世界的接口也是风险最集中的地方。举几个例子。Agent 调用一个内部系统下单。如果接口不保证幂等Agent 因为超时自动重试就可能造成重复订单。Agent 调用外部搜索服务。如果没有限流一次任务可能发起上百次请求账单和下游压力都失控。Agent 拿到一个工具之后它会拥有多大权限如果工具层不能控制每个 Agent 能调用哪些工具多 Agent 协作时安全边界几乎等于没有。基础设施在工具调用层要做四件事统一接入规范。不管上层 Agent 框架怎么变工具都注册到同一个平台用统一的描述格式暴露给模型。鉴权与权限。工具所有者可以控制哪些 Agent、哪些任务能调用这个工具这是最小权限原则的落地。限流与配额。每个工具、每个 Agent、每个租户都有独立的调用限制防止单个任务耗尽所有资源。审计日志。谁调用了什么工具、传入什么参数、返回什么结果全部记录。其中幂等性是最容易被忽视的。Agent 执行和传统 API 调用不同它的失败重试是常态。如果工具调用不能“幂等重放”一次失败带来的后果可能比失败本身更严重。# 思路示意调用前先检查幂等键是否存在 if idempotency_key_exists(call_id): return previous_result result call_tool(tool_name, payload, call_idcall_id) save_result(call_id, result)幂等键可以是一个基于任务 ID、步骤 ID、工具名生成的唯一字符串。这样即使 Agent 重试也不会重复执行副作用操作。3.3 安全边界Agent 越自主越需要可控Agent 的自主性越高安全边界就越重要。这里说的安全不只是外部攻击还包括内部权限混乱。一个常见的误区是先让 Agent 跑起来安全问题后面再补。但 Agent 不同于传统脚本它是“带自主决策”的执行体。如果没有边界它可能会在错误场景下调用不该调用的工具或者访问不该访问的数据。在多 Agent 协作场景里安全边界更复杂。每个 Agent 应该只看到自己职责范围内的数据只能调用自己被授权的工具只能写入自己被允许的存储位置。如果在 Infra 层面不设计好这个边界而是完全交给上层 Agent 框架风险会很高——框架一升级边界可能就失效了。我比较推荐的基础设施方案是在工具 API 网关、存储层、消息层做边界控制而不是在 Agent 代码里写一堆 if else。这样权限模型与业务逻辑解耦后续 Agent 怎么演化边界都不会失效。4. 从最小闭环到多 Agent一套可复用的推进路径4.1 第一步定义输入、输出和验证标准很多人搭 Agent 的第一步是选框架、配模型、写提示词。我更建议反过来先回答四个问题输入任务从哪来是用户文本、结构化数据还是某个系统触发的事件输出Agent 最终应该产出什么是一份回答、一份报告还是一个操作结果验证怎么判断成功有没有明确的 Success Criteria失败什么情况下必须停止最大重试次数是多少超过多少步没有进展就终止这四个问题不回答完后面的一切都不可控。如果没有验证标准Agent 能不能算成功会变成一个玄学问题。团队只能靠人肉看结果时间一长根本无法判断是模型出了问题还是任务定义本身有问题。4.2 第二步跑通单 Agent 最小闭环在真实项目和复杂编排之前先用一个最小闭环验证基础的运行链路。这个闭环是模型能理解任务并开始执行工具调用能成功返回结果Agent 能基于工具结果继续下一步最终输出符合预期日志和轨迹可以被回放。整个过程最好在沙盒或开发环境里跑不要直接上生产。跑通过一次只能说明流程没有断还不能说明它稳定。需要反复跑观察它在不同输入、不同外部状态下的表现。提醒不要一上来就设计复杂的多人协同流程。先让一个 Agent 在一个明确任务上连续跑 20 次不出现未预期错误再考虑增加复杂度。4.3 第三步再谈记忆、工具和多 Agent等到单个 Agent 的任务已经稳定了再逐步增加记忆、工具、外部系统集成。多 Agent 协作尤其要谨慎。很多团队认为多 Agent 是效率更高的形态但多 Agent 意味着更长的链路、更多的状态同步、更复杂的错误传播。没有基础设施托底多 Agent 就是“多个 Agent 同时出错”。什么时候可以上多 Agent我建议同时满足几个条件任务能拆成多个职责清晰的子任务子任务之间有明确的信息传递格式每个子 Agent 都可以独立验证结果有总控或编排者能处理子 Agent 的失败和超时。可以按下面这个顺序推进阶段核心目标要建的能力验收标准单 Agent 最小闭环跑通基础链路模型调用、工具调用、日志连续多次跑通无未知错误单 Agent 增强提升任务复杂度记忆、重试、状态持久化失败后可恢复不丢状态多 Agent 协作拆解任务、并行执行消息传递、任务编排、子 Agent 监控单个子 Agent 失败不影响全局生产化安全稳定运行限流、审计、灰度、回滚异常可追踪权限可控成本可见多 Agent 不是银弹。它更适合任务本身可以清晰拆分的场景。如果任务边界不清强行上多 Agent只会让问题从模型层扩散到系统和协作层。5. 排查链路从报错到根因的五步判断法5.1 一个五层排查表Agent 出问题最忌讳的是直接猜。猜模型不好、猜提示词不对、猜框架有 bug然后盲目改。我一般会按一个固定顺序排查现象。是报错终止还是卡住不响应是结果错误还是输出格式不对输入。任务格式是不是完整上下文是不是超长工具返回参数是不是符合预期环境。依赖版本有没有冲突API Key 权限够不够网络和资源配额是否正常参数。超时设置、重试策略、模型参数、工具选择是否合理工具边界。外部服务有没有限流工具本身有没有缺陷当前模型是否具备完成该任务的能力在每个环节都有对应的优先排查点。排查层优先检查项常见原因现象报错类型、是否可复现配置错误、输入异常输入上下文长度、工具返回格式Prompt 缺少约束、工具解析失败环境依赖版本、权限、网络版本不兼容、API Key 过期参数超时、重试、并发Agent 执行策略不合理工具边界外部限流、服务可用性下游服务不稳定、工具有缺陷这个顺序的核心思路是先确定出问题的是哪一层再决定要不要动模型和提示词。很多“模型回答不对”的问题最后查下来是工具返回的数据里混入了错误字段模型被误导了。5.2 用日志和时间轴定位真正的断点排查 Agent 问题不要只看最终错误要看完整时间轴。举个例子。一次 Agent 任务理想情况下是00:00.100 接收任务 00:00.300 模型推理第 1 步 00:01.200 调用工具 A 00:05.800 工具 A 超时重试 00:11.200 工具 A 第二次调用成功 00:11.500 模型推理第 2 步 00:12.000 输出最终结果如果日志是完整时间轴你可以很清晰地看到断点在哪。如果日志只有最终错误你就只能盲猜。我建议给每个 Agent 任务维护一个结构化的追踪日志至少包含任务 ID每轮模型调用的时间戳、Token 消耗每次工具调用的入参、出参、耗时、返回状态每轮执行完成后的上下文长度重试次数及原因最终结果或终止原因。有了这个时间轴之后大部分问题都能快速定位。上下文异常增长说明记忆压缩逻辑有问题某一步工具调用反复超时说明下游服务或者网络是瓶颈模型返回多次格式错误才需要考虑换模型或者改提示词。6. 最后该把注意力放在哪6.1 基础设施的客户是开发者回到文章开头的问题Agent 形态一天一个样Infra 到底该为谁而建我的答案是为开发者而建不是为某个 Agent 形态而建。这里有一个很实用的判断标准换一个 Agent 框架的时候有哪些东西不用重写如果换框架之后工具调用逻辑不用重写状态持久化不用重写日志追踪不用重写权限模型不用重写说明 Infra 已经沉淀下来了。如果每次换框架都要从零搭一遍说明所谓的 Infra 其实只是某个框架的附属品而不是真正的基础设施。好的 Infra 应该让开发者更快地发现失败、恢复失败、预防失败。它服务的用户是那些每天在调试 Agent 的工程师而不是一个抽象的概念。Agent 形态会继续变今天叫 ReAct明天叫 Graph后天可能有别的名字。但开发者面对的核心问题不会变——如何让一个复杂的、有状态的、需要工具和外部资源协作的 AI 任务被稳定地跑起来。6.2 下一步最该做什么如果你现在正要开始做一个 Agent 项目或者正在被不稳定的 Agent 流程折磨我建议你先不要急着换框架也不要急着学新概念。先做一件事拿一个真实任务跑一个最小闭环。记录它依赖什么状态、调用哪些工具、在哪一步最容易失败。然后把记录梳理成清单执行中断后能不能从断点恢复工具调用失败后有没有重试和幂等保护每次任务执行能不能通过一个 trace_id 还原全过程每个 Agent 拥有的工具和数据权限是不是最小化的这些问题回答了你会发现Agent 形态怎么变你都能接得住。因为真正决定一个 Agent 系统能不能跑进生产环境的从来不是最新的概念而是这些最基础的工程能力。