导读：本文围绕 TaskMatrix 仓库中的 Low-code LLM 子项目，系统讲解一种将人类纳入循环（human-in-the-loop）的新型人机交互模式——由规划 LLM 将复杂任务拆解为结构化工作流，用户通过六种预定义低代码操作可视化地审查与编辑工作流，再由执行 LLM 严格按工作流生成响应。读完本文，你将掌握该框架的整体架构、三种核心 API 的调用链、Docker 一键部署与 OpenAI/Azure 双端接入方式，以及工作流 JSON 数据模型与前后端实现细节，可直接复现运行并在此基础上扩展自己的前端界面。

一、核心思想：为什么需要"低代码"的人机交互

Low-code LLM是 TaskMatrix 项目中提出的一种新型 human-LLM interaction pattern（人类-LLM 交互模式）。与"一次性提问、一次性回答"的传统对话式 LLM 使用方式不同，Low-code LLM 的核心主张是：

将人类纳入循环（human in the loop），以获得**更可控、更稳定（more controllable and stable）**的 LLM 响应。

其理念与 TaskMatrix.AI 一脉相承：TaskMatrix.AI 致力于通过更有效地拆解任务，并利用现有的基础模型以及其他 AI 模型/系统的 API，在数字与物理领域实现多样化任务的自动化；而 low-code 人机交互模式可以增强用户对过程的控制（controlling over the process）与偏好的表达（expressing their preference），二者形成互补。

从源码结构看，该想法的落地形态是一个两阶段 LLM 流水线：planningLLM（规划 LLM）负责把任务变成"标准作业程序（SOP）"，executingLLM（执行 LLM）负责按 SOP 产出最终答复，人类则站在两者之间对工作流进行可视化审查与编辑。详见 LowCodeLLM/src/lowCodeLLM.py 中的lowCodeLLM类，它聚合了self.PLLM = planningLLM(...)与self.ELLM = executingLLM(...)两个组件。

需要注意的是，作者在 README 中明确说明：由于时间限制，仓库提供的代码是最小可行版本（minimum viable version），仅用于演示 Low-code LLM 人机交互的核心概念，并欢迎任何人改进前端界面。

二、系统概览：四步人机协作闭环

整套交互过程由下图所示的闭环完成（图源仓库 assets/low-code-llm.png）：

整个 human-LLM 交互流程包含四个环节：

1. 规划（Planning）：一个 Planning LLM 为复杂任务生成高度结构化的工作流（highly structured workflow）。
2. 用户编辑（User Editing）：用户使用预定义的低代码操作编辑工作流——这些操作全部通过**点击（clicking）、拖拽（dragging）或文本编辑（text editing）**完成，无需写代码。
3. 执行（Executing）：一个 Executing LLM 基于用户审阅后的工作流生成响应。
4. 精化（Refinement）：用户持续调整工作流，直到获得满意的结果。

这四步与 LowCodeLLM/src/app.py 中暴露的三个 HTTP 接口一一对应：/api/get_workflow（生成初始工作流）、/api/extend_workflow（扩展子工作流）、/api/execute（按确认的工作流对话执行），前端每次操作都会调用这些接口与后端lowCodeLLM实例交互。

仓库还附带了一个概念演示视频（README 中标注 "This is a conceptual video demo to demonstrate the complete process"），用于展示完整流程。

三、快速开始：Docker 部署与 OpenAI / Azure 双端接入

3.1 环境要求

• Docker 环境；
• 可用的OpenAI API或Azure OpenAI Service凭证；
• 端口8888未被占用（容器内应用默认监听8888）。

3.2 构建与运行

按照 README 的 Quick Start，完整步骤如下：

