手把手搭建个人Agentic系统：LLM就是新CPU

2026-06-30

为什么你需要自己的Agentic系统
一个大 Prompt 搞不定一切
LLM OS 架构揭秘
实战：用 LLMlight 搭建多Agent系统
什么时候该用 Agentic 系统？
值得关注的细节

为什么你需要自己的Agentic系统

如果你还在把 ChatGPT 当写作工具用，你可能已经错过了最本质的变化。LLM 的真正角色不是「生成器」，而是计算核心。Andrej Karpathy 提出的 LLM Operating System（LLMos） 框架给出了一个非常直观的类比：

传统计算机	LLMos
CPU	大语言模型（LLM）
字节	Token
RAM	上下文窗口
硬盘	检索系统
软件接口	Prompt

这个类比揭示了 Agentic 系统的核心思想：你的 LLM 不是一个写手，而是一个 CPU。 Token 就是新的字节，上下文窗口就是新的内存。当我们摆脱「用 LLM 写文章」的思维，进入「用 LLM 做计算」的范式，视野就完全不一样了。

当然，挑战也随之而来。小模型虽然有隐私、便携和成本优势，但上下文窗口更小、推理能力有限。在本地跑 Agentic 系统面临的问题包括：Agent 之间如何通信？哪些任务应该用确定性逻辑、哪些用概率模型？如何防止幻觉？如何保证评分的一致性？

这些问题的答案，不在于某个精巧的单条 Prompt，而在于精心设计的流水线——分块策略、检索系统、嵌入模型、排序机制、结构化 Prompt、评分工作流、多个专业化 Agent 的协同。这就是本篇文章要讲的内容。

一个大 Prompt 搞不定一切

一个常见的错误是：把整份文档丢进 LLM，期望它一次搞定所有事情。这种「单片式」方法有四个根本性缺陷：

上下文窗口饱和。 即使模型支持 200K 的上下文，当文档内容、系统指令、评分标准、输出格式约束全部塞进去，关键信息会被隐式压缩或忽略，推理结果自然不如人意。

任务纠缠。 一次 Prompt 要求模型同时执行完全不同的认知操作——提取数据、解释上下文、应用规则、保持跨段一致性、生成结构化反馈。没有机制的分离，输出必然浅层或自相矛盾。

结构缺失。 单次 Prompt 输出一个结果，没有中间检查点，没有推理步骤。如果最终答案不对，你无法追踪断链的位置。这使得系统几乎不可调试、不可验证。

Prompt 不稳定。 哪怕措辞的微小变化，也可能显著改变评分和反馈质量。

复杂任务的本质是迭代式的——需要阅读、交叉引用、验证、修正判断。把所有这些步骤压缩成一次变换，就移除了人脑判断时天然依赖的结构。解决方案是把大系统分解成更简单的部件：多个小型本地 LLM 各自承担专门任务，协同完成复杂目标。

LLM OS 架构揭秘

如果我们把 LLM 视为新计算范式的 CPU，那么围绕它需要构建完整的外设系统：

上下文窗口 = RAM。 这是临时工作内存，容量有限，读写速度快。当文档超过窗口大小时，就需要外部的存储和检索机制来补充。

检索系统 = 硬盘。 RAG（检索增强生成）就是你的外部存储。通过嵌入模型将文档向量化，形成可搜索的知识库。查询时找到最相关的片段，再注入上下文窗口。

Agent = 专用处理器。 每个 Agent 是一个小型 LLM，配以专门的指令和任务定义。一个 Agent 负责检索，一个负责质量评估，一个负责结构化输出，一个负责最终总结。它们通过结构化的通信协议协同工作。

Prompt = 软件接口。 就像操作系统为应用程序提供 API 一样，LLMos 中的 Prompt 是组件之间的标准化通信协议。结构良好的 Prompt 就像定义良好的 API 契约。

实战：用 LLMlight 搭建多Agent系统

现在进入动手环节。我们将使用 Python 库 LLMlight 构建一个轻量级的多 Agent 系统，全部在本地运行，保护你的数据隐私。

安装与环境准备

pip install llmlight
# 或者如果使用 uv
uv pip install llmlight

LLMlight 的核心理念是「用结构化 Prompt 把小型本地模型组织成团队」。它内置了对 Ollama、llama.cpp 等本地推理引擎的支持。

核心架构

一个典型的 LLMlight 系统包含以下组件：

主控制器（Orchestrator）
  ├── 检索 Agent：从文档库中找到相关信息
  ├── 推理 Agent：对检索结果进行分析和推理
  ├── 评分 Agent：评估输出质量和一致性
  └── 输出 Agent：格式化最终结果

基本用法示例

from llmlight import AgenticSystem, Agent

