AI Agent 与微服务融合架构实战

适用：已有 Spring Cloud 体系，希望接入 Agent 能力的企业
参考架构：国内多家 SaaS 厂商 2025–2026 Agent POC 演进路径

一、为什么 Agent 不能单独成一个「大脚本」？

早期 POC 常见形态：一个 FastAPI + LangChain 文件调用所有 API。问题：

• 与现有 鉴权、审计、限流 体系脱节
• Tool 逻辑复制，与 Java 服务 双份维护
• 长任务无 可靠重试与状态恢复
• 无法满足 等保 对操作留痕的要求

正确姿势：Agent 编排层薄，业务能力下沉到已有微服务。

---

二、推荐分层架构

┌─────────────────────────────────────────────┐
│  Agent Gateway（鉴权、会话、流式 SSE）        │
├─────────────────────────────────────────────┤
│  Orchestrator（规划、Tool 选择、记忆）        │
│  LangGraph / Spring AI / 自研状态机          │
├─────────────────────────────────────────────┤
│  Tool Services（已有微服务 + MCP Adapter）   │
│  order-service │ crm-service │ kb-service    │
├─────────────────────────────────────────────┤
│  State Store（Redis + PostgreSQL）          │
│  Vector DB（RAG）│ Message Queue（异步 Tool）│
└─────────────────────────────────────────────┘

---

三、服务拆分原则

组件	归属	说明
对话 UI / SSE	Agent Gateway	薄层，无业务
Prompt / 规划	Orchestrator	可独立部署，GPU 无关
订单/CRM/工单	现有微服务	通过 Tool 暴露
知识检索	kb-service + Vector DB	RAG 专用
审批流	workflow-service	Human-in-the-Loop

一个 Tool = 一个 bounded context 的原子操作，如 create_ticket、query_order，而非 handle_customer_complaint 大杂烩。

---

四、Tool 微服务化与 OpenAPI 注册

4.1 Tool Schema 规范

# tools/query-order.yaml
name: query_order
description: 根据订单号查询物流状态，仅支持已登录用户自己的订单
parameters:
  type: object
  required: [order_id]
  properties:
    order_id:
      type: string
      pattern: '^ORD[0-9]{10}$'
endpoint:
  service: order-service
  path: /internal/tools/query-order
  method: POST
  timeout_ms: 3000
auth: inherit_session

Orchestrator 启动时从 Tool Registry（Nacos/DB） 加载，模型只看到 JSON Schema。

4.2 调用链

LLM → tool_call(query_order) → Agent Gateway 校验参数
     → Feign 调 order-service → 结果压缩 → 回填 LLM

参数校验必须在 Gateway，不可信任模型输出。

---

五、通信模式

5.1 同步 Tool（< 5s）

Feign/gRPC 同步调用，适合查询类。

5.2 异步 Tool（> 5s）

LLM 调用 submit_report → 返回 task_id
→ MQ 消费生成报告 → Webhook/SSE 推送结果
→ 用户后续问「报告好了吗」→ 查 task 状态

Temporal / Cadence 管理长流程：

@WorkflowInterface
public interface ReportWorkflow {
    @WorkflowMethod
    String generateReport(String userId, ReportParams params);
}

---

六、会话状态管理

数据	存储	TTL
短期对话	Redis List	24h
用户画像摘要	PostgreSQL	永久
Tool 调用审计	ES / ClickHouse	180d
向量记忆	Milvus	按租户

多轮上下文：保留最近 N 轮 + 摘要压缩，避免 Token 爆炸。

---

七、Human-in-the-Loop

高风险 Tool（退款、删数据、发邮件给全员）必须 审批：

Agent 生成计划 → workflow-service 创建审批单
→ 主管企业微信确认 → Agent 继续执行

审批超时 30min 自动取消，状态回写会话。

---

八、MCP 集成

外部 MCP Server（GitHub、数据库浏览器）通过 独立 Adapter Pod 运行，网络策略隔离：

• MCP 仅 Agent 子网可访问
• 每个 MCP 独立 ServiceAccount
• 调用日志进 SIEM

---

九、可观测与成本

每个 Agent 会话一个 traceId，Span 记录：

• tool_name, latency, success
• prompt_tokens, completion_tokens
• model_version

按部门出 Token 账单，Agent 循环调用（>10 次 Tool）触发告警。

---

十、落地路线图

阶段	目标	周期
POC	3 个只读 Tool + 单服务	2 周
Pilot	审批流 + 审计 + 10 Tool	1 月
生产	多租户 + SLA + 降级	2–3 月

---

小结

Agent 与微服务融合的核心是：编排薄、Tool 厚、状态外置、高风险人工批。国内 2026 年成功项目普遍复用了 70% 以上现有微服务能力，而非重写业务逻辑。