企业官网建设流程全解析

今年让我真正觉得 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 可观测性与评测集：为什么没有这两样就管不住 Agent

Agent 系统上线第一天起，就要同时建两条线：观测线和评测线。

观测线解决“当时发生了什么”。单次模型调用的日志远远不够，需要任务级的 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, n=6) # 最近6轮 summary = memory_buffer.get_summary(conversation_id) # 历史摘要 top_k = vector_store.search(conversation_id, user_input, k=4) # 长期事实检索 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 的每次决策轨迹存成结构化日志，字段拆细一点，模型名、工具名、输入摘要、输出摘要、耗时、成本全记上。将来做评测集、做降级分析、甚至训练一个小模型做路由，全靠这批数据。这不是什么超前设计，这是我踩过坑以后，最想让你一开始就做对的一件事。