Agent Infra：从单体智能体到生产级Agent基础设施的工程化指南

今年让我真正觉得 Agent 开始从“玩具”走向“工程”的不是某个模型又刷了多少排行榜分数而是 Agent Infra 这个词开始频繁出现在架构评审和内部技术周会上。过去一年里几乎每一家做 AI 应用的公司最后都会撞上同一个瓶颈单体 Agent 靠提示词堆出来的“智能”根本撑不起生产环境。真正决定上限的是模型外围那一整条基础设施链——工具调用、记忆、权限、观测、成本控制。这些东西聚在一起就是 Agent Infra。这篇不是概念科普是我折腾 Agent 工程化一年多之后的底层笔记。我先把 Agent Infra 到底在解决什么问题讲透再拆开它的核心模块接着聊聊为什么各家头部玩家都在悄悄押注这个方向最后给出一条普通工程师能直接上手的入场路径。适合两类人一类是做 AI 应用、总在 Agent 上线边缘反复摩擦的工程师另一类是关心下一代平台机会在哪的从业者。1. Agent Infra 到底在解决什么问题1.1 从“单体 Agent”到“Agent 基础设施”的演进Agent 这个词在技术圈已经火了两三年但对它的理解其实一直在变。最早的“Agent”很朴素一个系统提示词、一个模型接口、再把任务文本塞进去模型输出什么就是什么那叫“提示词应用”不叫 Agent。后来大家发现单轮生成搞不定真实业务流程于是给它加了工具调用能力让它能查数据库、调 API、操作浏览器这算第二代 Agent——“会干活的 Agent”。再往后业务复杂度上来以后一个 Agent 不够用了需要多个 Agent 分工协作、互相传递状态还要能被人管理、审计、回滚这就到了第三代Agent 开始成为需要被“托管”的一等公民。这第三代就是 Agent Infra 出现的时刻。它的定义并不玄学Agent Infra 是支撑 Agent 设计、部署、运行、评估、迭代的一切基础设施。包括模型接入网关、工具注册中心、记忆存储、编排框架、权限体系、链路追踪、评估集、成本计量。你可以把它理解成“Agent 时代的容器编排平台、网关、监控和权限中心的组合”不是某一个产品而是一套组合。为什么要用类比因为 Agent Infra 跟前些年云原生那波基础设施实在太像了。云原生出现之前每个后端服务要自己处理注册发现、熔断、限流云原生出现之后这些都被收编进容器平台和微服务体系。Agent 领域也一样现在每个团队在自己手搓工具调用、手写上下文拼接、手工统计 token 成本过几年会被统一的 Agent 运行时收编。这里面的机会就是你现在手里的入场券。1.2 光有大模型Agent 为什么跑不起来这是个被问烂但很多人没想透的问题既然大模型这么聪明为什么不直接用模型当 Agent答案是不行因为模型只是“脑子”没有“神经系统”。先看记忆。很多时候你以为模型“记得”前面聊过什么其实它只是在一个有限的上下文窗口里看到前面的词。窗口不是档案室窗口是白板。白板写满旧内容就被擦掉。你需要一套记忆系统决定哪些内容值得长期保留、哪些转成摘要、关键时刻怎么把它“贴回”上下文。这些跟模型能力无关是工程问题。再看工具。Agent 要真正产生价值必须执行动作查库存、发邮件、改工单状态。每个动作背后都是真实系统的接口有鉴权、有参数校验、有限流、有幂等要求。把工具接入 Agent 很简单难的是让 Agent 在几百个工具里选对、用对、且不出安全事故。这又需要工具注册中心、权限边界和调用审计全都不是模型能自己解决的。还有可观测性。一个写代码助手在第五轮才失败错误埋在上下文深处模型返回来一段人模人样的“抱歉我无法完成”。没有 trace你只能靠猜。传统日志只能记录你写的那次请求Agent 的一次任务会拆成多次模型调用、多次工具调用、多个智能体协作记录粒度必须在“任务级”而不是“单次请求级”。这是传统基础设施没有的维度。最后是钱。Agent 的一次真实任务往往要消耗数万甚至数十万 token如果设计和降级策略不对一个不起眼的客服机器人一个月能烧掉比服务器贵得多的账单。成本控制严格来说不是功能但它是生产环境能不能走下去的前提。所有这些构成了 Agent Infra 要解决的完整问题域。1.3 Agent Infra 和传统后端基础设施的本质区别有人会问这不就是把微服务、网关、日志那套搬过来吗差得远。区别有三点。第一调度对象不确定。传统网关调度的请求是确定的一个 URL、一组参数、提前定义好的响应。Agent 编排层调度的是一次“意图”结果可能是走工具 A 也可能走工具 B失败的定义也不再是“返回非 200”而是“任务目标有没有实现”。这要求基础设施层面的评估、重试、补偿逻辑都围绕任务语义设计而不是 HTTP 状态码。第二故障模式更深。传统系统故障通常是宕机、超时、5xx能快速定位。Agent 系统最常见的故障是“看似成功实则失败”模型给了一句正常回复但那句话里的数字是编的、或者某个 Action 执行了两次。这种故障藏在语义层不靠可观测性和评测集根本发现不了。第三权限对象变宽。传统权限是“用户能不能访问这个接口”Agent 时代变成“这个 Agent 实例能不能在满足某种策略的前提下调用某个工具的某个方法”。而且工具权限还要和模型自由度联动模型不是人不能靠“告知”来约束只能靠“不给你钥匙”来约束。这些都是基础设施层的新设计空间。所以别把 Agent Infra 当成旧基建的换皮它是一个新问题域也因此孕育了新的工程师机会。2. Agent Infra 的核心模块拆解2.1 工具注册与统一协议让 Agent 长出“手脚”的关键一环工具层是 Agent 行动能力的载体。一个合格的工具接入层至少要做四件事注册、发现、执行、审计。注册负责收集工具元数据包括名称、描述、参数 schema、鉴权信息发现负责在模型决策时把候选工具列表喂进去执行负责真正调用背后的 API审计负责记录谁在什么时候用了哪个工具、用了多久、结果如何。注册这里有个很多人忽略的细节参数 schema 里“描述”字段的质量直接影响模型选工具的成功率。我之前见过一个团队把日期参数写成“date”模型总是填成昨天改成“订单创建日期格式 YYYY-MM-DD默认取当天”之后准确率立刻涨了一截。工具名也要带命名空间比如“order:create”而不是“create”避免几十个工具都叫 create 时模型懵掉。工具协议也正在快速统一。现在社区里最受关注的是 MCP也就是 Model Context Protocol模型上下文协议可以理解成“工具界的 USB-C 接口”。它的思路是把工具和资源定义成统一格式模型端和应用端通过这个协议对话整套生态就能互相兼容。已经有不少主流框架把它作为默认的工具接入标准。对普通工程师来说理解 MCP 背后的抽象思想比背协议细节更重要一次实现、多处复用这是基础设施价值最直观的体现。2.2 记忆分层与上下文拼接别把白板当档案室记忆系统的设计直接决定 Agent 的“人设连续性”。我把记忆拆成三层来看。短期记忆是当前任务窗口内要用的信息。最常见的实现是滑动窗口加摘要压缩保留最近 N 轮原始对话更早的内容用一次模型调用压成摘要随请求带着走。这个策略成本可控效果也够用。如果任务时间线特别长还可以引入“关键时刻”标记把用户明确表达过的偏好、承诺过的截止时间等关键信息单独存下来每次进上下文。长期记忆要解决跨会话的持久化。偏好设置、历史交互记录、用户画像适合落 KV 存储或向量库。RAG 的成熟度在这里可以直接复用把长期事实切块、向量化在相关时刻检索 topK 拼进提示。注意不要把整个知识库都塞进去检索质量比覆盖度重要一次检索到七八条高质量片段比塞进去三万字还管用。工作记忆是任务状态机。比如一个改地址的客服任务Agent 中途可能查了订单、核了身份、改了地址、发了确认邮件。每一小步的状态、依赖的数据、未完成的条件需要一套显式的任务状态管理否则多轮对话一旦中断整个流程就塌了。这部分很多开源编排框架都在做但生产环境建议还是自己掌控。2.3 多智能体编排哪些场景真需要哪些是自找麻烦单 Agent 能解决 80% 的问题但有些场景必须是多智能体比如“分析财报写新闻稿”这种任务让一个 Agent 同时做分析和创作Prompt 会互相打架。多智能体的价值是职责隔离、专家化。编排模式主要有四种。链式编排最简单A 的产出当 B 的输入适合流水线任务比如“提取→翻译→校对”。路由编排是让一个调度器根据输入分流到不同专家 Agent比如先判断是不是售前问题再转到对应处理人。主管/执行者模式适合复杂任务一个管理 Agent 负责分解任务、调度若干执行 Agent执行 Agent 回传结果管理 Agent 做质量把关。黑板模式适合多个 Agent 并行写一块共享内存互相更新适合开放性创作。听着越复杂的编排越高级我反而建议克制。每引入一个 Agent就多一层决策延迟和错误传播。在同一个模型能力下单 Agent 加五个工具能解决的就不要上三个 Agent。真要多 Agent优先保证“信息传递的显式化”也就是 Agent 之间的消息要么是人可读的输出要么是结构化的数据别搞成黑盒聊天。编排器本身要有“停止条件”否则一个任务会无限互相抄作业。2.4 可观测性与评测集为什么没有这两样就管不住 AgentAgent 系统上线第一天起就要同时建两条线观测线和评测线。观测线解决“当时发生了什么”。单次模型调用的日志远远不够需要任务级的 trace把一次用户请求产生的所有模型调用、工具调用、Agent 间消息串起来记录每次输入输出的快照、token 数、延迟、成本和模型版本。这里强烈建议一开始就存全量决策轨迹哪怕只是结构化 JSON 落库。将来训练路由模型、做回归推理、复盘线上事故全靠这些数据。评测线解决“这样做到底好不好”。最常用的方法是准备一个 Golden Set也就是一批覆盖主要业务场景的回归用例每次修改 Prompt、工具 schema、编排逻辑之后全量跑一遍用一组固定指标比对结果。指标可以不复杂准确率、完整率、格式合规率就够了。LLM-as-judge 流行因为它能做语义级对比和打分但一定要定期人工抽样校准否则裁判模型自己也会漂移。这两条线是 Agent 工程化的分水岭。见过不少团队兴奋地跑通 Demo然后直接在线上改 Prompt改完也不知道有没有变好一个版本一个样最后干脆回滚。有了 trace 和 eval你才能像做传统软件一样对 Agent 做版本管理。2.5 权限模型与成本路由上线前必须想清楚的兜底设计Agent 带来的安全问题和传统系统很不一样。危险不仅在于越权还在于“模型被诱导越权”。工具提示注入是现在最常听到的攻击方式外部文档、邮件正文里藏一段恶意指令模型读进去后可能把它当成系统指令执行。解法不是靠模型自觉而是基础设施层做强制控制敏感工具不给模型直接调用的钥匙而是返回一个“需要人工确认”的中间态让人审批后再执行。权限设计我建议按最小权限原则落到工具级。一个做客服的 Agent可以只授“读取订单”和“提交工单”两个工具不授“修改订单状态”。如果业务需要修改单独开一个带审批流的工具。审计日志要记录每次工具调用的人或会话、原因、结果方便出事回溯。成本控制是 Agent 基建里最容易被低估的模块。我的做法是建立模型路由简单问题走快而廉价的模型复杂问题才上旗舰模型再加一次性任务 token 上限跑超了就截断并标记人工介入最后做月度成本按业务线分摊报表。这些做到位一个 Agent 产品的毛利结构才能看。3. 为什么巨头把这当成隐秘战场3.1 入口之争谁定义下一代应用的开发范式很多人观察 AI 赛道注意力都放在“谁家模型分高、谁家 Agent 产品好用”上但各大厂商真正在私下较劲的是“开发者用谁家的工具链来构建 Agent”。这东西历史上叫平台现在叫 Agent Infra。道理很简单。当应用开发者习惯了某个框架的思维方式、工具生态和部署方式切换成本会非常高。云原生时代就是这样一开始各家都只是卖虚拟机后来谁定义了容器编排和微服务最佳实践谁就掌握了开发者心智。Agent 时代在重演这个剧本。现在各家都在推自己的 Agent 框架、工具协议、运行时就为了在标准尚未固化时抢到定义权。对头部玩家来说这个战场“隐秘”是因为它不面向公众。普通用户看到的是聊天机器人、AI 助手而幕后是模型推理集群、工具网关、评估平台、开发者社区。但研发资源投入比例是公开的秘密投入在“模型能力”和“基础设施”上的比例已经从早期的十比一变成现在的五五开甚至倒挂。3.2 从卖 API 到卖 Infra利润率与锁定效应单纯卖模型 API 是很辛苦的生意推理价格战一轮接一轮毛利薄而且用哪个模型客户随时可以切换。如果把重心放在 Agent Infra 上情况完全不一样。因为一套成熟的 Agent 基建往往跨多模型、多工具、多数据源客户一旦在上面跑起业务迁移不是改一行代码而是重构整个编排逻辑。商业模型也随之变化。模型收费是“按 token 计费”Agent 平台可以按“任务数”“坐席数”“工具调用量”计费客单价更高、黏性更强。更重要的是数据飞轮每一次 Agent 运行的决策轨迹都在积累平台用这些轨迹做评测集、做护栏调整、做模型能力瓶颈分析。这些数据比模型权重更稀缺因为它们直接代表真实用户场景。所以巨头做 Agent Infra不是一时冲动而是看到基础设施层具备“平台型生意”的所有特征高粘性、网络效应、数据积累。这也是为什么这个战场看似低调抢的却是最值钱的位置。3.3 为什么这场仗还没打出明确胜负如果你以为巨头下场早战局应该定了那就错了。Agent Infra 到现在还在“百家争鸣”有几个深层原因。标准没定。工具协议、编排抽象、Agent 记忆接口都还没有像 HTTP、SQL 那样被公认的共同标准。各家抢推自己的标准本身就说明标准还在流动。换个角度这正是工程师的机会——谁先做出了被广泛采用的标准实现谁就站在浪潮之巅。用户习惯没定。今天的开发者画 Agent 架构图时仍然各画各的。有人喜欢声明式配置有人喜欢代码编排有人喜欢低代码画板。这种“开发范式”的未定型意味着现在建的高楼可能过两年就要拆。这时候抢先定义“最顺手的范式”就是在提前卡位。另外一个原因是Agent 技术本身还在快速演进。多模态、超长上下文、推理成本下降都会改变上层架构最合理的形态。过度押注某个编排方案可能成为包袱。所以巨头们现在的普遍姿态是重兵投基础设施能力但对“标准答案”保持开放等生态跑出方向再收口。3.4 对普通工程师的连锁影响这场巨头博弈普通人为什么会感受到最直接的信号是招聘市场。现在打开招聘软件Agent 平台工程师、LLMOps 工程师、AI 基建工程师的岗位数量在快速上升。而且这些岗位大量向传统后端工程师、运维工程师、数据工程师敞开因为能力栈高度重合只要你会 RAG、懂服务治理、熟悉性能优化稍加训练就能切入。更深的影响是技能价值迁移。过去几年模型训练相关的技能最热门但普通工程师很难挤进去。Agent Infra 给了另一条路它需要的是工程能力不是研究天赋。一个能把 Agent 稳定性做到高可用、把成本降一半、把权限模型设计清楚的工程师价值必定超过一个只会调 API 写 Demo 的人。巨头越卷标准缺口越大留给普通人的填充位就越多。4. 工程师的入场券从使用者到建设者4.1 入门技能栈先补这三块不用卷模型微调很多人问我入局 Agent 是不是要去学模型训练我的答案始终是不用也不需要。Agent Infra 需要的技能栈跟传统后端工程师的重叠度非常高。我认为最先要补的是三块。第一LLM 应用开发基础。至少要非常熟悉消息格式、Function Calling、token 计算、温度与采样参数。不需要懂模型内部实现但要能解释“为什么这个任务要用流式输出”“为什么这个工具的 json schema 写不好模型就调用错”。这部分花几周就能完成。第二可靠系统设计。重试、幂等、限流、降级、链路追踪这些传统微服务的老手艺现在原封不动迁移到 Agent 编排里而且更加重要。举个最常见的例子工具调用超时后到底重不重试如果不做幂等键一次扣款请求可能被执行两次。能写出“任务级幂等 指数退避 最终补偿”的人在公司里直接能当 Agent 基建负责人。第三数据工程基础。RAG 要求你会文档切块、向量检索、相似度调参评测集要求你会构建数据集、设计指标、做回归比对。这些技能在学习材料里永远比模型调优少但实战中永远不够用。4.2 第一条入场路径当重度使用者把 Agent 用到“痛”入场最没有门槛的一步是自己把一个 Agent 用到“痛”。建议选一个真实高频的场景比如“搭个人知识库问答”或者“给聊天助手接上日历和邮件”。选开源框架能省很多体力但真正有价值的是做这几件事记录一次完整任务消耗了多少 token、多少工具调用观察模型在什么情况下会选错工具亲手给工具写一份规范的描述试几次改一改。这个过程里你会迅速建立对 Agent 系统的“体感”。等踩过“上下文塞太多反而答错”“工具返回字段不齐导致模型瞎猜”“重试让同一个操作执行两遍”这些坑之后再看行业里的技术方案你会立刻明白别人在解决什么。4.3 第二条入场路径从开源小 PR 攒行业可见度想快速积累可展示的成果参与开源 Agent 项目是最短路。但我不建议一上来就憋一个大功能容易把自己劝退。先找文档、示例、测试覆盖这些“看起来不性感但很需要”的活。更有效的方式是带着具体场景去贡献。比如你在自己的 Agent 项目里发现某个框架对“订单日期”这种中文日期解析总出问题你可以写一个解析增强模块提上去。这类 PR 有明确而具体的问题背景维护者容易 review合并率也高。连续几个这种小 PR 之后你的名字会出现在贡献者列表里也就有了行业可见度。顺便说一句多写复盘文章也有用。把踩坑记录整理发布虽然不直接产生代码但能让别人在搜索时看到你的思考。基础设施圈子重口碑重长期积累。4.4 第三条入场路径在团队里做“内部 Agent 平台”的小闭环如果你已经在公司做业务系统后端最现实的高速路是找一个高频、低风险、价值显性的场景搭一个内部 Agent 服务把“工具接入、权限、日志、评估”这四个能力做成可复用的内部组件。我见过不少团队这么干先是客服工单分类后来扩展到运维问答、代码审查建议。第一步往往很朴素一个模型接口、一个工具注册表、一个简单管理后台。关键是你要刻意把通用的部分抽象出来做成组件而不是把业务逻辑写死在某个 Agent 里。等第二个、第三个场景接上来你手里这套东西就从脚本变成了平台。内部平台要注意数据安全能私有化部署的模型服务优先敏感数据不要出内网。做平台最大的风险是没人用所以第一个场景最好找一个需求最明确、日常抱怨最多的部门让痛点替你说话。4.5 心态建议像看云计算早期一样看待这个机会最后说心态。现在 Agent Infra 很像 2010 年左右的云计算技术方向已经清晰标准和最佳实践还在形成大厂重兵投入普通人焦虑但不知道从哪下手。回头看那批最早把“容器化、服务发现、监控告警”研究透的工程师后来都成了基础设施领域的硬通货。基础设施型技能的复利很大但成长曲线是慢的。你学的可能不是下一个热门框架而是“如何让一个概率系统稳定运行”的通用方法。这个能力在 Agent 时代管用在自动驾驶、机器人、复杂自动化等其他领域一样管用。所以别焦虑错过某个新模型踏实把基建问题啃下来时间会给你回报。5. 最小可用 Agent Infra 的落地实操5.1 场景选型给自己搭一个“会议纪要 Agent”纸上谈兵没意思我拿一个自己实际做过的场景当例子会议纪要 Agent。需求很明确输入会议文字稿输出结构化纪要包含主题、决策、行动项每个行动项自动创建任务并给负责人发一封邮件提醒。选这个场景是因为它麻雀虽小五脏俱全有长文本输入需要摘要和抽取有结构化输出需要格式约束有外部动作建任务、发邮件需要工具调用还有状态管理需求一件事可能跨多轮确认。搭完这个大部分 Agent 基建问题你都会碰到一遍。5.2 模块一工具注册中心的实现场景定了第一件事是给 Agent 定义它能用的工具。在这个最小系统里我定义两个工具create_task 负责根据行动项创建任务send_email 负责给负责人发提醒邮件。工具定义我习惯用 JSON Schema因为它既是人可读的也是模型能直接消费的格式。下面这段是我实际调试过、最终稳定下来的一份定义{ name: create_task, description: 根据行动项创建一个待办任务返回任务ID, parameters: { type: object, properties: { title: {type: string, description: 任务标题不超过80字}, owner: {type: string, description: 负责人邮箱前缀比如zhangsan}, due_date: {type: string, description: 截止日期格式YYYY-MM-DD今天之后} }, required: [title, owner, due_date] } }这段 schema 看着简单但里面每个描述字段都是踩过坑之后写的。owner 写成“邮箱前缀”是为了让模型不再把整个邮箱地址传进来due_date 明确格式和默认规则后模型调用准确率显著提高。工具层还需要一张映射表工具名对应后端接口地址、鉴权方式、限流阈值、幂等键策略。执行前做参数校验执行后做返回结果规范化这些都要落到注册中心而不是散落在代码里。5.3 模块二上下文与记忆的核心逻辑会议纪要任务文本很长最好先做一次“入场摘要”。我的流程是先把完整会议稿压缩成二级摘要包含会议背景、讨论要点、未决问题把完整原文存库给模型的提示里只放摘要和最近几轮对话当模型需要查询细节比如某句原话时再通过一个 retrieve 工具把相关片段拉回来。核心代码可以用一个函数模拟记忆拼接逻辑def build_memory_context(conversation_id, user_input): recent memory_buffer.get_recent(conversation_id, n6) # 最近6轮 summary memory_buffer.get_summary(conversation_id) # 历史摘要 top_k vector_store.search(conversation_id, user_input, k4) # 长期事实检索 return { summary: summary, recent: recent, relevant_facts: top_k, }注意检索这里用的是当前用户输入做 query而不是整个历史这样相关度更高。滑动窗口加摘要加向量检索三层记忆叠加既控成本又保留关键信息。很多项目的记忆问题错就错在只做了滑动窗口历史一长就把关键事实丢了。5.4 模块三编排与重试流程的骨架我的编排器外层拆成四步规划把输入转成行动计划、执行调用工具、验证检查输出有没有达到目标、交付格式化成最终纪要。伪代码如下async def run_agent_task(user_input, request_id): plan await planner.create_plan(user_input) # 1 规划 for step in plan.steps: result await execute_with_retry(step, request_id) # 2 执行 ok await validator.check(result, step.target) # 3 验证 if not ok: result await compensator.compensate(step, result) return formatter.format(plan.output) # 4 交付执行层必须做幂等。我习惯给每次任务生成一个 request_id工具执行时把它传给后端后端用这个 id 做去重同一个 request_id 的重复请求直接返回第一次的结果。重试策略用指数退避第一次 1 秒、第二次 2 秒、第三次 4 秒最多三次。所有写操作工具必须声明是否幂等不承诺幂等的一律不自动重试改为转人工。这个规则写死在工具注册中心里而不是靠模型判断。5.5 成本账本与实测参考这个场景跑下来一个会议纪要任务大约会消耗多少 token 呢输入稿子按 5000 字算大约对应 8000 到 10000 token摘要压缩一次又新增几千 token加上工具调用和多轮交互单任务总消耗普遍在两万到三万 token 这个量级。按中等价位模型来算成本大约在几毛到块把钱之间。你要有几十个用户每天用月成本也就是几百到上千元量级。听上去不贵但要注意两个隐形成本一是评测集维护二是异常任务的重复调用。有些任务会反复失败每失败一次都在烧钱。我建议把单任务 token 上限设成常规值的两到三倍超过直接标记“需人工介入”避免失控账单。成本报表按业务线分摊每月出一份让产品经理也对模型花费有体感。5.6 从 Demo 到生产必须补的几门课Demo 能跑通和生产能扛住隔着几门必修课。第一门是鉴权与审计用户的角色、Agent 的工具权限、数据权限要联动。第二门是多租户隔离不同业务线不能用同一个向量库否则数据串味。第三门是容量和降级模型服务抖动时要不要切到备用模型摘要失败时能不能直接给原文第四门是版本化Agent 配置包括 Prompt、工具集、阈值要进版本库发布要能回滚。这四门课不好补但每补一门你手里的方案就从“脚本”向“平台”靠近一步。6. 踩坑实录Agent Infra 的工程化陷阱6.1 上下文越长越好这是最贵的错觉我把踩过的第一个坑分享出来早期觉得上下文是越多越聪明干脆把全部历史、全部背景文档一次塞进提示。结果模型回答变慢、费用翻了几倍回答质量反而下降。原因不难理解超长上下文里关键信息会被噪声淹没模型对中段内容的注意力明显弱。后来改成多层记忆方案后同样的任务成本下降了六成左右回答质量还更好。长文本不是不能进上下文而是要“按需进入”。也就是前面说的摘要常驻原文入库检索时再动态取回。这条经验能省真金白银也是 Agent 能不能落地的分水岭。6.2 模型“编造工具”或者“拒调工具”先别骂模型很多团队上线后遇到的第一个俗称“幻觉”的问题是模型调用了不存在的工具、传入了不存在的参数。第一次遇到大家都觉得是模型不行但我排查过几个案例后发现根因几乎都在工具层。典型问题工具描述含糊模型不知道什么时候该用这个工具工具数量太多且没有命名空间候选列表本身就把模型搞晕了有的工具 schema 写得不完整required 字段缺失模型只能自己编。建议先做工具治理砍掉低频工具、把工具名改得更语义化、给关键工具提供一两条示例。实测下来光是规范 schema 描述工具选择准确率就能提升很多。还有个技巧在工具执行层加一个“参数校验器”模型给的参数先过一遍 schema 校验不合格就返回一个结构化的修正错误给模型让它自己重来。这比直接调接口失败再报错高效得多。6.3 重试逻辑写不好系统直接被打爆工具调用超时本能反应是重试。但我见过一个真实事故一个扣费接口在回调时超时重试了四次最后产生四笔订单。问题就出在重试没有幂等键。修复方案很简单所有写操作必须带 request_id服务端按 id 去重重试多少次也只会成功一次。重试还要区分层级。工具级重试针对瞬时故障比如 500、超时但要控制次数任务级补偿针对逻辑失败比如工具返回“余额不足”这时候不该重试该转人工。两个层级的职责不能混。另外全局要设一个“单任务最大执行轮次”防止 Agent 在同一个问题上反复绕圈既保护成本也保护体验。6.4 没有评测集Agent 越改越乱我做 Agent 初期吃过最大的亏是上线后所有优化都靠“感觉”。改一次 Prompt 感觉回答更好了实际上某个边角场景反而崩了等客户反馈才后知后觉。正确做法是从第一天就建 Golden Set每个业务场景准备至少十到二十条有代表性的输入配好“期望行为关键词”“格式要求”“必含信息点”。每次修改任何 Agent 配置全量跑一遍对比指标变化。LLM-as-judge 可以承担一部分自动化评估但每周要人工抽二三十条校准裁判模型防止裁判本身漂移。这套东西坚持几个月你会发现手里攒下一份别人没有的业务资产。这条经验本身也说明Agent 工程化的核心壁垒不在模型选择而在你慢慢积累的评测资产和治理规范。6.5 权限一开始不上后面补的都是窟窿另一个容易拖延的是权限。Demo 阶段本地跑无所谓一旦接入真实系统就要立刻把最小权限做上。Agent 能访问的数据范围、能调用的工具集合、是否需要人工审批都要明确。见过有的团队图方便把所有工具一把钥匙交给 Agent结果模型被一封带恶意指令的邮件诱导着改了内部状态。这个事故的表象是模型被“越狱”根源是权限设计偷了懒。敏感操作必须卡审批流。工具注册中心里标记“高危”的工具执行前返回“待人工确认”状态审批通过后才有下一步。同时记录每次工具调用的完整轨迹触发会话、调用参数、模型推理摘要、执行结果。权限不是功能是底线别等事故来了再补。7. 给刚开始接触 Agent Infra 的工程师几句体己话7.1 先把小闭环跑稳再急着上复杂编排如果你现在刚起步我的建议很直接别一上来设计十智能体大盘先把“单 Agent 三五个工具 trace eval”这套最小闭环跑得滚瓜烂熟。越简单的架构越容易暴露本质问题也越容易建立正反馈。复杂编排是放大器不是发动机。你的单 Agent 任务都做不稳多 Agent 只会把错误分发得到处都是。所以先花几周时间把一个真实场景跑通、跑稳、跑出成本账然后再谈规模化。谁先把稳定性和成本这两件事做明白谁就攥住了入场券。7.2 三个建议和一个值得长期坚持的习惯最后给三个具体建议都是我自己摸索出来的笨办法。第一动手永远比观望强。哪怕周末搭一个最小 Agent也会比读十篇架构文章更有收获。第二把决策记录当成代码一样管理Prompt、工具集、阈值、版本都要进库能回滚才有资格谈迭代。第三所有优化都拿数据说话用评测集衡量而不是凭感觉。再分享一个值得长期坚持的小技巧从第一天就把 Agent 的每次决策轨迹存成结构化日志字段拆细一点模型名、工具名、输入摘要、输出摘要、耗时、成本全记上。将来做评测集、做降级分析、甚至训练一个小模型做路由全靠这批数据。这不是什么超前设计这是我踩过坑以后最想让你一开始就做对的一件事。