高校智能体平台微服务架构设计与稳定性治理实践

过去一年我带着团队设计并落地了一套面向高校场景的智能体平台，从招生咨询、教务问答到课程智能助教，前后拆出了十几个微服务，也踩过不少坑。这篇内容把我在这套系统上的架构决策、服务划分、链路实现和稳定性治理经验整理出来，给正在做同类事情的AI架构师做个参考。

先说结论：高等教育场景下的智能体，本质上不是一个“会聊天的机器人”，而是一个要对接学校业务系统、承接多轮对话、支持流式输出和工具调用的复杂业务系统。这种系统如果用单体架构硬扛，前期确实跑得快，但到场景一多、模型一换、流量一涨，就会处处掣肘。微服务不是银弹，但在这个领域，拆对了确实能让团队并行开发、模型灰度切换和业务能力复用都舒服很多。

1. 先想清楚业务边界，再谈微服务

1.1 高校智能体不是“一个聊天机器人”

先定义我口中的“高等教育智能体”。它不是官网上挂着的那个FAQ问答框，而是覆盖招生、教务、教学、科研、就业等多个业务域的智能服务集合。我梳理过一所本科院校的真实需求，至少包括：

• 招生咨询智能体：回答专业设置、分数线、奖助政策、宿舍条件；
• 教务助手：查课表、查成绩、办理流程问答，甚至触发缓考申请、请假审批；
• 课程助教：基于课程讲义做RAG问答，出练习题，答疑；
• 科研助手：文献检索、基金申报政策问答、研究方向建议；
• 学情分析助手：基于成绩和考勤数据做学业预警解读；
• 就业指导助手：岗位匹配、简历修改建议、面试模拟。

这些场景有一个共同点：它们不是单轮问答，而是多轮会话，并且需要对接学校已有的业务系统——教务系统、人事系统、OA流程、统一身份认证。也就是说，智能体要真正在高校里产生价值，必须往里扎，扎进业务链路里，而不只是在模型层做提示词工程。

我当时做架构调研时，也和几个高校信息化中心的负责人聊过。他们的核心诉求惊人地一致：第一，不能只做演示demo，要能接进现有系统；第二，数据主权和隐私合规必须满足；第三，不同院系、不同部门会陆续提需求，平台必须能扩展。这三点直接决定了技术选型的天平倒向微服务——因为只有微服务，才能在“各部门独立迭代”和“平台统一治理”之间找到平衡。

1.2 单体架构为什么扛不住

最早我们其实也是单体应用，把所有能力塞进一个Spring Boot服务里，加一个Python的AI推理模块，用HTTP内部调用串起来。当时想得很简单：业务量不大，模型调用就几个，单体最快。

结果把6个场景放进一个服务后，问题一个接一个冒出来。

• 部署耦合：招生季流量暴涨，我只想扩容招生咨询这一个模块，结果整个服务都得跟着扩，资源浪费严重，还容易把别的模块的JVM内存挤爆。
• 模型供应商切换成本高：我们早期用云端模型，后来想接入本地部署的开源模型做数据合规，发现模型调用的代码和prompt、业务逻辑全揉在一起，换一个供应商要改一堆代码，风险极高。
• 团队协作冲突：两个小组同时改一个代码仓库，一个改RAG策略，一个改意图识别，合并代码时冲突不断，发版要等所有人。
• 故障扩散：某个意图分类规则写了个死循环，CPU被打满，整个智能体平台全部不可用，连最基本的问答都挂了。

有段时间我每天晚上都在看监控，生怕哪个小改动把整个系统拖垮。后来实在受不了，才下决心拆。

这里我总结了一个判断信号，如果你手上也有类似的系统，出现下面两三条，大概率也该拆了：

• 一次版本上线，需要所有模块一起回归；
• 某个场景的prompt或工具逻辑改动，要重新部署整个服务；
• 模型供应商A不稳定，想灰度切到B，发现配置和代码完全耦合；
• 某个业务域的流量洪峰，会拖垮其它无关场景的服务；
• 团队规模超过5个人，代码仓库合并成本开始明显上升。

2. 服务划分：既要按业务拆，也要按能力拆

2.1 业务域拆分的两条主线

微服务划分不是随便切几刀就行。在我这个项目里，划分逻辑有两条主线并行：一条按业务域拆，一条按技术能力层拆。

