软件工程师罗小东，多年架构和平台设计经验，目前在研究平台与新技术结合中。
以下主要为大文本文档审核场景验证，也是高频使用场景之一。

概述

文档审批常常会遇到，而且大文本，人工多次审核和查阅可能还是遗落，这里利用Agent做初步审核，以提供初步审核意见。
主要目标点：

• 提高效率：自动上传和纠错，提出初步审批意见和低级错误。
• 保证质量：智能体检测文档中的错误，提升文档质量。
• 节省成本：减少人力投入，降低运营成本。
  每个设计师思路不一样，我有我思。提供一些参考设计，期望有兴趣的同学可以多交流。

设计思路

自动纠错模式

• 错误标注：对于每一个检测到的错误，我会在文档中标注出来，并高亮显示，让用户一目了然地看到需要修改的地方。
• 提供修改建议：针对每个错误，我会提供具体的修改建议，并且给出三个不同的修正方案，帮助用户选择最合适的修改方式。

具体步骤

1. 文本识别：将上传的文档转换为可处理的文本格式。
2. 语法检查：利用自然语言处理技术，检测文档中的语法错误。
3. 拼写校正：自动识别并纠正拼写错误。
4. 术语一致性：检查文档中术语的一致性，确保用词规范。
5. 错误标注：在文档中高亮显示错误，并标注具体位置。
6. 修改建议：为每个错误提供三种修改建议，供用户选择。

审阅模式下的批注

• 显示审批人信息：每一条批注都会注明审批人的名字，增加透明度，让每个人都对自己的工作负责。
• 记录审批意见：审批人可以根据我的修改建议表达自己的看法，比如是否同意我的建议，或者提出新的修改意见。
• 个性化修改建议：除了提供的标准修改建议之外，审批人还可以添加个性化的建议，提供更多元化的修改选项。

结合演示

建立新的审批频道，将需要审批的文件上传到频道

调用Agent进行文档审核，顺便说明审核重点。

审批结合的效果，带有审批意见和建议还有提供的原因

总结

以上为业务场景的情况，也是作为一个例子情况，提交给审核人员。

软件工程师罗小东，多年架构和平台设计经验，目前在研究平台与新技术结合中。

术语

• 频道：多Agent结合交互，类似群，可以拉Agent进入
• 场景：针对特定要求的多Agent编排，目前集成大文本、管理Agent

概述

针对于AIP的输出整合情况，AIP是目前在维护的开源项目，主要是进行平台和新技术的结合上，同时对外的交流方式之一。

智能体输出场景有很多，这里主要针对的是工作场景还有多Agent交互的情况，目前AIP集成相对常用的业务场景。

抛砖引玉，一家设计，同时也期望有兴趣的同学可以了解和交流，我有我思。

集成场景

主要集成包括频道和场景两部分，单个Agent这里不做场景列出，单个Agent是组成Multi-Agent场景的元素，可以单聊，也可以做执行，也可以调用工具，但是多任务和要求集成在单Agent上会目前导致结果幻觉还有审核流程不太好结合处理，所以这里整理成Agent团队的概念。

注：当前部分引用图片为网络下载，用于研究学习使用

场景列出主要是为了作为demo例子使用，当然这也是平时在用的，结合实际验证。说明:完成指已经在使用当中，测试指在调试验证中。

频道

多个Agent可以拉在一起调用，可以@指定的Agent角色，结果之间，知识库之间可以互相调用。

以下为目前集成的频道：

• （完成）写长文本文案，审核，导出word
• （完成）分析标书，写标书，导出word
• （完成）每日或是根据时间段进度汇总，也可以导出word
• （完成）研发工作日报、周报编写，也可以导出word
• （完成）研发工作统计情况还有报表生成
• （完成）文字转成对话音频，导出mp3
• （完成）根据场景需求生成图片4张
• （完成）网站知识库自动导入客服咨询
• （完成）根据意图项目自动发布项目集成
• （完成）根据问题自动推理自动使用工具输出结果（ReAct模式）
• （测试）word文档内容审核标注导出
• （测试）培训考核题目导出（包括答案），发送Email到指定邮箱

频道的使用角色之间有比较大的共用性，比如很多频道都需要发送email或者word，还有调用研发专员Agent等。

场景