# 克隆仓库 git clone https://gitcode.com/gh_mirrors/ta/TaskMatrix # 进入 LowCodeLLM 目录 cd LowCodeLLM # 构建镜像 docker build -t lowcode:latest . # 方式一：使用 OpenAI API —— 只需提供 API Key docker run -p 8888:8888 --env OPENAIKEY={Your_Private_Openai_Key} lowcode:latest # 方式二：使用 Azure OpenAI Service —— 建议将必要信息写入配置文件 # 1. 复制 config.template 并命名为 config.ini # 2. 在 config.ini 中填好各项信息 docker run -p 8888:8888 --env-file config.ini lowcode:latest

启动后，浏览器访问http://localhost:8888/即可进入 Demo 页面。

3.3 两种 API 接入方式的配置说明

README 明确指出：OpenAI API 与 Azure OpenAI Service 均已支持，运行前需要提供调用这些 API 的必要信息。

• 使用OpenAI API时，只需通过--env OPENAIKEY=...注入密钥即可，代码会默认使用gpt-3.5-turbo模型（见 LowCodeLLM/src/openAIWrapper.py）。
• 使用Azure OpenAI Service时，信息较多，建议复制 LowCodeLLM/config.template 为config.ini后逐项填写，再以--env-file config.ini传入容器。

config.template的完整字段如下：

以上字段在源码中均有对应读取逻辑：openAIWrapper.py通过os.environ.get("OPENAIKEY")读取密钥，将USE_AZURE字符串按lower() == 'true'转为布尔值，并在 Azure 分支下依次读取API_BASE、API_VERSION、MODEL三个环境变量（见 LowCodeLLM/src/openAIWrapper.py）。注意：USE_AZURE未定义时默认视为False，即默认走 OpenAI 直连模式。

3.4 Docker 镜像与进程管理

查看 LowCodeLLM/Dockerfile 可知镜像基于ubuntu:22.04，安装python3.11、pip、supervisor，安装 LowCodeLLM/src/requirements.txt 中的依赖，并将src目录拷贝到/app/src作为工作目录。容器启动命令为supervisord -c supervisord.conf，由 LowCodeLLM/src/supervisord.conf 统一托管进程——其核心配置为：

[program:flask] command=gunicorn --timeout 300 --bind "0.0.0.0:8888" "app:app" --log-level debug --capture-output --worker-class gevent

即通过 gunicorn（gevent worker、超时 300 秒）将 Flask 应用绑定到0.0.0.0:8888，并开启autorestart=true自动重启。依赖版本在requirements.txt中锁定为Flask==2.2.5、Flask_Cors==3.0.10、openai==0.27.2、gunicorn==20.1.0、gevent==21.8.0。

四、后端 API 设计与调用链剖析

后端是一个轻量 Flask 服务（LowCodeLLM/src/app.py），全局实例化llm = lowCodeLLM()后暴露三个 JSON 接口，均启用@cross_origin()支持跨域，便于前端页面直接调用。

4.1POST /api/get_workflow—— 生成初始工作流

• 请求体：{"task_prompt": "任务描述"}
• 调用链：app.get_workflow → llm.get_workflow(task_prompt) → PLLM.get_workflow(task_prompt)
• 响应：一个 JSON 数组格式的工作流（失败时返回{"errmsg": "internal errors"}与 500 状态码）。

4.2POST /api/extend_workflow—— 为指定步骤生成子工作流

• 请求体：{"task_prompt": ..., "current_workflow": ..., "step": "STEP n"}
• 调用链：app.extend_workflow → llm.extend_workflow(task_prompt, current_workflow, step) → PLLM.extend_workflow(...)
• 后端会先把当前工作流 JSON 转成文本（_json2txt），连同"需要扩展的步骤"一起送入规划 LLM，返回的子工作流同样为 JSON 数组。

4.3POST /api/execute—— 按确认工作流对话执行

• 请求体：{"task_prompt": ..., "confirmed_workflow": ..., "curr_input": ..., "history": [...]}
• 调用链：app.execute → llm.execute(task_prompt, confirmed_workflow, history, curr_input) → ELLM.execute(curr_input, history)
• 后端将task_prompt与confirmed_workflow组装为 system 消息（"The overall task you are facing is: ... / The standard operating procedure(SOP) is: ..."），再拼上对话历史与当前输入后送入执行 LLM（见 LowCodeLLM/src/lowCodeLLM.py）。

