NOOA多智能体系统入门子Agent隔离、状态共享与Python协调模式完全指南【免费下载链接】labs-OO-AgentsNVIDIA Object Oriented Agents: the Pythonic way to build AI Agents.项目地址: https://gitcode.com/gh_mirrors/la/labs-OO-AgentsNOOANVIDIA Object Oriented Agents是 NVIDIA 推出的 Pythonic AI Agent 框架其多智能体系统的核心理念是子 Agent 只是一个普通的 Python 对象。本文将带你快速掌握 NOOA 多智能体系统的三大核心模式——子 Agent 隔离、状态共享与 Python 协调无需任何工作流引擎或 DAG 配置用你熟悉的 Python 就能搭建可靠的多 Agent 应用。为什么需要多智能体系统很多 Agent 框架把提示词、工具、回调、工作流拆成一个个彼此独立的抽象。NOOA 换了一种思路一个 Agent 就是一个 Python 类字段是状态、方法是能力、docstring 是提示词、类型注解是契约。当你发现某段工作需要独立的模型交互历史、上下文、工具状态或可复用的角色时就应该引入一个子 Agent。判断标准很简单确定性操作查价格、算折扣→ 普通 Python 方法共享同一角色、历史、工具→ 同一对象上的另一个 agentic 方法需要隔离或可复用角色→ 拆出子 Agent⚠️ 官方提醒把每个函数都拆成 Agent 并不是可扩展性策略——Agent 越多提示词、历史、模型调用和故障边界就越多。子Agent隔离每个Worker都有独立工作台NOOA 多智能体系统的第一原则是隔离。一个正确隔离的子 Agent 应该拥有自己独立的事件历史与上下文块per-instance event history and context blocks生成锁与 REPL 会话每个 agentic 方法调用都有独立的 CodeAct REPL 会话REPL 变量只在单次调用内跨代码单元保留有状态工具与连接在该实例上构造而不是挂在类上可见字段与角色指令这里有一个新手最常踩的坑❌子 Agent 不会自动继承父 Agent 的历史和上下文数据必须通过方法参数或共享应用对象显式传递。方法签名本身就定义了交接契约——写作者不会悄悄依赖研究员的提示词历史数据流向在代码里一目了然。这种隔离随 Python 对象的生命周期存在默认存储是内存的进程重启不会自动恢复旧历史需要持久化时要显式使用存储与快照/恢复流程详见 prompts-and-context.md。状态共享显式传递拒绝隐式全局既然默认是隔离的那么共享就应该被写得清清楚楚。官方文档 multi-agent-systems.md 给出的原则是交接靠类型化参数writer.write(question, evidence)—— 签名即文档数据流可追踪可复用状态放共享应用对象比如共享的数据库客户端、配置对象作为构造参数注入不要传隐式全局状态这是 NOOA 列举的常见错误之一一个典型的隔离显式交接示例来自 multi-agent-systems.mdclass Researcher(Agent): async def research(self, question: str) - list[str]: Find evidence relevant to the question. ... class Writer(Agent): async def write(self, question: str, evidence: list[str]) - str: Write an answer supported only by the supplied evidence. ...注意evidence参数写作者只依赖显式传入的证据而不是研究员的整个对话记忆。还有一个容易忽略的边界独立的 Agent 和工具实例并不能隔离它们共同指向的外部资源。并发的写操作仍然需要各自独立的工作树、沙箱、数据库命名空间或围绕共享资源的确定性协调。Python协调模式串行的、并行的、LLM驱动的NOOA 最 Pythonic 的地方在于协调完全由普通 Python 完成。编排器不需要继承Agent——它不含 agentic 方法就是正常的 Python 类class AnswerPipeline: def __init__(self, llm): self.researcher Researcher(llmllm) self.writer Writer(llmllm) async def run(self, question: str) - str: evidence await self.researcher.research(question) return await self.writer.write(question, evidence)这就是 orchestration.md 所说的把图翻译成 Python边变成普通调用条件变成if扇出变成asyncio.gather。模式一顺序交接Sequential两个await调用串起来即可。顺序由你写死的代码保证模型无需记得步骤。模式二并行扇出Parallel⚡ 关键规则每个并发任务使用独立的 Agent 实例。内置的 Predict 和 CodeAct 策略会在同一实例上串行化生成调用并发调用同一实例会被内部锁排队独立实例才能真正并行。模式三LLM 驱动生成Model-directedCodeAct 方法本质是让模型写 Python而生成子 Agent本身也是普通 Python——所以只要模型知道子 Agent 类存在例如暴露为类属性出现在doc(self)中它就能在运行时自主决定何时创建、以什么顺序调用子 Agent。这三种模式的完整可交互教程见 04_composing_subagents.ipynb用了一个周末行程规划的玩具场景演示父子 Agent 协作。模型继承子Agent自动认亲在父 Agent 的活跃调用内创建的子 Agent如果自己的类没有声明llm会自动继承父 Agent 的模型。但在应用层编排器或构造函数中创建 Agent 时此时没有活跃的父调用上下文应显式传入llmself.researcher Researcher(llmaccurate_llm) # 高精度模型 self.writer Writer(llmfast_llm) # 低延迟模型显式构造更易于理解也让每个角色用什么模型清晰可见——这是按角色做模型选择的推荐姿势。与Supervisor/图节点框架的对比你完全可以在 NOOA 中实现 Supervisor、路由器、辩论模式、Worker 池等经典模式Supervisor 通常就是一个 Python 编排器或一个专注的路由方法Workers 就是普通 Agent 实例。区别在于状态归属和交接都摆在 Python 代码里而不是藏在框架管理的图状态中。这对调试、测试和重构非常友好。新手常见误区清单 来自 multi-agent-systems.md 的官方避坑指南误以为子 Agent 会继承上下文块或对话历史多个并行任务共享一个有状态工具或同一个 Agent 实例传递隐式全局状态而不是类型化参数用 LLM Supervisor 做本可以用确定性 Python 表达的路由在没有明确隔离或专业化收益时创建过多角色从哪里开始概念文档multi-agent-systems.md、orchestration.md交互教程04_composing_subagents.ipynb、tour.md策略实现源码src/nooa/strategies/框架核心包src/nooa/一句话总结 NOOA 多智能体系统的哲学模型负责判断Python 负责流程。对象组合成系统代码即编排。【免费下载链接】labs-OO-AgentsNVIDIA Object Oriented Agents: the Pythonic way to build AI Agents.项目地址: https://gitcode.com/gh_mirrors/la/labs-OO-Agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考