业务域拆分对应高校里的真实组织形态。招生、教务、课程、科研、就业，每个都是相对独立的业务闭环，有自己的数据、自己的流程、自己的权限模型。每个业务域部署一个独立的智能体服务，比如 admission-agent、academic-agent、course-agent，它们在逻辑上是独立的，互不直接依赖数据库。

技术能力层拆分则对应所有业务域都会用到的通用能力。这些能力如果每个业务域都自己实现一遍，不仅重复劳动，而且很难统一治理。我当时划出了五个核心能力服务：

• LLM网关（LLM Gateway）
• RAG服务（Retrieval-Augmented Generation）
• 记忆服务（Memory Service）
• 工具执行服务（Tool Executor）
• 智能体编排服务（Agent Orchestrator）

业务域智能体服务是“脸面”，能力服务是“肌肉”。业务域服务接收到用户请求后，自己不直接调大模型，而是编排器统一调度能力服务完成任务。这样设计的好处是：新增一个业务域，只要写一套编排逻辑和prompt，底层能力全复用；新增一个通用能力，所有业务域都能立刻使用。

2.2 核心能力服务的职责边界

这五个能力服务的边界我逐一说明，每个都对应了我们在实际落地中反复推敲过的点。

LLM网关是所有模型调用的唯一入口。它的价值不只是封装接口，而是从“模型管理”层面把复杂性收口。高校场景里经常需要同时使用多个模型：本地部署的Qwen、Llama做数据合规场景，云端模型做复杂推理场景。LLM网关统一管理供应商、API Key、配额、并发限制、成本计量，甚至可以做模型路由——按业务域配置默认模型、按请求复杂度决定用大模型还是小模型、按响应时间做降级切换。

RAG服务负责年金库和检索全链路。高校的语料种类特别杂：招生简章是PDF、课程大纲是Word、规章制度是扫描件、论文是LaTeX生成的PDF。不同文档的解析方式完全不同，切片策略也不同。RAG服务独立出来后，我们可以在内部做文档入库流水线，统一处理解析、清洗、切片、向量化、索引管理，业务域不需要关心这些细节。

记忆服务在智能体架构里经常被低估。高校场景有个特点，一个学生从大一到大四，四年都在同一个体系内活动，他的选课偏好、知识薄弱点、咨询历史，这些长期记忆非常有价值。但记忆的读写频次很高，每个请求都要读取会话上下文，如果和业务逻辑耦合在一个服务里，热点问题会把整个服务拖垮。单独拆出来之后，我们可以独立扩容，也可以针对短期记忆和长期记忆用不同的存储方案。

工具执行服务是智能体连接真实业务的桥梁。查课表、查成绩、触发审批流、提交缓考申请，这些操作都要调用学校现有的系统。高校内部系统的技术栈五花八门，有的提供REST接口，有的还是SOAP，有的只能连数据库。工具执行服务把这些异构系统统一封装成标准的工具定义，对上游只暴露统一接口。这个服务还要负责超时控制、重试策略、权限审计，因为涉及真实业务操作，安全要求非常高。

智能体编排服务是所有服务里最接近“大脑”的一个。它负责理解用户意图，决定调用哪些服务、按什么顺序调用、是否需要多智能体协作、最终怎么生成回答。编排服务本身不存业务数据，但它要维护一次会话的执行状态机。

2.3 每个服务独立数据库的代价

微服务架构有个硬性约定：每个服务独享自己的存储。也就是说，跨服务的联表查询是不存在的，只能通过接口聚合或者事件同步来完成。

这个约定在智能体场景里带来了两个直接问题。第一，用户基础信息要在多个服务里重复存储。比如说学号、姓名、所属院系，在编排服务、记忆服务、工具执行服务里可能各存一份。第二，跨服务的数据一致性变得复杂。比如用户在教务助手场景里做了一次缓考申请，这个状态既要更新工具执行服务的记录，也要更新记忆服务的长期记忆。

我在实践中的处理方式是分场景：

• 高频读取、低频变更的基础数据（比如用户身份信息），用本地缓存加TTL，容忍短时间不一致；
• 需要严格一致的业务数据（比如审批状态），通过领域事件异步同步，必要时用事务性消息表保证最终一致；
• 坚决避免跨服务直接查库，所有数据访问必须走服务接口。

很多团队在拆微服务时只拆了代码，没拆数据库，最后越拆越痛苦。我的体会是，数据库不拆，服务的独立性就是假的。但拆数据库也意味着要接受“读模型的冗余”，这个权衡必须想清楚。

