194、Agent即服务（AaaS）架构
半夜两点，我被一条线上告警拽起来。日志里agent的状态码是429，但我们的网关明明配了200 QPS的限流，实际流量才30。盯着屏幕看了十分钟，突然意识到问题不在限流，而在agent自己——它在每个任务里都重新初始化了模型上下文，导致每次请求都做了一次完整的prompt模板渲染和工具注册，CPU直接被打满，而网关看到的只是“慢请求”，不是“超量请求”。那一刻我才真正想明白一件事：当我们把Agent变成一种服务对外提供时，瓶颈往往不是模型API，而是我们自己架构里那些“顺手写”的代码。
那段时间我们内部正在推“Agent即服务”的路线，也就是AaaS。简单说，就是把一个或者一组Agent封装成具备SLA、可观测、可治理的远程服务接口，让业务方像调用普通REST接口一样调用智能体能力。听起来很优雅，但真正落地的时候，全是坑。
先说说最基础的服务粒度问题。很多人一开始会把整个Agent塞进一个HTTP handler里，里面跑完整的reAct循环：思考、调工具、再思考、再调工具。第一次跑通很容易，但生产环境一秒来十个并发请求，每个请求内部有五次工具调用，每个工具又要等外部系统的响应，这时候你的线程池、连接池、超时控制全部乱掉。我当时调试一个工单自动分类agent，发现调用方经常报read timeout，但我们的服务端处理时间中位数才200ms。后来抓包看到是agent在循环里调了一个内部知识库接口，而这个接口的客户端连接池配置成了1，多个agent实例互相等连接释放，整个服务像死锁一样卡住。所以AaaS架构第一课：不要把agent的内部循环直接暴露给网络层，一定在它外面套一层“会话门面”，把每次完整的任务交互封装成幂等的服务
