1. 为什么“Agent Infra”成了绕不开的话题1.1 从一个真实困惑说起前阵子有个做后端的朋友找我聊天说他所在的团队想给产品加一个“智能助手”功能一开始大家觉得不就是调个模型接口嘛两三天就能搞定。结果真动手才发现事情远没有那么简单模型调用要管理密钥和配额多轮对话要维护上下文工具调用要处理超时和重试还要考虑成本控制、日志追踪、效果评估……一堆脏活累活堆上来原本以为的“两三天”变成了“两三个月”而且做出来的东西还特别脆稍微改点需求就牵一发动全身。这个困惑其实非常典型。它背后指向的正是最近被反复提起的一个词——Agent Infra也就是“智能体基础设施”。你可以把它理解成当大模型从“聊天玩具”变成“真正干活的员工”时支撑这个员工稳定上班的那一整套底层设施。模型本身是大脑但光有大脑没法工作你还得有记忆、有手脚、有工位、有考核、有安全边界这些加起来才是 Agent Infra。我写这篇东西不是要给你灌什么宏大叙事。恰恰相反我想从一个一线工程师的视角把 Agent Infra 到底包含哪些东西、每一块为什么必须存在、动手时该从哪里切入、哪些坑我踩过尽量讲清楚。不管你是刚接触这块的新手还是已经在做相关系统但总觉得哪里不对劲的老手应该都能从里面找到能直接抄作业的部分。1.2 Agent Infra 到底指什么先把概念钉死不然后面全是空谈。Agent Infra 指的是支撑智能体Agent运行、开发、部署、观测和迭代的一整套基础设施层。它不负责“模型有多聪明”它负责“模型能不能稳定、可控、可负担地把活干完”。打个比方。模型像是刚招进来的高材生智商很高但没上过班。Agent Infra 就是公司的整套办公体系门禁权限、工位运行时环境、工作手册提示词与流程编排、工具箱工具调用、会议纪要记忆与上下文、绩效考核评估与观测、财务报销成本与配额。少了任何一块这个高材生要么干不了活要么干着干着就把公司搞乱了。它和传统的“后端基础设施”有重叠但重心完全不同。传统后端关心的是高并发、低延迟、数据一致性Agent Infra 额外关心的是不确定性管理——因为模型的输出本身是概率性的同样的输入可能给出不同结果这就让缓存、重试、评估、回滚这些机制的设计逻辑全变了。1.3 为什么说它是“巨头的隐秘战场”说它“隐秘”是因为普通用户根本感知不到。你用一个智能助手只会觉得“它挺聪明”或者“它有点笨”不会去想背后有多少层调度、多少条链路、多少次重试。但对做产品的公司来说这块是实打实的护城河。原因很简单模型能力会趋同但工程能力不会。今天你用一个开源模型明天可能换个更强的闭源模型切换成本其实不高。但如果你围绕模型建了一整套 Agent Infra——你的记忆系统、你的工具生态、你的评估数据集、你的成本优化策略——这些东西是搬不走的。谁先把这套基础设施打磨顺了谁就能用更低的成本、更快的速度把智能体产品推到用户面前。所以你会看到各家都在闷头做这块但很少大张旗鼓地讲。因为讲出来对普通用户没意义对同行却是直接送经验。这也是为什么网上关于 Agent Infra 的系统性资料一直比较零散大多是各家自己踩坑后零散分享的片段。1.4 为什么说它是“每个工程师的入场券”这句话我觉得一点不夸张。过去几年会调 API 就能做 AI 应用现在光会调 API 已经不够了。市场需要的是能把智能体真正跑起来、跑稳、跑便宜的人。而这三件事全都落在 Agent Infra 上。我观察下来现在招聘市场上对这类能力的需求非常明确不是要你懂多深的模型原理而是要你懂怎么让模型在真实业务里稳定工作。这包括上下文怎么管、工具怎么接、失败怎么兜底、成本怎么压、效果怎么量化。这些能力恰恰是传统后端工程师、运维工程师、甚至产品经理都能切入的点门槛没有想象中那么高但天花板很高。换句话说Agent Infra 不是一个“新岗位”而是给现有工程师加了一层新技能。你原来的后端功底、系统设计能力、排查问题的经验在这里全都用得上只是需要补上“不确定性”这一课。这就是为什么我说它是入场券——不是让你转行而是让你在原有能力上多一个非常值钱的维度。2. 拆开看Agent Infra 的核心模块与设计取舍2.1 运行时环境智能体的“工位”怎么搭运行时环境是 Agent Infra 最底层的一块负责让智能体“有地方跑”。听起来简单但这里的选择直接决定了后面所有东西的复杂度。最常见的两种做法进程内运行和沙箱隔离运行。进程内运行就是把智能体的逻辑直接跑在你的主服务里调用模型、执行工具都在同一个进程。好处是简单、延迟低、调试方便坏处是隔离性差一个工具调用把进程搞崩了整个服务就挂了而且资源没法精细控制。沙箱隔离运行则是给每个智能体任务开一个独立的执行环境比如容器或者轻量级虚拟机。好处是安全、可控、可限制资源坏处是启动有开销通信有延迟整套调度逻辑复杂不少。我的建议是分阶段来。早期验证阶段用进程内运行快速跑通闭环一旦要上生产、要接外部工具、要处理不可信输入就必须切到沙箱隔离。这个切换点不要拖我见过太多团队因为早期图省事后期重构运行时层代价非常大。具体到沙箱选型容器是最常见的选择因为生态成熟、启动快。但要注意容器的隔离强度对于执行任意代码来说是不够的如果你的智能体会执行用户提供的代码那得考虑更强的隔离方案。这块的取舍逻辑是隔离强度越高启动越慢、成本越高要根据你的实际风险来定不要盲目上最重的方案。2.2 上下文与记忆让智能体“记得住、想得起”上下文管理是 Agent Infra 里最容易被低估、但实际最影响体验的一块。很多人以为上下文就是“把历史对话拼起来发给模型”真做起来才发现问题一大堆拼多了超长、拼少了失忆、拼错了跑偏。这里要区分两个概念短期上下文和长期记忆。短期上下文是当前任务内的对话历史长期记忆是跨任务、跨会话沉淀下来的信息。两者的管理策略完全不同。短期上下文的核心问题是窗口有限。模型的上下文窗口再大也是有限的而且越长越贵、越慢。所以你需要一套裁剪策略。常见的做法有几种按轮次裁剪只保留最近 N 轮、按重要性裁剪用模型或规则给每轮打分保留高分、按摘要压缩把旧对话总结成一段话。我实测下来混合策略最稳最近几轮原样保留更早的做摘要压缩同时把关键实体比如用户提到的订单号、人名单独抽出来常驻。长期记忆的核心问题是存什么、怎么取。不是所有信息都值得存存多了检索噪音大存少了又不够用。我的经验是长期记忆要存的是稳定的事实和偏好比如“这个用户偏好简洁回复”“这个项目的技术栈是某某”而不是一次性的对话内容。存储用向量库做语义检索是主流做法但要注意纯向量检索在精确匹配场景下会翻车最好配上关键词检索做混合召回。提示上下文管理不要一上来就追求完美。先用最简单的“最近 N 轮”策略跑起来观察真实使用中哪些信息丢了会导致问题再针对性补。过早设计复杂的记忆系统往往是在解决不存在的问题。2.3 工具调用智能体的“手脚”怎么接工具调用是智能体从“会说”到“会做”的关键。模型本身只能生成文本要让它查数据库、发邮件、调接口全靠工具调用这一层。这块的设计核心是契约清晰和失败可控。契约清晰指的是每个工具的描述要准确包括它做什么、需要什么参数、返回什么格式。描述写得含糊模型就会乱调、错调。我见过一个案例某个工具的描述里没写清楚参数是必填还是选填结果模型经常漏传参数导致大量失败。后来把描述改清楚失败率直接降了一大截。失败可控指的是工具调用一定会失败你得提前想好怎么办。超时了重试几次重试还是失败怎么办返回错误给模型让它自己调整还是直接兜底这些都要有明确策略。我的做法是分级处理可重试的错误比如网络抖动自动重试不可重试的错误比如参数错误把错误信息返回给模型让它重新决策连续失败超过阈值就中断任务并上报。还有一个容易被忽略的点是工具的数量。工具不是越多越好工具太多会让模型选择困难调用准确率下降。实践中单个智能体能稳定使用的工具数量是有限的超过一定数量后要么做工具分组要么做动态工具加载根据当前任务只暴露相关工具。这个阈值因模型而异需要你自己测。2.4 编排与调度多个智能体怎么协作当任务复杂到单个智能体搞不定时就需要多个智能体协作。这时候编排和调度就成了核心问题。常见的编排模式有几种串行流水线一个接一个、并行分发同时跑多个再汇总、层级调度一个主智能体指挥多个子智能体。选哪种取决于任务结构。串行适合有明确先后依赖的流程并行适合可以拆分的独立子任务层级适合任务复杂、需要动态决策的场景。这里最大的坑是错误传播。在串行流水线里前面一步错了后面全错。所以每一步都要有校验不能盲目往下传。在层级调度里主智能体的决策质量直接决定整体效果所以主智能体的提示词和工具设计要格外用心。调度层面还要考虑并发控制和资源配额。多个智能体同时跑很容易把模型配额打满或者把下游服务压垮。我的做法是给每个任务设一个资源预算比如最多调用多少次模型、最多花多少钱超了就中断。这个预算机制看起来简单但能避免很多“跑飞了”的事故。2.5 观测与评估怎么知道智能体干得好不好这是 Agent Infra 里最不性感、但最重要的一块。没有观测和评估你根本不知道你的智能体是在进步还是在退步。观测分两个层面系统层观测和效果层观测。系统层观测就是传统的日志、指标、链路追踪看的是延迟、错误率、资源消耗这些。效果层观测看的是智能体干得对不对、好不好这就需要专门的评估机制。效果评估的难点在于没有标准答案。传统软件测试是输入确定、输出确定对错分明。智能体的输出是开放的怎么判断好坏常见的做法有几种用规则做自动校验比如检查输出格式、检查是否包含必要信息、用模型做裁判让另一个模型给输出打分、人工抽检。我实测下来规则校验打底、模型裁判补充、人工抽检兜底这个组合最实用。纯靠模型裁判会有偏差纯靠人工又太慢。还有一个关键点是评估数据集。你得有一批固定的测试用例每次改动后都跑一遍看效果有没有退化。这个数据集要覆盖典型场景和边界场景而且要持续维护。很多团队一开始没有这个意识改着改着就发现效果莫名其妙变差了又找不到原因。3. 动手实操从零搭一个最小可用的 Agent Infra3.1 整体架构与选型思路前面讲了这么多模块真动手时不可能一次全上。我的建议是先搭最小闭环再逐步加固。最小闭环包含四样东西一个运行时、一套上下文管理、一个工具调用机制、一套基础日志。评估和编排可以后面再加。选型上我的原则是能用现成的就不自己造。现在开源生态里已经有不少成熟的组件比如向量库、编排框架、观测工具没必要从零写。但要注意框架会带来抽象成本有时候直接用底层库反而更灵活。我的判断标准是如果框架能帮你省掉 80% 的样板代码就用如果框架的抽象让你调试困难就绕开。下面给一个我实际用过的架构参考用文字描述清楚接入层接收任务请求做鉴权和限流编排层解析任务决定用哪个智能体、走什么流程运行时层每个智能体任务跑在独立容器里能力层模型调用、工具调用、记忆读写都封装成统一接口观测层全链路日志和指标采集存储层向量库存长期记忆关系库存任务状态这个架构不算复杂但每一层都有明确的职责边界后面加东西不会乱。3.2 关键步骤上下文管理的代码实现上下文管理这块我给一个简化但可用的实现思路。核心是一个ContextManager类负责维护对话历史、做裁剪、做摘要。class ContextManager: def __init__(self, max_tokens8000, keep_recent6): self.history [] # 完整历史 self.max_tokens max_tokens self.keep_recent keep_recent self.summary # 旧对话的摘要 def add(self, role, content): self.history.append({role: role, content: content}) self._compress_if_needed() def _compress_if_needed(self): # 估算当前 token 数超了就压缩 if self._estimate_tokens() self.max_tokens: old self.history[:-self.keep_recent] recent self.history[-self.keep_recent:] # 把旧对话合并进摘要 self.summary self._summarize(old, self.summary) self.history recent def build_prompt(self): # 摘要 最近对话组成最终上下文 messages [] if self.summary: messages.append({role: system, content: f历史摘要{self.summary}}) messages.extend(self.history) return messages这段代码的关键在于_compress_if_needed这个触发时机。我一开始是每轮都检查后来发现太频繁改成超过阈值才压缩性能好很多。另外keep_recent这个参数要调太小了会失忆太大了压缩没意义我一般设 6 到 10 轮。_summarize这个函数可以用模型来做也可以用规则做。用模型做质量好但费钱用规则做省钱但可能丢信息。我的做法是关键信息用规则抽取整体摘要用模型生成两者结合。3.3 关键步骤工具调用的容错设计工具调用这块容错设计是重点。我给一个我常用的重试加兜底的模式def call_tool_with_retry(tool, params, max_retry3): last_error None for attempt in range(max_retry): try: result tool.execute(params) if result.is_valid(): return result last_error result.error except TimeoutError as e: last_error e time.sleep(2 ** attempt) # 指数退避 except Exception as e: # 不可重试的错误直接返回给模型 return {status: error, message: str(e), retryable: False} return {status: error, message: str(last_error), retryable: True}这里有几个细节值得说。指数退避是必须的不然重试会把下游打得更惨。区分可重试和不可重试也很关键参数错误重试一百次也没用只会浪费时间。返回给模型的时候带上retryable标记让模型知道是该换个参数重试还是该放弃这个工具换别的路子。还有一个我踩过的坑工具调用的超时时间要分层设置。模型调用有超时工具执行有超时整个任务也有超时。这三个超时要协调好不然会出现工具还在跑但任务已经超时被杀了的情况。我的设置是任务超时 工具超时 模型超时留出足够的缓冲。3.4 关键步骤成本控制的参数计算成本控制这块很多人是等账单来了才后悔。其实可以提前算清楚。假设你用的是按 token 计费的模型输入和输出价格不同。一个智能体任务的平均消耗可以这样估算系统提示词约 500 token每轮对话历史约 300 token平均 5 轮工具调用返回约 200 token平均 3 次模型输出约 400 token那么单次任务的输入 token 大约是 500 300×5 200×3 2600输出约 400。如果输入价格是每百万 token 若干元输出价格是输入的几倍你就能算出单次任务成本。再乘以预估的日活任务数就是日成本。这个计算的意义在于你能提前知道成本瓶颈在哪。如果发现历史对话占了大头那就优化上下文裁剪如果工具返回占了大头那就精简工具返回格式。我见过一个团队工具返回里塞了一大堆用不上的字段光这一项就占了总成本的近一半精简后直接省了一大笔。注意成本优化不要牺牲效果。我见过为了省钱把上下文裁得太狠结果智能体频繁失忆用户体验崩了反而要花更多成本去补救。省钱的前提是效果达标。3.5 关键步骤观测埋点的最小集合观测埋点不用一上来就做全套先埋最关键的几个指标指标含义用途任务成功率完成任务数 / 总任务数看整体健康度平均轮次每个任务平均对话轮数看效率轮次异常高说明有问题工具调用失败率失败次数 / 总调用次数定位工具问题平均延迟任务从开始到结束的耗时看性能单任务成本平均 token 消耗换算看成本这几个指标埋下去基本能覆盖大部分问题定位场景。我建议每个任务都打一个 trace_id把这次任务的所有模型调用、工具调用、错误都串起来排查问题时能一路追下去。这个习惯看起来简单但真出问题时能省你大量时间。4. 踩坑实录那些文档里不会写的问题4.1 上下文丢失导致的“失忆”问题这个问题我遇到过好几次表现是智能体在对话中途突然忘了前面说过的关键信息。排查下来原因基本都是上下文裁剪把重要信息裁掉了。有一次是用户先说了自己的会员等级后面几轮对话后智能体推荐商品时完全没考虑这个等级。查日志发现会员等级那条消息在裁剪时被归入了“旧对话”摘要时又没被保留。解决办法是在摘要逻辑里加一条规则涉及用户属性、偏好、关键实体的信息必须原样保留不参与摘要压缩。这个坑的教训是上下文裁剪不能纯按时间顺序来要按信息重要性分层。我现在会把上下文分成三层常驻层关键实体和属性永不裁剪、摘要层旧对话的压缩、原始层最近几轮原样保留。这样既省 token 又不丢关键信息。4.2 工具描述含糊引发的“乱调”前面提过工具描述的重要性这里展开说一个具体案例。有个团队做了一个查询订单的工具描述写的是“查询订单信息”参数是“订单相关参数”。结果模型经常传一些奇怪的参数比如把用户 ID 当订单号传进去。问题出在描述太含糊。后来改成“根据订单号查询订单的详细状态参数 order_id 为必填的订单编号格式为纯数字字符串”调用准确率立刻上去了。我的经验是工具描述要写到“一个不了解业务的人看了也能正确调用”的程度。具体包括这个工具做什么、什么时候用、每个参数的含义和格式、返回什么、有什么限制。写的时候不要怕啰嗦模型不怕啰嗦怕的是含糊。4.3 并发任务把配额打满的事故这个坑比较惨烈。有次上线了一个批量处理功能用户一次提交几百个任务结果这些任务同时跑瞬间把模型配额打满导致其他正常用户的请求全部失败。事后复盘问题在于没有做并发控制和配额隔离。批量任务和实时任务共用同一个配额池批量任务一冲实时任务就饿死了。解决办法是做了两层隔离配额池隔离批量任务和实时任务用不同的配额池和并发限流每个用户同时运行的任务数有上限。另外加了一个任务队列超出的任务排队而不是直接跑。这套机制加上后再没出现过类似事故。这个教训是Agent Infra 的调度层一定要考虑公平性不能让某个用户或某类任务把资源占满。这在传统后端里是常识但在智能体场景下容易被忽略因为大家注意力都在模型效果上。4.4 评估缺失导致的“悄悄退化”这个问题最隐蔽。有个团队改了一版提示词主观感觉效果变好了就直接上线了。结果过了一周用户投诉变多回头一查发现新提示词在某些边界场景下表现反而更差只是这些场景在主观测试时没覆盖到。根因是没有固定的评估数据集每次改动都是凭感觉判断。后来他们建了一个包含几百条测试用例的数据集覆盖典型场景和边界场景每次改动前都跑一遍对比通过率。有了这个之后改动就有了客观依据不会再出现“悄悄退化”。我的建议是评估数据集要从项目第一天就开始积累。每次发现一个 bad case就把它加进数据集。时间长了这个数据集就是你最宝贵的资产比任何提示词技巧都值钱。4.5 常见问题速查表问题现象可能原因排查方向解决思路智能体失忆上下文裁剪过度检查裁剪策略和摘要逻辑关键信息常驻分层管理工具调用失败率高工具描述含糊检查工具描述和参数定义描述写详细参数标必填任务跑飞成本失控无预算限制检查是否有资源预算加预算和并发控制效果莫名变差无评估机制对比改动前后的评估结果建评估数据集改动必跑延迟忽高忽低资源竞争检查并发和配额分配做隔离和限流错误传播导致全盘失败无步骤校验检查每步是否有校验加校验和中断机制这张表是我自己排查问题时常用的基本覆盖了八成以上的常见故障。遇到问题先对号入座能省不少时间。5. 给不同阶段工程师的切入建议5.1 如果你是后端工程师你的优势在于系统设计和工程能力这些在 Agent Infra 里全都用得上。切入点是运行时和调度层这两块和你原来的经验最接近。你需要补的是对“不确定性”的理解——模型输出不稳定所以缓存、重试、评估这些机制的设计逻辑和传统后端不一样。我的建议是先从一个小的智能体功能做起把上下文管理和工具调用这两块吃透然后再往编排和评估扩展。不要一上来就搞大而全的平台容易陷进去出不来。5.2 如果你是算法或数据方向你的优势在于对模型的理解和数据处理能力。切入点是评估和记忆层。评估这块需要设计测试用例、分析 bad case、做效果对比这些和你原来的工作很接近。记忆层涉及向量检索和召回优化也是你的强项。你需要补的是工程侧的稳定性思维——怎么让系统在部分失败时还能降级运行怎么做资源隔离这些是算法背景容易忽略的。多和后端同事交流能少走很多弯路。5.3 如果你是产品或其他方向不要觉得这块和你无关。Agent Infra 的很多设计决策本质上是在效果、成本、体验之间做权衡这正是产品该参与的。比如上下文保留多少轮、工具调用失败时怎么给用户反馈、成本超预算时怎么降级这些都是产品决策。我的建议是主动去了解这套基础设施的能力边界知道什么能做、什么做不了、代价是什么。这样在设计产品功能时就不会提出一些技术上根本落不了地的需求。5.4 一个通用的学习路径不管什么背景我建议的学习路径是这样的先跑通一个最小智能体再逐步加模块。具体来说用最简单的进程内运行调通模型跑通单轮对话加上上下文管理跑通多轮对话加上一两个工具跑通工具调用加上日志能看清每次任务发生了什么加上评估能判断改动是好是坏把运行时换成沙箱隔离准备上生产加上编排和调度支持复杂任务这个路径每一步都有明确的产出不会让你觉得无从下手。而且每一步都是在真实跑通的基础上加东西比看一堆理论资料有效得多。6. 我对这块的一些个人判断做了一段时间下来我最大的体会是Agent Infra 的难点不在技术深度而在工程细致度。它用到的技术单拎出来都不算前沿向量检索、容器调度、日志追踪都是成熟东西。但把它们组合起来让一个概率性的系统稳定运行这个组合过程非常考验细节把控。另一个体会是这块的迭代速度极快但底层逻辑变化很慢。工具、框架、模型都在快速更新但上下文管理、容错设计、成本控制这些核心问题的本质没变。所以与其追新工具不如把底层逻辑吃透这样换什么工具都能快速上手。最后分享一个小技巧养成记录 bad case 的习惯。每次遇到智能体表现不好的情况随手记下来包括输入、输出、期望输出。这些记录积累起来就是你优化系统最直接的依据。我自己的 bad case 记录本已经攒了几百条每次要改东西之前翻一翻能避开很多重复的坑。这个习惯看起来笨但真的有用。
