提到 Agent，大家习惯性盯的是模型：谁的推理更强、谁的指令遵循更准、谁的上下文更长。可如果你真把一个 Agent 从 Demo 推到生产环境，跑上一两个月，会发现决定它上限的根本不是模型本身，而是它脚下那层基础设施——Agent Infra。这不是什么新鲜概念，但过去一年它已经变成巨头之间最胶着的隐秘战场；而对普通工程师来说，这可能是为数不多的、还能从边缘切入中心的机会。这篇文章想聊清楚三件事：为什么 Agent Infra 如此关键、它到底由哪些部分组成，以及一个不在头部大厂、没有专门基建团队的工程师，应该从哪里拿到属于自己的入场券。
我把这段时间围绕 Agent Infra 的观察、拆解和实测经验整理了一下，希望能让正在做 Agent 应用、或者正准备转向这个方向的朋友，少走一点弯路。
1. 为什么说这是“隐秘战场”：模型同质化之后，胜负手转向了底座
1.1 三年前的竞争逻辑已经失效
两三年前，大家比拼的还是模型参数、推理效果和榜单分数。那时做应用很简单：调一个 API，写一段提示词，给用户一个聊天框，就算跑通了一个 Agent 应用。但今天你再去看，模型层已经高度同质化——几个主流模型在日常任务上的差距正在肉眼可见地缩小，随便一个开源模型微调一下，也能在垂直场景里打得有来有回。当模型本身不再构成壁垒的时候，巨头们拼什么？拼的就是谁能把 Agent 稳定地跑起来、低成本地跑起来、安全地跑起来。这些东西，全部落在模型之外的底座上。
这个底座，就是这个标题里的“Agent Infra”。它不性感，不会出现在发布会的大屏上，甚至大多数用户根本感知不到它的存在。但它决定了你的 Agent 是每周崩一次，还是能连续运行几个月；决定了一次任务完成率是 40% 还是 90%；决定了每笔任务成本是几分钱还是几块钱。巨头们心里清楚，模型能力是公共资源，但基础设施是私有护城河——所以这个战场注定是隐秘的，因为没人愿意把底牌亮出来。
1.2 决定 Agent 水平的三个隐性指标
如果只看论文和榜单，你会觉得 Agent 已经无所不能。但只要做过实际项目，你就会发现，真正让 Agent 产生差距的是三个不太起眼的隐性指标。
第一个是一次任务的完整成功率。也就是从用户抛出诉求到最终拿到正确结果，这中间模型自主完成规划、调用工具、处理错误、最终收敛的全过程成功率。单步正确率高没有用，一个 10 步的任务，每步成功率 95%，总体只有 60%。这也是为什么一个 Agent 系统好不好用，不能只看单次对话的体验，要看整条链路的完成率。
第二个是长流程的稳定性。生产环境里的 Agent 不是跑一次就结束的，它可能一天要处理几万次任务，每一次任务里的步骤还有分支、有循环、有外部依赖。稳定性的难点在于：外部接口随时可能变慢、返回结构可能变掉、第三方工具可能直接挂掉。Agent 必须能在这种乱糟糟的环境里，依然保持输出质量不塌方。
第三个是成本与延迟的平衡。模型调用不是免费的，Agent 任务通常需要多次甚至几十次模型调用。如果一次任务要消耗几十万 token，还要用户等待半分钟，再聪明的 Agent 也很难落地。这个指标直接影响产品形态，甚至决定某个场景能不能商业闭环。
这三个指标，没有哪一个能靠模型本身解决，全部都得靠 Agent Infra 来兜底。所以你会看到，真正的资源正在往这里倾斜。
2. 拆解 Agent Infra 的五层结构：每一层都有一堆烂摊子要收拾
如果把 Agent 系统比作一家公司，模型是雇佣来的明星员工，而 Agent Infra 就是这家公司的办公楼、水电网络、财务系统和安保体系。明星员工固然重要，但办公楼漏雨、水电频繁跳闸、财务对不上账、安保漏洞百出的时候，再厉害的人也发挥不出来。下面是我认为 Agent Infra 里最关键的五个层次。
2.1 模型接入与路由层：别把鸡蛋放在一个篮子
这一层解决的是“Agent 到底调用哪个模型”的问题。听起来很简单对吧？实际上一旦进入生产，麻烦就来了。
你不可能只依赖一家模型厂商。原因有很多：某个厂商的接口今天故障了怎么办？某个模型在中文任务上表现好、但代码能力弱怎么办？成本上涨了要不要切到更便宜的模型？这些问题要求基础设施里有一个统一接入层——你只跟这一层交互，由它负责把请求路由到不同的模型后端。
路由策略通常要支持几种模式：
- 成本优先：简单任务自动走低价模型，复杂任务才走高价位模型。
- 质量优先：关键任务强制使用最强模型，宁可慢一点。
- 故障降级：主模型不可用时，自动切换到备用模型，用户无感知。
- 语义路由：根据任务类型，把请求分发给最擅长该领域的模型。
这一层还要做超时管理和重试。模型接口偶尔会抖动，一次请求超时 30 秒，如果你直接报错，用户的体验就是“Agent 卡死了”。合理的做法是设置短超时，快速失败，然后重试一次备用通道。这些机制不需要什么高深理论，但没有它，你的 Agent 会非常脆弱。
2.2 任务编排与执行层：从“一条链”到“一张图”
早期 Agent 应用喜欢用“链”的方式组织流程：先做 A，再做 B，再做 C。线性流程简单好理解，但一旦任务复杂起来，它就不够用了。真实世界的任务往往是：我需要根据用户的输入决定下一步做什么；A 失败了我是不是要走 B 和 C；B 的结果会决定 C 要不要继续。这已经不是链，而是图。
现代 Agent 框架的编排层，本质上都在做一个有状态的状态机。它负责维护任务当前的进度，决定下一步执行什么动作，处理分支、循环和异常。
我见过不少团队在这个环节犯同一个错误：把编排逻辑全部写死在业务代码里，一个任务一个 class，每个 class 里塞满了 if-else。短期看没什么，但一旦任务种类多起来，代码就会迅速腐化，变得谁也不敢动。
一个更可持续的做法，是把任务定义成可描述的数据结构，用配置或 DSL 来描述任务步骤、分支条件和依赖关系，然后再用一个通用的执行引擎去“跑”这份描述。这样业务逻辑和底层执行被分离，新增一个任务类型不需要动引擎代码，只需要新增一份配置。这个过程和前端从手写 DOM 操作走向声明式框架的演进非常像。
2.3 记忆与状态层：Agent 的“三秒钟记忆”怎么破
大模型的上下文窗口是有限的。一个 Agent 在执行一个长任务时，哪怕最初用户只说了三句话，经过几轮工具调用、结果回填、中间推理之后，上下文很容易就满了。如果不做管理，最早的关键信息会被挤出窗口，Agent 就会“失忆”。
这一层要解决的问题有两个：短期的工作记忆和长期的跨会话记忆。
短期记忆比较好理解：把当前任务的上下文保存在结构化存储里，用压缩、摘要、滑动窗口等手段控制 token 消耗。比如对话轮次太多时，把早期内容摘要成几句概括，再塞回上下文，这样既保住了核心信息，又不会撑爆窗口。
长期记忆就比较麻烦了。它需要把用户的偏好、历史事实、之前的决策沉淀下来，供以后的会话使用。常见的做法是把信息写入向量数据库，做成检索式记忆——每次新会话开始时，先把相关的历史记录捞出来，放到上下文里。但这里有个坑：向量检索召回的结果经常不够准，你要么花精力调召回策略，要么干脆给记忆内容加上元数据和时间戳，让程序按照规则做一轮过滤，而不是全指望语义相似度。
说实话，记忆与状态层是目前 Agent Infra 里最不成熟的一层。每家实现的方案都不一样，也没有公认的最优解，所以这一层也是我觉得最值得花时间的切入点。
2.4 工具层与安全边界：能力越大，危险越大
Agent 与普通聊天机器人的最大区别，就是它能调用工具。它能操作数据库、发送邮件、提交订单、控制设备。这既是它价值最大的地方，也是风险最集中的地方。你可以想象，一个能让 AI 自动执行操作的接口，一旦被恶意提示词绕过了限制，后果不堪设想。
工具层要做的事情包括工具注册、参数校验、执行沙箱、权限控制。我给团队定的原则很简单：Agent 权限永远最小化。它默认没有权限，每调用一个工具都需要显式授权；涉及资金、隐私、删除类操作，必须设置二次确认的人工审批节点。这个原则意味着 Agent 可能因为权限不足而执行不了某些任务，但这恰恰是正常的——一个频繁越权的 Agent，比一个偶尔完不成任务的 Agent 危险得多。
另外还要特别注意工具的参数 Schema。模型调用工具时，是靠自然语言理解来生成参数的，它可能把日期格式传错，可能把金额单位搞混。你必须在工具层做严格的参数校验，而不是直接把这些脏数据丢给下游系统。我在实测中遇到过非常多这类问题，后面会展开讲。
2.5 可观测性、评估与成本控制：没有这三样，你就是在盲飞
Agent 和传统后端服务的最大不同，在于它的输出充满不确定性。传统接口你给同样的输入，返回几乎总是相同的；但 Agent 每次执行都可能走不同的路径。这就导致调试变得极度困难：用户报告“刚才那个任务失败了”，你根本无法复现，因为这次失败可能是一个小概率分支触发的。
所以可观测性在 Agent 系统里不是可选项，而是必需品。你需要记录每一个步骤的输入输出、调用了哪个模型、消耗了多少 token、花了多长时间、在哪一步发生了重试、最终为什么失败。这样你的 trace 才能还原出一条完整的执行路径。我强烈建议基础设施里直接支持标准的分布式追踪体系，把每一次模型调用和工具调用都串成一个完整的 span 链路。
评估层解决的是“我们改了一个 Prompt，到底是变好还是变坏了”的问题。Agent 的改动很难靠人工点几个用例来验证，你需要一套自动化评测集：一批有标准答案的任务，每次改动后批量跑一遍，看完成率和质量分是涨是跌。只有把评估跑成 CI 的一部分，你才敢放心地持续调整。
成本控制更不用多说。一个 Agent 任务几十次模型调用，如果模型用量翻倍，成本就翻倍。基础设施里要有 token 级别的计量、预算上限、熔断开关。没有成本控制，Agent 跑得越成功，你的账单越难看。
3. 普通工程师的入场券：先把一个最小可行的 Agent Infra 跑通
聊完理论，该动点真格的了。我知道大部分人看到上面那一套，第一反应是“这不是巨头才有资源搞的吗？”其实不是。作为普通工程师，你入场的第一步不需要去构建一个巨型平台，你只需要把一个最小的 Agent 系统完整地、可观察地跑起来。
3.1 先放下“造平台”的冲动，做一条被用户真正用起来的链路
我见过不少开发者，一上来就照着巨头的架构图搭平台：模型网关、编排引擎、向量数据库、评估系统、权限中心，光基础设施就开发了三个月，结果一个具体业务都没跑通。这是典型的本末倒置。
正确的入场姿势是选一个场景极其聚焦的任务，比如“自动整理客户邮件并生成回复草稿”或者“自动把网页信息提取并填入表格”。然后用最小的技术栈把它做成一条完整链路：用户输入一个请求，Agent 自主调用一两个工具，返回结果，同时输出这一整条链路的调用记录和 token 消耗。这条链路可能很朴素，但它会逼你亲自处理那些真正要命的问题：模型输出不稳定怎么办、工具返回格式乱了怎么办、任务跑到一半超时了怎么办。
3.2 最小基础设施长什么样
以我最近在模拟项目里的实测为例，一个最小的 Agent Infra 只需要四样东西：
- 一个模型接入层：封装一个统一的调用函数，支持设置模型名、切换备用模型、打印 token 消耗。
- 一个工具注册表：用一个字典把工具名映射到实际函数，每个工具提供统一的输入输出约定。
- 一个执行循环：让模型决定调哪个工具、传什么参数，然后把工具结果喂回去，循环 N 轮直到任务结束。
- 一条可观测的日志：把每轮循环的思考、工具调用、模型输入输出量全部记录下来。
用伪代码来表达，大概是这个样子：
# 极简 Agent 执行循环 TOOL_REGISTRY = {} def register_tool(name, fn, schema): TOOL_REGISTRY[name] = {"fn": fn, "schema": schema} def run_agent(user_input, max_steps=10): messages = [{"role": "user", "content": user_input}] steps = 0 while steps < max_steps: message, tool_calls = call_model(messages) # 模型生成回复或工具调用 log_trace(step=steps, message=message, tool_calls=tool_calls) if not tool_calls: return message.content # 没有工具调用，结束 for call in tool_calls: tool_result = execute_tool(call) # 执行工具 messages.append(tool_result) # 把结果回填给模型 steps += 1 raise MaxStepsExceeded() # 超过最大步骤数，强制终止这段伪代码看起来简单，当你真把它放到生产环境里，立刻就会遇到几个我实测下来最容易翻车的点。
3.3 我实测中容易翻车的三个细节
第一个坑：工具返回内容过长，直接污染上下文。工具返回的可能是整整一张表格、一大段日志或一次接口的完整响应。模型生成的上下文里塞进大段无用文本，任务质量立刻下降，token 成本也飙升。解决办法是给工具增加后置处理：默认只返回摘要、只返回前若干行，或者做结构化裁剪。任何工具的原始响应，都不能直接进模型上下文。
第二个坑：循环不设上限。有的任务模型会陷入无意义的循环，一直调用同一个工具，重试同一个错误。如果你没有最大步数限制，它会一直跑下去，烧完你的预算。我在一个实验里发现，某一类检索任务里模型竟然连续调用了 17 次同一个接口，参数一模一样。所以执行循环一定要有步数上限，同时要识别重复调用，发现连续 N 次同样的输入输出，直接掐断。
第三个坑：重试过于激进，造成下游雪崩。Agent 要调用第三方 API 时，如果超时立刻重试，重试再超时再重试，你这不是在解决问题，是在给下游制造流量风暴。正确做法是配置递进式重试策略：第一次快速重试、第二次退避、第三次完全放弃并报错；还要给整个任务设置一个总体时间预算，超过预算就降级为人工处理。
3.4 用数据验证你的入场成果
跑通最小链路之后，别急着加功能，先拿数据说话。建议你准备 20 到 50 个真实任务样例，做一个最简单的人工评估集：每跑一次，记录任务完成率、平均步数、token 消耗、失败原因分布。根据这几项数据，你就能明确知道自己的 Agent 到底处于什么水平。这是非常朴素的评估方法，但足以支撑最初的迭代。如果你的完成率已经能稳定在 80% 以上，恭喜，你已经比大多数停留在 Demo 阶段的人走得更远了。
4. 巨头建“航空母舰”，我们开“快艇”：中小团队不必复刻重型基建
说了半天入场券，还是要回到一个现实问题：我们没有巨头那样的工程资源，是不是就应该自建全套 Agent Infra？我的观点很明确：不应该，也不需要。
4.1 巨头为什么必须自研重型基建
巨头们自研，是因为它们面临的问题和我们完全不同。第一，它们的用户量级要求极致成本控制，单次调用省一毫，乘以亿次就是巨额利润。第二，它们的数据不能随便出企业边界，合规要求决定了必须自建。第三，它们的业务场景足够复杂，公开框架根本满足不了那种灵活性和可定制性。这三个条件，中小团队通常一个都不满足。所以巨头那条路，对我们的参考价值主要在认知层面，而不在操作层面。
4.2 什么该自建，什么该直接复用
我给团队的参考框架是这样分的：
| 组件 | 建议做法 | 原因 |
|---|---|---|
| 模型接入层 | 直接复用第三方模型网关/API 平台 | 成熟度高，省维护成本 |
| 任务编排层 | 优先复用开源编排框架，在其上做薄封装 | 框架思路成熟，自己写容易踩坑 |
| 记忆与状态层 | 自建一个轻量模块，但要封装好接口 | 需求差异化大，标准方案覆盖不了 |
| 工具层 | 自建，但要严格遵循统一注册协议 | 这是你业务的真正壁垒，值得投入 |
| 可观测与评估 | 复用基础设施 + 定制评估脚本 | 日志系统已成熟，评估脚本成本低 |
特别要说的是工具层。这是少数我认为中小团队应该重点自建的环节，因为工具背后才是你的业务逻辑、你的数据、你的行业 Know-how。模型和编排框架都是通用的，但“能调用我们行业特有的系统”这件事，任何通用框架都帮你做不了。
4.3 从工程师个人视角可以选择的路线
如果你是个人开发者或小团队的核心工程师，我建议按这个顺序进阶：
- 做一个使用者：先把现有的开源框架和主流模型 API 用熟，跑通一个端到端项目。
- 做一个插件作者：围绕某个具体行业场景，写一套工具组件，发布出去。这个过程能让你真正理解工具与模型交互的边界。
- 做一个平台模块贡献者：等你对执行循环、记忆管理、评估机制有足够理解，可以尝试给开源框架贡献模块，或者开发自己的轻量工具包。
- 做一个垂直领域的基建提供者：如果时机合适，可以把你的工具集和开发经验沉淀成一套面向某行业的轻量基建产品。
这条路径的好处是每一步都能独立产出价值，不需要你一步到位去建什么大平台。
5. 决定 Agent 系统生死的四个工程细节
最后分享一下我在实际调试中总结出的四个高频细节问题。它们每一个都单独看起来不大，但叠加起来，足以让一个 Agent 系统从“能用”变成“根本没法用”。
5.1 幂等性：你的 Agent 会重试，你的下游系统准备好了吗
模型接口超时了，Agent 会自动重试；工具调用失败了，Agent 可能会再次发起同一步操作。问题是：下游系统能不能接受同一个操作被提交两次？如果你调用的是“创建订单”或“转账”这类接口，重复提交的后果是很严重的。所以 Agent 每次调用工具时，都应该生成一个操作 ID，下游系统要做幂等处理。哪怕只是一个邮件发送接口，也建议做一层去重，否则用户会收到两封一模一样的邮件，然后怀疑你系统有 bug。
5.2 token 预算是系统里最容易被忽略的隐形杀手
很多人调试 Agent 时只看“效果”，不看 token 消耗。结果就是，任务确实完成了，但一次任务烧了几十万 token，单个用户成本高得离谱。我建议在基础设施里直接做一个 token 预算机制，分三个层级：单次模型调用预算、单次任务预算、单用户周期预算。超出预算时，不是直接失败，而是自动降级：从最贵模型切到便宜模型、压缩上下文、简化工具调用链，甚至主动询问用户是否要继续。为了控制预算，上下文压缩和摘要策略也值得花时间优化，省下来的都是利润。
5.3 观察 Agent 不能只看日志，要跟进“执行路径”
传统后端看日志就够了，因为逻辑是确定的；Agent 的逻辑是动态的，你必须把每次执行完整地追踪下来，才能知道模型为什么做了 A 而不是 B。我在前面说到的 trace 体系，落地上至少要做到：记录每一步的输入 token 数和输出 token 数、记录工具调用的参数和结果大小、记录重试事件、记录分支决策的理由。一条完整的执行轨迹，是改进 Agent 效果的第一手材料。没有它，你优化一个 Prompt 之后根本无法判断到底是变好了还是变坏了。
5.4 拦不住时，要让人能接管：human-in-the-loop 不是概念，是代码
生产环境里一定会有模型处理不了或不确定的情况，比如高风险操作、歧义指令、数据异常。这个时候，Agent 不应该硬着头皮往下执行，而应该明确告诉用户“我需要你确认一下”。人类确认的节点要设计在流程的关键位置上，而不是所有事情都去烦用户。当 Agent 主动说“我不确定，需要你确认”，这种表现反而会增加用户对系统的信任。我也遇到过因为 Agent 从不示弱，盲目给出错误答案，导致用户完全放弃的情况。敢于请求人工接管，是一个成熟 Agent 系统的标志。
按照我个人的实操体会，Agent Infra 的入场其实没有想象中那么高不可攀。你不一定要先去读懂巨头几十万字的架构文档，也不用急于复刻一个全功能的平台。找一个小而真实的场景，把模型调用、工具注册、执行循环、日志追踪这四件小事亲手做扎实，就已经摸到这张入场券的边了。等你把一次任务从“碰运气完成”打磨成“稳定地完成、可观测地完成、成本可控地完成”，你就会理解为什么那么多团队正在悄悄把资源压向这一层——因为当模型能力不再是秘密的时候，真正拉开差距的，就是这块看似不起眼的地基。
