企业官网建设流程全解析

前几年聊AI，所有人都在盯着模型的参数规模和榜单分数，一个模型发布，刷屏的是几个基准测试的涨点。但从去年下半年开始，我明显感觉到风向变了。身边做产品的朋友，不再张口闭口“换个大模型”，而是开始问一些更落地的问题：Agent跑起来之后状态存哪里、多个工具调用怎么编排、对话历史太长怎么处理、线上出了问题怎么排查。这些问题的集合，恰恰就是标题里说的Agent Infra——智能体基础设施。它不像模型本身那样光鲜，却直接决定了一个Agent是停留在“演示级玩具”，还是能成为生产环境里稳定跑业务的产品。

这篇文章我想把它彻底摊开讲清楚：Agent Infra到底在解决什么问题，为什么各路巨头都在悄悄押注这块“隐秘战场”，以及最关键的——作为普通工程师，不靠大厂资源，怎么自己拿到这张入场券。内容会尽量往实际操作上靠，包括我自己踩过的坑和最后沉淀下来的方案，希望能对正在做或准备做Agent开发的你有实际帮助。

1. 先弄清楚：Agent Infra 到底在解决什么问题

1.1 从模型能力到 Agent 能力，中间隔着一层“基础设施”

很多人对Agent有一个误解，觉得只要模型够聪明，Agent就能自动干活。这个想法在简单demo里勉强成立：给模型一段Prompt，让它调用一个工具，能跑通就算成功。但到了真实业务里，事情立刻变复杂。你可以把模型想象成一个刚入职、智商很高但毫无经验的实习生，他脑子转得快，但不知道公司流程怎么走、不知道资料存在哪、不知道出了问题该找谁。你需要的不是一个聪明的实习生，而是一整套让这个实习生能高效工作的办公环境：工位、电脑、内部系统权限、工作手册、汇报机制、应急预案。这套“办公环境”，就是Agent的基础设施。

为什么之前大家不觉得它重要？因为上一轮AI应用大多是单轮对话，用户问一个问题，模型给一个答案，完事了。但Agent的核心是“多步骤任务执行”，它要自己理解目标、拆解步骤、调用工具、检查结果、失败重试，整个过程跨越很长时间，涉及多个系统。这时候，任何一环基础设施缺失，Agent都会像无头苍蝇一样乱撞。模型负责“聪明”，Infra负责“靠谱”，两者缺一不可。

1.2 Agent 基础设施的六大能力面

我把Agent Infra拆成六个能力面，这六个面基本覆盖了从开发到上线的全链路。也是判断一个Agent平台成熟度的主要观察维度。

这六个面不一定每个Agent都需要全部自建。小规模场景可以先用现成组件拼；但一旦业务量上来，每一个面都会成为瓶颈。举例来说，早期一个Agent可能只用向量库存对话历史，但到了几百个用户并发使用的时候，你会发现存储设计、检索策略、上下文窗口的分配都变成了需要认真对待的工程问题，不再是“找个库存起来就行”这么简单。

1.3 一个残酷现实：没有基础设施的 Agent 只能是 Demo

我见过太多项目死在这个坎上。一个团队花两周时间，用现成的Agent框架搭出一个很惊艳的demo，能自己规划任务、调用好几个工具、完成复杂流程，演示效果满分。然后进入开发阶段，问题开始一个个冒出来。

第一个问题是“失忆”。Agent执行一个长任务，执行到一半，上下文窗口满了，最早的步骤被挤掉，它忘记了自己最开始要干什么，开始自由发挥。第二个问题是“失控”。调用外部工具时，接口返回格式和预期不符，Agent开始反复重试同一个错误请求，白白消耗Token和API配额。第三个问题是“黑盒”。线上用户反馈说Agent给出了错误答案，但你完全不知道中间经历了什么——它调了哪个工具、传了什么参数、在哪一步开始跑偏，全部无迹可循。

这些问题都不是模型能力能解决的。它们属于基础设施该管的范畴。所以我现在判断一个Agent项目有没有戏，先不看它的模型调得有多好，而是看它的基础设施是否跟得上。模型可以随时换，Infra的坑如果没填平，换什么模型都白搭。

