案例研究：Notion AI 背后的 Harness 逻辑-编程阁

案例研究：Notion AI 背后的 Harness 逻辑

关键词：Notion AI、Harness编排层、大模型应用落地、Prompt工程、RAG检索增强生成、AI原生应用、工具调用编排
摘要：很多用户都有一个疑问：Notion AI 没有自研大模型，用的是OpenAI、Anthropic的第三方模型能力，为什么体验比直接用ChatGPT还顺滑？本文将从用户体验倒推技术架构，深度拆解Notion AI背后的核心竞争力——Harness（AI编排）层的设计逻辑，从核心概念、算法原理、代码实战到行业应用，手把手带你复现一个简化版的Notion AI核心能力，帮你掌握AI原生应用的核心设计思路。

背景介绍

如果你是Notion的深度用户，肯定用过它的AI功能：选中一段文本点一下「总结」，1秒就能生成清晰的分点摘要；在项目文档里输入「帮我生成下周的迭代排期」，AI自动基于文档里的项目背景、人员配置生成可落地的计划；甚至你写了一半的文案，点「改进写作」就能得到更专业、更通顺的版本，完全不用你手动复制粘贴文档内容、绞尽脑汁写Prompt。
反观很多人用ChatGPT，要先把要处理的文档内容复制过去，还要自己写「请基于以下内容总结，分点输出，不要超过300字」之类的Prompt，稍微长一点的文档还会触发上下文长度限制，体验差了不止一个档次。
这背后的核心差异，根本不是大模型能力的差距，而是Notion做了一层非常强大的Harness（AI编排）层——就像一个经验丰富的大管家，把用户输入、私有数据、大模型能力、第三方工具全部串了起来，把用户的模糊需求自动转化成大模型能处理的标准化指令，最后把准确的结果交到用户手上。

目的和范围

本文的核心目标是拆解Notion AI Harness层的设计逻辑，让所有AI应用开发者、产品经理、创业者都能掌握AI原生应用的核心设计方法：

理解Harness层的核心概念、架构组成
掌握Harness层的核心算法原理
能够用Python复现一个简化版的Notion AI Harness服务
了解Harness层的行业应用场景和最佳实践
本文不会涉及大模型训练、底层推理的内容，聚焦于大模型上层应用的编排逻辑。

预期读者

AI应用开发工程师、全栈开发者
想要做AI原生应用的产品经理、创业者
对RAG、Prompt编排感兴趣的技术爱好者
企业内部AI工具的搭建者

文档结构概述

本文将按照「概念引入→原理拆解→代码实战→应用落地→趋势展望」的逻辑展开：

核心概念部分用生活类比讲解Harness层的作用、组成模块
算法原理部分讲解Harness层用到的核心算法、数学模型
项目实战部分用Python实现一个可运行的简化版Notion AI Harness服务
应用落地部分讲解Harness层的通用场景、最佳实践
最后总结Harness层的未来发展趋势、常见问题解答

术语表

核心术语定义

术语	定义
Harness层	介于用户、业务数据、第三方工具、大模型之间的调度层，负责将用户的模糊自然语言需求转化为大模型可处理的指令，调度相关数据和工具，校验输出结果后返回给用户
RAG（检索增强生成）	一种将私有数据召回后注入大模型Prompt的技术，解决大模型不知道私有数据、容易幻觉的问题
Prompt编排	根据用户的意图、场景动态生成适合大模型处理的Prompt模板的过程
意图识别	判断用户输入的自然语言需求属于哪个业务场景的技术
输出校验	检查大模型生成的内容是否符合业务要求、有没有幻觉、有没有敏感信息的过程

缩略词列表

LLM：大语言模型（Large Language Model）
RAG：检索增强生成（Retrieval Augmented Generation）
API：应用程序编程接口（Application Programming Interface）

核心概念与联系

故事引入

我们用大家都熟悉的奶茶店场景做类比：
你走进常去的奶茶店，对收银员说「少糖少冰加珍珠，要和上次我喝的那个芒果味差不多，我赶时间麻烦快一点」。
这个时候收银员不会直接把你的话原封不动转给后厨，而是会做这几件事：

感知上下文：先查你的历史订单，找到你上次喝的芒果奶茶的配方，确认你要的是七分糖、少冰、加椰果（哦不对你这次要加珍珠）
识别意图：判断你是要点单，不是要投诉、不是要问营业时间
调度资源：查库存系统确认有没有珍珠，如果没有就问你换成椰果行不行，同时备注「优先做，用户赶时间」
标准化指令：给后厨发送标准化的工单：「芒果奶茶，七分糖，少冰，加珍珠，优先制作」
校验结果：后厨做好之后，收银员先检查是不是你要的芒果味、有没有加珍珠、温度是不是对的，确认没问题才递给你
整个过程里，收银员就是Harness层，你是用户，后厨是大模型，你的历史订单是用户私有数据，库存系统是第三方工具。
Notion AI的Harness层做的就是和收银员一模一样的事情：你在Notion里输入「帮我总结这个文档的核心内容」，它自动把当前文档的内容找出来，生成合适的Prompt发给大模型，检查大模型返回的内容有没有编造文档里没有的信息，最后把结果返回给你，完全不用你操心中间的过程。

