.webp){kind=small}
LTT
Agent 为什么要沙箱：隔离检索、工具和密钥
在多租户环境实施安全管控需遵循三原则：一是资源隔离，Agent接入强制绑定tenant_id并贯穿检索过滤、缓存key、出站策略等全链路，不可通过用户输入推测租户归属；二是强沙箱机制，实施工具白名单、访问域名白名单、工作目录限制和出站网关管控，同时物理阻断shell和直接调用生产库；三是动态分级管控，单租户内部可采用逻辑隔离，但涉及客户数据或触发合规审计时必须实施独立向量集合、密钥体系及定制化出站规则，配合审计日志实时记录和不可篡改存储。方案重点平衡安全性与运行效率，当多租户混用场景形成时（如跨企业服务复用、集团内部多部门系统共享）则必须强制上线独立运行时隔离体系。
Agent 怎么停、怎么回放：取消、预算和 trace
文章探讨模型调用取消机制的关键要点。停止条件包括步数耗尽、墙钟超时、token预算打满、工具连续失败或用户取消。必须通过run_id追踪调用并优先中断后续步骤，已执行副作用需通过补偿或确认回滚，避免隐式吞取消 demands导致日志欺诈。日志需完整记录输入、工具调用参数、观察结果、停止原因及耗时费用，按trace_id将多步调用串联整合。该机制设计使系统能清晰回溯问题环节，实现安全边界与响应性的平衡，减少非预期返回率并提升事务可审计性。读者可掌握取消场景下的调用跟踪规范和全量日志构造标准，兼顾用户体验与系统可靠性。
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 上下文撑不住怎么办：窗口、外置检索和衰减
文章探讨记忆管理机制与信息压缩技术，区分感知记忆（当前输入）、短期记忆（窗口内对话工具结果）、长期记忆（外部库召回）和实体记忆（结构化事实）四类要素。工作记忆三类标签需按实际参数（是否进窗口/可检索/可过期）进行差异化管理。信息压缩采用三点策略：滑动窗口替换最旧轮次仅保留提示和最新工具结果，通过摘要压缩将中间过程抽象为决策卡片存入长期记忆，实施重要性过滤聚焦当前目标实体。系统建议定期合并过期或冲突记忆，并明确区分上下文管理服务与RAG知识库服务，推荐采用Mem0、Letta、Zep/Graphiti等现成组件以避免架构混淆，最终形成高密度、低冗余的上下文管理体系，提升工作记忆运行效率。
RAG 怎么处理 Word 和扫描 PDF：版面还原和表格通道
扫描件与Word文档因格式差异需采用独立流水线处理。扫描件仅存像素，使用传统分块处理易导致表格结构破坏和页眉干扰，需通过版面还原工具（如IBM Docling/Marker）转换为保留层级顺序的Markdown等结构化文本。复杂表格建议转HTML/JSON后入库，采用LlamaParse类解析器做二次处理确保数据连贯性。处理低质量扫描件时，应先进行倾斜校正和OCR预处理，对置信度低于阈值的页面需人工复核标识而非静默索引。验收标准以实际能否准确提取表格数据为依据，而非单纯字符准确率，分块策略需参照系列文档中Chunking技术规范。文末强调解析系统的价值在于传递数据结构而非简单字符分割，混合使用不同格式文件时应分离处理路径。
RAG 向量库怎么选：Chroma、pgvector、Qdrant 和 Milvus
本文探讨Embedding数据库选型建议与核心注意事项。Chroma适合单机原型，pgvector适配已有PostgreSQL生态，Qdrant适用于中小规模部署且运维成本低，Milvus在数据量增长且需量化存储时表现突出。内存不足时建议先采用SQ8索引降低内存压力，后续可升级mmap机制。需注意批量写入导致的Segment合并问题，建议错峰或控制单次写入量。特别强调Embedding模型与数据库应分离部署，中文业务需在自有数据集验证召回效果，数据敏感时选择BGE/Qwen本地部署方案。运维复杂度、数据增长性、现有生态兼容性是选型核心维度，模型训练与数据库存储需独立实施并依据具体业务场景权衡技术方案。
RAG 文档改了怎么办：删除、版本号和 Upsert
动态文档更新需规避写入失败导致的结构丢失风险，推荐三种策略：1）先删后增（需预先备份旧向量，插入失败立即回写）适用于大改或结构重组；2）先增后删（新数据就绪后替换旧文档，允许短期双倍存储）适合需持续检索的服务；3）软删除加版本号（新数据激活后释放旧资源，定时物理清理）稳定性最优，支持实时恢复。核心原则是文档ID必须稳定，二级ID需关联文档且采用增序/哈希组合。变更感知可通过定时轮询或事件驱动（如对象存储 notify、Git webhook）实现实时同步，Milvus等工具底层采用“标记旧数据-完成新索引-统一回收”机制避免读写冲突。全量重建仅限事故回退，日常维护推荐灰度切换（先切部分流量验证新版本）。最终收益是平衡数据一致性、检索连续性与服务稳定性，规模较大时建议采用软删除+版本号的混合结构，在突发写入失败时可借助备份快速回滚恢复业务连续性而无感知延迟。
RAG 怎么验收：Hit@K、Ragas 和线上指标
核心要点包括：系统应该同时优化检索层（Hit@K、MRR、上下文准确率）和生成层（答案忠实度、相关性），离线测试需人工标注问答集建立基准，Ragas可验证模型迭代后的忠实度变化，Hit@K下降应优先排查分块策略或多路召回配置。线上通过踩率、追问率等6项指标验证效果，形成"离线设计→上线观测→复现测试→再优化"的闭环。测试工具选择需配套定义指标，避免经验主观性。最终效果体现在提升用户问题解决效率与降低人工介入频率，关键收益是建立可复现的量化评估体系以减少无效调试成本。
RAG 检索为什么不准：多路召回、MMR 与 Query rewrite
多路检索技术提升问答系统准确率，通过稀疏（BM25）与稠密多路召回结合避免模型偏差，实现跨数据源召回覆盖。核心流程包含：1）query rewrite对问题补全同义词与拆解子问题，修正失误需原查询兜底；2）多路召回取TopN后经RRF（加权融合）消除单一索引评分局限；3）rerank用编码器对问题-文档对优化排序，低于阈值直接拒答；4）MMR算法控制相关性 redundence，防止Output near-duplicate。辅助手段包括预生成QA对拓展语义入口，利用元数据和图谱过滤制度版本与租户信息。这种方法优先通过检索层过滤无效数据降低生成模型负荷，相比单纯扩围大模型显著提升效率，使正确答案无需计算复杂度即可触达。
