1. 当所有人盯着模型参数时真正的工程战场已经转移了过去一年多我身边做算法的朋友聊天话题几乎被两件事占满一是模型又刷新了什么榜单二是推理成本又降了多少。但如果你真的在工业环境里交付过基于大模型的系统就会发现一个很尴尬的事实——模型能力再强把它变成一个能稳定跑在生产环境、能扛住真实用户流量、能持续迭代的智能体系统中间隔着的鸿沟远比想象中大。这条鸿沟就是现在圈内越来越多人挂在嘴边的Agent Infra也就是智能体基础设施。我先把话说直白一点Agent Infra 不是某个具体的框架也不是某个开源库的名字它是一整套支撑智能体从能跑到能规模化跑的工程底座。它涵盖的东西非常杂——运行时怎么调度、上下文怎么管理、工具怎么注册和调用、多智能体之间怎么通信、状态怎么持久化、失败怎么恢复、成本怎么控制、效果怎么评测。这些东西单拎出来都不新鲜但组合到智能体这个场景下就变成了一片几乎没人系统整理过的战场。为什么说它是巨头的隐秘战场因为大厂在模型层面的差距正在被快速抹平开源模型追得很紧闭源模型之间的能力差距也没有代差那么夸张。真正拉开产品体验差距的往往是背后那套基础设施做得够不够扎实。同样一个任务A 家的智能体能连续跑二十步不崩B 家跑到第五步就开始胡言乱语或者死循环这不是模型的问题是基础设施的问题。而这类能力大厂不会大张旗鼓地讲因为它不像模型参数那样好宣传但它是实打实的护城河。那每个工程师的入场券又是什么意思我的判断是未来两三年懂 Agent Infra 的工程师会比懂模型微调的工程师更稀缺也更难被替代。原因很简单微调这件事正在被工具链不断平民化而 Agent Infra 涉及的是分布式系统、状态管理、可观测性、成本工程这些硬功夫它需要的是工程判断力不是调参手感。这篇文章我就想把这套东西拆开讲清楚从它到底解决什么问题到核心模块怎么设计再到实际落地时那些文档里不会写的坑尽量给想入场的人一张能用的地图。提示本文讨论的 Agent Infra 是工程架构层面的通用概念不绑定任何特定厂商或产品所有案例均为抽象化的工程场景描述。2. Agent Infra 到底在解决哪些模型解决不了的问题2.1 从单次问答到多步执行的本质变化很多人对智能体的理解还停留在给个提示词模型回一段话。但真正的智能体是多步执行的它要拆解任务、调用工具、观察结果、调整策略、再执行循环往复直到任务完成。这个变化带来的工程挑战是数量级的。单次问答是无状态的请求进来、模型算完、结果返回结束。多步执行是有状态的每一步都依赖前面的结果中间任何一步出错都可能让整个任务崩掉。更麻烦的是这个状态不是简单的键值对而是包含了对话历史、工具调用记录、中间推理、外部环境快照等一大堆异构数据。你怎么存、怎么取、怎么在多个执行节点之间同步全是问题。我见过太多团队一开始用最简单的方式——把整个执行历史塞进一个列表每次调用都全量传给模型。小规模测试没问题一旦任务步数上去、并发上来立刻爆炸上下文超长、token 成本飙升、延迟高得离谱。这就是典型的没有 Infra 思维的写法。2.2 上下文管理不是塞得越多越好上下文管理是 Agent Infra 里最容易被低估的模块。新手直觉是信息越多模型判断越准但实际恰恰相反。上下文里塞太多无关信息模型注意力会被稀释关键指令被淹没反而更容易跑偏。一个成熟的上下文管理策略通常包含几层分层存储把系统指令、任务目标、近期对话、历史摘要、工具返回结果分开管理不同层有不同的生命周期和裁剪策略。动态裁剪根据当前步骤的需要只把相关片段注入上下文而不是全量灌入。摘要压缩对久远的历史做摘要保留语义主干丢掉细节噪声。优先级排序当上下文接近上限时按重要性决定谁留下谁丢弃。这里有个经验值可以参考大多数任务场景下真正需要保留在活跃上下文里的信息往往只占全部历史记录的 20% 到 30%。剩下的要么可以摘要要么可以放到外部存储按需检索。我做过一个对比测试把全量上下文改成摘要加按需检索之后同样的任务成功率没降token 消耗降了将近一半延迟也明显改善。2.3 工具调用注册容易治理难工具调用看起来是最简单的一环——定义个函数描述模型决定调不调、传什么参数。但真正上规模之后工具治理才是大头。首先是工具数量膨胀。一个业务系统跑半年工具从最初的五六个涨到几十上百个。工具一多模型选择困难误调用率上升而且每个工具的 schema 都要占上下文。这时候就需要工具分组、按场景动态加载、甚至用检索的方式先筛出候选工具再让模型选。其次是参数校验和容错。模型生成的参数经常不合规——类型错了、必填项漏了、枚举值不在范围内。你不能指望模型每次都完美必须在工具执行前做一层严格的校验和修正执行后做一层结果规范化。这层护栏做得好不好直接决定系统的稳定性。最后是幂等和副作用控制。有些工具是有副作用的比如写数据库、发消息、下单。模型可能因为重试或者逻辑混乱重复调用同一个工具如果没有幂等设计后果很严重。我的做法是给所有有副作用的工具加一个执行令牌机制同一个逻辑步骤内重复调用直接返回缓存结果。2.4 状态持久化与故障恢复智能体执行到一半进程挂了怎么办这是生产环境必须回答的问题。单机内存里存状态的做法在真实场景下完全不可靠。正确的做法是把执行状态持久化到外部存储每一步执行完都做一次检查点。这样即使进程崩溃重启后也能从最近的检查点恢复而不是从头再来。这里的关键设计是检查点要足够细又不能太细。太粗恢复后要重做很多步浪费成本太细写存储的开销又太大。实践中我一般按逻辑步骤做检查点一个逻辑步骤可能包含若干次模型调用和工具调用这样粒度比较合适。还有一个容易被忽略的点恢复后的状态一致性。如果崩溃前某个工具已经产生了副作用恢复后不能重复执行。这就要求检查点里不仅记录执行到哪了还要记录哪些副作用已经生效了。3. 拆开看一套能打的 Agent Infra 由哪些模块组成3.1 运行时与调度层运行时层负责的是智能体怎么跑起来、怎么被调度。它要处理的核心问题包括任务怎么排队、并发怎么控制、超时怎么处理、资源怎么隔离。并发控制这块特别值得说。智能体的执行往往涉及大量外部调用模型推理、工具执行、检索查询这些调用的延迟差异很大。如果用一个简单的线程池去跑很容易出现某些慢调用把线程占满、其他任务饿死的情况。更合理的做法是异步加事件驱动把每个外部调用都做成非阻塞的用事件循环来驱动状态流转。这样单机能支撑的并发数能提升一个数量级。超时处理也有讲究。不能简单地设一个全局超时因为不同步骤的合理耗时差异很大。我的经验是分层设超时单次模型调用一个超时单个工具调用一个超时整个任务一个总超时。任何一层超时都触发相应的降级或重试策略而不是一刀切。3.2 记忆与知识层记忆层解决的是智能体怎么记住东西。它通常分短期记忆和长期记忆。短期记忆就是当前任务的执行上下文长期记忆是跨任务、跨会话积累的知识。长期记忆的实现方式现在主流是向量检索加结构化存储的组合。纯向量检索的问题是召回不准尤其是涉及精确条件过滤的时候。所以实践中往往是先用结构化字段做粗筛再用向量做语义精排。这个混合检索的思路比单纯堆向量库效果好得多。还有一个坑是记忆的写入时机。不是所有对话都值得记无脑全存会导致记忆库被噪声污染检索质量越来越差。我的做法是加一个记忆价值判断环节用规则或者小模型判断这段信息是否值得长期保留只存高价值的。3.3 工具与集成层工具层是智能体和外部世界交互的接口。它的设计目标应该是让新增工具的成本尽可能低同时保证治理能力不打折。一个实用的做法是把工具定义标准化用统一的 schema 描述工具的输入输出、副作用类型、超时要求、幂等性等元信息。然后工具的执行、校验、重试、监控全部由框架统一处理业务方只需要写核心逻辑。这样既降低了接入成本又保证了治理的一致性。集成层还要考虑外部系统的稳定性差异。有些第三方接口很稳有些经常抽风。对不稳定的接口要有熔断和降级机制不能让它拖垮整个智能体。3.4 可观测与评测层这是最容易被忽视、但长期价值最高的一层。智能体的执行链路很长出问题时如果只能看到任务失败了根本没法排查。你需要的是全链路追踪每一步的输入输出、耗时、token 消耗、工具调用结果、决策依据全部记录下来能按任务 ID 串起来看。评测层则是回答我的智能体到底行不行。这里的关键是建立可复现的评测集覆盖典型场景和边界场景每次改动都跑一遍看成功率、平均步数、成本、延迟这些指标的变化。没有评测的迭代就是盲人摸象。模块核心职责常见踩坑点运行时调度并发、超时、资源隔离同步阻塞导致并发上不去记忆知识短期上下文、长期记忆无脑全存污染检索质量工具集成注册、校验、幂等工具膨胀导致选择困难可观测评测追踪、指标、回归只记结果不记过程无法排查4. 落地时那些文档不会告诉你的坑4.1 成本失控往往发生在你没注意的地方智能体的成本结构和普通应用完全不同。普通应用的成本主要是服务器智能体的成本大头是 token。而 token 消耗最容易失控的地方不是模型调用本身而是上下文的重复传输。多步执行时每一步都要把历史上下文传给模型。如果历史有 5000 token执行 20 步光历史传输就是 10 万 token。这个开销在测试阶段看不出来上线后账单会教你做人。控制方法有几个一是前面说的上下文裁剪和摘要二是缓存复用很多模型服务支持上下文缓存重复的前缀部分可以复用成本能降不少三是分级模型简单步骤用小模型复杂步骤才用大模型不要全程都用最贵的。我做过一个粗略的估算一个设计良好的智能体系统通过上下文优化和分级模型token 成本能压到 naive 实现的 30% 到 40%。这个差距在规模化之后就是生死线。4.2 死循环和跑偏最隐蔽的稳定性杀手智能体最让人头疼的失败模式不是报错而是不报错但一直在做无用功。它可能陷入死循环反复调用同一个工具也可能跑偏越走越远但每一步看起来都合理。这类问题很难靠单点检测发现需要全局的异常检测。我的做法是设几个硬性护栏最大步数限制、相同工具连续调用次数限制、任务耗时上限、以及一个进展检测机制——如果连续几步没有产生新的有效信息就判定为停滞触发干预。干预策略可以是让模型重新审视目标、切换策略或者直接终止并上报。关键是不能让它无限跑下去那是在烧钱。4.3 多智能体协作听起来很美做起来很痛多智能体协作是现在很热的方向但我要泼盆冷水大多数场景下单智能体加工具就够用了多智能体反而增加复杂度和不确定性。多智能体真正有价值的场景是任务可以清晰拆分成多个独立子任务、且子任务之间耦合度低的时候。比如一个负责检索、一个负责分析、一个负责生成各司其职。但如果任务本身是高度耦合的硬拆成多智能体只会导致通信开销爆炸、状态同步困难、错误传播放大。如果确实要用多智能体通信协议的设计是核心。要明确谁对谁负责、消息格式是什么、冲突怎么仲裁、失败怎么回滚。这些在单智能体里不存在的问题在多智能体里全是坑。4.4 评测集不是一次性的是要养的很多团队建了评测集之后就放着不管结果评测集和真实场景越来越脱节跑出来的分数好看但线上照样出问题。评测集需要持续维护把线上发现的 bad case 定期补充进去把过时的场景剔除保持评测集和真实分布的同步。同时评测指标也要多维不能只看成功率还要看成本、延迟、步数、用户满意度。单一指标优化容易导致其他维度劣化。5. 想入场工程师该补哪些能力5.1 分布式系统的底子比模型知识更重要如果你问我 Agent Infra 工程师最该补什么我的答案不是提示词工程也不是模型原理而是分布式系统的基本功。状态管理、并发控制、故障恢复、一致性、可观测性这些才是日常工作中真正花时间的部分。具体来说你得理解异步编程模型、消息队列、分布式锁、幂等设计、检查点机制这些东西。它们不是新东西但在智能体场景下有了新的应用方式。有分布式背景的工程师转过来做 Agent Infra上手速度会快很多。5.2 提示词工程要懂但别神化提示词当然重要它是你和模型沟通的接口。但我要提醒的是不要把系统稳定性寄托在提示词上。提示词能解决的是让模型理解意图解决不了让系统在异常时优雅降级。一个成熟的工程师会把提示词当成系统的一个可配置组件而不是魔法咒语。它需要版本管理、需要 A/B 测试、需要和代码一起做回归。把提示词工程化比追求某个神级提示词有价值得多。5.3 成本意识要刻进骨子里做 Agent Infra 的人必须对成本极度敏感。每一次设计决策都要问这会让 token 消耗增加多少会让延迟增加多少规模化之后成本是多少这种意识不是天生的是被账单教育出来的。我建议每个做这块的工程师都定期看看自己系统的成本明细搞清楚钱花在哪了。很多时候优化空间就藏在那些你从没注意过的调用里。5.4 从一个小而完整的系统开始练手最后给想入场的人一个实操建议不要一上来就搞大而全的框架先做一个能跑通完整链路的小系统。哪怕它只支持一个工具、只处理一种任务只要它包含了运行时、状态管理、工具调用、可观测这几个核心环节你就能从中理解 Agent Infra 的全貌。跑通之后再逐步加复杂度加工具、加并发、加记忆、加多智能体。每一步都观察系统哪里先扛不住那个先扛不住的地方就是你最该深入的方向。这种从实践中长出来的理解比看一百篇架构文章都管用。我个人在实际操作中的体会是Agent Infra 这个方向最大的魅力在于它把很多经典的工程问题和最新的 AI 能力结合在了一起。你既要有传统后端的扎实功底又要理解模型的行为特性还要有产品思维去判断什么值得做。这种复合能力恰恰是短期内很难被替代的。所以如果你正在犹豫要不要往这个方向投入我的建议是早点动手从最小的完整系统开始边做边补这个入场券值得拿。