本文基于AI Mind项目的真实实现整理。GitHubhttps://github.com/HWYD/ai-mind对应代码版本v0.3.5 - v0.4.1线上链接https://ai.hwyblog.cloud/instant-mindAI Mind 是一个基于 Next.js 持续迭代的 AI Chat 项目项目从本地大模型聊天起步逐步扩展流式协议、工具调用、MCP、Skill Runtime 和 Agent 等能力。如果这篇文章或 AI Mind 项目对你有所帮助也欢迎到 GitHub 给项目点个 Star⭐这会是对我继续整理后续版本复盘很大的鼓励。起点从固定 Pipeline 到多 Agent 的演进动机先交代一下背景。AI Mind 是我在做的一个 AI 助手项目其中有一条链路叫/delivery-chain——用户输入需求系统输出一份从需求理解到实现方案到任务拆解到交付评审的完整报告。这条链路后来演变成了一套多 Agent 协作架构也是本文要讲的核心。在做/delivery-chain之前项目里已经有一条更成熟的链路/tasklist——具备持久化、人工审批Human-in-the-Loop简称 HITL、断点续跑还接了可观测性出了问题能定位 trace。这条线是稳的但它是为版本规划任务拆解这个特定场景设计的有它自己的状态机和交互模型。/delivery-chain的定位不一样。它是一个公开 demo 入口要展示从需求走到交付评审的端到端能力但又不能真的改代码、不能读真实项目文件、不能有太重的持久化负担。第一个版本我用 LangGraphStateGraph写了一个固定顺序的 workflowloadContext → Plan → Task → Review → BuildReport。四个节点硬编码串起来跑完就完了report 是 run 内的非持久化输出。这个版本能用但我越用越觉得它有架构上的局限流程是死的加阶段、调顺序都要改图结构Review 只有一个通用评审视角无法从风险、边界等多个角度同时审查LLM 在每个 stage 内部有发挥空间但做什么、按什么顺序做完全是代码写死的我想让 LLM 参与流程编排——决定什么时候调哪个阶段、让多个视角的评审同时进行——但又不想做成那种Agent 之间无限聊天的混乱局面。这是一个典型的灵活性 vs 可控性的矛盾。从 v0.3.5 到 v0.4.1我用了几个版本逐步回答这个问题。整个演进路线是固定Pipelinev0.3.6→ 进度可视化v0.3.7→ 串行Agent-as-Toolv0.4.0→ 并行评审synthesisv0.4.1。最终v0.4.1的架构如下——先看全貌后面逐层展开/delivery-chain 请求 - 加载 demo 上下文 - ControlledDeliveryManager - 阶段: plan串行 - 调用 plan-subagent - 接收 plan artifact - 阶段: task串行依赖 plan - 调用 task-subagent传入 plan artifact - 接收 tasks artifact - 阶段: review-group受控并行依赖 plan tasks - 调用 review-subagent 通用评审 - 调用 risk-subagent 风险评审 - 调用 boundary-subagent 边界检查 - 接收 3 份评审结果 - 阶段: synthesis - 构建 ReviewBundle - 代码规则优先处理blocked 判断 / 冲突合并 / 风险排序 - LLM 润色最终报告LLM 失败降级为纯规则输出 - 输出交付链路报告五个子Agent两个阶段串行一个阶段受控并行最后Manager做综合判断——这就是最终形态。这篇文章讲的就是这个架构是怎么设计出来的以及为什么这么设计。现有多Agent模式为什么我没直接用在动手之前我先梳理了一下当时主流的几种多Agent编排模式想清楚它们各自的问题在哪里。模式一固定顺序 Pipeline这是我最初用的方案。LangGraph StateGraph 串固定节点边写死没有分支。优点绝对可控流程100%确定极易调试安全边界清晰。缺点完全不灵活流程写死改不了LLM 没有任何跨阶段决策权加阶段、调顺序都要改图结构。这是最笨但最可靠的方案适合流程完全固定的场景但不是我想要的终点。模式二Supervisor Worker一个 Supervisor Agent 作为主控由它根据任务进展动态决定调用哪个 Worker Agent。Worker 之间不直接通信一切委派通过 Supervisor。LangGraph 的 Supervisor 模式、很多框架的Manager Agent都是这个思路。优点灵活LLM 有较大的决策空间能动态调整流程。缺点可控性差。Supervisor 是 LLM它可能做出错误路由没plan就直接写代码、陷入循环A→B→A→B…、重复调用。没有代码层硬约束所有规则都靠 prompt 说但 prompt 是建议不是护栏。出了问题很难调试——你不知道 Supervisor 为什么做出那个决策。模式三自由对话 / Group ChatAutoGen、CrewAI 支持的模式多个Agent在群聊里自由发消息通过 Speaker Selection 决定下谁说话。Agent 之间可以直接对话、辩论、互相批评。优点最灵活最像人类协作适合头脑风暴和创意生成。缺点最不可控。Agent 之间容易陷入无意义的冗长对话循环行话叫聊嗨了——可能为一个细节来回讨论十几轮几乎没有安全边界调试极其困难几十上百轮对话根本不知道问题出在哪。这种模式适合Demo和创意场景不适合生产环境里需要可靠完成任务的场景。模式四Map-Reduce / 并行分发一个任务分发给多个Worker并行处理最后汇总。适合子任务完全独立的场景效率高但处理不了有依赖关系的顺序流程也没有编排决策权。我需要的位置把这四种模式放在可控性-灵活性光谱上看完全可控 ──── Pipeline ──── Agent-as-Tool ──── Supervisor ──── Free Chat ──── 完全自由 ▲ 本文的位置我需要的是Pipeline和Supervisor之间的位置比Pipeline灵活LLM有一定编排决策权可以支持多视角并行评审比Supervisor可控得多代码层硬护栏兜底不是靠prompt说服模型支持有控制的并行不是任意并行而是在明确的阶段边界内、白名单工具之间的并行这就是我做Agent-as-Tool的出发点。Agent-as-Tool核心架构设计核心思路一句话把各个阶段从固定图节点变成注册给Manager的ToolManager通过模型原生tool-calling调用它们但每次调用前必须经过代码层Phase-aware DelegationPolicy校验并行只在明确允许的Review阶段内发生。这个设计有五个关键组成部分。一、子Agent 结构化Tool不是自主Agent我没有造新的Agent runtime也没引入多Agent框架。plan-subagent、task-subagent、review-subagent、risk-subagent、boundary-subagent就是五个普通的工具定义项目中所有工具的注册接口定义名称、输入输出 Schema 和执行函数用Zod schema定义输入输出和系统里的搜索工具、文件读取工具地位完全平等——同一个注册机制没有特殊通道。模型用原生tool-calling调用它们不需要新的通信协议。每个subagent tool有明确的边界定义typeSubagentToolDefinition{id:plan-subagent|task-subagent|review-subagent|risk-subagent|boundary-subagentroleInstruction:stringinputArtifactKinds:RuntimeArtifactKind[]// 必须的输入artifact可选值见下文 RuntimeArtifactoutputArtifactKinds:RuntimeArtifactKind[]// 产出的artifactallowedTools:string[]// 子Agent自己能调的工具nonGoals:string[]// 明确不能做什么runtimeScopes:[delivery-chain-manager]// 作用域}五个子Agent各自的职责plan-subagent理解需求生成实现方案task-subagent基于plan拆解具体任务review-subagent通用评审——检查plan/tasks对齐、任务拆解合理性、漏项、优先级、验收清晰度risk-subagent风险评审——检查实现复杂度、测试覆盖、tool-calling稳定性、维护成本等输出high/medium/blocker/low风险等级和缓解建议boundary-subagent边界检查——检查是否越界触碰DB/HITL/checkpoint/artifact:///Tasklist Agent等非目标范围输出passed/needs_review/blocked这里有几个重要设计一是nonGoals不只是告诉它要做什么还明确告诉它不要做什么二是inputArtifactKinds是代码层硬约束不是prompt建议——task-subagent必须收到plan artifact才能被调用三是所有subagent tools通过runtimeScopes做作用域过滤只在delivery-chain-managerscope内可用普通聊天场景看不到它们。二、Phase-aware DelegationPolicy代码层硬护栏这是整个架构最关键的部分。先说一下 v0.4.0 的基线状态五个子 Agent 已按固定顺序串行调用plan → task → review不允许任何并行。v0.4.1 在此基础上做了两件事——把并行能力按阶段放开并加入 Manager synthesis。并行不是全局开关而是按阶段控制constdeliveryChainDelegationPolicy{allowedSubagentTools:[plan-subagent,task-subagent,review-subagent,risk-subagent,boundary-subagent],maxToolCalls:5,// plantask3review5allowParallel:false,// 全局不允许并行allowNestedDelegation:false,// 禁止子Agent嵌套调用requirePlanBeforeTask:true,requireTasksBeforeReview:true,rejectUnregisteredTools:true,rejectOutOfOrderToolCalls:true,// 新增Review Group 独立控制并行reviewGroupPolicy:{allowedReviewTools:[review-subagent,risk-subagent,boundary-subagent],allowParallelInReview:true,maxReviewToolCalls:3,}}Manager主循环按phase执行plan(串行) → task(串行) → review-group(受控并行) → synthesis。Policy校验规则Plan/Task阶段任何parallel tool calls直接fail closed与v0.4.0一致Review阶段只允许白名单内三个review-class tools并行混入plan/task或未注册工具直接fail closed任何阶段超过maxToolCalls、嵌套委派、未注册工具、乱序调用——一律fail closed为什么不直接把全局allowParallel改成true因为那样会破坏Plan/Task阶段的fail-closed保障。并行能力必须是phase-scoped的而不是全局放开。这是我刻意的设计选择——宁可加一层ReviewGroupPolicy也不在全局开关上妥协。关于fail closed策略任何一项不通过直接fail closed——不执行tool不把错误返回给LLM让它纠错直接返回安全失败信息终止流程。为什么不给LLM改错机会因为我不想模糊代码层约束和LLM决策的边界。如果Policy拦住了非法调用却又把错误扔回给LLM让它纠正那护栏就变成了建议。MVP阶段护栏就是护栏碰了就停。三、RuntimeArtifact单次run内的受控流转多Agent协作的核心问题是信息交接——plan的输出要交给taskplantasks要交给三个review并行消费。我设计了RuntimeArtifact作为内部交接载体typeRuntimeArtifact{id:stringkind:plan|tasks|review|delivery_reporttitle:stringmarkdown:stringsource:{subagentId?:string;stage?:string}metadata?:Recordstring,unknown// 用metadata扩展不新增kind}v0.4.1我刻意不新增RuntimeArtifact kind。三个review subagent产出的artifact都用kind: review通过metadata.reviewType区分general | risk | boundary。这样不修改schema定义不引入breaking change。risk-subagent还会在metadata里带severity: blocker | high | medium | low | infoboundary-subagent带boundaryStatus: passed | needs_review | blocked和blocked: true/false。RuntimeArtifact的设计围绕三不原则不持久化。Artifact只在单次run的内存中存在不写数据库不做跨会话交接。这不是偷懒是刻意选择。持久化是最昂贵的架构决策——一旦写入数据库schema迁移、权限控制、数据清理、向后兼容全来了。等真的需要artifact://scheme和artifact持久化时再在RuntimeArtifact基础上演进而不是一开始就做一个通用artifact system。不暴露给前端。Artifact不进入message.artifacts不进入artifact-*stream chunks。它是Agent之间的内部交接语言不是给用户看的。用户看到的最终Delivery Chain Report是Manager综合后生成的用户友好版本。不泄露敏感信息。Artifact里不能有raw prompt、raw response、stack trace、API key、cookie、真实文件路径。子Agent返回的summaryForManager必须是经过脱敏的安全摘要。Artifact的流转依赖链plan-subagent完成 → RuntimeArtifact(kindplan) ↓ task-subagent消费plan → RuntimeArtifact(kindtasks) ↓ review-group并行消费plantasks: ├── review-subagent → RuntimeArtifact(kindreview, reviewTypegeneral) ├── risk-subagent → RuntimeArtifact(kindreview, reviewTyperisk) └── boundary-subagent → RuntimeArtifact(kindreview, reviewTypeboundary) ↓ Manager综合三个review → RuntimeArtifact(kinddelivery_report) → 用户看到报告四、Tool Result强Schema契约子Agent不能返回自由格式的Markdown文本必须返回符合Zod JSON Schema的结构化结果typeSubagentToolJsonResult{status:completed|blocked|failedmarkdown:string// 给用户看的内容artifactTitle?:stringwarnings:string[]summaryForManager:string// 给Manager的安全摘要不给用户看metadata?:Recordstring,unknown}为什么要强Schema因为如果返回自由文本ManagerLLM需要理解文本内容来决定下一步这又引入了不确定性。强Schema让Manager runtime可以确定性地处理结果——completed就生成artifactfailed就记录blocked就标记——不需要LLM去猜。校验不通过一律按failed处理不生成artifact。五、ReviewBundle Manager Synthesis规则优先LLM润色v0.4.1最有价值的升级是Manager synthesis。三个并行review返回结果后不是简单把三段markdown拼在一起而是构造ReviewBundlerun-local内部结构包含generalReview、riskReview、boundaryReview和failedReviews数组先用代码硬规则处理关键判断再交给LLM润色LLM润色失败时降级为纯规则生成的报告不fail closed硬规则包括boundary-subagent返回blocked → final conclusion blocked最高优先级risk-subagent severityblocker → 等同于boundary blockedfinal conclusion blockedboundary-subagent failed → final conclusion至少needs_reviewreview-subagent failed → final conclusion needs_reviewrisk-subagent failed → final report标注risk review missing多个子Agent提到相同问题 → 合并去重子Agent意见冲突 → 标注冲突并给出综合判断Partial failure1-2个review failed时synthesis继续report标注哪些检查缺失3个全部failed才fail closed为什么用规则优先LLM润色而不是让LLM自己综合因为纯规则保证安全性和可测试性——blocked判断、风险优先级这些不能靠LLM发挥LLM润色提升报告的可读性和自然度避免报告像机器拼接的降级机制保证LLM失败时核心流程不受影响——最差情况是输出纯规则生成的朴素报告但不会崩溃最终报告结构包含综合结论、本轮评审覆盖情况、Review总评、风险评估、边界检查、合并后的关键问题、阻塞项/高风险项、建议下一步。关于并行的设计取舍v0.4.0是完全串行v0.4.1只在Review阶段放开并行。为什么不做更激进的并行Plan和Task有严格依赖链Task必须消费Plan产物并行没有意义还增加复杂度三个评审天然独立通用质量、技术风险、边界合规并行能同时从三个视角审查且有实际价值限制并行范围可以保持DelegationPolicy的可控性——全局allowParallel保持false只在ReviewGroupPolicy里放开不做任意tool并行不做plan/task阶段并行不做嵌套并行这是一个刻意保守的选择。并行是能力但也是复杂度来源。先在最有价值、依赖最清晰的地方放开验证稳定后再考虑扩展。执行流程与安全防御受控工具调用循环v0.4.1 最终版实际的运行时循环按phase执行初始化加载 demo 上下文初始化空artifact集合和ReviewBundle绑定五个子Agent tools到Manager初始化Policy状态Plan phaseManager决定调用plan-subagent过Policy校验必须串行、不能是其他tool执行结果过Schema校验生成plan artifactTask phaseplan artifact存在后才能进入Manager调用task-subagent传入plan artifact同上校验生成tasks artifactReview phaseplantasks都存在后才能进入Manager在一次tool call中发起三个review-class tools的并行调用如果模型只返回1-2个缺失的标记为failed过ReviewGroupPolicy校验只能是这三个、不能混入其他tool、不能嵌套并行执行三个tool结果分别过Schema校验生成三个review artifactcompleted的构造ReviewBundleSynthesis phase基于ReviewBundle执行硬规则处理再LLM润色LLM失败则降级纯规则输出生成delivery_report输出最终报告模型有决策权但决策权被Policy严格限制在边界内。模型可以决定我现在要进入review phase并调用三个并行review但它不能决定跳过plan直接调review——Policy会拦住。部分失败处理并行场景下partial failure是常态我做了分级处理单个review返回非法JSON该review标记为failed其余继续1个review failedsynthesis继续report标注对应review missing2个review failedsynthesis继续report标注2个review missing3个review全部failedfail closed输出安全失败报告模型在review phase返回4个以上tool callfail closed超过允许的3个模型在plan/task phase返回parallel callsfail closed这种容忍部分失败但不容忍全部失败的策略比v0.4.0的任何失败直接fail closed更务实也更符合并行执行的实际场景。七层安全防线从v0.3.5到v0.4.1我叠了七层防御层机制防什么1. Tool白名单Manager只绑五个subagent tools看不到无关/危险工具2. Scope过滤runtimeScope限定delivery-chain-manager普通聊天场景不暴露子Agent3. Phase-aware PolicyDelegationPolicy分阶段控制顺序/依赖/并行范围乱序/重复/非授权并行直接被拦4. Schema校验Zod强JSON Schema校验tool result格式错误、夹带敏感信息都被拦5. 规则优先Synthesis硬规则处理blocked/风险/冲突不依赖LLM判断关键安全判断确定性执行6. Partial failure降级1-2个失败继续synthesisLLM润色失败降级纯规则避免单点失败导致整体崩溃7. 信息脱敏Progress只发安全摘要不含raw数据用户看不到prompt/response/stack/artifact我不相信单一防线。七层叠在一起即使某一层被突破还有其他层兜着。这是传统安全工程 Defense in Depth 的思路用在Agent系统里一样有效。用户体验进度展示工作流进度用通用的workflow-progress-*chunk协议v0.4.1的step序列是load → delegate-plan → delegate-task → delegate-review-group → synthesize-report注意review阶段不是三个step而是一个汇总stepdelegate-review-group——并行评审的进度用单step汇总展示summary是安全描述“已启动并行评审”不暴露raw invocation、raw result、RuntimeArtifact。不新增stream chunk类型不修改frontend reducer public shape。完成后所有step自动折叠成一行已处理XmXXs。Agent-as-Tool的优缺点与适用场景对比其他模式的优缺点经过v0.3.5到v0.4.1的实际实现和使用我对Agent-as-Tool的优缺点有比较清晰的认识相比固定Pipeline优点LLM有编排决策权在Policy边界内支持多视角并行评审新增子Agent不需要改图结构只需注册tool并更新Policysynthesis规则可以独立演进缺点比Pipeline复杂需要维护Policy、Schema、ReviewBundle理论上有LLM决策在边界内出错的可能但Policy兜底相比Supervisor模式优点代码层Policy强制约束不依赖prompt说服模型phase-aware并行控制不会全局放开乱序/非授权并行/超调用直接被拦不会无限循环子Agent是强Schema Tool边界清晰关键判断用硬规则不依赖LLM调试更简单——tool call边界明确缺点灵活性不如纯SupervisorPolicy限制了模型的决策空间需要upfront定义Schema和Policy前期设计成本稍高并行是phase-scoped的不是任意并行相比自由对话/Group Chat优点可控性高几个数量级安全边界清晰不会无限聊天支持受控并行而不混乱调试可追踪partial failure有降级策略缺点不适合创意生成和开放式探索不支持Agent之间对等协商辩论流程相对刚性什么时候应该用Agent-as-Tool企业级/生产级AI应用有严格安全要求、不能出错、需要可审计的场景。出错代价高需要系统行为在可预测范围内。流程有大致阶段但允许细节决策有明确阶段划分阶段间有依赖关系但允许模型在阶段内自主决策未来可以增减阶段或调整评审视角。需要多视角并行审查同一组产物需要从不同独立视角同时评审比如质量、风险、合规并行能提升效率和覆盖度。步骤间有明确依赖关系DAG式的依赖B必须等A的输出C必须等AB的输出用RuntimeArtifact和Policy可以很好表达。需要可观测可调试出了问题能快速定位——是Policy拦了是哪个subagent失败了是Schema校验没过边界清晰。什么时候不应该用开放式创意生成头脑风暴、写小说、辩论——需要Agent自由发挥、碰撞想法护栏太多会扼杀创意。用自由对话模式更好。流程完全不确定你甚至不知道需要哪些步骤需要Agent自己探索该做什么Agent-as-Tool的固定tool集合和Policy太死板。Hackathon/快速原型想快速验证想法固定Pipeline或CrewAI更快。Agent-as-Tool需要定义Schema、写Policy、做边界这些工程化工作在原型阶段是负担。Agent对等协商多Agent站在不同立场辩论、讨价还价星型Manager结构不支持对等交互。刻意不做的事从v0.4.0到v0.4.1我始终坚持一个很长的Non-goals清单不做全局Agent Catalog不需要一个中心化的 Agent 注册中心让用户自由注册、发现和组合 Agent子 Agent 始终由 Manager 内部控制不做subagent-to-subagent直接通信所有交接通过Manager和RuntimeArtifact不做nested subagent子Agent不能调子Agent避免委派链条失控不做任意并行只有review阶段三个白名单tool允许并行不做HITL/checkpoint/resume不接PostgresSaver保持/delivery-chain轻量HITL是后续版本的事但复杂度太高v0.4.1不碰不做artifact://持久化不提前做通用artifact系统不做用户可选subagent picker用户不需要也不应该选择调用哪些子Agent不保留旧graph fallback不做双主控不新增RuntimeArtifact kind用metadata扩展而非新kind不修改stream-core/frontend reducerPublic surface完全不变模型不支持tool-calling/parallel tool-calling直接fail closed不降级回旧runner**知道不做什么比知道做什么更难。**每加一个功能架构复杂度就上一个台阶。我只做最小必要集合。一些工程复盘做完这轮从v0.3.5到v0.4.1的重构有一些体会。护栏比引导可靠。不要试图用几百字prompt引导模型做正确的事。模型是概率性的总有概率忽略指令。用代码层白名单、Schema校验、Policy约束确保它不能做错事比希望它会做对事靠谱得多。Fail Closed不是保守是负责任。并行要phase-scoped不要全局放开。一开始我想过直接把allowParallel改成true后来意识到这会破坏Plan/Task阶段的安全性。最终的方案是全局保持串行只在ReviewGroupPolicy里独立控制并行——这个设计虽然多了一层抽象但安全性有保障。规则优先LLM润色。涉及blocked判断、风险等级、冲突合并这些关键决策用代码硬规则保证确定性自然语言生成、报告可读性这些交给LLM。LLM润色失败有降级不影响核心流程。这比让LLM做所有事靠谱得多。Partial failure是并行的常态。串行场景下一个环节失败整个流程失败是合理的但并行场景下不能因为一个review失败就丢掉另外两个有效的结果。分级处理部分失败标注缺失继续全部失败才终止。公开接口是负债。从v0.3.5到v0.4.1我始终只暴露/delivery-chain一个命令。五个子Agent是内部概念用户看不到。v0.4.1做了并行评审和synthesis升级stream protocol和frontend reducer完全没变用户几乎感知不到内部重构。非持久化原则。RuntimeArtifact只存在于内存不写数据库。这不是偷工减料是刻意选择。持久化是最昂贵的架构决策等真的需要时再加不提前做通用系统。用metadata扩展不要新增kind。risk和boundary review没有新增RuntimeArtifact kind而是复用kind:reviewmetadata区分。这避免了schema膨胀也为未来扩展留了空间。渐进式演进优于大爆炸重写。固定Pipelinev0.3.6→进度可视化v0.3.7→串行Agent-as-Toolv0.4.0→并行评审synthesisv0.4.1四个版本每一步用户都几乎无感知。不要等完美架构想清楚再动手先做能跑的版本再在稳定基础上逐步重构。好的架构是演进出的不是设计出来的。测试要用fake model。从v0.4.0到v0.4.1Manager测试始终用fake tool-call model不依赖真实provider。真实模型的tool-calling输出不稳定contract test必须确定性。partial failure组合我只测关键路径全成功、1个失败、boundary blocked、全失败不测全部27种组合——避免测试爆炸。克制是工程能力。Non-goals清单上的每一条都是我主动放弃的。AI领域每天有新框架、新demo刷屏忍住不加功能比加功能更难。最后这篇文章没有提出什么革命性的新概念。Agent-as-Tool本质上是把传统软件工程里接口定义、“契约编程”、“权限控制”、“分层防御”、降级策略这些老思路用到了多Agent系统设计上。子Agent就是有强Schema的工具DelegationPolicy就是代码层权限检查RuntimeArtifact就是类型安全的内部数据传递Synthesis硬规则就是业务逻辑不能交给LLM的体现。AI Agent领域很热闹每天都有自主Agent完成复杂任务的demo。但Demo和生产系统是两回事。真要让用户用需要它可靠、可控、出了问题能定位、部分失败能降级。给Agent套上护栏不是限制它的能力而是让它的能力真正可用。并行能力不是放开就好要在明确的边界内、在最有价值的地方放开。关键判断不要交给LLM代码硬规则兜底LLM负责它擅长的事——自然语言生成和润色。这就是我从v0.3.5到v0.4.1这次重构的全部思考。项目地址 GitHubhttps://github.com/HWYD/ai-mind 线上体验https://ai.hwyblog.cloud/instant-mind如果这篇文章或者 AI Mind 项目对你有所帮助也欢迎给项目点个 Star⭐。你的支持会是我持续更新这个系列、继续整理项目实现过程和设计复盘的很大动力。