回想那个面试，如果她当时能多说一句"docker 只是隔离光谱里比较轻量的一档，生产环境里面，microVM 因为兼顾了安全性和启动速度，是更常见的选择"，可能就不会只拿到"一半"的评价了。"Sandbox for AI agents" 这个说法，一年前还是个小众词。现在已经变成一个拥挤的赛道了。这本身就说明了一件事：当 agent 从"聊天"走向"真正执行任务"，安全边界就不再是可选项了。它是地

下一步做什么，是代码决定，还是模型决定？代码决定主要下一步 → Workflow模型根据工具反馈决定下一步 → AgentWorkflow 像地铁线路图：可以有分支、换乘和重试，但哪些站能去、什么条件能换乘，主要由代码规定。用户问题↓代码判断意图├─ 制度咨询 → RAG 检索 → 带引用回答├─ 订单查询 → 订单 API → 格式化输出└─ 退款申请 → 规则校验 → 人工审批Agent 更像

本文围绕Agent系统中模型、检索与工具三类依赖的熔断设计，提出在统一依赖调用层按真实故障域划分熔断范围，避免全局故障扩大。共用状态机但差异化定义“失败”标准：模型需等待流式完整输出；检索区分空结果与执行失败；写操作必须核对业务事实，防止重复提交。熔断触发基于可归因失败率与慢调用，恢复时限流探测，多实例共享探测预算，防止迟到回调干扰。运行时通过统一适配层拦截调用，确保降级合规、不重复操作，并通过三

本文从软件工程与AI系统架构视角，系统梳理知识库、RAG、向量数据库、图数据库、知识图谱及GraphRAG等核心概念。明确其英文全称、本质与解决的问题：知识库是知识组织体系，RAG为检索增强生成架构，向量数据库支持语义搜索，图数据库管理关系数据，知识图谱结构化表达实体关系，GraphRAG则利用图结构优化检索。文章详解文档如何经切块、嵌入、索引后供大模型检索，并揭示向量生成、相似性计算、混合检索、

面试官问：客服Agent项目资料中，哪些放RAG、哪些转Skill？答案是：先拆分知识类型。必须遵守的规则（如大额退款需人工审批）常驻于AGENTS.md；需按步骤执行的流程（如退款处理流程）写成Skill；量大且常变的事实（如各类目退款时限）留作RAG检索。技能用上时整份加载，检索则按问题匹配片段。关键在于：规则不靠模型记忆，流程要完整执行，事实应动态获取。验证方法：用历史工单对比四组通过率，看

Agent 的长任务失控，多半是状态管理和上下文管理的问题，而不是模型突然变笨了。把 Agent 当成一个需要状态机、校验、恢复和熔断的工程系统来做，而不是当成一段越写越长的 Prompt，这才是走出"第 20 轮魔咒"的正路​2026最新版百万八股面试宝典精选面试题库《Java》《大模型》《大并发》《大数据》以及架构体系技术栈核心知识点联合大厂面试官精心打造，多技术方向全覆盖>面试突击体系相关>

本文改造多Agent客服的短期记忆系统，摒弃自研Redis封装，改用LangGraph的RedisCheckpointer实现会话状态持久化。通过将thread_id与会话绑定，自动恢复历史对话，解决旧方案中状态断层、上下文丢失问题。引入trim_history节点控制消息窗口（最多20条），防止状态无限膨胀。重构AgentState，统一以messages为唯一状态主线，子任务结果直接作为消息注

多Agent并行开发需超越文件锁，避免跨文件依赖与状态冲突。核心是通过独立Git Worktree实现工作空间隔离，每个任务绑定持久化的工作树，确保状态可靠、执行目录可验证。任务认领需原子化，失败即终止，禁止隐式回退。冲突不消除，而是推迟至集成阶段，通过全量测试与人工评审统一处理。最终目标：让冲突可见、可控、可追溯。

超过约定时间，主Agent要查询状态、说明等待原因，或者进入明确的失败处理路径。如果返回的是“查询失败”，主Agent不能为了让流程看起来完成，把它改写成“暂时缺货”。例如“结果缺少型号，无法与订单对应”，而不是笼统地让它“再认真想想”。主Agent不能无限指责子Agent，也不能把“已委派”作为对用户的最终交付。库存Agent返回“有货”，主Agent还得看是不是对应型号，状态是不是最新，是否只

面对查资料、写报告、发邮件的Agent任务，应优先采用混合模式：先由Planner制定含依赖与验收条件的粗阶段计划（如“收集数据→分析→撰写→发送”），再在各阶段内使用ReAct进行局部动态执行。因任务虽复杂但可分解，且需全局协调，故不适用单一模式。关键在于判断反馈密度与依赖稳定性——若下一步依赖实时观察，则用ReAct；若目标与依赖可预知，则用Plan-and-Execute；二者结合更稳健。