OpenAI Agents SDK轻量多智能体框架从 1 行代码到 5 分钟协作【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-pythonOpenAI Agents SDK 是 OpenAI 开源的轻量级多智能体框架把调 LLM → 解析工具调用 → 追加结果 → 再调这套繁琐循环封装成一次Runner.run()调用。如果你在找 OpenAI Agents SDK 教程最短路径是2 行命令装好8 行代码走通 3 个智能体的分派协作再花 10 分钟理解它替你干了什么。它解决了什么问题直接拿裸 API 写过 LLM 应用的人都懂这份痛每轮对话手工拼消息列表、手工解析工具调用的 JSON、手工判断要不要继续循环一旦多个智能体参与上下文管理更难捋。这个多智能体框架的定位就是把这个循环标准化成运行时你声明智能体、工具和交接关系循环、状态、追踪全由框架代劳。类比工厂车间LLM 是工人SDK 是流水线加质检岗你只需要提供岗位说明书instructions和工位tools。 环境准备两条命令跑起来Python 3.10 起步python -m venv .venv source .venv/bin/activate pip install openai-agents运行前先设置OPENAI_API_KEY环境变量。语音、Redis 会话、Docker 沙箱、经 litellm / any-llm 接入第三方模型等能力都拆成了可选依赖组按需加一个[extra]装上即可不用一次全装。 核心机制用大白话讲Agent一份岗位说明书。为什么存在同一个模型在不同任务下需要不同人设和权限总不能改代码。一个 Agent 就是一组角色配置——instructions岗位说明、tools手边工具、模型参数。像新员工入职档案框架照着它派活。Tool让模型从会说变会做。裸模型只能输出文本function_tool把普通 Python 函数变成模型可触发的工具参数解析、结果回填框架全包了。from agents import function_tool, Agent function_tool def get_weather(city: str) - str: return fThe weather in {city} is sunny. agent Agent(nameWeather, instructionsYou are a weather assistant., tools[get_weather])Handoff智能体之间的转接电话。为什么存在一个智能体不可能什么都会把所有人设塞进一条 prompt 只会互相打架。交接本质是一次特殊工具调用——当前智能体判断这事该别人管把会话上下文整体转给另一个智能体。像前台接线员她不回答技术问题只查分机号然后转接。Runner 运行循环追着要结果的项目经理。模型的回答经常不是最终答案而是工具调用。Runner.run()自动执行调模型 → 跑工具 → 回填 → 再调直到拿到最终输出或发生交接这个 while 循环你一行都不用写。️ 最小可用场景8 行代码走通语言分派最直观的多智能体协作场景是前台分派用户用不同语言提问前台先看语言再转给对应专员。import asyncio from agents import Agent, Runner spanish Agent(nameSpanish, instructionsOnly speak Spanish.) english Agent(nameEnglish, instructionsOnly speak English.) triage Agent(nameTriage, instructionsHand off to the Spanish or English agent based on the language of the users message., handoffs[spanish, english]) asyncio.run(Runner.run(triage, Hola, ¿cómo estás?))关键不在 API 参数而在两处接线思路其一分派智能体只转不答所以 instructions 必须写明 handoff 规则否则模型会自己用中文回答完交接链路根本不会触发其二专员智能体是挂进handoffs列表的这个列表就是分派者的分机号簿——将来加一个德语专员只改列表不动其他逻辑。上图就是这类协作的运行结构Triage Agent 是入口工具如 get_weather按需求挂在智能体身上交接后由对应专员接管对话。进阶能力一览Guardrails进出两道质检输入进模型前、输出离开前都可以做程序化校验不合格就拦下。适用于敏感信息、合规审查、必须禁止某类回答的场景。Sessions跨请求的记忆内置 SQLite、Redis、MongoDB、SQLAlchemy 等会话实现绑定后对话历史自动持久。适合长对话、有状态 API、多轮客服。Human in the loop给危险操作踩刹车工具调用可配置成暂停等待人审批批准后从断点续跑。适用于发邮件、下单、改生产数据这类有真实副作用的操作。Sandbox agent给智能体一个真实工位SandboxAgent让智能体在容器或本地沙箱里执行命令、改文件、跨任务保留状态详见 docs/sandbox_agents.md。Realtime 与 Voice从文字到打电话支持gpt-realtime实时语音智能体也提供语音识别 → 智能体 → 语音合成的完整语音管线。适用于电话客服、车载、语音助手类交互。⚠️ 上手避坑分派智能体抢着答题→ 它的 instructions 必须写明只做 handoff不要直接回答且每个专员的边界要写到Only speak Spanish这种程度模型看到能答就会答交接链不会触发。instructions 越堆规则越糟→ 按任务拆智能体一个 Agent 只干一件事提示词只写何时用哪个工具、参数怎么填常识留给模型别把员工手册塞进岗位说明。护栏等出事才补→ 输入护栏放入口、输出护栏放出口时机要在设计期定下来上线后补护栏要动架构成本翻几倍。首次运行报莫名其妙的 import 错误→ 多半是可选依赖没装litellm、redis、docker 等都不在基础包里对照 pyproject.toml 的[project.optional-dependencies]检查缺哪组。 适合谁、不适合谁适合想在 LLM API 之上快速搭多智能体原型客服分派、研究助手、代码代理并且要现成的追踪、状态与审批机制的团队。不适合流程是固定 DAG、每个节点输入输出严格确定的硬编排场景——那类工作流引擎更稳而这套框架的强项恰恰是模型自主决定下一步的动态循环。生态上两个扩展方向值得留意Sessions 可接 Redis 或关系数据库做生产级持久化长任务可配合 Temporal 做持久执行或用 Docker 沙箱把智能体整个隔离起来。完整 API 参考在 docs/ref/ 目录入门可以从 docs/quickstart.md 接着往下读。【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenAI Agents SDK：轻量多智能体框架，从 1 行代码到 5 分钟协作
OpenAI Agents SDK轻量多智能体框架从 1 行代码到 5 分钟协作【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-pythonOpenAI Agents SDK 是 OpenAI 开源的轻量级多智能体框架把调 LLM → 解析工具调用 → 追加结果 → 再调这套繁琐循环封装成一次Runner.run()调用。如果你在找 OpenAI Agents SDK 教程最短路径是2 行命令装好8 行代码走通 3 个智能体的分派协作再花 10 分钟理解它替你干了什么。它解决了什么问题直接拿裸 API 写过 LLM 应用的人都懂这份痛每轮对话手工拼消息列表、手工解析工具调用的 JSON、手工判断要不要继续循环一旦多个智能体参与上下文管理更难捋。这个多智能体框架的定位就是把这个循环标准化成运行时你声明智能体、工具和交接关系循环、状态、追踪全由框架代劳。类比工厂车间LLM 是工人SDK 是流水线加质检岗你只需要提供岗位说明书instructions和工位tools。 环境准备两条命令跑起来Python 3.10 起步python -m venv .venv source .venv/bin/activate pip install openai-agents运行前先设置OPENAI_API_KEY环境变量。语音、Redis 会话、Docker 沙箱、经 litellm / any-llm 接入第三方模型等能力都拆成了可选依赖组按需加一个[extra]装上即可不用一次全装。 核心机制用大白话讲Agent一份岗位说明书。为什么存在同一个模型在不同任务下需要不同人设和权限总不能改代码。一个 Agent 就是一组角色配置——instructions岗位说明、tools手边工具、模型参数。像新员工入职档案框架照着它派活。Tool让模型从会说变会做。裸模型只能输出文本function_tool把普通 Python 函数变成模型可触发的工具参数解析、结果回填框架全包了。from agents import function_tool, Agent function_tool def get_weather(city: str) - str: return fThe weather in {city} is sunny. agent Agent(nameWeather, instructionsYou are a weather assistant., tools[get_weather])Handoff智能体之间的转接电话。为什么存在一个智能体不可能什么都会把所有人设塞进一条 prompt 只会互相打架。交接本质是一次特殊工具调用——当前智能体判断这事该别人管把会话上下文整体转给另一个智能体。像前台接线员她不回答技术问题只查分机号然后转接。Runner 运行循环追着要结果的项目经理。模型的回答经常不是最终答案而是工具调用。Runner.run()自动执行调模型 → 跑工具 → 回填 → 再调直到拿到最终输出或发生交接这个 while 循环你一行都不用写。️ 最小可用场景8 行代码走通语言分派最直观的多智能体协作场景是前台分派用户用不同语言提问前台先看语言再转给对应专员。import asyncio from agents import Agent, Runner spanish Agent(nameSpanish, instructionsOnly speak Spanish.) english Agent(nameEnglish, instructionsOnly speak English.) triage Agent(nameTriage, instructionsHand off to the Spanish or English agent based on the language of the users message., handoffs[spanish, english]) asyncio.run(Runner.run(triage, Hola, ¿cómo estás?))关键不在 API 参数而在两处接线思路其一分派智能体只转不答所以 instructions 必须写明 handoff 规则否则模型会自己用中文回答完交接链路根本不会触发其二专员智能体是挂进handoffs列表的这个列表就是分派者的分机号簿——将来加一个德语专员只改列表不动其他逻辑。上图就是这类协作的运行结构Triage Agent 是入口工具如 get_weather按需求挂在智能体身上交接后由对应专员接管对话。进阶能力一览Guardrails进出两道质检输入进模型前、输出离开前都可以做程序化校验不合格就拦下。适用于敏感信息、合规审查、必须禁止某类回答的场景。Sessions跨请求的记忆内置 SQLite、Redis、MongoDB、SQLAlchemy 等会话实现绑定后对话历史自动持久。适合长对话、有状态 API、多轮客服。Human in the loop给危险操作踩刹车工具调用可配置成暂停等待人审批批准后从断点续跑。适用于发邮件、下单、改生产数据这类有真实副作用的操作。Sandbox agent给智能体一个真实工位SandboxAgent让智能体在容器或本地沙箱里执行命令、改文件、跨任务保留状态详见 docs/sandbox_agents.md。Realtime 与 Voice从文字到打电话支持gpt-realtime实时语音智能体也提供语音识别 → 智能体 → 语音合成的完整语音管线。适用于电话客服、车载、语音助手类交互。⚠️ 上手避坑分派智能体抢着答题→ 它的 instructions 必须写明只做 handoff不要直接回答且每个专员的边界要写到Only speak Spanish这种程度模型看到能答就会答交接链不会触发。instructions 越堆规则越糟→ 按任务拆智能体一个 Agent 只干一件事提示词只写何时用哪个工具、参数怎么填常识留给模型别把员工手册塞进岗位说明。护栏等出事才补→ 输入护栏放入口、输出护栏放出口时机要在设计期定下来上线后补护栏要动架构成本翻几倍。首次运行报莫名其妙的 import 错误→ 多半是可选依赖没装litellm、redis、docker 等都不在基础包里对照 pyproject.toml 的[project.optional-dependencies]检查缺哪组。 适合谁、不适合谁适合想在 LLM API 之上快速搭多智能体原型客服分派、研究助手、代码代理并且要现成的追踪、状态与审批机制的团队。不适合流程是固定 DAG、每个节点输入输出严格确定的硬编排场景——那类工作流引擎更稳而这套框架的强项恰恰是模型自主决定下一步的动态循环。生态上两个扩展方向值得留意Sessions 可接 Redis 或关系数据库做生产级持久化长任务可配合 Temporal 做持久执行或用 Docker 沙箱把智能体整个隔离起来。完整 API 参考在 docs/ref/ 目录入门可以从 docs/quickstart.md 接着往下读。【免费下载链接】openai-agents-pythonA lightweight, powerful framework for multi-agent workflows项目地址: https://gitcode.com/GitHub_Trending/op/openai-agents-python创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
