子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学"明白"，也用"到位"
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- 引言
- [一、问题本质：AI 系统不再"自建"，而是"组装"](#一、问题本质：AI 系统不再“自建”，而是“组装”)
- 二、为什么开源成为默认选择
- [三、AI 构建的四层开源栈](#三、AI 构建的四层开源栈)
- 四、第一层：模型层
- [五、第二层：Agent Framework](#五、第二层：Agent Framework)
- 六、第三层：治理层
- 七、第四层：基础设施
- [八、关键挑战一：开源 ≠ 可控](#八、关键挑战一：开源 ≠ 可控)
- 九、关键挑战二：组件组合复杂度爆炸
- 十、关键挑战三：治理滞后
- [十一、关键设计：开源 + 自研的边界](#十一、关键设计：开源 + 自研的边界)
- 十二、最佳实践：开源驱动的系统架构
- 十三、为什么这是"新范式"
- 总结
引言
如果你这两年在做 AI 系统，大概率已经发现一个变化：
模型能力在增强
框架在演进
工具链在爆炸但真正改变游戏规则的，不是某一个模型，而是：
开源，正在成为 AI 系统的"默认底座"。
过去我们做系统：
自研为主
闭源为主
能力内建而现在：
模型开源
框架开源
Agent 系统开源
治理工具开源于是，一个新的范式出现了：
AI 系统 = 开源组件的组合体 + 自定义治理能力
一、问题本质：AI 系统不再"自建"，而是"组装"
传统系统的构建方式：
需求 → 设计 → 开发 → 上线AI 系统的构建方式正在变成：
选模型 → 选框架 → 选工具 → 组合 → 调整核心变化
从"写代码"
→ "选组件"示例
模型层：开源 LLM
Agent 层：开源框架
工具层：开源工具链
治理层：自定义 + 开源结合本质
AI 系统正在"模块化"，而开源是模块的来源。
二、为什么开源成为默认选择
不是情怀，而是现实驱动。
1、速度优势
不用从 0 开始
直接复用成熟能力2、成本优势
避免高昂 API 成本
可控部署3、可控性
可修改源码
可定制行为
可嵌入治理逻辑4、生态优势
社区驱动
快速迭代
插件丰富核心结论
不开源，你几乎无法高效构建 AI 系统。
三、AI 构建的四层开源栈
一个典型的 AI 系统，可以拆成四层：
┌────────────────────┐
│ Governance Layer │（治理）
├────────────────────┤
│ Agent Framework │（智能体）
├────────────────────┤
│ Model Layer │（模型）
├────────────────────┤
│ Infra / Tools │（基础设施）
└────────────────────┘四、第一层：模型层
这是最直观的一层。
开源带来的变化
不再依赖单一厂商
可以本地部署
支持定制训练使用方式
小模型：端侧推理
中模型：本地服务
大模型：云端补充本质
模型能力从"封闭服务"，变成"可组合资源"。
五、第二层：Agent Framework
这是变化最快的一层。
提供能力
任务编排
工具调用
多 Agent 协作
记忆管理问题
灵活，但不可控
强大，但容易失控解决方式
必须叠加治理能力本质
开源框架负责"能力"，但不负责"边界"。
六、第三层：治理层
这是最容易被忽视，但最关键的一层。
为什么必须存在？
开源组件不可控
模型输出不可预测
Agent 行为复杂必须引入
Policy Engine
Guardrails
监控系统
审计日志架构
模型 → Agent → Policy → Guardrails → 执行本质
开源提供"能力"，治理提供"安全"。
七、第四层：基础设施
很多人忽略这一层，但它决定系统是否"能跑"。
包括
推理引擎
缓存系统
日志系统
调度系统
数据存储特点
高度开源化
高度标准化本质
AI 系统，本质还是"工程系统"。
八、关键挑战一：开源 ≠ 可控
很多团队的误区：
用了开源 = 系统安全实际问题
行为不可预测
依赖链复杂
升级风险高示例
一个开源 Agent 更新 → 行为变化 → 系统异常本质
开源解决"能力"，不解决"稳定性"。
九、关键挑战二：组件组合复杂度爆炸
当系统变成"拼装"：
组件 A + 组件 B + 组件 C问题会变成：
A 和 B 不兼容
B 和 C 行为冲突
整体不可调试本质
复杂度从"代码"，转移到"组合"。
十、关键挑战三：治理滞后
很多团队的路径是：
先做功能
再补治理结果
系统已上线
行为不可控
治理成本极高正确顺序
能力设计 + 治理设计 同步进行本质
治理不是补丁，而是基础设施。
十一、关键设计：开源 + 自研的边界
不是所有东西都该开源。
适合开源的
模型
框架
工具
基础组件必须自研的
Policy Engine
治理策略
核心业务逻辑
安全机制本质
能力可以外包，控制必须自握。
十二、最佳实践：开源驱动的系统架构
一个成熟架构应该是：
开源组件（能力）
↓
Adapter（适配层）
↓
Policy Engine（控制）
↓
Guardrails（保护）
↓
Execution（执行）关键点
所有开源组件，都必须经过"控制层"本质
开源在下，治理在上。
十三、为什么这是"新范式"
过去的软件范式是：
代码为中心现在的 AI 范式是：
模型为能力中心
开源为组件来源
治理为系统核心核心变化
从"开发系统"
→ "构建系统"
→ "治理系统"总结
开源驱动的 AI 构建，本质是一次系统范式的转变：
开源 → 提供能力
组合 → 构建系统
治理 → 保证可控我们可以用一句话总结：
未来的 AI 系统，不是谁写得多，而是谁"组合得好、控制得住"。