企业官网建设流程全解析

过去一年，我几乎每天都在跟 Agent 基础设施打交道。这个词听起来不像大模型那样性感，但它恰恰卡在所有 AI 应用的咽喉位置：指令能不能被可靠执行，状态能不能跨轮次记住，工具能不能安全调用，出了问题能不能在十分钟内定位——这些全是基础设施问题。

我见过太多团队在大模型 API 上花了几十万调参，最后产品却死在了编排层：Agent 跑着跑着就重复调用同一个工具，或者明明拿到了正确结果却因为输出格式不合规被判定为失败。更微妙的是，这些痛点正在被各大厂商急速填平，他们嘴上喊着“让每个开发者都能构建智能体”，实际上抢的是未来十年应用分发的入口。

这篇文章我想把 Agent Infra 这层东西彻底拆开：它到底包含哪些能力，巨头在哪些点上暗中较劲，以及作为普通工程师，你能从什么位置挤进这张牌桌。

1. Agent Infra 到底在争什么

1.1 先拆个概念：Infra 与 Agent 的关系

很多人会把 Agent Infra 误解成“部署 Agent 用的服务器”或者“调用大模型的网关”，这个理解太窄了。

我们可以把整个智能体应用分成三层：最下面是模型层，负责“理解”和“生成”；最上面是业务层，负责具体的用户价值和场景逻辑；而中间的 Agent Infra 干的是连接模型能力与业务目标这套脏活累活。具体拆开，它至少要管五件事：

• 编排与调度：一个复杂任务怎么拆解成多步，哪一步交给模型推理，哪一步直接调工具，多个 Agent 之间如何协作、如何排序。
• 状态与记忆：跨轮对话、跨任务的上下文如何保存，长短期记忆怎么分级，状态丢失了怎么恢复。
• 工具接入与执行：外部 API、数据库、代码解释器、浏览器操作等工具如何注册、鉴权、调用，以及工具返回结果后如何反馈给模型。
• 可观测性与调试：一次 Agent 运行可能包含多轮模型调用，必须能完整回放中间过程，否则生产环境根本没法排查问题。
• 评估与护栏：怎么判断这次运行是成功还是失败，怎么防止不安全输出、防止 Agent 越权操作、防止陷入死循环。

你可以把 Agent Infra 想成“给会说话的发动机装一套传动系统”：模型是发动机，输出文本只是喷油，只有通过传动系统——也就是 Infra——这份动力才能真正驱动车轮。

1.2 “隐秘”在哪里：模型能力已过剩，交付链路还不成熟

为什么这个战场是“隐秘”的？因为公众注意力全被模型的跑分和生成效果吸引走了，很少有人关注模型输出之后的那一公里。

现实是，模型能力在过去两年突飞猛进，但把能力稳定交付成产品的手段还非常原始。举一个几乎所有团队都踩过的例子：让 Agent 调用 API 获取订单状态，模型正确输出了{"action": "get_order", "order_id": "12345"}，但工程侧没有处理好工具返回后的校验逻辑，Agent 在拿到“订单不存在”的错误后并不会告诉你哪里出了问题，它只会开始自己编一个“可能的原因”，然后继续重试。于是线上出现了一个奇怪的现象：Agent 明明在“干活”，用户却永远得不到正确答案。

这就是典型的 Infra 缺失。模型没有错，业务逻辑没有错，错在中间那一层没有把工具语义、重试策略、异常传递这些基础能力做扎实。

而巨头们看得很清楚：谁能把这一层补齐，谁就能成为 Agent 时代的默认底座。这个位置一旦定型，后来的应用层玩家全都要在它的规则上跳舞，流量入口、商业模式、生态话语权全都握在手里。

2. 巨头下场：战争背后的三条主线

2.1 场景控制权：从“卖模型”到“卖流程”

第一批吃到大模型红利的公司是靠卖模型授权赚钱的，但这条路走久了会非常累，因为模型是高度同质化的商品——你有推理能力，别人也有；你降价，别人也降。于是巨头开始往上游走，把触角伸向应用运行时的控制权。