不管是大模型的限制还是使用的便利，还有更加符合业务场景，统一抽取出来的特定编排形式。

以下为目前集成的场景：

• （完成）多Agent配合超大文本标书编写
• （完成）多Agent配合每日自动生成日报
• （完成）多Agent配合编写长文本内容
• （完成）管理Agent调动分配工作Agent做事
• （测试）多Agent配合写论文同时配图和报表，公式
• （测试）自动采集线索自动整理销售方案和技术方案
• （测试）自动根据需求生成新的Agent

这里只是列出已经使用和调试好的Agent，场景之间可以互相通用，需要定义Agent还有知识库的处理，针对不同行业达到通用性，比如大文本也可以编写律师行业的合同类。

计划

后续分配行业场景结合，目前为上面的例子，目前对例子进行集中测试，输出需要的指标：

• 频道、Agent、场景的成功率
• Token消耗成本
• 每个Worker节点时常

还有常见问题输出，对应的例子进一步优化使用和说明文档在整理输出。

以下为编写的初稿：http://portal.infra.linesno.com/technical/brain/01_自定义智能体开发流程.html

附

AIP开源地址：https://gitee.com/alinesno-infrastructure

设计思路：http://alinesno-agent.linesno.com/book/

注：部分图片从网络下载做调试使用，目前为研发学习使用而非商用。

软件工程师罗小东，拥有多年架构和平台产品设计经验，以下为开源项目AIP集成超大文本的设计思路。

术语

• 超大型文本：指的是超过100多页、超10万字的文档，比如解决方案、技术方案、招投标书
• Agent编排：这里的编排不是工作流，而是针对业务场景的编排，类似于团队人员工作的安排
• 多Agent技能：每个有自己的技能和擅长部分，每个Agent解决自己的擅长的点

概述

下面处理出来的一般是初稿，然后再进一步的调整，目前的Agent定位为辅助

常会接触过超大型文本，如解决方案、技术方案、招投标书等，通常超过100多页、10万字。处理这类文档时。多Agent系统提供了一种新的解决方案，通过多个智能体（Agent）的协同工作，可以高效地处理复杂任务。

一般超大型文本具有以下特点：

• 信息量大：包含大量的技术细节、业务流程、管理计划等内容。
• 专业性强：涉及多个领域的专业知识，需要高度的专业性和准确性。
• 一致性要求高：文档各部分需要保持一致性和连贯性。

处理超大型文本时面临的主要问题：

• 效率低下：人工编写和审核耗时长，容易出错。
• 一致性难保证：多人协作时，容易出现
• 质量难以控制：文档质量依赖于个人能力和经验，难以标准化。

为了更好的表达，下面以招投标场景为示例来进行阐述。

设计思路

多Agent系统是由多个智能体（Agent）组成的协作系统。每个Agent具有独立的技能和专长，能够处理特定的任务，从过去的项目中抽取成功案例和技术文档，形成一个结构化的知识库。将这些知识库分别导入给单个Agent，使其在编写文档时能够参考和借鉴。

协作机制

通过合理的编排，这些Agent可以高效地协同工作，完成复杂的任务。

任务分配：根据任务的性质和复杂度，将任务分配给最合适的Agent。例如，在招投标场景中，大纲编写Agent负责整体框架，技术方案编写Agent负责技术细节。
责任矩阵：建立责任矩阵，明确每个Agent的职责和任务边界。这有助于避免任务重叠和遗漏。
通信共享：Agent之间需要有效的通信机制，确保信息的及时传递和共享。
动态调整：系统应具备动态调整能力，根据任务进展和环境变化调整Agent的工作状态。

设计多Agent系统的协作机制需要综合考虑任务分配、通信机制和动态调整等多个方面。

场景设计

会有不同的大文本场景，不同的大文本场景可以非常丰富多样，涵盖各种领域和用途。

比如是每个场景都适用于不同的用途：

2. 解决方案 – 提供针对特定问题的综合解决方案，包括技术、管理、市场等方面。
3. 技术方案 – 设计详细的技术实施方案，如系统架构设计、软件开发计划、硬件配置方案。
4. 论文编写 – 学术论文、研究报告、文献综述、实验结果分析。
5. 项目管理 – 项目计划书、进度报告、风险管理报告、项目总结报告。
6. 市场分析 – 市场调研报告、竞争分析、消费者行为分析、市场趋势预测。
7. 产品手册 – 产品介绍、使用说明、技术参数、维护保养指南。
   ….

