1. 项目概述从“一问一答”到“持续规划”的思维跃迁在AI应用开发领域我们早已习惯了“输入-处理-输出”的单轮对话模式。用户抛出一个问题模型给出一个答案任务就算完成了。然而当任务复杂度上升比如用户说“帮我设计一个电商系统的架构图”事情就变得棘手了。这不再是一个可以靠单次提示词Prompt就能完美解决的问题。它需要拆解需求、选择组件、规划布局、考虑扩展性最后生成可视化结果。这个过程天然就是多轮的、有状态的、并且需要规划能力的。这就是“多轮对话生成架构图 Agent”要解决的核心问题如何让AI像一位经验丰富的架构师通过连续、有逻辑的对话引导用户厘清需求并最终交付一个结构清晰、可落地的架构设计方案。我最近在几个内部项目中实践了这类Agent的设计踩了不少坑也总结出一些行之有效的模式。它绝不仅仅是把ChatGPT的对话历史传进去那么简单其核心在于设计一个能够进行“任务规划”、“工具调用”和“自我反思”的智能体Agent工作流。这个Agent需要理解架构领域的专业知识能将模糊的自然语言描述转化为结构化的技术组件并具备通过多轮交互澄清歧义、优化设计的能力。最终它输出的可能是一份Mermaid代码、一张PlantUML图或者直接调用绘图API生成的PNG文件。接下来我将详细拆解这个Agent的设计思路、核心模块、实操步骤以及那些只有真正动手做过才会知道的“坑”。2. 核心设计思路构建一个会“思考”的架构师工作流设计一个能生成架构图的Agent首先要摒弃“万能模型”的幻想。没有任何一个基础大语言模型LLM能凭空精通所有技术栈的架构细节。我们的设计思路是将LLM作为“大脑”和“协调器”为其配备专业的“知识”架构领域提示词与示例和“双手”画图工具与验证工具并设计一套严谨的“工作流程”来规范它的思考与行动路径。2.1 分层决策与规划循环Agent的核心是一个“感知-思考-行动”的循环但在架构设计场景下这个循环需要被细化。需求分析与任务拆解感知与规划用户输入“做一个能抗住双十一流量的电商系统”。Agent的第一步不是直接画图而是理解。它需要将这个宏大的、模糊的目标拆解成可执行、可验证的子任务。例如子任务1确定核心业务场景用户、商品、订单、支付、库存。子任务2为每个场景选择合适的技术组件网关、服务发现、数据库、缓存、消息队列。子任务3定义组件间的交互关系和数据流。子任务4考虑高可用、高并发下的特殊设计负载均衡、分库分表、弹性伸缩。子任务5将上述结构化信息转换为图形描述语言如Mermaid。工具调用与信息获取行动在拆解任务后Agent可能需要调用工具。例如在子任务2中它可能调用一个“技术选型知识库”工具查询“高并发场景下Redis和Memcached该如何选择”在子任务5中它必须调用“Mermaid生成器”工具。关键在于Agent需要根据当前思考的上下文动态决定是否需要调用工具、调用哪个工具、以及传入什么参数。反思与验证再思考生成初步架构图描述如Mermaid代码后一个优秀的Agent不应直接输出给用户。它应该进入“反思”阶段调用一个“架构图语法检查器”工具验证代码有效性甚至调用一个“架构合理性评估”工具可以是另一组提示词检查是否存在单点故障、数据一致性是否得到保障等。如果发现问题则重新规划或调整。注意这个循环不是线性的而是可能嵌套和回溯的。例如在工具调用后获得新信息可能需要对之前的任务拆解进行修正。2.2 关键状态管理记忆与上下文多轮对话的核心是状态管理。Agent必须记住整个对话历史和它自己推导出的中间状态。对话历史Conversation History保存用户与Agent的所有问答记录。这是最基础的记忆但直接将其全部扔给LLM会导致上下文过长、成本剧增且关键信息被稀释。任务链Task Chain显式地记录当前的任务拆解结果和完成状态。例如用一个列表记录[任务1: 分析场景 - 完成 任务2: 选型 - 进行中 任务3: 绘图 - 未开始]。这比隐式地在对话历史中寻找要清晰得多。架构上下文Architecture Context这是一个结构化的对象存储当前架构设计的所有关键决策。它可以是一个JSON Schema例如{ system_name: 电商平台, scenarios: [用户登录, 商品浏览, 下单支付], components: [ {name: API Gateway, type: 网关, tech: Nginx/Spring Cloud Gateway}, {name: User Service, type: 微服务, tech: Spring Boot, db: MySQL} ], interactions: [{from: Client, to: API Gateway, protocol: HTTPS}], non_functional: {availability: 99.99%, scalability: horizontal} }每轮对话都在更新这个上下文对象它也是最终生成图形的直接数据源。实操心得直接使用原始对话历史作为记忆在超过3轮复杂对话后效果会急剧下降。我采用的方法是“摘要式记忆”“结构化上下文”结合。每轮对话后用LLM对上一轮关键信息做一个简短摘要更新到“摘要记忆”中。同时任何明确的决策如技术选型都立刻更新到“架构上下文”这个结构化对象里。这样在下一轮推理时我们提供给LLM的提示词就包含了本轮用户问题 摘要记忆 当前的架构上下文。这大大减轻了模型的记忆负担并保证了核心决策的准确性。3. 核心模块拆解与实现细节一个可运行的多轮架构图Agent通常由以下几个核心模块组成。我将以Python OpenAI API (或开源LLM) LangChain用于编排的技术栈为例进行说明但思路是通用的。3.1 智能体核心Agent Core这是Agent的“大脑”负责运行规划循环。我们通常使用ReActReasoning and Acting模式或其变种。# 简化的ReAct循环伪代码 class ArchitectureAgent: def __init__(self, llm, tools, memory, context): self.llm llm self.tools tools # 工具字典 self.memory memory self.context context # 架构上下文 def run(self, user_input): # 1. 更新对话记忆 self.memory.append(“user”, user_input) # 2. 构建提示词包含角色定义、任务目标、工作流程、可用工具、记忆、当前上下文 prompt self._build_agent_prompt(user_input) # 3. LLM进行思考输出包含“思考(Thought)”、“行动(Action)”、“行动输入(Action Input)”的文本 llm_response self.llm.invoke(prompt) # 解析出 thought, action, action_input # 4. 执行行动如果存在 if action ! “FINISH”: tool self.tools[action] observation tool.run(action_input) # 将“观察(Observation)”加入记忆并回到步骤2进行下一轮思考 self.memory.append(“system”, f”Action Result: {observation}”) return self.run(“”) # 传入空输入让Agent基于观察继续思考 else: # 5. 生成最终输出如图表代码 final_output self._generate_final_output(llm_response) return final_output关键提示词设计给LLM的提示词模板是成败关键。它必须清晰定义角色你是一位资深系统架构师擅长将业务需求转化为可落地的技术架构图。工作流程你必须遵循“分析需求 - 拆解任务 - 调用工具如需- 更新设计 - 反思验证 - 最终输出”的流程。工具使用规范严格定义每个工具的名称、描述和输入格式。例如工具query_tech_stack: 根据场景和需求查询推荐的技术组件。输入应为JSON格式{“scenario”: “高并发读”, “requirement”: “低延迟”}。输出格式强制要求LLM以Thought: ... Action: ... Action Input: ...的格式回复。3.2 工具集Tools设计工具是Agent能力的延伸。对于架构图生成必备工具包括技术知识库查询工具连接到一个向量数据库如Chroma里面存储了技术文档、博客、最佳实践。当Agent不确定选型时可以从此工具获取信息。架构图语法生成器generate_mermaid: 输入结构化的架构上下文JSON输出Mermaid代码。generate_plantuml: 类似输出PlantUML代码。这个工具本身可以是一个精心设计的提示词让LLM完成转换也可以是一套硬编码的模板引擎。语法验证与渲染工具validate_mermaid: 调用Mermaid的解析库或在线服务检查代码语法是否正确。render_diagram: 将有效的代码通过Mermaid CLI或PlantUML服务器渲染成图片PNG/SVG并返回图片路径或Base64编码。架构合理性检查工具这是一个“元”工具它实际上是用另一套提示词去询问LLM“以架构评审专家的身份检查以下设计是否存在单点故障、数据一致性问题、性能瓶颈...”。它将当前架构上下文作为输入输出检查结果和建议。实操心得工具的设计要“小而专”不要设计“万能工具”。一个工具只做一件事并且要有明确的成功/失败输出。例如validate_mermaid工具就返回{“valid”: true, “error”: null}或{“valid”: false, “error”: “Syntax error at line 5”}。这能让Agent的决策逻辑更清晰。另外工具调用可能失败网络超时、API限流必须在Agent循环中设计错误处理逻辑让Agent能够应对工具异常。3.3 记忆与上下文管理模块这是保证多轮对话连贯性的“粘合剂”。对话记忆可以使用简单的List存储但更推荐使用LangChain的ConversationBufferWindowMemory或ConversationSummaryMemory。后者会自动对历史对话进行摘要非常适合长对话。架构上下文建议用一个Pydantic模型来定义确保数据结构化且易于验证。from pydantic import BaseModel from typing import List, Optional class Component(BaseModel): name: str type: str technology: Optional[str] None description: Optional[str] None class ArchitectureContext(BaseModel): project_name: str core_scenarios: List[str] components: List[Component] interactions: List[dict] constraints: dict {}在Agent运行过程中通过LLM的输出来更新这个上下文对象。可以设计专门的工具update_context由Agent在做出决策后调用。3.4 输出与展示层最终Agent需要交付一个直观的结果。代码输出直接返回Mermaid或PlantUML代码让用户在支持该语法的平台如GitLab、Notion中查看。图片输出在服务器端渲染成图片后返回图片URL或Base64数据。这体验最好。交互式输出进阶玩法是生成一个前端组件的配置如ECharts配置在网页上实现可交互的架构图点击组件查看详情。一个简单的集成示例使用Gradio或Streamlit快速搭建一个演示界面。用户输入需求界面显示Agent的“思考过程”Thoughts并最终展示生成的架构图。4. 实操流程从零搭建一个最小可行产品假设我们要用LangChain和OpenAI GPT-4 API搭建一个基础版Agent。4.1 环境准备与依赖安装# 创建虚拟环境 python -m venv arch-agent-env source arch-agent-env/bin/activate # Linux/Mac # arch-agent-env\Scripts\activate # Windows # 安装核心库 pip install langchain langchain-openai langchain-community pip install pydantic # 用于图表渲染 pip install mermaid-cli # 需要先安装Node.js和npm # 用于Web界面 pip install gradio4.2 定义架构上下文与工具# context.py from pydantic import BaseModel from typing import List class ArchitectureContext(BaseModel): system_name: str “” components: List[dict] [] data_flows: List[dict] [] # tools.py import subprocess import json from langchain.tools import tool tool def query_tech_stack(query_json: str) - str: “””查询技术选型知识库。输入应为JSON字符串包含’scenario’和’requirement’字段。””” try: query json.loads(query_json) # 这里可以连接向量数据库进行查询此处简化为规则匹配 scenario query.get(“scenario”, “”).lower() if “cache” in scenario: return “推荐使用Redis因为它支持丰富的数据结构并具备持久化能力。若只需简单键值存储且追求极致内存效率可考虑Memcached。” elif “message” in scenario: return “推荐使用Kafka处理高吞吐、持久化的日志流使用RabbitMQ处理复杂的业务消息路由RocketMQ是阿里系生态的可靠选择。” else: return “未找到精确匹配建议明确具体场景如’数据库选型’、’网关选型’。” except: return “输入格式错误请提供有效的JSON。” tool def generate_mermaid(context_json: str) - str: “””根据架构上下文生成Mermaid流程图代码。””” try: context json.loads(context_json) # 这里可以更复杂根据context结构生成不同类型的图流程图、时序图、部署图 # 此处生成一个简单的组件图 mermaid_code “graph TD\n” for comp in context.get(“components”, []): mermaid_code f” {comp[‘id’]}[{comp[‘name’]}]\n” for flow in context.get(“data_flows”, []): mermaid_code f” {flow[‘from’]} -- {flow[‘to’]}\n” return mermaid_code except Exception as e: return f”生成Mermaid代码时出错{e}” tool def validate_and_render(mermaid_code: str) - str: “””验证Mermaid代码并渲染为图片Base64。””” # 1. 简单验证可选更严格的验证需调用mermaid-cli if “graph” not in mermaid_code: return “错误非法的Mermaid代码必须以’graph’开头。” # 2. 调用mermaid-cli渲染需提前安装 import tempfile, base64, os with tempfile.NamedTemporaryFile(mode‘w’, suffix‘.mmd’, deleteFalse) as f: f.write(mermaid_code) mmd_file f.name png_file mmd_file.replace(‘.mmd’, ‘.png’) try: # 使用mermaid-cli渲染 subprocess.run([‘mmdc’, ‘-i’, mmd_file, ‘-o’, png_file], checkTrue, capture_outputTrue) with open(png_file, ‘rb’) as img_f: img_base64 base64.b64encode(img_f.read()).decode(‘utf-8’) result f”验证通过图片渲染成功。\n” except subprocess.CalledProcessError as e: result f”渲染失败Mermaid语法可能有误。错误信息{e.stderr.decode()}” finally: os.unlink(mmd_file) if os.path.exists(png_file): os.unlink(png_file) return result4.3 构建智能体与工作流# agent.py from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain_core.prompts import PromptTemplate from tools import query_tech_stack, generate_mermaid, validate_and_render from context import ArchitectureContext import json # 初始化LLM llm ChatOpenAI(model“gpt-4”, temperature0.1) # 低temperature保证决策稳定 # 定义工具列表 tools [query_tech_stack, generate_mermaid, validate_and_render] # 构建ReAct风格的提示词模板 prompt_template “”” 你是一个专业的系统架构师助手。你的目标是通过与用户的多轮对话最终生成一个准确、清晰的技术架构图。 你必须严格按照以下步骤工作 1. **理解与澄清**仔细分析用户当前输入和对话历史。如果需求模糊必须主动提问澄清例如系统预期QPS是多少数据一致性要求如何。 2. **规划与拆解**将架构设计任务拆解为确定边界上下文、选择技术组件、定义交互关系。 3. **调用工具**如果你需要专业信息来做出技术选型请调用query_tech_stack工具。当你认为架构设计已足够清晰可以生成图表时调用generate_mermaid工具。生成代码后务必调用validate_and_render进行检查和可视化。 4. **更新上下文**在内部维护一个架构上下文记录所有已确定的组件和交互。 5. **反思**在最终输出前检查架构是否存在明显缺陷如单点故障、循环依赖。 当前对话历史 {history} 当前架构上下文JSON格式 {context} 用户最新输入{input} 你拥有以下工具 {tools} 请严格按以下格式回应 Thought: 我需要思考当前情况并决定下一步行动 Action: 要调用的工具名必须是[{tool_names}]中的一个如果没有必要则填“FINISH” Action Input: 调用工具的输入必须是一个合法的JSON字符串如果工具需要的话 一旦你生成了最终的架构图即调用validate_and_render成功并得到图片且用户没有新的修改意见你的最终回复应该是图片结果和简要说明。 “”” prompt PromptTemplate.from_template(prompt_template) # 创建Agent agent create_react_agent(llm, tools, prompt) # 创建执行器并传入初始化的记忆和上下文 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 初始化记忆和上下文 memory [] # 简化处理实际应用可用ConversationBufferMemory context ArchitectureContext() def run_agent_conversation(user_input): global context # 构建传入Agent的完整输入 formatted_input { “input”: user_input, “history”: “\n”.join(memory[-5:]), # 只保留最近5轮历史 “context”: context.json(), “tools”: “, “.join([t.name for t in tools]), “tool_names”: “, “.join([t.name for t in tools]) } memory.append(f”User: {user_input}”) # 执行Agent response agent_executor.invoke(formatted_input) # 解析输出更新上下文这里需要从Agent的输出中提取更新信息实际会更复杂 # 假设Agent的最终输出包含了更新后的上下文信息在实际中你可能需要设计一个专门的工具来更新上下文 memory.append(f”Assistant: {response[‘output’]}”) return response[‘output’]4.4 集成与测试使用Gradio创建一个简单的聊天界面进行测试。# app.py import gradio as gr from agent import run_agent_conversation with gr.Blocks() as demo: gr.Markdown(“## 多轮对话架构图设计助手”) chatbot gr.Chatbot() msg gr.Textbox(label“请输入您的架构需求”) clear gr.Button(“清空对话”) def respond(message, chat_history): bot_message run_agent_conversation(message) chat_history.append((message, bot_message)) return “”, chat_history msg.submit(respond, [msg, chatbot], [msg, chatbot]) clear.click(lambda: None, None, chatbot, queueFalse) if __name__ “__main__”: demo.launch()运行python app.py你将在本地启动一个Web应用。尝试输入“我想设计一个短视频推荐系统”观察Agent如何通过多轮提问比如问及用户规模、推荐算法类型、实时性要求来澄清需求并逐步调用工具生成架构图。5. 常见问题、挑战与优化策略在实际开发中你会遇到一系列挑战。以下是我在实践中总结的主要问题和应对策略。5.1 幻觉与信息不准确LLM可能会“捏造”不存在或不合适的技术组件。问题Agent推荐了一个名为“HyperDB”的虚构数据库或者建议在小规模内部系统中使用“TiDB”这种分布式数据库杀鸡用牛刀。对策知识库约束强化query_tech_stack工具使其基于一个经过审核的、真实的技术选型知识库来回答。限制Agent的“信口开河”。输出结构化强制要求Agent在提出技术组件时必须从预定义的列表中选择如[“MySQL” “PostgreSQL” “MongoDB” “Redis”]。这可以通过在提示词中明确枚举或使用LLM的“函数调用”Function Calling能力来实现。事后验证在最终输出前增加一个“事实核查”步骤让另一个专精于技术验证的LLM或规则引擎检查架构中所有组件的真实性。5.2 上下文管理与长对话遗忘随着对话轮次增加LLM可能会忘记最早的关键需求。问题用户在第1轮说了“要求成本最低”但在第5轮设计时Agent却推荐了价格昂贵的商业软件。对策关键信息提取与高亮在每一轮对话后自动运行一个摘要或提取流程将用户明确提出的约束条件如“成本低”、“高可用”、“快速上线”和核心名词提取出来放在一个“高优先级记忆区”在每次提示中都置于显眼位置。结构化上下文的强制引用要求Agent在每一步推理时都必须明确引用当前ArchitectureContext中的具体字段。例如“根据上下文中已记录的‘成本优先’原则我选择MySQL而非Oracle”。分段式对话当识别到一个主要设计阶段完成时例如“组件选型已完成”主动总结当前设计并请用户确认。这既刷新了上下文也确保了双方认知同步。5.3 工具调用的效率与稳定性工具调用失败或耗时过长会打断整个Agent流程。问题validate_and_render工具调用本地的mermaid-cli超时导致整个对话卡死。对策超时与重试机制为每个工具调用设置合理的超时时间并提供重试逻辑如重试2次。降级方案对于非核心工具准备降级方案。例如渲染工具失败时可以降级为只返回Mermaid代码文本并提示用户手动复制到支持渲染的编辑器中查看。异步调用对于耗时的工具如调用外部知识库查询采用异步调用让Agent在等待结果时可以处理其他轻量级任务但这需要更复杂的Agent状态机。5.4 评估与迭代优化如何判断这个Agent设计得好不好主观评估找真实的架构师或开发者试用收集反馈。他们是否觉得对话自然生成的设计图是否合理客观指标任务完成率给定一组测试用例如“设计一个博客系统”、“设计一个物联网数据平台”有多少比例能成功输出一张语法正确、内容相关的架构图平均对话轮次完成一个测试用例平均需要多少轮对话轮次越少通常说明Agent理解能力和引导能力越强。工具调用准确率Agent调用正确工具的比例是多少是否存在大量无效或错误的工具调用优化迭代根据评估结果持续优化三个部分提示词工程让指令更清晰、工具设计让工具更易用、更健壮、工作流逻辑增加或减少反思环节优化任务拆解策略。5.5 成本控制使用GPT-4等高级模型多轮对话加上长上下文成本可能迅速增长。策略模型分级将Agent的“大脑”和“工具”分开。用GPT-4这类强模型做核心的规划、拆解和复杂决策用GPT-3.5-Turbo或更小的开源模型如Qwen、DeepSeek来执行格式转换、简单摘要等确定性较高的任务。上下文压缩如前所述使用摘要记忆和结构化上下文而非传递全部原始对话历史。缓存对常见的、确定性的查询如“电商系统核心组件有哪些”可以将LLM的回答缓存起来下次直接使用避免重复调用。设计一个高效可用的多轮对话架构图Agent是一个典型的系统工程它考验的不仅是对LLM能力的理解更是对特定领域架构设计工作流的抽象和建模能力。从简单的提示词对话到配备工具和记忆的智能体再到拥有稳定工作流和评估体系的系统每一步都充满了细节上的挑战。但当你看到AI能通过连续对话一步步将一个模糊的想法勾勒成清晰的技术蓝图时你会觉得这一切的折腾都是值得的。这不仅仅是生成一张图而是在探索人机协同进行复杂设计的新范式。
基于Agent的多轮对话架构图生成：从任务规划到工程实践
1. 项目概述从“一问一答”到“持续规划”的思维跃迁在AI应用开发领域我们早已习惯了“输入-处理-输出”的单轮对话模式。用户抛出一个问题模型给出一个答案任务就算完成了。然而当任务复杂度上升比如用户说“帮我设计一个电商系统的架构图”事情就变得棘手了。这不再是一个可以靠单次提示词Prompt就能完美解决的问题。它需要拆解需求、选择组件、规划布局、考虑扩展性最后生成可视化结果。这个过程天然就是多轮的、有状态的、并且需要规划能力的。这就是“多轮对话生成架构图 Agent”要解决的核心问题如何让AI像一位经验丰富的架构师通过连续、有逻辑的对话引导用户厘清需求并最终交付一个结构清晰、可落地的架构设计方案。我最近在几个内部项目中实践了这类Agent的设计踩了不少坑也总结出一些行之有效的模式。它绝不仅仅是把ChatGPT的对话历史传进去那么简单其核心在于设计一个能够进行“任务规划”、“工具调用”和“自我反思”的智能体Agent工作流。这个Agent需要理解架构领域的专业知识能将模糊的自然语言描述转化为结构化的技术组件并具备通过多轮交互澄清歧义、优化设计的能力。最终它输出的可能是一份Mermaid代码、一张PlantUML图或者直接调用绘图API生成的PNG文件。接下来我将详细拆解这个Agent的设计思路、核心模块、实操步骤以及那些只有真正动手做过才会知道的“坑”。2. 核心设计思路构建一个会“思考”的架构师工作流设计一个能生成架构图的Agent首先要摒弃“万能模型”的幻想。没有任何一个基础大语言模型LLM能凭空精通所有技术栈的架构细节。我们的设计思路是将LLM作为“大脑”和“协调器”为其配备专业的“知识”架构领域提示词与示例和“双手”画图工具与验证工具并设计一套严谨的“工作流程”来规范它的思考与行动路径。2.1 分层决策与规划循环Agent的核心是一个“感知-思考-行动”的循环但在架构设计场景下这个循环需要被细化。需求分析与任务拆解感知与规划用户输入“做一个能抗住双十一流量的电商系统”。Agent的第一步不是直接画图而是理解。它需要将这个宏大的、模糊的目标拆解成可执行、可验证的子任务。例如子任务1确定核心业务场景用户、商品、订单、支付、库存。子任务2为每个场景选择合适的技术组件网关、服务发现、数据库、缓存、消息队列。子任务3定义组件间的交互关系和数据流。子任务4考虑高可用、高并发下的特殊设计负载均衡、分库分表、弹性伸缩。子任务5将上述结构化信息转换为图形描述语言如Mermaid。工具调用与信息获取行动在拆解任务后Agent可能需要调用工具。例如在子任务2中它可能调用一个“技术选型知识库”工具查询“高并发场景下Redis和Memcached该如何选择”在子任务5中它必须调用“Mermaid生成器”工具。关键在于Agent需要根据当前思考的上下文动态决定是否需要调用工具、调用哪个工具、以及传入什么参数。反思与验证再思考生成初步架构图描述如Mermaid代码后一个优秀的Agent不应直接输出给用户。它应该进入“反思”阶段调用一个“架构图语法检查器”工具验证代码有效性甚至调用一个“架构合理性评估”工具可以是另一组提示词检查是否存在单点故障、数据一致性是否得到保障等。如果发现问题则重新规划或调整。注意这个循环不是线性的而是可能嵌套和回溯的。例如在工具调用后获得新信息可能需要对之前的任务拆解进行修正。2.2 关键状态管理记忆与上下文多轮对话的核心是状态管理。Agent必须记住整个对话历史和它自己推导出的中间状态。对话历史Conversation History保存用户与Agent的所有问答记录。这是最基础的记忆但直接将其全部扔给LLM会导致上下文过长、成本剧增且关键信息被稀释。任务链Task Chain显式地记录当前的任务拆解结果和完成状态。例如用一个列表记录[任务1: 分析场景 - 完成 任务2: 选型 - 进行中 任务3: 绘图 - 未开始]。这比隐式地在对话历史中寻找要清晰得多。架构上下文Architecture Context这是一个结构化的对象存储当前架构设计的所有关键决策。它可以是一个JSON Schema例如{ system_name: 电商平台, scenarios: [用户登录, 商品浏览, 下单支付], components: [ {name: API Gateway, type: 网关, tech: Nginx/Spring Cloud Gateway}, {name: User Service, type: 微服务, tech: Spring Boot, db: MySQL} ], interactions: [{from: Client, to: API Gateway, protocol: HTTPS}], non_functional: {availability: 99.99%, scalability: horizontal} }每轮对话都在更新这个上下文对象它也是最终生成图形的直接数据源。实操心得直接使用原始对话历史作为记忆在超过3轮复杂对话后效果会急剧下降。我采用的方法是“摘要式记忆”“结构化上下文”结合。每轮对话后用LLM对上一轮关键信息做一个简短摘要更新到“摘要记忆”中。同时任何明确的决策如技术选型都立刻更新到“架构上下文”这个结构化对象里。这样在下一轮推理时我们提供给LLM的提示词就包含了本轮用户问题 摘要记忆 当前的架构上下文。这大大减轻了模型的记忆负担并保证了核心决策的准确性。3. 核心模块拆解与实现细节一个可运行的多轮架构图Agent通常由以下几个核心模块组成。我将以Python OpenAI API (或开源LLM) LangChain用于编排的技术栈为例进行说明但思路是通用的。3.1 智能体核心Agent Core这是Agent的“大脑”负责运行规划循环。我们通常使用ReActReasoning and Acting模式或其变种。# 简化的ReAct循环伪代码 class ArchitectureAgent: def __init__(self, llm, tools, memory, context): self.llm llm self.tools tools # 工具字典 self.memory memory self.context context # 架构上下文 def run(self, user_input): # 1. 更新对话记忆 self.memory.append(“user”, user_input) # 2. 构建提示词包含角色定义、任务目标、工作流程、可用工具、记忆、当前上下文 prompt self._build_agent_prompt(user_input) # 3. LLM进行思考输出包含“思考(Thought)”、“行动(Action)”、“行动输入(Action Input)”的文本 llm_response self.llm.invoke(prompt) # 解析出 thought, action, action_input # 4. 执行行动如果存在 if action ! “FINISH”: tool self.tools[action] observation tool.run(action_input) # 将“观察(Observation)”加入记忆并回到步骤2进行下一轮思考 self.memory.append(“system”, f”Action Result: {observation}”) return self.run(“”) # 传入空输入让Agent基于观察继续思考 else: # 5. 生成最终输出如图表代码 final_output self._generate_final_output(llm_response) return final_output关键提示词设计给LLM的提示词模板是成败关键。它必须清晰定义角色你是一位资深系统架构师擅长将业务需求转化为可落地的技术架构图。工作流程你必须遵循“分析需求 - 拆解任务 - 调用工具如需- 更新设计 - 反思验证 - 最终输出”的流程。工具使用规范严格定义每个工具的名称、描述和输入格式。例如工具query_tech_stack: 根据场景和需求查询推荐的技术组件。输入应为JSON格式{“scenario”: “高并发读”, “requirement”: “低延迟”}。输出格式强制要求LLM以Thought: ... Action: ... Action Input: ...的格式回复。3.2 工具集Tools设计工具是Agent能力的延伸。对于架构图生成必备工具包括技术知识库查询工具连接到一个向量数据库如Chroma里面存储了技术文档、博客、最佳实践。当Agent不确定选型时可以从此工具获取信息。架构图语法生成器generate_mermaid: 输入结构化的架构上下文JSON输出Mermaid代码。generate_plantuml: 类似输出PlantUML代码。这个工具本身可以是一个精心设计的提示词让LLM完成转换也可以是一套硬编码的模板引擎。语法验证与渲染工具validate_mermaid: 调用Mermaid的解析库或在线服务检查代码语法是否正确。render_diagram: 将有效的代码通过Mermaid CLI或PlantUML服务器渲染成图片PNG/SVG并返回图片路径或Base64编码。架构合理性检查工具这是一个“元”工具它实际上是用另一套提示词去询问LLM“以架构评审专家的身份检查以下设计是否存在单点故障、数据一致性问题、性能瓶颈...”。它将当前架构上下文作为输入输出检查结果和建议。实操心得工具的设计要“小而专”不要设计“万能工具”。一个工具只做一件事并且要有明确的成功/失败输出。例如validate_mermaid工具就返回{“valid”: true, “error”: null}或{“valid”: false, “error”: “Syntax error at line 5”}。这能让Agent的决策逻辑更清晰。另外工具调用可能失败网络超时、API限流必须在Agent循环中设计错误处理逻辑让Agent能够应对工具异常。3.3 记忆与上下文管理模块这是保证多轮对话连贯性的“粘合剂”。对话记忆可以使用简单的List存储但更推荐使用LangChain的ConversationBufferWindowMemory或ConversationSummaryMemory。后者会自动对历史对话进行摘要非常适合长对话。架构上下文建议用一个Pydantic模型来定义确保数据结构化且易于验证。from pydantic import BaseModel from typing import List, Optional class Component(BaseModel): name: str type: str technology: Optional[str] None description: Optional[str] None class ArchitectureContext(BaseModel): project_name: str core_scenarios: List[str] components: List[Component] interactions: List[dict] constraints: dict {}在Agent运行过程中通过LLM的输出来更新这个上下文对象。可以设计专门的工具update_context由Agent在做出决策后调用。3.4 输出与展示层最终Agent需要交付一个直观的结果。代码输出直接返回Mermaid或PlantUML代码让用户在支持该语法的平台如GitLab、Notion中查看。图片输出在服务器端渲染成图片后返回图片URL或Base64数据。这体验最好。交互式输出进阶玩法是生成一个前端组件的配置如ECharts配置在网页上实现可交互的架构图点击组件查看详情。一个简单的集成示例使用Gradio或Streamlit快速搭建一个演示界面。用户输入需求界面显示Agent的“思考过程”Thoughts并最终展示生成的架构图。4. 实操流程从零搭建一个最小可行产品假设我们要用LangChain和OpenAI GPT-4 API搭建一个基础版Agent。4.1 环境准备与依赖安装# 创建虚拟环境 python -m venv arch-agent-env source arch-agent-env/bin/activate # Linux/Mac # arch-agent-env\Scripts\activate # Windows # 安装核心库 pip install langchain langchain-openai langchain-community pip install pydantic # 用于图表渲染 pip install mermaid-cli # 需要先安装Node.js和npm # 用于Web界面 pip install gradio4.2 定义架构上下文与工具# context.py from pydantic import BaseModel from typing import List class ArchitectureContext(BaseModel): system_name: str “” components: List[dict] [] data_flows: List[dict] [] # tools.py import subprocess import json from langchain.tools import tool tool def query_tech_stack(query_json: str) - str: “””查询技术选型知识库。输入应为JSON字符串包含’scenario’和’requirement’字段。””” try: query json.loads(query_json) # 这里可以连接向量数据库进行查询此处简化为规则匹配 scenario query.get(“scenario”, “”).lower() if “cache” in scenario: return “推荐使用Redis因为它支持丰富的数据结构并具备持久化能力。若只需简单键值存储且追求极致内存效率可考虑Memcached。” elif “message” in scenario: return “推荐使用Kafka处理高吞吐、持久化的日志流使用RabbitMQ处理复杂的业务消息路由RocketMQ是阿里系生态的可靠选择。” else: return “未找到精确匹配建议明确具体场景如’数据库选型’、’网关选型’。” except: return “输入格式错误请提供有效的JSON。” tool def generate_mermaid(context_json: str) - str: “””根据架构上下文生成Mermaid流程图代码。””” try: context json.loads(context_json) # 这里可以更复杂根据context结构生成不同类型的图流程图、时序图、部署图 # 此处生成一个简单的组件图 mermaid_code “graph TD\n” for comp in context.get(“components”, []): mermaid_code f” {comp[‘id’]}[{comp[‘name’]}]\n” for flow in context.get(“data_flows”, []): mermaid_code f” {flow[‘from’]} -- {flow[‘to’]}\n” return mermaid_code except Exception as e: return f”生成Mermaid代码时出错{e}” tool def validate_and_render(mermaid_code: str) - str: “””验证Mermaid代码并渲染为图片Base64。””” # 1. 简单验证可选更严格的验证需调用mermaid-cli if “graph” not in mermaid_code: return “错误非法的Mermaid代码必须以’graph’开头。” # 2. 调用mermaid-cli渲染需提前安装 import tempfile, base64, os with tempfile.NamedTemporaryFile(mode‘w’, suffix‘.mmd’, deleteFalse) as f: f.write(mermaid_code) mmd_file f.name png_file mmd_file.replace(‘.mmd’, ‘.png’) try: # 使用mermaid-cli渲染 subprocess.run([‘mmdc’, ‘-i’, mmd_file, ‘-o’, png_file], checkTrue, capture_outputTrue) with open(png_file, ‘rb’) as img_f: img_base64 base64.b64encode(img_f.read()).decode(‘utf-8’) result f”验证通过图片渲染成功。\n” except subprocess.CalledProcessError as e: result f”渲染失败Mermaid语法可能有误。错误信息{e.stderr.decode()}” finally: os.unlink(mmd_file) if os.path.exists(png_file): os.unlink(png_file) return result4.3 构建智能体与工作流# agent.py from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_react_agent from langchain_core.prompts import PromptTemplate from tools import query_tech_stack, generate_mermaid, validate_and_render from context import ArchitectureContext import json # 初始化LLM llm ChatOpenAI(model“gpt-4”, temperature0.1) # 低temperature保证决策稳定 # 定义工具列表 tools [query_tech_stack, generate_mermaid, validate_and_render] # 构建ReAct风格的提示词模板 prompt_template “”” 你是一个专业的系统架构师助手。你的目标是通过与用户的多轮对话最终生成一个准确、清晰的技术架构图。 你必须严格按照以下步骤工作 1. **理解与澄清**仔细分析用户当前输入和对话历史。如果需求模糊必须主动提问澄清例如系统预期QPS是多少数据一致性要求如何。 2. **规划与拆解**将架构设计任务拆解为确定边界上下文、选择技术组件、定义交互关系。 3. **调用工具**如果你需要专业信息来做出技术选型请调用query_tech_stack工具。当你认为架构设计已足够清晰可以生成图表时调用generate_mermaid工具。生成代码后务必调用validate_and_render进行检查和可视化。 4. **更新上下文**在内部维护一个架构上下文记录所有已确定的组件和交互。 5. **反思**在最终输出前检查架构是否存在明显缺陷如单点故障、循环依赖。 当前对话历史 {history} 当前架构上下文JSON格式 {context} 用户最新输入{input} 你拥有以下工具 {tools} 请严格按以下格式回应 Thought: 我需要思考当前情况并决定下一步行动 Action: 要调用的工具名必须是[{tool_names}]中的一个如果没有必要则填“FINISH” Action Input: 调用工具的输入必须是一个合法的JSON字符串如果工具需要的话 一旦你生成了最终的架构图即调用validate_and_render成功并得到图片且用户没有新的修改意见你的最终回复应该是图片结果和简要说明。 “”” prompt PromptTemplate.from_template(prompt_template) # 创建Agent agent create_react_agent(llm, tools, prompt) # 创建执行器并传入初始化的记忆和上下文 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 初始化记忆和上下文 memory [] # 简化处理实际应用可用ConversationBufferMemory context ArchitectureContext() def run_agent_conversation(user_input): global context # 构建传入Agent的完整输入 formatted_input { “input”: user_input, “history”: “\n”.join(memory[-5:]), # 只保留最近5轮历史 “context”: context.json(), “tools”: “, “.join([t.name for t in tools]), “tool_names”: “, “.join([t.name for t in tools]) } memory.append(f”User: {user_input}”) # 执行Agent response agent_executor.invoke(formatted_input) # 解析输出更新上下文这里需要从Agent的输出中提取更新信息实际会更复杂 # 假设Agent的最终输出包含了更新后的上下文信息在实际中你可能需要设计一个专门的工具来更新上下文 memory.append(f”Assistant: {response[‘output’]}”) return response[‘output’]4.4 集成与测试使用Gradio创建一个简单的聊天界面进行测试。# app.py import gradio as gr from agent import run_agent_conversation with gr.Blocks() as demo: gr.Markdown(“## 多轮对话架构图设计助手”) chatbot gr.Chatbot() msg gr.Textbox(label“请输入您的架构需求”) clear gr.Button(“清空对话”) def respond(message, chat_history): bot_message run_agent_conversation(message) chat_history.append((message, bot_message)) return “”, chat_history msg.submit(respond, [msg, chatbot], [msg, chatbot]) clear.click(lambda: None, None, chatbot, queueFalse) if __name__ “__main__”: demo.launch()运行python app.py你将在本地启动一个Web应用。尝试输入“我想设计一个短视频推荐系统”观察Agent如何通过多轮提问比如问及用户规模、推荐算法类型、实时性要求来澄清需求并逐步调用工具生成架构图。5. 常见问题、挑战与优化策略在实际开发中你会遇到一系列挑战。以下是我在实践中总结的主要问题和应对策略。5.1 幻觉与信息不准确LLM可能会“捏造”不存在或不合适的技术组件。问题Agent推荐了一个名为“HyperDB”的虚构数据库或者建议在小规模内部系统中使用“TiDB”这种分布式数据库杀鸡用牛刀。对策知识库约束强化query_tech_stack工具使其基于一个经过审核的、真实的技术选型知识库来回答。限制Agent的“信口开河”。输出结构化强制要求Agent在提出技术组件时必须从预定义的列表中选择如[“MySQL” “PostgreSQL” “MongoDB” “Redis”]。这可以通过在提示词中明确枚举或使用LLM的“函数调用”Function Calling能力来实现。事后验证在最终输出前增加一个“事实核查”步骤让另一个专精于技术验证的LLM或规则引擎检查架构中所有组件的真实性。5.2 上下文管理与长对话遗忘随着对话轮次增加LLM可能会忘记最早的关键需求。问题用户在第1轮说了“要求成本最低”但在第5轮设计时Agent却推荐了价格昂贵的商业软件。对策关键信息提取与高亮在每一轮对话后自动运行一个摘要或提取流程将用户明确提出的约束条件如“成本低”、“高可用”、“快速上线”和核心名词提取出来放在一个“高优先级记忆区”在每次提示中都置于显眼位置。结构化上下文的强制引用要求Agent在每一步推理时都必须明确引用当前ArchitectureContext中的具体字段。例如“根据上下文中已记录的‘成本优先’原则我选择MySQL而非Oracle”。分段式对话当识别到一个主要设计阶段完成时例如“组件选型已完成”主动总结当前设计并请用户确认。这既刷新了上下文也确保了双方认知同步。5.3 工具调用的效率与稳定性工具调用失败或耗时过长会打断整个Agent流程。问题validate_and_render工具调用本地的mermaid-cli超时导致整个对话卡死。对策超时与重试机制为每个工具调用设置合理的超时时间并提供重试逻辑如重试2次。降级方案对于非核心工具准备降级方案。例如渲染工具失败时可以降级为只返回Mermaid代码文本并提示用户手动复制到支持渲染的编辑器中查看。异步调用对于耗时的工具如调用外部知识库查询采用异步调用让Agent在等待结果时可以处理其他轻量级任务但这需要更复杂的Agent状态机。5.4 评估与迭代优化如何判断这个Agent设计得好不好主观评估找真实的架构师或开发者试用收集反馈。他们是否觉得对话自然生成的设计图是否合理客观指标任务完成率给定一组测试用例如“设计一个博客系统”、“设计一个物联网数据平台”有多少比例能成功输出一张语法正确、内容相关的架构图平均对话轮次完成一个测试用例平均需要多少轮对话轮次越少通常说明Agent理解能力和引导能力越强。工具调用准确率Agent调用正确工具的比例是多少是否存在大量无效或错误的工具调用优化迭代根据评估结果持续优化三个部分提示词工程让指令更清晰、工具设计让工具更易用、更健壮、工作流逻辑增加或减少反思环节优化任务拆解策略。5.5 成本控制使用GPT-4等高级模型多轮对话加上长上下文成本可能迅速增长。策略模型分级将Agent的“大脑”和“工具”分开。用GPT-4这类强模型做核心的规划、拆解和复杂决策用GPT-3.5-Turbo或更小的开源模型如Qwen、DeepSeek来执行格式转换、简单摘要等确定性较高的任务。上下文压缩如前所述使用摘要记忆和结构化上下文而非传递全部原始对话历史。缓存对常见的、确定性的查询如“电商系统核心组件有哪些”可以将LLM的回答缓存起来下次直接使用避免重复调用。设计一个高效可用的多轮对话架构图Agent是一个典型的系统工程它考验的不仅是对LLM能力的理解更是对特定领域架构设计工作流的抽象和建模能力。从简单的提示词对话到配备工具和记忆的智能体再到拥有稳定工作流和评估体系的系统每一步都充满了细节上的挑战。但当你看到AI能通过连续对话一步步将一个模糊的想法勾勒成清晰的技术蓝图时你会觉得这一切的折腾都是值得的。这不仅仅是生成一张图而是在探索人机协同进行复杂设计的新范式。