首页 › ai-agents › 六大Agent框架人机审批门控实战拆解

六大Agent框架人机审批门控实战拆解

概述

当AI Agent从原型走向生产,第一个必须跨越的鸿沟不是性能,而是信任。2026年的Agent开发实践证明:没有任何一个生产级Agent系统可以在零人工监督下安全运行。人机审批门控(Human-in-the-Loop Approval Gate)不再是可选项——它是区分"demo"和"产品"的分水岭。本文深度拆解LangGraph、CrewAI、OpenAI Agents SDK、Google ADK、Microsoft Agent Framework和AWS Strands六大框架的人机协作审批机制,从架构原理、代码实现到生产陷阱逐层剖析,给出不同场景下的最佳选择路径。

六大框架审批门控对比总览

维度 LangGraph CrewAI OpenAI Agents SDK Google ADK MAF (微软) AWS Strands
核心原语 interrupt() + Command(resume=) human_input=True Runner callbacks before_tool_callback AG-UI ApprovalActivity Tool callback gates
控制粒度 节点级/条件级 Task级 Agent级+Tool级 6类Callback Activity级 Tool级
状态持久化 内置Checkpointer Memory层 外部Store Session Service durable state Bedrock AgentCore
异步支持 原生async 有限 原生streaming 原生async AG-UI协议 原生async
审批超时 自定义 无内置 无内置 自定义 内置超时策略 自定义
多审批人 支持(状态路由) 不支持 需自行实现 通过路由实现 原生支持 需自行实现
审批可观测 LangSmith集成 基础日志 Trace集成 Cloud Logging Application Insights CloudWatch
学习曲线 中高 低 中 中 高 中低
语言支持 Python/JS Python Python/JS Python/Java/Go C#/Python/JS Python/TS

深度分析

一、LangGraph:状态图中断恢复模型

LangGraph的人机审批设计理念源自状态机中断(State Machine Interrupt)模式——在图的任意节点执行前插入中断点,将当前状态快照持久化到Checkpointer,等待人类决策后从断点恢复执行。

架构原理:LangGraph的interrupt()函数在节点内部调用时,会将整个图的State冻结到持久化层(PostgreSQL、SQLite或MemorySaver)。当人类通过Command(resume=<value>)响应后,图从断点恢复,中断函数返回人类提供的值,继续后续节点执行。这意味着审批逻辑可以嵌入到图的任意位置,实现极其精细的门控。

from langgraph.types import interrupt, Command
from langgraph.graph import StateGraph, START, END

def approve_purchase(state):
    """在执行购买前请求人类审批"""
    # 将审批信息呈现给人类
    decision = interrupt({
        "question": f"是否批准购买 {state['item']},金额 ${state['amount']}?",
        "options": ["approve", "reject", "modify"]
    })
    # decision 来自人类的恢复输入
    if decision == "reject":
        return {"status": "cancelled", "reason": "human_rejected"}
    return {"approved": True, "modifier": decision}

def execute_purchase(state):
    if not state.get("approved"):
        return {"status": "skipped"}
    # 执行实际购买逻辑
    return {"status": "completed", "order_id": "ORD-12345"}

graph = StateGraph(PurchaseState)
graph.add_node("approve", approve_purchase)
graph.add_node("execute", execute_purchase)
graph.add_edge(START, "approve")
graph.add_edge("approve", "execute")
graph.add_edge("execute", END)

# 使用持久化后端
checkpointer = SqliteSaver.from_conn_string("checkpoints.db")
app = graph.compile(checkpointer=checkpointer)

# 第一次运行 —— 在审批节点中断
result = app.invoke(
    {"item": "GPU集群", "amount": 50000},
    config={"configurable": {"thread_id": "tx-001"}}
)
# result 中包含 interrupt 信息

# 人类审批后恢复
for event in app.stream(
    Command(resume="approve"),
    config={"configurable": {"thread_id": "tx-001"}}
):
    print(event)

优点:控制粒度最细——可以在任意节点、任意条件分支插入审批;状态持久化内置,崩溃后可恢复;支持多轮审批和复杂审批路由(如金额>$10k需要两级审批)。

缺点:学习曲线陡峭,需要理解StateGraph、Checkpointer、Command三套概念;调试中断-恢复流程不如同步代码直观;对于简单的"执行前问一句"场景显得过于重量级。

