引言：AI正在改变软件开发，但架构边界依然重要

过去的软件开发主要围绕确定性的业务逻辑展开：输入是什么，流程是什么，输出应该是什么，开发人员可以通过代码精确控制系统行为。

而随着大语言模型（LLM）、智能代理（Agent）、生成式AI等技术进入软件开发领域，软件系统正在发生变化。越来越多的软件开始具备推理、生成、规划和自主执行能力。开发者不再只是编写规则，而是在设计一个由模型、工具、数据和业务逻辑共同组成的复杂系统。

然而，AI能力越强，软件架构越需要清晰的边界。

如果没有合理的架构边界，AI系统很容易出现以下问题：

• AI模型承担过多业务职责，导致系统不可控；

• 业务规则隐藏在Prompt中，难以维护；

• 数据、模型和应用代码高度耦合；

• Agent权限过大，引发安全和稳定性风险；

• 系统随着需求增长快速失去演进能力。

因此，在AI时代，软件架构设计的核心问题之一，就是回答：

哪些事情应该交给AI？哪些事情必须由传统软件负责？AI能力应该如何被约束？

一、理解AI软件中的架构边界

传统软件架构中的边界，通常是模块之间的职责划分，例如：

• 前端负责交互；

• 服务层负责业务流程；

• 数据层负责存储；

• 基础设施负责运行环境。

AI软件增加了新的参与者：

• 大模型（LLM）；

• Prompt；

• Agent；

• 知识库（RAG）；

• 工具调用（Tool Calling）；

• AI工作流。

因此，架构边界需要重新定义。

一个成熟的AI系统通常应该包含以下几个边界：

用户交互层
    |
业务应用层
    |
AI能力编排层
    |
模型服务层
    |
数据与知识层
    |
基础设施层

每一层都应该有明确职责，而不是让AI成为一个“万能黑盒”。

二、明确AI与传统代码的职责边界

1. 不要让AI替代确定性逻辑

AI擅长：

• 理解自然语言；

• 总结信息；

• 生成内容；

• 推理分析；

• 处理非结构化数据。

但AI不适合承担：

• 金额计算；

• 权限判断；

• 交易流程；

• 状态管理；

• 核心业务规则。

例如，一个支付系统：

错误设计：

用户请求支付
        |
      AI判断
        |
AI决定是否扣款

这种设计的问题是：

• 模型输出不可完全预测；

• 无法保证业务一致性；

• 审计困难。

更合理的方式：

用户请求
    |
AI理解用户意图
    |
业务服务验证规则
    |
支付系统执行交易

AI负责理解，而代码负责执行。

三、建立AI能力隔离层

很多团队在开发AI应用时，会直接在业务代码中调用模型：

例如：

result = openai.chat(prompt)

短期开发速度很快，但长期会产生架构问题：

• 模型供应商无法替换；

• Prompt散落在代码中；

• 无法统一管理上下文；

• 难以监控AI行为。

更好的方式是增加AI能力层：

业务服务

    |
    ↓

AI Gateway

    |
    ↓

LLM Provider

AI Gateway负责：

• 模型选择；

• Prompt管理；

• Token控制；

• 请求监控；

• 安全过滤；

• 结果校验。

这样业务系统不依赖某一个具体模型。

未来可以：

• GPT切换到其他模型；

• 使用本地部署模型；

• 根据任务自动选择模型。

架构不会因为模型变化而重构。

四、Prompt也需要架构设计

在AI应用中，Prompt实际上成为了一种新的软件资产。

很多团队初期会把Prompt写在代码字符串中：

prompt = """
你是一名客服助手...
"""

随着业务复杂度增加，会出现：

• Prompt版本无法管理；

• 修改影响线上行为；

• 无法回滚；

• 不知道哪个Prompt效果最好。

因此Prompt应该像代码一样管理。

建议：

Prompt独立化

例如：

/prompts

 customer_service_v1.yaml

 customer_service_v2.yaml

 sales_analysis_v1.yaml

Prompt版本控制

