配置系统与核心对象设计：构建稳定可控的应用基石

1. 项目概述从“对象”与“配置”出发构建稳定可控的应用基石在软件开发尤其是构建具有一定复杂度的服务端应用或智能体Agent系统时我们常常会听到两个高频且核心的词汇“核心对象”与“配置系统”。乍一听它们似乎分属不同的领域——一个关乎业务逻辑的实体建模另一个关乎运行环境的参数管理。但当你真正深入一个项目的设计与维护尤其是面对像“Agent智能体开发”、“Session管理”这类需要高度可控和灵活扩展的场景时你会发现这两者实际上是紧密咬合、共同决定系统稳定性与可维护性的齿轮。很多新手开发者遇到的“Session文件报错”、“环境变量配置缺失导致启动失败”、“Agent能力无法按需加载”等问题其根源往往不在于某一行代码的语法错误而在于对这两个基础概念的抽象与管理失当。所谓“核心对象”在我的理解里它不是一个孤立的类或结构体而是一个承载了关键业务状态、生命周期和行为逻辑的实体。在Web开发中Session会话就是一个典型的核心对象它代表了服务器与特定客户端一次交互的上下文存储着用户登录状态、临时数据等。在AI Agent开发中Agent智能体本身也是一个核心对象它封装了感知、决策、执行等一系列能力。这些对象不是凭空存在的它们的创建、初始化、行为模式乃至销毁方式都需要一套清晰的规则来定义。而这套规则很大程度上就来源于“配置系统”。配置系统远不止是读取一个config.ini或者.env文件那么简单。它是一个动态的、层次化的决策体系。它需要处理从操作系统环境变量如JAVA_HOME、NODE_PATH、到应用部署配置文件、再到运行时动态参数的全链路信息。一个健壮的配置系统能让我们在不修改代码的情况下轻松切换数据库连接、调整线程池大小、开启或关闭某个功能模块比如Agent的特定Skill或者为不同环境的Session设置不同的超时策略。当你的uniapp项目因为本地Node.js环境变量未配置而报错或者Selenium测试脚本因为chromedriver路径问题而无法启动时你正是在与配置系统打交道。因此将“核心对象”与“配置系统”放在同一章讨论绝非偶然。本章的目标就是深入探讨如何通过精心的设计让配置系统像血液一样滋养核心对象使整个应用骨架清晰、运行稳健、易于观测和调整。我们会从最基础的配置读取与解析讲起逐步深入到如何利用配置来驱动核心对象如Session、Agent的生命周期管理并分享在实际构建高并发服务或智能体框架时围绕这两个概念积累的实战经验和避坑指南。2. 配置系统的架构设计与核心原则在动手写任何一行配置读取代码之前我们必须先想清楚配置系统的设计目标。一个随意的、散落在代码各处的配置访问方式是后期维护的噩梦。我们的目标是建立一个统一、安全、层次化、可热更新的配置源管理体系。2.1 配置源的层次结构与优先级一个成熟的应用其配置可能来自多个源头这些源头应该有明确的优先级高优先级的配置可以覆盖低优先级的配置。一个常见的层次结构如下从高到低命令行参数最高优先级用于临时覆盖例如--port8080。环境变量非常适用于容器化如Docker部署可以方便地注入敏感信息如密码、密钥和部署环境差异如生产/测试数据库地址。配置文件应用的主要配置来源格式可以是JSON、YAML、TOML或Properties等。根据环境不同可以有application-dev.yamlapplication-prod.yaml。默认值代码内嵌最低优先级为配置项提供安全的默认值。注意绝对不要将敏感信息如数据库密码、API密钥硬编码在配置文件或代码中。对于配置文件应使用.gitignore排除生产环境配置对于敏感信息务必使用环境变量或专业的密钥管理服务如Vault、KMS来传递。2.2 配置对象的映射与验证读取配置的下一步是将散落的配置项映射到一个结构化的、类型安全的配置对象中。这个过程不仅仅是简单的键值对赋值。为什么需要结构化映射想象一下你的应用有数据库、Redis、日志、HTTP服务器等多个模块的配置。如果到处都通过字符串键如config.get(“db.host”)来访问首先容易拼写错误其次无法利用IDE的自动补全和跳转最重要的是失去了类型安全。一个端口号被误读为字符串可能导致难以察觉的运行时错误。如何实现以Java Spring Boot的ConfigurationProperties或Python Pydantic的BaseSettings为例它们都提供了将配置文件或环境变量自动绑定到带有类型注解的类属性的能力并能在绑定过程中进行数据验证。# application.yaml app: session: timeout: 1800 # 秒 cookie: name: “APP_SID” secure: true agent: workers: 4 skills: - “web_search” - “calculator”# config_models.py from pydantic import BaseSettings, Field, validator from typing import List class SessionConfig(BaseSettings): timeout: int Field(1800, gt0, description“会话超时时间秒”) cookie_name: str Field(“APP_SID”, regex“^[\\w-]$”) cookie_secure: bool True class Config: env_prefix “APP_SESSION_” # 环境变量前缀如 APP_SESSION_TIMEOUT class AgentConfig(BaseSettings): worker_count: int Field(4, ge1, le32) enabled_skills: List[str] [] validator(‘enabled_skills’) def validate_skills(cls, v): allowed_skills {“web_search”, “calculator”, “weather”} for skill in v: if skill not in allowed_skills: raise ValueError(f“Skill ‘{skill}’ is not allowed.”) return v class Config: env_prefix “APP_AGENT_” class AppConfig(BaseSettings): session: SessionConfig SessionConfig() agent: AgentConfig AgentConfig()在上面的例子中Pydantic不仅完成了映射还进行了验证timeout必须大于0cookie_name需符合正则worker_count在1到32之间enabled_skills中的技能必须在白名单内。如果环境变量APP_AGENT_WORKER_COUNT50应用在启动时就会立刻报错而不是在运行时才出现诡异的行为。实操心得配置验证前置务必在应用启动的初始化阶段就完成所有核心配置的加载和验证。这被称为“快速失败”Fail Fast。让问题暴露在启动时远比在业务高峰期因为一个错误的配置项导致服务雪崩要好查得多。你可以将加载和验证逻辑封装在一个init_config()函数中并在应用入口最早调用它。2.3 配置的热更新与监听对于某些配置我们希望在不停机的情况下动态生效比如日志级别、某个功能开关、或Agent的技能列表。这就需要配置系统支持热更新。实现模式中心化配置服务使用如Nacos、Apollo、Consul、etcd等。应用启动时从中心拉取配置并订阅变更。当配置中心的数据变化时会主动通知或由应用定期拉取触发本地配置的更新回调。文件监听对于文件配置可以使用像watchdogPython这样的库来监听配置文件的变化事件。一旦文件被修改就重新加载并解析配置。关键设计点原子性更新热更新应该以整个配置对象或至少一个完整的逻辑模块为单位进行替换避免出现配置项中间状态不一致的情况。更新回调提供注册回调函数的机制。当某个配置组如SessionConfig更新时负责管理Session生命周期的SessionManager能收到通知并优雅地应用新策略例如逐步淘汰旧超时时间的Session而不是立即切断所有连接。线程安全确保配置对象在被多个线程读取时是安全的。通常采用“拷贝-替换”的模式在后台线程准备新的配置对象准备就绪后通过一个原子操作替换掉全局的配置引用。3. 核心对象Session与Agent的生命周期管理有了强大的配置系统作为支撑我们就可以游刃有余地设计和实现我们的核心对象了。我们以Session和Agent这两个典型对象为例。3.1 Session对象状态保持与隔离的基石Session的本质是有状态服务对无状态协议如HTTP的一种补偿机制。它在一个会话周期内在服务端维持用户相关的状态。核心属性session_id唯一标识符通常通过Cookie或URL参数传递。creation_time/last_accessed_time用于实现超时淘汰。attributes一个键值对容器用于存储任意会话数据如用户ID、购物车内容。生命周期管理Session的生命周期通常由SessionManager来管理。它的核心职责包括创建根据请求生成唯一的session_id创建空的Session对象并可能将其持久化到存储内存、Redis、数据库。查找根据传入的session_id从存储中加载对应的Session数据并反序列化为对象。访问更新每次对Session的读/写操作都应更新其last_accessed_time以延迟其过期。失效与销毁用户登出或Session超时时主动将其标记为失效并从存储中清理数据。配置如何驱动Session管理超时时间session.timeout配置项直接决定了SessionManager清理过期Session的策略。存储策略session.store.typememory/redis/database配置决定了SessionManager使用哪种存储后端。对应的连接参数如Redis的host、port也来自配置。Cookie特性session.cookie.name、secure、http_only、domain等直接影响如何设置响应头中的Set-Cookie关乎安全性。常见问题与排查Local Session Manager占用CPU过高这通常发生在使用内存存储如Tomcat的StandardManager且Session数量极大时。管理器需要周期性扫描所有Session判断是否过期。解决方案1) 缩短扫描间隔的代价是CPU开销延长间隔则可能导致内存不能及时释放。需要权衡。2) 更优方案是使用外部存储如Redis并利用Redis的过期键功能自动淘汰将CPU压力转移。Session丢失可能原因包括1) Cookie未正确设置或传递检查secure、http-only、domain/path设置。2) 存储层故障如Redis宕机。3) 集群环境下负载均衡未启用粘性会话sticky session且Session未在节点间共享。Pending authentication: please accept debugging session on the device这更像是一个客户端调试授权提示但与Session理念相通。它表明一个认证会话正在等待客户端确认。在服务端设计中对于pending状态的会话也应设置一个较短的超时时间并通过配置管理避免资源被无限占用。3.2 Agent对象能力单元的动态组装在AI智能体Agent系统中Agent是一个能感知环境、进行决策并执行动作的软件实体。一个复杂的Agent可能由多个“技能”Skill或“工具”Tool组合而成。核心属性agent_id唯一标识。status运行中、空闲、停止。context当前对话或任务的上下文信息。skills一个技能实例的列表每个技能封装了特定的能力如调用搜索API、执行代码、查询数据库。生命周期管理Agent的生命周期可能比Session更复杂涉及初始化、技能加载、任务执行、状态重置等。初始化根据配置创建Agent实例。关键步骤根据agent.enabled_skills配置列表通过工厂模式或依赖注入动态实例化对应的技能对象并装配到Agent中。这实现了“配置驱动能力组装”。任务执行接收输入如用户问题让Agent根据上下文和技能库进行规划、选择并执行技能。资源管理Agent可能持有网络连接、大模型客户端等资源。需要提供start()、stop()或dispose()方法来妥善管理这些资源的生命周期。池化对于耗时较长的Agent如那些需要加载大模型的可以考虑使用对象池Object Pool来避免频繁创建销毁的开销。配置如何驱动Agent管理技能列表这是最直接的驱动。通过修改enabled_skills我们可以为不同场景的Agent装配不同的能力包无需修改代码。资源参数例如每个技能可能都有自己的配置如API密钥、模型名称、超时时间。这些都可以通过配置系统如skills.web_search.api_key注入到具体的技能对象中。并发控制agent.worker_count可以控制处理请求的线程池或协程池大小。常见问题与排查Agent能力加载失败检查enabled_skills配置的技能名称是否与代码中注册的技能工厂类名一致。技能初始化时的依赖如API客户端是否已正确配置并初始化。技能执行超时或阻塞为每个技能的execute方法设置超时控制。超时时间可以作为该技能的配置项。使用异步Async或超时中断机制防止一个技能卡死整个Agent。内存泄漏Agent的context或技能内部可能累积数据。需要确保任务完成后能正确清理上下文或者对Agent设置一个空闲超时超时后将其整个回收重置。4. 配置与对象的协同实战以SessionManager为例让我们通过一个简化的SessionManager实现来看看配置系统如何与核心对象的管理器深度集成。# session_manager.py import time import threading from typing import Optional, Dict from .config import AppConfig # 导入我们之前定义的配置结构 from .session import Session from .storage import StorageBackend, MemoryStorage, RedisStorage class SessionManager: def __init__(self, config: AppConfig): self.config config.session self._sessions: Dict[str, Session] {} self._lock threading.RLock() # 根据配置选择存储后端 store_type self.config.store_type if store_type “memory”: self._storage MemoryStorage() elif store_type “redis”: self._storage RedisStorage( hostself.config.redis_host, portself.config.redis_port, passwordself.config.redis_password, dbself.config.redis_db, ) else: raise ValueError(f“Unsupported store type: {store_type}”) # 启动后台清理线程仅内存存储需要 if store_type “memory”: self._cleanup_thread threading.Thread(targetself._cleanup_expired_sessions, daemonTrue) self._cleanup_thread.start() def create_session(self) - Session: 创建新会话 session_id self._generate_id() new_session Session( idsession_id, creation_timetime.time(), last_accessed_timetime.time(), max_inactive_intervalself.config.timeout # 使用配置的超时时间 ) with self._lock: self._storage.save(session_id, new_session.serialize()) return new_session def get_session(self, session_id: str) - Optional[Session]: 获取会话并更新访问时间 data self._storage.load(session_id) if not data: return None session Session.deserialize(data) # 检查是否已过期 if session.is_expired(): self._storage.delete(session_id) return None # 更新访问时间 session.last_accessed_time time.time() self._storage.save(session_id, session.serialize()) # 写回存储更新访问时间 return session def invalidate_session(self, session_id: str): 使会话失效 self._storage.delete(session_id) def _cleanup_expired_sessions(self): 后台线程定期清理过期会话仅用于内存存储优化 while True: time.sleep(self.config.cleanup_interval) # 清理间隔也来自配置 with self._lock: now time.time() expired_ids [] # 这里简化了遍历逻辑实际生产环境需要更高效的扫描方式 for sid, data in self._storage.get_all_items(): session Session.deserialize(data) if session.is_expired(now): expired_ids.append(sid) for sid in expired_ids: self._storage.delete(sid) def _generate_id(self) - str: 生成安全的会话ID import secrets return secrets.token_urlsafe(32)关键点解析配置注入SessionManager的构造函数接收一个完整的AppConfig对象或至少是SessionConfig。所有行为参数超时时间、存储类型、Redis连接信息、清理间隔都来源于此。这意味着只要修改配置管理器的行为就会改变。策略模式存储后端的选择MemoryStoragevsRedisStorage通过配置驱动在初始化时动态决定。这符合开闭原则未来要新增一种存储如Memcached只需添加新的存储类并扩展配置解析即可无需修改SessionManager的核心逻辑。生命周期与配置联动后台清理线程的启动与否、清理间隔都由配置控制。对于Redis这类自带过期功能的存储我们甚至可以关闭这个线程完全依赖Redis的TTL。5. 环境配置与依赖管理从开发到部署的连贯性“在我机器上是好的”——这句经典名言道出了环境差异带来的痛苦。配置系统的另一项重要使命就是保证应用在不同环境开发、测试、生产下行为的一致性。这不仅仅是配置文件不同更涉及系统级依赖的配置。5.1 系统环境变量与运行时依赖很多问题出现在应用启动之前因为所需的运行时环境未正确配置。“uniapp 运行报错 cli项目运行依赖本地的nodejs环境,请先安装并配置到系统环境变量”这是一个典型的环境变量PATH配置问题。Node.js的可执行文件nodenpm所在目录必须被添加到系统的PATH环境变量中这样命令行在任何位置都能找到它们。“windows系统下chromedriver安装与selenium环境配置指南”Selenium需要ChromeDriver来操控浏览器。ChromeDriver的路径也需要被放入PATH或者通过webdriver.chrome.driver系统属性显式指定。这个过程同样可以通过配置来管理在应用的配置文件中指定一个chromedriver.path启动脚本读取这个配置并设置相应的系统属性。最佳实践使用环境管理工具Python使用virtualenv或conda创建隔离的Python环境并通过requirements.txt或pyproject.toml精确管理包版本。Node.js使用nvm管理Node版本使用npm或yarn配合package.json。Java使用Maven或Gradle管理依赖JAVA_HOME环境变量指向正确的JDK。配置与启动脚本编写一个启动脚本如start.sh或start.bat在这个脚本中完成最终的环境准备。例如脚本可以检查必要的环境变量JAVA_HOMENODE_PATH是否存在检查Chromedriver是否存在然后组装最终的Java命令或Node命令来启动应用并将应用配置文件路径作为参数传入。5.2 多环境配置策略配置文件分层application.yaml(或.env)存放所有环境的默认配置和不敏感的通用配置。application-{env}.yaml存放特定环境的覆盖配置如application-prod.yaml。通过启动参数--spring.profiles.activeprod或环境变量APP_ENVprod来激活特定环境配置。敏感信息分离将数据库密码、API密钥等全部移出配置文件。在开发环境可以放在本地的.env.local文件中并加入.gitignore。在生产环境通过容器编排平台如Kubernetes Secrets或云服务商提供的密钥管理服务注入为环境变量。配置中心在微服务架构中强烈建议使用配置中心。它不仅能实现环境隔离还能提供配置的版本管理、灰度发布、实时推送等功能。6. 疑难杂症排查清单与性能调优在实际运维中围绕核心对象和配置系统的问题层出不穷。这里整理一份快速排查清单和调优思路。6.1 常见问题速查表问题现象可能原因排查步骤Session频繁丢失1. Cookie设置问题secure/httpOnly/domain。2. 服务器时间不同步。3. 存储层故障Redis连接超时/宕机。4. 集群环境下Session未共享。1. 检查浏览器开发者工具中的Cookie详情。2. 检查服务器时间。3. 检查存储服务Redis监控和日志。4. 确认负载均衡策略和Session存储是否跨节点共享。Agent初始化失败报“Skill not found”1. 配置文件中enabled_skills拼写错误。2. 对应的技能类未正确注册到工厂。3. 技能类初始化时依赖的配置项缺失或错误。1. 核对配置文件与技能注册名。2. 检查技能工厂类的注册逻辑。3. 查看技能类初始化日志确认其依赖的配置是否已加载。应用启动报“Configuration property X is invalid”1. 配置值类型错误如字符串给了数字。2. 配置值违反验证规则如负数给了要求正数的字段。3. 必需的配置项缺失。1. 查看启动日志中的详细错误信息定位具体配置项。2. 检查对应环境dev/prod的配置文件。3. 检查环境变量是否覆盖了配置文件并产生了冲突。Local Session Manager CPU占用高1. Session数量过多。2. 过期扫描间隔太短。3. 使用了低效的内存存储扫描算法。1. 监控Session数量考虑引入分布式存储。2. 适当调大cleanup_interval权衡内存占用。3. 考虑使用延迟过期策略或改用Redis等有自动过期功能的存储。配置热更新不生效1. 配置文件监听未正确启动。2. 配置中心客户端订阅失败。3. 更新回调函数未注册或执行出错。1. 检查文件监听器的日志。2. 检查配置中心连接状态和订阅关系。3. 在更新回调函数内添加日志确认是否被触发。6.2 性能与资源调优建议Session存储选型内存最快但无法跨进程/节点共享且易丢失。仅适用于单机小型应用或开发环境。Redis高性能、支持持久化、自带过期机制、可跨节点共享。生产环境首选。注意合理设置连接池参数和Redis内存淘汰策略。数据库性能相对较差但数据持久化最可靠。适用于Session数据量极大或需要复杂查询的场景。务必为session_id和last_accessed_time字段建立索引。Agent对象池化对于初始化成本高的Agent例如加载了大模型权重使用对象池避免重复初始化。池大小应根据agent.worker_count和系统资源动态调整。太小会导致请求排队太大会占用过多内存。池中的Agent对象在归还时应进行必要的状态重置清理上下文避免数据泄露到下一个任务。配置缓存配置读取应避免频繁的IO操作。在应用启动时一次性加载到内存中的结构化对象里。对于热更新采用“原子引用”切换整个配置对象而不是逐个字段更新保证读操作的线程安全和一致性。监控与告警为SessionManager暴露关键指标活跃Session数、创建/销毁速率、存储操作耗时。为Agent系统暴露指标任务队列长度、各技能执行耗时与成功率、Agent池使用率。为配置系统本身暴露指标配置加载/刷新次数、失败次数。当这些指标出现异常如Session数暴涨、技能执行超时率升高时能第一时间触发告警。7. 从理论到实践构建一个简易的配置化Agent框架最后让我们把本章的概念串联起来勾勒一个简易但五脏俱全的、由配置驱动的Agent框架实现思路。这个框架将清晰地展示配置、核心对象Agent、Skill、管理器AgentManager是如何协同工作的。框架组件设计配置层使用Pydantic模型定义AgentConfig、SkillConfig等支持从YAML和环境变量加载。技能抽象层定义BaseSkill抽象类要求所有技能实现execute(context, input)方法和name属性。技能工厂维护一个技能名 - 技能类的注册表。根据配置中的enabled_skills列表通过工厂动态创建技能实例。Agent核心类包含agent_id、context和skills列表。其run(input)方法负责遍历技能、选择并执行合适的技能。Agent管理器负责Agent的生命周期创建、缓存、销毁可能实现为Agent池。其初始化依赖AgentConfig。核心流程代码示意# 1. 配置定义 class SkillConfig(BaseSettings): api_key: Optional[str] None timeout: int 30 class WebSearchSkillConfig(SkillConfig): search_engine: str “bing” endpoint: str “https://api.bing.microsoft.com/v7.0/search” class AgentConfig(BaseSettings): name: str enabled_skills: List[str] [] skills_config: Dict[str, Any] {} # 嵌套各技能的具体配置 max_workers: int 5 # 2. 技能基类与实现 class BaseSkill(ABC): def __init__(self, config: SkillConfig): self.config config property abstractmethod def name(self) - str: pass abstractmethod async def execute(self, context: Dict, input: str) - str: pass class WebSearchSkill(BaseSkill): name “web_search” def __init__(self, config: WebSearchSkillConfig): super().__init__(config) self.client SearchClient(config.endpoint, config.api_key) async def execute(self, context: Dict, input: str) - str: # 调用搜索API的逻辑 results await self.client.search(input, timeoutself.config.timeout) return format_results(results) # 3. 技能工厂 class SkillFactory: _registry: Dict[str, Type[BaseSkill]] {} classmethod def register(cls, name: str, skill_cls: Type[BaseSkill]): cls._registry[name] skill_cls classmethod def create(cls, name: str, global_config: Dict) - BaseSkill: if name not in cls._registry: raise ValueError(f“Skill ‘{name}’ not registered.”) skill_cls cls._registry[name] # 从全局配置中提取该技能特有的配置并实例化对应的Config模型 skill_config_dict global_config.get(“skills_config”, {}).get(name, {}) # 这里需要根据skill_cls对应的Config类来解析略去细节 config_model … # 解析出 WebSearchSkillConfig 等 return skill_cls(config_model) # 注册技能 SkillFactory.register(“web_search”, WebSearchSkill) # 4. Agent 类 class Agent: def __init__(self, agent_id: str, config: AgentConfig): self.agent_id agent_id self.config config self.skills [] self._init_skills() def _init_skills(self): for skill_name in self.config.enabled_skills: skill SkillFactory.create(skill_name, self.config.dict()) self.skills.append(skill) async def run(self, user_input: str, context: Dict) - str: # 简化的决策逻辑按顺序尝试执行第一个能处理的技能 for skill in self.skills: # 这里应有更复杂的路由或规划逻辑 if self._can_handle(skill, user_input): result await skill.execute(context, user_input) context.update({“last_skill”: skill.name, “last_result”: result}) return result return “I don’t know how to handle that.” # 5. AgentManager 与主程序入口 class AgentManager: def __init__(self, config: AgentConfig): self.config config self.agent_pool {} # 简单的池实际可用更复杂的结构 def get_agent(self, agent_id: str) - Agent: if agent_id not in self.agent_pool: self.agent_pool[agent_id] Agent(agent_id, self.config) return self.agent_pool[agent_id] # 应用启动 def main(): # 加载配置 app_config AppConfig() # 这会自动从环境变量和‘config.yaml’加载 # 初始化管理器 agent_manager AgentManager(app_config.agent) # 模拟处理请求 async def handle_request(user_id: str, query: str): agent agent_manager.get_agent(user_id) context agent_manager.get_context(user_id) response await agent.run(query, context) return response # 启动服务...在这个框架中一切皆由配置驱动启用哪些技能、技能自身的参数、Agent的并发数。要新增一个技能你只需要1) 实现BaseSkill2) 用SkillFactory.register注册它3) 在配置文件的enabled_skills列表里加上它的名字。无需修改Agent或AgentManager的代码。这极大地提升了系统的可扩展性和可维护性。最后的叮嘱核心对象与配置系统是软件工程中“分离关注点”和“控制反转”思想的经典体现。好的设计能让你的代码像乐高积木一样通过不同的配置组合轻松搭建出适应不同场景的应用。而理解并妥善处理它们的生命周期、依赖关系和配置来源则是确保这座大厦稳固不垮的关键。当你再遇到“环境问题”、“配置不生效”、“对象状态错乱”时希望你能从本章梳理的脉络中快速定位到那个出错的“齿轮”。