变现评估:LangGraph的HITL模式是企业级Agent系统的标配能力。可包装为"企业AI风控工作流训练营",面向金融、医疗等高合规行业。单个训练营售价可定在¥2999-5999。

二、CrewAI:任务级人类输入标记

CrewAI走了一条完全不同的路——声明式标记。在Task定义时标注human_input=True,Agent执行到该任务时会暂停并等待人类在终端输入。这种方式极其简单,但代价是精细控制力的缺失。

架构原理:CrewAI的执行引擎在遇到标记了human_input=True的Task时,会将Agent的中间输出通过CLI呈现给人类,等待键盘输入后继续。整个过程是同步的、阻塞的,没有持久化保证——如果进程崩溃,未保存的审批状态会丢失。

from crewai import Agent, Task, Crew, Process

reviewer = Agent(
    role="合同审核员",
    goal="审核合同条款并标识风险",
    backstory="你是一名资深法律顾问",
    llm="gpt-4o"
)

# 关键:human_input=True 触发人类审批
review_task = Task(
    description="审核以下合同并给出修改建议:{contract_text}",
    expected_output="修改建议清单",
    agent=reviewer,
    human_input=True  # 执行到此任务时暂停,等待人类输入
)

finalizer = Agent(
    role="合同定稿员",
    goal="根据审核意见生成最终合同",
    backstory="你负责将审核意见落地到合同文本",
    llm="gpt-4o"
)

finalize_task = Task(
    description="根据审核意见修改合同",
    expected_output="最终合同文本",
    agent=finalizer
)

crew = Crew(
    agents=[reviewer, finalizer],
    tasks=[review_task, finalize_task],
    process=Process.sequential
)

result = crew.kickoff(inputs={"contract_text": "..."})

优点:上手极快,一行代码human_input=True即可实现基础审批;与CrewAI的Role-Task-Crew抽象无缝集成;适合快速原型和内部工具。

缺点:仅支持Task级粗粒度控制——要么整个任务需要审批,要么不需要;同步阻塞模型,无法实现异步审批流;无内置状态持久化,进程中断等于审批丢失;不支持多审批人路由。

变现评估:CrewAI的HITL适合中小团队快速构建内部Agent工具。可作为"AI Agent快速原型实战课"的一部分,面向非技术背景的产品经理和运营人员。课程定价¥999-1999。

三、OpenAI Agents SDK:Runner回调审批模型

OpenAI Agents SDK在2026年3月发布后迅速成为生产级Agent系统的热门选择。其HITL机制通过Runner回调实现——在Agent运行器的配置中注册on_tool_call回调,在工具执行前拦截并请求人类审批。

架构原理:SDK的Runner在执行Agent循环时,每次遇到Tool Call都会先通过回调询问是否放行。回调函数返回Approve、Reject或Modify决策。SDK还支持沙箱执行(Code Interpreter在隔离环境中运行),审批可以在工具调用级别精确控制。

from agents import Agent, Runner, RunConfig, ToolCallApproval
from agents.items import ToolCallItem

async def approval_callback(tool_call: ToolCallItem, context):
    """在工具执行前请求人类审批"""
    tool_name = tool_call.raw_item.function.name
    args = tool_call.raw_item.function.arguments

    # 高风险工具需要人类审批
    HIGH_RISK_TOOLS = {"execute_trade", "send_email", "delete_record"}

    if tool_name in HIGH_RISK_TOOLS:
        print(f"[审批请求] 工具: {tool_name}")
        print(f"  参数: {args}")
        decision = input("批准?(y/n/m=修改): ").strip().lower()

        if decision == "y":
            return ToolCallApproval.APPROVE
        elif decision == "m":
            new_args = input("输入修改后的参数: ")
            return ToolCallApproval.MODIFY(args=new_args)
        else:
            return ToolCallApproval.REJECT

    return ToolCallApproval.APPROVE  # 低风险工具自动放行

trade_agent = Agent(
    name="交易助手",
    instructions="帮助用户执行股票交易",
    tools=[execute_trade, get_portfolio, analyze_risk]
)

config = RunConfig(
    tool_call_approval_callback=approval_callback,
    max_turns=10
)

result = await Runner.run(
    trade_agent,
    messages=[{"role": "user", "content": "买入100股AAPL"}],
    run_config=config
)