这里的典型案例是各云厂商推出的“智能体开发平台”：你不仅可以在上面调用模型，还可以直接编排工具、配置知识库、发布对话应用。看起来很贴心，对吧？但注意，这些平台默认绑定了自家的向量数据库、自家对象存储、自家监控服务。等你把业务跑起来，迁移成本就会高到让你放弃思考。

这就是第一条主线：巨头在争夺“场景入口”。谁掌握了开发者的第一个动作，谁就掌握了后续所有技术选型的主动权。你今天为了省事在平台上点两下配置了一个 Agent，明天想换成别家的模型，就会发现自己已经被工具链、沙箱、数据格式牢牢焊死。

2.2 工具即生态：越多接入，越难离开

Agent 的价值不在于它本身会“思考”，而在于它能通过工具做到比人更快、更准的动作。因此工具生态的丰富度，直接决定了一个基础设施平台的吸引力。

我举一个很典型的对比：同样一个“帮我订会议室”的任务，甲平台预置了企业通讯软件的接口，乙平台什么都没接，那么即便乙的模型效果更好一点，用户也会毫不犹豫选甲。工具接入越多，Agent 能做的事情越多，开发者在上面产生的业务数据就越多，平台对开发者的锁定就越深。

巨头之间的竞争因此常表现为“接入竞赛”：各家都在疯狂扩展预置工具列表——日历、邮件、数据分析、低代码流程、内部系统连接器。你以为他们在做用户体验，其实他们在做护城河。

做基础设施的同行应该特别留意这个趋势：你的 Agent 编排层如果支持“插件化工具接入”，那你还有独立生存空间；如果你打算自己包办所有工具连接，那基本是在用血肉之躯挑战整个巨头生态链。

2.3 开放协议与标准之争：比代码更致命的战场

工具生态竞争的上层，还有一个容易被忽略的维度：标准协议。巨头们都想让自己定义的通信格式、任务描述规范、工具调用协议成为行业默认标准。

这类标准和编程语言之争很像：掌握标准的一方决定了“合法表达”的边界。比如某天行业默认了 A 平台定义的 Agent 间通信协议，那么所有后来者要接入生态，就必须兼容 A 平台的格式。这比绑定几个数据库要厉害得多，因为它是顶层规则的垄断。

对于普通工程师来说，这意味着两件事：第一，你在做技术选型时不要只看功能特性，要关注它背后的生态协议是否开放；第二，如果你想在 Agent Infra 领域做长期积累，深入理解协议设计比熟悉某个具体产品更有复利价值。

3. 普通工程师的入场券到底长什么样

看到这里你可能已经意识到，Agent Infra 不是巨头专属，它更像一片正在被开垦的荒地，每个工程师都有机会用自己的方式参与进去。我把入场路径分成三层，你可以对照自己的情况选择。

3.1 第一张：站在巨人肩膀上做应用

第一层入场券最容易拿到，也最适合大多数人：直接在现有框架和平台上，做出一个完整的、能解决真实问题的 Agent 应用。

别小看这一层，我见过太多人把 Agent 做成“聊天玩具”——能聊几句，但一问到业务细节就露馅。而真正能落地的应用，要求工程师对编排流程、工具设计、错误恢复都有深刻理解。

举一个例子：某团队要做“招聘助手”Agent，功能是自动筛选简历并生成面试评语。第一版他们直接在提示词里写“请分析简历与岗位的匹配度”，结果模型输出非常主观，同一个简历换个说法答案就变了。后来他们把流程改成了三步：先由 Agent 调用一个打分工具得到结构化指标，再根据指标生成评语，最后做一次自检评估。改动不大，但稳定性立刻上来了。

这一层的核心技能是：理解模型能力边界，并把任务拆解成语义清晰、往返可控的步骤。你不需要自己造框架，但要非常熟悉某种编排框架的机制与限制。

3.2 第二张：给开源基础设施“打补丁”

第二层入场券给有一定工程经验的开发者：深入使用某个开源 Agent 框架，然后为它贡献代码。

开源基础设施项目现在普遍处在“能跑但不够好用”的阶段：文档不全、边界情况处理粗糙、企业级特性缺失。这些恰好是普通工程师切入的机会，因为你不需要发明新东西，只需要解决真实场景中已经存在的痛点。

