AI智能体编排框架：从单体应用到智能体即服务的架构演进

1. 项目概述：从单体应用到智能体驱动的范式转变

最近在GitHub上看到一个挺有意思的项目，叫nerdzinha/agents。光看这个名字，可能很多人会联想到AI智能体，没错，这确实是一个关于构建和运行AI智能体的开源项目。但它的价值远不止于此。在我过去十多年的开发经验里，我们经历了从单体应用、微服务到如今“智能体即服务”的架构演进。agents这个项目，在我看来，正是这种演进趋势下的一个具体实践，它试图解决一个核心问题：如何将大语言模型（LLM）的能力，以一种标准化、可编排、可管理的方式，封装成一个个独立的、可复用的“智能体”，并让它们协同工作，去完成更复杂的任务。

简单来说，它不是一个简单的聊天机器人框架，而是一个智能体编排与执行平台。你可以把它想象成一个数字世界的“导演工作室”。导演（开发者）手里有一群各有所长的演员（智能体），比如有的擅长文本分析（分析员Agent），有的擅长调用API获取数据（数据员Agent），有的擅长生成图表（可视化Agent）。agents项目提供的，就是一套让导演能轻松编写剧本（定义工作流）、指挥演员按顺序或条件执行（任务编排）、并实时监控演出效果（日志与状态管理）的工具集和运行时环境。

这个项目适合谁呢？我认为有三类人会很感兴趣。第一类是全栈或后端开发者，你厌倦了为每一个AI功能点写一堆胶水代码，想要一个统一的框架来管理所有与LLM交互的逻辑。第二类是AI应用创业者或产品经理，你有一个复杂的、多步骤的AI产品创意（比如自动化的市场报告生成、智能客服工单处理），需要快速验证工作流是否跑得通。第三类是技术爱好者或学生，你想深入理解AI智能体是如何被构建、通信和管理的，agents提供了一个相对清晰、可学习的代码库。

它的核心价值在于“降本增效”。通过标准化智能体的接口和生命周期，它降低了开发复杂AI工作流的门槛；通过内置的编排引擎，它提升了任务执行的可靠性和可观测性。接下来，我们就深入这个“导演工作室”，看看它的后台到底是如何运作的。

2. 核心架构与设计哲学拆解

2.1 智能体作为一等公民：从函数到自治实体

在传统的编程范式里，我们通过函数（Function）或服务（Service）来封装逻辑。函数是被动执行的，需要明确的调用指令和输入参数。而agents项目倡导的理念是，将“智能体”（Agent）视为系统中的一等公民。一个智能体不仅仅是一段代码，它是一个具有状态、目标、能力和通信接口的自治实体。

这带来了根本性的不同。举个例子，一个“天气查询”函数，你需要传入城市名，它返回天气数据。而一个“天气信息员”智能体，它可能内置了“理解用户模糊位置描述”（如“我老家明天天气怎么样？”）的能力，能主动去调用地理位置解析服务和天气API，甚至能根据天气数据给出“建议带伞”的结论。智能体封装了从意图理解到任务执行再到结果加工的完整闭环。

agents项目是如何在架构上支持这一理念的呢？从代码结构来看，它通常会定义几个核心的基类或接口：

1. Agent基类：所有智能体的父类，定义了诸如initialize、execute、handle_message等生命周期方法。这里会强制要求子类实现其核心能力逻辑。
2. 消息总线或通信层：智能体之间不能直接耦合调用，而是通过发送和接收消息来协作。这类似于演员之间通过台词和对戏来推进剧情。项目会实现一个轻量级的消息队列或事件系统，用于路由消息。
3. 上下文（Context）管理：每个智能体在执行任务时，都需要一个上下文，包含当前会话信息、用户数据、历史记录等。agents框架需要提供一套机制来创建、传递和持久化上下文，确保智能体在复杂的多轮交互中“不迷失”。

注意：这种设计模式解耦了智能体间的依赖，使得系统更具弹性。你可以随时替换或升级某个智能体，只要它遵守相同的通信协议，整个工作流依然可以运行。这是构建可持续演进AI系统的关键。

2.2 工作流编排：可视化与代码化的双重表达

单个智能体能力有限，真正的威力来自于智能体的组合与编排。agents项目的另一个核心模块就是工作流（Workflow）或管道（Pipeline）编排器。这相当于导演的“分镜脚本”。

