group-buy-market-banyv

# 1. Project Overview - Project Name: `ai-agent-station-study`, from the root module [pom.xml](/e:/xfg-code/ai-agent-station-study/pom.xml). - Core Objective: To make "models, prompts, MCP tools, memory, RAG, and execution strategies" into configurable components, assemble them into different roles of `ChatClient` at runtime, and then execute user tasks by different Agent strategies. - Problem Solved: Avoid hardcoding Agent capabilities in the code, but instead, quickly switch models, prompts, tools, advisors, and execution processes through database configuration and startup assembly. - Oriented Scenarios: Content generation and release, operation and maintenance monitoring analysis, knowledge Q&A, and Agent execution with timed tasks. Test and deployment scripts directly appear in CSDN release, WeChat public account notification, Grafana/Prometheus analysis and other scenarios, [FlowAgentExecuteTest.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/test/java/cn/bugstack/ai/test/domain/FlowAgentExecuteTest.java) and [docker-compose-app.yml](/e:/xfg-code/ai-agent-station-study/docs/dev-ops/docker-compose-app.yml#L6) are obvious. - One-sentence summary: This is an "Agent orchestration platform based on Spring AI + MCP + RAG + configuration-driven assembly", not a single chat interface, but an assembleable and switchable strategy Agent Runtime. Core Code Entrance: [Application.java:9](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/Application.java#L9) [AiAgentController.java:26](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java#L26) [AiAgentAutoConfiguration.java:32](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentAutoConfiguration.java#L32) # 2. Project Overall Architecture The overall structure is a DDD-style multi-module monolith, and the module split is shown in [pom.xml:11](/e:/xfg-code/ai-agent-station-study/pom.xml#L11). ```text User / Scheduled Task -> Trigger Layer -> HTTP Controller / Scheduler Provider -> Dispatch Layer -> Select execution strategy according to ai_agent.strategy -> Auto Strategy or Flow Strategy -> Read ai_agent_flow_config to get role configuration for each step -> Call assembled ChatClient at runtime -> Model (OpenAI compatible) -> MCP Tools -> Advisor (Memory / RAG) -> System Prompt -> SSE outputs results in stages Configuration Data Flow MySQL(ai_agent / ai_client_*) -> Repository -> Armory assembly chain -> OpenAiApi Bean -> McpSyncClient Bean -> OpenAiChatModel Bean -> Advisor Bean -> ChatClient Bean Knowledge Base Data Flow File / Document -> TikaDocumentReader + TokenTextSplitter -> PgVector -> RagAnswerAdvisor similarity retrieval ``` Layered Responsibilities: - `app`: Spring Boot startup, data source, vector library, thread pool, and automatic assembly configuration. [ai-agent-station-study-app/pom.xml](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/pom.xml) - `trigger`: HTTP entrance and task trigger. [AiAgentController.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java) [AgentTaskJob.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/job/AgentTaskJob.java) - `domain`: Real Agent orchestration, execution strategy, Armory assembly logic, and domain objects. - `infrastructure`: Repository, MyBatis DAO, PO. - `api`: External interface contract DTO. - `types`: Common exceptions, constants, and basic task scheduling components. Module Collaboration Method: - `trigger` does not directly assemble models, only responsible for receiving requests and calling dispatch. - `domain` does not directly query SQL, but through `IAgentRepository`. - `infrastructure` is responsible for assembling multiple configuration tables into `VO`. - `app` assembles configurations into Spring Beans at startup and directly obtains them by beanName during execution. # 3. Project Workflow Here is a more suitable understanding of the project workflow: "Startup Phase -> Two Lines and Strategy Phase -> Capability Invocation Phase". This not only explains how the code runs but also clarifies the project design ideas: `auto` and `flow` are two main execution lines, and RAG, MCP, Prometheus, CSDN, and WeChat notifications are not a third main line but rather capabilities that are mounted on `ChatClient` and dynamically called by the main lines. ## Startup Phase 1. Spring Boot starts from [Application.java:12](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/Application.java#L12) and reads [application.yml:5](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/application.yml#L5) to activate `dev`. This layer only does the work of "running the host service" and does not enter the specific Agent execution. 2. `DataSourceConfig` creates two sets of data sources, MySQL and PGVector, [DataSourceConfig.java:20](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/DataSourceConfig.java#L20) [DataSourceConfig.java:68](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/DataSourceConfig.java#L68). MySQL is responsible for saving configurations such as Agent, Client, Prompt, MCP, Advisor, and TaskSchedule, while PGVector is responsible for subsequent knowledge retrieval. 3. `AiAgentConfig` creates `vectorStore`, with the underlying implementation being `PgVectorStore + OpenAiEmbeddingModel`, [AiAgentConfig.java:14](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentConfig.java#L14). The significance of this step is to prepare the RAG infrastructure in advance, so that if a client is equipped with `RagAnswerAdvisor`, it can directly query the vector database. 4. `ThreadPoolConfig` creates a business thread pool, [ThreadPoolConfig.java:16](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/ThreadPoolConfig.java#L16). This is not an ordinary "thread pool added for convenience" but one of the execution infrastructures of the entire project, as the asynchronous execution of dispatch and the concurrent configuration query during the assembly phase depend on it. 5. `AiAgentAutoConfiguration` triggers automatic assembly after `ApplicationReadyEvent`, [AiAgentAutoConfiguration.java:41](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentAutoConfiguration.java#L41). It reads `client-ids` from [application-dev.yml:55](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/application-dev.yml#L55) and pre-assembles these clients into the Spring container. The `client-ids` followed by a series of numbers: - Numbers: Node numbers - A set of numbers: A workflow; different sets of numbers: Different workflow versions in different scenarios, for example: - 3101~3104: General Auto - 4101~4104: Log/ES analysis version Auto - 5101~5104: Prometheus/Grafana monitoring version Auto - 2101~2103: Flow But there's an additional key point: - The numbers themselves are not "capability names" but "step node numbers". - They are actually bound to how this node works: - What Prompt to use - What model to use - Whether to call tools - Is it an analyzer, executor, or supervisor? - So, you can think of it as: - 3101 is not just a number - It actually represents "the first analysis node, which has its own exclusive way of working" After the project starts, it will first create a batch of ChatClients that Agents will use at runtime and put them into the Spring container for standby. You can think of ChatClient as: - It is not just a model object - It is a combination shell of "model + Prompt + tools + Advisor + invocation entry" You can think of it as: - The Spring container is like a "tool warehouse", and AiAgentAutoConfiguration creates commonly used AI clients after the application starts and puts them into the warehouse. When executing auto or flow steps, you can directly get the client by clientId without having to assemble it temporarily. The project includes which ChatClients: - The ChatClients in this project are divided into two layers: - Role layer, such as TASK_ANALYZER_CLIENT, PLANNING_CLIENT, EXECUTOR_CLIENT - Instance layer, which is the specific Bean registered in the Spring container by clientId, such as ai_client_3101, ai_client_5102. The mapping relationship between roles and instances is configured by the ai_agent_flow_config table, not hardcoded in the code. ## Automatic Assembly Phase 6. The first step of automatic assembly is to construct `ArmoryCommandEntity(commandType=client, commandIdList=...)`, [AiAgentAutoConfiguration.java:76](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentAutoConfiguration.java#L76). The role of this object is to clearly pass to the Armory total assembler "which type of object to assemble now and which IDs to assemble". 7. The Armory root node [RootNode.java:37](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/RootNode.java#L37) will find the corresponding loading strategy according to `commandType`, and the specific strategy mapping is driven by [ArmoryCommandEntity.java:19](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/model/entity/ArmoryCommandEntity.java#L19). Currently, it mainly adopts the client assembly. 8. `AiClientLoadDataStrategy` will query API, Model, Prompt, MCP, Advisor, and Client six types of configurations concurrently, [AiClientLoadDataStrategy.java:32](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/business/data/impl/AiClientLoadDataStrategy.java#L32). This is a key point: the project does not hardcode models and Prompts in the code but batch queries the required metadata at runtime. 9. The assembly chain will register `OpenAiApi -> McpSyncClient -> OpenAiChatModel -> Advisor -> ChatClient` in sequence, corresponding to [AiClientApiNode.java:19](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientApiNode.java#L19), [AiClientToolMcpNode.java:28](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientToolMcpNode.java#L28), [AiClientModelNode.java:23](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientModelNode.java#L23), [AiClientAdvisorNode.java:26](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientAdvisorNode.java#L26), [AiClientNode.java:24](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientNode.java#L24). 10. The final output of this assembly chain is not an "abstract configuration object" but a directly callable `ChatClient` Bean. That is to say, after a request comes in, the strategy layer no longer cares about how to build the model, how to hang tools, and how to assemble Advisor but only needs to "pick the right client to execute". # Tool List ## Two Lines with Strategy Period 1. HTTP requests enter from `/api/v1/agent/auto_agent` and are received by [AiAgentController.java:37](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java#L37). The core inputs here are not complex protocols but rather `aiAgentId + message + sessionId + maxStep`. 2. The Controller constructs `ExecuteCommandEntity(aiAgentId, message, sessionId, maxStep)`, [AiAgentController.java:52](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java#L52). The purpose of this step is to convert web layer parameters into domain layer unified command objects. 3. Next, it enters `AgentDispatchDispatchService`. It queries the Agent metadata in the `ai_agent` table based on `aiAgentId` and obtains the `strategy` field, [AgentDispatchDispatchService.java:38](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/dispatch/AgentDispatchDispatchService.java#L38) [ai_agent_mapper.xml:62](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/mybatis/mapper/ai_agent_mapper.xml#L62). 4. It's essential to note that the current project does not "temporarily decide whether to go auto or flow based on the user's problem." Instead, it "first finds the pre-configured strategy for this Agent based on `aiAgentId` and then directs the flow." This means that the choice of `auto/flow` is configuration-driven, not content-driven. 5. Dispatch then retrieves the corresponding strategy bean from `executeStrategyMap` and executes it asynchronously in a thread pool, [AgentDispatchDispatchService.java:28](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/dispatch/AgentDispatchDispatchService.java#L28) [AgentDispatchDispatchService.java:47](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/dispatch/AgentDispatchDispatchService.java#L47). Therefore, the Controller is responsible for access, and Dispatch is responsible for routing, while the actual orchestration logic is inside the strategy. 6. Regardless of which line is taken, the strategy root node will first load the step configuration and `step_prompt` of the current Agent from `ai_agent_flow_config`, which includes "which role executes each step, what prompt words are used, and what the order is." This corresponds to [auto RootNode.java:33](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/RootNode.java#L33) [flow RootNode.java:32](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/RootNode.java#L32) [ai_agent_flow_config_mapper.xml:47](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/mybatis/mapper/ai_agent_flow_config_mapper.xml#L47). 7. The `Auto` line enters [AutoAgentExecuteStrategy.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/AutoAgentExecuteStrategy.java) and initializes context variables like `step`, `maxStep`, `executionHistory`, and `currentTask` in `DynamicContext`. It then starts executing in a loop. This indicates that it is essentially a "multi-round closed loop" rather than a "one-time link." 8. The first step of `Auto` is `Step1AnalyzerNode`, [Step1AnalyzerNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step1AnalyzerNode.java). Its responsibility is not to do the actual work but to judge whether the current task is clear enough, whether it needs to be broken down further, and what the current completion status is. It writes the analysis results back into the context and determines whether it has `COMPLETED` based on keywords. 9. The second step of `Auto` is `Step2PrecisionExecutorNode`, [Step2PrecisionExecutorNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step2PrecisionExecutorNode.java). This step is where the actual action is executed. It calls the corresponding role client based on the analysis results, current task, and historical records, and appends the results to `executionHistory`. 10. The third step of `Auto` is `Step3QualitySupervisorNode`, [Step3QualitySupervisorNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step3QualitySupervisorNode.java). The supervisor checks if the execution results of this round meet the standards. If not, it generates a new `currentTask` for the next round to continue; if it passes, it sets the completion status. 11. The fourth step of `Auto` is `Step4LogExecutionSummaryNode`, [Step4LogExecutionSummaryNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step4LogExecutionSummaryNode.java). This layer no longer pursues "continuing to do things" but instead integrates the multi-round execution process, conclusions, and outputs into user-readable results and finally ends the SSE. 12. Therefore, `Auto` is more suitable for being described as a "analyze -> execute -> supervise -> re-execute -> summarize" closed-loop self-reflection process. Its advantages are that it is suitable for tasks with vague goals and requires multi-round revisions, but it relies heavily on the output format and keywords of the model. 13. The `Flow` line enters [FlowAgentExecuteStrategy.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/FlowAgentExecuteStrategy.java) and does not perform closed-loop iterations like `Auto` but rather works like a typical Plan-and-Execute workflow. 14. The first step of `Flow` is `Step1McpToolsAnalysisNode`, [Step1McpToolsAnalysisNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step1McpToolsAnalysisNode.java). Its responsibility is to identify which tools and external capabilities are needed for the current task, which is not for final execution but for resource awareness. 15. The second step of `Flow` is `Step2PlanningNode`, [Step2PlanningNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step2PlanningNode.java). It generates a task plan based on user demands and tool analysis results, essentially doing task decomposition. 16. The third step of `Flow` is `Step3ParseStepsNode`, [Step3ParseStepsNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step3ParseStepsNode.java). Because the planning result is text or Markdown, this step parses the text plan into structured steps and writes them into `stepsMap` for subsequent execution. 17. The fourth step of `Flow` is `Step4ExecuteStepsNode`, [Step4ExecuteStepsNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step4ExecuteStepsNode.java). It traverses the planned steps in order, calls and executes the role client and external tools step by step, and finally summarizes the results. 18. Therefore, `Flow` is more suitable for being described as a "identify tools -> make plans -> parse steps -> execute steps" workflow pattern. Its advantages are that the structure is clear and it is suitable for tasks that involve multiple tools in series, but the planning text parsing is relatively fragile. 19. From the perspective of interview expression, you can describe these two lines as: `Auto` tends to be a closed-loop self-reflection, while `Flow` tends to be a workflow execution that can be broken down. They share the same underlying capabilities but have different top-level orchestration methods. ## Capability Invocation Period 1. The two main lines do not create models, tools, or retrievers themselves but instead go to the Spring container to retrieve the `ChatClient` Bean that has been assembled based on `clientId`. This is one of the most critical abstract boundaries of the entire architecture. 2. The internal capability composition of a `ChatClient` can be understood as: `system prompt + model + tool callbacks + advisors + default options`. That is, the strategy layer sees is the "role client" rather than the underlying technical details. 3. The system prompt is assembled into `defaultSystem` by `AiClientNode` during the assembly period, [AiClientNode.java:39](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientNode.java#L39). This means different roles can share a set of execution engines but present different responsibilities through different prompts. 4. If a client is equipped with MCP tools, these tools will be hung on the `ChatClient` as `defaultToolCallbacks`, [AiClientNode.java:76](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientNode.java#L76). The logic for registering external tools is in [AiClientToolMcpNode.java:28](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientToolMcpNode.java#L28). 5. Therefore, capabilities like Prometheus/Grafana queries, CSDN posting, and WeChat notifications should be understood as "tool capabilities." They are not independent main lines but are called by the current role client through MCP callbacks during certain steps. 6. If a client is equipped with an Advisor, these Advisors will be hung on the `ChatClient` as `defaultAdvisors`, [AiClientNode.java:73](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientNode.java#L73). This indicates that RAG and Memory are not scattered in business code but are uniformly incorporated into the client capability model. 7. If the current client is equipped with RAG, it will first query the `VectorStore` before calling the model and then append the retrieval results to the context, [RagAnswerAdvisor.java:46](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/factory/element/RagAnswerAdvisor.java#L46). So, RAG is more accurately described as a "knowledge enhancement capability" rather than a "third process line." 8. If the current client is equipped with Memory, it will bring historical messages into the current call through `PromptChatMemoryAdvisor`. That is, Memory solves "context continuity," while RAG solves "external knowledge supplementation," and the two have different responsibilities but are plugged into the Advisor in a unified manner at runtime. 9. In the `Auto` line, capability invocation usually unfolds around "current task + historical execution records + supervision feedback." In the `Flow` line, capability invocation typically revolves around "current step + planning results + tool input parameters." Although the two lines share the capability layer, the way contexts are organized is different. 10. For example, a task to "generate an article and post it to CSDN and then send a WeChat notification" will first do tool analysis, plan steps, and then execute step 1 to generate content, step 2 to call MCP to post to CSDN, and step 3 to call MCP to send WeChat. Here, CSDN and WeChat are capabilities, not the process itself. 11. For another example, a task to "analyze the interface TPS and response time of Prometheus/Grafana," if an Agent is configured with `auto`, then the Analyzer first judges the analysis path, the Executor actually calls the Grafana/Prometheus tool to query, and the Supervisor checks if the results are complete. At this time, Prometheus/Grafana is still just a tool capability, but it is called by the `auto` main line. 12. During the entire execution process, each step's result is encapsulated into `AutoAgentExecuteResultEntity(type/subType/content/sessionId)` and returned to the front end through SSE, [AutoAgentExecuteResultEntity.java:17](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/model/entity/AutoAgentExecuteResultEntity.java#L17). Therefore, the front end sees not a single return but a streaming display of the "main line execution process + capability invocation results." 13. If this workflow is summarized in one sentence, it can be described as: the project first puts capabilities into `ChatClient` during startup, and when a request arrives, it selects `auto` or `flow` based on `aiAgent.strategy` and finally completes the task by calling capabilities like Tool, RAG, Memory, and Model in each step of the main line. # 4. Technical Stack Analysis - Java 17: Basic language version, root POM specified [pom.xml:34](/e:/xfg-code/ai-agent-station-study/pom.xml#L34). Suitable for Spring Boot 3 / Spring AI; advantages include stable ecosystem, disadvantages include higher runtime resource overhead compared to Go/Python simple scripts. - Spring Boot 3.4.3: Application startup, IOC, Web container, [pom.xml:59](/e:/xfg-code/ai-agent-station-study/pom.xml#L59). Suitable for enterprise backend and component assembly. - Spring AI 1.0.0: LLM, Tool Calling, Advisor, VectorStore, MCP integration main framework, [pom.xml:122](/e:/xfg-code/ai-agent-station-study/pom.xml#L122) [ai-agent-station-study-app/pom.xml](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/pom.xml). Advantages include alignment with Spring ecosystem, disadvantages include complex workflow control capabilities not as strong as LangGraph/Temporal specialized orchestration engines. - MyBatis: Configuration center data access layer, [DataSourceConfig.java:48](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/DataSourceConfig.java#L48). Advantages include controllable SQL, suitable for multi-table configuration aggregation; disadvantages include more mapping layer template code. - MySQL: Stores Agent/Client/Prompt/MCP/Advisor/TaskSchedule configuration, [ai_agent_mapper.xml](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/mybatis/mapper/ai_agent_mapper.xml) [ai_client_config_mapper.xml](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/mybatis/mapper/ai_client_config_mapper.xml). - PostgreSQL + PGVector: Knowledge base storage, [AiAgentConfig.java:30](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentConfig.java#L30) [init.sql](/e:/xfg-code/ai-agent-station-study/docs/dev-ops/pgvector/sql/init.sql). - MCP Client: Supports SSE/STDIO two tool transmission, [AiClientToolMcpNode.java:72](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientToolMcpNode.java#L72). Suitable for standardizing external tool capabilities access. - Advisor mechanism: Attaches memory and RAG to ChatClient, [AiClientAdvisorTypeEnumVO.java:26](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/model/valobj/enums/AiClientAdvisorTypeEnumVO.java#L26). - SSE: Server-side streaming returns multi-stage results, [AiAgentController.java:49](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java#L49). Suitable for process display, but current implementation uses `ResponseBodyEmitter` manual SSE data splicing, not as direct as `SseEmitter` semantics. - Thread pool: Business execution and concurrent configuration loading, [ThreadPoolConfig.java:20](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/ThreadPoolConfig.java#L20). - Logging: Logback asynchronous rolling file, [logback-spring.xml](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/resources/logback-spring.xml). Advantages include complete logging; disadvantages include no link tracking, structured埋点 not enough. - Scheduling: Built-in lightweight task scheduler, no dependency on MQ, [TaskJobAutoConfig.java:28](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-types/src/main/java/cn/bugstack/ai/types/job/config/TaskJobAutoConfig.java#L28). - Testing: Junit4 + SpringBootTest + DAO integration testing, but skips tests during packaging, [ai-agent-station-study-app/pom.xml:143](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/pom.xml#L143). Supplementary judgment: - No frontend framework source code; `docs/dev-ops/nginx/html` seems more like a static demo page, not a formal frontend project. - Redis, JWT, Retrofit, Guava Cache basically not used in the current main process, just dependency or placeholder configuration. - No Actuator/Micrometer dependency, indicating the monitoring system is more focused on the external environment scripts rather than application-level indicators. # 5. Core Module Disassembly ## Trigger Entrance - Role: Receives user requests and scheduled task triggers. - Key locations: [AiAgentController.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java) [AgentTaskJob.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/job/AgentTaskJob.java) - Input: `AutoAgentRequestDTO` or task scheduling record. - Output: `ResponseBodyEmitter` streaming result or background asynchronous execution. - Highlight: Both HTTP and scheduled tasks reuse unified dispatch. - Issue: Controller injects `autoAgentExecuteStrategy` and `threadPoolExecutor` but not used, [AiAgentController.java:29](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java#L29) [AiAgentController.java:32](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java#L32). ## Dispatch Scheduling Module - Role: Selects execution strategy based on `ai_agent.strategy`. - Key location: [AgentDispatchDispatchService.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/dispatch/AgentDispatchDispatchService.java) - Implementation idea: First queries `ai_agent` table, then takes strategy from Spring container's `Map<String, IExecuteStrategy>` by beanName. - Input: `ExecuteCommandEntity` - Output: Asynchronous trigger strategy execution - Highlight: Strategy selection and entrance decoupling. - Issue: `flow` and `auto` currently not implementing the same interface type, exists real bug risk, listed separately below. ## Armory Assembly Module - Role: Assembles configuration from database into runtime `ChatClient`. - Key locations: [RootNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/RootNode.java) [AbstractArmorySupport.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AbstractArmorySupport.java) - Core link: API -> MCP -> Model -> Advisor -> Client. - Input: `ArmoryCommandEntity(commandType, commandIdList)` - Output: Multiple named Beans, e.g., `ai_client_3101` - External dependencies: MySQL configuration table, OpenAI compatible model endpoint, MCP server endpoint, PGVector - Highlight: Truly componentalizes model layer capabilities. - Optimizable point: Currently "startup pre-assembly", not "on-demand assembly per agent". ## Repository Configuration Aggregation Module - Role: Combines multiple configuration tables into domain VO. - Key location: [AgentRepository.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-infrastructure/src/main/java/cn/bugstack/ai/infrastructure/adapter/repository/AgentRepository.java) - Implementation idea: First queries `ai_client_config` relationship table, then joins tables for model/api/prompt/advisor/mcp. - Highlight: Database model is a "relationship configuration center", not a single large wide table. - Issue: Reading link is deep, validation is weak, easily leads to runtime null pointer or bean missing. ## Auto Agent Execution Strategy - Role: Performs "analysis -> execution -> supervision -> summary" closed-loop iteration. - Key locations: [AutoAgentExecuteStrategy.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/AutoAgentExecuteStrategy.java) [Step1AnalyzerNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step1AnalyzerNode.java) [Step2PrecisionExecutorNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step2PrecisionExecutorNode.java) [Step3QualitySupervisorNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step3QualitySupervisorNode.java) [Step4LogExecutionSummaryNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step4LogExecutionSummaryNode.java) - Input: User's original task - Output: Phased SSE + final summary - Design highlight: Has a Supervisor link, can form the simplest self-reflection. - Risk: State judgment relies on text keywords, e.g., `任务状态: COMPLETED`、`是否通过: FAIL`, [Step1AnalyzerNode.java:56](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step1AnalyzerNode.java#L56) [Step3QualitySupervisorNode.java:56](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/auto/step/Step3QualitySupervisorNode.java#L56). ## Flow Agent Execution Strategy - Role: Performs "tool analysis -> planning -> plan parsing -> sequential execution" workflow. - Key locations: [FlowAgentExecuteStrategy.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/FlowAgentExecuteStrategy.java) [Step1McpToolsAnalysisNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step1McpToolsAnalysisNode.java) [Step2PlanningNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step2PlanningNode.java) [Step3ParseStepsNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step3ParseStepsNode.java) [Step4ExecuteStepsNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step4ExecuteStepsNode.java) - Input: Complex tasks requiring collaboration of multiple tools - Output: Planning result, execution result, final summary - Highlight: Clearly a Plan-and-Execute mode, suitable for explaining "workflow Agent" in interviews. - Risk: Planning output is Markdown, parsing relies on regular expressions, [Step3ParseStepsNode.java:84](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/execute/flow/step/Step3ParseStepsNode.java#L84), which can be fragile. ## Memory / RAG Module - Role: Adds memory and knowledge retrieval to ChatClient. - Key locations: [AiClientAdvisorTypeEnumVO.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/model/valobj/enums/AiClientAdvisorTypeEnumVO.java) [RagAnswerAdvisor.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/factory/element/RagAnswerAdvisor.java) - Implementation idea: `ChatMemory` uses `PromptChatMemoryAdvisor`, `RagAnswer` uses custom Advisor wrapping `VectorStore.similaritySearch`. - Highlight: Not writing RAG into business code, but as a pluggable Advisor. - Issue: Knowledge base import only in test samples, [OpenAiTest.java:117](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/test/java/cn/bugstack/ai/test/spring/ai/OpenAiTest.java#L117), production link missing. # 6. How the Project is Implemented - Request Reception and Distribution: The Controller is only responsible for access, and the actual strategy selection occurs in the dispatch layer. - Task Decomposition: `auto` relies on analyzing the Prompt to determine the status; `flow` performs tool analysis first, then generates a plan. - Agent Decision-Making: `auto` uses text keywords to drive the state machine; `flow` uses planning results to drive sequential execution. - Tool Registration: `ai_client_tool_mcp` table defines the transmission method and configuration, Repository parses JSON, and `AiClientToolMcpNode` converts it into `McpSyncClient`. - Prompt Organization: There are two layers. - System Prompt: Comes from `ai_client_system_prompt`, assembled into `defaultSystem` in `AiClientNode`. - Step Prompt: Comes from `ai_agent_flow_config.step_prompt`, configured separately for each role of the agent. - Context Maintenance: - Session Level: Through `PromptChatMemoryAdvisor` and `chat_memory_conversation_id`. - Process Level: Saves `currentTask`, `executionHistory`, `stepsMap`, `analysisResult`, etc. through `DynamicContext`. - RAG Injection: `RagAnswerAdvisor` retrieves, then adds the retrieval result to the context area below the user's message. - Database Storage Content: - `ai_agent`: Agent metadata and strategy - `ai_agent_flow_config`: Step roles and prompts for each Agent - `ai_client*`: Model, API, Prompt, MCP, Advisor component configuration - `ai_agent_task_schedule`: Scheduled tasks - `ai_client_rag_order`: Knowledge base label configuration, but the main process does not consume it yet - State Management: No independent state machine framework, state is in `DynamicContext` and LLM output text. - Fault Tolerance and Retry: The main process does not have unified retry, circuit breaking, current limiting, or idempotence; more is log recording or skipping. - Permission Control: The current main link does not have authentication, tenant isolation, or tool authorization boundary control. # 7. Agent Orchestration Special Analysis My Judgment: This project "has Agent, but it's not a strictly multi-agent autonomous collaboration platform in the strict sense", it's more accurately described as a "configuration-driven role-based LLM orchestration system". Auto Orchestration: - Roles: `TASK_ANALYZER_CLIENT`, `PRECISION_EXECUTOR_CLIENT`, `QUALITY_SUPERVISOR_CLIENT`, `RESPONSE_ASSISTANT` - Collaboration Method: Serial, Analyzer checks status first, Executor performs actions, Supervisor determines whether to continue, Summary is responsible for the final answer. - Termination Condition: `completed=true` or `step > maxStep`. - Advantages: Clear structure, easy to explain "self-reflection closed loop". - Disadvantages: Strong dependence on model output format, not deterministic enough. Flow Orchestration: - Roles: `TOOL_MCP_CLIENT`, `PLANNING_CLIENT`, `EXECUTOR_CLIENT` - Collaboration Method: First recognize tools, then make plans, then parse plans into steps, and then execute step by step. - Who is responsible for decomposition: `Step2PlanningNode` - Who is responsible for tool calling: `Step4ExecuteStepsNode` corresponding execution client - Who is responsible for summarizing: `Step4ExecuteStepsNode.sendSummaryResult` - Termination Condition: All steps are executed before ending - Advantages: Suitable for long tasks, multi-tool tasks, and more like Workflow Agent in interviews - Disadvantages: Plan parsing relies on regular expressions, stability is poor; step context and execution state library capabilities are not available. Memory / Tool / RAG Relationship: - Agent itself does not directly touch underlying tools or vector databases. - Tool is hooked into `ChatClient` through `defaultToolCallbacks`. - Memory / RAG is hooked into `defaultAdvisors`. - So "Agent capability" is essentially a combination of `ChatClient(system + tools + advisors + model)`. Typical Execution: 1. User initiates "generate article and send to CSDN, then send a WeChat notification" 2. Dispatch selects `flow` based on `ai_agent.strategy` 3. `TOOL_MCP_CLIENT` determines which tools are needed 4. `PLANNING_CLIENT` produces 3 to 5 steps 5. `Step3ParseStepsNode` parses Markdown plan into `stepsMap` 6. `EXECUTOR_CLIENT` calls MCP tools to execute each step 7. SSE returns analysis, execution, summary continuously to the front end # 8. Highlights of the Project - Truly made Agent into "configuration center + runtime assembly", not a hardcoded set of Prompt and models. The assembly chain is in [AiClientLoadDataStrategy.java:74](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/business/data/impl/AiClientLoadDataStrategy.java#L74). - Supports Memory, RAG, MCP tools simultaneously, and integrates AI basic capabilities into `ChatClient` layer. - Same platform supports two execution modes: self-reflection closed loop `auto`, and plan execution flow `flow`. - Front-end experience is not a one-time return, but SSE push step by step, `type/subType` design is friendly to UI. [AutoAgentExecuteResultEntity.java:25](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/model/entity/AutoAgentExecuteResultEntity.java#L25). - Engineering is not a pure demo, already has double data sources, log rolling, scheduler, Dockerization, DAO testing, and external MCP environment scripts. # 9. Difficulties of the Project - Difficulty 1: Assembling "configuration table" into "runtime Agent". - Difficult in configuration across many tables, and strict dependency order. - Code solution is Armory chain registration Bean. - Unresolved issue is assembly failure without unified validation report. - Difficulty 2: Making LLM output consumable by workflow. - `auto` uses keyword judgment, `flow` uses Markdown + regex. - This works, but robustness is poor. - Difficulty 3: External MCP service instability. - Code skips registration if initialization fails. [AiClientToolMcpNode.java:49](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/AiClientToolMcpNode.java#L49) - Logs also show SSE/connection errors and null pointer exceptions. - Difficulty 4: Prompt and configuration consistency. - Current `step_prompt`, system prompt, client config inconsistencies easily cause runtime errors. - Difficulty 5: Knowledge base link is incomplete. - Retrieval is connected, but production入库, label management, and versioning are not yet a complete system. # 10. How to Introduce the Project in an Interview 1-minute version: The project is essentially a configuration-driven AI Agent platform. It uses Spring Boot as the host, Spring AI to unify model, RAG, memory, and MCP tools, and stores model APIs, Prompts, tools, and advisors in MySQL. It dynamically assembles different roles of `ChatClient` at startup. After user requests, the system checks `ai_agent` to decide which strategy to use. `auto` is more like analysis, execution, supervision, and summary of the closed loop Agent, while `flow` is more like planning and then executing workflow Agent. 3-minute version: This project is a Maven multi-module monolithic application, with `app` responsible for startup and configuration, `trigger` responsible for HTTP and scheduled task entry, `domain` bearing Agent orchestration and assembly logic, and `infrastructure` responsible for configuration storage. Its core design is Armory assembly chain: after startup, it reads `ai_client_*` and `ai_agent_flow_config` tables, assembles API, model, MCP tools, Prompt, and advisor into Spring Bean, and finally gets `ChatClient` like `ai_client_3101`. After requests come in, Controller only does SSE access, and Dispatch selects specific strategy based on `ai_agent.strategy`. `auto` is more like lightweight multi-role collaboration: Analyzer judges task completion, Executor performs actions, Supervisor provides feedback, and Summary provides final results. `flow` is more like workflow: tool analysis, plan generation, plan parsing, and step execution. 5-minute in-depth version: From an architectural perspective, I would say this is an "Agent platform" project, not "a Agent". The platform-level core is the configuration model. MySQL stores `ai_agent` defining specific intelligent agents and execution strategies, `ai_agent_flow_config` defining role sequences and step prompts for each Agent, and `ai_client_config` linking clients, models, prompts, MCP, and advisors. After application startup, `AiAgentAutoConfiguration` reads clientIds from configuration, triggering Armory. Armory concurrently checks six types of configurations, then registers Beans in order of `OpenAiApi -> McpSyncClient -> OpenAiChatModel -> Advisor -> ChatClient`. At runtime, what you get is an assembled Agent role client. When requests come from `/api/v1/agent/auto_agent`, Controller constructs command objects, and Dispatch checks the database to decide whether to use `auto` or `flow`. # 11. Possible Interview Questions A. Project Background 1. What problem does your project solve? Why: To see if you understand business value. Standard answer: Start with "configuration-driven Agent platform", then explain specific scenarios. B. Technical Selection 2. Why use Spring AI, not LangChain4j or LangGraph? Why: To see if you have selection awareness. Standard answer: Explain existing project context. C. Architecture Design 3. Why make Armory dynamic assembly? Why: This is the core architecture point of the project. Standard answer: Answer "decoupling configuration" and "runtime composition capability". D. Core Process 4. How does a request go from entry to result? Why: To see if you have really read through the call chain. Standard answer: Five-paragraph answer: entry, dispatch, strategy, step, SSE. E. Agent Orchestration 5. What is the difference between auto and flow strategies? Why: To see if you really understand Agent orchestration. Standard answer: One is closed-loop reflection, the other is plan execution. F. Prompt / RAG / Memory 6. How are Memory and RAG hooked into Agent? Why: To see if you understand Spring AI Advisor. Standard answer: Explain Advisor plugin. G. Database / Cache / Performance 7. Why separate MySQL and PGVector? Why: To see if your data layering is clear. Standard answer: Configuration data and vector retrieval data are two storage models. H. Engineering / Deployment 8. How is the project deployed? Why: Many candidates only talk about code, not landing. Standard answer: Explain by "application + supporting environment + MCP service". I. Optimization and Extension 9. If you continue to make it bigger, how would you evolve it? Why: To see your architecture thinking ceiling. Standard answer: Answer from stability, observability, workflow, and configuration governance. J. Follow-up / Stress Surface 10. What is the biggest pit of the current project? Why: To see if you dare to tell the truth. Standard answer: Choose a key issue that shows you have read the code. # 12. High-Quality Interview Answers 1. Q: What is this project in one sentence? A: This is a Spring AI Agent platform that makes models, prompts, MCP tools, memory, and RAG into configurable components and executes tasks through two strategy sets. 2. Q: What is the business value of the project? A: It upgrades agents from a fixed chain to a platform with assembleable capabilities, supporting content publishing, monitoring analysis, knowledge Q&A, and scheduled execution on the same underlying infrastructure. 3. Q: Why is it not just an ordinary chat interface? A: Because the core is not just `chat()`, but the assembly chain at startup and the strategy tree at runtime. Incoming requests are not directly sent to the model but are processed by selecting a strategy, then a role client, and then using tools/RAG/memory. 4. Q: How does the main request chain work? A: `AiAgentController -> AgentDispatchDispatchService -> Auto/FlowExecuteStrategy -> RootNode -> StepNode -> ChatClient -> SSE`. The database is involved in strategy and role configuration, not in business result storage. 5. Q: What is Armory? A: Armory is a runtime assembler. It converts APIs, MCPs, models, advisors, prompts, and clients from the database into Spring Beans and registers them as directly callable `ChatClient`. 6. Q: Why dynamically register beans? A: Because the project needs to support a large number of agent role combinations. If all are hardcoded in `@Bean`, it would be very rigid; dynamic registration makes configuration changes a first-class citizen. 7. Q: How does the auto strategy work? A: It analyzes the task status, executes, supervises, and if supervision fails, it enters the next round until completion or reaching the maximum steps, and finally summarizes for the user. 8. Q: How does the flow strategy work? A: It analyzes available MCP tools, makes a plan, parses the plan into steps, and then executes each step sequentially. It is more suitable for scenarios with long toolchains and clear task objectives. 9. Q: What agent roles are in the project? A: The auto path has analyzers, executors, supervisors, and summarizers; the flow path has tool analyzers, planners, and executors. They are essentially `ChatClient` with different configurations. 10. Q: How is Prompt managed? A: System prompts are stored in `ai_client_system_prompt`, and step prompts are stored in `ai_agent_flow_config.step_prompt`. The former is for the client level, and the latter is for the agent-step level. 11. Q: How is Memory implemented? A: Through `PromptChatMemoryAdvisor + MessageWindowChatMemory`, it is attached to `ChatClient` during assembly and uses `conversation_id` to connect the conversation during requests. 12. Q: How is RAG implemented? A: By customizing `RagAnswerAdvisor`, it performs similarity searches on `VectorStore`, retrieves relevant documents, and injects them into the user's message context, allowing the model to answer with the search results. 13. Q: Why use PGVector? A: Because the project is already in the Java/Spring ecosystem, PGVector has low integration cost with Spring AI, suitable for lightweight knowledge base scenarios, and does not require introducing separate systems like Milvus. 14. Q: How are MCP tools integrated? A: The `ai_client_tool_mcp` table configures tools and transmission methods, and `AiClientToolMcpNode` builds `McpSyncClient` based on `sse/stdio` and hangs it on the model or client through `SyncMcpToolCallbackProvider`. 15. Q: What best represents AI capability in the project? A: Not just calling models, but integrating tool calls, memory, RAG, planners, and executors into a configuration-driven runtime system. 16. Q: What best represents engineering capability in the project? A: Dynamic assembly chains, dual data sources, SSE streaming results, schedulers, logs, and Docker environments turn an Agent demo into a platform prototype. 17. Q: What are the biggest technical risks in the current architecture? A: One is the strong dependency on assembly integrity, and the other is the dependency on LLM output format during execution. The former can lead to bean not found errors, and the latter can cause plan parsing failures or state judgment distortions. 18. Q: Why use Markdown planning and regular expression parsing for flow instead of JSON? A: This is a lightweight solution with low development barriers and easy-to-write prompts. However, it is suggested to switch to JSON Schema or function calling for production. 19. Q: How to add a new tool? A: Prioritize configuration extensions. Add `ai_client_tool_mcp` and `ai_client_config` relationship configurations. If it's a new transmission protocol, modify `AiClientToolMcpNode`. 20. Q: How to add a new Agent? A: First, add a strategy definition in `ai_agent`, then configure each role and prompt in `ai_agent_flow_config`. If it's a new execution mode, add a new strategy/root/step. 21. Q: Why use MyBatis over JPA? A: Because it's not a typical order/user domain but involves a lot of configuration relationship aggregation. SQL control is more intuitive than ORM automatic mapping, especially for cross-table assembly of VO. 22. Q: Why use SSE? A: Because the project emphasizes "visibility of stage results," analysis, execution, supervision, and summarization should be returned progressively. A one-time return would lose the Agent's process sense and observability. 23. Q: How to reuse the main chain for scheduled tasks? A: `AgentTaskJob` takes configuration from `ai_agent_task_schedule`, constructs `ExecuteCommandEntity`, and then sends it to dispatch. Therefore, HTTP and scheduler share the same execution kernel. 24. Q: Why is the knowledge base chain not complete? A: Because only test-type storage like `OpenAiTest.upload` is seen, not formal document upload, slicing, writing back, or label governance services. 25. Q: If an interviewer questions its stability, how to answer? A: Acknowledge it and point out that the current version is more like a platform prototype. It has assembled and executed tools and RAG, but production-level stability requires structured output, assembly verification, hot updates, and unified retry mechanisms. # 13. Project Learning Path ### Stage 1: Understand the Entry Point - Learning Goal: Know how the system starts and requests come in. - Suggested Order: [Application.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/Application.java) -> [AiAgentController.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java) -> [AgentDispatchDispatchService.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/dispatch/AgentDispatchDispatchService.java). - Focus: `aiAgentId`, `strategy`, SSE. ### Stage 2: Understand Assembly - Learning Goal: Understand how `ai_client_xxxx` comes into being. - Suggested Order: [AiAgentAutoConfiguration.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentAutoConfiguration.java) -> [RootNode.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/RootNode.java) -> [AiClientLoadDataStrategy.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/business/data/impl/AiClientLoadDataStrategy.java) -> `AiClient*Node` series. - Focus: Bean registration order, configuration table relationships, naming conventions. ### Stage 3: Understand Execution Strategies - Learning Goal: Understand the differences between Auto and Flow. - Suggested Order: Start with Auto's four steps, then Flow's four steps. - Focus: What is placed in `DynamicContext`, who decides the next step, and what are the termination conditions. ### Stage 4: Supplement RAG, Memory, and Database - Learning Goal: Understand how AI capabilities are integrated. - Suggested Order: [AiClientAdvisorTypeEnumVO.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/model/valobj/enums/AiClientAdvisorTypeEnumVO.java) -> [RagAnswerAdvisor.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/armory/factory/element/RagAnswerAdvisor.java) -> [OpenAiTest.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/test/java/cn/bugstack/ai/test/spring/ai/OpenAiTest.java) -> MyBatis mapper. - Focus: Retrieval injection points, knowledge base labels, configuration tables. ### Stage 5: Use Logs for Validation - Learning Goal: Know where the system might fail in reality. - Suggested Order: Look at `data/log` for `NoSuchBeanDefinitionException`, `ResponseBodyEmitter has already completed`, template errors, and MCP initialization failures. - Focus: Assembly integrity, SSE lifecycle, tool connection stability. # 14. Final Summary - One-sentence summary of the project's essence: This is a Spring AI Agent platform that is configuration-driven, role-based, and can integrate tools and knowledge bases. - One-sentence summary of the technical core: The core is not calling models but the runtime chain of "database configuration -> Armory assembly -> strategy execution -> SSE output". - One-sentence summary of the interview selling point: You can present it as "Agent platform design" rather than "I just connected a large model interface". - One-sentence summary of the most likely questioned point: Differences between `auto` and `flow`, why Armory exists, and how RAG/Memory are integrated into ChatClient. # 15. Additional Questions and Answers 1. What are the core entry files of this project? The core entry files are [Application.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/Application.java), [AiAgentAutoConfiguration.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-app/src/main/java/cn/bugstack/ai/config/AiAgentAutoConfiguration.java), [AiAgentController.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-trigger/src/main/java/cn/bugstack/ai/trigger/http/AiAgentController.java), [AgentDispatchDispatchService.java](/e:/xfg-code/ai-agent-station-study/ai-agent-station-study-domain/src/main/java/cn/bugstack/ai/domain/agent/service/dispatch/AgentDispatchDispatchService.java), and the two strategy root nodes. 2. What are the most important 3 to 5 call chains? `Startup -> AutoConfig -> Armory -> ChatClient registration`; `HTTP -> Controller -> Dispatch -> Auto Strategy -> SSE`; `HTTP -> Controller -> Dispatch -> Flow Strategy -> Tool Calling`; `TaskJob -> AgentTaskJob -> Dispatch`; `RAG file -> Tika/slicing -> PgVector -> RagAnswerAdvisor`. 3. What are the minimum things to explain to others about this project? You must clearly explain four things: its configuration center model, Armory assembly chain, Auto/Flow execution strategies, and how Memory/RAG/MCP are integrated into ChatClient. 4. If an interviewer asks you to draw an architecture diagram on the spot, how should you draw it? Draw 6 blocks: `Client/Task -> Trigger -> Dispatch -> Strategy(auto/flow) -> ChatClient Runtime -> External LLM/MCP/RAG`. Alongside, draw `MySQL Config Center` and `PGVector Knowledge Base` as two data sources. 5. If an interviewer asks, "Why design this way, can't it be done differently?", how should you answer? You can answer: It can be done differently, but this project prioritizes "configurable switching, simple Spring integration, and lightweight landing," so in-process orchestration was chosen. If more complex long流程 and recoverable execution are needed, a state machine or workflow engine can be introduced. 6. If you are to do secondary development, where is the best place to start? The best places to start are: adding a new MCP tool; adding a new Agent role configuration; and converting the existing flow's Markdown+Regex to JSON structured output. 7. What represents engineering capability in this project? Runtime assembly represents engineering capability. Many people can write prompts, but few put prompts, models, tools, memory, RAG, task scheduling, and streaming returns into a unified runtime. 8. What represents AI/Agent capability in this project? The unified combination of "role-based orchestration + Tool Calling + Memory + RAG" represents AI/Agent capability, especially the `auto` Analyzer/Executor/Supervisor loop, which is suitable for explaining Agent thinking. 9. What are the potential bottlenecks in the current architecture? The biggest bottleneck is not CPU but stability: assembly integrity, external MCP availability, prompt structure contracts, and the fragility of flow plan parsing. 10. If the project continues to grow, how should it evolve in the future? It will evolve in four steps: unify execution interfaces and configuration validation; plan output structured; agent lazy assembly and support hot updates; and make execution status, tool calls, and retrieval results observable and traceable persistent workflows.