它的本质是用软件工程将一个“动态资料库”外挂给大模型。离线索引和在线检索增强。其中离线索引阶段将私有 Markdown 文档切分成大小适宜的文本块（Chunk），转化为高维数学向量，存入索引引擎。在线检索增强在用户提问时，先通过语义算法和关键词匹配召回最相关的 Top-K 个文档片段，将这些客观片段动态注入 Prompt，最后驱动 LLM 总结出带有真实引用溯源的回答。

装载结果末尾追加一句指令重申："以上是说明书不是任务结果，必须逐步调用工具执行"。的接入：查天气、读网页、查待办，每个工具一份 JSON Schema 声明，模型决定调用、Agent 本地执行、结果回写。3. 调用 run_skill_script 执行 clothing-advice.js，输入 {"temp": 温度, "weather": 天气现象}"装载说明书"实现为两个普通本地工具，对模

记忆系统的目标不是"记得越多越好"，而是在对的时刻用对的那一条，在错的时刻保持沉默。规则保证不出事，模型保证好用。缺了前者，AI 会让人不安全；缺了后者，AI 会让人觉得笨。

回到开头那个核心问题：「Agent 为什么记不住、管不过来？那就让系统学会常驻—— 把会话管理从用户侧移到系统侧，把知识处理从查询时移到沉淀时，把任务执行从单线程改成并行调度，把被动响应变成主动推进。它不是银弹，不能解决所有问题，也替代不了高质量的知识内容和持续的运营投入。企业智能体正在从「以对话为中心」转向「以任务为中心」，企业知识库正在从「以检索为中心」转向「以知识沉淀与应用为中心」。未来的企

我们搭建 DeepAgents 项目的过程，正是解决普通智能体痛点的过程：从基础的工具调用，到状态管理实现任务规划，再到并行调用提升效率，最后通过虚拟文件系统和子智能体委托，实现复杂任务的高效处理，每一步都循序渐进、可落地。整个项目的核心逻辑，是让智能体从 “被动执行” 升级为 “主动管理”：通过 “规划-分解-委托-整合” 的闭环架构，让智能体能够调度资源、管理记忆、分工协作。

大多数 Agent 系统不需要那么多子 Agent。单 agent loop + skills 的"扁平架构"，在质量、成本、延迟上全面更优。一个客户 AI 客服实测：单 loop 比多 agent 架构快约2 倍， 往往复杂的客服问题或者相关工单占比很少的。另一个案例：某公司 12 个子 agent 让品牌体验难以维护，延迟还伤害了用户体验，每一次都慢的话，往往就是你自身产品有问题了。所以多不一

一个Manager Agent 负责任务拆解、分配和结果汇总，多个 Worker Agent 并行执行。Manager 把大任务拆成子任务、分给不同 Worker 并行干活，最后汇总。就像项目经理接到大项目，拆成子任务分给开发人员，并行完成后汇总交付。它的优点是并行速度快、任务拆解清晰、子任务独立、易扩展；缺点是Manager 是瓶颈（它的拆解能力决定整体质量）、子任务之间有依赖就无法完全并行、汇

Skill 属于流程层，MCP 属于能力层。Skill 把你的重复工作流程固化下来；MCP 把 Agent 接入外部系统的通道打通。Skill 能编排调用顺序，但永远无法替代外联能力。下面把这两层分别拆开。规则归配置文件——业务规则写进执行步骤归 Skill——SKILL.md规定五步排查顺序跨系统取数靠 MCP——三个 MCP Server 负责拿订单、支付、日志的实时数据Skill 能编排调用

这次面试给的一个教训就是:技术面试里面问的"怎么处理",从来就不是考你知道多少个名词。它考的是你能不能把一个真实的问题,完整地讲成一条闭环的因果链。这条链是什么样的呢,就是:怎么发现问题,然后怎么去定位病因,用了什么方案,为什么选这个方案而不是别的,最后怎么去验证这个方案是真的有效。七八个方法论堆在一起,听起来是很全。但如果每一环都是浅浅地带过,面试官立刻就能听出来,你到底是"知道",还是真正"做

一个自定义基金专家可以配置：只是对模型的软偏好，不会自动把正文塞入 Child，也不会隐藏未偏好的合法能力。而明确请求在专家启动时读取并投影指引，但必须使用原注册资源、真实 Child grant、内容校验与上下文容量。失败就局部报告 unavailable，不能把未知路径拿来直接读，也不能假装加载成功。若完整指引超出容量，当前投影以完整项为单位保留省略，避免截断一半再让模型误以为拿到了可用方法。