最近帮团队搭建一个内部知识库Agent，原本以为就是调个大模型API，没想到工程化过程中踩了不少坑。从推理弹性到状态管理，再到多Agent协作，几乎每个环节都推翻了我最初的设想。记录几个关键决策点，给同样在做技术选型的同学参考。
一、推理服务的弹性比模型本身更先成为瓶颈
内部工具类Agent有个典型特征：使用频率低，但峰值不确定。一开始直接挂了台带GPU的ECS，结果大部分时间空转，成本极高。后来把推理层迁到事件驱动的Serverless架构，按实际计算时长付费，配合GPU实例的弹性伸缩，资源利用率才回到合理区间。对于中小团队来说，算力成本往往是决定项目能不能活下去的关键，而不是模型参数有多大。
二、"记忆"的实现比想象中麻烦
Agent不是无状态的聊天接口，它需要维护对话历史、用户偏好，甚至向量缓存。我早期尝试把状态全塞到Prompt里，上下文一长就触发了Token上限，且每次重启服务记忆就清零。最终的解法是把长期记忆外置：通过共享文件存储挂载到函数运行环境，实现对话状态的持久化。这属于"有状态Serverless"的实践，也是Agent从Demo走向生产必须跨过的一道坎。
三、多Agent协作不能靠"硬编码"
当业务复杂度上升，单Agent很难兼顾意图识别、知识检索、工具调用和结果汇总。我尝试过把多个Agent用HTTP接口串起来，但调用链路过耦合，调试极其痛苦。后来接触A2A（Agent-to-Agent）协议，才意识到Agent间需要标准化的通信格式。配合类型安全的框架（如PydanticAI）做参数校验，能有效避免模型输出格式错乱导致的工具调用失败。协议层标准化，是多人协作开发Agent系统的前提。
四、务实路径：先跑通，再定制
完全自研周期长，直接采购SaaS又不够灵活。目前比较务实的策略是：基于成熟模板跑通最小可用版本，再逐步替换业务逻辑。比如舆情分析、智能客服这类典型场景，社区已有相对完整的工具链和网关配置可以参考，没必要从零造轮子。
如果你正在做类似的选型，可以看看这个场景化实践合集，整理了从一键部署到高代码定制的参考链路：
AI Agent场景化实践合集
结语
AI Agent的技术栈还在快速迭代，与其追逐最新模型，不如先把工程化底座打稳。Serverless解决算力弹性，NAS和向量存储解决状态持久化，标准化协议解决协作问题——底座稳了，上层业务才能跑得起来。
