一个让我逐渐改变看法的片段去年有段时间我同时维护两个 Agent 项目一个跑在 A 方案上一个跑在 B 方案上模型的底座其实经常互换。做到后面团队里已经很少有人争论“哪个模型更聪明”了真正挡住进度的永远是另一些问题状态保存在哪里、工具调用由谁做权限校验、某次失败之后怎么重试、深夜跑挂的任务有没有人知道。这些问题放在一起就是我今天想聊的 Agent Infra——智能体基础设施。巨头们把这块地方当成隐秘战场逻辑很直接模型层正在变成可被替换的浮动引擎而数据、工具生态、运行时这些基建一旦被用户采纳就会长在业务里。对普通工程师来说这反而是入场券。你不是非要成为研究模型的人才能参与这轮 AI 落地把状态机、注册表、链路追踪这些传统工程能力迁移过来你已经站在牌桌上了。下面我会先讲为什么巨头抢的是基建而不是模型再把 Agent Infra 拆成五层接着用一个真实踩坑过程讲讲调试思路最后给出自建与买平台的决策框架。通篇没有厂商立场都是一线项目里验证过的经验。1. 巨头的隐秘战场模型会商品化基础设施不会1.1 模型层的拉平速度快于大多数人的感知我自己过去一年实测过的模型数量不少从闭源头部到开源权重从几百亿到上千亿参数都有。横向对比下来一个很直接的结论是头部模型之间的差距远没有发布会和营销话术传达得那么大。放到具体垂直场景里把不同版本的模型放到同一套测试集上跑分数差异经常只有几个百分点但 token 成本和时延的差别却非常明显。更重要的一点是某个模型的领先往往是暂时性的。这一代你领先下一代开源权重很可能追上来推理价格又在持续跳水。对技术选型来说这意味着模型层的“不可替代性”正在消失今天你选定某个底座明天就可能因为成本、时延或者能力变化换掉它。可问题也跟着来了当你想换底座时系统还换得动吗如果业务逻辑、工具生态、状态定义、评测集全都深度耦合在某一个平台上那你表面上是在买模型实际是被模型周围的一整套设施锁住了。大厂嘴上推模型心里想的其实是模型上方的基建。这才是“隐秘战场”真正的含义——模型发布会只是烟幕基础设施才是正面战场。1.2 应用层的窗口期在缩短抄完界面只算第一层说“应用层三个月就会被抄完”有点过于简单但它确实指出了趋势如果产品只依赖公开模型接口和一套通用交互 Pattern后来者用同样的路径完全可以快速复制。真正留得住用户的是你针对某个垂类业务过程的深度抽象比如工单怎么拆解、审批规则怎么落到状态机、不同系统的数据怎么去重和合并。这些业务抽象一旦沉淀成工具定义、存储结构和评测用例团队才算形成自己的竞争壁垒。反过来如果你只是把模型封装成一个聊天框再放几个提示词模板进去那用户对界面是没有忠诚度的。过两个月就会有人做出体验更顺滑、响应更快的替代品。很多团队把精力花在 UI 和提示词上恰恰是押错了地方。应用层竞争最终会被迫往纵深走这个纵深的载体就是基建。1.3 真正的锁定来自数据闭环、工具生态和运行时我观察下来巨头争夺的焦点可以归纳为三块。第一是数据闭环用户与 Agent 交互会产生大量真实轨迹这些轨迹是优化系统、构建评测集、发现边界问题的原材料。第二是工具生态一套统一的接入协议让 Agent 能连接企业内外的各种系统谁吸引的开发者多谁的工具生态就厚。第三是运行时执行环境里对并发、超时、重试、权限、审计这些能力的原生支持程度。这三点有个共同点它们都不是一次性模型调用能完成的而是要长期驻留在你的系统里。一旦沉淀下来迁移的心理成本和工程量都会非常大。反过来如果这套设施做成了开放标准和 SDK就会吸引大量工程师在其上开发从而让生态滚雪球。资本和工程资源自然会持续涌向这个隐秘战场——它没有模型发布会那么抓眼球但决定了未来十年开发者默认在什么地基上盖房子。2. 拆开 Agent 基建的抽屉柜编排、记忆、工具、可观测性、安全与其用很玄的概念讨论 Agent Infra不如直接打开工作台上的五个抽屉。任何正式上线并运行一段时间的 Agent 系统都躲不开这五层。每一层都不需要多么黑科技但每一层做不好Agent 都会从“可用”跌到“难受”。2.1 编排层从线性链到状态机新手 Demo 最常见的形态是一条链先让模型拆解问题再调用工具最后生成回答。演示阶段没有问题业务一复杂就露馅分支逻辑完全交给模型自由发挥中间任何一步失败整条链就没法回滚。我更推荐把编排写成状态机模型只负责在几个可行节点之间做选择而状态回退、超时、错误跳转都由代码控制。你可以把它类比成一个审批流负责人可以决定下一步走到哪个节点但“谁有权审批”、“超时后自动转给谁”、“驳回回到哪一步”这些规则由系统而不是某个临时工说了算。状态机加循环是目前可维护性最好的组合未来要加并行分支或者人工审核节点也不会推翻重来。2.2 记忆层上下文窗口不等于记忆上下文窗口充其量是一张随机访问的短期便签纸。很多人习惯把所有历史都塞进 Prompt结果 Agent 跑不到多少轮就开始“失忆”——不是模型变笨了是上下文里堆满了冗余信息早期的重要细节被淹没。生产级系统应该把记忆拆成三层对话缓冲只保留最近一小段关键中间结果做结构化摘要长期业务状态落到存储里。这里提醒一句向量库不是唯一答案甚至不应该是默认答案。如果任务元数据比较规范用一张 SQL 表做检索又简单又可靠只有在确实需要按语义相似度召回历史记录时才引入向量索引。我曾见过一个项目为了解决“存储历史”的问题硬上了向量库最后查询准确率和排查成本都很难受本质上是用错了工具。2.3 工具层工具注册表才是真正的入口Agent 的“手脚”是工具而工具不是散装函数。生产环境里每个工具至少需要四个部分唯一且语义化的名称、可解析的参数 Schema、给模型看的自然语言描述、返回结果格式约定。这四部分加在一起相当于为模型提供一份接口契约。否则模型面对一个含糊的工具说明只能在猜。工具注册表还承担动态暴露的职责根据当前状态决定把哪些工具放进候选集避免模型在几十个工具里挑花眼同时负责参数合法性校验并且把每次调用记录下来。当你的 Agent 要连十几个内部系统时工具注册表的好坏会直接决定用户体感这比纠结模型聪明不聪明重要得多。2.4 可观测性层看得见每个决策点Agent 调试难很大一部分原因是看不见。用户问“为什么你没把会议订上”你翻聊天记录根本看不出中间经历了什么到底调了哪个工具、返回了什么错误、模型为什么中途放弃。只有链路追踪能回答这些问题。一次任务对应一个 request_id每一步都记录模型输入输出、工具入参出参、状态迁移、重试次数和 token 消耗。你可以把它理解成后端的分布式 Tracing 加上了“决策轨迹”。这不是奢侈品而是排障的底线设施。没有 trace 的项目出问题时只能靠猜猜的次数多了团队就会把所有问题归咎于模型然后陷入换模型的风火轮。2.5 安全与权限层最小权限再加审批门Agent 越强大越容易在权限上翻车。最常见的设计错误是前端把管理员凭证直接交给 Agent 工具简化实现却忽略了一个基本问题——模型不可信。一次构造巧妙的 Prompt 注入就可能让 Agent 调用任意高权限操作。生产环境必须做三件事工具声明最小权限范围比如“读工单”和“删工单”是两把不同的钥匙高危操作需要人工审批门每次工具调用都保留审计记录。这其实和其他后端系统的权限模型一脉相承只是多了一个必须默认模型不可信的前提。我见过太多团队把安全排在“跑通再说”的位置等到线上出事才回头补代价通常远高于预期。下面是五层基建的快速对照表适合在团队选型和复盘时直接引用层级入门做法生产级做法最容易踩的坑编排线性链状态机 循环分支全部交给模型崩溃无法回滚记忆全部塞进上下文缓冲 / 摘要 / 长期存储三层窗口塞满早期信息丢失工具散装函数注册表 校验 动态暴露模型拿错参数调错系统可观测性打印日志请求级链路追踪出了问题无处查起安全复用登录令牌最小权限 审批 审计一次注入打穿整个系统3. 从“模型不够聪明”到“系统太脆弱”一次客服 Agent 的排查链路我记忆最深的一次调试发生在某个客服场景的 Agent 项目上。知识库和工单系统都接好了表面看功能完整但线上表现一直不稳。团队前两周每天都在怀疑模型版本不对后来我们把链路一层层加上日志把多个失败样本拉出来逐条看才发现真正的问题都出在基建层。这里我把排查链路完整写出来你很可能也会遇到。3.1 第一个坑上下文爆炸导致模型“变笨”失败样本的第一个特征是模型越到对话后期越答非所问。把请求体拉出来一看三十五轮历史全在里面其中还夹杂着大段数据库查询返回的原始记录。模型不是变笨而是要在几千 token 的噪音里找重点找着找着就丢了。我们当时的修复方式很朴素对话缓冲只保留最近两轮历史关键信息做成结构化摘要需要详情时让 Agent 按 ID 再去查一次。改动后同样的测试集准确率直接上了一个台阶而这和模型一点关系都没有纯粹是记忆层设计不合理。3.2 第二个坑工具命名含糊导致模型拿错工具客服场景里有两把工具一把叫“查订单”一把叫“查售后单”。在参数 Schema 里两者的字段都叫“单号”连类型都一样。模型经常把售后问题查成订单返回一堆看似正确却对不上的信息。用户看到的结果就是模型一本正经地说了一个错误答案。问题不在模型而在于工具契约写得不够清楚。我们做了三件事把工具改名为“查询订单基本信息”和“查询售后处理进度”明确边界在描述里补上典型的适用场景给参数加枚举和格式示例。模型再没有在这两个工具上混淆过。工具说明不是给人看的文档而是给模型看的路标。3.3 第三个坑异常被模型当成正常内容讲给用户有一次第三方系统限流接口返回了 429。工具函数把这个结果当作正常返回值交回给模型模型理解成“当前访问人数较多”然后很贴心地替系统向用户致歉。这个问题极具迷惑性因为从用户视角看模型是在理解情况实际上是把基础设施的异常当成了业务信息。修复方案是给工具返回值建立统一结构正常结果、可重试错误、不可恢复错误三类。凡是异常都不允许模型自由发挥而是走固定的错误分支由代码决定是否重试或人工兜底。模型只对“业务问题”负责不为“系统故障”编解释这是 Agent 稳定性的关键边界。3.4 第四个坑没有回归集改一个地方崩一片修完上面三个问题之后我们以为可以收工了结果在验证时发现另一个老功能坏了。原因是改了工具描述影响了模型在其他场景里的选择。这时才意识到项目从头到尾没有一套标准评测集。后来我们补了三类用例单步测试固定输入看模型是否选了正确工具多步任务测试看完整场景的状态回退与工具协作回归集把历史上出过错的所有样本都存下来每次改模型、改提示词、改工具描述都自动重跑一遍。有了回归集团队才敢放心做后续迭代否则每次修改都是在拆东墙补西墙。4. 工程师的入场券不用卷提示词去卷可维护的 Agent 系统很多人以为参与 Agent 时代要先去学各种提示词技巧或者去追最新的模型动态。我的观点恰好相反入场券的本质是“让 Agent 稳定工作的系统能力”这门手艺不新甚至有点传统。4.1 后端工程的老经验八成可以直接迁移Agent 执行过程可以看作一个高度分布式的任务系统要调用外部服务、要处理超时重试、要保证状态一致、要做身份权限控制。这些全是后端工程里反复锤炼过的老问题一个都没少。差别只在于核心决策单元从一个确定性的函数变成了一个有概率性的模型调用。所以懂得给外部 API 设计超时、重试、降级策略的人只需要把同样的思路移到工具调用上懂得给分布式请求做 Trace 的人做 Agent 链路追踪不会有太大违和感。你不是从零开始你只是在补一层“面向概率系统”的思维。这一层说难不难不要再默认同一个输入一定得到同一个输出仅此而已。4.2 提示词不是话术而是接口契约把提示词当作文案去写是很多项目失控的开始。更稳妥的姿势是把它当作代码来维护系统提示词定义前置条件和行为边界工具描述对齐业务语义关键输出一律用 JSON Schema 约束。模型输出只要不符合结构就自动重试或请求重新生成而不是放任它自由发挥。我常用的习惯是所有关键输出都加校验规则字段缺失或类型不对就进入重试逻辑。这样一来模型的文本产物会变成一个符合预期的结构化对象和程序里的状态数据顺畅对接。提示词的每一句都应该能回答两个问题我为什么要这样写如果删掉会发生什么做不到这一点的提示词本质上是不可维护的。4.3 用三层评测代替“肉眼感觉还行”Agent 项目的评测不能靠感觉必须有自动化手段。单步评测固定一个输入看模型在这一步是否选对工具、参数是否合法多步任务评测跑通完整场景验证工具协作和状态流转回归评测把过去所有出错样本集中起来每次改动后自动重跑确认没有修一处坏一处。这三层评测的搭建成本并没有想象中高核心难点在于坚持项目刚起步时就要保存错误样本而不是等出了问题再回头翻日志。评测集不是可选项也不是后期补的它应该是和代码同步生长的资产。没有评测集Agent 迭代就会退化为人肉试错模式。4.4 运营纪律日志、指标、告警、成本线上 Agent 一定是要盯运营的。我看到过不少项目半夜无人值守时 Agent 跑挂第二天早上用户投诉才被发现。真实环境里至少有四件事要做记录链路日志、统计成功率与平均轮次、配置异常告警、核算 token 成本。告警阈值不用复杂连续失败超过 N 次就触发Agent 循环超过 M 分钟自动熔断即可。成本也要纳入日常视野Agent 的平均轮次一旦失控token 开支会指数级上升这不是小事。稳定性与成本都可视化之后Agent 才真正从“能跑”进入“能运营”的状态。5. 自建还是接入现成平台给个人和团队的选择框架聊完基建的五层回到一个很现实的问题这些能力究竟是自己搭还是直接买现成平台我的看法是不要非黑即白而是按“是否构成你的竞争力”来分层决策。5.1 三个问题判断边界第一这一层是否是我产品差异化的核心如果是比如你对某个垂类业务做了非常深的工具定义那就值得自建如果只是通用能力比如调用模型做摘要直接买更合理。第二这一层是否还在快速变化且难以标准化如果底层引擎随时可能换代采用成熟平台反而能让你跟上变化。第三如果放弃自建省下的维护时间能不能换来更核心的进展按这三个问题做判断通常会得到一个比较稳定的结论业务模型、工具定义、评测集自己要建因为它们直接承载业务逻辑底层执行引擎、基础存储、云端推理交给平台因为它们不属于你的核心竞争力而且维护成本很高。5.2 最小自建组合从本地能跑开始对个人开发者或小团队我建议从一个很小但是端到端闭环的组合开始一个关系库保存状态一个声明式工具注册表一个状态机性质的控制循环再加一层外部服务模拟。这套组合大概一周可以搭完足够支撑一个中等复杂度的 Agent。关键动作是“契约先行”先把工具结构、记忆结构、回退行为定义成文档代码只是按文档实现。这样坚持的好处是将来不管迁移到什么平台你的业务抽象和评测集都能够带走真正被换掉的只是执行引擎。很多团队一上来就铺大平台结果业务还没有跑顺反而被平台的功能边界牵着走。5.3 在平台之间犹豫时优先选择开放生态和标准协议当你同时面对两个候选平台我会建议把“开放程度”放在很高的优先级。模型能否通过统一接口替换工具调用协议是否对外开放日志和评测数据能不能顺利导出这三个问题比所谓的“内置功能丰富”更重要。封闭平台初期的顺滑体验很有迷惑性但你的数据和工具生态会越嵌越深等到想迁移时沉没成本足以让你放弃离开。开放生态往往意味着初期要自己处理一些琐碎细节但换来的是长期选择权。对工程师个人来说选择权尤其值钱它意味着你的技能和项目资产不绑定在某一个特定平台上而是跟着可迁移的契约走。5.4 先做小闭环不要急着模仿大厂最后一条建议也是我最想说的不要从一开始就模仿大厂搭整套控制台也不要预设自己要管理上千个 Agent。先做一条端到端最小闭环一个业务场景、两个核心工具、三个关键状态、四种异常处理路径。跑顺之后再把抽象一层层抽出来。我见过太多团队把时间耗在追风口和搭大平台上面最后没有一个场景是真正稳定的。反过来那些先把一个闭环打磨到能稳定跑通、能自动评测、能快速排障的小项目反而在后来拿到了更多机会。地基这件事没有捷径但有顺序。我自己现在的习惯也一直在简化每接到一个新的 Agent 需求先是纸面画状态机再写工具清单和评测用例最后才去碰代码和模型配置。这个顺序让项目少走了很多弯路。市值也好巨头厮杀也罢离普通工程师都很远真正离你近的是你桌上那个能随时看状态、能安全调工具、能离线复盘的自治系统。把这套东西打磨上手Agent Infra 这场隐秘战你手里的入场券就算真正生效了。