2026 年年中了，现在开发大型企业级智能体用什么架构方案

[unt]

其实总体架构没啥的，现在各种设计理念已经很成熟了。随便问下 AI 基本上整体架构思路给得清清楚楚。
但是在某些基础功能的实现上，现在很纠结，比如 MCP 注册，上下文管理，中断等等，是用以下哪种方案呢：
1. 需求理清楚，全部靠 vibe coding 原生实现。
2. 基于 openai response api 提供的功能
3. openai agent sdk


现在时代背景下，agent 框架基本不会再用了，去年写的 langchain 版也废弃重写了。

[lmmlwen]

LLM Runtime + Workflow Engine + Tool Platform

[codingmiao]

这玩意越高水越深，所以我们简单的需求 langchain4j(因为我们有好多 java 的基建)，复杂的直接套壳 claude code 😄

[flyhelan]

3

[shinelamla]

好奇同问

[unt]

@codingmiao Claude 应该是纯手撸的吧，应该属于方案 1

[Liu6]

大公司不知道， 我还是用的 langGraph 设计流程 然后手动+各种。 个人觉得 langGraph 还是写起来舒服一点， 啥流程都知道，啥玩意都是自己管理

[Liu6]

@Liu6 #6 langGraph 多人协同开发也很方便。 流程设计出来，按节点分工，再让 AI 干就完事了。最后汇总

[unt]

@Liu6 依赖框架的话后期想抽身有点难，未来模型的能力和 API 一定是越来越强

[Liu6]

@unt #8 langGraph 只是管理模型，按照设计工作流在不同的条件不同的时机下进行调用模型+其他工具。
所以我觉得没有抽身困难这一说。
不管未来模型如何变化，也是要根据公司业务场景来考虑的， 模型虽好，也要考虑成本
我相信很多公司 AI 模型用的大部分应该是 flash 版本。尤其是在低耗时且复杂的场景下。
目前我这边 就是用的豆包 1.6flash 多个子 agent + 汇总 2.0lite 版本。

以上个人观点。

顺便贴 2 个业务的流程图，通过 langGraph 实现起来省了很多代码（忠爱粉）

```
START
↓
classify_input_node
↓
route_by_input_type
├── first_message → first_message_node
│ ↓
│ core_node
│ ↓
│ END
│
├── normal → reply_node
│ ↓
│ emotion_node
│ ↓
│ report_node
│ ↓
│ core_node
│ ↓
│ END
│
└── force_end → report_node
↓
core_node
↓
END

└── end → END
```
```
START
├── consultation_risk
├── consultation_knowledge
├── consultation_sop
└── consultation_tone
↓
等 risk / knowledge / sop / tone 全部完成
↓
├── consultation_reply # 流式生成最终回复文本，并直接发送 socket partial
├── consultation_card # 生成推荐情景卡片
└── consultation_tags # 生成 suggested_tags
↓
等 reply / card / tags 全部完成
↓
consultation_core # 最终汇总，返回输出
↓
consultation_summary # 后台更新历史摘要
↓
END
```

[Liu6]

啥时候一个模型能解决所有问题的时候，我觉得就不需要任何框架了。

[mmdsun]

我们从 langchain 换 spring ai 了，主要做服务端。
现在生态很好，RAG 、工具调用、mcp 、skills 、代码执行沙箱环境都支持。还有 springaicommunity 社区库：
https://springaicommunity.mintlify.app