1. 项目缘起当“单打独斗”的LLM遇上复杂软件设计最近在折腾一个老项目的重构目标是把它从一个单体应用拆成微服务。这事儿说起来简单但真动起手来从领域划分、接口设计到数据一致性一堆问题扑面而来。我习惯性地把需求描述扔给ChatGPT让它给我出个设计草案。结果呢草案是出来了但总感觉差点意思——要么是架构图过于理想化忽略了现有技术栈的约束要么是某些模块的职责边界模糊经不起推敲。这让我开始思考一个更本质的问题对于软件设计这种需要多角度、深层次思考的复杂任务让一个大语言模型LLM“单打独斗”是不是最优解我们人类在做设计评审时不也是需要架构师、开发、测试、产品经理等不同角色一起碰撞吗每个角色带着自己的知识背景和关注点才能把一个设计从“能用”打磨到“好用”甚至“优雅”。于是一个想法冒了出来能不能模拟这种多人协作的评审过程让多个LLM智能体Agent扮演不同的角色通过特定的协作拓扑Collaboration Topology来共同完成软件设计的迭代与精炼这个“LLM联合会”LLM Consortium的构想就成了我这次探索的起点。我想通过一个受控实验看看不同的多智能体协作模式到底哪种对提升软件设计质量最有效。2. 构建“联合会”角色定义、协作拓扑与实验设计要让多个LLM智能体有效协作首先得明确两件事谁角色来参与以及他们怎么拓扑一起工作。这直接决定了“联合会”的运作效率和产出质量。2.1 核心角色画像超越“通用助手”的专家智能体我不再使用一个“全能”的模型而是为不同的设计评审视角创建了专属的智能体。每个智能体都通过精心设计的系统提示词System Prompt来固化其角色、知识范围和审查重点。架构师智能体它的核心使命是把握全局。提示词会强调其关注点在于高可用性、可扩展性、技术选型的合理性与一致性、以及关键的非功能性需求如性能、安全。它会审视微服务划分是否遵循了领域驱动设计DDD的限界上下文原则服务间的通信机制如REST、gRPC、消息队列是否恰当。资深开发智能体这个角色下沉到实现层面。它负责挑刺关注接口设计的优雅性是否遵循RESTful规范或GraphQL最佳实践、数据模型的有效性、代码的可维护性以及潜在的技术债。例如它会检查API的幂等性是否得到保证数据库查询是否存在N1问题。测试工程师智能体它的视角独特而关键专注于设计的可测试性Testability和潜在的风险点。它会评估设计是否便于进行单元测试、集成测试和端到端测试例如依赖注入是否清晰是否有难以模拟的外部服务。它还会基于经验预测哪些模块在集成时最容易出问题。提示角色定义的关键在于“约束”和“视角聚焦”。给智能体的提示词不能太宽泛比如“请评审这个设计”而必须是“作为一名专注于可测试性的测试工程师请评估该微服务设计在以下方面的表现1. 模块间耦合度是否允许轻松模拟Mock2. 关键业务流程是否有清晰的入口点便于构造测试用例”。明确的指令才能引导出专业的反馈。2.2 协作拓扑设计串联、并联与混合评审智能体们如何交换信息、达成共识这就是协作拓扑要解决的问题。我设计了三种基础模式进行对比实验2.2.1 串联式评审Sequential Review这是一种链式结构。原始设计草案首先交给架构师智能体它提出修改意见并生成版本A版本A随即交给开发智能体评审生成版本B最后版本B交给测试智能体产出最终版本C。这种模式的优点是流程清晰每个角色都能基于前一个角色的输出进行深化。但风险在于“误差累积”如果架构师的初始意见有偏差这个偏差可能会在后续流程中被放大。2.2.2 并行式评审Parallel Review所有智能体同时接收原始设计草案独立进行评审分别产出自己的修订版本版本A-架构师版本B-开发版本C-测试。最后需要一个“仲裁者”可以是另一个LLM也可以是我本人来综合三个版本的改动去芜存菁合并成一个最终版本。这种模式的优点是能获得最多样化的视角避免早期偏见。但挑战在于最终的合并阶段可能很复杂需要处理不同意见之间的冲突。2.2.3 混合式评审Mixed Review with Debate我先让三个智能体并行工作产出初步意见。然后我模拟一个“设计评审会”将A、B、C的评审意见匿名或署名地同时发给每一个智能体并指令它们“基于其他同事的反馈重新审视你最初的意见并进行一轮辩论试图就关键分歧点达成共识或明确备选方案。” 这个过程可以迭代1-2轮。最后再基于辩论后的输出进行综合。这种模式试图结合前两者的优点既有多元输入又有交互和收敛。2.3 实验设置与评估指标为了控制变量我固定了以下条件基准模型所有智能体均使用同一款主流LLM的API如GPT-4确保能力基线一致。输入材料我准备了3个不同复杂度的软件设计描述作为测试用例简单用例一个用户注册登录模块的设计。中等用例一个电商系统的“下单-支付”流程微服务设计。复杂用例一个内容管理平台CMS从单体向微服务迁移的初步架构设计。评估方法这是最关键的。我无法完全自动化评估因此采用了主客观结合的方式人工评估我作为有经验的开发者会从“架构合理性”、“实现可行性”、“可测试性”、“文档清晰度”四个维度对每个拓扑产出的最终设计进行评分1-5分。一致性检查使用LLM本身作为“裁判”让它评估不同版本设计在应对预设的边界条件如高并发、部分服务失效时哪个表现更健壮、描述更无矛盾。改进点统计定量统计每个流程产出的设计版本相比原始草案提出了多少条独特的、有价值的修改建议。3. 实验结果深度剖析拓扑如何影响设计产出运行了几轮实验后一些有趣的模式开始浮现。结果并非简单地“某种拓扑完胜”而是各有其适用的场景和优缺点。3.1 串联拓扑效率与风险的平衡在简单用例用户注册登录上串联拓扑表现最佳。它的线性流程非常高效架构师确定了使用JWT令牌和Redis缓存会话开发接着完善了接口细节和错误码测试最后补充了针对暴力破解的限流测试点。整个过程流畅最终设计质量明显高于原始草案。然而在复杂用例CMS迁移中串联拓扑的弊端暴露了。架构师智能体首先提出了一个基于“事件驱动”的彻底解耦方案。这个方向本身有一定道理但过于激进。当这个方案传递给开发智能体时开发智能体的大部分反馈都集中在“如何在这个事件架构下实现某个具体功能”而不是去质疑“事件驱动对当前团队和项目是否是最佳选择”。测试智能体则进一步陷入细节。最终产出的设计虽然内部一致但整体上过度设计脱离了项目“平滑迁移、风险可控”的初始约束。这就是“误差累积”的典型表现第一个环节的偏差设定了整个思考的轨道。实操心得串联拓扑适用于目标明确、问题域相对收敛的任务。如果你想用它务必把最全面、最谨慎的智能体通常是“架构师”角色放在链条的起点并给予最清晰的约束条件。同时要意识到这是一种“风险前置”的模式。3.2 并行拓扑多样性与整合的代价并行拓扑在中等用例电商下单支付上展现了优势。三个智能体分别关注了不同层面架构师关注支付渠道的可扩展性和事务最终一致性方案如Saga模式开发关注库存锁定的API设计和幂等性测试则聚焦在支付成功/失败/超时等各种异常流的覆盖。最终我手动合并时感觉材料非常丰富像是一次高质量的头脑风暴。但它的缺点也很明显整合成本高三个输出版本可能有直接冲突。比如架构师建议用Saga开发可能详细设计了基于本地事务表的补偿机制而测试可能指出某种边缘情况下补偿难以测试。我需要花费大量精力去理解、权衡和手动合并这个过程本身就很耗时且依赖我个人的判断力。重复与冗余三个智能体可能会指出相同的问题如“需要幂等性”只是表述不同需要去重。3.3 混合拓扑辩论式质量与成本的博弈混合拓扑在复杂用例上产出了我个人评价最高的设计。第一轮并行评审后三个智能体意见分歧很大。在“辩论轮”中我观察到了一些模拟的“协作”行为开发智能体对架构师说“您提出的事件溯源Event Sourcing模式对于审计固然好但会极大增加当前团队的学习成本和实现复杂度我建议先采用更简单的状态跟踪。”测试智能体对两者说“我支持开发的保守意见。另外无论采用哪种方案请务必为每个核心状态变更提供明确的Hook点以便我注入测试桩。”经过两轮这样的“辩论”最终输出的意见虽然仍有不同但焦点更集中选项也更清晰例如明确给出了“激进方案A”和“渐进方案B”的对比。这极大地降低了我的决策成本。然而这种模式的成本是最高的。它消耗的Token数量API调用成本几乎是并行模式的两倍并且整个流程耗时更长。它更像一个“重”流程适合用于关键、高风险的设计决策而不是日常的简单设计任务。4. 超越实验构建实用LLM设计评审工作流的思考这次受控实验更像是一个原型验证。要将“LLM联合会”的想法工程化、实用化还需要解决一系列更深层的问题。4.1 智能体能力的“幻觉”与“对齐”问题实验中最让我头疼的不是协作拓扑而是每个智能体自身的“幻觉”。例如架构师智能体可能会推荐一个它“知道”但细节模糊的新兴技术栈开发智能体可能生成一段看似合理但存在死锁风险的伪代码。多智能体协作并不能根除幻觉反而可能让幻觉在交互中被“合理化”。我的应对策略是知识库RAG增强为每个智能体配备专属的知识库。例如为“架构师”智能体接入公司内部的技术规范文档、过往的架构决策记录ADR为“开发”智能体接入项目的API设计指南、代码库中的常见模式。在提示词中明确指令“你的建议应优先参考知识库中的规范如有偏离请明确说明理由。”链式验证Chain-of-Verification对于智能体提出的关键建议如“使用Redis集群”要求它自己再扮演一个“质疑者”列出这个建议的潜在风险和实施前提并给出应对措施。这相当于在智能体内部进行一次快速复核。4.2 协作中的状态管理与上下文工程在串联或混合拓扑中智能体之间传递的“设计版本”是一个核心资产。如何表示它简单地把整个对话历史扔给下一个智能体会导致上下文过长、焦点丢失。我实践下来比较有效的方法是结构化传递原始需求始终保留。当前设计草案用Markdown或结构化格式如伪代码、Mermaid图表。本轮评审意见要求智能体以“新增/修改/删除/疑问”的列表形式给出。关键决策与待决问题一个不断更新的列表。这样每个智能体都能快速抓住重点而不是在冗长的聊天历史中迷失。4.3 评估自动化与持续迭代的挑战人工评估终归是瓶颈。为了能让这个系统半自动化运行我在探索以下方向基于规则的初步过滤写一些简单的规则检查设计文档例如“是否所有API都定义了HTTP方法”、“是否提到了数据存储”。这可以过滤掉明显不合格的草案。利用LLM进行相对评估给定原始设计D和精炼后的设计R让一个“评估者”LLM回答“针对‘可维护性’和‘风险覆盖度’R在哪些方面明确优于D请列出具体点。” 这种相对比较比让它直接打一个绝对分更可靠。建立反馈闭环将最终被人类采纳的设计方案及其评审过程作为高质量样本反哺到各个智能体的知识库或微调数据中让它们越来越贴近团队的实际标准和偏好。5. 从多智能体协作看LLM应用的范式转移这次实验让我对LLM的应用有了更深的看法。我们正从一个“提问-回答”的简单范式走向“编排-协作”的复杂范式。单个LLM作为“万能问答机”存在明显的天花板尤其是在软件设计这类需要权衡、迭代和深度思考的领域。多智能体系统Multi-Agent System的魅力在于它通过角色划分和交互规则将复杂问题分解并模拟了人类团队中“观点碰撞-达成共识”的社会性智能过程。不同的协作拓扑实质上是不同的决策流程和沟通模型。串联是瀑布模型并行是头脑风暴混合辩论则类似敏捷评审。对于开发者而言未来的关键技能可能不再是精通某个模型的全部参数而是如何定义角色、设计流程、管理上下文以及评估结果——更像一个架构师或产品经理。我们使用的工具也从单一的聊天界面变成了一个可以编程的、由多个“数字同事”组成的协作环境。当然这条路还很长。智能体的稳定性、协作的成本、评估的客观性都是现实的挑战。但毫无疑问通过多智能体协作来放大LLM在复杂任务上的潜力是一个极具前景的方向。它让LLM不再只是一个被动的工具而是一个可以主动参与复杂思考过程的合作伙伴。我的下一步是尝试将其中一种拓扑可能是混合式固化成一个轻量级的内部工具用于实际项目的早期设计评审环节在真实场景中继续迭代和验证。 多智能体协作模式在软件设计评审中的实践与探索
1. 项目缘起当“单打独斗”的LLM遇上复杂软件设计最近在折腾一个老项目的重构目标是把它从一个单体应用拆成微服务。这事儿说起来简单但真动起手来从领域划分、接口设计到数据一致性一堆问题扑面而来。我习惯性地把需求描述扔给ChatGPT让它给我出个设计草案。结果呢草案是出来了但总感觉差点意思——要么是架构图过于理想化忽略了现有技术栈的约束要么是某些模块的职责边界模糊经不起推敲。这让我开始思考一个更本质的问题对于软件设计这种需要多角度、深层次思考的复杂任务让一个大语言模型LLM“单打独斗”是不是最优解我们人类在做设计评审时不也是需要架构师、开发、测试、产品经理等不同角色一起碰撞吗每个角色带着自己的知识背景和关注点才能把一个设计从“能用”打磨到“好用”甚至“优雅”。于是一个想法冒了出来能不能模拟这种多人协作的评审过程让多个LLM智能体Agent扮演不同的角色通过特定的协作拓扑Collaboration Topology来共同完成软件设计的迭代与精炼这个“LLM联合会”LLM Consortium的构想就成了我这次探索的起点。我想通过一个受控实验看看不同的多智能体协作模式到底哪种对提升软件设计质量最有效。2. 构建“联合会”角色定义、协作拓扑与实验设计要让多个LLM智能体有效协作首先得明确两件事谁角色来参与以及他们怎么拓扑一起工作。这直接决定了“联合会”的运作效率和产出质量。2.1 核心角色画像超越“通用助手”的专家智能体我不再使用一个“全能”的模型而是为不同的设计评审视角创建了专属的智能体。每个智能体都通过精心设计的系统提示词System Prompt来固化其角色、知识范围和审查重点。架构师智能体它的核心使命是把握全局。提示词会强调其关注点在于高可用性、可扩展性、技术选型的合理性与一致性、以及关键的非功能性需求如性能、安全。它会审视微服务划分是否遵循了领域驱动设计DDD的限界上下文原则服务间的通信机制如REST、gRPC、消息队列是否恰当。资深开发智能体这个角色下沉到实现层面。它负责挑刺关注接口设计的优雅性是否遵循RESTful规范或GraphQL最佳实践、数据模型的有效性、代码的可维护性以及潜在的技术债。例如它会检查API的幂等性是否得到保证数据库查询是否存在N1问题。测试工程师智能体它的视角独特而关键专注于设计的可测试性Testability和潜在的风险点。它会评估设计是否便于进行单元测试、集成测试和端到端测试例如依赖注入是否清晰是否有难以模拟的外部服务。它还会基于经验预测哪些模块在集成时最容易出问题。提示角色定义的关键在于“约束”和“视角聚焦”。给智能体的提示词不能太宽泛比如“请评审这个设计”而必须是“作为一名专注于可测试性的测试工程师请评估该微服务设计在以下方面的表现1. 模块间耦合度是否允许轻松模拟Mock2. 关键业务流程是否有清晰的入口点便于构造测试用例”。明确的指令才能引导出专业的反馈。2.2 协作拓扑设计串联、并联与混合评审智能体们如何交换信息、达成共识这就是协作拓扑要解决的问题。我设计了三种基础模式进行对比实验2.2.1 串联式评审Sequential Review这是一种链式结构。原始设计草案首先交给架构师智能体它提出修改意见并生成版本A版本A随即交给开发智能体评审生成版本B最后版本B交给测试智能体产出最终版本C。这种模式的优点是流程清晰每个角色都能基于前一个角色的输出进行深化。但风险在于“误差累积”如果架构师的初始意见有偏差这个偏差可能会在后续流程中被放大。2.2.2 并行式评审Parallel Review所有智能体同时接收原始设计草案独立进行评审分别产出自己的修订版本版本A-架构师版本B-开发版本C-测试。最后需要一个“仲裁者”可以是另一个LLM也可以是我本人来综合三个版本的改动去芜存菁合并成一个最终版本。这种模式的优点是能获得最多样化的视角避免早期偏见。但挑战在于最终的合并阶段可能很复杂需要处理不同意见之间的冲突。2.2.3 混合式评审Mixed Review with Debate我先让三个智能体并行工作产出初步意见。然后我模拟一个“设计评审会”将A、B、C的评审意见匿名或署名地同时发给每一个智能体并指令它们“基于其他同事的反馈重新审视你最初的意见并进行一轮辩论试图就关键分歧点达成共识或明确备选方案。” 这个过程可以迭代1-2轮。最后再基于辩论后的输出进行综合。这种模式试图结合前两者的优点既有多元输入又有交互和收敛。2.3 实验设置与评估指标为了控制变量我固定了以下条件基准模型所有智能体均使用同一款主流LLM的API如GPT-4确保能力基线一致。输入材料我准备了3个不同复杂度的软件设计描述作为测试用例简单用例一个用户注册登录模块的设计。中等用例一个电商系统的“下单-支付”流程微服务设计。复杂用例一个内容管理平台CMS从单体向微服务迁移的初步架构设计。评估方法这是最关键的。我无法完全自动化评估因此采用了主客观结合的方式人工评估我作为有经验的开发者会从“架构合理性”、“实现可行性”、“可测试性”、“文档清晰度”四个维度对每个拓扑产出的最终设计进行评分1-5分。一致性检查使用LLM本身作为“裁判”让它评估不同版本设计在应对预设的边界条件如高并发、部分服务失效时哪个表现更健壮、描述更无矛盾。改进点统计定量统计每个流程产出的设计版本相比原始草案提出了多少条独特的、有价值的修改建议。3. 实验结果深度剖析拓扑如何影响设计产出运行了几轮实验后一些有趣的模式开始浮现。结果并非简单地“某种拓扑完胜”而是各有其适用的场景和优缺点。3.1 串联拓扑效率与风险的平衡在简单用例用户注册登录上串联拓扑表现最佳。它的线性流程非常高效架构师确定了使用JWT令牌和Redis缓存会话开发接着完善了接口细节和错误码测试最后补充了针对暴力破解的限流测试点。整个过程流畅最终设计质量明显高于原始草案。然而在复杂用例CMS迁移中串联拓扑的弊端暴露了。架构师智能体首先提出了一个基于“事件驱动”的彻底解耦方案。这个方向本身有一定道理但过于激进。当这个方案传递给开发智能体时开发智能体的大部分反馈都集中在“如何在这个事件架构下实现某个具体功能”而不是去质疑“事件驱动对当前团队和项目是否是最佳选择”。测试智能体则进一步陷入细节。最终产出的设计虽然内部一致但整体上过度设计脱离了项目“平滑迁移、风险可控”的初始约束。这就是“误差累积”的典型表现第一个环节的偏差设定了整个思考的轨道。实操心得串联拓扑适用于目标明确、问题域相对收敛的任务。如果你想用它务必把最全面、最谨慎的智能体通常是“架构师”角色放在链条的起点并给予最清晰的约束条件。同时要意识到这是一种“风险前置”的模式。3.2 并行拓扑多样性与整合的代价并行拓扑在中等用例电商下单支付上展现了优势。三个智能体分别关注了不同层面架构师关注支付渠道的可扩展性和事务最终一致性方案如Saga模式开发关注库存锁定的API设计和幂等性测试则聚焦在支付成功/失败/超时等各种异常流的覆盖。最终我手动合并时感觉材料非常丰富像是一次高质量的头脑风暴。但它的缺点也很明显整合成本高三个输出版本可能有直接冲突。比如架构师建议用Saga开发可能详细设计了基于本地事务表的补偿机制而测试可能指出某种边缘情况下补偿难以测试。我需要花费大量精力去理解、权衡和手动合并这个过程本身就很耗时且依赖我个人的判断力。重复与冗余三个智能体可能会指出相同的问题如“需要幂等性”只是表述不同需要去重。3.3 混合拓扑辩论式质量与成本的博弈混合拓扑在复杂用例上产出了我个人评价最高的设计。第一轮并行评审后三个智能体意见分歧很大。在“辩论轮”中我观察到了一些模拟的“协作”行为开发智能体对架构师说“您提出的事件溯源Event Sourcing模式对于审计固然好但会极大增加当前团队的学习成本和实现复杂度我建议先采用更简单的状态跟踪。”测试智能体对两者说“我支持开发的保守意见。另外无论采用哪种方案请务必为每个核心状态变更提供明确的Hook点以便我注入测试桩。”经过两轮这样的“辩论”最终输出的意见虽然仍有不同但焦点更集中选项也更清晰例如明确给出了“激进方案A”和“渐进方案B”的对比。这极大地降低了我的决策成本。然而这种模式的成本是最高的。它消耗的Token数量API调用成本几乎是并行模式的两倍并且整个流程耗时更长。它更像一个“重”流程适合用于关键、高风险的设计决策而不是日常的简单设计任务。4. 超越实验构建实用LLM设计评审工作流的思考这次受控实验更像是一个原型验证。要将“LLM联合会”的想法工程化、实用化还需要解决一系列更深层的问题。4.1 智能体能力的“幻觉”与“对齐”问题实验中最让我头疼的不是协作拓扑而是每个智能体自身的“幻觉”。例如架构师智能体可能会推荐一个它“知道”但细节模糊的新兴技术栈开发智能体可能生成一段看似合理但存在死锁风险的伪代码。多智能体协作并不能根除幻觉反而可能让幻觉在交互中被“合理化”。我的应对策略是知识库RAG增强为每个智能体配备专属的知识库。例如为“架构师”智能体接入公司内部的技术规范文档、过往的架构决策记录ADR为“开发”智能体接入项目的API设计指南、代码库中的常见模式。在提示词中明确指令“你的建议应优先参考知识库中的规范如有偏离请明确说明理由。”链式验证Chain-of-Verification对于智能体提出的关键建议如“使用Redis集群”要求它自己再扮演一个“质疑者”列出这个建议的潜在风险和实施前提并给出应对措施。这相当于在智能体内部进行一次快速复核。4.2 协作中的状态管理与上下文工程在串联或混合拓扑中智能体之间传递的“设计版本”是一个核心资产。如何表示它简单地把整个对话历史扔给下一个智能体会导致上下文过长、焦点丢失。我实践下来比较有效的方法是结构化传递原始需求始终保留。当前设计草案用Markdown或结构化格式如伪代码、Mermaid图表。本轮评审意见要求智能体以“新增/修改/删除/疑问”的列表形式给出。关键决策与待决问题一个不断更新的列表。这样每个智能体都能快速抓住重点而不是在冗长的聊天历史中迷失。4.3 评估自动化与持续迭代的挑战人工评估终归是瓶颈。为了能让这个系统半自动化运行我在探索以下方向基于规则的初步过滤写一些简单的规则检查设计文档例如“是否所有API都定义了HTTP方法”、“是否提到了数据存储”。这可以过滤掉明显不合格的草案。利用LLM进行相对评估给定原始设计D和精炼后的设计R让一个“评估者”LLM回答“针对‘可维护性’和‘风险覆盖度’R在哪些方面明确优于D请列出具体点。” 这种相对比较比让它直接打一个绝对分更可靠。建立反馈闭环将最终被人类采纳的设计方案及其评审过程作为高质量样本反哺到各个智能体的知识库或微调数据中让它们越来越贴近团队的实际标准和偏好。5. 从多智能体协作看LLM应用的范式转移这次实验让我对LLM的应用有了更深的看法。我们正从一个“提问-回答”的简单范式走向“编排-协作”的复杂范式。单个LLM作为“万能问答机”存在明显的天花板尤其是在软件设计这类需要权衡、迭代和深度思考的领域。多智能体系统Multi-Agent System的魅力在于它通过角色划分和交互规则将复杂问题分解并模拟了人类团队中“观点碰撞-达成共识”的社会性智能过程。不同的协作拓扑实质上是不同的决策流程和沟通模型。串联是瀑布模型并行是头脑风暴混合辩论则类似敏捷评审。对于开发者而言未来的关键技能可能不再是精通某个模型的全部参数而是如何定义角色、设计流程、管理上下文以及评估结果——更像一个架构师或产品经理。我们使用的工具也从单一的聊天界面变成了一个可以编程的、由多个“数字同事”组成的协作环境。当然这条路还很长。智能体的稳定性、协作的成本、评估的客观性都是现实的挑战。但毫无疑问通过多智能体协作来放大LLM在复杂任务上的潜力是一个极具前景的方向。它让LLM不再只是一个被动的工具而是一个可以主动参与复杂思考过程的合作伙伴。我的下一步是尝试将其中一种拓扑可能是混合式固化成一个轻量级的内部工具用于实际项目的早期设计评审环节在真实场景中继续迭代和验证。