这里尽量针对于每个场景设计出不同的Agent，以进行更精细化，更贴近的效果，因为每个输出在与团队路径最短的，只有团队自己或者此场景下最熟悉的人了解。

Agent设计

以招投标场景为示例。

大概会设计下面的Agent，细化可以更精准化，还有知识库更符合团队本地场景，每个场景有自己的知识库，同时每个Agent又有自己的知识库。

• 负责大纲编写的Agent：会有多个角色编写大纲，然后将大纲合成一份。
• 负责编写技术方案部分的Agent：注于技术实现方案的撰写，确保技术方案的准确性和创新性。
• 负责编写概要部分的Agent：编写文档的概要部分，确保整体连贯性。
• 负责编写项目管理的Agent：负责项目实施计划的制定，确保项目的可执行性。
• 负责编写商务服务的Agent：关注商务条款和服务承诺，提升客户满意度。
• 负责编写安装部署的Agent：负责安装部署方案的编制，确保方案的实用性。
• 负责编写售后服务的Agent：编写售后支持策略，提供全面的售后服务方案，增强客户的信任感。
• ….

上面的Agent可以理解成一个团队，然后针对这个团队的人员安排，我们这里暂时称这种为场景编排。合理的协作机制可以确保各个Agent高效地协同工作，提高系统的整体性能和可靠性。

过程中每个Agent可以替换和重新更换更好更合适的Agent，比如张三设计的更出，在实践中体验较佳，便可以切换。

集成效果

以下是一个简单的多Agent系统界面设计设计演示，首先选择和分配Agent角色，进行大纲编写，可以选择多个Agent。

编写出大纲之后，如果不符合，针对大纲进行调整或者可调整微调目录结构及符合的场景。进行内容人员编写人员选择。

内容编写界面和文档导出，167页，近10万字文本导出。

当然，也可以添加在这个场景下的特定的文档知识库，然后给各个Agent共享使用。

总结

通过合理的设计和编排，各个Agent可以高效地协同工作，提高文档的质量和一致性。特别是通过历史知识库的利用，可以有效控制文档质量，减少对个人能力和经验的依赖。

软件工程师罗小东，拥有架构和平台产品设计经验，目前在研究平台与新技术结合中。

术语

• Agent员工指提大模型Agent，比如需求编写的智能体，现在需要进一步的结合真实业务场景
• 数据资产是为企业或个人带来经济利益的数据资源。它不仅包括数据本身的质量和特征，还涉及数据的应用场景和使用方式。

概述

在找到更合适的方法论前，暂时以此方法论进行结合落地

随着企业数字化转型的不断推进，智能体在提高工作效率、降低运营成本方面展现出巨大潜力。数据资产作为企业的核心资源之一，正逐渐成为提升竞争力的关键因素。

以下为员工能力复制过程:

本文旨在更好地结合Agent员工与数据资产来克服现有挑战，以及这种结合能够带来的价值。每个架构思设计不一，我有我思。

为什么要结合一起

在实Agent员工落地过程中，尽管已有自定义的智能体平台支持数字员工或Agent的落地，但其在真实业务场景中的表现并不尽如人意，遇到的比如：

1. 落地思路模糊：很多企业尚未形成一套成熟的方法论指导Agent员工的应用，其作用发挥受限。
2. 应用场景贴合度不高：部分解决方案过于通用化，未能充分考虑到具体行业的特殊需求。
3. 执行效果欠佳：由于缺乏足够的数据资产或者不恰当的设计，某些Agent可能无法准确理解用户意图或完成复杂任务。

现阶段已经有自定义的智能体平台，进行一步的数字员工或者说Agent落地。

1. Agent员工落地思路不够明确，执行结果不理想，与真实业务场景结合不理想
2. 需要更统一的结合思想，Agent员工落地的指导思想，需要更明确的落地思想。
3. Agent与数据资产结合，同岗位结合很产生数据价值

大致的设计流程如下:

• 构建经验沉淀知识库：收集并整理各个岗位上的宝贵经验，将其转化为结构化的信息存储起来。例如，在IT运维领域内，关于不同规模服务器集群的最佳实践指南便属于此类资源。
• 数据资产化处理：利用先进的数据分析技术对积累下来的知识进行深加工，提炼出其中蕴含的价值点，从而形成真正意义上的“数据资产”。
• 整合进Agent体系：把这些经过精心准备的数据资产融入至Agent员工的核心逻辑之中，使其能够更好地服务于特定行业或职能领域内的用户群体。

以体现Agent员工的价值和意义，也体现数据资产的价值(甚至能形成以Agent为载体的数据交易)。

从经验到数据资产

需要考虑将Agent员工同数据资产管理相结合的方法论。这样不仅可以优化现有的工作模式，还能进一步释放数据背后隐藏的巨大潜力。通过这种方式，
我们可以构建一个更加灵活高效的运营体系，使得企业在快速变化的市场环境中保持竞争优势。

知识库建设

• 经验积累：首先，需要收集并整理各个岗位上的实践经验。这些信息通常以文档形式存在于企业内部，比如最佳实践手册、故障排除指南等。
• 结构化处理：接着，通过自然语言处理（NLP）、机器学习等技术手段将非结构化的文本资料转化为易于理解和检索的形式。
• 建立关联：为每条记录添加适当的标签或元数据，便于后续查询时能够快速定位相关内容。
• 持续更新：确保该数据库随着时间推移得到及时维护，反映最新的技术和行业趋势。

比如一个简单的场景：

现在需要系统部署规划角色，要求是针对于某个业务场景下：

• 针对简单服务器的划分怎么处理
• 针对内网外网，中间安全网络怎么划分
• 针对百万、千万、分布式服务器资源怎么划分
• 针对高并发、单机、信创网络非容器场景怎么划分
• 针对于k8s、容器化场景下怎么划分资源
• ….

将上面经验中形成数字化，资产化，将前期的经验形成资产化进行沉淀，梳理形成数据资产，再进一步的结合Agent，形成原岗位角色的能力复制（或者说分身）。

数据资产建设

在将Agent员工与业务场景紧密结合的过程中，构建一数据资产体系。以下是数据从采集到加工再到输出为数据资产的主要步骤。

1. 数据采集

• 多源整合：确定并整合来自不同渠道的数据源，包括内部系统（如ERP、CRM）、日志文件、外部API以及公开可用的数据集等。这些数据可以涵盖操作记录、用户反馈、性能指标等多个维度。
• 自动化收集：利用ETL工具或其他数据集成解决方案实现数据的自动收集和同步。确保数据能够定时更新，并且保持最新状态，以便于后续处理和分析。

2. 数据清洗与预处理

• 质量保证：对收集到的数据进行清洗，包括去除重复项、填充缺失值、修复错误信息等。通过设定数据清洗规则来保证数据的一致性和准确性。
• 标准化处理：将数据转换成统一的格式，例如日期时间戳的格式化、数值范围的归一化等。同时，对文本数据执行分词、停用词过滤等自然语言处理任务，使其更适合后续使用。

3. 知识库建设

• 经验积累：整理各个岗位上的实践经验，将文档形式的最佳实践手册、故障排除指南等信息纳入知识库中。
• 建立关联：为每条记录添加适当的标签或元数据，便于快速定位相关内容。同时，利用图数据库等技术表达知识点之间的关系，增强搜索的相关性。
• 持续更新：定期维护知识库，确保其反映最新的技术和行业趋势。设立专门团队负责知识库的管理和更新工作。

4. 数据资产管理平台

• 集中存储：构建一个中央数据仓库或数据湖，用于存储经过处理后的所有数据资产。这有助于提供一个统一的数据访问入口，方便管理和查询。
• 权限管理：设置不同的访问权限，确保敏感信息的安全。根据不同角色的需求分配相应的读写权限，以保护数据资产不被滥用。
• 资产管理：维护详细的元数据信息，包括数据来源、处理过程、更新频率等。这有助于提高数据透明度，便于审计和合规检查。

智能化应用开发

• 定制化服务：基于构建好的知识库开发出符合特定需求的服务模块。例如，针对IT运维部门可提供故障诊断、性能优化等方面的辅助决策支持。
• 交互界面设计：创建友好直观的用户界面，让用户能够轻松地与系统互动，获取所需的信息或完成相关任务。
• 自我进化机制：引入强化学习算法让Agent能够在实际使用过程中不断学习改进，从而提供更精准的服务。
• 安全性考量：考虑到敏感数据的安全性问题，在整个过程中采取严格的数据保护措施，防止未授权访问或泄露事件发生。

