← Harness

模型与开放条件Model & openness

接入方式是「300+ 分散的集成包」，不是统一网关。

• 官方在 integrations 页统称它们 "community integrations"（社区集成）
• 也就是说，多数由社区维护，不是官方自己一个个养

"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."

命名空间规则一眼能记住：

• 带 .core 的（from llama_index.core.xxx）是核心
• 不带的（from llama_index.xxx.yyy）是集成包

新集成要过维护者审核。

README 写明："some integrations may be declined"。

未知：官方未公布集成包的质量分层与维护活跃度分级。 （已查 README 与 integrations 页。）

运行位置Where it runs

OSS 形态是纯库，有两个安装档位；托管运行在商业平台那一侧。

安装档位有两个（README Getting Started）：

• Starter —— llama-index（PyPI）：核心 + 一批常用集成的合集
• Customized —— llama-index-core：只装核心，再按需从集成页挑包

框架本身是被 import 的库。 接入方式是跟外部应用框架对接， 这也是 README Proposed Solution 第四条：

"integrations with your outer application framework"

官方另有一套托管 / 部署路径。LlamaAgents 的 llamactl CLI 可以这样用：

官方原文："serve locally, and deploy to LlamaCloud or export for self-hosting"

LlamaCloud 另有托管 Index。

• 托管是 LlamaCloud / LlamaAgents 那一层（商业）
• 它不是 OSS 自带的运行形态

本地文件Local files

它读本地文件是为了建索引，不是给 agent 一个工作区。

官方 SimpleDirectoryReader 文档把这句说得很直白：

"the simplest way to load data from local files into LlamaIndex"

可传的参数：

• input_dir、recursive=True
• exclude、required_exts、num_files_limit
• 远程文件系统走 fsspec（S3、GDrive 等）

索引默认存内存。 两个官方示例动作：

• 落盘：index.storage_context.persist() 写到 ./storage
• 重载：load_index_from_storage

本站记这一轴用的是「索引层视角」。

它不是「agent 工作区」文件系统。 而是「数据源接入 + 索引」层的本地文件读取。

它读盘是为了把文档变成可检索的索引。 这与 Deep Agents 那种「agent 在工作区里改文件」不是一回事。

关机后的任务Tasks after shutdown

它没有「关机后继续跑」的托管执行。 但编排（Workflows）确实还在 OSS 里。

有一处容易被 README 误导。 README 把 Workflows 列在 LlamaParse 平台的 Agents 节，官方框架文档却说得很清楚：

"llama-index-core comes with a stable version of Workflows included"

也就是说编排没被移出 OSS。两个入口：

• import 路径 llama_index.core.workflow
• 也可独立 pip install llama-index-workflows

后台执行这一项是缺的。 官方框架文档未提供「关机续跑」的托管运行时， 进程要你自己跑。需要托管时走 LlamaAgents / llamactl：

"deploy them to LlamaCloud or your own infrastructure"

而那是平台侧。

工具与扩展Tools & extensions

工具层两件事：社区 ToolSpec，加一个官方的 MCP 接入包。

官方 tools 文档给了 FunctionTool。 还有 QueryEngineTool。

另有 "Community contributed ToolSpecs"。

处理「工具返回超大输出」的是 Utility Tools：

• OnDemandLoaderTool
• LoadAndSearchToolSpec

MCP 官方支持，而且是独立包。 文档原文："LlamaIndex provides robust support for consuming MCP servers through the llama-index-tools-mcp package"

它的 MCP 面：

• 三种传输都支持：SSE / Streamable HTTP / stdio
• 能把 Workflow 反发布为 MCP server
• 官方另托管 mcp.llamaindex.ai（文档检索 / LlamaParse 的 MCP 服务）

上下文与记忆Context & memory

这一维度官方有具体机制，不是空白。

官方把框架叫 "data framework"。

核心是 structure your data（indices, graphs）。 再加 retrieval/query interface。

也就是「把外部数据变成可检索的上下文」。

检索结果怎么塞进上下文窗口？ 官方用 Response Synthesizer 回答：

• compact（默认）—— "stuff as many text ... that can fit within the context window"
• refine —— 逐块精炼
• tree_summarize —— 递归摘要
• simple_summarize —— 截断到单 prompt

这就是它的上下文裁剪与摘要机制：先按窗口装箱，装不下再切块，摘要类模式做压缩。

权限与限制Permissions & limits

⚠ 这是一个明确的重大信息缺口，选型前必须自己确认。

官方 README 全文没写的东西：沙箱、文件权限模型、 网络访问控制、人工确认机制 —— 一个都没有。

与本站收录的其它编排框架对照：

• Google ADK 有 Tool Confirmation（HITL）
• CrewAI 有 guardrails（机制未说明）
• LangGraph 有 interrupts（可检查并修改状态）
• LlamaIndex —— README 全文里连一个名词都没有

⚠ 风险面的性质不一样。 它的主战场是文档解析与 RAG， 处理的通常是用户上传的数据。

这与「agent 动你本地文件」是两类风险（数据泄露面 vs 主机操作面）。

但 README 未讨论数据权限与隔离。

适合什么任务Best for

适合：把外部数据接进来做检索问答。

• 核心任务是把外部数据源（API / PDF / 文档 / SQL）接进来做检索与问答
• 需要 300+ 现成集成里的某一个
• 团队是 Python 栈
• 明确要用 LlamaParse 的解析能力（那走商业平台）

不太适合三种情况。

• 需要 agent 在自己项目目录里读写文件并跑命令 —— 那是 Deep Agents 那一类「工作区文件系统」
• 需要明确的沙箱与权限边界 —— 官方框架文档无此类机制
• 需要「关机后托管续跑」—— 走 LlamaAgents 平台侧

本页由This page is generated from the ai-agent-guide 数据层生成（CC BY 4.0）。data layer (CC BY 4.0). 方法论与坐标系定义见仓库内 METHODOLOGY.md。