# InfoQ 2025架构趋势报告：从LLM泛滥到社会技术架构的范式转变

Posted on 2025-11-24 11:31  吾以观复  阅读(0)  评论(0)    收藏  举报

关联知识库：# InfoQ 2025架构趋势报告：从LLM泛滥到社会技术架构的范式转变

InfoQ 2025架构趋势报告：从LLM泛滥到社会技术架构的范式转变

来源：InfoQ Software Architecture and Design Trends Report - 2025
发布时间：2025年4月28日
作者：Thomas Betts, Sarah Wells, Eran Stiller, Daniel Bryant
观察日期：2025年10月15日

核心摘要

InfoQ编辑团队基于Geoffrey A. Moore的"跨越鸿沟"（Crossing the Chasm）模型，对2025年的软件架构趋势进行了分类。这份报告的最大价值在于：它不是告诉你用什么技术，而是告诉你什么技术已经成熟到可以考虑采用，什么技术还需要观望。

关键洞察

  1. LLMs已经"跨越鸿沟"到Late Majority：这是一个信号——当技术普及到这个程度时，开始出现滥用和不适当应用
  2. RAG从Early Adopter跃升至Early Majority：检索增强生成已经成为"标准配置"
  3. Agentic AI是下一个焦点：从LLM到Agent的范式转变正在发生
  4. 架构师角色正在转型：从"决策者"到"促进者"，这是社会技术架构思维的体现

趋势分层解读（按Crossing the Chasm模型）

Late Majority（后期大众）- 已成主流

LLMs（大语言模型）

InfoQ的判断：

"LLMs跳过了Early Majority，直接从Early Adopter跃升到Late Majority"

批判性分析：

✅ 合理之处：

  • ChatGPT、Claude等工具确实已经渗透到各行各业
  • "AI-powered"已经成为产品宣传的标配话术
  • 普通用户不再需要技术背景就能使用

⚠️ 值得警惕的信号：
报告指出了一个重要现象：

"当技术跨越鸿沟时，开始被用于不适当的场景"

这说明什么？

  1. 锤子综合征：有了LLM这把锤子，什么问题都想用它来解决
  2. 技术债务累积：很多团队在没有充分理解LLM局限性的情况下就大规模采用
  3. 过度承诺：市场营销驱动的技术决策导致期望与现实脱节

现实案例佐证：

  • 某些公司将LLM用于需要100%准确性的场景（如法律文书生成）
  • 忽视了成本：GPT-4调用成本可能比传统方案高10-100倍
  • 隐私问题：将敏感数据发送给第三方LLM服务

Early Majority（早期大众）- 可以考虑采用

RAG（检索增强生成）

InfoQ的判断：

"RAG正在被采用作为改善LLM结果的常用技术。架构师正在设计系统，使其能够更容易地容纳RAG。"

深度分析：

为什么RAG能快速跨越鸿沟？

  1. 解决了LLM的核心痛点：

    • 幻觉问题（Hallucination）
    • 知识时效性（Knowledge Cutoff）
    • 领域专业性不足

  2. 技术栈相对成熟：

    • 向量数据库（Pinecone, Weaviate, Qdrant）已商业化
    • 嵌入模型（Embedding Models）标准化
    • LlamaIndex、LangChain等框架降低了实现门槛

架构设计的启示：

报告提到"架构师在设计系统时需要考虑如何更容易地容纳RAG"，这意味着什么？

传统架构：
用户请求 → LLM → 返回结果

RAG架构：
用户请求 → [查询改写] → 向量检索 → [上下文注入] → LLM → 返回结果
          ↓
      需要考虑：
      - 向量数据库的选择和扩展性
      - 嵌入模型的更新策略
      - 上下文窗口的管理
      - 检索质量的监控

⚠️ 被忽视的复杂性：

InfoQ报告相对乐观，但实际部署RAG时会遇到：

  1. 检索质量问题：

    • 语义检索不一定比关键词检索好
    • Chunk策略（如何分割文档）极大影响结果
    • 需要Hybrid Search（混合检索）才能达到理想效果

  2. 成本和延迟：

    • 向量检索 + LLM调用 = 双重成本
    • 延迟增加50%-200%

  3. 运维复杂度：

    • 向量数据库需要单独维护
    • 嵌入模型版本管理
    • 数据同步问题