优点:API设计干净,回调模式对开发者友好;与OpenAI的沙箱执行环境无缝集成;支持MCP协议的工具审批(HostedMCPTool);2026年4月更新后增加了原生sandbox执行,安全性进一步提升。

缺点:深度绑定OpenAI模型生态;回调模式在多Agent协作时需要为每个Agent单独配置;缺少内置的审批历史审计日志。

变现评估:OpenAI Agents SDK的HITL适合构建SaaS级Agent产品。可包装为"AI Agent产品化实战训练营",聚焦从原型到生产的全流程。定价¥3999-7999。

四、Google ADK:六类回调拦截模型

Google ADK(Agent Development Kit)在2026年4月发布1.0稳定版,其HITL设计最为系统化——提供了6类回调钩子(before/after × agent/model/tool),覆盖Agent执行生命周期的每一个关键节点。

架构原理:ADK的回调系统分为三层——Agent层(before_agent/after_agent)、模型层(before_model/after_model)、工具层(before_tool/after_tool)。开发者可以在任意层插入审批逻辑。before_tool_callback是最常用的审批门控点,返回google.adk.models.types.Content可以替换工具输出,返回None则放行。

from google.adk.agents import LlmAgent
from google.adk.models.types import Content, Part

async def approve_financial_tools(callback_context, tool_call):
    """在金融工具执行前拦截并审批"""
    tool_name = tool_call.function.name
    args = tool_call.function.args

    FINANCIAL_TOOLS = {"transfer_money", "approve_loan", "execute_trade"}

    if tool_name not in FINANCIAL_TOOLS:
        return None  # 非金融工具自动放行

    # 构建审批请求并发送给审批系统
    approval_request = {
        "tool": tool_name,
        "args": args,
        "requester": callback_context.agent_name,
        "timestamp": callback_context.invocation_id
    }

    # 调用企业审批系统API
    decision = await call_approval_system(approval_request)

    if decision["status"] == "approved":
        callback_context.state["approval_id"] = decision["approval_id"]
        return None  # 放行
    else:
        # 返回拒绝信息作为工具输出
        return Content(
            parts=[Part(text=f"审批被拒绝:{decision['reason']}")],
            role="model"
        )

banking_agent = LlmAgent(
    name="银行助手",
    model="gemini-2.5-pro",
    instruction="帮助客户处理银行业务",
    tools=[transfer_money, approve_loan, get_balance],
    before_tool_callback=approve_financial_tools
)

优点:6类回调覆盖最全面的生命周期钩子;与Google Cloud生态(Vertex AI、Cloud Logging)深度集成;支持Python、Java、Go三种语言;回调返回值可以完全替换工具输出,灵活性极高。

缺点:6类回调的组合使用增加了心智负担;回调地狱风险——多层回调嵌套可读性差;企业审批系统集成需要自行实现。

变现评估:Google ADK适合Google Cloud生态企业。可包装为"Google Cloud AI Agent企业级开发认证培训",面向使用GCP的企业开发团队。定价¥4999-9999。

五、Microsoft Agent Framework:AG-UI协议审批模型

Microsoft Agent Framework(MAF)在2026年2月将Semantic Kernel和AutoGen合并为一个统一框架,4月发布1.0 GA版本。其HITL机制基于AG-UI协议——一个专为人机协作设计的通信协议,支持多种审批Activity类型。

架构原理:MAF将人机交互建模为AG-UI协议中的Activity。ApprovalActivity是核心审批原语——Agent在需要人类决策时发出ApprovalActivity,AG-UI运行时将Activity路由到对应的人类审批界面(可以是Web UI、Teams Bot或自定义应用)。人类响应后,Activity结果回传给Agent继续执行。整个过程支持超时策略、多审批人路由和审批历史审计。

// C# 示例 —— MAF + AG-UI 审批模式
using Microsoft.AgentFramework;
using Microsoft.AgentFramework.Activities;