3. 核心链路的技术选型与实现细节

3.1 通信协议：gRPC还是HTTP/JSON

服务间通信我采用了混合策略。低频的控制面通信，比如服务注册发现、配置下发、管理接口，用HTTP/JSON，简单直接，调试方便。高频的数据面通信，尤其是AI推理过程中的流式返回，用gRPC的双向流。

为什么流式返回要单独考虑？因为大模型生成token是流式的，用户看到的是一个个字蹦出来。如果内层服务先等完整结果再一次性抛给前端，用户等待时间会非常长，体验极差。所以从编排器到业务域服务、从业务域服务到前端，都要支持流式透传。

gRPC在这个场景的优势是双向流（bidi streaming）天然支持流式消息，而且有背压控制机制，不会因为下游消费慢把内存打爆。HTTP虽然有chunked encoding也能做流式，但在服务间转发时，连接管理和错误传播不如gRPC精细。我们最终的方案是：前端到业务域服务采用SSE（Server-Sent Events），业务域服务内部采用gRPC双向流。前端拿到SSE流，后端一路透传到模型层。

这里有一个细节：SSE不能传自定义请求头，鉴权信息只能放在query参数里或者用Cookie。我踩过这个坑，建议在网关层把SSE的鉴权提前处理好，不要让业务服务去解析SSE的URL参数。

3.2 状态管理：有状态会话怎么设计

智能体天然是有状态的。用户上一轮问了什么，这一轮的指代（比如“它的学分是多少”），都需要上下文的支撑。在单体架构里，这个状态放在内存里就行，但在微服务架构里，会话状态必须独立出来。

我的设计是三层记忆模型：

• 短期记忆：保存在Redis里，以Session ID为key，存储最近几轮对话的完整内容和当前执行状态，TTL设置为30分钟；
• 中期记忆：保存在向量数据库里，存储一次会话中抽取出的关键实体和结论，用于同主题会话的召回；
• 长期记忆：保存在关系库里，存储用户的画像、偏好、历史咨询记录，按学号关联，永久保留。

每次请求进来，编排器先从Redis恢复短期记忆，再从向量库召回中期记忆，最后根据用户ID从关系库拉取长期记忆，三者拼装成完整的上下文，再交给模型。这样设计的好处是，任何一个服务实例挂掉，用户的会话状态都不会丢，因为状态不在进程内存里。

Session的数据结构大致是这样的：

json复制{
  "session_id": "sess_8f3a...",
  "user_id": "202400123",
  "business_domain": "academic",
  "created_at": "2025-06-01T09:00:00Z",
  "updated_at": "2025-06-01T09:05:00Z",
  "recent_turns": [
    {"role": "user", "content": "我大二上学期高数挂科了"},
    {"role": "assistant", "content": "看到您有高数（上）不及格记录，需要我帮您查询补考安排吗？"}
  ],
  "context": {
    "current_intent": "retake_query",
    "extracted_entities": {"course": "高等数学(上)", "term": "2024-2025-1"}
  }
}

短期记忆的写入要在每一轮问答结束后异步完成，避免阻塞响应。这里要注意并发问题：同一用户连续发两条消息时，后一条消息可能先完成推理，导致前一条写入被覆盖。我通过Redis的WATCH或者版本号字段来解决，保证写入的单调递增。

3.3 RAG链路的关键参数与文档治理

RAG服务是高校智能体的重头戏，因为绝大多数问答都依赖知识库检索。我在这个模块上花的时间最多，也最有心得。

先看在线检索链路：用户问题进来后，RAG服务先做query改写（把口语化表达转成更适合检索的形式），再做向量检索，然后做重排（rerank），最后把召回的段落拼装成上下文返回给编排器。关键参数我建议这样设置：

• 切片大小：高校文档通常按章节结构写，固定字符切片会切断语义。我们用的是结构感知切片，优先按标题层级切，每个切片控制在500字左右，重叠100到200字。
• topK：初筛取20条候选，重排后取前5条送入模型。topK太小召回容易漏，太大会把噪声灌进上下文，增加模型幻觉风险。
• 召回分数阈值：相关性分数低于0.35的直接丢弃，宁可让模型说“这个我不知道”，也不要强行编造。

在线链路只是表象，真正要花精力的是文档入库流水线。高校文档每年都在更新，比如招生简章每年都要换版本。文档更新时，不能把旧索引彻底删掉重来，因为同时间段可能有用户在查询。

