说明
本教程主要针对 dodo agent 相关的面试问题进行整理与总结，内容围绕实际项目中常见的设计思路、架构方案以及落地经验展开。文档当前处于持续更新状态，会不断补充新的高频面试题以及完整的解答。同时也欢迎大家在知识星球中分享自己的面经或遇到的典型问题，我会在此文档中统一整理与回复，持续完善这份面试宝典，帮助更多的同学系统性地理解和掌握Agent 相关能力。
1. 为什么智能体开发不用dify和coze去做，要自己实现？
第一个是业务定制化的需求。我们的产品是一个企业级的通用智能体平台，需要支持多种不同的Agent模式，比如ReAct、Plan-Execute、deepresearch等等，每种模式都有它特定的业务逻辑。如果用Dify或者Coze，虽然它们提供了可视化的编排能力，但是在深度定制上还是会非常受限，特别是当我们的业务逻辑比较复杂的时候，比如PPT生成的状态机管理，用现成平台就很难实现 第二个是技术可控性。智能体开发这东西，很多核心逻辑其实是个黑盒，比如工具调用的时机、循环的控制、上下文的管理等等。如果我们自己实现，这些细节都在我们掌控之中，遇到问题也好排查。如果用第三方平台，一旦出问题，我们很多时候是无能为力的。 第三个是成本和扩展性。Dify和Coze这些平台都有自己的定价模式，当我们规模上来了之后，成本会是一个问题。而且自己实现的话，我们可以根据业务需要灵活调整架构，比如我们企业内部大部分产品都是基于的Spring生态，那么智能体使用Spring AI 就和整个技术栈是统一的，集成起来也方便。 当然，这并不意味着自己实现就一定比用平台好，主要还是要看业务场景。如果是做一些简单的流程编排，用现成低代码平台确实能快速落地。但如果是做企业级产品，需要长期维护和深度定制，自己实现会更有优势。
2. 为什么不用springai-alibaba自带的react agent，而是自己手搓一个？
没有直接使用Spring AI Alibaba 的 ReactAgent，主要是从灵活性、可控性和定制化三个方面考虑。 第一，首先是灵活性。React最致命的问题，就是模型的工具调用能力。有的模型工具调用能力差，很可能调用一轮工具就结束了，比如我们公司私有化部署的模型，客户算力有限制。如果你用Alibaba的，你这种问题怎么解决？它的React对你而言是黑盒的，你没法做优化。而我现在自己手搓的这种方式，我可以在适当的地方，给他插入提示指令，动态引导它继续调用工具，避免过早结束。并且Alibaba这个ReactAgent在开始的时候只支持DashScope模型，而我们的业务场景是要兼容各种类型的模型。 第二，是可控性。整个执行流程——轮次控制、Tool调度、流式输出、任务中断等——都由我自己掌控，可以做到过程可观测、可干预，而不是黑盒无法干预。 第三是定制化。我可以很方便地叠加业务能力，比如会话持久化、输出结果定制化、引用生成定制化等，而这些在使用第三方组件的时候会比较受限。 所以很多时候，做智能体开发，宁可自己用最简单的框架手搓，不会因为框架的问题而被卡脖子，对于我整体项目的优化和后续的扩展也非常有好处的。
3. React agent的原理是什么？如何判断是否结束？
React Agent 其实是推理（Reasoning）和行动（Acting）的缩写。 它的核心原理就是一个“思考→执行→反思”循环执行的过程。 第一步，接收用户问题。Agent拿到问题后，首先会分析这个问题，看是否需要调用工具。 第二步，思考阶段。Agent会根据系统提示词和用户问题进行思考，判断下一步应该做什么。如果它觉得有足够的信息可以直接回答，就会输出最终答案；如果觉得需要更多信息，就会决定调用工具。 第三步，行动阶段。Agent调用相应的工具，比如搜索工具或者文件检索工具，企业中的查询数据mcp等工具，获取所需的信息。 第四步，观察阶段。Agent拿到工具的返回结果，把这些结果加入到上下文中。Agent基于新的上下文，再次判断是否需要继续调用工具。如果需要，就回到第二步；如果不需要，就输出最终答案。 关于如何判断是否结束，一般有几种机制： 第一个是模型自身的判断。我们在系统提示词里会明确告诉模型，如果工具返回的信息已经足够回答用户的问题了，Agent就会输出最终答案，不再调用工具。 第二个是最大轮次限制。我们会设置一个maxRounds参数，比如5轮，防止Agent无限循环下去。如果达到最大轮次还没有结束，就会强制结束并生成答案。 第三个是用户中断。我们实现了任务管理器，用户可以随时停止正在流式输出的Agent。 实际使用中，这几种机制是配合使用的，既要保证能充分调用工具获取信息，又要避免无限循环或者过度调用。
4. 为什么不用python的智能体框架，如langchain、langgraph、autogen等？
这个问题涉及到技术选型的核心考量，我们选择Java/Spring AI而不是Python生态，主要基于以下几个方面的考虑： 第一个是技术栈统一。公司的主要项目都是基于Java开发的，基本上都是基于spring的微服务架构，如果用Python的框架，就意味着要维护两套技术栈，人员培训、运维部署都是成本。而Spring AI是Java生态的，和我们的技术栈是统一的，大家上手也快，和其他项目的整合集成也很方便。 第二个是企业级稳定性。Spring Boot 本身提供了非常成熟的企业级能力，比如完善的配置管理、依赖注入、AOP 扩展机制以及与各类中间件的集成能力，在 Web 应用开发中有很强的工程化优势。相比之下，Python 的这些智能体框架虽然在功能上很灵活，但在工程化能力、系统稳定性以及长期维护方面，相对来说还不够好。对于企业级应用来说，稳定性和可维护性往往是优先级最高的。 第三个是性能和并发。Java在处理高并发场景时表现更好，而且我们用了响应式编程（Reactor），可以更好地利用系统资源。而智能体应用通常会涉及大量的 LLM 调用、工具调用以及流式输出，这些场景本质上是 IO 密集型操作。相比之下，Java 的响应式模型在处理这类高并发请求时会更加稳定。 第四个是部署和运维。我们的应用都是部署在k8s上的，Java应用的部署、监控、日志收集都已经有一套成熟的方案。Python应用虽然也能部署，但在企业级的运维体系上，Java显然还是更加方便成熟的。 当然，这并不是说 Python 的框架不好。像 LangChain、LangGraph 这些框架在快速原型开发以及 AI 能力探索方面确实非常强大，也更灵活。 但是对于企业级产品来说，技术选型更看重的是整体系统的一致性、工程化能力以及长期稳定性，因此我们最终选择了基于 Spring AI 的方案。
5. 参考来源是如何实现的？
参考来源功能就是引用溯源，让用户知道AI的回答是基于哪些信息来源的。 第一个是信息来源的追踪。当Agent调用搜索工具或者其他外部工具时，我们会把工具返回的结果都记录下来。比如搜索工具会返回多个网页链接，每个链接包含标题、URL、摘要等信息，我们会把这些信息保存到一个List里面。 第二个是前端展示。我们需要对输出给前端的消息进行区分，前端才可以根据类型来渲染不同的样式，比如正文部分是type=text的，而参考来源就是type=reference的。当Agent完成回答后，我们会通过流式输出一个reference类型的消息，里面包含所有来源信息的JSON数组。前端收到这个消息后，会在页面底部显示出来，用户点击就能查看原始来源。 具体实现上，我们在BaseAgent里维护了一个allReferences列表，每次工具调用返回结果后，就把来源信息添加进去。最后在大模型流式输出完成后，不要直接关闭流，而是先发送reference的消息即可。
6. 推荐问题是如何实现的？如何保证生成的推荐问题，你的智能体一定能回答的了？
推荐问题功能是为了提升用户体验，让用户可以继续探索相关话题。这个功能的实现其实挺有意思的。 首先是实现原理。我们在每次会话结束后，会单独调用一次大模型来生成推荐问题。具体流程是： 1. 把历史对话记录整理好，包括之前的问答和当前这次问答 2. 调用大模型，Prompt告诉它"根据对话历史生成3个推荐问题"，当然要以当前轮次的问答为主，历史消息为辅，这样才能保证对话的延续性。 3. 大模型返回3个问题，我们通过流式发送给前端。 但是关于如何保证推荐问题能被回答，这个确实是个挑战，比如你的智能体是一个智能查数的智能体，你的mcp可以查询一些企业级的数据，但是如果你直接让大模型基于对话的历史来生成推荐问题，他并不知道到底当前有什么可用工具啊，这就会导致它很容易生成一些超出能力范围的问题，比如问一些系统根本查不到的数据，或者调用不了的能力。这种推荐问题在实际场景中是不可用的，也是不合理的。 那么到底应该如何解决呢？ 核心思路是： 让大模型感知能力边界，而不是只基于简单的对话去生成 具体做法是，在生成推荐问题的这一步调用中，需要在上下文里显式注入以下信息： - 当前所有可用工具的名称和描述 - 每个工具的能力边界（能查什么，不能查什么） - 当前的历史会话内容 同时在提示词中增加明确约束，比如： - 生成的问题必须严格基于已有工具能力 - 不得超出工具可支持的查询范围 - 推荐问题要与当前对话保持上下文延续性 - 控制复杂度，比如限制问题长度、避免多轮工具调用问题等 通过这样的方式，你就可以真的生成一些真实可用的推荐问题。
7. react agent有没有可能执行到一半执行不下去了？如何解决？
这个问题本质上描述的是 ReAct 模式下，对大模型工具调用能力的依赖是比较强的。 如果模型的工具调用能力比较强，那么它可以在上下文不断扩展的过程中，持续进行思考和规划，多轮调用工具，直到问题被完整解决。但如果模型的工具调用能力比较弱，就有可能只调用一轮或者两轮工具之后，就无法继续推理，提前输出不完整的结果，甚至直接停止执行。 这个问题其实是非常常见的，甚至在强如claude code等智能体之中也会经常出现，本质就是对接入的大模型能力是有一定要求的。太弱的大模型就是会导致智能体使用效果的下降。 那么如何解决这个问题？ 核心思路是增强对模型推理过程的控制，而不是完全依赖模型自身的能力。 具体做法是在每一轮工具调用结束之后，手动向上下文中插入一条引导消息，比如在我们的completeToolCall方法中增加一条 UserMessage 例如：
messages.add(new UserMessage("""
已完成一轮执行，需要根据当前已有信息判断是否输出最终结果，还是继续调用其他工具：
1. 当前工具执行的信息是否完整，已经足够回答用户的问题
2. 如果不足，必须继续调用工具获取更多信息
如果需要更多信息，请直接调用工具，信息足够则直接输出最终结论。
"""));
通过增加这样的引导信息，可以强制模型在每一轮之后进行一次判断，避免因为上下文变长导致注意力偏移，或者模型过早结束推理。 本质上，这种方式是在人为增加一个决策校验点，让整个 Agent 的执行过程更加可控，从而提升多轮工具调用的稳定性。因此，ReAct Agent 在实际使用中确实可能出现执行中断的问题，但可以通过这种方式进行有效优化。 这也是为什么我一直偏爱手搓智能体框架的原因，如果你现在用的是黑盒的react agent，那么你优化起来是不是费劲多了，但是我用最简单的技术来手搓，整个流程都在我的控制之中，对于每个环节的优化都显得很自然方便了。
8. 你的豆豆agent，是如何管理多智能体的？如果只能有一个入口怎么处理？
这个问题本质上是需要从产品设计和系统架构两个层面来考虑。 首先，在我们的实际产品设计中，是从前端开始做了分离的架构。不同类型的用户操作，会对应不同的智能体能力，比如联网问答类、PPT生成类、深度研究类或者后续可以扩展其他的能力，这些在前端就已经做了一定的区分，然后分别调用后端不同的接口。这样可以保证每个智能体的调用是独立的，逻辑也更加清晰，整体系统的耦合度比较低。 但是如果只能提供一个统一入口，那么就需要在后端增加一层意图识别的能力。 具体来说，就是在统一入口接收到用户请求之后，先通过一次大模型调用，对用户输入进行意图判断，识别出当前请求属于哪一类任务，然后再将请求路由到对应的智能体去执行。 在这个过程中，需要提前维护好智能体能力描述，包括： - 每个智能体的功能说明 - 能处理的问题类型 - 对应的唯一标识（比如 code） 然后把这些信息一并提供给大模型，让模型在做意图识别的时候，有明确的选择范围。模型最终只需要返回一个匹配的 code，后端再根据这个 code，通过代码逻辑路由到具体的 Agent 实现即可。
9. PlanExecute和react架构的区别是什么？分别应用于什么场景？
这两个都是智能体的架构模式，但它们的设计思路和适用场景是不太一样的。 React 架构，本质上是“推理 + 行动”的循环模式。它的工作方式是： - 拿到问题之后，逐步进行思考和行动 - 每一步都会判断当前是否需要调用工具 - 可以根据中间结果动态调整策略 - 比较适合处理“依赖实时信息”的问题 React 的特点是比较灵活、实时性强，但缺点是缺乏全局规划能力，本质上是走一步看一步，在面对复杂任务时，整体规划能力会比较弱。 PlanExecute 架构，是“先规划，再执行”的模式。它的工作方式是： - 先生成一个相对完整的任务执行计划 - 再按照计划逐步执行各个子任务 - 在执行过程中会进行自我评估和反思，必要时调整原有计划，不断逼近最终目标 - 更适合处理需要多轮推理和深度分析的复杂任务 PlanExecute 的特点是具备全局视角，并且引入了反思机制，因此在复杂任务上的表现更稳定。 具体区别可以总结为： 1. 规划方式：React 是边执行边决策，PlanExecute 是先整体规划再执行 2. 执行方式：React 通常是串行推进，PlanExecute 在拆解任务后可以支持一定程度的并行执行 3. 反馈机制：React 主要依赖工具返回结果进行调整，PlanExecute 还引入了自我评估和反思机制 4. 适用场景：React 更适合实时问答和工具调用场景，PlanExecute 更适合复杂任务和深度研究 在我们项目中的实际应用是： - WebSearchReactAgent 和 FileReactAgent 使用的是 React 架构，因为这类场景需要频繁获取实时信息，强调灵活性和响应速度 - 深度研究类场景使用的是 PlanExecute 架构，因为 deep research 通常涉及多轮推理、任务拆解以及持续反思优化 整体来看，选择哪种架构，核心还是取决于任务的复杂度： - 如果是相对简单、偏实时的问题，React 就可以很好地胜任 - 如果是复杂度较高、需要多阶段推理的任务，PlanExecute 会更加合适
10. 如果mcp的工具太多，会不会持续影响大模型的上下文？如何优化呢？
这是一个非常典型的工程问题，也是MCP的最大缺陷，比如一个端点MCP，可能就会包含大量的工具集合，在调用模型时，我们需要把工具的定义（名称、描述、参数等）一并放入上下文中，如果工具数量很多，就会持续占用大量的上下文空间。 这个问题的影响主要有几个方面： 1. 上下文占用过多，留给用户问题和模型推理的空间被压缩 2. 工具描述过长，模型容易出现注意力分散，导致工具选择准确率下降 3. Token 消耗显著增加，整体调用成本上升 优化的方案我给大家总结为以下几种： 第一种是工具分组。 将工具按照功能进行分类，比如文件处理类、搜索类、数据查询类等。在 Spring AI 中可以通过 toolFilter 机制，对某一个 MCP 地址下的工具进行过滤，只加载当前场景需要的一部分工具，而不是全部加载，从而减少上下文体积。 第二种是工具描述优化。 对每个工具的描述进行精简，去掉冗余信息，只保留最核心的功能说明和使用边界。本质上就是对“工具提示词”的优化，让模型既能理解工具能力，又不会被无关信息干扰。 第三种是动态工具加载。 不在一开始就注入所有工具，而是在 Agent 执行过程中按需加载。这是一种非常进阶的方案，类似于 Claude Code 的 ToolSearch 机制，当工具的整体描述占用超过大模型10%的上下文的时候，则自动启用Toolsearch机制，整体流程可以是： 1. 第一轮：只注册工具名称（或简要信息）+ ToolSearch 工具 2. 模型调用 ToolSearch：检索当前需要的工具 3. 下一轮：将检索到的完整工具定义注入到上下文中 4. 后续轮次：已发现的工具持续保留使用 通过这种方式，可以把全量工具加载变成按需加载，显著降低上下文压力。 第四种是工具索引机制。 维护一套工具索引，对工具的类别、功能、关键词等元信息进行结构化管理。在模型调用前，先基于用户问题，通过 RAG 或检索机制筛选出最相关的一小部分工具，再注入上下文中，从而减少无关工具的干扰。 第五种是上下文压缩。 当上下文本身已经较长时，可以结合压缩策略，保留关键信息，减少无效 Token 占用，从整体上控制上下文规模。 通过以上的优化手段，让模型在有限上下文中，只看到当前最需要的工具，从而可以在保证能力完整的前提下，有效控制上下文长度和调用成本。
11. React agent中对于工具的调用是并发调用还是串行调用，如果是并发调用需要注意什么问题？这个问题的原因是什么？
这个问题其实和大模型的工具调用能力是强相关的。在早期模型或者工具调用能力较弱的模型中，一次返回的 tool_call 通常只有一个，所以整体表现更偏向串行调用。但随着模型能力的增强，如果模型判断当前任务可以拆分为多个相互独立的子任务（前提是没有依赖关系），那么在一轮中就可能返回多个 tool_call。 因此，从工程实现角度来看，我们的 React Agent 必须支持并发调用，否则整体执行效率会比较低。 但是在并发调用时，有一个非常关键的问题需要注意：工具返回结果的顺序，必须和模型生成的 tool_call 顺序严格一致。这个问题的根本原因在于： 大模型的 chat template 在处理工具调用结果时，是按顺序进行解析的，而不是严格按照 tool_call_id 来做映射。 这一点在实际开发中是非常容易被坑的地方，当然我也是最近刚发现这个问题，比如： - 模型生成了 A、B、C 三个 tool_call - 我们并发调用后，返回顺序变成了 B、C、A - 如果直接按返回顺序拼接结果 那么在下一轮推理中，就可能出现： - A 工具的问题，对应了 B 的结果 - B 工具的问题，对应了 C 的结果 - C 工具的问题，对应了 A 的结果 最终会导致整个推理链条错乱。也就是说： - 模型生成的每一个 tool_call，不仅有唯一 id，同时也隐含了顺序语义 - 在拼接 ToolResponseMessage 时，必须和原始 tool_call 一一对应 - 一旦顺序错乱，就会导致模型拿到错位的工具结果 可能带来的问题包括： - 结果错配（A 问题用了 B 的结果） - 推理过程混乱 所以在并发场景下，正确的处理方式是： - 工具调用可以并发执行，用于提升性能 - 但在结果汇总阶段，必须按照原始 tool_call 的顺序进行重排 - 并且结合 tool_call_id 做严格的一一映射 所以说，执行可以并发，但结果必须有序。并发确实提升了执行效率，但如果不处理好顺序问题，就会破坏整个推理链的正确性。这个点在实现 React Agent 时非常关键，也是一个非常容易被忽略但影响很大的细节。
12. PPT生成智能体的状态机是如何设计的？如何支持断点续传？
PPT 生成智能体是我们系统中最复杂的一个 Agent，因为它涉及多个阶段，而且每个阶段的处理逻辑都不一样，所以我们采用了状态机模式来进行管理。 状态定义，PPT 生成主要包含以下几个状态： - INIT：初始状态，用于识别用户意图 - REQUIREMENT：需求澄清，判断用户信息是否完整 - SEARCH：信息收集，通过联网搜索获取相关资料 - SCHEMA：结构生成，生成 PPT 的章节结构 - OUTLINE：大纲生成，为每个章节生成详细大纲 - SCHEMA：具体模板内容生成，为每一页生成具体的内容 （包含生成图片） - RENDER：渲染生成，生成最终的 PPT 文件 - SUCCESS：成功完成 - FAILED：失败状态 状态转换规则： - 正常流程：INIT → REQUIREMENT → SEARCH → SCHEMA → OUTLINE → SCHEMA → RENDER → SUCCESS - 异常情况：任何阶段出错，当前状态 → FAILED 策略模式实现，每个状态对应一个独立的 Strategy 类： - RequirementStrategy：负责需求澄清 - SearchStrategy：负责信息收集 - SchemaStrategy：负责具体结构生成 - …… 每个 Strategy 都实现统一的 PptStateStrategy 接口，专注处理当前状态的具体逻辑，实现了解耦和可扩展。 状态机上下文，通过 PptStateStrategyContext 统一维护： - 当前状态以及对应的 PPT 实例 - ChatClient、ChatMemory 等共享服务资源 - 状态流转控制逻辑（例如 continueStateMachine） 这样可以保证各个状态之间的数据是连贯的，同时状态切换是可控的。 那么断点续传实现，核心在于状态持久化： 1. 每个状态执行完成后，将当前状态持久化到数据库 2. 下次请求时，先判断是否存在未完成的 PPT 实例 3. 如果存在，则从数据库加载当前状态和上下文 4. 根据当前状态，继续执行对应的 Strategy 整体执行流程： 1. 用户发起请求 2. 系统根据 conversationId 检查是否存在未完成任务 3. 如果存在，加载实例和当前状态 4. 执行当前状态对应的 Strategy 5. 通过 continueStateMachine 进入下一状态 6. 持续推进，直到 SUCCESS 或 FAILED 即使在生成过程中出现中断（比如用户关闭页面、网络异常等），用户再次进入时，也可以从上一次的状态继续执行，而不会丢失已有进度。这对于 PPT 这种长耗时任务（通常需要几分钟）来说是非常关键的，可以显著提升用户体验和系统可靠性。
13. 文件问答，如果是大文件，遇到用户提问的是一个比较抽象的全局问题该怎么处理？比如：这个故事的主题是什么？
这个问题本质上是一个典型的 RAG 问题。因为传统基于向量检索的方式，更擅长处理局部相似度问题，也就是通过语义匹配命中某一段具体内容。但对于这种全局性问题，往往很难通过单次检索直接获取完整答案。 针对这种问题，一个比较常见的解决思路是：基于分层摘要来实现。 具体做法是： 第一层，对原始文档进行分 chunk，然后对每一批（比如几个或者几十个 chunk）做一次摘要，生成新的“摘要 chunk”。 第二层，将这些摘要 chunk 再次进行聚合和摘要，逐步向上压缩信息，形成更高层级的语义表示。 通过这种“层层摘要”的方式（具体层数取决于文档规模、chunk 大小以及模型上下文限制），最终可以得到一个或多个“全局摘要 chunk”，用于表达整个文档的核心内容。 在查询阶段： 1. 对于局部问题，仍然走普通的向量检索流程 2. 对于全局问题，可以优先命中这些高层摘要 chunk 这样就可以比较好地回答类似“主题是什么”“核心观点是什么”这类全局性问题。 另外一种思路是引入 GraphRAG 这类知识图谱相关的方案，例如 LightRAG。 这类基于知识图谱的 RAG 方案，会在构建阶段就抽取实体和关系，并形成结构化的语义网络。在查询时，可以天然区分： - 高层次问题（全局总结、主题归纳） - 低层次问题（细节检索、事实查询） 因此在处理全局性问题时，GraphRAG 往往会比纯向量检索更有优势。
14. 做这个项目的意义是什么？做个仿豆包的产品，有什么用？
这个项目的意义，在于如何构建一套完整的智能体系统架构和工程实现能力。 如果只是从表面看，它确实只是一个仿豆包的对话产品，但本质上它解决的是如何让大模型具备思考、执行和反思能力的问题。真正核心的是智能体如何运行，以及复杂任务是如何被拆解、执行和优化的。 从技术角度来看，这个项目覆盖的是一整套 Agent 架构能力，比如流式 ReAct 推理与工具调用、Plan Execute 多轮规划执行、基于状态机的 Workflow 编排（例如 PPT 生成）、Agentic RAG 文件问答，以及 Deep Research 这种复杂任务的多轮迭代执行。这些都不是简单调用模型能解决的问题，而是完整的工程系统设计。 以 ReAct 为例，用户看到的是输入问题得到答案，但内部其实涉及流式 token 级别的状态判断、tool call 跨 chunk 拼接、流式中断恢复、会话记忆持久化以及并发控制等一系列工程问题。这些能力本质上是智能体工程化能力，而不是提示词能力。 基于Plan Execute的 Deep Research 场景，需要解决任务规划、依赖管理、并发执行以及多轮自我优化的问题，这类能力在复杂业务场景中是非常通用的。 文件问答虽然是基于 RAG，但通过工具接入到 ReAct Agent 后，形成的是一个可以多轮检索和推理的 Agentic RAG，而不是传统的一次性问答。这种方案设计，在企业中是得到广泛应用的。 更重要的是，这套架构是可以直接落地到业务中的。比如把搜索能力替换为企业内部系统接口，把工具接入改造成 MCP 标准，就可以实现对企业数据、业务信息的智能查询和分析能力。无论是做智能客服、数据分析助手，还是业务辅助决策系统，本质上都是这一套架构的复用。 所以做这个项目的意义，不是做一个对标产品，而是掌握一套通用的智能体解决方案。它解决的是智能体如何设计、如何实现、如何落地的问题。 如果连这些通用能力都不清楚，是很难真正把智能体应用到企业实际业务中的，更谈不上用智能体去改造和赋能现有系统。
15. DeepResearch是如何保证在多轮迭代过程中主键逼近目标的？并且主题不跑偏
首先，在进入研究之前，会经历需求澄清和研究主题生成两个阶段，把用户的模糊问题提炼成一个明确的研究主题。这个研究主题和用户的原始问题会被作为不可变锚点，在后续每一轮的 Plan、Critique、Summarize 阶段都被强制注入到 Prompt中，确保无论迭代多少轮，所有阶段的思考准则都只能有一个，就是用户真正关心的问题。 其次，就是架构上的关键设计，四个角色的严格职责分离。Planner 只负责规划任务，明确禁止它做分析和推理执行；Executor 只负责执行工具，并返回事实结果，不能加入任何主观判断；Critic 只评估当前信息是否足够支撑报告，输出一个 passed 标记和feedback未通过的原因，以及 Summarizer 只基于所有工具检索结果生成最终报告，没检索到的必须诚实说明。每个角色的 Prompt 里都有明确的约束行为边界，这样就不会出现某个角色越界导致研究方向偏离的问题。 第三也是最核心的，是 Critique 反馈机制。每一轮执行完成之后，Critic 会判断当前的研究结果是否已经足够。如果不够，它会输出具体的 feedback 指出缺什么。这个 feedback 会被写入下一轮的 Plan 阶段，被强制注入生成执行计划的prompt。PLAN 提示词里有一条优先级最高的指令，就是要求 Planner 必须严格优先围绕 Critique Feedback 来补充增量计划，不能重复之前失败的尝试。这样就形成了一个定向收敛的闭环，每一轮都在针对性地补齐上一轮指出的信息缺口，而不是漫无目的胡乱搜索。 最后，在上下文管理层面，当对话历史过长需要压缩时，COMPRESS 提示词设定了严格的保留优先级，用户最终目标是最高优先级，禁止删除或改写；其次是已完成的关键任务结论、工具执行结果、最近一次 Critique 反馈和当前未解决的问题。同时要求压缩后不能使用模糊指代，必须保留具体事实。这样就保证了即使经过多轮压缩，核心的研究方向和已有成果也不会丢失。加上maxRounds 硬性循环上限和 Critique 的"满足80%即通过"的放宽策略，整个深度研究系统能够高效收敛而不会陷入无限循环或漂移到不相关的问题上。 所以我们可以看到，DeepResearch 的核心并不在于单一模型能力或者提示词设计，而是在于整体的架构设计。它通过目标锚定、任务分解、反馈驱动以及上下文控制等一系列机制，构建了一套能够持续收敛的执行体系。 本质上，这套架构就是在讲如何让智能体在复杂、多轮任务中稳定、高效地逼近目标并最终完成任务。 而这正是我们这个项目的意义所在，教会大家一套可落地的智能体工程范式，让复杂任务具备可控执行和稳定收敛的能力。