《Ai Agent》，关于面试中的技能、简历、问题汇总

作者：小傅哥
博客：https://bugstack.cn (opens new window)
课程：https://t.zsxq.com/GwNZp (opens new window)

沉淀、分享、成长，让自己和他人都能有所收获！😄

此部分主要用于向读者提供星球项目之一的《Ai Agent》项目如何体现到简历中，包括；专业技能、项目经验。

一、项目介绍

面试官您好，本套 Ai Agent 综合智能体项目，主要为业务应用系统提效而构建，包括；需求文档分析、代码评审（可结合 openai 代码自动评审）、文档资料编写（+消息通知）、ELK 日志检索 + 普罗米修斯监控的智能 Ai Agent 分析等功能。

整套项目，抽象设计拆分了 Ai Agent 执行过程所需的各项组件（Advisor、Prompt、MCP）能力到数据库表中，使其具备自由配置编排组装的特性。以此方式可结合应用中实际场景诉求，编排类似 Diff 和智能分析 Coze 能力，达到需要什么场景就配置什么场景的 Ai Auto Agent。

该项目，在架构设计上使用了 DDD 分层架构进行设计，运用了组合模式的规则引擎构建执行链路，并结合工厂、策略、责任链等方式来处理具体流程细节（多种组合方式的Ai Agent执行过程），以此解耦系统功能的实现。这样就可以更加灵活方便的迭代各类扩展性诉求。

二、简历模板

注意：🙅🏻‍♀️不要直接复制粘贴简历模板内容，以此结构和描述方式，可以用你的个人第1学习视角来描述。包括；学习过程中的积累、检索的同类资料，以及对课程的扩展等多方面内容来编写简历。以下简历涵盖了课程 1~3 阶段内容；

• 项目名称：Ai Agent 综合应用提效智能体/Ai Agent 智能巡检系统/Ai Agent 可编排服务系统 - 基于你的实际场景/目的，修改项目名称
• 项目架构：微服务架构、DDD 领域驱动四色模型、前后端分离设计、Agent 设计模式
• 核心技术：Spring AI（RAG、MCP、Advisor）、SpringBoot、MyBatis、MySQL、PGVector、Redis、React、flowgram.ai、Nginx、Docker
• 项目描述：本项目是一套面向业务应用系统提效的综合智能体（Ai Agent）解决方案，支持将执行过程中的各项能力（如Advisor、Prompt、MCP）抽象并存储于数据库，实现自由配置和灵活编排。用户可根据实际业务场景，动态组合和调整智能分析、代码评审、日志检索等功能模块，打造定制化的Ai Auto Agent，从而显著提升开发设计、编码、运维效率。
• 核心职责：
  • 以产品（PRD）服务诉求和多方面调研评审，设计出具有可编排能力的 Ai Agent 服务架构。并以 DDD 领域驱动建模，构建系统架构。
  • 拆解 Ai Agent 执行过程所需的能力组件，包括；Advisor 顾问角色记忆上下文和访问RAG知识库、Tool（Function Call、MCP）调用服务端（推文、通知、ELK、普罗米修斯监控等）、Prompt（提示词）、Model（对话模型）、Api（使用 one-api/自研sdk组件，统一转换其他各个模型为 openai 格式）
  • 设计通用对话分析模型，完成 Ai Agent 执行过程中所需的，问题分析、自主规划、精准执行、内容判罚（循环执行），直至输出最终结果。—— Ai Agent 可对不同步骤配置不同的 Model + MCP + Prompt 能力。并对执行过程中，通过 Advisor 顾问角色访问知识库和存储上下文数据。
  • 实现 MCP 服务能力，以 stdio/sse 方式，开发，公众号通知 MCP、推文 MCP（可以是内部的文档化服务）、ELK-MCP、普罗米修斯-MCP等。以及使用 MCP 服务平台，检索公用能力 https://sai.baidu.com/zh/（本地文件、Github、搜索引擎），统一配置使用。—— 数据库设计了多类型 MCP 服务的配置操作。
  • 设计通用 MCP Nginx Token 校验能力（也可以设计 MCP-GateWay），以配置化方式进行鉴权使用。增强 MCP 调用过程中，数据传输安全性。
  • 基于 Spring TaskScheduler 扩展实现，智能体任务调度服务，可自动化完成日常系统巡检（客诉、报警）产生 html 格式报告文档。也可以基于报警监听消息，触发巡检动作（公司内，报警信息有 MQ 消息）。
  • 提供 RAG 知识库能力，可自主上传文件 + 解析工程代码库，并对知识库设有标签为 Ai Agent Advisor 访问 RAG 提供数据使用能力，增强准确性。—— 解析的代码库，可以为 openai 代码自动评审，增强评审能力。
  • 设计一键 Ai Agent 预热能力，动态化注入 Spring 容器。支持运营配置服务，随时调整、变更、上线，方便运营配置和使用。
  • 基于 Racet + flowgram.ai 框架，为 Ai Agent 服务提供拖拉拽编排能力，增强运营使用体验。