2. 巨头们的隐秘战场：为什么都在押注同一块地

2.1 巨头切入 Agent Infra 的三个底层逻辑

如果只把Agent Infra理解成“一套技术组件”，你会觉得它没什么特别的，开源拼一拼也能搭。但巨头们看得更远，它们押注的是这个领域背后的三个战略价值。

第一个逻辑是模型层正在快速同质化。头部模型之间的性能差距在缩小，你追我赶的周期从一年缩短到几个月。模型本身越来越难成为护城河，真正的差异点开始转移到工程能力和生态完善度上。谁能让开发者更容易地构建、部署、运营Agent，谁就能在应用层占据优势。基础设施就是那个“更容易”的关键。

第二个逻辑是入口争夺。如果Agent真的成为下一代人机交互的主要形态，那么用户的大量请求会经由Agent转发给各种服务。这个过程中，Agent的基础设施——尤其是工具调度和记忆层——就成了流量的分配层。掌握这一层的玩家，实际上掌握了未来应用分发的入口。这和十年前移动互联网时代争夺应用商店的逻辑非常相似。

第三个逻辑是生态锁定。这一点对开发者来说最切身相关。当你在某个平台上构建了Agent，写了编排逻辑、设计了记忆存储结构、集成了它的工具生态，日后再想迁移到别的平台，成本会非常高。平台方很清楚这一点：基础设施一旦被采用，就形成了深度的绑定关系。

2.2 隐秘战场的三个梯队

虽然不点名具体公司，但观察这个战场,基本能分出三个梯队，它们的切入方式各有不同。

第一梯队是底层资源型的巨头。这批玩家手里有大规模算力和云服务能力，战略很清晰：我不跟你们抢应用，我先把“土地和水电”修好。它们提供GPU实例、模型托管服务、向量数据库、消息队列等一系列云上组件，然后把这些组件打包成“Agent云服务”。对它们来说，Agent Infra是云计算市场的新增长曲线。任何做Agent的公司，无论用什么框架，最后大概率都要跑在它们的基础设施上。

第二梯队是模型和应用型的巨头。它们手里有用户入口和场景，打法更加“接地气”。一边开源自己的Agent框架和工具生态，吸引开发者，一边在自己的产品里集成Agent能力，产生示范效应。这类巨头切入的是“编排”和“记忆”这两个中间层，因为这是离开发者最近、最容易形成依赖的部分。通过开源和产品双轮驱动，它们试图成为事实上的标准制定者。

第三梯队是开源社区和创业公司。这里面有老牌开源项目，也有大量新兴项目。它们填补巨头们看不上的“细碎需求”：比如专门做工具调用可靠性、专门做Agent可观测性、专门做多Agent通信协议。这个梯队的特点是迭代极快，很多创新的最佳实践都是从这些小项目里长出来的，然后被巨头吸收进自己的体系。

2.3 这场竞争的“溢出效应”：为什么对普通工程师是好事

巨头打架，表面上看跟普通工程师没关系，实际上溢出效应非常明显。最直接的一点是：大量原本需要自己从零搭建的底层能力，正在被做成开箱即用的产品。我在两年前想给项目加一个记忆层，需要自己部署向量库、自己处理 embedding、自己写检索逻辑，前后花了好几周。现在云厂商直接提供托管的记忆服务，几十行代码就能接入。这不是因为我变厉害了，是因为巨头们把基础设施的价格打下来了。

另一个溢出效应是开源生态的繁荣。因为巨头们都想抢开发者，所以竞相把自家基础设施的核心模块开源出来，或者大力赞助开源项目。这给我们带来了丰富的学习素材和直接可用的组件。以前想学分布式任务编排，只能去看大厂内部的技术分享PPT，现在开源的编排框架都写得明明白白，读源码就能学到工程精髓。巨头竞争越激烈，普通工程师的入场成本就越低。在它们把最后的“收门票”服务做好之前，我们完全可以自己先搭建一套小规模的基础设施，积累经验，甚至把它变成职业发展中的独特筹码。

3. 工程师的入场券：从使用工具到构建平台

3.1 明确入场位置：先做用户，再做构建者

