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