当智能开始形成系统
生成式 AI 的第一阶段，是模型能力的突破。
人们讨论最多的是参数规模、上下文长度、推理能力，以及模型在各种 benchmark 上的表现。很多人自然地认为，只要模型足够强，AI 就可以完成越来越复杂的任务。
但在真实世界中，很快就会遇到一个问题：
一个模型很难完成完整的工作流程。
现实世界的任务通常包含多个步骤：信息获取、规划、工具调用、执行、验证，以及不断修正。如果让一个模型独立完成所有事情，系统往往会变得不稳定、难以控制，也难以扩展。
于是，AI 系统的重点开始从 模型能力 转向 系统结构。
Agent orchestration 与 agent harness，正是在这样的背景下出现的。
Orchestration：智能之间的秩序
所谓 Agent Orchestration，本质上是协调多个 AI agent 共同完成任务的系统机制。不同 agent 可以承担不同角色，例如规划、检索、分析或执行，而 orchestration 负责组织它们之间的协作关系。
换句话说：
Orchestration 并不是智能本身，而是智能之间的秩序。
在一个典型的多 agent 系统中，往往会出现这样的结构：
一个 agent 负责理解任务
- 一个 agent 负责检索信息
一个 agent 负责推理与规划
一个 agent 负责调用工具或执行操作
另一个 agent 负责验证结果
这些 agent 单独看并不复杂，但通过 orchestration，它们可以组成一个协作系统。
因此，从系统视角看，Orchestration 更像一种 调度层。它决定：
- 哪个 agent 参与任务
agent 之间如何通信
信息如何共享
任务如何分解与合并
某种意义上，它和操作系统中的调度机制并没有太大区别。 - CPU 调度线程，而 orchestration 调度智能。
Harness：让智能真正可用
如果说 orchestration 解决的是 协作问题，那么 harness 解决的是 运行问题。
一个原始模型，本质上只是一个推理引擎。
要让它成为一个真正可运行的 agent，还需要一层完整的系统结构。
这就是 Agent Harness。
简单来说，harness 是包裹在模型周围的一整套基础设施，它负责管理工具调用、上下文状态、任务生命周期以及错误恢复等问题。
在实际系统中，harness 通常承担很多职责，例如：
管理 agent 的运行状态
- 提供稳定的上下文环境
控制工具调用权限
记录执行轨迹
持久化记忆
提供人类监督机制
因此，有一种很形象的比喻：
模型是引擎，而 harness 是整辆车。
再强的引擎，如果没有方向盘、刹车和底盘，也无法真正运行。
从单个 Agent 到系统智能
当人们第一次构建 AI agent 时，很容易把注意力集中在 agent 本身：
如何让 agent 更聪明
如何让 agent 更自主
如何让 agent 能够规划任务
但随着系统规模扩大，很快会发现一个事实：
真正复杂的问题，很少由一个 agent 解决。
现实世界更像一个团队，而不是一个超级个体。
因此，多 agent 系统正在成为一种越来越普遍的架构。通过 orchestration，不同 agent 可以共享信息、协同决策，并共同完成复杂任务。
在企业环境中，这种结构甚至会扩展到：
AI agent
- 软件系统
自动化流程
人类决策者
共同构成一种 混合智能系统。
UBAI 的系统视角
在 UBAI 的理解中，生成式 AI 的真正潜力，并不在于生成内容，而在于 生成系统能力。
一个模型可以生成文本。
一个 agent 可以执行任务。
但只有系统，才能真正参与生产。
当多个 agent 可以被动态编排，当工具与流程可以在运行中生成，软件本身就开始发生变化。
我们将这种新的形态称为：
Liquid Intelligence
在 Liquid Intelligence 的世界里：
系统结构不再固定
- agent 可以动态生成
工作流程可以不断演化
软件不再只是静态工具，而是一种能够持续组织智能的系统。
从这个角度看，Agent orchestration 与 harnessing 并不是某种技术细节，而是 AI 系统工程的核心部分。
AI 的第一阶段，是让机器变得聪明。
AI 的第二阶段，是让智能形成系统。
单个模型可以回答问题。
但只有系统，才能真正参与生产。
Agent orchestration 与 harness，正是这一转变的开始。
而未来的软件，也许不再只是代码的集合，而是一种 能够持续组织智能的系统结构。
这可能才是生成式 AI 真正的工程革命。