聊完宏观，落到个人。普通工程师怎么进入Agent Infra这个领域？我的建议非常直接：不要一开始就想着“我要做一个平台”，而是先成为一个重度用户，再转型成为构建者。

这中间的路径大概是这样的：第一步，用现成的Agent框架和云服务搭建自己的应用，把每一个基础组件都真刀真枪地用一遍，理解它们的优劣和限制。第二步，当你用到不满足的点时——比如某个开源的记忆组件在高并发下性能不行、某个编排框架不支持你需要的分支逻辑——这时候你已经具备了“发现问题”的能力。第三步，带着这些问题去读源码、写补丁、或者干脆自己造一个轻量轮子。到了这个阶段，你实际上已经在做Agent Infra的构建了，只是规模还小。

我自己就是这样走过来的。最初我只是想在内部工具里加一个能自主查数据库的Agent助手。一开始用的现成框架，跑通了。但很快发现两个痛点：一是工具调用的错误处理不符合业务需求，二是Long-running任务的状态管理太弱。为了搞定这两个问题，我开始自己写一个小小的工具调度层和一个简单的任务状态存储。写着写着，我发现自己做的东西已经可以抽象成一个通用的内部组件，其他小组也开始拿来用了。整个过程没什么宏大开头，就是从“用得不爽”开始的。

3.2 一个最小可落地的 Agent 基础设施原型

给一个具体可参考的落地案例。我帮某团队搭过一个内部知识助手Agent，需求是：员工可以问它公司政策、项目文档、IT流程等问题，它能自动检索资料并回答，同时能调用一个内部的工单系统来提交请求。规模不大，并发几十，但它覆盖了Agent Infra的核心环节。

架构上我用了一个三层设计。第一层是模型网关，统一对接模型服务，方便后续切换不同的模型供应商，同时实现请求级限流和成本统计。第二层是记忆与检索层，对话历史存在关系型数据库里，文档知识放到向量库里，回答问题时先做语义检索，再把结果组装成上下文。第三层是工具层，把工单系统封装成一个标准工具，定义了输入输出schema，加上超时和重试逻辑。

先看模型网关的简化代码，重点是统一接入和成本统计：

# gateway.py — 模型网关的核心抽象 class ModelGateway: def __init__(self, providers: dict): self.providers = providers # {"openai": OpenAIProvider(...), "local": LocalProvider(...)} self.cost_tracker = CostTracker() async def chat(self, model_alias: str, messages: list, **kwargs): # 根据别名路由到具体模型供应商 provider, real_model = self.providers[model_alias] start = time.time() response = await provider.chat(real_model, messages, **kwargs) # 记录每次请求的token用量和耗时，用于成本归因 self.cost_tracker.record( alias=model_alias, model=real_model, prompt_tokens=response.usage.prompt_tokens, completion_tokens=response.usage.completion_tokens, latency=time.time() - start, ) return response

这个网关看着简单，但它解决了几个实际问题：第一，业务代码不用关心底层到底用的哪家模型，切换只要改配置；第二，每个请求的花费和延迟都被记录下来，做成日报就能看到成本分布；第三，方便做限流，防止某个业务线不小心把预算烧光。

记忆层我用了“摘要+细节”的两级方案。每当对话轮数超过阈值，就把旧消息交给模型生成一个摘要，存为长期记忆，同时保留最近的原始消息。这样既控制Token开销，又不丢失关键信息。这个方案的取舍在拉长会话场景里尤其重要，具体计算后面第4部分会细说。

工具层的实现则体现了一个容易被忽略但入坑极多的环节：函数调用参数的严格校验。模型经常“编造”一些不存在的参数，或者把参数类型弄错。所以我们的工具层在真正调用外部API之前，先做一次schema校验，不合格就返回错误信息让模型重新生成，而不是把脏数据直接打到下游系统。

3.3 技术路线图与学习优先级

根据自己的学习经验和带人经验，给一份分阶段的学习路线图，适合从常规后端转过来的工程师。