一个典型的编排场景可能是“智能内容创作”：用户输入一个主题 ->研究Agent搜索相关资料并总结 ->大纲Agent根据资料生成内容大纲 ->写作Agent根据大纲撰写初稿 ->润色Agent对初稿进行语法检查和风格优化 -> 输出最终文章。

agents框架需要提供一种方式来定义这个流程。通常有两种方式：

• 代码定义（DSL）：通过一个领域特定语言或Python装饰器/类来声明工作流。这种方式灵活、强大，适合开发者。

  # 假设性示例，非项目真实代码 @workflow(name="content_creation") def create_content(topic: str): research_result = research_agent.execute(topic) outline = outline_agent.generate(research_result) draft = writing_agent.write(outline) final = polishing_agent.refine(draft) return final

• 可视化编排：通过拖拽节点（智能体）和连接线（数据流）的图形界面来构建工作流。这种方式直观，降低了非技术人员的参与门槛。agents项目若具备或计划集成此类UI，将大大提升其易用性。

编排引擎的核心职责是调度和数据传递。它需要决定哪个智能体在何时运行，如何将上一个智能体的输出，转换成下一个智能体所需的输入。这里会涉及错误处理（某个智能体执行失败怎么办？）、条件分支（如果研究结果为空，则跳过写作直接告警）、循环（持续监控直到满足某个条件）等复杂逻辑的实现。

2.3 状态持久化与可观测性：让运行过程透明化

当智能体和工作流在后台异步执行时，如何知道它们进行到哪一步了？是否出错了？中间结果是什么？这对于调试和运维至关重要。因此，一个成熟的agents框架必须重视状态持久化和可观测性。

• 状态持久化：每个工作流实例、每个智能体任务都应该有一个唯一的ID和状态（如“等待中”、“执行中”、“成功”、“失败”）。这些状态需要被持久化到数据库（如PostgreSQL, Redis）中。这样，即使系统重启，也能恢复中断的工作流。agents项目需要抽象出存储层接口，允许用户适配不同的存储后端。
• 日志与追踪：详细的执行日志是排查问题的生命线。框架应该自动记录每个智能体的输入、输出、开始时间、结束时间以及内部的重大决策点。更高级的实现会集成分布式追踪（如OpenTelemetry），将一个请求流经的所有智能体串联起来，形成完整的调用链视图，便于进行性能分析和根因定位。
• 监控与管理界面：一个Web管理面板是“导演”的指挥台。在这里，可以查看所有运行中的和历史的智能体任务、工作流实例，可以手动重试失败的任务，可以查看详细的日志和中间数据。这对于运营复杂的AI应用是不可或缺的。

3. 核心模块深度解析与实操要点

3.1 Agent基类：定义智能体的契约

让我们深入到代码层面。一个健壮的Agent基类是框架的基石。它需要平衡“约束”与“灵活”。约束是为了保证所有智能体行为一致，便于框架管理；灵活是为了让开发者能自由实现各种奇异功能。

一个典型的Agent基类可能包含以下核心部分：

from abc import ABC, abstractmethod from typing import Any, Dict, Optional from pydantic import BaseModel class AgentContext(BaseModel): """智能体执行的上下文数据模型""" session_id: str user_id: Optional[str] input_data: Dict[str, Any] historical_messages: List[Dict] = [] # ... 其他自定义字段 class BaseAgent(ABC): def __init__(self, agent_id: str, config: Dict[str, Any]): self.agent_id = agent_id self.config = config self._initialized = False async def initialize(self): """初始化智能体，如加载模型、连接外部服务""" if not self._initialized: # 执行具体的初始化逻辑，比如加载AI模型权重 await self._setup() self._initialized = True @abstractmethod async def execute(self, context: AgentContext) -> AgentContext: """ 执行智能体的核心逻辑。 必须由子类实现。 参数 context: 包含输入和历史的上下文。 返回: 更新后的上下文，通常包含输出结果。 """ pass async def handle_message(self, message: Dict) -> Dict: """处理来自其他智能体或系统的消息（可选）""" # 默认实现，子类可覆盖 pass def get_status(self) -> Dict[str, Any]: """返回智能体的当前状态""" return {"agent_id": self.agent_id, "initialized": self._initialized}

实操要点：

