做一个 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 接口，也许不是更多工具协议，而是让它与开发者共同面对同一个可执行对象。
