云程智能体开发平台

摘要： Camunda 7 与 Camunda 8 的共同点是 BPMN，差异却贯穿执行内核、事务、编程、存储、查询、运维和许可。Camunda 7 到 8 是架构迁移，不是依赖升级。 存量 Camunda 7 应先治理、解耦和制定退出路线；新建跨服务编排平台可以优先评估 Camunda 8；传统人工审批和低代码 OA 则应从组织、事务、动态审批和二开成本出发，比较包括 Flowable 在内的嵌入式路线。 阅读全文

摘要： Activiti 5、6、7 不是一条“版本越高、替换依赖就越先进”的简单升级线。 Activiti 5 是经典的嵌入式 Java BPMN 引擎；Activiti 6 重写了执行核心；Activiti 7 在 6.x 内核之上增加新的 Runtime API，并把路线延伸到 Spring Boot、消息驱动和 Activiti Cloud。 阅读全文

摘要： 对中国式 OA 和低代码审批，Flowable 通常仍是更均衡的开源底座；已有 Activiti 资产应优先评估加固与渐进迁移；需要跨语言、高吞吐编排时可评估 Camunda 8、Conductor 或 Temporal；规则与流程强耦合可看 Apache KIE/jBPM；Camunda 7 存量系统可以验证 Operaton、CIB seven；LiteFlow 则更适合应用内逻辑链。 阅读全文

摘要： Activiti、Flowable、Camunda 共享 Activiti 5 时代的 Java BPMN 引擎血统，但开源项目从来不只由代码决定。维护团队、目标用户、商业模式和目标负载不同，最终让 Activiti 走向“轻量引擎与云组件探索”，Flowable 走向“面向业务自动化的多引擎开源底座”，Camunda 则从开发者友好的 BPM 平台进一步走向以 Zeebe 为核心的分布式流程编排。 阅读全文

摘要： 新建传统 Java 审批平台、强调 Apache 2.0、国产数据库适配和会签/加签/回退等深度定制，优先评估 Flowable；已有 Activiti 资产且团队能长期维护内核，可以继续演进，但不建议仅凭“历史知名度”用于全新项目；需要高吞吐分布式编排、跨语言 Worker、成熟运维界面和商业支持，并能接受生产许可证与更高运维成本，评估 Camunda 8。Camunda 7 社区版已经结束生命周期，不应再作为新项目基线。 阅读全文

摘要： 多 Agent（Multi-Agent System，多智能体系统）是由多个具备独立角色、上下文、工具和决策能力的 AI Agent 共同完成一个目标的系统。它的核心价值不是“多调用几次大模型”，而是把可以拆分的复杂任务交给不同专业单元，并通过编排、消息契约、共享状态和结果验证形成协作闭环。 多 Agent 并不天然优于单 Agent。它更适合任务可并行、专业边界清晰、上下文可以隔离、子任务能够独立验收的场景；如果步骤固定、依赖紧密、所有角色都需要完整共享同一上下文，单 Agent 加确定性工作流通常更便宜、更稳定。LangChain 的官方文档也明确提醒：很多复杂任务仍可由一个拥有合适工具和提示词的 Agent 完成，不应为了架构新颖而强行拆分。 阅读全文

摘要： 提示词工程主要优化单次请求中的指令表达，而智能体需要跨多轮执行、调用工具、读取知识、保存状态并处理失败。真正决定 Agent 是否可靠的，往往不只是模型会不会推理，而是运行时给模型看到了什么、没有看到什么，以及这些信息是否准确、及时、可授权、可追溯。 上下文工程（Context Engineering）是对模型推理时全部输入信息进行选择、组织、压缩、隔离、更新和评测的系统工程。它包含提示词，但范围还包括会话历史、任务状态、检索证据、工具定义、长期记忆、用户权限、执行反馈与输出契约。Anthropic 将其称为提示词工程的自然演进；LangChain 的官方文档也把大量 Agent 失败归因于“传给模型的上下文不正确”，而不是模型本身没有能力。 阅读全文

摘要： AI Agent 评估不能只检查最终回复，而要同时评估任务、运行轨迹、工具调用、外部环境结果和多次运行的稳定性。两者侧重点有所不同：Anthropic 更像一套完整的评估方法论，OpenAI 更像一套可接入开发与生产流程的评估工具链。 阅读全文

摘要： 2026 年 AI Agent 最重要的变化，不是智能体突然实现了完全自治，而是行业开始把 Agent 当作一种需要长期运行、连接企业系统并接受治理的软件执行单元。模型能力仍在提高，但真正决定 Agent 能否落地的重点，已经转向任务边界、上下文工程、持久化状态、协议互联、安全控制、评测体系和业务流程重构。 阅读全文

摘要： LLM 负责理解和决策，RAG 负责补充知识，Function Call 负责表达工具调用意图，MCP 负责连接工具与数据，Skill 负责复用专业方法，Workflow 负责约束执行路径，Agent 负责动态决定下一步，A2A 负责多个 Agent 之间的协作。 阅读全文

摘要： AI Agent 落地效果不佳，通常不是单纯因为模型能力不足，而是系统缺少生产级工程闭环：目标和完成条件不清、提示词与上下文不可测试、工具缺少权限和幂等契约、任务状态不能持久化、控制流由模型独占、结果依靠模型自评、失败不能恢复，也没有评测与人工审批。12-Factor Agents 的十二项原则提供了一条改进路径：让 LLM 负责语义理解和候选决策，让确定性代码负责控制、验证和副作用，让人在高风险与歧义节点介入。企业应从一个可验收的小任务开始，依次建设契约、状态、韧性和产品化运行能力。 阅读全文