# 创建一个检索 Agent
retriever = Agent(
    name="retriever",
    model="qwen2.5:7b",  # 可使用任何 Ollama 支持模型
    system_prompt="你是一个文档检索专家。从给定的知识库中找到与用户问题最相关的信息。",
    temperature=0.1
)

# 创建一个推理 Agent
reasoner = Agent(
    name="reasoner",
    model="qwen2.5:7b",
    system_prompt="你是一个分析推理专家。基于检索到的信息，进行逻辑分析和推理。",
    temperature=0.3
)

# 组建系统
system = AgenticSystem(
    agents=[retriever, reasoner],
    orchestrator_model="qwen2.5:14b"  # 控制器可用稍大的模型
)

# 执行任务
result = system.run("分析这份技术文档中的安全风险")

RAG 集成

要让系统能处理私有文档，需要集成检索增强生成：

from llmlight import VectorStore, Chunker

# 文档分块
chunker = Chunker(chunk_size=512, overlap=64)
chunks = chunker.chunk(document_text)

# 构建向量存储
store = VectorStore(embedding_model="bge-small-zh-v1.5")
store.add_documents(chunks)

# 在 Agent 中使用
retriever.with_retrieval(store, top_k=5)

评分与验证机制

一个常被忽略但至关重要的组件是评分 Agent。它的任务是在最终输出之前，对推理结果进行质量检查：

scorer = Agent(
    name="scorer",
    model="qwen2.5:7b",
    system_prompt="""评估以下分析的质量，从三个维度打分（1-10）：
1. 事实准确性：与检索到的信息是否一致
2. 逻辑连贯性：推理过程是否清晰
3. 完整性：是否覆盖了关键方面
返回 JSON 格式评分结果。""",
    temperature=0.1,
    output_format="json"
)

评分 Agent 的存在让系统从「黑箱输出」变成了「可审计的流程」。如果某个输出分数低于阈值，系统可以自动触发重试或回退到更保守的策略。

上下文管理策略

本地模型的一个主要限制是上下文窗口较小。以下是一些实用的管理策略：

分层检索：先检索文档摘要，再根据相关性深入检索详细内容
滑动窗口：对长文档使用滑动窗口 + 交叉引用的方式分段处理
摘要压缩：对中间结果进行摘要化处理，减少 token 消耗
优先级队列：根据相关性评分动态管理上下文中的段落优先级

# 分层检索示例
summary_agent = Agent(name="summarizer", ...)
detail_agent = Agent(name="detail_analyzer", ...)

# 第一层：获取文档概要
summary = summary_agent.run("总结本文档的核心内容")

# 第二层：基于概要定位关键段落
key_sections = retriever.search(summary, top_k=3)

# 第三层：深入分析选定段落
analysis = detail_agent.run(key_sections)

什么时候该用 Agentic 系统？

Agentic 系统不是万能的。在以下场景中收益最大：

✅ 适合用的场景：

需要处理大量文档的分析和结构化输出
任务需要多步推理和验证
对输出一致性和可审计性有要求
需要结合私有知识库的问答系统

❌ 不适合的场景：

简单的单次问答（一个 Prompt 就够）
对延迟敏感的场景（多 Agent 通信有额外开销）
需要 100% 确定性的场景（概率模型永远有不确定性）

值得关注的细节

最让我在意的一个判断是：Agentic 系统的价值不在模型参数量的增加，而在工程架构的精细度。 很多人以为多 Agent 就是多调几个 API，真正困难的地方在于：分块策略如何设计？嵌入模型怎么选？Agent 之间如何通信？失败重试怎么做？评分阈值设多少？

另一个容易被忽略的问题是：小模型组队 > 大模型单挑。 实验表明，3-4 个 7B 参数的模型组成的 Agent 团队，在很多任务上的表现可以超过单个 70B 模型，而且成本更低、速度更快、可解释性更好。这是因为每个小模型专注于特定任务，避免了认知资源的稀释。

不过我也注意到一个需要谨慎的地方：Agent 之间的通信增加了系统的延迟和不确定性。 每一次 Agent 调用都可能引入新的波动，需要设计完善的验证和回退机制。

目前我的判断是：Agentic 系统是当前 AI 应用最有价值的范式之一。它把 LLM 从「聊天工具」提升到了「计算平台」的层面。但工程化的成熟度还远不如传统软件——可观察性、调试工具、标准化协议都还在早期。如果你愿意投入精力打磨流水线，这可能是 2026 年回报率最高的 AI 技能投入。

版权所有，本作品采用知识共享署名-非商业性使用 3.0 未本地化版本许可协议进行许可。转载请注明出处：https://www.wangjun.dev//2026/06/personal-agentic-system-guide/