Seedance 2.0与飞书机器人安全集成：RBAC加固与租户隔离实战 1. 项目概述当Seedance 2.0遇上飞书安全集成是道必答题最近在帮一个客户做Seedance 2.0与飞书机器人的深度集成项目过程中踩了不少坑也发现了一些在官方文档里语焉不详、但在实际企业部署中至关重要的安全问题。特别是那个“RBAC权限绕过漏洞”以及如何将飞书自带的“应用可见范围”与Seedance的多租户隔离策略对齐这两个点要是没处理好轻则数据泄露重则整个AI助理服务被滥用。网上关于Seedance的讨论大多集中在怎么用它生成酷炫的提示词或者调用AI接口但真正要把这套系统在企业级飞书环境里跑起来安全配置才是那个最核心、也最容易出岔子的环节。Seedance 2.0作为一个功能强大的AI智能体平台通过飞书机器人这个入口能做的事情太多了——读取群消息、访问云文档、管理日程任务甚至操作多维表格。这带来的效率提升是肉眼可见的但与此同时攻击面也被急剧放大。想象一下如果一个未授权的用户通过某种方式绕过了你精心设计的角色权限RBAC直接以管理员的身份向机器人发号施令会发生什么他可能批量导出通讯录、删除重要文档、甚至利用机器人的能力向全公司发送欺诈信息。这绝不是危言耸听在复杂的群聊交互和Webhook回调机制下权限校验的链条上任何一个环节的疏忽都可能导致全线崩溃。所以这篇内容我想抛开那些花哨的功能演示聚焦在最“硬核”也最实际的安全集成规范上。我会先带大家复现一个典型的、基于Spring Security JWT的RBAC权限绕过漏洞场景看看攻击者是如何一步步得手的。然后我们会深入飞书开放平台的后台把“应用可见范围”这个配置项彻底吃透并把它与Seedance 2.0自身的租户隔离策略进行精准对齐。目标只有一个构建一个从飞书入口到Seedance后端业务逻辑的、无懈可击的安全防线。无论你是正在规划集成方案的技术负责人还是在一线调试代码的开发者这些实战经验都能帮你避开我踩过的那些坑。2. 核心安全风险拆解RBAC漏洞与飞书权限模型的错位在开始动手配置之前我们必须先搞清楚敌人是谁以及我们的防御体系可能在哪里出现裂缝。Seedance 2.0与飞书机器人的集成本质上构建了一个“飞书用户 - 飞书机器人 - Seedance后端服务 - 企业内部数据/服务”的调用链。安全风险就潜伏在这个链条的每一个转换环节。2.1 RBAC权限绕过漏洞的典型场景与原理很多团队在实现Seedance后端时会采用经典的SpringBoot Spring Security JWT RBAC架构。这个组合拳听起来很稳妥但魔鬼藏在细节里。我复现的这个漏洞根源在于对JWT令牌Token中“角色Role”声明的过度信任以及权限校验逻辑的上下文缺失。漏洞复现步骤正常流程用户A普通员工在飞书群里机器人请求“帮我查一下项目X的文档”。飞书服务器会将这个事件通过Webhook推送到你的Seedance后端。Webhook请求体里会携带一个重要的参数event.sender.sender_id.open_id即用户的OpenID。你的后端服务收到后通常会用这个OpenID去查询内部用户系统映射出对应的内部用户ID和角色比如ROLE_USER。根据请求的意图“查询文档”Spring Security的PreAuthorize(“hasRole(‘USER’)”)或类似的注解进行校验。由于用户A的角色是USER且“查询文档”这个接口允许USER角色访问请求通过。攻击者视角攻击者B同样是普通员工发现了问题。他注意到当机器人以“应用”身份调用飞书API比如主动发消息时使用的是tenant_access_token而当机器人处理用户请求时飞书传递的是用户的open_id。关键在于后端服务是否严格区分了“本次请求的权限上下文到底属于哪个实体”漏洞利用攻击者B可以尝试伪造或篡改Webhook请求。虽然直接伪造飞书官方的Webhook签名很难但他可以通过其他方式“污染”请求上下文。一个常见的错误是在后端代码中将从JWT解析出的角色信息与从数据库查询出的用户角色错误地绑定或缓存。例如// 错误示例将用户OpenID与角色缓存在一起且缓存键可能被预测或遍历 String cacheKey “user_role:” openId; // 攻击者可能通过大量请求触发某些边界条件使缓存中存入一个他控制的openId对应管理员角色的记录。更隐蔽的一种情况是Seedance后端某些管理接口比如“重新加载AI模型”、“查看所有对话日志”的权限校验依赖的是一个全局的、与应用绑定的管理令牌而这个令牌的校验逻辑如果和用户请求的校验逻辑混在一起就可能被绕过。攻击者B可能通过构造特殊的请求路径或参数让请求误入管理接口的处理逻辑而该逻辑只验证了一个弱口令的“管理令牌”这个令牌或许就硬编码在代码里或者通过不安全的配置泄露了。漏洞核心权限校验没有和唯一的、不可伪造的飞书用户身份open_idunion_id以及本次请求的原始意图进行强绑定。校验过程可能被中间件、缓存、或者混乱的代码逻辑干扰导致“谁是发起者”这个问题变得模糊。2.2 飞书“应用可见范围”与Seedance“租户”的概念鸿沟解决了后端逻辑的漏洞我们还要面对平台层面的配置对齐问题。这是很多企业集成时最头疼的地方。飞书“应用可见范围”这是在飞书开放平台创建应用时设置的一项基础配置。它决定了你这个应用机器人能被哪些部门的员工看到并添加到会话中。它主要是一个“可见性”控制。例如你设置应用仅对“研发中心”部门可见那么其他部门的员工在飞书应用目录或搜索机器人时根本找不到它。但是这并不等同于数据访问权限一个“研发中心”的员工添加了机器人后理论上机器人通过该员工授权的user_access_token可以访问该员工有权访问的任何数据这可能包括全公司的公开文档、他所在的跨部门群聊等。可见范围控制的是入口而非门内的行动范围。Seedance 2.0“租户隔离”Seedance作为多租户SaaS平台或自建系统其“租户”概念通常对应一个独立的企业或团队数据在租户间是严格逻辑或物理隔离的。Seedance的后台会为每个租户分配唯一的tenant_id。它的权限模型RBAC是在这个tenant_id边界内生效的。例如租户A的管理员绝对无法管理租户B的用户。风险点就在于两者的错配 假设你们公司有“集团总部”和“子公司B”两个飞书组织实际可能是同一个飞书企业下的不同部门树。你开发了一个Seedance机器人应用希望只给“子公司B”使用。错误配置你在飞书后台将应用可见范围设置为“子公司B”。你以为万事大吉。实际风险“集团总部”的某个员工如果被“子公司B”的员工拉入了一个包含该机器人的群聊他就能在群里机器人。此时机器人收到的Webhook请求中该总部员工的open_id对应在Seedance里哪个租户如果你的后端代码简单地用open_id去全局查找用户很可能因为找不到而返回一个默认租户比如第一个租户或者错误地将其映射到“子公司B”的租户下。这就导致了跨租户的数据混淆和越权访问。所以我们的目标是将飞书的“组织架构可见性”与Seedance的“租户数据边界”进行精准映射和强制校验这需要我们在后端逻辑中建立一个可靠的映射层。3. 安全集成架构设计与核心组件解析基于上面的风险分析一个健壮的安全集成架构必须包含以下核心组件它们环环相扣共同构成防御体系。3.1 四层防御体系总览我们的安全设计遵循“纵深防御”原则不依赖任何单一环节。飞书平台层管控利用飞书开放平台提供的原生安全能力守住第一道门。包括应用可见范围、API权限清单、IP白名单等。请求接入层校验在Seedance后端服务的入口对飞书Webhook请求进行真实性、完整性验证并提取可信的身份上下文。身份映射与租户隔离层这是最核心的一层负责将飞书的用户/部门身份准确无误地映射到Seedance内部的租户和用户角色上并确保所有后续操作都在正确的租户上下文内进行。业务逻辑层权限校验在具体的业务代码中结合Spring Security等框架进行细粒度的角色和权限校验。3.2 关键组件详解飞书事件订阅与签名验证所有用户与机器人的交互都始于飞书服务器向你后端发送的一个HTTPS POST请求Webhook。确保这个请求真的来自飞书是一切安全的前提。飞书事件订阅验证流程飞书侧配置在开放平台后台你需要配置请求校验令牌Verification Token和加密密钥Encryption Key。飞书会在特定事件如首次验证URL、消息事件中用到它们。后端验证逻辑以Spring Boot为例import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import org.apache.commons.codec.binary.Hex; PostMapping(“/feishu/webhook”) public String handleEvent(RequestBody String requestBody, RequestHeader(“X-Lark-Signature”) String signature, RequestHeader(“X-Lark-Request-Timestamp”) String timestamp, RequestHeader(“X-Lark-Request-Nonce”) String nonce) { // 1. 防止重放攻击检查时间戳是否在合理范围内如5分钟内 long currentTime System.currentTimeMillis() / 1000; long requestTime Long.parseLong(timestamp); if (Math.abs(currentTime - requestTime) 300) { // 5分钟 throw new SecurityException(“Request timestamp expired.”); } // 2. 拼接验证字符串 String dataToSign timestamp “\n” nonce “\n” requestBody; // 3. 使用你在飞书后台配置的Encryption Key进行HMAC-SHA256签名 String calculatedSignature; try { Mac mac Mac.getInstance(“HmacSHA256”); SecretKeySpec secretKeySpec new SecretKeySpec(encryptionKey.getBytes(“UTF-8”), “HmacSHA256”); mac.init(secretKeySpec); byte[] hash mac.doFinal(dataToSign.getBytes(“UTF-8”)); calculatedSignature Hex.encodeHexString(hash); } catch (Exception e) { throw new RuntimeException(“Failed to calculate signature”, e); } // 4. 比对签名 if (!calculatedSignature.equals(signature)) { throw new SecurityException(“Invalid signature. Request may be forged.”); } // 5. 签名验证通过解析请求体 // ... 后续处理逻辑 return “success”; }注意Encryption Key必须妥善保管绝不能硬编码在客户端代码或前端。推荐使用环境变量或配置中心如Apollo, Nacos来管理。这个验证过程确保了请求的完整性和来源真实性防止了中间人篡改或伪造Webhook请求。只有通过这关的请求我们才会认为它携带的open_id、event等信息是可信的。4. 核心实现构建身份映射与租户强隔离系统签名验证只是拿到了“可信数据”接下来我们要把这些数据翻译成Seedance系统能理解的“身份”和“权限”。4.1 设计安全的用户-租户映射表这是整个系统的中枢神经。我们需要在Seedance的后台数据库或缓存中建立一张映射表。CREATE TABLE feishu_tenant_mapping ( id bigint(20) NOT NULL AUTO_INCREMENT, feishu_department_id varchar(128) NOT NULL COMMENT ‘飞书部门ID可从事件或用户信息API获取’, feishu_union_id varchar(128) DEFAULT NULL COMMENT ‘飞书用户Union ID用于唯一标识用户’, seedance_tenant_id varchar(64) NOT NULL COMMENT ‘对应的Seedance租户ID’, seedance_user_id varchar(64) DEFAULT NULL COMMENT ‘在Seedance系统内的用户ID可为空仅部门映射’, seedance_default_role varchar(32) DEFAULT ‘USER’ COMMENT ‘该映射下的默认角色’, is_admin_mapping tinyint(1) DEFAULT ‘0’ COMMENT ‘是否是租户管理员映射1:是0:否’, status tinyint(4) DEFAULT ‘1’ COMMENT ‘状态1-有效0-无效’, created_at datetime DEFAULT CURRENT_TIMESTAMP, updated_at datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_feishu_dept_union (feishu_department_id,feishu_union_id), KEY idx_tenant (seedance_tenant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT‘飞书-租户映射表’;这张表的设计逻辑和查询策略是关键优先查询union_id当收到一个Webhook事件时首先尝试用事件中的event.sender.sender_id.union_id去映射表查询。union_id是用户在同一个飞书开发者账号下的唯一标识最可靠。如果能查到直接返回对应的seedance_tenant_id和seedance_user_id。降级查询open_id 部门如果union_id为空某些情况下飞书可能不返回或者映射表中未找到则使用event.sender.sender_id.open_id结合event.sender.sender_id.department_ids用户所属部门列表进行查询。逻辑是找出该用户所属部门中在映射表里存在的、且状态有效的记录。如果找到多条则需要一个冲突解决策略强烈建议采用“最小部门ID”或指定优先级部门确保一致性。兜底与拒绝如果通过以上方式都无法确定租户那么这次请求必须被拒绝。可以记录详细日志并告警提示“未知用户或未授权部门访问”。绝对不允许赋予一个默认租户如第一个租户。4.2 增强RBAC实现租户上下文感知的权限校验传统的PreAuthorize(“hasRole(‘ADMIN’)”)注解在这里不够用了因为它不知道当前请求属于哪个租户。我们需要对其进行增强。方案一自定义Security表达式Component(“tenantSecurity”) public class TenantSecurityExpressionRoot extends SecurityExpressionRoot { private final TenantContext tenantContext; // 当前请求的租户上下文 public TenantSecurityExpressionRoot(Authentication authentication) { super(authentication); } public boolean isTenantAdmin() { UserDetails userDetails (UserDetails) this.authentication.getPrincipal(); // 检查用户是否在当前租户(tenantContext.getCurrentTenantId())下拥有ADMIN角色 return userService.hasRoleInTenant(userDetails.getUsername(), tenantContext.getCurrentTenantId(), “ROLE_TENANT_ADMIN”); } public boolean hasPermissionInTenant(String permissionCode) { UserDetails userDetails (UserDetails) this.authentication.getPrincipal(); return permissionService.checkPermission(userDetails.getUsername(), tenantContext.getCurrentTenantId(), permissionCode); } } // 在Controller中使用 RestController RequestMapping(“/api/tenant/{tenantId}/docs”) public class DocumentController { GetMapping(“/{docId}”) PreAuthorize(“tenantSecurity.isTenantAdmin() or tenantSecurity.hasPermissionInTenant(‘DOC_READ’)“) public ResponseEntityDocument getDocument(PathVariable String tenantId, PathVariable String docId) { // 方法内无需再校验tenantId与当前用户租户是否匹配注解已保证 // 但业务逻辑仍需使用tenantId参数来查询数据确保数据范围隔离 // … } }方案二在Service层进行强制校验对于更复杂的业务逻辑或者在非Controller层如Async方法、消息监听器可以在Service方法入口进行显式校验。Service public class DocumentService { Autowired private TenantContext tenantContext; Autowired private PermissionValidator permissionValidator; public Document getDocument(String docId) { // 1. 获取当前请求的租户ID从ThreadLocal或SecurityContext中 String currentTenantId tenantContext.getCurrentTenantId(); if (currentTenantId null) { throw new AccessDeniedException(“No tenant context found.”); } // 2. 查询文档并强制关联租户条件 Document doc documentRepository.findByDocIdAndTenantId(docId, currentTenantId); if (doc null) { // 即使docId存在但不属于当前租户也返回空或拒绝防止信息泄露 throw new ResourceNotFoundException(“Document not found.”); } // 3. 可选进行更细粒度的权限校验如文档是否在用户可访问的项目中 if (!permissionValidator.canUserAccessDocument(getCurrentUserId(), doc)) { throw new AccessDeniedException(“You do not have permission to access this document.”); } return doc; } }实操心得无论采用哪种方案核心原则是“租户ID必须作为数据查询的强制过滤条件”。在MyBatis或JPA的查询中永远不要忘记加上where tenant_id #{tenantId}。建议使用框架层面的拦截器如MyBatis的Plugin自动注入租户ID避免开发人员遗漏。5. 飞书“应用可见范围”与Seedance租户的配置对齐实战理论说完了我们来一步步看怎么在飞书后台和Seedance管理端进行配置让两者严丝合缝。5.1 飞书开放平台配置详解创建应用与配置可见范围进入 飞书开放平台 创建企业自建应用。在“权限管理” - “应用可见范围”中不要直接选择整个公司。而是根据你的Seedance租户规划选择对应的部门或人员。例如如果你的Seedance只为“华东销售大区”服务那么就在这里只选择“华东销售大区”这个部门或其子部门。重要即使在这里做了限制也要清醒认识到这只是控制了“谁能找到并添加这个机器人”。一旦被添加权限控制就交给了你后端的映射逻辑。精细化配置API权限在“权限管理” - “权限配置”中遵循“最小权限原则”申请权限。参考前面网络资料中的表格仔细评估每个权限点位的风险。对于Seedance机器人我强烈建议的基线权限配置如下im:message:readonly(必选)接收用户发给机器人的消息。im:message:send_as_bot(必选)以机器人身份发送消息。contact:contact.base:readonly(谨慎选择)如果需要读取组织架构来辅助映射可以开通但要做好数据缓存和脱敏避免频繁调用。云文档、日程、任务等权限按需申请并且强烈建议通过user_access_token用户授权的方式动态获取而不是给应用全局的tenant_access_token权限。这样权限边界就是用户自己的权限边界更安全。配置事件订阅在“事件订阅”中订阅im.message.receive_v1接收消息等必要事件。填写请求网址URL你的Webhook端点并正确通过飞书的验证。这里填写的URL应该就是你部署了上述签名验证逻辑的后端API地址。启用加密并保存好Encryption Key。5.2 Seedance管理后台的租户与映射配置Seedance 2.0的管理后台需要提供相应的配置界面或者你需要通过数据库脚本/API来初始化映射关系。创建Seedance租户为每个需要接入的飞书组织单元如子公司、独立事业部在Seedance中创建一个独立的租户记录其tenant_id。初始化部门映射获取飞书目标部门的department_id。可以通过飞书 获取部门列表API 来获取。在Seedance的feishu_tenant_mapping表中插入记录将飞书部门ID与Seedance租户ID绑定。seedance_user_id和feishu_union_id暂时留空。示例INSERT INTO feishu_tenant_mapping (feishu_department_id, seedance_tenant_id, seedance_default_role) VALUES (‘od-xxx’, ‘tenant_sales_east’, ‘USER’);用户同步与映射可选但推荐可以开发一个同步任务定期调用飞书 获取部门用户列表API 将部门下的用户同步到Seedance用户表并建立union_id到seedance_user_id的映射记录。这样当Webhook请求到来时可以直接通过union_id命中映射效率最高也最准确。5.3 动态映射与“加群”事件处理现实情况是员工可能被拉入一个已经有机器人的群而这个群所属的部门可能不在你预设的映射里。或者一个来自已映射部门的员工被拉入了一个跨部门的群。处理流程当机器人被加入群聊im.chat.member.bot.added_v1事件或新成员入群im.chat.member.user.added_v1事件时你的后端会收到Webhook。解析事件获取群ID (chat_id) 和操作者/新成员的ID (operator_id/user_id)。调用飞书 获取群信息API 获取群的owner_id和member_user_id_list。关键决策这个群应该归属于哪个Seedance租户一个可行的策略是优先看群主(owner_id)所在的部门是否在映射表中。如果在就将此群绑定到该租户。如果群主部门未映射则查看群成员列表寻找第一个所在部门已被映射的成员以此确定租户。如果都无法确定则将此群标记为“待定”并限制机器人在该群的功能例如只响应基础帮助命令不执行任何数据查询或操作同时发送告警通知管理员。将确定的(chat_id, seedance_tenant_id)关系持久化到数据库供后续该群消息处理时使用。这套机制确保了即使是在复杂的跨部门协作场景下每一条消息都能被归因到正确的租户上下文中进行处理。6. 漏洞加固针对性的安全编码实践与审计有了架构和映射我们还需要在代码层面堵住常见的漏洞。6.1 修复RBAC权限绕过漏洞的代码示例回顾第2.1节的漏洞修复的核心在于确保每一次权限校验都具备完整的、不可篡改的上下文。修复方案实现一个租户感知的AuthenticationProviderComponent public class FeishuJwtAuthenticationProvider implements AuthenticationProvider { Autowired private TenantMappingService tenantMappingService; Autowired private JwtTokenUtil jwtTokenUtil; Override public Authentication authenticate(Authentication authentication) throws AuthenticationException { String token (String) authentication.getCredentials(); // 1. 验证JWT本身的有效性签名、过期时间 if (!jwtTokenUtil.validateToken(token)) { throw new BadCredentialsException(“Invalid JWT token”); } // 2. 从JWT中解析出声明Claim String feishuUnionId jwtTokenUtil.getUnionIdFromToken(token); String requestTenantId jwtTokenUtil.getTenantIdFromToken(token); // JWT中应包含发起请求时确定的tenant_id // 3. 关键步骤用unionId和请求中的tenantId去验证映射关系 TenantUserMapping mapping tenantMappingService.getMappingByUnionIdAndTenantId(feishuUnionId, requestTenantId); if (mapping null) { // 映射不存在说明用户不属于这个租户或令牌被篡改 throw new InsufficientAuthenticationException(“User is not authorized for this tenant.”); } // 4. 加载用户在**该租户下**的权限 ListGrantedAuthority authorities userService.loadAuthorities(mapping.getSeedanceUserId(), requestTenantId); // 5. 构建Authentication对象将tenantId也放入details或principal中 UserDetails userDetails new CustomUserDetails(mapping.getSeedanceUserId(), “[PROTECTED]”, authorities); UsernamePasswordAuthenticationToken result new UsernamePasswordAuthenticationToken( userDetails, null, authorities); result.setDetails(new TenantAuthenticationDetails(requestTenantId)); return result; } Override public boolean supports(Class? authentication) { return (UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication)); } }同时确保生成JWT的接口在生成令牌时必须将当前请求验证后得到的tenant_id写入Token的声明中后续所有接口的校验都依赖于此。6.2 定期安全审计与渗透测试清单安全不是一劳永逸的配置需要持续审计。建议定期检查以下清单检查项检查方法预期结果/修复建议飞书应用权限登录飞书开放平台检查应用已获取的权限列表。遵循最小权限原则移除未使用的敏感权限如im:message:recall消息撤回。映射表一致性抽查数据库feishu_tenant_mapping表对比飞书部门成员变化。确保离职员工、部门调整后的映射关系及时失效或更新。JWT密钥安全检查JWT签名密钥HS256或私钥RS256的存储位置。必须从环境变量或安全的密钥管理服务如Vault读取严禁硬编码。Webhook签名验证使用工具如Postman伪造一个带错误签名的请求到Webhook端点。端点必须返回4xx错误且不应执行任何业务逻辑。租户数据隔离以租户A的用户身份尝试访问租户B的资源ID如/api/docs/{docId}。应返回“未找到”或“无权访问”绝不能返回租户B的数据。错误信息泄露触发一些异常如数据库连接失败、映射不存在。返回给前端/飞书机器人的错误信息应通用化如“服务内部错误”避免暴露数据库结构、SQL语句、服务器路径等。API速率限制模拟短时间内大量发送消息给机器人。后端应启用速率限制如使用Spring Cloud Gateway或Redis防止恶意刷屏或DDoS。7. 监控、告警与应急响应再完善的防御也可能出现未知的绕过方式。因此建立监控和应急机制至关重要。关键日志记录在所有身份映射、权限校验的关键节点如映射失败、越权访问被拒绝、管理员操作记录结构化日志JSON格式包含tenant_id,user_id,open_id,request_path,action等字段方便后续溯源。异常行为告警同一用户高频敏感操作例如短时间内尝试访问大量不同部门的文档。映射失败率飙升可能预示着有大量来自未授权部门的访问尝试。权限校验失败日志激增可能正在发生暴力破解或权限探测。这些告警应实时通知到运维和安全团队通过钉钉、飞书群或短信。应急响应预案一级响应疑似漏洞立即在飞书开放平台将应用版本回退到上一个安全版本或临时禁用部分高危权限。同时在Seedance后端服务中对疑似攻击源IP或用户进行临时封禁。二级响应确认漏洞启动漏洞修复流程。根据日志定位漏洞点进行代码修复和测试。修复后更新飞书应用并全量发布。通知受影响租户的管理员。事后复盘必须形成书面报告分析漏洞根因更新安全编码规范并将此案例加入团队的安全培训。整个集成方案从飞书的一个简单配置到后端复杂的映射与校验逻辑其核心思想始终是“零信任”和“最小权限”。不要相信任何未经验证的输入不要授予任何超出必要的权限。将飞书的组织架构作为第一道粗粒度过滤网再用我们自建的精准映射和RBAC系统作为第二道细粒度防线这样才能让Seedance 2.0这样强大的AI能力在企业的飞书环境里安全、稳定地发挥价值。