1. 异步优先：AI模型调用、网络IO都是阻塞性操作，因此execute等方法应设计为async，以支持高并发。
2. 上下文即参数：将所有输入、输出、会话状态都封装进AgentContext对象中传递，避免了函数参数列表的无限膨胀，也使数据流更清晰。
3. 明确的初始化阶段：initialize方法将资源密集型操作（如加载大模型）与执行逻辑分离，方便框架在启动时预加载智能体，提升首次响应速度。
4. 配置化：通过config字典传入配置，使得同一个智能体类可以通过不同配置实例化为不同“角色”（如一个翻译Agent，通过配置指定源语言和目标语言）。

注意：在子类实现execute时，务必做好错误处理。智能体的失败不应该导致整个工作流崩溃，而应该被框架捕获，并更新任务状态为“失败”，同时记录详细的错误信息到上下文中，供后续处理或人工查看。

3.2 通信机制：事件驱动与消息队列

智能体之间如何“对话”？直接函数调用会引入紧耦合。agents框架通常采用事件驱动架构。每个智能体可以发布（publish）事件（消息），也可以订阅（subscribe）感兴趣的事件。

一种常见的实现是使用内存中的事件总线（如asyncio.Event或pubsub模式）作为轻量级解决方案。对于分布式部署，则需要集成真正的消息队列，如 Redis Pub/Sub、RabbitMQ 或 Apache Kafka。

# 简化的事件总线示例 class EventBus: def __init__(self): self._subscribers = defaultdict(list) def subscribe(self, event_type: str, callback: Callable): self._subscribers[event_type].append(callback) async def publish(self, event_type: str, data: Any): for callback in self._subscribers.get(event_type, []): # 异步执行回调，避免阻塞发布者 asyncio.create_task(callback(data)) # 智能体注册到事件总线 class ResearchAgent(BaseAgent): async def execute(self, context: AgentContext) -> AgentContext: # ... 执行研究逻辑 research_data = await self._do_research(context.input_data["topic"]) context.output_data = {"research": research_data} # 研究完成，发布一个事件 await event_bus.publish("research.completed", {"session_id": context.session_id, "data": research_data}) return context class OutlineAgent(BaseAgent): def __init__(self, agent_id: str, config: Dict): super().__init__(agent_id, config) # 订阅感兴趣的事件 event_bus.subscribe("research.completed", self.on_research_completed) async def on_research_completed(self, event_data: Dict): # 当收到研究完成事件，触发大纲生成 if event_data["session_id"] == self.current_session_id: # 需要会话匹配逻辑 context = self._create_context_from_event(event_data) await self.execute(context)

核心考量：

• 消息格式标准化：定义统一的消息信封（Envelope），包含消息ID、类型、发送者、接收者、时间戳、会话ID和负载（Payload）。
• 序列化：消息需要被序列化（如JSON）以便于网络传输和持久化。
• 错误处理与重试：消息可能丢失或处理失败。框架需要提供至少一次（at-least-once）或恰好一次（exactly-once）的投递语义，并实现死信队列（DLQ）来处理反复失败的消息。
• 性能：消息传递是系统的中枢神经，其性能直接影响整体吞吐量。需要根据场景选择合适的技术栈。

3.3 工具（Tools）集成：扩展智能体的手和脚

智能体的核心能力可能来自大语言模型，但很多实际任务需要与真实世界交互：查询数据库、调用第三方API、操作文件、执行计算。这些能力通常通过“工具”（Tools）来集成。

agents框架应该提供一套优雅的工具集成机制。一种流行的模式是受 LangChain 或 AutoGPT 启发的“工具调用”（Tool Calling）：智能体（或背后的LLM）在推理过程中，可以“决定”调用某个工具，框架负责执行该工具并返回结果。

