1. 为什么“基础设施”这个词在小团队语境下需要重新定义先把一个容易跑偏的认知掰正小团队做 AI 基础设施不是去复刻大厂那套 GPU 集群调度、分布式训练框架、千卡互联的活儿。那条路对十几个人甚至几个人的团队来说投入产出比低到离谱光是运维成本和硬件折旧就能把现金流拖垮。我见过好几个小团队一上来就想做“中国的某某云”“某某推理平台”结果半年烧完融资连一个稳定付费客户都没跑出来。那“只有这一层”到底指哪一层我的判断是面向 Agent 的垂直基础设施层。再具体一点是夹在底层大模型 API 和上层具体应用之间的那一层——它不训练模型不卖算力而是解决 Agent 在真实业务里跑起来时那些又脏又累又绕不开的问题记忆怎么存、工具怎么编排、权限怎么隔离、调用怎么计费、行为怎么审计、多 Agent 之间怎么协作。为什么偏偏是这一层因为底层模型正在快速商品化。2026 年的现实是主流大模型的推理能力差距在缩小价格战打得飞起单纯做模型封装没有任何壁垒。而上层应用呢又太卷、太碎、太依赖具体场景小团队做应用很容易被大厂一个功能更新拍死。唯独中间这层大厂看不上太脏太细小团队做应用又绕不开自己造轮子成本太高这就是结构性机会。我拿一个真实场景说明这层的价值。假设你做一个法律合同审查 Agent它需要读取用户上传的 PDF、调用 OCR、检索历史判例库、调用大模型做条款比对、生成审查报告、把结果写回用户的文档系统。这里面涉及文件存储、向量检索、工具调用链、错误重试、结果缓存、权限校验、操作留痕。如果每个做法律 Agent 的团队都自己实现一遍那是巨大的重复浪费。而如果有一层基础设施把这些能力标准化团队只需要关注“合同审查”这个业务逻辑本身开发周期能从三个月压缩到两周。这一层的核心特征有三个垂直不是通用平台而是针对 Agent 这类负载专门优化、轻量小团队能自己部署、自己维护、自己改、可组合像积木一样按需取用不强制全家桶。接下来我会把这层的几个关键模块拆开讲每个模块都会说清楚它解决什么问题、为什么这样设计、以及实际落地时容易踩的坑。2. Agent 记忆层从“存下来”到“记得住、找得回、忘得掉”2.1 为什么向量数据库不是记忆层的全部答案很多人一提 Agent 记忆第一反应就是“上个向量数据库”。我早期也这么干过用某个开源向量库存对话历史检索的时候做相似度匹配。跑 demo 没问题一上真实业务就露馅用户问“我上周说的那个预算数字是多少”向量检索返回的是一堆语义相似但时间不对的片段因为向量相似度根本不理解“上周”这个时间约束。记忆层要解决的是三个独立问题存储原始数据放哪、检索怎么快速找到相关片段、管理什么时候该遗忘、什么时候该合并、什么时候该提升为长期记忆。向量数据库只解决了检索里的一部分而且是最容易的那部分。我的做法是分层设计。短期记忆用 Redis 或内存队列存最近 N 轮对话读写快过期自动清理。中期记忆用结构化数据库PostgreSQL 就够存带时间戳、带会话 ID、带用户 ID 的事件流支持按时间范围、按类型过滤。长期记忆才用向量库而且存的是经过提炼的“事实”和“偏好”不是原始对话。比如“用户偏好用表格呈现数据”这种结论才值得进长期记忆。2.2 记忆写入的触发时机比检索算法更重要我踩过最大的坑是把所有对话都往记忆里塞。结果就是记忆库迅速膨胀检索质量断崖式下跌因为噪音太多了。后来我改成事件驱动写入只在特定条件下触发记忆写入用户明确表达偏好时“以后都这样”“我不喜欢……”出现关键决策点时“就选方案 B 吧”任务状态发生变更时“这个需求已经完成了”用户纠正 Agent 错误时“不对应该是……”这些触发点需要在上层业务逻辑里埋钩子基础设施层提供统一的写入 API。写入时做一次轻量提炼把原始对话压缩成结构化的事实条目附带来源引用和时间戳。这样检索的时候返回的是干净的事实而不是一堆口水话。2.3 遗忘机制被大多数团队忽略的关键能力记忆不是越多越好。一个 Agent 如果记得用户三年前随口说的一句话并在今天拿来用那不是智能是惊悚。遗忘机制要处理几种情况过期信息比如临时地址、被覆盖的信息用户改了偏好、低置信度信息Agent 自己推断的、没被确认的。我的实现方案是给每条记忆打三个标签置信度用户明确说的 vs Agent 推断的、时效性永久有效 vs 有保质期、访问频率被检索命中的次数。定期跑一个清理任务把低置信度且长期未被访问的记忆降权或归档。这个清理任务的频率和阈值需要根据业务调法律、医疗这类场景要保守闲聊类场景可以激进。实操心得记忆层的 schema 设计一定要预留source和confidence字段哪怕一开始用不上。我见过太多团队后期想加这两个字段结果要迁移全量数据痛苦不堪。3. 工具编排与执行层Agent 真正干活的地方3.1 工具描述的质量直接决定 Agent 的智商上限Agent 调用工具的能力七分靠工具描述三分靠模型本身。我见过同一个模型工具描述写得烂的时候调用成功率不到 40%重写描述后直接拉到 90% 以上。工具描述不是写给人看的文档是写给模型看的“使用说明书”要包含这个工具做什么、什么时候该用、什么时候不该用、参数的含义和格式、返回值的结构、常见错误和应对方式。举个例子一个“查询订单”工具烂的描述是“查询订单信息”。好的描述是“根据订单号查询订单的当前状态、金额和物流信息。当用户询问订单进度、退款状态、或需要确认订单是否存在时使用。参数 order_id 必须是 16 位数字字符串从用户消息中提取不要自己编造。如果返回 not_found说明订单号错误应提示用户核对。”后者把使用场景、参数约束、错误处理都讲清楚了模型调用准确率天差地别。3.2 编排引擎状态机比自由规划更可靠让模型自由规划多步工具调用看起来很酷实际生产环境里极不稳定。模型会跳步、会循环、会忘记已经拿到的中间结果。我的经验是用状态机约束流程用模型填充决策点。基础设施层提供一个轻量编排引擎开发者用配置或代码定义状态和转移条件模型只在每个状态内部做局部决策。比如一个“退换货”流程状态机定义识别意图 → 校验订单 → 判断是否符合退换条件 → 收集退换原因 → 生成退换单 → 通知用户。每个状态内部模型负责理解用户输入、提取参数、生成回复。状态之间的转移由代码控制不交给模型。这样既保留了灵活性又保证了流程可控。编排引擎还要处理几个工程问题超时控制单个工具调用超过 N 秒就中断、重试策略幂等工具可重试非幂等工具要谨慎、并发控制多个工具可以并行调用时怎么调度、上下文传递上一步的输出怎么传给下一步。这些细节看起来琐碎但每一个没处理好线上都会出事故。3.3 工具调用的可观测性出问题时能定位到具体哪一步Agent 出错了最怕的是不知道错在哪。是模型理解错了是工具返回了异常是参数传错了还是编排逻辑有 bug基础设施层必须提供完整的调用链追踪每次 Agent 执行生成一个 trace_id记录每个状态的进入退出时间、每次模型调用的输入输出、每次工具调用的参数和返回值、每个决策点的选择依据。这些数据要能可视化展示最好能一键回放。我团队内部有个规矩任何线上 Agent 异常必须能在 5 分钟内通过 trace 定位到根因。做不到这一点说明可观测性建设不到位。存储上trace 数据量大建议用列式存储或专门的追踪系统保留最近 30 天更早的归档。4. 多 Agent 协作什么时候该拆什么时候不该拆4.1 多 Agent 不是架构炫技是职责隔离手段2026 年“多 AI 协作”是个热词但我看到很多团队为了多 Agent 而多 Agent把一个简单的任务拆成五个 Agent 互相调用结果延迟翻倍、成本翻倍、出错概率翻倍。多 Agent 的唯一正当理由是不同子任务需要不同的工具集、不同的系统提示、不同的权限边界。比如一个客服系统售前咨询 Agent 需要产品知识库和报价工具售后 Agent 需要订单系统和退款工具这两个 Agent 的权限和知识完全不重叠拆开是合理的。但如果只是“一个 Agent 负责理解一个负责生成”那纯属脱裤子放屁一个 Agent 加两段提示词就搞定了。4.2 Agent 间通信消息传递比共享内存更可控多 Agent 协作有两种模式共享上下文所有 Agent 读写同一块内存和消息传递Agent 之间通过结构化消息通信。我强烈推荐后者。共享上下文看起来方便但会导致状态污染、竞态条件、调试困难。消息传递虽然要多写一些序列化代码但每个 Agent 的输入输出都是明确的、可记录的、可重放的。消息格式建议用 JSON Schema 严格定义包含发送方、接收方、消息类型、负载、关联的 trace_id、时间戳。基础设施层提供一个消息总线负责路由、持久化、重试。Agent 之间不直接调用都通过总线通信这样任何一个 Agent 挂掉或重启都不会影响整体流程。4.3 协作中的死锁与循环必须有的熔断机制多 Agent 互相等待、互相触发很容易形成死锁或无限循环。我遇到过两个 Agent 互相认为对方应该先行动结果卡了十分钟直到超时。基础设施层必须内置熔断单个任务的总执行时间上限、单个 Agent 的被调用次数上限、消息队列的长度上限。超过阈值就强制中断返回明确的错误而不是无限等待。还有一个隐蔽的坑Agent A 调用 Agent BB 又调用 A形成环。这在设计时要通过依赖图检查来避免运行时也要有调用链深度限制。我的做法是给每个 trace 维护一个调用栈检测到环就立即报错。5. 合规与安全小团队最容易忽视、出事最致命的一环5.1 数据边界什么数据能进模型什么绝对不能Agent 处理的数据里经常混着用户隐私、商业机密、甚至受监管的敏感信息。小团队往往图省事把整段对话直接丢给模型 API这是巨大的合规风险。基础设施层要提供数据脱敏和边界控制在数据离开你的系统之前自动识别并替换敏感字段身份证号、银行卡号、手机号、地址等只把脱敏后的内容发给外部模型。脱敏不是简单的正则替换要考虑上下文。比如“我的卡号是 6222 开头”这种正则可能匹配不全。我的方案是组合使用正则、命名实体识别模型、以及白名单机制。白名单机制是指只有明确标记为“可外发”的字段才允许传给外部模型其他一律拦截。这个策略偏保守但合规场景下保守比激进好。5.2 审计日志出了事能说清楚“谁在什么时候让 Agent 做了什么”合规审计要求可追溯。基础设施层要记录所有关键操作谁用户 ID在什么时候时间戳通过什么入口渠道发起了什么请求原始输入Agent 执行了哪些步骤调用链调用了哪些外部服务工具列表产生了什么结果输出以及最终谁确认了结果人工审核记录。这些日志要防篡改建议用追加写、带哈希链的方式存储。保留期限根据行业要求定金融类通常要求 5 年以上。日志的查询接口要支持按用户、按时间、按操作类型多维检索方便应对审计和纠纷。5.3 权限模型Agent 不能拥有比用户更大的权限这是最容易被忽略的一条。Agent 代表用户执行操作它的权限应该是用户权限的子集而不是超集。比如用户只能查看自己的订单那 Agent 也只能查看该用户的订单不能因为 Agent 有“查询订单”工具就放任它查所有人的订单。实现上每次工具调用都要携带用户身份上下文工具内部做权限校验。基础设施层提供统一的权限校验中间件开发者定义每个工具的权限要求中间件自动拦截越权调用。这个设计要在架构初期就定好后期补会非常痛苦因为要改所有工具的调用逻辑。注意涉及支付、医疗、法律等强监管场景时建议在 Agent 输出后增加人工确认环节不要完全自动化。这不仅是合规要求也是风险控制。6. 小团队做这层的现实路径与资源分配6.1 不要从零造轮子但核心链路必须自己掌控小团队资源有限全自研不现实。我的建议是通用能力用开源或云服务核心链路的控制权必须在自己手里。比如向量检索可以用开源的消息队列可以用成熟中间件但记忆的写入策略、工具的编排逻辑、权限校验规则这些跟业务强相关的部分必须自己实现、自己维护。为什么因为这些是差异化所在也是出问题时你能快速定位和修复的地方。如果核心链路依赖黑盒服务一旦出问题你只能等供应商这在 to B 场景里是致命的。6.2 技术选型优先考虑团队现有技能栈我见过团队为了“技术先进性”选了一个团队没人会的语言或框架结果开发速度减半维护成本翻倍。小团队选型的第一原则是用团队最熟的技术。如果团队都是 Python 背景那就用 Python 生态FastAPI PostgreSQL Redis 某个向量库这套组合足够支撑绝大多数 Agent 基础设施需求。性能瓶颈出现了再针对性优化不要提前优化。Rust 在 Agent 基础设施里确实有优势性能、内存安全、并发但如果团队没有 Rust 经验强行上就是给自己找麻烦。我个人的经验是核心网关和性能敏感模块可以用 Rust业务逻辑和编排用 Python两者通过 gRPC 或消息队列通信。这样兼顾性能和开发效率。6.3 商业化路径先服务好一类客户再谈平台化小团队做基础设施最容易犯的错是“想做通用平台”。通用平台需要巨大的生态投入和品牌背书小团队耗不起。正确的路径是先深耕一个垂直场景把这类客户服务到极致再逐步抽象出通用能力。比如你先服务法律行业的 Agent 开发者把合同审查、判例检索、合规检查这些场景的基础设施做深做透形成口碑。然后发现医疗行业也有类似需求再把能力抽象一层适配医疗场景。这个过程是自下而上的不是自上而下的。我见过太多团队一上来就画大饼做平台最后什么都没做成。6.4 团队配置三个人也能跑起来的最小配置如果只有三个人我的建议配置是一个后端偏基础设施负责记忆层、编排引擎、消息总线一个全栈偏应用负责工具接入、业务逻辑、前端管理界面一个偏算法和运维负责模型调优、可观测性、部署运维。三个人都要能写代码都要能 on-call。这个配置下前三个月不要追求功能大而全集中把一条核心链路跑通一个场景、三个工具、一套记忆、完整的 trace。跑通之后再横向扩展。我见过五人团队三个月做出七个半成品模块每个都不能用不如三人团队三个月做一个能上线的完整链路。7. 一些踩坑之后的零散经验关于 Agent 安全有个容易被忽视的点提示词注入。用户可能在输入里藏指令试图让 Agent 执行非预期操作。基础设施层要在输入进入模型之前做一层清洗识别并剥离可疑的指令模式。同时工具调用的参数要做严格校验不能因为模型说“调用删除接口”就真的删。关于多 AI 协作我的经验是能单 Agent 解决就别多 Agent。多 Agent 带来的复杂度是指数级的调试难度也是。只有当子任务的工具集、权限、知识库确实需要隔离时才拆。拆的时候Agent 之间的接口要像微服务一样严格定义不能随意传递自由文本。关于成本控制Agent 的 token 消耗很容易失控。基础设施层要提供 token 计量和预算控制每个用户、每个会话、每天的总消耗上限超过就降级或拒绝。这个功能上线越早越好不然月底账单会让你怀疑人生。关于模型切换不要把业务逻辑绑死在某个模型上。基础设施层做一层模型抽象统一输入输出格式底层可以切换不同供应商。这样某个模型涨价或降智时你能快速切换不至于被动。最后说一个心态问题。小团队做基础设施前期会很苦因为基础设施的价值是“让上层跑得更快”它本身不直接产生用户可见的价值。你需要有耐心需要找到愿意为“省事”付费的客户。一旦跑通粘性会很强因为迁移成本高。这个生意不性感但很扎实。