今年云栖聊得最多的，不是哪个大模型又刷新了榜单，而是 Agentic AI Infra。会场里反复出现的一个判断是：2026 是工业智能体从概念演示走向工程化落地的分水岭。这话我认，因为我过去一年落地过好几个智能体类应用，真正的瓶颈从来不是“模型会不会”，而是“让智能体能稳定、可控、可观测地跑起来”的那套基础设施。这篇文章就从实操者视角，把 Agentic AI Infra 拆开讲清楚：它到底解决什么问题、核心组件有哪些、一个能直接复用的最小闭环长什么样，以及我实测踩过的坑。适合正在做 AI 应用、打算用智能体改造业务流程、或者准备搭建 Agent 平台的人对照参考。
1. Agentic AI Infra到底在解决什么问题
1.1 从“会聊天”到“会干活”，差的不是模型
先说一个被反复混淆的概念差异。聊天机器人（Chatbot）的核心能力是“回答”：你问它一句，它回你一段，你的多轮追问只是把上下文叠得更厚一点。而智能体（Agent）的核心能力是“完成目标”：它会自己拆解任务、调用工具、观察结果、修正方向，最后向你交付一个成果。两者的差别，就像客服和管家的差别。客服只会告诉你营业时间是几点，管家会自己查餐厅、订座位、改行程，发现第一家没位子还会立刻换第二家。
这个差别放到工程上，意味着智能体本质上是“一个长期运行、有状态、会采取动作的程序”。它不再是一次请求-响应的闭环，而是一个循环：规划、执行、观察、再规划。既然是这样，它就必须有配套的运行时。模型只是它的“大脑”，还缺手脚、缺记忆、缺神经系统。把大脑、手脚、记忆和神经系统整合在一起的这一层，就是 Agentic AI Infra。
1.2 传统AI Infra为什么带不动智能体
传统意义上的 AI Infra，比如模型推理服务、向量数据库、推理加速和 AB 测试平台，解决的核心问题是“把模型服务稳定、高效地供出去”。这套体系对 Chatbot 完全够用，但放到智能体身上，至少会撞上四堵墙。
第一堵墙是无状态输入和有状态任务的冲突。一次模型 API 请求天然无状态，而一个智能体任务是有状态的：当前子目标是什么、已经尝试过哪条路径、哪些中间结果需要保留、哪些结论已经失效。这些状态如果全部靠外部一个大容器硬扛，任务一长就会陷入混乱。
第二堵墙是延迟放大。同一个智能体任务平均要调用 4 到 10 次模型，每一次都是串行，总延迟是单次调用延迟的线性累加。某些复杂任务里，模型还要先规划再分步执行，期间再穿插多次工具调用。一次任务超过 30 秒是家常便饭，传统单次推理的 SLA 思维在这里完全不适用。
第三堵墙是评估对象的改变。以前评测的是“这一条回答好不好”，现在的评测对象变成了“这个任务有没有被完成，走的路径是不是最优”。单轮指标漂亮，不代表一个智能体在生产环境里真的可靠。必须引入轨迹级评估，把智能体的每一步都拉出来看。
第四堵墙是安全边界的扩大。聊天机器人最多输出一段有风险的文本，你可以在最终输出层做审核。但智能体会调用数据库、发送消息、提交订单、修改配置，它的动作本身是有权力的。如果 Infra 只兜住输出、不兜住动作，就会出大事。
这几堵墙叠加在一起，结论很明确：智能体需要的不是“模型服务”的延伸，而是一层全新的任务运行时。
1.3 Infra要接住的四个核心诉求
我把这层运行时抽象成四个核心诉求，做项目时照着这四个方向查缺补漏，基本不会跑偏。
第一是模型弹性。模型不会只有一个，小任务跑小模型，复杂规划跑大模型，关键节点用更强的推理模型。Infra 要能做路由、做预算控制、做故障回退，而不是把全部流量压到一个模型上。
第二是确定性编排。很多团队的误区是“智能体就应该完全自由发挥”。实际上生产环境里，越是影响业务的关键路径，越要给它套上确定性边界：哪些步骤是必须顺序执行的、哪些分支是允许模型自行判断的、最多循环几次、什么条件下必须收手。把不确定性的范围圈定住，模型才能在你允许的区间里做创新。
第三是记忆与知识。智能体必须有短期记忆（当前任务的上下文）、长期记忆（用户偏好、业务规则、历史决策）和外部知识库的访问能力。这三者缺一不可。
第四是全链路审计。谁、在什么时间、基于什么信息、让模型执行了什么动作、花费了多少 token，全部要可追溯。没有审计，智能体永远只能停留在演示阶段，过不了内部合规这关。
看今年云栖展台，很多底层产品都在往这四个方向收敛，不是偶然。需求已经在这里了，技术栈只是跟着长出来。
2. Agentic AI Infra的核心技术栈与选型
2.1 模型接入层：模型网关与多模型路由
模型网关是智能体 Infra 的“入口开关”。现在的常态是：同一个业务里，意图分类用又快又便宜的小模型，文档改写用中等模型，复杂规划才动用顶配大模型。如果没有一个网关做统一接入，应用层每换一个模型就要改一遍代码，成本非常可观。
网关的核心动作就两件事：路由和降级。路由可以简单到按任务类型分流，也可以复杂到按上下文长度、预算余量、渠道稳定性做动态调度。我给一个小团队常用的朴素实现思路，不要神话它：
# 轻量级模型路由示意 def route_request(request): task_type = request["task_type"] if task_type == "classification": # 简单分类，用小模型，限制输出长度 return call_model("fast-model", request, max_tokens=200, temperature=0) if task_type == "extraction": return call_model("medium-model", request, max_tokens=1024, temperature=0.1) if task_type == "planning": return call_model("strong-model", request, max_tokens=4096, temperature=0.2) # 兜底：小模型先顶上，宁可慢一点不能直接挂 return call_model("fallback-model", request, max_tokens=1024)路由之外，必须给每个模型配置三个关键参数：超时时间、最大重试次数、单任务 token 预算。我就见过因为没配超时，智能体在某个上游模型一直挂着，整个任务的线程全部卡死。我的习惯是：首 token 超过 30 秒直接切换备用模型，连续重试 2 次失败就降级到小模型回答，宁可损失一点质量，也不能让任务悬空。
2.2 编排层：Workflow与Agent Loop怎么选
编排层是智能体 Infra 的“总指挥”。现在主流有两种编排形态：一种是固定工作流（Workflow），任务步骤提前画死，每个节点只做固定的事；另一种是智能体循环（Agent Loop），模型自主判断下一步动作。两者不是二选一，而是围绕业务复杂度做组合。
我的原则很简单：能画成流程图的业务，先用 Workflow。只有那些步骤不确定、高度依赖上下文判断的分支，才把控制权交给 Agent Loop。典型例子是客服工单：建单、查历史、给处理建议这些步骤完全固定，直接编排成 Workflow；但“这个用户的问题到底属于哪一类、要不要升级人工”这种判断，才是 Agent Loop 发挥价值的地方。
Agent Loop 本身也不复杂，核心就是一个循环加一个终止条件：
def run_agent(task, max_iterations=8): context = [] for step in range(max_iterations): planned_action = planner(task, context) if planned_action["done"]: return planned_action["answer"] result = execute_tool(planned_action["tool"], planned_action["args"]) context.append({ "step": step, "action": planned_action, "result": result, "observation": summarize_result(result), }) # 超过最大迭代，强制收敛，不要再让模型自由发挥 return final_answer_from_context(task, context)注意其中的“done”字段，这是整个循环的生命线。很多团队的智能体跑起来就不停了，本质上是模型永远觉得自己还没完成任务。你一定要在工具返回结果里加入显式的终止信号，比如检索到答案、用户确认满意、超过迭代上限，任何一条满足就直接跳出。不要把“让它自己想停”当成方案，程序里必须有硬性停止条件。
2.3 记忆与上下文：智能体的“持久化”
记忆系统是智能体 Infra 里最容易被低估的一层。很多人一开始觉得，模型有上下文窗口，把历史对话全塞进去不就行了？实际操作会立刻打脸：任务进行到一半，上下文已经几万 token，延迟变高、成本失控、模型开始遗忘最初目标。
记忆要分两层设计。短期记忆是当前任务的工作记忆，比如子目标列表、最近几轮中间结果、已经排除的错误路径。这层可以用一个结构化的运行时缓存来维护，并且要有滚动窗口策略：保留最近 N 轮的关键信息，更早的内容压缩成摘要。长期记忆才是真正需要持久化的部分，包括用户偏好、业务规则、历史决策依据、过去处理过的相似问题。我一般把长期记忆放进向量数据库或者 Redis，按需检索，而不是全量塞给模型。
上下文管理的核心动作，是把“所有历史”变成“与当前目标相关的历史”。你可以做一个摘要压缩服务，每完成一个子任务，就用一次小模型调用把关键结论提炼出来，把原文丢弃。也可以做一个相关性检索，当模型需要回忆某条历史时，只把最相关的片段捞回来。记住一个类比就够了：长期记忆是笔记本，短期记忆是草稿纸。干长活的人靠的是会记笔记，不是靠一张无限大的草稿纸。
2.4 工具调用：Function Calling与MCP生态
如果说记忆是智能体的神经，工具就是智能体的手脚。Function Calling 的本质，是让模型在对话过程中输出结构化的工具调用参数，由程序去真正执行。这项能力本身已经足够成熟，翻车大部分发生在工程细节上。
我给团队定的工具接入标准是这样的。第一，工具描述必须写清楚“什么时候该用它、什么时候不该用它”，模型的工具选择能力高度依赖这段描述写得多细。第二，参数必须用严格的 JSON Schema 定义，类型、枚举值、必填项都要写死，模型自由发挥的空间越小越好。第三，工具执行失败时，异常信息要原样回传给模型，让它根据错误重新改参数或换工具，绝对不能静默失败。第四，每个工具都要有超时时间，超时后返回一个“工具无响应”的伪结果，避免整个任务卡死在一次工具调用里。
MCP 解决的问题更宏观：统一工具协议。以前你做一个业务智能体，要对接文件系统、数据库、日历、内部 API，每个都得写适配器，工作量巨大。有了 MCP，数据源和工具可以封装成标准 Server，智能体用统一的方式去发现和调用。我目前的新项目，只要被调用的东西可能复用，一律先考虑封装成 MCP Server，这已经是明确趋势。另外要提醒一句：工具数量不是越多越好。工具列表超过 10 个，模型的选择准确率会明显下降。先控制在核心工具范围内，跑熟了再逐步放开。
2.5 可观测性与评估：让Agent“被看见”
智能体是黑盒中的黑盒，没有可观测性，你只能对着一个“跑完了但不知道对不对”的结果发愣。我的建议是，从第一天就把链路追踪接入项目，不要等上线再补。
每次智能体任务运行，至少要记录四类信息：外部输入（用户说了什么）、内部推理（模型思考了什么）、工具动作（调用哪个工具、参数是什么、返回了什么）、资源消耗（每步的 token 数、延迟、花费）。技术上可以用 Langfuse 或 LangSmith 这类 tracing 工具，也可以自己接一个 OpenTelemetry 管道。核心不是工具选型，而是你要养成习惯：每条智能体轨迹都是可回放的。
评估方面，我建议拆成三层来做。第一层是在线监控，盯住任务成功率、工具调用失败率、平均循环轮数、超时率这些硬指标。第二层是离线评测，维护一组“有标准答案”的任务集，每次改动 prompt、模型、编排策略，先在这组任务集上跑一遍，用任务完成率和轨迹质量判断是升级还是回退。第三层是成本指标，单任务平均成本、单用户月成本、top 耗时任务清单，这三项是财务上迟早要面对的问题，越早摸清越好。
我把这三层常用指标整理成一张表，给团队做日常参考。
| 层级 | 核心指标 | 关注点 |
|---|---|---|
| 在线监控 | 任务成功率、平均轮数、超时率、工具失败率 | 系统健康度、用户体验 |
| 离线评测 | 任务完成率、轨迹有效步数、答案引用准确率 | 版本变更是否引入回归 |
| 成本控制 | 单任务 token 数、单任务成本、日均总成本 | 算力预算、收费模型设计 |
3. 实操落地：从零搭一个“制度条例学习助手”智能体
3.1 先画边界，再写代码
讲完理论，走一个可复现的例子。我选“制度条例学习助手”作为案例，是因为这类场景最常见：企业内部有成堆的制度文档，员工靠搜索框找答案效率极低，想用智能体来回答“报销出差误餐费需要什么材料”这类问题。
动手之前，先把边界画清楚。这个智能体的范围是：制度文档问答和流程引导。它能检索文档、给出基于原文的答复、在不确定时建议人工咨询。它不做的事是：自动提交申请、自动审批、跨系统写操作。这个边界不是怕麻烦，而是风险控制：信息类智能体的业务风险低，可以多给一些自主性；凡是涉及写操作的，都必须先有人工确认环节。
边界画清楚之后，技术选型就非常简单了：RAG 链路加一个轻量 Agent Loop，完全没必要上多智能体协作那套复杂架构。这也是我在实操里最想强调的一点：永远让架构复杂度与业务风险匹配，不要为技术上的兴奋感买单。
3.2 RAG链路：把文档变成工具
制度条例类文档有一个特点：条理清晰、层级明确、内容相对稳定。这天然适合 RAG。我的处理流程分四步。
第一步是文档切分。按章节标题切，不要把一段完整的制度解释截断成两半。我的经验是 chunk size 设在 500 到 800 字之间，重叠 80 到 120 字，同时把文档标题、章节号、发布年份作为元数据一起存进去，方便后面做语义检索和引用溯源。
第二步是向量化。中文场景下，embedding 模型的选择比很多人想象中更重要。建议用一个在中文语义任务上效果比较好的模型，比如 BGE 系列或同类中文优化模型，建好索引后做一次抽样召回测试，确认“报销差旅费”和“出差误餐补贴”这类说法能互相召回。
第三步是检索增强。单纯向量检索不够稳，我习惯再加一个重排模型。先用向量检索召回 top 50，重排后取 top 5，准确率会明显提升。查询改写也值得做：用户说“我出差吃饭怎么报”，改写成“出差误餐费报销流程与所需材料”再检索，命中效果完全不一样。
第四步是引用约束。生成答案时要求模型严格基于检索到的原文回答，并标注来源条款。对于检索结果无法覆盖的问题，直接回答“制度文档中未找到相关内容”，不要编造。这条约束必须写进系统提示词，并且要在评测数据集里专门加“无据题”，防止模型在文档查不到的情况下开始幻觉式发挥。
3.3 编排细节：一个最小可跑的Agent Loop
这个助手不需要复杂规划，我把它设计成 3 个工具加 1 个简单循环。
工具列表很克制：
- retrieve_docs(query)：对制度文档做召回和重排，返回带出处片段。
- generate_answer(contexts)：基于召回内容生成有引用依据的答复。
- escalate_to_human(query)：当置信度不足或用户明确要求人工帮助时，生成一条咨询工单记录。
循环逻辑是：先做一次查询改写，然后调用 retrieve_docs；检查召回结果是否充分，如果充分就调用 generate_answer，不充分就再改一次查询重试；如果连续两次召回结果都不理想，直接调用 escalate_to_human，终止循环。整个流程最多跑 5 步，不会无限空转。
关键参数我给一个参考值：生成答案时 temperature 设为 0.1，避免发挥；检索 top_k 取 5；重试次数 2 次；单次任务最大 token 消耗限制在 4000，超过这个量说明链路已经出了问题，强制转人工。这套配置虽然保守，但在制度问答这种“准确高于创意”的场景里，保守就是最大的正确。
3.4 把Infra用起来：监控、缓存、成本控制
这个助手看起来很小，但真正上线前还要把 Infra 层补齐，否则就是裸奔。
第一是监控。每个请求从进入网关开始打 trace，记录检索消耗、生成消耗、每步延迟、最终是否转人工。我特别关注一个指标：检索后生成答案的比例。如果这个比例偏低，说明检索链路没做好，用户总是走到转人工分支。
第二是缓存。制度文档更新频率低，用户问的问题高度重复。对用户 query 先做一次 embedding，如果和某条历史 query 的相似度超过 0.92，直接返回缓存答案，能省掉 20% 到 50% 的模型调用成本。这个优化实施成本极低，收益非常直接。
第三是配额与限流。按用户维度设置每日调用上限，比如每人每天 50 次。这不是为了限制大家使用，而是防止有人通过脚本刷接口把预算打爆。没有配额机制的智能体应用，上线第一天就失控是大概率事件。
4. 常见问题与排查技巧实录
4.1 Agent空转与停止条件缺失
现象很典型：模型在一个问题上绕来绕去，不断调用工具，但始终不给最终结果。排查下来，绝大多数情况是终止条件设计得太模糊。你让模型“判断任务是否完成”，它就永远觉得自己还能做得更好。
我的解决方法是把终止条件显式化。第一，设置最大迭代次数，我曾经把上限设为 8 步，超过就不让模型继续自由发挥。第二，工具返回结果里增加一个“任务完成”信号，检索到了明确答案、用户表达了满意、找到了唯一匹配项，都算完成。第三，如果连续两轮观察到的信息没有新变化，强制进入总结阶段。给模型戴个铃铛，它反而跑得更稳。
4.2 上下文无限膨胀与成本失控
智能体跑得越久，prompt 越肥。上下文窗口没有被塞满之前，你往往意识不到问题，直到某天账单暴涨。我见过一个案例，单任务 token 消耗超过 10 万，原因就是每一步的结果都被完整保留，旧内容完全没有清理。
对抗这个问题，核心策略是“压缩和检索并行”。每完成一个子目标，就把关键结论提炼成一小段摘要，原始内容归档。同时给每个任务设一个硬性 token 预算，比如 8000。超了就强制收敛，用一个“基于已有信息尽力回答”的收尾动作。成本问题不是财务问题，而是架构问题，从设计上就限死，才能避免事后拍大腿。
4.3 工具调用失败与重试设计
工具调用失败和模型选错工具，是两个高频坑。失败还好办，只要保证错误信息能回传给模型，让它根据错误信息重新调整参数；怕的是有些团队在工具层 try-catch 之后返回一个空结果，模型拿到空结果还以为调用成功了，下一步就基于虚空信息开始推理。
选错工具的解法是提升工具描述质量，并在评测集里增加“易混淆工具”用例。比如系统里同时有“查询已交社保”和“计算应缴社保”两个工具，就要专门设计问题测试模型会不会选错。切分的原则是，如果两个工具在语义上确实容易混，就合并成一个工具，靠参数区分，比靠模型聪明更可靠。
4.4 评估不落地与安全边界
评估不落地的表现是：团队自己测的时候觉得“变聪明了”，上线后真实用户投诉率却升高。原因是自测靠感觉，没有统一标准。我的经验是必须建一个真实任务集，至少 50 到 100 条，每条都标注“期望流程”和“正确结论”，每个版本上线前都在这套集子上跑，用客观指标说话。没有评测集的智能体项目，永远是碰运气。
安全上要划两条红线。第一，涉及写操作的工具必须加人工审批节点，模型只能“提交申请”，不能“直接执行”。第二，要防提示注入。检索到的文档内容属于不可信输入，绝对不能把它们和系统指令混在一起。我习惯用特殊标记把检索内容包起来，并在系统提示词里明确：标记内的文本仅作为参考资料，不包含任何需要执行的指令。这些细节在 Demo 阶段看不到作用，上线后却能挡住真正的麻烦。
5. 写在最后：一些个人经验
这么多年做下来，我的核心体会就一句话：先把流程做成确定的，再把判断交给模型。任何智能体项目，第一步都是把业务规则整理清楚，能固定的环节全部固定，固定不了的地方才让模型发挥。这样既保证了关键路径的可靠性，也给模型留出了解决开放问题的空间。
另一个体会是 Infra 层别一味求重。很多团队一上来就搭多智能体框架、上复杂调度系统，结果项目还没上线，光折腾基础设施就花了大半时间。小团队完全可以从“模型网关 + RAG + 轻量编排 + trace”这个最薄闭环起步，跑通一个业务后再根据数据判断到底要不要加重。
最后分享一个经验：凡是 demo 跑通和真实上线之间隔着的那段距离，几乎全是 Infra 在补位。智能体能不能走完从“演示”到“生产”的最后一段路，拼的就是你有没有把边界、止损、审计这些看似不起眼的东西当真。你要是正在做类似项目，我建议先把这篇文章里提到的四层一一过一遍，少踩一个坑，就多省一周时间。