第一阶段，夯实基础设施通用能力。无论做什么方向，Agent Infra的底层还是传统后端技术。并发编程、缓存设计、消息队列、数据库索引优化，这些基础中的基础一定要过关。很多Agent基建问题，本质上是高并发和数据一致性问题的换皮表现。这个阶段看经典后端技术书籍和开源项目源码就够了，不需要接触任何Agent特定概念。

第二阶段，专项攻Agent核心技术。重点学习四个模块：任务是编排，了解状态机、工作流引擎和重试策略；第二是记忆系统，看向量数据库的实现原理、Embedding模型的选择和混合检索策略；第三是工具协议，理解Function Calling机制、工具描述schema的编写，以及工具调用的可靠性设计；第四是评估与可观测，学会怎么给Agent建评测集、怎么追踪一次完整调用链。这一阶段最好的学习方式就是读开源项目的源码，尤其关注它们如何设计状态机和上下文管理。

第三阶段，平台化思维养成。当你会搭单个Agent后，要开始思考平台问题：多租户怎么隔离、权限怎么做、计费怎么实现、不同团队开发的Agent怎么共享记忆和工具。这个阶段的重点是抽象能力。我见过很多工程师能写好一个Agent，但写不好一个Agent平台，差距就在于有没有站在“多个团队使用”的角度做设计。

学习节奏上，我建议采用“2+1”模式：两周学一个专项，然后立刻动手做一个对应的小项目，不要光看不练。比如学记忆系统，就自己写一个带向量检索的聊天记忆模块；学任务编排，就做一个支持失败重试的定时任务Agent。亲身踩过一遍，半年后再看这个领域，你已经能读懂大部分基础设施的设计思路了。

4. 实操中的硬骨头：常见问题与排查记录

4.1 状态管理：一切“失忆”的根源

Agent开发中遇到频率最高的坑，就是状态不一致导致的“失忆”。我们之前做过一个报表生成Agent，负责从多个数据源拉数据、汇总、生成报告。有一次线上反馈说，Agent在生成了第一段报告之后，突然开始重复刚才的步骤，生成了两遍一模一样的内容。排查下来发现原因很典型：Agent在生成过程中内存里的状态标记没有被持久化，任务执行到一半进程重启，在途的状态全部丢失，重新拉起后它无法判断“我已经走到哪一步了”，只能从头再来。

解决方案是引入持久化状态机。把Agent的每一步执行结果都写入数据库，每一步都记录前置状态和下一步候选动作。进程崩溃后重启，Agent可以从最近一个成功状态继续执行，而不是从头开始。实现上有两个细节需要特别注意：一是状态写入要“先写后执行”，不能先干活再补状态，否则崩溃的时候状态还是旧的；二是状态版本化，每次更新都递增版本号，防止并发情况下状态被旧请求覆盖。

4.2 工具调用：Agent 最容易翻车的地方

工具调用是Agent和外部世界交互的窗口，也是出错的重灾区，大概分成三类：参数幻觉、反复重试、安全越权。

参数幻觉指的是Agent生成了一个看起来合理但实际上不存在的参数。比如一个工具接受department_id，Agent基于对业务的理解“编造”了一个不存在的部门编号传进去。这种情况只能用严格校验来解决：在调用真实API前，用JSON Schema校验Agent生成的参数，不匹配就让模型重新生成，最多重试三次，超过就放弃并告知用户。不要相信模型的自我纠错能力，重复错三次的比率比我预想的高得多。

反复重试是另一个典型问题。当外部API返回错误时，Agent会倾向于用相同参数再次调用，形成一个死循环。我们的对策是给每个工具调用设置最大重试次数，并且强制要求“重试必须修改参数”，不允许原样提交。还会引入幂等键，保证同一任务请求在服务端只被处理一次。这两个组合拳基本消灭了工具调用死循环的问题。

安全越权则更隐蔽。当Agent同时接入了只读查询工具和写操作工具时，模型偶尔会“自作主张”地调用写工具，做一些用户没要求的事。这个必须在基础设施层拦截：在工具注册表里给每个工具标记操作等级，只读操作可以放行，写操作必须经过额外的用户确认环节。Agent的基础设施里，安全边界不应该依赖模型的自觉性，而应该靠机制强制兜底。

4.3 上下文工程：Token 消耗失控怎么办