核心概念解释

我们用刚才的奶茶店类比，把Harness层的核心模块一个个讲清楚：

核心概念一：Harness层（AI编排层）

Harness层是整个AI应用的「大脑+大管家」，所有的请求都要经过它的处理。就像奶茶店的收银员，是连接用户、后厨、供应链的核心节点，所有的需求都要经过它的中转、处理、校验。
传统的软件应用是「用户输入→固定逻辑处理→输出结果」，逻辑是写死的；而AI应用的逻辑是动态的，用户的输入是模糊的自然语言，大模型的输出是不确定的，Harness层的作用就是把这种不确定性变成确定性的用户体验。

核心概念二：上下文感知模块

上下文感知模块是Harness层的「眼睛」，负责找到和用户当前需求相关的所有数据。就像收银员查你的历史订单、查库存，知道你之前喝的什么、现在有没有你要的配料。
Notion的上下文感知逻辑非常智能：

如果你选中了部分文本，它默认把选中的文本作为上下文
如果你没有选中文本，它默认把当前打开的整个文档作为上下文
如果你在问题里提到了其他文档的名字，它会自动召回其他相关文档的内容
如果你在团队空间里，它还会自动召回你有权限访问的团队公共文档的内容

核心概念三：Prompt编排模块

Prompt编排模块是Harness层的「翻译官」，负责把用户的模糊需求转化成大模型能听懂的标准化指令。就像收银员把你说的「少糖少冰加珍珠和上次差不多」转化成后厨能看懂的标准化工单。
Notion预设了几十种不同场景的Prompt模板：

总结场景：Prompt里会要求「分点输出，简洁清晰，不要遗漏核心信息，字数不超过原文的30%」
翻译场景：Prompt里会要求「保持原意，保留原文的格式，专业术语准确」
改进写作场景：Prompt里会要求「保持原意不变，让内容更通顺、更专业、更有逻辑，适合职场场景」

核心概念四：工具调度模块

工具调度模块是Harness层的「手」，负责根据用户的需求调用对应的第三方工具。就像收银员查库存系统、给后厨备注优先制作。
Notion AI的工具调度能力现在已经支持：

调用日历工具，自动根据生成的排期创建日程
调用邮件工具，自动把生成的内容发给相关的团队成员
调用搜索工具，自动补充文档里没有的公开信息

核心概念五：输出校验模块

输出校验模块是Harness层的「质检员」，负责检查大模型生成的内容是不是符合要求，有没有幻觉、有没有敏感信息、有没有偏离用户的需求。就像收银员在递给你奶茶之前先检查是不是你要的口味、有没有加对配料。
Notion AI的输出校验逻辑会重点检查：

生成的内容有没有编造文档里没有的信息
有没有敏感内容、不符合职场规范的内容
有没有偏离用户的需求（比如用户要总结，结果生成了翻译）

核心概念之间的关系

我们用一个表格对比传统API编排和AI Harness编排的核心差异：

对比维度	传统API编排	AI Harness编排
输入处理	结构化输入，参数固定	模糊自然语言输入，动态解析
逻辑确定性	逻辑100%固定，写死在代码里	逻辑动态生成，根据用户需求调整
数据依赖	固定的数据源，提前定义好	动态召回相关数据，按需获取
输出处理	结构化输出，格式固定	非结构化自然语言输出，需要校验
容错机制	出错就重试，返回错误码	出错就重新生成，自动修正
适用场景	固定业务流程的标准化需求	AI原生应用的模糊需求
这几个模块的关系就像一个足球队：Harness层是队长，上下文感知是守门员（挡住没用的信息，只放有用的进来），Prompt编排是中场（把需求转化成进攻指令），工具调度是前锋（执行具体的操作），输出校验是后卫（把不合格的内容挡在用户面前），所有模块配合才能赢下比赛（给用户好的体验）。

核心概念原理和架构的文本示意图

Notion AI的完整Harness层架构如下：

[用户侧] → [用户输入/操作指令] ↓ [Harness层] ├─ 上下文感知模块 → 读取当前页面内容/选中内容/召回相关私有文档 ├─ 意图识别模块 → 判断用户需求属于哪个场景（总结/翻译/生成/调用工具） ├─ Prompt编排模块 → 基于场景模板+召回的上下文生成标准化Prompt ├─ 多模型路由模块 → 选择最合适的大模型（简单需求用GPT-3.5，复杂需求用GPT-4） ├─ 工具调度模块 → 按需调用第三方工具（日历/邮件/搜索等） ├─ 大模型调用模块 → 调用大模型服务获取生成结果 └─ 输出校验模块 → 校验结果是否符合要求，不符合就重新生成 ↓ [用户侧] → [返回最终结果]