** 相关资源**：参见本知识库《RAG开创性论文解读》和《RAG讣告批判性阅读报告》

小语言模型（SLMs）

InfoQ的判断：

"随着LLMs被广泛采用，AI相关创新现在聚焦于精细调优的小语言模型"

趋势洞察：

这个趋势非常重要，因为它代表了从"大力出奇迹"到"精准打击"的范式转变。

为什么SLMs开始受关注？

维度 LLMs SLMs
参数规模 70B-400B+ 1B-13B
推理成本 $0.002-0.06/1K tokens | $0.0001-0.001/1K tokens
延迟 1-5秒 100-500ms
部署 需要GPU集群 单卡GPU甚至CPU
适用场景 通用任务 垂直领域

现实案例：

  • Anthropic的Claude Haiku：3秒生成→0.3秒生成（10倍提升）
  • Llama 3.1 8B：在代码生成任务上接近GPT-3.5的表现，但成本降低95%
  • Microsoft的Phi系列：3B参数的Phi-3在某些任务上超过了7B的模型

批判性思考：

⚠️ 潜在陷阱：

  1. 过度追求小型化：为了降低成本而牺牲了任务完成度
  2. Fine-tuning的幻觉：以为微调就能让小模型媲美大模型
  3. 评估偏差：在Benchmark上表现好≠实际业务场景表现好

Early Adopter（早期采用者）- 值得关注但需谨慎

Agentic AI（AI代理系统）

InfoQ的观点：

"Agentic AI作为Early Adopter趋势出现"

** 批判性分析**：

什么是Agentic AI？

从LLM到Agent的核心区别：

  • LLM：单次交互，无状态，被动响应
  • Agent：多轮交互，有状态，主动规划
传统LLM工作流：
输入Prompt → LLM处理 → 输出结果（结束）

Agent工作流：
目标设定 → Agent规划 → 调用工具 → 观察结果 → 重新规划 → ...（循环）

为什么说它还在Early Adopter阶段？

  1. 可靠性问题：

    • Agent容易进入死循环（无限调用工具）
    • 规划能力不稳定（同样的任务可能生成完全不同的执行计划）
    • 错误传播（一个工具调用失败导致整个流程崩溃）

  2. 成本爆炸：

    • 单个任务可能触发10-50次LLM调用
    • 成本可能是传统LLM方案的10-50倍

  3. 缺乏标准化：

    • Anthropic的Computer Use、OpenAI的Function Calling、LangChain的Agents各不相同
    • 没有统一的评估标准

** 相关资源**：

  • 参见本知识库《Building agents with the Claude Agent SDK》
  • 《Effective context engineering for AI agents》

** 适用场景**：

目前Agentic AI真正适合的场景：

  1. 数据分析助手：需要多步骤查询和计算
  2. 代码审查助手：需要读取多个文件、运行测试
  3. 客服系统：需要查询知识库、调用业务API

❌ 不适合的场景：

  1. 需要高可靠性的生产环境（如金融交易）
  2. 对延迟敏感的场景（如实时客服）
  3. 成本敏感的大规模应用

AI辅助开发工具

InfoQ的警告：

"架构师需要考虑AI辅助开发工具，确保它们提高效率而不是降低质量"

** 这是一个非常重要但容易被忽视的问题**

现状观察：

  1. GitHub Copilot、Cursor、Windsurf等工具已经普及
  2. "10倍生产力"的神话正在被营销
  3. 技术债务的隐蔽累积

架构师需要关注的问题：

风险类型 具体表现 应对策略
代码质量下降 AI生成的代码缺乏整体设计思考 强化Code Review流程
技术债务累积 为了快速交付接受了不理想的实现 定期重构Sprint
安全漏洞 AI可能生成有安全隐患的代码 集成SAST工具
依赖混乱 AI随意引入新的第三方库 依赖管理策略
知识流失 团队过度依赖AI，失去独立思考能力 技术分享机制

报告提到的"Prompt工程"：

"架构师正在寻找方法提供好的Prompt，以确保代码和架构指南得到遵守"

实践建议：

## 团队Prompt模板示例