class BaseTool(ABC): name: str description: str parameters_schema: Dict[str, Any] # 描述工具输入参数的JSON Schema @abstractmethod async def run(self, **kwargs) -> Any: pass class WebSearchTool(BaseTool): name = "web_search" description = "Search the web for current information." parameters_schema = { "type": "object", "properties": { "query": {"type": "string", "description": "The search query."}, "max_results": {"type": "integer", "default": 5} }, "required": ["query"] } async def run(self, query: str, max_results: int = 5) -> List[Dict]: # 调用实际的搜索API，如Serper.dev, Google Custom Search async with aiohttp.ClientSession() as session: # ... 发起请求并解析结果 return search_results # 在智能体中声明可用的工具 class ResearcherAgent(BaseAgent): def __init__(self, agent_id: str, config: Dict): super().__init__(agent_id, config) self.tools = { "web_search": WebSearchTool(), "calculate": CalculatorTool(), # ... 其他工具 } async def execute(self, context: AgentContext) -> AgentContext: # 智能体的逻辑可能由LLM驱动，LLM根据问题选择并调用工具 # 框架部分需要实现LLM与工具调用的粘合逻辑 llm_response = await self.llm.decide_tool_use(context.user_query, self.tools) if llm_response.tool_to_use: tool = self.tools[llm_response.tool_to_use] result = await tool.run(**llm_response.tool_arguments) # 将结果反馈给LLM或直接放入上下文 context.intermediate_results.append(result) return context

实操心得：

1. 工具描述要精准：description和parameters_schema是LLM能否正确调用工具的关键。描述应清晰说明工具的用途、输入和输出。使用JSON Schema可以严格定义输入格式，减少LLM的幻觉调用。
2. 工具权限管理：不是所有智能体都应该能调用所有工具。比如，一个“只读分析Agent”不应该拥有“删除数据库记录”的工具。框架需要支持在智能体或工作流层面进行工具权限的配置。
3. 工具执行环境隔离：对于执行系统命令或文件操作的工具，必须考虑安全沙箱，防止恶意代码执行。

4. 从零构建一个智能体工作流：实战演练

4.1 场景定义与智能体设计

假设我们要实现一个“智能旅行规划助手”工作流。用户输入目的地和出行天数，系统自动生成一份包含景点推荐、住宿建议、天气提醒和大致预算的旅行计划。

我们需要设计以下智能体：

1. 目的地解析器（DestinationParserAgent）：解析用户输入，可能从模糊描述中提取具体城市、国家，并标准化格式。
2. 信息搜集员（InfoGathererAgent）：并发调用多个工具，获取目的地的景点、美食、文化活动信息，以及近期的天气预测。
3. 行程规划师（ItineraryPlannerAgent）：基于搜集的信息、用户的天数和偏好（需通过对话或配置获取），生成按天划分的详细行程。
4. 预算估算师（BudgetEstimatorAgent）：根据行程、当地的消费水平，估算大致的交通、住宿、餐饮和门票费用。
5. 报告生成器（ReportGeneratorAgent）：将以上所有信息整合成一份结构清晰、格式美观的Markdown或PDF报告。

4.2 工作流编排实现

我们使用代码DSL的方式来定义这个工作流。假设agents框架提供了一个Workflow类。

from agents.framework import Workflow, BaseAgent, AgentContext from agents.agents import DestinationParserAgent, InfoGathererAgent, ItineraryPlannerAgent, BudgetEstimatorAgent, ReportGeneratorAgent import asyncio class TravelPlanningWorkflow(Workflow): name = "smart_travel_planning" version = "1.0" async def run(self, initial_input: Dict) -> Dict: """ 工作流主函数 """ # 1. 创建初始上下文 ctx = AgentContext( session_id=self.generate_session_id(), user_id=initial_input.get("user_id"), input_data=initial_input ) # 2. 初始化智能体实例 (框架通常有依赖注入或注册表管理) parser = DestinationParserAgent("parser_1", {}) gatherer = InfoGathererAgent("gatherer_1", {"timeout": 30}) planner = ItineraryPlannerAgent("planner_1", {}) estimator = BudgetEstimatorAgent("estimator_1", {"currency": "CNY"}) reporter = ReportGeneratorAgent("reporter_1", {"format": "markdown"}) await asyncio.gather( parser.initialize(), gatherer.initialize(), planner.initialize(), estimator.initialize(), reporter.initialize() ) # 3. 顺序执行工作流（实际可能更复杂，有条件分支） try: # 阶段1: 解析目的地 ctx = await parser.execute(ctx) if not ctx.get("parsed_destination"): raise ValueError("Failed to parse destination.") # 阶段2: 并发搜集信息 (景点、天气等) # 注意：这里需要将上下文拆解出不同任务所需参数，并发执行后合并结果 # 为简化，假设gatherer内部并发调用多个工具 ctx = await gatherer.execute(ctx) # 阶段3: 规划行程 ctx = await planner.execute(ctx) # 阶段4: 估算预算 ctx = await estimator.execute(ctx) # 阶段5: 生成最终报告 ctx = await reporter.execute(ctx) # 工作流成功完成 self.status = "completed" return { "status": "success", "session_id": ctx.session_id, "final_report": ctx.output_data.get("report"), "intermediate_data": ctx.intermediate_results # 可选，返回中间数据用于调试 } except Exception as e: # 工作流执行失败 self.status = "failed" self.error = str(e) # 记录详细的错误上下文 logger.error(f"Workflow failed for session {ctx.session_id}: {e}", exc_info=True) return { "status": "error", "session_id": ctx.session_id, "error": str(e), "step_failed_at": self.current_step # 需要框架跟踪当前步骤 }