五、六种预定义低代码操作

README 强调所有工作流编辑操作都"由点击、拖拽或文本编辑支持"。仓库提供的示意图（图源 assets/low-code-operation.png）展示了六种操作：

结合前端源码 LowCodeLLM/src/index.html，从源码结构看，这六种操作由节点右键菜单（contextMenu）与连线右键菜单（edgeMenu）触发，分别对应：

同时，画布本身配置了drag-canvas、zoom-canvas、drag-node三种交互模式（LowCodeLLM/src/index.html），并使用dagre分层布局渲染工作流，从而真正实现了"点击、拖拽、文本编辑"三种低代码编辑能力。

5.1 工作流 JSON 数据模型

所有操作最终都在编辑一个 JSON 数组格式的工作流，每个步骤（step）包含四个字段（测试用例中可见完整示例，如 LowCodeLLM/src/test/testcases/execute_test_cases.json）：

{ "stepId": "STEP 1", "stepName": "Research", "stepDescription": "Gather statistics and information about drunk driving issue", "jumpLogic": [], "extension": [] }

• stepId：步骤编号，如STEP 1、STEP 2.1（子步骤）；
• stepName：步骤名称；
• stepDescription：步骤描述；
• jumpLogic：判断逻辑数组，每项形如{"Condition": "if 'lack of information'", "Target": "STEP 1"}，表示"当条件满足时跳转到目标步骤"；
• extension：该步骤的子工作流数组（扩展操作的结果会写入这里，并在前端展开为图中的多个节点）。

一个带跳转逻辑的完整示例（摘自 LowCodeLLM/src/test/testcases/execute_test_cases.json）：

{ "stepId": "STEP 4", "stepName": "Develop a prevention plan", "stepDescription": "Create a plan to prevent drunk driving", "jumpLogic": [ {"Condition": "if 'lack of information'", "Target": "STEP 1"}, {"Condition": "if 'unclear causes'", "Target": "STEP 2"}, {"Condition": "if 'incomplete analysis'", "Target": "STEP 2"}, {"Condition": "if 'unrealistic plan'", "Target": "STEP 4"} ], "extension": [] }

5.2 扩展操作的前端联动逻辑

extend分支（LowCodeLLM/src/index.html）展示了完整的扩展流程：前端将task_prompt、当前工作流（G6ToData()序列化）与目标步骤 ID 打包 POST 到/api/extend_workflow，拿到子工作流后，把原步骤替换为扩展出的若干子步骤，同时将原步骤的jumpLogic迁移到扩展列表末尾，并同步修正后续所有步骤的STEP编号与跳转目标编号，最后通过graph.read()重绘整个画布。这一步实现了"一键把粗糙步骤细化成子 SOP"的低代码能力。

六、工作流文本格式与底层解析原理

工作流在 LLM 与后端之间以文本形式传输，格式为：

STEP 1: [step name][step descriptions][[[if 'condition1'][Jump to STEP]], [[if 'condition2'][Jump to STEP]], ...]

规划 LLM 的 system 提示词（LowCodeLLM/src/planningLLM.py）严格要求其只输出上述格式的 SOP 文本、不得输出任何其他文字，并在后缀中再次强调格式纪律（NEVER reply any word other than the standard operating procedure）。解析方向有两个：

• 文本 → JSON：planningLLM._txt2json（LowCodeLLM/src/planningLLM.py）按STEP行切分，用正则匹配方括号提取stepId / stepName / stepDescription，再解析jumpLogic（从[[[if 'condition'][Jump to STEP]]]中提取Condition与Target）；若跳转字段不含字母则视为无跳转逻辑。解析失败时会打印Format error, please try again.并返回None。
• JSON → 文本：lowCodeLLM._json2txt（LowCodeLLM/src/lowCodeLLM.py）将 JSON 步骤逐一还原为stepId: [stepName][stepDescription][...jumpLogic...]文本，并递归展开extension子步骤，供执行 LLM 阅读。