我的实现是给每个文档建立版本号，向量化时写入 doc_version 字段。检索时默认只查最新版本，同时保留历史版本用于回溯。文档入库采用异步任务队列，新文档解析完成、向量化完成、索引切换完成后，旧索引才被标记过期。整个过程对在线检索无感。

高校的知识库还有一个特点：不同业务域的知识要严格隔离。招生办的文档不能混进课程助教的知识库。所以RAG服务的知识库设计上，每个业务域对应独立的Collection，向量化时在metadata里写入 domain 字段，检索时强制过滤。

3.4 工具接入与安全审计

工具执行服务对外提供统一接口，对内接各种异构系统。每个工具的定义我设计成标准结构：

json复制{
  "tool_name": "query_score",
  "description": "查询学生成绩",
  "parameters": [
    {"name": "student_id", "type": "string", "required": true, "description": "学号"},
    {"name": "term", "type": "string", "required": false, "description": "学期"}
  ],
  "auth_type": "oauth2",
  "timeout_ms": 3000,
  "retry_times": 1
}

这些工具定义会同步给编排器，模型根据定义决定何时调用、传什么参数。这里有个安全关键点：高校系统的敏感操作（比如提交申请、修改信息）绝对不能由模型自动执行，必须设置人工确认节点。

工具执行服务里我加了一个 human_confirmation 标记。标记为true的工具，执行到一半会暂停，把待确认的操作信息推给用户，用户明确同意后才继续。这个机制有效避免了模型误判导致的错误操作。

审计方面，工具执行服务每次调用都会记录完整日志：谁调用的、用的哪个工具、传了什么参数、返回了什么结果、耗时多久。这对高校的合规审查非常重要，后续追溯时不用翻好几个服务的日志。

3.5 与主流开源平台的取舍

调研过程中，我们也评估过Dify、Coze、MaxKB这些开源或商业化智能体平台。这些平台在快速搭建原型时效率很高，尤其是Dify的工作流编排界面，业务人员也能上手。但落到我们这种要和学校多套业务系统深度集成、要支撑多个独立业务域并行迭代的场景，通用平台的定制成本反而更高。

最终我们采用了一个混合路线：底层能力服务完全自研，业务域编排层借鉴了Dify这类平台的“应用即工作流”思路，在编排服务里实现了类似的可视化配置面板。这样既有自研的灵活性，又有低代码平台的上手效率。如果你的团队人力有限，从Dify这类平台起步，把高校业务封装成平台里的工具调用，也是一种务实的过渡方案。

4. 一次完整请求的流转：编排器怎么指挥全局

4.1 从“补考咨询”看完整调用链

与其空谈架构，不如看一个具体场景。假设学生问：“我大二上学期高数挂科了，能补考吗？”

这一步我拆解成13个环节：

1. 前端通过SSE建立连接，请求到达API网关；
2. 网关解析客户端携带的JWT Token，识别用户身份，从统一身份认证中心获取学号、院系等基础信息；
3. 网关根据请求路径路由到 academic-agent 业务域服务；
4. academic-agent 把Session ID传给记忆服务，加载短期和中期记忆；
5. 记忆服务返回历史上下文，发现这是新会话，没有历史；
6. academic-agent 将用户问题和上下文交给编排服务；
7. 编排服务调用意图识别模型，判定意图是“补考政策咨询”；
8. 编排服务根据意图，从工具注册表里匹配工具：查成绩（query_score）、查补考安排（query_retake_policy）；
9. 编排服务调用工具执行服务，工具执行服务分别请求教务系统成绩接口和补考安排接口；
10. 工具执行服务拿到结果：用户确实有高数（上）不及格记录，补考安排在下一学期第2周；
11. 编排服务又把“补考规定”的查询请求发给RAG服务，RAG服务从教务知识库中检索出补考政策原文；
12. 编排服务把工具返回的结构化数据、RAG检索到的政策段落、历史上下文拼装成最终prompt，调用LLM网关；
13. LLM网关选择模型生成回答，通过gRPC双向流把token逐字返回给编排服务，编排服务再通过SSE推给前端。

整条链路看似长，但P99实测稳定在2.8秒左右，首token返回大约0.6秒。用户体感是：问题发出去，不到一秒开始出字，两三秒内拿到完整回答。如果不做流式，等到全部生成完再返回，至少需要5秒起，那体验就是质的差别。