Agent跑着跑着，Token费用突然飙升，是很多开发者的噩梦。核心原因往往是上下文管理做得太粗糙。最典型的错误：把整段对话历史从头到尾全部塞给模型，随着轮次增加，输入的Token线性增长，成本也跟着线性增长。

举个例子，假设每次问答约1000 Token，一个用户连续对话50轮，完整历史就是50000 Token。如果用户量是1000人，每一轮新问答都要带着50000 Token的历史一起发送，这个成本是惊人的。问题还在于，模型处理超长上下文的速度也在下降，用户体验一并受损。

解决方案是上下文分层。我在实践中用“摘要层+最近消息+检索层”的结构。对话进行到10轮以后，把更早的对话缩成一个不超过500 Token的摘要，替换掉原始聊天记录；那些被压缩进摘要的细节，如果后续问到，通过检索原始记录来补充。

# context_manager.py — 上下文压缩的简化实现 class ContextManager: def __init__(self, max_rounds=10, max_summary_tokens=500): self.max_rounds = max_rounds self.max_summary_tokens = max_summary_tokens def get_recent_messages(self, history): # 直接保留最近的max_rounds轮 return history[-self.max_rounds:] def get_summary(self, history, model_gateway): # 超出保留轮数的部分，压成summary old_messages = history[:-self.max_rounds] if not old_messages: return None summary_text = model_gateway.summarize(old_messages, max_tokens=self.max_summary_tokens) return {"role": "system", "content": f"以下是更早对话的摘要: {summary_text}"} def build_context(self, history): recent = self.get_recent_messages(history) summary = self.get_summary(history, self.model_gateway) if summary: return [summary] + recent return recent

这样把输入Token从“线性增长”变成“轮回时重置”，长期对话的成本从几十万Token降到几千Token量级。算一笔账就明白差距：不做压缩的情况下，50轮对话折合50000 Token；做了压缩之后，同样场景下只需约2000 Token。规模越大，这个优化带来的节省越可观。

4.4 Agent 评测：比你想的更难也更刚需

传统软件的测试对确定性逻辑很有效，但Agent的行为充满概率性，同样输入可能每次输出不同。这种不确定性对评测是一个真正的挑战。很多团队在Agent上线前不做系统评测，直接靠“我觉得它表现还行”来做决策。结果一上生产环境，各种边界情况开始暴露，用户信任度被一次糟糕表现摧毁。

我给Agent项目配置的是“评测集+回归基线+人工抽检”三层结构。评测集包括一百个左右有标准答案的任务，覆盖典型场景和边界情况。回归基线则是每次改动后进行自动化跑批，对比改动前后在评测集上的表现分数，低于阈值就拦住发布。人工抽检则解决自动化评测覆盖不到的主观质量问题，比如回答的语气、逻辑连贯性、是否误解了用户隐含意图。

自动化评测的指标也会因场景而不同，下面是我常用的几个：成功率（任务是否正常完成）、工具调用准确率（调用是否与预期一致）、无效输出的比例（模型胡言乱语或返回空内容的情况）、单任务耗时和单任务成本。表格里总结的这些问题几乎是每个Agent项目都避不开的，值得对照排查。

4.5 常见问题速查表

写在最后的一些体会

回看这两年做Agent相关项目的经历，我自己最大的变化是：从“追模型”转向“搭骨架”。模型迭代永远追不完，但一套牢靠的Agent基础设施，可以稳定支撑业务跑一年两年，而且随着接入的业务越多，它的价值越大。基建的投入不像换模型那样能立刻看到指标上涨，它的回报周期长，但一旦建起来，抗风险能力完全是另一个数量级。

对普通工程师来说，我的看法是：不用等巨头把全套基础设施做成傻瓜式服务再来学，那时候入场券就真的只有“买票”一条路了。现在趁战场还在早期，选择一个小切点，比如把一个开源项目研究透、给自己日常用的Agent加上记忆层、把工具调用的错误处理做得比默认方案更健壮——任何一个都是入场的好姿势。踩过的那些坑、修过的那些状态丢失问题，都是别人拿不走的经验，也是你在下一次技术浪潮里最值钱的资产。