摘要： AI Agent 目前最大的瓶颈不是“不会完成复杂任务”，而是不能以可测量、可复现、可恢复、可治理的方式持续完成复杂任务。模型决定能力上限，工程决定可用下限。真正能够进入生产环境的 Agent，必须把两者之间的巨大空白，用状态、验证、权限、评测和反馈闭环一点点填满。 阅读全文

摘要： AI Agent（人工智能智能体）不是一个“更会聊天的大模型”，而是一套以大语言模型为推理核心、能够读取环境、规划步骤、调用工具、检查结果并持续迭代的软件系统。 从序结构看，Agent 最核心的部分并不神秘：编排器把任务和当前状态交给模型；模型决定直接回答还是调用工具；程序执行工具并把结果写回状态；模型再根据新证据继续判断。这个循环一直运行到任务完成、需要用户确认，或者触发预算、超时与安全限制。 本文不只解释“Agent 是什么”，还会深入到 API 消息、Tool Calling、ReAct 循环、上下文窗口、RAG、长期记忆、MCP、并发执行、错误恢复、成本优化与可观测性等工程细节。 阅读全文

摘要： Agent 与 Agent 的差距，不只是大模型能力差距，而是任务边界、上下文管理、工具调用、知识检索、规划方式、状态记忆、评测体系、安全治理和运行可观测性的综合差距。模型越强，Agent 的上限可能越高；但没有工程化能力，强模型也只能变成一个更会说话的聊天窗口。 很多人会误以为“只要大模型足够强，Agent 就自然强”。这个判断只对了一半。大模型提供推理、生成和理解能力，但 Agent 要完成真实任务，还需要知道能做什么、不能做什么、该查哪些知识、该调哪些工具、失败后怎么重试、什么时候交给人、如何记录过程、如何控制权限、如何持续评测。 Anthropic 在“Building effective agents”中强调，Agent 系统的关键不是把流程做得越复杂越好，而是根据任务复杂度选择合适的工作流和自主程度。LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、MCP 等主流项目也在从不同方向说明同一件事：真正可用的 Agent，是模型能力与工程约束共同作用的结果。 阅读全文

摘要： 模型蒸馏的核心思想，是用一个能力更强的大模型作为“老师模型”，把它在特定任务上的答案、推理过程、偏好判断或行为模式，转化为训练数据，再训练一个更小、更快、更便宜的“学生模型”。它的目标不是复制一个巨型通用模型，而是在明确场景里获得接近老师模型的效果，同时降低推理成本、部署成本和延迟。企业要做蒸馏，不能只看“能不能把大模型答案拿来训练”。更关键的是三件事：老师模型输出是否允许用于训练，蒸馏数据质量是否可靠，学生模型是否在真实业务评测中达到上线标准。 阅读全文

摘要： 模型微调的本质，是在已有大模型基础上，用高质量领域样本继续训练，让模型更稳定地完成特定任务。它不是把所有企业知识“塞进模型参数”，而是让模型学会某个领域的表达方式、判断标准、输出格式和任务流程。 如果企业只是希望模型回答最新制度、合同、产品手册或业务系统数据，优先考虑 RAG、工具调用和权限控制；如果企业希望模型按照稳定口径做分类、抽取、审查、生成、格式化输出、行业问答或任务执行，再考虑模型微调。 阅读全文

摘要： 从零预训练一个自己的大模型，技术上可以做，但它不是普通企业使用大模型的默认路径。真正的预训练不是“下载代码跑起来”，而是围绕高质量语料、分布式训练、稳定性监控、模型评测、安全对齐、推理服务和持续迭代建立一套长期工程体系。 如果只是想让企业知识可问、业务流程可自动化、系统接口可调用，通常不需要从零训练基座模型。更现实的路线是：选择合适的开源或商业基座模型，结合 RAG、微调、继续预训练、Agent 和 AI 工作流，把模型能力转化为可上线、可治理、可运维的业务应用。 阅读全文

摘要： 多模态 RAG 适合处理“知识不只在纯文本里”的场景，例如 PDF 制度、扫描合同、图片票据、设备照片、表格报表、产品手册、图纸截图和网页资料。它的核心不是简单做 OCR，而是把文本、版面、表格、图片、图表和元数据一起转成可检索、可重排、可引用、可权限控制的企业知识资产。 如果传统 RAG 解决的是“从文本里找答案”，多模态 RAG 解决的是“从复杂业务资料里找证据”。企业真正的知识往往不在一段干净的 Markdown 里，而在 PDF 里的表格、图片里的文字、扫描件里的印章、报表里的指标、设备照片里的状态、PPT 里的流程图和网页里的混合内容里。只做文本切片会丢失大量结构信息。 阅读全文

摘要： RAG 做得好不好，关键不在于“有没有向量库”，而在于文档能不能被正确解析，切片是否保留语义结构，检索是否能同时覆盖语义和关键词，Rerank 是否能把真正相关的证据排到前面，以及检索阶段是否按用户权限过滤知识片段。 一句话回答：企业级 RAG 的实用技巧可以概括为“四件事”：结构化切片、混合检索、重排精选、权限随行。只做向量检索通常只能解决“能搜到一点内容”，而真正可用的知识库要解决“搜得准、答得稳、能追溯、不越权”。 阅读全文

摘要： 真正可靠的 RAG 不是“向量库 + 大模型”这么简单，而是文档解析、切片、混合检索、重排序、权限过滤、引用校验和答案评测共同组成的一套工程体系。 现在所谓“替代 RAG”的新技术，准确说更多是在不同场景下升级、补充或部分替代基础 RAG，包括长上下文模型、GraphRAG、KG-RAG、LightRAG、Agentic RAG、KAG、结构化查询、工具调用和答案验证器。企业做 AI 应用时，通常不是在 RAG 与替代技术之间二选一，而是把它们组合成“可信知识增强生成”体系。 阅读全文