此套 Ai Agent 以为企业/平台/系统，上线3个月以来，主动巡检解决数十次系统隐患问题和运营配置错误情况，以及撰写了上万篇有效文档 + 提炼技术关键信息对新人辅导。后续还会继续配置更多方面的 Ai Agent 服务能力，为企业提效。

三、面试问题

1. 你们项目采用了DDD领域驱动设计，能简单介绍一下你们的四色模型是如何划分的？

回答：我们项目严格按照DDD四色模型进行架构设计。首先是**实体（Entity）**层，主要包含AiClientVO、AiClientAdvisorVO等核心业务对象，承载业务状态和标识；**值对象（Value Object）**层包含各种配置信息如AiClientSystemPromptVO、AiClientModelVO等，保证数据的不可变性；**领域服务（Domain Service）**层实现了复杂的业务逻辑，如AiClientNode、AiClientAdvisorNode等节点服务，负责AI Agent的组装和编排；**聚合根（Aggregate Root）**则通过ExecuteCommandEntity等实体来管理整个AI Agent的生命周期。这种设计让我们的业务逻辑更加清晰，各层职责分明，便于维护和扩展。

2. 你们的微服务架构是如何设计的，各个模块之间是如何协作的？

回答：我们采用了标准的DDD分层架构，分为六个核心模块：api层定义对外接口契约，app层作为应用启动入口和配置中心，domain层包含核心业务逻辑和领域模型，trigger层处理HTTP请求和事件触发，infrastructure层负责数据持久化和外部服务调用，types层定义通用类型和枚举。各模块通过依赖注入和事件驱动进行协作，domain层作为核心不依赖任何外部模块，infrastructure层实现domain层定义的接口，trigger层调用domain层的服务。这种设计保证了业务逻辑的纯净性和系统的可测试性。

3. Agent设计模式在你们项目中是如何体现的？

回答：我们的Agent设计模式主要体现在多层次的智能体架构设计上。首先是策略模式的应用，通过IExecuteStrategy接口定义执行策略，AutoAgentExecuteStrategy实现自动执行逻辑；其次是责任链模式的核心应用，我们设计了四步执行链：RootNode→Step1AnalyzerNode（任务分析）→Step2PrecisionExecutorNode（精准执行）→Step3QualitySupervisorNode（质量监督）→Step4LogExecutionSummaryNode（执行总结），每个节点继承AbstractExecuteAutoSupport并实现特定的业务逻辑；再次是工厂模式，通过DefaultAutoAgentExecuteStrategyFactory创建执行策略处理器，管理DynamicContext动态上下文；最后是模板方法模式，AbstractExecuteAutoSupport定义了执行模板，各个Step节点实现具体的doApply方法。这种设计实现了"问题分析→自主规划→精准执行→质量监督"的完整AI Agent执行循环，每个步骤都可以独立配置不同的ChatClient、Prompt和Advisor，真正实现了智能体的可编排和可扩展。

4. Spring AI中的Advisor顾问角色是如何设计和实现的？

