当前 AI 应用开发已经从“单点调用大模型 API”进入“组合智能体、编排多个模型能力”的软件工程化阶段。与其说我们缺少一个更强的模型不如说我们缺少一套把 AI 能力组织成产品的架构方法。本文将围绕第 71 期《AI 软件工厂设计模式》直播中的核心内容梳理 AI 软件开发中的工程范式、智能体设计模式、多 Agent 编排方式并结合完整代码示例给出落地思路。1. 背景从“写提示词”到“经营软件工厂”1.1 为什么 AI 应用开发需要设计模式传统软件工程里设计模式解决的是“在特定场景下反复出现的结构性问题”。工厂模式解决对象创建、策略模式解决算法切换、观察者模式解决事件通知、状态机模式解决复杂状态流转。到了 AI 时代这些结构性问题不但没有消失反而升级了。一个 AI 应用不再是“调一次模型接口”而是包含多轮对话状态维护。意图识别与路由。多种工具调用Tool Calling。多个模型或智能体的协同。上下文窗口管理与记忆持久化。失败重试、兜底回复、安全过滤。如果没有设计模式这些逻辑会全部堆在几个 Python 文件里最后变成难以测试、难以扩展、难以维护的“屎山代码”。1.2 AI 软件工厂的比喻“软件工厂”这个词来自传统工业化软件开发把需求分析、设计、编码、测试、部署拆成标准化流水线。AI 软件工厂更进一步它把“大模型能力”当成可插拔的产线设备把“智能体”当成产线上的工人把“工具库”当成工人手边的工具箱。要经营好这样一座工厂核心挑战不是某台设备模型多强而是产线设计是否合理。这就是设计模式的价值。1.3 本文读者范围本文将围绕 AI 软件工厂中高频使用的设计模式展开包括Agent 创建与装配工厂模式。模型与工具切换策略模式。复杂流程状态管理状态机模式。主 Agent 与子 Agent 协作主从编排模式。将 Sub-Agent 封装为 Tool适配器模式。领域建模与边界划分DDD 思想在 AI 项目中的应用。适合希望从“会调 API”走向“系统工程化”的 AI 开发者也适合后端开发转型 AI 应用落地场景参考。2. 环境准备与工程结构2.1 运行环境本文示例侧重思路讲解语言使用 Python 3.10框架以常见的开源智能体框架为例。实际项目请根据你的技术栈调整。组件建议版本说明Python3.10目前多数 AI 框架对 3.10 的支持最稳定智能体框架按项目实际选择例如LangChain、LlamaIndex、CrewAI、AutoGen模型服务OpenAI 兼容接口也可以使用国内大模型服务保持 OpenAI 兼容即可日志组件loguru / logging生产环境建议统一结构化日志2.2 示例项目结构为了把设计模式讲清楚本文会用“AI 客服工单系统”作为贯穿案例。项目结构如下ai_agent_factory/ ├── config.py # 全局配置 ├── models.py # 数据模型 ├── agents/ # 智能体模块 │ ├── base.py # 智能体抽象基类 │ ├── factory.py # 智能体工厂 │ ├── agent.py # 基础智能体实现 │ └── supervisor.py # 主控智能体Supervisor ├── tools/ # 工具模块 │ ├── registry.py # 工具注册表 │ ├── sub_agent_tool.py # 将子智能体封装为 Tool │ └── business_tools.py # 业务工具查询订单、查库存等 ├── workflow/ │ ├── state_machine.py # 状态机 │ └── pipeline.py # 流水线编排 ├── main.py # 入口 └── requirements.txt在开始写代码之前先把几个核心概念统一一下。2.3 概念统一Agent智能体一个能感知环境、做出决策、调用工具的单元。简单说它不仅仅是“模型”还包含系统提示词、工具集、记忆、执行策略。Tool工具智能体可以调用的外部函数例如查询 API、执行 SQL、调用搜索接口。编排Orchestration决定多个智能体或步骤以什么顺序执行的逻辑。主从模式Supervisor Mode一个主控 Agent 负责任务拆解和结果汇总多个子 Agent 分别执行具体任务。Sub-Agent 即 Tool把子 Agent 封装成工具让主 Agent 像调用普通工具一样调用它这是当前多 Agent 设计中的一种实用思路。3. 核心设计模式拆解3.1 工厂模式动态创建智能体工厂模式解决的是“不能硬编码创建过程”的问题。AI 应用里不同场景需要不同 Agent客服机器人需要售后 Agent、订单 Agent、退货 Agent。内容平台需要文案 Agent、审核 Agent、数据分析 Agent。测试平台需要用例生成 Agent、执行 Agent、报告 Agent。如果每次都用if-else创建代码会变成def create_agent(agent_type: str): if agent_type after_sale: return AfterSaleAgent() elif agent_type order: return OrderAgent() elif agent_type return: return ReturnAgent() else: raise ValueError(Unknown agent type)这种方式有两个问题每新增一种 Agent 都要改这个函数创建逻辑和业务逻辑耦合在一起。使用工厂模式后我们通过注册表自动装配 Agent# agents/factory.py from typing import Dict, Type from agents.base import BaseAgent from agents.agent import OrderAgent, AfterSaleAgent, ReturnAgent class AgentFactory: def __init__(self): self._registry: Dict[str, Type[BaseAgent]] {} def register(self, agent_type: str, agent_class: Type[BaseAgent]): self._registry[agent_type] agent_class def create(self, agent_type: str, **kwargs) - BaseAgent: agent_class self._registry.get(agent_type) if not agent_class: raise ValueError(fAgent type {agent_type} not registered) return agent_class(**kwargs) # 全局工厂实例 agent_factory AgentFactory() def register_builtin_agents(): agent_factory.register(order, OrderAgent) agent_factory.register(after_sale, AfterSaleAgent) agent_factory.register(return, ReturnAgent)这样每增加一种业务 Agent只需要新增一个类并在注册函数中登记主流程代码完全不需要改动。3.2 策略模式模型与工具的动态切换策略模式解决的是“同一件事不同场景用不同算法”的问题。AI 开发中典型场景简单问题用轻量模型复杂问题用强模型。不同渠道微信、网页、App使用不同的回复策略。限流降级时切换到备用模型服务商。先定义策略接口# agents/base.py from abc import ABC, abstractmethod from typing import List, Optional class BaseAgent(ABC): abstractmethod def run(self, user_input: str, **kwargs) - str: 执行智能体逻辑返回回复结果 abstractmethod def get_tools(self) - List[str]: 返回需要绑定的工具列表然后在配置层把模型描述为一个可切换的策略# config.py from dataclasses import dataclass dataclass class ModelConfig: name: str base_url: str api_key_env: str temperature: float 0.2 max_tokens: int 2048 staticmethod def default() - ModelConfig: return ModelConfig( nameqwen-plus, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, api_key_envDASHSCOPE_API_KEY, ) staticmethod def fast() - ModelConfig: return ModelConfig( nameqwen-turbo, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, api_key_envDASHSCOPE_API_KEY, temperature0.1, )在智能体执行时可以根据输入判断使用哪种模型策略。策略模式的核心不是“配置写得多好”而是“运行时能够按条件切换行为”。这一点在后续 AI 项目中比传统后端项目更关键因为模型服务本身就不稳定。3.3 状态机模式管理多轮对话状态AI 应用很多问题出在状态管理上。用户说“我要退货”Agent 需要先确认订单号再确认商品再判断是否在退货期内最后提交退货申请。这个流程如果用自由对话实现很容易跑偏。更稳妥的做法是引入状态机# workflow/state_machine.py from enum import Enum from typing import Optional, Dict class OrderState(Enum): INIT init WAITING_ORDER_ID waiting_order_id WAITING_PRODUCT_CONFIRM waiting_product_confirm CHECKING_RETURN_POLICY checking_return_policy APPLYING_RETURN applying_return DONE done class ReturnStateMachine: def __init__(self): self.state OrderState.INIT self.context: Dict[str, Optional[str]] { order_id: None, product_name: None, is_within_policy: None, } # 事件 - 状态转移表 self._transitions { (OrderState.INIT, provide_order_id): OrderState.WAITING_ORDER_ID, (OrderState.WAITING_ORDER_ID, order_id_received): OrderState.WAITING_PRODUCT_CONFIRM, (OrderState.WAITING_PRODUCT_CONFIRM, product_confirmed): OrderState.CHECKING_RETURN_POLICY, (OrderState.CHECKING_RETURN_POLICY, policy_ok): OrderState.APPLYING_RETURN, (OrderState.CHECKING_RETURN_POLICY, policy_rejected): OrderState.DONE, (OrderState.APPLYING_RETURN, apply_success): OrderState.DONE, } def trigger(self, event: str): key (self.state, event) if key in self._transitions: self.state self._transitions[key] return True return False有了状态机Agent 的每一步行为就不再是“自由发挥”而是在显式状态约束下完成。这对生产环境的可控性非常重要。3.4 主从模式Supervisor 与 Sub-Agent这是直播中重点讨论的部分。当任务足够复杂时一个 Agent 处理所有事情往往出现上下文过载、指令冲突、结果质量下降。主从模式的核心思想是主 AgentSupervisor负责分析任务、拆分子任务、选择子 Agent、汇总结果。子 AgentSub-Agent只负责执行特定领域任务。伪代码示意# agents/supervisor.py from agents.base import BaseAgent from agents.factory import agent_factory class SupervisorAgent(BaseAgent): def __init__(self, model_config): self.model model_config self.sub_agent_names [order, after_sale, return] def run(self, user_input: str, **kwargs) - str: # 1. 用主模型判断意图 intent self._detect_intent(user_input) # 2. 根据意图选择子 Agent sub_agent agent_factory.create(intent, model_configself.model) # 3. 执行子 Agent result sub_agent.run(user_input) # 4. 如果需要做结果汇总 return result def _detect_intent(self, user_input: str) - str: # 这里是简化逻辑生产环境会用模型做意图识别 if 退货 in user_input or 退 in user_input: return return if 订单 in user_input or 查 in user_input: return order return after_sale主从模式的关键不是代码里有多少类而是“职责分离”主 Agent 不要陷入具体业务细节。子 Agent 不要承担调度逻辑。每个 Agent 的系统提示词只描述自己的专业领域。3.5 将 Sub-Agent 视为 Tool 的编排思路直播中有一个观点非常实用最新的多 Agent 设计里主从模式本质上会把 Sub-Agent 当作另类的 Tool 进行调用。这个思路解决了工程实现中的一个难题大多数框架对 Tool 的接入是标准化的而对 Agent 的接入各不相同。如果我们把子 Agent 封装成 Tool那么主 Agent 的调度逻辑就完全复用“工具调用”框架。代码示例如下# tools/sub_agent_tool.py from agents.base import BaseAgent class SubAgentTool: 把子 Agent 包装成一个标准 Tool def __init__(self, agent: BaseAgent, name: str, description: str): self.agent agent self.name name self.description description def __call__(self, input_text: str) - str: # 增加日志、限流、异常处理 try: result self.agent.run(input_text) return result except Exception as e: return fSub-Agent execution failed: {str(e)} def build_sub_agent_tools(agent_configs: dict) - list: tools [] for name, config in agent_configs.items(): agent config[class](**config.get(params, {})) tools.append( SubAgentTool( agentagent, namename, descriptionconfig[description], ) ) return tools这种封装带来的好处主 Agent 的代码只需要理解“工具有什么”不需要理解“Agent 是什么”。团队可以把多个 Agent 像微服务一样独立维护再统一注册到工具库。限流、监控、审计可以在工具层统一处理。4. 完整实战多 Agent 主从模式工单系统下面通过一个可运行的最小案例完整走一遍 AI 软件工厂的设计模式落地流程。4.1 需求说明构建一个客服工单系统包含一个主控 AgentSupervisor。三个子 Agent订单 Agent、售后 Agent、退货 Agent。子 Agent 以 Tool 形式注册给主 Agent。使用状态机约束退货流程。支持通过工厂模式动态扩展新 Agent。4.2 安装依赖本文示例使用openaiSDK 作为模型客户端实际模型服务只要支持 OpenAI 兼容接口即可。pip install openai pip install loguru4.3 配置模块新建config.py# config.py from dataclasses import dataclass dataclass class AppConfig: model_name: str gpt-4o-mini base_url: str https://your-model-endpoint/v1 api_key_env: str MODEL_API_KEY temperature: float 0.2 max_tokens: int 2048 app_config AppConfig()注意base_url请改成你自己项目使用的模型服务地址。不同服务商的地址格式可能存在差异。4.4 定义智能体基类# agents/base.py from abc import ABC, abstractmethod from typing import List class BaseAgent(ABC): abstractmethod def run(self, user_input: str, **kwargs) - str: 执行智能体逻辑 abstractmethod def get_tools(self) - List[str]: 返回工具列表 class SimpleTurnAgent(BaseAgent): def __init__(self, system_prompt: str): self.system_prompt system_prompt def run(self, user_input: str, **kwargs) - str: # 生产环境这里会调用大模型接口 return f[{self.system_prompt[:10]}...] 收到{user_input} def get_tools(self) - List[str]: return []上面的SimpleTurnAgent是示例中的最小实现。真实项目中run()内部应该调用大模型完成对话补全。4.5 创建子 Agent# agents/agent.py from agents.base import SimpleTurnAgent class OrderAgent(SimpleTurnAgent): def __init__(self): super().__init__( system_prompt你是订单助手负责查询订单状态、修改订单备注、确认收货地址。 ) class AfterSaleAgent(SimpleTurnAgent): def __init__(self): super().__init__( system_prompt你是售后服务助手负责处理用户咨询、投诉与建议并记录服务进度。 ) class ReturnAgent(SimpleTurnAgent): def __init__(self): super().__init__( system_prompt你是退货助手负责核实退货条件、生成退货申请、返回退货地址。 )4.6 构建工具注册# tools/business_tools.py def query_order_status(order_id: str) - str: 模拟查询订单状态 # 生产环境应调用订单服务的接口 return f订单 {order_id} 已发货预计明天送达。 def apply_return_refund(order_id: str) - str: 模拟提交退货申请 # 生产环境应调用售后系统接口并记录审核日志 return f订单 {order_id} 的退货申请已提交请留意退款通知。# tools/registry.py from typing import Dict, Callable class ToolRegistry: def __init__(self): self._tools: Dict[str, Callable] {} def register(self, name: str, fn: Callable): self._tools[name] fn def get(self, name: str): return self._tools.get(name) def all(self) - Dict[str, Callable]: return self._tools tool_registry ToolRegistry() def register_business_tools(): from tools.business_tools import query_order_status, apply_return_refund tool_registry.register(query_order_status, query_order_status) tool_registry.register(apply_return_refund, apply_return_refund)4.7 编写主控 Agent主控 Agent 负责意图识别与任务分发。为了演示这里先用规则匹配代替真实模型调用实际项目中可以将“意图识别”部分替换为模型接口。# agents/supervisor.py from typing import List from agents.base import BaseAgent from agents.factory import agent_factory from tools.registry import tool_registry class SupervisorAgent(BaseAgent): def __init__(self): self.intent_keywords { order: [订单, 查, 物流, 收货], after_sale: [售后, 投诉, 建议, 服务], return: [退货, 退款, 不想要了, 退回], } def detect_intent(self, user_input: str) - str: for intent, keywords in self.intent_keywords.items(): for kw in keywords: if kw in user_input: return intent return after_sale def run(self, user_input: str, **kwargs) - str: intent self.detect_intent(user_input) print(f[Supervisor] 命中意图{intent}) # 方式一通过工厂创建子 Agent sub_agent agent_factory.create(intent) result sub_agent.run(user_input) # 方式二如果需要工具直接调用工具注册表 if intent order and 订单号 in user_input: order_id user_input.split(订单号)[-1].strip() tool_result tool_registry.get(query_order_status)(order_id) result f\n[Tool 调用结果] {tool_result} return result def get_tools(self) - List[str]: return [query_order_status, apply_return_refund]4.8 编写入口文件# main.py from agents import register_builtin_agents from agents.supervisor import SupervisorAgent from tools.registry import register_business_tools def init_system(): register_builtin_agents() register_business_tools() def main(): init_system() supervisor SupervisorAgent() test_inputs [ 帮我查一下订单号 20240315001, 我想退货订单号 20240315002, 我要投诉物流太慢了, ] for text in test_inputs: print(f\n用户{text}) response supervisor.run(text) print(f助手{response}) if __name__ __main__: main()4.9 运行结果预期输出如下用户帮我查一下订单号 20240315001 [Supervisor] 命中意图order 助手[订单助手负责查询订] 收到帮我查一下订单号 20240315001 [Tool 调用结果] 订单 20240315001 已发货预计明天送达。 用户我想退货订单号 20240315002 [Supervisor] 命中意图return 助手[退货助手负责核实退货] 收到我想退货订单号 20240315002 用户我要投诉物流太慢了 [Supervisor] 命中意图after_sale 助手[售后服务助手负责处理] 收到我要投诉物流太慢了这个案例把工厂模式、主从模式、工具注册、意图路由串联了起来。虽然逻辑简化了但结构已经具备生产项目的骨架。5. 常见问题与排查思路5.1 主 Agent 无法正确选择子 Agent问题现象常见原因解决思路所有请求都走同一个子 Agent意图识别过于简单使用模型做意图分类而不是只靠关键词匹配子 Agent 相互冲突系统提示词职责划分不清为每个 Agent 明确限定“绝不处理”的边界意图识别结果不稳定提示词缺少示例在提示词中增加 few-shot 示例建议在生产环境中为每个意图准备 5-10 个典型用户句子构造少量样本用于模型微调或 few-shot 提示。5.2 Sub-Agent 作为 Tool 调用时上下文丢失问题现象常见原因解决思路子 Agent 不知道订单号主 Agent 没有把上下文完整传入封装 Tool 时显式传入结构化参数子 Agent 之间信息孤立没有共享内存引入 Conversation Memory 或向量记忆库结果汇总不符合要求缺少汇总提示词主 Agent 在收到子 Agent 结果后增加二次加工把 Sub-Agent 当成 Tool 调用本质上是降低主 Agent 的上下文负担。但这要求每个 Tool 的入参、出参尽量标准化否则主 Agent 的提示词会越来越复杂。5.3 状态机导致流程卡死问题现象常见原因解决思路用户反复修改信息流程无法前进状态转移条件过严增加“回到上一步”或“重新开始”事件模型生成的事件不在状态表中事件枚举不完整增加 DEFAULT 事件处理未知事件状态存内存里重启后丢失没有持久化将状态写入 Redis 或数据库状态机的核心是“确定性”。在 AI 场景中模型输出天然带有不确定性因此不能直接让模型自由写状态而应该让模型输出结构化事件再交给状态机处理。5.4 模型调用限流问题现象常见原因解决思路请求 429并发 QPS 过高增加限流组件、退避重试大量重复调用没有缓存对相同输入增加缓存例如基于 embedding 的相似缓存成本失控模型选择不智能简单问题走轻量模型复杂问题再升级在 AI 软件工厂里模型调用不是“免费的 API 测试”而是真正的成本中心必须纳入监控与预算管理。6. AI 软件工程中的设计模式全景6.1 传统设计模式的 AI 映射传统设计模式AI 场景示例工厂模式根据场景创建不同类型的 Agent策略模式根据业务需求切换模型或提示词模板方法模式定义固定流程骨架子类实现细节观察者模式模型输出结果发布给多个下游处理组件适配器模式把不同厂商的模型 API 统一为同一接口门面模式对上层提供统一 Agent 调用入口状态模式多轮对话状态管理、任务状态流转设计模式不是 AI 开发的银弹但它提供了一套“成熟的沟通语言”。团队讨论时说“这里用工厂模式管理 Agent 创建”和“这里用 if-else 创建一堆 Agent”复杂度差距会越来越大。6.2 DDD 思想在 AI 工程中的应用领域驱动设计DDD强调“先理解业务领域再设计技术实现”。AI 项目中同样适用不要把 Agent 设计成“什么都能干的万能助手”。每个 Agent 应该对应一个明确业务能力比如“订单查询能力”“库存咨询能力”“退货审核能力”。上下文Context边界要清晰。子 Agent 之间共享信息时必须显式传递而不是依赖全局变量。每个工具的输入输出要有明确的“契约”类似 DDD 中的防腐层。6.3 状态机模式在多 Agent 场景下的扩展当系统从单 Agent 升级到多 Agent 时状态机需要考虑“跨 Agent 状态”。例如退货流程主控调度 - 退货Agent确认订单 - 调用库存工具 - 调用退款工具 - 通知用户这个流程涉及多个组件每个组件都可能成功或失败。建议用状态机描述整体流程而每个 Agent 只负责其中一段的子状态。# workflow/return_pipeline.py from workflow.state_machine import ReturnStateMachine, OrderState class ReturnPipeline: def __init__(self): self.state_machine ReturnStateMachine() def handle_user_input(self, user_input: str) - str: if self.state_machine.state OrderState.INIT: if 订单号 in user_input: order_id user_input.split(订单号)[-1].strip() self.state_machine.context[order_id] order_id self.state_machine.trigger(provide_order_id) self.state_machine.trigger(order_id_received) return 请问您要退哪个商品请提供商品名称。 if self.state_machine.state OrderState.WAITING_PRODUCT_CONFIRM: self.state_machine.context[product_name] user_input.strip() self.state_machine.trigger(product_confirmed) # 这里可以调用策略模式根据商品类型选择退货策略 self.state_machine.trigger(policy_ok) self.state_machine.trigger(apply_success) return 退货申请已提交物流单号将在1小时内发送给您。 return 抱歉当前流程状态无法处理该输入请重新描述问题。这样做的价值是即使模型理解出现偏差流程执行的边界还是可控的。7. 最佳实践与工程建议7.1 命名规范建议在项目初期统一命名规则Agent 类名以业务域命名OrderAgent、ReturnAgent而不是MyAgent、TestAgent。Tool 名使用动词开头query_order_status、apply_return_refund便于大模型理解。状态名使用业务语义WAITING_ORDER_ID而不是无意义的STATE_1。7.2 配置管理模型名称、API Key、温度参数不要写死在代码里。使用环境变量管理密钥。不同环境dev、test、prod使用独立配置。# config/prod.yaml model: name: qwen-max temperature: 0.1 max_tokens: 4096 agent: supervisor_model: qwen-max sub_agent_model: qwen-turbo memory: type: redis ttl: 36007.3 异常处理与降级AI 应用最怕的是“模型服务不可用导致整个业务中断”。工程上建议所有的模型调用都设置超时时间。调用失败先重试一次第二次失败走本地兜底回复。如果主模型不可用考虑切换备用模型服务。# utils/llm.py import time def call_llm_with_retry(func, retries2, timeout10): for attempt in range(retries 1): try: return func(timeouttimeout) except TimeoutError: if attempt retries: time.sleep(1) continue return 系统繁忙请稍后重试。7.4 日志与可观测性传统后端开发重视日志AI 项目更需要日志因为模型输出经常是黑盒。建议记录用户完整输入。系统提示词版本。意图识别结果。选择的 Agent 和工具。模型原始输出。后处理后的最终回复。耗时与 token 消耗。from loguru import logger logger.info(Agent execution start | intent{} | agent_type{}, intent, agent_type)7.5 安全边界不要将系统提示词直接暴露给用户。子 Agent 之间不要共享敏感密钥。外部用户传入的内容必须经过敏感词过滤和安全审查。涉及支付、退款等操作必须加入人工审批环节不能让模型独立完成。7.6 最小权限原则如果 AI Agent 要操作数据库或第三方系统应该遵循最小权限原则查询 Agent 只授予只读权限。修改 Agent 只授予特定表的写权限。涉及删除操作需要二次确认或人工审批。所有敏感操作保留审计日志。8. 从第一期到第七十一期AI 项目开发的演进总结AI 应用开发的主题已经从“如何调大模型接口”演进到“如何组织复杂 AI 工程”。从第 71 期直播呈现的内容来看有几个趋势非常明显第一AI Agent 正在从单体对话机器人走向多智能体协作。单体 Agent 的上下文窗口再好也难以应对复杂业务。主流方案开始走向“主 Agent 子 Agent 工具”的组合结构。第二Sub-Agent 作为 Tool 被调用已经成为常见落地路径。这意味着多 Agent 系统可以复用成熟的工具调用机制不必为每个 Agent 定制编排引擎。工程实现上只需要把子 Agent 包装成标准接口主 Agent 就能像调用普通函数一样调用子 Agent。第三状态机模式重新回归。大模型生成具有不确定性但业务流程不能不确定。状态机给 AI 应用提供了“确定性骨架”模型在骨架内生成内容而不是自由发挥。第四软件工厂隐喻不仅仅是一种宣传说法。它意味着 AI 开发要追求可复用、可测试、可运维。设计模式在这个背景下从“软技能”变成了“工程基础设施”。第五DDD 等后端设计思想正在 AI 项目中被重新验证。领域边界、上下文隔离、防腐层这些概念在智能体设计中依然有效。真正能把 AI 项目做大的团队往往是后端架构功底扎实的团队。9. 实践任务清单如果你准备在项目中落地本文的设计模式建议按照以下顺序推进梳理业务边界列出你希望 AI 系统具备的 5 个能力点。为每个能力设计独立 Agent明确系统提示词和禁止事项。用工厂模式实现 Agent 动态创建与注册。将子 Agent 封装为 Tool统一注册到工具表。为主流程设计状态机覆盖主要业务状态。加入日志、超时、重试与降级机制。最后再接真实模型服务先用 mock 结果验证流程。不要一开始就接入最强模型。先把编排结构跑通再逐步替换模型策略。10. 下一期可以继续关注的方向AI 软件工厂的后续演进方向包括多 Agent 的自动评估与质量门禁。Agent 可观测性与 trace 追踪系统。模型路由与成本优化平台。AI 项目的持续集成与持续部署。智能体的安全测试与红队测试。从单项目 AI 架构走向 AI 中台。对于已经把设计模式学完的开发者下一步可以重点学习 AI Agent 框架的源码理解框架底层如何注册工具、如何管理多轮上下文、如何处理流式输出。理解框架之后你就能在自己的业务代码里做出更合理的取舍。如果本文对你有帮助欢迎收藏备用。动手写代码时如果遇到问题欢迎在评论区讨论。