4.2 多智能体协作在高校场景的适用性

这个话题我多说几句。现在多智能体概念很热，但并不是所有场景都适合上多智能体。在高校场景里，我觉得真正有必要上多智能体协同的场景是跨域复杂任务。

拿“转专业咨询”举例。学生问：“我想从计算机转专业到建筑学，有什么要求？”这个问题至少涉及教务处的转专业政策、目标学院的接收条件、学分转换规则、时间节点。如果让一个智能体同时处理这么多知识域，prompt会非常臃肿，检索的知识库也需要跨多个Collection。

我们在这类场景里用了类似“主管-下属”的双层编排：主管智能体负责拆解任务，把问题分成子任务，分发给招生政策智能体、学分规则智能体、时间节点智能体，最后汇总各子智能体的回答，生成统一答复。

智能体间的通信，我关注了A2A（Agent-to-Agent）协议的进展，但目前生产环境还是用我们内部的RPC协议，因为要保留状态传递、错误重试和超时控制。MCP（Model Context Protocol）我们倒是已经在用了，主要用于标准化工具接入。如果后续A2A生态成熟了，再考虑平滑迁移。

4.3 流式输出的跨服务透传方案

流式透传是整个链路设计里最容易翻车的地方。前端到业务域服务用SSE，业务域服务到编排服务用gRPC双向流，编排服务到LLM网关再用gRPC双向流。三层流式嵌套，有一层处理不好，用户就会看到“字蹦一下停两秒”的卡顿。

几个关键处理：

• 背压传递：下游生成速度大于上游转发速度时，不能盲目在内存里堆积。我们给每个流式连接设了固定缓冲区，满了就通过gRPC的流控机制反压到上游，让模型放慢生成速度；
• 超时控制：流式连接不是建立就完事，模型侧可能生成到一半挂了。我们设置了空闲超时（10秒没有新数据就断开），还有全流程超时（最多180秒，超过强制终结）；
• 错误传递：LLM网关内层出错时，不能直接在流中间断掉，那样用户只看到一句话说了一半。我们用流内错误消息传递，把“抱歉，我遇到一个问题，请重试”作为正常的SSE消息发给前端。

4.4 数据一致性与分布式事务

微服务之间天然存在分布式事务问题。高校智能体里最容易踩坑的是“申请审批类”操作。学生通过智能体发起缓考申请，工具执行服务调用了OA系统成功创建审批流，这时如果编排服务后续环节超时失败，学生可能会看到“申请失败”的提示，但OA里其实已经有一条审批在跑。

这个问题的标准解法是Saga模式。我们在工具执行服务里对每个跨服务操作设计了“补偿动作”。创建审批流成功，但后续环节失败时，执行补偿——调用OA的撤销接口，把刚创建的审批流废掉。

具体实现上，我们没有引入复杂的Saga框架，而是用一张“事务日志表”记录每个操作的阶段，配合定时任务做补偿扫描。这个方案虽然土，但足够可靠，也容易排查问题。

5. 稳定性治理与可观测性

5.1 智能体场景的四大稳定性威胁

智能体系统的稳定性威胁，和传统CRUD系统很不一样。我总结了四类：

• 模型调用超时：大模型推理动辄几秒到几十秒，远超普通接口的毫秒级标准；
• 上下游波动：教务系统在选课高峰会卡顿，工具执行服务调它就会超时；
• 流量洪峰：招生季的咨询量是平时的10倍以上，且集中在志愿填报的那几天；
• 模型幻觉与错误输出：这虽然不是“宕机”，但对用户体验的伤害不亚于宕机。

5.2 限流熔断降级策略

针对前两类威胁，我们在LLM网关和工具执行服务两个流量入口都做了治理。

限流按两层做：业务域维度限流（比如课程助手每秒最多100个并发请求）、用户维度限流（单个用户每秒最多3个并发请求，防止刷接口）。招生季时，我们会给 admission-agent 单独调高配额，同时限制匿名游客的请求频率。

熔断用的是类似Resilience4j的思路，但在配置上做了适应AI场景的调整：

• 慢调用阈值：超过8秒就算慢调用，因为模型调用本来就慢，不能用普通接口50ms的标准；
• 熔断窗口：30秒内慢调用比例超过40%，触发熔断15秒；
• 熔断后的降级方案：返回缓存答案（如果知识库有相关FAQ），或者提示“当前咨询量过大，请稍后重试”。