我认识的一位开发者就是这么起步的：他在用某 Agent 编排框架时发现工具调用的并发控制有问题，多个工具同时返回时，上下文管理会丢数据。他花了两个周末定位问题、写了补丁提交上去，后来成了这个项目的核心维护者之一，也因为这个身份拿到了不错的工作机会。

这一层入场券的价值在于“借力”：借助开源项目的流量和社区背书，用相对低的风险积累自己的技术影响力。你写的每一行代码都在被真实用户试用，这种反馈速度是任何内部项目都难以提供的。

3.3 第三张：自建内部平台

第三层入场券适合本身就是平台型团队或基础设施团队的人：在企业内部搭建一套 Agent 开发基础设施，供多个业务线共用。

企业内部自建平台的核心优势是贴近业务：外部的通用框架不愿意处理的脏需求——比如内部系统鉴权、特定数据格式转换、合规审计——你在自建平台里可以理直气壮地做得很深。同时，自建平台也是一个极佳的学习场：你需要同时面对编排、记忆、可观测性、安全策略等一系列问题，而这些经验在市场上非常有价值。

但我也要提醒一点：自建平台不是“从零写框架”。绝大多数团队都不应该重新发明轮子，而是在开源框架之上，叠加企业需要的外层能力：统一鉴权、租户隔离、审计日志、灰度发布等。这需要你有能力把控住“上游更新”和“定制需求”之间的平衡。

4. 实操：搭一套能跑起来的 Agent 基础设施

前面讲的都是战略层，接下来我们落地。我会以一个假设的“内部工单处理 Agent”为例，带你走一遍搭建 Agent Infra 的全过程。

4.1 最小可用架构长什么样

假设业务目标：员工提交工单后，Agent 自动分类、检索历史解决方案、生成答复建议，并在无法解决时转人工。

一个最小可用架构至少包含这几个模块：

• 接入网关：接收消息，管理对话轮次，做简单的用户身份识别。
• 编排引擎：决定 Agent 的执行步骤（先分类还是先检索？什么条件下需要转人工？）。
• 记忆模块：保存当前工单上下文、历史处理记录、用户偏好。
• 工具层：封装工单系统 API、知识库检索 API、人员分配 API。
• 模型网关：统一管理模型调用，负责重试、降级、成本追踪。
• 追踪与日志：记录每一轮模型输入输出、工具调用参数与结果。

我的建议是：第一版不要追求微服务化，这些东西完全可以跑在一个进程里。先跑通端到端链路，再考虑扩展性。

4.2 核心模块的选型与权衡

选型时最容易踩的坑是“全部自己造”和“全盘依赖大平台”两个极端。我的建议是中间路线：

• 编排框架：优先选有活跃社区、支持显式流程定义的框架，尽量避免只依赖“让模型自由发挥”的无结构方案。无结构方案适合 Demo，生产环境会让排查问题变成噩梦。
• 记忆模块：如果场景以短期上下文为主，用分布式缓存就够了；如果确实需要跨会话用户画像，再上向量数据库。千万不要为了追概念，一上来就搞一套复杂记忆分层。
• 工具调用：优先采用“工具即函数”的模式：每个工具定义好入参、出参、错误码，由编排层统一调度。模型只负责生成“调用意图”和关键参数，不直接触碰业务系统。
• 模型网关：如果你的团队已经有不少 API 调用经验，可以自己封装一层简单的统一接口；如果是从零开始，直接借助云厂商的网关服务会更稳妥。

工具选型没有绝对正确答案，关键是你要能说出每个选择“牺牲了什么”。比如你选了功能最全的大平台，就牺牲了迁出的自由；你选了轻量开源自建方案，就承担了运维维护的成本。能在心里时刻装着这笔账的人，才不会被厂商锁定坑到。

4.3 关键参数与配置经验

很多 Agent 项目翻车，不是架构不对，而是配置参数完全凭感觉。我把几个关键参数整理一下，全都是实战中验证过的经验值。

首先是温度（temperature）和 top_p。分类、抽取这类结构化任务，温度建议调到 0.1 以下，甚至直接设 0，尽量让输出稳定。而开放式生成，比如给用户写一段安抚话术，温度可以放到 0.7 左右。如果你用同一个模型既做结构化判断又做自由文本生成，记得按任务分别调用，不要在同一个会话里来回改参数，很容易混淆结果对比。

