AI Agent 框架、平台、Runtime、Harness 和 MCP 到底有什么区别？
框架、平台、运行时、Harness 和 MCP 都在介绍页里出现，但它们不负责同一件事。本文用控制流、状态、执行环境和工具边界给出一张可落地的区分表。
本文索引06
如果你搜索 AI Agent framework、platform、harness 或 MCP，很容易看到一堆产品都声称自己提供 Agent、Tools、Memory 和 Multi-Agent。它们看起来像竞品，实际往往处在不同层。
先给结论：框架主要组织应用代码，平台主要交付应用能力，Runtime 负责运行过程，Harness 把模型、工具、权限和执行环境装进一个可工作的系统，MCP 则是连接工具与模型的协议。 这些层可以组合，不需要互相替代。
一张边界表
| 层 | 它主要负责什么 | 你真正要问的问题 | 它不应该承诺什么 |
|---|---|---|---|
| Agent framework | 组合节点、状态和调用逻辑 | 这段 Agent 流程如何编排和测试？ | 自动解决部署、权限与所有运行时故障 |
| Agent platform | 提供应用搭建、数据接入、发布和运营入口 | 团队怎样把 Agent 交付给用户？ | 用一个模板适配所有开发和部署边界 |
| Runtime / orchestration | 管理循环、事件、重试、恢复和调度 | 任务中断后从哪里继续？ | 仅靠一个 Memory 开关保证连续性 |
| Agent harness | 把模型、工具、权限、环境、上下文和交互组成完整工作系统 | 谁决定工具能否执行、结果如何回到模型？ | 让模型自动拥有安全隔离或正确答案 |
| MCP | 描述模型如何发现和调用外部工具 | 工具如何被不同客户端接入？ | 代替 Agent Loop、审批、部署和业务状态 |
边界不是绝对的。同一个项目可以同时提供 SDK、Runtime 和平台；这里按“最重要的责任”区分，目的是避免拿 Star 数或首页功能列表做错误比较。
Framework 和 Platform：写代码，还是交付应用？
框架通常从开发者的代码开始。你定义节点、状态、工具调用和分支，测试重点是流程是否按预期运行。它适合需要自己掌握控制流、数据结构和部署方式的团队。
平台则把更多交付工作包装起来：可视化流程、知识库接入、用户管理、发布入口、日志或计费可能都在同一套产品里。平台的价值不是“比框架更智能”，而是让一支团队少拼一些基础设施。
两者的选择可以很简单：如果你要把 Agent 嵌进自己的系统，先看框架的状态和工具边界；如果你要让非工程用户配置和使用它，先看平台的发布、权限和运维边界。不要因为两边都写着 multi-agent 就把它们当成同一种产品。
Runtime 和 Harness：为什么经常被混用？
Runtime 更像“过程管理器”。它关心一轮调用怎样开始、事件怎样记录、失败怎样恢复、多个 Agent 怎样协作。Harness 更像“完整承载系统”：除了循环，还要决定文件能不能读、命令怎样执行、危险操作是否需要批准、工具结果怎样回到上下文，以及任务运行在哪个环境里。
这也是为什么同一个模型换一个 Harness，长任务表现会变化。模型决定一次推理能走多远；Harness 经常决定任务是否能在崩溃、超时、权限拒绝或上下文变长以后继续完成。
最近公开的 DeepSeek Harness 分析值得作为一个边界案例阅读：它把模型适配器、工具注册、事件日志，甚至 Agent Loop 都放在插件边界里。这个设计很有启发，但项目仍是 Developer Preview，不能把可替换架构当成成熟度或安全性的证明。
MCP 到底处在哪一层？
MCP 解决的是连接问题。客户端可以通过统一的协议发现工具、读取资源、发起调用，而工具提供方不必为每个模型客户端写一套完全不同的接口。
但 MCP 不会替你决定：
- 任务该不该调用工具；
- 多次调用如何去重或恢复；
- 危险操作由谁审批；
- 大结果是否应该压缩、分页或保留原文；
- 一个业务任务的状态和验收条件存在哪里。
因此，一个 MCP Server 可以是 Harness 的工具层，也可以被多个不同 Runtime 使用。把 MCP Server 叫成“完整 Agent 框架”，通常是在把协议、工具实现和编排系统混成一件事。
五个问题，够你做第一次选型
- 谁控制流程？ 如果流程需要明确分支、重试和人工审批，先看 framework 或 orchestration 能力。
- 任务怎样恢复？ 问清事件、状态和幂等边界，不要只看有没有
memory字段。 - 谁执行真实动作？ 文件、Shell、浏览器、数据库和外部 API 的权限边界，通常属于 Harness 或 Host。
- 工具怎样接入？ 需要跨客户端复用时看 MCP；只在一个应用内使用时，普通函数或内部 API 可能更简单。
- 结果怎样回到上下文？ 搜索、日志和数据库结果都可能很大，先看来源、失败状态、大小预算和恢复方式。
如果第五个问题是你的痛点，可以继续看 Agent Search MCP 产品页：它处在“搜索工具服务 + MCP 接口”这一层，不是一个替代全部 Agent Runtime 的框架。源代码、测试和当前能力边界以 lennney/agent-search-mcp 为准。
最后：先画责任，再看产品名
选择顺序可以压缩成一句话：先画出控制流、状态、权限、执行环境和工具协议，再看哪个项目刚好承担这些责任。生态全景页适合回答“有哪些层和项目”，2026 年 AI Agent 框架选型指南适合回答“哪个方案更适合我的流程”。
这个分类不是排行榜，也没有证明某一层一定比另一层好。产品会继续合并职责，协议也会继续变化。真正可复用的判断，是知道你正在购买、引入或自己实现的到底是哪一条责任边界。