把 Agent 写回 Python：NVIDIA 的 NOOA，想结束“框架套娃”

做一个 Agent，代码往往不在一个地方。

提示词藏在模板里，工具定义塞进 JSON Schema，状态挂在回调中，流程又画成另一张图。模型明明只是在完成一个任务，开发者却要同时维护好几套抽象。

NVIDIA-labs OO Agents 提出的 NOOA，选择了一条近乎“返璞归真”的路线：Agent 就是一个 Python 对象。

论文名称：NVIDIA-labs OO Agents: Native Python Object-Oriented Agents 论文链接：https://arxiv.org/abs/2607.20709

类定义角色，字段保存状态，方法提供能力，文档字符串变成提示，类型标注负责输入输出契约。普通方法照常执行；方法体只有 ... 时，运行时才把它接管成 LLM 驱动的 Agent 循环。

NOOA 最值得关注的，不是“面向对象”这个标签，而是它试图让 Agent 工程重新服从软件工程。

真正的摩擦，不只来自模型

今天的 Agent 框架普遍拥有工具、记忆、工作流、交接和追踪能力。问题在于，这些能力经常被包装成框架专属的概念。

开发者要学习新的图结构、新的消息类型、新的状态容器；模型也要理解一套陌生的工具协议。人的开发界面与模型的行动界面，被拆成了两套语言。

NOOA 的判断是：Python 已经有类、方法、变量作用域、异常、asyncio 和类型系统，没必要再为 Agent 复制一遍。

这有点像 PyTorch 当年的思路——底层运行时可以很复杂，但用户面对的仍然是熟悉的 Python。论文把同一原则移到 Agent：能沿用语言原语的地方，就不创造新的领域专用语言。

一个省略号，把确定性与生成性分开

一个 NOOA Agent 可以同时拥有两类方法。

第一类有正常方法体，负责规则、计算、解析和状态转换。这些工作需要确定性，应该能被测试、复用和静态检查。

第二类的方法体是 ...。它看起来仍是普通的异步方法，却会在运行时启动 Agent 循环。方法签名给出输入输出，文档字符串描述任务，self 上的方法与状态成为模型可用的能力。

框架内置两种策略。PredictStrategy 适合分类或抽取：调用一次模型，并按返回类型校验结果。CodeActStrategy 则让模型在类似 Notebook 的 REPL 中反复写 Python、观察输出、更新状态，直到调用 return_result(...)。

如果结果不符合返回类型，调用不会悄悄结束。运行时会把错误交还给模型继续修正。于是，“任务完成”不再只是一句自然语言声明，而是一个通过验证的程序动作。

这条边界很重要：语义判断交给模型，精确规则留在普通代码里。与其用更长的提示词提醒模型“务必遵守”，不如把约束写成可执行的类型与方法。

六种能力，为什么必须放在同一表面

论文总结了六种面向模型的能力：类型化输入输出、活对象的按引用传递、代码即行动、可编程循环、显式对象状态，以及模型可调用的上下文与事件 API。

单独看，它们并不全是新概念。论文比较了十四种 Agent 框架与 harness，也承认社区正在从不同方向靠近这些能力。NOOA 的主张是：它首次把六者集中到同一个 Python 对象表面。

其中最容易被低估的是按引用传递。

传统工具调用常把对象序列化为文本或 JSON，再塞进上下文。数据一大，token 成本和截断风险就一起上升。NOOA 只向模型展示变量的类型、真实长度与首尾样本，完整对象仍留在执行环境中。

模型看到的可能只是“这是一个长度为一百的列表，以及头尾十项”，但它写出的 Python 可以遍历全部一百项。这样，可处理的数据规模由执行环境决定，而不是由上下文窗口决定。

论文的洞见在于：Agent 不必“看见”全部数据，才能对全部数据做计算。它只需要看见对象的形状，并拥有操作真实对象的代码能力。

上下文不是聊天记录，而是可编程状态

NOOA 把每一轮上下文拆成三部分。

静态块保存系统提示与对象接口，可以复用前缀缓存；事件历史以带类型的事件追加，记录调用、输出和返回值；动态块则在每轮模型调用前重新渲染，例如待办进度或最新环境状态。

这使上下文管理从“拼字符串的幕后脚本”，变成开发者和模型都能调用的 Python API。事件可以查询、折叠和限定可见范围；状态则挂在对象字段上，不必完全依赖容易被压缩的聊天历史。