关键实现细节：

• 错误处理与补偿：上述代码是简单的顺序执行。在生产环境中，需要考虑某个智能体失败后的重试策略、补偿事务（如已调用外部API产生副作用怎么办）以及整个工作流的回滚或人工干预流程。
• 上下文管理与数据流：ctx对象在各个智能体间传递。需要精心设计ctx的数据结构，避免不同智能体污染彼此的字段。可以使用命名空间，如ctx.data["parsed"]、ctx.data["gathered"]。
• 并发控制：InfoGathererAgent内部可能并发调用多个工具（天气API、景点API），需要使用asyncio.gather来提高效率。框架层面可能需要控制全局并发度，防止对下游服务造成冲击。

4.3 部署与运行监控

开发完成后，我们需要将这个工作流部署起来，并提供API供前端或用户调用。

1. API服务层：使用 FastAPI 或 Flask 创建一个Web服务。主要端点包括：

   • POST /workflows/travel-plan/execute：触发旅行规划工作流。
   • GET /workflows/travel-plan/status/{session_id}：查询某个会话的工作流执行状态。
   • GET /workflows/travel-plan/result/{session_id}：获取执行结果。
   • POST /workflows/travel-plan/cancel/{session_id}：取消正在执行的工作流。

2. 任务队列集成：对于耗时较长的工作流（可能几十秒甚至几分钟），不应该在HTTP请求线程中同步执行。应该将工作流执行任务提交到像 Celery + Redis/RabbitMQ 或 RQ 这样的任务队列中，API接口立即返回一个任务ID，客户端通过轮询或WebSocket来获取结果。

3. 监控仪表盘：利用框架的状态持久化功能，我们可以构建一个简单的管理后台，展示：

   • 所有工作流实例的列表及其状态（成功、失败、运行中）。
   • 每个实例下各个智能体任务的执行详情和耗时。
   • 系统级别的指标，如智能体调用次数、平均响应时间、错误率。
   • 日志查看器，可以按会话ID或时间过滤日志。

5. 常见问题、性能优化与避坑指南

在实际使用和构建agents这类框架时，会遇到许多挑战。以下是我总结的一些常见问题与解决方案。

5.1 智能体执行超时与僵尸任务

问题：某个智能体（尤其是调用外部慢API或复杂模型推理时）执行时间过长，甚至无响应，导致整个工作流卡住，资源被占用。

解决方案：

• 设置超时：在每个智能体的execute方法调用时，使用asyncio.wait_for或为任务队列配置超时时间。

  try: result = await asyncio.wait_for(agent.execute(ctx), timeout=agent.config.get("timeout", 60.0)) except asyncio.TimeoutError: ctx.status = "timeout" ctx.error = f"Agent {agent.agent_id} execution timed out." # 触发超时处理逻辑，如重试或标记工作流失败

• 心跳与健康检查：对于长时间运行的任务，智能体应定期向框架报告“心跳”。框架端设置一个看门狗（Watchdog），如果超过预定时间未收到心跳，则判定任务僵死，强制终止并清理资源。
• 任务可中断设计：设计智能体时，考虑支持优雅中断。例如，将长时间计算分解为多个可保存状态的步骤，收到中断信号时能保存当前进度。

5.2 上下文数据膨胀与序列化开销

问题：工作流执行步骤多，每个智能体都在上下文ctx中添加数据，导致ctx对象变得非常庞大。在消息传递或状态持久化时，序列化/反序列化的开销巨大，影响性能。

解决方案：