其次是最大迭代步数。Agent 任务经常需要工具循环，但如果循环不设上限，一个 bug 就能让成本爆炸。作为起步值，单任务最大步数建议控制在 8 到 10 步，复杂任务最多也不要超过 20 步。超过上限就强制触发“转人工”分支，把控制权交还给用户。

然后是超时与重试。模型 API 和工具 API 都可能慢或失败。我的经验是：模型调用超时设 30 秒到 60 秒，重试两次；工具调用超时应按具体业务定，但宁可设短一点，也不要让用户长时间等待。重试必须做“指数退避”，否则故障时所有请求同时重试，会把下游系统彻底击穿。

最后是并发度。很多 Agent 应用是耗时的“异步作业”（处理文件、生成报告、批量分析），这类任务应当走消息队列，把并发数控制在个位数到几十之间。千万不要把这种任务挂在用户请求线程里同步等待，否则服务一有流量波动就雪崩。

4.4 从 Demo 到生产的落地清单

即使架构和参数都没问题，从 Demo 到生产还是会漏掉很多细节。我整理了一份自己的检查清单，每次上生产前都过一次：

• [ ] 所有工具调用都做了鉴权和白名单：Agent 只能访问被授权的最小资源集。
• [ ] 模型输出做过 schema 校验：不仅校验格式，还要校验枚举值范围，防止出现不在业务定义内的动作。
• [ ] 有完整追踪：每个请求生成一个 trace_id，模型调用、工具调用、状态变更都能串起来查。
• [ ] 有降级方案：模型服务不可用时，流程能降级成人工处理，而不是把所有用户请求都打死。
• [ ] 有成本仪表盘：按用户、按任务类型、按模型维度统计 token 消耗，设置告警阈值。
• [ ] 有审计日志：Agent 做出的所有关键动作（创建、修改、删除、发给外部系统）都有留痕，方便合规审查。

这份清单看起来都是“脏活”，但它们才是 Agent 基础设施真正值钱的部分。很多人做 Agent 只关注“聪明不聪明”，忽略了“安全不安全”“可靠不可靠”，结果 Demo 演示全场鼓掌，上线半天就翻车。

5. 在生产里踩过的坑和排查手记

5.1 问题一：Agent 进入死循环，疯狂调用同一个工具

这是 Agent 生产环境最高频的问题。具体表现是：Agent 反复调用同一个检索工具，每次返回相同结果，但它就是不停下，导致 token 消耗飙升、用户体验极差。

排查思路分两层。第一层检查编排引擎的“循环检测”：是否记录了每个工具最后一次调用参数？如果完全一致，直接终止并给出兜底响应。第二层检查提示词设计：很多死循环是因为模型“误以为”结果不完整，想再确认一次。我们当时的修复方案是在工具返回结果的额外注释里加上一句“这是基于当前条件的最新结果，请依据它给出最终答案”，循环率直接降了一半。

如果你们用的是开源框架，优先检查是否有内置的重复调用检测，没有的话自己写一个也没多难，就是维护一份调用哈希表。

5.2 问题二：工具调用失败导致“看起来在干活”

另一个高频问题是 Agent 调用的工具返回了异常，但 Agent 没有感知到，反而顺着错误信息继续生成内容。比如工具返回“权限不足”，Agent 却开始向用户解释“系统正在处理中”，用户以为任务在进行，实际上早就停了。

这个问题的根源在于工具返回信息与模型推理之间缺少“中间层语义映射”。我后来做了一套规则：工具返回码分为 SUCCESS、RETRYABLE_ERROR、FATAL_ERROR 三类，前两类可以交给模型决策，第三类直接短路，绕开模型推理，走预设的异常回复流程。这样不仅省 token，而且用户得到的是明确的“失败+原因”，不是模棱两可的敷衍话。

5.3 问题三：可观测性缺失导致无法复盘

Agent 应用的排查难度远高于传统服务，原因很简单：一个错误可能是提示词引起的，也可能是工具返回引起的，还可能是模型随机性引起的。如果日志只有“调用成功/失败”，那你几乎无法定位根因。