长时记忆沿用了同一思路。Agent 可以主动 remember、recall、search、更新或遗忘；系统也能在每轮前注入相关记忆，并在空闲时合并重复项、处理冲突和衰减低价值记录。整个存储落在一个可检查的 SQLite 文件中。

这里最有价值的设计不是“又一个向量库”，而是记忆仍然属于对象状态的一部分。记忆还能保存指向实时对象的类型化引用，召回时解析最新状态，而不是永远回答旧副本。

模型真的会用这套接口吗？

论文先做了 88 个测试、36 类能力、10 个模型、每项重复 5 次，共得到 4400 条记录。总体通过率是 97.9%；小型或高效模型为 96.0%，大型前沿模型为 99.2%。

这说明当代模型已经很熟悉 Python 对象、方法调用和返回类型。接口本身没有成为明显负担。

但更像真实 Agent 工作的压力测试只达到 84.7%。大型模型为 93.9%，小型模型只有 70.8%。差距主要出现在批量记账、错误恢复、REPL 探索、结果迭代和任务分解。

换句话说，模型会“使用对象”已经不是最难的部分；长程执行中的纪律性与一致性，仍然是能力边界。

基准成绩说明了什么

在 SWE-bench Verified 上，NOOA 使用 GPT-5.5、xhigh 推理强度时达到 82.2%，高于论文对比中的 OpenCode 78.6% 与 PI 78.2%。它平均约调用模型 28 次、消耗 110 万 token；PI 则约 66 次、220 万 token。

在 Terminal-Bench 2.0 上，GPT-5.5 的 high 设置达到 73.0%，对比 OpenCode 的 60.7% 与 PI 的 68.5%。不过在 xhigh 设置下，PI 的 75.3% 反而高于 NOOA 的 73.0%。论文展示的是稳定优势，不是所有配置都碾压。

论文将一部分收益归因于“验证后终止”：Agent 必须返回包含根因、证据和验证命令的 TaskResult，不能因为模型少发了一次工具调用就被视为完成。

在 CyberGym L1 上，开源的 NOOA Agent 得到 86.8% 解题率，高于论文列出的开源对照；但更能展示架构价值的，是 ARC-AGI-3。

作者把原本六个角色、复杂 harness 的世界模型系统，压缩成一个 NOOA Agent 加一份约 50 行的技能。GPT-5.5 配合世界模型与记忆达到 50.2%，高于基线的 41.7% 和“Markdown 文件代替记忆”的 38.4%。

同一 Agent 换成 GPT-5.6-sol 后达到 85.1%，每局成本低于 20 美元。论文还对比了原始模型 13.3% 的公开结果，但明确提醒两者预算不同，因此这只能视作harness 影响力的指示性证据，不能当成严格同条件增益。

它没有解决什么

NOOA 的优势也带来直接风险：为了保留按引用传递，模型生成的代码在 Agent 进程内执行。框架会拦截 eval、exec 等破坏循环的接口，但这不是完整的主机安全边界。

论文建议把容器、虚拟机或权限系统放在 Agent 进程外层。进程内活对象与强隔离之间存在真实取舍：跨沙箱序列化更安全，却会失去原生引用语义。

此外，论文主要证明“当前模型能有效使用这套接口”，而不是证明所有收益都由某一个设计点单独造成。不同 harness 的提示、工具与终止条件难以完全等价，框架对比也会随版本快速变化。

因此，NOOA 更适合被看作一种鲜明的工程提案：先减少抽象，再让类型、状态和运行时承担可靠性；而不是一个已经终结 Agent 框架竞争的答案。

当模型越来越会写代码，最自然的 Agent 接口，也许不是更多工具协议，而是让它与开发者共同面对同一个可执行对象。

进阶学习

如果你正在关注大模型 Agent、强化学习后训练、RLHF、DPO、GRPO、RLVR 等前沿方向，欢迎学习我最新上线的精品课程：

课程围绕 Agent 架构、强化学习基础、Reward 设计、策略优化、工具调用、多轮任务执行、Agentic Workflow 以及前沿论文与实战案例展开，帮助你建立从理论到应用的完整知识体系。

Agent RL 正在成为大模型能力提升与智能体系统演进中的重要方向。未来的 Agent 不只是会调用工具，而是要能规划任务、评估结果、修正策略，并在复杂环境中持续优化自己的行为。

现在系统学习 Agent RL，提前进入下一阶段 AI 应用开发的核心赛道。

🌟 关注“唐国梁TGLTommy”，一起持续追踪 AI 技术演进背后的长期趋势。