# LLM agent - platform (low code AI)
* ETL工具
* ETL 工具是一種資料整合軟體，能從不同資料來源提取（Extract）、進行轉換（Transform）和載入（Load）資料，以供資料倉儲、資料湖或其他系統進行分析。
* 基本上 ETL 和 automation 密不可分，但不完全一樣，ETL 通常會考慮更多資料版本，不可變性...的問題。
* only self-hostable can put following
其他標準
1. 專案
* 要能 git **version control**
* 單次性的垃圾可能不用。
* git verison 對工程是必要的，放棄 low code 都可以。
* 任何 low code 的專案檔幾乎無法避免是客製化的 json。而且常常包含 history or coordinate 這種沒用的東西。很難說是可git，甚至不如svg。
2. 可以 visual 顯示 graph
3. support webhook endpoint(receive) and sender.
* 難的可能不是coding。嫁接其他服務(receive)，尤其是有 token 的麻煩很多。
* plugin
* 如何加功能。
* 能否加入 MCP 功能
overview ref
* [ Day14 - LLMOps Pipeline 自動化實戰：用 Prefect 與 Dagster，拯救你的睡眠時間 ](https://ithelp.ithome.com.tw/articles/10389635)
license 的建議是，有很多奇怪切分的都別用，尤其是把功能切好幾塊，分開 license 的。
可接受的就是全部AGPL，有EE 版的。
## without AI
Non-AI
| name | license | star | version | visual graph | free-cloud-quota |
|:------------ |:--------------------------- |:----- |:------- |:------------ |:----------------:|
| Huginn | MIT | 47.5k | | | |
| automatisch | CE AGPL, has EE comml (v) | 13.2k | | | |
| activepieces | MIT core, EE feat comml (x) | 18.3k | | | |
| Temporal | MIT | 15.9k | v | | |
| windmill | CE agpl, EE comml | 14.7k | v | v | |
| airfow | apache | 42.6k | v | v | |
| Prefect | CE apache, has EE | 20.5k | v | p | |
| dagster | apache | 14.1k | v | v | |
| trigger.dev | apache | 12.5k | v | | |
| zenML | CE apache, has EE | 4.9k | v | | |
| zapier | | | | | |
| | | | | | |
* **Temporal**
* > Temporal microservices orchestration engine
* 更偏 underline tool 而非 automation framework。
* [工作流引擎Temporal学习笔记](https://code2life.top/blog/0070-temporal-notes)
* 主要寫code
* focus 在比較精細的 流程，e.g. 失敗怎麼辦。
* 有 git version control
* no visual editor, only some visual display, and no graph view
* [ Temporalio.Graphs ](https://github.com/oleg-shilo/Temporalio.Graphs)
* 因為 temporal 是 FSM 而非 DAG。
* better performance, reliability than airflow
* `dapr` micro service farmework
* weebhook 功能也弱
* [Is that possible to send signal to a temporal workflow through REST api? ](https://community.temporal.io/t/is-that-possible-to-send-signal-to-a-temporal-workflow-through-rest-api/7953/1)
* 自己弄 http server
* [Build a Choose Your Own Adventure Bot in TypeScript](https://learn.temporal.io/tutorials/typescript/build-choose-your-own-adventure-bot/#servers)
* 確實是獨立 server。
* **airflow**
* much larger community than other solution
* edit DAGs directly within the Airflow UI
* git version control
* 其實沒什麼 webhook 功能，需要手動建立 http post point。
* **Prefect**
* 有 [webhook](https://docs.prefect.io/v3/concepts/webhooks) 等待call
* 有 git versioning, [How to version deployments](https://docs.prefect.io/v3/how-to-guides/deployments/versioning)
* [ Day14 - LLMOps Pipeline 自動化實戰：用 Prefect 與 Dagster，拯救你的睡眠時間 ](https://ithelp.ithome.com.tw/articles/10389635)
* 其實file watch 還是額外一個 process
* 會有不少人噴他的 資料功能不夠 嚴謹，但如果從 automation 的角度了話，缺點沒那麼重。
* 實際上雲端提供的服務是 prefect-cloud，和 opensource 的 prefect 有差。
* default 是用 distributed execution。老實說，我覺得對 automation 來說已經太複雜，尤其對於 deploy 時的 storage 來說，很難想像被稱為簡單。so does state management.
* distributed is good for good scalibility
* 其實使用時再強制要求 local only 也應該可以。
* <-- choice (1st)
* [**dagster**](https://github.com/dagster-io/dagster)
* <-- choice (2nd)
* 會不會比 prefect 難太多？主要是 coding per task 時, decorator 填不少東西。
* [dagster-project-example](https://github.com/AntonFriberg/dagster-project-example/tree/main)
* 其實有分 op 和 assets，只用 op 就和 prefect(@task) 比較像
* webhook 功能好像很弱。用 endpoint sensor
* [Add “trigger”-like abstraction to support push-style launches from external events #8096](https://github.com/dagster-io/dagster/issues/8096)
* 基本上現在也是要自己 create server，call [External assets REST API reference](https://docs.dagster.io/api/rest-apis/external-assets-rest-api) 轉到 dagster server 下。
* [ End-to-end Dagster Data Platform Speedrun ](https://www.youtube.com/watch?v=NaaF7sw1W_8)
* default 是用 centalized, local execution (compare to prefect). optional distributed execution
* dagster self-host 好像複雜很多，需要不少 container 設定。
* Huginn
* [使用Huginn打造自动化信息处理中心](https://github.com/huginn/huginn?tab=readme-ov-file)
* 感覺有點為了low code 反而怪怪的。
* automatisch
* Open source Zapier alternative
* no version control
* zapier
* [Zapier是什麼？怎麼設定？5步驟學會超實用自動化工具！](https://welly.tw/blog/what-is-zapier)
* 都是 event 加工具(action, workflow)，但我也希望純 event 轉接
* windmill
* CE 的限制太多，基本是塗滿劇毒，give up
* [windmill pricing](https://www.windmill.dev/pricing)
* 蠻可惜的，對 end user 難度可能是最低的。
* 有 git version control
* IFTTT
* proprietory
* trigger.dev
* We built a developer-first open-source Zapier alternative (trigger.dev)
* 我覺得和 preset 的定位更接近，更接近 automation tool，webhook 功能強。
* 甚至 buildin MCP，比 prefect 更接近 automation tool。(prefect 可靠 langgraph)
* node-red
* 單純 flow based programming
* build in git version control
* **zenML**
* <-- choice
* [zenML overview](/BBo3O_otRBiJ3eI3p8V_kw)
* self script
* 這些工具有的太複雜，有的為了次要功能捨棄關鍵功能，有的有 license 問題。以前直接寫一些簡單腳本有這麼複雜嗎？
* 而且有 LLM coding，low code 工具意義大幅衰減。
* string.com, pipedream.com, [pipedream github](https://github.com/PipedreamHQ/pipedream?tab=readme-ov-file)
## with AI feat
AI
| name | license | star | version | free-cloud-quota |
|:------------ |:---------------------- |:----- |:------- |:----------------:|
| n8n | limited opensource (x) | 144k | o | |
| dify | limited opensource (x) | 116k | v | |
| langflow | MIT | 126k | x | |
| flowise | comml core | 44k | | |
| coze | MIT(fear limited) | 17.3k | | |
| bisheng | apache | 9.7k | | |
| Activepieces | CE MIT, has EE | 18.4 | | |
| pipedream | comml OSS | | | |
| | | | | |
| | | | | |
* n8n
* 唯一有 完整 [version control](https://docs.n8n.io/source-control-environments/)
* [n8n 收費方式巨變， 國外鄉民無法接受 n8n 這個 ...](https://www.facebook.com/groups/gaitech/posts/1455860478931496/)
* n8n 沒有辦法 keep promise，只能建議別用。
* coze
* [Coze与Dify深度对比与实践体验](https://www.bilibili.com/video/BV1ofhEzCEZ2?spm_id_from=333.788.recommend_more_video.-1&vd_source=114036022665e0ff42175121fa14c5de)
* query db 的功能很重要。基本能替代不少內部 app 的使用。
* 劃分 workflow 和 agent。
* dify
* [Version Control](https://docs.dify.ai/en/guides/management/version-control)
* half functioning. build in version control but that is not git.
* **langflow**
* 甚至更接近 framework 而非 platform 一點。
* 基本是 langChain (langGraph)套殼，其實大部份的這些platform 都是。
* [langflow搭建个人知识库](https://www.bilibili.com/video/BV18WuWz4EZS/?spm_id_from=333.337.search-card.all.click&vd_source=114036022665e0ff42175121fa14c5de)
* [零代码打造RAG知识库和AI智能体！LangFlow轻松创建ChatGPT级应用，ollama也支持！轻松拖拽搭建RAG系统，效率提升百倍 #LangFlow](https://www.bilibili.com/video/BV1Kb42177Kq/?spm_id_from=333.337.search-card.all.click&vd_source=114036022665e0ff42175121fa14c5de)
* version control is problem
* [No Flow with Langflow: The Hidden Cost of No-Code AI Tools](https://medium.com/@LeoNguyenAI/no-flow-with-langflow-the-hidden-cost-of-no-code-ai-tools-2b9ef570fac2)
* Activepieces
* 要確認 CE 和 EE 的差距。
* [Editions](https://www.activepieces.com/docs/about/editions)
* 砍在 git version 上，直接沒用。
## if designing automation tool
* pure code
* 本質就是 flow based programming 而已
* 要求 pure function 就能做到
* visual display only (no edit, or minor target)
* visual 可以用不同方法做到
* json graph 當然不是我們要的
* **framework based** task 比較簡單，有點要求rewrite everything。雖然簡單的 decorator(wrapper) 可以搞定。
* support 不同語言就是做n套 decorator 而已。
* comment 加 custom parser
* 難度最高。
* 再來如果要額外資訊 e.g. icon/tag for display，只能用 comment 加，並且要額外的 parser。最重要的是要求user 學習，很難成功。
* 如果我把 prefect 的用法是 reuse define，但直接額外寫執行器 其實就很接近。
## discussion
客製化的 json is bad for version control，是不是還不如直接 source code?
* [Langgraph Visualization with get_graph](https://medium.com/@josephamyexson/langgraph-visualization-with-get-graph-ffa45366d6cb)
* [langgraph create branch](https://langchain-ai.github.io/langgraph/how-tos/graph-api/#create-a-sequence-of-steps)
* 但還是要有一些 tool，e.g. gui to trigger work...
或是雖然用這些 platform，但主要是用它的API/lib
* [告别手动操作：Langflow定时任务全攻略，3步实现智能流程自动化](https://blog.csdn.net/gitblog_00756/article/details/151085234)
* 不知道要寫在哪裡。
* [[Feature Request] Scheduled Trigger/cron-like component to run a flow repeatedly #5541](https://github.com/langflow-ai/langflow/issues/5541)
* [Agent-Driven Schedule](https://medium.com/logspace/build-a-calendar-agent-with-composio-and-crewai-in-langflow-bc8a3244eea3)
* 用 google calender + Composio 繞一大圈
automation platform 的本質? 如何構成？
從最早的 crontab 開始，一直就是 event 和 task（flow） 切分。
現在 web的環境，每個 task 可以生成 webhook 準備被 trigger。event source 則可以從多個網路來源。
我們自己如果要做 automation platform，最好也像這樣 platform 切分 event service 和 task service。task service 管理taskflow，生成 webhook...，是主要的核心。event service 則可以產生一些內部的 webhook call e.g. 週期性。
這裡有個問題，webhook url 一定希望是 public URL。但這對一般user 很困難，尤其是在層層內網裡面。所以這裡需要一個轉接平台，只能 ngrok。DDNS 蠻勉強的，內網一樣不適用。[cloudflare tunnel 更好](https://medium.com/@zetavg/%E4%BD%BF%E7%94%A8-cloudflare-tunnel-%E4%BD%9C%E7%82%BA%E4%BD%8E%E6%88%90%E6%9C%AC%E7%9A%84-ngrok-%E6%9B%BF%E4%BB%A3%E5%93%81-6b0aaef97557)
http 轉發？ queuing?
webhook 轉 RSS 之類的可能有用，RSS 就是用 polling 達成的通知。但webhook原格式還是要事後unpacking，e.g. `fetchRSS`。[ Facebook Posts to Discord Channel ](https://www.reddit.com/r/ifttt/comments/dd2x99/comment/f2ekcmj/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)。
再來是webhook 希望 http 快速response。所以用Kong api + rabbitMQ 之類 做 queuing + 轉接?
這有一個基本假設，就是 所有的 webhook 都只需要 return 200。
或是把discord 之類的平台直接當webhook 的接收點，再去query。這有一個額外的好處，很多平台內建的output to webhook 其實都只支援特定的大平台，而不支援第三方(ourself) 客製化的webhook 服務。背靠discord，可以簡化架接API的部份。代價是 event 並非直接trigger ，而是需要一個分配器去對應or matching 要用到的task。
其實discord support N個webhook，所以也能解決。
但像 facebook 的 webhhook 就是直接定 facebook 想怎麼丟。developer 的 server 自己想辦法去接。也沒有對接到discord，基本就是完全不管。[將YT、IG、FB的新貼文通知自動發到Discord頻道，完全免費](https://ray.lanmootech.com/archives/1190)，其實就是再用現成的自動化平台轉接。
但這樣又把可控性交出去，而且 webhook 如何 packing 原始 webhook 要不確定。
service input/output 的安全性是不對稱的。在discord 裡，to discord webhook 只需要一個get request with token。output 則需要一連串的 discord bot 申請與邀請機制。input 濫用了不起就是亂發消息，output 濫用則用 隱私問題。
再來 webhook 其實沒有標準，本質就是自定義的API，收發雙方要約好，由其是需要在webhook 裡夾帶定製化的 message。一般會是http post，直接把token 放在 post 裡面。但方面一點是把token 寫在 URL，用 get request
auto 平台幫忙寫好是優點，導致無法support 新 API 也是缺點。
總之，trigger webhook 不可能 general ，所以 event trigger 也在 local 端處理比較好。
或是我直接把 code 連同 docker host 到 render.com 之類的地方。就能保證穩定性? 但我其實有點希望能存檔案到 local，一樣用 NAS, NFS, webdav?其實需求不高。
task(workflow, action) 自身怎麼寫就 app 自己決定，甚至全部都 subprocess 也可以。那麼 support 的 功能就完全看task 自己 e.g. 需要引入 AI，就用 langgraph 寫。
---
### visual display/editor
再來low code 是否能有普遍性，為了 low code ，讓 code 限縮在奇怪且不可交換的json 裡是不應該的。
直接開發 python visual editor 才是徹底的解法，而不是疊床架屋 的修補。
### compose micro Service
延續 Infrastructure as Code(IaC) 的精神。
單靠單一的產品確實很難達到完美的效果。與其花大量時間去找到勉強平衡的產品，克服 micro service 部署可能是更上一層的方案。
如果是完整的案場，multi container 更是無可避免。
場景是選用 dagster or temporal 這種沒有內建 endpoint 的 service 時，需要額外的 web server。且 dagster 本身也要 git repo 做版本管控。
應該分開看，dagster 本身的 task 是單獨專案，所以自己就一個 repo 。usually work with git-sync (low code tool).
然後在按照 IaC 的想法，一個案場的組件本來就要 repo 管理。把 webhook endpoint server 想成是設定腳本之類的，而非 dagster 專案的一部份更好。dagster 專案本體只知道有個 sensor point，無 webhook 概念。
當然如果功能已經明確到可以獨立 repo 時，就獨立出去再外接。
在專案配置裡用 env var 配置 dagster git repo 網址 和 token。甚至直接在 dockerfile 裡 clone repo (這一步需要 dagster 有做好)。
我覺得引入專案的步驟暫時還是和 IaC 分開比較好。因為根本無法確定是否有對應的引入機制，而且一定要保有局部更新的能力，否則無法正常開發。
[prefect tutorial](/LjSdyo6gRhS93N18RwIkkg)
### summary
用 dagster, zenML or prefect 當平台。
用 langgraph 做內部功能。
| Criterion | Prefect 2.x | Dagster | ZenML |
| ------------------------------------------------ | ------------------------------------------------------------ | --------------------------------------------------------------- |:--------------------------------------------------------------------- |
| Learning curve | Easiest: Python function = flow; tasks optional | Medium–High: ops/jobs/assets, resources/IO managers | Medium–High: ML‑first concepts (stacks, artifact store, orchestrator) |
| Docker Compose footprint | Light: server + worker (2 containers). SQLite default | Heavier: webserver + daemon + user‑code + DB (Postgres typical) | Server container plus chosen orchestrator (local process is simplest) |
| “One command” up | Yes: docker compose up runs server+worker | Yes, but more services to maintain | Yes: zenml up (Docker) + local orchestrator |
| S3/object storage required | No (mount code, --skip-upload). S3 only if distributing code | No (local FS ok; DB for metadata) | No (local artifact store possible) |
| Fit for “automation with intermediate documents” | Excellent: minimal ceremony, great for scripts/docs | Good but more ceremony aimed at data assets | Possible but overkill for non‑ML automation |
| Maintenance burden | Low | High (more moving parts) | Medium (server + stack config) |
| UI & scheduling | Built‑in UI; schedules via deployments | Rich UI; schedules/sensors via daemon | UI for ML stacks; scheduling depends on orchestrator |
| Code packaging/upload | Optional; can skip and run from bind mount | N/A (your code lives in user‑code container) | Usually local; artifacts stored per configured store |
| Worker/process requirement | Worker needed for server mode (can be same Compose) | Daemon + user‑code gRPC service | Orchestrator handles runs; “local” is simplest |
| DB requirement | None explicitly (SQLite default in server) | Practically Postgres for durability | Server uses DB (SQLite default), local OK |
| Best use case | General automation, scripts, cron‑like flows | Asset‑centric data platforms, lineage, type safety | ML pipelines, experiment tracking, MLOps stacks |
| Simplicity rank (for your constraints) | 1 (simplest) | 3 | 2 |
| LLM/agent integration | Embed LangGraph/LLM calls directly in flows/tasks; simple params, retries, caching | Model LLM outputs as assets with lineage/partitions; validations via resources/IO managers | LLMOps stacks (artifact store, eval, tracing); switch backends (OpenAI/Ollama/HF) easily |
| LLM benefit | Automation tasks (summaries, doc gen, RAG jobs) with minimal ceremony and self-hosted Compose | Reproducible, versioned LLM artifacts (datasets, embeddings, eval reports) with strong governance | Experiments and evaluations at scale (prompt/version tracking, metrics, comparisons) |
#### Verdict
- For self‑hosted, simple docker compose up, automation with documents, and no S3: pick Prefect 2.x.
- Choose Dagster if you specifically want asset lineage and accept more services.
- Choose ZenML if your workflows are ML‑centric and you want MLOps features.
Sign in with Wallet
Connect another wallet