我们的经验是：每一轮模型调用都要记录完整输入输出和 token 数，每一次工具调用都要记录参数和响应体，上下文窗口变化也要留痕。说白了就是把每个 Agent 会话变成可以“逐帧回放”的视频，而不是只有一句“第 5 步出错了”的黑盒告警。

有条件的团队建议直接接入可观测性产品，没条件的就在框架里打结构化日志。别用 print 糊弄，等到线上出事再后悔就晚了。

5.4 问题四：评估离线跑分和线上体验脱节

很多团队会在测试集上跑评估指标，但跑分很高，线上用户体感却很糟糕。最典型的原因是评估集“太干净”——示例都是理想输入，而线上真实输入充满了歧义、漏字段、重复提问、无关信息。

后来我们改了评估策略：从线上日志里采样真实请求作为评估集，并且对每个请求人工标注“正确回答”的关键要素，再让模型比对。效果立竿见影，原来测试集准确率 95%，一换真实请求直接掉到 80% 以下。这个反差才是真实水平的反映。

现在我把评估集分成三个子集：理想常规集、边界噪声集、失败恢复集。边界噪声集专门放那些网上接到的奇怪问题；失败恢复集专门测试工具调用半路失败、模型输出超时等故障场景。这样评估出来的结果才真正具备生产参考价值。

6. 写在最后：这一波基础设施浪潮给工程师的启示

我在开头说 Agent Infra 是巨头的隐秘战场，写到这你应该也发现了，它同时也是每个工程师的实操场。巨头能在这一层建立生态优势，但不可能独占所有场景；真正能扎根在具体业务里的基础设施，往往还是要靠我们这些一线工程师一砖一瓦垒起来。

6.1 技能栈要往“系统 + 智能”双修走

过去我们习惯把“工程能力”和“算法能力”分成两条职业路径，但在 Agent 时代，这条界限正在快速模糊。一个合格的 Agent 开发者，既要懂分布式系统里那些稳定可靠的经典手段——队列、缓存、限流、幂等、重试，又要理解模型的概率性本质——输出不固定、可能产生幻觉、需要校验和兜底。

我强烈建议还在观望的工程师，从今天开始有意识地搭建这套双修能力：在一个开源 Agent 项目上跑一个完整 Demo，再把其中一个环节做到“生产级”——即加入重试、日志、鉴权、测试。这不是很难，但它会逼你去同时面对系统和模型两侧的问题。

6.2 入场之后的三种成长路径

选了第一层“做应用”的人，会往行业专家方向走：你越来越懂某个行业（比如客服、招聘、供应链）的流程痛点，你的价值在于把行业经验翻译成 Agent 能执行的流程，这种人稀缺且不容易被替代。

选了第二层“改开源”的人，会往工具生态和开源影响力方向走：你的代码会被大量开发者使用，你的名字会成为简历上最有说服力的部分，这条路也更适合将来创业做开发者工具。

选了第三层“自建平台”的人，会往企业架构师方向走：你负责的不只是某个 Agent，而是整个公司的 AI 应用生产方式，这种位置晋升快，但确实压力也大。你可以先从一条业务线试点，做出口碑后再横向扩。

6.3 我的个人体会与建议

最后说几句掏心窝的话。我从一开始的“追热点式”做 Agent，到现在把重心放在基础设施稳定性和可演进性上，最大的体会是：Agent 的复杂度不在于某个单一的“灵感时刻”，而在于大量真实场景中琐碎而繁杂的工程决策——工具到底怎么切分、记忆多久过期、失败时用户看到什么、评估集是否真实反映环境。

如果你现在觉得自己被铺天盖地的“Agent 重构一切”的说法弄得很焦虑，我的建议很简单：找一个你真正熟悉的业务场景，用 Agent 基础设施把它做深做透。不需要去追赶那些还在 PPT 阶段的宏大概念，只需要把你手里的项目做得比任何一个 Demo 稳定一点、安全一点、可复盘一点，你就已经在牌桌上了。

最后再分享一个我近期坚持的小习惯：每次上线 Agent 功能前，自己亲自在测试环境里完整跑十遍“用户可能乱来的路径”，而不是只跑理想路径。这十遍里，通常会有两三个意外收获，它们救过我不止一次线上事故。这一行没有任何捷径，多跑一遍，心里就多稳一分。