例如：

客服助手Prompt:

v1.0 初始版本

v1.1 增加投诉处理规则

v1.2 优化回答格式

Prompt测试

建立类似软件测试的机制：

• 输入样例；

• 期望输出；

• 质量评分。

Prompt工程正在逐渐成为软件工程的一部分。

五、限制Agent的边界

Agent是AI软件发展的重要方向。

一个Agent通常包含：

• 目标；

• 推理能力；

• 工具调用；

• 状态记忆。

但Agent最大的问题是：

自主能力越强，风险越高。

因此必须设计边界。

1. 工具权限边界

不要让Agent直接拥有：

• 数据库写权限；

• 生产服务器权限；

• 财务操作权限。

应该通过受控接口：

Agent

  |

工具接口

  |

业务服务

  |

权限系统

例如：

AI客服可以：

• 查询订单；

但不能：

• 修改订单金额。

2. 行为边界

Agent应该有：

• 最大执行步骤；

• 最大调用次数；

• 超时限制；

• 人工确认节点。

例如：

AI生成方案

↓

人工审核

↓

系统执行

而不是：

AI决定

↓

自动执行所有操作

六、数据边界：AI不能直接接触所有数据

AI系统最大的风险之一是数据访问。

很多企业希望：

“让AI知道公司的所有资料。”

但真正的问题是：

AI应该知道什么？

谁可以访问什么？

什么时候可以访问？

正确方式是建立数据边界：

业务数据

   |

权限控制层

   |

知识检索系统(RAG)

   |

AI模型

AI不是直接读取数据库，而是通过：

• 权限过滤；

• 数据脱敏；

• 检索控制；

获得必要的信息。

遵循一个原则：

AI只应该看到完成任务所需要的数据。

七、建立可观测性的架构边界

传统软件关注：

• 日志；

• 性能；

• 错误率。

AI系统还需要关注：

• Prompt版本；

• 模型版本；

• 输入上下文；

• Token消耗；

• 输出质量；

• 用户反馈。

例如：

一次AI回答：

用户问题

↓

Prompt版本:v2.3

↓

模型:gpt-x

↓

Token:3500

↓

结果评分:4.5/5

这些信息应该被记录。

否则当AI出现错误时，团队无法定位原因。

八、AI架构设计的几个原则

原则一：AI负责不确定性，代码负责确定性

适合AI：

• 理解；

• 推理；

• 创造。

适合代码：

• 规则；

• 流程；

• 权限；

• 数据一致性。

原则二：模型是能力组件，不是业务核心

不要设计：

业务 = AI模型

应该设计：

业务系统 + AI能力

模型未来一定会变化，业务价值不能绑定某个模型。

原则三：所有AI行为必须可控制

AI输出应该经过：

• 校验；

• 限制；

• 审计。

不要相信：

“模型足够聪明，所以可以放开权限。”

原则四：架构应该允许AI能力升级

今天：

人工流程

明天：

AI辅助流程

未来：

AI自动流程

好的架构应该支持渐进演进，而不是一次推倒重来。

九、未来AI软件架构的发展趋势

未来的软件系统可能会形成新的架构模式：

用户

↓

智能交互层

↓

Agent编排层

↓

业务服务层

↓

数据与模型基础设施

其中：

• Agent负责任务规划；

• 业务服务保证可靠执行；

• 模型提供智能能力；

• 数据系统提供知识基础。

AI不会取代软件架构，而是推动软件架构更加重视边界。

结语：AI时代，边界比能力更重要

AI开发最大的挑战，不是如何让模型变得更聪明，而是如何让聪明的模型在正确的位置发挥作用。

优秀的AI软件架构，不是把所有事情交给AI，而是在：

• AI能力；

• 业务逻辑；

• 数据资源；

• 安全权限；

• 人工决策；

之间建立清晰边界。

真正成熟的AI系统，是一个“可智能化，也可控制”的系统。

在未来的软件开发中，架构能力的重要性不会降低，反而会因为AI的加入变得更加关键。