产品原型

由于界面有限，这里只是展示部分设计界面。

下面是针对于运营需要的产品原型，建立的各个Agent角色，这里主要是为了更好的进行产品演示。

多Agent角色之间的交互模式，通过进一步的驱动业务推进

从数据采集到数据加工再到数据资产的输出。

调试串起来的结合情况，下面以内容输出产品运营示例，建立内容运营频道，由Agent员工输出内容：

添加调整数据之后，进一步的发布到内容运营平台，结合自媒体做运营管理。

总结

以上为通过加强Agent员工与数据资产之间的联系来促进前者在业务环境中的运用思路和设计，当前在进行Agent员工的调试和设计中，也期待能有机会与其他同学就此话题展开讨论。

软件工程师罗小东，多年架构和平台产品设计经验，以下为做开源智能体平台(AIP)的构建工具选型过程。

概述

自动化过程中，持续集成工具一直是扮演着核心的位置，是软件的基础设施之一，类似于称手的工具还有习惯会影响效率，以下为研发AIP智能体平台过程中，CICD工具的考虑和迁移情况。
这里工具的使用有一个背景，并不是每个团队都合适，以下为当前的背景：

• 稳定性：基础设施之一，要求稳定性高
• 微小团队：使用人数少
• 低成本：成本尽量最小化，薅羊毛思维
• 敏捷：构建速度要快，效果快
• 兼容性：可以在不同CICD工具兼容
• 可复制：微服务拆分，大同小异
• ….

总的来说，就是稳定、减少成本、构建快、快速迁移快。

这里使用的工具对比主要从以下三个工具使用情况的迁移还有对比：

• Jenkins: 开源持续集成工具
• GithubAction: Github持续集成工具
• CodeUp流水线：阿里Codeup中的流水线

