OpenAI Agents SDK 官方文档解析
是一款轻量级且强大的框架，帮助开发者构建“代理型”（agentic）的 AI 应用程序。这里的“代理”（Agent）指由大型语言模型（LLM）驱动、能够根据指令自主调用工具执行任务的智能体。OpenAI Agents SDK 基于去年推出的实验性代理框架Swarm，经过改进升级后已达到生产就绪级别。Agents（代理）：装备了明确指令和工具的 LLM，即智能代理，可以接受用户输入、调用工具并生
OpenAI Agents SDK 概述
OpenAI Agents SDK 是一款轻量级且强大的框架，帮助开发者构建“代理型”（agentic）的 AI 应用程序
。这里的“代理”（Agent）指由大型语言模型（LLM）驱动、能够根据指令自主调用工具执行任务的智能体。OpenAI Agents SDK 基于去年推出的实验性代理框架 Swarm，经过改进升级后已达到生产就绪级别
。它提供了极简的一组核心抽象，以降低上手难度，同时保留足够的功能性：
- Agents（代理）：装备了明确指令和工具的 LLM，即智能代理，可以接受用户输入、调用工具并生成回应 。
- Handoffs（交接）：代理之间的任务委派机制。一个代理可以将特定任务交接给另一个更合适的代理来处理 。
- Guardrails（护栏）：输入/输出校验机制，用于在执行过程中验证代理的输入或输出是否符合预期条件，从而提高安全性和可靠性 。
通过 Python 代码将上述原语组合使用，开发者能够搭建起复杂的工具与智能代理协作关系，实现真实世界应用，而无需陡峭的学习曲线
。此外，Agents SDK 内置了 Tracing（跟踪） 功能，可视化地记录代理运行流程，方便开发者调试、监控和优化代理的行为
。
总的来说，OpenAI Agents SDK 的目标是让构建多步骤、自主决策的 AI 代理变得简单高效。它抽象出了核心组件，提供默认实现开箱即用，同时允许开发者根据需求自定义底层行为
。
架构分析
体系结构：OpenAI Agents SDK 采用模块化的设计，由代理、工具、交接、护栏等模块共同构成代理应用的运行流程。每个 Agent（代理） 本质上是一个绑定了特定说明（指令集）和可用工具的 LLM 模型实例
。开发者在初始化代理时，可以为其指定：
name：代理名称（用于区分不同代理，调试时也方便识别）。instructions：代理的行为规范或系统提示。明确代理的身份和目标，使其在对话中遵循这些说明行事。tools：该代理可调用的工具清单，例如检索数据的函数、执行计算机操作的接口等。工具可以是OpenAI提供的内置工具（如网络搜索、文件检索、计算机操作等），也可以是开发者自定义的函数工具 。handoffs：可交接的其他代理列表。如果设置了交接对象，当前代理在任务超出自身职责或能力范围时可以将任务转交给列表中的另一个代理处理 。input_guardrails/output_guardrails：输入/输出护栏，用于在每次代理执行前后进行校验。例如，限制输入格式或内容、检查输出是否包含违规信息等 。
代理循环：Agents SDK 内置了**Agent Loop（代理循环）**机制
。当一个代理接收到用户输入时，框架会自动触发以下循环流程
：
- LLM决策：代理根据当前指令和对话上下文，由 LLM 模型生成下一步动作。这个动作可能是直接给出最终回答，也可能是调用某个工具或将任务交接给其他代理。代理自主规划如何完成任务——例如需要检索信息就调用搜索工具，需要计算就调用代码执行工具，或者需要更专业的处理就交接给特定代理 。
- 执行操作：如果 LLM 决定调用工具，Agents SDK 会根据代理输出识别所选工具，并自动执行对应的函数或API。执行结果（例如搜索到的信息或计算结果）会返回给代理。
- 结果反馈：执行结果被封装为Result对象，并反馈给同一代理的LLM，供其参考后决定下一步。例如，LLM 可以阅读工具返回的数据，再继续生成后续行动或最终答案 。
- 代理交接：如果代理决定将任务交接（handoff）给另一代理，Agents SDK 会在幕后将交接视为一种特殊的“工具调用”
。也就是说，LLM 输出一个调用类似
transfer_to_X_agent的指令，框架接收到这类指令后，会暂停当前代理，并启动目标代理，用原始任务或特定信息作为该代理的新输入 。交接使得不同专长的代理可以在同一工作流中协作。 - 循环迭代：上述过程会循环进行——代理持续生成动作，调用工具或交接代理，再获得结果——直到某个代理生成了最终输出（Final Output）表示任务完成。框架将该最终答复返回给调用方。
在每次循环迭代中，Agents SDK 都会并行运行预先配置的护栏校验。例如，可以对用户输入运行安全检查，或在工具执行后验证代理输出是否符合格式要求。一旦护栏检测到违规或错误，会及时中断流程，避免继续浪费资源或产生不良输出
。
多代理协作：Agents SDK 支持同时定义和运行多个代理，实现复杂任务的分工协作。架构上提供了两种主要的编排方式：
- LLM驱动的编排：让某个“调度代理”由 LLM 自主决定调用哪个工具或交接给哪个代理。这种方式利用了模型的推理能力，让 AI 自己规划任务流程 。例如，可以设置一个Triage Agent（分诊代理），它的职责就是根据用户问题决定是自己回答，还是交接给更合适的助手代理 。LLM驱动的优点是灵活智能，适合开放式的问题，但需要精心设计提示词确保决策可靠 。
- 代码驱动的编排：由开发者在程序中通过条件判断、循环等控制逻辑，显式地安排代理的运行顺序 。例如，可以先调用一个分类代理判断询问类型，然后在代码中根据分类结果选择调用哪个专项代理；或者串联多个代理的输出和输入，形成固定的流程链。代码驱动的优点是行为可预测、易于调试，在对性能和成本有明确要求时非常有用 。
开发者可以将上述两种编排模式结合使用，以发挥各自优势
。无论哪种方式，Agents SDK 都通过统一的 Runner 接口管理代理的运行。Runner 相当于调度器，提供方法如 Runner.run_sync() 来启动代理（或整个代理集群）处理输入，并跟踪整个任务流程的状态和结果。
可观察性与调试：架构中内置的**Tracing（跟踪）**系统在代理运行时记录每一步的详细信息，包括：哪个代理何时被调用、LLM产生了什么中间决策、调用了什么工具、工具返回了什么结果等等
。开发者可以通过这些追踪数据可视化代理的推理路径，方便地调试复杂的决策流程，找出可能的错误或低效步骤。此外，跟踪数据还能用于评估代理表现，配合 OpenAI 提供的评估工具和微调接口，不断改进代理的能力
。
主要功能详解
OpenAI Agents SDK 提供了一系列开箱即用的强大功能，概括如下
：
- Agent Loop（代理循环）：内置代理决策循环，引擎自动处理与 LLM 的对话循环、工具调用和结果传递，直到任务完成，无需开发者手动编写繁琐的循环逻辑 。这使得构建多步对话流程和工具交互变得简单直接。
- Python 优先：SDK 设计遵循“Python-first”原则，将复杂工作流的编排委托给惯用的 Python 代码来完成，而非引入新的DSL抽象 。开发者可以利用熟悉的控制结构（函数调用、条件判断、循环、并发等）来组织和串联多个代理的执行，而不是被限定在固定的框架流程内。
- Handoffs（代理交接）：提供强大的多代理协作能力，允许一个代理在需要时智能地将控制权转移给另一个代理
。通过交接机制，可以将复杂任务拆分给不同专长的代理各司其职，例如客服场景下根据客户需求在订单查询代理和退款处理代理之间切换。这种任务委派是通过特殊的工具调用实现的（例如代理输出
transfer_to_X指令） 。 - Guardrails（护栏校验）：可配置的安全检查与验证机制，并行于代理逻辑运行 。开发者可以为代理的输入和输出指定多个“护栏”规则（如正则校验、内容审核函数等）。在每次迭代时，护栏都会自动检测当前输入/输出是否符合规则要求，如有异常将提前中止流程 。这确保了代理在封装复杂工具时的安全性和健壮性。
- Function Tools（函数工具）：将任意 Python 函数快速封装为代理可用的工具
。只需通过装饰器或SDK提供的注册方法，Agents SDK 会自动生成工具的使用模式schema，并基于 Pydantic 对函数参数进行验证
。这意味着开发者无需手动编写额外包装代码，就能让 LLM 调用自定义函数，并确保输入输出类型正确。例如，上下文中的
@function_tool装饰器可将一个提交退款的Python函数直接变为代理可调用的submit_refund_request工具。 - Tracing & Observability（跟踪与可观测性）：内置完备的跟踪系统，能够实时记录并可视化代理工作流的每一步执行情况 。开发者可以借助这些数据调试代理决策路径、分析性能瓶颈。此外，Tracing 与 OpenAI 平台评估工具、模型微调工具集成，支持对代理行为的离线评估和持续优化 。这一可观测性功能对于构建复杂AI系统、在生产环境监控代理表现非常关键。
通过上述功能，Agents SDK 极大简化了构建多工具、多智能体AI应用的难度，开发者既可以利用默认逻辑迅速起步，又能根据需要深入定制各环节的行为。
使用方法（代码示例）
下面通过一些示例代码展示 OpenAI Agents SDK 的基本用法和进阶功能。
安装与环境准备
在使用 Agents SDK 之前，确保您的 Python 开发环境已经配置完毕。安装方法非常简单，只需通过 pip 安装最新的 openai-agents 软件包即可
：
bash
复制
pip install openai-agents
安装完成后，您需要配置 OpenAI API 密钥用于调用底层的模型接口。在终端中设置环境变量 OPENAI_API_KEY 为您的 API 密钥（或在代码运行前通过 openai.api_key 赋值）：
bash
复制
export OPENAI_API_KEY=<您的OpenAI_API_Key>
Hello World 示例
首先来看一个最简示例，创建一个只会遵循指令回答问题的单一代理，并运行之：
python
复制
from agents import Agent, Runner # 创建一个名为 "Assistant" 的代理，并赋予简单的身份指令 agent = Agent(name="Assistant", instructions="You are a helpful assistant") # 使用 Runner 来同步运行该代理，传入一个用户输入 result = Runner.run_sync(agent, "Write a haiku about recursion in programming.") # 打印代理产生的最终输出 print(result.final_output)
在上述代码中，我们通过 Agent(...) 创建了一个助手代理，指令是要求它充当“乐于助人的助手”。然后使用 Runner.run_sync(agent, input) 运行代理，传入用户请求（让它写一首关于递归的俳句）。最终结果保存在 result.final_output 中。按照默认设置，这个 Agent 会调用 OpenAI 的 GPT-4 模型生成回答。运行这段代码，代理应当返回一首简短的俳句作为结果
。
输出示例（可能略有不同）：
Code within the code,
Functions calling themselves,
Infinite loop's dance.
多代理与工具示例
下面的示例展示了一个稍复杂的场景：我们创建三个不同的代理并让它们协作完成用户请求。其中一个代理充当“分诊”角色，根据用户意图将问题分配给合适的专家代理。
python
复制
from agents import Agent, Runner, WebSearchTool, function_tool # 定义一个自定义函数工具，用于提交退款申请 @function_tool def submit_refund_request(item_id: str, reason: str): # 这里实现实际的退款处理逻辑 print(f"[模拟] 提交退款申请: 商品ID={item_id}, 原因={reason}") return "success" # 简化起见，假设调用成功并返回 "success" # 创建“客服&退货”代理，可调用退款函数工具 support_agent = Agent( name="Support & Returns", instructions="You are a support agent who can submit refunds and handle return requests.", tools=[submit_refund_request] # 将上面定义的函数注册为工具 ) # 创建“购物助理”代理，可调用网络搜索工具 shopping_agent = Agent( name="Shopping Assistant", instructions="You are a shopping assistant who can search the web for product info and recommendations.", tools=[WebSearchTool()] # 使用OpenAI内置的网络搜索工具 ) # 创建“分诊”代理，不直接使用工具，而是根据询问内容将任务交接给上述两个代理之一 triage_agent = Agent( name="Triage Agent", instructions="You are a triage agent. Route the user to the correct agent based on their request.", handoffs=[shopping_agent, support_agent] # 可以交接给购物助理或客服代理 ) # 模拟一次用户询问，由分诊代理开始处理，并自动分配给合适的代理 output = Runner.run_sync( starting_agent=triage_agent, input="I bought a pair of shoes from your store and they broke. Can I get a refund or a replacement?" ) print(output.final_output) # 打印最终由相应代理给出的答复
在这个示例中，我们演示了 Agents SDK 的多代理协作能力：
support_agent（客服代理）能处理退款相关请求，它通过工具列表注册了我们用@function_tool定义的submit_refund_request函数。因此，当LLM决定调用退款工具时，会触发执行该 Python 函数，把用户提供的商品ID和原因传入函数。 shopping_agent（购物助理代理）具有网络搜索能力，它的工具列表包含了WebSearchTool，这是OpenAI提供的内置工具之一，可以让代理主动在互联网上检索信息。该代理适合回答购物咨询类的问题。triage_agent（分诊代理）本身没有工具，但配置了可交接的代理列表（两个子代理）。当用户输入到来时，分诊代理会根据询问内容决定调用transfer_to_shopping_assistant或transfer_to_support_&_returns这样的“交接”指令 。Agents SDK 识别出这是交接操作后，会将用户请求转发给对应的子代理处理。
通过 Runner.run_sync(starting_agent=triage_agent, ...) 启动流程后，Agents SDK 首先调用分诊代理的LLM判断用户意图。比如用户提及“鞋子坏了想退款”，分诊代理可能将任务交接给 support_agent。随后，support_agent 接管对话，根据指令它知道可以调用退款工具，于是LLM可能产生一个调用 submit_refund_request 工具的动作（携带商品ID和原因）。框架执行该函数工具，得到结果后再交由代理的LLM生成最终回复（例如告知用户已提交退款申请）。整个过程中，Agents SDK 自动管理了代理之间的切换和工具调用，无需我们手动协调各代理的运行顺序。
可以看到，借助 Agents SDK，我们用少量代码就实现了一个初步的多智能体协作应用。开发者只需关注定义代理的行为和工具，复杂的对话控制逻辑由 SDK 接管完成。
与其他 OpenAI API 的比较
OpenAI Agents SDK 本质上是构建在 OpenAI 模型 API 之上的一个客户端框架。它本身并不是提供新的基础模型能力，而是简化了调用 OpenAI 模型并让其以代理方式工作的流程。Agents SDK 当前能够兼容 OpenAI 提供的两种主要接口——Chat Completions API 和 Responses API，并推荐使用后者
。
-
Chat Completions API（聊天补全接口）: 这是 OpenAI 原有的对话模型接口，被广大开发者广泛采用。它适用于纯粹的对话或简单的函数调用场景。如果应用不需要用到复杂的内置工具，只是让模型根据提示产生回复，那么继续使用 Chat Completions 是完全可行的
。OpenAI 承诺将持续为该接口提供新模型和功能支持 。不过，需要注意 Chat Completions API 本身并不直接支持多轮工具调用或多智能体协作——开发者若想实现复杂代理逻辑，需要自行编写代码管理与模型的多次交互、解析模型输出来决定调用哪个工具等流程。 -
Responses API（响应接口）: 这是 OpenAI 新推出的通用接口，用于简化构建带有工具使用能力的 AI Agent。Responses API 可以看作是 Chat Completions 的超集，既保留了后者简单易用的对话生成方式，又内置了多工具调用和多轮交互的支持
。通过一次 Responses API 调用，模型就有能力在单个会话中多次调用各种内置工具（如网络搜索、文件查询、计算机操作等）并结合返回结果完成复杂任务 。这意味着对于许多需要调用工具的代理应用，开发者可以直接使用 Responses API 发起请求，让 OpenAI 的后台自动处理工具调用逻辑，减少了自行编排的复杂度。 Responses API 是 OpenAI 面向未来代理应用的重点发展方向，官方建议新项目优先采用该接口 。 -
Agents SDK 与上述 API 的关系: Agents SDK 并非替代 Chat Completions 或 Responses API，而是建立在它们之上，提供了更高层的工作流管理。简单来说，Agents SDK 调用 OpenAI 模型时，可以选择走 Chat Completions API 或 Responses API 接口。在SDK中，这体现在不同的模型适配器上：例如
。在代码中默认使用的是 Responses API（因其功能更丰富） 。不论底层用哪个API，Agents SDK 都为开发者封装了多轮对话、工具选择、结果处理的循环逻辑，大大简化了复杂应用的开发。因此，当需要构建多步骤、多工具的智能代理时，使用 Agents SDK 可以免去大量样板代码。反之，如果只是实现单轮问答或非常简单的功能，直接调用 Chat Completions 可能更加轻量。值得一提的是，Agents SDK 也支持接入其他模型提供商——只要其API格式类似于OpenAI的Chat Completion，即可通过自定义OpenAIChatCompletionsModel会通过 Chat接口调用模型，而OpenAIResponsesModel则通过 Responses接口调用ModelProvider适配，这使得框架具有一定的通用性 。
综上，Chat Completions API 仍适合无需复杂工具的传统对话应用，Responses API 则面向需要工具使用的更复杂任务，而 Agents SDK 提供了一个在客户端 orchestrate 这些对话与工具调用的高级抽象层，使多智能体协作和复杂流程控制更为容易
。在实践中，开发者可以根据需求混合使用：比如在 Agents SDK 中优先采用 Responses API 作为模型后端，以充分利用其工具能力和即将推出的新特性。
适用场景和最佳实践
典型应用场景：OpenAI Agents SDK 适用于各类需要自动化、多步骤处理的AI应用。根据官方介绍和早期用户案例，以下场景特别适合采用 Agents SDK 来实现：
- 客户支持自动化：例如客服助手根据客户提问自动在知识库查找答案、处理订单查询或退款请求等。这类场景常需要调用数据库/API查询或执行业务流程，Agents SDK 支持定义专门的客服代理并集成相应工具 。
- 多步骤研究：代理可以主动检索网页、查找资料，再综合整理成报告或答案。在学术研究、市场调研等场景下，代理通过网络搜索工具和文件检索工具完成信息收集，再输出结果 。
- 内容生成：例如写作助理、营销文案生成等。代理可以分步骤完成内容创作：先用一个代理搜集素材，另一个代理撰写初稿，再交由第三个代理润色审核 。
- 代码分析与审查：代理作为编程助手，能阅读代码片段、调用解释器执行测试或静态分析工具，然后给出优化建议或发现漏洞。这需要结合代码执行工具和GPT模型的分析能力。
- 销售线索挖掘：例如销售助理代理从公司内部数据库和网络资料中提取客户信息，整合生成销售建议 。又或者代理自动化执行网络调研，寻找潜在客户并整理要点，供销售团队跟进。
实际上，Agents SDK 的灵活性使其几乎适用于任何需要模型自主决策、多步骤任务执行的情境。早期已有企业使用该SDK实现创新应用，例如 Coinbase 在几小时内构建了 AgentKit，让AI代理能无缝与加密货币钱包和链上操作互动
；Box 则将网络搜索与内部数据查询结合，开发出能从企业内部文件和互联网中同步检索信息的智能助手
。这些案例表明，通过合理设计代理架构，Agents SDK 能在短时间内产出可用的原型，并具备扩展到生产环境的潜力
。
最佳实践：为了充分发挥 Agents SDK 的能力，在开发和部署代理应用时建议遵循以下实践策略：
- 在提示词设计上多下功夫。代理的行为极大受系统指令和示例的影响。确保明确告知代理有哪些工具可用、如何调用，限定其决策边界。例如可以在说明中包含使用工具的格式示例，提醒模型在需要时调用工具 。
- 持续监控迭代代理的表现。利用SDK的Tracing功能观察代理每一步的决策，找出可能的误判并改进提示或代码逻辑 。迭代开发是提升代理可靠性的关键——看到不理想的输出，就调整提示或工具配置再次尝试。
- 分工明确，职责单一。与软件工程的原则相似，单个代理不宜肩负过多不同职责。应根据任务类型拆分成多个专长代理，各自精通一块内容，再通过交接组合完成复杂任务 。例如将“检索信息”和“撰写报告”拆分给不同代理，它们通过交接配合，而非让一个通用代理包揽所有工作。
- 允许代理进行自我反思和改进。可以在工作流中引入反馈循环，如让代理生成初步答案后，再调用一个评估代理来审查反馈，然后让原代理据此改进答案，直到满足质量要求 。这种链式思考（Chain-of-Thought）和自我检视能提升复杂任务的完成质量。
- 运用**评估工具(Evals)**对代理进行定量测试 。OpenAI 提供了评估框架，可针对特定任务反复运行代理并衡量成功率或正确性。据此对代理策略进行数据驱动的优化，甚至可以收集代理对任务的执行记录用于进一步微调底层模型。
- 如果选择LLM自主规划流程，让模型决策下一步行动，要确保提供充分的信息和约束。如提示中清晰列出可用工具名称和用法，给出几个示例指导模型遇到不同情况时应如何选择动作。这降低了模型产生无效指令的概率 。
- 如果采用代码显式编排流程，可考虑一些常见模式：
- 利用结构化输出：让前一阶段代理以机器可读格式输出决定（例如输出JSON指示下一步属于哪种类别），然后在代码中解析决定结果，路由到相应的代理或操作 。这种方式提高了决策的确定性。
- 串联多个代理：将复杂任务拆解为固定顺序的子任务，在代码中依次调用不同代理处理，并将前一步的输出作为下一步的输入 。例如撰写博客可流水线式地分解为“主题研究 -> 提纲撰写 -> 内容生成 -> 校对改进”四个代理顺序执行。
- 引入评审循环：使用一个审查代理在每轮对主要代理的输出进行评价，如果不达标则让主要代理根据反馈重试
。通过在代码中设置
while循环反复调用，直到审查通过为止，以提高结果质量。 - 并行化独立任务：对于彼此独立的多个子任务，可以在代码中并发运行多个代理（例如使用 Python 的
asyncio.gather）以加速整体流程 。并行模式适用于需要汇总多个来源信息的场景。
通过以上最佳实践，开发者可以更有条理地设计 Agents SDK 驱动的应用，使代理的决策更可控、性能更高效、输出质量更可靠
。总结来说，要充分利用AI代理的智能，也要运用工程手段约束和指导它们，二者相辅相成，才能构建出在实际场景中稳健运行的代理系统。
未来发展方向
OpenAI 对 Agents SDK 的未来有着明确的规划和展望。官方认为，AI 代理将很快成为各行业工作流程中不可或缺的一部分，能够显著提升生产力
。为此，OpenAI 正在致力于搭建完善的代理开发平台，并计划从以下几个方面推进 Agents SDK 及相关生态的发展：
- 更深的集成与新工具：随着模型能力日益提升并变得更“agentic”（自主代理化），OpenAI 将在其API中引入更深入的集成功能。例如更紧密地结合代理框架与底层模型接口，使得调用模型、管理代理状态、工具使用变得更加顺畅 。同时，OpenAI 还会推出新的内置工具和能力，帮助开发者更轻松地将代理部署到真实环境并监控、评估其性能 。例如，未来可能在Responses API中增加对**代码执行（Code Interpreter）**等高级工具的支持，以及提供类似“线程（Thread）对象”这样的抽象来追踪多轮对话历史 。
- Node.js 等多语言支持：目前 Agents SDK 以 Python 实现为主，但官方已经表示将很快推出 Node.js 版本，方便 JavaScript/TypeScript 开发者使用相同的理念构建代理应用 。长期来看，不排除会有更多语言的 SDK 实现出现，逐步形成跨语言的 OpenAI 代理开发套件。
- 开放源代码与社区共建：Agents SDK 已作为开源项目发布在 GitHub，OpenAI 表示将继续以开源方式发展该框架，鼓励社区参与 。这意味着开发者可以深入研究源码、贡献代码和扩展插件，共同丰富 SDK 的功能。社区的优秀创意（例如更好的Prompt模板、定制的工具集成等）都有机会融入官方框架中。
- 完善的代理开发平台：最终，OpenAI 的目标是打造一个无缝衔接的代理开发与部署平台 。这涵盖从设计代理逻辑、调试优化、一键部署，到后续的监控评估和持续改进整个生命周期。Agents SDK 只是第一步——随着后续组件的推出（如托管的代理执行服务、Eval评估工具的改进、与Fine-tuning微调的联动等），开发者将能够在 OpenAI 平台上完成端到端的代理应用开发，而不需要东拼西凑不同的服务 。
总而言之，OpenAI 对 Agents SDK 寄予厚望，将其视为推动“自治智能体”普及的关键。随着官方不断投入开发新特性并整合更强大的模型和工具，我们可以期待 Agents SDK 在未来变得更加健壮、易用且功能多样。这将使开发者能够更从容地构建各种AI代理，让这些代理在各行各业中发挥价值
。 OpenAI 表示对代理技术的前景感到兴奋，并期待着开发者社区创造出更多创新的应用。现在正是加入这个浪潮的好时候——通过研究 Agents SDK 的文档和示例，动手构建属于您的 AI 代理，为未来的智能应用奠定基础。
中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。
更多推荐
18
0- 0
已为社区贡献1条内容
所有评论(0)