AI 智能体（agent）接入工具、记忆和多步执行后，仍可能丢字段、重复调用，或在长任务中偏离目标。遇到这些问题，先检查运行框架（harness）如何传入上下文、执行动作、保存状态并判定任务完成。
NVIDIA Developer Blog 于 2026-07-27 发布 Six Agent Harness Capabilities for Higher Model Performance，介绍 NVIDIA Labs Object-Oriented Agents（NOOA）。截至 2026-07-28，NOOA 代码仓库已经公开，但 CHANGELOG仍把首次公开发布放在 Unreleased 项下。代码和评测方法都已公开，可以直接检查和复现；但 NOOA 仍是研究预览，不能当作现有运行框架的稳定替代品。
现有团队可以用这六项能力审查当前系统：固定输入输出契约和上下文引用，隔离模型生成的代码并收紧执行循环，再把状态显式化，同时限制模型可调用的框架 API。没有固定评测集、完整轨迹和回滚路径时，所有改造都应留在隔离环境。
哪些团队应该先查运行框架
这份清单适合已经有智能体原型、能保存任务轨迹，并愿意用同一模型和任务集比较改造前后结果的开发者或平台团队。单轮回答质量不佳，先查模型、提示词和检索；连基线都复现不了，先补评测和日志。
| 当前症状 | 第一检查项 |
|---|---|
| 工具结果过长，提示上下文持续膨胀 | 对象引用与摘要预览 |
| 输出字段缺失或格式经常无效 | 类型契约与返回值校验 |
| 长任务丢状态或重复执行 | 显式状态与事件历史 |
| 没有固定评测集或完整轨迹 | 暂停框架改造，先补基线 |
先写清四个完成条件：任务成功率是否提升、每个任务的词元（token）是否下降、失败类型是否减少，以及哪些旧任务出现退步。任何一项答不上来，都不要把改造接入生产流量。
NOOA 实际把智能体做成什么
NOOA 用单个 Python 类表示一个智能体。方法签名和 docstring（文档字符串）定义任务与类型边界，字段保存模型可见状态。方法体为 ... 时，运行框架用大语言模型驱动的循环执行该方法；普通方法体则作为确定性代码直接运行。NVIDIA 技术报告详细说明了这套编程模型和评测方法。
| Python 结构 | NOOA 中的职责 |
|---|---|
| 一个类 | 智能体的能力、状态和提示边界 |
| 方法签名与 docstring | 类型化输入输出与任务提示 |
... 方法体 |
由模型驱动的生成或 CodeAct 循环 |
| 普通方法与字段 | 确定性规则、外部能力和显式状态 |
CodeAct 循环允许模型编写 Python，在当前对象上调用方法，并操作执行环境里的对象。NOOA 会检查语法树并限制模块，但这些措施无法隔离宿主机。官方要求把会执行模型代码的智能体放进容器、虚拟机或 NVIDIA OpenShell 这类操作系统级沙箱。NOOA 仓库的安全说明还明确列出了文件删除、环境修改和数据外传风险。
下表第二列是 NOOA 的官方机制，第三列是本站给现有生产系统的保守建议，不能把两列当成同一结论。
| 官方能力 | NOOA 机制 | 现有系统先检查什么 |
|---|---|---|
| 类型化输入输出（typed input/output） | 方法参数和返回值经过类型校验 | 工具参数、返回值和最终答案是否有可执行校验 |
| 引用传递（pass by reference） | 对象留在执行环境，模型只看有界预览 | 大对象是否反复序列化进提示上下文 |
| 代码行动（code as action） | 模型在执行循环中编写并运行 Python | 代码执行是否隔离，副作用是否经过确定性门禁 |
| 可编程循环（programmable loop engineering） | 开发者和模型都可用普通 Python 组织循环 | 停止、重试、预算和权限是否由系统强制执行 |
| 显式对象状态（explicit object state） | 类型化状态存在智能体对象上 | 任务、证据和风险状态是否脱离聊天历史 |
| 模型可调用框架 API（model-callable harness APIs） | 模型可检查上下文块和事件历史 | 是否先开放只读查询，再评估写入权限 |
第一阶段：固定契约和上下文
先处理两类能直接量化的问题：输入输出校验失败，以及大对象反复进入提示上下文。完成后，应该能分别看到结构校验失败率和每个任务的词元变化。
第 1 步：把自由文本边界改成类型契约
只要求模型“返回 JSON”并不等于有了契约。输入、工具结果和最终答案都要经过结构定义（schema）或等价代码校验；校验失败后，把字段级错误交回执行循环，由它决定重试还是停止。
| 边界 | 必须校验 | 失败处理 |
|---|---|---|
| 工具输入 | 类型、必填字段、枚举值、长度限制 | 拒绝执行并返回字段级错误 |
| 工具输出 | 成功状态、错误码、关键结果字段 | 按错误类型重试或停止 |
| 最终答案 | 任务状态、证据、限制、下一步动作 | 缺少必要字段时不交付 |
下面的示例只展示字段契约，不是可直接执行的 JSON Schema。字段名和校验器仍要按业务实现。
{
"action": "create_ticket",
"input": {
"customer_id": "string",
"priority": "low | medium | high",
"evidence_ids": ["string"]
},
"output": {
"status": "created | rejected",
"ticket_id": "string | null",
"errors": ["string"]
}
}
验收时分别统计结构校验失败、自动修正成功和最终停止的次数。旧系统里只能靠人工读日志发现的格式错误，改造后必须变成可查询指标。
第 2 步：让大对象留在执行环境
NOOA 的引用传递把活动 Python 对象留在执行环境中。模型先看到受限预览，需要完整内容时再调用方法查询。NVIDIA 技术报告把它列为在 SWE-bench Verified 中减少上下文词元的机制之一。
现有系统未必能传递活动 Python 引用，可以先用可审计的对象句柄：
- 长文档保存为
doc_id，上下文只给摘要、章节索引和可请求片段。 - 检索结果先返回标题、来源、摘要和证据 ID，不一次塞入全部结果。
- 表格通过查询函数返回小窗口，同时记录过滤条件和行范围。
- 日志、图片和二进制保留资源引用，只暴露错误摘要或按需提取结果。
每个对象句柄至少要记录来源和更新时间，还要能查到对象大小、可查询字段与访问权限。上线时同时观察平均提示词元和任务成功率。若成功率下降，先扩大预览或补查询接口。
第二阶段：约束代码和执行循环
让模型编写代码，也会扩大它对文件、网络和进程的操作能力。代码必须先在操作系统级沙箱中执行，开发者再通过外层循环强制执行预算、权限、审批和停止条件。
第 3 步：把模型代码放进沙箱
NOOA 的 CodeAct 策略会在智能体进程内执行模型生成的 Python；技术报告的限制章节说明，进程内校验不能保护宿主机。在生产系统中，模型只负责语义判断和提出动作意图；权限、幂等、审计和最终提交交给确定性代码。
| 动作类型 | 模型可以决定 | 系统必须强制 |
|---|---|---|
| 读取信息 | 查询对象和条件 | 权限、范围和返回字段 |
| 生成草稿 | 候选内容 | 格式、敏感数据和引用检查 |
| 修改系统状态 | 变更意图和参数草稿 | 幂等、审批、审计和提交 |
| 高风险操作 | 待确认计划 | 默认停止并等待人工批准 |
容器或虚拟机至少要限制挂载目录、网络出口、凭证和进程资源。动作失败时，轨迹要分清三类原因：模型或契约错误、权限或策略拒绝、外部系统故障。原因分不清，就不要继续增加工具。
第 4 步：把停止和重试写进程序
NOOA 的可编程循环允许开发者和模型使用普通 Python 组织控制流。生产中可以让模型编排受限的内层步骤，但任务完成、最大步数、费用和高风险审批必须由模型无法绕过的外层程序控制。
- 完成与停止：列出完成所需的字段与证据，以及最大步数和转人工条件。
- 重试与预算：只重试暂时性错误，并限制次数、词元、费用和总时长。
- 工具与权限：按任务阶段开放工具，权限扩大时暂停并重新审批。
- 上下文与失败输出：规定进入短期上下文的信息，并向用户返回可执行的失败原因。
系统提示词负责解释规则，程序边界负责执行。测试至少覆盖正常完成、可重试错误、不可重试错误和预算耗尽四条路径。
第三阶段：分离状态并限制自管理 API
长任务要把完成条件、证据、工具结果和风险标记保存为可检查状态。先给模型事件与上下文的只读查询能力；只有权限控制、审计和回放都稳定后，才开放写入型自管理 API。
第 5 步：让状态离开聊天历史
NOOA 把显式对象状态保存在智能体实例上，每轮都从活动对象重新渲染公开字段给模型，不靠聊天历史重建。现有系统可以先定义四类类型化状态。
| 状态 | 示例字段 | 用途 |
|---|---|---|
| 任务状态 | goal、current_step、blocked_reason |
选择下一步并判断完成 |
| 证据状态 | source_ids、verified_claims、unknowns |
防止重复核验和无依据结论 |
| 工具状态 | failed_calls、resource_refs |
控制重试和资源引用 |
| 风险状态 | needs_approval、policy_flags、rollback_plan |
阻断未批准的副作用 |
状态必须能序列化、审计和回放。只写在聊天记录里的计划不算可靠状态；历史压缩或跨会话恢复都可能把它丢掉。
第 6 步：从只读框架 API 开始
NOOA 把上下文块、每轮动态上下文和事件历史暴露为模型可调用 API；开发者可以决定每个智能体能看到哪些接口。按照 NVIDIA 技术报告的定义，这不是普通工具调用：模型可以直接检查和管理自己的工作上下文。
- 只读查询：查看事件历史、资源引用和当前状态。
- 受限写入：只能添加工作笔记或标记待验证事实。
- 记忆候选：允许提交长期记忆候选，由策略或人工决定是否信任。
- 生产 API：只开放经过权限、审计和回放验证的操作。
NVIDIA 技术博客介绍的可选长期记忆会记录类型、重要性、标签和关系，并在任务结束后合并重复或冲突记录。这些是官方研究机制，不意味着业务记忆可以自动信任。业务系统仍要保留来源、写入原因、纠错和删除路径。
用同一任务集决定是否放行
NVIDIA 报告称，在 SWE-bench Verified 上使用 GPT-5.5 的 xhigh 推理强度时，NOOA 的通过率为 82.2%，平均每个任务约调用模型 28 次、使用 110 万词元。作为对照，PI 运行框架的通过率为 78.2%，平均调用 66 次、使用 220 万词元。这组结果只适用于报告中的模型、智能体、工具和评测设置，不能当作客服、知识库或运维智能体的收益承诺。NVIDIA 技术报告
| 指标 | 记录方式 |
|---|---|
| 任务成功与退步 | 固定任务集，列出旧版成功而新版失败的任务 |
| 词元和模型调用 | 分别统计提示、输出、工具返回和调用次数 |
| 结构与工具错误 | 按校验、权限、外部系统和停止原因分类 |
| 轨迹可复查性 | 审查者能否重放关键动作并定位失败来源 |
一次只改一类能力，模型、任务集和判分规则保持不变。类型契约稳定后再测对象引用；代码沙箱和外层循环通过故障测试后，才开放状态写入或长期记忆。
生产放行条件
- 模型生成代码始终运行在受限容器、虚拟机或 OpenShell 中。
- 访问控制与幂等由确定性代码负责，审批、预算和停止规则也由程序执行。
- 固定任务集覆盖成功、退步、故障和高风险拒绝，回滚已实际演练。
- 轨迹能还原模型动作、系统门禁、外部副作用和人工批准。
本文只审查模型与运行框架之间的接口，不替代长任务安全控制或评测集建设。长时间自主任务还要执行长程安全门禁；没有固定任务集时，先按AI Agent 评测集工作流建立基线。模型代码进入真实环境前，再用 NVIDIA OpenShell 与本地 Agent 安全清单核对隔离边界。
FAQ
NOOA 适合直接替换 LangGraph、AutoGen 或自研框架吗？
不建议。截至 2026-07-28，代码已经公开，但仓库还没有稳定版本标签，因此仍应按研究预览使用。先用本文六项能力检查现有系统，再按同一口径评测，决定是否采用 NOOA 的实现。
没有 SWE-bench 或 CyberGym，怎么评估？
使用自己的固定任务集。例如，客服智能体可用脱敏历史工单配合人工判分，代码智能体则用单元测试和审查清单。研究智能体可以按引用准确率和证据覆盖率判分。基线和新版必须使用同一批任务、同一模型和同一判分规则。
记忆系统可以自动写入所有模型结论吗？
不能。自动写入会把错误结论带进后续任务。长期记忆至少要保存来源、时间、写入原因和纠错状态；高风险事实还需要策略或人工确认。
什么时候应该暂停运行框架改造？
遇到以下任一情况就暂停：完整轨迹无法保存、基线无法复现，或分不清失败来自模型还是系统边界。继续增加工具或记忆，会破坏新旧版本的可比性；补齐日志、评测集和最小类型契约后再恢复。