### 代码生成Prompt前缀
你是一个遵循{团队名称}编码规范的开发助手：
- 使用TypeScript严格模式
- 遵循函数式编程范式
- 每个函数不超过20行
- 必须包含JSDoc注释
- 错误处理使用Result类型（不使用try-catch）

### 架构决策Prompt前缀
在提出架构方案前，必须考虑：
1. 与现有系统的兼容性
2. 团队的技术栈熟悉程度
3. 长期维护成本
4. 可测试性

** 相关资源**：参见本知识库《逆向工程Cursor的LLM客户端》中关于Prompt注入的分析

社会技术架构（Socio-technical Architecture）

InfoQ的观点：

"复杂软件系统需要围绕将要构建、支持和演进软件的人来设计"

** 这是报告中最具前瞻性的观点**

核心思想：

传统架构决策链：

业务需求 → 技术方案 → 系统架构 → 人去适应系统

社会技术架构：

业务需求 → 团队能力评估 → 系统架构 → 人与系统共同演进
            ↓
      考虑：团队规模、技能、沟通成本、认知负载

康威定律的深层应用：

"组织的系统架构反映了组织的沟通结构"

报告指出的创新实践：

  1. 架构师角色转变：

    • ❌ 传统：架构师是唯一的决策者
    • ✅ 新模式：架构师是决策的促进者（Facilitator）

  2. 去中心化决策：

    • 让更接近问题的人做决策
    • 架构师提供指导和护栏（Guardrails）
    • 团队有更高的自主权

  3. 平台思维：

    • 平台即产品（Platform as a Product）
    • 减少开发者的认知负载
    • 自服务能力

案例：Spotify的Squad模型

传统模式：
前端团队 + 后端团队 + DBA团队 → 需求在团队间流转

Squad模式：
[前端 + 后端 + DBA + 运维] → 端到端负责一个功能

批判性思考：

⚠️ 挑战：

  1. 需要高度信任的文化：不是所有组织都能做到
  2. 标准化与自主性的平衡：过度自主导致系统碎片化
  3. 架构师的转型阵痛：从技术专家到组织设计者

** 适用场景**：

  • 中大型团队（50+工程师）
  • 产品复杂度高，需要快速迭代
  • 组织文化开放，愿意授权

Innovators（创新者）- 观望但值得关注

绿色软件（Green Software）

InfoQ的洞察：

"降低云成本是能源消耗的合理代理指标，但这还不够——架构师需要考虑何时何地运行软件以利用可再生能源"

** 被严重低估的趋势**

为什么绿色软件很重要？

数据中心的碳排放事实：

  • 全球数据中心占全球电力消耗的1-2%
  • AI训练一个大模型的碳排放 ≈ 5辆汽车的终身排放
  • 2025年AI相关电力消耗预计增长30-50%

三个层次的绿色软件实践：

Level 1：成本优化（大多数公司的现状）

目标：降低云账单
方法：Right-sizing、Spot Instance、Auto-scaling
效果：成本降低20-40%，碳排放间接降低

Level 2：能效优化（少数公司在做）

目标：降低能耗
方法：
- 算法优化（减少计算复杂度）
- 选择高能效语言（Rust vs Python）
- 使用ARM架构（能效比x86高30-50%）
效果：能耗降低30-60%

Level 3：碳感知计算（创新者在探索）

目标：最小化碳足迹
方法：
- 时间迁移：在电网可再生能源占比高的时段运行任务
- 空间迁移：将任务调度到可再生能源丰富的数据中心
- 需求塑造：用户行为引导（如鼓励离峰下载）
效果：碳足迹降低40-70%

实际案例：

Google的Carbon-Aware Load Shifting

场景：YouTube视频转码任务
策略：
- 监控各数据中心的实时碳强度（gCO2/kWh）
- 将任务路由到当前碳强度最低的数据中心
- 非紧急任务延迟到太阳能充足的时段

结果：碳排放降低5-10%，成本基本不变

批判性思考：

⚠️ 为什么采用率低？

  1. 缺乏直接激励：

    • 云厂商按用量计费，不考虑碳排放
    • 企业优先考虑成本和性能，环保是"Nice to have"

  2. 复杂度高：

    • 需要实时监控碳强度数据
    • 任务调度算法复杂
    • 跨区域数据传输可能增加延迟

  3. ROI不明确：

    • 碳信用（Carbon Credit）市场不成熟
    • 难以量化商业价值

