长太不看版：基于领域驱动设计思考的 AI Agent 框架 Chocolate Factory，框架现在还在 PoC 阶段，欢迎加入开发。（当前主要关注于 SDLC + AIGC 的场景）。
GitHub：https://github.com/unit-mesh/chocolate-factory
Demo 视频：
在过去的一段时间，我们尝试从先前的 AIGC 应用经验里，进行一些再提炼和总结。从起先的 ClickPrompt（https://www.clickprompt.org/）、ChatFlow，到我们的 AI + 软件开发组织 Unit Mesh 下构建了一系列应用：
AutoDev。一个具备多语言支持 🌐、自动生成代码 🏗️ 和有用的错误修复助手 🐞 的AI驱动编程巫师！包括可定制的提示 🎨 和神奇的自动测试功能 🧪！🚀
DevTi。一个基于 LLM 的微调来提供全面智能化解决方案，助力开发人员高效完成开发任务，以实现自动化用户任务拆解、用户故事生成、自动化代码生成、自动化测试生成等等。
CoUnit。一个基于 LLM 的虚拟团队接口人（API），通过向量化文档、知识库、SDK和 API 等，结合 LLM 智能化团队间对接与协作。
以及我们在其它海外、国内的内外部项目上的应用经验。
于是乎，我们开始构建 Chocolate Factory 框架，以实现一个内部的目标：如何在 1 天内将一个复杂场景做成 PoC？
引子 1：回顾 LLM + 工作流
半年前，我们构建了 ChatFlow：https://github.com/prompt-engineering/chat-flow ，一个围绕 ChatGPT 构建的简易工作流引擎。简单来说：将做事的套路工具化，结合 AI 进行自动化。具体来说：
我们认为每个具体的问题可以拆为 N 步。
每一步都需要结合具体的规范和上下文。
N 步之间都是有关联的，诸如于通过 DSL。
我们先前设计的 DSL 如下所示：
# ....
- name: 分析需求，编写用户故事
ask: |
story: $$placeholder$$
cachedResponseRegex: .*
values:
placeholder: |
用户通过主菜单进入“权限管理”模块，选择“账号管理”Tab页，可以看到“新增账号”按钮。
点击“新增账号”按钮，系统弹出新增账号窗口（可能还会写一句“背景置灰”）。
用户可在窗口中填写姓名、登录邮箱……
若用户未填写必填字段，则点击“确认”时给出错误提醒“请完成所有必填字段的填写！”
点击“确认”按钮后弹出二次确认窗口，二次确认信息为“确认创建该账号？账号一旦创建成功即会邮件通知对应用户”。用户再次选择“确认”则系统创建账号，若用户选择“取消”则返回填写账号窗口。
- name: Mermaid 绘制流程图
ask: |
我会给你一个模糊的需求，你需要：
1. 分析和完善需求，但是不需要返回结果给我。
2. 使用 Mermaid 绘制时序图，但是不需要返回给我。
3. 最后，只返回 Mermaid 代码，如："""```mermaid graph {}"""，只返回 Mermaid 代码。
需求，如下：
"""
$$response:1$$
"""而在使用 RAG 技术时，即结合向量数据库时，我们可以添加更多的 examples 作为上下文，就可以使 LLM 更理解我们的问题，以输出更理想的解决方案。
引子 2：DDD 的问题空间与解空间
软件系统的构建实则是对问题空间的求解，以此获得构建解空间的设计方案。—— 《解构领域驱动设计》
在领域驱动设计（Domain-Driven Design，简称DDD）中，问题空间（Problem Space）和解空间（Solution Space）是两个关键的概念，用于帮助开发团队理解和建模复杂的领域问题以及设计相应的软件解决方案：（由 ChatGPT 生成）
问题空间（Problem Space） 问题空间是指领域中实际的业务问题、需求和挑战，它关注的是业务领域的本质问题和业务需求。在问题空间中，团队与领域专家合作，收集和理解领域的业务规则、流程、概念以及业务需求。
解空间（Solution Space）是指基于问题空间的理解所提出的软件解决方案，包括软件架构、设计模式、编码实现等。在解空间中，开发团队将问题空间的概念和需求映射到具体的代码和技术实现上。
DDD 强调问题空间和解空间之间的分离，这意味着在开始开发之前，团队应该首先深入了解问题空间，与领域专家合作，确保对领域的理解是准确的。然后，他们可以将这个理解映射到解空间，设计和实现相应的软件系统。
Chocolate Factory：将 DDD 应用于 Agent 设计
（在 Chocolate Factory 中，右边才是真正 AI Agent 的使用领域）
围绕于上面的思考，也就有了 Chocolate Factory 三个核心思想：
基于问题域的用户意图识别与引导。
以 DSL 作为问题域与解决方案的中间语言。
围绕解决方案的内容生成与执行结果。
而如何设计中间的 DSL，以作为问题域的精炼，并作为解决方案的输入，则需要取决于不同领域的场景。
基于我们现有的框架能力，我们在三个场景下构建了示例：
text2UI，文本生成前端 UI。步骤分为三个阶段：问题澄清、方案设计和方案执行。
text2code，文本生成代码。步骤只有一个阶段：方案执行。
text2testcases，文本生成测试用例。
详细可以见前面的参考视频。
Text2UI 示例
当然了，这么说有一些抽象，我们可以先看个例子。如下是 Chocolate Factory 的文本转 UI 的步骤：
步骤 1：ProblemClarifier：使用响应式布局，编写一个聊天页面
步骤 1.1：ProblemClarifier：左边是一个导航，中间是聊天区，聊天区的下方是一个输入按钮。
步骤 2：SolutionDesigner：请确认以下的设计是否符合您的要求。如果符合，请回复"YES"，如果不符合，请提出你的要求。
步骤 3：SolutionExecutor：生成一个聊天页面
最后效果图如下：
Chocolate Factory 的 Stage 设计
根据上面的思想，我们设计了五个 Stage：
ProblemClarifier.kt：根据用户提供的文本来澄清问题，以确保准确理解用户的需求。问题澄清器的任务是分析用户的输入，提取关键信息，可能要求用户提供更多详细信息以确保问题清晰，并将清晰的问题描述传递给下一步。
ProblemAnalyzer.kt：可以进一步分析问题，将问题细化成更具体的子问题或任务，以帮助解决方案的设计和执行。
SolutionDesigner.kt：根据经过问题澄清和分析后的用户需求，设计一个解决方案。解决方案设计师的任务是将问题领域的需求转化为可执行的计划或设计，确保解决方案符合用户的期望和要求。
SolutionReviewer.kt：负责审核已经设计好的解决方案，以确保其质量、安全性和合规性。审核员可能会对解决方案进行测试和评估，并提出建议或修改，以满足特定标准和要求。
SolutionExecutor.kt：负责实际执行解决方案的步骤，根据设计好的计划来生成结果。根据具体情况，解决方案执行者的任务可以包括编程、自动化、生成文档等。
在不同的领域里，会根据场景不同，而有所取舍。诸如在测试用例的场景下，text2tecases 的步骤如下：
步骤 1：ProblemAnalyzer 分析用户的需求，确认是否是一个测试用例生成的需求
多 Temperature 模式：TemperatureMode.Default, TemperatureMode.Creative
步骤 2：SolutionDesigner 设计测试用例生成的方案
步骤 3：SolutionReviewer 确认方案是否符合用户的需求
当然，后续还可以继续结合执行场景的代码：
部署和开发 Chocolate Factory
只需要下载项目，并启动 docker compose 就行了。
git clone https://github.com/unit-mesh/chocolate-factory
# modify OPENAI_API_KEY and OPENAI_HOST in docker-compose.yml
docker-compose up模块：Code Interpreter
我们从加强了开发的 Unit Runtime 中提供的 REPL 功能，除了原先的 Spring、Ktor 框架的代码段运行，现在还可以支持绘图功能。
模块：Local Embedding
在代码场景上，由于已经有 Bloop 的成功经验，所以我们采用了同样的方式 —— 使用本地 Sentence Transformers 进行 embedding，并进对应的向量化搜索。
小结
Chocolate Factory 框架为解决复杂问题提供了一个结构化的方法，通过结合领域驱动设计和AI生成代码技术，可以快速实现复杂场景的Proof of Concept（PoC）。这个框架的开源性使得更多开发者可以参与并贡献，推动了 AIGC 领域的发展。
框架现在还在 PoC 阶段，欢迎加入框架的开发。
GitHub：https://github.com/unit-mesh/chocolate-factory
![[学习笔记]PageRank算法](https://img-blog.csdnimg.cn/48de627f51ec460f8aa932c198d22b72.png)
