每天早上快速浏览一遍 AI 圈子的最新动态已经是很多开发者的固定习惯。今天这期日报里有三条值得关注的信息Dify 社区版在 Agent 与工作流方向持续迭代越来越多团队开始用它搭建可复用的人机协同流程OpenAI 方面出现 Project Astra 暂停的社区传闻Grok Image 2.0 疑似开始灰度推送部分用户已经晒出了新生成的图像。三条消息看起来分散指向的趋势却是一致的——AI 能力正在从“单点模型调用”走向“完整工作流编排”。本文不打算只做新闻搬运而是以 Dify 搭建 Agent 工作流为主线把背后的核心概念、部署方式、节点配置、常见报错和工程化建议完整拆开尽量让读者从零开始也能搭出一条可运行的工作流。1. AI日报速览Agent 工具链正在成为焦点1.1 今日三条核心动态先快速看一下本期日报提到的三条消息各自的背景和对开发者的潜在影响动态大致背景对开发者的影响Dify 社区版持续迭代开源 LLM 应用开发平台工作流、Agent、知识库、RAG 能力不断更新社区热度高搭建 Agent 应用门槛进一步降低成为个人开发者和中小团队的首选平台之一OpenAI 被传暂停 Project Astra社区流传 Astra 项目出现暂停迹象具体原因尚未确认声音助手类产品的研发路线可能调整短期不必过度解读Grok Image 2.0 疑似灰度推送部分用户在社交平台反馈图像生成结果变化推测是新版本开始灰度放量图像生成赛道竞争加剧应用侧接入多模态模型时可保持关注这里要说明一下Astra 暂停和 Grok Image 2.0 推送目前都还停留在社区讨论层面官方没有给出完整的版本说明。做技术选型时不要因为一条新闻就立刻换掉主力模型或重写应用架构更合理的做法是持续观察并在自己的测试环境里验证新能力。1.2 日报背后的技术主线这三条动态放在一起可以发现一个共同点模型能力再强最终都要落到具体的业务流程里才有价值。OpenAI、Grok 这些模型侧的新进展解决的是“模型能做什么”的问题而 Dify 这类平台解决的是“如何把模型接入业务并且让流程稳定可控”的问题。近年来 Agent 开发的热度持续上升核心原因也在于此大模型本身更像一个“能力单元”Agent 则负责理解目标、拆解任务、调用工具、检查结果。要把这一套过程固化下来不能只靠写 Prompt 或者在聊天窗口里反复试而是需要一个可视化、可复用、可观测的编排环境。Dify 的工作流功能正是从这个角度切入的。它允许开发者用画布的方式把 LLM 节点、知识检索节点、工具节点、条件分支节点串起来形成一条具备业务语义的流水线。相比直接调用 API 写代码工作流的优势在于修改逻辑时不用改代码、排错时有日志、发布后可以通过 API 和 Web 界面同时接入。这也是接下来全文要重点展开的内容。2. Dify 与 Agent 工作流核心概念2.1 Dify 是什么Dify 是一个开源的大语言模型应用开发平台通常被称为 LLMOps 平台。它把模型管理、Prompt 编排、知识库、Agent、工作流、应用发布等能力整合到同一个系统里让开发者不需要从零搭建前后端和模型调用链路。从使用方式上看Dify 有两个明显的特点低代码甚至零代码业务逻辑通过画布连线完成不强制写代码但又保留了代码节点方便处理复杂逻辑。模型无关可以接入 OpenAI、Anthropic、通义千问、智谱、Ollama 本地模型等多种供应商模型切换不用重写应用。在企业级场景中Dify 经常被用来做客服机器人、企业知识库问答、数据分析助手、自动化流程触发器等。它的社区版可以私有化部署数据保存在自己的服务器里这也是它受到国内开发者和企业欢迎的重要原因。2.2 什么是 Agent什么是工作流这两个概念容易混淆先做一个通俗解释。Agent 可以理解为一个“有目标的智能体”。它不只是回答一个问题而是能根据用户目标自动规划步骤、选择合适的工具、执行操作并根据执行结果决定是否需要调整策略。比如用户说“帮我查一下昨天订单异常的原因”Agent 可能需要先查询订单系统、再对比日志、最后生成结论。工作流则是把一整套执行过程固定下来用节点和连线表达“先做什么、再做什么、满足什么条件走哪条分支”。它更像是流程引擎由开发者预先定义节点顺序用户输入进来后按照固定流程流转。两者之间的关系可以这样理解工作流适合流程相对稳定、规则清晰、结果可预期的场景。Agent 适合开放性强、需要模型自主决策、工具组合不确定的场景。在 Dify 中两者不是对立的。你可以搭建一个纯工作流也可以搭建 Agent 应用还可以把 Agent 能力封装成一个节点放进工作流里。实际项目中更常见的做法是“工作流为主、Agent 为辅”用工作流保证流程稳定性和可维护性只在需要动态决策的地方交给 Agent。这样既避免了完全自由的 Agent 不可控又避免了纯工作流不够灵活的问题。2.3 Agent 开发学习路线中的 Dify 定位很多初学者会问学 Agent 开发应该直接从 LangChain 开始还是先学 Dify这里给一个比较务实的建议如果目标是快速做原型、验证业务逻辑、交付一个可演示的应用Dify 的效率和性价比非常高。如果目标是深入理解 Agent 内部原理、做底层框架开发、研究模型调优需要学习 LangChain、LlamaIndex 或直接阅读模型 API 文档。更合理的路线是先用 Dify 建立全局认知理解节点、数据流、工具、知识库这些概念再回到代码层面看具体实现。也就是说Dify 不只是“拖拽工具”它能把 Agent 开发中的核心要素全部具象化。弄懂了 Dify 工作流再去看 LangChain 里的 Chain、Tool、Memory会有一种“原来对应的是同一个东西”的感觉。3. 环境准备本地部署 Dify 社区版3.1 两种使用方式Dify 提供两种主流使用方式云服务版直接访问 Dify 官网创建账号无需自己部署适合快速体验和小规模测试。社区版自部署通过 Docker Compose 部署在自己的服务器或本机适合数据敏感、需要二次开发、长期稳定使用的场景。如果只是学习可以先试云服务版。如果希望跟随本文搭建更完整的开发环境或者把工作流接入自己的私有数据建议选择自部署。自部署的版本差异相对灵活本文以 Docker Compose 方式为例版本需要根据你的项目实际情况调整重点演示配置思路。3.2 Docker Compose 部署步骤自部署 Dify 最常用的方式是 Docker Compose整套依赖包括 API 服务、Worker、Web 前端、PostgreSQL、Redis、Weaviate 等。部署步骤如下第一步克隆 Dify 官方仓库并进入 docker 目录git clone https://github.com/langgenius/dify.git cd dify/docker如果在国内访问 GitHub 比较慢也可以把仓库下载为压缩包再上传到服务器解压。这里顺便提醒一句部署时请确保服务器具备正常的网络访问能力能够拉取 Docker 镜像后续启动过程才不会卡在镜像下载环节。第二步复制环境变量文件cp .env.example .env.env 文件里包含数据库密码、密钥、中间件配置等参数默认值可以直接用但生产环境建议修改默认密码。第三步启动服务docker compose up -d启动过程会拉取多个镜像耗时取决于网络状况。看到所有容器状态为 running 后访问http://服务器IP即可打开 Dify 控制台。通过以下命令可以查看容器状态docker compose ps第一次访问时会引导创建管理员账号设置好邮箱和密码后即可登录。3.3 配置模型供应商Dify 本身不提供大模型能力需要在后台配置模型供应商工作流里的 LLM 节点才能被调用。登录控制台后进入“设置”页面找到“模型供应商”。这里支持 OpenAI、Anthropic、Azure OpenAI、智谱、通义千问、Ollama 等多种渠道。以配置 OpenAI 为例需要准备 API Key并在供应商页面对应位置填写。如果是国内可直连的模型服务选择对应供应商后通常在模型列表里能看到可选的模型名称。配置完成后可以在“模型供应商”页面点击测试确认调用正常。如果希望通过本地模型做开发调试可以配置 Ollama。在服务器上安装 Ollama 并拉取模型后在 Dify 模型供应商页面选择 Ollama填写 Ollama 服务的地址和模型名称即可。这种方式的好处是不依赖外部 API适合隐私要求高的实验场景。模型配置是整个工作流运转的前提建议在进入画布编排之前先完成这一步否则后续调试时每个 LLM 节点都可能报“模型未配置”或“凭证无效”的错误。4. 搭建 Agent 工作流核心节点4.1 工作流控制台基本认识在 Dify 工作台创建一个新应用时应用类型选择“工作流编排”进入后可以看到一块画布。画布左侧是节点面板画布上是开始节点和结束节点。通过拖动节点并连线可以把不同能力串起来。工作流的运行逻辑可以理解为数据流用户输入从开始节点进入经过各节点处理后最终由结束节点输出。每个节点有输入和输出后一个节点可以引用前一个节点的输出变量。Dify 会在参数配置区提供变量选择器选中前置节点后会自动生成引用表达式不需要手写复杂的变量路径。工作流的调试方式也很直观右上角可以填写测试输入并运行系统会逐步展示每个节点的输入输出。这个特性在排错时非常有用。4.2 开始节点与结束节点开始节点是工作流的入口通常定义用户输入字段比如“用户问题”“用户ID”“会话上下文”。它的作用是把外部传入的参数绑定为工作流变量。结束节点决定工作流的最终输出内容可以是固定文本也可以引用前面某个节点的输出。比如客服场景中可以最终返回 LLM 节点生成的回答文本。这部分需要特别注意结束节点的输出格式直接决定了 API 调用方拿到的响应结构。如果对接到前端聊天组件输出通常应为模型回复的字符串如果对接到业务系统可以输出 JSON 结构方便后续程序解析。4.3 LLM 节点与提示词编排LLM 节点是工作流中最常用的节点作用就是调用大模型执行某个明确的任务。在 LLM 节点配置中需要关注几个关键部分模型选择不同模型的推理能力和响应速度差异很大简单场景用轻量模型可以节省成本。上下文可以引用开始节点的用户输入也可以引用前面节点的输出。Prompt 体系系统提示词定义模型角色和行为边界用户消息部分传入实际需要处理的文本。举个例子一个意图识别节点可以这样写系统提示词你是一个意图识别助手。根据用户问题输出以下分类之一aftersales、presales、chat。 只返回分类名称不要输出其他内容。用户消息部分传入{{开始节点中的用户输入}}LLM 的输出就是我们需要的分类。这里需要说明的是变量选择器会自动生成引用表达式实际显示形式以画布中的变量选择结果为准。LLM 节点是工作流中最核心的“智能”来源它可以承担文本分类、内容生成、信息抽取、多轮对话等各种任务。一个复杂工作流往往会包含多个 LLM 节点分别承担不同职责。4.4 知识检索节点知识检索节点用于从知识库中召回与用户问题相关的文档片段是大模型结合私有数据的关键节点。它解决的问题是模型没有学习过的内部资料如何通过检索增强生成的方式让模型基于资料回答。使用知识检索节点前需要先在“知识库”模块创建数据集并上传文档。Dify 会自动对文档切片、向量化建立索引。检索节点配置时需要选择数据集并设置召回数量 TopK 和相似度阈值等参数。TopK 决定了召回多少条相关片段值越大模型能看到的信息越多但噪声也可能增加相似度阈值用于过滤低相关片段阈值越高召回越严格。建议根据测试结果调整不要在第一次配置时就追求极端值。知识检索节点输出的通常是文档片段列表在后续 LLM 节点中需要把检索结果拼接到 Prompt 里让模型基于这些片段生成回答。设计 Prompt 时应明确提示模型“只基于给定的资料回答不要编造”从而减少幻觉。4.5 工具节点、条件分支与代码节点工具节点让工作流具备了调用外部系统的能力。它可以是 Dify 内置的工具也可以是通过 OpenAPI Schema 定义的自定义工具。实际项目中常见的工具包括查询订单接口、创建工单接口、获取天气信息、调用搜索服务等。条件分支节点用于流程的分流。它基于某个变量的值进行判断满足条件则走对应分支。比如意图识别后如果意图为“售后”就走知识库查询分支如果意图为“售前”就走商品推荐分支。代码节点支持运行 Python 或 Node.js 代码适合处理复杂的数据转换、字符串拼接、逻辑计算等场景。它接收输入变量代码执行后返回输出变量。下面是一个简单的 Python 代码节点示意# 这是一个代码节点示例 # 输入变量intent, query # 输出变量message def main(intent: str, query: str) - dict: if intent aftersales: message f售后问题已收到{query} elif intent presales: message 正在为您查询商品信息... else: message 感谢您的咨询请补充更多信息。 return {message: message}代码节点的好处是灵活可以完成很多低代码节点难以实现的逻辑但也要注意不要写过于复杂的逻辑否则会导致工作流难以维护。保持每个节点职责单一是工作流设计的重要原则。5. 实战搭建一个客服工单 Agent 工作流5.1 需求分析与流程设计为了把上面的节点概念串联起来这里设计一个“智能客服工单 Agent”案例。业务背景一家电商平台需要自动处理用户的咨询和售后问题。用户发送消息后系统要判断用户意图并从知识库中寻找解决办法。如果知识库无法解决则自动创建人工工单随后通知用户人工客服将介入。这个需求如果只用单个 LLM 节点提示词完成所有逻辑都会混在 Prompt 里难以维护如果全部交给 Agent 自主决策又可能出现不可控的工具调用。因此采用工作流方式把流程拆成明确步骤。工作流设计如下开始节点接收用户问题。LLM 节点对用户问题进行意图识别输出售后、售前、闲聊三类意图。条件分支节点根据意图走不同分支。售后分支知识检索 → 判断是否有高置信度答案 → 有则直接回答无则调用工单 API 创建工单。售前分支LLM 节点根据商品知识生成推荐回复。闲聊分支LLM 节点直接生成闲聊回复。结束节点输出最终回复文本。这个流程虽然不复杂但已经覆盖了工作流最常见的核心要素LLM、知识库、条件分支、工具调用、输出聚合。5.2 各节点配置过程详解下面展开说明每个节点的配置要点。开始节点配置输入字段类型说明query字符串用户输入的问题文本user_id字符串用户的唯一标识供后续创建工单使用LLM 意图识别节点配置模型选择一个响应速度较快的模型。系统提示词要求模型只输出分类名称例如aftersales、presales、chat。用户消息引用开始节点中的query。条件分支节点配置判断变量引用 LLM 节点的输出text。分支条件等于aftersales走售后分支。等于presales走售前分支。默认走闲聊分支。售后分支中的知识检索节点配置选择数据集商品售后 FAQ 知识库。TopK设置为 3。相似度阈值0.5 到 0.65 之间需要测试调整。知识检索后接一个 LLM 节点生成最终回答。系统提示词强调“只基于给定资料回答”上下文同时引用检索结果和用户原始问题。如果检索置信度低需要创建工单。这里可以设计一个条件分支判断检索结果是否为空或置信度是否低于阈值如果满足条件则进入 HTTP 请求节点或代码节点模拟调用外部工单系统。下面是一个 HTTP 请求节点的配置思路请求方法POST。请求地址例如https://api.example.com/tickets。Headers包含认证 Token。Body包含用户 ID 和问题描述变量引用开始节点的user_id和query。售前分支的 LLM 节点相对简单只需要让模型根据商品描述生成推荐回复并提示允许追问。结束节点统一输出售后分支、售前分支或闲聊分支的最终 LLM 输出。5.3 工作流逻辑概念示意Dify 工作流是用画布连线完成的不需要编写整套代码。但为了帮助理解节点之间的数据流向下面给出一段概念示意 Python 代码。它不用于替代 Dify 配置只表示逻辑# 工作流逻辑示意非Dify源码仅用于理解流程 def workflow(query, user_id): # 开始节点 user_input query # LLM节点意图识别 intent llm_classify(user_input) # 返回 aftersales / presales / chat # 条件分支 if intent aftersales: faq_docs knowledge_retrieve(user_input, top_k3) if len(faq_docs) 0: ticket_id create_ticket(user_id, user_input) answer f已为您创建人工工单编号{ticket_id} else: answer llm_answer_with_docs(user_input, faq_docs) elif intent presales: answer llm_recommend(user_input) else: answer llm_chat(user_input) # 结束节点 return answer从这段示意代码可以看出工作流的本质就是把这种“顺序 分支 工具调用”的逻辑固化成可视化流程。在 Dify 画布中你不写这段代码但节点之间的数据依赖关系与它一致。5.4 发布与 API 调用工作流调试通过后点击发布Dify 会生成一个可访问的应用版本。发布后可以通过 Web 端聊天组件直接体验也可以通过 API 接口集成到自己的业务系统。API 调用的方式通常是在应用“访问 API”页面获取 API 密钥然后向/chat-messages端点发送 POST 请求。下面是一个 Python 调用示例import requests API_ENDPOINT http://你的服务器地址/v1/chat-messages API_KEY app-xxxxxxxxxxxxxxxx payload { inputs: {}, query: 我的订单已经付款了为什么还没有发货, response_mode: blocking, conversation_id: , user: demo-user } headers { Authorization: fBearer {API_KEY} } response requests.post( API_ENDPOINT, jsonpayload, headersheaders, timeout30 ) print(response.status_code) print(response.json())运行后如果工作流配置正确响应中会包含最终的回答文本也就是结束节点输出的内容。这里需要提醒API 地址、请求字段在不同 Dify 版本中可能有细微差异实际使用以你自己部署的版本为准。5.5 运行验证与效果观察在正式接入前建议用多组测试数据进行验证售后类问题例如“如何申请退货”预期是触发知识库检索返回 FAQ 答案。知识库覆盖不到的问题预期是创建工单并返回工单编号。售前类问题例如“这款手机有 256G 版本吗”预期进入售前推荐分支。闲聊类问题例如“你好”预期走闲聊分支。运行调试时Dify 会展示每个节点的输入和输出。如果结果不符合预期重点检查两个地方一是条件分支里的判断值是否与 LLM 节点实际输出完全一致比如模型输出了多余空格导致匹配失败二是知识检索是否召回了正确内容以及阈值是否设置合理。6. 常见问题与排查思路搭建 Dify 工作流的过程中比较容易遇到下面几类问题。问题现象常见原因解决思路工作流导入或运行时提示“缺失节点或缺少依赖包”使用了自定义节点但 Python 环境中缺少依赖根据提示在对应环境中安装依赖或改用平台内置节点Agent 执行器超时提示 provider did not respond in time模型推理速度慢、网络不稳定、模型配置不可用更换轻量模型检查网络连通性适当调大超时时间知识库检索结果不准确回答经常答非所问文档切片粒度不合理、TopK 偏大、相似度阈值过低清洗数据调整切片长度和 TopK提高相似度阈值HTTP 节点调用外部接口失败接口地址错误、认证失败、返回体格式不符先用 curl 或 Postman 单独测试接口再检查节点配置发布后 API 调用返回 401API 密钥未配置或已失效在应用访问 API 页面重新生成密钥并更新请求 Header条件分支总是走到默认分支LLM 节点输出与条件值不匹配存在空格或大小写差异打印 LLM 节点实际输出在 Prompt 中约束输出格式6.1 工作流导入提示“请安装缺失的包”这个报错在引入社区插件或自定义节点时经常出现。它的核心原因是当前 Dify 运行环境的 Python 包列表与节点要求不一致。解决思路是定位报错信息中提到的包名在 Dify 容器或宿主机对应 Python 环境中安装依赖再重启服务。需要提醒的是不要在生产环境随意安装来源不明的包。如果某个自定义节点长期维护不良更好的方案是阅读它的源码确认逻辑后自己实现或直接改用平台内置节点。6.2 Agent 执行器未及时响应“the agent execution provider did not respond in time”这类超时提示通常不是因为工作流逻辑写错而是模型侧没有在预期时间内返回结果。可能原因包括选择了大参数模型导致推理慢、模型服务所在区域网络延迟高、API 限流等。建议排查顺序是先手动测试模型供应商配置是否正常再切换到一个速度更快的模型最后调整客户端或服务端的超时配置。把超时时间设置得过长并不是好方案因为用户侧体验会变差适当设置超时并在超时后返回兜底文案是更稳妥的做法。6.3 知识库检索质量差知识库问答的效果很大程度取决于“数据进得怎么样”。如果文档本身包含大量无关内容、切片后片段语义不完整、Embedding 模型与实际场景不匹配检索质量一定不会好。建议从三个方向优化数据质量删除无关章节统一格式按业务模块拆分文档。切片策略针对不同文档类型调整切片长度和重叠长度让每个片段语义相对完整。检索参数通过测试调整 TopK 和相似度阈值观察不同参数对回答质量的影响。知识库优化是一个反复迭代的过程不要指望一次上传就能获得理想效果。Dify 后续版本在知识库流水线方向也有持续更新建议关注官方 Release Notes。7. 最佳实践与工程建议工作流做到能跑只是第一步做到可维护、可扩展、可治理才是工程化的关键。下面结合实战经验给出几条具体建议。7.1 从简单流程开始逐步扩展新手很容易在第一次搭建时就把十几个节点连成一张大网结果调试时根本不知道问题出在哪个节点。更推荐的做法是先搭一条最小链路比如“开始 → LLM → 结束”让整条链路跑通后再逐步加入知识检索、条件分支、工具节点等。每加一个节点就运行一次测试确认新的节点输出符合预期。这样排错范围会小很多。工作流不是越复杂越好稳定的简单流程远胜于脆弱的复杂流程。7.2 节点命名要具备业务语义默认的节点名称通常是“LLM”“LLM2”“条件分支”节点一多根本分不清。建议创建节点后立即重命名比如intent_classify_llm意图识别模型节点。faq_retrieveFAQ 知识库检索节点。create_ticket_http创建工单 HTTP 节点。is_aftersales售后判断条件分支。命名规范不需要太复杂做到“看到名字就知道这个节点的作用”即可。这对后续维护、交接、排查都有很大帮助。7.3 模型分级与成本控制不是所有节点都要用最强模型。意图识别、文本分类这类简单任务可以使用响应更快的轻量模型知识库总结、长文生成这类复杂任务再使用更强的大模型。在 Dify 中不同 LLM 节点可以选择不同模型这一点为成本优化提供了空间。实际项目中可以通过流量监控了解每个节点的调用量优先优化调用量最大的节点模型。如果某个节点长期占用高成本模型但业务收益不明显就值得重新评估它的模型选择。7.4 工具调用必须做好权限与输入校验当工作流需要调用外部系统时必须考虑安全问题。以下几点建议一定要重视API 密钥不要写死在前端代码或请求 URL 中尽量由服务端统一保管。对所有用户输入做合法性校验防止通过 Prompt 注入的方式让模型执行非预期操作。涉及创建订单、删除数据、转账等敏感操作时建议增加人工确认环节不要让工作流自动执行高风险动作。对生产环境变更保持谨慎任何工作流调整都先在测试环境验证。技术工具本身是中性的是否能安全使用取决于工程规范。把权限边界、操作审计、异常兜底设计好工作流才能从“玩具”变成“生产工具”。7.5 保留日志持续观测Dify 后台提供了运行日志和链路追踪能力。生产环境建议定期查看节点执行记录关注以下指标节点失败率哪个节点最容易失败。平均响应时间用户从发起到收到回复耗时。工具调用成功率外部接口是否稳定。知识库命中率检索是否经常为空。这些数据是优化工作流的重要依据。没有观测就没有改进方向。8. 总结与学习路线这篇文章从 AI 日报的三条动态切入重点落在 Dify 搭建 Agent 工作流这条技术主线上。你在本文中应该已经掌握了几个关键点Dify 在大模型应用开发中的定位Agent 与工作流的关系Docker Compose 部署 Dify 社区版的方法工作流核心节点的作用以及如何把一个客服工单 Agent 的流程从设计到发布完整落地。常见报错的排查思路和工程化建议也可以直接在后续项目中复用。下一步如果你打算继续深入学习可以沿着这几个方向走学习 Dify 知识库的完整流水线文档清洗、切片策略、Embedding 模型选择、索引更新机制。研究代码节点的高级用法通过 Python 处理复杂数据结构连接外部数据库实现更灵活的业务逻辑。探索多 Agent 协作在 Dify 中尝试 Agent 节点与工作流节点的组合让系统在稳定中保留智能决策能力。深入 API 集成把发布后的工作流接入企业微信、钉钉、飞书或自己的前端系统。实际项目中最值得优先关注的还是稳定性和成本。先保证流程可运行、可观测再去追求功能丰富度不要一次性引入过多模型和工具。Dify 社区版的更新节奏很快建议每到一个新版本先看 Release Notes再决定是否升级升级前做好备份。如果这篇文章对你有帮助可以收藏备用。等到你真正开始搭建 Dify Agent 工作流时再翻出来对照着操作。动手实践比只看不练更重要建议你现在就打开控制台创建一条最简单的“开始 → LLM → 结束”工作流然后逐步加入你自己的业务逻辑。