public class InvoiceApprovalAgent : Agent
{
    [AgentTool("提交发票审批")]
    public async Task<ApprovalResult> SubmitForApproval(
        Invoice invoice,
        AgentContext context)
    {
        // 创建审批Activity
        var approval = new ApprovalActivity
        {
            Title = $"发票审批:{invoice.Vendor} - ¥{invoice.Amount}",
            Description = invoice.Description,
            Approvers = DetermineApprovers(invoice.Amount),
            // 金额 > ¥50000 需要两级审批
            ApprovalLevels = invoice.Amount > 50000 ? 2 : 1,
            Timeout = TimeSpan.FromHours(24),
            Data = new Dictionary<string, object>
            {
                ["invoice_id"] = invoice.Id,
                ["amount"] = invoice.Amount,
                ["vendor"] = invoice.Vendor
            }
        };

        // 发出审批请求,阻塞等待结果
        var result = await context.WaitForApprovalAsync(approval);

        return result.Status switch
        {
            ApprovalStatus.Approved => new ApprovalResult { 
                Approved = true, 
                ApprovalId = result.ApprovalId 
            },
            ApprovalStatus.Rejected => new ApprovalResult { 
                Approved = false, 
                Reason = result.RejectionReason 
            },
            ApprovalStatus.Timeout => new ApprovalResult { 
                Approved = false, 
                Reason = "审批超时,已自动拒绝" 
            },
            _ => throw new InvalidOperationException()
        };
    }

    private List<string> DetermineApprovers(decimal amount) =>
        amount switch
        {
            > 100000 => new() { "CFO", "CEO" },     // 超大额:CFO + CEO
            > 50000  => new() { "CFO", "总监" },     // 大额:CFO + 总监
            _        => new() { "直属经理" }          // 普通额:直属经理
        };
}

优点:AG-UI协议是标准化的——不同UI前端(Web、Teams、桌面)通过同一协议与Agent通信;内置超时策略和多级审批路由;与Azure生态(Application Insights、Entra ID)深度集成;C#/Python/JS三语言支持。

缺点:框架复杂度最高——需要理解Agent、Activity、AG-UI协议三套概念;设置和部署流程较重,不适合轻量级场景;AG-UI协议相对新,社区生态还在建设中。

变现评估:MAF适合大型企业的Agent平台建设。可包装为"Microsoft AI Agent企业架构师认证培训",面向使用Microsoft技术栈的企业。定价¥6999-12999。

六、AWS Strands:模型驱动的工具门控

AWS Strands Agents SDK走了一条独特的模型驱动(Model-Driven)路线——Agent的行为完全由模型推理驱动,HITL通过工具回调实现。开发者定义的工具在执行前会经过回调检查,模型决定何时调用工具,回调决定是否放行。

架构原理:Strands的核心是一个循环——模型推理 → 工具选择 → 回调审批 → 工具执行 → 结果反馈。@tool装饰器标记的函数作为工具暴露给模型,在工具执行链中插入审批逻辑。Strands与Amazon Bedrock AgentCore集成,提供持久化执行和状态管理。

from strands import Agent, tool
from strands_tools import approval

@tool
def process_refund(order_id: str, amount: float, reason: str):
    """处理退款请求"""
    # 实际退款逻辑
    return {"status": "processed", "refund_id": f"REF-{order_id}"}

@tool  
def check_risk_level(amount: float) -> str:
    """评估退款风险等级"""
    if amount > 10000:
        return "HIGH"
    elif amount > 1000:
        return "MEDIUM"
    return "LOW"

# 定义审批策略
async def approval_gate(tool_name: str, tool_args: dict, context):
    """Strands的工具审批门控"""
    if tool_name == "process_refund":
        risk = await context.agent.call_tool(
            "check_risk_level", 
            {"amount": tool_args["amount"]}
        )

        if risk == "HIGH":
            # 高风险退款需要人类审批
            decision = await request_human_approval(
                title=f"高风险退款审批",
                details=f"订单: {tool_args['order_id']}, "
                       f"金额: ${tool_args['amount']}",
                approvers=["finance_lead"]
            )
            if not decision.approved:
                return {"status": "rejected", "reason": decision.reason}

    return None  # 放行

refund_agent = Agent(
    model="anthropic.claude-sonnet-4-20250514",
    tools=[process_refund, check_risk_level],
    system_prompt="你是退款处理助手,帮助客户处理退款请求",
    tool_approval_callback=approval_gate
)

result = refund_agent("客户要求退还订单 #12345 的 ¥15000")

优点:模型驱动设计哲学使得Agent行为更自然——模型自行决定何时需要工具、何时需要人类;与AWS Bedrock生态(Guardrails、AgentCore、Knowledge Base)无缝集成;学习曲线相对平缓。