执行 LLM 侧（LowCodeLLM/src/executingLLM.py）的提示词要求其严格遵循 SOP作答，同时提醒它：对面是不知道 SOP 存在的真实人类，因此不要把正在遵循的步骤展示给用户，只需直接给出答案。

七、参数调优与测试验证

7.1 温度参数

lowCodeLLM.__init__提供了两个可调参数（LowCodeLLM/src/lowCodeLLM.py）：

• PLLM_temperature=0.4：规划 LLM 的采样温度，适中的温度让拆解出的 SOP 既有稳定性又有一定灵活性；
• ELLM_temperature=0：执行 LLM 的温度设为 0，保证在固定 SOP 约束下输出确定性最强、最可复现的响应。

调用方可根据需要覆盖默认值，例如测试脚本中统一使用lowCodeLLM(0.5, 0)。

7.2 自带测试

仓库提供了三个最小测试脚本及其用例，可在设置好OPENAIKEY环境变量后直接运行：

• LowCodeLLM/src/test/test_get_workflow.py：对Write an essay about drunk driving issue.、Write an bolg about Microsoft.、I want to write a two-player battle game.三个任务调用get_workflow，断言返回结果至少包含一个步骤（用例见 LowCodeLLM/src/test/testcases/get_workflow_test_cases.json）；
• LowCodeLLM/src/test/test_extend_workflow.py：对确认后的工作流调用extend_workflow展开指定步骤（用例见 LowCodeLLM/src/test/testcases/extend_workflow_test_cases.json），同样断言返回至少一个子步骤；
• LowCodeLLM/src/test/test_execute.py：携带工作流与对话历史调用execute，断言返回非空字符串（用例见 LowCodeLLM/src/test/testcases/execute_test_cases.json）。

三个脚本均在用例之间time.sleep(5)以规避限流，展示了该框架"规划 → 扩展 → 执行"三条核心调用链的最小验证方式。

八、设计优势

README 总结了 Low-code LLM 框架的三大优势：

1. 可控生成（Controllable Generation）：复杂任务被分解为结构化执行计划并以工作流形式呈现给用户；用户通过低代码操作控制 LLM 的执行，从而获得更符合需求的响应——按定制工作流生成的回答与用户要求的对齐度更高。
2. 友好交互（Friendly Interaction）：直观的工作流让用户快速理解 LLM 的执行逻辑；基于图形化界面的低代码操作让用户以友好的方式便捷地修改工作流。这一机制缓解了耗时费力的 prompt engineering（提示词工程），让用户能高效地把想法转化为详细指令，获得高质量结果。
3. 广泛适用性（Wide applicability）：该框架可应用于各领域的大量复杂任务，尤其适合需要人类智慧或偏好的场景。

九、延伸与致谢

Low-code 人机交互模式是 TaskMatrix 愿景的一部分：未来 TaskMatrix.AI 将更有效地拆解任务，并利用既有基础模型及其他 AI 模型/系统的 API，在数字与物理领域完成多样化任务的自动化，而 low-code 模式将在其中增强用户对过程与偏好的控制。

值得一提的是，README 的 Acknowledgement 披露了一个有趣的细节：本论文（指 Low-code LLM 相关工作）的部分内容本身就是通过与所提出的 Low-code LLM 交互协作完成的——GPT-4 先勾勒框架，作者补充创新想法并优化工作流结构，最终由 GPT-4 生成连贯且富有说服力的文本。这恰好是该框架"人类在环、可控生成"理念的一次自我印证。

如需继续深入，建议按顺序阅读：核心聚合类 LowCodeLLM/src/lowCodeLLM.py、规划模块 LowCodeLLM/src/planningLLM.py、执行模块 LowCodeLLM/src/executingLLM.py、API 封装 LowCodeLLM/src/openAIWrapper.py、Web 服务 LowCodeLLM/src/app.py 以及前端画布 LowCodeLLM/src/index.html。