做AI应用开发的同学，大概率踩过这个坑：demo阶段搞了一个万能Agent，什么问题都往里塞，效果看着还行。结果一上生产，prompt膨胀、能力串扰、响应不稳定，各种问题全来了。

我在一个教育AI项目里也经历了这个过程，最后重构成多Agent路由架构，稳定性和可维护性都上了一个台阶。核心是五个设计决策：

1. 意图路由：别让一个Agent干所有事

用户意图先经过路由层识别，再分发到对应的专业Agent。每个Agent只处理一类任务，职责单一，出问题一眼定位。

这和微服务的"单一职责"原则完全一致。一个Agent的prompt塞了20种能力，和一个Service写了20个不相关接口一样——迟早要拆。

2. 画像注入：Agent必须理解上下文

每次对话前把用户画像（角色、偏好、历史上下文）注入Agent。不做这一步，Agent的回答千人一面，用户体验直线下降。

具体做法：在Agent路由后、LLM调用前，从用户画像服务拉取上下文，注入到system prompt。

3. Skill动态绑定：工具和Agent解耦

Skill可以独立启用禁用，不需要重建Agent。新增能力只需挂载Skill，运营侧热配置，不依赖发版。

关键设计：Skill是独立实体，通过绑定关系挂到Agent上。启用时先创建Agent再绑Skill，禁用时先解绑Skill再停Agent。

4. SSE流式透传：长链路下的响应体验保障

从LLM到Gateway到前端，三层SSE透传。首字延迟控制在1-2秒，用户感知是"正在思考"而不是"卡死了"。

生产环境必做：断线重连、超时兜底、异常降级。SSE长连接的生命周期管理是最容易出问题的地方。

5. 生命周期管理：启停顺序有讲究

启用时先Agent后Skill（确保宿主就绪），禁用时先Skill后Agent（避免孤儿引用）。

顺序反了会怎样？禁用时如果先停Agent，Skill还挂着，下次启用时可能绑到错误的Agent实例上，导致数据不一致。

总结

Agent编排的核心不是让一个AI什么都会，而是让每个AI只做最擅长的事，然后用路由把它们串起来。

如果你也在做Agent系统，建议从这五个点逐一对照检查——尤其是生命周期管理和SSE透传，这两个是生产环境最容易翻车的地方。

更多AI Agent、RAG、MCP实战内容，关注我持续更新。