回答：Advisor顾问角色是我们AI Agent的核心能力之一，主要负责上下文记忆和知识库访问。我们实现了两种主要的Advisor：PromptChatMemory用于维护对话历史，通过maxMessages参数控制记忆长度；RagAnswerAdvisor用于访问向量知识库，通过topK和filterExpression参数控制检索精度。在实现上，我们继承了Spring AI的BaseAdvisor，重写了aroundCall方法来拦截对话请求，在请求前注入相关上下文信息，在响应后更新记忆状态。这种设计让AI Agent具备了持续学习和知识积累的能力，大大提升了对话的准确性和连贯性。

5. RAG知识库的分词和向量化是如何设计的？

回答：我们的RAG知识库基于PGVector实现，使用OpenAI的Embedding模型进行向量化。在分词策略上，我们使用TokenTextSplitter按照token数量进行智能分割，既保证了语义的完整性又控制了向量的维度。向量存储采用1536维的向量空间，支持余弦相似度检索。在数据预处理阶段，我们会对上传的文档进行清洗和标准化，提取关键信息并添加元数据标签，这些标签可以用于后续的过滤检索。检索时通过SearchRequest配置topK参数控制返回结果数量，通过filterExpression进行精确过滤，确保检索结果的相关性和准确性。

6. MCP协议的设计理念和实现方式是什么？

回答：MCP（Model Context Protocol）是我们实现工具调用的核心协议，它定义了AI模型与外部工具之间的标准化通信接口。我们支持两种通信方式：stdio模式适用于本地工具调用，通过标准输入输出进行通信；sse模式适用于远程服务调用，通过Server-Sent Events实现实时通信。在实现上，我们为每个MCP服务定义了标准的Function接口，使用@Tool注解标记可调用的方法，通过MethodToolCallbackProvider将Java方法暴露为MCP工具。比如微信通知MCP通过WeiXinNoticeService提供消息推送能力，CSDN发帖MCP提供自动发布文章的能力。这种设计让AI Agent能够调用各种外部服务，大大扩展了智能体的能力边界。

7. 你们是如何实现AI Agent的动态编排和热部署的？

回答：我们通过Spring的动态Bean注册机制实现了AI Agent的热部署能力。核心思路是将AI Agent的各个组件（Model、Prompt、Advisor、MCP）抽象为可配置的Bean，存储在数据库中。当配置发生变化时，通过ArmoryCommandEntity触发重新装配流程，使用DefaultArmoryStrategyFactory的策略模式动态创建新的组件实例，然后通过registerBean方法将新组件注册到Spring容器中。整个过程采用责任链模式，依次执行AiClientApiNode、AiClientModelNode、AiClientAdvisorNode、AiClientNode等节点，确保组件的正确装配顺序。这种设计让我们能够在不重启服务的情况下，动态调整AI Agent的能力配置，大大提升了系统的灵活性和运维效率。

8. 智能体任务调度服务是如何设计的，如何实现自动化巡检？

回答：我们基于Spring TaskScheduler扩展实现了智能体任务调度服务，支持定时和事件驱动两种触发方式。定时巡检通过Cron表达式配置执行周期，自动收集系统指标、日志信息、告警数据等，然后调用专门的巡检Agent进行智能分析，最终生成HTML格式的巡检报告。事件驱动巡检则监听MQ消息，当收到告警信息时立即触发相应的巡检动作。在实现上，我们为每种巡检场景配置了专门的Agent，比如性能巡检Agent配置了Prometheus MCP工具，日志巡检Agent配置了ELK MCP工具。巡检结果会通过微信公众号MCP自动推送给相关人员，实现了从发现问题到通知处理的全自动化流程。

9. 你们的MCP服务是如何保证安全性的？

回答：我们设计了通用的MCP Nginx Token校验机制来保证数据传输安全性。首先在Nginx层配置了统一的鉴权模块，所有MCP请求都需要携带有效的Token才能通过；Token采用JWT格式，包含用户身份、权限范围、过期时间等信息；在应用层，我们为每个MCP服务配置了独立的访问密钥，支持定期轮换；对于敏感操作如数据库访问、文件操作等，还增加了二次验证机制。此外，我们还实现了请求频率限制、IP白名单、操作审计日志等安全措施。在数据传输过程中，所有敏感信息都进行了加密处理，确保即使在网络传输过程中被截获也无法直接使用。

10. 前端的拖拽编排功能是如何实现的？

