前几年聊AI所有人都在盯着模型的参数规模和榜单分数一个模型发布刷屏的是几个基准测试的涨点。但从去年下半年开始我明显感觉到风向变了。身边做产品的朋友不再张口闭口“换个大模型”而是开始问一些更落地的问题Agent跑起来之后状态存哪里、多个工具调用怎么编排、对话历史太长怎么处理、线上出了问题怎么排查。这些问题的集合恰恰就是标题里说的Agent Infra——智能体基础设施。它不像模型本身那样光鲜却直接决定了一个Agent是停留在“演示级玩具”还是能成为生产环境里稳定跑业务的产品。这篇文章我想把它彻底摊开讲清楚Agent Infra到底在解决什么问题为什么各路巨头都在悄悄押注这块“隐秘战场”以及最关键的——作为普通工程师不靠大厂资源怎么自己拿到这张入场券。内容会尽量往实际操作上靠包括我自己踩过的坑和最后沉淀下来的方案希望能对正在做或准备做Agent开发的你有实际帮助。1. 先弄清楚Agent Infra 到底在解决什么问题1.1 从模型能力到 Agent 能力中间隔着一层“基础设施”很多人对Agent有一个误解觉得只要模型够聪明Agent就能自动干活。这个想法在简单demo里勉强成立给模型一段Prompt让它调用一个工具能跑通就算成功。但到了真实业务里事情立刻变复杂。你可以把模型想象成一个刚入职、智商很高但毫无经验的实习生他脑子转得快但不知道公司流程怎么走、不知道资料存在哪、不知道出了问题该找谁。你需要的不是一个聪明的实习生而是一整套让这个实习生能高效工作的办公环境工位、电脑、内部系统权限、工作手册、汇报机制、应急预案。这套“办公环境”就是Agent的基础设施。为什么之前大家不觉得它重要因为上一轮AI应用大多是单轮对话用户问一个问题模型给一个答案完事了。但Agent的核心是“多步骤任务执行”它要自己理解目标、拆解步骤、调用工具、检查结果、失败重试整个过程跨越很长时间涉及多个系统。这时候任何一环基础设施缺失Agent都会像无头苍蝇一样乱撞。模型负责“聪明”Infra负责“靠谱”两者缺一不可。1.2 Agent 基础设施的六大能力面我把Agent Infra拆成六个能力面这六个面基本覆盖了从开发到上线的全链路。也是判断一个Agent平台成熟度的主要观察维度。能力面核心解决什么问题典型技术组件运行时与编排Agent如何按步骤执行、如何控制流程任务调度器、状态机、工作流引擎记忆与状态Agent怎么记住上下文和已完成的事会话存储、向量数据库、长期记忆模块工具与连接Agent怎么调用外部系统和数据工具注册表、API网关、函数调用框架上下文与检索怎么高效地把需要的信息塞给模型检索增强生成RAG、上下文压缩、动态选择可观测与评测线上怎么监控、怎么评估Agent好坏日志追踪、指标采集、评测集、回归测试安全与治理怎么防止Agent做不该做的事权限控制、指令校验、内容过滤、审计日志这六个面不一定每个Agent都需要全部自建。小规模场景可以先用现成组件拼但一旦业务量上来每一个面都会成为瓶颈。举例来说早期一个Agent可能只用向量库存对话历史但到了几百个用户并发使用的时候你会发现存储设计、检索策略、上下文窗口的分配都变成了需要认真对待的工程问题不再是“找个库存起来就行”这么简单。1.3 一个残酷现实没有基础设施的 Agent 只能是 Demo我见过太多项目死在这个坎上。一个团队花两周时间用现成的Agent框架搭出一个很惊艳的demo能自己规划任务、调用好几个工具、完成复杂流程演示效果满分。然后进入开发阶段问题开始一个个冒出来。第一个问题是“失忆”。Agent执行一个长任务执行到一半上下文窗口满了最早的步骤被挤掉它忘记了自己最开始要干什么开始自由发挥。第二个问题是“失控”。调用外部工具时接口返回格式和预期不符Agent开始反复重试同一个错误请求白白消耗Token和API配额。第三个问题是“黑盒”。线上用户反馈说Agent给出了错误答案但你完全不知道中间经历了什么——它调了哪个工具、传了什么参数、在哪一步开始跑偏全部无迹可循。这些问题都不是模型能力能解决的。它们属于基础设施该管的范畴。所以我现在判断一个Agent项目有没有戏先不看它的模型调得有多好而是看它的基础设施是否跟得上。模型可以随时换Infra的坑如果没填平换什么模型都白搭。2. 巨头们的隐秘战场为什么都在押注同一块地2.1 巨头切入 Agent Infra 的三个底层逻辑如果只把Agent Infra理解成“一套技术组件”你会觉得它没什么特别的开源拼一拼也能搭。但巨头们看得更远它们押注的是这个领域背后的三个战略价值。第一个逻辑是模型层正在快速同质化。头部模型之间的性能差距在缩小你追我赶的周期从一年缩短到几个月。模型本身越来越难成为护城河真正的差异点开始转移到工程能力和生态完善度上。谁能让开发者更容易地构建、部署、运营Agent谁就能在应用层占据优势。基础设施就是那个“更容易”的关键。第二个逻辑是入口争夺。如果Agent真的成为下一代人机交互的主要形态那么用户的大量请求会经由Agent转发给各种服务。这个过程中Agent的基础设施——尤其是工具调度和记忆层——就成了流量的分配层。掌握这一层的玩家实际上掌握了未来应用分发的入口。这和十年前移动互联网时代争夺应用商店的逻辑非常相似。第三个逻辑是生态锁定。这一点对开发者来说最切身相关。当你在某个平台上构建了Agent写了编排逻辑、设计了记忆存储结构、集成了它的工具生态日后再想迁移到别的平台成本会非常高。平台方很清楚这一点基础设施一旦被采用就形成了深度的绑定关系。2.2 隐秘战场的三个梯队虽然不点名具体公司但观察这个战场,基本能分出三个梯队它们的切入方式各有不同。第一梯队是底层资源型的巨头。这批玩家手里有大规模算力和云服务能力战略很清晰我不跟你们抢应用我先把“土地和水电”修好。它们提供GPU实例、模型托管服务、向量数据库、消息队列等一系列云上组件然后把这些组件打包成“Agent云服务”。对它们来说Agent Infra是云计算市场的新增长曲线。任何做Agent的公司无论用什么框架最后大概率都要跑在它们的基础设施上。第二梯队是模型和应用型的巨头。它们手里有用户入口和场景打法更加“接地气”。一边开源自己的Agent框架和工具生态吸引开发者一边在自己的产品里集成Agent能力产生示范效应。这类巨头切入的是“编排”和“记忆”这两个中间层因为这是离开发者最近、最容易形成依赖的部分。通过开源和产品双轮驱动它们试图成为事实上的标准制定者。第三梯队是开源社区和创业公司。这里面有老牌开源项目也有大量新兴项目。它们填补巨头们看不上的“细碎需求”比如专门做工具调用可靠性、专门做Agent可观测性、专门做多Agent通信协议。这个梯队的特点是迭代极快很多创新的最佳实践都是从这些小项目里长出来的然后被巨头吸收进自己的体系。2.3 这场竞争的“溢出效应”为什么对普通工程师是好事巨头打架表面上看跟普通工程师没关系实际上溢出效应非常明显。最直接的一点是大量原本需要自己从零搭建的底层能力正在被做成开箱即用的产品。我在两年前想给项目加一个记忆层需要自己部署向量库、自己处理 embedding、自己写检索逻辑前后花了好几周。现在云厂商直接提供托管的记忆服务几十行代码就能接入。这不是因为我变厉害了是因为巨头们把基础设施的价格打下来了。另一个溢出效应是开源生态的繁荣。因为巨头们都想抢开发者所以竞相把自家基础设施的核心模块开源出来或者大力赞助开源项目。这给我们带来了丰富的学习素材和直接可用的组件。以前想学分布式任务编排只能去看大厂内部的技术分享PPT现在开源的编排框架都写得明明白白读源码就能学到工程精髓。巨头竞争越激烈普通工程师的入场成本就越低。在它们把最后的“收门票”服务做好之前我们完全可以自己先搭建一套小规模的基础设施积累经验甚至把它变成职业发展中的独特筹码。3. 工程师的入场券从使用工具到构建平台3.1 明确入场位置先做用户再做构建者聊完宏观落到个人。普通工程师怎么进入Agent Infra这个领域我的建议非常直接不要一开始就想着“我要做一个平台”而是先成为一个重度用户再转型成为构建者。这中间的路径大概是这样的第一步用现成的Agent框架和云服务搭建自己的应用把每一个基础组件都真刀真枪地用一遍理解它们的优劣和限制。第二步当你用到不满足的点时——比如某个开源的记忆组件在高并发下性能不行、某个编排框架不支持你需要的分支逻辑——这时候你已经具备了“发现问题”的能力。第三步带着这些问题去读源码、写补丁、或者干脆自己造一个轻量轮子。到了这个阶段你实际上已经在做Agent Infra的构建了只是规模还小。我自己就是这样走过来的。最初我只是想在内部工具里加一个能自主查数据库的Agent助手。一开始用的现成框架跑通了。但很快发现两个痛点一是工具调用的错误处理不符合业务需求二是Long-running任务的状态管理太弱。为了搞定这两个问题我开始自己写一个小小的工具调度层和一个简单的任务状态存储。写着写着我发现自己做的东西已经可以抽象成一个通用的内部组件其他小组也开始拿来用了。整个过程没什么宏大开头就是从“用得不爽”开始的。3.2 一个最小可落地的 Agent 基础设施原型给一个具体可参考的落地案例。我帮某团队搭过一个内部知识助手Agent需求是员工可以问它公司政策、项目文档、IT流程等问题它能自动检索资料并回答同时能调用一个内部的工单系统来提交请求。规模不大并发几十但它覆盖了Agent Infra的核心环节。架构上我用了一个三层设计。第一层是模型网关统一对接模型服务方便后续切换不同的模型供应商同时实现请求级限流和成本统计。第二层是记忆与检索层对话历史存在关系型数据库里文档知识放到向量库里回答问题时先做语义检索再把结果组装成上下文。第三层是工具层把工单系统封装成一个标准工具定义了输入输出schema加上超时和重试逻辑。先看模型网关的简化代码重点是统一接入和成本统计# gateway.py — 模型网关的核心抽象 class ModelGateway: def __init__(self, providers: dict): self.providers providers # {openai: OpenAIProvider(...), local: LocalProvider(...)} self.cost_tracker CostTracker() async def chat(self, model_alias: str, messages: list, **kwargs): # 根据别名路由到具体模型供应商 provider, real_model self.providers[model_alias] start time.time() response await provider.chat(real_model, messages, **kwargs) # 记录每次请求的token用量和耗时用于成本归因 self.cost_tracker.record( aliasmodel_alias, modelreal_model, prompt_tokensresponse.usage.prompt_tokens, completion_tokensresponse.usage.completion_tokens, latencytime.time() - start, ) return response这个网关看着简单但它解决了几个实际问题第一业务代码不用关心底层到底用的哪家模型切换只要改配置第二每个请求的花费和延迟都被记录下来做成日报就能看到成本分布第三方便做限流防止某个业务线不小心把预算烧光。记忆层我用了“摘要细节”的两级方案。每当对话轮数超过阈值就把旧消息交给模型生成一个摘要存为长期记忆同时保留最近的原始消息。这样既控制Token开销又不丢失关键信息。这个方案的取舍在拉长会话场景里尤其重要具体计算后面第4部分会细说。工具层的实现则体现了一个容易被忽略但入坑极多的环节函数调用参数的严格校验。模型经常“编造”一些不存在的参数或者把参数类型弄错。所以我们的工具层在真正调用外部API之前先做一次schema校验不合格就返回错误信息让模型重新生成而不是把脏数据直接打到下游系统。3.3 技术路线图与学习优先级根据自己的学习经验和带人经验给一份分阶段的学习路线图适合从常规后端转过来的工程师。第一阶段夯实基础设施通用能力。无论做什么方向Agent Infra的底层还是传统后端技术。并发编程、缓存设计、消息队列、数据库索引优化这些基础中的基础一定要过关。很多Agent基建问题本质上是高并发和数据一致性问题的换皮表现。这个阶段看经典后端技术书籍和开源项目源码就够了不需要接触任何Agent特定概念。第二阶段专项攻Agent核心技术。重点学习四个模块任务是编排了解状态机、工作流引擎和重试策略第二是记忆系统看向量数据库的实现原理、Embedding模型的选择和混合检索策略第三是工具协议理解Function Calling机制、工具描述schema的编写以及工具调用的可靠性设计第四是评估与可观测学会怎么给Agent建评测集、怎么追踪一次完整调用链。这一阶段最好的学习方式就是读开源项目的源码尤其关注它们如何设计状态机和上下文管理。第三阶段平台化思维养成。当你会搭单个Agent后要开始思考平台问题多租户怎么隔离、权限怎么做、计费怎么实现、不同团队开发的Agent怎么共享记忆和工具。这个阶段的重点是抽象能力。我见过很多工程师能写好一个Agent但写不好一个Agent平台差距就在于有没有站在“多个团队使用”的角度做设计。学习节奏上我建议采用“21”模式两周学一个专项然后立刻动手做一个对应的小项目不要光看不练。比如学记忆系统就自己写一个带向量检索的聊天记忆模块学任务编排就做一个支持失败重试的定时任务Agent。亲身踩过一遍半年后再看这个领域你已经能读懂大部分基础设施的设计思路了。4. 实操中的硬骨头常见问题与排查记录4.1 状态管理一切“失忆”的根源Agent开发中遇到频率最高的坑就是状态不一致导致的“失忆”。我们之前做过一个报表生成Agent负责从多个数据源拉数据、汇总、生成报告。有一次线上反馈说Agent在生成了第一段报告之后突然开始重复刚才的步骤生成了两遍一模一样的内容。排查下来发现原因很典型Agent在生成过程中内存里的状态标记没有被持久化任务执行到一半进程重启在途的状态全部丢失重新拉起后它无法判断“我已经走到哪一步了”只能从头再来。解决方案是引入持久化状态机。把Agent的每一步执行结果都写入数据库每一步都记录前置状态和下一步候选动作。进程崩溃后重启Agent可以从最近一个成功状态继续执行而不是从头开始。实现上有两个细节需要特别注意一是状态写入要“先写后执行”不能先干活再补状态否则崩溃的时候状态还是旧的二是状态版本化每次更新都递增版本号防止并发情况下状态被旧请求覆盖。4.2 工具调用Agent 最容易翻车的地方工具调用是Agent和外部世界交互的窗口也是出错的重灾区大概分成三类参数幻觉、反复重试、安全越权。参数幻觉指的是Agent生成了一个看起来合理但实际上不存在的参数。比如一个工具接受department_idAgent基于对业务的理解“编造”了一个不存在的部门编号传进去。这种情况只能用严格校验来解决在调用真实API前用JSON Schema校验Agent生成的参数不匹配就让模型重新生成最多重试三次超过就放弃并告知用户。不要相信模型的自我纠错能力重复错三次的比率比我预想的高得多。反复重试是另一个典型问题。当外部API返回错误时Agent会倾向于用相同参数再次调用形成一个死循环。我们的对策是给每个工具调用设置最大重试次数并且强制要求“重试必须修改参数”不允许原样提交。还会引入幂等键保证同一任务请求在服务端只被处理一次。这两个组合拳基本消灭了工具调用死循环的问题。安全越权则更隐蔽。当Agent同时接入了只读查询工具和写操作工具时模型偶尔会“自作主张”地调用写工具做一些用户没要求的事。这个必须在基础设施层拦截在工具注册表里给每个工具标记操作等级只读操作可以放行写操作必须经过额外的用户确认环节。Agent的基础设施里安全边界不应该依赖模型的自觉性而应该靠机制强制兜底。4.3 上下文工程Token 消耗失控怎么办Agent跑着跑着Token费用突然飙升是很多开发者的噩梦。核心原因往往是上下文管理做得太粗糙。最典型的错误把整段对话历史从头到尾全部塞给模型随着轮次增加输入的Token线性增长成本也跟着线性增长。举个例子假设每次问答约1000 Token一个用户连续对话50轮完整历史就是50000 Token。如果用户量是1000人每一轮新问答都要带着50000 Token的历史一起发送这个成本是惊人的。问题还在于模型处理超长上下文的速度也在下降用户体验一并受损。解决方案是上下文分层。我在实践中用“摘要层最近消息检索层”的结构。对话进行到10轮以后把更早的对话缩成一个不超过500 Token的摘要替换掉原始聊天记录那些被压缩进摘要的细节如果后续问到通过检索原始记录来补充。# context_manager.py — 上下文压缩的简化实现 class ContextManager: def __init__(self, max_rounds10, max_summary_tokens500): self.max_rounds max_rounds self.max_summary_tokens max_summary_tokens def get_recent_messages(self, history): # 直接保留最近的max_rounds轮 return history[-self.max_rounds:] def get_summary(self, history, model_gateway): # 超出保留轮数的部分压成summary old_messages history[:-self.max_rounds] if not old_messages: return None summary_text model_gateway.summarize(old_messages, max_tokensself.max_summary_tokens) return {role: system, content: f以下是更早对话的摘要: {summary_text}} def build_context(self, history): recent self.get_recent_messages(history) summary self.get_summary(history, self.model_gateway) if summary: return [summary] recent return recent这样把输入Token从“线性增长”变成“轮回时重置”长期对话的成本从几十万Token降到几千Token量级。算一笔账就明白差距不做压缩的情况下50轮对话折合50000 Token做了压缩之后同样场景下只需约2000 Token。规模越大这个优化带来的节省越可观。4.4 Agent 评测比你想的更难也更刚需传统软件的测试对确定性逻辑很有效但Agent的行为充满概率性同样输入可能每次输出不同。这种不确定性对评测是一个真正的挑战。很多团队在Agent上线前不做系统评测直接靠“我觉得它表现还行”来做决策。结果一上生产环境各种边界情况开始暴露用户信任度被一次糟糕表现摧毁。我给Agent项目配置的是“评测集回归基线人工抽检”三层结构。评测集包括一百个左右有标准答案的任务覆盖典型场景和边界情况。回归基线则是每次改动后进行自动化跑批对比改动前后在评测集上的表现分数低于阈值就拦住发布。人工抽检则解决自动化评测覆盖不到的主观质量问题比如回答的语气、逻辑连贯性、是否误解了用户隐含意图。自动化评测的指标也会因场景而不同下面是我常用的几个成功率任务是否正常完成、工具调用准确率调用是否与预期一致、无效输出的比例模型胡言乱语或返回空内容的情况、单任务耗时和单任务成本。表格里总结的这些问题几乎是每个Agent项目都避不开的值得对照排查。4.5 常见问题速查表现象可能原因快速对策长期方案Agent执行到一半丢失上下文状态未持久化进程重启后丢状态加数据库快照重启后恢复最近状态引入持久化状态机步骤级记录工具被反复调用相同参数缺少重试上限模型在自我重复设置最大重试次数超过即终止强制重试必须修改参数引入幂等键Token消耗直线上升上下文未经压缩完整历史塞入限制输入轮数加上简单的截断摘要压缩滑动窗口检索补充Agent“编造”工具参数模型幻觉schema约束不足调用前做参数合法性校验用JSON Schema严格校验不合格重生成线上出问题无法定位日志缺失无调用链追踪给每次调用生成ID输出请求响应日志建立完整可观测体系对接日志平台多个Agent互相冲突共享工具没有权限隔离给工具打上只读/写操作标工具注册表权限模型强制鉴权评测不稳定、波动大评测集太小或任务设计模糊增加样本量重复运行建立规范评测集和回归基线写在最后的一些体会回看这两年做Agent相关项目的经历我自己最大的变化是从“追模型”转向“搭骨架”。模型迭代永远追不完但一套牢靠的Agent基础设施可以稳定支撑业务跑一年两年而且随着接入的业务越多它的价值越大。基建的投入不像换模型那样能立刻看到指标上涨它的回报周期长但一旦建起来抗风险能力完全是另一个数量级。对普通工程师来说我的看法是不用等巨头把全套基础设施做成傻瓜式服务再来学那时候入场券就真的只有“买票”一条路了。现在趁战场还在早期选择一个小切点比如把一个开源项目研究透、给自己日常用的Agent加上记忆层、把工具调用的错误处理做得比默认方案更健壮——任何一个都是入场的好姿势。踩过的那些坑、修过的那些状态丢失问题都是别人拿不走的经验也是你在下一次技术浪潮里最值钱的资产。