工具执行服务的熔断阈值更严格，因为它是查真实业务系统，慢会影响学校系统的稳定性。对教务系统的调用，超过3秒就快速失败，绝不阻塞。

5.3 全链路追踪与Token级观测

微服务架构最大的排查难点是问题定位。用户说“回答很慢”，到底是网关慢、模型慢、RAG慢还是教务系统慢?没有全链路追踪根本没法定论。

我们团队在关键路径上接入了OpenTelemetry，每个请求生成一个TraceID，贯穿API网关到LLM网关的每一跳，并标记各Span的耗时。排查慢请求时，直接看Trace水焰图，一眼就能定位瓶颈。

此外，我们对LLM调用做了专门的Token级观测，记录每次调用的模型、输入token数、输出token数、耗时、成本和返回状态。这带来了两个额外价值：一是成本核算可以精确到业务域、到用户；二是可以监控输出质量，比如记录每次生成的截断标志，判断是否因为max_tokens设置导致回答不完整。

可观测性三板斧缺一不可：指标（Metrics）、日志（Logs）、追踪（Traces）。我们统一通过OpenTelemetry Collector汇聚，再打到监控系统。微服务架构下，绝不能有哪个服务自己另搞一套日志系统，那会让排查问题变成灾难。

6. 踩坑实录与常见问题排查

6.1 高频问题速查表

我把上线半年多来最常遇到的问题整理成了一张表，按出现频率排序：

6.2 三个值得记录的案例分析

这里展开讲三个我印象最深的案例。

第一个是“会话串线事故”。那是上线初期，我接到学生反馈说“系统用别人的名字叫我”。排查后发现，问题出在前端没有把Session ID放进SSE连接，网关按连接维度生成了新Session ID，Redis里又以Session ID为Key存储上下文，结果两个人复用了同一个连接，串了线。修复方案是：SSE连接建立时强制传入会话ID和用户ID，Redis Key改为 session:{domain}:{user_id}:{session_id}，三层维度确保唯一。这个问题让我们深刻意识到，微服务架构下，会话标识规范必须在第一个版本就定义清楚。

第二个是“招生季雪崩”。去年7月某天下午，访问量突然飙到平时的12倍，然后整个平台不可用。复盘发现限流配置只作用在API网关层，没有做容量预估和自动扩容。我们上了招生季专项预案：提前为 admission-agent 预留20个实例，限流阈值动态调整，RAG服务开启缓存模式，热门FAQ走本地缓存不走模型。调整后扛住了高峰期，P99从3秒降到1.2秒，效果非常明显。

第三个是“模型幻觉引发的舆情风险”。有学生问“挂科是否影响保研”，模型在没有准确知识库支撑的情况下，给出了一段看似合理的回答，但实际政策和学校规定不符。这件事让我们调整了所有业务域的prompt策略：如果RAG召回的段落相关度低于阈值，模型必须回答“我暂时没有掌握这个信息，建议您咨询辅导员或教务处”，严禁根据通用知识推断校內政策。同时给每个回答增加引用溯源，点击能查看知识来源，极大地提升了用户信任度。

6.3 给AI架构师的实操建议

最后说几个我压箱底的建议，都是真金白银换来的：

• 微服务是手段，不是目的。如果团队只有两三个人，业务场景就两三个，别急着拆，一个模块化单体也能跑。我们拆的原因是多个业务域并行迭代的冲突已经严重影响节奏。
• 智能体服务拆分时，最先拆的一定是LLM网关，然后是RAG服务。这两个是所有业务域的公共底座，收益最大。
• 流式透传要在一开始就设计好，后面再加要改的代码量非常大。
• 工具调用的安全审计不能省，高校场景合规要求高，出了问题就是大事。
• 在AI Infra里，可观测性和模型成本管理要前置，不要等出了问题再补。

我个人在实际操作中的体会是，智能体系统的微服务架构，难点不在技术选型，而在领域划分和状态管理。业务域拆分如果跟着行政组织走，通常不会出大错；能力层拆分如果坚持“每个服务可以独立部署、独立扩容、独立迭代”，就成功了一半。这套架构落地后，我们新增一个业务域智能体的时间从原来的三周压缩到了三天，大部分工作变成了写编排逻辑和调prompt，这就是拆分的红利。后续我还在尝试把学情分析领域做成更独立的智能体，并推进MCP标准工具接入，让更多高校业务系统可以快速接入平台，过程有收获也有挑战，但方向是明确的。