一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > AI > 正文内容

AWS Strands SDK 技术调研报告：AI 代理开发的新范式与未竟之路

anycodes3天前AI220

> 人工智能领域正在经历从单一模型调用到复杂智能代理构建的重要转变。

最近一段时间，我频繁收到业内朋友的咨询：他们希望了解Amazon Q的实现原理，并探讨是否可以在自己的业务平台或产品中复刻类似功能，主要目标是通过AI助手提升运维效率。上周在AWS中国峰会期间，我有幸与Amazon Q团队的工程师进行了深入交流，并向他们转达了这些普遍关注的问题。令人振奋的是，团队成员给出了明确的技术路径：AWS Strands SDK正是为此类需求量身打造的解决方案。简而言之，这个开源框架可以帮助开发者快速构建出类似Amazon Q的智能助手，将强大的AI代理能力整合到自己的产品生态中。

![25062703.png](https://note.runor.cn/pic/home/bl/img/U1/25062703.png)

本文将深入探讨 Strands 的技术架构、实现细节和应用场景，并通过与早期项目 DipperAI 的比较，反思 AI 开发工具演进的必然趋势及未能实现的可能性，

> DipperAI 是自己在前东家离职前想要去做的一个项目，其实殊途同归，最终的目的和 Stands SDK 有极大的类似，甚至功能上会出现极大的重合，可惜...

## Strands SDK 的技术底蕴与实现细节

AWS Strands SDK 是一个基于深刻技术洞察的代理开发框架，其核心理念源自对大型语言模型能力演进的敏锐观察。随着Claude、GPT系列和Llama等现代LLM的发展，它们已经具备了强大的规划、推理和工具使用能力，这使得传统的复杂代理编排方式变得冗余。Strands正是基于这一认识，采用了"模型驱动"的方法，将代理的决策权交给模型本身，而非预定义的工作流程。

### 核心架构与设计哲学

Strands的架构设计围绕一个核心理念：简化开发者与LLM能力之间的距离。其架构由三个关键组件组成：模型（作为代理的"大脑"）、工具（扩展代理的能力范围）和提示（定义代理的任务目标和行为边界）。这种设计使开发者能够专注于"要做什么"而非"如何做"。

![25062701.png](https://note.runor.cn/pic/home/bl/img/U1/25062701.png)

从技术实现角度看，Strands采用了模块化设计，将核心功能与扩展能力清晰分离。代码库主要由以下模块组成：

- `strands.agent`：定义Agent类，处理代理的初始化和交互
- `strands.models`：提供多种模型提供商的接口和实现
- `strands.tools`：工具注册、验证和执行的核心逻辑
- `strands.session`：管理对话历史和状态
- `strands.telemetry`：支持OpenTelemetry的可观察性实现

这种模块设计确保了框架的灵活性和可扩展性，同时保持了核心API的简洁。例如，添加新的模型提供商只需实现特定接口，而不会影响其他组件。

### 代理循环的深度解析

Strands最具创新性的部分是其代理循环（Agent Loop）的实现。这不仅是一个简单的请求-响应处理器，而是一个复杂的状态机，能够处理多轮交互、工具调用和动态上下文管理。

![25062702.png](https://note.runor.cn/pic/home/bl/img/U1/25062702.png)

但实际实现远比这个简化流程复杂。在源码层面，Strands实现了一个精巧的事件驱动系统，使用生成器（Python generators）和回调（callbacks）来处理异步交互和流式响应。这种设计使得代理可以在等待工具执行的同时保持响应性，并能实时向用户提供进度更新。

代理循环的一个关键优势是它对模型输出的智能解析。Strands使用了精心设计的提示工程技术，引导模型生成结构化输出，以便于解析工具调用意图和参数。与传统基于正则表达式的解析方法不同，Strands采用了更加灵活的语义解析方法，能够处理模型输出中的各种变体和边缘情况。

例如，当模型决定调用一个工具时，Strands会检测以下模式：

```
I'll use the [tool_name] tool with parameters: [parameters]
Let me search for [query] using the [search_tool]
```

此外，为了处理更复杂的场景，Strands实现了一个多阶段的推理过程，允许模型在单次交互中多次切换between思考和行动。例如，代理可能首先分析问题，然后调用工具A获取数据，分析结果后又调用工具B进行验证，最后综合所有信息生成回答。这种复杂的推理链条通过精心设计的上下文管理和状态追踪来实现。

### 模型集成与交互机制

Strands支持多种模型提供商，从技术上是通过抽象出一个统一的模型接口来实现的。这个接口定义了与模型交互的标准方法，包括初始化参数、生成请求和处理响应。每个具体的模型提供商实现都需要适配这个接口，同时处理特定模型的独特特性。

在内部实现中，模型交互是通过一个标准化的消息格式进行的，这种格式基于OpenAI的聊天消息协议，但经过扩展以支持更多功能：

```python
class Message:
    """表示聊天历史中的一条消息"""
    role: str  # 'system', 'user', 'assistant', 'tool'
    content: str  # 消息内容
    name: Optional[str] = None  # 对tool消息，表示工具名
    tool_calls: Optional[List[ToolCall]] = None  # 工具调用信息
    tool_call_id: Optional[str] = None  # 对tool消息，关联的工具调用ID
```

当代理向模型发送请求时，它会构建一个完整的上下文，包括系统提示、历史消息、当前用户输入和可用工具的描述。这个上下文经过精心排序和格式化，以最大化模型的理解和响应质量。

Strands还实现了模型交互的高级功能，如Token限制管理（自动截断过长历史以适应模型上下文窗口）、流式响应处理（允许实时显示模型生成结果）和错误处理（处理API故障、速率限制等）。这些功能使得代理在生产环境中更加健壮和可靠。

以Amazon Bedrock集成为例，Strands实现了一个专门的`BedrockModel`类，该类不仅处理与Bedrock API的通信，还优化了请求参数以获得最佳性能：

```python
class BedrockModel(BaseModel):
    """Amazon Bedrock模型提供商实现"""
    
    def __init__(
        self,
        model_id: str = "us.anthropic.claude-3-7-sonnet-20250219-v1:0",
        region_name: Optional[str] = None,
        temperature: float = 0.7,
        max_tokens: Optional[int] = None,
        client: Optional[Any] = None,
        **kwargs
    ):
        # 初始化Bedrock客户端和模型配置
        self.model_id = model_id
        self.client = client or boto3.client('bedrock-runtime', region_name=region_name)
        self.temperature = temperature
        self.max_tokens = max_tokens
        self.additional_params = kwargs
```

### 工具系统的设计与实现

Strands的工具系统是其最灵活的组件之一。工具本质上是带有元数据的Python函数，通过`@tool`装饰器注册到代理中。这个装饰器添加了描述、参数信息和返回类型等元数据，帮助模型理解如何使用工具。

工具注册的技术实现依赖于Python的内省和类型注解功能。当一个函数被`@tool`装饰时，Strands会检查函数签名、参数类型和文档字符串，自动生成工具描述。这个过程涉及复杂的类型解析和文档处理：

```python
def tool(_func=None, *, name=None, description=None):
    """将Python函数注册为代理工具"""
    def decorator(func):
        # 提取函数签名和类型注解
        sig = inspect.signature(func)
        params = sig.parameters
        
        # 生成参数架构
        param_schema = {}
        for param_name, param in params.items():
            # 处理参数类型、默认值和文档
            param_type = param.annotation if param.annotation != inspect.Parameter.empty else None
            param_schema[param_name] = _create_param_schema(param_name, param_type, param.default)
        
        # 生成工具描述
        tool_desc = description or inspect.getdoc(func) or f"Function {func.__name__}"
        
        # 创建和注册工具
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            return func(*args, **kwargs)
        
        wrapper.__strands_tool__ = {
            "name": name or func.__name__,
            "description": tool_desc,
            "parameters": param_schema,
            "return_type": sig.return_annotation if sig.return_annotation != inspect.Signature.empty else None
        }
        return wrapper
    
    return decorator(_func) if _func else decorator
```

除了基本的工具注册，Strands还实现了高级工具功能，如参数验证（确保模型提供的参数符合类型要求）、异步工具支持（适用于需要I/O操作的工具）和工具组合（将多个工具组合成更复杂的功能）。

特别值得一提的是Strands对MCP（Model Context Protocol）的支持。MCP是一个用于模型和工具交互的开放标准，通过实现MCP客户端，Strands能够与数千个预建工具无缝集成，而无需为每个工具编写自定义代码。这大大扩展了代理的能力范围。

### 多代理协作与编排

Strands不仅支持单一代理，还提供了多种多代理协作模式的实现。在技术层面，这是通过将代理实例封装为可调用工具来实现的。一个代理可以将另一个代理作为工具调用，从而形成层次结构或网络。

多代理系统的一个关键技术挑战是上下文管理。每个代理需要维护自己的上下文，同时又需要与其他代理共享信息。Strands通过会话（Session）机制解决了这个问题。每个代理实例都有一个关联的会话对象，用于存储对话历史和状态。会话可以配置为使用不同的存储后端，从内存存储（用于开发和简单场景）到持久化存储（如DynamoDB，用于生产环境）。

Strands还实现了一个`agent_graph`工具，用于定义和管理多代理网络。这个工具接受一个图定义，指定代理节点和连接边，然后处理代理之间的消息路由和状态管理。例如，以下代码展示了如何定义一个三层代理层次结构：

```python
from strands import Agent, tool
from strands_tools import agent_graph

# 定义代理图
graph_definition = {
    "nodes": {
        "executive": {
            "system_prompt": "你是一位执行官，负责高层决策和任务分配..."
        },
        "research_manager": {
            "system_prompt": "你是研究主管，负责协调研究工作..."
        },
        "data_analyst": {
            "system_prompt": "你是数据分析师，擅长处理和分析数据..."
        },
        "writer": {
            "system_prompt": "你是专业写手，负责内容创作和编辑..."
        }
    },
    "edges": [
        {"from": "executive", "to": "research_manager"},
        {"from": "research_manager", "to": "data_analyst"},
        {"from": "research_manager", "to": "writer"}
    ]
}

# 创建代理图工具
@tool
def execute_agent_graph(query: str) -> str:
    """使用代理图处理复杂查询"""
    result = agent_graph(graph_definition, entry_node="executive", query=query)
    return result

# 创建主代理使用代理图
agent = Agent(
    system_prompt="你是一个助手，可以处理复杂查询...",
    tools=[execute_agent_graph]
)
```

在这个例子中，用户查询首先传递给主代理，主代理调用`execute_agent_graph`工具，该工具又将查询传递给"executive"代理。执行官代理可能将子任务分配给研究主管，研究主管又可能委派给数据分析师和写手。这种灵活的结构使得代理系统能够处理复杂的多步骤任务。

### 可观察性与监控

生产级系统需要强大的可观察性支持，Strands在这方面进行了深入设计。该框架内置了对OpenTelemetry（OTEL）的支持，能够生成代理执行的详细轨迹（traces）、指标（metrics）和日志（logs）。

在技术实现上，Strands使用了装饰器模式为关键操作添加遥测点。例如，每次模型调用、工具执行和代理循环迭代都会生成相应的跟踪跨度（span）。这些跨度包含丰富的元数据，如模型输入/输出、工具参数/结果和执行时间等。

```python
def _trace_model_call(func):
    """为模型调用添加跟踪的装饰器"""
    @functools.wraps(func)
    async def wrapper(self, *args, **kwargs):
        tracer = trace.get_tracer("strands.models")
        with tracer.start_as_current_span("model_call") as span:
            # 添加模型类型和ID到跨度
            span.set_attribute("model.type", self.__class__.__name__)
            span.set_attribute("model.id", getattr(self, "model_id", "unknown"))
            
            # 记录请求大小（token数量）
            if "messages" in kwargs:
                input_tokens = self._estimate_tokens(kwargs["messages"])
                span.set_attribute("model.input_tokens", input_tokens)
            
            # 执行实际的模型调用
            try:
                result = await func(self, *args, **kwargs)
                
                # 记录响应大小（token数量）
                if hasattr(result, "usage") and result.usage:
                    span.set_attribute("model.output_tokens", result.usage.completion_tokens)
                
                return result
            except Exception as e:
                # 记录错误信息
                span.record_exception(e)
                span.set_status(Status(StatusCode.ERROR))
                raise
    
    return wrapper
```

Strands还提供了一个可配置的回调系统，允许开发者实时捕获代理执行的各个阶段。这对于创建自定义监控解决方案或实现用户界面的实时更新非常有用。例如，一个Web应用可以使用这些回调来流式显示代理的思考过程和工具使用情况。

```python
def stream_agent_process(message):
    """处理代理流式输出的回调函数"""
    def callback_handler(**kwargs):
        if "data" in kwargs:
            # 文本生成事件
            yield {"type": "text", "content": kwargs["data"]}
        elif "current_tool_use" in kwargs:
            # 工具使用事件
            tool = kwargs["current_tool_use"]
            yield {
                "type": "tool_use",
                "name": tool.get("name"),
                "input": tool.get("input"),
                "status": "started"
            }
        elif "tool_result" in kwargs:
            # 工具结果事件
            result = kwargs["tool_result"]
            yield {
                "type": "tool_result",
                "name": result.get("name"),
                "output": result.get("output"),
                "status": "completed"
            }
    
    # 创建代理并配置回调
    agent = Agent(callback_handler=callback_handler)
    
    # 返回生成器，产生流式事件
    return agent.stream_async(message)
```

### 实际应用中的高级功能

在实际应用中，Strands提供了多种高级功能，使其能够处理复杂的生产场景。例如，它实现了一个复杂的上下文管理系统，能够智能地截断和汇总长对话历史，以保持上下文窗口内的有效信息。这种"长期记忆"机制使得代理能够在长时间交互中保持一致性，同时避免上下文溢出问题。

另一个重要特性是状态持久化。Strands允许将代理会话状态保存到持久存储中（如DynamoDB或Redis），这样代理可以在重启后恢复之前的对话上下文。这对于长期运行的任务或需要高可用性的应用至关重要。

Strands还支持自定义模型提示策略。默认情况下，它使用预定义的提示模板来指导模型行为，但开发者可以完全自定义这些模板，以适应特定的应用需求。例如，一个金融顾问代理可能需要特定的指令来确保合规性和准确性。

```python
# 自定义提示策略
class FinancialAdvisorPromptStrategy(BasePromptStrategy):
    """金融顾问的自定义提示策略"""
    
    def system_prompt(self, agent_config):
        """生成系统提示"""
        base_prompt = agent_config.get("system_prompt", "")
        compliance_guidelines = """
        作为金融顾问，你必须遵循以下准则：
        1. 不提供具体投资建议，只提供教育性信息
        2. 所有风险声明必须明确
        3. 引用数据时必须标明来源和日期
        4. 不讨论特定证券的未来表现
        """
        return f"{base_prompt}\n\n{compliance_guidelines}"
    
    def format_tool_definitions(self, tools):
        """格式化工具定义"""
        # 自定义工具描述格式
        tool_descriptions = []
        for tool in tools:
            description = f"工具: {tool['name']}\n描述: {tool['description']}\n"
            if tool.get("parameters"):
                description += "参数:\n"
                for param_name, param_info in tool["parameters"].items():
                    description += f"  - {param_name}: {param_info.get('description', '')}\n"
            tool_descriptions.append(description)
        
        return "\n".join([
            "你可以使用以下工具:",
            "--------------------",
            *tool_descriptions,
            "--------------------",
            "使用工具时，请严格按照格式: '我将使用[工具名]工具，参数是: [参数]'"
        ])
```

此外，Strands实现了一种模型回退机制，在主要模型不可用或响应质量不佳时，可以自动切换到备用模型。这增强了系统的可靠性和稳健性，特别是在处理关键业务功能时。

### 与其他框架的技术比较

相比其他代理框架，Strands的技术设计有几个显著特点。与LangChain相比，Strands更加关注模型驱动的自主性，而不是开发者定义的工作流。LangChain的Chain和Agent构造通常需要开发者明确指定执行步骤，而Strands则将这种决策权交给LLM本身。

另一个差异点是代码复杂性。Strands的核心API非常简洁，一个完整的代理通常只需几行代码即可定义。这种简洁性使得快速原型开发变得容易，但也可能在需要高度自定义行为时需要更多工作。

在架构上，Strands采用了更加统一的设计，所有功能都围绕核心代理循环构建。这种一致性使得代码更容易理解和维护。相比之下，LangChain提供了更多离散的构建块，让开发者自行组合，这带来了更大的灵活性，但也增加了学习曲线。

在生产就绪性方面，Strands得益于AWS的企业级经验，内置了许多生产环境所需的功能，如全面的遥测、错误处理和扩展性支持。这使其特别适合企业应用，尤其是已经使用AWS服务的组织。

从模型支持的角度看，虽然两个框架都支持多种模型，但Strands与Amazon Bedrock的集成尤为紧密。它针对Bedrock模型进行了优化，并提供了无缝的权限和身份管理。同时，通过开放的模型接口，Strands也能很好地支持其他模型提供商。

综合来看，Strands的技术设计反映了一种更加集中和简化的理念，将复杂性隐藏在简洁API之下，而将智能决策交给强大的LLM模型。这种方法与当前LLM能力日益增强的趋势相契合，让开发者能够更加专注于代理的能力定义，而非实现细节。

## 市场格局与 Strands 的差异化优势

AI代理框架市场已经形成了一个多元化的生态系统。下表详细对比了主要框架的技术特点和适用场景：

| 框架 | 开发者 | 核心设计理念 | 优势 | 局限性 | 适用场景 |
|------|--------|--------------|------|--------|----------|
| Strands Agents | AWS | 模型驱动的代理循环 | 简单API、AWS集成、生产就绪 | 较新、文档仍在完善 | AWS客户、无服务器架构爱好者 |
| LangGraph | LangChain | 基于DAG的工作流控制 | 精确控制执行流、可视化 | 学习曲线陡、较复杂 | 需要严格工作流控制的企业应用 |
| OpenAI Agents SDK | OpenAI | 统一代理运行时 | 与OpenAI模型无缝集成 | 仅支持OpenAI模型 | 已使用OpenAI服务的团队 |
| AutoGen | 微软研究院 | 基于异步对话的代理协作 | 灵活的多代理交互 | 配置复杂、调试困难 | 研究项目、复杂多代理系统 |
| CrewAI | - | 基于角色的多代理协作 | 直观的角色定义、工作流程控制 | 可扩展性有限 | 需要角色扮演的协作任务 |
| LlamaIndex Agents | - | 知识检索增强 | 出色的文档处理和检索 | 专注于RAG而非通用代理 | 知识密集型应用、文档处理 |

Strands在这个竞争激烈的市场中的差异化优势主要体现在以下几个方面：

Strands采用了极其简洁的API设计，让开发者能够用最少的代码实现功能完备的代理。相比需要大量样板代码的框架，Strands的学习曲线更平缓，上手更快。一个典型的Strands代理只需不到10行代码就能实现，而其他框架可能需要数十甚至上百行。

在错误处理方面，Strands实现了多层次的稳健性保障。它能够自动处理模型API的临时错误，实现智能重试；能够管理上下文长度，防止token溢出；还能处理工具执行异常，提供友好的错误信息。这些特性在生产环境中尤为重要，可以显著减少运维负担。

与AWS服务的深度集成是Strands的另一大优势。代理可以直接使用IAM角色访问AWS资源，无需管理额外的凭证；可以将执行轨迹和指标发送到CloudWatch进行监控；还可以利用AWS Lambda的按需计算特性实现经济高效的运行。这种"云原生"设计对于已经采用AWS的组织特别有吸引力。

## 实际应用场景与成功案例

Strands已经在各种实际应用场景中证明了其价值和适用性。以下是几个详细的案例研究：

### 案例1：Amazon Q Developer 智能编程助手

Amazon Q Developer团队使用Strands构建了智能编程助手，帮助开发者解决复杂的编码问题。这个助手能够：

- 理解用户的编程问题并分解为可管理的子任务
- 搜索AWS文档和开源代码库获取相关信息
- 生成符合最佳实践的代码解决方案
- 解释代码工作原理并提供学习资源

关键技术实现：
```python
# 编程助手代理示例
from strands import Agent
from strands.tools.mcp import MCPClient
from strands_tools import python_repl, http_request

# 加载AWS文档查询工具
aws_docs_tools = MCPClient(lambda: stdio_client(
    StdioServerParameters(command="uvx", args=["aws-documentation-mcp-server"])
))

# 组合多个工具创建编程助手
with aws_docs_tools:
    coding_assistant = Agent(
        system_prompt="""你是Amazon Q Developer助手，专注于帮助开发者解决AWS相关的编程问题。
        遇到AWS服务问题时，请查询官方文档；需要编写代码时，请使用Python REPL测试代码。
        始终提供清晰的解释和工作示例。""",
        tools=aws_docs_tools.list_tools_sync() + [python_repl, http_request]
    )
```

### 案例2：多代理金融顾问系统

一家金融科技公司使用Strands构建了多代理金融顾问系统，包括投资研究、预算规划和退休规划三个专业代理，由一个协调代理管理工作流。系统架构如下：

```python
from strands import Agent

# 专业化代理定义
def create_investment_advisor():
    return Agent(
        model="anthropic.claude-3-sonnet-20240229-v1:0",
        system_prompt="你是投资研究专家，提供基于数据的投资建议和市场分析...",
        tools=[stock_analysis, market_data, portfolio_optimization]
    )

def create_budget_advisor():
    return Agent(
        model="amazon.titan-text-express-v1",
        system_prompt="你是预算优化专家，帮助用户分析支出并提高储蓄率...",
        tools=[expense_analysis, budget_planning, saving_calculator]
    )

def create_retirement_planner():
    return Agent(
        model="anthropic.claude-3-haiku-20240307-v1:0",
        system_prompt="你是退休规划专家，帮助用户制定长期财务目标...",
        tools=[retirement_calculator, tax_planning, estate_planning]
    )

# 将专业代理包装为工具
@tool
def consult_investment_advisor(query: str) -> str:
    """咨询投资顾问获取投资建议"""
    advisor = create_investment_advisor()
    return advisor(query)

@tool
def consult_budget_advisor(query: str) -> str:
    """咨询预算顾问获取预算优化建议"""
    advisor = create_budget_advisor()
    return advisor(query)

@tool
def consult_retirement_planner(query: str) -> str:
    """咨询退休规划师获取长期财务规划建议"""
    advisor = create_retirement_planner()
    return advisor(query)

# 创建协调代理
coordinator = Agent(
    model="anthropic.claude-3-sonnet-20240229-v1:0",
    system_prompt="""你是金融顾问协调员，负责理解客户的财务需求，
    并咨询适当的专家以提供全面的财务建议。根据问题性质决定咨询哪位专家。""",
    tools=[consult_investment_advisor, consult_budget_advisor, consult_retirement_planner]
)
```

这个系统的关键优势在于模块化设计和专业化分工。协调代理负责理解用户需求并将子任务分配给专业代理，每个专业代理都配备了领域特定的工具和知识。这种设计使得系统能够提供全面而深入的财务建议，同时保持了可维护性和可扩展性。

### 案例3：AWS基础设施自动化代理

一个大型企业IT团队使用Strands构建了AWS基础设施自动化代理，帮助管理员设计和部署云资源。这个代理能够：

- 根据自然语言需求描述生成架构图
- 转换架构设计为CloudFormation或Terraform代码
- 估算部署成本并提供优化建议
- 执行安全最佳实践检查

值得注意的是，这个代理利用了Strands与MCP(Model Context Protocol)服务器的集成，实现了代码生成和图表创建等复杂功能：

```python
from strands import Agent
from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters

# 加载AWS图表生成工具
diagram_tools = MCPClient(lambda: stdio_client(
    StdioServerParameters(command="uvx", args=["aws-diagram-mcp-server"])
))

# 加载CloudFormation代码生成工具
cfn_tools = MCPClient(lambda: stdio_client(
    StdioServerParameters(command="uvx", args=["aws-cloudformation-mcp-server"])
))

# 创建基础设施自动化代理
with diagram_tools, cfn_tools:
    infrastructure_agent = Agent(
        system_prompt="""你是AWS基础设施专家，帮助设计和实现云架构解决方案。
        需要时生成架构图，并创建对应的CloudFormation模板。
        始终考虑成本优化、安全性和可扩展性。""",
        tools=diagram_tools.list_tools_sync() + cfn_tools.list_tools_sync()
    )
```

## DipperAI：一个未能实现的愿景

在AWS Strands出现之前，我曾经和小伙伴们有一个名为DipperAI的开源项目，其愿景与Strands有着惊人的相似之处。DipperAI起始于模型即服务(MaaS)的概念，旨在从简化对机器学习模型的访问和使用开始，帮助开发者快速构建 AI 应用，当然这里包括如何构建 Agent，如何构建 AI 相关的业务 API 等。

### DipperAI的技术架构与目标（前期）

DipperAI采用无服务器架构，让开发者能够直接从Hugging Face和ModelScope等模型库中调用预训练模型，无需下载、部署或维护这些模型。其核心API设计非常简洁：

```python
from dipperai.maas import Modelscope, HuggingFace

# 使用ModelScope模型进行图像校正
model_url = "https://modelscope.cn/models/iic/cv_resnet18_card_correction/summary"
result = Modelscope(model_url).invoke("image_url_or_path")

# 使用Hugging Face模型进行文本摘要
model_url = "https://huggingface.co/facebook/bart-large-cnn"
summary = HuggingFace(model_url).invoke("需要摘要的长文本...")
```

这种设计理念与Strands的简洁API风格高度一致，都致力于通过几行代码就能访问强大的AI能力。DipperAI的无服务器架构也与Strands的部署模型相似，都采用了函数即服务(FaaS)的方式，实现按需计算和自动扩展。

### DipperAI的技术架构与目标（预期）

在DipperAI的发展蓝图中，基础MaaS层仅是一个起点，其长远目标远不止于此。之前我曾规划了一条从模型调用到全功能AI开发平台的清晰演进路径，包含多个阶段性目标和技术突破点。

首先，DipperAI计划构建一个综合性的模型注册与发现系统。这个系统不仅能连接现有模型库，还将提供智能化的模型选择建议，根据开发者描述的任务需求，自动推荐最适合的模型和参数配置。这种"模型即匹配"的理念旨在解决AI开发中的一个关键痛点：在海量模型中选择最适合特定任务的一个。

在代理构建方面，DipperAI本来计划引入一个名为"智能体工作台"(Agent Workbench)的开发环境，提供可视化的代理设计、测试和部署工具。这一环境将允许开发者通过直观的界面构建代理，同时自动生成对应的代码，大大降低企业采用AI代理技术的门槛。这种低代码/无代码的方法特别适合领域专家和业务分析师，使他们能够不依赖专业开发团队就创建专业AI应用。

与Strands相比，DipperAI的技术路线有一个显著差异：它计划从一开始就支持多云和混合云部署，不局限于特定云平台。这种设计选择反映了对企业IT环境多样性的尊重，以及对技术开放性的坚持。DipperAI希望成为一个真正云中立的平台，让企业能够根据自身需求选择最适合的部署环境，而不必担心供应商锁定问题。

在性能优化方面，DipperAI设想了一个智能的资源调度系统，能够根据任务特性和预算约束，自动选择最佳的执行环境和计算资源。例如，对于实时性要求高的任务，系统可能选择GPU加速；而对于批处理任务，则可能选择更经济的CPU资源。这种智能调度将极大提高资源利用效率，降低AI应用的运营成本。

DipperAI还计划构建一个丰富的预构建组件库，包括常见的数据处理管道、模型适配器和应用模板。这些组件将大幅缩短开发周期，让开发者能够专注于业务逻辑而非技术细节。组件库将涵盖多个垂直领域，如金融、医疗、零售和制造业，为各行业提供定制化的AI解决方案。

### 两个项目的技术共性与差异

尽管DipperAI与AWS Strands SDK诞生于不同背景，但在技术理念和架构设计上呈现出惊人的相似性，同时也各自体现了独特的技术侧重和发展路径。这种共性与差异的并存，恰好反映了AI开发工具演进的必然趋势与多元可能性。

| 特性 | DipperAI | Strands |
|------|----------|---------------|
| 核心起点 | 模型即服务(MaaS)，专注简化模型访问和调用 | 代理构建框架，直接提供端到端的智能代理构建能力 |
| 部署架构 | 无服务器架构，按需计算，自动扩展，资源高效利用 | 无服务器架构，与AWS Lambda、Fargate等服务深度集成 |
| API设计 | 简洁的函数式接口，以URL直接调用模型，极低的入门门槛 | 面向对象的Agent类设计，简单几行代码即可创建完整代理 |
| 模型来源 | 专注开源模型生态，优先支持HuggingFace、ModelScope等公共模型库 | 优先支持AWS Bedrock、Claude等商业云服务模型，同时兼容开源模型 |
| 代码风格 | Python原生，遵循函数式和声明式编程范式 | Python原生，结合面向对象和装饰器模式 |
| 工具集成 | "All APIs for Agent"概念，计划将各种功能模块化为API | 成熟的工具装饰器系统，支持Python函数、API和MCP服务作为工具 |
| 云平台策略 | 多云支持愿景，计划实现云平台中立的部署能力 | AWS优先战略，与AWS服务紧密集成，提供无缝体验 |
| 社区定位 | 开源社区驱动，计划广泛吸纳社区贡献 | AWS官方支持，结合开源社区和企业资源优势 |
| 技术成熟度 | 概念验证阶段，基础功能实现 | 成熟产品，已在多个AWS服务中应用 |
| 可观察性 | 计划中的日志和监控功能 | 完整的OpenTelemetry集成，生产级遥测能力 |

这两个项目在技术路线上的根本差异体现在发展方向上。DipperAI采取了"自下而上"的方法，从解决模型访问这一基础问题开始，计划逐步构建起完整的代理开发栈。这种方法的优势在于能够为开发者提供更灵活的底层控制和更广泛的模型选择。特别是在开源模型日益丰富的今天，DipperAI的方法可能更好地满足那些希望充分利用开源AI生态系统的开发者需求。

相比之下，Strands采用了"自上而下"的策略，直接从代理构建框架切入，提供了开箱即用的端到端解决方案。这种方法能够让开发者更快地实现复杂的代理功能，而无需深入理解底层模型交互细节。Strands的设计特别适合那些希望快速部署生产级AI代理，并与AWS生态系统紧密集成的企业用户。

两者在实现哲学上也有微妙差异。DipperAI的设计理念更加开放和中立，计划支持多种云平台和模型提供商，体现了开源社区的普遍价值观。而Strands虽然也是开源项目，但其设计明显优先考虑了与AWS服务的集成，反映了其作为云厂商开发工具的定位。

然而，尽管起点和侧重点不同，两个项目在核心技术理念上却高度一致：都采用无服务器架构、简洁API设计和Python原生开发体验，都致力于降低AI开发门槛，都认识到了工具集成对于构建实用代理的重要性。这种一致性表明，无服务器AI开发已经成为行业共识，代表了未来AI应用开发的主流方向。

如果DipperAI能够继续发展，它可能会沿着原定路线，逐步构建起从模型调用到代理开发的完整技术栈，最终在功能上与Strands趋同，但保持其多云支持和开源模型优先的独特优势。这两个项目的共存将为开发者提供更丰富的选择，推动AI开发工具生态的多元化和繁荣。

### DipperAI未完成的遗憾与启示

遗憾的是，由于我从阿里离职，DipperAI未能继续发展，这个充满潜力的项目被迫中断。如果能够持续推进，DipperAI可能会发展出一套与Strands不同但同样强大的AI开发生态。

> 人生会充满一些不确定性和遗憾，期待为了平安顺遂，少些遗憾，多些自豪。

DipperAI可能会更加关注开源模型生态系统，为开发者提供一个与特定云平台无关的解决方案。它可能会引入独特的创新，如更深入的模型注册和版本管理、更灵活的多云部署策略或针对边缘设备的优化。这些可能性虽然未能实现，但其背后的思想仍然有价值。

DipperAI的未完成旅程提醒我们技术发展中的偶然性和必然性。偶然的是，一个有潜力的项目因为外部因素而中断；必然的是，相似的技术理念最终会以不同的形式实现。AWS Strands的成功某种程度上验证了DipperAI最初愿景的合理性，证明了无服务器AI代理确实是一个有前景的技术方向。

## 技术融合与未来展望

随着大型语言模型能力的持续提升，基于模型驱动的代理框架将进一步简化AI应用的开发流程。展望未来，我们可以预见几个可能的发展趋势：

AI代理框架将越来越关注垂直领域的专业化，为特定行业和应用场景提供优化的工具和模板。例如，医疗代理可能会集成电子健康记录系统和医学知识库；金融代理可能会提供市场数据分析和风险评估工具；教育代理则可能专注于个性化学习路径生成和知识评估。

多代理协作将成为重点研究方向，使得复杂任务能够通过多个专业化代理的协同工作来完成。这种协作可能采用不同的模式，如层次结构（协调者和执行者）、平等协商（代理之间相互讨论）或市场机制（代理竞标任务）。Strands已经开始支持这些协作模式，并计划进一步加强相关功能。

代理的可解释性和可控性将获得更多关注，以满足企业对透明度和合规性的要求。这包括详细的执行轨迹记录、决策过程可视化、安全guardrails实现和人类反馈机制。这些特性对于在监管严格的行业（如金融、医疗和法律）部署AI代理尤为重要。

在这些趋势下，像Strands这样的框架将继续演进，吸收开源社区的贡献并适应新的应用需求。同时，我们也期待看到DipperAI的理念以新的形式重生，或者由其他项目承接其未完成的使命。

## 总结

AWS Strands SDK代表了AI代理开发的一个重要里程碑，它通过模型驱动方法和无服务器架构的结合，大幅降低了构建智能应用的技术门槛。通过深入研究Strands的技术特性和应用场景，我们不仅看到了它在当前市场中的价值，也能从中获得对AI开发未来趋势的洞察。

同时，DipperAI的未完成旅程提醒我们技术发展往往由不同路径汇聚到相似的解决方案。DipperAI与Strands在理念上的共鸣表明，无服务器AI已经成为行业共识，只是实现路径和具体形式各有不同。

在AI技术快速迭代的今天，我们每个人都期待看到更多创新项目的出现，它们将共同塑造智能应用的未来。无论是像Strands这样的云厂商主导项目，还是像DipperAI这样的社区驱动倡议，每一个尝试都推动着技术边界的扩展，让AI的力量真正惠及更广泛的开发者和用户群体。

扫描二维码推送至手机访问。

本文链接：https://runor.cn/?id=13

标签: AWS Strands SDK AI代理无服务器架构模型驱动开发云原生应用

分享给朋友：

返回列表

没有更早的文章了...

下一篇：运维聊天机器人实践：用AI解决日常痛点

“AWS Strands SDK 技术调研报告：AI 代理开发的新范式与未竟之路” 的相关文章

运维聊天机器人实践：用AI解决日常痛点

运维工作说起来复杂，其实很多时候就是在解决重复性问题。每天都有人问同样的操作流程，每周都要查找相似的文档，每个月都要处理类似的告警。随着云服务越来越多，团队协作越来越频繁，这些”小事”累积起来，占用了大量本应用于技术优化的时间。最近我开发了一个基于飞书和Dify的运维机器人，尝试用AI来解决这些...

刘博说云

大家都在搜：

AWS Strands SDK 技术调研报告：AI 代理开发的新范式与未竟之路

“AWS Strands SDK 技术调研报告：AI 代理开发的新范式与未竟之路” 的相关文章

运维聊天机器人实践：用AI解决日常痛点

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

AWS Strands SDK 技术调研报告：AI 代理开发的新范式与未竟之路

“AWS Strands SDK 技术调研报告：AI 代理开发的新范式与未竟之路” 的相关文章

运维聊天机器人实践：用AI解决日常痛点

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论