回答：我们基于React和flowgram.ai框架实现了AI Agent的可视化编排功能。前端采用节点式的流程图设计，每个节点代表一个AI Agent组件，用户可以通过拖拽的方式组合不同的Model、Prompt、Advisor、MCP组件。在技术实现上，我们使用React Flow作为基础图形引擎，自定义了各种组件节点的渲染逻辑；通过Context API管理全局状态，实时同步编排配置；使用WebSocket与后端保持连接，支持实时预览和调试。当用户完成编排后，前端会将配置信息序列化为JSON格式发送给后端，后端解析配置并动态创建对应的AI Agent实例。这种设计让非技术人员也能够轻松配置和使用AI Agent，大大降低了使用门槛。

11. 在实现多模型适配时遇到了什么挑战，是如何解决的？

回答：最大的挑战是不同AI模型的API格式和调用方式差异很大，直接适配会导致代码耦合度过高。我们的解决方案是引入one-api服务作为统一的模型网关，将所有第三方模型的API统一转换为OpenAI格式。在系统内部，我们只需要适配OpenAI的接口规范，通过配置不同的baseUrl和apiKey就能接入各种模型。同时我们还自研了SDK组件，封装了模型调用的通用逻辑，包括重试机制、超时处理、错误码转换等。这种设计不仅简化了开发复杂度，还提升了系统的稳定性和可扩展性，当需要接入新模型时只需要在one-api层配置即可。

12. 大规模并发场景下，AI Agent的性能是如何保证的？

回答：我们从多个维度进行了性能优化。首先是连接池管理，为每个模型API配置了独立的连接池，避免相互影响；其次是异步处理，所有AI调用都采用异步方式，通过ResponseBodyEmitter实现流式响应，用户可以实时看到AI的思考过程；然后是缓存策略，对于相同的问题我们会缓存AI的回答，减少重复计算；在资源调度上，我们使用自定义的线程池进行任务分发，根据任务类型和优先级进行智能调度。此外，我们还实现了熔断降级机制，当某个模型服务不可用时自动切换到备用模型，保证服务的高可用性。通过这些优化，我们的系统能够支持数千并发用户同时使用。

13. 如何保证AI Agent执行过程中的数据一致性？

回答：我们采用了事件驱动架构来保证数据一致性。每个AI Agent的执行过程被拆分为多个步骤，每个步骤完成后都会发布相应的事件，下一个步骤监听事件后开始执行。在数据库层面，我们使用了分布式事务来保证跨服务的数据一致性，关键操作都包装在事务中执行。对于长时间运行的AI任务，我们实现了断点续传机制，将执行状态持久化到数据库，即使服务重启也能从断点继续执行。同时我们还建立了完善的监控和告警机制，实时监控AI Agent的执行状态，一旦发现异常立即进行人工干预。这种设计确保了即使在复杂的业务场景下，数据的一致性和完整性也能得到保证。

14. 这个AI Agent系统给公司带来了什么实际价值？

回答：我们的AI Agent系统在多个方面为公司创造了显著价值。在开发效率方面，代码评审Agent将人工评审时间从平均2小时缩短到15分钟，准确率达到95%以上；在运维效率方面，智能巡检Agent实现了7×24小时自动监控，故障发现时间从小时级缩短到分钟级，运维人员的重复性工作减少了80%；在内容创作方面，文章生成Agent帮助技术团队每月自动产出50+篇高质量技术文章，大大提升了公司的技术影响力。更重要的是，这套系统的可编排特性让我们能够快速响应新的业务需求，从需求提出到Agent上线的周期从原来的2周缩短到2天，大大提升了业务响应速度。

15. 在项目推广过程中遇到了什么阻力，是如何解决的？

回答：最大的阻力来自于用户对AI准确性的担忧和使用习惯的改变。为了解决这个问题，我们采用了渐进式推广策略。首先选择了代码评审这个相对低风险的场景进行试点，通过大量的测试数据证明AI的准确性；然后我们设计了人机协作的工作模式，AI负责初步分析，人工负责最终决策，让用户逐步建立信任；在用户体验方面，我们提供了详细的操作文档和培训视频，还建立了用户反馈机制，根据用户建议持续优化产品功能。经过3个月的推广，用户接受度从最初的30%提升到了85%，现在已经成为团队日常工作的重要工具。

