← Harness 图谱

⚠ 但先得说清一件事：官方已明确把公司重心从「编排框架」移走了。

模型与开放条件

官方给的数字最激进，但形态是「300+ 分散的集成包」而不是统一网关。 README 原文："There are over 300 LlamaIndex integration packages that work seamlessly with core, allowing you to build with your preferred LLM, embedding, and vector store providers." 命名空间约定值得记（README 给的代码示例说明）： from llama_index.core.xxx import ClassABC 是核心， from llama_index.xxx.yyy import SubclassABC 是集成包 —— 带 .core 意味着用核心，不带意味着用集成。 ⚠ 未核验：300+ 集成包的质量分层与维护状态。 这一点对选型很关键 —— 官方原话是"work seamlessly"， 但本站未实测过任何跨 provider 的能力对齐度。

运行位置

纯库，且有两个安装档位（官方 README 明示，这是它少见的清晰之处）。 ① Starter：llama-index（PyPI）—— 核心 + 一批常用集成的合集； ② Customized：llama-index-core —— 只装核心，再按需从集成页挑包 （README 说有 300+ 个集成包可选）。 ⚠ 一个必须指出的定位缺口：README 里没有 CLI 启动命令、没有 Web UI、 没有容器部署示例 —— 至少在本次核验的 223 行 README 里没有。 它是库，不是平台。 ⚠ 未核验：官方推荐的部署形态（对比本站收录的 Google ADK 有 adk deploy docker/cloud_run、 OpenHands 有四种部署形态）。

本地文件

⚠ 这是 LlamaIndex 的真正主场，但不是「agent 读文件」意义上的本地文件。 README 的Proposed Solution 第一条原文："Offers data connectors to ingest your existing data sources and data formats (APIs, PDFs, docs, SQL, etc.)"。 即它的文件能力是批量接入与解析数据源，不是「让 agent 在工作区里改文件」那套。 ⚠ 本站要提醒的区分：这一点很容易与 Deep Agents 的 filesystem（agent 工作区文件操作）混为一谈 —— 两者是不同的东西。 本地模型侧：它有 LiteParse 项目（官方定位为「free, fast, cheap text parser」， 独立仓 run-llama/liteparse），⚠ 该项目与框架的集成方式本站未核验。

关机后的任务

⚠ 本站最看重的一维，而这里有一个必须说清的事实：编排能力已被移出 OSS。 README 里Workflows 只出现在商业平台那一节： "Agents — Build end-to-end document agents with Workflows and Agent Builder" （链接指向 developers.llamaindex.ai/python/llamaagents/overview）。 OSS 那节（Proposed Solution）谈的是数据接入、结构化、检索接口、应用集成， 没有提后台任务、定时、队列或跨进程恢复。 ⚠ 未核验：OSS 的 llama-index-core 里是否仍有 workflow / agent 编排模块 （README 首屏也提到"the framework has consisted of a broad set of orchestration tools"， 说明历史上是有编排工具的，但当前 OSS 那部分剩多少，本次无法从 README 判断）—— 这是本条最需要补核验的一项。

工具与扩展

300+ 集成包是它的绝对优势，也是它的维护负担。 官方给的 import 示例本身就是工具接入范式（核心类 + 集成子类）。 ⚠ 未核验：MCP 支持情况 —— 本次核验的README 里没有出现 MCP。 本站因此不把它与本站 MCP 站的 9 个官方 server 关联。 ⚠ 未核验：300+ 集成包里的官方 vs 社区比例与维护活跃度分层。

上下文与记忆

⚠ 本维度有明确官方表述，且与本站主张直接相关。 README 对整个框架的定位原句："LlamaIndex is a "data framework" to help you build LLM apps" 以及 "Provides ways to structure your data (indices, graphs) so that your data can be easily used with LLMs"、"an advanced retrieval/query interface over your data"。 本站的判断（推断）：它处理的是「把外部数据变成可检索的上下文」， 这在本站的坐标系里属于上下文获取层，而不是上下文压缩层。 ⚠ 未核验：检索结果如何裁剪以适配上下文窗口、 是否有明确的压缩/摘要机制（README 未提及任何压缩手段）。

权限与限制

⚠ 本站明确的重大信息缺口，选型前必须自己确认。 README 全文没有任何沙箱、文件权限模型、网络访问控制或人工确认机制的表述。 与本站收录的其它编排框架对照： Google ADK 有 Tool Confirmation（HITL）、CrewAI 有 guardrails（机制未说明）、 LangGraph 有 interrupts（可检查并修改状态）—— LlamaIndex 在这一维度上 README 里连一个名词都没有。 ⚠ 需特别注意：由于它的主战场是文档解析与 RAG， 它处理的通常是用户上传的数据，这本身是一个与「agent 动你本地文件」性质不同的风险面， 但 README 未讨论数据权限与隔离。

适合什么任务

适合：核心任务是把外部数据源（API / PDF / 文档 / SQL）接进来做检索与问答， 且需要 300+ 现成集成里的某一个；团队 Python 栈； 或明确要用 LlamaParse 的解析能力（那走商业平台）。 不适合：主要目的是「多 Agent 编排 / 工作流」—— 那部分能力现在在商业平台 LlamaAgents； 需要 agent 在工作区里读写文件（那是 Deep Agents 那一类，不是 LlamaIndex）； 需要明确沙箱与权限边界（README 无任何表述）； 需要长任务的上下文压缩机制（未核验）。

本页由 ai-coding-agent-atlas 数据层生成（CC BY 4.0）。 方法论与坐标系定义见仓库内 METHODOLOGY.md。