项目从1-3的迁移过程中的一些使用经验及总结，当然还有其它工具(比如gitlab），每个团队工具使用不一，而且场景不一，得到的总结效果也不一，这里偏于客观中带有主观经验分享。

使用过程

经验以直接说明为主，从过程中体验和优势和劣势进行阐述说明。

Jenkins使用

这个是开始的选择，接触的公司也一直在使用这个。
但是随着项目过程构建工程的变多，服务器要求也会更高，稳定性还有维护成本更高，成本支出是一项问题。当前构建任务大概是接近百个（工程、运维、备份等），而且随着自动化程度的集成，会更多构建任务。

兼容性

以下为构建前后端的脚本：

这里执行流程尽量简单。

优势

• 私有化程度高：可以在内部服务器上完全私有地部署，这意味着你可以全面控制数据的存储位置以及如何处理这些数据。这对于那些需要遵守严格数据保护法规或希望保持知识产权安全的企业来说非常关键。
• 工具集成度高：拥有一个庞大的插件生态系统，几乎可以与任何你想要集成的开发工具进行对接，比如Git、Docker、Maven等。这使得它非常适合用于构建复杂的CI/CD流程。
• 分布式构建支持：支持分布式构建环境（即Master-Slave架构），允许在多台机器上并行执行任务，从而显著提高大型项目的构建速度和效率。

劣势

• 维护成本：尽管Jenkins是开源且免费使用的，但它的安装、配置、升级及日常维护工作可能相对复杂，特别是对于小型团队而言，可能需要专门的技术人员来负责管理。
• 升级成本高：随着新版本不断发布，为了获取最新的功能和修复已知的安全漏洞，定期更新Jenkins变得必要。然而，升级过程有时并不简单，尤其是在高度定制化的环境中，可能会遇到兼容性问题。
• 安全性考量：虽然Jenkins本身提供了许多安全设置选项，但由于其开放性以及广泛使用的插件体系，如果没有妥善配置安全策略，则存在被攻击的风险。此外，一些第三方插件的质量参差不齐，也可能成为潜在的安全隐患。

总结

适合那些对定制化需求较高、愿意投入资源进行管理和维护的大中型企业。其广泛的社区支持和丰富的插件库使其能够满足大多数自动化测试、构建、部署等方面的需求。

但对于AIP微小团队人员一说并不想持续工具上投入过多，连维护都不想考虑，研发人员最好忘记有这个工具的存在更好。

Github Action 使用

这里暂时不考虑搭梯子的情况。

大公司维护的产品，功能还有稳定性上是满足，插件工具集成也高，对开源项目免费，比较符合。自动化的构建及邮件通知，多种安全代码检测都有，这些针对于开源项目都是免费的，很长一段时间，只需要同步代码即可，CICD的事情基本上不用过于考虑。

兼容性

以下为构建前后端的脚本：

工程基本上可以做到不动，调整CICD脚本即可。

优势

• 大公司维护：由GitHub官方支持和维护，这意味着它能够得到持续的更新和技术支持。对于依赖稳定性和可靠性的项目来说，这一点尤为重要。
• 使用体验良好：界面直观友好，文档详尽且易于理解，即使是CI/CD新手也能快速上手。
• 高稳定性：作为GitHub的核心服务之一，其性能表现相当稳定，减少了因平台问题导致构建失败的可能性。
• 丰富的集成选项：拥有大量的预定义Actions（动作），可以直接用于常见的开发任务，如代码质量检查、自动化测试等，并且很容易与各种第三方服务集成。
• 对开源项目友好：对于公共仓库或开源项目，GitHub Actions提供了免费的执行分钟数，这对于促进开源社区的发展非常有利。

劣势

• 速度较慢：国内环境下，可能会遇到队列等待时间较长的问题。此外，由于服务器分布在全球各地，某些地区的网络延迟也可能影响整体运行效率。
• 隐私与安全：虽然GitHub本身采取了多种措施来确保数据的安全性，但是你很难确保人为的不安全性行为，长期久了总会有人为疏忽概率。

总结

GithubAction有很多集成的好的工具，包括GithubPage等，但是有两个致命的因素一个是慢，另一个是安全，首先慢这个是体验性最为困难的。
另外的安全性并非说工具的安全，而是人为的操作不小心，导致日志或者其它地方的不安全因素（至少有个安全处理的过滤阶段）。

CodeUp流水线

这个是新迁移工具的使用，还有迁移中，没迁移完成，

兼容性

以下为构建前后端的脚本：

脚本会有一些较大的改动，可能使用还不熟悉，但是总的来说，使用体验会比GithubAction好一些，稳定性还在验证和体验。

优势

• 国内环境友好：网络环境进行了优化，可以提供更加稳定的连接和服务，这对于位于中国的团队来说是一个显著的优势。
• 私有化支持：允许在阿里云上创建私有的代码仓库和构建环境，确保敏感信息不会泄露到外部，适合对数据安全有较高要求的企业使用。
• 免费额度：对于小规模或初创团队而言，CodeUp提供了基本的免费服务层级，有助于减少初期投入成本。
• 与阿里云生态集成：能够无缝对接其他阿里云服务（如对象存储OSS、ECS等），简化了从开发到部署整个流程中的操作步骤。

劣势

• 工具集成度有限：相比于Jenkins或GitHub Actions，CodeUp提供的预置Action数量较少，可能需要更多自定义脚本来实现特定功能。这增加了学习曲线，并且在某些情况下可能导致效率降低。
• 文档和支持资源相对不足：由于推出时间较晚，关于CodeUp流水线的文章、教程以及社区讨论内容还不够丰富。用户往往需要自行探索如何最佳利用该平台的各种特性，这可能会影响到快速解决问题的能力。

总结

适用于那些希望在国内拥有良好性能表现同时又注重隐私保护的小型至中型企业。它在工具多样性和全球范围内可用的支持材料方面尚存在局限性，但对于已经采用或考虑迁移到阿里云生态系统中的组织来说，不失为一个值得探索的选择。

针对于目前的团队来说，国内网络环境会更好符合情况，体验会更好，目前也还在探索，Github转变成当前备份的环境。

总结

虽然每种工具都有各自的特点，但最终的选择应当根据团队的具体情况而定。在构建智能体平台的过程中，选择合适的持续集成/持续部署(CI/CD)工具是至关重要的。基于团队对稳定性、成本控制、敏捷性以及兼容性的需求，经历阶段都有其独特的优势与局限。

每个团队工具使用不一，而且场景不一，得到的总结效果也不一，这里偏于客观中带有主观经验分享，期望有兴趣的同学可以多交流。