** 实践建议**：

如果你想尝试绿色软件：

Step 1：测量

  • 使用Cloud Carbon Footprint等工具
  • 了解你的应用的碳排放基线

Step 2：低悬果实

  • 优化数据库查询（减少计算）
  • 实施缓存策略（减少重复计算）
  • 清理僵尸资源（Zombie Resources）

Step 3：架构调整

  • 异步处理非紧急任务
  • 考虑Edge Computing（减少数据传输）
  • 选择可再生能源比例高的云区域

隐私工程（Privacy Engineering）

InfoQ的观点：

"隐私工程是将隐私作为首要特性，而不是对法规或事件的被动反应"

** 在AI时代更加关键**

为什么AI使隐私工程变得紧迫？

  1. LLM的数据吸尘器效应：

    • 用户输入的Prompt可能包含敏感信息
    • 第三方LLM服务可能用这些数据训练模型
    • 数据一旦发出，无法撤回

  2. RAG的知识库风险：

    • 向量数据库中可能包含敏感文档
    • 检索过程可能泄露信息
    • 难以实现"删除权"（Right to be Forgotten）

  3. Agent的权限泛滥：

    • Agent可能访问多个系统
    • 权限管理复杂
    • 审计困难

隐私工程的核心原则：

Privacy by Design（隐私优先设计）

❌ 传统方法：
开发产品 → 发现隐私问题 → 打补丁 → GDPR罚款

✅ 隐私工程：
需求阶段 → 隐私影响评估 → 架构设计 → 实施 → 持续审计

实践框架：

原则 AI场景下的应用
数据最小化 只发送必要的上下文给LLM，脱敏敏感字段
透明度 明确告知用户数据如何被AI处理
用户控制 允许用户选择退出AI功能
安全存储 向量数据库加密，访问控制
可审计性 记录所有AI交互，支持溯源

技术实现：

1. Prompt脱敏