缺点:模型驱动意味着审批逻辑的可预测性不如显式图模型(LangGraph);AWS生态绑定较深;工具级审批是唯一粒度,不支持节点级或条件级控制。

变现评估:Strands适合AWS生态企业构建生产Agent。可包装为"AWS AI Agent生产实战工作坊",面向AWS开发者。定价¥3999-7999。

架构总览:六种审批门控模型对比

graph TB
    subgraph "LangGraph: 状态图中断模型"
        LG1[Agent节点] -->|interrupt| LG2[状态快照持久化]
        LG2 -->|等待| LG3[人类审批]
        LG3 -->|Command resume| LG4[恢复执行]
    end

    subgraph "CrewAI: 任务级标记模型"
        CA1[Task执行] -->|human_input=True| CA2[CLI暂停]
        CA2 -->|键盘输入| CA3[继续下一Task]
    end

    subgraph "OpenAI SDK: 回调审批模型"
        OA1[Runner循环] -->|Tool Call| OA2[回调检查]
        OA2 -->|Approve/Reject| OA3[执行/跳过]
    end

    subgraph "Google ADK: 六类回调模型"
        GA1[Agent生命周期] --> GA2[before_agent]
        GA2 --> GA3[before_model]
        GA3 --> GA4[before_tool]
        GA4 -->|拦截决策| GA5[放行/替换/拒绝]
    end

    subgraph "MAF: AG-UI协议模型"
        MF1[Agent Activity] -->|ApprovalActivity| MF2[AG-UI路由]
        MF2 -->|多审批人| MF3[审批界面]
        MF3 -->|超时策略| MF4[结果回传]
    end

    subgraph "AWS Strands: 模型驱动模型"
        AS1[模型推理] -->|工具选择| AS2[回调门控]
        AS2 -->|放行| AS3[Bedrock执行]
        AS2 -->|拦截| AS4[人类审批]
    end

    style LG2 fill:#e1f5fe
    style CA2 fill:#fff3e0
    style OA2 fill:#e8f5e9
    style GA4 fill:#fce4ec
    style MF2 fill:#f3e5f5
    style AS2 fill:#fff8e1

生产级审批门控的五个隐藏陷阱

陷阱一:审批状态的持久化黑洞

LangGraph通过内置Checkpointer解决了这个问题,但其他框架几乎都依赖开发者自行实现持久化。CrewAI的human_input=True完全依赖进程存活——如果容器重启,未完成的审批全部丢失。生产建议:对CrewAI和OpenAI Agents SDK,必须外挂持久化层(Redis + 数据库),将审批状态在回调触发时写入持久存储。

陷阱二:审批超时与自动降级

人类审批不可能无限等待。MAF内置了超时策略(Timeout = TimeSpan.FromHours(24)),LangGraph可以通过条件边实现超时路由,但CrewAI、OpenAI SDK和Strands都没有内置超时机制。生产建议:为每个审批门设置超时时间,超时后自动降级为默认安全策略(如自动拒绝或升级给上级审批人)。

陷阱三:审批审计日志的缺失

金融、医疗等合规行业要求每次审批决策都有完整的审计追踪。MAF通过Application Insights天然满足;LangGraph + LangSmith可以实现;其他框架需要自行搭建审计日志系统。生产建议:无论使用哪个框架,审批审计日志应该作为非功能性需求的第一优先级。

陷阱四:多审批人路由的复杂性

当审批涉及多人时(如金额超阈值需要两级审批),只有LangGraph和MAF有原生支持。LangGraph通过状态路由实现多审批人流转;MAF的ApprovalLevels属性直接支持多级审批。其他框架需要开发者自行实现审批人路由和等待逻辑。

陷阱五:审批UI与Agent运行时的解耦

LangGraph的interrupt()将审批信息序列化为JSON,前端需要自行反序列并渲染审批表单;MAF的AG-UI协议标准化了审批Activity格式,前端框架可以统一处理。生产建议:在选型时评估是否有配套的审批UI组件库,否则需要投入大量前端开发成本。

场景推荐决策矩阵

