置顶

RAG 与 Agent 工程系列总目录

2026/09/10 15:00

CrewAI 适合什么:角色、任务和 Crew 编排

这篇解决什么 CrewAI 解决的是「按角色分任务」的 Multi-Agent,不是通用图编排。核心对象只有三个:Agent(角色、目标、工具)、Task(要交付什么)、Crew(谁和谁、按什么流程跑)。原先这篇是空草稿,并进这一条,不再另开标题。 先写角色边界,再写 Crew 每个 Agent 只

CrewAI 适合什么:角色、任务和 Crew 编排
LangGraph 管什么:State、边和人机协同

LangGraph 管什么:State、边和人机协同

LangGraph 通过图结构系统性管理循环、分支、中断和恢复场景,核心包含共享状态(State)、可执行节点(Node)和条件边(Edge)。State以TypedDict实现多轮共享数据,Node定义模型/工具调用或状态修改,Edge区分固定路径和需模型决策的分支。相比LangChain的链式结构,LangGraph更适合需人工干预或多状态分支的流程。两种API互不混用,Graph API可视设计强,Functional API适配已有函数改造。执行时通过HITL机制(Human-in-the-loop)在tool调用前中断,记录检查点至内存外数据库(如PostgreSQL/Redis),确保恢复准确。流式执行需输出token级和节点级事件,避免内存存储导致会话中断。选型时:需可视化流程和中断恢复选LangGraph;仅需基础提示词+NLP/检索直接拼接 LangChain;角色分工场景建议CrewAI;需完整权限沙箱机制则参考AgentScope标准。

LangChain 提供什么:提示词、LCEL 与可组合组件

LangChain通过提示词、模型、检索器、工具等独立组件构建应用,而非提供完整产品。提示词需区分通用(填变量单轮调用)、Few-shot(固定示例保持格式语气)和ChatPromptTemplate(角色化消息链)三种类型,避免信息过载影响模型效果。核心在于LCEL(LangChain Element Layer)的组合机制,通过Runnable部件实现检索、上下文拼接、模型调用、结果解析的管道化流程,支持中间节点独立调试和流量控制,且保持与后续LangGraph(需图状态/HITL)和CrewAI(多代理协作)的系统扩展性。读者需根据需求选择:简单应用用本文方法,状态追踪选LangGraph,复杂的角色协作选CrewAI。特别指出RAGFlow专门处理文档权限闭环,避免用LangChain混用冒充平台功能。

AI 
LangChain 提供什么:提示词、LCEL 与可组合组件
Agent 为什么要沙箱:隔离检索、工具和密钥

Agent 为什么要沙箱:隔离检索、工具和密钥

在多租户环境实施安全管控需遵循三原则:一是资源隔离,Agent接入强制绑定tenant_id并贯穿检索过滤、缓存key、出站策略等全链路,不可通过用户输入推测租户归属;二是强沙箱机制,实施工具白名单、访问域名白名单、工作目录限制和出站网关管控,同时物理阻断shell和直接调用生产库;三是动态分级管控,单租户内部可采用逻辑隔离,但涉及客户数据或触发合规审计时必须实施独立向量集合、密钥体系及定制化出站规则,配合审计日志实时记录和不可篡改存储。方案重点平衡安全性与运行效率,当多租户混用场景形成时(如跨企业服务复用、集团内部多部门系统共享)则必须强制上线独立运行时隔离体系。

Agent 怎么停、怎么回放:取消、预算和 trace

文章探讨模型调用取消机制的关键要点。停止条件包括步数耗尽、墙钟超时、token预算打满、工具连续失败或用户取消。必须通过run_id追踪调用并优先中断后续步骤,已执行副作用需通过补偿或确认回滚,避免隐式吞取消 demands导致日志欺诈。日志需完整记录输入、工具调用参数、观察结果、停止原因及耗时费用,按trace_id将多步调用串联整合。该机制设计使系统能清晰回溯问题环节,实现安全边界与响应性的平衡,减少非预期返回率并提升事务可审计性。读者可掌握取消场景下的调用跟踪规范和全量日志构造标准,兼顾用户体验与系统可靠性。

Agent 怎么停、怎么回放:取消、预算和 trace
Multi-Agent 什么时候才该上:角色边界、编排和验收

Multi-Agent 什么时候才该上:角色边界、编排和验收

多Agent系统需满足两个核心条件:单Agent加工具可完成时禁用多Agent以规避失败模式增量,或需实现专业角色并行协作及任务执行-校验流程解耦。拆分方式包括主从调度、对等协作和共享黑板三种架构,要求明确分工角色(规划、检索、执行、校验)并保证通信可观测性及状态可回溯性。评估重点转向任务完成率、协作轮次与工具调用失败率,取代单轮正确率测量。原标题为"Multi-Agent"的独立短稿内容已整合至本文,强化了协作机制实施标准。该框架为有限上下文窗口环境下,通过外置长记忆与片段化知识注入提升决策质量,同时控制多Agent系统复杂度提供了系统化方案。

Agent 循环怎么选:ReAct、先规划再执行与反思

Agent核心架构为"推理-行动"循环,需前置规划框架再沉积工具。主流范式存在差异:ReAct采用动态推理但存在误差累积风险;Plan-and-Execute通过事前计划与事中核验实现可控循环;Reflection/Reflexion系双阶段架构,后者具备失败归因机制可直接优化。部署需遵循梯度:单Agent集成工具白名单跑通基础循环,再逐步添加终止条件和全链日志,最后过渡到多Agent协作环境。需注意思维链CoT/ToT/GoT属于能力扩展组件,与循环结构无必然关联;(token消耗与执行效率)需同步评估不同框架的token开销。

Agent 循环怎么选:ReAct、先规划再执行与反思
Agent 上下文撑不住怎么办:窗口、外置检索和衰减

Agent 上下文撑不住怎么办:窗口、外置检索和衰减

文章探讨记忆管理机制与信息压缩技术,区分感知记忆(当前输入)、短期记忆(窗口内对话工具结果)、长期记忆(外部库召回)和实体记忆(结构化事实)四类要素。工作记忆三类标签需按实际参数(是否进窗口/可检索/可过期)进行差异化管理。信息压缩采用三点策略:滑动窗口替换最旧轮次仅保留提示和最新工具结果,通过摘要压缩将中间过程抽象为决策卡片存入长期记忆,实施重要性过滤聚焦当前目标实体。系统建议定期合并过期或冲突记忆,并明确区分上下文管理服务与RAG知识库服务,推荐采用Mem0、Letta、Zep/Graphiti等现成组件以避免架构混淆,最终形成高密度、低冗余的上下文管理体系,提升工作记忆运行效率。

RAG 怎么处理 Word 和扫描 PDF:版面还原和表格通道

扫描件与Word文档因格式差异需采用独立流水线处理。扫描件仅存像素,使用传统分块处理易导致表格结构破坏和页眉干扰,需通过版面还原工具(如IBM Docling/Marker)转换为保留层级顺序的Markdown等结构化文本。复杂表格建议转HTML/JSON后入库,采用LlamaParse类解析器做二次处理确保数据连贯性。处理低质量扫描件时,应先进行倾斜校正和OCR预处理,对置信度低于阈值的页面需人工复核标识而非静默索引。验收标准以实际能否准确提取表格数据为依据,而非单纯字符准确率,分块策略需参照系列文档中Chunking技术规范。文末强调解析系统的价值在于传递数据结构而非简单字符分割,混合使用不同格式文件时应分离处理路径。

RAG 
RAG 怎么处理 Word 和扫描 PDF:版面还原和表格通道