# 示例：在发送给LLM前脱敏
def sanitize_prompt(prompt: str) -> str:
    # 替换邮箱
    prompt = re.sub(r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b', '[EMAIL]', prompt)
    # 替换信用卡号
    prompt = re.sub(r'\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b', '[CARD]', prompt)
    # 替换电话号码
    prompt = re.sub(r'\b\d{3}[-.]?\d{3}[-.]?\d{4}\b', '[PHONE]', prompt)
    return prompt

2. 本地部署vs云服务的权衡

云服务（如OpenAI API）：
✅ 性能好，成本低
❌ 数据离开组织边界

本地部署（如Llama 3.1）：
✅ 数据完全可控
❌ 需要GPU基础设施，运维成本高

混合方案：
- 敏感数据用本地小模型
- 非敏感数据用云服务

批判性思考：

⚠️ 隐私工程的困境：

  1. 用户体验vs隐私的权衡：

    • 更好的AI体验往往需要更多数据
    • 用户口头上重视隐私，行为上却选择便利

  2. 法规滞后：

    • GDPR是2018年的法规，未考虑AI场景
    • 各国法规不一致，合规成本高

  3. 技术限制：

    • 完全匿名化会降低AI效果
    • 差分隐私（Differential Privacy）实施复杂

** 实践建议**：

优先级排序：

  1. 必做：分类数据（公开/内部/敏感/机密）
  2. 必做：禁止将机密数据发送给第三方LLM
  3. 应做：实施Prompt审计
  4. 考虑：评估本地部署小模型的可行性

批判性思考：报告没说的事

1️⃣ 过度乐观的AI趋势

观察：报告大量篇幅讨论AI，但很少提及AI项目的失败率。

现实：

  • Gartner 2024报告：85%的AI项目未能交付预期价值
  • 主要原因：数据质量问题（67%）、缺乏明确ROI（55%）

启示：在追逐AI趋势前，问问自己：

  • 我们有足够的高质量数据吗？
  • 这个问题真的需要AI解决吗？
  • 传统方法是否已经足够好？

2️⃣ 忽视了"技术保守主义"的价值

报告偏向于"创新"，但成熟稳定的技术往往被忽视

反思：

  • PostgreSQL、Redis、Nginx这些"无聊技术"支撑了大多数互联网应用
  • 过度追求新技术可能导致技术债务和团队疲劳

Boring Technology原则：

"在3个技术决策中，最多只有1个选择创新技术，其他必须选择成熟方案"

3️⃣ "社会技术架构"的组织前提

报告提倡去中心化决策，但没有说清楚前提条件

现实挑战：

  • 需要高度信任的文化（不是一朝一夕能建立的）
  • 需要工程师具备架构思维（需要培养）
  • 需要强有力的技术标准（需要权威制定）

适用场景有限：

  • 初创公司：团队小，不需要去中心化
  • 大型传统企业：组织惯性大，难以转型
  • 最适合：50-500人的成长型科技公司

4️⃣ 绿色软件的"漂绿"风险

观察：很多公司宣称"碳中和"，但实际只是购买碳信用，没有真正减少排放。

警惕：

  • 云厂商宣传的"绿色数据中心"可能只是营销话术
  • 真正的绿色软件需要从架构层面重新思考

5️⃣ 缺乏对成本的充分讨论

AI趋势听起来很美好，但成本呢？

现实数据：

  • RAG系统运营成本可能是传统搜索的5-10倍
  • Agentic AI的成本可能爆炸式增长
  • 很多公司在AI热潮中烧钱，却没有清晰的盈利路径

理性视角：

"技术选型不仅要看能力，更要看ROI"

可操作的启发

对于架构师：

  1. LLMs已成主流，关注点应该转向"如何用好"而不是"是否使用"

    • 建立AI使用规范
    • 关注成本和质量平衡
    • 防范滥用

  2. RAG是当下应该掌握的技术

    • 理解向量检索原理
    • 评估不同向量数据库
    • 设计可容纳RAG的系统架构

  3. 对Agentic AI保持关注但不急于采用

    • 先在内部工具场景试验
    • 等待标准化和最佳实践
    • 警惕成本和可靠性问题

  4. 社会技术架构是长期趋势

    • 开始思考如何减少架构决策的瓶颈
    • 培养团队的架构思维
    • 建立决策框架和护栏

对于CTO/技术负责人：

  1. 制定AI治理策略

    • 哪些数据可以发送给第三方LLM？
    • 如何评估AI工具的ROI？
    • 如何平衡创新和风险？

  2. 投资团队能力建设

    • 组织RAG技术培训
    • 建立AI最佳实践知识库
    • 鼓励实验但要有失败容忍度

  3. 关注长期价值而非短期炒作

    • 绿色软件可能在3-5年后成为竞争优势
    • 隐私工程可能避免未来的巨额罚款
    • 社会技术架构可能提升组织效能

对于开发者：

  1. 提升AI素养

    • 理解LLM的工作原理和局限性
    • 学会写好的Prompt
    • 不盲信AI生成的代码

  2. 关注基础能力

    • 向量检索、嵌入模型等成为新的基础技能
    • 数据工程能力比以往更重要

  3. 保持批判性思维

    • 不是所有问题都需要AI解决
    • 成熟技术往往比新技术更可靠

延伸阅读（本知识库相关内容）

AI技术深度：

  • 《RAG开创性论文解读：检索增强生成的技术革命》
  • 《RAG讣告批判性阅读报告：Agent Search是革命还是过度乐观？》
  • 《Building agents with the Claude Agent SDK》
  • 《Effective context engineering for AI agents》

工程思维：

  • 《MVP架构选型指南：停止过度设计，从简单开始》
  • 《微服务重构失败案例与分布式系统设计思考》

Prompt工程：

  • 《逆向工程Cursor的LLM客户端：商业机密泄露与技术解构的双重启示》
  • 《综合批判性分析Prompt》

元信息

文档类型：技术趋势观察
可信度：⭐⭐⭐⭐（权威来源，但需结合实际批判性阅读）
时效性：2025年4月发布，有效期约12-18个月
适用对象：架构师、技术负责人、技术决策者

观察者评论：

InfoQ的趋势报告价值在于它提供了一个技术成熟度的参考框架，帮助我们判断"什么时候采用什么技术"。但需要警惕的是，报告倾向于乐观，对风险和失败案例的讨论不足。作为读者，我们需要结合自身情况，保持批判性思维。记住：没有银弹，技术选型永远是权衡（Trade-offs）。

最后更新：2025年10月15日
版本：v1.0