graph LR
    START[需要HITL审批] --> Q1{审批复杂度?}
    Q1 -->|"简单:执行前确认"| CREW[CrewAI]
    Q1 -->|"中等:多条件门控"| Q2{云厂商绑定?}
    Q1 -->|"复杂:多级多审批人"| Q3{技术栈偏好?}

    Q2 -->|"OpenAI生态"| OPEN[OpenAI Agents SDK]
    Q2 -->|"Google Cloud"| ADK[Google ADK]
    Q2 -->|"AWS"| STRANDS[AWS Strands]
    Q2 -->|"云中立"| LANG[LangGraph]

    Q3 -->|".NET/Azure"| MAF[Microsoft Agent Framework]
    Q3 -->|"Python优先"| LANG2[LangGraph]

    CREW --> END1[快速原型/内部工具]
    OPEN --> END2[SaaS产品]
    ADK --> END3[GCP企业应用]
    STRANDS --> END4[AWS企业应用]
    MAF --> END5[大型企业平台]
    LANG --> END6[通用生产系统]
    LANG2 --> END6

    style CREW fill:#fff3e0
    style OPEN fill:#e8f5e9
    style ADK fill:#fce4ec
    style STRANDS fill:#fff8e1
    style MAF fill:#f3e5f5
    style LANG fill:#e1f5fe
    style LANG2 fill:#e1f5fe

场景一:初创团队快速验证

推荐:CrewAI → 升级到LangGraph

先用CrewAI的human_input=True在30分钟内实现基础审批,验证业务逻辑。产品验证后,迁移到LangGraph获得持久化和细粒度控制。迁移成本主要在State定义和图结构重构,核心Agent逻辑可以复用。

场景二:SaaS产品线

推荐:OpenAI Agents SDK

Runner回调模式与SaaS架构天然契合——回调可以接入Webhook,将审批路由到产品的通知系统。结合OpenAI的沙箱执行,安全性有保障。风险在于OpenAI模型绑定,建议在回调层做好模型抽象。

场景三:金融/医疗合规场景

推荐:LangGraph 或 MAF

金融场景需要多级审批、审计追踪、状态持久化三要素。LangGraph在这三点上通过Checkpointer + LangSmith + 条件路由可以完整覆盖;MAF通过AG-UI + Application Insights + ApprovalLevels同样满足。选择取决于团队的技术栈——Python优先选LangGraph,.NET/Azure优先选MAF。

场景四:Google Cloud企业

推荐:Google ADK

ADK的6类回调覆盖了Agent执行的全生命周期,配合Vertex AI的Model Garden和Cloud Logging,可以在Google Cloud生态内完成整个审批链路。唯一需要注意的是回调组合不要过于复杂,建议统一在一个回调函数内处理所有审批逻辑。

场景五:AWS企业

推荐:AWS Strands

Strands与Bedrock生态的深度集成(Guardrails、AgentCore、Knowledge Base)使得审批门控可以与AWS的安全基础设施协同工作。模型驱动的审批方式更自然,但需要额外的集成测试来确保模型在边界情况下正确触发审批。

核心结论

2026年的Agent框架在人机审批门控上已经从"有没有"进化到"怎么做更好"的阶段。LangGraph的状态图中断模型在灵活性和生产就绪度上仍然是标杆,但学习成本最高;CrewAI适合快速验证但需要自行补齐持久化和审计;OpenAI Agents SDK在SaaS场景中表现最佳;Google ADK的回调体系最全面但心智负担最重;MAF的企业级能力最强但复杂度也最高;AWS Strands的模型驱动哲学独特但可预测性稍弱。

选型的核心原则只有一个:审批门控的复杂度应该匹配业务风险等级。用CrewAI处理内部工具的低风险审批,用LangGraph或MAF处理金融级的高风险审批——不要用大炮打蚊子,也不要用弹弓打坦克。

参考来源

  1. LangGraph Human-in-the-Loop Patterns & Examples 2026 — LangGraph四种HITL模式的完整代码示例
  2. Human-in-the-Loop Approval Flow Pattern for AI Agents — Agent审批流的通用架构模式参考
  3. Google ADK Callbacks Documentation — ADK六类回调的官方文档
  4. Microsoft Agent Framework AG-UI Human-in-the-Loop — MAF审批Activity的官方指南
  5. OpenAI Agents SDK Running Agents Guide — OpenAI Agents SDK运行器和回调配置文档
  6. Strands Agents SDK — AWS Strands Agents SDK官方站点

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入