• 上下文分片：不要将所有数据都放在一个内存对象里传递。对于大型中间结果（如搜集到的大量网页文本、生成的图片），可以将其存储到外部存储（如对象存储S3、数据库BLOB字段）中，在上下文中只保存其引用（如URL或存储ID）。
• 惰性加载：上下文中某些数据可能只在特定步骤被用到。可以设计一个惰性加载的机制，只有真正访问时，才从外部存储加载。
• 压缩：在序列化前后对数据进行压缩（如gzip），对于文本类数据效果显著。
• 选择高效的序列化格式：相比JSON，MessagePack、Protocol Buffers或Pickle（注意安全风险）等二进制格式通常更小更快。

5.3 LLM调用成本与速率限制

问题：多个智能体可能都需要调用LLM API（如OpenAI GPT、Anthropic Claude），导致API调用成本激增，且容易触发提供商的速率限制（Rate Limit）。

解决方案：

• 缓存层：对LLM的请求和响应进行缓存。如果两个不同的会话或智能体提出了完全相同（或高度相似）的请求，可以直接返回缓存的结果。缓存键可以基于模型名称、请求参数（Prompt、温度等）的哈希值。可以使用Redis或Memcached。
• 请求合并与批处理：如果框架内同时有多个智能体准备调用相同模型的LLM，可以将这些请求合并成一个批处理请求发送给API（如果API支持），这通常比逐个请求更高效、更便宜。
• 限流与队列：在框架层面实现一个全局的LLM调用限流器。为每个LLM供应商/模型设置一个并发请求数上限和每秒请求数（RPS）限制。超出限制的请求进入队列等待。这不仅能防止触发速率限制，还能平滑请求流量，避免突发流量对系统造成压力。
• 降级策略：当主要LLM服务不可用或成本过高时，能否降级到更便宜、更快的模型（或规则引擎）？在智能体设计时可以考虑备选方案。

5.4 智能体间的循环依赖与死锁

问题：在复杂的编排中，智能体A等待智能体B的输出，而智能体B又需要智能体A的输出，形成循环依赖，导致死锁。

解决方案：

• 工作流静态分析：在定义工作流时（尤其是可视化编排时），框架应能进行静态的依赖分析，检测出明显的循环依赖并报错。
• 超时与死锁检测：在运行时，监控智能体等待消息的时间。如果某个智能体长时间等待未收到预期消息，可以触发超时异常，并记录可能的死锁路径。
• 设计模式：避免双向强依赖。通常，工作流应设计成有向无环图（DAG）。如果确实需要双向信息交换，考虑引入第三个“协调者”智能体，或使用发布/订阅模式让双方都向一个公共频道发布信息，而不是直接点对点请求。

5.5 调试与测试困难

问题：AI智能体的行为具有非确定性（尤其是基于概率的LLM），工作流涉及多个步骤和外部服务，调试和编写自动化测试非常困难。

解决方案：

• 详尽的日志与追踪：如前所述，这是基础。确保每个决策点、工具调用、LLM请求和响应都被结构化记录，并关联到唯一的会话ID和链路追踪ID。
• 上下文快照与回放：框架可以支持将某个失败工作流的完整上下文（包括所有输入、中间结果）保存为“快照”。开发者可以离线加载这个快照，在调试环境中重新执行到失败点，或者单步执行智能体，观察内部状态变化。
• Mock与测试替身：为外部服务（LLM API、数据库、第三方API）创建Mock或Stub。在测试时，用这些可控的替身替换真实服务，可以模拟各种成功、失败、超时场景，确保智能体逻辑的健壮性。agents框架应提供方便的依赖注入机制来支持这一点。
• 评估指标：为智能体和工作流定义可量化的评估指标。例如，对于翻译智能体，可以使用BLEU分数；对于问答智能体，可以使用准确率。通过自动化测试集定期运行，监控智能体性能的波动。

构建一个成熟的agents系统是一个复杂的工程，它融合了软件架构、分布式系统、AI工程化和运维监控等多个领域的知识。nerdzinha/agents这样的项目为我们提供了一个探索和实践的起点。从理解其设计哲学开始，到亲手实现一个智能体，再到编排复杂的工作流，每一步都充满了挑战和乐趣。最重要的是，它让我们以一种新的、更模块化、更可控的方式来思考和应用人工智能。