- 博客(236)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 自研工作流、开源引擎二开、商业 BPM，企业应该如何选择？
本文探讨企业工作流建设的三条路线选择：从零自研引擎、基于开源引擎扩展开发（二开）和采购商业BPM平台。核心决策点在于确定流程执行内核、审批产品能力和长期演进责任的承担方。建议大多数企业优先选择开源引擎二开路线，保留内核稳定性的同时在外围构建业务适配层；当交付速度和完整工具链优先于控制权时，可考虑商业BPM；仅当流程语义构成核心竞争力且现有方案无法满足时，才需从零自研。文章详细分析了各方案的技术边界、实施成本和适用场景，强调许可证合规与长期演进能力的重要性，并指出商业BPM的隐性价值在于产品化能力和厂商支持体
2026-08-13 11:00:42
383
原创 为什么开源流程引擎能跑 BPMN，却不能直接成为一套 OA？
开源流程引擎（如Activiti、Flowable、Camunda）虽能解析BPMN并驱动流程执行，但与企业级OA系统仍存在显著能力鸿沟。本文指出流程引擎仅是"执行内核"，完整OA需补足四大核心能力：动态组织找人（多级架构、兼岗代理等）、电子表单与业务事务管理、中国式审批操作（会签/加签/撤回等）、统一协同入口与治理运营。通过分层架构分析，提出企业应复用引擎的标准执行能力，但需自建组织服务、审批领域层和流程适配层，形成"业务主键+领域API+事件驱动"的稳定交互模式，避免业务代码直接操作引擎内部状态。建设路
2026-08-13 09:29:19
220
原创 Flowable 和 Camunda 谁更适合中国式 OA 审批？
如果目标是建设传统中国式 OA 审批平台，并要求私有化部署、Java 深度二开、关系型数据库和可控的引擎扩展，Flowable 通常是更合适的 PoC 起点。它并不直接提供完整的会签、加签、退回和撤回产品，但部署形态与国内 Java 技术栈更贴近，状态变更 API 也较容易被封装成受控的审批操作服务。Camunda 必须拆成 Camunda 7 和 Camunda 8。Camunda 7 技术形态同样适合传统人工作流，但社区版生命周期使其不再适合作为新项目默认底座；Camunda 8 面向分布式流程编排
2026-08-12 10:26:36
316
原创 Flowable 与 Camunda 性能对比：怎样设计一次可信的流程引擎压测？
工作流引擎性能对比方法指南 本文探讨了如何科学比较工作流引擎（如Flowable和Camunda）的性能表现。核心观点包括： 比较前提：单纯问"谁的TPS更高"无意义，必须固定业务语义、事务边界、历史级别等条件，在满足SLO约束下测量可持续吞吐量。 架构差异： Flowable与Camunda 7采用关系型数据库存储状态 Camunda 8采用分布式架构（Gateway+Broker+Worker） 三者部署方式不同导致直接比较困难 科学测试方法： 需要设计多维度工作负载（直通流程、异步服务、人工审批等）
2026-08-12 08:59:04
246
原创 Camunda 7 与 Camunda 8 不是升级关系：架构差异与选型边界
摘要（150字）： Camunda 8是基于Zeebe的分布式流程编排平台，并非Camunda 7的简单升级。两者架构差异显著：Camunda 7以Java嵌入型引擎为核心，依赖共享数据库和本地事务；Camunda 8通过远程Job Worker、分区化Broker和事件流实现分布式执行。迁移需重构代码模型（如JavaDelegate转Job Worker）、调整事务边界（引入幂等性）、转换数据格式（JSON/FEEL替代JUEL），并重建运维体系（分区/副本管理）。历史数据、运行实例及API的迁移需依赖工
2026-08-11 16:48:05
581
原创 从 Activiti 迁移到 Flowable，需要迁移哪些数据库表和流程数据？
从 Activiti 迁移到 Flowable，不能把任务理解为“复制几张 ACT_ 表”。真正的迁移对象是一张有关联的数据图：流程定义、部署资源、执行树、任务、变量、作业、历史、身份、业务单据、表单附件和消息状态共同描述一个流程。迁移前必须先确认 Activiti 来源版本、目标 Flowable 版本、数据库方言、历史级别、定制扩展和运行实例复杂度。不同版本的可行路线差异很大：有的可以使用官方升级脚本，有的应让旧实例自然跑完，还有的必须按平台迁移重新设计。
2026-08-11 16:43:28
329
原创 Activiti 5、6、7 有什么区别？老项目是否值得升级？
Activiti版本升级指南：5、6、7版核心差异与迁移策略 摘要 Activiti版本升级并非简单的线性替代： 内核差异：Activiti 5采用PVM执行模型，6.x重写为BPMN直接执行，7.x在6内核基础上新增Runtime API并扩展云原生架构。 风险维度：5→6需解决PVM移除和作业表拆分问题；6→7侧重API边界与分布式改造，老实例迁移需谨慎评估。 决策建议： 短期系统建议加固隔离而非升级； 核心系统应通过适配层逐步迁移，优先解除对.impl、PVM和直接SQL的依赖； 中国式审批扩展会签
2026-08-10 11:22:39
345
原创 2026 年 Java 开源工作流引擎选型：别只看版本号和社区活跃度
2026年Java开源工作流引擎选型指南：按场景精准匹配技术方案 核心摘要： 工作流引擎需按场景分类选型：BPMN审批流程（Flowable/Activiti）、分布式服务编排（Camunda 8/Conductor）、规则引擎（jBPM）、应用内逻辑链（LiteFlow）四类技术栈差异显著，混评将导致误选。 中国式OA审批推荐Flowable：其多实例会签、动态状态变更等特性为二次开发提供支点，但需自建组织权限和任务门户等上层能力。 存量系统迁移策略：Activiti资产建议评估加固升级，Camunda
2026-08-10 07:09:13
597
原创 Activiti、Flowable、Camunda 为什么同宗同源，却走向了三条道路？
Activiti、Flowable、Camunda 的演进之路：从同源到分道扬镳 Activiti、Flowable、Camunda 均源自2010年的 Activiti 项目，共享 BPMN 2.0 Java 引擎的初始设计，但后续因目标差异分道扬镳。 Activiti：保持轻量级 Java 引擎定位，探索云原生组件（如 Runtime Bundle），适合需要嵌入式引擎且能自建上层平台的企业。 Flowable：由 Activiti 原核心团队主导，扩展为支持 BPMN/CMMN/DMN 的多引擎业务自
2026-08-09 09:17:21
292
原创 开源工作流引擎 Activiti、Flowable、Camunda 到底怎么选？从源码、功能和生态全面对比
流程引擎选型指南：Activiti、Flowable与Camunda 8对比分析 核心结论： Flowable最适合新建Java审批平台，支持深度定制和国产数据库适配 Activiti仅适合已有技术资产的团队维护，不建议新项目采用 Camunda 8适合需要分布式编排和商业支持的企业，但需考虑许可成本 关键差异： 架构路线： Activiti/Flowable采用传统嵌入式Java引擎 Camunda 8基于Zeebe的分布式架构，支持多语言Worker 许可模式： Activiti/Flowable使用
2026-08-09 08:46:18
483
原创 AI Agent 为什么从提示词工程走向上下文工程？原理、核心技术与开源工具指南
AI Agent 正从静态提示词转向动态上下文工程，实现更可靠的智能体行为。提示词工程关注单次指令优化，而上下文工程则动态管理模型推理所需的全部信息（如知识、工具、状态、权限等）。两者核心区别在于：前者设计"怎么问"，后者决定"模型该知道什么、能做什么、必须遵守什么"。 上下文工程通过六个阶段运行：收集候选信息池、筛选当前步骤所需内容、结构化装配、动态推理与工具调用、执行结果写回。这一过程强调信息密度而非数量，并需平衡质量、时效与安全。研究表明，过长上下文会导致性能下降（"上下文腐烂"），因此需要精确控制模
2026-08-07 10:00:56
407
原创 多 Agent（Multi-Agent）是什么？原理、主流框架、适用场景、优劣势与真实案例
多 Agent 系统（MAS）是通过多个专业化智能体协作完成复杂任务的分布式系统，其核心在于任务分解、专业分工和结构化协作。摘要要点如下： 本质特征：MAS不是简单多次调用大模型，而是通过协调器、专业Agent和验证单元的分工协作实现任务闭环，需满足分工必要、交接清晰、结果可验证等条件。 适用场景：适合任务可并行、专业边界明确且上下文隔离的场景（如调研、多领域分析）；对强依赖连续上下文的任务（如连贯创作），单Agent更高效。 协作模式：包括串行流水线、并行扇出、主管-执行者、转接（Handoff）和群组对
2026-08-07 08:11:10
337
原创 Anthropic 与 OpenAI 如何评估 AI Agent？评估体系、行业影响与企业落地指南
AI Agent能否进入企业生产环境，关键取决于三个核心问题：任务准确性、执行可靠性和系统稳定性。Anthropic和OpenAI分别提出评估框架：Anthropic强调评估方法论，将Agent评估分解为任务、轨迹和结果等八个对象，建议组合使用代码、模型和人工三类评分器；OpenAI则侧重工程实践，通过Trace记录执行过程，建立Grader评分机制，形成可复用的Dataset和Eval Run流程。两者共同推动AI Agent从原型演示转向可测试、可审计的质量工程，解决传统评测难以捕捉的中间过程错误和业务
2026-08-06 15:09:23
325
原创 2026 年 AI Agent 有哪些发展趋势？智能体十大技术趋势与企业落地指南
2026年AI Agent发展趋势摘要。 2026年，AI Agent正从通用聊天助手转型为企业级任务执行系统。行业关注点转向长期运行、系统集成与治理能力，形成十大趋势：1）任务专用Agent普及；2）长任务处理能力提升；3）上下文工程取代简单提示词优化；4）MCP/A2A协议推动互操作；5）多Agent专业分工；6）语音与Computer Use扩展交互方式；7）工作流深度整合；8）评测体系标准化；9）安全治理系统化；10）企业流程重构。尽管Gartner数据显示仅17%企业完成部署。
2026-08-06 08:51:57
1082
原创 从大模型到 AI Agent：一文读懂 LLM、RAG、MCP、Skill 与 A2A 的技术原理
AI技术体系全景图：从模型到智能体的系统化架构 摘要：现代AI应用已从单一模型竞争转向系统工程竞争。大语言模型（LLM）作为推理核心，需结合RAG补充知识、Function Call实现工具调用、MCP协议连接资源、Skill封装专业方法、Workflow约束执行路径，才能构建完整的企业级智能体（Agent）。本文构建了六层技术架构：模型层（LLM/VLM/OCR等）提供基础能力，知识层（RAG/向量库）扩展实时信息，协议层（MCP/A2A）实现系统连接，能力层（Skill）沉淀专业知识，智能体层（Agen
2026-08-05 08:03:15
479
原创 AI Agent 为什么落地效果不佳？12-Factor Agents 十二项原则与企业落地指南
AI Agent落地困境与12-Factor Agents解决方案 摘要：当前AI Agent在生产环境中普遍表现不佳，核心问题并非大模型能力不足，而是缺乏完整闭环管理体系。企业常犯六大错误：混淆聊天机器人与Agent概念、过度依赖单一提示词循环、忽视上下文管理、工具调用缺乏工程契约、状态持久化不足、缺少可观测性。12-Factor Agents架构提出关键解决思路：将自然语言转为结构化工具调用、独立管理提示词与上下文、分离推理与执行、建立事件溯源机制、实现人机协同控制。
2026-08-05 07:46:32
453
原创 AI Agent 目前最大的瓶颈是什么？
AI Agent的可靠性瓶颈：从能力到生产落地的关键挑战 当前AI Agent在代码生成、任务分解等复杂任务上展现出惊人能力，但距离生产系统要求仍有本质差距。核心瓶颈并非单一技术指标，而是系统级可靠性——在长链路、重复运行和异常环境下持续产生正确结果的能力。 主要挑战： 多步任务成功率衰减：即使单步正确率达95%，20步后整体成功率仅剩35.8% 上下文噪声累积：长上下文导致信噪比下降，工具调用将语言错误转化为现实副作用 非确定性调试困境：输出受多重因素影响，错误难以复现和追踪 评测体系缺失：现有基准无法评
2026-08-03 15:53:11
750
原创 AI Agent 智能体的运行原理：从一次模型调用到可持续的任务执行
AI Agent（人工智能智能体）是一套以大语言模型为核心，结合状态管理、工具调用和环境反馈的自主决策系统。其核心架构包括任务入口、上下文构建器、大模型、编排器、工具层、记忆层和治理层，通过“观察—思考—行动—更新”循环动态执行任务。与聊天机器人或固定工作流不同，Agent能自主选择工具并迭代优化结果。关键技术包括Tool Calling、ReAct循环、上下文窗口管理和长期记忆系统，工程实现需考虑安全控制、并行执行和成本优化。Agent适用于开放式复杂任务，如调研、编程和故障分析，而预设路径明确的问题更适
2026-08-03 11:07:03
391
原创 Agent 与 Agent 之间的差距很大？到底差在了哪里？
摘要： Agent能力的差距远不止大模型性能的差异，而是综合体现在任务边界定义、上下文管理、工具调用、知识检索、规划方式、状态记忆、评测体系及安全治理等工程化维度。大模型虽决定Agent的理解与推理上限，但实际落地需结合企业知识库、权限控制、流程编排等系统工程能力。主流框架（如LangGraph、AutoGen）正从状态管理、多Agent协作等方向补足工程短板。企业级Agent需满足可追踪、可治理、可集成的核心要求，其价值取决于模型能力与工程约束的协同优化，而非单一技术突破。
2026-08-02 09:24:48
341
原创 最好用的 Agent 框架有哪些？2026 年开源框架选型指南
Agent框架选择需根据任务需求和技术栈决定，主要分为六类：状态图编排（如LangGraph）、多智能体协作（如AutoGen）、RAG数据应用（如LlamaIndex）、类型安全与工程化（如PydanticAI）、轻量实验（如smolagents）及企业语言生态（如SpringAIAlibaba）。生产级应用需关注状态控制、工具调用、RAG集成等能力，而原型开发则侧重快速上手和社区支持。企业选型需结合工程化闭环，如模型路由、权限治理等平台能力，单一框架难以满足全部需求。
2026-07-31 15:48:27
534
原创 如何基于大模型蒸馏出一个小模型？
模型蒸馏是一种利用大模型（老师模型）训练小模型（学生模型）的技术，旨在在特定任务上实现接近大模型的效果，同时降低推理成本、延迟和部署难度。其核心包括明确任务目标、选择合规的老师模型、构造高质量训练数据、严格过滤数据、训练学生模型并进行真实任务评测。企业应用时需注意授权合规性，优先选择高频、稳定的任务场景，并确保蒸馏后的小模型在业务评测中达标。典型案例包括客服工单分类和推理能力迁移。最终目标是实现专用模型的降本增效，而非替代通用大模型。
2026-07-31 07:24:07
491
原创 如何进行模型微调，训练成一个特定领域的模型？
模型微调的本质是在预训练大模型基础上，通过高质量领域数据继续训练，使其适应特定任务需求。它主要解决“模型应该怎么做”的问题，而非单纯记忆知识。企业决策是否微调需考虑：任务是否稳定、数据质量、格式要求、判断标准等因素。典型微调流程包括：明确任务边界、选择基座模型、构建训练数据、选择训练方法、建立评测体系。实践中应避免将微调等同于知识库、使用低质数据、缺乏评测等误区。成功应用需结合RAG、工作流等组件，形成“基座模型+高效微调+知识检索+业务集成”的完整解决方案。
2026-07-30 15:44:43
332
原创 如何从零训练一个自己的大模型？方法论、开源工具与真实案例
从零预训练大模型是一项高门槛的系统工程，需要建立涵盖数据、训练、评测、部署的完整体系。企业应优先考虑开源基座模型+RAG+微调+Agent的实用路径，仅当具备独占高质量数据、明确模型目标、充足算力团队和长期投入决心时，才需启动从零预训练。关键成功要素包括：数据质量决定上限、评测体系前置设计、训练稳定性保障、后训练对齐优化，以及模型服务化治理能力。典型案例表明，模型效果取决于算法框架硬件的协同优化，而非单纯追求参数量级。
2026-07-30 07:37:21
459
原创 多模态 RAG 有哪些应用场景？PDF、图片、表格、OCR 如何进入企业知识库
多模态RAG技术突破传统文本检索局限，针对企业复杂业务场景设计。其核心价值在于：1）支持PDF、图片、表格、图表等多格式文档的联合解析与检索，保留原始结构信息；2）通过跨模态索引实现文本、视觉、元数据的统一检索；3）确保答案可追溯至原始证据（如页码/表格/图片区域）。该技术特别适用于合同审查、财务票据、设备运维等需处理非结构化业务资料的场景，但需注意解析质量、权限控制等实施难点。相比传统RAG仅处理纯文本，多模态RAG真正实现了从业务资料中找证据的企业级知识管理需求。
2026-07-29 16:06:05
372
原创 大模型 RAG 有哪些好用技巧？文档切片、混合检索、Rerank、权限过滤怎么做
实际问题往往出在这些地方：PDF 表格解析错了，Word 标题层级丢了，Markdown 代码块被切断，Excel 表头和数据行分离，图片 OCR 结果没有校验，用户问题里包含编号和专有名词但系统只做向量检索。所有切片都要写入元数据，包括来源、章节、页码、更新时间、密级和权限范围。RAG 做得好不好，关键不在于“有没有向量库”，而在于文档能不能被正确解析，切片是否保留语义结构，检索是否能同时覆盖语义和关键词，Rerank 是否能把真正相关的证据排到前面，以及检索阶段是否按用户权限过滤知识片段。
2026-07-29 09:15:37
660
1
原创 RAG 真的可以规避大模型胡说八道吗？现在有哪些最新技术能替代 RAG
真正可靠的 RAG 不是“向量库 + 大模型”这么简单，而是文档解析、切片、混合检索、重排序、权限过滤、引用校验和答案评测共同组成的一套工程体系。现在所谓“替代 RAG”的新技术，准确说更多是在不同场景下升级、补充或部分替代基础 RAG，包括长上下文模型、GraphRAG、KG-RAG、LightRAG、Agentic RAG、KAG、结构化查询、工具调用和答案验证器。企业做 AI 应用时，通常不是在 RAG 与替代技术之间二选一，而是把它们组合成“可信知识增强生成”体系。
2026-07-28 13:56:30
313
原创 使用大模型服务如何保证数据安全？企业 AI 安全、私有化部署与治理实践
企业使用大模型服务需建立分级安全治理体系，区分数据敏感等级并采取相应保护措施。低敏数据可使用合规公有云API，高敏数据需通过专有云或私有化部署处理，确保数据不出域。风险不仅来自模型训练环节，更存在于Prompt、上下文、工具调用及日志等全链路。企业应实施数据分级、输入脱敏、权限过滤、工具管控和日志审计等策略，并选择适合的部署方式（公有云/专有云/私有化）。核心在于将安全制度融入AI应用全生命周期，通过技术手段和管理规范保障数据隐私与安全。
2026-07-28 07:17:49
662
原创 企业垂直场景如何做大模型选型？企业客户关注国产化、成本和部署
企业垂直场景的大模型选型需综合考虑业务需求、数据安全、国产化要求和成本效益，而非单纯追求模型性能。应基于场景特点（如低敏内容、客户数据或高并发需求）选择部署方式（公有云、专有云或私有化）。主流厂商如DeepSeek、通义千问等已形成模型矩阵，覆盖通用对话、推理、多模态等能力。选型需评估国产化、部署方式、推理能力、RAG支持及运维治理等维度，并通过模型组合与路由机制优化成本。落地步骤包括场景梳理、任务拆分、评测验证和持续监控，最终实现动态选型与降本增效。
2026-07-27 16:15:00
996
原创 企业 AI 应用应该从哪些场景切入？大型研发制造企业从研发到售后的落地路线
大型研发制造类企业做 AI 应用，不应先从“全厂智能化大平台”切入，而应沿着研发、生产制造、质量供应链、销售交付、售后服务这些价值链环节，优先选择高频、知识密集、数据基础较好、结果可验证、风险可人工确认的场景。更具体地说，第一批最适合做的是研发知识助手、工艺与质量知识库、生产异常分析、销售方案生成、售后故障诊断和服务工单辅助。
2026-07-27 10:07:03
435
原创 企业如何利用 AI 大模型提升业务效率？企业 AI 应用应该从哪些场景切入
企业利用 AI 大模型提升效率，不应从“哪里最炫”切入，而应从“高频、文本密集、知识密集、规则清楚、可验证、风险可控”的场景切入。最适合优先落地的方向，通常是知识检索与员工助手、客服与销售支持、文档处理与报告生成、数据分析与报表生成、IT/研发/运维助手，以及带人工确认的流程自动化。Morgan Stanley 用大模型帮助财富管理顾问检索内部知识，Klarna 将 AI 助手用于客服会话处理，制造企业把生成式 AI 用于现场知识查询和问题分析，银行与零售企业把 AI 放进数据分析、运营等
2026-07-26 14:54:42
306
原创 Codex、Claude Code 等 AI 编程工具对软件工程的启发
AI编程工具正在重塑软件工程范式。以Codex、ClaudeCode、GitHub Copilot为代表的AI编程助手正从代码补全工具演变为贯穿需求分析、编码、测试、评审全流程的工程协作者。这一转变要求企业重构研发体系：需求需结构化表达，代码库需清晰上下文，测试需自动化覆盖，评审需聚焦业务逻辑而非语法检查。研究表明，AI编程效能与工程治理强度正相关——模型越强大，越需要完善的文档规范、测试门禁和安全审计机制。本质上，AI编程推动软件生产从人工编码转向人机协同的工程闭环。
2026-07-26 08:28:50
428
原创 好用的 AI 智能体开发平台有哪些？Dify、n8n、Coze该怎么选
本文介绍了当前主流的AI智能体开发平台及其适用场景，为企业和开发者提供选型参考。Dify适合开源学习和LLM应用开发，n8n擅长业务自动化流程集成，Coze便于快速创建互联网渠道应用，阿里云百炼适合云上模型应用一体化，而云程等企业级平台则更注重私有化部署、国产化适配和系统集成能力。 选型关键不在于功能清单，而需评估：1）部署边界和数据安全要求；2）权限控制和审计能力；3）业务系统集成深度；4）长期演进和治理能力。不同规模团队应根据实际需求，在开发效率、安全性、扩展性之间取得平衡，选择最适合自身技术栈和业务场
2026-07-25 14:51:14
324
原创 如何系统性学习大模型、Agent等相关知识？传统开发程序员如何快速转型成为AI人才
传统开发程序员转型 AI 人才，不是放弃原来的编程能力，而是把后端、前端、数据库、接口、权限、日志、运维这些工程经验，迁移到大模型、RAG、Agent、工具调用、AI 工作流和模型治理上。未来更有竞争力的程序员，不只是会写业务代码，也能把模型能力做成可上线、可追踪、可治理的企业级 AI 应用。
2026-07-25 13:39:19
389
原创 传统的 BPMN 工作流审批和 AI 工作流有什么区别？
传统BPMN工作流审批主要用于规范业务流程的流转和审批环节，关注流程节点、审批规则和状态管理；而AI工作流则聚焦于智能任务的编排，整合大模型、知识库、工具调用等AI能力处理非结构化任务。二者并非替代关系，BPMN适合规则明确的审批场景，AI工作流擅长需要认知能力的任务。实际应用中，企业往往将二者结合：BPMN管理流程框架，AI工作流嵌入智能处理节点。落地时需关注权限控制、人工确认机制及节点可观测性，在保留现有业务流程的同时增强智能处理能力。（
2026-07-24 07:49:51
283
原创 Agentic AI、AI Agent、AI 工作流有什么区别？
Agentic AI 是一种让 AI 围绕目标自主规划、调用工具并根据反馈完成任务的应用范式；AI Agent 是实现这种范式的具体执行单元；AI 工作流是把模型、Agent、工具、知识库和人工确认编排成确定流程的工程化方式。这三个概念经常被混用，但它们不是同一个层级。Agentic AI 回答“AI 应用应该具备什么样的自主执行能力”；AI Agent 回答“谁来理解任务、规划步骤和调用工具”；AI 工作流回答“如何让这些能力在生产环境里可控执行、可审计、可集成”。
2026-07-23 14:40:17
580
原创 AI Agent 到底是什么？能干什么，怎么实现？
AI Agent 是以大模型为推理核心，能够理解任务、规划步骤、调用工具或知识、执行动作并返回结果的软件执行单元。它不是魔法，也不是一个孤立的大模型接口。真正有价值的 Agent，通常由模型、Prompt、知识库、工具、工作流、权限和日志共同组成。
2026-07-23 07:02:52
314
原创 如何基于开源组件开发一个像 Dify 一样的 AI 工作流平台，实现自主可控
AI 工作流和传统BPMN工作流不完全一样。传统 BPMN 工作流更关注审批、流转、人工任务和业务状态；AI 工作流则要把 LLM、RAG、Agent、Tool、HTTP、代码节点、变量上下文、结构化输出、流式响应和调试日志一起纳入流程。它的核心目标不是画一张流程图，而是让不确定的大模型能力在确定的流程边界内稳定执行。
2026-07-22 12:22:07
451
原创 如何基于开源组件开发一个像 Dify 一样的AI智能体平台，实现自主可控
企业自研AI智能体平台的必要性及技术路线分析 摘要：本文探讨了企业基于开源组件自研类似Dify的智能体平台的技术路线。随着大模型应用的深入，企业面临私有化部署、权限集成、国产化适配等需求，直接使用开源平台存在技术栈匹配、治理合规等问题。文章剖析了Dify的功能架构，将其拆解为模型接入、RAG、Agent编排等核心模块，并推荐了SpringAI、LangChain、Milvus等开源技术选型组合。建议采用分阶段实施策略，重点自研资源对象模型、权限审计等企业级能力，实现真正的自主可控。
2026-07-22 10:49:41
592
原创 AI 知识库文档如何切片和检索？
企业AI知识库建设需突破文档解析与切片的技术瓶颈 企业构建AI知识库时，初期往往关注基础功能，但实际落地时会面临文档解析、切片策略和检索方法等深层挑战。不同格式（Word/PDF/Excel等）需采用差异化的解析技术，如Word需解析样式树，PDF需版面识别，表格需结构化处理。有效的切片策略应保留文档语义边界，并附加元数据。检索环节需结合向量检索、关键词检索、混合检索等多种方法，并严格管控权限。 知识库的核心价值在于将企业资料转化为可检索、可追溯的知识资产，需建立从文档解析到质量评估的完整链路。
2026-07-21 08:00:02
457
原创 AI 开源框架 Spring AI Alibaba 和 AgentScope 怎么选？
阿里巴巴开源的两个AI框架SpringAIAlibaba和AgentScope定位不同： SpringAIAlibaba：面向Java/Spring生态，侧重企业后端AI集成，支持模型接入、工作流编排（Graph/Workflow）及业务系统融合，适合智能客服、RAG服务等工程化场景。 AgentScope：以Python为主，专注多智能体协作与可观测性，强调Agent行为调试、任务拆解及可视化追踪，适合研究型应用和复杂Agent实验。
2026-07-21 07:45:20
253
基于camunda源代码编译运行流程引擎
2024-02-22
Camunda开源流程引擎快速入门文档
2024-02-21
一文说透低代码平台和无代码平台
2023-03-27
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人