Harness 和 Agent：AI 系统的分层架构
探索工具层和 Agent 层的关系，以及 MCPlato 如何实现 MCP 原生架构
发布于 2026-03-19
Harness 和 Agent：AI 系统的分层架构
从 MCP 协议到 MCPlato 的工具层和 Agent 层设计
1. 引言：AI 系统的架构觉醒
从模型至上到架构至上
过去三年，AI 行业沉迷于一个单一指标：模型能力。基准分数、参数数量和上下文窗口大小主导了技术讨论。隐含的假设很清楚——模型越好，系统越好。
但 2024 年发生了变化。
当大语言模型（LLM）跨过了对大多数实际任务"足够好"的阈值时，从业者发现了一个令人清醒的真相：AI 系统的瓶颈很少是模型本身。工具集成设计糟糕的 GPT-4 级模型表现不如工具层设计良好的 GPT-3.5 级模型。竞争的焦点已从原始智能转向架构优雅。
为什么 Harness 层比模型更重要
考虑这个场景：你拥有世界上最强大的 AI 模型。它可以推理复杂问题、编写复杂代码、理解微妙的指令。但当它尝试与现实世界交互——读取文件、调用 API、浏览网站——时，它通过设计糟糕、格式不一致、实现不安全的工具来完成这些操作。
结果是什么？沮丧、错误，最终无法交付价值。
Harness 层（也称为工具层）代表了使 AI 与外部世界交互的一切：工具定义、执行环境、安全策略、错误处理、结果格式化和内存管理。这是被困在房间里的天才与拥有能力改变世界的天才之间的区别。
核心挑战：安全可靠的工具使用
现代 AI 架构面临的基本问题看似简单：我们如何让 Agent 安全、可靠、有效地使用工具？
这个问题涵盖：
- 安全性：我们如何防止未授权的文件访问、数据泄露或恶意代码执行？
- 可靠性：我们如何确保工具行为一致、优雅地处理错误、从故障中恢复？
- 组合性：我们如何让 Agent 组合多个工具来完成复杂任务？
- 可发现性：Agent 如何知道哪些工具可用以及何时使用它们？
回答这些问题需要刻意的架构方法——一种分离关注点、建立清晰接口、优先考虑健壮性而非便利性的方法。
2. 分层架构：Harness 和 Agent 的理论模型
为了应对这些挑战，我们提出在两个不同的架构层之间进行清晰的关注点分离：Harness 层和 Agent 层。这种分离不仅仅是组织上的——它反映了根本不同的责任、故障模式和优化目标。
2.1 Harness 层（工具层）
Harness 层作为 AI 推理和外部世界之间的接口。其责任是具体的、操作性的，主要关注执行而非决策。
核心责任
| 责任 | 描述 |
|---|---|
| 工具封装 | 将外部能力（文件系统、API、数据库、浏览器）包装成定义良好的、可调用的接口 |
| 执行编排 | 管理工具调用的生命周期：验证、执行、超时处理和清理 |
| 验证和保护 | 执行安全策略、沙箱不受信任的操作、防止未授权访问 |
| 内存管理 | 处理状态持久化、会话存储、工具调用之间的上下文共享 |
| 结果格式化 | 将原始工具输出转换为适合模型使用的结构化格式 |
关键洞察：Harness 处理"其他一切"
Harness 层的定义特征是它处理纯模型推理之外的一切。当模型生成计划以"分析销售数据 CSV 并生成摘要报告"时，Harness 层：
- 定位并读取 CSV 文件
- 验证文件权限和格式
- 执行分析（可能调用代码）
- 处理任何错误或边界情况
- 为模型使用格式化结果
- 管理临时资源和清理
模型关注应该做什么；Harness 确保它能安全可靠地完成。
2.2 Agent 层（代理层）
如果 Harness 层是关于执行，Agent 层就是关于决策制定。它在更高的抽象层次上运作，关注目标、计划和策略，而不是具体的工具调用。
核心责任
| 责任 | 描述 |
|---|---|
| 任务规划 | 将高级目标分解为可执行的子任务，确定执行顺序 |
| 工具选择 | 为给定的子任务选择适当的工具（如果有） |
| 推理和决策制定 | 评估中间结果、根据反馈调整计划、处理歧义 |
| 上下文管理 | 维护相关的对话历史、过滤噪音、优先考虑重要信息 |
| 用户交互 | 确定何时要求澄清、提供中间结果或请求批准 |
关键洞察：Agent 通过抽象操作
Agent 层不直接操纵文件或执行代码。相反，它在工具的抽象上运作——理解它们的能力、限制和适当用途。当 Agent 决定"搜索相关文档"时，它将实际搜索操作委托给 Harness 层，相信 Harness 将处理查询公式化、API 调用和结果检索的具体细节。
2.3 交互模型：文本流图
Agent 和 Harness 之间的关系遵循请求-响应模式，具有清晰的边界：
┌─────────────────────────────────────────────────────────────────────┐
│ 交互流程 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ 工具发现 ┌──────────────────────┐ │
│ │ │ ─────────────────> │ │ │
│ │ AGENT │ │ HARNESS │ │
│ │ 层 │ │ 层 │ │
│ │ │ <───────────────── │ │ │
│ │ │ 工具清单 │ │ │
│ └──────┬───────┘ └──────────────────────┘ │
│ │ │
│ │ 1. Agent 分析任务并选择合适的工具 │
│ │ 2. Agent 用参数制定调用请求 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 调用请求 │ │
│ │ { │ │
│ │ "tool": "file_read", │ │
│ │ "params": { "path": "/data/sales.csv" }, │ │
│ │ "context": { "session_id": "abc123" } │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HARNESS 处理 │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 验证 │ ─>│ 执行 │ ─>│ 格式化 │ │ │
│ │ │ 请求 │ │ 工具 │ │ 结果 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 响应消息 │ │
│ │ { │ │
│ │ "status": "success", │ │
│ │ "result": { "content": "...", "metadata": {...} }, │ │
│ │ "elapsed_ms": 150 │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ AGENT │ ← Agent 整合结果，继续推理 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
2.4 分离的好处
这种分层架构提供了几个关键优势：
1. 独立演进 Harness 层可以扩展新工具而不修改 Agent 层。当新 API 可用时，只需更改工具实现——Agent 在工具清单中看到新能力。
2. 可重现性和测试 Harness 操作是确定性和可测试的。你可以验证文件读取操作正确工作，独立于 Agent 决定读取该文件。这种分离在两层都启用单元测试。
3. 安全边界 安全策略在 Harness 层执行，创建 Agent 无法绕过的硬边界。即使 Agent 被破坏或误导，它也在 Harness 沙箱的约束内运作。
4. 多 Agent 支持 多个 Agent 可以共享相同的 Harness 层，每个都从一致的工具行为和安全策略中受益。这启用了协作场景，其中不同的 Agent 处理复杂任务的不同方面。
3. MCP 协议：AI 的 USB-C 接口
2024 年 11 月，Anthropic 发布了Model Context Protocol（MCP），一个开放标准，承诺为 AI 工具集成做 USB-C 为设备连接所做的事情：提供单一、通用的接口，消除分割并启用真正的互操作性。
3.1 MCP 解决的问题
在 MCP 之前，将新数据源或工具集成到 AI 应用中通常需要构建自定义连接器。想让你的 AI 查询 Postgres 数据库？编写连接器。想让它访问你公司的 CRM？编写另一个连接器。每个集成都是定制的、脆弱的，与特定 AI 平台绑定。
MCP 通过定义 AI 应用如何连接到外部系统的标准协议来消除这种集成成本。MCP 不是 N×M 集成（N 个工具 × M 个 AI 平台），而是 N+M 集成（每个工具实现 MCP 一次，每个平台支持 MCP 一次）。
3.2 MCP 架构：三个核心角色
MCP 定义了三个对应于工具生态中不同责任的架构角色：
┌─────────────────────────────────────────────────────────────────────┐
│ MCP 架构 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │
│ │ │ │ │ │ │ │
│ │ HOST │◄───────►│ CLIENT │◄───────►│ SERVER │ │
│ │ │ │ │ │ │ │
│ │ AI 应用 │ │ 连接 │ │ 工具/数据 │ │
│ │ (MCPlato, │ │ 管理 │ │ 提供者 │ │
│ │ Claude, │ │ │ │ │ │
│ │ Cursor) │ │ • 协议 │ │ • 工具 │ │
│ │ │ │ 处理 │ │ • 资源 │ │
│ │ 编排 │ │ • 能力 │ │ • 提示 │ │
│ │ 交互 │ │ 发现 │ │ │ │
│ │ │ │ • 状态管理 │ │ │ │
│ └──────────────┘ └──────────────┘ └────────────┘ │
│ │
│ 责任： │
│ • HOST：UX、编排、生命周期管理 │
│ • CLIENT：协议合规、能力协商 │
│ • SERVER：工具实现、数据访问、执行 │
│ │
└─────────────────────────────────────────────────────────────────────┘
| 角色 | 描述 | 例子 |
|---|---|---|
| Host | 用户交互的 AI 应用；管理连接和编排交互 | MCPlato、Claude Desktop、Cursor |
| Client | 管理与特定 MCP 服务器的连接；处理协议合规和能力发现 | Host 内置的 MCP 客户端 |
| Server | 通过 MCP 协议提供特定能力（工具、资源、提示） | 文件系统服务器、GitHub 服务器、Postgres 服务器 |
3.3 MCP 核心原语
MCP 定义了服务器可以提供的三个基本原语：
Tools（可执行函数） Tools 是执行操作的函数——读取文件、查询数据库、发送消息或执行代码。它们接受结构化参数并返回结构化结果。Tools 由 AI 基于上下文和需要显式调用。
{
"name": "file_read",
"description": "读取文件内容",
"inputSchema": {
"type": "object",
"properties": {
"path": { "type": "string", "description": "文件路径" }
},
"required": ["path"]
}
}
Resources（数据源） Resources 代表 AI 可以参考的数据——文件内容、数据库架构、API 文档或配置文件。与工具不同，资源通常是只读的，充当上下文而不是操作。
Prompts（交互模板） Prompts 提供预定义的交互模式或模板，指导 AI 在特定任务中的行为。它们可以包括系统指令、示例交互或结构化请求格式。
3.4 MCP 为什么对架构重要
MCP 不仅仅是便利——它代表了我们如何思考 AI 工具集成的根本转变：
标准化启用竞争 当工具实现通用标准时，竞争从"谁有最多集成"转向"谁提供那些集成的最佳体验"。这对用户有益，并推动工具质量和 AI 能力方面的创新。
解耦启用专业化 通过 MCP，工具开发者可以专注于构建伟大的工具，而不用担心 AI 平台兼容性。AI 平台可以专注于编排和推理，而无需维护无数自定义连接器。
组合性启用生态系统 MCP 创建网络效应：每个新 MCP 服务器使所有 MCP 兼容的 Host 受益，每个新 MCP Host 为所有现有服务器创建价值。这个飞轮效应加快了生态系统增长。
4. MCPlato 的架构实践
MCPlato 代表了 Harness-Agent 分层架构的具体实现，以 MCP 为基础原则而不是事后考虑。其设计反映了从学术研究和 AI 系统实际部署中学到的经验。
4.1 三层架构模型
MCPlato 的架构围绕三个不同的层组织，每个都有清晰的责任和边界：
┌─────────────────────────────────────────────────────────────────────┐
│ MCPLATO 架构 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 工作区层 │ │
│ │ │ │
│ │ • 工作区管理和隔离 │ │
│ │ • 多目录挂载 │ │
│ │ • 跨会话内存（日记） │ │
│ │ • 环境配置 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ SESSION 层 │ │
│ │ │ │
│ │ • 上下文维护和消息历史 │ │
│ │ • 消息路由和分发 │ │
│ │ • Session 级别状态管理 │ │
│ │ • 多 Session 协调 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ AGENT 层 │ │
│ │ │ │
│ │ • ClawMode 自主执行 │ │
│ │ • 任务规划和分解 │ │
│ │ • 工具选择和调用 │ │
│ │ • 多步推理和恢复 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ HARNESS 层 │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌────────┐ │ │
│ │ │ @Tool │ │ 信息图表 │ │ 浏览器 │ │ PDF │ │ │
│ │ │ 套件 │ │ Creator │ │ Automation │ │ Tools │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ └────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌────────────────────────┐ │ │
│ │ │ MCP │ │ 图像生成 │ │ 文档分析 │ │ │
│ │ │ Host │ │ 和编辑 │ │ (OCR/理解) │ │ │
│ │ └─────────────┘ └─────────────┘ └────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
(continued in next part due to length...)
工作区层
工作区层提供组织边界和跨越各个会话的持久存储。它是 MCPlato 层次结构中最高的抽象级别。
关键能力：
- 隔离：每个工作区维护单独的配置、挂载目录和环境变量
- 多目录挂载：工作区可以包含多个项目目录，启用跨项目工作流
- 持久化内存：日记系统在会话间维护长期内存，保存见解和决策
- 环境管理：MCP 服务器、自定义工具和行为设置的工作区级配置
Session 层
Session 层管理即时交互上下文——与特定对话或任务相关联的消息、状态和短暂数据。
关键能力：
- 上下文维护：Session 内的消息历史、工具结果和中间状态
- 消息路由：将用户输入分发给适当的处理程序，并将输出路由回去
- 并行执行：支持单个工作区内的多个并发会话
- 状态持久化：为长期运行的任务保存和恢复 Session 状态的能力
Agent 层
Agent 层实现了系统的推理和决策能力，体现在 MCPlato 的 ClawMode 自主执行引擎中。
关键能力：
- 自主执行：ClawMode 使 Agent 能够独立工作，在没有持续用户输入的情况下做出决策
- 任务规划：将复杂目标分解为可执行步骤，具有依赖管理
- 多 Session 协调：为并行或顺序执行跨多个 Session 编排工作
- 自我改进：从执行模式学习和优化未来行为的能力
4.2 Harness 集成特征
MCPlato 的 Harness 层以几个关键设计决策为特征：
MCP 原生支持
与其他将 MCP 支持作为插件或扩展添加的系统不同，MCPlato 将 MCP 实现为核心架构原则：
- 内置 MCP Host：支持 stdio 和 HTTP 传输的完整 MCP Host 实现
- 动态服务器管理：运行时添加、删除和配置 MCP 服务器
- 能力发现：可用工具、资源和提示的自动检测和公开
- 热加载：无需重启应用即可添加新 MCP 服务器
内置工具套件
除了 MCP，MCPlato 提供为生产力工作流设计的完整工具集：
| 工具类别 | 能力 |
|---|---|
| @Tool 套件 | 文件操作、bash 执行、代码编辑、网络搜索 |
| 信息图表 Creator | 数据可视化、图表生成、图表创建 |
| 浏览器自动化 | 网络导航、表单填充、截图、元素交互 |
| 图像工具 | 生成（多个模型）、编辑（内画/外画）、合成、风格转移 |
| 文档工具 | PDF 分析、OCR、结构化提取、格式转换 |
内置套件中的每个工具都遵循与 MCP 工具相同的接口标准，确保无论使用原生能力还是外部服务器，行为都一致。
动态工具发现
Harness 层实现了复杂的工具发现机制：
- 运行时内省：工具动态声告其能力、参数和要求
- 语义匹配：Agent 可以基于自然语言需求描述发现工具
- 版本管理：支持相同工具的多个版本，具有优雅的弃用
- 依赖解决：自动处理工具依赖和先决条件检查
4.3 Agent 能力
MCPlato 的 Agent 层（ClawMode）实现了几个高级能力，将其与更简单的聊天界面区分开：
任务规划和分解
当面对复杂目标时，Agent：
- 分析目标以识别所需的步骤和依赖关系
- 为每个步骤选择适当的工具
- 建立成功标准和检查点
- 创建可恢复的执行计划，可以在中断后存活
多 Session 协调
Agent 可以跨多个会话编排工作：
- 并行执行：在单独的会话中运行独立的子任务
- 顺序管道：链接会话，其中一个的输出成为另一个的输入
- 跨 Session 内存：在会话之间共享相关上下文，同时维护隔离
长期运行任务支持
MCPlato 支持超越单个交互的任务：
- 计划执行：基于 Cron 和周期性任务调度
- 检查点和恢复：在任务边界处保存状态以供恢复
- 进度报告：长期运行操作的实时更新
- 人类在循环中：需要人类判断的决策的适当升级点
5. 竞争架构比较
为了理解 MCPlato 的架构选择，将它们与 AI Agent 景观中的其他系统进行比较很有用。下表总结了关键的架构差异：
| 产品 | Harness 设计 | Agent 设计 | 架构特征 |
|---|---|---|---|
| Claude Code | 内置工具 + MCP 支持 | 单个 Agent，长期运行的会话 | Agent-Harness 集成的先驱；以终端为中心；CLAUDE.md 用于内存 |
| Cursor | MCP 生态系统 + 内置编辑器工具 | Agent 2.0 具有自主能力 | Agent 优先的 IDE；用于多文件更改的 Composer；并行 Agent 执行（最多 8 个） |
| OpenClaw | 工具沙箱 + Skills 框架 | 分层多 Agent 设计 | 开源框架；多渠道访问的网关层；自托管 |
| Devin | 云集成工具套件 | 端到端工程 Agent | Agent 原生 IDE；完整云沙箱；SWE-bench 优化 |
| MCPlato | 内置工具 + MCP 原生 Host | ClawMode 自主执行 | 三层解耦架构；本地优先；完整工具链 |
5.1 设计选择分析
Claude Code 强调简洁性和与现有开发者工作流的集成。其 Harness 精简，专注于基本的文件和终端操作。Agent 层维护一个单一的长期运行会话，简化上下文管理，但限制并行化。
Cursor 强调 IDE 上下文中的开发者生产力。其 Harness 利用编辑器现有的能力，同时添加 MCP 支持以实现可扩展性。Agent 2.0 架构在代码编辑的有界上下文内引入自主性。
OpenClaw（MCPlato 的开源基础）通过其网关-Agent-Tools 层次结构提供最大灵活性。作为框架而不是产品，它优先考虑可配置性而非开箱即用的体验。
Devin 代表云原生极端：整个环境是虚拟化和托管的。这启用了强大的能力，但需要向云基础设施献出控制权。
MCPlato 占据独特的位置：它结合了 OpenClaw 的灵活性与产品级的精良，添加了本地优先原则，并实现了一个清晰分离关注点的三层架构。
5.2 关键区别
| 维度 | MCPlato 优势 |
|---|---|
| 架构深度 | 三层设计（工作区-Session-Agent）vs 两层或平面设计 |
| MCP 集成 | 原生 Host 实现 vs 附加支持 |
| 本地优先 | 完整本地工具链 vs 云依赖或沙箱限制 |
| 工具完整性 | 内置图像、文档、信息图表和浏览器工具，超越基本文件操作 |
| 内存架构 | 三层持久化（工作区/Session/日记）vs 单上下文或手动内存文件 |
| 调度 | 原生基于 cron 的调度 vs 外部调度器依赖或无支持 |
6. 架构设计原则和最佳实践
基于 MCPlato 和可比系统的分析，我们可以提炼用于设计有效 Harness-Agent 架构的几个原则：
6.1 原则 1：分层解耦
Harness 和 Agent 层应该有清晰、稳定的接口。
- 定义层之间的显式合约（如 MCP 的协议提供这些）
- 避免跨层边界泄露实现细节
- 启用每层的独立测试、部署和演进
- 抵制"便利"的诱惑，模糊层责任
6.2 原则 2：标准优先
在构建自定义解决方案之前采用开放标准。
- MCP 等标准提供即时的生态系统利益
- 自定义协议创建技术债务和集成挑战
- 标准来自集体智慧——尊重那些累积的知识
- 贡献于标准演进而不是不必要地分叉
6.3 原则 3：动态发现
工具应该在运行时可发现，而不是硬编码。
- Agent 应该适应可用的工具，无需代码更改
- 工具清单应包括丰富的元数据（描述、参数、示例）
- 支持热加载以实现零停机工具更新
- 通过标准接口启用工具链接和合成
6.4 原则 4：安全隔离
工具执行应该是沙箱化和策略执行的。
- 假设 Agent 可能出错或被误导
- 实现深层防御：在多层验证
- 使用最小权限原则——工具仅获得它们需要的权限
- 为安全敏感操作提供清晰的审计跟踪
6.5 原则 5：状态持久化
长期运行的任务需要稳健的状态管理。
- 为中断进行设计——任务将被暂停、杀死或失败
- 在任务边界处实现检查点/恢复机制
- 将短暂状态与持久状态分离
- 当状态丢失时启用优雅降级
6.6 最佳实践检查清单
在实现 Harness-Agent 架构时，考虑：
- 工具定义：工具是否良好记录，具有清晰的架构和示例？
- 错误处理：工具是否提供可操作的错误消息和恢复建议？
- 可观察性：你能追踪从 Agent 决策到 Harness 执行的请求吗？
- 速率限制：是否有防止意外滥用或无限循环的保护？
- 用户控制：用户能否检查、批准或覆盖 Agent 工具选择？
- 备用策略：当首选工具不可用时会发生什么？
- 资源清理：临时文件、连接和进程是否正确释放？
7. 结论：架构作为竞争优势
当我们展望 AI 系统的未来时，清晰的模式出现：模型能力正在商品化，但架构卓越仍然是持久的竞争优势。
7.1 模型能力平台
边界模型和有能力的开源替代品之间的差距正在缩小。蒸馏、量化和高效训练等技术正在民主化对强大推理能力的访问。在几年内，"模型质量"将对大多数应用而言是一个已解决的问题。
不会被解决的是集成挑战——将这些强大的模型连接到混乱、异构的企业系统、个人工作流和外部数据源现实。这是架构的领域。
7.2 Harness 可靠性作为决定性因素
当模型"足够好"时，决定性因素变成：
- 可靠性：系统是否在不同情景中一致工作？
- 安全性：用户能否相信系统处理他们的数据和系统？
- 可扩展性：系统是否能适应新需求而无需重新设计？
- 可观察性：操作者能否理解和调试系统行为？
这些是架构关注点，不是模型关注点。Harness 层就是解决这些关注点的地方。
7.3 MCP 和工具访问的统一
MCP 代表了 AI 架构中的关键时刻——真正标准的出现以实现工具集成。随着 MCP 采用的增长，我们可以期待：
- 可用工具的爆炸性增长（每个 SaaS 产品、数据库和 API 都变成 AI 可访问的）
- AI 平台之间在编排质量而不是集成数量方面的竞争增加
- 专业化 Harness 提供者的出现（安全专注、性能优化、领域特定）
7.4 从单 Agent 到多 Agent 协作
当前一代 AI 系统主要将 Agent 视为单一实体。下一代将拥抱多 Agent 架构，其中专业化 Agent 在复杂任务上协作：
- 研究 Agent 收集和综合信息
- 规划 Agent 分解目标和分配资源
- 执行 Agent 与特定系统和工具交互
- 审查 Agent 验证质量并捕获错误
这些多 Agent 系统将需要复杂的 Harness 层，能够：
- Agent 间通信和协调
- 跨 Agent 边界的共享上下文管理
- Agent 不同意时的冲突解决
- 资源分配和优先级设置
MCPlato 的三层架构——具有工作区、Session 和 Agent 关注点的清晰分离——为这个多 Agent 未来提供了基础。
7.5 最后的想法
从"模型优先"到"架构优先"思维的转变代表了 AI 领域的成熟。我们正从演示什么是可能的时代转向交付什么是可靠的时代。
对于今天构建 AI 系统的从业者，教训很明确：投资你的 Harness 层。设计良好的 Harness 将比你当前的模型提供者活得更长，适应新用例，并为尚未想象的能力提供基础。
MCPlato 的架构——MCP 原生、三层解耦、本地优先——代表了这个基础看起来像什么的一个愿景。这不是唯一有效的方法，但它演示了将指导成功 AI 架构未来几年的原则。
架构优先的 AI 时代已经开始。
FAQ
Q：什么是 AI 系统中的 Harness 层？
Harness 层（工具层）负责工具封装、执行编排、验证和保护、内存管理。它将外部能力（文件、API、搜索）包装成可调用的 Tools/Skills，处理模型推理之外的所有功能，包括安全沙箱、错误处理和结果格式化。
Q：MCPlato 如何实现 Harness-Agent 架构？
MCPlato 实现了三层架构：工作区层用于工作区管理和隔离，Session 层用于上下文维护和消息分发，Agent 层用于 ClawMode 自主执行。它提供原生 MCP Host 能力、内置工具集包括 @Tool、信息图表、浏览器、图像和文档工具，支持动态工具发现和热加载。
Q：什么是 MCP，为什么它很重要？
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月发布的开放标准。它作为 AI 应用和外部系统之间的通用接口，无需为每个数据源构建单独的连接器。MCP 定义了三个核心原语：Tools（可执行函数）、Resources（数据源）和 Prompts（交互模板）。
Q：为什么 Harness 层比模型本身更重要？
超过一定阈值后，模型能力变得商品化。Harness 层的可靠性、安全性和工具集成质量成为生产 AI 系统的决定性因素。设计良好的 Harness 能够实现安全、可靠的工具使用，无论底层模型如何，都提供一致的接口。
Q：设计 Harness-Agent 架构的关键原则是什么？
关键原则包括：(1) 分层解耦，明确分离 Harness 和 Agent 的责任，(2) 标准优先采用 MCP 等协议，(3) 动态发现用于运行时工具注册，(4) 通过沙箱执行实现安全隔离，(5) 长期任务的状态持久化。
Q：MCPlato 与 Claude Code 和 Cursor 有什么区别？
MCPlato 通过以下方式区分自己：(1) 三层架构 vs 两层设计，(2) 原生 MCP Host 实现 vs 附加支持，(3) 本地优先具有完整的本地工具链，(4) 内置图像、文档、信息图表和浏览器工具，(5) 三层内存架构，(6) 原生调度能力。
Q：AI 系统架构的未来方向是什么？
该行业正在从单 Agent 向多 Agent 协作转变，从模型中心设计向架构中心设计，从专有集成向 MCP 等标准化协议转变。未来系统将强调可靠性、可观察性和可扩展性作为主要设计目标。