长成什么产品 — 给人用的那一面
这条分支在货架里的位置: 总纲把这一货架的共性讲成一句话——「把一个只会吐文本的 LLM,包成能在循环里感知-动作、能被放心运营的程序」。围绕这条共性分出几条分支:有的分支关心内核(agent 循环怎么转、动作怎么落盘、上下文怎么给),本章是另一头——当这个 agent 要变成一个终端用户真的能碰到的产品时,它长成什么外壳。 别的分支回答「agent 怎么工作」,本章回答「agent 怎么交付给人」。
30 秒导读: 一个能跑的 agent 和一个能给人用的产品之间,隔着一层外壳。同一个「LLM + 工具 + 循环」的内核,可以被包成完全不同的四种东西:①一块拖拽画布,让不写代码的人搭出流程(dify / langflow / flowise / coze-studio);②一个自托管的聊天/助手 app,像 ChatGPT 但装在你自己的服务器上(open-webui / librechat / lobehub…,这是货架里项目最多、star 最高的一片);③一套组件库,让开发者把 agent 的输出渲染进自己的 React 应用(copilotkit / assistant-ui / crayon);④一条实时语音流水线,让人直接和 agent 说话(pipecat / livekit-agents / ten-framework)。本章把这四类横过来切,讲清每类对准哪个交付场景、代表库靠什么机制实现。
怎么读本章: 正文是给人读的白话综述,不出现路径行号。每个论断后面挂一个脚注
[^x],精确的仓库/路径:行+ 符号名都在脚注里;对比矩阵则单开一列「代码锚点」放引用。人读正文,agent 读脚注 / 锚点列。
1. 这条分支要解决什么(第一性原理)
承上:整个货架的共性是「给只会说话的 LLM 装手脚,让它能对世界采取动作」。别的分支盯着内核——循环怎么转、编辑怎么落盘、记忆怎么存。本分支把镜头往外拉一层,问一个产品问题:这个内核最终要怎么摆到终端用户面前?
一个光会「感知-动作」的 agent 还不是产品。产品要有人能碰到的表面:一个网页、一个桌面 app、一块可拖拽的画布、一根能对着说话的麦克风。这层表面既决定「谁能用」(工程师 / 运营 / 普通人),也决定「怎么用」(编排 / 对话 / 嵌入 / 语音)。
把这层表面拆开,它其实在解四个彼此独立的产品问题:
| 产品问题 | 白话 | 对应外壳 |
|---|---|---|
| 让不写代码的人也能编排 agent | 把「提示→检索→调工具→分支」画成图 | 可视化 workflow 平台 |
| 给个人 / 团队一个能自托管的对话入口 | 像 ChatGPT,但模型、数据、插件都在自己手里 | 自托管聊天 / 助手 app |
| 让开发者把 agent 塞进自己的前端 | 别重造聊天框,直接 npm install 一套组件 | agent 前端组件库 |
| 让人用「说话」而不是「打字」和 agent 交互 | 麦克风进、喇叭出,还得能被打断 | 实时语音对话流水线 |
一句话直觉: 内核只有一个(LLM + 工具 + 循环),但交付形态分成四种独立的产品选择——按谁来用、怎么用来分。选错外壳,再好的内核也到不了用户手里。本章 §2–§5 一层一个流派,§6 用一张矩阵横切,§7 讲怎么选。
四类的受众正好错开:workflow 平台面向搭流程的非工程师;聊天 app 面向要私有部署的个人/团队;组件库面向做前端的工程师;语音流水线面向要「能说话」体验的产品。记住这条「受众轴」,四类的取舍就都顺了。
2. 流派一:拖拽搭流程的可视化平台(workflow-builder)
对准哪个环节: 让不写代码的人,把「取输入 → 检索 → 调模型 → 调工具 → 按条件分支 → 出输出」这套流程,用拖节点连线的方式搭出来,再一键部署成 API 或 app。核心是一个节点图引擎:前端画布产出一份图的 JSON,后端把它编译成可执行的图并按拓扑跑。
这一派内部的关键区别,在「图 JSON 怎么变成能跑的东西」上分两路:
(a) 自研图引擎、逐节点解释执行。 后端有一套自己的图运行时,按入度/拓扑排队节点、在节点间传变量。
- dify 是这一派体量最大的代表:workflow 编排是一等公民,
WorkflowEntry把画布 schema 交给一个图引擎驱动,节点由一个DifyNodeFactory按类型实例化。1 它同时是货架里 star 最高的 workflow 平台之一。 - coze-studio(字节跳动)把画布 JSON 先翻成内部
WorkflowSchema,再编译成底层 eino 图;每个节 点套一层统一执行壳做超时/重试/错误分支,约 50 种节点类型登记在一张NodeTypeMetas表里。2 它比 dify 更「编译派」——不是解释执行,而是先编译成图再跑。 - langflow 用一张
Graph抽象:顶点(Vertex)+ 边,astep按可运行顶点逐步推进,支持环、子图隔离。3
(b) 节点即代码模块、动态加载执行。 每个节点对应一个组件文件,运行时按画布里的节点名把对应模块 import 进来调用。
- flowise 走这条:
buildAgentflow遍历画布节点,executeNode按节点的filePath动态import组件模块再执行;它自带一个几十类的节点组件目录(memory / LLM / tool / agent…)。4 好处是「加一个节点 = 加一个文件」,生态扩展极快。
长尾同派: bisheng(企业 LLMOps,workflow/graph/graph_engine)、fastgpt(知识库 + 可视化编排)、sim / pyspur / rivet(可视化 agent 图 IDE)、activepieces(~400 个 MCP/连接器的自动化平台)、botpress(对话流可视化)、kestra(声明式 YAML 编排,偏数据工程但支持 AI/RAG 步骤)——都落在「画布产 JSON → 引擎跑图」这个格子里,只在「引擎自研 vs 节点即代码」「面向 AI 应用 vs 面向自动化/数据」上分 。
一句话取舍: workflow 平台把「编排逻辑」从代码变成了数据(图 JSON)——这让非工程师能改流程,代价是遇到图表达不了的逻辑就得写自定义节点/代码块逃生。dify/coze 偏「编译成内部图跑」,flowise 偏「节点即可加载模块」,选型时先看你要不要自己写节点。
3. 流派二:自托管聊天/助手 app(chat-agents · 货架里最大的一片)
对准哪个环节: 给个人或团队一个能自己部署的对话入口——外表像 ChatGPT,但模型 provider、聊天记录、RAG 文档、插件/工具全在自己手里。这是货架里项目最多、star 最高的一片(open-webui、dify 门口那批都在十万 star 量级)。
它们看着都是「一个聊天框」,但内部按入口形态分三支:
3.1 Web 自托管平台(浏览器打开,多用户)
一个 Web 服务:后端接多家模型 provider、管会话、挂 RAG / 工具 / MCP,前端是一个聊天 UI。
- open-webui 是货架里 star 最高的自托管聊天 UI:后端一条
process_chat_payload→process_chat_response的中间件管线,把工具调用(chat_completion_tools_handler)、RAG、模型路由都串进这条 pipe。5 - librechat 走多 provider + agents:
api/server/controllers/agents/一套 agent client / request / responses 控制器,支持 MCP、code interpreter、artifacts、多用户鉴权。6 - lobehub(原 LobeChat)、onyx(原 Danswer,企业 RAG chat)、anything-llm、chat-ui(SvelteKit,驱动 HuggingChat)——同派,区别在「偏个人多模型」还是「偏企业 RAG/连接器」。
3.2 桌面客户端(装在本机,常接本地模型)
一个跨平台桌面 app,重点是「本地优先」——常直接接 Ollama / 本地 LLM,聊天记录不出本机。
- cherry-studio / chatbox / jan / gpt4all / big-agi / deepchat 都属此支:桌面壳(多为 Electron / Tauri)+ 多 provider + MCP/插件,jan 与 gpt4all 更强调离线跑本地模型。区别主要在「桌面框架 + 本地模型支持度」,内核仍是「多 provider 聊天 + 工具」。
3.3 IM 平台机器人(把 agent 接进现有聊天软件)
不做新 UI,而是把 agent 接进用户已经在用的 IM(QQ / 微信 / Discord / Slack / Telegram…)。核心是一层平台适配器把各家消息协议归一,再过一条处理管线。
- langbot 是代表:
pkg/platform/sources/下一堆平台适配器(discord / lark / dingtalk / aiocqhttp…),消息进来过一条可注册的PipelineStage管线(预处理 → 内容过滤 → 调 LLM 的Processor→ 回复)。7 - astrbot / openclaw / qwenpaw 同派:多 IM 渠道路由到 per-agent 的处理逻辑,openclaw 尤其把「多渠道 → 每 agent workspace」做成主打;chatwoot 则是客服台形态(omni-channel + captain 助手)。
特例: eliza 是「社交/角色 agent 框架」而非纯聊天 app(character agents + 插件 + 多 agent swarm);nanobot-obot 是「Go 写的 MCP 聊天 agent 框架」——两者更偏「搭 chat agent 的框架」,但仍归在这片,因为终端产物是一个会聊天的 bot。
一句话取舍: 这三支的差别全在入口——浏览器(多用户/团队)、桌面(本地/隐私)、IM(接进现有社交)。内核高度同质:多 provider 路由 + 会话管理 + 工具/RAG/MCP。选型先问「用户从哪进来」,再看本地模型/多用户/渠道数这些细节。
4. 流派三:给 agent 做前端的组件库(agent-ui)
对准哪个环节: 前三派都交付一个完整 app;这一派只交付一段前端——让开发者别再手搓聊天框,直接 npm install 一套 React 组件/hook,把 agent 的流式回复、工具调用、乃至「agent 动态生成的 UI」渲染进自己已有的应用里。
它们内部按给你什么抽象分两路:
(a) 组件 + 运行时(把聊天/agent 循环封装成 hook)。 给你现成的 Thread / Message / Composer 组件,外加一个前端 agent 循环,你只管接数据源。
- assistant-ui:一套可组合的 UI primitives(Thread / Message / Composer),配一个本地 thread 运行时——
do…while循环靠shouldContinue决定要不要因工具调用再转一圈,还内建了工具审批门(有审批配置就阻塞到批准)。8 - copilotkit:前端 agent 栈,核心是一个 facade(
core.ts)+ 工具执行循环(run-handler.ts里runAgent/ 处理工具结果 / 触发 re-run);它也是 AG-UI 协议的作者——把「agent↔前端」的事件流标准化。9 - tambo / tanstack-ai 同路:tambo 是 React 的 generative-UI SDK(渲染 agent 驱动的组件/工具调用/流式);tanstack-ai 是类型安全、provider 无关的 TS AI SDK(跨 React/Vue/Svelte/Solid 的流式聊天+工具)。
(b) 生成式 UI 语言(agent 直接「说」出界面)。 不止渲染消息,而是让 agent 输出一段能被解析成组件树的标记,前端流式解析并渲染成真实 UI。
- crayon(Thesys)最典型:一套框架无关的 lang-core——流式
parser边收 token 边解析(对半截输入 autoClose)、library.ts用 Zod introspection 从组件定义生成给模型的 system prompt、evaluator把 AST 求值成带响应式$变量绑定的真实组件。10 这是「generative UI」做得最彻底的一个:agent 说的不是文本,是 UI。
特例: open-design-nexu 是「本地优先的桌面设计 agent」(生成 web/mobile 原型、slides、导出),产物偏设计稿而非嵌入式组件,但也归在「给 agent 做前端」这片。
一句话取舍: (a) 派解决「别重造聊天框」,(b) 派解决「让 agent 生成界面本身」。选型看你要渲染对话(assistant-ui / copilotkit)还是要 agent 产出 UI(crayon / tambo)。copilotkit 额外给你一个协议(AG-UI),想跨栈标准化 agent↔前端事件流时值得先看它。
5. 流派四:实时语音对话(voice-realtime)
对准哪个环节: 让人用说话而不是打字和 agent 交互。这一派的外壳不是 UI,而是一条全双工音频流水线:麦克风音频进来,经 VAD(判断有没有人在说)→ STT(转文字)→ LLM(想回复)→ TTS(合成语音)出去,还得处理「用户中途打断(barge-in)」和「什么时候算用户说完了(turn detection)」这两个语音特有的难题。
流水线的四段(VAD/STT/LLM/TTS)各家都有,真正区分它们的是**「怎么把这四段串成低延迟、能被打断的实时环」**:
5.1 帧驱动的处理器流水线(pipecat)
pipecat 把整条链建成一串 FrameProcessor——音频/文本以「帧」在管线里流动。它把语音特有的难题拆成独立处理器:VAD(silero 等)、turn 分析器(smart-turn 端到端模型判断「说完没」)、以及一套 InterruptionFrame / user-turn 控制器做打断。11 好处是「换一个 STT/TTS = 换一个 processor」,几十家 STT/LLM/TTS 服务都做成了可插拔 service。
5.2 会话对象 + 语义轮次检测(livekit-agents)
livekit-agents 以一个 AgentSession 为中心,把 stt / vad / llm / tts 作为构造参数注入;它的招牌是语义 turn detection——不只靠静音判断说完,而是用一个 turn 检测模型 predict_end_of_turn 预测「这句话是不是说完了」,降低抢话。12 底座是 WebRTC,天然适合浏览器/电话实时音频。
5.3 图化的多模态运行时(ten-framework)
ten-framework 把每段能力做成一个 extension(ASR/LLM/TTS/VAD 各一个包),用一张图(property.json 里的 graph)把它们连起来,由一个 C 写的 ten_runtime 调度——主打全双工多模态对话。13 它更像「语音版的 workflow 引擎」:pipeline 本身是可编排的图。
长尾同派:
- vocode-core:模块化 Python 语音 agent 库,覆盖电话/web/Zoom。
- hf-speech-to-speech:纯开源模型拼的本地 VAD/STT/LLM/TTS 链,暴露 OpenAI Realtime 兼容 API。
- unmute:把任意文本 LLM 包进 Kyutai 的低延迟 STT/TTS,走 WebSocket(OpenAI Realtime 风格协议)。
- dograh:自托管语音 AI 平台,可视化 workflow + 电话(Vapi/Retell 的开源替代)——注意它同时踩了「语音」和「workflow 平台」两个流派。
一句话取舍: 四段流水线是共识,分化在编排风格:pipecat = 帧驱动处理器链(最灵活的插拔)、livekit = 会话对象 + 语义轮次(最省抢话)、ten = 可编排的 extension 图(最接近「语音 workflow」)。选型先定要不要 WebRTC/电话、以及turn detection 要不要语义模型。
6. 对比矩阵(逐格接地)
维度:外壳形态(交付成什么)、受众(谁来用)、核心机制(靠什么实现)、扩展点(怎么加东西)。描述列写白话,精确
path:line+符号 全在最右「代码锚点」列。—表示该维度对此库不突出。
| 库 (id) | 外壳形态 | 受众 | 核心机制 | 扩展点 | 代码锚点 |
|---|---|---|---|---|---|
| dify | 可视化 workflow 平台 + RAG + 模型 API | 非工程师 + 团队 | WorkflowEntry 交给图引擎,DifyNodeFactory 按类型建节点 | 自定义节点 / 工具 / 插件 | workflow_entry.py:155/:201/:277 |
| coze-studio | 拖拽 workflow 编辑器(字节) | 非工程师 | 画布 JSON→WorkflowSchema→编译成 eino 图,约 50 种节点 | 节点 adaptor 注册表 | compose/workflow.go;canvas/adaptor/to_schema.go;entity/node_meta.go |
| langflow | 可视化 agent/workflow IDE | 非工程师 + 工程师 | Graph(Vertex+Edge),astep 按可运行顶点推进,支持环/子图 | 组件(component)节点 | graph/graph/base.py:65/:1580 |
| flowise | 拖拽 LLM/agent 构建器 | 非工程师 + 工程师 | buildAgentflow 遍历节点,executeNode 动态 import 组件文件 | 节点即文件(加文件即加节点) | utils/buildAgentflow.ts:1051/:1113 |
| bisheng · fastgpt · sim · pyspur · rivet · activepieces · botpress · kestra | 可视化编排(企业 LLMOps / 知识库 / 自动化 / 数据) | 非工程师 / 运营 | 同派:画布产图 JSON → 引擎跑图 | 节点 / 连接器 / MCP | 见各卡片 entry(如 bisheng workflow/graph/graph_engine.py) |
| open-webui | Web 自托管聊天 UI(star 最高) | 个人 + 团队(多用户) | process_chat_payload→response 中间件管线 + 工具/RAG/路由 | tools / pipelines / functions | utils/middleware.py:2311/:5259/:1246 |
| librechat | 多 provider 自托管 chat + agents | 团队 | agents controller(client/request/responses)+ MCP + 多用户 | MCP / agents / tools | server/controllers/agents/*.js |
| lobehub · onyx · anything-llm · chat-ui | Web 自托管 chat(多 provider / 企业 RAG) | 个人 / 团队 | 多 provider 路由 + 会话 + RAG/插件 | 插件 / 连接器 | 见各卡片 entry(src/ 等) |
| cherry-studio · chatbox · jan · gpt4all · big-agi · deepchat | 桌面客户端(本地优先) | 个人(隐私/离线) | Electron/Tauri 壳 + 多 provider + MCP;jan/gpt4all 强本地模型 | MCP / 插件 / 本地模型 | 见各卡片 entry(如 chatbox src/shared/models/abstract-ai-sdk.ts) |
| langbot | IM 平台机器人 | 社群 / 客服 | 平台适配器归一消息 + 可注册 PipelineStage 管线 | 平台适配器 / 管线阶段 / 插件 | platform/sources/*;pipeline/stage.py:22;process/process.py:11 |
| astrbot · openclaw · qwenpaw · chatwoot · eliza · nanobot-obot | IM bot / 客服台 / 角色 agent 框架 | 社群 / 客服 | 多渠道路由 → per-agent 逻辑;chatwoot 客服台;eliza 角色 agent | 渠道 / 插件 / character | 见各卡片 entry |
| copilotkit | React agent 前端栈 + AG-UI 协议 | 前端工程师 | facade + runAgent 工具循环 + AG-UI 事件流 | React hooks / 前端工具 / 协议 | core/core.ts;core/run-handler.ts:289 |
| assistant-ui | React 聊天/助手组件库 | 前端工程师 | UI primitives + 本地 thread 运行时(shouldContinue 循环 + 工具审批门) | primitives / runtime adapters | runtimes/local/local-thread-runtime-core.ts:44/:360 |
| crayon | 生成式 UI 语言 + React 工具包 | 前端工程师 | 流式 parser + Zod→system prompt(library.ts)+ evaluator 渲染 AST | 组件库(defineComponent) | lang-core/src/parser/parser.ts;library.ts;runtime/evaluator.ts |
| tambo · tanstack-ai · open-design-nexu | 生成式 UI SDK / 类型安全 AI SDK / 桌面设计 agent | 前端工程师 / 设计 | agent 驱动组件渲染;provider 无关流式;设计稿生成 | 组件 / adapter / skill | 见各卡片 entry |
| pipecat | 帧驱动语音流水线(框架) | 语音产品工程师 | FrameProcessor 链 + VAD + smart-turn 说完检测 + InterruptionFrame | 可插拔 service(STT/LLM/TTS) | pipeline/pipeline.py:91;audio/turn/smart_turn/…v2.py:43;frames.py:1018 |
| livekit-agents | WebRTC 语音 agent(框架) | 语音产品工程师 | AgentSession 注入 stt/vad/llm/tts + 语义 predict_end_of_turn | plugins(STT/LLM/TTS/turn-detector) | voice/agent_session.py:209;voice/turn.py:49 |
| ten-framework | 图化全双工多模态运行时 | 语音产品工程师 | extension(ASR/LLM/TTS/VAD)+ property.json graph + C ten_runtime | extension 包 + graph 编排 | core/src/ten_runtime;ai_agents/agents/property.json |
| vocode-core · hf-speech-to-speech · unmute · dograh | 语音库 / 本地 s2s 链 / LLM 语音包装 / 语音平台 | 语音产品工程师 | 模块化 VAD/STT/LLM/TTS;unmute 走 WS OpenAI Realtime;dograh 可视化+电话 | provider / 协议 / 节点 | 见各卡片 entry |
矩阵里反复出现的两个「同派家族」:图引擎家族(dify/coze/langflow/flowise + 一堆长尾,共享「画布产 JSON → 引擎跑图」)和聊天壳家族(open-webui/librechat/lobehub… 共享「多 provider + 会话 + 工具」,只在入口=Web/桌面/IM 上分)。长尾库不必逐一拆解——它们几乎都落进上面某个已接地的格子。
7. 模式与权衡(可带走的领域智慧)
读完矩阵,几条横跨全分支的规律浮出来:
-
外壳决定受众,不决定内核。 四类外壳套的是同一个「LLM + 工具 + 循环」内核。dify 的图节点、open-webui 的中间件、assistant-ui 的 thread 运行时、livekit 的 AgentSession——底下都在做「取上下文 → 调模型/工具 → 处理结果 → 也许再来一轮」。先想清楚交付给谁,再选外壳。
-
「编排逻辑」在两种表示之间摇摆:代码 vs 数据。 workflow 平台把编排变成数据(图 JSON),让非工程师能改,代价是表达力有天花板(遇到怪逻辑要写自定义节点逃生)。组件库/语音框架把编排留在代码里,灵活但要工程师。这是「谁来用」这条轴的直接后果。
-
自托管聊天这片高度同质,靠「入口 + 边角」区分。 十几个 chat app 内核几乎一样(多 provider + 会话 + 工具/RAG/MCP)。真正的选型差别在入口(Web 多用户 / 桌面本地 / IM 渠道)和边角料(本地模型支持、多租户、渠道数)。看内核选不出来,看入口和运维形态就清楚了。
-
前端这一派把「渲染消息」推进到了「生成界面」。 早期组件库只渲染对话气泡;crayon/tambo 这代让 agent 直接产出 UI(一段可解析成组件树的标记)。copilotkit 更进一步,把「agent↔前端」抽成一个协议(AG-UI)——这是从「组件」到「标准」的升级。
-
语音的难点不在四段流水线,在「实时性 + 可打断」。 VAD/STT/LLM/TTS 谁都能拼;真正拉开差距的是 turn detection(livekit 的语义模型 / pipecat 的 smart-turn)和 barge-in(pipecat 的 InterruptionFrame)。把这两件做好,体验才像「对话」而不是「对讲机」。
-
有的产品横跨两个流派。 dograh(语音 + 可视化 workflow)、coze-studio(workflow + 聊天 agent 发布)提醒你:流派是镜头不是围栏——一个成熟产品常同时长出好几种外壳。
8. 演化趋势(这条分支往哪走)
把时间轴拉出来,三条趋势很清楚:
-
从「一个大而全的平台」到「可嵌入的一层」。 早期这片是 all-in-one 平台(dify/open-webui,啥都自己做);近年冒出一整片只交付一层的组件库(copilotkit/assistant-ui/crayon)和 SDK(tanstack-ai)——因为越来越多团队已经有自己的 app,只想把 agent「嵌进去」,不想再要一个新前端。
-
generative UI:agent 从「输出文本」到「输出界面」。 传统聊天 app 渲染 markdown 气泡;新一代(crayon/tambo/copilotkit)让 agent 直接说出一段 UI 描述,前端流式渲染成真实组件。伴随而来的是协议化(copilotkit 的 AG-UI),想把 agent↔前端事件流标准化。
-
语音正在从「拼装」走向「端到端 + 语义」。 turn detection 从纯静音判断(VAD 阈值)升级到端到端说完检 测模型(pipecat smart-turn、livekit 的
predict_end_of_turn);全双工(ten-framework)成为标配追求。语音这一派最能体现「模型变强后,把更多判断还给模型」这条货架级趋势。
三条趋势同源:产品形态在向「更贴合用户已有环境」收敛——嵌进现有 app、生成原生界面、用最自然的语音交互。这也呼应总纲的共性:agent 的价值不只在内核多聪明,更在它能不能以用户碰得到的形态、被放心地交付出去。
9. 代表作 + 深入读哪些
按流派点名代表作,想深入就从这里下钻:
| 想学的东西 | 代表作 | 入口 |
|---|---|---|
| 可视化 workflow 引擎(画布→图→跑) | dify · langflow | 克隆 dify api/core/workflow/;langflow src/lfx/…/graph/ |
| 「编译成内部图」的 workflow(约 50 节点) | coze-studio | 克隆 backend/domain/workflow/internal/compose/ |
| 「节点即可加载文件」的扩展模型 | flowise | 克隆 packages/server/src/utils/buildAgentflow.ts + components/nodes/ |
| Web 自托管聊天(中间件管线 + 工具/RAG) | open-webui | 克隆 backend/open_webui/utils/middleware.py |
| 多 provider + agents + MCP 聊天平台 | librechat | 克隆 api/server/controllers/agents/ |
| IM 平台机器人(适配器 + 管线) | langbot | 克隆 src/langbot/pkg/platform/ + pkg/pipeline/ |
| React 聊天组件 + 前端 agent 循环 | assistant-ui | 克隆 packages/core/src/runtimes/local/ |
| agent 前端协议(AG-UI)+ 工具循环 | copilotkit | 克隆 packages/core/src/core/ |
| generative UI 语言(agent 产出界面) | crayon | 克隆 packages/lang-core/src/parser/ + library.ts |
| 帧驱动语音流水线(可插拔 STT/TTS) | pipecat | 克隆 src/pipecat/pipeline/ + audio/turn/ |
| WebRTC 语音 + 语义 turn detection | livekit-agents | 克隆 livekit/agents/voice/ |
| 图化全双工多模态运行时 | ten-framework | 克隆 core/src/ten_runtime + ai_agents/agents/ |
给入门者的学习路径: 先挑一类贴你受众的外壳看透——想给非工程师搭流程就先读 dify(workflow 引擎最完整),想私有部署对话就读 open-webui(chat app 的模板),想嵌进自己前端就读 assistant-ui / copilotkit,想做语音就读 pipecat(流水线拆得最清楚)。四类各读一个代表作后,你会发现它们套的是同一个内核——回总纲 index.md,再顺着「内核」那几条分支下钻,就能把「agent 怎么工作」和「agent 怎么交付」两头接上。
10. 代码地图(导航索引)
给 agent 的精确入口表(库 / 路径 / 符号),按流派排:
| 主题 | 路径 | 符号 |
|---|---|---|
| workflow 入口 + 节点工厂(dify) | dify/api/core/workflow/workflow_entry.py:155 | WorkflowEntry / DifyNodeFactory |
| 画布→图编译(coze-studio) | coze-studio/backend/domain/workflow/internal/compose/workflow.go | WorkflowSchema→eino 图 |
| 图推进(langflow) | langflow/src/lfx/src/lfx/graph/graph/base.py:1580 | Graph.astep |
| 节点动态加载(flowise) | flowise/packages/server/src/utils/buildAgentflow.ts:1113 | executeNode / import(filePath) |
| 聊天中间件管线(open-webui) | open-webui/backend/open_webui/utils/middleware.py:2311 | process_chat_payload |
| agents 控制器(librechat) | librechat/api/server/controllers/agents/client.js | agents client/request/responses |
| IM 适配器 + 管线(langbot) | langbot/src/langbot/pkg/pipeline/stage.py:22 | PipelineStage / Processor |
| 本地 thread 运行时(assistant-ui) | assistant-ui/packages/core/src/runtimes/local/local-thread-runtime-core.ts:360 | do…while shouldContinue |
| 工具执行循环(copilotkit) | copilotkit/packages/core/src/core/run-handler.ts:289 | runAgent |
| 流式 UI 解析(crayon) | crayon/packages/lang-core/src/parser/parser.ts | streaming parser / autoClose |
| 帧流水线 + 说完检测(pipecat) | pipecat/src/pipecat/audio/turn/smart_turn/local_smart_turn_v2.py:43 | LocalSmartTurnAnalyzerV2 |
| 语音会话 + 语义轮次(livekit) | livekit-agents/livekit-agents/livekit/agents/voice/agent_session.py:209 | AgentSession / predict_end_of_turn |
| extension 图运行时(ten) | ten-framework/core/src/ten_runtime | ten_runtime + property.json graph |