16. 未来你们计划如何进一步优化和扩展这个系统？

回答：我们有几个重要的优化方向。首先是增强AI Agent的自主学习能力，通过强化学习让Agent能够从历史执行结果中学习，不断优化自己的决策策略；其次是扩展更多的业务场景，比如客服机器人、数据分析助手、项目管理助手等；在技术架构方面，我们计划引入更先进的向量数据库和图数据库，提升知识检索的准确性和效率；在用户体验方面，我们正在开发移动端应用，让用户能够随时随地使用AI Agent服务。同时我们也在探索多模态AI的应用，让Agent能够处理图片、音频、视频等多种类型的数据，进一步扩展应用场景。预计在未来一年内，我们的AI Agent系统将覆盖公司80%以上的业务流程。

17. 在设计通用对话分析模型时，你们是如何处理问题分析、自主规划、精准执行这个循环的？

回答：我们设计了一个四阶段的执行循环：问题分析、自主规划、精准执行、内容判罚。在问题分析阶段，AI Agent首先理解用户意图，提取关键信息和上下文；自主规划阶段，Agent根据可用的工具和知识库制定执行计划，选择最优的执行路径；精准执行阶段，按照计划调用相应的MCP工具和Advisor，获取执行结果；内容判罚阶段，Agent评估执行结果是否满足用户需求，如果不满足则重新进入规划阶段。整个过程中，我们为每个阶段配置了不同的Model、MCP、Prompt组合，比如规划阶段使用逻辑推理能力强的模型，执行阶段使用工具调用能力强的模型。这种设计让AI Agent具备了类似人类的思考和执行能力。

18. 你们的向量数据库检索性能是如何优化的？

回答：我们从多个层面优化了向量检索性能。在索引层面，PGVector使用了HNSW（Hierarchical Navigable Small World）算法构建高效的向量索引，支持近似最近邻搜索；在查询优化方面，我们实现了查询缓存机制，对于相似的查询直接返回缓存结果；在数据分片方面，我们按照业务领域对向量数据进行分片存储，减少检索范围；在并发控制方面，我们使用了连接池和异步查询，提升并发处理能力。此外，我们还实现了智能的预加载机制，根据用户的历史查询模式预先加载可能需要的向量数据到内存中。通过这些优化，我们的向量检索响应时间从原来的500ms优化到了50ms以内，同时支持千级并发查询。

19. 在实现MCP服务的过程中，stdio和sse两种模式各有什么优缺点？

回答：stdio模式的优点是实现简单，适合本地工具调用，通信开销小，调试方便；缺点是只能用于本地服务，不支持远程调用，扩展性有限。sse模式的优点是支持远程调用，可以跨网络部署，支持实时双向通信，扩展性强；缺点是实现复杂度高，需要处理网络异常和重连机制，通信开销相对较大。在实际应用中，我们根据具体场景选择合适的模式：对于文件系统操作、本地命令执行等场景使用stdio模式；对于微信通知、CSDN发帖、远程API调用等场景使用sse模式。为了统一开发体验，我们封装了通用的MCP客户端，屏蔽了底层通信细节，开发者只需要关注业务逻辑即可。

20. 你们是如何保证AI Agent在复杂业务场景下的稳定性的？

回答：我们建立了多层次的稳定性保障机制。在架构层面，采用微服务设计，单个服务的故障不会影响整个系统；在服务层面，实现了熔断降级机制，当某个依赖服务不可用时自动切换到备用方案；在数据层面，建立了完善的备份和恢复机制，关键数据都有多副本保护；在监控层面，实现了全链路监控，从请求接入到响应输出的每个环节都有详细的监控指标；在异常处理方面，我们为每种可能的异常场景都设计了对应的处理策略，包括重试、降级、人工介入等。此外，我们还建立了完善的测试体系，包括单元测试、集成测试、压力测试、混沌工程测试等，确保系统在各种极端情况下都能稳定运行。通过这些措施，我们的系统可用性达到了99.9%以上。

随着课程进展和大家面试遇到的问题，持续更新这部分内容。