智能体来了2026AI元年：工作流推理能力的系统级融合成为主流实践
随着大模型能力从以内容生成见长，逐步扩展至复杂任务推理与多步骤协同，2026 年被普遍视为企业级 AI 应用形态发生结构性变化的关键节点。在行业实践中，AI 正从独立能力模块，转变为嵌入业务系统内部的基础性认知组件。这一变化的核心，并非模型参数规模的增长，而是 AI 与工作流（Workflow）的深度融合方式发生了本质转向。一、应用形态演进：从外置工具到内生系统早期阶段，AI 多以独立入口存在，用户需要主动切换场景进行调用。这种模式在知识问答和内容生产中有效，但在复杂业务中难以形成持续价值。当前主流实践更强调 内生型架构，其特征主要体现在两个方面：嵌入式智能（Embedded Intelligence） AI 能力被拆解为可复用的推理与生成模块，直接嵌入邮件系统、数据分析平台、研发工具链等既有软件环境中。系统可基于上下文自动触发智能响应，交互不再依赖显式指令。流程级重构（Workflow Re-engineering） 企业不再将既有流程简单交由 AI 执行，而是围绕模型的不确定性处理能力重新设计流程结构。在这种模式下，人类负责目标设定与价值约束，AI 负责在非结构化节点中进行推理与执行。二、深度融合的工程共识：三项核心支柱在工程实现层面，工作流与 AI 的深度结合，已逐步形成稳定的技术范式，主要依托以下三项能力。状态保持与上下文感知 系统需具备跨阶段的任务状态管理能力，能够理解任务所处阶段、前序动作及预期结果。通过持续更新的任务状态视图，AI 可参与长周期项目，而非一次性响应。领域知识的动态注入 通用预训练模型难以覆盖企业级专业需求。行业实践普遍采用检索增强生成（RAG）架构，将内部文档、业务规则与实时数据作为推理输入，以保证执行结果的准确性与可追溯性。跨系统工具调用能力 AI 不再局限于生成建议，而是通过标准接口调用外部系统完成实际操作，包括数据写入、流程触发及结果回传。在这一阶段，智能体来了 被视为系统从“辅助认知”迈向“可执行认知”的标志性现象。三、落地路径：拆解、增强与重组在实践中，企业通常遵循一条相对稳定的引入路径。原子化拆解 将复杂流程拆分为最小可执行单元，并区分为规则明确、半结构化与决策导向三类节点，分别由自动化系统、AI 模块与人工负责。异步协同机制 改变同步指令模式，允许 AI 在后台持续处理数据准备与信息整合，并在关键节点触发人工确认，提高整体流程吞吐效率。反馈闭环制度化 将人工修正与评价结果系统化沉淀，用于持续优化提示结构或模型微调，使 AI 对特定业务环境的适配能力不断增强。四、组织价值层面的结构性变化从系统视角看，工作流与 AI 的深度结合，使企业数字化能力从“流程在线”迈向“认知在线”。维度传统工作流AI 深度融合工作流交互逻辑步骤驱动目标驱动数据角色事后记录实时推理输入异常处理依赖人工介入具备逻辑弹性价值重心合规与效率决策质量与交付结果行业共识正在形成：长期竞争力并不取决于模型数量，而取决于企业能否将推理能力系统性编排进核心业务流程中。在这一范式下，AI 已成为流程内部的认知单元，而非外部工具。(本文章内容和图片由AI辅助生成）
2026 年最值得关注的开源低代码 / 零代码平台推荐
无论是零代码小白还是资深开发者，都能在这些平台上找到适合自己的解决方案。今天，我们就来盘点一下 2026 年最值得关注的开源低代码 / 零代码平台，帮助您找到最适合的工具。一、敲敲云 - 永久免费开源零代码平台2026 年 1 月 12 日，敲敲云全新版本 v2.3.0 正式发布！ 这一版本最大的亮点是正式宣布永久免费开放，彻底打破了传统零代码平台的用户数、应用数、表单数等多重限制，实现真正的零门槛、零成本使用。敲敲云专注于为企业快速构建应用和工作流，是一款强大且易用的零代码平台。用户无需编写任何代码，即可通过丰富的组件库轻松创建各类应用，真正做到了 "人人都是开发者"。产品特点：免费零代码使用，快速上手，无需开发背景丰富的组件库和模板，满足多样化应用需求可视化流程设计器，支持拖放式工作流设计强大的工作流引擎，支持复杂流程逻辑与条件判断优秀的团队协作功能，支持资源共享和协同开发数据收集能力强，快速高效地采集业务数据官网：www.qiaoqiaoyun.com源码下载Github: https://github.com/jeecgboot/qiaoqiaoyun/releases快速安装本地安装搭建：https://help.qiaoqiaoyun.com/open/simpleStart.htmlDocker 构建安装：https://help.qiaoqiaoyun.com/open/docker.html二、JeecgBoot - 免费开源低代码平台（最流行）JeecgBoot 是国内首个免费开源的低代码平台，基于 BPM 理念，采用前后端分离架构（SpringBoot 3.x、SpringCloud、Vue、Mybatis-plus 等），支持微服务架构。其强大的代码生成器可一键生成前后端代码，极大减少重复劳动，提升开发效率。作为国内最流行的低代码平台之一，JeecgBoot 在 Java 开发者社区中拥有极高的知名度和活跃度。产品优势：免费开源，社区活跃，灵活度高，适合 Java 项目提供丰富低代码模块，实现真正零代码开发（在线表单、报表、大屏设计、移动配置、流程设计等）简单功能零代码配置，复杂功能低代码生成，兼顾智能与灵活性业务流程采用工作流引擎，流程与表单松耦合设计，支持灵活配置保障企业流程保密性，显著减轻开发人员负担国产数据库友好（达梦、人大金仓）官网：www.jeecg.com源码下载Github 地址： https://github.com/jeecgboot/JeecgBootGitee 地址： https://gitee.com/jeecg/JeecgBoot三、积木报表 - 像搭建积木一样设计报表积木报表 (jimureport)，是一款免费的数据可视化报表，含报表、打印、大屏和仪表盘，像搭建积木一样完全在线设计！功能涵盖：复杂报表、打印设计、图表报表、门户设计、大屏设计等！JimuReport 侧重传统复杂报表和打印JimuBI 侧重数据大屏和仪表盘可视化设计产品优势：JimuReport 采用 Web 版报表设计器，类 Excel 操作风格，通过拖拽完成报表设计，所见即所得。领先的企业级 Web 报表，支持各种复杂报表，专注于解决企业报表难题。JimuBI 是专注于数字孪生和数据可视化的工具，旨在通过直观、动态且视觉吸引力强的形式呈现实时业务数据，尤其擅长打造 交互式大屏和仪表盘JimuBI 业内唯一实现全场景覆盖：同时支持大屏（炫酷动态）、仪表盘（专业分析）、门户（交互式业务看板）、移动端（随时随地查看），真正实现 "一次开发，多端适配"。大屏采用类 word 风格，可以随意拖动组件，想怎么设计怎么设计，可以像百度和阿里一样，设计出炫酷大屏！秉承 "简单、易用、专业" 的产品理念，极大的降低报表开发难度、缩短开发周期、节省成本.官网：https://jimureport.com代码下载https://github.com/jeecgboot/JimuReport四、BudibaseBudibase 是一个开源低代码平台，可以更快地构建业务应用程序，从而增强团队能力并提高生产力。IBM、Deloitte、Proctor 和 Gamble、Rakuten 等企业在内部使用该平台。它利用内部数据库，但也集成了领先的数据库，包括 ArangoDB、DynamoDB、Mongo DB、MySQL、S3 等。产品特点包括：为所有团队成员快速构建内部工具在企业中设置和自动化表单创建管理面板来管理数据和团队和客户的简单门户源码下载Github: https://github.com/Budibase/budibase五、AppsmithAppsmith 是一个用于构建管理面板、内部工具和仪表板的低代码项目。与超过 15 个数据库和任何 API 集成。构建你需要的一切，速度提高 10 倍。允许你拖放组件来构建仪表板、使用 Java 对象编写逻辑并连接到任何 API、数据库或 GraphQL 源。源码下载地址：https://github.com/appsmithorg/appsmith六、BudiBaseBudibase 是一个开源的低代码平台，帮助 IT 专业人士在几分钟内在自己的基础架构上构建、自动化和交付内部工具。它专注于为开发人员提供工具，以加快一个平台内的开发、部署和集成过程。源码下载地址：https://github.com/Budibase/budibase七、JogetJoget 使业务用户、非编码人员或编码人员能够使用单一平台轻松构建、交付、监控和维护企业应用程序。Joget DX 在一个简单、灵活和开放的平台中结合了业务流程自动化、工作流管理和低代码应用程序开发的优点。项目地址项目地址：https://www.joget.org/八、n8n（流程自动化）n8n 是一个开源的工作流自动化工具，主要用于连接不同的应用程序和服务，实现数据的自动化处理和流程的自动化执行。它提供了一个可视化的界面，让用户可以通过拖拽节点的方式来构建工作流，无需编写复杂的代码。主要特点包括：节点式工作流设计：用户可以通过拖拽不同的节点来构建工作流，每个节点代表一个特定的功能或操作。丰富的集成能力：n8n 支持与多种第三方服务和应用程序的集成，如 Slack、Google Drive、GitHub 等。自定义节点：用户可以根据自己的需求创建自定义节点，扩展 n8n 的功能。源码下载地址：https://github.com/n8n-io/n8n
原文链接：https://www.nocobase.com/cn/blog/weekly-updates-20260129汇总一周产品更新日志，最新发布可以前往我们的博客查看。NocoBase 目前更新包括的版本更新包括三个分支：main ，next和 develop。main ：截止目前最稳定的版本，推荐安装此版本。next：包含即将发布的新功能，经过初步测试的版本，可能存在部分已知或未知问题。主要面向测试用户，用于收集反馈和进一步优化功能。适合愿意提前体验新功能并提供反馈的测试用户。develop：开发中的版本，包含最新的功能代码，可能尚未完成或存在较多不稳定因素，主要用于内部开发和快速迭代。适合对产品功能前沿发展感兴趣的技术用户，但可能存在较多问题或不完整功能，不建议在生产环境中使用。mainv1.9.40发布时间：2026-01-25🚀 优化[Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher🐛 修复[client]修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhh[database]修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile修复嵌套关联的深度更新问题 (#8492) by @chenos[文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher[数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile[区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe[工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher[模板打印] 复了联合角色时打印按钮权限逻辑错误 by @jiannx[工作流：审批]修复并发提交导致流程被重复恢复执行的问题 by @mytharcher修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher[迁移管理] 修复迁移异常后打印异常对象所包含 SQL 过大容易卡死进程的问题 by @cgyrocknextv2.0.0-beta.17发布时间：2026-01-29🐛 修复[client] 修复筛选相关的已知问题 (#8514) by @zhangzhonghe[AI 员工] 修复构建后系统无法启动问题 (#8523) by @cgyrock[AI: 知识库] 修复构建后系统无法启动问题 by @cgyrockv2.0.0-beta.16发布时间：2026-01-27🎉 新特性[client] 新增子表格（弹窗编辑）字段组件 (#8280) by @katherinehhh[工作流] 为移动节点增加 API (#8507) by @mytharcher🚀 优化[client]修复单元格更新导致表格整体重渲染 (#8349) by @katherinehhh改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8458) by @katherinehhh[文件管理器] 为文件管理器增加可扩展的预览组件 (#8501) by @mytharcher[工作流] 修改工作流子页面的路由路径，将工作流页面都统一在 /admin/settings/workflow 路径之下 (#8519) by @mytharcher🐛 修复[client]修复筛选区块日期带时间时时间格式重复的问题 (#8506) by @zhangzhonghe修复多层级对多字段子表单字段联动规则无法使用表单变量赋值的问题。 (#8518) by @gchust修复多级弹窗及跨区块数据变更后不刷新问题。 (#8471) by @gchust修复编辑表单中配置阅读态子详情数据不能正常显示问题 (#8469) by @katherinehhh修复targetKey 可选字段的处理逻辑 (#8333) by @katherinehhh修复编辑态子表格中关系字段 Select 的 filter 参数错误问题 (#8335) by @katherinehhh[flow-engine] 修复外部数据源 filterTargetKey 为单元素数组时 FilterByTK 处理错误 (#8522) by @katherinehhh[AI 员工] 修复 AI 建模与数据源管理模块中可选字段配置不一致的问题 (#8488) by @cgyrock[邮件管理] 选中文本时正文不折叠。修复附件下载失败 by @jiannxv2.0.0-beta.15发布时间：2026-01-25🚀 优化[Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher🐛 修复[database] 修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile[模板打印] 复了联合角色时打印按钮权限逻辑错误 by @jiannx[工作流：审批] 修复 1.x 审批记录弹窗报错的问题 by @mytharcher[迁移管理] 修复迁移异常后打印异常对象所包含sql过大容易卡死进程的问题 by @cgyrockv2.0.0-beta.14发布时间：2026-01-23🎉 新特性[AI 员工] AI 对话支持复制粘贴文件 (#8487) by @heziqiang🚀 优化[client]改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8473) by @katherinehhh改进子表格中附件字段的上传与编辑按钮，引导用户点击上传 (#8474) by @katherinehhh[flow-engine] 优化 runjs 的 ctx.libs, 使其支持按需加载，并新增 lodash, math, formula 预定义库。 (#8468) by @gchust[错误处理器] 避免 SQL 引用错误直接暴露 (#8464) by @2013xile[工作流：审批] 增加对 API 的访问控制，以避免通过 API 越权操作数据 by @mytharcher🐛 修复[client]修复富文本编辑器的弹出层被遮挡的问题 (#8443) by @zhangzhonghe修复筛选区块日期带时间时时间格式重复的问题 (#8484) by @zhangzhonghe修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhhfilter列表去重 (#8431) by @jiannx修复在 Chrome 144 版本中不显示配置菜单的问题 (#8470) by @zhangzhonghe[database]修复嵌套关联的深度更新问题 (#8492) by @chenos[server] 修复通用依赖中 mathjs 包的版本 (#8475) by @mytharcher[flow-engine] 修复内嵌弹窗页面连续打开联动规则配置和事件流配置后关闭弹窗报错的问题。 (#8368) by @gchust[数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile[异步任务管理器] 修复异步导入触发的工作流事件延迟执行的问题 (#8478) by @mytharcher[区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe[UI 模板] 修复引用模板区块无法通过事件流设置数据范围的问题。 (#8472) by @gchust[文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher[操作：导入记录 Pro] 修复异步导入触发的工作流事件延迟执行的问题 by @mytharcher[工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher[模板打印] 模板打印的配置模板弹窗移除底部按钮 by @katherinehhh[工作流：审批]修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher修复并发提交导致流程被重复恢复执行的问题 by @mytharcher修复审批任务卡片字段不显示的问题 by @zhangzhonghedevelopv2.0.0-alpha.68发布时间：2026-01-27🎉 新特性[工作流] 为移动节点增加 API (#8507) by @mytharcherv2.0.0-alpha.67发布时间：2026-01-26🎉 新特性[server] 重构应用监管器以适配不同场景下的多应用管理需求 (#8043) by @2013xile[client] 新增子表格（弹窗编辑）字段组件 (#8280) by @katherinehhh[AI 员工] AI 对话支持复制粘贴文件 (#8487) by @heziqiang🚀 优化[client]改进子表格中附件字段的上传与编辑按钮，引导用户点击上传 (#8474) by @katherinehhh改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8473) by @katherinehhh[flow-engine] 优化 runjs 的 ctx.libs, 使其支持按需加载，并新增 lodash, math, formula 预定义库。 (#8468) by @gchust[server] 支持配置跨域 Origin 白名单 (#8454) by @2013xile[文件管理器] 为文件管理器增加可扩展的预览组件 (#8501) by @mytharcher[Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher[错误处理器] 避免 SQL 引用错误直接暴露 (#8464) by @2013xile[操作：导出记录] 改进导出按钮数据范围：优先按选中记录，其次按前端筛选范围 (#8442) by @katherinehhh[操作：导出记录 Pro] 改进导出按钮数据范围：优先按选中记录，其次按前端筛选范围 by @katherinehhh[工作流：审批] 增加对 API 的访问控制，以避免通过 API 越权操作数据 by @mytharcher🐛 修复[client]修复筛选区块日期带时间时时间格式重复的问题 (#8484) by @zhangzhonghe修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh修复富文本编辑器的弹出层被遮挡的问题 (#8443) by @zhangzhonghefilter列表去重 (#8431) by @jiannx修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhh修复在 Chrome 144 版本中不显示配置菜单的问题 (#8470) by @zhangzhonghe修复编辑表单中配置阅读态子详情数据不能正常显示问题 (#8469) by @katherinehhh修复自定义变量弹窗被遮挡的问题 (#8463) by @zhangzhonghe修复数据表字段分组排序设置不生效问题 (#8453) by @katherinehhh修复表格“列设置”按钮无效的问题 (#8441) by @zhangzhonghe修复关系文件快速编辑，选择文件的弹窗层级错误，无法保存弹窗配置的问题。 (#8446) by @gchust修复数据表图形界面编辑数据表报错问题 (#8451) by @katherinehhh[database]修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile修复嵌套关联的深度更新问题 (#8492) by @chenos[server] 修复通用依赖中 mathjs 包的版本 (#8475) by @mytharcher[flow-engine]修复内嵌弹窗页面连续打开联动规则配置和事件流配置后关闭弹窗报错的问题。 (#8368) by @gchust修复能够重复点击配置菜单打开多个配置弹窗的问题。 (#8448) by @gchust修复 runjs 相关代码在运行前变量就被解析的问题。 (#8445) by @gchust修复数据选择器快速新增弹窗中无法选择弹窗变量的问题。 (#8450) by @gchust[AI 员工] 修复 AI 建模与数据源管理模块中可选字段配置不一致的问题 (#8488) by @cgyrock[数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile[区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe[异步任务管理器] 修复异步导入触发的工作流事件延迟执行的问题 (#8478) by @mytharcher[文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher[UI 模板] 修复引用模板区块无法通过事件流设置数据范围的问题。 (#8472) by @gchust[移动端（已废弃）] 弃用移动端插件（2.0 后将使用 ui-layout 插件代替） (#8456) by @chenos[操作：导入记录 Pro] 修复异步导入触发的工作流事件延迟执行的问题 by @mytharcher[工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher[模板打印]复了联合角色时打印按钮权限逻辑错误 by @jiannx模板打印的配置模板弹窗移除底部按钮 by @katherinehhh[工作流：审批]修复审批任务卡片字段不显示的问题 by @zhangzhonghe修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher修复并发提交导致流程被重复恢复执行的问题 by @mytharcher修复 1.x 审批记录弹窗报错的问题 by @mytharcher[邮件管理]修复邮箱配置弹窗被遮挡的问题 by @zhangzhonghe修复多个用户间相同邮箱邮件问题，性能优化 by @jiannx[迁移管理] 修复迁移异常后打印异常对象所包含 SQL 过大容易卡死进程的问题 by @cgyrock完全掌控，无限扩展，AI 协同。NocoBase 让你的团队快速响应变化，大幅降低成本。无需多年研发，无需数百万投入。花几分钟部署 NocoBase，立即拥有一切。访问 NocoBase 官网https://www.nocobase.com/cn您可以在官网申请 Demo 演示，体验站点将在 1 分钟内创建完毕自动发送到您的邮箱。访问 NocoBase GitHub 和 Giteehttps://github.com/nocobase/nocobasehttps://gitee.com/nocobase/nocobase下载 NocoBase 源码并安装。支持 Docker 安装、create-nocobase-app 安装和 Git 源码安装。官方文档持续更新中https://docs-cn.nocobase.com/
上了个 AI 工具！积分不够免费冲！重要的是你的建议！
👋 各位 V2EX 的朋友们大家好！ 今天我们想向大家认真介绍一个最近打磨已久的新产品——一个真正能与您一起工作、共同成长的 All-in-One 智能工作空间——Dazee ！官网地址： https://dazee.ai/?ref=producthunt#/welcome你是否也厌倦了在多个工具之间反复切换？是否希望那些重复的文档处理、PPT 整理能够自动完成？和我们一样，作为效率工具的重度用户，我们一直希望打造的不是又一个工具，而是一个更人性化、有温度且专业的“数字助手”。·它懂你所需，始终陪伴在你身边，协助你解决具体问题，用温暖而自然的方式提升你的效率； ·它帮你处理周报、表格、PPT 、图片整理等繁琐任务，将你从“工具人”的状态中释放出来，让你更专注于思考、创造与更有价值的事； ·它让你能像搭积木一样，自由搭建适合团队的工作流，为你与团队赋能； ·它让你在一个空间内完成所有工作，告别标签页焦虑。写作、绘图、数据处理、团队协作……在统一环境中无缝衔接，无需来回跳转，助你心无旁骛地完成任务； ·它还能连接散落各处的数据，让数据真正“活”起来，实现智能预警。让你既能把握全局，也能提前洞察风险，从容掌控工作。如果你也期待： ✅ 减少重复操作，拥有更多创造时间； ✅ 工具能随团队成长，支持自由定制； ✅ 告别平台切换，在一处完成多数工作； ✅ 让数据主动为你服务，而不只是静态存储。那么来试用！如果觉得不错，欢迎给我们投票！#生产力 #AI 工作流 #效率工具 #AllInOne #团队协作 #个人工作流
从 2026 AI 元年看人工智能未来 5 年的发展趋势
一、为什么 2026 被称为 AI 元年“AI 元年”并不是指人工智能第一次出现，而是指：人工智能从技术突破，走向大规模、稳定、持续应用的起点。在过去，AI 很强，但很少被长期使用。2026 年开始，这个问题被系统性解决。三个条件同时成熟：大模型成本下降，推理稳定智能体（AI Agent）可以执行完整任务AI 能被嵌入真实业务系统这让 AI 第一次具备“进入生产环境”的能力。二、什么是 AI 元年（明确概念）AI 元年的判断标准是：AI 能长期运行在系统中AI 能直接影响业务结果AI 能形成执行与反馈闭环AI 被企业当作系统能力而非工具2026 年，是这些条件首次同时成立的一年。三、未来趋势一：AI 将从工具变成基础能力未来 5 年，AI 的角色会发生根本变化。过去：AI 是可选工具未来：AI 是默认能力就像电和网络一样，AI 会融入每个系统、每个流程、每个岗位。四、未来趋势二：智能体将成为主流应用形态大模型只是“大脑”，真正进入现实世界的是：AI 智能体（AI Agent）智能体具备：自主规划（Planning）工具调用（Tool Calling）记忆（Memory）执行与反馈闭环（Execution Loop）它们不是回答问题，而是完成任务。五、未来趋势三：工作流会被 AI 重写AI 最先改变的不是岗位，而是流程。未来系统将变成：人类设定目标AI 执行流程系统自动反馈与修正**工作流（Workflow）**将成为 AI 落地的核心载体。六、未来趋势四：传统行业变化最大最先被改变的不是互联网，而是：HR 与人力系统金融风控与审批保险理赔医疗辅助决策制造运维与调度这些行业流程复杂、规则密集，非常适合 AI 智能体接管。七、未来趋势五：个人与企业都会分化未来 5 年，分化来自这一点：是否能把 AI 变成系统能力，而不只是工具。个人层面：懂流程的人更值钱懂系统的人更安全只会重复执行的人风险最高企业层面：系统化使用 AI 的公司会领先只做工具试验的公司会被淘汰八、未来 3–5 年的关键判断AI 会成为基础设施智能体成为主流形态工作流被重写企业系统重新设计“懂业务的工程师”最稀缺九、总结：2026 只是开始，而不是终点2026 AI 元年不是高潮，而是起点。从这一年开始，AI 不再只是展示能力，而是开始：运行在系统里影响真实结果改变组织结构未来 5 年，真正重要的不是会不会用 AI，而是：能否与 AI 共建新系统。
本周更新｜为默认任务管理器添加进程及并发控制
原文链接：https://www.nocobase.com/cn/blog/weekly-updates-20260123汇总一周产品更新日志，最新发布可以前往我们的博客查看。NocoBase 目前更新包括的版本更新包括三个分支：main ，next和 develop。main ：截止目前最稳定的版本，推荐安装此版本。next：包含即将发布的新功能，经过初步测试的版本，可能存在部分已知或未知问题。主要面向测试用户，用于收集反馈和进一步优化功能。适合愿意提前体验新功能并提供反馈的测试用户。develop：开发中的版本，包含最新的功能代码，可能尚未完成或存在较多不稳定因素，主要用于内部开发和快速迭代。适合对产品功能前沿发展感兴趣的技术用户，但可能存在较多问题或不完整功能，不建议在生产环境中使用。mainv1.9.39发布时间：2026-01-21🐛 修复[server] 修复通用依赖中 mathjs 包的版本 (#8475) by @mytharcher[client] 修复在 Chrome 144 版本中不显示配置菜单的问题 (#8470) by @zhangzhonghe[异步任务管理器] 修复异步导入触发的工作流事件延迟执行的问题 (#8478) by @mytharcher[操作：导入记录 Pro] 修复异步导入触发的工作流事件延迟执行的问题 by @mytharcherv1.9.38发布时间：2026-01-20🚀 优化[server] 支持配置跨域 Origin 白名单 (#8454) by @2013xile[错误处理器] 避免 SQL 引用错误直接暴露 (#8464) by @2013xile🐛 修复[client]修复数据表字段分组排序设置不生效问题 (#8453) by @katherinehhh修复数据表图形界面编辑数据表报错问题 (#8451) by @katherinehhh修复表格“列设置”按钮无效的问题 (#8441) by @zhangzhonghe修复表格行按钮的联动规则会影响弹窗表单按钮状态的问题 (#8434) by @zhangzhonghe[移动端（已废弃）] 弃用移动端插件（2.0 后将使用 ui-layout 插件代替） (#8456) by @chenosv1.9.37发布时间：2026-01-15🚀 优化[evaluators] 升级 math.js 包的版本以支持更多函数 (#8411) by @mytharcher[通知：站内信] 修复当发送站内信至大量用户时的性能问题 (#8402) by @mytharcher🐛 修复[client]修复新建表单中级联组件成功提交数据后，级联组件数据未清空 (#8403) by @katherinehhh为操作按钮的 schema 增加容错，避免点击后页面崩溃 (#8420) by @mytharcher修复提交按钮同时设置二次确认和跳过必填校验时跳过必填校验不生效的问题 (#8400) by @katherinehhh[数据表字段：多对多 (数组)] 修复关联查询时 append 的二级关联表是多对多（数组）时报错的问题 (#8406) by @cgyrock[工作流] 修复复制工作流之后节点配置中的界面配置 ID 未被更新的问题 (#8396) by @mytharchernextv2.0.0-beta.13发布时间：2026-01-19🚀 优化[server] 支持配置跨域 Origin 白名单 (#8454) by @2013xile[操作：导出记录] 改进导出按钮数据范围：优先按选中记录，其次按前端筛选范围 (#8442) by @katherinehhh[操作：导出记录 Pro] 改进导出按钮数据范围：优先按选中记录，其次按前端筛选范围 by @katherinehhh🐛 修复[client]修复自定义变量弹窗被遮挡的问题 (#8463) by @zhangzhonghe修复数据表图形界面编辑数据表报错问题 (#8451) by @katherinehhh修复数据表字段分组排序设置不生效问题 (#8453) by @katherinehhh修复快捷便捷弹窗高度超出页面高度的问题 (#8437) by @zhangzhonghe修复表格行按钮的联动规则会影响弹窗表单按钮状态的问题 (#8434) by @zhangzhonghe修复切换分页时表格区块操作列状态污染的问题。 (#8438) by @gchust修复表格“列设置”按钮无效的问题 (#8441) by @zhangzhonghe修复关系文件快速编辑，选择文件的弹窗层级错误，无法保存弹窗配置的问题。 (#8446) by @gchust[flow-engine]修复 runjs 相关代码在运行前变量就被解析的问题。 (#8445) by @gchust修复数据选择器快速新增弹窗中无法选择弹窗变量的问题。 (#8450) by @gchust修复能够重复点击配置菜单打开多个配置弹窗的问题。 (#8448) by @gchust[移动端（已废弃）] 弃用移动端插件（2.0 后将使用 ui-layout 插件代替） (#8456) by @chenos[前端流引擎] 修复无法正确解析包含中划线字符的变量的问题。 (#8432) by @gchust[邮件管理] 修复邮箱配置弹窗被遮挡的问题 by @zhangzhonghev2.0.0-beta.12发布时间：2026-01-16🚀 优化[前端流引擎] 支持解析当前表单变量中未添加到编辑表单中的字段的值。 (#8436) by @gchust🐛 修复[flow-engine] 修复点击按钮打开弹窗时动态事件流里的步骤会执行两次的问题。 (#8435) by @gchust[模板打印] 2.0版本里显示空间字段 by @jiannxv2.0.0-beta.11发布时间：2026-01-15🚀 优化[evaluators] 升级 math.js 包的版本以支持更多函数 (#8411) by @mytharcher[client] 富文本编辑器支持字体大小调整，图片大小调整，软换行 (#8401) by @jiannx[AI 员工] 将工作流调用的结果改为从 execution.output 中获得，明确使用流程输出节点以获得稳定的结果 (#8423) by @mytharcher🐛 修复[client]为操作按钮的 schema 增加容错，避免点击后页面崩溃 (#8420) by @mytharcher修复表单关系字段标题设置附件 URL 后，再设置为其他字段时，标题设置项消失问题 (#8418) by @katherinehhh修复新增表单中关系字段设置阅读模式，切换标题字段不生效问题 (#8413) by @katherinehhh[前端流引擎] 修复 filterByTk 为数组时变量解析不正确的问题。 (#8412) by @gchust[模板打印] 支持空间字段 by @jiannxdevelopv2.0.0-alpha.66发布时间：2026-01-16🐛 修复[前端流引擎] 修复无法正确解析包含中划线字符的变量的问题。 (#8432) by @gchustv2.0.0-alpha.65发布时间：2026-01-16🎉 新特性[test] 为默认任务管理器添加进程级并发控制 (#8343) by @cgyrock🚀 优化[client]富文本编辑器支持字体大小调整，图片大小调整，软换行 (#8401) by @jiannx支持事件流指定执行时机。 (#8340) by @gchust通过改为使用 webkit 原生 CSS 展示文本省略号，优化插件管理器列表渲染性能 (#8391) by @mytharcher[evaluators] 升级 math.js 包的版本以支持更多函数 (#8411) by @mytharcher[cli] 支持通过环境变量配置 CDN 基础地址 (#8384) by @chenos[flow-engine] GridModel 新增 rowOrder 字段以确保行顺序的一致性 (#8371) by @zhangzhonghe[前端流引擎] 支持解析当前表单变量中未添加到编辑表单中的字段的值。 (#8436) by @gchust[AI 员工]优化 AI 员工主入口按钮 (#8414) by @heziqiang将工作流调用的结果改为从 execution.output 中获得，明确使用流程输出节点以获得稳定的结果 (#8423) by @mytharcher隐藏入口列表中的构建类 AI 员工； 优化 LLM 接入流程； 更新 Gemini-3 模型相关文档。 (#8409) by @heziqiang支持 Anthropic 和 Claude-4.5 (#8389) by @heziqiang[通知：站内信] 修复当发送站内信至大量用户时的性能问题 (#8402) by @mytharcher🐛 修复[client]修复快捷便捷弹窗高度超出页面高度的问题 (#8437) by @zhangzhonghe修复表格行按钮的联动规则会影响弹窗表单按钮状态的问题 (#8434) by @zhangzhonghe修复切换分页时表格区块操作列状态污染的问题。 (#8438) by @gchust为操作按钮的 schema 增加容错，避免点击后页面崩溃 (#8420) by @mytharcher修复新增表单中关系字段设置阅读模式，切换标题字段不生效问题 (#8413) by @katherinehhhinput number component does not display value (#8410) by @chenos修复表单关系字段标题设置附件 URL 后，再设置为其他字段时，标题设置项消失问题 (#8418) by @katherinehhh修复提交按钮同时设置二次确认和跳过必填校验时跳过必填校验不生效的问题 (#8400) by @katherinehhh修复网格卡片区块设置 layout 无冒号不生效问题 (#8399) by @katherinehhh修复新建表单中级联组件成功提交数据后，级联组件数据未清空 (#8403) by @katherinehhh修复表单中数字输入汉字时没有阻止赋值问题 (#8397) by @katherinehhh修复关系关联文件表中对一关系字段选择文件弹窗右下角出现提交按钮问题 (#8398) by @katherinehhh修复 targetKey 可选字段的处理逻辑 (#8333) by @katherinehhh[flow-engine] 修复点击按钮打开弹窗时动态事件流里的步骤会执行两次的问题。 (#8435) by @gchust[前端流引擎] 修复 filterByTk 为数组时变量解析不正确的问题。 (#8412) by @gchust[文件管理器] 修复上传至 S3 存储引擎的文件 URL 生成错误的问题 (#8392) by @mytharcher[数据表字段：多对多 (数组)] 修复关联查询时 append 的二级关联表是多对多（数组）时报错的问题 (#8406) by @cgyrock[工作流]修复复制工作流之后节点配置中的界面配置 ID 未被更新的问题 (#8396) by @mytharcher为节点执行记录的 Snowflake ID 加入实例 ID 配置，以避免集群下 ID 冲突问题 (#8382) by @mytharcher[区块：模板（已废弃）] 修复无法进入继承模板(v1)的编辑页面的问题。 (#8376) by @gchust[数据源：REST API] 为请求上下文增加容错，避免方法不存在时的报错 by @mytharcher[多空间]关联数据添加时关联空间 by @jiannx空间选择器颜色跟着主题 by @jiannx[模板打印]修复配置模板弹窗被遮挡的问题 by @zhangzhonghe支持空间字段 by @jiannx2.0 版本里显示空间字段 by @jiannx[文件存储：S3 (Pro)] 修复文件重命名模式不起作用的问题 by @mytharcher[工作流：审批]修复错误的参数导致的加载数据错误问题 by @mytharcher修复由于缺失 ValueBlock.Result 组件注入导致的值区块内容不展示的问题 by @mytharcher[邮件管理]修复会话链 by @jiannxadd filters to the management by @jiannx
n8n 是一款强大的开源低代码自动化工具，它允许你通过可视化节点的方式，将不同的服务和 API 串联起来，构建复杂的自动化工作流。与传统的自动化平台相比，n8n 拥有极高的自由度和扩展性，支持自托管部署，能够确保数据的完全私有化。在集成 AI 能力时，n8n 丰富的节点生态可以轻松对接 GPUStack 部署的本地大模型。这种组合不仅消除了昂贵的 API 调用费用，还确保了企业敏感数据在处理过程中始终留在本地，是构建私有化 AI 智能体的理想选择。接下来，我们将通过一个实战案例，演示如何将两者结合使用。🛠️ 演示环境GPUStack v2.0.3：请参考官方文档 https://docs.gpustack.ai 进行安装部署。n8n 最新版：推荐使用 Docker 快速部署，请参考官方指引 https://docs.n8n.io/hosting/installation/docker 。gpt-oss-120b：在 GPUStack 中部署，具备优秀并发能力。📖 工作流搭建1. 获取模型 API 凭证首先，我们需要获取模型的调用地址。在 GPUStack 的 Deployments 列表找到目标模型，通过右侧菜单点击 API Access Info。系统会弹出详细的接入信息，若尚未配置密钥，可直接点击窗口内的链接跳转至创建页。创建 API Key成功创建后，生成的 API Key 将作为 n8n 访问本地模型的安全凭证。由于 Key 仅在创建时显示一次，建议立即将其妥善保存。2. 配置 n8n 模型连接由于 GPUStack 兼容 OpenAI 协议，我们在 n8n 中直接添加一个 OpenAI API 类型的凭证即可。在配置窗口，填入刚才获取的 API Key 和 GPUStack 的接入地址。如果填入凭据信息无误，点击 Save 会提示 Connection tested successfully。关闭凭据配置窗口后，勾选 Limit models，指定该凭证仅使用特定的本地模型。3. 编排自动化工作流本节目标是搭建一个自动化链路：每天早上八点半定时触发，自动采集 RSS 源信息，并调用 AI 提取摘要发送至指定邮箱。创建空白 Workflow设置工作流的 First step node 为 On a schedule 类型配置触发时间为每天早上八点半添加 RSS Read 节点，这里以 https://36kr.com/feed 为例点击测试按钮，验证 RSS Read 节点是否正常工作双击 RSS Read 节点可查看执行日志和数据添加 Basic LLM Chain 节点，用于提取信息摘要在弹出的配置窗口中，配置 Source for Prompt (User Message) 为 Define below，然后拖动左侧面板 contentSnippet 字段到 Prompt (User Message) 输入框中继续在下方配置 System Prompt -> 你是一个资深科技编辑。请阅读下方的文章内容，提取摘要，要求字数精炼，直击本质。配置 LLM Model添加 Send Email 节点添加 Email 凭据，如下如所示，点击 Create new credential 会弹出配置窗口。此界面仅为示例，具体的 SMTP 配置信息（如服务器地址、端口、授权码）请参照你所使用邮箱服务的官方说明。配置收件人地址及邮件正文。作为初步演示，我们直接将模型输出的原始文本作为邮件内容。表达式无需手写，将字段拖拽到输入框即可。📊 效果验证点击 Execute Workflow 手动触发一次工作流。n8n 将抓取最新的 RSS 资讯，调用 GPUStack 进行推理生成摘要，最后通过 Send Email 节点发送邮件。注意：这一步不要着急实操，否则将一次性收到 30 封邮件！🤣执行完成如图所示：邮箱截图：💡 工作流优化上述流程中我们注意到，工作流每完整执行一次就会发送 30 封邮件，这显然不符合预期。我们期望将每条资讯压缩为一句话摘要，再将所有摘要汇总为一个列表，以单封邮件的形式发送，并对展示样式进行统一美化。修改 Basic LLM Chain 节点上的系统提示词，指导其直接输出一个 list item你是一个资深科技编辑。请将用户输入的文章内容总结为一条简练的 HTML 列表项（ ... ），包含标题和核心要点。 格式示例： 标题：核心要点摘要 要求： 1. 仅输出 标签及其内容，不要包含 或其他 markdown 格式。 2. 摘要控制在 50 字以内。在 Basic LLM Chain 与 Send Email 节点之间插入一个 Code 节点，用于将分散的摘要聚合为美观的 HTML 格式。在后续弹出的菜单中，根据自己偏好选择 Code in JavaScript / Code in Python (Native)。本文以 Code in JavaScript 为例。在弹出的配置面板中，填入如下 JavaScript Code：⚠️ 注意：在微信公众号中直接复制以下代码时，普通空格可能会被替换成不换行空格 (NBSP)，粘贴后请务必检查并手动替换回普通空格！// 获取所有 LLM 节点的输出项 const items = $input.all(); // 定义 CSS 样式 const style = { container: "font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; max-width: 600px; margin: 0 auto; padding: 20px; background-color: #f9f9f9; border-radius: 10px; border: 1px solid #e0e0e0;", header: "color: #2c3e50; border-bottom: 2px solid #3498db; padding-bottom: 10px; margin-bottom: 20px; font-size: 24px;", list: "list-style-type: none; padding: 0;", listItem: "background-color: #ffffff; margin-bottom: 15px; padding: 15px; border-radius: 8px; box-shadow: 0 2px 4px rgba(0,0,0,0.05); line-height: 1.6; color: #555;", footer: "margin-top: 30px; font-size: 12px; color: #999; text-align: center; border-top: 1px solid #e0e0e0; padding-top: 10px;" }; // 构建 HTML 内容 let htmlContent = ` `; htmlContent += ` 📅 每日科技资讯摘要 `; htmlContent += ` `; for (const item of items) { if (item.json.text) { // 为 item 添加样式 let styledItem = item.json.text.replace(' ', ` `); htmlContent += styledItem + "\n"; } } htmlContent += ` `; htmlContent += ` Generated by n8n & GPUStack • ${new Date().toLocaleDateString()} `; htmlContent += ` `; // 返回合并后的单一结果供邮件节点使用 return [{ json: { email_content: htmlContent } }];更新 Send Email 节点n8n 支持在 {{ }} 中编写 JavaScript 表达式。这里我们使用 {{ $now.format('yyyy-MM-dd') }}，以便在邮件主题中自动附带当天的日期信息。最终效果修改完成，重新运行，最终效果如下所示保存工作流并发布至此，工作流部署完成。只要 n8n 服务保持运行，系统将按照预设在每天早上 8:30 触发执行，并在处理完成后自动发送资讯摘要邮件。📈 总结通过本文的实战，我们成功利用 n8n 和 GPUStack 搭建了一套全自动、零成本的 AI 资讯助手。从 RSS 抓取到 AI 摘要再到邮件推送，整个流程完全运行在本地环境中，既保护了数据隐私，又规避了高昂的 API 调用成本。最后，别忘了打开 GPUStack Dashboard 概览页。你可以直观地查看指定模型在一段时间内的 Token 消耗详情（包括 Prompt 和 Completion）以及 API 请求总数，真正掌握 AI 服务的运行状况。🙌 欢迎加入我们的社区如果二维码失效，大家可前往 GPUStack 项目获取最新入群二维码 https://github.com/gpustack/gpustack/blob/main/docs/assets/wechat-group-qrcode.jpg
最新消息，Apache DolphinScheduler 3.4.0 已正式发布！本次版本带来了多租户调度隔离、工作流并行性能优化、任务重试与告警机制增强，以及资源管理和日志处理改进。无论是复杂企业业务场景，还是高并发任务调度，3.4.0 都让系统更高效、更可靠、更易用。立即升级，体验全新调度能力！升级与下载下载页面（可选择镜像下载）：https://dolphinscheduler.apache.org/zh-cn/download/3.4.0GitHub Release 页面：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0升级时建议参考官方文档中的集群升级指南，确保兼容性和配置一致性。核心功能增强与重要更新通用 OIDC 认证支持3.4.0 引入了对 OpenID Connect（OIDC）的通用支持，旨在简化与企业身份认证系统的集成。通过 OIDC，用户可以使用统一的身份提供商（如 Keycloak、Okta 等）进行 SSO 登录，无需额外实现复杂自定义逻辑。这提升了安全性和用户体验，尤其是在多系统联邦登录与统一认证场景中，能够使 DolphinScheduler 更自然地融入企业级认证体系，减少重复配置和验证成本，从而提高登录配置的扩展性和一致性。（参考图）gRPC 任务插件支持本版本新增了 gRPC 任务插件能力，使调度器能够通过原生 gRPC 协议直接与远程服务交互。用户可以将后端微服务暴露的 gRPC 接口作为任务执行目标，无需中间脚本封装。这种方式特别适合微服务生态或跨语言执行场景，通过明确参数契约和高性能通信协议提升任务整合效率，从而减少资源调度延迟、提高任务可靠性。支持工作流串行策略实现了 工作流串行执行策略（Workflow Serial Strategy） 的核心逻辑重构，通过引入一个全新的串行命令队列机制（t_ds_serial_command 表及相关 DAO/Mapper），配合一套串行执行协调器（WorkflowSerialCoordinator）及策略处理器，使 DolphinScheduler 能更智能地管理串行类型的工作流（如 SERIAL_WAIT、SERIAL_PRIORITY、SERIAL_DISCARD）。该设计改进了工作流触发流程的执行类型判断、状态管理、命令队列处理等关键路径，使串行调度逻辑更清晰、更可靠，有助于提升串行工作流场景下的调度稳定性与可控性。同时，3.4.0 重构了触发器与状态机相关代码，增强该能力的可维护性和扩展性。移除 PyTorch 任务类型3.4.0 对任务类型体系进行了精简，正式移除了内置的 PyTorch 任务类型。该调整主要基于实际使用情况和长期维护成本的考量，因为原有 PyTorch 任务实现使用率较低，且与调度器核心任务模型耦合度较高，增加了版本演进和兼容性维护的复杂度。通过移除该任务类型，DolphinScheduler 能保持核心架构的简洁与稳定。我们鼓励用户通过更通用的 Shell、Python 或插件化方式运行 PyTorch 作业，从而提升系统整体的可维护性和扩展性。稳定性与重要修复Kubernetes Worker 部署增强在 Kubernetes 原生部署场景下，3.4.0 使 Worker StatefulSet 的 Helm Chart 支持注入 Secrets 和 InitContainers。通过 Secrets 注入，可以安全传递证书或凭据；InitContainers 允许在主容器启动前完成必要的初始化逻辑，如准备文件系统或校验环境依赖。这些增强有助于在容器化环境下实现更安全、更一致的部署策略和生命周期管理。SQL 任务取消能力针对 SQL 任务类型，本次版本提供了对任务执行取消的原生支持。当执行的 SQL 语句由于逻辑错误或长期运行导致资源占用时，用户可以通过调度器下发取消操作，使任务尽快中止，而不是简单失败或等待超时。这一能力改善了任务控制能力，避免长时间运行对集群资源的无效占用，有助于提升整体资源利用率和执行调度体验。条件任务节点在前置失败情况下执行逻辑修复在某些复杂工作流中，当条件任务节点的前置任务失败时，条件节点未按预期执行。3.4.0 修复了这一调度核心逻辑，确保条件节点能够正确响应前置失败状态。这样，工作流分支逻辑能够按照既定 DAG 定义可靠运行，从而避免因逻辑错误导致的流程中断或不一致执行。ZooKeeper 节点清理问题修复在使用 ZooKeeper 作为协调组件的高可用部署中，部分用户反馈 Master Server 在启动失败后未正确清理已注册的 failover 节点路径，可能导致后续状态异常。该版本修复了这个问题，使 Master 在异常启动路径中能够正确清理关联注册节点，保持注册中心状态一致，确保高可用场景下集群状态的健康和可靠性。Worker Group 分配逻辑错误修复此前版本中，项目与 Worker Group 关联/移除操作可能在 API 层出现逻辑不一致，导致调度器未能正确识别项目与 Worker Group 的关系。本次版本修正了相关逻辑，使 API 行为与用户预期一致，从而改善 Worker 管控、资源隔离和调度分配体验。此外，3.4.0 版本还进行了很多功能优化和问题修复，包括文档与配置规范完善（时区、安全、负载均衡）、核心调度与注册中心稳定性增强（TraceId、Failover 清理、可重入锁）、性能与资源管理优化（任务组索引）、前端与插件体验改进（日志查询、DataX 校验、文件展示）、依赖与安全更新（PostgreSQL JDBC、Spring Boot CVE 修复）等，篇幅所限不再一一展开，详情可查询完整更新列表：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0Bug 修复亮点标记任务为 Inactive 状态逻辑修复某些生命周期事件中，当任务状态需要被标记为 Inactive 时，状态变更可能未正确触发，导致 UI 和执行引擎状态不一致。此版本修复了这一逻辑，使状态标记与生命周期事件更加一致。Workflow Lineage 删除逻辑优化在工作流血缘关系删除操作中，系统可能未能彻底清理相关引用，导致历史血缘链路残留。3.4.0 改进了删除逻辑，使 DolphinScheduler 在删除血缘链时能够更精确地清理对应关系，避免分析后续依赖时出现错误链路。其他 Bug 修复包括前置任务失败导致条件节点不执行问题修复、项目级 Worker Group 绑定与移除逻辑修正、子工作流触发参数丢失问题修复等，详情请查询完整 Release Note：https://github.com/apache/dolphinscheduler/releases/tag/3.4.0文档更新发布并完善 Apache DolphinScheduler 3.3.2 版本发布说明文档。修复文档 CI 构建错误，提升文档发布流程的稳定性。补充 Prometheus 指标接口的认证机制及其在 Kubernetes 环境下的使用说明。同步更新 JdbcRegistry 引入事务机制后的相关文档描述，保证文档与实际行为一致。致谢本次版本发布离不开社区各位贡献者的热情参与与支持。特别感谢 @ Gallardot 作为 3.4.0 的 Release Manager，从版控、构建、候选版验证到最终投票组织，确保发布流程高质量推进。同时，感谢以下本次版本的所有贡献者（GitHub ID，排名不分先后）：Gallardot、njnu‑seafish、det101、Mrhs121、EinsteinInIct、sanfeng‑lhh、ruanwenjun、tusaryan、qiong‑zhou、SbloodyS、kvermeulen、npofsi、CauliflowerEater、ChaoquanTao、dill21yu、sdhzwc、zhan7236、KwongHing、jmmc‑tools、liunaijie感谢所有通过提交 PR、Issue、文档贡献、社区讨论、测试验证等方式参与 Apache DolphinScheduler 项目的人。正是你们的努力推进了 DolphinScheduler 的持续演进与社区繁荣，欢迎更多人加入我们的队伍！
DolphinScheduler 3.1.9 + Minio 开发环境【IDEA】搭建访问及相关问题处理
目录DolphinScheduler 3.1.9 开发环境【IDEA】搭建访问前提1、软件要求2、克隆代码库3、编译源码DolphinScheduler 普通开发模式1、编译问题：2、启动zookeeper官方内容存储配置启动脚本3、workspace.xml 修改4、数据库4-1：数据初始化4-2：依赖相关修改5、application.yaml 修改数据库配置5-1：dolphinscheduler-master5-2：dolphinscheduler-worker5-3：dolphinscheduler-api6、logback-spring.xml 修改日志级别6-1：dolphinscheduler-master6-2：dolphinscheduler-worker6-3：dolphinscheduler-api7、启动后端三个服务7-1：MasterServer配置 VM Options7-2：WorkerServer配置 VM Options7-3：ApiApplicationServer配置 VM Options8、启动前端服务命令：9、浏览器访问账号密码：成功访问：相关问题1、存储未启用、租户\\用户 指定解决方法：1、minio 创建 dolphinscheduler 桶2、commom.properties 修改3、dolphinscheduler 可视化页面添加租户用户添加租户演示创建文件夹、上传文件成功这里按照官方提供的文档进行操作：前提官方提供的开发手册位置1、软件要求在搭建 DolphinScheduler 开发环境之前请确保你已经安装以下软件:GitJDK: v1.8.x (当前暂不支持 jdk 11)Maven: v3.5+Node: v16.13+ (dolphinScheduler 版本低于 3.0, 请安装 node v12.20+)Pnpm: v6.x2、克隆代码库通过你 git 管理工具下载 git 代码，下面以 git-core 为例mkdir dolphinscheduler cd dolphinscheduler git clone git@github.com:apache/dolphinscheduler.git3、编译源码支持的系统: * MacOS * Linux 【这个我没有运行试试】 运行 `mvn clean install -Prelease -Dmaven.test.skip=true`DolphinScheduler 普通开发模式上面是官方提供的，我觉得有用就复制下来，这里开始我就按照自己的操作顺序记录1、编译问题：1、git相关 1-1：开启 Windows Git 长路径支持， 管理员 PowerShell 执行，解决 DolphinScheduler 路径太深导致 git add 失败 git config --system core.longpaths true 1-2：先初始化git仓库，只在本地，不涉及账号、不推远程，Spotless 需要 HEAD git init git add . git commit -m "initial commit" 2、Maven 编译 / 格式化（IDEA 里的 Terminal） 2-1：依赖 Git HEAD，自动修复格式问题 mvn spotless:apply 2-2：编译整个项目（跳过测试），确保所有模块已 install mvn clean install -DskipTests 3、前端相关： 查看 Node.js 是否已安装 node -v 查看 npm 版本 npm -v 安装 pnpm npm install -g pnpm pnpm -v编译都没有问题2、启动zookeeper官方内容下载 ZooKeeper，解压存储配置启动脚本搞个txt编辑完后，后缀该bat即可@echo off echo 正在启动 ZooKeeper... cd /d E:\\install\\ZooKeeper\\zookeeper-3.8.3\\bin zkServer.cmd pause3、workspace.xml 修改【可以不用，我也是看其他文章有添加的，不过我没添加也能正常运行，这里只做记录】在其他文章看到说在这里添加这行，说是让 IDEA 在运行时动态使用模块的 classpath，而不是用启动时生成的静态 classpath。 注意点： 这个作用只会影响本地 IDEA 启动，线上环境如果有问题这个是解决不了的。 "dynamic.classpath": "true",4、数据库我这里用的是mysql，所以需要修改4-1：数据初始化创建名为【dolphinscheduler】的新数据库后， 把这个位置的sql直接拷贝复制执行即可。如图：4-2：依赖相关修改如果使用 MySQL 作为元数据库，需要先修改 `dolphinscheduler/pom.xml`， 将 `mysql-connector-java` 依赖的 `scope` 改为 `compile`， 使用 PostgreSQL 则不需要 test 改成 compile5、application.yaml 修改数据库配置5-1：dolphinscheduler-master如图，配置文件中修改这些数据：三个内容都是一样的 spring: config: activate: on-profile: mysql datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/dolphinscheduler?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8 username: 账户名 password: 数据库密码5-2：dolphinscheduler-worker5-3：dolphinscheduler-api6、logback-spring.xml 修改日志级别6-1：dolphinscheduler-master<appender-ref ref="STDOUT"/>6-2：dolphinscheduler-worker6-3：dolphinscheduler-api7、启动后端三个服务我们需要启动三个服务，包括 MasterServer，WorkerServer，ApiApplicationServer * MasterServer：在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.server.master.MasterServer` 中的 `main` 方法，并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql` * WorkerServer：在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.server.worker.WorkerServer` 中的 `main` 方法，并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql` * ApiApplicationServer：在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.api.ApiApplicationServer` 中的 `main` 方法，并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Dspring.profiles.active=api,mysql`。启动完成可以浏览 Open API 文档，地址为 http://localhost:12345/dolphinscheduler/swagger-ui/index.html > VM Options `-Dspring.profiles.active=mysql` 中 `mysql` 表示指定的配置文件7-1：MasterServer配置 VM Options按照操作配置这个：打开后填入即可 -Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql7-2：WorkerServer配置 VM Options跟上面一样操作：-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql7-3：ApiApplicationServer配置 VM Options-Dlogging.config=classpath:logback-spring.xml -Dspring.profiles.active=api,mysql总的就这三个：8、启动前端服务命令：安装前端依赖并运行前端组件 cd dolphinscheduler-ui pnpm install pnpm run dev9、浏览器访问账号密码：浏览器访问： http://localhost:5173/home 默认账号密码： 账号：admin 密码：dolphinscheduler123 成功访问：相关问题1、存储未启用、租户\用户 指定问题：测试能否创建文件夹、上传文件等，提示【存储未启用】问题：当前登录用户的租户信息未被指定解决方法：Minio 安装、启动我这里直接用minio来尝试：1、minio 创建 dolphinscheduler 桶2、commom.properties 修改配置文件改了这些地方# Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information regarding copyright ownership. # The ASF licenses this file to You under the Apache License, Version 2.0 # (the "License"); you may not use this file except in compliance with # the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # # user data local directory path, please make sure the directory exists and have read write permissions data.basedir.path=/tmp/dolphinscheduler # resource view suffixs #resource.view.suffixs=txt,log,sh,bat,conf,cfg,py,java,sql,xml,hql,properties,json,yml,yaml,ini,js # resource storage type: HDFS, S3, OSS, NONE # ljh --> S3 is Minio-------------------------------------- resource.storage.type=S3 # resource store on HDFS/S3 path, resource file will store to this base path, self configuration, please make sure the directory exists on hdfs and have read write permissions. "/dolphinscheduler" is recommended resource.storage.upload.base.path=/dolphinscheduler # ljh --> The account and password of MinIO------------------------------- # The AWS access key. if resource.storage.type=S3 or use EMR-Task, This configuration is required resource.aws.access.key.id=minioadmin # The AWS secret access key. if resource.storage.type=S3 or use EMR-Task, This configuration is required resource.aws.secret.access.key=minioadmin # The AWS Region to use. if resource.storage.type=S3 or use EMR-Task, This configuration is required resource.aws.region=cn-north-1 # ljh --> add bucket ------------------------------ # The name of the bucket. You need to create them by yourself. Otherwise, the system cannot start. All buckets in Amazon S3 share a single namespace; ensure the bucket is given a unique name. resource.aws.s3.bucket.name=dolphinscheduler # You need to set this parameter when private cloud s3. If S3 uses public cloud, you only need to set resource.aws.region or set to the endpoint of a public cloud such as S3.cn-north-1.amazonaws.com.cn # ljh --> localhost convert 127.0.0.1 resource.aws.s3.endpoint=http://127.0.0.1:9000 # alibaba cloud access key id, required if you set resource.storage.type=OSS resource.alibaba.cloud.access.key.id=<your-access-key-id> # alibaba cloud access key secret, required if you set resource.storage.type=OSS resource.alibaba.cloud.access.key.secret=<your-access-key-secret> # alibaba cloud region, required if you set resource.storage.type=OSS resource.alibaba.cloud.region=cn-hangzhou # oss bucket name, required if you set resource.storage.type=OSS resource.alibaba.cloud.oss.bucket.name=dolphinscheduler # oss bucket endpoint, required if you set resource.storage.type=OSS resource.alibaba.cloud.oss.endpoint=https://oss-cn-hangzhou.aliyuncs.com # if resource.storage.type=HDFS, the user must have the permission to create directories under the HDFS root path resource.hdfs.root.user=hdfs # if resource.storage.type=S3, the value like: s3a://dolphinscheduler; if resource.storage.type=HDFS and namenode HA is enabled, you need to copy core-site.xml and hdfs-site.xml to conf dir resource.hdfs.fs.defaultFS=hdfs://mycluster:8020 # whether to startup kerberos hadoop.security.authentication.startup.state=false # java.security.krb5.conf path java.security.krb5.conf.path=/opt/krb5.conf # login user from keytab username login.user.keytab.username=hdfs-mycluster@ESZ.COM # login user from keytab path login.user.keytab.path=/opt/hdfs.headless.keytab # kerberos expire time, the unit is hour kerberos.expire.time=2 # resourcemanager port, the default value is 8088 if not specified resource.manager.httpaddress.port=8088 # if resourcemanager HA is enabled, please set the HA IPs; if resourcemanager is single, keep this value empty yarn.resourcemanager.ha.rm.ids=192.168.xx.xx,192.168.xx.xx # if resourcemanager HA is enabled or not use resourcemanager, please keep the default value; If resourcemanager is single, you only need to replace ds1 to actual resourcemanager hostname yarn.application.status.address=http://ds1:%s/ws/v1/cluster/apps/%s # job history status url when application number threshold is reached(default 10000, maybe it was set to 1000) yarn.job.history.status.address=http://ds1:19888/ws/v1/history/mapreduce/jobs/%s # datasource encryption enable datasource.encryption.enable=false # datasource encryption salt datasource.encryption.salt=!@#$%^&* # data quality option data-quality.jar.name=dolphinscheduler-data-quality-dev-SNAPSHOT.jar #data-quality.error.output.path=/tmp/data-quality-error-data # Network IP gets priority, default inner outer # Whether hive SQL is executed in the same session support.hive.oneSession=false # use sudo or not, if set true, executing user is tenant user and deploy user needs sudo permissions; if set false, executing user is the deploy user and doesn't need sudo permissions sudo.enable=true setTaskDirToTenant.enable=false # network interface preferred like eth0, default: empty #dolphin.scheduler.network.interface.preferred= # network IP gets priority, default: inner outer #dolphin.scheduler.network.priority.strategy=default # system env path #dolphinscheduler.env.path=dolphinscheduler_env.sh # development state development.state=false # rpc port alert.rpc.port=50052 # set path of conda.sh conda.path=/opt/anaconda3/etc/profile.d/conda.sh # Task resource limit state task.resource.limit.state=false # mlflow task plugin preset repository ml.mlflow.preset_repository=https://github.com/apache/dolphinscheduler-mlflow # mlflow task plugin preset repository version ml.mlflow.preset_repository_version="main" # ljh --> minio must open path style resource.aws.s3.path.style.access=true 3、dolphinscheduler 可视化页面添加租户安全中心 - 租户管理 - 创建租户用户添加租户演示创建文件夹、上传文件成功如图，数据已经存放在我指定的minio文件夹里面了
导读AI 编码工具正在从"智能补全"演进为能自主完成复杂任务的 Coding Agent。本文基于开源项目源码研究与实践经验，系统性地拆解 Coding Agent 的工作原理。旨在帮助开发者在了解Coding Agent后，与AI伙伴更好的协作配合，更高效的提问和拿到有效结果。01 背景AI 编码工具的发展速度快得有点"离谱"。从开始使用 GitHub Copilot 的代码补全，到使用Claude Code、Cursor、Comate IDE等完成复杂编程任务，AI 不再只是个「智能补全工具」，它能读懂你的代码库、执行终端命令、甚至帮你调试问题，成为你的“编码伙伴”。我自己在团队里推 AI 编码工具的时候，发现一个很有意思的现象：大家都在用，但很少有人真正理解它是怎么工作的。有人觉得它"很神奇"，有人吐槽它"经常乱来"，还有人担心"会不会把代码搞乱"。这些困惑的背后,其实都指向同一个问题：我们对这个"伙伴"还不够了解。就像你不会无脑信任一个新来的同事一样，要和 AI 编码伙伴配合好，你得知道它的工作方式、能力边界、以及怎么"沟通"才更有效。在经过多次的实践尝试后，我尝试探索它的底层原理，并写下了这篇文章记录，主要围绕了这些内容展开：Coding Agent 的核心工作机制，包括身份定义、工具调用、环境感知等基础组成。从零实现一个最小化 Coding Agent 的完整过程，以建立对 Agent 工作流程的直观理解。上下文管理、成本控制、冲突管控等生产环境中的关键技术问题及其解决方案。Rule、MCP、Skill 等能力扩展机制的原理与应用场景。在了解原理后，我和伙伴的协作更佳顺畅，让伙伴更清晰的了解我的意图，我拿到有效的回答。02 概念2.1 从Workflow到Agent取一个实际的例子：休假申请。如果我们的需求非常简单：一键申请明天的休假。这个需求可以被简化为一个固定的工作流：打开网页。填写起始时间。填写结束时间。填写休假原因。提交表单。全过程没有任何模糊的输入，使用程序化即可完成，是最原始的工作流形态。如果需求再模糊一些：申请后天开始3天休假。这个需求的特点是没有明确的起始和截止时间，需要从语义上分析出来：起始时间：后天。休假时长：3天。转换日期：10.14 - 10.16。执行申请：提交表单。这是一个工作流中使用大模型提取部分参数的典型案例，是模型与工作流的结合。如果需求更加模糊：国庆后休假连上下个周末。这样的需求几乎没有任何直接确定日期的信息，同时由于年份、休假安排等动态因素，大模型不具备直接提取参数的能力。将它进一步分解，需要一个动态决策、逐步分析的过程：知道当前年份。知道对应年份的国庆休假和调休安排。知道国庆后第一天是星期几。国庆后第一天到下个周末设为休假日期。额外补充调休的日期。填写并提交表单。可以看出来，其中1-5步都是用来最终确定休假日期的，且需要外部信息输入，单独的大模型无法直接完成工作。这是一个典型的Agent流程，通过大模型的智能与工具访问外部信息结合实现用户需求。2.2 什么是AgentAgent是以大模型为核心，为满足用户的需求，使用一个或多个工具，自动进行多轮模型推理，最终得到结果的工作机制。2.3 什么是Coding Agent在Agent的基本定义的基础上，通过提示词、上下文、工具等元素强化“编码”这一目的，所制作的特化的Agent即为Coding Agent。Coding Agent的最大特征是在工具的选取上，模拟工程师进行代码编写的环境，提供一套完整的编码能力，包括：阅读和查询代码：读取文件，对应 cat 命令。查看目录结构，对应 tree 命令。通配符查找，对应 ls命令（如 **/*.test.ts 、src/components/**/use*.ts）。正则查找，对应grep 命令（如function print\(.+\) 可以找函数定义）。LSP（Language Server Protocol），用于提供查找定义、查找引用、检查代码错误等能力。编写或修改代码：写入文件。局部编辑文件。删除文件。执行或交互命令：执行终端命令。查看终端命令stdout输出。向终端命令stdin 输入内容。除此之外，通常Coding Agent还具备一些强化效果而设定的工具，通常表现为与Agent自身或外部环境进行交互，例如经常能见到的TODO、MCP、Subagent等等。03 内部组成3.1 上下文结构3.2 身份定义一个Agent首先会将模型定义成一个具体的身份（红色与橙色部分），例如在社区里常见的这样的说法：You are a Senior Front-End Developer and an Expert in React, Nexts, JavaScript, TypeScript, HTML, CSS and modern UI/UX frameworks.在身份的基础上，再附加工作的目标和步骤拆解，比如Cline有类似这样的内容：https://github.com/cline/cline/blob/4b9dbf11a0816f792f0b3229a08bbb17667f4b73/src/core/prompts/system-prompt/components/objective.tsAnalyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Then, think about which of the provided tools is the most relevant tool to accomplish the user's task. Next, go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params). DO NOT ask for more information on optional parameters if it is not provided.Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. open index.html to show the website you've built.The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.不用特别仔细地看每一句话，多数Coding Agent会提供一些详实的行动准则、目标要求，这部分称为“Guideline”。有一些Coding Agent可以在多种模式（或者说智能体）之间进行切换，例如Cursor有Edit、Ask、Plan等，RooCode有Architect、Orchestrator等，有些产品还支持自定义模式。CursorRooCode选择不同的模式时，实际上会产生不同的目标要求、行为准则，即不同的Guideline环节。因此系统提示词中的身份部分，通常会分成不变的Base Prompt（红色）和可变的Agent Prompt（橙色）两个部分来管理，实际开始任务时再拼装起来。3.3 工具调用Agent的另一个最重要的组成部分是工具，没有工具就无法称之为一个Agent。让Agent能够使用工具，就必须要有2部分信息：有哪些工具可以用，分别是什么作用。如何指定使用一个工具。对于第一点（哪些工具），在Agent开发过程中，一般视一个工具为一个函数，即由以下几部分组成一个工具的定义：名称。参数结构。输出结构。实际在调用模型时，“输了结构”往往是不需要提供给模型的，但在Agent的实现上，它依然会被预先定义好。而“名称”和“参数结构”会统一组合成一个结构化的定义，通常所有工具都只接收1个参数（对象类型），用JSON Schema表示参数结构。一个典型的工具定义：{ "name": "read", "description": "Read the contents of a file. Optionally specify line range to read only a portion of the file.", "parameters": { "type": "object", "properties": { "path": { "type": "string", "description": "The file path to read from" }, "lineStart": { "type": "integer", "description": "The starting line number (1-indexed). If not specified, reads from the beginning of the file." }, "lineEnd": { "type": "integer", "description": "The ending line number (1-indexed). If not specified, reads to the end of the file." } }, "required": ["path"] } }可以简单地把这个工具理解成对应的TypeScript代码：interface ReadToolParameter { path: string; lineStart?: number; lineEnd?: number; } async function read(parameters: ReadToolParameter) { // 工具实现 }对于第2点（指定使用工具），则是要让大模型知道工具调用的具体格式。这在业界通常有2种做法。第1种以Claud Code、Codex等为典型，使用大模型提供的Function Calling格式调用，分为以下几步：在调用大模型时，通过一个tools 字段传递所有的工具定义。模型会返回一个消息中包含tool_calls 字段，里面每一个对象是一个工具的调用，使用id 作为唯一标识。工具产生的结果，以一条role: 'tool' 的消息返回，其中tool_call_id 与调用的id对应，content 是工具的结果（这里各家模型厂商的实现略有不同，其中Anthropic要求role: user，但content字段中传递toolResult，其结构是[{type: 'tool_result',tool_use_id: toolBlock.id, content: toolResultContent}],tool_use_id与调用的id对应）。第2种方式是以Cline、RooCode为典型，使用一种自定义的文本格式来表示工具调用，通常选择XML的结构，例如对于Cline，读取一个文件的结构如下：<read_file> <path>src/index.ts</path> </read_file>只要在模型返回的消息中出现这样的结构，就会被解析为一个工具调用，得到的结果以普通的role: 'user' 的消息返回，包括实际内容和一些提示相关的信息。Content of src/index.ts: Note: - this file is truncated to line 1000, file has a total 2333 lines. - use read_file with line_start and line_end parameters to read more content. - use seach_in_files tool searching for specific patterns in this file. ...3.4 环境感知Coding Agent之所以可以在一个代码库上执行任务，除了通过工具来遍历、检索代码外，另一个因素是Agent实现会在调用模型时主动地提供一部分与项目有关的信息。其中对Coding Agent工作最有用的信息之一是代码库的结构，即一个表达出目录、文件结构的树型区块。这部分信息通常会符合以下特征：尽可能地保留目录的层级结构，使用换行、缩进的形式表达。遵循 .gitignore 等项目配置，被忽略的文件不会表现在树结构中。当内容过多时，有一定的裁剪的策略，但同时尽可能多地保留信息。以Cursor为例，这部分的内容大致如下：<project_layout> Below is a snapshot of the current workspace's file structure at the start of the conversation. This snapshot will NOT update during the conversation. It skips over .gitignore patterns. codex-cursor/ - AGENTS.md - CHANGELOG.md - cliff.toml - codex-cli/ - bin/ - codex.js - rg - Dockerfile - package-lock.json - package.json - scripts/ - build_container.sh - build_npm_package.py - init_firewall.sh - [+4 files (1 *.js, 1 *.md, 1 *.py, ...) & 0 dirs] - codex-rs/ - ansi-escape/ - Cargo.toml - README.md - src/ - lib.rs </project_layout>当内容数量超过阈值时，会采用广度优先的保留策略（即尽可能地保留上层目录结构），同时对于被隐藏的文件或子目录，会形如 [+4 files (1 *.js, 1 *.md, 1 *.py, ...) & 0 dirs]这样保留一个不同文件后缀的数量信息。除了目录结构外，还有一系列默认需要模型感知的信息，在一个Coding Agent的工作环境中，它通常分为2大类，各自又有一系列的细项：系统信息：操作系统（Windows、macOS、Linux，具体版本）。命令行语言（Shell、Powershell、ZSH）。常见的终端命令是否已经安装（ python3 、node 、jq 、awk等，包含具体版本）。代码库目录全路径。为Agent扩展能力的信息：Rule（自动激活的部分）。Skill（摘要描述部分）。MCP（需要的Server和Tool列表）。Memory（通常是全量）。需要注意的是，环境信息这部分，一般不出现在系统提示词中，而是和用户提问的消息放置在一起。3.5 简单实现在身份定义、工具调用、环境感知这3部分最基础的Agent组成都达成后，简单地使用大模型的API，进行自动化的工具调用解析、执行、发送新一轮模型调用，可以非常简单地实现一个最小化的Coding Agent。可以尝试用以下的提示词，使用任意现有的Coding Agent产品，为你编写一个实现，并自己调试一下，感受Coding Agent的最基础的逻辑：我希望基于大模型实现一个Coding Agent，以下是我的具体要求： 1. 使用Claude作为模型服务商，使用环境变量管理我的API Key。 2. 默认使用Claude Sonnet 4.5模型。 3. 使用Anthropic's Client SDK调用模型。 4. 不需要支持流式输出。 5. 使用TypeScript编写。 以下是Agent提供的工具： 1. read({path: string})：读取一个文件的内容 2. list({directory: string})：列出一个目录下的一层内容，其中目录以`/`结尾 3. write({path: string, content: string})：向文件写入内容 4. edit({path: string, search: string, replace: string})：提供文件中的一块内容 以下是交互要求： 1. 通过NodeJS CLI调用，支持`query`和`model`两个参数，可以使用`yargs`解析参数。 2. 在System消息中，简短地说明Coding Agent的角色定义、目标和行为准则等。 3. 在第一条User消息中，向模型提供当前的操作系统、Shell语言、当前目录绝对路径信息，同时包含跟随`query`参数的内容，组织成一条模型易于理解的消息。 4. 对每一次模型的工具调用，在控制台打印工具名称和标识性参数，其中标识性参数为`path`或`directory`，根据工具不同来决定。 5. 如果模型未调用工具，则将文本打印到控制台。 请在当前目录下建立一个`package.json`，并开始实现全部的功能。04 优质上下文工程4.1 成本控制大模型是一个非常昂贵的工具，以Claude为例，它的官方API价格如下：我们可以观察到一些特征：输出的价格是输入的5倍（但实际考虑到输出与输出的数量比例，输出的价格根本不值一提）。缓存输入（Cache Writes）比正常输入（Base Input）更贵一些，约1.25倍。缓存命中（Cache Hits）的价格比正常输入（Base Input）要便宜很多，为1/10的价格。这就意味着，一个良好使用缓存的Agent实现，其成本会比不用缓存降低8-10倍。因此所有的Coding Agent一定会细致地梳理内容结构，最大化利用缓存。在大模型的API中，缓存通常以“块”为单位控制，例如：系统提示词中不变的部分。系统提示词中可变部分。工具定义。每一条消息，单条消息也可以拆成多个块。继续观察Claude对于缓存控制的文档：可以看到，在大模型API中各种参数一但有所变动，缓存都会大量失效（至少消息缓存全部失效，大概率系统缓成失效），这就会造成成本的极大提升。因此，在Coding Agent实现中，都会从一开始就确定所有参数，整个任务不做任何变更。一些很经典的实例：一次任务不会一部分消息开思考模式，一部分不开，因为思考参数会让全部的消息缓存失效。切换不同模式（如Edit、Ask、Plan）时，虽然能使用的工具不同，但只是在消息中增加说明，而不会真的将 tools 字段改变。另外，Coding Agent会尽可能保持历史消息内容完全不变，以最大化地缓存消息。例如对于一个进行了10轮模型调用的任务，理论上第10次调用中，前9轮的消息内容都会命中缓存。但如果此时擅自去修改了第1轮的工具调用结果（例如试图删除读取的文件内容），看似可能消息的长度减少了，但实际因为缓存被破坏，造成的是10倍的成本提升。总而言之，缓存是一个至关重要的因素，Coding Agent的策略优化通常以确保缓存有效为前提，仅在非常必要的情况下破坏缓存。4.2 空间管理Coding Agent因为会自动地与大模型进行多轮的交互，随着不断地读入文件、终端命令输出等信息，上下文的长度会变得非常的大，而大模型通常只具备128K左右的总长度，因此如何将大量内容“适配”到有限的长度中，是一个巨大的挑战。控制上下文长度的第一种方式是“裁剪”，即在整个上下文中，将没用的信息删除掉。试想如下的场景：模型读取了一个文件的内容。模型将文件中 foo 这一行改成了 bar 。模型又将文件中 eat 这一行改成了 drink 。假设我们对模型每一次修改文件，都返回最新的文件内容，如果这个文件有1000行，那么1次读取、2次修改，就会产生3000行的空间占用。一种优化方式就是，在这种连续的读-改的场景下，只保留最后一条消息中有全文内容，即上述3次模型调用后，出现在上下文中的内容实际是这样的： read(file) [This file has been updated later, outdated contents are purged from here] edit(file, foo -> bar) The edit has been applied successfully. --- a/file +++ b/file @@ -23,1 +23,1 @@ -foo +bar [This file has been updated later, outdated contents are purged from here] edit(file, eat -> drink) The edit has been applied successfully, the new file content is as below: {content of file}可以看到，通过将连续对同一文件的修改进行裁剪，可以只保留最新的内容，同时又使用unidiff 之类的形式保留中间编辑的差异信息，最大限度地降低空间占用，又能保留模型的推理逻辑。但裁剪不能使用在非连续的消息中，随意地使用剪裁逻辑，很有可能破坏消息缓存结构，进而使模型调用的输入无法通过缓存处理，几倍地增加模型的调用成本。即便裁剪有一定效果，但随着更多的内容进入到上下文中，始终会有将上下文占满的时候，此时模型将完全无法进行推理。为了避免这种情况出现，Coding Agent通常会使用“压缩”这一技术，即将前文通过模型摘要成少量的文字，同时又保留比较关键的推理链路。通常，压缩在上下文即将用完的时候触发，如已经使用了90%的上下文则启动压缩，压缩的目标是将90%的内容变为10%的长度，即省出80%的空间供后续推理。压缩本身是一个模型的任务，即将所有的上下文（可以选择性地保留最新的1-2对消息）交给模型，同时附带一个压缩的要求，让模型完成工作。这个压缩的要求的质量将决定压缩的最终结果，一个比较典型的实现是Claude Code的“八段式摘要”法：const COMPRESSION_SECTIONS = [ "1. Primary Request and Intent", // 主要请求和意图 "2. Key Technical Concepts", // 关键技术概念 "3. Files and Code Sections", // 文件和代码段 "4. Errors and fixes", // 错误和修复 "5. Problem Solving", // 问题解决 "6. All user messages", // 所有用户消息 "7. Pending Tasks", // 待处理任务 "8. Current Work" // 当前工作 ];通过将信息压缩成8部分内容，能够最大限度地保留工作目标、进度、待办的内容。4.3 独立上下文在实际的应用中，其实大概率是不需要128K上下文用满的，但真实表现又往往是上下文不够用。这中间存在的差异，在于2类情况：为了满足一个任务，需要收集大量的信息，但收集到正常信息的过程中，会引入无效的、错误的内容，占用上下文。一个任务足够复杂，分解为多个小任务后各自占用部分上下文，但加起来以后会超出限制。试想一下，对于一个这样的任务：修改我的Webpack配置，调整文件拆分逻辑，让最终产出的各个JS文件大小尽可能平均。但是很“不幸”地，这个项目中存在6个 webpack.config.ts文件，且最终splitChunks 配置在一个名为 optimization.ts 的文件中管理，那么对于Coding Agent来说，这个任务中就可能存在大量无意义的上下文占用：读取了6个 webpack.config.ts ，一共2000行的配置内容，但没有任何splitChunks 的配置，包含了大量 import 其它模块。又读取了10个被 import 的模块，最终找到了 optimization.ts 文件。经过修改后，执行了一次 npm run build 来分析产出，发现JS的体积不够平均。又修改 optimization.ts ，再次编译，再看产出。循环往复了8次，终于在最后一次实现了合理的splitChunks 配置。这里面的“6个 webpack.config.ts ”、“10个其它模块”、“8次优化和编译”都是对任务最终目标并不有效的内容，如果它们占用150K的上下文，这个任务就不得不在中途进行1-2次的压缩，才能够最终完成。为了解决这个问题，当前多数的Coding Agent都会有一个称为“Subagent”的概念。就好比一个进程如果只能使用4GB的内存，而要做完一件事需要16GB，最好的办法就是开5个进程。Subagent是一种类似子进程的，在独立的上下文空间中运行，与主任务仅进行必要信息交换的工作机制。再回到上面的案例，在Subagent的加持下，我们可以将它变成以下的过程：启动一个Subagent，给定目标“找到Webpack文件拆分的代码”。读取6个 webpack.config.ts 。读取10个被 import 的模块。确定目标文件 optimization.ts 。返回总结：在 optimization.ts 中有文件拆分的配置，当前配置为……。启动一个Subagent，给定目标“修改 optimization.ts ，使产出的JS体积平均，执行 npm run build 并返回不平均的文件“。修改 optimization.ts。执行 npm run build，得到命令输出。分析输出，找到特别大的JS文件，返回总结：配置已经修改，当前 xxx.js 体积为平均值的3倍（723KB），其它文件体积正常。启动一个Subagent，给宝目标“分析 dist/stats.json，检查 xxx.js 中的模块，修改 optimization.ts 使其分为3个250KB左右的文件，执行 npm run build并返回不平均的文件”。…………继续启动6次Subagent，直到结果满意。不难看出来，这种模式下主体的Coding Agent实际是在"指挥"Subagent做事，自身的上下文占用是非常有限的。而Subagent仅“专注”于一个小目标，也不需要太多的上下文，最终通过这类不断开辟新上下文空间的方式，将一个复杂的任务完成。4.4 注意力优化如果你经常使用Coding Agent，或在业界早期有过比较多的使用经验，你可能会发现这种情况：Coding Agent在完成一个任务到一半时，忘了自己要做什么，草草地结束了任务，或偏离了既定目标产生很多随机的行为。会发生这样的情况，有一定可能是裁剪、压缩等策略使有效的上下文信息丢失了，但更多是因为简单的一个用户需求被大量的代码内容、命令输出等推理过程所掩盖，权重弱化到已经不被大模型“注意到”，因此最初的目标也就完全丢失了。Coding Agent一个很重要的任务，就是在长时间运作的同时随时调整大模型的注意力，使其始终聚焦在最终目标、关注当前最需要做的工作，不要偏离预先设定的路线。为了实现这一效果，Coding Agent产品提出了2个常见的概念。第一称为TODO，在很多的产品中，你会看到Agent先将任务分解成几个步骤，转为一个待办列表。这个列表在界面上始终处于固定的位置，随着任务的推进会逐步标记为完成。这个TODO实际上并不是给用户看的，而是给模型看的。在实际的实现中，每一次调用模型时，在最后一条消息（一般就是工具调用的结果）上，除了原始消息内容外，会增加一个称为“Reminder”的区域。这个区域因为始终出现在所有消息的最后，通常来说在模型的注意力中优先级更高，而且绝对不会受其它因素影响而消失。Reminder中可以放置任意内容，比较经典的有：TODO及进度。用于模型时刻理解目标、进展、待办。<reminders> - Planned todos: - [x] Explore for code related to "print" function - [x] Add "flush" parameter to function - [ ] Refactor all "print" function calls to relect the new parameter </reminders>工具子集。如前面《缓存》相关的描述，因为修改工具定义会使缓存失效，因此当切换模式使得可用的工具减少时，一般仅在Reminder中说明部分工具不可用，由模型来遵循这一约束，而不是直接删除部分工具。 <reminders> - You can ONLY use these tools from now on: - read - list - grep - bash </reminders>行为指示。例如当模型连续多次给出名称、参数都一模一样的工具调用时，说明模型处在一种不合理的行为表现上，此时在Reminder中增加提示，让模型感知到当前状态的错误，就有可能调整并脱离错误的路线。 read(file) The file content: ... read(file) The file content: ... <reminders> - Your are using read tool the second time with exactly the same parameters, this usually means an unexpected situation, you should not use this tool again in your response. </reminders>状态提示。例如激活某一个Skill时，Reminder中可以提示“当前正在使用名为X的Skill“，这种提示可以让模型更加专注于完成一个局部的工作。<reminders> - You are currently working with the skill "ppt" active, be focused on this task until you quit with exit_skill tool. </reminders>需要额外注意的是，Reminder仅在最后一条消息中出现，当有新的消息时，旧消息上的Reminder会被移除。基于这一特征，我们知道Reminder是永远无法命中缓存的，因此Reminder部分的内容长度要有控制，避免造成过多的成本消耗。4.5 冲突管控随着Coding Agent能力的发展，当下执行的任务时间越来越长、编辑的文件越来越多，同时更多的用户也习惯于在Agent工作的同时自己也进行编码工作，甚至让多个Agent任务并发执行。这种“协同”形态下，不少用户曾经遇到过这样的问题：自己将Agent生成的代码做了一些修正，但之后Agent又把代码改了回去。这个现象的基本原因也很清楚，就是Agent并不知道你改动过代码。例如以下的过程使Agent读取并编辑了一个文件： read(file) The file content: ... console.log('hello'); ... edit(file, hello -> Hello) Edit has been applied successfully.这个时候，在模型见到的上下文中，这个文件中的代码显然是console.log('Hello'); 。假设乃又将它改成了console.trace('Hello'); ，后面模型依然会基于.log 来修改代码，用户看起来就是代码“改了回去”。解决这种共同编辑文件的冲突，实际上有多种方法：加锁法。当Agent读取、编辑一个文件时，更新模型认知的文件内容的快照。当这个Agent再一次编辑这个文件时，读取文件当前的实际内容，和快照做比对，如果内容不一样，拒绝这一次编辑，随后要求Agent重新读取文件（更新快照与实际内容一致）再进行编辑。这是一种主流的做法，不过Agent实现上的细节比较重。 edit(file, console.log...) This edit is rejected, the file has been modified since your last read or edit, you should read this file again before executing any write or edit actions. read(file) The file content: ... edit(file, console.trace...);推送法。监听所有模型读取、编辑过的文件的变更，当文件发生变更时，在下一次模型调用时，不断通过Reminder区域追加这些变更，让模型“实时”地知道文件有所变化，直到文件被下一次读取。这种方式能让模型更早地感知变化，但推送信息可能过多，影响成本和推理速度。 run_command(ls) The command output: ... <reminders> - These files have been modified since your last read or edit, you should read before write or edit to them: - file - file - ... </reminders>隔离法。使用Git Worktree方案，直接让不同的Agent任务在文件系统上隔离，在一个独立的Git分支上并行工作，相互不受干扰。在任务完成后，用户检查一个任务的全部变更，在采纳时再合并回实际的当前Git分支，有冲突的由用户解决冲突。这种方法让Agent根本不需要考虑冲突问题，但缺点是系统资源占用高，且有合并冲突风险。文件编辑冲突只是一个比较常见的现象，实际上用户和Agent、多个Agent并行工作，可能造成的冲突还有很多种，例如：用户敲了半行命令 ls -，Agent直接在终端里敲新的命令 grep "print" -r src执行，导致最后的命令是 ls -grep "print" -r src ，是一个不合法的命令。终端的抢占也是一种冲突，但相对更容易解决，只要让每一个Agent任务独占自己的终端，永远不与用户、其它Agent任务相交叉即可。4.6 持久记忆我们都知道，模型是没有状态的，所以每一次Agent执行任务，对整个项目、对用户的倾向，都是从零开始的过程。这相当于历史经验无法积累，很多曾经调整过的细节、优化过的方向都会被重置。虽然可以通过比如Rule这样的方式去持久化这些“经验”，但需要用户主动的介入，使用成本是相对比较高的。因此当前很多Coding Agent产品都在探索“记忆”这一能力，争取让Agent变得用的越多越好用。记忆这个话题真正的难点在于：如何触发记忆。如何消费记忆。什么东西算是记忆。首先对于“如何触发”这一问题，常见于2种做法：工具型。定义一个 update_memory 工具，将记忆作为一个字符串数组看待，工具能够对其进行增、删改，模型在任务过程中实时地决定调用。往往模型并不怎么喜欢使用这类工具，经常见于用户有强烈情感的描述时才出现，比如“记住这一点”、“不要再……”。总结型。在每一次对话结束后，将对话全部内容发送给模型，并配上提示词进行记忆的提取，提取后的内容补充到原本记忆中。总结型的方案往往又会过度地提取记忆，将没必要的信息进行持久化，干扰未来的推理。存储型。不进行任何的记忆整理和提取，而是将所有任务的原始过程当作记忆，只在后续“消费”的环节做精细的处理。然后在“如何消费”的问题下，也常见有几种做法：始终附带。记忆内容记录在文件中，Agent实现中将文件内容附带在每一次的模型请求中。即模型始终能看到所有的记忆，这无疑会加重模型的认知负担，也占用相当多的上下文空间，因为很多记忆可能是与当前任务无关的。渐进检索。本身不带记忆内容到模型，但将记忆以文件系统的形式存放，Agent可以通过read 、list、grep 等工具来检索记忆。配合“存储型”的触发方式，能让全量的历史任务都成为可被检索的记忆。但这种方式要求模型有比较强的对记忆的认知，在正确的时刻去找相关的记忆。但往往因为根本不知道记忆里有什么，进而无法知道什么时候应该检索，最终几乎不触发检索。而最终的问题，“什么东西是记忆”，是当下Coding Agent最难以解决的问题之一。错误的、不必要的记忆甚至可能造成实际任务效果的下降，因此精确地定义记忆是Agent实现的首要任务。通常来说，记忆会分为2种大的方向：事实型。如“使用4个空格作为缩进”、“不要使用any 类型“，这些都是事实。事实是无关任何情感、不带主观情绪的。画像型。如”用户更喜欢简短的任务总结“就是一种对用户的画像。画像是单个用户的特征，并不一定与项目、代码、架构相关。在Coding Agent上，往往更倾向于对”事实型“的内容进行记忆，而不考虑用户画像型的记忆。同时，从业界的发展，可以看到越来越多的模型厂商在从底层进行记忆能力的开发，如最近Google的Titan架构就是一种记忆相关的技术。可能未来某一天，Agent实现上已经不需要再关注记忆的逻辑与实现，模型自身将带有持久化的记忆能力。05 能力扩展在实际应用中,还需要一些机制来让Agent更好地适应特定的项目、团队和个人习惯。当前主流的Coding Agent产品都提供了Rule、MCP、Skill这三种扩展能力,它们各有侧重,共同构成了Agent的能力增强体系。5.1 Rule当面对业务的repo往往存在一些领域相关的知识而非模型的知识库中已有的内容，这些往往需要凭借老员工的经验或者读取大量代码库的信息进行总结后才能明白，这些内容便适合放到Rule中，作为静态的不会频繁改动的内容放入Environment Context中长期Cache。好的Rule应当足够精简、可操作且范围明确，人看不懂的规则或者描述不清的规则模型是一定搞不定无法遵守的。将Rule控制在 500 行以内。将较大的规则拆分为多个可组合的规则，采取按需的方式，按照 文件路径/关键场景 激活Rule；对于特定场景激活的Rule，采取编写索引的方式创建Rule，让模型渐进式激活，比如项目针对网络请求和错误处理相关做了项目维度的封装处理，但这种情况并不是每个文件ts/tsx文件都会遇到的诉求，比如在项目的rules目录下创建index.mdr（curso是.mdc文件），编写下面的激活的条件：需要进行API调用获取数据处理异步操作的错误和加载状态 - 当编码涉及以下任一情况时，必须立刻阅读 \[08-api-error-handling.mdc\](mdr:.cursor/rules/08-api-error-handling.mdc) 提供具体示例或参考文件，针对xx情况正确的方式是\`code\`。避免模糊的指导，比如交互式的东西模型交互不了，不需要写进去。为了模型能够积极验证每次改动是否符合预期，告知模型改动后可以执行的正确的构建命令，以及某些自定义命令（比如自动化测试）引导模型在后台启动命令，在xx秒后读取日志文件的内容进行结果的判断。5.2 MCPMCP(Model Context Protocol)是Anthropic提出的一种标准化的工具扩展协议，它允许开发者以统一的方式为Coding Agent添加新的能力。与Rule的"声明式约束"不同，MCP是一种实时工具调用协议，即通过MCP server的方式进行连接，来扩展Agent可以做的事情。一个典型的场景是集成外部服务。比如你的项目托管在GitHub上，可以让Agent直接访问GitHub实现创建Issue、查询PR状态、添加评论等功能：{ "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-github-token>" } } } }配置好后，Agent就能在代码审查过程中自动创建Issue记录问题、查询相关PR的讨论、甚至根据代码变更自动生成commit message。MCP的另一个优势是实现门槛低。一个MCP Server本质上就是一个标准输入输出的程序,它通过JSON-RPC协议与Agent通信，当模型需要外部能力的时候，调用MCP Server，而模型无需关心其内部代码实现，Agent只需要按照固定的协议去连接获取内容。5.3 Skill5.3.1 什么是Skill随着模型能力的提升，使用Agent完成的任务复杂度逐渐增加，使用Coding Agent可以进行本地代码执行和文件系统完成跨领域的复杂任务。但随着这些Agent的功能越来越强大，我们需要更具可组合性、可扩展性和可移植性的方法，为它们配备特定领域的专业知识，因此Agent Skill作为一种为Agent扩展能力的标准诞生。Skill 将指令、脚本和资源的文件夹打包，形成专业领域的知识，Agent在初始化的时候会获取可用的Skills列表，并在需要的时候动态加载这些内容来执行特定任务。随着 Skill 复杂性的增加，它们可能包含过多的上下文信息，无法放入单个配置文件中 SKILL.md，或者某些上下文信息仅在特定场景下才相关。在这种情况下，Skill可以在当前目录中bundle额外的文件，并通过文件名引用这些文件，这些额外的文件提供了更多详细信息，Coding Agent 可以根据需要选择浏览和查找这些信息。Skill 是渐进式触发的， 因此 SKILL.md中 name和 description很关键，这会始终存在于Agent的环境上下文中提供给模型，模型会根据这些描述信息来决定是否在当前任务中触发该Skill，当你明确希望使用某个Skill完成任务，可以在prompt中指定“使用xxxx Skill完成xx任务”。5.3.2 Skill和代码执行LLM在很多任务上表现出色，但许多操作需要使用编写代码 -> 代码执行的方式，带来更高效的操作、确定性的以及可靠性的结果。生成式的模型常常通过生成可执行代码的方式去验证/计算结果。代码既可以作为可执行工具，也可以作为文档。Skill中应该明确让模型是应该直接运行脚本，还是应该将其作为参考信息读取到上下文中。5.3.3 如何创建Skill每个Skill由一个必需的 SKILL.md 文件和可选的bundle资源组成，Skill 应该只包含完成任务所需的信息。skill-name/ ├── SKILL.md (必需) │ ├── YAML frontmatter 元数据 (必需) │ │ ├── name: (必需) │ │ ├── description: (必需，这是 skill 的主要触发机制,帮助模型理解何时使用该 skil) │ │ └── compatibility: (可选) │ └── Markdown 说明 (必需) └── bundle的资源 (可选) ├── scripts/ - 可执行代码 (Python/Bash/等) ├── references/ - 需要时加载到上下文的文档 └── assets/ - 用于输出的文件 (模板、图标、字体等)举一个具体的例子，比如当我们需要进行批量项目的技术栈migrate，比如将less迁移postcss，中间涉及一系列的复杂步骤，比如：安装postcss以及postcss plugin的依赖配置postcss的config分析项目用到了哪些less varibale替换成css vars删除mixin并替换一系列的其他兼容less的语法转换...替换文件后缀上面的工作可以通过清晰的流程描述，并配合脚本实现，因此可以作为一个Skill将经验变成可复制的，一个less-to-postcss的skill的结构：5.3.4 Skill的使用人人都可以创建Skill，也可以让Agent来编写Skill，这是Skill非常便捷的地方。Skill通过instructions和code赋予Coding Agent新的能力。虽然这使其功能强大并有很高的自由度，但也意味着恶意SKill可能会在其使用环境中引入漏洞，诱使模型窃取数据并执行非预期操作。仅从可信来源安装Skill，如果无法确信来源可信，在使用前请务必进行彻底审核。Skill的出现并不是替代MCP的出现，而是相互配合，在合适的场景下选取Skill或是MCP。某些任务Skill和MCP Server均可完成，但Skill通过执行代码的方式可以一次性加载完整流程，但MCP Server要经历多次查询和多轮对话往返，这种情况下Skill更为合适，但这不意味着绝对的优势，比如标准化文档创建这个典型的场景，创建PPT/Word/Excel在本地使用Skill即可完成，但数据的提供则需要借助MCP Server进行查询。因此Skill擅长的是在本地通过执行 code的方式完成复杂任务，在用户私有数据、动态数据查询这些情况下Skill就无法搞定了，这和用户的数据库以及隐私强关联，需要让模型无法感知在执行过程中的隐私信息，Skill能够与MCP Server互补完成更为复杂的流程。