当无数团队还在为提示模板放哪儿、工具 schema 怎么维护吵得不可开交时，Nvidia 甩出了一个极简方案：把所有东西塞进一个 Python 类。

1. 碎片化之痛

如果你在过去一年里搭建过 AI Agent，大概率经历过这样的场景：

• 提示词藏在 Jinja 模板文件里
• 工具定义散落在 JSON Schema 中
• 回调函数写在另一个 Python 模块里
• 工作流还得额外画一张 DAG 图

一个 Agent 的逻辑分散在四五个文件中，维护成本随着迭代次数指数级上升。更致命的是——代码审查时根本看不清 Agent 的完整行为边界。团队里的新人接手一个 Agent 项目，需要先读模板、再翻 Schema、最后才找到执行逻辑，心智负担极大。

这不是某个团队的问题，而是整个 AI Agent 工程化进程中的结构性问题。LangChain、AutoGen、CrewAI 等框架各自给出了自己的抽象方案，但本质上都是在"模型之外"堆砌一层又一层的挽具（Harness）。UST 首席 AI 架构师 Adnan Masood 曾直白地评价：挽具就是包裹模型的所有外设，现在它们天女散花一样撒在不同的抽象层里。

2. NOOA 的解法：一个类统治一切

2026 年 7 月底，Nvidia 静悄悄地在 AI 开发者圈投下了一枚"代码核弹"——NOOA（Object-Oriented Agents，面向对象的代理），并将其贡献给了自己刚刚拉起的"开放安全 AI 联盟"。

NOOA 的设计哲学简单到近乎粗暴：

• 类的方法 = Agent 的能力（Tool）
• 类的字段 = Agent 的状态（Memory/Context）
• 方法的 docstring = Agent 的提示词（System Prompt）
• 类型注解 = Agent 的强制契约（Structured I/O）

来看一段概念示例：

from nooa import Agent

class ResearchAgent(Agent):
    """你是一个专业的技术研究员，擅长从多源信息中提炼关键结论。"""

    knowledge_base: dict = {}

    def search_papers(self, query: str) -> list[dict]:
        """在论文数据库中搜索与 query 相关的论文，返回标题、摘要和链接列表。"""
        ...
        # ... 意味着由 LLM 驱动的循环在运行时自动补全

    def synthesize_report(self, papers: list[dict]) -> str:
        """基于论文列表生成一份结构化的研究综述报告。"""
        report_parts = []
        for paper in papers[:5]:
            report_parts.append(f"## {paper['title']}\n\n{paper['abstract']}\n")
        return "\n---\n".join(report_parts)

注意 search_papers 方法体里的三个点 ...——这就是 NOOA 最巧妙的设计。方法体写了 ... 的方法，运行时会由大模型驱动的循环自动补全执行逻辑；而方法体写了正常 Python 代码的（如 synthesize_report），则老老实实按确定性 Python 执行。

这种"混合体"设计让 Agent 的定义回到了一个工程师最熟悉的容器——类。没有额外的 YAML 配置、没有分散的模板文件、不需要画工作流图。一个 .py 文件就是一个完整的 Agent。

3. 争议：确定性代码 vs. 概率性魔法

IBM 解决方案架构师 Karthik Karunanithi 在社区的尖锐提问，精准戳中了 NOOA 最脆弱的环节：

“两个方法的函数签名、缩进、docstring 长得一模一样，代码审查时你怎么区分哪一段是可控的代码，哪一段是概率性的魔法？”

这不仅是代码审查的问题，更是工程可信度的问题。传统软件工程花了几十年建立起确定性的护城河——单元测试、类型检查、静态分析、CI/CD 流水线——这一切的前提是：代码的行为是可预测的。

当同一个类里混入了 LLM 驱动的动态补全逻辑，这条护城河就出现了裂缝。search_papers 这次返回 5 条结果，下次可能返回 8 条；这次的查询策略是用关键词匹配，下次可能变成了语义检索。你没法为 ... 写单元测试，因为它每次的行为都不完全一样。

Thine 和 MerlinAI 的联合创始人 Siddhartha Saxena 也指出：NOOA 用类型化的输入输出来规范 Agent 调用，确实给调用结构加了层骨架，但一旦工具调用量跑到百万级，可观察性（Observability） 的硬仗不是哪个框架单枪匹马能摆平的——你需要一套独立的诊断系统来追踪 Agent 的实际行为轨迹。

4. 我的判断：方向对了，但远不是终点

站在工程实践的角度，NOOA 的价值不在于它是不是"终极方案"，而在于它旗帜鲜明地提出了一个方向：Agent 的定义应该回归到普通软件工程的范式中来。

过去两年 AI Agent 开发的混乱，很大程度上是因为"LLM 是特殊的"这个观念让工程师放弃了对代码结构的追求。提示词工程、工具编排、记忆管理被当作独立领域各自发展，碎片化是必然结果。

NOOA 的意义在于它说了一句话：别把 Agent 当魔法，把它当代码。

至于争议——确定性代码与概率性魔法混在一起的问题——这恰恰是下一代 AI 工程工具需要解决的。我预判接下来半年会出现两类关键基础设施：

1. Agent 专用 Linter/静态分析工具：能在 CI 阶段标注出哪些方法是 ... 动态补全的，哪些是确定性执行
2. Agent 级 Observability 平台：不止追踪 token 消耗和延迟，更要追踪 Agent 的决策路径、工具调用链、以及每次 ... 补全的实际行为差异

5. 写在最后

AI Agent 工程化正在进入深水区。早两年大家还在争论到底该用 AutoGPT 还是 BabyAGI，现在一线工程师的痛点已经变成：怎么让 Agent 像普通软件一样被 review、被 debug、被审计。

Nvidia NOOA 给出的答案是一行代码的审美——你敢不敢把全部复杂性塞进一个 Python 类里？有人觉得它干净得像个艺术品，也有人觉得它只是把混乱藏进了漂亮的抽屉里。

至少，当无数团队还在为"提示模板放哪儿"这种问题内耗时，有人先甩出了一个极简的方案。模型之外的挽具怎么设计，已经变得和模型本身一样重要了。

---

本文作者：小马

#AI #Agent #NOOA #Nvidia #LLM #软件工程 #Agent框架 #Python